Kimi K3 发布：2.8T 开源 MoE 已进入前沿工作流区间

Moonshot AI 在 7 月 17 日发布 Kimi K3：2.8 万亿参数的稀疏 MoE 模型，具备原生视觉能力和 100 万 token 上下文，已通过 Kimi.com、Kimi Work、Kimi Code 和 API 提供服务，完整权重计划于 7 月 27 日发布。1

它的价值不只是参数更大，而是把模型、Agent harness、长上下文和多模态入口一起交付。K3 在 Moonshot 公布的多项编码与知识工作评测中已进入前沿区间，但不能写成全面超过闭源旗舰：官方承认总体表现仍落后于 Claude Fable 5 和 GPT 5.6 Sol，用户体验也有差距。1

K3 是 MoE 模型，总参数 2.8T，但在 Stable LatentMoE 下每次激活 896 个专家中的 16 个。这把模型容量和单 token 计算量分开，却不等于部署简单。Moonshot 建议使用 64 个或更多加速器的 supernode；7 月 27 日开放权重后，普通开发者能否低成本复现，仍取决于推理实现、显存组织和通信效率。1

架构主轴是 Kimi Delta Attention（KDA）和 Attention Residuals（AttnRes）：官方称前者面向更高效的 attention 扩展，后者在模型深度方向选择性取回表示。配套还有 Quantile Balancing、Per-Head Muon、SiTU、Gated MLA，以及从 SFT 阶段开始的量化感知训练，权重使用 MXFP4、激活使用 MXFP8。Moonshot 声称相对 Kimi K2 带来约 2.5 倍整体 scaling efficiency，但完整技术报告尚未公开，这个数字应按厂商自测理解。1

KDA 还改变了传统 prefix cache 的实现路径。Moonshot 表示已向 vLLM 社区贡献对应实现，并计划与模型同步发布；长上下文能否在真实 Agent 工作流里保持可接受的延迟和缓存命中率，才决定 1M 上下文是生产规格还是演示规格。

下面列出最能说明位置的几项。分数来自 Moonshot 发布页，统一使用 max 或 xhigh 推理设置，但不同模型使用 KimiCode、Claude Code 或 Codex harness；Fable 5 结果可能包含 fallback，GPT 5.6 Sol 结果可能包含 guardrails，不能当作严格同条件排行榜。1

这组结果的价值不在于「赢了几项」，而在于 K3 在长程执行任务中没有明显塌陷：Program Bench 略高于 Sol，Terminal-Bench 几乎贴近；但 DeepSWE 仍落后于 Sol 和 Fable 5。更准确的结论是，K3 已进入前沿工作流执行区间，而不是取代所有旗舰。1

知识工作部分的信号更直接，但可信边界更窄。Moonshot 的内部 Knowledge Work Bench 中，K3 在 Online Exp Bench、DECK-Bench 和 Finance-Bench 分别为 75.5、73.5 和 62.6，均高于同图中的 Claude Opus 4.8（65.9、66.9、60.7）。这支持「K3 在 Moonshot 设计的生产型工作流样本里领先 Opus 4.8」这一有限结论，不能外推成整个知识工作领域的全面领先，因为提示词、工具链和裁判方式没有完整公开。1

K3 已出现在 Kimi.com、移动端 Agents、Kimi Work、Kimi Code 和 API 五个入口。Kimi Work 需要 Windows 或 Apple silicon Mac 上的 3.1.0 及以上版本；Kimi Code 通过 /model 选择 K3；API 模型名是 kimi-k3。发布时默认 max thinking effort，low 和 high 模式后续加入。1

API 价格为 cache-hit input 每百万 token 0.30 美元、cache-miss input 3 美元、output 15 美元。Moonshot 称官方 API 在编码工作负载中的缓存命中率超过 90%，但这不是所有请求的保证值；成本预算必须把三类 token 分开，不能用最低价代表完整调用。1

7 月 17 日是服务和 API 发布日，7 月 27 日才是完整权重计划开放日；更多架构、训练和评测细节将随技术报告发布。今天可以评估产品能力和 API 单位经济，但还不能把「开源」理解成本地部署、权重审计和社区推理生态都已完成。1

第一，K3 对 thinking history 敏感：harness 若未回传完整历史思考内容，或把其他模型的 session 中途切换到 K3，质量可能高度不稳定。这个限制会影响模型路由、故障恢复和多模型编排。第二，它可能过度主动，遇到小问题或模糊意图时替用户做未预期的决定；接入真实仓库、企业数据或可写工具时，应在 system prompt 和 AGENTS.md 中收紧边界，并保留人工确认。第三，模型能力和产品体验不是一回事，真正需要测试的是响应稳定性、工具调用可解释性、长任务恢复和多模态失败模式，而不是只看榜单。1

如果今天就要试用，最合理的切入点不是把 K3 当成通用聊天模型，而是选择它擅长且能量化收益的长任务：大型代码库导航、跨文档研究、带截图的前端或游戏开发，以及需要反复复用上下文的 Agent 流程。先记录 cache-hit、cache-miss、输出 token、工具调用次数和人工接管率，再与现有模型在同一 harness、同一任务集上比较，才能判断低价是否真的转化成单位任务成本。

产品团队还要把「1M 上下文」拆成两个问题：模型能否读完材料，和它能否在读完后稳定提取、规划并执行。长上下文扩大了输入范围，却不会自动解决信息筛选、权限边界和长任务恢复。K3 对 thinking history 的敏感，意味着多模型路由、会话迁移和故障重试都需要单独设计，不能沿用只验证请求格式的兼容性测试。

基础设施团队应把 7 月 27 日视为部署评审节点，而不是简单的下载日，同时检查权重许可、技术报告、vLLM 的 KDA 实现、最低硬件拓扑、量化精度和多机通信开销。若 64 个以上加速器仍是实际建议，K3 的开放价值会首先体现在可审计和可定制，其次才是低成本自托管。

Kimi K3 的意义，是把开放模型从参数规模竞赛推进到 Agent 系统竞赛：2.8T 总容量、16/896 稀疏激活、1M 上下文、原生多模态、Kimi Code harness 和 API 价格，组成了一条从模型到工作流的完整路径。它已经足以让开发者认真评估，而不是只把它当作闭源模型的廉价替代。

但它是否改变开放模型的部署格局，要等完整权重、vLLM 实现和技术报告落地后再判断。届时最值得复核的是：64 个以上加速器的部署要求能否被工程化压缩；KDA 的缓存和通信开销是否兑现低价承诺；以及社区 harness 能否稳定处理 thinking history。7 月 27 日之后，Kimi K3 才会从一次强势发布，变成可独立复现和长期运营的开放模型。