How Do You Teach a 2.8-Trillion-Parameter Model to Actually Work?

A plain-language walkthrough of Kimi K3’s post-training — structured as the sequence of problems its designers had to solve

Written for engineers who use AI models daily but haven’t worked in reinforcement learning. Assumes basic college math (probabilities, logarithms) and nothing else. All claims are sourced to the Kimi K3 technical report unless marked as interpretation.

How this post was made. This post was drafted by Claude Fable 5, working from the Kimi K3 technical report over an extended conversation in which I asked questions, pushed on unclear points, and set the structure and audience. A separate agent running Claude Opus 5 then reviewed the draft against the report and produced two rounds of editorial notes — factual corrections, attribution fixes, and structural suggestions — which Fable 5 applied and I verified. The interpretations flagged throughout as inference rather than reportage are the models’; the decision to publish, and any errors that survived two AI passes and one human one, are mine.

In July 2026, Moonshot AI released Kimi K3: a 2.8-trillion-parameter open-weights model that trails only Claude Fable 5 and GPT-5.6 Sol on most benchmarks, at a fraction of their cost to run. The architecture (a hybrid attention design with a 1M-token context window) gets most of the press. But arguably the more instructive half of the technical report is post-training: everything that happens after the model has learned to predict text, to turn a text predictor into something that can debug a repository for six hours or run a simulated office for a week.

One architectural fact you do need before we start, because most of this post’s economics live in it: K3 is a mixture-of-experts model. Of its 2.8 trillion parameters, only about 104 billion fire on any given token — 16 of 896 routed experts, chosen per token, plus 2 always-on shared ones (report §2.3). Roughly 3.7% of the network runs at a time. Keep the gap between total and active in mind throughout.

This post walks through K3’s post-training as a chain of design decisions. For each one, we’ll start from the problem and ask: if you had to solve this yourself, what would force you toward their answer? By the end, the design should feel less like a bag of tricks and more like the only shape the solution could take.

One theme will keep recurring, so let’s name it upfront:

When a metric becomes a target, it stops being a good metric. (Goodhart’s law.) A model updated millions of times against any measurement is the most thorough auditor that measurement will ever face. It will find every crack between what you measured and what you meant, with infinite patience and no embarrassment.

Count how many times this forces a design choice below. I count at least six.

Here’s the map of where we’re going:

Part 0: Where K3 came from

K3’s post-training is the fourth iteration of a lineage, and each generation contributed one load-bearing idea:

So when the report says things like “retaining the tournament-style group reward as in Kimi K2.5,” it’s telling you which parts are inherited machinery and which are new. The genuinely new post-training ideas in K3 are the expert-consolidation scheme and the infrastructure to run RL at million-token horizons. Everything else is a refined inheritance.

There’s also a bootstrapping flywheel worth noticing: K3’s supervised fine-tuning data was synthesized by prior Kimi models (“domain-specialized models from the prior Kimi series,” §4.1.1), then verified and human-annotated. Each generation manufactures training data for the next. Keep this in mind when we get to judges and graders — the grading models are likely part of the same flywheel, though the report doesn’t name them.

Part 1: Why reinforcement learning at all?

The starting point. After pre-training (predict the next word over the internet) and supervised fine-tuning (SFT: learn the format of being a helpful assistant from example conversations), you have a generalist: a model that can chat, call tools, and write plausible code. Call it the cold-start model. It is competent everywhere and exceptional nowhere.

The problem. You want it to be exceptional at long, messy, multi-step work: fix a real bug across a codebase, research a question across forty web pages, keep a week-long workflow coherent. Why can’t you just do more SFT — collect examples of experts doing these tasks and train the model to imitate them?

Two reasons force you toward RL:

1. Demonstrations don’t exist at scale. Nobody has millions of recorded expert traces of “six-hour debugging session with every keystroke and every dead end.” And the dead ends matter: an expert trace with the false starts edited out teaches a fantasy version of the work.
2. Imitation teaches moves, not strategy. Copying an expert’s output word-for-word doesn’t teach why the expert profiled before optimizing, or when to abandon a hypothesis. Strategy only reveals itself under consequences.

So the alternative: stop showing the model answers. Instead, let it try, grade the tries, and nudge it toward what scored well. That’s reinforcement learning, stripped of jargon. Concretely, the loop is:

repeat millions of times:
  1. Give the model a task
  2. Let it generate K attempts (say, 8) — thinking, tool calls, everything
  3. Score each attempt
  4. Nudge word-probabilities UP in high-scoring attempts,
     DOWN in low-scoring attempts

(Remember what a language model is: at each step it assigns a probability to every possible next word and samples one. “Training” always just means adjusting those probabilities. RL adjusts them based on scores instead of based on matching a reference text.)

Notice what the loop demands: nothing about how to solve tasks — only the ability to score attempts. Nobody ever tells K3 how to optimize a GPU kernel; they only build a world where fast correct kernels score higher than slow or wrong ones, and run the loop until the strategy is carved in.

Which immediately raises the real question, the one the whole rest of the design flows from:

Where do you get millions of tasks that can be scored automatically?

Part 2: The task factory — ground truth without humans

Try the naive approach first, so you feel why it fails: hire people to write tasks and grade attempts. At K3’s scale (the report mentions 51,219,741 sandboxes across 1,505,678 distinct images created during training and evaluation, a proxy for the sheer scale of practice), human grading is off the table by orders of magnitude. (For calibration on what expert labor buys: the report’s 36-task cybersecurity evaluation suite is estimated at roughly 540 expert-hours for a human to solve, about 15 hours per task. Now imagine paying rates like that across a training curriculum.)

So both task creation and scoring must be automated. Two tricks make this possible, and once you see them, most of §4.2 of the report reads as their systematic application.

Trick 1: Construct tasks backwards

Finding the answer to a hard question is expensive. But starting from a known answer and building a hard question around it is cheap.

K3’s pipeline (§4.2.2): AI agents recursively build a giant knowledge graph. Start from seed topics (CS, biomedicine, physics…); each node spawns an agent that web-searches the concept and adds finer sub-concepts, stopping when concepts are atomic. To make a task: sample related nodes, retrieve real public materials (papers, blog posts, code repos), and have a synthesis agent write a task from them. Picture it concretely: the retrieved article says “Company X was acquired for $47M in 2013,” so the agent records $47M as ground truth and writes a multi-hop question whose answer is $47M (“A physicist who won a national award in the 1970s later founded a company acquired in 2013 — for how much?”). Verification of any future attempt is then a string comparison. (Attribution note: the report describes the retrieval-and-synthesis pipeline but not this answer-first construction; the $47M mechanics are my reconstruction of how automatic verification could work at this scale — interpretation, not the paper.)

Trick 2: Only train on tasks where checking is cheaper than doing

This is the deep asymmetry, the everyday cousin of the P-vs-NP intuition: verifying a factorization takes one multiplication; finding it takes a search. K3’s task domains are chosen so that a program can check what only an expert could produce:

The simulated-office environments deserve a sentence: the fake companies are themselves built by agents that search the web for realistic reference material and assemble a coherent workspace.

Where humans actually are

Not grading examples — auditing the graders and designing the factories. The report places humans at: SFT data verification (“multi-stage verification and human-in-the-loop annotation”), curating web-dev tasks, tuning effort budgets “under human-in-the-loop guidance,” and extending anti-cheating detectors as new exploits appear (more on that soon). Human judgment is spent once at the meta level, then automation runs the assembly line. This is the only division of labor that survives the arithmetic.

(Is the dataset open? No — K3 releases weights and some infrastructure [MoonEP, FlashKDA, the AgentENV sandbox runtime], but the task pools, knowledge graph, and environments stay proprietary. Standard for “open” models; the data factory is the moat.)

One more thing gets randomized: the desk itself

There’s a subtler Goodhart trap hiding in the setup, and §4.2.1 exists to close it. Every agentic attempt runs inside a harness: the scaffolding of tool schemas, system prompts, and context-management conventions that turns a raw model into an agent. Claude Code, Codex, and Kimi Code are all harnesses. Train exclusively inside one harness and the model overfits to that desk: its particular tool-call format, its prompt phrasing, its way of trimming context. Competence at one scaffolding is a proxy for general agentic competence, and under enough optimization pressure the two diverge. The report says so directly: a fixed harness “can cause a model to overfit to a particular tool schema, system prompt, context management mechanism, or interaction protocol.”

So K3 randomizes the harness. Their environment represents a harness as composable modules (tool interfaces, system prompts, context strategies, skills, memories, subagents) and can instantiate Kimi Code, Claude Code, Codex, OpenClaw, Hermes, or entirely new combinations. During RL, different task groups get different configurations, so the model can’t memorize any one desk’s furniture and has to learn the work itself.

One domain resists both tricks

Reports. Analyses. Strategy memos. Explanations. A huge fraction of real usage, and there is no answer key, no test suite, no reference pixels. Two excellent market analyses can share barely a sentence. If you were designing this system, here is where you’d get stuck.

One honesty note before we go there: the clean split I’ve drawn — Part 2 for programmatically checkable tasks, Part 3 for judged ones — is cleaner than the report’s actual design. Web-dev rewards mix “deterministic checks and model judging” (§4.2.7), and assistant-task events are “assessed by deterministic rules or LLM-based evaluators” (§4.2.5). So the judge you’re about to meet isn’t a fallback for the leftovers; it’s a working component inside the “verifiable” domains too. That’s Part 3.

Part 3: Grading the ungradable — the judge, and its three failure modes

The only available grader for “write a good report” is another AI model: a generative reward model, so called because it generates a written judgment instead of running a check. The naive version fails in three instructive ways, and each of K3’s design choices (§4.1.2, “Agentic Generative Reward Model”) patches one failure. Derive them in order.

Failure 1: absolute scores are noise → use head-to-head tournaments

Ask a judge to “rate this report 1–10” and the same report gets a 7 today and 8.5 tomorrow. Comparison is cognitively easier and more stable than absolute measurement. A wine critic answers “which glass is better?” far more reliably than “how many points?”.

And here’s the structural luck: RL never needed absolute scores. The loop generates K sibling attempts at the same task and only needs to know which siblings beat which. So: run a tournament. Pairwise matchups, judge picks a winner, reward ≈ win rate against your own siblings. (Readers who want the literature handle: sibling-group scoring with rewards measured relative to the group is the idea behind the GRPO family of methods.) Bonus: comparing siblings on the same task cancels task difficulty out of the signal. A mediocre attempt at a brutal task and a mediocre attempt at an easy one both land mid-pack among their own siblings, so the reward measures how well you did relative to what was achievable here — exactly the right learning signal. (This tournament machinery is inherited from Kimi K2.5.)

Failure 2: judges rationalize → force the rubric before scoring

Left alone, a judge model reads two reports, forms a gut impression (“B feels thorough”), then writes a justification backwards from the gut call. The reasons are decoration; the decision was vibes. And vibes are gameable.

K3’s fix is procedural, and the ordering is everything. The judge must:

1. Read the actual product (it’s an agentic judge — it has tools, opens files, interacts with what was built);
2. Write the rubric, before scoring anyone: “a strong answer here should cite current data, size the market numerically, address regulation, flag its own uncertainty…”;
3. Score each candidate against that rubric, criterion by criterion;
4. Record scores in a scorepad, so the verdict is computed from the criteria rather than asserted alongside them.

Committing to “what does good mean for this task” while both candidates are unscored kills the backwards-rationalization channel. Any teacher who grades essays rubric-first for exactly this reason will recognize the move.

But wait — can a judge even write a good rubric? Doesn’t it have to be as smart as the thing it grades? Two structural facts rescue the scheme:

• Discrimination is a lower bar than generation. The judge doesn’t need to outperform the best attempt; it only needs to tell better attempts from worse ones. A book critic who couldn’t write the novel still reliably finds its weak chapters. And writing the rubric (“what do market analyses generically need?”) is closer to recalling a professional checklist than doing professional work. The design quietly bets that rubric-writing is an easier task than the task itself. That’s a defensible bet, and the same checking-vs-doing asymmetry from Part 2, one level up.
• Random rubric errors wash out; only systematic errors compound. Rewards aggregate over millions of tasks with tiny nudges each. A bad rubric on one task is noise; uncorrelated mistakes average toward zero, like measurement error in a lab. But a bias that’s consistently wrong in the same direction (always rewarding confident tone, always crediting length) compounds every round, because the student becomes a specialist in exploiting exactly that bias. Design rule that falls out: tolerate noise, hunt down bias.

(Who judges the judge? Nobody in the loop; that’s an infinite regress. The industry-standard answer, which the report doesn’t detail but the field practices: validate the judge offline against human rankings on a sample, like calibrating a lab instrument, then trust it on the population. Biases subtle enough to fool both the judge and the human validators remain an open problem — the research area is called “scalable oversight.” Flagged honestly: interpretation, not the paper.)

Failure 3: the graded seduce the grader → the verbosity cliff

Now the adversarial one, and the first full-dress appearance of Goodhart. The student model doesn’t know it’s “supposed to” write good reports; it knows winning tournaments raises reward. Over thousands of rounds it will discover whatever wins. One thing reliably impresses judge models (and humans): length. More sections, more caveats, more restated points look thorough. If longer wins even slightly more often, training amplifies it relentlessly, round over round, until the model produces 40-page reports of diluted content. The proxy (wins matchups) has parted ways with the target (is actually good).

K3’s fix is deliberately blunt:

• Before training, record each task’s natural answer length ℓ₀ under the cold-start (post-SFT) model — a pre-bloat baseline;
• Pick a tolerance multiplier σ;
• Any attempt longer than σ × ℓ₀ automatically loses its matchup. Not docked points. Loses, before the rubric is consulted, regardless of quality.

Why a cliff instead of a graded penalty? Because the pressure it fights is a gradient. A mere penalty lets training find the profit-maximizing amount of padding and settle there: still bloated, just optimally so. An automatic loss makes the frontier a cliff: no padding beyond σℓ₀ is ever profitable, so the incentive to creep dies entirely. And anchoring ℓ₀ to the frozen cold-start model (not a moving average) prevents the whole population from inflating together and dragging the threshold with it — the anchor’s power is that it never moves.

Keep this cliff in mind; the identical shape appears twice more.

Part 4: One model or nine? The specialist problem

The problem. Different work rewards different temperaments. Deep research rewards exhaustive double-checking; a quick factual answer rewards economy; kernel optimization rewards a profile-restructure-benchmark loop. Training one model against all of it at once risks the reward signals partially fighting each other, so K3 trains specialists — and then has to merge them, because you can only ship one model. (Attribution note on that first step: the interference story is the natural reading, not something the report asserts or ablates. Its own stated motivation leans toward coarse specialization: “Rather than training specialized RL models for individual tasks, we scale RL across three broad domains, each encompassing a wide spectrum of sub-tasks,” §4.1.2. Three wide buckets, not fifty narrow ones; why exactly three is an open question.)

The specialists come from a 3 × 3 grid:

Axis 1: domain. Copy the SFT cold-start model three times (each copy is the full 2.8T network — RL fine-tuning changes weights, not size), and send each copy to a different task pool from Part 2:

• General tasks: knowledge, search, vision, reasoning
• General agents: deep research, long-horizon assistant work, writing
• Coding agents: software engineering, kernels, web dev

Axis 2: effort. Within each domain, run a curriculum using budget control (inherited from K2.5). Every problem gets an estimated natural budget b₀ (measured off the cold-start model). One rule stacks on the normal score: exceed τ × b₀ and your reward is overridden to −1 no matter how good the answer was — the cliff again, aimed this time at rumination: thinking longer rarely hurts success, so naked success-rewards breed endless double-checking. (What counts against the budget differs by domain: thinking tokens for general tasks, but for agentic tasks cumulative output including tool-call arguments — verbose tool calls burn budget too, §4.1.2.) Then:

1. Train with generous τ → freeze a copy: the max-effort expert (thorough, but capped against overthinking);
2. Keep training while shrinking τ → the model is forced to find shorter paths to the same answers → freeze high, then low effort experts.

Crucially, low-effort isn’t “dumber.” It’s a later checkpoint on a learn-to-be-economical curriculum, explicitly optimized to keep the score while spending fewer words.

Result: nine expert models (3 domains × 3 efforts), each a full 2.8T network, each excellent in its niche. Nine times the weights to store, shard, and keep resident in expensive GPU memory. Which forces the next question — the one that names the paper’s headline technique.

Part 5: Merging nine minds into one — MOPD

Multi-Teacher On-Policy Distillation is how nine experts become one shipped model (the “student”). One demarcation before we start, because the word “reward” is about to change meaning. In Parts 2–4, a reward measured an outcome: did the answer match, did the kernel pass, did the tournament rank you high. MOPD’s per-word score is a different object entirely — it measures agreement with a teacher, word by word, with no outcome in sight. The teachers already paid the outcome-based tuition; MOPD transfers their acquired judgment, not the outcomes themselves. Keep the two kinds of “score” separate and everything below is simple. Now, derive the method by eliminating the obvious approach first.

Why not just imitate the teachers?

The obvious merge: have each expert write thousands of example solutions; train the student to copy them word-for-word. This is learning to drive from dashcam videos of an expert — and it has a famous flaw. The expert never drifts into the wrong lane, so the videos contain zero footage of recovering from the wrong lane. The student, being imperfect, will drift — and the moment it does, it’s in a situation the training data never covered, and small errors snowball. In the jargon: this is off-policy learning (a “policy” is just a model’s way of choosing actions; off-policy = learning from data generated by a different chooser than yourself). The drift problem has its own name in the literature — covariate shift — and the classic fix, DAgger, is exactly the shape of what comes next: put the learner in the driver’s seat and query the expert about the learner’s own states.

The fix: the student drives; the teacher grades from the passenger seat

Flip it (on-policy): the student generates its own attempts, and the matching teacher grades every word of them. Feedback lands precisely in the situations the student actually gets into — including its own characteristic mistakes.

The mechanical loop:

1. A task arrives labeled with domain d and effort e. How is the label decided? It isn’t; it’s inherited. The domain was stamped when the task was synthesized (it came off the coding shelf of Part 2’s factory — like a calculus problem being calculus because it’s printed in the calculus textbook). The effort level is simply sampled: dice pick low/high/max, and the choice is written into the student’s prompt as a plain-language instruction (“use high thinking effort”). Same task, different training passes, different effort tags. The (d, e) pair is then a dictionary lookup: fetch that teacher. (Why sample effort randomly instead of matching difficulty? Because the user controls the dial at deployment. Seeing every task type at every effort level is what teaches “obey the instruction” rather than “hard task → think long.”)
2. The student writes a full solution using its own current probabilities.

3. For every word, compare two numbers: the probability the student assigned when it picked the word, and the probability the teacher would have assigned to that same word in that same spot. The per-word score:

   score = clip( log( p_teacher / p_student ), −Rmax, +Rmax )

Walk the formula’s behavior:

Concrete example: the student, fixing a bug, writes “I’ll just wrap the error in a try/except.” The coding teacher — which learned through expensive outcome-based RL that root-cause fixes score better — assigns tiny probability to that continuation: log(0.01/0.40) ≈ −3.7. The student is pushed away from symptom-patching at exactly the words where it went wrong.

Compare the alternative the teachers themselves endured: outcome grading. A 10,000-word coding session gets a single pass/fail at the end (an exam returned marked only “FAIL,” no red ink), and the model must infer which of 10,000 words was the mistake. MOPD puts red ink on every word. The teachers already paid the expensive outcome-based tuition; the student inherits their judgment at a fraction of the cost. That density is why the report calls it a “dense reward signal.”

What’s the clip for? Probabilities get tiny. If the teacher assigns 0.0000001 somewhere, the raw score is ≈ −15, and one freak word would dominate the update for the whole passage, jerking weights violently. Capping at ±Rmax is exam-curving: no single question can tank the grade by 50 points. (Two footnotes for the technically inclined: the report’s Eq. 15 also wraps the ratio in a stop-gradient, meaning the teacher’s side is treated as a fixed grade that gradients don’t flow through — the student learns from the score, the teacher isn’t perturbed by giving it. And they tried fancier objectives — matching the teacher’s full top-k distribution — with no gain in speed or final quality.)

Why not just ship a teacher? There are nine, and none is good at everything. An engineer’s next thought is: fine, route — host all nine and pick one per request. But that’s nine full 2.8T checkpoints to store, shard, and keep resident in GPU memory, for a product whose entire pitch is cost efficiency; the routing idea dies on the memory bill. The student is the only model that gets red ink from all nine, the union of their skills, and it catches each teacher’s judgment applied to its own trajectories, which (per the driving analogy) beats copying any teacher’s frozen habits.

One more arrow in the pipeline that the clean SFT → RL → MOPD story hides: the experts’ trajectories also flow backwards. The report’s §4.1.2 closes with: trajectories produced by the experts at all reasoning levels “are jointly collected for supervised fine-tuning and multi-teacher on-policy distillation.” Expert output becomes SFT data, for this generation and, per the flywheel from Part 0, presumably the next one’s cold start too. The pipeline diagram’s straight line is really a loop.

At deployment the teachers vanish; only habits remain. Effort is whatever the API request says, in the same plain-language format the student saw millions of times. Domain needs no signal at all — the most plausible mechanism (my inference; the report doesn’t spell it out) is that coding-teacher habits fire on coding-looking text simply because that’s the only context where coding red-ink ever arrived during training. One 2.8T model, nine temperaments, one dial.

Part 6: The logistics problem nobody warns you about — partial rollouts

Everything so far assumed the RL loop just runs. At million-token horizons, it doesn’t, and the reason is mundane: waiting.

The straggler problem

RL runs in synchronized rounds on one shared GPU fleet (“co-located” — the report says this keeps each 1M-context RL experiment “within a few hundred GPUs,” §5.3.1; nobody runs separate fleets for a 2.8T model): attempt phase (generate N × K attempts in parallel) → update phase (grade, nudge weights) → repeat with the improved model. The phases must alternate, and the same GPUs do both — so updates can’t start until attempts finish.

Now recall Part 2’s simulated office: one attempt can span thousands of tool calls and millions of words. Attempt lengths aren’t just uneven — they’re heavy-tailed: most attempts finish quickly, but a few marathons run vastly longer than the average, and the longer the horizons you train, the fatter that tail gets. If the rule is “wait for all N × K,” the fleet’s schedule is set by the single slowest attempt: with a heavy tail, the maximum over thousands of attempts dwarfs the average, and the maximum is what you wait for. Picture 4,090 of 4,096 attempts finished and idling while 6 marathons crawl (numbers illustrative; the report gives neither N nor K).

The fix: leave when most of the class is done

Partial rollouts (introduced in Kimi k1.5, extended here): pick λ ∈ (0,1), say 0.9. The moment λ·N·K attempts finish, the attempt phase ends. The stragglers aren’t killed. They’re frozen mid-sentence and resumed first in the next round, alongside fresh attempts. λ is the dial: λ=1 means no staleness but terrible utilization; small λ means great utilization but perpetually old data. (The report doesn’t disclose their λ.)

Freezing is where the engineering lives. An attempt is two things:

• The model’s side: the text so far (trivial) plus a huge working cache the model built while reading its own million-word context; recomputing it on resume would cost nearly as much as the original work. So caches get parked in ordinary CPU memory (the “external KV cache pool,” §5.3.1) and pulled back before resuming. A chess player photographing the board instead of replaying the game.
• The environment’s side: the sandbox, a small virtual machine with files the model edited, programs left running, half-sent emails in mock Gmail. K3’s AgentENV runtime (§5.3.2, open-sourced) snapshots a sandbox in ~133 ms and resumes in ~49 ms, saving only memory dirtied since the last checkpoint. A sandbox waiting for the model to think (~98% of its lifetime) can be paused to consume zero resources, which is how 51 million sandboxes becomes affordable.

The catch freezing creates: staleness

Follow one frozen marathon: its first half was written by model v1; weights update; its middle by v2; another freeze; its end by v3. It finally finishes and gets graded, and the update logic wants to nudge v3 based on choices v1 made. The premise of the nudge (“you chose this word with probability p and it worked, so raise p”) assumed the model being updated is the one that chose. This mismatch is staleness: adjusting your golf swing from video of how you swung two coaching sessions ago. A little is harmless; marathons spanning several rounds create a lot, and it destabilizes training.

On the defense, the report gives exactly one sentence: their algorithm “inherently tolerates such an extreme off-policy regime through a per-token regularization,” by “constraining policy updates within a localized neighborhood.” Here is the shape that fix almost certainly takes, based on standard practice (interpretation from here on): for each word in a stale attempt, compare the current model’s probability for it against the probability it was generated under. Close → apply the nudge fully. Drifted far apart → shrink that word’s nudge toward zero: “this evidence is about a model I no longer am.” Same clip-the-extremes philosophy as MOPD’s Rmax, aimed at a different ratio. The consequence would be elegant: staleness self-manages word by word, with still-valid parts of old attempts teaching at full strength and only the genuinely outdated parts muted.

Without this whole apparatus, a curriculum containing week-long office simulations would hold the datacenter hostage to its slowest simulated Friday. Partial rollouts are what make Part 2’s most ambitious tasks trainable at all.

Part 7: Training for the model you’ll actually ship

The last cluster is easy to skip and shouldn’t be: three decisions about making the model cheap to serve, all pushed upstream into training instead of bolted on after. This is on-brand: K3’s pitch is frontier output at a fraction of frontier price, and the report closes with four score-vs-cost charts (§6.4) — which is where its actual competitive claim lives.

7a. Train in the compressed format (quantization-aware training)

2.8T parameters at standard 16-bit precision ≈ 5.6 terabytes of weights. Unservable. (And remember the sparsity fact: activated compute is already small, so weight memory is the binding constraint — exactly what compression attacks.) So the routed expert weights, which dominate the model’s parameter memory, are stored in a 4-bit format (MXFP4 — small blocks of 4-bit numbers sharing a scale factor), while shared experts, attention, and routers stay at higher precision (§4.1.4). Roughly a 4× memory saving on the dominant component. The usual recipe — train at full precision, compress at the end — loses quality: the model’s tuned numbers get rounded to a coarse grid it never expected. Like rehearsing on a full 88-key piano and performing on a 12-key toy.

K3 instead trains with the 4-bit rounding active from SFT onward, through all the RL above — rehearsing on the toy keyboard from day one, learning to route computation around the coarseness. Bonus, and note the rhyme with staleness: during RL the model generates attempts (inference) then learns from them (training); if inference ran compressed and training ran full-precision, the model doing the attempting would subtly differ from the one being updated. Sharing one format kills the mismatch.

7b. The fast guesser — and grading it on the right thing

A giant model writes slowly, but not for the reason you’d guess. Thanks to sparsity, the arithmetic per word is modest (~104B active parameters). The real cost is hauling weights: for each word, the selected experts’ weights must be streamed from memory into the compute units, and at the small batch sizes of live serving that memory traffic, not math, is the bottleneck (§5.4.2 — the decode kernels are explicitly designed for “memory-bound streaming of weight matrices”). Crucially, the haul is paid per word, and it costs about the same whether you process one word or several.

That “about the same” is the exploit. The standard trick, speculative decoding, pairs the giant with a tiny sidekick that cheaply guesses the next several words; the giant then checks the whole batch of guesses in roughly one weight-streaming pass. Accepted guesses are nearly free speed; the first rejection is where the giant takes over. The output is statistically identical to what the giant would have produced alone — autocomplete where the big model, not you, clicks accept.

The economics reduce to one number: the acceptance rate — the fraction of guesses accepted. K3’s sidekick is a small prediction head the model already carries from pre-training, fine-tuned into the role, fed the giant’s own internal representations from three depths (so it guesses using the giant’s partial thoughts, not from scratch — the EAGLE-3 recipe, arXiv:2503.01840).

The interesting part is the training objective. The conventional recipe says “make the sidekick’s probability distribution resemble the giant’s.” But resemblance is a proxy. A tiny sidekick can’t match the giant everywhere; it must spend limited capacity somewhere — and the resemblance objective spends it evening out similarity across all words, including ones the giant would rarely pick. Acceptance only cares about words that actually get guessed. A sidekick mediocre-everywhere can out-resemble one that’s excellent exactly-where-it-counts, yet get fewer guesses accepted. So K3 writes the target itself as a formula — for each word take min(p_giant, p_sidekick), sum over the vocabulary; that sum literally is the acceptance probability — and trains on that directly (the “LK loss,” arXiv:2602.23881). The proxy isn’t patched. It’s discarded.

7c. A chat format designed so new features are free

Every model has a hidden formatting layer — special markers structuring “user says / model thinks / model calls tool.” K3 rebuilt theirs (XTML, Appendix F) around one economic insight: every feature expressed through new special syntax must be trained in, and at 2.8T scale, training is the most expensive thing you own.

Design rule: new capabilities become plain-language instructions placed in context, not new syntax. The effort dial is the canonical case — “low effort” is literally a natural-language message in the context, not a special token. Same for output-format and tool-choice options. A well-pretrained model already follows written instructions, so new options ship with little or no extra training — the report calls this a “low alignment tax,” and it’s why the nine-expert effort scheme needed no new machinery. Two smaller choices in the same spirit: code in tool calls passes as raw text, not escaped inside JSON strings (no capacity wasted reading code through a haze of backslashes); and in thinking mode, the model’s reasoning from earlier turns stays in the history (kept even when empty), so every thinking-mode conversation has one consistent shape.

What this design costs

Before the victory lap, the bill. Every defense above trades something away, and the report is quieter about this side of the ledger.

The cliffs cut real gradients, not just fake ones. The verbosity rule anchors to the cold-start model’s ℓ₀, which blocks population-wide inflation, and also means the model can never learn that some tasks genuinely deserve longer answers than the SFT model would have given. Everything hangs on σ, which the report doesn’t publish. The τ×b₀ effort cliff has the same edge: overriding reward to −1 regardless of quality will, at some τ, suppress legitimate deep reasoning on genuinely hard problems. Cliffs kill gradient-hacking and gradients you wanted, indiscriminately; the report’s own hedge is visible in the fact that τ is tuned per domain “under human-in-the-loop guidance”: that is, by hand.

MOPD has a ceiling. The student is optimized toward per-word teacher agreement; the teachers were optimized toward outcomes. Those are different targets. Nothing in the scheme lets the student exceed the union of nine teachers’ habits. It inherits judgment; it doesn’t extend it. The transfer is cheap precisely because it forgoes the expensive exploration that made the teachers good.

And a scope note the report leaves implicit: its post-training chapter is capability training end to end. There is no section on safety training, refusal behavior, or harmlessness — the report doesn’t discuss it, and this post hasn’t either. The one adjacent data point is the cyber evaluation (§6.2.2), which cuts both ways: K3 found 16 previously unknown vulnerabilities across six projects (including a remotely triggerable Linux-kernel heap overflow and a Dirty-COW-class permission bug), yet a joint UK AISI / US CAISI assessment found it achieved arbitrary code execution on 0 of 41 end-to-end tasks, well behind frontier cyber-capable models. The report also notes, dryly, that Anthropic and OpenAI frontier models refuse cyber tasks outright and so couldn’t be compared. Read that paragraph next to this post’s closing thesis and the symmetry is hard to miss: a model trained by finding cracks in reward functions, evaluated by how well it finds cracks in real software.

The one lesson, if you keep one

Line up the defenses we’ve met. Six of them share a shape — a learner under optimization pressure exploiting a gap in its own measurement:

A seventh case rhymes without being adversarial — nobody games the sidekick’s resemblance loss; it’s a misspecified objective rather than an exploited one — but the cure is identical: the conventional “resemble the giant” objective diverges from the acceptance rate that actually matters, so K3 writes the acceptance rate down and optimizes it directly.

Seven subsystems; one reflex: ask what you actually want, check whether the number being optimized can silently part ways with it, and either substitute the real thing or wall off the gap. And note the report’s phrasing on kernels — safeguards extended “as new hacking strategies are observed during Kimi K3’s development.” That’s an arms race, told in one clause: the model is a fully automated exploit-finder; the defense is iterative, partly artisanal, observe-and-patch. RL at scale is an adversarial audit of your own metrics, conducted by a colleague with infinite patience and no embarrassment.

Did it work?

Selectively, per the report and third parties (as of July 2026). The wins: K3 tops BrowseComp (91.2% at $2.03/task — half GPT-5.6 Sol’s cost, an order of magnitude under the Claude models at max effort), SWE-Marathon, and several agentic suites; ranks fourth of 580 on Artificial Analysis’s intelligence index — third once GPT-5.6 Sol’s effort variants are collapsed into one entry — behind Claude Fable 5 and GPT-5.6 Sol; and became the first open model to top the WebDev Arena. The losses, which the report itself lists: it trails on research-grade reasoning (HLE-Full, CritPt), places third on the GDPval knowledge-work Elo and fourth on the Agent Arena, and names five of its own internal suites where it trails the leaders (Agent Behavior, MIRA, 24/7 ClawBench, Agentic Vision, KWV). The claim was never “best model”; it was “the cost-efficiency frontier” — and the single cleanest sentence for it is from §6.4: at high effort, K3 already matches Claude Opus 4.8’s maximum-effort coding score at roughly one third the cost. The effort dial isn’t a feature; it’s the product. The post-training design above — cheap automated grading, one model with nine temperaments, a trained dial, 4-bit-native routed experts, a tuned guesser — is that claim’s engine room.

Sources and further reading

Primary:

• Kimi Team, Kimi K3: Open Frontier Intelligence, arXiv:2607.24653 (2026). Post-training: §4; infrastructure: §5; chat template: Appendix F. Weights: huggingface.co/moonshotai/Kimi-K3.

The lineage:

• Kimi k1.5: Scaling Reinforcement Learning with LLMs, arXiv:2501.12599 — partial rollouts.
• Kimi K2: Open Agentic Intelligence, arXiv:2507.20534 — agentic RL at scale, data pipelines.
• Kimi K2.5: Visual Agentic Intelligence, arXiv:2602.02276 — tournament rewards, budget control.

Key techniques cited by the report:

• On-policy distillation: Lu & Thinking Machines Lab, thinkingmachines.ai/blog/on-policy-distillation (2025) — the clearest standalone explanation of the driving-instructor argument.
• Speculative decoding head: EAGLE-3, arXiv:2503.01840; acceptance-rate loss: LK Losses, arXiv:2602.23881.
• Sandbox virtualization: Agache et al., Firecracker (NSDI 2020); AgentENV: github.com/kvcache-ai/AgentENV.

Independent evaluations referenced: Artificial Analysis, Vals AI, LMArena, and the joint UK AISI / US CAISI cyber assessment.

Interpretations flagged as such in the text — the answer-first task construction in Part 2, the judge-calibration practice in Part 3, the interference reading in Part 4, the domain-habit deployment mechanism in Part 5, and the shape of the staleness defense in Part 6 — are the author’s inference from standard practice, not claims of the report.