开放日：一次同时开放权重、技术报告与基建三件套
开放日当天，月之暗面把 Kimi K3 的模型权重、技术报告和三个基础设施仓库同时放了出来。我第一时间把权重拉下来，顺手把报告和仓库也一起克隆了，现场拆解会人坐得挺满，周围几位开发者没太关注台上讲了什么，都在低头翻刚公开的模型卡和配置文件。官方公布时间是 2026 年 7 月 27 日，选择这个日子相当于把整个训练家底一次性摊开。
现场气氛与其说在发布，不如说像一场技术复盘会，他们把家底翻出来摆在桌子上，就看你能不能看懂门道。权重落地同时给全技术报告，还公开支撑训练的底层基建，这种配置在大模型开源历史上并不多见，值得逐件看明白它到底是干什么用的。与多数只发权重的开源不同，这次连训练基础设施也一起给出来。
这篇想把我从开放日上带走的那套理解写出来，核心讲三件事：为什么一个 896 个专家的 MoE 只让 16 个干活，那个叫 KDA 的注意力机制到底在解决什么问题，以及如果你想本地跑起来，该先看哪几个文件、敲哪几条命令。我尽量把每条结论的出处写清楚，方便你把关。开放日不算新闻里最大的消息，但细看内容量是这两年开源里数一数二的。
有一个背景值得先交代：K3 是 K2.5 的下一代，参数规模是 K2.5 的 3 倍左右，官方强调规模化不只是把参数堆大，在算力并不宽裕的条件下，靠 KDA、AttnRes 和 MoonEP 等一系列创新把规模化效率提了上去，这条路线的含金量比单纯堆参数高得多。技术报告足足 47 页，把架构、训练过程、评测和基建的细节都交代了。
二点八万亿参数，十六个专家干活
先看参数到底怎么分布。总参数量是一个数字，激活参数量是另一个数字，两者之间的比值决定了模型的稀疏程度。Kimi K3 的总参数是 2.8 万亿，但每个 token 实际参与计算的只有大约 1040 亿参数，这个巨大差距全部来自 MoE 架构的稀疏路由。这里的 1040 亿是激活参数，不是总参数，两个数字差着 27 倍。
模型内部有 896 个路由专家，每个 token 只激活其中 16 个，再加 2 个始终参与计算的共享专家，总共 18 个专家在干活，剩下的专家都在待命。896 选 16，听起来像是路由策略的功劳，但事情没那么简单，如果只是随机选或者简单靠 router 打分，这么多专家很容易出现负载不均，有的专家忙死，有的专家闲死。专家之间的切换由 router 完成，router 本身也是模型的一部分。
更麻烦的是，当专家分布在不同的 GPU 上，跨设备通信会变成比矩阵乘法更早出现的瓶颈。K3 的设计思路是把 token 的隐藏状态先从主维度 7168 压缩到 3584 维，再送入路由专家计算，算完之后再恢复回来，这个降维实际上同时解决了三个问题。这类降维方案业界叫 latent MoE，K3 把它的规模做到了接近千专家。
第一，专家需要读取的权重变少了，单个专家的参数量直接砍半。第二，跨设备传输的数据量变小了，通信压力明显下降。第三，每个专家自身的计算开销也降下来了，弱机也能承担更多专家。原来可能只能做 448 选 8 的方案，现在因为每个专家更轻量，可以扩展到 896 选 16。448 选 8 与 896 选 16 的激活比例一致，都是约 1.8%。
两种配置的激活比例其实是一样的，但后者拥有更多可组合的专家，分工可以更细。潜在空间说到底是一道信息瓶颈，如果压缩得太狠，信息进入专家之前就损失了，所以那两个共享专家专门负责语言结构、基础语义这些通用任务，路由专家集中学细分能力，一粗一细互相补位。共享专家承担通用技能，路由专家在细分技能上做高密度分工。
让这个规模的 MoE 稳定训练，本身就是一个工程难题。技术报告把 Stable LatentMoE 单独拎出来说，重点在 SiTU-GLU 和 Quantile Balancing 两样东西：量化平衡解决的是负载均衡问题，SiTU-GLU 解决的是数值稳定性问题，做过大规模 MoE 训练的人知道这两样缺一不可。这些机制直接关系到训练 2.8 万亿参数模型时能不能稳定收敛。
专家数量膨胀到接近一千个的时候，routing decision 对初始化和学习率非常敏感，一个小波动可能在某个专家分支上被放大成数值溢出。传统路由策略靠辅助 loss 惩罚负载不均，响应速度和稳定性在大规模下都不够理想，而 Quantile Balancing 的做法是根据调度得分的统计分布，一次性推导出最优的路由偏好。量化平衡的路由偏好是一次性推导的，不需要逐步调整的学习过程。
这项设计在数学上可以证明能达到理论完美均衡，比固定步长的调整方式更有弹性，SiTU-GLU 在关键节点插入归一化层抑制数值波动，让训练过程在大规模下保持稳定。K3 每个 token 激活 16 个路由专家的比例大约是 1.8%，意味着推理时不需要把 2.8 万亿参数全部加载到显存里。训练稳定之外，1.8% 激活率也让部署端显存占用成为现实话题。
KDA 混合注意力与注意力残差
再看 KDA 和注意力残差。现场讲解用了一个很直观的类比：传统全注意力处理长文本时，计算量随文本长度平方级增长，内容增加一倍计算量就变成四倍。KDA 的混合线性设计把这一开销降到了接近线性增长，长文本场景的收益非常直接，这也是它能支撑百万上下文的底气。全注意力的平方复杂度在百万 token 下基本不可用，混合线性设计是必选项。
技术报告说的是 KDA 加 AttnRes 这套组合方案，以 3 比 1 的比例混合 KDA 与 Gated MLA，实现高效长上下文建模。具体到模型结构，K3 总共 93 层，被划分为 9 个 block，其中 7 个 block 各有 12 层，加上 1 个 9 层 block 和 embedding 层，层数分布比常见模型更细碎。93 层拆成 9 个 block 的结构，和常见模型的编排方式不太一样。
大部分层用 KDA 处理长上下文，每隔三层插入一层 Gated MLA 做全局信息交互。这就好比你在读一本很厚的书，大部分时候你扫读，但每隔几章会停下来回看目录和章节小结，既有速度又不丢主线。这种混合比例的权衡，值得抄进自己的项目里做参考。每隔几层插入一层全局交互层，长距离依赖由这层补回。
注意力残差解决的是另一个问题：模型越深、层数越多，信息传递通路越长，早期层的信息传到后面容易衰减失真。AttnRes 允许网络层有选择地调用前面区块的表示，相当于给信息传递加了一条捷径，深层模型的长距离信息不再只能靠一层层硬传，误差累积在源头就被打断了。注意力残差把前区块软选择引入，跨层流动不再完全依赖深链传导。
这两个设计叠加起来，规模化效率提升了 2.5 倍，官方说法是在算力最优意义下，单位算力产出智能约等于原来的 2.5 倍。这个数字听起来有点抽象，可以理解为在同样算力投入下，K3 比 K2.5 多产出了约 1.5 倍的智能，规模化的成本曲线在这里被重新画了一次。2.5 倍规模化效率是算力最优口径下的数字，不是简单性能对比。
百万 token 上下文下的强化学习基建
百万 token 上下文窗口对强化学习的基建提出了什么挑战？如果你只在 API 上调用模型，传入一百万个 token 的输入，你感知到的只是生成了结果。但从训练角度看，百万 token 意味着单条轨迹上的累积奖励信号需要贯穿整个上下文，回归问题的难度被指数级放大了。100 万 token 的上下文让强化学习轨迹变得极长，这带来了新的工程质量问题。
强化学习算法需要在如此长的序列上做 credit assignment，K3 的后训练在通用推理、通用 Agent 和编程 Agent 三个领域做了大规模任务合成，RL 训练流程涉及环境交互、奖励计算、策略更新等多个环节，每一步都可能成为分布式瓶颈，任何一环掉链子整个训练都会卡住。三个领域的任务合成涵盖了推理、通用智能体和编程智能体。
他们把支撑这套流程的基建之一 AgentEnv 开源了，这是一个与 KVCache.ai 合作开发的沙箱系统，支持快照、恢复和分叉这些操作。做分布式 RL 的人应该能理解 fork 的重要性，你可以在某个状态点保存快照，然后分出多个实例去做不同动作探索，这种模式在大规模 Agent 训练中几乎是必不可少的。AgentEnv 的 fork 语义让并行探索和大规模回放成为可能。
技术报告里披露了一个硬核数据：这套 RL 训练系统累计创建了 5120 万个沙箱，单次存档耗时 133 毫秒，恢复只需要 49 毫秒。这个数字说明他们在生产环境里已经把这套机制打磨得相当成熟，不是实验室原型，而是经过了数千万次沙箱操作验证过的，稳定性是靠量堆出来的。5120 万个沙箱的累计量说明这套环境已经在训练中真正跑过。
长时程训练还有一个拖后腿问题，同步等待最慢轨迹会让 GPU 大规模闲置。Partial Rollout 的方案是在轨迹完成到一定比例时就暂停生成，立刻启动策略优化，未完成的轨迹存入可恢复沙盒，同步等待就改成了流水线作业，整体吞吐改善是数量级的。Partial Rollout 让最长轨迹不再拖累整体，训练吞吐明显改善。
训练完的多路专家也不会浪费，他们通过基于在线 OPD Reward 的蒸馏方法，把 9 个专家的能力无损融合成单一的 K3 模型。这类做法在业内并不常见，等于把多路探索的收益在收尾阶段重新打包，让一份权重拿到整个团队探索出来的合力，算是对并行训练的资源回收。多专家蒸馏成单模型并不是常见操作，这一手要配合训练流程看。
MoonEP、FlashKDA 与 AgentEnv：三件套怎么分工
接下来看三件套怎么分工。MoonEP、FlashKDA 和 AgentEnv 覆盖了从通信、算子到 RL 环境的三层链路，都是开放日同步放进仓库的真实生产代码，不是演示工程。MoonEP 是为细粒度 MoE 设计的高性能通信库，解决的是专家并行下的负载不均衡问题。三件套的分层正好对应训练系统的通信、计算和环境三条腿。
当 896 个专家分布在多台 GPU 上，routing 决策可能让某几个 GPU 上的专家过载，而其他 GPU 闲置，MoonEP 要做的就是在这种情况下把通信效率推到极致。报告里说它提供了数学可证的均衡分配方案，只需要少量冗余专家就能保障任意负载下训练的连续性，这比经验调参的工程方案稳得多。MoonEP 这类通信库是超大规模 MoE 训练能不能扩展的关键之一。
FlashKDA 是 KDA 算子的高性能实现，在英伟达 H20 上 prefill 速度比 flash-linear-attention 基线快了 1.72 到 2.22 倍，可以直接作为 flash-linear-attention 的替换后端。这块对推理性能影响直接，prefill 阶段处理的是用户输入的全部 token，如果这步慢了，整个请求的延迟都会被拖累。FlashKDA 提供的是算子级别的速度，替换后端即可直接收益。
从 vLLM 社区的一个集成 PR 来看，在 GB200 上用 FlashKDA 替换 Triton 后端后，吞吐从 35776 token/s 提升到 39961 token/s，提升约 11.7%，首 token 延迟从 6.90 秒降到 5.75 秒，降低约 16.7%，算子级别的替换最后带来的是整车级别的提速。vLLM 社区 PR 的数据说明算子选型对线上服务有直接可观的影响。
它的 chunk size 选的是 16 而不是常见的 64，背后有数值精度和矩阵求逆开销的权衡，文档里写得很清楚，这种细节只有真正做过算子优化的人才会解释。AgentEnv 面向的是后训练阶段的大规模 Agent 环境运行，提供高保真、强隔离的沙箱，支撑前面的 5120 万次沙箱动作。chunk 16 的选择是精度与开销平衡后定下来的工程决策。
评测和对比数据最能说明问题，下表把 K3 与同代闭源旗舰放到一起看，各家口径一次对齐，差距一目了然。评测口径各家的差异不小，看表时要特别注意测试集和版本。
|--------------|-----------|----------------|-------------|
| 基准 | Kimi K3 | Claude Fable 5 | GPT 5.6 Sol |
| ProgramBench | 77.8% | 76.8% | 77.6% |
| BrowseComp | 91.2% | 88.0% | 90.4% |
| SWE Marathon | 42.0% | 35.0% | 39.0% |
| DeepSWE | 67.5 | 70.0 | 73.0 |
K3 在 ProgramBench 上拿到 77.8%，超过了 Fable 5 的 76.8% 和 GPT 5.6 Sol 的 77.6%，BrowseComp 达到 91.2%，也超过了两家闭源旗舰，SWE Marathon 达到 42.0%，领先幅度更大。技术报告里也坦承综合性能上还是稍逊于 Fable 5 和 GPT 5.6 Sol。ProgramBench 与 BrowseComp 都是偏真实任务的评测，含金量较高。
有意思的是模型在写代码和编译器任务上表现突出，代码能力接近闭源旗舰是开源模型很稀缺的位置。另外报告提到 MoonViT-V2 视觉编码器完全从零训练，只用 next-token prediction 目标，没用对比预训练，在视觉评估上达到了 SigLIP 初始化的基线水平。视觉编码器从零训练而不依赖对比预训练，这是技术上的一手探索。
DeepSWE 上 K3 拿到 67.5 分，低于 Fable 5 的 70.0 和 GPT 5.6 Sol 的 73.0，说明特定领域的深度软件工程任务还有提升空间。把优势项和弱点项摊开来看，K3 的真实画像不是全面碾压，而是定位清晰、优点突出的开源旗舰，用它该看能不能覆盖业务主干。DeepSWE 的差距说明复杂软件工程任务仍是开源模型要补的短板。
模型自己写编译器、自己设计芯片
报告里最让我意外的一块，是 K3 在沙盒里自举式地写了工具链。在 24 小时的沙盒预算内，K3 独立对 AttnRes、DSA、KDA 和 MLA 四个复杂内核进行 profiling 和重写，把 AttnRes 延迟从 283.6 毫秒压缩到 114.4 毫秒，性能提升 59.7%，这已经是性能工程师级别的活儿。24 小时预算内完成四个内核的优化，展现的是智能体的持续作业能力。
更进一步，它从零构建了一个类 Triton 的编译器，包含 Python 前端、MLIR 优化层、PTX 代码生成，以及支持反向传播的张量库，在 L20 GPU 上 Tensor Core GEMM 达到了硬件 Roofline 的 90%，并成功从头训练了一个 GPT 模型，工具链的每一个环都是自己造出来的。MiniTriton 是模型在沙盒内自建工具链的一环，完整度超出演示范畴。
在 48 小时的自主运行中，K3 针对一个 Nano 模型设计并验证了一款混合 KDA-MLA 架构的推理芯片原型，在 4 平方毫米面积内集成了 146 万逻辑门，时钟频率 100MHz，解码吞吐量超过 8700 token/s，这是从模型到芯片的全链路自闭环，跨度大得吓人。芯片设计闭环验证了模型在硬件层面的跨领域规划能力。
这些实验的意义不在于模型真的能取代芯片工程师，而在于它展示了长时程智能体的另一种上限：给足评测环境，模型可以自己发现瓶颈、自己造工具、自己验证结果。Agent 的自我进化路线在这里有了非常具体的画面，未来可执行的轨迹也比演示级别扎实很多。这些实验提示我们，长时程 Agent 的评测环境本身也该成为基础设施。
本地部署与 API 使用要点
最后说说本地部署和 API 使用。模型权重已经在 Hugging Face 和 ModelScope 上同步放出，vLLM 和 SGLang 都已经支持 Kimi K3 的加载，量化方案从 checkpoint 自己的配置里读取，不需要额外指定 quantization 参数，这一点很大程度上减少了部署踩坑的概率。部署路径两条都写了，选择哪条取决于手里的 GPU 数量和技术栈。
SGLang 官方推荐直接用镜像 lmsysorg/sglang:dev-dev-kimi-k3-nvfp4 启动服务，这是从支持 PR 的 head 切出来的 CUDA 13 构建版本，不需要运行时补丁和注册认证。8 卡 B300 上验证的 context length 是 196608 个 token，这是 TP8 配置下的验证设置而不是模型架构上限，实际可以根据显存调整长度和并发度。196608 token 是实测值，不是上限，延长时会受显存与延迟制约。
启动示例里有一个关键点：--moe-runner-backend flashinfer_trtllm 是强制要求的，因为自动解析不会走 TRT-LLM 的 deferred-finalize 路径，而 flashinfer_cutlass 没有针对路由专家的 SiTU kernel，这个参数直接决定了路由专家能不能正确跑起来，不按它来会得出错误结果。flashinfer_cutlass 缺 SiTU kernel 这个细节，文档里专门讲清楚了。
vLLM 那边也有自己的约定，当前 vLLM 0.1.dev19262 版本的镜像还带着仓库里的兼容补丁，等官方 PR 合并进正式发布版本后就不需要了，踩坑的人主要都卡在这一步。下面这段是基于 SGLang 的启动命令，运行前需要确认有 8 张 B300 或同等显存的 GPU，安装了 nvidia-docker，并且已经配置了 API Token。vLLM 的兼容补丁在 PR 合并后可以去掉，升级时留意即可。
docker run --rm --gpus all --ipc=host --network=host \
--shm-size=64g \
-e HF_TOKEN \
-v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
lmsysorg/sglang:dev-dev-kimi-k3-nvfp4 \
sglang serve \
--trust-remote-code \
--model-path nvidia/Kimi-K3-NVFP4 \
--served-model-name kimi-k3-nvfp4 \
--tp-size 8 \
--dcp-size 8 \
--mem-fraction-static 0.85 \
--reasoning-parser kimi_k3 \
--tool-call-parser kimi_k3 \
--host 0.0.0.0 \
--port 30000 \
--moe-runner-backend flashinfer_trtllm \
--speculative-algorithm DSPARK \
--speculative-draft-model-path RadixArk/Kimi-K3-DSpark \
--speculative-dspark-block-size 7 \
--enable-linear-replay启动成功后，可以通过 OpenAI 兼容的 API 调用，用 curl 验证一下服务是否正常，如果返回了正常响应，说明部署已经跑通，接下来就可以接业务了。这条命令也是我调通后留下的最快路径，新手直接复制即可少走弯路。curl 验证是最快确认服务跑通的方式，返回 JSON 即代表正常。
curl http://localhost:30000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "kimi-k3-nvfp4", "messages": [{"role": "user", "content": "用一句话解释什么是MoE"}]}'不想自己搭服务器的话，可以直接调用 Kimi API 平台，OpenAI 兼容的 Python SDK 就能连上，上下文窗口 1048576 个 token，输入缓存命中每百万 token 0.3 美元，缓存未命中 3 美元，输出 15 美元。如果业务以超长上下文为主，缓存命中的价格优势很明显。API 计费里缓存命中与未命中差了 10 倍，长上下文业务要专门设计。
输入便宜了 10 倍，这类定价结构也暗示了服务端的成本大头在哪里，缓存策略是长上下文业务的关键省钱杠杆。不过需要留意，虽然每个 token 只激活 16 个专家，模型权重本身是完整的 2.8 万亿参数，加载进显存跑推理跟训练是两个量级的资源需求，不要想着买台家用机就能玩。完整权重加载是推理端资源规划必须算的账，激活率只是其中一面。
动手之前建议先把 47 页的技术报告读一遍，重点关注第四章的架构细节和第六章的 Infra 配置，很多问题的答案都在里面，看完再决定是自己部署还是走 API。给开发者的一句话建议：先跑通部署，再读技术报告，你的疑问会在链路里自己找到答案。报告的第 4 章和第 6 章是读者预期收益最大的部分，建议优先精读。