Kimi K3 完整解读：2.8 万亿参数、100 万上下文、开放权重与 API 怎么测
编辑标准与来源政策: 编辑标准, 团队. 内容均链至原始来源，见 方法论.
Last checked: 2026-07-20.
月之暗面在 2026 年 7 月 17 日发布 Kimi K3。官方快速入门给出的硬信息包括 2.8 万亿参数、Kimi Delta Attention、Attention Residuals、原生视觉与 100 万 token 上下文。验证重点是大材料中的证据命中、引用位置、拒答表现和单任务成本；成功放入一百万 token 只证明输入被接受。
直接访问
- Kimi K3 API Quickstart：规格、架构和调用入口。
- Kimi K3 Pricing：cache hit、cache miss 与输出单价。
- Kimi K3 OpenLM：开放权重计划、模型说明和官方 benchmark 图。
- Kimi 产品页：消费端 K3 功能入口。
- Kimi Code：编码 Agent 与 CLI 入口。
实测边界：RadarAI 已核对五个公开页面和文档字段，但未使用付费 API 跑完整的 68 万 token 合同集，也未复现官方编码 benchmark。本文的价格计算可复算；能力分数标注为官方报告，不冒充独立实测。
K3 能做什么，公开效果来自哪里
| 能力 | 官方规格/入口 | 已公开效果 | RadarAI 结论 |
|---|---|---|---|
| 长上下文 | 1,048,576 tokens | 能容纳百万级输入；官方未替用户证明末尾证据命中率 | 必须用位置分层问题自行测有效上下文 |
| 编码 | Kimi Code、CLI、API | 官方图给出 DeepSWE 67.5、Terminal Bench 2.1 88.3、Program Bench 77.8 等 | 仅作为候选筛选，不能替代同仓库回归 |
| 原生视觉 | Quickstart 明确列出视觉能力 | 可用于图文混合材料 | 扫描件 OCR、图表理解和正文引用应分开评分 |
| MoE 推理 | 2.8T 总参数，16/896 专家激活 | 官方称相对 K2 约 2.5 倍扩展效率 | 激活专家数有助于理解架构，不能直接换算 API 延迟 |
| API 成本 | 每 1M token：$0.30 hit、$3 miss、$15 output | 68 万 miss 输入约 $2.04；相同前缀命中约 $0.204 | 账单还受重试、工具调用和缓存失效影响 |
证据类型：官方 benchmark 图。来源：Kimi K3 OpenLM，访问日期 2026-07-20。图中成绩由 Kimi 公布，RadarAI 未在相同环境独立复现。
K3 已经确认的六个规格
| 项目 | 2026-07-20 可确认状态 | 阅读时要保留的边界 |
|---|---|---|
| 模型 | Kimi K3，官方称当前最强旗舰 | 不要与旧 K2/K2.6 的价格和限制混用 |
| 规模 | 2.8T 参数 | 部署还取决于激活参数、量化和并行方案 |
| 上下文 | 官方文档写 1M token | 窗口上限不等于有效检索长度 |
| 架构 | KDA 混合线性注意力 + Attention Residuals | 性能结论仍需任务评测 |
| 权重状态 | 完整权重计划在 2026-07-27 前发布 | 访问日尚未到官方承诺日期 |
| API 价格 | $0.30 cache hit / $3 miss / $15 output，每 1M token | 重试和工具费用另算 |
K3 不是只公布了一个模型名。官方文档已经给出 2.8T 总参数、1,048,576 token 上下文、16/896 专家激活、Kimi Delta Attention、原生视觉和三档 API 单价。仍要单独标注的是权重状态：完整权重计划在 7 月 27 日前发布，7 月 20 日的页面不能提前把计划写成下载事实。
K3 把长上下文、视觉和编码放进同一旗舰
K3 把规模、长上下文、视觉和 agentic coding 放在同一旗舰上。官方 Kimi 页面强调多人游戏、3D、演示文稿和 Swarm/Goal 并行任务；API 快速入门则给出更适合开发者核验的架构与上下文字段；openlm.ai 页面承担开放模型说明。三处入口的目标用户不同，不能把消费端功能直接写成 API 保证。
这次发布值得单独建页，是因为“Kimi 3”搜索背后同时有模型规格、开放权重、调用方式和部署问题。旧的 Kimi pricing 或 CLI 页面只能承接其中一部分。新页以 K3 为唯一核心对象，价格变化、推理框架支持和模型卡更新都回到这里维护。
100 万 token 能装下什么，不等于能答对什么
100 万 token 最容易被误解。窗口表示请求可容纳的理论长度，但答案质量还受位置偏差、材料重复、OCR 噪声、跨文档冲突和输出预算影响。验证时要把证据放在开头、中段、末尾，并加入措辞相近的干扰条款。只让模型总结整包材料，无法证明它找到了关键段落。
2.8T 模型也不适合用单卡消费级显卡想象。完整权重按官方计划尚待发布；发布后还要确认权重精度、分片大小、推荐并行、推理框架版本与许可证。若团队只需要 API，重点反而是首 token 延迟、吞吐、缓存计费、失败重试和地区可用性。
原生视觉要用混合输入测试：扫描 PDF、图表、截图和正文中的同名实体。视觉正确率、文字引用和长上下文检索应分别计分，不能因为一张图片解释得好就推导整套文档审查可靠。
| 判断维度 | 应该记录什么 | 不能怎样下结论 |
|---|---|---|
| 长上下文 | 命中率、证据位置、冲突识别和拒答 | 只记录成功放入 1M token |
| 开放权重 | 模型卡、许可证、分片、精度和框架 | 把开放等同于能在笔记本运行 |
| API | base URL、model ID、价格、缓存和限流 | 沿用 K2 旧字段 |
| 视觉 | 图表/扫描件的字段准确率和引用 | 用单张演示图概括多模态能力 |
| Agent | 工具成功率、长任务恢复和总成本 | 只看最终成品是否漂亮 |
K3 对 K2 用户真正改变了什么
K3 是少数把 3T 级开放模型、百万上下文和产品化 agent 入口同时推到用户面前的发布。团队可以把长材料、视觉材料和多步骤编码放到同一候选上评估，但不应立即替换全部模型。证据检索不稳定时，大窗口会让错误更难发现；开放部署成本过高时，API 仍可能是更现实的路径。
开发团队案例：用 240 份合同算一遍真实成本
让法务运营团队准备 240 份合同与附件，共约 68 万 token，埋入 30 个金标准问题：续约、赔偿上限、数据驻留、终止通知和版本冲突各 6 个。另加入 10 个资料中没有答案的问题，测试拒答。
| 环节 | 合同审查动作 | 通过标准 |
|---|---|---|
| 装载 | 保留文件名、页码和版本日期 | 240 份材料全部可定位 |
| 提问 | 40 个固定问题，证据分布于不同位置 | 每题输出答案、文件与页码 |
| 评分 | 完全支持/部分支持/不支持/拒答 | 证据准确率至少 90% |
| 性能 | 记录输入 token、缓存、首 token 与总时长 | 成本和延迟可复算 |
| 暂停 | 旧条款覆盖新条款或无答案时编造 | 立即停止进入法务流程 |
这个案例同时检验三件事：68 万 token 是否能稳定装入、证据位置是否影响命中、缓存是否真的降低后续查询成本。每个答案必须返回文件名、页码和版本日期；一旦旧合同覆盖新合同，或材料里没有答案却生成条款，长上下文窗口再大也不能进入法务流程。
百万上下文最常见的五种假成功
- 位置失败：末尾证据命中率明显低于开头，却仍宣称百万上下文可用。
- 版本失败：同时引用新旧合同，但没有指出冲突和生效日期。
- 拒答失败：资料没有答案时生成看似合理的条款。
- 部署失败：权重可下载，但目标框架或硬件无法稳定加载。
- 成本失败：缓存、重试或超长输入费用未进入单任务成本。
“请求被接受”只是容量成功，不是任务成功。证据放到材料末尾后命中率下降、同一条款的新旧版本被混用、无答案问题不拒答，都属于有效上下文不足。评估报告必须分别记录容量、检索、引用、拒答与成本，不能用一个“支持 1M”标签覆盖五种结果。
7 月 27 日前后要核对的发布清单
- 官方模型卡：补齐激活参数、许可证、训练与评测细节。
- API pricing：记录输入、输出、缓存、批处理和长上下文阶梯。
- 推理框架：关注 vLLM、SGLang、Transformers 的官方兼容说明。
- 量化版本：核对来源、精度、校验值和质量损失。
- 独立长上下文评测：要求公开材料构造、证据位置与评分脚本。
7 月 27 日是这篇文章的第一个明确刷新点：检查完整权重、模型卡、许可证、分片精度和推荐推理框架是否同时出现。API 侧则继续核对 model ID、缓存命中定义和账单明细。只有官方组织页上的文件与文档能把“计划开放”改写为“已开放”。
K3 的架构、权重时间表和 API 成本可以算到多细
Kimi K3 官方快速入门披露的增量远多于“2.8T + 1M”。K3 使用 Kimi Delta Attention 与 Attention Residuals；Stable LatentMoE 在 896 个 experts 中每次激活 16 个。官方称这一结构与训练改进让 K3 相比 K2 获得约 2.5x 的 overall scaling efficiency。这里的 16/896 是路由稀疏度，不是部署所需显存公式，完整权重仍然包含全部专家。
“开放模型”在 7 月 20 日还有明确时间边界。快速入门写明 full model weights 将在 2026-07-27 前发布，架构、训练和评测细节会随技术报告补齐。因此当前可确认的是模型发布、API 可用和权重发布计划；完整权重文件尚未到计划日期。文章若在 7 月 27 日后上线，编辑必须重新检查下载地址、许可证、分片和校验值，不能沿用这段未来时。
API 价格已经可以写成可复算数字。Kimi K3 定价页以 100 万 token 为单位：cache hit 输入 $0.30，cache miss 输入 $3.00，输出 $15.00；上下文窗口列为 1,048,576 tokens。一个 68 万 token 合同包若全部 cache miss，单次输入约 $2.04；若后续重复查询全部命中缓存，输入约 $0.204。输出 20,000 token 约 $0.30。这只是理想算术，重试、文件解析、工具调用和无法命中缓存的前缀都会增加实际成本。缓存测试必须固定完全相同的前缀；只改一个系统提示就可能让命中率与估算不同。
定价页还提示 web_search 正在更新，近期不建议依赖，且该部分文档已过时。这个警告直接影响 agent 方案：合同审查应以用户提供材料为闭集，不把 web search 当稳定补充。K3 支持 reasoning effort、ToolCalls、JSON Mode、structured output 和动态工具加载，但每项都要单独测 schema 合规、工具误选和取消恢复。
68 万 token 合同包的成本记录不能只写一个单价
40 个问题连续执行时，应把首次装载与后续查询分开统计。首次请求通常按 cache miss 计算输入；只有前缀、文件顺序和系统提示保持一致，后续请求才可能命中缓存。任意一处改动都可能改变账单。记录表至少包含 prompt tokens、cache-hit tokens、output tokens、重试次数和工具费用，最终用平台账单复核本地估算。
证据类型：官方页面图片。来源：Kimi K3 API Quickstart，访问日期 2026-07-20。具体型号和价格以链接内文档字段为准。
常见问题
Kimi 3 和 Kimi K3 是同一个吗？
用户常搜索“Kimi 3”，官方产品名为 Kimi K3；页面标题同时承接两种表达，但正文使用官方名称。
K3 真的支持 100 万 token 吗？
官方快速入门明确写 1M-token context window；实际有效长度仍要用证据检索测试。
开放权重能在本地电脑运行吗？
2.8T 总规模决定它不是普通单机模型。是否能部署取决于激活规模、量化、内存与并行。
Kimi App、Code 和 API 有什么区别？
它们分别面向交互知识工作、编码 agent 和程序调用，功能、额度和数据路径不能混写。
长文档最关键的指标是什么？
应同时记录有干扰和冲突时的证据准确率、拒答率、延迟与总成本，最大输入长度仅是容量字段。
官方与一手来源
- Kimi K3 API Quickstart：官方规格与 API 快速入门
- Kimi K3 Pricing：模型 ID、三档 token 单价与 1,048,576 context
- Kimi K3 OpenLM：官方开放模型说明
- Kimi 官方产品页：K3 消费端与知识工作入口
- Kimi Code：K3 编码代理入口
访问日期均为 2026-07-20。新闻媒体用于确认事件时间与公开说法；涉及版本、参数、使用入口、公司身份和活动安排时，优先回到官方页面。页面无法提供的细节会明确标注为待核验，不从搜索摘要自行补齐。