4-Bit Training vs Adapter Sharing: Two Ways to Make One GPU Do More
LongLive-2.0 runs a whole long-video model in NVFP4 4-bit, cutting a 64s generation from 112.9 to 36.3 GB; MinT swaps LoRA adapters over one resident base, making handoff 18.3x faster on a 4B dense LLM.
The two bets
Both papers are answers to the same accounting problem: frontier models are too big for the hardware budgets people actually have, and the naive fix, “buy more GPUs,” stopped being a plan. But they attack the bill from opposite ends.
LongLive-2.0 makes the model itself cheaper in bits. It runs both training and inference of a 5B long-video diffusion model entirely in NVIDIA’s NVFP4 4-bit format, with a sequence-parallel scheme (Balanced SP) that pairs clean and noisy latent chunks per GPU so training long clips stops running out of memory. The claim is not “4-bit inference is fine” (that is established) but that the whole pipeline, training included, survives 4-bit with almost no quality loss.
MinT makes the set of models you serve cheaper in parameters. It keeps one frontier base model resident in GPU memory and treats every fine-tuned variant as a swappable LoRA adapter, often under 1% of base size in rank-1 settings. The expensive “load a new model” step becomes an “attach an adapter” step. MinT is built for catalogs of roughly a million adapters on shared bases past 1 trillion parameters.
One shrinks the weights everyone shares; the other shrinks the differences between them.
Key numbers
| Measurement | LongLive-2.0 (NVFP4 4-bit) | MinT (shared-base LoRA) | Same harness? |
|---|---|---|---|
| What is saved | Memory and time on one model | Switching and storage cost across many models | Different units |
| Headline speed | 2.1x faster training, 1.84x faster inference vs BF16 | 18.3x faster handoff (4B dense), 2.85x (30B MoE) | Each vs its own baseline |
| 64s generation, GB200 | 36.3 GB / 19.4s (2-step NVFP4) vs 112.9 GB / 36.4s (BF16) | n/a (serving infra, not generation) | n/a |
| Throughput | 45.7 FPS at 1280x720 (2-step); 29.7 FPS (4-step) vs 24.8 BF16 | Adapter handoff, not throughput | n/a |
| Quality cost | VBench total 85.06 BF16 → 84.51 (4-step) → 83.14 (2-step) | Not measured (infrastructure paper) | LongLive internal |
| Training iteration, 64s clip | 1196.5s → 639.5s with Balanced SP + NVFP4; BF16 without SP OOM | Concurrent GRPO 1.77x (dense) / 1.45x (MoE) wall-clock | Each internal |
| Secondary tricks | ~3.6x KV-cache compression, under 2% overhead; streaming VAE | Packed MoE LoRA loads 8.5-8.7x faster than unpacked | Each internal |
| Enabling assumption | Blackwell GPUs with 4-bit Tensor Cores | All tenants share one base model | n/a |
| Fallback | Sequence-parallel inference on A100/H100, no 4-bit speedup | Full model reload, i.e. the baseline | n/a |
Read the table for what it does not contain: no shared benchmark, no shared task, no shared hardware. The two systems are not competitors, and any page that ranks them against each other is inventing a comparison. What is comparable is the shape of the savings and the shape of the assumptions.
What each system is really doing
LongLive-2.0’s hard problem is error accumulation. Long-video diffusion is autoregressive over chunks: each new chunk conditions on the model’s own earlier output, so a small 4-bit rounding error compounds across a 60-second clip into drift, flicker, and identity loss. The paper’s stack exists to stop that compounding: Balanced SP to even out per-rank work, NVFP4’s hierarchical scaling (FP4 values, FP8 block scales, FP32 tensor scales), distillation tuned directly in 4-bit, plus W4A4 inference with reshaped KV-cache quantization and an asynchronous streaming VAE. The measured reward: on VBench-Long 60-second clips, subject consistency actually holds at 97.62% in NVFP4 versus 97.48% in BF16.
MinT’s hard problem is bookkeeping. If a million tenants each need “a model,” and all of them are the same base plus a small LoRA delta, then the serving problem is not inference but management: how fast you can switch the active adapter, how you pack MoE expert adapters so loading them is not a tensor-by-tensor crawl (8.5-8.7x faster packed), and how you run GRPO updates across a wave of adapters concurrently instead of serially (1.77x dense, 1.45x MoE). The dense-versus-MoE gap in both rows is the honest signal: the bigger the base cost being amortized, the bigger the win, and MoE routing eats into it.
When to use which
- You serve one big model to many users and pay for memory per inference: LongLive-2.0’s lever. If you are on Blackwell, a 3x memory cut with a half-point quality change is a straightforward trade, and the training-side 2.1x compounds it.
- You serve many fine-tuned variants of one base and pay for switching and storage: MinT’s lever. 18.3x handoff on dense models is the difference between “one model per request batch” and “one adapter per request.”
- You run MoE at scale: read MinT’s MoE numbers (2.85x, 1.45x), not its dense headline, and size expectations accordingly.
- You need the fastest LongLive-2.0 mode: know that 45.7 FPS is the 2-step setting, where VBench total drops to 83.14 and the semantic sub-score falls from 78.63 to 74.12. The headline FPS and the headline quality are not the same configuration.
- You are not on Blackwell: LongLive-2.0 gives you the engineering but not the 4-bit acceleration; MinT’s wins are hardware-agnostic in principle since they come from avoiding reloads.
Failure modes and fine print
LongLive-2.0’s caveats are hardware lock-in and the quality-FPS split described above; its win is throughput and memory, not new capability. MinT’s caveat is conditional applicability: if two use cases genuinely need different base weights, the core trick does not apply, and the paper measures nothing about whether a rank-1 adapter is good enough for a task. Both are systems papers, so both measure their own economics, not end quality. MinT explicitly does not evaluate adapter quality, and LongLive-2.0’s VBench deltas are its own model family under its own settings.
Limits and open questions
Neither paper ablates the combination. A stack that is both 4-bit and adapter-shared (NVFP4 weights with per-tenant LoRA deltas) is the obvious next system, and neither paper tells you whether 4-bit rounding interacts badly with small adapter updates. LongLive-2.0’s numbers are locked to GB200-class hardware, so the 1.84x/2.1x figures are not portable downward. MinT’s million-adapter, trillion-parameter figures are capacity claims the system is built to address, validated against, not a guarantee that every workload hits the best-case speedup.
FAQ
Which saves more money, 4-bit training or LoRA serving?
They save different line items. LongLive-2.0 cuts per-inference memory about 3x (112.9 GB to 36.3 GB for a 64-second clip) and training time 2.1x for one model. MinT cuts model-to-model switching 18.3x on a 4B dense LLM. If your bill is one big model on expensive GPUs, quantization is the lever; if your bill is many variants of one base, adapter sharing is.
Does NVFP4 4-bit training hurt quality?
In LongLive-2.0’s measurements, barely at 4 steps: VBench total goes from 85.06 (BF16) to 84.51 (NVFP4 4-step), and subject consistency on 60-second clips holds at 97.62% versus 97.48%. The faster 2-step mode costs more, dropping VBench total to 83.14 with the semantic sub-score falling from 78.63 to 74.12.
What hardware does LongLive-2.0 require?
NVFP4 acceleration needs NVIDIA Blackwell-class GPUs with native 4-bit Tensor Cores, such as GB200. On A100 or H100 there is no NVFP4 path; the authors fall back to sequence-parallel inference, which saves memory but not via 4-bit matmuls.
Is MinT training a million separate models?
No. It addresses roughly 10^6-scale catalogs of LoRA adapters over a shared base, where each adapter can be under 1% of base-model size in rank-1 configurations. The speedup is conditional on tenants sharing base weights; genuinely different bases break the trick.
Why is MinT’s MoE speedup smaller than its dense speedup?
Because the win comes from removing the base-model reload, and the larger the per-switch base cost relative to adapter movement, the bigger the saving. A 30B MoE carries more fixed switching overhead than a 4B dense, so handoff speedup is 2.85x instead of 18.3x, and concurrent training gains shrink from 1.77x to 1.45x. Same pattern in both rows.