Kimi K3 正式发布：2.8 万亿参数、百万上下文，完整权重将于 7 月 27 日前开放
月之暗面正式发布 Kimi K3。新模型采用 2.8 万亿参数 MoE 架构，支持 100 万 token 上下文和原生视觉，已登陆 Kimi、Kimi Work、Kimi Code 与 API；完整权重计划在 7 月 27 日前发布。
2026 年 7 月 16 日，月之暗面正式发布 Kimi K3，并将其定位为目前能力最强的 Kimi 模型。新模型总参数达到 2.8 万亿，原生支持图像与视频理解，提供 100 万 token 上下文窗口，面向长程编程、知识工作和复杂推理任务。
Kimi K3 已同步进入 Kimi 网页端与 App、Kimi Work、Kimi Code 和 Kimi API，开发者可通过模型 ID kimi-k3 调用。月之暗面还宣布，完整模型权重将在 2026 年 7 月 27 日前发布；更详细的架构、训练和评测信息将随技术报告公开。
这次发布纠正了预热阶段的一项关键传闻。正式资料披露的是 2.8 万亿参数，此前流传的 2.5 万亿并非最终规格。对开发者更有实际意义的变化，则落在 1M 上下文、视觉输入、长时间任务执行和明确的 API 价格上。
K3 把规模、长上下文和原生视觉放进同一模型
Kimi K3 采用混合专家架构，底层包含 Kimi Delta Attention、Attention Residuals 和 Stable LatentMoE。官方披露，模型共有 896 个专家，每次有效激活其中 16 个，用稀疏路由控制超大参数规模下的计算量。
可以先把已经确认的规格整理成一张表：
维度 | Kimi K3 已公开信息 | 对使用者的含义 |
|---|---|---|
模型规模 | 总参数 2.8T，MoE 架构，激活 16 / 896 个专家 | 参数规模很大，实际延迟和成本仍取决于路由与推理系统 |
上下文 | 最高 1M tokens | 可容纳更大的代码仓库、文档集和长时间 Agent 历史 |
输入模态 | 文本、图像与视频 | 代码、截图、界面录屏和视觉检查可以进入同一任务链 |
推理设置 | 上线时默认使用 max thinking effort | 适合高难度任务，简单请求也可能产生较高等待与输出成本 |
开放范围 | Kimi、Kimi Work、Kimi Code、Kimi API | 普通用户、知识工作者和开发者均有直接入口 |
模型权重 | 计划在 2026 年 7 月 27 日前发布 | 当前可先使用官方服务，自托管需等待权重和完整技术细节 |
1M 上下文最适合已经明确遇到容量瓶颈的任务，例如跨多个包分析大型代码库、处理成套合同与研究资料，或让 Agent 在长时间执行中保留更多过程信息。上下文容量提高后，模型仍可能出现定位偏差、前后不一致或把无关材料带进判断。团队需要用真实任务验证有效利用率，不能只看可输入长度。
原生视觉则让 K3 的编程能力覆盖到前端、游戏、3D 和 CAD 等需要“看结果再修改”的场景。模型可以结合代码、截图与视频继续迭代。官方展示了 GPU 内核优化、编译器开发、浏览器 3D 游戏、芯片设计和科研计算等长程案例，不过这些案例来自发布方，暂时不能替代独立评测和生产环境回归测试。
API 已开放，旗舰价格要求更细的模型路由
Kimi API 已提供 kimi-k3。官方以美元按每 100 万 token 计价：
计费项 | Kimi K3 价格 |
|---|---|
缓存命中输入 | 0.30 美元 |
未命中缓存的输入 | 3.00 美元 |
输出 | 15.00 美元 |
输出价格是普通输入的 5 倍，缓存命中输入则只有普通输入的十分之一。对于会反复携带系统提示、仓库说明、工具定义和项目背景的 Agent，稳定前缀与缓存命中率会显著影响账单。
K3 上线时只提供最高强度的推理设置，官方计划后续增加低强度和高强度模式。现阶段把它设为所有请求的默认模型，容易让摘要、分类、简单改写等常规任务承担不必要的成本和延迟。
更适合小团队的方式是按任务价值分流：
- K3 处理跨领域难题、超长上下文、复杂研究和返工成本高的工程任务。
- 编程日常任务继续与 Kimi K2.7 Code 并排测试，不因版本号直接迁移全部工作流。
- 批量提取、分类和短摘要优先保留成本更低的模型。
- 长会话固定系统提示与项目背景，监控缓存命中、输出 token 和单任务总成本。
官方评测显示全面接近前沿，仍有明显边界
月之暗面公布的完整评测表覆盖编程、Agent、知识推理和视觉任务。K3 在部分项目上取得较强成绩，例如 BrowseComp 为 91.2、DeepSearchQA 为 95.0，Program Bench 为 77.8，MMMU-Pro 为 81.6。它也没有在所有项目领先：官方直接承认，K3 的整体表现仍落后于当时最强的专有模型，部分复杂体验也存在差距。
跨模型分数需要结合测试框架阅读。同一个模型在 Kimi Code、Claude Code 或 Codex 等不同 harness 下运行，工具配置、上下文管理和失败回退机制都会改变结果。发布方自测能说明产品重点，无法直接回答某个团队的代码库、数据流程或内容任务是否会受益。
官方同时列出了三项使用限制，其中两项会直接影响 Agent 接入：
- 思考历史必须完整回传。 K3 按保留思考历史的方式训练。如果 Agent 框架没有按要求带回完整历史，生成质量可能明显波动。正在进行的会话也不适合中途从其他模型切换到 K3。
- 模型可能过度主动。 K3 针对长程和困难任务强化后，遇到轻微问题或模糊指令时，可能替用户作出超出预期的决定。涉及文件修改、外部发送、支付、删除或生产权限时，需要更明确的系统约束和人工确认。
- 独立评测仍需等待。 技术报告与完整权重尚未同步发布，部署需求、激活规模、硬件要求和第三方实测还需要更多材料补齐。
这些限制决定了 K3 更适合从隔离环境和可回放任务开始测试。一个能自主运行 24 小时的 Agent，也会把权限错误、错误假设和成本波动放大 24 小时。
独立开发者最该先测的四类任务
Kimi K3 的价值要通过具体工作流验证。小团队可以选取已有标准答案或验收测试的历史任务，在 K3 与当前主力模型之间做并排对比。
- 大型代码库调查
输入仓库结构、关键文档和相关代码，让模型定位跨模块调用链、影响范围与测试缺口。重点记录定位准确率、无关修改数量和总 token，而非只看它能否读入全部文件。
- 视觉驱动的前端迭代
给出代码、目标截图和当前页面录屏，让模型修改后重新查看结果。验收视觉差异、响应式布局、交互状态和回归问题，观察“视觉进入循环”是否减少人工往返。
- 长文档知识工作
使用一组可核查的报告、合同或研究材料，要求模型建立结论与原文位置之间的对应关系。测试重点是遗漏率、冲突识别和长上下文中的证据定位。
- 受控的长程 Agent
在沙箱中设置明确权限、预算、停止条件和检查点，让 K3 完成持续数小时的工程任务。特别观察中途切换模型、历史压缩、工具返回和失败重试是否破坏稳定性。
K3 的首要选型信号是任务是否同时需要高难度推理、长记忆和多工具执行。只满足其中一项时，更便宜或更专用的模型往往更容易控制。
接下来关注权重、技术报告和真实成本
Kimi K3 已经从预热视频和匿名模型猜测走到可直接调用的产品阶段。现阶段可以确认的是 2.8T 参数、1M 上下文、原生视觉、全产品开放和 API 价格；完整权重、技术报告及更广泛的第三方复现仍在后续时间表上。
7 月 27 日前的权重发布将是下一个关键节点。届时需要继续确认许可证、量化版本、推理框架支持、实际激活参数、推荐硬件和部署成本。对多数小团队，本周更合理的动作是先挑一条难且长的真实任务做受控试点，同时记录质量、延迟、缓存命中与总账单，再决定是否扩大使用范围。
