Gemma-3-12B-it clean encoder GGUFs for LTX-2.3 + JoyAI-Echo (Q8_0 + Q4_0)
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
| file | size | what it is |
|---|
gemma3-12b-BASE-clean-Q8_0.gguf | 12.45 GiB | reference tier, ~0.55% RMS error vs bf16 |
gemma3-12b-BASE-clean-Q4_0.gguf | 7.31 GiB | half-size tier, embedding table held at Q8_0 |
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.
