MoonshotAI

Kimi released its own TCS benchmark, TCSExam, yesterday, and the repo only has 7 stars so far. It has 100 tasks covering Lean proofs, solvers, constructions and open conjectures. MoonshotAI/TCSExam t.co

@chamath Chamath, do you want to try Kimi K3.1 pro in 8090 ? I lead inference pool efforts for this model @verdacloud inference. HW-SW codesigned for long context agentic inference MoonshotAI/Kimi-Vendor-Verifier t.co

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）