How open models actually learn new abilities in 2026 — Part 2: the recipes and the GPUs behind them

Part 1 built a lens. This part uses it, but here is the one-paragraph recap so this post stands on its own.

Through 2025, the common way to make one model good at many things was a single giant multi-domain RL run, with every capability entangled in one job. Over 2025–2026 a growing share of the frontier open labs leaned into a two-phase structure instead: build each capability as an independent RLVR specialist, then fuse the specialists into one student with on-policy distillation — a step where the student samples its own answers and same-origin teacher models grade every token with a mode-seeking reverse-KL signal. It is one trend among several — joint multi-domain RL is still common, and weight merging has not gone away — but it is the one gaining ground fastest for fusing separately-trained specialists. Because that fusion step is dense, on-policy, and cheap, the production of abilities and their integration come apart. Capabilities become microservices: produced in parallel, integrated at the end. RLVR did not go away; it stopped being the integrator and became the specialist factory. (Part 1 has the mechanism and the math.)

That framing predicts what you should see inside real pipelines: a factory of parallel RLVR jobs, then a distillation pass with a fleet of teachers. That is exactly what the 2026 reports describe, with instructive variations from one lab to the next.

The recipe on one grid

Before the lab-by-lab detail, here is the whole field on one grid. The recipe is consistent; the choices within it are where the labs differ. (Where each lab puts the distillation step is its own axis, shown in Fig 2 just below, so it is not repeated here.)

Table 1 — Same recipe, different dials, from each lab's primary report (see references). LongCat-2.0 has only a vendor blog (no arXiv), so its loss, serving, and reward are undisclosed; Qwen3 is included as the compression contrast, not a fusion recipe.

Lab / model	Loss form	Teacher serving	Reward	Same-origin
DeepSeek V4	full-vocab reverse KL	offload + hidden-state cache	actor-as-GRM	one student
Xiaomi MiMo-V2-Flash	policy-gradient, top-k	prefill scoring service	RLVR verifiers	same SFT checkpoint
Zhipu GLM-5	on-policy, gap-to-teacher	slime (Megatron + SGLang)	RLVR	own prior checkpoints
Kwai Keye-VL-2.0	token-level, routed	routing, 13 teachers	RL teachers	shared MoE backbone
Meituan LongCat-2.0	undisclosed	undisclosed	undisclosed	1 checkpoint → 3 groups
Alibaba Qwen3	logit KL (off→on)	none	flagship full RL	big → small

Now the mechanics, lab by lab.

DeepSeek-V4: the archetype, and an infrastructure master-class

DeepSeek-V4 (arXiv 2606.19348) is the clearest single data point for the shift, because it is a lab abandoning a method it had shipped. The report states it plainly: the pipeline "largely mirrored that of DeepSeek-V3.2," but "a critical methodological substitution was made: the mixed Reinforcement Learning (RL) stage was entirely replaced by On-Policy Distillation (OPD)." OPD is now "the primary technique for merging expert capabilities," explicitly "circumventing the performance degradation often encountered in traditional weight-merging or mixed RL techniques": the see-saw and instability from Part 1, named and designed around.

DeepSeek chose the most faithful and most expensive loss form (full-vocabulary reverse KL) and integrates, in the report's words, "more than ten teacher models covering various domains." The objective is a weighted sum of per-teacher KLs:

The interesting part is how they make exact full-vocabulary distillation affordable at scale, because this is where the "teacher as a service" idea from Part 1 becomes concrete engineering. Three moves:

• Offload and load on demand. "All teacher weights are offloaded to a centralized distributed storage and are loaded on demand," with ZeRO-like sharding. You do not hold ten-plus trillion-parameter-class teachers resident.
• Order samples by teacher. "We order training samples by teacher index during data dispatching. This arrangement ensures that each distinct teacher head is loaded only once per mini-batch and that at most one teacher head resides in device memory at any given time." One teacher hot at a time, loading hidden behind compute.
• Cache hidden states, reconstruct logits. Materializing a full vocabulary of logits is the bottleneck: "naively materializing logits for a vocabulary size |V|>100k across all teachers is prohibitive, even when spooled to disk." Their fix is elegant: cache only "the last-layer teacher hidden states," then at training time pass them "through the corresponding prediction head module to reconstruct the full logits on the fly," and compute the exact KL with a "specialized TileLang kernel." You store a compact hidden state and regenerate the big distribution only when you need it.

DeepSeek also folds away the reward model entirely. Rather than train a separate scalar scorer, "the actor network natively functions as the GRM" (generative reward model): the policy grades itself during GRPO, jointly optimizing its evaluative, reward-modeling proficiency "alongside its standard generative capabilities." DeepSeek-V4-Pro is a 1.6T-total / 49B-active MoE (a smaller Flash variant is 284B/13B), trained with FP4 (MXFP4) quantization on the expert weights, a detail that matters for the GPU section below.

Read together, DeepSeek's post-training reads like the org chart of a lab that let each group build its specialist and stitched them together at the end: the microservices thesis, in silicon.

Xiaomi MiMo-V2-Flash: the formalism's home

If DeepSeek is the showcase, Xiaomi's MiMo-V2-Flash (model report arXiv 2601.02780; the method paper is MOPD, arXiv 2606.30406) is where the recipe is written down precisely. MiMo-V2-Flash is a 309B-total / 15B-active MoE with a hybrid attention scheme ("Sliding Window Attention (SWA) with global attention, with a 128-token sliding window under a 5:1 hybrid ratio") pre-trained on 27T tokens.

Its post-training is a three-stage framework, and the sequencing matters: SFT, then domain-specialized RL that produces the teachers, then MOPD as the final consolidation stage. As the report puts it: "Having established the foundation through SFT and trained specialized teachers through domain-specific RL, we now formalize the multi-teacher on-policy distillation mechanism." The large-scale agentic RL is part of building the specialists; the distillation is what fuses them at the end, not a middle step with more RL after it. This is the MOPD paper's exact contribution from Part 1: casting distillation as RL so it drops into a GRPO loop, proving the same-origin requirement, and defaulting to the light policy-gradient loss form. (MiMo also uses IcePop — Ant's masked, two-sided importance-ratio clipping from Part 1 — to handle the training–inference mismatch in MoE RL, as Zhipu does below.)

The MOPD paper's default is deliberately the cheap loss form, which is what lets it scale. Rather than materialize the teacher's full distribution, it casts the reverse KL as a policy gradient: each token's advantage is the stop-gradient log-probability gap to the teacher, and the update is an ordinary REINFORCE step over the student's own tokens, evaluated on just the top-k (k = 64) teacher tokens.

This is the exact sense in which distillation "drops directly into existing PPO/GRPO": the only change from ordinary RLVR is replacing the sparse verifier reward with this dense per-token gap. It is the same objective DeepSeek optimizes, only estimated cheaply on the top-k tokens instead of exactly over the full vocabulary.

Zhipu GLM-5: same idea, most open stack

Zhipu's GLM-5 (arXiv 2602.15763) is the most useful entry for a practitioner, because its infrastructure is open. GLM-5 performs "on-policy cross-stage distillation as the final stage," using it to "swiftly recover the skills acquired in earlier SFT and RL stages (Reasoning RL and General RL)," where "the final checkpoints from the preceding training stages serve as teacher models." Note the nuance: GLM-5 fuses its own earlier stages, the model distilling from past versions of itself, which is the purest form of same-origin: the teacher and student are literally the same lineage. The advantage, as in MOPD's policy-gradient form, is "computed directly from the gap with the teacher models."

What makes GLM-5 distinct is not the loss but the teacher. Where DeepSeek and MiMo distill from separately-trained domain specialists, GLM-5's teachers are its own earlier checkpoints, so the teacher policy is simply a prior stage of the student itself:

That is same-origin taken to its limit — teacher and student share not just an initialization but an entire lineage — and it is why GLM-5 frames the step as recovering skills its earlier stages already had, rather than importing new ones from outside.

Two named pieces carry into the rest of the series. IcePop (Ant's Ring-1T correction, defined in Part 1) is what GLM-5 uses "to mitigate the training-inference mismatch, i.e., the discrepancy between the inference distribution and the training distribution during RL optimization"; GLM-5 adopts it with the KL-regularization term removed, the same correction MiMo uses. And GLM-5 runs on slime: "We continue to use slime as the unified post-training infrastructure for GLM-5." slime (open-source, from Zhipu) is the concrete stack (Megatron for training, SGLang for rollout) that Part 2's infra section builds on. Zhipu describes GLM-4.5 as having used "iterative self-distillation" before this; the later GLM-5.1 and GLM-5.2 point releases (which company posts describe as consolidating specialists on slime in roughly two days) have no dedicated technical report, so treat those specifics as vendor-reported.

Kwai Keye-VL-2.0: the recipe crosses into vision

Kuaishou's Keye-VL-2.0 (arXiv 2606.10651) shows the recipe is not text-only. It is a 30B-total / 3B-active multimodal MoE, and it applies multi-teacher on-policy distillation across modalities. The paper is explicit about the count that earlier coverage left fuzzy: "MOPD maintains 13 RL-trained domain teachers," spanning "safety, pure-text math, instruction following, code, visual STEM, OCR, grounding, counting, video, and tool use, among others." Each student sample is routed to the best-matching teacher, which supplies token-level feedback that is merged back into the shared MoE backbone.

Its signature, then, is a routing step in front of the KL. With 13 domain teachers spanning text and vision, each student sample is first routed to the teacher that owns its domain, and only then does the usual per-token reverse KL apply against that one teacher:

The routing is what stops a video-understanding teacher from overwriting the math teacher's signal: each sample only ever learns from the teacher that owns it, so thirteen specialists fuse into one backbone without trampling each other.

The motivation is a problem Keye names the "Multimodal Alignment Dilemma": "directly injecting complex video understanding and tool-use capabilities often triggers catastrophic forgetting, degrading the model's foundational STEM, mathematical, and linguistic reasoning abilities." That is the see-saw of Part 1, in multimodal form, and the same answer applies: build the modality and task specialists separately, fuse them with on-policy distillation rather than one entangled run.

Meituan LongCat-2.0: single unified student (vendor-reported)

Meituan's LongCat-2.0 is a large MoE trained on domestic accelerators. It has no arXiv report, so everything here is vendor-reported from Meituan's official tech blog and model card, and should be read with that caveat. Meituan describes branching a shared SFT checkpoint into Agent, Reasoning, and Interaction expert groups and distilling them into one unified model. Worth flagging a common misreading: LongCat's "gating network routes tasks to experts" language describes the fused model's internal sparse-MoE routing, not a top-level router picking between separate models. It is a single student, like the others. Loss form and teacher count are not independently documented, and as of this writing the weights are listed as pending release. It fits the pattern; it just cannot be verified to the same standard as the others.

The four recipes, one objective

Strip the reports down to their gradients and the four on-policy-distillation recipes are dials on a single objective. Every one of them minimizes the same per-token reverse KL between the student and a teacher, measured over the student's own rollouts:

Three choices inside that expression are where the labs actually differ.

Dial 1 — how the divergence is computed: exact vs. cheap. DeepSeek-V4 pays for the exact thing: a full-vocabulary reverse KL summed over all |V| > 100k tokens and weighted across ten-plus teachers (the weighted-KL objective in its section above), made affordable by a TileLang kernel and hidden-state caching. Xiaomi's MoPD default is the cheap estimator: the same reverse KL as a top-k policy gradient. It is one objective seen from opposite ends of a cost/fidelity trade — DeepSeek buys fidelity, MiMo buys scale.

Dial 2 — who the teacher is: external vs. self. For DeepSeek, MiMo, and Kwai the teacher is a set of separately-trained domain specialists. GLM-5's teachers are its own prior-stage checkpoints (self-distillation). Kwai keeps external teachers but adds a router, selecting one of thirteen per sample. Same objective, three different definitions of π_T.

Dial 3 — whether a train-inference correction is bolted on. Because the student samples under an inference engine (SGLang) but the gradient is taken under the training engine (Megatron), the two distributions disagree slightly, and in a sparse MoE that gap is enough to destabilize training. MiMo and GLM-5 both add IcePop (Ant's masked, two-sided importance-ratio clipping from Part 1): it reweights each token by the train-vs-inference probability ratio and drops the badly-mismatched ones, so a few outlier tokens cannot blow up the update:

DeepSeek's exact full-vocabulary KL sidesteps the worst of this by not depending on sampled top-k tokens in the first place; Meituan's LongCat-2.0 sits outside the table entirely, with no public loss form. So the grid earlier reduces to this: one reverse-KL objective, and three independent choices (exact-or-cheap divergence, external-or-self teachers, correct-the-gap-or-not) that each lab makes its own way.

That external-or-self choice is the one to pause on, because it splits the whole story into two uses of a single tool. When the teachers are separate, parallel specialists — DeepSeek, Xiaomi, Kwai — on-policy distillation is doing fusion, and that is the "capabilities as microservices" picture from Part 1: build abilities independently, integrate them cheaply at the end. When the teachers are the model's own earlier checkpoints — GLM-5, and NVIDIA's Nemotron-Cascade 2 below — it is doing self-recovery: a later stage distills from an earlier one to restore skills that further training eroded. Same objective, same stability rules, two jobs. The real through-line is not "parallel microservices" but a cheap, stable, on-policy consolidation step that works equally well for fusing specialists and for a model repairing itself.

One caution: not every "distillation" is this one

Before we trace where this came from, a quick disambiguation, because you will see the word "distillation" attached to models doing something entirely different from what this post describes. Alibaba's Qwen3 (arXiv 2505.09388) is the clearest example. Its "distillation" is strong-to-weak compression, not same-scale fusion: "For smaller models, we use strong-to-weak distillation, leveraging both off-policy and on-policy knowledge transfer from larger models," by "directly distilling the output logits from teacher models into lightweight student models." The flagship Qwen3 models are trained with full RL; only the smaller ones are produced by distilling down from a big teacher, reportedly at about a tenth of the GPU-hours full RL would cost. That is transferring capability from one large teacher into a small student, the opposite direction from fusing many same-scale specialists into one. Same word, genuinely different mechanism, and a trap when reading these reports side by side.

How we got here: specialists were already being fused in 2025 — often by merging weights

If the recipe looks like it appeared fully formed in 2026, it did not. Through 2025 several labs were already building capabilities separately and combining them at the end; some just used a different integrator. The clearest example is the direct predecessor to the LongCat-2.0 above.

Meituan's LongCat-Flash-Thinking (arXiv 2509.18883, September 2025) met the mix-RL problem from Part 1 head-on. It measured that different domains produce wildly different outputs and drew the obvious conclusion: don't mix them. It ran domain-parallel RL, training separate STEM, coding, and agentic experts each with its own settings, then fused the three into one model by merging their weights (a task-vector recipe: normalize each expert's change from the shared starting point, drop the redundant parts, erase the conflicting ones), and finished with a short general-RL pass to smooth the seams. The fused model matched or beat every single specialist on nearly every benchmark (Fig 3). That is exactly Part 1's thesis, produce specialists in parallel and integrate at the end, shipped a year early.

It was not alone. ByteDance's UI-TARS-2 (arXiv 2509.02544) fused independently-trained agent models by linearly interpolating their weights, literally a weighted average of specialists:

And Tencent's Hunyuan-MT (arXiv 2509.05209) trained a small model, by RL, to aggregate several candidate answers into one better answer: fusion learned rather than merged. Different mechanisms, one shared move: build the parts separately, combine them at the finish.

So what is changing? Not that one method replaced another, but where the center of gravity is moving. Fusing RL-trained specialists is really a three-way contest: average their weights (parameter merge), pool everything in one joint run (mix-RL), or distill the specialists into a student (on-policy distillation). The 2025 recipes above sit at the merge corner, and merging is exactly the option Part 1 flagged as unstable for RL specialists. The MOPD paper puts a number on it: on the same integration task, merging scores 0.857 while distilling scores 0.937. That is why distillation is the corner gaining ground for this particular job: it learns the fused behavior from the student's own rollouts instead of hoping an average of weights lands somewhere good. The other corners have not vanished. Weight merging is alive and well, it just moved to a different layer (optimization-time checkpoint averaging, MoE composition), and mix-RL is still common at the frontier (OLMo 3, INTELLECT-3, Nemotron 3). The 2026 story is not "merge is dead," it is "for fusing separately-RL'd specialists, on-policy distillation is the rising answer."

LongCat-Flash-Thinking also sharpened something that changes how you read every "RLVR" claim: what counts as a verified answer. A plain rule-based checker (does the output string match the reference?) agreed with the ground truth only 80.9% of the time, because correct answers written in an unusual form slip past it. A generative reward model that reasons about whether two answers are equivalent reached 98.8%.

Table 2 — "Verifiable" is getting smarter. Source: LongCat-Flash-Thinking (Meituan, arXiv 2509.18883).

Reward checker	Agreement with ground truth
Rule-based (string / exec match)	80.9%
Non-reasoning generative RM	94.0%
Reasoning generative RM	98.8%

So when a 2026 report calls a domain "verifiable," it increasingly means a reasoning grader, not a regex, which is also why DeepSeek-V4 folds the reward model into the policy itself. By late 2025 this whole shape (independent specialists, then a fusion step, backed by smarter verifiers) was showing up across a wide range of open models: Ant's trillion-parameter Ring-1T and Ling-1T, Zhipu's GLM-4.5V, Xiaomi's MiMo-VL, Shanghai AI Lab's Intern-S1, Baichuan-M2, StepFun's provers. One honest caveat: the labs do not agree on when to mix versus separate. GLM-4.5V finds that mixing several domains in one RL run actually helps some abilities through cross-domain transfer; Ring-lite and LongCat find the opposite for domains that conflict. The right amount of separation is task-dependent. What they agree on is that a cheap, stable fusion step at the end is what makes "many specialists → one model" practical.

Where this came from: one technique, several labs converging

Precision about lineage matters here, because the interesting story is a shared body of work that several labs arrived at, not a single origin or a contest between them. It helps to separate the two ingredients.

The distillation idea is the older one. Per-token reverse-KL, on-policy distillation was set out in GKD (Agarwal et al.) and MiniLLM (Gu et al.) around 2023–24, and Thinking Machines Lab (October 2025) cleanly reframed and popularized it for the reasoning era. RLVR — the reward style the specialists are trained with — has a more tangled lineage of its own: it names a reward source, not an algorithm; the technique appeared first in DeepSeek's DeepSeekMath (GRPO, early 2024), the term was coined by the Allen Institute's Tülu 3 (arXiv 2411.15124, which used PPO), and it was popularized at scale by DeepSeek-R1. Neither ingredient traces to a single group.

What is distinctive about 2026 is not who invented the pieces but who first put them together in flagship pipelines, and most uniformly: DeepSeek, Xiaomi, Zhipu, Kuaishou, and Meituan all pushed on-policy distillation into production within two quarters. That cluster of near-simultaneous adoption is what makes the pattern legible when you read the reports side by side.

And the same technique is now turning up beyond that first cluster — the real sign it is becoming a standard rather than one group's trick. The clearest example is NVIDIA's Nemotron-Cascade 2 (arXiv 2603.19220), a 30B-total / 3B-active MoE that reached Gold-medal territory at IMO, IOI, and ICPC 2025 — the second open-weight model to do so, after DeepSeek's 671B, at roughly 20× fewer parameters. It uses multi-domain on-policy distillation, but in a different role. Rather than making OPD the final integrator, it runs a sequential Cascade RL and uses OPD inside it as a regression-prevention device: "multi-domain on-policy distillation from the strongest intermediate teacher models for each domain throughout the Cascade RL process," to "efficiently recover benchmark regressions" as later stages erode earlier abilities. One honest nuance sets it apart: its "teachers" are not separately-trained domain specialists but the model's own intermediate checkpoints along the cascade, so this is closer to self-distillation than to fusing distinct experts. Even so, reading the body (not just the abstract), it lands on the same two design choices the production labs did: same-origin teachers ("derived from the same SFT initialization," sharing "the same tokenizer and vocabulary," "without introducing external model families") and a token-level policy-gradient loss with a truncated importance weight. And it cites the same on-policy-distillation literature, so this is convergence within a shared body of work, not parallel discovery in a vacuum.

Nemotron-Cascade 2 even argues for sequential Cascade RL on infrastructure grounds ("response lengths and verification wall-clock times are more uniform within a domain than across multiple domains trained jointly") — the mirror image of the other labs' flight from mix-RL's interference. Different motivation, converging technique. And the academic literature is already generalizing the recipe: Uni-OPD (arXiv 2605.03677, Zhejiang University / Tencent) proposes "a unified OPD framework that generalizes across LLMs and MLLMs," built around a dual-perspective optimization strategy that spans both single-teacher and multi-teacher settings — the usual sign a production technique is about to become a standard one.

So the honest read is convergence, not competition. The method has research roots (GKD, MiniLLM, later Thinking Machines Lab); it was productionized as the integration mechanism first and most uniformly by the cluster of labs above; and it is now spreading — NVIDIA on the engineering side, Uni-OPD on the academic side — even as plenty of other frontier models still integrate a different way (OLMo 3, Nemotron 3, and INTELLECT-3 lean on simultaneous mix-RL; Cohere's Command A on parameter merging; Meta's Llama line on DPO).

What this means for your GPU cluster

Here is the part most write-ups skip: this recipe has a specific compute shape, and it maps cleanly onto how you should provision GPUs. Post-training in this style is not one job. It is three distinct engines, and the move to on-policy distillation makes the split sharper, not softer.

1. Training engine: the gradient updates (Megatron / FSDP, optimizer states). Memory-heavy, wants fast interconnect for a big MoE. BF16 or FP8; DeepSeek-V4 goes further with FP4+FP8 mixed precision, QAT-training the MoE expert weights and the sparse-attention indexer in FP4 (MXFP4, a vendor-neutral format) while keeping attention, norms, and the router in FP8.
2. Rollout / inference engine: generation, both for the RLVR phase and for the student's on-policy samples (SGLang or vLLM). Prefilling a prompt is compute-bound, but because reasoning rollouts generate long, the decode dominates and the engine is net bandwidth-bound. On a MoE that means expert-weight bandwidth and expert dispatch, since even a few-active model has to keep all experts resident in HBM. Usually FP8.
3. Teacher-scoring engine: new with OPD. The teachers prefill over the student's tokens and return log-probabilities or logits. Forward-only, no decode, structurally a reward/verifier service. Once the teachers' combined size outgrows your HBM, which with a couple of large teachers happens fast, you stop holding them resident and offload, loading on demand. And because OPD is on-policy, you cannot precompute the teachers' outputs the way offline distillation can: the student's samples change every step, so the teachers must score fresh rollouts live each time.

The open reference stack makes this concrete. Zhipu's slime (the framework GLM-5 is built on) is Megatron for training plus SGLang for rollout with a data buffer between them, and it exposes exactly the two modes that matter: colocated-synchronous (train and rollout share GPUs; simpler; fine for reasoning-only runs) and disaggregated-asynchronous (separate GPU pools; higher utilization; the mode you want once agentic rollouts and a teacher-scoring service enter the picture). This is the same prefill/decode disaggregation that serving systems already use, pushed into training: keep the compute-bound forward work (teacher scoring, prefill) on one pool and the bandwidth-bound decode work (rollout) on another, so neither starves the other. Meituan's LongCat team reports exactly this payoff. Their disaggregated asynchronous RL system (they call it DORA) runs more than 3× faster than a synchronous setup, because it stops the fast, bursty rollout work from waiting on the heavy training step.

Why the three engines are bound by different things. It reduces to one principle. Whether a kernel is compute-bound or memory-bound is set by its arithmetic intensity — FLOPs done per byte moved — against the hardware's ridge point (peak FLOP/s ÷ peak bytes/s, a few hundred FLOP/byte on an H200). And what sets the intensity is not the model but M, the number of tokens you push through a weight after loading it once: load the matrix, run M tokens through it, and you have reused it M times. Small M means you keep re-reading weights (memory-bound); large M means the reads amortize (compute-bound). That single number splits the three engines — here is the map before the details:

Table 3 — The three engines, one roofline. Small M pins decode to memory bandwidth; large M makes scoring compute-bound (until teachers overflow HBM); training's sharding collectives make it interconnect-bound.

Engine	M	Bound by	In one line	Key fixes
Rollout / decode	small	HBM bandwidth	reads all weights + the full KV for each single token	MLA/GQA, paged batching, spec decode
Teacher scoring	large	compute, then I/O	parallel one-pass GEMM; offloads when teachers exceed HBM	hidden-state cache, stream on demand
Training (1T MoE)	large	interconnect	GEMMs are compute-bound, but sharding collectives gate the step	DualPipe / DeepEP overlap

• Rollout / decode — small M, bandwidth-bound. The KV cache is why. Autoregressive decoding emits one token per step, so each step must read the whole set of active weights (on a MoE, the routed experts plus attention) and the entire KV cache out of HBM just to produce that one token: O(one token) of compute against O(weights + KV) of bytes, intensity on the floor. The KV cache tightens the screw in two distinct ways. First, as bytes: it must be re-read every step and it grows with context length, so the longer the context, the more bandwidth-bound decode becomes. Second, as capacity: its size scales with sequence × batch, so once it crowds out weight memory you cannot raise the batch B — and a small B keeps M small, pinning you to the memory-bound side for good. That is why decode optimizations all attack those two points: MLA / GQA shrink the KV itself, paged / continuous batching raise B to amortize the weight reads, and speculative decoding / MTP verify several draft tokens per weight-load to force M up. On a MoE it is worse at small batch, since only a few tokens route to each expert, so per-expert M is tiny — the reason you gather tokens with large expert-parallel groups.
• Teacher scoring — large M, compute-bound. That holds until the teachers stop fitting. Scoring runs teacher forcing: the answer is already known, so every position goes through in one parallel forward pass (M = batch × sequence, a real GEMM), and no KV cache accumulates across steps — that broken symmetry is exactly why scoring is compute-bound where decode is not. What flips it is capacity. In multi-teacher OPD the teachers' combined weights blow past HBM (with trillion-scale teachers, two or three is enough), so DeepSeek-V4 offloads them to distributed storage and streams on demand — and now the binding resource is the storage→GPU load bandwidth and inter-node fabric, a different bottleneck from decode's HBM reads. Full-vocabulary scoring adds the other half: materializing |V| > 100k logits at every position for every teacher is impossible even spooled to disk, so it caches only the last-layer hidden state and rebuilds the logits on the fly through each teacher's prediction head. Capacity-bound, half weight-residency and half logit-tensor explosion.
• Training — large M, but interconnect-bound. Its sharding collectives own the critical path. The GEMMs themselves are compute-bound like prefill, but a 1T model forces sharding across thousands of GPUs, and the collectives that sharding requires are frequent and bandwidth-hungry: tensor-parallel all-reduces every layer, expert-parallel all-to-all twice per MoE layer. Without overlap the GPUs stall waiting on the network with compute to spare — that is what "lives or dies on the network" means literally. So the frontier's real move is to hide the comms, overlapping the expert all-to-all behind computation (DualPipe, DeepEP) to drag the run back toward compute-bound.

How the GPU tiers map. The three engines all draw from the same GPU generation — you are not buying three different chips — but each is bound by a different constraint, and that constraint, not the chip, is what should decide where it runs. (DeepSeek-V4 itself was reportedly trained on domestic Ascend accelerators, so read this as how the pipeline maps onto an NVIDIA fleet, not a parts list for cloning DeepSeek's cluster.)

• Training a 1T-class MoE — interconnect-bound. Wants memory capacity and, above all, interconnect: H200 (141 GB HBM3e) for BF16/FP8, B200 / B300 (Blackwell), and at the top GB200 NVL72 rack-scale. The thing to get right is which traffic goes where: the heavy collectives (tensor-parallel all-reduce, expert-parallel all-to-all) have to stay inside one NVLink domain, while the lighter traffic (data-parallel gradient all-reduce, pipeline-parallel activation hand-offs) is content to scale out across racks over InfiniBand. That is NVL72's real value: not to hold a 1T run (which needs far more than 72 GPUs) but to fit a wide expert-parallel group — EP=64 and up, impossible on an 8-GPU node — inside a single NVLink fabric (which is why a rack-scale domain matters more for MoE than for dense training). Precision caveat: DeepSeek-V4 QAT-trains its expert weights in FP4 (the vendor-neutral MXFP4), and native FP4 compute is Blackwell-only — on a Blackwell fleet that maps to NVFP4, while Hopper (H200) has no native FP4 tensor core and falls back to W4A16, forfeiting the FP4 throughput; read H200 here as capacity for BF16/FP8, not an FP4 compute part.
• Rollout / decode — bandwidth-bound. It lives on HBM bandwidth (B200 / B300, then H200), the same reason inference throughput scales on these parts. The contrast with training is scale-out, not scale-up: a 1T MoE still can't fit its experts on one GPU at decode, so it does shard intra-node over NVLink with TP/EP (DeepEP routes the expert all-to-all over NVLink inside a node and RDMA between nodes). The point is not that NVLink goes unused, but that decode's collective volume is far smaller than training's (small effective batch, no backward), so it never needs a rack-scale NVLink domain and is happy spreading across ordinary nodes over InfiniBand.
• Teacher scoring — capacity-bound. A single teacher-forcing forward pass is compute-bound like prefill, but the constraint flips the moment the teachers' combined residency outgrows HBM — and then the scarce resource is I/O, not FLOPs: the storage→GPU bandwidth to stream teacher weights on demand and the inter-node fabric to move them (the offload-and-hidden-state-cache scheme from the workload section above). It still wants big HBM and fast fabric — again H200 / B200 / B300.

Look at what those three bullets have in common, though: they nearly all point at the same shortlist of GPUs. That is the real signal. The interesting decision is not which GPU but where each engine runs, because the one resource you cannot buy incrementally is the NVLink domain. An NVL72 rack is a fixed 72-GPU unit, so spend it where it is irreplaceable, on the training engine, whose expert-parallel all-to-all has nowhere else to go. Rollout and teacher scoring are the opposite: both are asynchronous and embarrassingly parallel, so they are happy on ordinary H200 / B200 nodes (scoring runs fine even on H100 / H200), which are cheaper and far easier to source than rack-scale NVLink. Putting an NVL72 rack on rollout wastes the one thing NVL72 is for. So the right GPU allocation follows the same disaggregation boundary that slime and SGLang already draw between training and rollout, which is the whole reason the disaggregated-asynchronous mode exists.

You do not need a 50,000-card cluster to do this. That is the quiet good news. LongCat's domestic mega-cluster is the flagship end of the spectrum, but the method is deliberately cheap: on-policy distillation is roughly one-tenth the GPU-hours of RL, and reaches teacher parity in about 6× fewer samples. The smallest useful version of the recipe is: run one or two domain RLVR teachers on a single 8×H100 / 8×H200 node with an open stack (slime, verl, or TRL with SGLang/vLLM), then a one- or two-teacher on-policy-distillation pass into a student on the same node, the teacher as a co-located scoring service to start, disaggregated onto a second node only when you scale the teacher count up. Because OPD is the cheap phase, a well-provisioned single node can reproduce the whole shape of the recipe end-to-end.

That production/integration split is also a provisioning story. Capability production is many independent, burstable, parallel RLVR jobs: each domain team wants its own node on demand, not a standing reservation on a shared monolith. Capability integration is a shorter, heavier distillation pass with a teacher-serving fleet. This is precisely the workload shape a GPU cloud is good at: spin up parallel per-domain jobs across H100 / H200 when a team needs them, reach for B200 / B300 (and GB200 NVL72 for the largest MoEs) for the memory- and bandwidth-heavy integration and serving. On VESSL Cloud you can place each stage on the tier it needs (A100, H100, H200, B200, GB200, and B300 on one platform) spot, on-demand, or reserved, pay-as-you-go, so you stop paying for the teacher fleet between integration passes without tearing down your environment, and reproduce the whole recipe on a single node before you ever need the mega-cluster.

Takeaways

• The 2026 open-model shift is not a new way to train a capability; it is a new way to integrate abilities (RLVR builds independent specialists, on-policy distillation fuses them) and the reports bear it out lab by lab.
• The recipe is consistent but the dials differ: DeepSeek goes full-vocabulary with a teacher-offload/TileLang stack and an actor-as-reward-model; Xiaomi wrote down the formalism (MOPD as the final consolidation stage); Zhipu does it cross-stage on the open slime stack; Kwai carries it into vision with 13 teachers.
• A terminology caution: Qwen3 uses "distillation" for the opposite direction, compressing a big teacher into small models, not fusing same-scale specialists. Don't confuse it with the on-policy distillation in this post.
• It draws on a shared body of work (on-policy distillation from GKD, MiniLLM, and Thinking Machines Lab; RLVR from DeepSeekMath and AI2's Tülu 3), was productionized as the integration mechanism first and most uniformly by DeepSeek, Xiaomi, Zhipu, Kuaishou, and Meituan, and is now spreading — NVIDIA on the engineering side, Uni-OPD on the academic side.
• Operationally it is a three-engine, disaggregated workload (train / rollout / teacher-scoring) that reproduces on a single 8-GPU node and scales onto Blackwell-class memory and bandwidth. Which is the practical reason to care about which GPUs you can actually get.

References (Part 2)

• MOPD: Multi-Teacher On-Policy Distillation for Capability Integration in LLM Post-Training (Xiaomi LLM Core) — arXiv 2606.30406
• DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence — arXiv 2606.19348
• MiMo-V2-Flash Technical Report (Xiaomi) — arXiv 2601.02780
• GLM-5: from Vibe Coding to Agentic Engineering (Zhipu) — arXiv 2602.15763; GLM-5.1/5.2 via Z.ai blog
• Kwai Keye-VL-2.0 Technical Report (Kuaishou) — arXiv 2606.10651
• Qwen3 Technical Report (Alibaba) — arXiv 2505.09388
• Nemotron-Cascade 2: Post-Training LLMs with Cascade RL and Multi-Domain On-Policy Distillation (NVIDIA) — arXiv 2603.19220
• Uni-OPD: Unifying On-Policy Distillation with a Dual-Perspective Recipe (Zhejiang University / Tencent) — arXiv 2605.03677
• Meituan LongCat-2.0 — official tech blog https://longcat.chat/blog/longcat-2.0/ · model card https://huggingface.co/meituan-longcat/LongCat-2.0 · code https://github.com/meituan-longcat/LongCat-2.0
• Open frameworks: THUDM/slime (https://github.com/THUDM/slime), verl, SGLang, vLLM