近期AI热点003Kimi K3 技术拆解2.8 万亿参数、API 接入与真实评价主要信息源Kimi 官方技术博客与 API 文档、MoonshotAI GitHub、Artificial Analysis、Hacker News、爱范儿实测关键词Kimi K3、Moonshot AI、开源大模型、MoE、KDA、API 接入、长上下文、AI Agent7 月 18 日更新官方 API 参数与max推理限制未变完整权重仍计划在 7 月 27 日前发布。本文同步更新了独立评测和社区讨论数据。下文的计费数字仅用于估算 Token 消耗对工程预算的影响计费规则以发布时的官方文档为准。2026 年 7 月 16 日月之暗面发布 Kimi K3并把它定位为面向长程编程、端到端知识工作和推理任务的旗舰模型。Kimi K3 的总参数量达到 2.8 万亿采用 Kimi Delta AttentionKDA、Attention ResidualsAttnRes和更稀疏的 MoE 架构原生支持视觉输入并提供 1,048,576 Token 的上下文窗口。不过关于“开源”需要先把时间线讲清楚。Kimi 官方已经宣布 K3 是开放模型并承诺在 2026 年 7 月 27 日前发布完整权重技术报告也会随权重公布。截至权重正式上线之前开发者可以通过官方在线服务和 API 测试 K3但还不能根据官方模型卡完成真正可复现的自托管部署。因此本文重点讨论当前已经可以验证的模型架构、API 接入、调用限制、成本和公开评价。自托管只记录官方状态不展开尚未得到模型卡支持的部署命令。先看清 Kimi K3 的技术规格项目官方信息总参数量2.8 万亿模型结构MoE896 个专家、每次激活 16 个注意力结构Kimi Delta Attention 与 Gated MLA 组成的混合结构深度信息流Attention Residuals上下文窗口1,048,576 Token输入模态文本、图像和视频输出模态文本API 模型名kimi-k3推理模式始终开启目前reasoning_effort仅支持max完整权重官方承诺最迟于 2026 年 7 月 27 日发布官方没有在首发文档中公布完整的激活参数量、层数、隐藏维度、专家大小、KV Cache 结构和训练 Token 数量。这些数据需要等待模型配置与技术报告不能根据“16/896 个专家”简单算出整个模型的激活参数量。2.8 万亿参数不等于每个 Token 都计算 2.8 万亿参数K3 使用更稀疏的 Mixture of Experts。每个 Token 只路由到 896 个专家中的 16 个这会显著减少单次前向计算量。但 MoE 有两个容易混淆的概念计算量和存储量。每个 Token 只激活少量专家降低的是计算成本部署节点仍然需要存放完整专家权重除非使用专家按需加载或 CPU/NVMe Offload而这又会引入明显的通信与延迟开销。换句话说K3 可能拥有比同规模稠密模型更可控的推理计算量但 2.8 万亿参数仍然是一份非常庞大的权重资产。它不会因为“每次只用 16 个专家”就突然变成一张消费级显卡能跑的模型。KDA 与 AttnRes 在解决什么标准 Transformer 的全注意力计算会随着序列长度增长快速增加。Kimi Delta Attention 是一种混合线性注意力机制目标是在长序列中降低注意力计算压力同时保留处理复杂上下文的能力。Attention Residuals 解决的是另一个方向的问题模型变得更深以后信息如何跨层传递。传统残差连接主要沿相邻层传播AttnRes 则允许网络从多个历史块中选择和聚合信息减少深层网络中的信息损失。官方还引入 Stable LatentMoE并称 K3 相比 K2 的整体扩展效率约提升 2.5 倍。这个数字描述的是官方定义下的整体 scaling efficiency不应直接理解为“同一张显卡上速度快 2.5 倍”。实际吞吐量仍取决于专家并行、KDA 内核、量化格式、跨节点网络和推理框架实现。官方对能力的表述其实比较克制Kimi 官方技术博客明确写道K3 的整体性能仍落后于 Claude Fable 5 和 GPT-5.6 Sol但在其评测套件中超过了其他被测试模型。官方展示的重点不是简单问答而是长时间自主执行在相同沙箱中持续优化 GPU Kernel。从零构建带有 Tile IR、MLIR Pass 和 PTX 代码生成的 MiniTriton 编译器。通过截图反馈迭代前端、3D 游戏和 CAD 任务。在 48 小时自主任务中使用开源 EDA 工具设计并验证芯片原型。阅读论文、编写数值程序并完成端到端科研分析。这些案例能说明模型的目标方向但仍属于厂商提供的案例。代码、完整轨迹、Token 消耗、失败样本和复现环境是否公开会直接影响它们的证据强度。API 计费与 Token 成本边界官方文档列出的基础计费单价如下单位均为每 100 万 Token。这里保留数字是为了计算不同上下文与输出长度下的调用成本计费项文档单价输入 Token命中缓存0.30 美元输入 Token未命中缓存3.00 美元输出 Token15.00 美元上下文窗口1,048,576 TokenKimi 帮助中心还列出 Web Search 每次调用 0.004 美元。不过 K3 文档同时提示Web Search 正在更新近期不建议用于生产流程。进行系统设计时应把模型 Token、工具调用和失败重试分别计量。三个成本例子假设不考虑税费和其他工具费用场景计算费用10 万输入 5000 输出输入未缓存0.1 × $3 0.005 × $150.375 美元同一长前缀命中缓存 5000 输出0.1 × $0.3 0.005 × $150.105 美元100 万输入 10 万输出输入未缓存1 × $3 0.1 × $154.50 美元这里最值得注意的不是输入单价本身而是输出长度和推理过程。K3 当前始终开启思考模式并且只能使用max推理强度。如果一个任务产生大量reasoning_content即使用户最后只看到几百字答案账单也可能主要来自推理和输出 Token。因此K3 当前更适合高价值、长流程任务不适合不加区分地替换所有普通对话接口。现在可执行的 API 接入Kimi API 兼容 OpenAI SDK。Python 3.9 以上环境可以按下面的方式安装python-mvenv .venv# Linux / macOSsource.venv/bin/activate# Windows PowerShell.venv\Scripts\Activate.ps1 python-mpipinstall--upgradeopenai1.0在环境变量中保存 API Key不要把密钥写进代码仓库# Linux / macOSexportMOONSHOT_API_KEY你的 API Key# Windows PowerShell$env:MOONSHOT_API_KEY你的 API Key最小调用代码如下importosfromopenaiimportOpenAI clientOpenAI(api_keyos.environ[MOONSHOT_API_KEY],base_urlhttps://api.moonshot.ai/v1,)responseclient.chat.completions.create(modelkimi-k3,reasoning_effortmax,max_completion_tokens8192,messages[{role:system,content:(你是代码审查助手。先定位高风险问题再给出最小修改方案没有证据时不要猜测。),},{role:user,content:请审查下面的并发任务队列实现并给出修改后的代码。,},],)messageresponse.choices[0].messageprint(message.content)print(response.usage)建议显式设置max_completion_tokens。官方默认值是 131072最高可以设置到 1048576如果业务不需要超长输出不设置上限会放大异常任务的成本风险。流式输出要分别处理推理和答案streamclient.chat.completions.create(modelkimi-k3,reasoning_effortmax,max_completion_tokens8192,streamTrue,stream_options{include_usage:True},messages[{role:user,content:分析这个项目的模块依赖并给出重构顺序。}],)forchunkinstream:deltachunk.choices[0].delta reasoninggetattr(delta,reasoning_content,None)ifreasoning:print(reasoning,end,flushTrue)ifdelta.content:print(delta.content,end,flushTrue)在生产环境中通常不应把完整思考内容直接展示给最终用户。更稳妥的做法是把reasoning_content与最终content分开处理只记录必要的运行指标并遵守业务数据与日志安全要求。多轮对话和工具调用的几个坑K3 虽然使用 OpenAI 兼容接口但不是把模型名替换掉就万事大吉。第一K3 目前只支持reasoning_effortmax。不要继续使用 K2.x 的thinking参数。第二temperature1.0、top_p0.95、n1、presence_penalty0和frequency_penalty0已固定。官方建议从请求中省略这些字段。第三在多轮对话和工具调用中必须把 API 返回的完整 Assistant Message 放入下一轮历史不能只保留content。工具执行结果还必须使用对应的tool_call_id回传。第四视觉输入不支持直接传公网图片 URL应使用 Base64 Data URL 或ms://file-id。第五K3 支持tool_choicenone、auto和required也支持动态加载工具定义。对于高风险操作应在应用层继续保留权限检查和人工确认不能只依赖 Prompt。百万上下文怎么用才不浪费K3 的普通请求会自动尝试上下文缓存不需要手动创建 Cache ID 或指定 TTL。要提高命中率应把不经常变化的内容放在最前面并保持长前缀完全稳定例如固定 System Prompt。固定代码仓库索引或知识库正文。固定工具定义。把每次变化的问题放在消息末尾。不要在长前缀里插入当前时间、随机 ID 或动态排序内容否则很容易破坏缓存复用。生产环境还应记录prompt_tokens、缓存命中 Token、推理 Token、答案 Token、首 Token 延迟和完整任务耗时。百万上下文是容量上限不是每次请求都应该填满的目标。API 接入的工程化注意事项如果暂时不自托管模型可以把 K3 当作外部推理服务在自己的业务侧部署一层轻量网关业务客户端 │ ▼ 鉴权与配额网关 │ ├── Prompt 模板与敏感信息处理 ├── Token 预算、超时与取消 ├── 工具权限与人工确认 ├── 重试、熔断与降级模型 └── Usage、延迟和质量指标 │ ▼ Kimi API上线时至少应增加以下控制将 API Key 放进 Secret Manager而不是镜像或配置文件。给单次请求设置输入、输出和工具调用预算。仅对网络错误、限流和部分 5xx 做带抖动的指数退避不要盲目重试已经执行过外部动作的 Agent 请求。使用流式接口并支持客户端取消避免用户断开后模型继续产生高价输出。对长任务保存状态区分模型失败、工具失败和业务校验失败。为普通聊天准备更便宜的模型只把复杂编程与知识工作路由到 K3。上线前用自己的任务集统计“每个成功任务成本”不要只比较每百万 Token 单价。K3 发布约两天后Hacker News 主讨论帖已经达到约 1995 Points 和 1161 条评论。讨论热度很高但可归纳成四类较稳定的观点。第一类关注点集中在架构和长程任务部分社区讨论认为开放模型与高规格闭源模型之间的差距正在缩小。KDA、AttnRes、896 专家 MoE以及官方展示的 GPU 编译器、芯片设计和长程科研任务是讨论较多的部分。爱范儿的首轮体验也更偏正面其团队使用 K3 完成了多个 Three.js 场景、交互系统和应用原型认为 K3 在前端视觉、交互实现和持续迭代方面表现突出。Code Arena 首发榜单中K3 以 1679 分位于前端代码榜首。不过这类榜单更接近人类偏好盲测能够反映前端成品偏好不能替代后端正确性、可维护性和生产稳定性评测。第二类单位任务成本取决于推理长度社区对 K3 的 Token 消耗存在较多讨论。由于当前只能启用max推理强度静态单价并不能直接代表一个任务最终需要的预算。真正影响成本的是推理 Token。开发者 Simon Willison 分享的一个 SVG 生成案例只有 95 个输入 Token却生成了 16658 个输出 Token其中 13241 个是推理 Token按官方价格约为 0.25 美元。单个案例不能代表平均水平但它很好地说明了“输出偏长”为什么会放大账单。第三类独立评测很强但速度与冗长是现实问题Artificial Analysis 给 K3 的 Intelligence Index 评分为 57在其 7 月 18 日页面收录的 187 个同类模型中排名第 4测得输出速度约为每秒 62 Token低于同类平均的 71 Token。该机构还指出K3 在完整 Intelligence Index 测试中生成约 1.30 亿输出 Token而同类平均约为 6300 万评价是“较慢、非常冗长、价格偏高”。其页面更新后的完整评测模型费用约为 2709.75 美元这类动态统计会随着评测集和计费记录调整。这些数据补充了厂商提供的评测结果但仍不是所有业务的统一答案。编程 Agent、法律分析和普通客服的 Token 分布完全不同最终仍要回到自己的任务集。第四类开放状态仍待权重与许可证确认7 月 18 日再次核对 MoonshotAI 官方 GitHub组织中仍没有 Kimi K3 权重仓库Artificial Analysis 也暂时将其标为 Proprietary Model。原因并不复杂权重尚未发布。官方已经给出 7 月 27 日这一明确期限。届时最需要检查的不是下载按钮而是许可证是否允许商用和再分发、是否提供官方量化版本、主流推理框架是否同步支持以及技术报告能否解释评测与部署细节。对 K3 后续发展的预估短期内K3 更可能首先用于长程编程、前端与视觉联动、复杂报告生成以及需要大上下文的 Agent 任务。普通聊天、短摘要和高吞吐分类任务较难支撑当前的推理成本。官方已经表示后续会增加低和高推理强度。如果这些档位能明显减少推理 TokenK3 的单位任务成本和延迟会获得更大的调节空间。K3 后续能否形成更广泛的开发者生态主要取决于四件事权重与许可证能否按时、完整地发布。KDA 和超稀疏 MoE 能否迅速获得高性能开源推理内核。独立评测和企业实测能否复现官方的长程任务能力。低推理强度与量化版本能否降低单位成功任务的成本。在这些信息公布以前更合适的观察重点仍然是 API 的真实任务表现、推理长度、工具调用稳定性和百万上下文效果而不是提前估算尚不可执行的本地部署方案。参考资料KimiKimi K3: Open Frontier Intelligence2026-07-16https://www.kimi.com/blog/kimi-k3Kimi APIKimi K3 快速上手https://platform.kimi.ai/docs/guide/kimi-k3-quickstartKimi APIKimi K3 官方定价https://platform.kimi.ai/docs/pricing/chat-k3Kimi APIOpenAI API 兼容说明https://platform.kimi.ai/docs/guide/migrating-from-openai-to-kimiMoonshotAI GitHub 组织https://github.com/MoonshotAIArtificial AnalysisKimi K3 Intelligence, Performance Price Analysishttps://artificialanalysis.ai/models/kimi-k3Hacker NewsKimi K3: Open Frontier Intelligence 讨论帖https://news.ycombinator.com/item?id48935342爱范儿连夜实测 Kimi K3建议改名 Kablehttps://www.ifanr.com/1672232新华社Chinese company releases world’s largest open-source AI model2026-07-17https://english.news.cn/20260717/66d0dd4a939b430ab2334c766a92ea93/c.html