A 13.6B bf16 DiT is ~27 GB: it does not fit a 24 GB card and streams across PCIe
every step. The INT8 copy fits. So the model page gets a "Build INT8 weights"
button beside the existing "INT8 DiT" switch — the switch said which weights to
USE, and nothing could produce them.

Deliberately an action, never a default. It is lossy and slow, the bf16 weights
are never touched, and un-ticking the switch goes straight back to them. A test
asserts nothing turns use_int8 on by itself.

It runs in LongCat's isolated py3.10 venv (upstream's helpers, torch 2.6), so it
is a worker script like training, not in-process — tools/longcat_quantize.py,
driven by longcat_worker.quantize_int8() on the same job/JSON-lines protocol, so
the existing progress plumbing needed no special case. Quantisation happens on the
CPU on purpose: the point is to produce a model that fits the card, so getting
there must not need the card.

One thing upstream's code could not do for us. load_quantized_dit() hardcodes the
AVATAR transformer class — correct for its avatar-only INT8 build, wrong for a
quantised BASE checkpoint. The avatar families keep using it; the base family gets
_load_quantized_base_dit(), the same procedure (build from the saved config, swap
every non-skipped Linear for QuantizedLinear, load the sharded state dict) against
LongCatVideoTransformer3DModel. Upstream's QuantizedLinear and skip patterns are
reused rather than restated, so the layout cannot drift from what wrote it.

The existing /admin/api/model-quantize routes a longcat-backed model here instead
of GPTQ/AWQ, which are for transformers this is not; quantize-status reports the
job the same way, so the page polls one endpoint. A model whose weights are not
downloaded yet is refused rather than silently started.

Not yet run against real weights — the 83 GB base checkpoint is still downloading.

43 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY