SWIFT!
*If you found this model useful, please give it a like!
Welcome to SWIFT! a Fast and detailed Z Image Turbo base model.
The goal of this base model is to be fast yet detailed.
It also adds more variety to the original Z image Turbo model's female faces.
The model is in GGUF format; This greatly helps improve the speed of image creation.
How to use:
Exactly the same as the original Z image Turbo model, in GGUF version.
Use your preferred Z image Turbo configuration; a common one is:
Sampler: Euler simple, CFG 1, 10 steps.
To load GGUF models, use whichever charger of this type you prefer.
You can use this simple workflow:
https://civarchive.com/models/2535121/simple-gguf-workflow
-
Try it, you won't regret it!
Updates:
-SWIFT! NEO released. New checkpoint!
- I've changed the version name from v1.0 Preview to v1.0 Final. I believe the model doesn't need adjusting; this version is final.
Description
v1.0 Final
First version, focused on speed, more detailed.
FAQ
Comments (35)
I am extremely impressed with this model. I followed your workflow that I'm not used to but its easy to implement and replicate my earlier results. I must say in some cases it has produced better and more detailed results for around 20-30% less time taken on my RTX 3070 GPU. Thank you for making this, you've earned a fan! My only constructive feedback is the seed variance is still quite limiting, but that's a general complaint with ZIT, I have solved this by introducing a seedvarianceenhancer node.
I'm very honored by your words. I'm glad you like it and, above all, that you find it useful.
Your constructive criticism is welcome; everything has room for improvement, and after all, this is a new project, so expecting it to be free of imperfections would be presumptuous.
That it's useful is the most important thing for me right now.
Thank you very much :)
getting an error when loading UNET
While copying the parameter named "layers.29.attention_norm1.weight", whose dimensions in the model are torch.Size([3840]) and whose dimensions in the checkpoint are torch.Size([7680]), an exception occurred : ('only Tensors of floating point dtype can require gradients',).
Have you updated ComfyUI and the custom nodes? Which node are you using to load the model? These types of errors usually occur when you use an unsuitable loader.
The loader in the workflow I mentioned in the description should work fine for you.
@Liant I used the workflow from that red head image you have. And ComfyUI is updated I'm pretty sure.
@Liant I mean it's your workflow
@TheOooh Which Vae and Clip are you using?
It's a half quant DIT model. Use the "Unet Loader (GGUF/Advanced)" Node. it's in the GGUF node pack. Turn the dequant and patch to "target" and make it patch on device. Fixes both the tensor and gradient issue.
@lonecatone23 hmm, did that and still same error. quen_3_4b.safetensors for clip, type lumina2, device default?
@TheOooh Yeah, It's crashing on my basic Ksampler workflows as well and I can;t get around it, but then again so are all GGUF models.
I can't get it to work a excpt in my sandbox.
@TheOooh It runs on @Liant s workflow just fine. I probably have a node that crashes it downline on my workflow
@lonecatone23 that's the workflow I tried and got that error. Maybe some kind of conflict installation on my side. Very weird, never had problems like this before.
@TheOooh
*Update all installed custom nodes in comfyUI (I emphasize: the nodes)
*Make sure the model paths loaded by the nodes are correct. ( my GGUF, the VAE and the CLIP), Click again where the file is selected, in the three nodes, and make sure the desired file appears and you can select it.
*Make sure the VAE you're using is: ae.safetensors
*What arguments are you using to start ComfyUI? Use something like this:
--windows-standalone-build
and nothing else (I'm assuming you're using Windows)
My workflow is very simple; it should work for you. If you're still having problems, I would try downloading the VAE file and the CLIP file again. (They must be the same ones normally used for Z image Turbo)
@Liant soooo... afte a long day of wondering why my workflows were crashing.
The only loader that seems to work is the UNET one in your workflow. What happens is that downline, older nodes cause issues (gee 🙄). This is only a node issue, and it also crashes the official GGUF files as well.
Quite annoying
@Liant Yep, everything is loaded correctly. The only node gets an error color is the GGUF Loader after the error. Also I updated all my nodes, and tried 4 different GGUF loades. Still the same error. :(
@TheOooh are you on desktop?
@lonecatone23 yeah
@TheOooh At this point, what I would recommend (if you want to use the model) is to install ComfyUI PORTABLE elsewhere (not the Desktop version), and continue from that point with this clean installation.
@Liant Continuing on the subject of wrongly sized tensors, i had an issue with x_embedder.weight reported with the wrong size in stable-diffusion.cpp ([960, 256] vs [[3840, 64]). Nothing a copy from the original ZiT couldn't fix, but it can happens in some tool i believe.
@n_Arno It happens in the stock ComfyU_GGUf loader node sometimes. Try a UNET loader or KJ's version
@lonecatone23 ah, that's not the point as i don't use comfy and know enough python, pytorch and gguf to fix it myself (original Q8_0 => BF16 safetensor => fix errors => requant to Q4_K). But Neo Forge for example will probably complain ^^;
@n_Arno What can I say? the model has always charged fine in ComfyUI for me. It's never given me any problems. These kinds of errors, as @lonecatone23 mentioned, are usually because the charger (whichever one it is) isn't working properly, for some reason unrelated to the model. I can't add anything more to this because, like I said, I've never had any problems with this model in that regard :/
@Liant It's solid. Quants will always pop errors for people sometimes.
@lonecatone23@Liant it may be due to the tool used to make the quantized version. If it modify the model making it readable only by himself, that's an issue on my end, but like i said, not an unfixable issue. Just good to know: it does alter the model architecture.
After taking an other look at the file, i confirm the layer is modified as 256 × 960 but an additional metadata is added "comfy.gguf.orig_shape.x_embedder.weight" = "3840, 64".
This make it a quant that only works for Comfy (or tools that leverage comfy loader). Just good to know for other people 😉
@n_Arno again.....
use a different loader 🙄
@lonecatone23 again, not using comfy, no way to use an excentric loader that does custom stuff with the layers except expecting the proper layer shape. This is starting to feel stupid. I don't have an issue: i fixed the model, i can use it, it's a great model... but work only for comfy as-is and not everyone use this software. It would be a non-issue if a BF16 safetensors version of the checkpoint was available, i just wanted to point for people who may try it and are not using comfy that it will throw an error and fail ^^;
@n_Arno Thank you for the information regarding this. I'll keep it in mind for the future. The BF16 won't be publicly available, at least in the short term, for private reasons. So, for now, the solution is to use ComfyUI with an appropriate node or workarounds like the one you used.
I've tried several GGUF loaders on ComfyUI (desktop version), including the workflow by the author, to no avail. Hopefully, a stable solution to run this model will pop up eventually.
@cybercloud429 with the "fp8" gguf file provided here, i did a quick binary edit in-place to change the value of the tensor shape of x_embedder.weight and was able to load it as-is in stable-diffusion.cpp (the position of the edit is coming from analysis the gguf file beforehand). Be aware this could corrupt the file if done on the wrong version, back it up before this.
import struct
f = open("swiftFastAndDetailed_v10Final.gguf","r+b")
f.seek(44433)
f.write(struct.pack("Q",64))
f.write(struct.pack("Q",3840))
f.close()
I would have love to have access to the full BF16 safetensors to do my own Quant, Q8_0 is nice but too large for my GPU and re-quantizing a model is never a great idea 😅
The reason there aren't any "official" SWIFT! models with more lower quantization is that I made some, but in testing, their quality wasn't acceptable enough to publish.
Regarding BF16, I'm sorry to say that, at least for now, it won't be published.
@Liant No problem on my side, if you'd rather not publish it (either the BF16 or a lower quant) that's your right and not an issue for me. I'll stick for now to my low quality personnal re-quant (because i can't use it at all otherwise), i am looking for a future release 😊