MoonshotAI

I Asked Kimi K3.1 Pro to Build a 3D Game From One Prompt. It Worked. Here's the Catch --- title: "I Asked Kimi K3.1 Pro to Build a 3D Game From One Prompt. It Worked. Here's the Catch" published: true description: "A real test of Moonshot AI's Kimi K3.1 Pro on the free kimi.ai plan: one prompt produced a 752-line Three.js racing game that runs at 60 fps. Then came the 21-minute wait, a stuck self-test, and a free plan that refused 6 of 6 follow-ups." tags: ai, javascript, threejs, gamedev canonical_url: cover_image: --- AI-assisted disclosure: I used an AI assistant to help structure this write-up. The test runs, timings and logs are my own (kimi.ai free plan, October 28, 2026). Benchmark numbers come from Moonshot's blog and Artificial Analysis, linked at the end. Short version: one prompt to Kimi K3.1 Pro gave me a playable 3D racing game: a single 752-line HTML file using Three.js, 3 laps, 60 fps, zero page errors. But the file took about 21 minutes to arrive, Kimi's own self-test was still stuck after 38 minutes, and the free plan refused my next prompt 6 times in a row. {% youtube iAoYAYFxDQs %} ▶ Full video: youtu.be What is Kimi K3.1 Pro? Kimi K3.1 Pro is the new flagship model from Moonshot AI, the Chinese lab behind Kimi. It launched on October 23, 2026. - Base model: Kimi K3, about 2.8 trillion parameters (mixture of experts) - Context window: 1 million tokens - Open weights: Moonshot says the full weights will be released by November 4, 2026 - API price: $2 input / $10 output per million tokens ($0.20 for cached input). A Highspeed variant costs $4 / $20. Moonshot's headline claim is that it codes almost as well as Claude Opus 5.5. I wanted to see what a normal person gets on the free website. Test 1: one prompt, one 3D game This is the exact prompt I sent on kimi.ai (free plan, Kimi K3.1 Pro): Build a playable 3D racing game in ONE single HTML file using Three.js from a CDN. Low-poly neon city track at night, the car drives with WASD or arrow keys, chase camera, 3 laps with a lap timer and best-lap display, a few obstacles to dodge, and a start screen with "Press Space". No other external assets. Give me the full file. Kimi came back with "Neon Velocity": one index.html, 752 lines, 47 KB, Three.js loaded from a CDN, a night circuit, nitro, a minimap, lap timers and a finish screen. To check it honestly, I didn't just eyeball it. I drove it with a script that sends real key presses in headless Chrome on a Mac mini M4: title screen ready 0.16 s lap 1 done 19.533 s lap 2 done 41.033 s race finished 64.750 s (shown as 1:04.749) best lap 0:19.516 fps avg 60.5, min 60 page errors 0 draw calls / triangles 36 / 25,554 The only console message was a Three.js warning about the old non-module build. For a single prompt, that is a genuinely good result. Test 2: speed This is where it hurt. - The file was written about 21 minutes after I hit send. - Kimi then tried to test the game itself in its own browser. It hit a 404 on its own server, switched ports, and its step "Loads game and captures title screen" was still running at 38:53. I stopped it and took the file from the chat. Artificial Analysis measured the API at about 42.7 tokens per second (No. 184 of 192 models) when I checked, versus about 98 for Claude Opus 5.5. Test 3: the free plan Next I asked for a second round: 3 AI rival cars and a race position display. The free plan refused it 6 out of 6 times, including in a brand-new chat and at a lower effort setting: > "Too many people are chatting with Kimi; a subscription will grant you priority access." So "free" works, but not reliably during busy hours. On the API side it is cheap: Artificial Analysis lists about $3.68 to run its index tasks on Kimi K3.1 Pro versus $10.04 on Opus 5.5. Test 4: is it really Opus-level? | Source | Kimi K3.1 Pro | Claude Opus 5.5 | |---|---|---| | Moonshot (self-reported): Terminal-Bench 4.0 | 65.7% | 66.4% | | Moonshot (self-reported): BenchCAD | 92.7% | 96.2% | | Artificial Analysis: Intelligence Index | 46 (No. 20 of 51) | 58 | On Moonshot's own chart it's less than a point behind. The independent index puts it well behind, in 20th place. Both can be true: it is very strong at the agentic coding tasks Moonshot picked, and less strong across the board. The catch - Slow. 21 minutes for one file, plus a self-test that never finished. - The free plan gets busy. 6 of 6 follow-up prompts refused. - "Opus-level" is Moonshot's claim, not the independent ranking. Verdict If you want the best coding model today, Claude Opus 5.5 is still smarter and more than twice as fast. But one free prompt built a real, playable 3D game, and the API is about a third of the price. If the open weights really land by November 4, anyone with enough GPUs can run a near-frontier model themselves. That's the part I'll be watching. Have you tried Kimi K3.1 Pro for coding yet? I'd like to know if you hit the same free-plan wall. Sources - Moonshot blog: kimi.ai - Kimi API pricing: platform.kimi.ai - Artificial Analysis: artificialanalysis.ai - Moonshot AI on GitHub: github.com/MoonshotAI - Full video: youtu.be

Same model, 15 providers, 84.63% to 100% tool-call accuracy Two rows out of a table Moonshot publishes in their K2 Vendor Verifier repo: | Provider | schema_accuracy | successful / triggered | | --- | --- | --- | | Fireworks | 100.00% | 1703 / 1703 | | Together | 84.63% | 1602 / 1893 | Same weights. Same 4,000-request test set. Same reference to compare against (Moonshot's own endpoint decides what a correct response looks like). The only variable is who served the model. Moonshot built that harness after a run of "K2 is bad at tool calling" reports that turned out to be deployment problems. Their write-up is direct about why: the more open the weights, the more channels they get deployed through, and the less control anyone has over the result. From the outside you can't tell a model defect from an engineering deviation, and if users can't tell, the model gets blamed for both. The two metrics measure different failures tool_call_f1 scores the decision to call a tool at all. It's computed off finish_reason: true positive when the deployment and the reference both return tool_calls, false positive when only the deployment does, false negative when only the reference does. It answers one question. Does this endpoint decide to call tools at the same moments the official API does. schema_accuracy is count_successful_tool_call / count_finish_reason_tool_calls. It only counts responses that already committed to a tool call, then asks how many produced arguments that validate against the JSON schema. The second metric is the one that reaches your error handler. finish_reason says tool_calls, your dispatcher pulls the arguments out, the payload doesn't match the schema, and you get something like this in the middle of a 40-step run: jsonschema.exceptions.ValidationError: 'path' is a required property at tools.read_file(arguments={'file': 'src/api/handlers.ts'}) A retry sometimes papers over it. It costs you a round trip and a chunk of context either way, and in a loop that is already deep into a plan, the retry happens without the model knowing why. The spread, on identical weights Kimi K2 Thinking, 15 deployments, temperature 1.0: | Provider | schema_accuracy | successful / triggered | | --- | --- | --- | | MoonshotAI (official) | 100.00% | 1958 / 1958 | | Fireworks | 100.00% | 1703 / 1703 | | InfiniAI | 99.89% | 1825 / 1827 | | SiliconFlow | 98.96% | 2097 / 2119 | | GMICloud | 95.95% | 1775 / 1850 | | AtlasCloud | 95.74% | 1798 / 1878 | | SGLang | 95.52% | 1790 / 1874 | | vLLM | 87.22% | 1856 / 2128 | | Parasail | 87.14% | 1837 / 2108 | | DeepInfra | 86.91% | 1800 / 2071 | | GoogleVertex | 85.76% | 1668 / 1945 | | Together | 84.63% | 1602 / 1893 | | Chutes | 83.05% | 3037 / 3657 | Sixteen points between the top and the bottom of the same model. On the K2 0905 table the floor is lower: five deployments at 100%, then vLLM at 76.00%, SGLang at 73.13%, Volc at 72.86%, Baseten at 72.49%, Together at 71.96%. Roughly 28 points of spread on identical weights. A perfect schema score can still be a broken deployment Look at Groq on the 0905 table: 100.00% schema accuracy, and a trigger F1 of 69.52%. The schema metric only looks at calls the model already decided to make, so a deployment that fires tool calls at the wrong moments keeps a clean schema score. Nebius shows the same shape, 84.47% schema with 50.60% F1. Read the pair together or the number lies to you. High schema plus low F1 means the endpoint is confident about when to call tools and wrong about it. Per-call accuracy is the wrong unit Schema accuracy is a per-call number. Your agent doesn't make one call, it makes a session's worth, and every call has to validate. If the per-call probability is p, the chance that all N calls in a session validate is p^N. | Provider | per call | 10 calls | 25 calls | | --- | --- | --- | --- | | Fireworks | 100.00% | 100.0% | 100.0% | | SiliconFlow | 98.96% | 90.1% | 77.0% | | GMICloud | 95.95% | 66.1% | 35.6% | | vLLM | 87.22% | 25.5% | 3.3% | | Together | 84.63% | 18.9% | 1.5% | | Chutes | 83.05% | 15.6% | 1.0% | A 1.04 point gap between SiliconFlow and Fireworks looks like noise per call. Over a 25-call session it's a 23 point gap. This is the same reason a cost-per-PR number is a distribution rather than a price: the interesting behavior lives in the tail of the repeated event, not in the average of one. Two honest caveats on the table above. The denominators differ per provider (Moonshot's official run triggered 1958 tool calls, Together's 1893, Chutes' 3657), so these are not perfectly paired samples. And a schema failure in production is often a retry rather than a dead run, so p^N is a lower bound on session success, not a prediction of crash rate. The shape holds either way: small per-call differences get amplified by repetition, and the amplification is where agents live. The same provider shows up at both ends DeepInfra is 100.00% on k2-0905-preview at temperature 0.6, and 86.91% on k2-thinking at temperature 1.0. Together is 71.96% on one table and 84.63% on the other. So a provider's score is a property of a specific model version, decoding parameters, and serving stack, not a brand fact you can carry forward. KVV's first fix after the initial reports was exactly this class of thing: enforcing Temperature=1.0 and TopP=0.95 in thinking mode, and requiring that thinking content be passed back to the API. The repo also names two failure modes that are worth reading before you file a bug against a model. Tool call IDs have to follow the format functions.func_name:idx, and Moonshot's own API rewrites incoming IDs into that shape automatically. A provider that doesn't rewrite them feeds the model malformed IDs from history and gets parsing failures back. And there's no built-in schema enforcement: the model generates tokens by probability, so the README tells vendors to add guided encoding rather than trust prompting. Their recommended versions are vLLM v0.11.0 or newer and SGLang v0.5.3rc0 or newer for 0905, with v0.11.1rc6 and v0.5.5.post2 for thinking. If you route through an aggregator, you're already measuring a moving target Most teams don't pin a provider. They point at a router and take whatever answers. OpenRouter's default is price-based load balancing across providers with allow_fallbacks set to true, so the endpoint that serves your request can change between runs without any config change on your side. Their docs are explicit that a sort or order preference disables load balancing. That means your eval score, your p95 latency, and your schema accuracy are all attached to a provider you didn't choose. For an eval run, pin it: extra_body={"provider": {"only": ["fireworks"], "allow_fallbacks": False}} If you run a reviewer or an agent on your own keys, the provider is a config field you own rather than a default you inherit. Kodus's BYOK setup has that shape, keys in and a model choice per task, and it's the right shape for this problem: the provider is a variable you set per job and can hold constant while you measure something else. A protocol you can run in an afternoon 1. Pick one model version and one decoding parameter set. Write both down, because the next table you compare against won't have them. 2. Run your own tool-call test set against at least two providers, and log finish_reason plus a schema validation result per response. Do not log only pass or fail on the session, or you'll lose the per-call number. 3. Report schema_accuracy next to trigger F1. A clean schema score on its own has already been shown to hide a deployment that calls tools at the wrong times. 4. Re-run after every version bump on either side, and treat a provider change as a model change for eval purposes. The KVV table is a deployment check, not a model review. The useful takeaway isn't which vendor is on top this month, it's that identical weights produce a 16 to 28 point spread in the number your agent depends on, and that spread is something you can reproduce on your own endpoint in an afternoon. If you can't reproduce it, you don't have a number. You have a vendor's number.

vLLM Tool Calling Not Working? 1 in 12 Calls Fail by Default. Here's the Fix If your vLLM tool calling is not working with Kimi or DeepSeek, and your agent keeps emitting broken JSON, inventing arguments or looping on the same call, check your server before you blame the model. Ubicloud measured Kimi K2.6 on vLLM 0.28 and got schema-valid tool calls only 92% of the time. That is 2 failures in every 25 calls, roughly 1 in 12. With constrained decoding turned on, Ubicloud got to 100%. vLLM doesn't turn it on for you, even though Moonshot, who make the model, tell vendors to use it (they call it guided encoding). On vLLM 0.31+ the fix is one server flag, --tool-strict-level parameter, and the rest of this post is about why and how to check it worked. A lot of the "open models are bad at agents" talk I've seen comes down to a server default. What broken vLLM tool calls look like On the client it rarely says "tool call failed". Instead you get: - arguments that won't parse as JSON, or parse but miss a required field - a parameter the tool never declared, or an enum value that isn't in the enum - the agent reading back its own validation error, retrying with the same mistake and burning your token budget in a loop - a framework that quietly drops the call and lets the model answer in prose Each of these looks like a model problem, so people swap models or add three paragraphs of "ALWAYS RETURN VALID JSON" to the system prompt. Neither fixes it. 92% sounds fine until you chain calls Per-call accuracy compounds. At 92%, a 10-step agent run gets through clean 0.92^10 ≈ 43% of the time. At 20 steps it's about 19%. In the Hacker News thread, one commenter worked out that even 95% per call gives you about an 8% chance of finishing a 50-call sequential task. Someone else in the same thread said they run around 300 tool calls per prompt. 92% wasn't a fluke of Ubicloud's setup, either. Moonshot's own K2 Vendor Verifier results (test date 2025-11-15) show the vLLM reference deployment at 87.22% schema accuracy on K2-thinking and 76.00% on K2-0905, while Moonshot's API and providers like Fireworks hit 100% serving the same weights. Why vLLM leaves tool calls unconstrained by default Without constraints, the model samples tool-call tokens like any other text. Kimi K2.6's format looks like this: <|tool_calls_section_begin|><|tool_call_begin|>functions.webfetch:0<|tool_call_argument_begin|>{"url": "https://ubicloud.com", "format": "markdown"}<|tool_call_end|><|tool_calls_section_end|> Nothing stops the model from writing an unknown function name, a non-integer index or JSON that ignores your schema. Constrained decoding uses XGrammar structural tags to mask the vocabulary at each step, so once the model opens a tool call it can only produce a declared tool name, then an integer index, then JSON that matches that tool's schema, then the end tag. vLLM supports this, just not on every request. PR #45600, merged in June 2026, changed tool_choice="auto" so structural tags apply only when at least one tool sets "strict": true. A missing strict counts as not strict. A reviewer on that PR objected that Claude Code's protocol doesn't include a strict field at all, which left Messages API clients with no obvious opt-in; the PR ended up adding strict to vLLM's Anthropic tool model. Plenty of OpenAI-style agent code doesn't set it either. So if you're on tool_choice="auto" (most agents are) without strict on your tools, you're sampling free-form. Ubicloud originally added constrained decoding in their own vLLM fork. After vLLM shipped the feature in v0.25 they switched to upstream, and their score dropped back to 91% because of this default change. The fix: --tool-strict-level in vLLM 0.31+ vLLM 0.31.0 added a server-side floor, --tool-strict-level (PR #56268). From the tool calling docs: | Value | What gets constrained | |---|---| | auto | Default for most parsers. Structural tags only for required/named tool choice, or auto when a tool sets strict: true | | function | Tool-call envelope (markup, function name) on every request with tools. Arguments stay free unless the tool is strict | | parameter | Everything in function, plus argument schemas for every tool, as if all were strict | If you don't set it, the parser's default applies: function for glm47, auto for everything else, Kimi included. For a Kimi deployment I'd go straight to parameter. Invented args and missing required fields are argument problems, and function doesn't touch those: vllm serve <your-kimi-k2.6-checkpoint> \ --enable-auto-tool-choice \ --tool-call-parser kimi_k2 \ --tool-strict-level parameter Two things to know before you deploy it: - It's a floor. It never loosens what a request already asked for, and it doesn't force a tool call. The grammar engages only after the model opens the tool-call wrapper itself. - VLLM_ENFORCE_STRICT_TOOL_CALLING=false turns structural tags off entirely and overrides this flag. If someone set it while chasing a bug months ago, the flag does nothing. Stuck below 0.31? Set "strict": true on every function definition you send. Under tool_choice="auto" that turns on the same structural tags without a server flag. Where constrained decoding still bites This has costs, and the HN thread argues about them at length. A grammar guarantees valid syntax but can't make the arguments correct: a well-formed call to the wrong tool with a wrong URL still passes. One commenter argued that grammar masking only gives you token-level retries rather than retrying the whole sequence, so it can skew output away from what the model would have picked, and suggested just retrying failed calls. They later allowed that retries might not win once you count cost. Ubicloud's post calls constrained decoding "a per-model task", and one of its authors said in the thread that Qwen 3.8 doesn't come with the clear recommendation Moonshot gives for Kimi, and advised checking model quality with it on and off. Measure both. It also has bugs you should know about: - #58930: JSON schemas nested inside structural tags skip XGrammar's unsupported-feature check, so a constraint like multipleOf is silently ignored. Still open at the time of writing, with a fix proposed in PR #58940. - #44006: strict tool calling plus MTP speculative decoding threw "Failed to advance FSM" errors and 500s. Closed by PR #44297 in July 2026, though a later comment on v0.28.0 still saw the FSM error, just without the 500. - #55152: the guidance backend rejects the new structural tag format with KeyError: 'triggers'. A vLLM contributor replied that the tool-call structural tags were built for xgrammar and expects all of them to fail on guidance. Ubicloud also notes that gpt-oss-20b, Qwen 3.6 and GLM 5.1 users reported issues back when constrained decoding was on by default. PR #45600 says it wanted to stop structural tags from over-constraining generation when the caller hadn't asked for strict. I think that was the wrong trade: a few loud regressions on some models in exchange for Kimi and DeepSeek deployments silently failing a chunk of their tool calls. Measure your own deployment with K2VV Don't take my numbers or Ubicloud's on faith; test your own deployment. Moonshot's K2 Vendor Verifier works against any OpenAI-compatible endpoint. The repo ships a pyproject.toml and uv.lock, and the tool-call sample set (half of the 4,000-request test set, which matches the 2,000 requests Ubicloud ran) lives at https://statics.moonshot.cn/k2vv/tool-calls.tar.gz. The README's example for Kimi K2.5 served by vLLM or SGLang, with thinking turned off (Instant mode): python tool_calls_eval.py samples.jsonl \ --model kimi-k2.5 \ --base-url YOUR_API_BASE_URL \ --api-key YOUR_API_KEY \ --concurrency 5 \ --extra-body '{"chat_template_kwargs": {"thinking": false}, "temperature": 0.6}' Swap --model for whatever name your server reports. You get two numbers in summary.json: - schema_accuracy: successful tool calls divided by responses that finished with tool_calls. Anything under 100% means your server is shipping broken calls. - tool_call_f1: how closely your deployment matches Moonshot's API on when to call a tool. Moonshot's acceptable bar is above 73% for K2-thinking and 80% for K2-0905. Run it once with your current flags and once with --tool-strict-level parameter. Use --incremental to rerun only the failed requests. If the schema number doesn't move, your problem is somewhere else, but at least you've ruled out the cheapest fix. The checklist: 1. Upgrade to vLLM 0.31 or newer. 2. Add --tool-strict-level parameter. 3. Confirm VLLM_ENFORCE_STRICT_TOOL_CALLING isn't set to false. 4. Use the xgrammar backend, not guidance. 5. If you run MTP or other speculative decoding, retest after enabling strictness. 6. Run K2VV before and after, and keep the summary.json files. So what's your number? My guess is most teams have never measured their tool-call failure rate. They have a vague feeling the agent is "flaky" and a retry loop that hides it. What's yours in production? Have you actually measured it, and did constrained decoding help or hurt your model? If you think retries beat grammars, tell me why in the comments. Sources - Ubicloud: Fixing Tool-Call Accuracy in vLLM - Hacker News discussion - MoonshotAI K2 Vendor Verifier - vLLM tool calling docs - vLLM v0.31.0 release notes - vLLM PR #45600, PR #56268, issues #58930, #44006, #55152

再补一句：Moonshot 官方 GitHub 的 Kimi-Vendor-Verifier 里有一张 K3 测评表，列了 Fireworks、Together、Baseten、Nebius、Modal 等 9 家，DeepInfra 不在表里。但这张表是不是许可证说的「认证推理伙伴」名单，官方没说，【未核实】。MoonshotAI/Kimi-Vendor-Verifier 【非投资建议】

教程：blog.zhoudw.vip 仓库：MoonshotAI/kimi-code 同日补充（据 IT之家转载 Kimi 官方致歉，2026-10-26）：会员用 K3.1 Pro 出现限流与不必要额度消耗；有效订阅补偿月度总额 25%（约一周用量），当前用量不足 25% 则重置为 0；并称已减少多余子 Agent 与过长输出。 ithome.com

Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5 for Front-End Work: Benchmarks, Cost per Build, and a Three-Model Test Script TL;DR. One of the three has shipped. Moonshot released Kimi K3.1 Pro on 23–24 October, and AIHubMix already serves it as kimi-k3.1-pro. Alibaba hasn't released Qwen 4 yet (its tiers were named at Apsara in September), and Fable 5.5 has only appeared in leaks. For them there's an anonymous Arena model (Kalmia, tied to Qwen by tokenizer fingerprint) and a claude-fable-5-5 catalogue listing that was removed a day later. What the evidence says so far: - Moonshot's numbers: K3.1 Pro ahead of Fable 5.1 on agentic coding. 65.7 to 57.9 on Terminal-Bench 4.0 and 75.5 to 67.4 on DeepSWE, but 31.5 to 53.5 behind on ProgramBench. Self-reported, harnesses differ, and the rival is Fable 5.1, not 5.5. - Independent numbers, mostly last generation: Fable. Claude Fable 5.1 scores 53 to Kimi K3's 44 on Artificial Analysis's Intelligence Index v4.3.2, and 52% to 13% on its Terminal-Bench 4.0 run. - Cost: Kimi. $2.00 per index task for K3 against $7.63 for Fable 5.1. K3.1 Pro is cheaper per token than K3: Moonshot lists it at $2.00 / $10.00 per million, a third below K3's $3.00 / $15.00. - Front end: split. K3 topped Arena's Frontend Code board at launch, ahead of Fable 5. On the LMArena WebDev ratings AIHubMix shows today, Fable 5.1 leads K3, 1,742 to 1,655. - Token price: Qwen. Qwen3.8-Max's list output price, $6.00 per million, is 60% of K3.1 Pro's and 40% of K3's. - One one-prompt build, at official list prices and the token counts of AIHubMix's own K3 run: about $1.14 on K3, $0.76 on K3.1 Pro, $0.46 on Qwen3.8-Max and $3.80 on Fable 5.1, if all of them used the same tokens. That's an assumption, not a measurement. The engineering problem for launch week: neither price sheets nor vendor tables will settle this; one measured run per model will. This post collects what's known, checks the loudest claims, and gives a script that sends the same Three.js prompt to all three. Why these three, and the task that decides it - Qwen 4 is the same-week, same-tier rival. Kibitz and Kalmia ran side by side in Code Arena's battle mode. K3 and Qwen3.8-Max were the summer's two Chinese trillion-parameter flagships, both with downloadable weights. - Fable 5.5 is the model both are chasing. Moonshot measured K3 against Claude Fable 5 at launch and K3.1 Pro against Fable 5.1. Developers who use Claude ask the same thing of every Kimi release: can it do Fable's job for a fraction of the price? - One task decides it: a one-prompt 3D front-end build in Three.js. Kimi's teaser shows exactly that, and Moonshot lists 3D creation among K3.1 Pro's main gains. Arena testers gave Kalmia prompts like "a 3D cycle riding a cow using three.js". Front end is also where Kimi has independent evidence on its side. What's known about each model | | Kimi K3.1 Pro | Qwen 4 | Claude Fable 5.5 | |---|---|---|---| | Status | Shipped, 23–24 Oct | Named, 22 Sep | Leaked, 13 Oct | | Codename seen | Kibitz (likely) | Kalmia (likely) | Onigiri (likely) | | Parameters | 3T | Not announced | Not announced | | Open weights | By 4 Nov (announced) | 27B shown as open | No | | Context | 1M | Not announced | Not announced | | Price | $2.00 / $10.00 (official) | Not announced | 5.1's (placeholder) | | Model ID seen | kimi-k3.1-pro | None | claude-fable-5-5 | The Kimi column comes from Moonshot's launch post and API docs. K3.1 Pro is a post-trained K3 with 3T parameters (K3 has 2.8T), image and video input, and a 1M context priced flat. For your client code, the rules match K3's: thinking is always on, reasoning_effort takes low, high or max and defaults to max, temperature is fixed at 1.0, and max_completion_tokens defaults to 131,072 with a ceiling of 1,048,576. Moonshot says "the full model weights will be released by Nov 4". The price cell is Moonshot's official list, per million tokens: $2.00 input, $10.00 output, $0.20 cached, a third below K3's $3.00 / $15.00 / $0.30 (¥13 / ¥68 against ¥20 / ¥100 on the CNY list). AIHubMix serves Kimi K3.1 Pro under Moonshot's ID; the cost model below uses the official lists. The other two columns are still leaks or stage announcements. Qwen 4's four tier names (Max, Plus, Flash, 27B) come from attendee reports of Alibaba's Apsara keynote. Its architecture preview, Qwen3.8-Flash-Next, has open weights: 125B main parameters plus 51B of n-gram embeddings, about 6B active per step. The Fable column is the shakiest. On 13 October a claude-fable-5-5 entry was added to LiteLLM's price list from an Azure catalogue, with its price, context and output fields copied from Fable 5.1 ($10 / $50, 1M context, 128K output). It was removed a day later, when nobody could find a deployment. TestingCatalog reported on 17 October that partners have the model. A test model called claude-onigiri-eap was briefly visible on Artificial Analysis and is the likeliest candidate for it. The hype, checked | Claim | Status | |---|---| | Qwen 4 has 5–10 trillion parameters | Wrong: that target is for Qwen 4.5 and 5 | | K3.1 built 13,707 Minecraft blocks for $0.38 | One leaker, unreproduced | | Kalmia beat GPT 6.1 Sol Ultra on a prompt | One tester's anecdote | | Fable 5.5 is live on Azure | Listing removed a day later | | Code Arena's "korrine" was K3.1 | Wrong: tokenizer says Qwen-family | | K3.1 costs the same as K3 | Wrong: Moonshot's list is a third lower | The same-price claim came from a September registry listing that showed K3's price, likely a placeholder; Moonshot's own list now prices K3.1 Pro a third below K3 ($2.00 / $10.00 against $3.00 / $15.00). The Minecraft figure is from @ChrisGPT on X: 13,707 blocks for $0.38 from K3.1, against 5,738 blocks for $5.31 from a GPT-6 model. No prompt or token counts were published, so there's nothing to rerun. And anonymous labels have been wrong before: in August a Code Arena model was taken for K3.1 until a tokenizer fingerprint placed it in the Qwen family. K3.1 Pro has shipped, but Moonshot hasn't said it was Kibitz, so treat Kibitz, Kalmia and Onigiri as strong guesses until the labs confirm. Baseline: K3, Qwen3.8-Max and Fable 5.1 Apart from a first, preliminary Arena score (below), K3.1 Pro's benchmark numbers are Moonshot's, so the independent baseline is still the previous generation. | | Kimi K3 | Qwen3.8-Max | Claude Fable 5.1 | |---|---|---|---| | Released | Jul 2026 | Aug 2026 | Sep 2026 | | Weights | Open | Open | Closed | | Context / max output | 1M / 1M | 1M / not stated | 1M / 128K | | Official in / out | $3.00 / $15.00 | $2.00 / $6.00 | $10.00 / $50.00 | Prices are official list prices per million tokens; AIHubMix sells Qwen3.8-Max for less, at $1.69 / $5.07. Both open-weight models come with custom licences. Kimi vs Fable. From Artificial Analysis, Intelligence Index v4.3.2, both models at max effort: | AA result | Kimi K3 | Fable 5.1 | |---|---|---| | Intelligence Index | 44 | 53 | | Terminal-Bench 4.0 | 13% | 52% | | Humanity's Last Exam | 47% | 59% | | AA-LCR (long context) | 89% | 85% | | AutomationBench | 58% | 59% | | Cost per task | $2.00 | $7.63 | | Output tokens per task | 48k | 78k | Fable 5.1 is clearly ahead on hard reasoning and terminal work. Kimi leads only on long-context retrieval and ties on business automation. Fable also spent more tokens per task, so each task cost almost four times as much, a wider gap than the list prices suggest. Kimi vs Qwen. These independent figures are older: Artificial Analysis results from August 2026 (Intelligence Index v4.1.1), as compiled by Qubrid. K3 scored 57 and Qwen3.8-Max 56, and K3 was cheaper per task ($0.86 to $1.14) because Qwen spent more tokens. In TrilogyAI's blind-reviewed StackPerf test, each model got an hour to analyse the same 269 files from two codebases (Qwen ran as the 3.8-Max preview). K3 scored 83 and Qwen 80, and the reviewers called the two "complementary". Don't compare the v4.1.1 and v4.3.2 numbers with each other: Artificial Analysis rescaled the index between them. K3.1 Pro vs Fable 5.1: Moonshot's numbers Figures are Moonshot's self-reported launch numbers; harnesses differ by model and nobody has reproduced them yet. Most of K3.1 Pro's coding runs used a Claude Code harness, and Fable 5.1 ran at max effort with fallback. Moonshot's table has Fable 5.1, not 5.5, and no Qwen model. | Moonshot's result | Kimi K3.1 Pro | Fable 5.1 | |---|---|---| | Terminal-Bench 4.0 | 65.7 | 57.9 | | DeepSWE v1.1 | 75.5 | 67.4 | | SWE-Marathon v1.1 | 51.7 | 45.6 | | ProgramBench | 31.5 | 53.5 | | Humanity's Last Exam, no tools | 51.1 | 57.6 | | OSWorld V2.1 | 79.6 | 80.7 | | Hallucination rate | 8.3 | 23.3 | The hallucination row is Moonshot's internal Kimi Hallu Bench (hard, with tools); lower is better. K3.1 Pro wins the long agentic coding runs and makes far fewer factual errors on Moonshot's own test. It loses badly on ProgramBench, loses on Humanity's Last Exam without tools, and roughly ties on OSWorld. On the same test version as its predecessor, DeepSWE went from K3's 67.5 to 75.5. Don't chain the Terminal-Bench rows across tables. Artificial Analysis's harness put K3 at 13% on Terminal-Bench 4.0; Moonshot's 65.7 for K3.1 Pro comes from a different harness. It's not a jump from 13 to 65.7, and it doesn't overturn Fable's independent lead until someone reruns it. Front end: what the evidence says Arena battles this week. Arena doesn't publish scores for anonymous models, so the only evidence on the new pair is one-shot battles that testers posted on X. TestingCatalog collected the Kibitz reports on 23 October; the Kalmia rows come from the testers' own posts: | Battle report | What it showed | |---|---| | Same 3D helicopter prompt, Kibitz vs Kalmia | Both built it in 15–20 minutes | | Kibitz vs Fable 5.1, 3D test | Kibitz quicker; rated near Opus 5.5 Medium | | Kibitz, voxel castle | "Feels identical to GPT-6.1 Sol Max" | | Kalmia, drivable 3D car | About 20 minutes, "still has some issues" | LuminaBench's helicopter test is the closest to this post's task. From the same prompt, both models built takeoff, landing and exploded-part views; Kibitz added X-ray and wireframe modes, Kalmia a component index and flight telemetry. The tester called both "very strong". Each report is one prompt and one attempt, so none of it ranks the models. No anonymous Fable 5.5 has been reported on Arena; its likely codename, Onigiri, showed up only in Artificial Analysis's site code. Kimi vs Qwen: Kimi, narrowly. K3 took first place on Arena's Frontend Code leaderboard at launch with 1,679 points, ahead of Claude Fable 5 (1,631), and led six of the seven frontend domains; Fable 5 kept only Gaming. Sources disagree on Qwen3.8-Max's standing on that board, so it gets no number there. On Arena's WebDev board on 24 October, K3.1 Pro (Max) has a preliminary 1,692 (±14, about 2,450 votes) against 1,673 for Qwen3.8-Max's September build; K3 itself, at 1,655, sits below both Qwen builds. Kimi vs Fable: unclear. On the LMArena WebDev ratings AIHubMix shows today, Fable 5.1 scores 1,742 to K3's 1,655. That's a different board from the Frontend Code arena K3 topped in July, so the two results don't make a trend, but Fable is ahead on the board AIHubMix tracks. K3.1 Pro's first, preliminary score there, 1,692, narrows the gap but leaves Fable 5.1 about 50 points ahead. Moonshot's own front-end number is its internal Design Bench, an Elo rating: K3.1 Pro 957, GPT-6 Astra 1,076, Claude Opus 5.5 927, and no Fable 5.1 entry. Where K3.1 Pro lands against Fable 5.5 is the first thing to check once both have independent results. A cost model for one build AIHubMix's own K3 run of a one-prompt game build (single HTML file, one reference image) used 74,994 completion tokens, 73% of them thinking, over about 42 minutes. Input wasn't recorded; assume 5,000 tokens. Official list prices: K3: 5,000 × $3.00/M + 74,994 × $15.00/M ≈ $1.14 K3.1 Pro: 5,000 × $2.00/M + 74,994 × $10.00/M ≈ $0.76 (same token counts) Qwen3.8-Max: 5,000 × $2.00/M + 74,994 × $6.00/M ≈ $0.46 (same token counts) Fable 5.1: 5,000 × $10.00/M + 74,994 × $50.00/M ≈ $3.80 (same token counts) Measured K3.1 Pro / Qwen 4 / Fable 5.5: AIHubMix will run this once all three are available The shared token count is the weak spot, and real counts move the result both ways. On Artificial Analysis's tasks, Fable 5.1 used more output tokens than K3, and so did Qwen3.8-Max. In one hands-on build by Chase AI, K3 used about six times Fable 5's tokens. K3.1 Pro doesn't think less than K3: in an AIHubMix spot check at low effort, both reasoned several thousand tokens on the same prompt (K3.1 Pro 5,561–7,356, K3 3,013–7,051), though K3.1 Pro finished about twice as fast. Replace these lines with measured completion_tokens. Prerequisites - An AIHubMix key in AIHUBMIX_API_KEY. - The OpenAI Python SDK: pip install openai. - Kimi, Qwen and Claude models answer on the same OpenAI-compatible endpoint, https://aihubmix.com/v1, so only the model ID changes. - kimi-k3.1-pro is live on AIHubMix. AIHubMix serves it on Chat Completions, Responses and Messages; the script uses Chat Completions. qwen4-max and claude-fable-5-5 are guesses until those models ship, and AIHubMix rejects both today (see the failure modes below). To run the current generation now, use qwen3.8-max and claude-fable-5-1. The script import os from openai import OpenAI client = OpenAI(base_url="https://aihubmix.com/v1", api_key=os.environ["AIHUBMIX_API_KEY"]) prompt = ("Build a single-file HTML page with Three.js: a low-poly cow riding a bicycle " "around a track, with orbit controls. Return only the HTML.") for model in ["kimi-k3.1-pro", "qwen4-max", "claude-fable-5-5"]: # Qwen 4 and Fable 5.5 IDs are guesses, not on AIHubMix yet r = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], timeout=3600, ) with open(f"{model}.html", "w") as f: f.write(r.choices[0].message.content) print(model, r.usage.prompt_tokens, r.usage.completion_tokens) Each model writes <model>.html and prints its prompt and completion tokens; each call gets up to an hour, which K3.1 Pro may need, since it thinks at max unless told otherwise. Open the three files side by side, judge the scenes, then price each run from the printed counts instead of the estimate above. Failure modes and fixes A 400 on temperature. K3.1 Pro fixes temperature at 1.0, like K3. When an AIHubMix test sent 0.2 to kimi-k3.1-pro, it came back as 400 invalid temperature: only 1 is allowed for this model. The script leaves the field out; if your client or framework injects a default, strip it for Kimi models. The migration post linked below covers the K3.1 Pro 400s. A first token that takes minutes. Artificial Analysis measured Fable 5.1's first token at 255 seconds, because its reasoning isn't streamed, against 3.6 seconds for K3. Yet Fable finished an average task in 722 seconds against K3's 1,231. A watchdog tuned to Kimi's first token will cut Fable off early; size timeouts and progress indicators for both. If Kimi's wall-clock time is the problem, Moonshot says K3.1 Pro Highspeed (kimi-k3.1-pro-highspeed) has identical capabilities at 2–3× the speed (138–150 tokens a second in an AIHubMix spot check on the main IDs, about 1.6–1.75× K3.1 Pro's rate at low effort over three runs each, with tool calls no faster); the Highspeed post below weighs that against its price. A 200 that isn't an answer. Fable runs safety classifiers that can decline a request with a normal 200 response and stop_reason: "refusal". Anthropic's stop-reason docs recommend retrying on another Claude model. Check that a reply actually contains HTML before writing it out. In Moonshot's own runs, Fable 5 fell back on 35% of SWE-Marathon tasks; that's a rival's number, but test security-adjacent prompts early. Long outputs cut short. Fable 5.1 caps output at 128K tokens. K3.1 Pro allows up to 1,048,576 but defaults max_completion_tokens to 131,072, so raise it for whole-file generation and long reports. Choosing on per-token price. List prices, per-task cost and per-build tokens point in different directions. Compare completion_tokens from real runs on your own prompt before choosing on price. Trusting a codename. "korrine" was the wrong model. Kibitz, Kalmia and Onigiri are guesses, and K3.1 Pro shipping doesn't confirm Kibitz, so don't wire anything to them until the labs confirm. A 400 on the Qwen and Fable IDs. qwen4-max and claude-fable-5-5 are guesses. On 24 October AIHubMix answered both with a 400, "This model ID is incorrect", so the loop stops after writing the Kimi file. Swap in qwen3.8-max and claude-fable-5-1 to compare against the current generation, and check the real Qwen 4 and Fable 5.5 IDs on AIHubMix when they launch. What this can't tell you yet - Independent benchmarks for K3.1 Pro beyond a first, preliminary Arena score; every other K3.1 Pro score here is Moonshot's. - Prices, context and open-weight status for Qwen 4 and Fable 5.5, which haven't been announced. - Qwen3.8-Max's maximum output, which the sources used here don't state. - Whether Kimi keeps its front-end lead over Qwen, and where K3.1 Pro lands against Fable 5.5. - Real token counts on the Three.js prompt for any of the new models. - Qwen3.8-Max's Frontend Code standing: sources disagree. Which one to pick These calls rest on the independent K3, Qwen3.8-Max and Fable 5.1 record, weighed against Moonshot's K3.1 Pro numbers and K3.1 Pro's first, preliminary Arena score. Re-check them once K3.1 Pro has more independent results and the other two have launched. - Hardest agentic and terminal work, where a failed run costs more than the tokens: Claude Fable 5.5, until independent tests back Moonshot's numbers. Moonshot puts K3.1 Pro ahead of Fable 5.1 on Terminal-Bench, but the last independent check had Fable 5.1 far ahead of K3 there. - Front-end and UI generation at volume: start with Kimi K3.1 Pro, and run the Three.js test against Fable 5.5 before committing. Kimi beat Qwen there, but Fable 5.1 leads on WebDev today, and Moonshot's Design Bench didn't rate Fable. - High-volume, short tasks: Qwen 4, if it keeps Qwen3.8's pricing. - Long documents and retrieval across a 1M-token context: Kimi K3.1 Pro, priced flat across the context. K3 led Fable 5.1 on long-context retrieval at a quarter of the cost per task. - Self-hosting or data residency: Kimi or Qwen. K3's weights are about 1.56 TB and need a large multi-accelerator cluster, and K3.1 Pro's are due by 4 November; Qwen 4 27B is the tier shown as open, and its predecessor fits on one 80 GB GPU. Fable has no weights and runs only on Anthropic's API and the clouds that resell it. AIHubMix's Kimi K3.1 Pro vs Claude Fable 5.1 comparison page puts the current pair side by side. Keep reading: the Kimi K3.1 Pro series - If you're already on Kimi and the real question is whether to move up from K3: Kimi K3 to K3.1 Pro: What Carries Over, What Breaks, and How to Measure the Bill - If this comparison sends you to K3.1 Pro, clear the 400s and the max-effort bill before you switch: Kimi K3.1 Pro Migration Guide: the 400s, the Quiet Failures, and a Claude Code / Codex Config - If Kimi's wall-clock time is what worries you next to Fable, see whether the fast variant earns its price: Timing Kimi K3.1 Pro vs Highspeed: 1.7x Faster for 2x the Price, and When That's Worth It Sources - Moonshot AI: Kimi K3.1 Pro tech blog - Moonshot AI: Kimi K3 model card and evaluations - Artificial Analysis: Claude Fable 5.1 vs Kimi K3 - AIHubMix: Kimi K3 vs Claude Fable 5.1 - TestingCatalog: Claude Fable 5.5 reaches partners

Kimi K3.1 Pro: 65,7% en Terminal-Bench, según Moonshot; pesos abiertos 4 nov Moonshot AI activó hoy Kimi K3.1 Pro en Kimi.ai, Kimi Work, Kimi Code y su API, aunque los pesos abiertos del modelo recién llegarán el 4 de noviembre. Mientras tanto, ya compite de cerca con Claude Opus 5.5 en programación de agentes: 65,7% frente a 66,4% en Terminal-Bench 4.0. El lanzamiento también suma K3.1 Pro Highspeed, una variante entre 2 y 3 veces más rápida pensada para interacciones en tiempo real. Es la primera entrega de la nueva serie K3.1 y el salto más grande de Moonshot AI desde Kimi K3. TL;DR - Moonshot AI lanzó Kimi K3.1 Pro hoy 23 de octubre de 2026, con contexto de 1 millón de tokens.- El modelo anota 65,7% en Terminal-Bench 4.0, por encima de GPT-6 Astra (58,2%) y cerca de Claude Opus 5.5 (66,4%).- Los pesos abiertos completos se liberarán antes del 4 de noviembre de 2026.- La variante K3.1 Pro Highspeed ofrece entre 2 y 3 veces más velocidad de respuesta.- En finanzas, el modelo mejora 11,6 puntos sobre Kimi K3 en el benchmark Financial Research. Qué es Kimi K3.1 Pro Kimi K3.1 Pro es el modelo insignia de código abierto que Moonshot AI incorporó a su nueva serie K3.1, con pesos liberados y una ventana de contexto de 1 millón de tokens. Es una versión post-entrenada de Kimi K3 mediante aprendizaje por refuerzo a gran escala, optimizada para programación, modelado 3D y análisis financiero. Moonshot AI lo describe como su modelo abierto de clase 3 billones de parámetros más capaz hasta la fecha. Está disponible hoy en los cuatro productos de la familia Kimi: el chat general en Kimi.ai, el entorno de trabajo Kimi Work, el asistente de programación Kimi Code y la API para desarrolladores. A diferencia de un lanzamiento desde cero, K3.1 Pro parte de los mismos pesos base de Kimi K3 y agrega una capa de entrenamiento por refuerzo mucho más grande, aplicada a cientos de dominios distintos a la vez. Qué pasó El anuncio llegó acompañado de cifras de rendimiento concretas. En Terminal-Bench 4.0, que evalúa agentes de código en tareas de terminal con recursos limitados, Kimi K3.1 anota 65,7%. Eso lo ubica por encima de GPT-6 Astra (58,2%) y apenas detrás de Claude Opus 5.5 (66,4%). En el benchmark interno Kimi Code Bench 3.0 Long-horizon, que mide ejecución de múltiples pasos y uso de herramientas en tareas de ingeniería, el modelo llega a 61,2%, frente al 55,95% de Kimi K3. La mejora de casi 5,3 puntos viene del mismo entrenamiento por refuerzo ampliado que define a toda la serie K3.1. K3.1 Pro Highspeed corre entre 2 y 3 veces más rápido que el modelo base, pensada para chats y agentes que necesitan respuestas inmediatas. Moonshot AI no publicó todavía benchmarks separados para esa versión, así que su calidad real frente al modelo estándar sigue sin confirmarse de forma independiente. Terminal-Bench 4.0 evalúa agentes de código en tareas de terminal con recursos limitados. Contexto e historia Moonshot AI es el laboratorio chino detrás de la familia Kimi, que pasó de ser un asistente de chat único a un ecosistema con versiones separadas para trabajo, programación y agentes. Esa división llegó con Kimi K3, repartido entre Kimi Work, Kimi Code y Kimi Claw. K3.1 Pro es el sucesor directo de ese modelo: toma los mismos pesos base y agrega una ronda de entrenamiento por refuerzo mucho más grande en cientos de dominios a la vez. Moonshot AI lo posiciona como su respuesta más directa hasta ahora a los modelos cerrados de Anthropic y OpenAI en tareas de agentes de código. Detalles técnicos El salto de rendimiento no viene de una arquitectura nueva, sino de cómo Moonshot AI organiza el entrenamiento por refuerzo. La compañía rediseñó capa por capa el framework de RL, la inferencia de contexto largo, la eficiencia del entrenamiento, la infraestructura de sandboxes y la planificación de rollouts, además de una plataforma compartida que revisa la calidad de cada entorno de entrenamiento. Ese rediseño permite que cada unidad de cómputo adicional de RL produzca una ganancia estable y predecible en cada dominio, en lugar de mejoras que se estancan en algunos mientras otros retroceden. El siguiente diagrama resume ese flujo: flowchart TD A["Framework de RL"] --> B["Inferencia de contexto largo"] B --> C["Eficiencia de entrenamiento"] C --> D["Infraestructura de sandboxes"] D --> E["Planificacion de rollouts"] E --> F["Chequeo de calidad de entornos"] F --> G["Ganancia estable por computo de RL"] El caso más concreto que Moonshot AI documentó es un simulador de dinámica de caminata humana, construido sobre human-atlas, un modelo anatómico abierto con 296 componentes óseos y 402 componentes musculares. En 167 misiones y 420 revisiones independientes, el modelo analizó resultados experimentales, diagnosticó errores y refinó el controlador de marcha hasta lograr que la simulación pasara de colapsar en segundos a caminar 11,2 segundos con zancadas alternadas. Cuando ajustar la función de recompensa dejó de mejorar el movimiento de los brazos, el sistema no insistió con más ajustes. Corrió pruebas de lazo abierto sobre la física del simulador, encontró y corrigió 36 errores en el cálculo del brazo de palanca de los músculos del hombro, y recién después volvió a entrenar el controlador. En modelado 3D, K3.1 Pro usa razonamiento espacial para inferir forma, proporciones y relaciones entre piezas a partir de un boceto, una imagen de referencia o una descripción de texto. En BenchCAD, que mide reconstrucción 3D desde renders multi-vista hasta generar código CAD, anota 92,7% con herramientas, cerca del 96,2% de Claude Opus 5.5 y el 95,9% de GPT-6 Astra. Puede escribir y ejecutar scripts para Blender y software CAD sin depender de conectores MCP, algo útil para modelado paramétrico de piezas mecánicas o muebles configurables. BenchmarkKimi K3.1 ProClaude Opus 5.5GPT-6 AstraTerminal-Bench 4.0 (agentes de código)65,7%66,4%58,2%BenchCAD (modelado 3D con herramientas)92,7%96,2%95,9% En finanzas, el modelo alcanza 64,4 puntos en OfficeQA Pro v2, el mejor resultado reportado para ese benchmark, que exige análisis de datos fiscales reales con verificación cruzada entre documentos. También mejora 7,2 puntos sobre Kimi K3 en Financial Modeling, que evalúa enlaces de fórmulas y lógica financiera en hojas de cálculo reales, y 11,6 puntos en Financial Research, que mide si el modelo produce investigación auditable bajo restricciones de evidencia y fecha de corte. En Business Operation, un entorno simulado de gestión de negocio a largo plazo, el modelo rinde cerca de 4,2 veces más que Kimi K3. BenchCAD mide reconstrucción 3D desde renders multi-vista hasta código CAD generado. Impacto y análisis El resultado más relevante no es que K3.1 Pro gane en algún benchmark puntual, sino que un modelo abierto quede a menos de un punto de un modelo cerrado de referencia en tareas de agentes reales. Eso reduce el argumento de que solo los laboratorios cerrados pueden sostener este tipo de rendimiento. > 📌 Nota: los pesos abiertos permiten auto-hospedar K3.1 Pro, pero un modelo de clase 3 billones de parámetros exige clusters con cientos de gigabytes de memoria de GPU: no es algo que corra en una laptop ni en un servidor único. Para equipos de LATAM, la ventana de 1 millón de tokens importa tanto como el puntaje. Permite cargar bases de código completas, documentos financieros largos o historiales de conversación extensos sin fragmentar el prompt. Pero el acceso real, hasta que estén los pesos el 4 de noviembre, pasa por la API o por los productos de Kimi, no por infraestructura propia. La competencia también se mueve rápido: Claude Opus 5.5 sigue ligeramente adelante en Terminal-Bench 4.0 y en BenchCAD, y GPT-6 Astra queda atrás en ambos. La diferencia entre los tres hoy se mide en puntos porcentuales, no en generaciones completas de modelos. Qué sigue Los pesos completos de Kimi K3.1 llegan el 4 de noviembre de 2026, lo que permitirá a la comunidad correr evaluaciones independientes y confirmar si los números de Moonshot AI se sostienen fuera de sus propios benchmarks internos. Hasta entonces, cualquier comparación depende de los datos que publicó la propia compañía. También queda por ver si K3.1 Pro Highspeed mantiene la calidad del modelo base a 2 o 3 veces la velocidad, algo que Moonshot AI todavía no respaldó con benchmarks propios. Y si 3D Make, ya activo en kimi.ai, se traduce en adopción real fuera de los ejemplos que mostró la propia compañía. 📖 Resumen en Telegram: Ver resumen Probalo vos: entrá a kimi.ai hoy mismo y compará una tarea de programación larga contra el modelo que uses ahora, antes de que lleguen los pesos abiertos el 4 de noviembre. Preguntas frecuentes ¿Qué es Kimi K3.1 Pro y quién lo desarrolla? Es el modelo insignia de código abierto de la nueva serie K3.1 de Moonshot AI, con contexto de 1 millón de tokens y post-entrenado sobre Kimi K3 con aprendizaje por refuerzo a gran escala. ¿Cuándo se liberan los pesos abiertos de Kimi K3.1? Moonshot AI confirmó que los pesos completos del modelo estarán disponibles antes del 4 de noviembre de 2026; hoy solo está disponible vía producto y API. ¿Qué diferencia a K3.1 Pro Highspeed del modelo estándar? Corre entre 2 y 3 veces más rápido, pensado para interacciones en tiempo real, aunque Moonshot AI no publicó benchmarks propios para esa variante. ¿Cómo se compara el modelo de Moonshot AI con Claude Opus 5.5? Queda apenas detrás en Terminal-Bench 4.0 (65,7% frente a 66,4%) y en BenchCAD (92,7% frente a 96,2%), una diferencia de menos de un punto en el primer caso. ¿Puede Kimi K3.1 usarse para modelado 3D? Sí: con BenchCAD anota 92,7% con herramientas y puede escribir scripts para Blender y software CAD sin conectores MCP, además de generar modelos paramétricos. Referencias - Kimi (blog oficial): anuncio original de Kimi K3.1 Pro con benchmarks y disponibilidad.- GitHub de Moonshot AI: repositorios oficiales de la familia de modelos Kimi.- Hugging Face: Moonshot AI: organización oficial donde se publican los pesos abiertos de los modelos Kimi. 📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

推論基盤の「公開の境界」に地政学を読む — DeepSeek・OpenAI・Moonshot の結合の置き場所 DeepSeek の推論エンジン DeepInfer の公開をきっかけに、フロンティアモデルの推論エンジンと、それを取り巻くサービス基盤を調べました。すると、どれも純粋に性能や技術の理想形を追った形ではなく、想像以上に地政学を映した結果になっていそうだと感じるようになりました。 象徴的なのは、DeepSeek が KV キャッシュと負荷分散を「社内インフラと密結合している」として出さなかったことです。この記事では DeepSeek・OpenAI・Moonshot を「結合をどこに置いたか」という同じ物差しで並べ、各社の境界の引き方から、その読み方を探ります。次のリリースや技術ブログを見たときに、境界がどこにあり、なぜそこなのかを読むための手がかりになれば幸いです。 ! 本文は公開資料（リポジトリ、公式ブログ、論文、報道）だけを材料にしています。各社が明言していない読みには「推測」と書きました。報道の数字には媒体と日付を添えています。 DeepInfer が外した層は、コードに跡が残っている DeepInfer は 2026-10-20 に公開されました。対象は DeepSeek-V4.1-Flash のオフライン推論だけで、NVIDIA SM100（Blackwell 世代の GPU）と Huawei Ascend 950 に対応します。README は "not included in this release" として、KV キャッシュのシステム、P/D 分離（入力を読む段と出力を作る段を別の機械で動かす方式。エンジン側は大半が実装済み）、データ並列（DP）レプリカ間の負荷分散の 3 つを挙げています。 理由は同梱の Q&A 文書にあります。KV キャッシュ管理と負荷分散の部品が "tightly coupled to our internal infrastructure" なので、まだ全部は出せない、という説明です。 空の「仮想関数」として残る穴 外した層は、穴として残っています。deepinfer/engine/llm_engine.py の L800〜858 に、コメント「这里开始都是虚函数」（ここから仮想関数）で囲まれた空実装のメソッドが並びます。 llm_engine.py L800-858（本体はすべて空実装） init_pd_split() 初始化 PD 分离需要的数据结构 do_save_kvcache() 保存 kvcache, pre_sampler_sync 时调用 send_processed_prompts() 把已经处理完的 prompt sequence 发送给 completion engine ... 呼び出し側は公開コードにあり、decode・prefill・PROMPT エンジンの各段から呼ばれます。中身を書くのは社内のサブクラスだろう、というのが私の推測です。 ほかにも跡があります。 KV を保存・復元する関数（select_state_slice_to_store など）は tests からしか呼ばれない deep_cluster/ の中身は、ノード内のハード検出と NUMA バインド（CPU とメモリの割り当て）だけ KV の照合・取得・転送は、公開エンジンの外側にあります。 出したものと、出さなかったもの 出した部品 出さなかった層 FlashMLA / DeepEP / DeepGEMM（vendor/ に同梱） KV キャッシュのシステム（3FS の上で照合・TTL（保持期限）・削除を担う層） C++ スケジューラ、EPLB（自前実装） P/D 間の転送路と上位の振り分け TileLang カーネル（CUDA と Ascend の 2 系統） DP レプリカ間の負荷分散 3FS（2025-02 公開。コードからは参照しない） 自動伸縮・障害時の再構成 3FS は DeepSeek の分散ファイルシステム、EP はエキスパート並列（MoE のエキスパートを GPU に分けて置く方式）、EPLB はその負荷を均す配置の仕組みです。部品も社内と同一ではなく、公開版 FlashMLA は decode カーネルが社内版より 5〜10% 遅いと Q&A にあります。 2025 年に挙げた 3 つの理由 DeepSeek は 2025-04-14 にも、推論エンジン全体の公開を見送っていました。理由は次の 3 つです。 1 年以上前の vLLM フォークを元にしていて、乖離が大きい "including cluster management tools" を含む社内基盤と結合している 大きな OSS を保守する余力がない 2026 年版はエンジン単体に切り出して出しました。今回出せた理由の説明は見当たりません。境界は固定でもなく、Q&A は今後の推論コードも DeepInfer で継続して公開すると書いています。 外した層は、計算資源の不足を運用で吸収する層に見える DeepSeek は計算資源の制約への対策を運用層に集め、そこが社内インフラとの結合点になった、というのが私の読みです。 制約はチップの禁輸 制約の出どころは米国の輸出規制です。2022-10 の規制で NVIDIA は対中版の H800 を出しましたが、2023-10 の改定で H800 も対象になりました。2025-04 には H20 にも許可が要ると通知され（NVIDIA の 8-K）、2025-12 に H200 の販売を認める方針が出ています。 創業者も 2024-07 に、問題は資金ではなくチップの禁輸だと語っています（ChinaTalk の英訳）。 制約はモデルと運用の両方に出ている V3 の技術報告（2024-12）では、学習は H800 2,048 枚です。NVLink（160 GB/s）と IB（50 GB/s）の帯域差を踏まえ、各 token の送り先を最大 4 ノードに制限しました。 運用側にも似た発想が見えます（2025-03-01 の推論システム概要）。 全サービスが H800。昼は全ノードで推論し、夜は縮めて研究と学習に回す ピークは 278 ノード、平均は 226.75 ノード 24 時間の入力 token のうち 56.3% が、ディスク上の KV キャッシュに命中 文書は配分の理由を禁輸とは書いておらず、限られた台数を時間で使い回す工夫と読むのは私の推測です。 ディスクの KV は 2024-08 に料金表にも現れ、キャッシュ命中は最大 90% 安くなりました。 2026 年の Q&A では KV 専用の 3FS が約 100 PiB あり、冗長化は 10+2 の消失訂正符号（データ 10 に検査用 2 を足す方式）です。2024 年の論文のミラー構成（20 PiB 超）とは用途の違う別クラスタなので、単純には比べられません。 容量コストへの対策だろう、というのは推測です。 停止時の KV ごとの移送や故障時の再構成も、Q&A にはあってもコードにはありません。 部品は出し、運用層は残した カーネル、通信、EP、スケジューラ、3FS といった部品は公開され、その上で台数・配置・料金・TTL を決める運用層は残りました。 もう一つの仮説です。DeepInfer は NVIDIA と Ascend 950 の両方で動き、Q&A の設計目標の 1 つ目も「複数ベンダーのチップ」です。 そのためにハード依存の部分をカーネルに閉じ込め、運用層から切り離す必要があったことが、エンジンを切り出す圧力になったと推測します。「国産チップのために公開した」とは DeepSeek は言っていません。 閉じた層に乗るのは、計算資源の希少さ 制約は価格にも出ています。2026-04-24 の V4 の発表で DeepSeek は、高性能な計算資源が足りず V4-Pro の処理量に限りがあり、Ascend 950 の超節点が量産されれば大幅に値下げすると述べました（財聯社の引用による）。2026-08 にはピークとオフピークで料金を分けています。 ただ、運用層を閉じるのは DeepSeek に限りません。地政学が決めているのは閉じるかどうかではなく、閉じた層に何が埋め込まれるかで、DeepSeek ではそれが計算資源の希少さだと私は読んでいます。 OpenAI は逆に、結合を一か所に集めた OpenAI も運用層は出していません。逆なのは結合の置き方で、ハードの層の結合はほどき、状態と制御の層に集めました。 Habitat: 負債と知りつつ一か所に寄せる OpenAI の社内ストレージ基盤 Habitat は、約 40 地域、毎秒 7,000 万件超、500PB 超の規模です（2026-09-11 の記事）。 始まりは DevDay 2023 の、単一の DB につながる Python クライアントライブラリでした。のちにサービスに集約し、アクセス制御・監査ログ・ストレージへのアクセス制限を一か所で効かせられるようにしています。これを本人たちは戦略的に引き受ける技術的負債と呼んでいます。 ChatGPT の DB も、単一プライマリの PostgreSQL と約 50 のリードレプリカです（2026-01-22）。Habitat の背後は Azure Cosmos DB、PostgreSQL も Azure の管理サービスで、状態の層の足場はまだ Microsoft の上にあります。 ハード層は多重化して広げた チップの調達先は、DeepSeek と同じく複数ベンダーに広げました。学習と推論の大部分はなお NVIDIA だとしつつ（2026-03）、AMD（6GW）、Broadcom（自社設計 10GW と推論チップ Jalapeño）、AWS Trainium（2GW、GeekWire）、Cerebras（750MW、TechCrunch）と組んでいます。 Microsoft の独占も、優先交渉権への後退（2025-01）、その廃止（2025-10-28）、全製品を任意のクラウドで提供可（2026-04-27）の 3 段階でほどけました。 提供サービスの線は「状態を持つか」で引かれたように見える 2026-02-27 の共同声明で、Azure は「stateless な OpenAI API」の独占クラウドのままとされました。同じ時期に Amazon とは、Bedrock 上で記憶や権限を保持する「stateful runtime」を作ると報じられています（InfoWorld、2026-02）。 契約の線が状態を持つ層かどうかで引かれた、というのが私の読みです。2026-04 の改定後もこの線が残るかは、Microsoft のブログ本文からは確認できませんでした。 顧客と政府の要件も、状態と制御の層に集まります。 データの所在地: 2026-01-16 から ChatGPT Enterprise などで米国か欧州の地域内で推論 ゼロデータ保持（ZDR）: /v1/files など状態を持つエンドポイントは対象外 FedRAMP 20x Moderate（米連邦政府向けクラウドの認証、2026-04-27） 国防総省との合意（2026-02-28）: cloud-only で、安全の仕組みは OpenAI が自社で運用 出しているのは、重み（gpt-oss、2025-08）と運用記事と障害報告です。配信・安全・ストレージのスタックは出しておらず、境界の説明も見つかりませんでした。状態と制御の層こそ売っている部分なので出さない、というのが私の推測です。 制御面については、OpenAI 自身が政策の側から求めてもいます。2025-03 の OSTP（米大統領府の科学技術政策局）への意見書で、米国が最も優遇する国々（輸出規則の Tier I）のデータセンターに、Tier I の国に本社を置く企業による支配と、運用への不正アクセスの防止を求めました。これは OpenAI の提案で、課された条件ではありません。 何を出せるかも契約で縛られています。2025-10 の Microsoft との契約では、オープンウェイトの公開に能力基準（中身は非公開）が付きました。輸出・政府販売・提携の三方から、制御面を手元に置く動機が重なっている、と私は読んでいます（推測）。 OpenAI の閉じた層に埋め込まれているのは、所在地と統制の要件です。 Mooncake は、結合部分そのものを外に出した Moonshot（Kimi の開発元）の Mooncake は、DeepSeek が残した層のうち、KV の転送・保存・索引を公開しています。 Transfer Engine（2024-11-28）: RDMA などで KV を運ぶ転送層 Mooncake Store（2025-03-07）: 分散 KV キャッシュのプール Conductor（2026-09〜）: cache-aware なルータ（KV が残っているエンジンへ要求を回す）が使う KV インデクサ 2024-11 の公開時から、大モデル時代のストレージの「标准接口」（標準インタフェース）と参考実装を目標に掲げていました（量子位、2024-11-28）。その後 vLLM・SGLang・TensorRT-LLM・Dynamo・llm-d にコネクタが入り、2026-02-12 に PyTorch Ecosystem に加わっています。 担い手は Moonshot だけではない 2024-11 の公開は、清華大学の研究室と Moonshot が主導する産学の共同開源でした。 MAINTAINERS.md の codeowner 4 人は Alibaba Cloud の 2 人と清華系の 9#AISoft・趋境科技の 2 人で、Moonshot 所属はいません。git 履歴の社用メールでも Alibaba 259 件、tencent.com 114 件に対し、moonshot.cn は 2 件です（全 2,480 件。個人メールが大半）。 Alibaba は Moonshot の大口株主で（2024 年時点で約 36%、SCMP の報道）、Tencent も 2024-08 の調達に参加しました（Bloomberg）。どちらもクラウドを売る側で、Alibaba の tair-kvcache と Tencent の FlexKV は Mooncake に対応しています。標準になれば自社クラウドの得になる、というのは推測です。 契約と測定は、後から足した押さえ 公開の理由と商流の押さえは、時期が違います。コードを出した 2024-11〜2025-03 に見える理由は、共同開発・標準狙い・株主のクラウドです。商流の押さえは、その後に足されました。その後も KV インデクサ（Conductor、2026-09〜）の公開は続いていて、出すものと押さえるものを並行させている形です。 測定（2025-09〜）: Vendor Verifier は、Fireworks や Together などの第三者 API のスコアを公式と並べて公開する 契約（2026-07）: Kimi K3 License は、12 か月の売上が 2,000 万ドルを超える MaaS 事業者（モデルを API で提供する事業者）に、商用利用の前に別契約を求める ブログには "Weights are open. The knowledge to run them correctly must be too." とあります。運用の知識は開き、品質と商流はライセンスと検証で押さえる形です（推測）。 Moonshot では地政学の影は薄く見えます。国務院の「人工智能+」の意見（2025-08）は開源を奨励していますが、Mooncake の公開はそれより前で、政策が後押しした証拠は見つかりませんでした。 置き場所を決めるのは、お金と責任の流れ ラボ 結合の置き場所 出したもの 出さないもの 乗るお金と責任（推測） DeepSeek 運用層（KV・負荷分散・伸縮） カーネル、通信、エンジン単体 KV システム、P/D、DP 負荷分散 キャッシュ命中の料金、ピーク料金、処理量の上限 OpenAI 状態と制御の層 重み（gpt-oss）、運用記事、障害報告 配信・安全・ストレージのスタック クラウド契約、データ所在地、FedRAMP、政府契約 Moonshot 契約と測定（公開の後に追加） 転送・KV ストア・KV インデクサ（2024-11〜） 本番との差分（同じかは不明） MaaS の売上条項、提供品質の検証 どの社も、お金と責任が乗る層は手元に残しているように読めます（Moonshot は運用層を出した後に、契約と測定を足しました）。乗るものの中身には地政学が入り込み、DeepSeek では計算資源の希少さが料金と処理量に、OpenAI では所在地と統制の要件が契約に表れています（推測）。 DeepSeek は 2026-06〜07 に初の外部資金を受け、7 月 15 日の登記変更で国家人工智能产业投资基金が直接の株主になりました（財聯社、2026-07-15）。持分は約 0.28% と小さく、これだけで国家の関与が強いとは言えません。上場の準備も報じられています（Reuters 経由の The Star、2026-10-22）。 時系列だけ確かめておくと、2025-04 の見送りは外部資金の前、DeepInfer の公開は外部資金の後で上場準備の最中です。資金が公開の判断を左右したことを示す材料はありません。 一方、2026-09-10 の発表では "2,000 GPUs + a storage cluster? Let's talk." と呼びかけています。運用層は全員には出さず、規模のある相手とは個別に組む道を残している、と読んでいます（推測）。 業務システムの密結合は業務要件から生まれます。AI 基盤の密結合は、モデルとハードの事情から生まれる面が大きいように見えます。そう考えると、結合の位置がチップと料金の事情に引っ張られるのも自然です（推測）。 まとめ 公開の境界は秘密主義の度合いではなく、結合をどこに置いたかという設計の結果として読める DeepSeek は運用層に、OpenAI は状態と制御の層に結合を置いた。Moonshot は運用層を共同体で出し、後から契約と測定を足した その置き場所は、お金と責任が乗る層に重なる 地政学が効くのは閉じるかどうかより、閉じた層に何が埋め込まれるか（DeepSeek は計算資源の希少さ、OpenAI は所在地と統制の要件） 次のリリースや技術ブログでは、次の 5 つを確かめてみてください。 どの層が欠けているか、前回から動いたか（README の「含まれないもの」の欄） フックや設定の跡はあるか（空実装、外から注入する口、tests からしか呼ばれない関数） 誰が保守しているか（MAINTAINERS、コミットのメールドメイン） ライセンスと測定で何を押さえているか（売上条項、認定パートナー、検証ツール） 閉じた層にどの制約・要件が乗っているか（チップの調達、データの所在地、政府との契約） 今回出せた理由、出さない層の意図、地政学の効き方の解釈は、各社の明言ではなく私の推測です。 参考リンク DeepSeek DeepInfer（README） DeepInfer の Q&A 文書（doc/inference_deployment_qa.md） llm_engine.py（仮想関数の箇所） The Path to Open-Sourcing the DeepSeek Inference Engine（2025-04-14） Day 6: V3/R1 Inference System Overview（2025-03-01） DeepSeek-V3 Technical Report Fire-Flyer AI-HPC（SC24） Context Caching on Disk（2024-08-02） 財聯社（2026-04-24、V4-Pro の処理量の制約と値下げの条件） V4-Pro の GA とピーク・オフピーク料金（2026-08-13） V4.1-Flash の発表（2026-09-10） NVIDIA 8-K（2025-04、H20 の輸出許可） ChinaTalk: DeepSeek CEO インタビュー英訳（2024-11-27） 財聯社（2026-07-15、株主の変更） The Star / Reuters（2026-10-22、追加調達と上場準備） OpenAI 10 億人超の ChatGPT ユーザーを支えるオンラインストレージの急速な拡張（Habitat、2026-09-11） PostgreSQL を拡張して 8 億人の ChatGPT ユーザーに対応（2026-01-22） OpenAI raises $122 billion（2026-03-31） OpenAI and Broadcom unveil inference chip（2026-06-24） AMD and OpenAI（2025-10-06） Microsoft: The next chapter of the Microsoft–OpenAI partnership（2025-10-28） Microsoft and OpenAI joint statement（2026-02-27） The next phase of the Microsoft–OpenAI partnership（2026-04-27） InfoWorld: OpenAI launches stateful AI on AWS（2026-02） Your data（データの所在地と ZDR） Introducing data residency in Europe（2026-01-16 の追記） OpenAI available at FedRAMP Moderate（2026-04-27） Our agreement with the Department of War（2026-02-28） OpenAI の OSTP への意見書（AI Action Plan、2025-03-13、PDF） gpt-oss Moonshot / Mooncake Mooncake（README） Mooncake MAINTAINERS.md Mooncake 論文（arXiv 2407.00079） 量子位: Mooncake の共同開源（2024-11-28） Kimi K3 License Kimi-Vendor-Verifier Kimi Vendor Verifier（ブログ） SCMP: Alibaba の Moonshot 持分 BNN Bloomberg: Tencent が Moonshot の調達に参加（2024-08-05） Alibaba tair-kvcache（Mooncake をストレージに使える） 国務院「人工智能+」行動の意見（2025-08-26）

post-training 時代の LLM 学習の規模と効率の整理 はじめに にゃーん。 ! この記事は、post-training の時代に LLM の学習がどのくらいの規模と計算効率で行われているのかに個人的に興味があり、主に自分向けに整理したものです。私は超大規模な事前学習も事後学習も自分で回したことがなく、その規模の実体験としてのデータは持っていません。この記事の数字は、公開された技術報告の値と、そこから式で計算した試算だけでできています。どの数字がどちらなのかは、そのつど書きます。 AWS の 3 人の著者が Hugging Face に書いた「Building Blocks for Foundation Model Training and Inference on AWS」は、基盤モデルの学習と推論に要る部品を、下の層から順に整理したブログです。以下、このブログを Building Blocks と呼びます。Building Blocks は冒頭で、NVIDIA のスケーリング則が 1 本から 3 本に増えたという整理を「one to three scaling laws」と紹介し、LLM の性能は事前学習だけでなく、SFT や RL による post-training と、推論時の計算量でも伸びると書いています。AWS で学習と推論を動かすためのインスタンス、ネットワーク、ストレージ、クラスタの管理、ソフトウェアの構成も、Building Blocks に幅広く整理されています。Building Blocks で扱っている内容は、この記事では改めて解説しません。Building Blocks は網羅的かつ過不足なくまとまっているので、読んで前提知識をそろえてから本記事を読み進めてください。 スケーリング則が 1 本から 3 本になった中で、最近の LLM の学習が、どのくらいの規模 (GPU の枚数と GPU 時間)、どのくらいの MFU (Model FLOPs Utilization、GPU のピーク性能のうちモデルの計算に使えた割合)、どのくらいのトークン数で行われているのかを、この記事では公開された資料から整理します。ここでの学習には、RL の中で回答を生成する推論も含めます。公開された GPU 時間は GPU の世代がばらばらなので、世代の違いをそろえて比べる考え方も合わせて整理します。最後に、post-training では GPU だけでなく CPU も重要になっていることを整理します。扱う問いは次の 5 つです。 最近の LLM の事前学習は、何トークンで行われているか 事前学習は、どのくらいの MFU で動いているか post-training はどのくらいの規模と効率で動くのか 世代の違う GPU の値は、どうそろえて比べるか agentic な RL では、どのくらいの CPU が要るか 集計に使ったデータとスクリプトは GitHub に置いてあり、記事の数値とグラフはそこから再現できます。 3 本のスケーリング則 事前学習では、パラメータ数 N とトークン数 D を増やすと損失が下がります。この関係は Kaplan ら と Chinchilla の論文が示しました。事前学習の計算量の数え方も Kaplan らの論文にあり、1 トークンあたり約 6N FLOP として、学習全体の計算量を、1 batch のトークン数と step 数を掛けて 6N \times (\text{1 batch のトークン数}) \times (\text{step 数}) と書いています。1 batch のトークン数と step 数の積が学習したトークン数 D にあたるので、C \approx 6ND FLOP になります。Chinchilla の論文も同じ近似を使っています。 計算量が 6ND になる理由 重みの行列 W を入力 x に掛ける y = Wx では、重み 1 つにつき掛け算と足し算を 1 回ずつ行うので、1 トークンあたり 2N FLOP かかります。これが forward の分です。 backward では、同じ大きさの行列積を 2 回行います。1 回は前の層へ勾配を返すための \partial L / \partial x = W^\top \, \partial L / \partial y で、もう 1 回は重みの勾配を求める \partial L / \partial W = \partial L / \partial y \, x^\top です。どちらも 2N FLOP なので、backward は 4N FLOP になります。 合わせて 1 トークンあたり 2N + 4N = 6N FLOP で、D トークンを学習すると 6ND FLOP です。この数え方には、系列長に比例して増える attention の QK^\top と重み付き和の計算、embedding の参照、正規化などが入っていません。全層の activation を recompute すると forward をもう 1 回行うので、GPU が実際に実行する計算は約 8ND に増えます。MFU は 6ND のようなモデルの計算量を分子に、GPU の実行時間とピーク性能を分母にして数える効率で、recompute の分まで含めて数える効率は HFU (Hardware FLOPs Utilization) と呼んで区別します。 post-training には、お手本の回答で学ぶ教師ありの微調整（SFT）と、生成した回答への報酬で重みを更新する RL があります。post-training で性能を伸ばすために増やすのは、SFT に使うデータの量と、RL に使う計算量です。推論時の計算量で性能を伸ばすために増やすのは、1 つの回答に使うトークン数や、並列に作って比べる回答の本数です。Building Blocks は、3 つの伸ばし方の違いは、主に GPU にかかる負荷の形とスケジューリングだとしています。図の中段の concurrency は、HBM に KV キャッシュを置いて並行して生成できる系列 (リクエスト) の数のことで、本文では同時生成数と呼びます。推論エンジンが一度にまとめて処理する系列の数、つまりバッチの大きさの上限にあたります。問い 3 の節で回答が伸びると同時生成数が減ることに触れ、問い 4 の節で世代による同時生成数の違いを計算します。 最近の LLM の事前学習は、何トークンで行われているか この節は問い 1 を扱います。 上の図は、一次資料から集めた 155 のモデルと、Epoch AI のデータベースのモデルか、アーキテクチャが dense か MoE か不明なモデルの 81 を、総パラメータ数と事前学習のトークン数で並べたものです。縦軸に添えた容量の目安は、1 トークンを約 4 バイトのテキストとして換算した参考値で、言語とトークナイザーで変わります。一次資料の 155 モデルを総パラメータの大きさで分けると、事前学習のトークン数は次のとおりです。 総パラメータ モデル数 中央値 四分位の範囲 2025 年以降のモデルの中央値 10B 未満 60 6.0T 2.5〜11T 5.0T、14 モデル 10〜100B 54 8.2T 2.1〜15T 12T、19 モデル 100B 以上 41 20T 12〜29T 24T、19 モデル 一次資料の 155 モデルのうちリリースの年が記録されている 103 モデルで分けると、事前学習のトークン数の中央値は、2023 年の 1.45T、2024 年の 4.5T、2025 年の 13T、2026 年の 24.4T と、前年の 1.9〜3.1 倍ずつ増えています。事前学習のデータは、ウェブなどから集めた生のデータから、重複した文書、品質の低い文書、対象外の言語の文書を取り除いて作ります。この記事でいうフィルタ後のテキストは、こうして取り除いたあとの、学習に使うと決めたテキストのことです。トークン数をテキストの容量に直すには、1 トークンが平均で何バイトの文字にあたるかを掛けます。英語の文章では 1 トークンがおよそ 4 バイトにあたり、この値は言語とトークナイザーで変わります。総パラメータ 100B 以上の中央値の 20T トークンに 4 バイトを掛けると、約 80 TB です。これは学習で読んだ延べの量で、同じデータを複数回読んだ分も含むので、フィルタ後のテキストの大きさはこれ以下です。取り除く前の生のデータの大きさは、延べの量からは決まりませんが、たとえば FineWeb は、Common Crawl の 96 回分の収集データを絞り込んで 15T トークンのデータセットを作っています。学習データが PB の規模だと言われるのは、この絞り込む前のデータを指す場合です。 1 トークンの計算に使うパラメータを active パラメータと呼びます。MoE では選ばれた expert に加えて attention など毎回使う層の分も数え、dense では総パラメータと同じです。2025 年以降のモデルのうち active パラメータがわかる 48 モデルでは、active パラメータあたりの事前学習のトークン数の中央値は 745 で、Chinchilla の論文が dense のモデルで計算量に対して最適とした 1 パラメータあたり約 20 トークンの約 37 倍です。Llama 3 は 8B から 405B まで約 15T トークンで学習しており、論文は推論の費用を考えて小さなモデルを最適な量より長く学習したと明言しています。 最適な量より長く学習すると、同じ損失に届くまでの計算量は、最適な配分で学習した場合より多くかかります。Besiroglu らが Chinchilla の損失の当てはめ式を推定し直した式を使い、一次資料の dense の 68 モデルについて、実際に使った計算量と、当てはめ式が予測する同じ損失に最適な配分で届く計算量を比べました。モデルごとに求めたこの比は、中央値で 2.6 倍、四分位の範囲で 1.6〜4.1 倍で、68 モデルのうち 65 モデルは、同じ計算量で最適になる大きさよりモデルが小さい側にありました。この倍率は、モデルを最適より小さくした代わりに、事前学習で多く払っている計算量の目安です。当てはめ式は Chinchilla の論文の学習データで求めたものなので、学習データやアーキテクチャの違う最近のモデルでは、損失そのものではなく配分のずれの目安として読みます。 パラメータあたりのトークン数が増える一方で、MoE のモデルでは、総パラメータのうち 1 トークンの計算に使う割合の年ごとの中央値が下がっています。事前学習のトークン数を公開している一次資料の MoE のモデルで、active パラメータを総パラメータで割った値の中央値は、2024 年の 24.2 % (5 モデル、四分位の範囲 13.4〜24.6 %)、2025 年の 9.7 % (12 モデル、5.1〜16.2 %)、2026 年の 5.5 % (14 モデル、4.6〜10.0 %) です。トークン数を公開していないモデルは入っていません。2024 年は 5 モデルだけで、2025 年と 2026 年の四分位の範囲も重なるので、確かに言えるのは、active の割合が 1 割を切る MoE が増えたことまでです。active パラメータの数え方は、embedding を含めるかどうかなどでモデルごとに少し違います。 事前学習は、どのくらいの MFU で動いているか この節は問い 2 を扱います。 事前学習の 1 step は、系列長やバッチの構成を変えない同じ段階の中では、ほぼ同じ形の計算です。並列化の構成、dtype、recompute の範囲、系列長、バッチの大きさを決めて学習が安定すれば、step 時間はあまり動きません。そのため、事前学習に要る GPU 時間 H は次の式で概算できます。 H = \frac{6 N_\text{active} D}{3600 \cdot P \cdot \text{MFU} \cdot A} P は GPU 1 枚のピーク性能で、単位は FLOP/s です。本来の P は、学習が行列積に使う精度のピークで、FP8 で学習するなら FP8 のピークを使います。ただ、MFU を報告している論文の多くが bf16 の dense のピークを分母にしているので、この記事では公開値と比べられるように、P を bf16 の dense のピークにそろえて扱います。dense は、データシートの見出しにある 2:4 の構造化 sparsity を使った場合の値ではない、という意味です。MFU は、学習が動いている間に、6ND のようなモデルの計算量を基準として、GPU が理論ピークのうち学習の計算に使えた割合です。A は、GPU を確保していた全体の時間のうち、故障からの復旧や checkpoint の保存で止まった時間を除いた、学習が進んでいた時間の割合です。GPU の時間単価が同じなら、MFU や A が下がった分だけ事前学習の費用が増えます。たとえば MFU が 35 % から 34 % に 1 ポイント落ちると、H は 35/34 倍、つまり 2.9 % 増えます。Llama 3 の 405B の事前学習を分析した 54 日間の期間に 466 回の中断があり、A は 90 % を超えたと報告されています。Blackwell 世代でも、GB300 を 6,144 枚使った Reflection AI の Beam は、学習が進んだ時間の割合が学習の終盤に 92.3 % に達したと報告しており、世代による大きな差は公開値からは見えません。学習を運用するチームが、step 時間、実効の TFLOP/s から求めた MFU、計算と重ならない通信、中断と再開の時間を常に監視するのは、どれもこの式の分母を直接動かすからです。 公開された値からも、事前学習の効率を逆算できます。上の図は、H100、H800、H200 で学習し、トークン数と GPU 時間の両方を公開している 21 のモデルを並べたものです。PFLOP/s は 1 秒間に何千兆回の計算ができるかを表す単位で、1 PFLOP/s は 1 秒に 10^{15} 回です。H100 は bf16 の行列積を最大で 1 秒に約 989.5 兆回、つまり 0.9895 PFLOP/s 計算できます。H800 と H200 は H100 と同じ Hopper 世代のチップで、メモリや GPU 間の接続は違いますが、行列積の最大の速さは同じなので、3 つとも 0.9895 PFLOP/s として扱います。図の破線は、GPU がこの最大の速さの 10 %、20 %、40 % で計算し続けたとしたら、横軸の計算量を終えるのに何 GPU 時間かかるかを引いた線です。たとえば DeepSeek-V3 の計算量 6 N_\text{active} D = 6 \times 37\text{B} \times 14.8\text{T} \approx 3.3 \times 10^{24} FLOP は、最大の速さの 40 % で計算し続けると約 231 万 GPU 時間、20 % なら約 461 万 GPU 時間かかります。報告値の 266 万 GPU 時間はその間にあるので、点は 20 % と 40 % の破線の間、約 35 % の位置に描かれます。点が上の破線に近いほど、同じ計算量に多くの GPU 時間を使った、つまり効率が低かったことを表します。21 モデルの 6 N_\text{active} D を GPU 時間と bf16 ピークで割った値は、中央値 23.9 %、四分位の範囲 14.9〜26.5 % でした。この値は attention の計算量を含まないので、attention を含めて数えた報告 MFU より低めに出ます。また、報告された GPU 時間が中断を含む場合は、\text{MFU} \cdot A に対応する分だけさらに低めに出ます。 MFU を直接報告した大規模な事前学習の値は、21 モデルの逆算値の中央値 23.9 % より高く並びます。H100 で bf16 の例では、Llama 3 の 405B が 38〜43 %、Nemotron-4 340B が H100 を 1,536 枚から 6,144 枚へ増やす間に 42.4 % から 41.0 % でした。MegaScale は、Ampere 世代の GPU のクラスタで 175B の dense のモデルを 12,288 枚で学習し、MFU 55.2 % を報告しています。MoE では、ERNIE 4.5 が最大のモデルの事前学習で MFU 47 % を報告していますが、FP8 の混合精度で学習しており、MFU の分母の dtype は書かれていません。MegaScale-MoE は 352B の MoE を H800 の 1,440 枚で学習し、MFU 27.9〜32.5 % でした。 MFU は、FLOP の数え方と分母の dtype で値が大きく変わります。DeepSeek-V3 は 37B / 671B のモデルを 14.8T トークンで、H800 の 2,664K GPU 時間で学習しました。この値から 6 N_\text{active} D を bf16 のピークで割ると 34.6 % ですが、DeepSeek-V3 は行列積の大半を FP8 で計算しているので、FP8 のピークで割ると 17.3 % です。attention の計算量も小さくなく、GLM-4.5-Air の 46 層、96 ヘッドの形では、causal mask で半分だけ数えても、系列長 4K で 6N_\text{active} の約 2 割、32K では 6N_\text{active} の 1.5 倍になります。 自分たちの環境で MFU を実測しておくと、GPU 時間と費用を上の式で見積もれるようになります。また、世代の違う GPU に移るときの見積もりにも使えます。問い 4 の節で扱うように、新しい世代でどれだけ速くなるかは、演算、HBM の帯域、通信のどれに時間を使っているかで決まります。今の世代で MFU と step 時間の内訳を測っておけば、ピーク性能の比だけで見積もるよりも根拠のある GPU 時間を出せます。学習中に MFU が下がったときは、設定の誤りや調子の悪いノードに早く気づく手がかりにもなります。 post-training はどのくらいの規模と効率で動くのか この節は問い 3 を扱います。 計算量の規模 post-training に使った GPU 時間や費用が、事前学習の GPU 時間や費用に比べて誤差とは言えない大きさになった例が出ています。 次の表の GPU 時間には、報告値と、私が報告の枚数と期間から換算した値が混ざっています。報告値にも、学習に使った時間と、実験を含めてクラスタを確保していた時間の 2 種類があるので、値どうしを学習の計算量として直接は比べられません。 モデル 公開された内容 post-training の GPU 時間 報告か換算か 事前学習との比 DeepSeek-V3 post-training の GPU 時間 H800 で 5K 報告 事前学習の GPU 時間の 0.19 % DeepSeek-R1 R1-Zero と R1 の RL と、SFT のデータ作りを H800 の 512 枚で 約 147K 報告 V3 全体の GPU 時間の約 5 % DeepSeek-V3.2 post-training の計算の予算 未公開 報告 事前学習の費用の 10 % 超 Olmo 3 32B 32B の dense のモデルの RL を、Olmo 3.1 で H100 の 224 枚で 21 日追加 約 113K 換算 事前学習の GPU 時間の約 12 % MiniMax-M1 RL の全体を H800 の 512 枚で 3 週間 約 258K 換算 事前学習の GPU 時間は未公開 Llama-Nemotron Ultra 253B の dense のモデルの RL を H100 の 576 枚で 約 140K 報告 Llama 3.1 405B を元にしたモデル INTELLECT-3 GLM-4.5-Air を元に SFT と RL。H200 のクラスタ 512 枚を 2 か月確保 約 737K 換算 事前学習の GPU 時間は未公開 Reflection AI の Beam 501B / 23B のモデルの RL を GB300 の 1 万 500 枚で 4 週間 約 7.06M 換算 事前学習の 6,144 枚、4 週間未満を上回る post-training と事前学習の規模の比を出せるのは 5 例 (DeepSeek-V3、DeepSeek-R1、DeepSeek-V3.2、Olmo 3、Beam) で、比の定義は GPU 時間か費用か、報告値か換算値か、下限かが例ごとに違います。値は 0.19 %、約 5 %、10 % 超 (V3.2)、約 12 % (Olmo 3)、170 % 超 (Beam) でと、定義が違ううえに 3 桁にわたって散らばっています。DeepSeek の 3 つの報告 (V3 の 0.19 %、R1 の約 5 %、V3.2 の 10 % 超) は分子と分母の定義がそれぞれ違い、V3 の値は同じ base から作った R1 の RL を含まないので、ここから時間とともに増えたとは読めません。それでも、同じ組織の報告の中に、post-training の費用が事前学習の 1 割を超えた例が出ています。学習時間の報告値とクラスタの確保時間からの換算値を混ぜた上の図の 10 例では、RL の GPU 時間は中央値約 11 万 GPU 時間、範囲 3 千〜706 万 GPU 時間です。SFT のデータの量は、数十万から百万件の桁で、推論の能力を蒸留で移す例では DeepSeek-V3 が 150 万件、DeepSeek-R1 が約 80 万件、一般的な指示チューニングの例では Tülu 3 が約 94 万件です。ごく少量のデータで微調整する例には、LIMA や s1 のように 1,000 件程度のものもあります。 RL の計算量と性能の関係にも、スケーリング則が見つかりつつあります。The Art of Scaling Reinforcement Learning Compute for LLMs は 40 万 GPU 時間を超える実験で、RL の計算量と性能の関係がシグモイドの曲線に乗り、小さな実験から 10 万 GPU 時間の 1 本の学習の性能を外挿できたと報告しています。性能の到達点はレシピで決まり、損失の集計や正規化、カリキュラム、off-policy の方式は、主に到達までの効率を変えるとしています。この論文が示す RL の計算量と性能の曲線は、横軸が GB200 の GPU 時間なので、GPU の世代が変われば、1 GPU 時間でできる仕事の量も変わります。そのため、問い 4 の節で扱う世代のそろえ方がここでも要ります。 RL の時間の内訳 RL の 1 step には、性質の違う 2 つの主な仕事が入ります。rollout は、推論エンジンで回答を生成する仕事です。trainer は、回答に付いた報酬から勾配を計算して重みを更新する仕事です。trainer が更新した重みを rollout 側へ配る処理を、重み同期と呼びます。仕組みは「分散 RL post-training の通信プリミティブ入門」で図にしました。 rollout が RL の 1 step に占める割合は、計算量で数えた場合と時間で数えた場合で大きく違います。計算量で数えると、生成したトークンに対して、active パラメータを N として、rollout の 2N、trainer が学習の前に古い重みで確率を計算し直す 2N、学習の 6N がかかるので、rollout は計算量の約 20 % です。確率を計算し直さない構成では 2N + 6N のうちの 25 % になります。この数え方には、プロンプトの処理、attention、参照モデルや報酬モデルの計算が入っていません。INTELLECT-2 も学習と推論の FLOP の比を 4.5 倍と報告しており、rollout は計算量の約 18 % にあたります。 一方、時間で数えた rollout の割合は、上の図の実測の 10 の設定で中央値 68.5 %、範囲 22〜87 % でした。同期の方式では step の経過時間に対する割合、非同期の方式では処理ごとの時間の内訳で、分母はそろっていません。Seer は、Moonlight、Qwen2-VL-72B、Kimi-K2 の 3 つの RL の負荷で rollout が反復の時間の 63〜87 % を占めたと報告しています。短い回答の設定では、DistFlow が 31.8 %、比較の相手の verl が 21.9 % です。完全に非同期にした MiMo-V2.6 の Pro は、RL の時間を rollout 43.8 %、学習 43.5 %、採点 12.7 % と報告しています。図の白抜きの点は、rollout の時間比率について論文の導入部などにある一般的な記述や、その上限と下限です。decode は 1 回に各系列を 1 トークンずつしか進めないのに、その 1 回ごとに重みと KV を HBM から読み出すので、trainer の行列積と比べて計算量のわりに時間がかかります。 rollout の時間は、最後まで終わらない少数の長い回答にも引っ張られます。Seer は、メモリが厳しい負荷では、最後の 10 % のリクエストが rollout の時間の最大 50 % を使うと報告しています。さらに、回答の長さは学習の途中で伸びます。DeepSeek-R1 の報告では、R1-Zero の回答の平均長は RL の進行とともに伸び続けました。回答が伸びれば rollout と trainer の処理はどちらも増え、KV が膨らんで同時に置ける系列が減るので、rollout の割合は増えやすくなります。事前学習の時間の内訳が構成でほぼ決まるのに対し、RL の時間の内訳は、回答の長さという学習中の方策の振る舞いでも動きます。 RL の MFU と GPU の枚数 私が調べた RL のシステム論文と技術報告の 21 本には、RL 全体の MFU の値がありませんでした。推論側だけの実測なら Olmo 3 にあり、A100 の 2 ノードを学習 1 ノード、推論 1 ノードに分けた小さなベンチマークの推論側で、MFU が 1.01 %、HBM 帯域の利用率が 43.2 % でした。この測定では、演算のピークに対する利用率は低くても、HBM の帯域の利用率はそれより高くなっています。Olmo 3 の本番の 32B の RL は、推論に H100 の 20 ノード、学習に 8 ノードを使い、学習側は時間の 75 % を rollout のデータを待って過ごしたと書いています。 RL に使う GPU の枚数は、事前学習と比べて少ない例も多い例もあります。事前学習と RL の両方の枚数を公開している 4 例で、RL と事前学習の枚数の比は中央値 0.41、範囲 0.22〜1.71 でした。DeepSeek は事前学習が 2,048 枚、R1 の RL が 512 枚で、Olmo 3 は事前学習が最大 1,024 枚、RL が 224 枚です。Arcee AI の Trinity Large Thinking は、事前学習は Trinity Large と共通の B300 の 2,048 枚で、SFT と RL の post-training は H100 の 1,152 枚です。Beam は事前学習が 6,144 枚、RL が 1 万 500 枚です。推論と学習の GPU の配分は、AReaL で 75 対 25、INTELLECT-3 で 44 対 16 ノード、Olmo 3 で 20 対 8 ノードと、推論側を 2.5〜3 倍にする例が並びます。同じモデルの RL を、事前学習と同じ枚数で回した場合と少ない枚数で回した場合とで、学習の期間や到達する性能を比べた公開値は見つかりませんでした。 世代の違う GPU の値は、どうそろえて比べるか この節は問い 4 を扱います。 実効倍率と移送係数 公開された GPU 時間は、H100、H800、H200、B200、GB300 など、さまざまな世代の GPU で測られています。世代の違う値を比べたり、ある世代の値から別の世代の GPU 時間を見積もったりするには、新しい世代の GPU 1 枚が古い世代の GPU 1 枚の何倍の仕事をするかを表す実効倍率 S が要ります。S は、古い世代の step 時間を、演算・HBM 帯域・通信・待ちなど何に律速されているかで区分 i に分け、その割合を f_i、それぞれの区分が新しい世代で何倍速くなるかを r_i として合成します。 上の図は、H200 の 1 step の時間を 100 として、その中身を演算 60、メモリの読み出し 25、ノード間の通信 10、待ち 5 に分けた例です。B200 では演算が 2.27 倍速くなるので 60 が 26 に、メモリの読み出しは 1.60 倍速くなるので 25 が 16 に縮みますが、通信と待ちは速くならないので 10 と 5 のままです。合計は 57 で、新しい世代ではソフトウェアがまだこなれていない分を 0.95 として割ると 60 になります。つまり B200 は H200 の 100 ÷ 60 = 1.66 倍速く、これが S です。カタログのピーク比 2.27 倍のうち実際に生きる割合は 1.66 ÷ 2.27 = 0.73 で、これが k です。H200 で 100 万 GPU 時間かかった学習は、B200 では 100 万 ÷ 1.66 で約 60 万 GPU 時間になります。同じ計算を式で書くと次のとおりです。 S = \frac{\eta}{\sum_i f_i / r_i}, \qquad k = \frac{S}{r_\text{peak}}, \qquad H_\text{新} = \frac{H_\text{旧}}{S} = \frac{H_\text{旧}}{r_\text{peak} \cdot k} この式は、処理の一部だけが速くなったときの全体の速さを表すアムダールの法則を、区分ごとの倍率に広げた形です。\eta は、古い世代と比べた新しい世代でのソフトウェアの成熟度で、根拠のない仮の値としてここでは 0.95 と置きます。r_\text{peak} は新しい世代と古い世代の bf16 dense のピーク性能の比で、k はそのピーク比のうち実際に生きる割合です。この記事では k を移送係数と呼びます。k = 1 ならピーク比どおりに速くなり、k が小さいほどピーク比から目減りします。k が 1 を超える場合は、ピーク比より速くなります。f_i の通信には、計算と重ならない分だけを入れます。演算が速くなると、古い世代で計算の裏に隠れていた通信が新しい世代では表に出るので、この点では、この式は楽観側に外れやすくなります。\eta は逆に悲観側に効く仮の値で、2 つのどちらがどれだけ大きいかは確かめていません。 NVIDIA のデータシートと P5、P6 の製品ページから、p5en.48xlarge の H200 と p6-b200.48xlarge の B200 を比べると次のようになります。 項目 H200 B200 B200 の H200 に対する比 bf16 dense のピーク 0.9895 PFLOP/s 2.25 PFLOP/s 2.27 HBM の容量、データシート 141 GB 180 GB 1.28 HBM の帯域 4.8 TB/s 7.7 TB/s 1.60 NVLink、GPU 1 枚あたり 900 GB/s 1.8 TB/s 2.0 EFA、1 台あたり 3,200 Gbps、第 3 世代 3,200 Gbps、EFAv4 1.0 B200 の演算は H200 の 2.27 倍になる一方で、HBM の帯域は 1.60 倍にとどまります。演算律速と帯域律速の境目になる算術強度は、ピーク値から計算すると H200 の 206 FLOP/byte から B200 の 292 FLOP/byte へ上がるので、同じ算術強度で動く区間は B200 のほうが帯域の制約を受けやすくなります。 p5en の 8 台、64 GPU の事前学習を p6-b200 に置き換える場合に、例として 4 通りの内訳を当てると次のようになります。各区間の倍率は、演算 2.27、HBM 1.60、ノード間通信 (EFA) 1.0、データの読み込みや同期などの待ち 1.0 と置き、ノード内の NVLink の通信は計算と重なるとみなして区間に入れていません。 p5en の step 時間の内訳 k 同じ期間で終えるのに要る B200 p6-b200 の台数 すべて演算律速 0.95 30 枚 4 演算 80 %、HBM 10 %、ノード間通信 5 %、待ち 5 % 0.81 35 枚 5 演算 60 %、HBM 25 %、ノード間通信 10 %、待ち 5 % 0.73 39 枚 5 演算 50 %、HBM 20 %、ノード間通信 25 %、待ち 5 % 0.65 44 枚 6 実測からも k を出せます。MLPerf Training v6.0 の結果の表で SXM 型の H200 と B200 を 16 枚どうしで比べると、B200 は H200 より Llama 3.1 8B の事前学習で 2.34 倍、Llama 2 70B の LoRA で 1.96 倍速く終わっています。NVIDIA の Megatron Bridge の性能表の 25.09 版の表では、FP8 の TFLOP/s/GPU が H100 から B200 で Llama 3.1 405B は 2.20 倍、DeepSeek-V3 は 1.74 倍です。DeepSeek-V3 は、H100 側が dropless、B200 側が tokendrop と、MoE の振り分けの設定が違う比較です。この 4 つをピーク比 2.27 (H100 と H200 は bf16 のピークが同じ) で割った k は、中央値 0.92、範囲 0.77〜1.03 でした。提出した会社、ソフトウェアの版、GPU の枚数がそれぞれ違う測定なので、目安として使います。 アーキテクチャと同時生成数 step 時間の内訳の割合 f_i と、区分ごとに新しい世代で何倍速くなるか r_i は、モデルのアーキテクチャにも左右されます。影響が大きいのは、MoE で 1 トークンが使う expert の割合と、attention が 1 トークンあたりに持つ KV キャッシュの大きさです。GQA と MLA は、通常の multi-head attention と比べて 1 トークンあたりに保持する KV を小さくする方式で、sliding window は直近の一定の長さだけを見る方式です。次の表は、各モデルの config から bf16 で計算した、全層の合計の KV の大きさです。 モデル 総 / active expert 数 / 選ぶ数 attention KV、1 トークン 32K トークンの 1 本 GLM-4.5-Air 106B / 12B 128 / 8 GQA、46 層 184 KiB 5.75 GiB gpt-oss-120b 117B / 5.1B 128 / 4 GQA、36 層の半分が sliding window 36 KiB、sliding window の層は除く 1.13 GiB DeepSeek-V3 671B / 37B 256 / 8 MLA、61 層 68.6 KiB 2.14 GiB Llama 3.1 70B 70B / 70B dense GQA、80 層 320 KiB 10.0 GiB MoE では、expert 1 つの行列積に流れるトークンは、層に入るトークン全体の「選ぶ数 / expert 数」に細ります。GLM-4.5-Air なら 8/128 = 1/16 なので、B200 の境目の 292 FLOP/byte に届くには、1 回の expert の行列積に約 292 トークン、MoE 層全体ではその 16 倍の約 4,700 トークンをまとめる必要があります。事前学習の大きな micro-batch なら約 4,700 トークンに近づけますが、rollout の decode では 1 回の forward で各系列が 1 トークンずつしか進みません。そのため、MoE 層に入るトークン数は同時に生成している系列の数とほぼ同じになり、後の表の同時生成数 (1 台 130〜590) ではまず届きません。そのため、decode が中心で同時生成数がこの程度という仮定では、rollout の expert の計算は帯域律速に近く、rollout の r_i は演算の比の 2.27 より帯域の比の 1.60 に近いと考えられます。prefill が多い局面や回答の短い負荷では、この見方は当てはまりません。 rollout の速さは、HBM に同時に置ける生成中の系列の数、この記事でいう同時生成数にも左右されます。GLM-4.5-Air の bf16 の重み約 212 GB を 1 台の 8 GPU に均等に分けて置き、1 台の HBM の 90 % から重みを引いた残りをすべて KV に使い、全系列が 32K トークンに達したとして計算すると、同時生成数は次のとおりです。HBM の容量は AWS の製品ページの 1 台あたりの値です。 1 台 KV に使える HBM bf16 の同時生成数 重みと KV を FP8 にした同時生成数 bf16 の同時生成数の H200 に対する比 p5en、H200 8 枚 803 GB 130 294 1.0 p6-b200、B200 8 枚 1,077 GB 174 383 1.34 p6-b300、B300 8 枚 1,718 GB 278 590 2.14 この同時生成数は、全系列が 32K トークンに達したときの少なめの値で、回答の長さがばらつく実際の負荷では、これより多くの系列を同時に置けます。同時生成数は HBM の容量から重みの分を引いた残りで決まり、上の表の計算では B200 の同時生成数は H200 の 1.34 倍です。decode の 1 step の速さは帯域の比の 1.60 倍に近づいても、同時に生成できる系列の数は 1.34 倍しか増えません。rollout の大部分の倍率を帯域の比の 1.60 か同時生成数の比の 1.34、遅い回答の裾の倍率を帯域の比の 1.60、確率の再計算と学習の倍率を 2.0、重み同期の倍率を 1.5、報酬と環境の倍率を 1.0 と置きます。RL の step 時間の内訳を rollout の大部分 45 %、遅い回答の裾 25 %、確率の再計算と学習 20 %、重み同期 5 %、報酬と環境 5 % とすると、RL の移送係数 k (ピーク比のうち実際に生きる割合) は 0.62〜0.67 で、事前学習の仮定の例の 0.65〜0.95 の下端と同じくらい、実測の中央値 0.92 よりは低めに出ます。RL の時間の内訳は学習中に動くので、この k は学習のどの時点の内訳を使うかでも変わります。 agentic な RL では、どのくらいの CPU が要るか この節は問い 5 を扱います。 agentic な RL では、GPU の外で動く環境の比重が増えています。RL の中でモデルがコードを実行し、ツールを呼び、テストを回すたびに、CPU の上のサンドボックスが結果を返すまで、その系列の生成は止まります。公開された 4 例では、サンドボックスと環境を同じ数として数え、Kimi K2 の「1 万を超える」を 1 万として数えると、同時に動かす数は中央値約 2.6 万、範囲 1 万〜17 万でした。Kimi K2 は Kubernetes の上で 1 万を超えるサンドボックスを同時に動かし、Qwen3-Coder は 2 万の環境、LongCat-Flash-Thinking-2601 は 3 万 2,000 の環境を並列に動かしたと報告しています。Reflection AI の Beam は、GB300 の 1 万 500 枚の RL で、同時に最大 17 万のサンドボックスを動かしました。どの例も、CPU のコア数と GPU の比は公開していません。近い開示として、DeepSeek-V4.1-Flash の技術報告は、サンドボックスを GPU の学習のノードの外に置き、1 ノードあたり 2,500 を超えるコンテナを動かせたと書いています。 サンドボックスの結果を他の系列の生成で隠せない場合、その待ち時間は GPU の効率を直接下げます。SkyRL-Agent は H100 の 16 枚で SWE の agent を学習し、回答の生成と環境の実行をまとめて待つ方式ではサンドボックスの初期化と報酬の計算の間に GPU の利用率が大きく落ち、生成と環境を流れ作業で重ねる方式では利用率が約 90 % で安定して 1.55 倍速くなったと報告しています。逆に、環境が GPU を待つ時間も長く、Kimi K3 は、サンドボックスを Firecracker の microVM (軽量の仮想マシン) として動かし、モデルの推論の結果を待つ時間がサンドボックスの寿命の最大 98 % になり得るので、その間はサンドボックスを一時停止して CPU とメモリを使わないようにしています。報酬の作り方でも CPU の量は変わり、SWE-RL はコードを実行せず、正解との差分の似ている度合いを報酬にして、サンドボックスを使わずに済ませています。 Firecracker は AWS が開発したオープンソースの仮想化技術で、Amazon EKS でも、ワーカーノードで Kata Containers を使うと、Pod を Firecracker の microVM として動かせます (AWS のブログ)。Firecracker は KVM の上で動くので、ノードにはベアメタルのインスタンスか、C8i や M8i のように入れ子の仮想化に対応したインスタンスを使います。agentic な RL では、GPU のノードで学習と推論を回しながら、CPU のノードで数万のサンドボックスを立ち上げ、止め、再開します。同じ Kubernetes のクラスタの中で、GPU と CPU に資源を柔軟に割り当てられることも、RL の時代には大事になっています。 CPU とサンドボックスの構成を変えずに GPU だけを新しい世代にしても、CPU の上の環境の時間は速くなりません。環境の処理が GPU の処理と重ならない場合、GPU の区間が縮むほど、RL の step 時間に占める環境の割合は大きくなります。 3 scaling raw の下での必要な学習リソース量の見積もり スケーリング則が 3 本になると、自社で学習を計画するときに見積もるものも増えます。事前学習の GPU に加えて、post-training の GPU、世代の違う GPU への換算、RL のサンドボックスを動かす CPU まで要ります。ここでは、ここまでに整理した公開値を仮の値として、この 4 つを順に見積もる手順を示します。値は自社のモデルと学習の条件に置き換えて使ってください。 ! この見積もりはあくまで私の調査と独自の整理に基づくもので、これが業界標準の考え方かどうかは正直知りません。 実際のプロジェクトでは、予算と GPU の確保が先に決まり、使える GPU の種類と台数、期間がそこで固定されることがよくあります。その場合は、学習に要る量から台数を出すのではなく、固定された資源から使える GPU 時間を逆算し、学習の計画をそこに収めます。ここでは、H200 の p5en.48xlarge を 16 台、1 年間確保していたプロジェクトを、予算を 1.2 倍にして B200 の p6-b200.48xlarge に移す場合を例に、この流れを追います。 前提 例に置く前提は次のとおりです。料金は米国西部 (オレゴン) の 2026 年 10 月 21 日時点のオンデマンド料金です。GPU は ODCR (オンデマンドキャパシティ予約) で 1 年間確保する想定で、ODCR は使っていない時間もオンデマンドと同じ料金がかかります。Savings Plans などの割引は入れていません。 記号 意味 値 T 期間 1 年、8,760 時間 N_\text{旧} これまでの p5en.48xlarge (H200 8 枚) の台数 16 台 p_\text{旧} p5en.48xlarge の 1 時間の料金 63.296 ドル \beta 新しい予算のこれまでの予算に対する倍率 1.2 p p6-b200.48xlarge (B200 8 枚) の 1 時間の料金 113.9328 ドル r_\text{peak} H100 または H200 から B200 へのピーク性能の比 2.27 k_\text{pre}、k_\text{RL} ピーク比のうち実際に生きる割合 (移送係数)。事前学習と、post-training 0.92、0.65 学習の中身には、計画と実績の両方が公開されている Olmo 3 の 32B を使います。Olmo 3 の論文は、1,024 枚の H100 のクラスタで、事前学習 (中間学習と長文脈の段階を含む) に約 47 日、SFT、DPO、RL の post-training に約 9 日かかったと報告しています。どちらも中断からの再開などを含む日数です。その後の Olmo 3.1 では、RL を 224 枚の H100 で 21 日追加しています。これを H100 の GPU 時間に直すと、事前学習が H_\text{pre} = 1{,}024 \times 47 \times 24 = 1{,}155{,}072、post-training が H_\text{post} = 1{,}024 \times 9 \times 24 + 224 \times 21 \times 24 = 334{,}080 です。事前学習のトークン数は D = 5.5\text{T} です。 予算から台数と GPU 時間を出す これまでの予算 B_\text{旧} と、新しい予算 B は次のとおりです。 B_\text{旧} = N_\text{旧} \cdot p_\text{旧} \cdot T = 16 \times 63.296 \times 8{,}760 \approx 887 \text{ 万ドル}, \qquad B = \beta \cdot B_\text{旧} \approx 1{,}065 \text{ 万ドル} この予算で 1 年間確保できる p6-b200.48xlarge の台数 N と、使える B200 の GPU 時間 H_\text{有} は次のとおりです。 N = \left\lfloor \frac{B}{p \cdot T} \right\rfloor = \lfloor 10.67 \rfloor = 10 \text{ 台}, \qquad H_\text{有} = 8 \cdot N \cdot T = 700{,}800 \text{ GPU 時間} 10 台の 1 年分の料金は約 998 万ドルで、予算の残りは約 66.5 万ドルです。この残りは、後で FSx for Lustre と RL の CPU に回します。 学習に要る GPU 時間を B200 に換算する Olmo 3 の H100 の GPU 時間を、問い 4 の章の式で B200 の GPU 時間に直します。事前学習は移送係数 k_\text{pre} = 0.92、post-training は RL の rollout が帯域と同時生成数に縛られることを見込んで k_\text{RL} = 0.65 を使います。0.92 は実測の中央値ですが、0.65 は問い 4 の章で仮の時間内訳から出した試算で、実測ではありません。RL の k は、自社の環境で測って置き換えるのが確実です。 H_\text{要} = \frac{H_\text{pre}}{r_\text{peak} \cdot k_\text{pre}} + \frac{H_\text{post}}{r_\text{peak} \cdot k_\text{RL}} = \frac{1{,}155{,}072}{2.27 \times 0.92} + \frac{334{,}080}{2.27 \times 0.65} \approx 553{,}000 + 226{,}000 = 779{,}000 必要な 78.0 万 GPU 時間に対して、使えるのは 70.1 万 GPU 時間なので、約 11 % 足りません。なお、これまでの p5en の 16 台の 1 年分は 112 万 H200 GPU 時間で、Olmo 3 の 149 万 H100 GPU 時間にはもともと約 25 % 届いていませんでした。予算を 1.2 倍にして B200 に移すと、事前学習に換算した計算の量は H200 のときの約 1.31 倍に増えますが、RL に換算すると k_\text{RL} が小さいので約 0.92 倍に減ります。post-training の比重が大きい計画ほど、世代を上げた効果は小さくなります。 足りない分を合わせる 足りない分の合わせ方には、計画の中身を変える方法と、同じ GPU 時間でこなせる仕事を増やす方法があります。実際のプロジェクトでは、実験や失敗したときのやり直しの分の余裕も要るので、その分だけ使える GPU 時間はさらに減ります。 合わせ方 計算 結果 事前学習のトークン数を減らす D' = D \times \dfrac{(H_\text{有} - 226{,}000) \times 2.27 \times 0.92}{H_\text{pre}} 5.5T → 約 4.7T 期間を延ばす H_\text{要} \div (8 \cdot N) 約 9,740 時間、約 1.11 年 台数を増やす \lceil H_\text{要} \div (8 \cdot T) \rceil 12 台、予算はこれまでの約 1.35 倍 ただし、予算と GPU の確保が先に決まっているプロジェクトでは、期間を延ばすことも台数を増やすことも、制約のためにできないことが多くあります。その場合は、トークン数に加えて、モデルの大きさ、post-training の段階や実験の回数、目標とする精度など、プロジェクトのスコープのほうで合わせます。 同じ GPU 時間でこなせる仕事を増やす技術的な改善も、当然あります。GPU 時間は MFU と稼働率 A の積に反比例するので、この例の約 11 % の不足は、MFU と A の積を約 11 % 上げれば埋まります。 改善 上がるもの カーネルのチューニング、FP8 など低い精度での計算、通信と計算の重ね合わせ MFU 障害の早期検知と、自動での再開 (auto resume) A 障害の起きる間隔に合わせたチェックポイントの間隔、学習を止めずに書く非同期のチェックポイント A 残りの予算で FSx と RL の CPU をまかなう GPU の残りの約 66.5 万ドルから、ストレージと RL の CPU を出します。FSx for Lustre は、事前学習のデータとチェックポイントを置く約 82 TiB を 250 MB/s/TiB で確保すると、1 年で約 21.2 万ドルです。残りは約 45.4 万ドルです。 RL で同時に動かすサンドボックスの数 M、必要な vCPU の数 V、CPU のインスタンスの台数 N_\text{CPU} は、次の式で見積もります。 M = s \cdot G_\text{RL}, \qquad V = M \cdot c, \qquad N_\text{CPU} = \left\lceil \frac{V}{v} \right\rceil G_\text{RL} は RL に使う GPU の枚数、s は GPU 1 枚あたりの同時のサンドボックスの数、c はサンドボックス 1 つあたりの vCPU、v は CPU のインスタンス 1 台あたりの vCPU です。s には、GPU の枚数と同時サンドボックスの最大数の両方を公開している Beam の 170{,}000 / 10{,}500 \approx 16 を、c には Terminal-Bench 2.0 がサンドボックス 1 つに割り当てる 8 vCPU を置きます。どちらも 1 例だけの値で、8 vCPU は RL ではなく評価のときの割り当てなので、桁を見るための仮の値です。 80 枚の B200 をすべて RL に使うと、M = 16 \times 80 = 1{,}280、V = 10{,}240 vCPU で、192 vCPU の c8i.48xlarge (1 時間 8.99616 ドル) が 54 台要ります。RL の期間は 226{,}000 \div 80 \approx 2{,}830 時間、約 118 日なので、CPU の料金は約 137 万ドルで、残りの予算の約 3 倍になります。Olmo 3 の RL は数学やコードの推論が中心で、Beam のような agentic な RL ほど多くのサンドボックスは使いませんが、agentic な RL を計画するなら、CPU の費用も GPU と同じ桁で予算に入れておく必要があります。 まとめ はじめにの 5 つの問いに、公開値の統計で答えます。 問い 答え 事前学習のトークン数 総パラメータ 100B 以上で中央値 20T。2025 年以降のモデルは active パラメータあたり中央値 745 トークンで、Chinchilla の目安の約 37 倍 事前学習の MFU H100、H800、H200 の 21 モデルの逆算値で中央値 23.9 % (attention と中断を含まないので低めに出る)。大規模な学習の報告値は dense で 38〜55 % post-training の規模 事前学習との比は定義の違う 5 例で 0.19 % から 170 % 超まで散らばる。RL の GPU 時間は中央値約 11 万。rollout は時間の中央値 68.5 % を占める 世代のそろえ方 ピーク比に移送係数 k を掛ける。H200 から B200 への実測の k は中央値 0.92 RL の CPU 同時のサンドボックスは中央値約 2.6 万。CPU と GPU の比の公開値はなく、仮の値の試算では CPU のインスタンスが GPU のインスタンスの 5 倍以上 AWS で学習と推論を動かす構成は、Building Blocks を見てください。 参考 Building Blocks for Foundation Model Training and Inference on AWS How Scaling Laws Drive Smarter, More Powerful AI Scaling Laws for Neural Language Models、Training Compute-Optimal Large Language Models The Llama 3 Herd of Models Chinchilla Scaling: A replication attempt DeepSeek-V3 Technical Report、DeepSeek-R1 Seer: Online Context Learning for Fast Synchronous LLM Reinforcement Learning The Art of Scaling Reinforcement Learning Compute for LLMs Amazon EC2 P6 インスタンス、Amazon EC2 P5 インスタンス この記事の集計のデータとスクリプト

@pankajkumar_dev Kimi Code CLI is another one to test: MoonshotAI/kimi-code . It uses Kimi Code login or a Moonshot API key. With your saved projects, compare one fixed task using the same acceptance tests and a spend cap before moving more work over.