Kimi K3：2.8T MoE 先上 API，权重要等 7 月 27 日
Moonshot 的 Kimi K3 把 2.8T 稀疏 MoE、原生视觉和 100 万 token 上下文放进同一模型；本文拆解它的架构、官方评测、Agent 案例和本地部署边界。
先说结论
Kimi K3 的发布分成两条线：今天可以在 Kimi、Kimi Work、Kimi Code 和 API 中使用，模型权重则计划在 2026 年 7 月 27 日开放。它的卖点不是单一 benchmark，而是把 2.8T 参数规模、原生视觉、100 万 token 上下文和长程 Agent 任务放进同一个 MoE 模型；对开发者来说，眼下能验证的是托管 API，能否本地运行要等权重和推理实现真正落地。1
官方发布页也没有把 K3 写成全面领先的模型：它在一些编码、搜索和视觉项目上接近或超过对比模型，但整体体验仍落后于 Claude Fable 5 和 GPT 5.6 Sol。这个自我评价，反而比「全面超越」更值得注意。
一页看懂 Kimi K3
| 项目 | 官方信息 | 读者该怎么理解 |
|---|---|---|
| 模型规模 | 2.8 万亿参数 | 这是公开模型目前非常大的参数规模，但不等于每次请求都计算全部参数。 |
| MoE 激活 | Stable LatentMoE 下有效激活 896 个专家中的 16 个 | 稀疏激活把总容量和单次计算量分开，实际吞吐仍取决于路由、通信和推理实现。 |
| 上下文 | 100 万 token | 可以承载超长代码仓库或资料集合，但长上下文不自动等于长任务能稳定完成。 |
| 输入能力 | 原生视觉，支持文本、图片和视频 | 视觉信息可以进入同一套模型循环，官方重点展示了截图驱动的代码和创作任务。 |
| API | 已上线；缓存命中输入 $0.30/MTok，未命中输入 $3.00/MTok，输出 $15.00/MTok | 这是官方发布页给出的价格，缓存条件会直接影响实际成本。 |
| 权重 | 计划于 2026 年 7 月 27 日开放 | 在权重和推理代码可用前，不应把它当作已经能下载部署的开源模型。 |
其中「MTok」指每百万 token。官方还称，Kimi API 在编码工作负载中的缓存命中率超过 90%，但这是发布方自己的服务数据，不能直接外推到所有应用。1
2.8T 参数是怎么被压住的
K3 的架构核心有三个词：Kimi Delta Attention（KDA）、Attention Residuals（AttnRes）和 Stable LatentMoE。
KDA 试图降低注意力随序列长度增长的成本。AttnRes 则让模型跨深度选择性取回表示，不必把每一层的信息都用同一种方式累加。再加上 16/896 的稀疏专家配置，K3 把「模型总容量」和「一次请求要动用多少计算」拆开处理。官方称，这套结构配合训练和数据配方，相比 Kimi K2 带来约 2.5 倍的整体 scaling efficiency 提升。这个数字目前仍是 Moonshot 的发布口径，完整架构、训练细节和评测说明要等技术报告。1
这里有一个容易被忽略的工程代价：专家越多，路由和专家并行通信越难做。K3 的发布页因此建议使用至少 64 个加速器组成的 supernode 配置，并说明已经向 vLLM 社区贡献了适配 KDA 的实现，计划和模型一起发布。换句话说，2.8T 的参数规模只是故事的一半，另一半是如何把稀疏计算、跨卡通信和百万上下文同时跑稳。
官方 benchmark：强，但不是全场第一
K3 的公开表格使用了不同的 Agent harness，包括 KimiCode、Claude Code 和 Codex；有些对手分数来自其他官方发布或第三方榜单，Claude Fable 5 的部分结果还可能包含 fallback。因此，下面这些数字适合用来定位强项，不适合当成严格的同条件总排名。1
| 方向 | Kimi K3（max） | 官方表中的对照信号 | 解读 |
|---|---|---|---|
| Program Bench | 77.8 | Claude Fable 5 为 76.8，GPT 5.6 Sol 为 77.6 | 代码生成与程序任务很强，但差距并不大。 |
| Terminal Bench 2.1 | 88.3 | GPT 5.6 Sol 为 88.8，Claude Fable 5 为 84.6 | 接近最高分，评测 harness 差异需要保留。 |
| BrowseComp | 91.2 | GPT 5.6 Sol 为 90.4，Claude Fable 5 为 88.0 | 长上下文搜索是 K3 的亮点之一，官方还报告了 1M context 下不做上下文管理的结果。 |
| DeepSearchQA | 95.0 | Claude Fable 5 为 94.2，Claude Opus 4.8 为 93.1 | 工具辅助的深度搜索问答表现突出。 |
| GDPval-AA v2 | 1668.0 | Claude Fable 5 为 1760.0，GPT 5.6 Sol 为 1748.0 | 知识工作综合指标仍落后于最强对手。 |
| HLE-Full | 43.5 | Claude Fable 5 为 53.3，GPT 5.6 Sol 为 44.5 | 复杂知识与推理任务并非 K3 的全面优势。 |
| MMMU-Pro | 81.6 | Claude Fable 5 为 81.2，GPT 5.6 Sol 为 83.0 | 原生视觉有竞争力，但不能据此说已经超过所有闭源模型。 |
这张表最有用的地方不是证明 K3 在某一列赢了，而是显示它的能力分布：编码、搜索、视觉和长任务都能打，真正拉开差距的可能是任务持续时间、工具调用和部署成本，而不是一项孤立的答题分数。
更值得看的，是它拿来做什么
让模型连续工作数小时
在 GPU kernel 优化实验中，每个模型在相同沙盒里最多有 24 小时，可以分析、改写和 benchmark 四类任务，硬件包括 NVIDIA H200 和另一家厂商的 GPGPU。K3 在 AttnRes kernel 任务里连续迭代约 15 小时，把前向加反向时间从 283.6 毫秒降到 114.4 毫秒；在 DSA kernel 上相对基线降低 55.1%，在 MLA-512 从零编写的 kernel 上达到 517.8 TFLOPS。1
这些结果说明 K3 被训练和评测的目标，是持续观察结果、修改代码、再跑验证，而不是一次生成一个看起来合理的函数。不过实验仍是官方设定的沙盒任务，部分模型允许在数值容差内做精度折衷，Fable 5 的结果还可能有 fallback。它能否迁移到真实大型工程，不能只看这组数字。
视觉进入代码循环
K3 把截图和视觉输入放进代码 Agent 的工作过程，官方展示了浏览器 3D 游戏、前端和 CAD 场景：模型写代码、查看实时截图，再根据结果继续修改。这个方向的价值在于，模型不必只靠 DOM、日志或用户描述判断结果，而是可以直接读到画布和界面状态。
但「原生视觉」的含义要说准确。它表示视觉输入和语言、视频能力在同一模型体系里处理，不代表模型天然拥有可靠的 GUI 控制、物理世界反馈或无限长的视频记忆。发布页给出了案例，没有在这篇文章里完整披露训练数据、失败率和跨环境泛化结果。
也可以做芯片设计，但目前还是仿真案例
在一个 48 小时自主运行的概念验证中，K3 用开源 EDA 工具和 Nangate 45nm library 设计、优化并验证了一个服务于自有架构小模型的芯片：面积约 4 mm²，仿真中以 100 MHz 收敛，decode 吞吐超过 8,700 tokens/s，包含 146 万个标准单元、0.277 MB SRAM 和带融合反量化的 INT4 MAC 阵列。1
这里的关键词是「仿真」。它展示了长程 Agent 能把规格、RTL、布局布线和验证串起来，但不等于芯片已经流片，也不等于相同流程在生产约束下无需工程师介入。
当前最现实的使用方式
现在能用 K3 的入口有四个：Kimi App、Kimi Work、Kimi Code 和 Kimi API。Kimi Code 可以通过
/model 选择 K3；Kimi Work 需要 3.1.0 或更高版本。默认是 max thinking effort，低和高两种 effort 模式会在后续更新中加入。1API 价格表面上不算离谱，但不能只拿输入单价和别家比较。K3 的长任务会产生大量输出 token，且缓存命中与否会把输入成本拉开十倍；官方所谓超过 90% 的编码缓存命中率，也依赖 Mooncake 的服务架构和具体工作负载。做成本评估时，应该用自己的 prompt 前缀、会话切换和工具调用轨迹重放，而不是套一个公开单价。
本地部署还要等两个节点：7 月 27 日的权重，以及与 KDA、专家并行和前缀缓存匹配的推理实现。官方建议 64 个以上加速器的 supernode 配置，这已经把它和普通单机开源模型的使用方式区分开了。即使权重按计划开放，真正值得测试的也会是显存、通信拓扑、量化精度和长上下文吞吐，而不是「能否启动」这一项。
不能忽略的限制
官方发布页明确写了三类边界：
- K3 以保留 thinking history 的模式训练。如果 Agent harness 没有完整回传历史思考内容，或者在会话中途从另一模型切换到 K3，生成质量可能变得不稳定。接入方需要确认 harness 能保留这部分上下文。
- K3 对长程困难任务的训练会让它更主动。遇到小问题或模糊意图时，它可能替用户做出未授权的决定。需要严格边界的应用，应在 system prompt 或
AGENTS.md中写清行为限制。 - 官方承认 K3 的整体用户体验仍与 Claude Fable 5、GPT 5.6 Sol 有明显差距。
这三条对 Agent 开发比一句「支持 100 万上下文」更有操作价值：上下文能塞进去，只是容量指标；历史思考是否被正确传回、模型会不会擅自扩大任务范围，才决定长任务能不能放进生产流程。
判断：K3 现在改变了什么
Kimi K3 把「超大规模稀疏 MoE」「原生视觉」「百万上下文」「长程编码 Agent」组合到一个可立即调用的服务里，给开发者提供了一个很具体的试验对象。它最值得看的地方，是把模型评测从单轮问答推向持续数小时的代码、研究和工具任务。
但「开放模型」在今天仍是一个分阶段承诺：API 已经开放，权重和配套推理实现尚在后续计划里；技术报告也还没有随发布页一起给出。下一步应盯住三件可验证的事：7 月 27 日权重是否按时开放，vLLM 等实现能否在真实硬件上跑出可接受吞吐，以及第三方复测能否复现官方表格中的长程 Agent 和视觉结果。在这三件事出现之前，K3 更适合作为一个已经上线的 API 来评估，而不是已经完成本地部署的开源底座。
関連コンテンツ
- ログインするとコメントできます。