只换后训练、不动权重结构，3T 级模型为什么能把分数整体抬高一档：Kimi K3.1 Pro 的 65.7%、1.40 TB 与那笔几乎没变的推理账单

除另行标注外，本文引用的外部事实与页面核验均以 2026-10-27（北京时间）为时点。文中凡出自官方博客、模型卡或 config.json 的数字一律标出来源编号；凡本文自己按公式算出来的数字一律标「本文自行推导」并写清假设与中间值。本文没有做端到端实测，也没有下载权重跑过：所有关于吞吐与显存的数字都是按公开常量复算的上界或量级，不是我在某张卡上测出来的。

一、先把三个数字摆在一起

2026 年 10 月 23 日，Moonshot AI 发布 Kimi K3.1 Pro。官方博客给出的三句话决定了这篇文章要算的三笔账 [1]：

• 能力侧：Terminal-Bench 4.0 上 65.7%，同一张对比表里 GPT-6 Astra 是 58.2%、Claude Opus 5.5 是 66.4%（对照分取自各家博客或官方榜单的最大值 [1]，不是同一场评测）——也就是比前者高 7.5 个百分点、比后者低 0.7 个百分点，属于「同一档」而不是「追赶中」。
• 结构侧：官方原话是「a post-trained version of Kimi K3, with substantially larger post-training compute」——也就是在 K3 之上再后训练，而不是换一个更大的网络。这跟过去两年「发更大的模型」的主线是两种不同的技术路线。注意官方没有公布 K3.1 Pro 自己的参数表，所以「结构没变大」是本文据这句话设的前提，不是官方给的数字。
• 可用侧：K3.1 Pro 与 K3.1 Pro Highspeed 当天上线产品与 API，完整权重承诺 2026 年 11 月 4 日前放出 [1]。

这三条放在一起，就出现了一个值得工程读者关心的问题：如果能力提升不再依赖更换网络结构，那么推理账单会不会跟着涨？

答案只能从公开可核的那一侧推：K3 的权重与 config.json 是 2026 年 7 月就开出来的 [2][3][4]。按它算，2.8T 总参数、每 token 只激活 104B（3.71% 是本文按 104B/2.8T 自算；2.8T 与 104B 出自模型卡 [3]），理想 4 bit 下的权重体积下界约 1.40 TB（本文自行推导，含微缩放开销约 1.49 TB，见 §六），1M 上下文里只有 24 层在随长度长 KV（本文自行推导约 29 GB/序列）。只要 K3.1 Pro 沿用 K3 的架构与量化配置（官方未公布其参数表，这是本文的前提），分数涨一档并不会让每 token 要搬的权重字节数（按 K3 推导约 52 GB/步，见 §七）跟着涨——「与 K3 相比没多」是这句话的比较对象。

这就是本文要讲清的事：能力是在哪一层被抬起来的，成本又是在哪一层被钉住的。

二、为什么现在值得看：热度不是「感觉热门」，是四条可点的信号

按本站的选题纪律，「热度」方向必须给出可核的热度依据，不能只写「最近很火」。这一轮的信号是四条：

1. 官方发布与时间承诺：官方博客落款时点 2026-10-23，同一天 K3.1 Pro 与 Highspeed 上线 Kimi.ai、Kimi Work、Kimi Code 与 Kimi API；完整权重承诺 2026-11-04 前放出 [1]。也就是说，接下来一周多，这件事会从「API 里的模型」变成「你能下载的 1.4 TB」——这是工程读者真正要动手的时刻。
2. 对照表可查：Terminal-Bench 4.0 的 65.7% 与两个闭源前沿模型并列出现在同一张表里，博客还写明评测用的是 Claude-Code harness、其余模型分数取自各自博客或官方榜单的最大值 [1]。这比「我们自评超过某某」要可核。
3. 前代同一周就开过权重：K3 博客写于 2026-07-16，承诺 7 月 27 日前放出权重 [2]；HF 仓库的模型卡与 config.json 至今可下载 [3][4]。K3.1 Pro 的后训练是「在上一次公开权重之上再训」，所以它的成本结构可以现在就按 K3 算，不必等 11 月。
4. 「只做后训练」本身是这次的传播点：多家第三方汇总在 10-23 之后两天内跟进（二手来源，仅作热度信号，本文不使用它们的任何数字断言）[9]。

一条反向的自查也必须写在前面：热度高不等于结论稳。本文所有能力侧结论都来自厂商自评，其中 Kimi Code Bench、Financial Modeling、Financial Research、Business Operation、Hallu Bench Hard、xdev-bench-hard 六个基准是内部基准，数据集不公开 [1]。它们能说明方向，不能当作第三方复现。

把时间线摆开看，「现在」这个时点其实是两件事的重叠（发布日本文按官方博客与多数媒体口径记 2026-10-23；部分第三方按页面元数据记 10-24，相差 1 天不影响本文任何计算）：

这条时间线解释了为什么今天能写「账本」：能算成本的那一半（基座架构与权重）三个多月前就公开了（博客 2026-07-16、权重 2026-07-27），能算能力的那一半（后训练结果）上周才公布。 大多数关于新模型的讨论只盯着后者，于是「分数涨了一档」容易被读成「机器要求也涨了一档」——而按公开权重核，后者并没有动。本文后面每一节都在拆这个错觉。

三、术语与符号表

三条必须写明的口径（写不清就会把「残差项」误读成「每 token 必算的权重」）：

• 本文把 2 个共享专家并入 $F$，因为官方写明它们与 16 个路由专家一起被激活 [2]，语言 token 每步都会过它们。
• $F$ 里还包含 attention、第 1 层稠密 FFN、词表与输出头、视觉塔等非路由部分。其中视觉塔只在有图像输入时才参与，embedding/输出头是按行查表与一次投影，不是整张矩阵逐 token 相乘——所以 $F$ 是「按 104B 激活口径反解出的残差项」，不等于「每 token 都完整算一遍的权重」。
• 反解还依赖三条假设：各路由专家参数等量、92 个 MoE 层都是 896 选 16、模型卡的 2.8T 与 104B 是近似值。任一条不成立，$F$ 与 $E$ 的拆分要重算（但总激活量 104B 不变）。

四、官方事实层：K3 的架构长什么样

先把能查的写清楚，后面所有推导都从这里出发。

架构层面的四处新东西（官方博客 [2]）：

• KDA（Kimi Delta Attention）：给「注意力随序列长度变贵」这个老问题换了一种增长方式——状态大小与序列长度无关。
• AttnRes（Attention Residuals）：残差不再是把各层表示一律累加，而是按需选择性取回；config.json 里对应的粒度参数是 attn_res_block_size = 12 [4]，即 93 层按 12 层一块组织。
• Stable LatentMoE：把 MoE 稀疏度拉到「896 选 16」；官方称这套结构改动与训练/数据配方一起，相对 K2 带来约 2.5 倍的整体扩展效率提升 [2]。
• 量化感知训练：从 SFT 阶段起就用 MXFP4 权重 + MXFP8 激活，目的是「广谱硬件兼容」[2]。这一条是本文后面算 1.4 TB 的前提。

config.json 里的硬数字（[4]，本轮实际下载核读）：

• 93 层，hidden 7168，词表 163840，最大位置 1048576（1M）。模型卡写明 K3 是原生多模态模型（文本 / 图像 / 视频同模型），因此 config.json 里另有一份 vision_config（含视觉塔与投影层）[3][4]。
• 896 个专家，每 token 选 16，共享专家 2，专家 FFN 维度 3072；first_k_dense_replace = 1（第 1 层是稠密 FFN）。
• 注意力是 MLA：96 头，q_lora_rank = 1536、kv_lora_rank = 512、qk_nope_head_dim = 128、qk_rope_head_dim = 64、v_head_dim = 128。
• 混合层：linear_attn_config 明确列出 full_attn_layers 共 24 层（4、8、……、92、93）与 kda_layers 共 69 层，两者相加正好 93。

部署层面的一条建议（[2]）：官方推荐把 K3 部署在 64 卡以上的超级节点上，理由有两句——一是训练侧为了压住大规模专家并行下的专家不均衡，用了「静态形状、关键路径无主机同步」的全平衡专家并行方法；二是「推理效率同样受益于更大的高带宽通信域」。另外官方提到，KDA 给常规前缀缓存带来新问题，他们已把对应实现贡献给 vLLM 社区，随模型一起放出。

训练侧的三条工程约束，为什么最后变成推理侧的三条建议。 官方在 K3 博客里提了三件事，初看都是训练细节，其实每一条都对应一个推理侧后果：

• 静态形状 + 关键路径无主机同步的专家并行：为了让 896 个专家在跨卡切分时不出现「谁多干活谁等」的抖动，训练侧把 batch 形状固定下来、把主机侧同步移出关键路径 [2]。推理侧对应的是「批大小可预期」——这也是为什么这类模型的服务实现偏爱固定批窗口而不是随意攒批。
• 专家并行规模越大，越依赖高带宽通信域：官方明确写「推理效率同样受益于更大的高带宽通信域」，并建议 64 卡以上超节点 [2]。换句话说，64 卡不是训出来的要求，是推出去的形状。
• 量化感知训练从 SFT 阶段就开始：权重从一开始就以 MXFP4 参与训练，而不是训完再压 [2]。这解释了为什么 4 bit 不是「为了省显存牺牲一点质量」的可选项——在 K3 这条线上，4 bit 是训练时的既定条件。

以上四组事实（架构改动、config.json 硬数字、部署建议、混合层结构）拼起来，就是本文的推理账本边界：权重下界 1.40 TB 是硬的，KV 只长 24 层是硬的，每 token 只碰 104B 是硬的。下面逐条算。

五、激活参数账：两个方程解出「常开」与「按需」

模型卡给了两个数：总参 2.8T、激活 104B [3]；config.json 给了 896 与 16 [4]。三者放在一起，可以反解出一个不太被讨论的量：每 token 必算的「常开」参数到底有多少。

先写分解式。设非路由残差项为 $F$、全部路由专家参数为 $E$，则：

$A = F + \frac{k}{N}\,E$

$P = F + E$

两式相减消掉 $E$，得到：

$F = \frac{A - sP}{1-s},\qquad s = \frac{k}{N} = \frac{16}{896} \approx 1.786\%$

代入 $A = 104\times10^{9}$、$P = 2.8\times10^{12}$、$s = 0.017857$：

$F \approx \frac{104\times10^{9} - 0.017857 \times 2.8\times10^{12}}{1 - 0.017857} \approx 55.0\times10^{9}$

于是路由专家总量 $E \approx 2.745\times10^{12}$，每 token 真正参与计算的专家部分约 $49.0\times10^{9}$。三个结果连起来读：

• 常开部分约 55B，只占总参的 1.96%；
• 每 token 激活 104B，占总参 3.71%；
• 「896 选 16」的稀疏率是 1.79%，但激活率是 3.71%——差出来的近 2 个百分点，就是 attention、第 1 层稠密 FFN、2 个共享专家、词表投影这些非路由部分（其中视觉塔只在有图像输入时才参与）。

这个差值本身是个判断工具：稀疏率越高的模型，激活率越不等于稀疏率。看到「896 选 16 所以只算 1.8%」就直接推成本，会漏掉接近一半的激活量。

六、权重体积：1.40 TB 是「多少张卡」的问题，不是「能不能跑」的问题

官方写明权重是 MXFP4 [2]，config.json 也带了压缩配置：format = mxfp4-pack-quantized、group_size = 32、scale_dtype = torch.uint8，并且有一份 ignore 列表把 self_attn、shared_experts、mlp 的各个投影、lm_head、vision_tower、mm_projector 排除在 4 bit 之外 [4]。这一条很关键：「全部参数都是 4 bit」不是真实配置，所以下面这个式子算出来的是理想化下界，不是权重文件的真实体积。

先把下界算出来：

$V_{\min} = P \cdot \frac{b_w}{8} = 2.8\times10^{12} \times 0.5\ \text{B} \approx 1.40\ \text{TB}$

对照：同样的参数用 BF16 存是 $2.8\times10^{12}\times2 = 5.60\ \text{TB}$。也就是说 4 bit 相对 BF16 把「必须同时驻留的字节」压到了约四分之一（减少约 75%）——这是 3T 级模型今天还能谈部署的前提，而不是一个可选优化。

再算两档修正：MXFP4 每 32 个权重存一个 1 字节的微缩放因子 [4]，按 payload 16 字节 + scale 1 字节计，体积放大 $17/16 = 1.0625$ 倍，得到 约 1.49 TB；如果 ignore 列表里那些层确实以更高位宽（例如 BF16 或 FP8）存放，真实体积会继续高于这个数——具体高多少，官方没有公布逐层量化表，本文不做猜测。所以正确读法是：1.40 TB 是下界，1.49 TB 是「只补 scale 开销」的修正值，真实文件只会更大。

按官方建议的 64 卡超节点均摊：

$\frac{V_{\min}}{64} \approx \frac{1.40\ \text{TB}}{64} \approx 21.9\ \text{GB/卡},\qquad \frac{1.49\ \text{TB}}{64} \approx 23.3\ \text{GB/卡}$

32 卡则是 43.8 GB/卡（只补 scale 后 46.6 GB/卡）。这两个数说明「64 卡」不是营销数字，而是权重之外还给 KV、激活、通信缓冲和冗余留出空间的余量选择：单看权重，80 GB 级别的加速器 18 张就装得下；但装得下不等于跑得动，因为下一节的搬运量还要叠加。

六·补：「扩展效率提升约 2.5 倍」这句该怎么读

K3 博客里有一句很容易被当成「便宜 2.5 倍」的话：结构改动与训练/数据配方一起，带来相对 K2 约 2.5 倍的整体扩展效率提升 [2]。这句话至少有三种读法，而官方没有给定义：

• 读法一（等效算力）：达到同样的损失，需要的训练算力是原来的 $1/2.5$。这是最常见的意思，也是唯一能直接换算成钱的读法。
• 读法二（等效损失）：同样的算力下，损失下降得更多。这个读法无法直接换算成本，因为「损失差一点」值多少钱取决于下游任务。
• 读法三（等效参数效率）：同样的损失，可以用更少参数——但 K3 反而从 K2 涨到 2.8T，所以这条在 K3 上不成立。

之所以要专门写一段，是因为这三种读法指向完全相反的成本结论：读法一会得出「训练更便宜」，读法三会得出「参数更省」，而实际发生的是「参数变多了、但每单位算力换到的能力更多」。如果把 2.5 误当成「推理便宜 2.5 倍」，那和本文算出来的「每 token 52 GB」直接冲突——扩展效率是训练侧概念，不进推理账单。这条界线在讨论任何「X 倍效率」时都适用。

七、每步搬运：decode 的账本在带宽，不在算力

大模型解码阶段，一个 token 只做一次前向，矩阵乘法的另一维是 1。这时算术强度极低，性能由「每一步必须读多少字节」决定。每步搬运量就是激活权重：

$B_{\text{step}} = A \cdot \frac{b_w}{8} = 104\times10^{9} \times 0.5\ \text{B} = 52\ \text{GB/步}$

再给聚合带宽 $B_{\text{agg}}$ 与并发批大小 $C$，解码吞吐的上界是：

$R \le \frac{C \cdot B_{\text{agg}}}{B_{\text{step}}}$

代入一个 8 卡、单卡 4.8 TB/s 量级的机器（$B_{\text{agg}} \approx 38.4\ \text{TB/s}$）：

• 单序列（$C=1$）：$R \le 38.4\times10^{12} / 52\times10^{9} \approx 738\ \text{tok/s}$——这是不计 KV 读取、不计通信、不计算力的乐观上界，实际远低于它。
• 批 256：$R \le 738 \times 256 \approx 189\text{k}\ \text{tok/s}$——因为同一份权重被整批共享，权重流量被摊薄。

还有一笔常被漏掉的账：专家并行下的通信量。896 个专家被切到 $D$ 张卡上后，一个 token 选中的 16 个专家大概率不在同一张卡，它的隐藏态要按路由结果被发到对应卡上再收回。设 hidden 维度 $d = 7168$、激活值位宽 $b_a = 1$ 字节（MXFP8 的 8 bit，官方口径 [2]），每 token 每层的跨卡收发量级是：

$B_{\text{comm}} \approx 2 \cdot k \cdot d \cdot b_a = 2 \times 16 \times 7168 \times 1\ \text{B} = 229{,}376\ \text{B} \approx 224\ \text{KiB}$

乘上 92 个 MoE 层（93 层减去 first_k_dense_replace = 1 指定的那层稠密 FFN [4]）得到 $229{,}376 \times 92 = 21{,}102{,}592\ \text{B}$，即约 21.1 MB/token（写成常见单位即 229,376 B ≈ 224 KiB/层、21.1 MB/全层；十进制，约 20.1 MiB）。这个量与 52 GB 的权重搬运相比小约三个数量级（$52\ \text{GB} / 21.1\ \text{MB} \approx 2{,}470$ 倍），但它是在卡间而不是卡内发生的——一旦通信域带宽不够，这 21.1 MB 就会变成等待时间。这就是「更大的超节点」那句话的真正含义。两处假设要说清：激活位宽取 MXFP8 的 8 bit（量化前的训练口径 [2]），实际跨卡搬运的位宽不必然等于它，所以这是指定位宽下的估算，不是实测流量。

这两个数放在一起就解释了为什么这类模型的成本结构是「吞吐靠并发、单流吃亏」：单用户对话的响应速度受限于一次搬运 52 GB 的物理下限，而 API 的单位 token 成本取决于能把多少请求塞进同一批。也因此，官方把「更大的高带宽通信域」写进部署建议——专家并行跨卡之后，每次路由都要把隐藏态跨卡收发到被选中专家所在的卡（权重本身是常驻不动的），通信域的大小直接决定这条路径的效率 [2]。

七·补：七个在讨论里反复出现的误算

这一节把评论区与转发里最常见的七个算法摆出来，逐个对一遍，因为它们直接影响你要不要为这类模型准备机器：

• 误算一：「896 选 16，所以只要 2% 的算力」。漏了 attention、稠密层、共享专家与词表投影，真实激活率是 3.71%（§五）。按 2% 估算，$2.8\text{T} \times 2\% = 56\text{B}$，只有真实激活量 104B 的约 54%（若按 1.79% 算则是约 50B、约 48%），也就是单 token 算力被低估了约 46%–52%，不是「差不多」。
• 误算二：「2.8T 参数，FP4 就是 1.4 TB，所以 8 张 80 GB 够」。权重装得下不等于跑得动：还要加 KV（1M 上下文下单序列 29 GB，BF16 假设）、激活、通信缓冲与专家并行的副本冗余，这也是官方建议 64 卡以上的原因 [2]。
• 误算三：「上下文越长越慢，所以 1M 只是营销」。decode 每步的权重搬运与长度无关（52 GB），随长度涨的只有 KV 读取与 prefill 算力；在 24 层全注意力的混合结构下，1M 的 KV 是 29 GB 而不是 112 GB（§八）。真正会卡住的是并发数，不是长度本身。
• 误算四：「1M 上下文就等于 1M 的 KV」。KV 只挂在 24 层全注意力层上；KDA 层的状态与长度无关（§八），所以「长度翻倍、缓存翻倍」只对那 24 层成立。
• 误算五：「前缀缓存命中就不用算」。命中的是同一个前缀；一旦改动系统指令或 effort 档位，命中区整体失效（§九），成本回到全额重算。
• 误算六：「量化只是省显存」。MXFP4 是从 SFT 阶段就参与的量化感知训练 [2]，它同时改变了每步要搬的字节数与所需的通信域规模——在 decode 阶段，位宽直接换吞吐。
• 误算七：「后训练让模型更强，所以部署需求也跟着涨」。后训练不改变网络结构（官方措辞是 post-trained version of K3）：在沿用 K3 结构的前提下，仍是 2.8T/104B、93 层、MXFP4。分数上移与显存需求是两条互不影响的线（§十、§十四）。

七个误算共享同一个病因：把「参数量」当成唯一的成本变量。真实的成本函数里，参数量只是第一项；激活率、KV 结构、量化位宽、并发策略每一项都能改变量级。

八、长上下文：69 层不随长度变贵，才是 1M 能卖的前提

如果 93 层全部是标准注意力，1M 上下文的缓存是不可承受的。K3 的做法是把 69 层换成 KDA（状态大小与长度无关），只留 24 层保留完整 KV [4]。

MLA 的每 token 缓存只需存压缩潜向量与 RoPE 部分，即 $d_c + d_r = 512 + 64 = 576$ 个元素：

$M_{\text{kv}}(T) = L_{\text{full}} \cdot (d_c + d_r) \cdot b_{kv} \cdot T$

取 $b_{kv} = 2$ 字节（BF16，本文假设；官方未公布缓存位宽）：

$M_{\text{kv}}(1) = 24 \times 576 \times 2 = 27{,}648\ \text{B} \approx 27.0\ \text{KiB/token}$

满 1M 上下文（$T = 1{,}048{,}576$）：

$M_{\text{kv}}(1\text{M}) \approx 27{,}648 \times 1{,}048{,}576 \approx 28.99\ \text{GB/序列}$

如果 93 层全用同一套 MLA：

$M_{\text{kv}}^{\text{all}}(1\text{M}) = M_{\text{kv}}(1\text{M}) \times \frac{93}{24} \approx 112.3\ \text{GB/序列}$

3.88 倍。这两个数字的差别不是「省一点内存」，而是「1M 上下文能不能同时服务多个请求」：29 GB 档还能在一台 8 卡机器（按 8 × 80 GB = 640 GB 计）上谈几条并发；112 GB 档则一条序列就超过一张 80 GB 卡的容量，占掉这台机器约 17.5% 的显存。这就是「KDA 换来的东西」最直接的量纲表达——它买的不是速度，是上下文长度的可服务性。

另外必须承认一处不清楚：KDA 层的状态是常数大小，但常数是多少、config.json 没有以「每层多少元素」的形式给出（只给了 head_dim = 128、num_heads = 96、short_conv_kernel_size = 4 这些结构参数）[4]。本文因此不给 KDA 状态的具体字节数，只给「与 $T$ 无关」这一条定性结论；把「常数」当作「很小」是另一回事，不该混算。

顺带解释一句官方说的「KDA 给常规前缀缓存带来新问题」：常规前缀缓存是按注意力层存 KV 块——前缀相同，KV 就相同，直接复用。KDA 这类线性注意力不存 KV，它存的是一个随序列更新的递推状态；前缀 8K 处的状态，不是「8K 个 KV 块」，而是「递推 8K 步之后的一个矩阵」。要在 KDA 层做前缀缓存，就得在可复用点上存状态快照，并在命中时把状态恢复回去。官方说这套实现已经贡献给 vLLM 社区，随模型一起放出 [2]——这也解释了为什么 K3 的 1M 上下文在开源推理栈里能落地：不解决状态快照，69 层 KDA 等于每轮从头递推。

九、前缀缓存与 reasoning_effort：一个会破缓存的可调档

K3 系列有两处与工程账单直接相关的机制，都能在官方文档里查到 [5]：

• 始终推理、保留式思考：K3 始终进行推理思考，且「保留式思考（Preserved Thinking）」始终开启，思考强度用顶层 reasoning_effort 调，三档 low / high / max，默认 max。
• 采样参数不可调：temperature 固定 1.0、top_p 固定 0.95、n 固定 1、presence_penalty / frequency_penalty 固定 0；传入其他值会报错。K3.1 Pro 与 K3.1 Pro Highspeed 的约束与 K3 完全一致 [5]。

文档还写了一句很容易被忽略、但对 agent 长时程任务很贵的话：切换 effort 档位会破坏前缀缓存命中，建议在会话开始前确定档位 [5]。

把它写成式子。设上下文长度 $T_{\text{ctx}}$、前缀缓存命中率 $h$、峰值算力 $F_{\text{peak}}$、每 token 前向算力约 $2A$，则一次 prefill 的时间近似：

$T_{\text{prefill}} \approx (1-h)\cdot \frac{2A\,T_{\text{ctx}}}{F_{\text{peak}}}$

$h=1$ 时理论上接近 0（只剩未命中部分与开销），$h=0$ 时全额重算。对「一个 codebase 反复问」这类 agent 场景，前半段稳定的系统指令、工具定义、仓库骨架几乎每次相同，$h$ 本来可以很高；而在中途从 max 调到 high（或反向），缓存整段失效，$h$ 归零一次。这条对账单的影响，可能比模型分数那 7.5 个百分点更直接。

九·补：一次 1M 上下文回合的成本怎么随长度变

把前面几节拼起来，就能回答一个实际的问题：同样一次请求，长度从 8K 加到 1M，账单是怎么变的？ prefill 与 decode 的成本曲线形状完全不同。

prefill 的算力随长度线性增长（忽略注意力里的二次项）：

$C_{\text{prefill}} \propto 2A\,(1-h)\,T_{\text{ctx}}$

decode 的权重搬运随长度不变（每步仍只碰 104B 激活权重），只有 KV 读取随长度线性增长：

$C_{\text{decode}} \propto A \cdot \frac{b_w}{8} + L_{\text{full}}(d_c+d_r)b_{kv}\,T_{\text{ctx}}$

代入本文的数字，三个长度档的量级对照就出来了：

这张表说明的是：短上下文时 decode 几乎全在搬权重（KV 可以忽略）；到 1M 时 KV 读取已经超过权重搬运的一半，成为第二个主项。 而如果 93 层都留完整 KV，1M 那一行的 KV / 权重比会变成 $112.3/52 \approx 2.16$——KV 反超权重，成为最大单项。这就是 §八 那个 3.88 倍在账单上的落点：它不是「省内存」，是把 1M 上下文的瓶颈从 KV 挪回权重。

一个必须说明的假设：上表按「理想 4 bit 激活权重 52 GB」与 BF16、单序列、无前缀缓存命中计算；52 GB 与 29 GB 都是量级，用于比较两项的相对大小，不是任何真实部署的实测读数。真实服务里并发与缓存命中会同时改变这两个数，表里的比值只用于说明「谁在长、谁不变」。

十、后训练为什么能整体抬分：形式化一下

官方对「怎么涨的」只给了方向，没给配方细节：K3.1 Pro 是 K3 的后训练版本，用了显著更大的后训练算力，为了在「数百个下游领域」上做大规模联合 RL，他们把整条栈都优化了一遍——RL 框架、长上下文推理、训练效率、沙箱基础设施、rollout 调度，以及一个共享的环境质量检查平台 [1]。

这句话的结构值得拆开看。策略侧的目标函数（GRPO 一类带裁剪与 KL 约束的做法，符号是通用形式，不是官方公布的实现）：

$J(\theta) = \mathbb{E}\left[\frac{1}{G}\sum_{i=1}^{G} \min\left(\rho_i(\theta)\hat{A}_i,\ \mathrm{clip}(\rho_i(\theta), 1-\epsilon, 1+\epsilon)\hat{A}_i\right) - \beta\, D_{\mathrm{KL}}\big(\pi_\theta \,\|\, \pi_{\text{ref}}\big)\right]$

其中 $\rho_i = \pi_\theta(o_i)/\pi_{\text{old}}(o_i)$ 是当前策略相对采样时行为策略的概率比（分母必须是产生这批样本的旧策略，不是 KL 项里的参考策略），$\hat A_i$ 是组内归一化的优势估计，$G$ 是同题采样数，$\pi_{\text{ref}}$ 只出现在 KL 约束里用于限制漂移。这条区分看起来是符号洁癖，实际是这类算法最常见的实现错误之一：把 $\pi_{\text{ref}}$ 写进比值，裁剪区间就失去意义。

这个式子对「为什么要几百个域」给出一个朴素解释：每个域提供一套可验证的奖励（跑通没跑通、测试过没测试过、表格对不对），策略在同一个参数集上同时被多套奖励塑形。域越多，可验证信号的覆盖越宽，越不容易只在一个分布上过拟合。这也是为什么官方强调「共享平台做环境质量检查」——环境本身有 bug 时，$\hat A_i$ 就是在奖励错误的行为。

再看分数为什么能「整体」动而不是「局部」动。对同一批任务做多次采样，通过率与采样数的关系是：

$\text{pass@}k = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}$

$n$ 是每题采样数，$c$ 是通过数。只要「有时能过」的概率从 $c/n$ 抬一点点，$k$ 次里至少过一次的概率就会被放大——这可能解释一个常见现象（此处是本文的解释性推测，不是官方结论）：后训练带来的提升，在允许重试的 agent 基准（Terminal-Bench 这类跑真实终端任务的）上比在一次成型的问答基准上更明显。pass@k 恒等式本身只描述采样与通过率的关系，不能单独证明提升来自哪里。官方报告里同一个模型在「长时程、多步、可重试」的基准上分数最整齐，也符合这条曲线。

十一、三个可核对的能力面

把官方给的数字按「可核程度」分开摆：

① 有对照、来源逐项写明的数字（含厂商自测与官方文档）

② 内部基准（只有官方数字，方向性证据）

• Kimi Code Bench 3.0 Long-horizon：61.2%，前代 K3 是 55.95%（本文自行算相对提升 9.4%）。
• 金融三件套：Financial Modeling 较 K3 +7.2 分；Financial Research +11.6 分；Business Operation 约为 K3 的 4.2 倍（这是相对前代的倍数，官方正文未给绝对值，不能读成高基数跃升）[1]。

③ 幻觉（这条最值得单独看）

官方在内部压力测试集 Kimi Hallu Bench Hard 上报告：claim 级幻觉率从 K3 的 23.4% 降到 8.3%；同时「至少包含一处事实错误的响应占比」是前代的 42.4% [1]。官方自己加了两条限定：这是针对易错场景构造的压力测试，比率不代表日常使用中的总体错误率 [1]。

请注意口径差别：23.4% → 8.3% 是 claim 级的绝对率，而 42.4% 是「响应级指标相对前代」的比值——它不等于「42.4% 的响应有错」，也不是一个绝对率。一个率、一个比，不能互相推。本文不把「8.3/23.4 ≈ 35.5%」当成 42.4% 的解释——它们是两个不同定义下的量。

把这三个数字放在一起读，能看出一个方向：后训练的收益不是「更会说话」，而是「更少给出没有依据的断言」。对金融、法务这类场景，8.3% 与 23.4% 的差别比 Terminal-Bench 那 7.5 个百分点更值钱——因为后者影响的是「能不能完成任务」，前者影响的是「完成的任务能不能签字」。但请注意官方的限定：这是压力集，构造时专门挑模型易错的场景 [1]，所以它衡量的是相对改善，不是绝对可靠性。

十二、反向证据：他们自己删掉了网络安全数据

这一节是全文最值得读的地方，因为它是一份厂商自己给出的负向对照。

官方在发布说明里承认：后训练规模上去之后，模型的漏洞研究能力随之上升；追查来源发现，网络安全相关内容既嵌在中训练语料里，也存在于 RL 环境组合里。于是他们在中训练与 RL 两个阶段都移除了相关数据，只保留通用编码任务 [1]。

结果是可量化的：在内部基准 xdev-bench-hard（以真实披露漏洞改造任务、pass@3 计分）上，没做这套数据移除的 checkpoint 解出 90.5%，最终发布的 K3.1 Pro 是 81.0% [1]。

$90.5\% - 81.0\% = 9.5\ \text{个百分点}$

官方给的解释是双面的：一方面「更强的通用编码与长时程调试能力会迁移到网络任务上」，所以哪怕删了数据，最终版仍比前代强；另一方面，他们明确把「不开源一个会推进网络能力绝对前沿的权重」写成发布原则 [1]。

对做工程的读者，这一段的含义不是「伦理讨论」，而是一份厂商自测的负向对照（xdev-bench-hard 是内部基准，无第三方复现）：在今天的训练栈里，某一类能力的强弱可以在数据与 RL 环境这两层被有意调节，并且调节量可以量化到 9.5 个百分点。反过来说，你在某个开源权重上量到的能力，是训练方一系列数据决策的结果，不是架构的必然产物。

十三、Highspeed 的「2–3 倍」：三种可能，官方都没说

官方对 K3.1 Pro Highspeed 的全部表述是：比 K3.1 Pro 快 2–3 倍，能力相同，与 K3.1 Pro 使用完全一致的参数约束 [1][5]。官方没有说明它靠什么变快。

工程上「同一模型 2–3 倍」通常落在三类手段里：

1. 服务侧：更高并行度、更激进的批调度、更大规模的专家并行副本，把每步的等待时间摊掉；
2. 数值与 kernel：更低的缓存位宽、融合 kernel、更高效的通信实现；
3. 解码策略：更短或更浅的思考路径（但这一条会改变输出分布，与「能力相同」的表述有张力）。

本文不对号入座。可核的只有两条：一是速度比是官方给的（2–3×），二是参数约束（temperature、top_p、n 固定等）与 K3.1 Pro 完全一致 [5]。要判断它到底改了哪一层，得等权重放出后看服务实现或自己做 A/B——现在下结论就是编。

把「2–3 倍」拆成可测的维度，能更清楚这条口径到底覆盖了什么：

表格里三格空着，恰好是三个最该问的问题。这也是「等权重放出」的价值所在：有了 1.4 TB 的权重和一份服务实现，前三行可以自己测；现在只能把官方口径当作上限描述来规划，不能当作容量承诺。

十四、给开发者的四件事：选型、采样、成本、门槛

① 什么时候值得换

按官方数据，K3.1 Pro 的强项集中在三类任务：长时程终端/编码 agent（Terminal-Bench 65.7%、Code Bench 长时程 61.2%）、3D 与参数化建模（BenchCAD 92.7% with tools）、金融表格与研究（OfficeQA Pro v2 64.4、内部金融三项全面提升）[1]。如果你的负载不在这三类里，「同一档」的模型之间差异会被你的 prompt 与工具设计盖过。

② 采样不可调，是把双刃剑

temperature 固定 1.0、top_p 固定 0.95、n 固定 1、penalties 固定 0 [5]，意味着传统「调低温度求稳」的手段在这条 API 上不存在。稳定输出只能靠三样东西：结构化输出约束、工具校验回环、以及重试——而重试的前提是任务可判定对错（这也是为什么这类模型最擅长的是有验证器的任务）。

③ 成本按「token 体积 × 缓存折扣」估，不要按「参数量」估

一次 agent 任务的 token 体积：

$N_{\text{tok}} = \sum_{i=1}^{S}\Big(T_{\text{ctx},i} + T_{\text{out},i}\Big)$

其中 $S$ 是步数。真正决定账单的是两项乘子：前缀缓存命中率 $h$（步间上下文大量重复时，$h$ 高，prefill 便宜）与输出/思考长度（默认 max 档会显著拉长 $T_{\text{out}}$）。这两项都在你手里，而模型参数量在厂商手里——所以优化顺序应该是：先定 effort 档（并整场不变，见 §九），再压缩上下文重复，最后才考虑换模型。

④ 自建的门槛是「多少张卡」，不是「有没有权重」

权重 2026-11-04 前放出 [1]，然后你要面对的是 1.40 TB 起的权重下界（理想 4 bit；含微缩放开销约 1.49 TB）与 21.9–23.3 GB/卡（64 卡）这几个数。再加上 1M 上下文下 29 GB/序列的 KV（BF16 假设），以及官方对 64 卡以上高带宽通信域的建议 [2]——自建的决策点是集群规模，不是单机显存。

十五、K3 与 K3.1 Pro 的对照

十五·补：四步自测，判断这篇的账跟你的负载有没有关系

这一步不是建议，是判据。按下面四问走一遍，就能知道 K3.1 Pro 这一档模型对你的实际影响：

第一问：你的任务有验证器吗？ 后训练抬分最明显的场景是「能判定对错」的任务——终端命令跑通没跑通、测试过没通过、表格公式对不对 [1]。如果你的任务没有客观判据（文案、审美、开放问答），后训练那部分收益在你身上会被判据缺失吃掉，剩下的差异主要是风格。

第二问：你的上下文里有多少是重复的？ 如果一次会话里同一份代码库或文档被反复带入，前缀缓存命中率 $h$ 高，prefill 便宜；此时 §九 那条「effort 档位整场不变」的价值最大。反过来，如果你的每次请求都是全新长文档，$h$ 接近 0，你会直接吃满 $2A T_{\text{ctx}}$ 的 prefill 成本。

第三问：你要单流还是吞吐？ 单流体验受限于每步 52 GB 的搬运下限（§七），这不是换模型能解决的；如果在意的是单位 token 成本，那要看厂商的批调度与专家并行规模，也就是官方说的「64 卡以上高带宽通信域」[2]。

第四问：你是用 API 还是要自建？ 用 API：温度与 top-p 全是固定值，稳定性只能靠结构化输出与重试；自建：先算 1.40 TB / 64 卡 = 21.9 GB 这一行，再算 29 GB/序列的 KV——两个数任何一个超预算，方案就不成立。

四问里如果有两问以上落在「否」，那么本文讨论的后训练增益与部署账本都不构成你换模型的理由；这时候真正值得看的是你自己的任务判据与上下文复用率，而不是 Terminal-Bench 那 7.5 个百分点。

十六、边界与未解

1. K3.1 Pro 自身的参数表没有公开。官方只说它是 K3 的后训练版本 [1]；本文所有体积、激活量、KV 计算都建立在「架构与 K3 相同」这个前提上。若后训练阶段改过层数或专家数，本文数字需重算。

2. KV 缓存位宽未公布。本文取 BF16 得 29 GB/序列；若按 FP8 则约 14.5 GB/序列。这个假设只影响绝对值，不影响 3.88 倍的层数比。

3. KDA 状态的常数大小未知。只确定了「与序列长度无关」，没有给字节数（§八）。把常数当 0 是错的。

4. 能力侧全部是厂商自评。六个内部基准不公开数据集；Terminal-Bench 的对比分数取自各模型博客或官方榜单的最大值，agent 壳不同（Claude-Code / Codex / Kimi Code）[1]。跨壳比较本身有噪声。

5. Highspeed 的实现方式未说明（§十三）。「2–3 倍」是厂商口径，本文没有独立复测。

6. 官方明确说幻觉数字来自压力测试集，不代表日常使用错误率 [1]。把 8.3% 当成「日常幻觉率」是误读。

7. 本文没有任何实测：1.40 TB、52 GB/步、738 tok/s、189k tok/s 都是按公开常量复算的上界或量级，且忽略了 KV 读取、跨卡通信与算力上限。真实系统只会更慢。

8. 逐层量化表未公布：config.json 只给了 ignore 列表与 group_size=32 [4]，没有说明被排除的 self_attn、shared_experts、mlp 投影、lm_head 各自以什么位宽存放，所以 1.40 TB 只是下界、1.49 TB 是只补微缩放开销的修正值，真实文件体积未知。

9. 幻觉数字有两套口径的说法未交叉核对：本轮核到的是博客的 23.4% → 8.3%（响应级 42.4%）[1]；有第三方指出 API 侧文档另给过一组不同数值，本文未能在一手页面确认这一点，故不并列引用，只把它列为此处未解。

10. 11-04 之后的权重是另一份文件：本文核的是 K3 的 config.json 与模型卡，不是 K3.1 Pro 的权重清单。放出后应逐一核对层数、专家数与量化格式。

11. 第三方数字一律未采用：搜索过程中出现的「3T 总参」「激活参数未公布」「Highspeed 配额约为 2 倍」等说法，本轮只在一手页面核到后两条中的第一条（官方确实未给 K3.1 Pro 参数表），其余两条本文不作断言、也不写进正文。

12. 「2.5 倍扩展效率」的定义官方未给（§六·补），本文只列三种可能读法并明确它不进推理账单；不据此推算任何训练成本。

13. 时间锚点：K3 博客的发布日 2026-07-16 与权重承诺日 2026-07-27 取自页面内文与页面元数据；K3.1 Pro 的 2026-10-23 与 2026-11-04 取自官方博客正文。本文的相对表述都给出锚点日期（「上周」= 2026-10-19 至 10-25 那一周；「三个多月前」= 2026-07-16 的架构与 2026-07-27 的权重），若你在更晚的日期读到本文，请以绝对日期为准。

十七、小结：四句可以带走的话

第一，这次升档的是能力，不是账单——前提是它沿用 K3 的结构。 官方把 K3.1 Pro 定义为 K3 的后训练版本，但没有公布 K3.1 Pro 的参数表；按 K3 的公开权重算，每 token 只碰 3.71% 的参数，理想 4 bit 下权重下界约 1.40 TB。这个「不变」是条件命题，不是官方数字。

第二，「896 选 16」不等于「只算 1.8%」。 用两个方程反解，常开部分约 55B、路由专家 2.745T，激活率 3.71% 是稀疏率的 2 倍多；拿稀疏率当成本系数会系统性低估。

第三，1M 上下文的可服务性来自 69/93 层不随长度变贵。 只有 24 层留完整 KV，1M 时约 29 GB/序列；若全层都留是 112 GB，差 3.88 倍。

第四，也是最实用的一条：可调的离散档位比采样参数更贵。 temperature/top_p 全是固定值，你唯一能调的 reasoning_effort 一旦中途切换就会清空前缀缓存——在会话开始前把档位定死，这是这篇文章里最省钱的一句话。措辞上要准确：官方写的是「破坏前缀缓存命中」[5]，不是「删掉缓存」——已缓存的内容未必被立即回收，但你不再命中它，账单按未命中算。

最后补一句方法论上的话：这篇稿子的所有数字分成三类——官方公布的（分数、参数、层数、档位约束）、本文按公开常量算的（体积、搬运量、缓存量、通信量）、官方没说的（Highspeed 实现、KDA 状态大小、KV 位宽）。第三类的正确写法是留白并注明，而不是拿一个「看起来合理」的数补上。如果你只带走一句话：在 3T 级开源模型这条线上，能力已经可以在不改变推理形状的前提下被后训练推动，而决定你能不能自建的那几个数（1.40 TB、21.9 GB/卡、29 GB/序列）反而比分数更早定格。

flowchart TD
    A["Kimi K3 基座<br/>2.8T 总参 / 104B 激活"] --> B["后训练阶段<br/>数百下游域联合 RL"]
    B --> C["K3.1 Pro 权重<br/>架构不变"]
    C --> D["API 服务<br/>kimi-k3.1-pro"]
    C --> E["Highspeed 服务<br/>官方称 2–3x 速"]
    D --> F["1M 上下文<br/>69 层 KDA + 24 层 MLA"]
    F --> G["每序列 KV 约 29 GB<br/>BF16 假设"]
    C --> H["权重 2026-11-04 前放出<br/>MXFP4 约 1.40 TB"]
    H --> I["自建门槛<br/>64 卡均摊约 21.9 GB/卡"]

这张图说明了什么：能力提升发生在后训练这一段（B），而部署成本的三个硬数字（KV 29 GB、权重 1.40 TB、每卡 21.9 GB）全部由基座架构决定（F、H、I）——两条链在「K3.1 Pro 权重」这个节点上分叉，互不影响。

flowchart LR
    subgraph TOK["单个 token 的一次前向"]
        X["hidden 7168"] --> Y1["24 层 MLA<br/>读 KV 缓存"]
        X --> Y2["69 层 KDA<br/>读常数状态"]
        Y1 --> Z["MoE 路由<br/>896 选 16 + 2 共享"]
        Y2 --> Z
        Z --> W["激活权重约 52 GB<br/>MXFP4"]
    end
    W --> V["聚合带宽 38.4 TB/s<br/>单流上界约 738 tok/s"]
    W --> U["批 256 共享同一份权重<br/>上界约 189k tok/s"]

这张图说明了什么：同一个 token 的计算路径分成「读 KV」（24 层，随长度长）与「读常数状态」（69 层，不随长度长）两支，最后都汇到 MoE 路由；而每步真正决定速度的是右下角那 52 GB 的激活权重搬运——单流吃亏、批发划算，成本结构由此决定。

flowchart TD
    R1["可验证任务环境<br/>沙箱 + 环境质量检查"] --> R2["rollout 采样<br/>每题 G 条"]
    R2 --> R3["奖励 / 验证器<br/>跑通与测试"]
    R3 --> R4["组内优势归一<br/>裁剪 + KL 约束"]
    R4 --> R5["策略更新"]
    R5 --> R2
    R1 --> S1["数据决策<br/>如移除网络安全语料"]
    S1 --> S2["能力分布改变<br/>xdev 90.5% 到 81.0%"]

这张图说明了什么：后训练是一个「环境—采样—验证—更新」的闭环（R1–R5），而能力上限不只由这个环决定——最左边那个数据决策（S1）可以单独把某一类能力拉低 9.5 个百分点，这是厂商自己给出的负向对照。

📋 来源与核验记录

以下 URL 均于 2026-10-27（北京时间）本轮实际打开并核验（HTTP 200，内容与标题一致）：

1. Moonshot AI 官方技术博客《Kimi K3.1 Pro Tech Blog: Advancing Open Intelligence》，发布时点 2026-10-23：https://www.kimi.ai/blog/kimi-k3-1-pro —— 本文的能力侧数字（Terminal-Bench 4.0 65.7% / GPT-6 Astra 58.2% / Claude Opus 5.5 66.4%、Kimi Code Bench 3.0 Long-horizon 61.2% 与 K3 的 55.95%、BenchCAD 92.7% 与 96.2% / 95.9%、OfficeQA Pro v2 64.4、Financial Modeling +7.2、Financial Research +11.6、Business Operation 约 4.2 倍、Hallu Bench Hard 23.4% → 8.3% 与响应级 42.4%、xdev-bench-hard 90.5% → 81.0%、Highspeed 2–3 倍、权重 2026-11-04 前放出、默认 reasoning effort max 与 temperature 1.0 / top-p 0.95）全部出自此页正文与脚注。
2. Moonshot AI 官方技术博客《Kimi K3: Open Frontier Intelligence》，发布时点 2026-07-16，权重承诺 2026-07-27 前：https://www.kimi.com/blog/kimi-k3 —— 本文的结构侧事实（KDA、AttnRes、896 选 16 的 Stable LatentMoE、相对 K2 约 2.5 倍扩展效率、Quantile Balancing、Per-Head Muon、SiTU、Gated MLA、MXFP4 权重 + MXFP8 激活的量化感知训练、静态形状无主机同步的全平衡专家并行、建议 64 卡以上超节点、KDA 前缀缓存实现已贡献 vLLM）出自此页。
3. Hugging Face 模型卡（本轮实际下载 README.md 原文）：https://huggingface.co/moonshotai/Kimi-K3 —— 2.8T 总参、104B 激活、93 层、896 专家、16 选中、2 共享、1,048,576 上下文、Kimi K3 License 均出自此页表格。
4. Hugging Face 仓库配置（本轮实际下载 /raw/main/config.json）：https://huggingface.co/moonshotai/Kimi-K3/blob/main/config.json —— hidden_size=7168、num_hidden_layers=93、num_experts=896、num_experts_per_token=16、num_shared_experts=2、moe_intermediate_size=3072、intermediate_size=33792、q_lora_rank=1536、kv_lora_rank=512、qk_nope_head_dim=128、qk_rope_head_dim=64、v_head_dim=128、num_attention_heads=96、first_k_dense_replace=1、attn_res_block_size=12、max_position_embeddings=1048576，以及 linear_attn_config.full_attn_layers 共 24 层 / kda_layers 共 69 层的层号清单。
5. Kimi 开放平台文档《模型参数参考》（本轮实际打开，含 kimi-k3.1-pro 与 kimi-k3.1-pro-highspeed）：https://platform.kimi.com/docs/api/models-overview —— 1M 上下文、thinking 约束、reasoning_effort 三档（默认 max）、temperature 固定 1.0、top_p 固定 0.95、n 固定 1、penalties 固定 0，以及「切换档位会破坏前缀缓存命中，建议在会话开始前确定 effort 档位」均出自此页；该页同时写明 K3.1 Pro 与 Highspeed 的参数约束与 K3 完全一致。

热度信号（3、4 条用于证明「现在为什么值得看」，本文未使用它们的任何数字）

6. 官方博客脚注引用的 Terminal-Bench 4.0 官方榜单：https://www.tbench.ai/ （用于核对该基准的公开存在性，本文未逐项抓榜）。
7. 第三方汇总跟进（二手，仅作传播信号）：https://www.unite.ai/moonshot-ai-releases-kimi-k3-1-pro-first-model-in-new-k3-1-series/ 与 https://siliconangle.com/2026/10/23/moonshot-ai-launches-new-flagship-kim-k3-1-pro-model-with-3t-parameters/ 。

本文自行推导的数字（与官方数字分列，不混用）

上述推导对应的百分数在这里一次性列清（供核对，均为本文自算）：稀疏率 1.79%（同一个数的近似写法 1.8%）、常开参数占总参 1.96%、激活率 3.71%、§十一 的相对提升 9.4%；文中提到的 35.5% 只是 claim 级两个官方数字的比值（8.3 / 23.4），用来说明它不能拿去解释响应级的 42.4%，本身不是任何结论。

• 稀疏率 $s = 16/896 \approx 1.786\%$、常开参数 $F \approx 55.0\text{B}$、路由专家总量 $E \approx 2.745\text{T}$、按需专家部分 $\approx 49.0\text{B}$、激活率 $104/2800 \approx 3.71\%$（§五，输入为官方 2.8T/104B 与 config 的 896/16，假设 2 个共享专家计入常开项）。
• 权重体积 $2.8\times10^{12}\times0.5\,\text{B} \approx 1.40\ \text{TB}$、BF16 对照 5.60 TB、64 卡均摊 21.9 GB/卡、32 卡 43.8 GB/卡（§六）。
• 每步搬运 52 GB、单流上界约 738 tok/s、批 256 上界约 189k tok/s（§七，假设单卡 4.8 TB/s 量级、8 卡聚合 38.4 TB/s，忽略 KV 与通信）。
• §八「112 GB 占 8 卡机（8 × 80 GB = 640 GB）约 17.5%」的换算（本文按该机器规格假设）。
• 每 token KV 27,648 B ≈ 27.0 KiB、1M 上下文 28.99 GB/序列、全层 MLA 对照 112.3 GB、比值 3.88 倍（§八，假设 KV 为 BF16 2 字节）。
• Kimi Code Bench 3.0 Long-horizon 相对提升 $(61.2-55.95)/55.95 \approx 9.4\%$、Terminal-Bench 相对差 $(65.7-58.2)/58.2 \approx 12.9\%$（§十一）。
• xdev-bench-hard 差值 9.5 个百分点（§十二）。
• 量化口径修正带来的百分数：4 bit 相对 BF16 为 25%（即减少 75%）；若按 2% 稀疏率估算激活量，得到约 56B，仅为真实值 104B 的 54%（按 1.79% 则约 50B、48%），即低估约 46%–52%。
• §九·补 表格里的比值 0.4%、6.9%、55.8%（以及全层对照的约 2.16）：按 8K / 128K / 1M 三档长度、BF16 KV 与 52 GB 权重搬运量算得；21.1 MB/token 的跨卡通信量按 92 个 MoE 层、16 专家、hidden 7168、MXFP8 激活估算。

未核实项（如实列出）

• K3.1 Pro 与 K3.1 Pro Highspeed 的参数量、层数、专家数、量化格式官方尚未单独公布；本文全部按 K3 公开权重口径计算，没有下载任何权重文件。
• KV 缓存与 KDA 状态的实际位宽与每层状态字节数未公布；本文只做了「与序列长度无关」的定性结论与 BF16 假设下的绝对值。
• Highspeed 的加速实现方式未公布，§十三 的三种解释是可能性清单，不是结论。
• Terminal-Bench 4.0 与 BenchCAD 的对照分数取自各模型自己的博客或官方榜单最大值，agent 壳不同；本文未复跑任何基准。
• 本文的 738 tok/s 与 189k tok/s 是忽略 KV 读取、跨卡通信与算力上限的上界，不能当作任何真实部署的性能预期。