Gemma-3-12B-it clean encoder GGUFs for LTX-2.3 + JoyAI-Echo (Q8_0 + Q4_0)

Nodes, workflow, issues and releases: https://github.com/jlucasmcrell/joyai-echo-multishot-patch
All models: https://huggingface.co/joeygambino

A word on expectations: the multishot workflow this feeds is powerful but not one-click - first renders usually take some tuning to your VRAM, system RAM and model build. The workflow repo's INSTRUCTIONS.md covers setup and known failure modes, and I am happy to troubleshoot: open a discussion and I will answer.

A one-hop Q8_0 quantization of the TRUE base google/gemma-3-12b-it, in the loader format the JoyAI-Echo ComfyUI node pack expects. This is the exact text encoder the LTX-2.3 / JoyAI-Echo DiT family was trained against — nothing finetuned, nothing re-quantized.

Files

Both are one-hop quantizations of the same clean bf16 base, in the same loader format. Start with Q8_0; take Q4_0 if those 5 GiB are what fit your card.

Render at 24 fps — voices and accents (2026-07-30)

LTX-2.3's joint audio-video prior is 24 fps-native, and render fps turns out to be a hidden accent dial: at 25 fps the same prompt and seed render non-rhotic southern British, at 30 fps broad Australian — and any off-24 fps setting overrides accent wording in the prompt entirely (a few conditioning tokens cannot outvote a geometric signal present in every attention op at every step). Verified by A/B on identical configs: 24 fps = rhotic General American at 5/5 reviewer confidence, same text and seed.

Keep video_fps at 24 and state the accent in the positive prompt ("in a casual American accent"). Flip side: if you want an authentic British or Australian voice, rendering that scene at 25/30 fps is more consistent than any accent wording.

None of this is encoder-dependent: during the hunt this encoder was A/B'd against three alternates on identical prompts — accents never moved with the encoder, only with fps.

Why this exists

The commonly circulated gemma3-12b-joyecho-Q8_0.gguf is not base Gemma — its architecture string is a different, modified model, and it was built from an fp8 checkpoint and then re-quantized (double quantization; it carries .comfy_quant marker tensors from the fp8 stage). In my renders it produced duplicated subjects and identity corruption. The DiT reads base Gemma's embedding space; any encoder drift degrades output structurally, not subtly.

This file is built directly from the clean bf16 release in a single hop: measured ~0.55% RMS error on every spot-checked tensor, including the embedding table. Functionally the base encoder, at half the size.

Works with any LTX-2.x DiT you load through the pack — base LTX-2.3 dev, distilled, distilled-1.1, JoyAI-Echo, and every merge or finetune of them. The whole family was trained against base Gemma-3-12B-it; the encoder is shared, so this one file serves them all. (The pre-LTX-2 family, LTXV 0.9.x, uses a different encoder and is not covered.)

The practical payoff

The pack's GGUF encoder path keeps linear weights packed and memory-mapped — resident footprint is roughly 2.5 GB versus ~12 GB for the fp8 path. That is the difference between the encoder crowding a 24 GB rig's RAM and it barely registering. Conditioning is also cached by the pack after first encode, so the encoder cost is paid once per prompt set.

Compatibility — read this

• Loads in: the JoyAI-Echo GGUF node pack (gemma_file dropdown). Drop the file in ComfyUI/models/text_encoders/ and pick it. Tokenizer bytes are embedded; sidecar configs resolve from the pack.
• Does NOT load in: llama.cpp, Ollama, LM Studio, or any llama.cpp-based runtime. This file preserves HuggingFace tensor names (the pack's loader contract) instead of llama.cpp's naming. It is an encoder for a video pipeline, not a chat model.

Verification

All 48x7 text-tower linears present and name-verified against the loader's matching logic; embeddings and norms stored exactly; per-tensor dequant spot-checks at 0.54-0.58% RMS error vs bf16; tokenizer (spiece_model) bytes embedded byte-for-byte.

About the Q4_0 tier

Built on community request. Same recipe and same loader contract as the Q8_0, with one deliberate exception: model.embed_tokens.weight is held at Q8_0 while the 473 layer linears go Q4_0.

That embedding table is ~1B parameters (262144 x 3840) and is the most quantization-sensitive tensor in the model. llama.cpp's own K-quants protect token_embd for the same reason. Here the embeddings are the conditioning signal the DiT cross-attends to, so pushing them to 4 bits moves prompt semantics rather than merely losing precision. Protecting it costs ~0.5 GiB and is the difference between a usable tier and a subtly wrong one.

Measured against bf16: embeddings 0.575% RMS error (protected), layer linears 8.7-9.0%. For reference, the same 4-bit step on the DiT measured 9.9% error and 5.6 degrees of angular deviation in layer output direction.

Stated honestly: this file is verified structurally and per-tensor (architecture string, all 1066 tensor names and shapes identical to the Q8_0, all 48x7 text-tower linears present, tokenizer bytes embedded, dequant round-trip within the limits above). It has not been validated by rendering. That is deliberate rather than lazy - comparing renders cannot validate a quantization, because a weight perturbation this size walks the sampler to a different valid sample, so any PSNR or eyeball difference measures trajectory divergence rather than quality. If you use it and see prompt adherence slip relative to Q8_0, please open a discussion; that is the failure mode to watch.

License

Gemma is provided under and subject to the Gemma Terms of Use. This repository redistributes a quantized derivative of google/gemma-3-12b-it; the Gemma Terms of Use and its Prohibited Use Policy apply to this file and any use of it. Not affiliated with Google, Lightricks, JD, or RealRebelAI.

Support

Everything here is free and stays free. If it saved you time, you can sponsor me on GitHub, buy me a coffee, or support me on Liberapay.