模型解读

Kimi K3 API：为什么 1M 上下文改变了模型路由

Kimi K3 集 2.8T 参数、1M 上下文、稀疏 MoE 与 API 接入于一身。本文拆解定价、缓存、路由与部署的取舍。

Kimi K3 带着两个天生适合上头条的数字登场：2.8 万亿参数，以及 100 万 token 的上下文窗口。

但对一个生产团队来说，更有用的数字是 10。

在 Moonshot 官方的 Kimi K3 API 上，缓存未命中的输入 token 价格是缓存命中的十倍。而影响更深远的要求根本不是数字：多轮对话和工具调用应用必须完整保留 assistant 消息，包括推理内容和工具状态。

这让 Kimi K3 不只是一个新的模型 ID。它把上下文布局、缓存稳定性、会话持久化和任务边界路由，变成了实打实的生产架构问题。

核心要点

Moonshot 将 Kimi K3 描述为 2.8T 参数、开放的 3T 级模型，具备原生视觉能力和 1,048,576 token 的上下文窗口
截至核查时，K3 已可通过 Kimi 产品和 Moonshot 的 API 使用，完整权重则计划在 2026 年 7 月 27 日前发布
模型从 896 个专家中激活 16 个，因此总参数量并不等于每个 token 的实际激活计算量
官方 API 定价：缓存命中输入每 1M token $0.30，缓存未命中输入每 1M token $3.00，输出每 1M token $15.00
K3 目前始终以 max 档推理，并要求在多轮对话和工具调用循环中完整保留 assistant 消息
Moonshot 警告：缺失思考历史，或把已有会话中途切换到 K3，都可能导致质量不稳定
本文核查时，K3 尚未出现在 Velokey 的实时模型目录中。不要臆测模型 ID，先验证实时可用性

Kimi K3 现状：已确认、待发布与不可用

围绕一次重大模型发布的信息源，往往把几种不同的状态压缩成一个词：已发布。

对 Kimi K3 来说，这些状态需要分开看。

事项	2026 年 7 月 17 日的状态
Kimi 应用与产品	可用
Moonshot 官方 API 模型 `kimi-k3`	可用
完整模型权重	计划于 2026 年 7 月 27 日前发布
最终开源权重许可证	在已审阅的发布材料中尚未确认
完整的 Kimi K3 技术报告	待发布
通过 Velokey 使用 Kimi K3	核查时未上架

Moonshot 的 Kimi K3 发布页称它是 3T 级别的首个开放模型。这是提供方自己的说法。当前更实际的区别在于：开发者已经可以通过 Moonshot 的 API 调用 K3，而计划本地部署的团队仍在等真正的权重、许可证、模型卡和技术报告。

如果本文在 7 月 27 日之后更新，应重新核查权重发布状态。计划发布，和一个可下载、有许可证的产物，不是一回事。

2.8T 参数在实践中意味着什么

Kimi K3 结合了 Kimi Delta Attention、Attention Residuals 和 Stable LatentMoE 架构。Moonshot 表示，模型在一次请求中会从 896 个专家中激活 16 个。

这改变了参数量这个头条数字的读法。

Kimi K3 关键规格：2.8 万亿总参数、896 个专家中实际激活 16 个、1,048,576 token 上下文窗口，以及原生视觉能力。

*Moonshot 公布的规格：2.8T 总参数、896 个专家中实际激活 16 个、1,048,576 token 上下文窗口，以及原生视觉能力。*

2.8T 的总参数量描述的是模型的整体容量，并不意味着每个 token 都会用到全部参数。稀疏专家激活正是让超大模型在不为每一步支付稠密模型全额计算成本的前提下，释放更多容量的机制。

Moonshot 还宣称整体扩展效率约为 Kimi K2 的 2.5 倍。这是提供方自报的架构成绩，不是独立的生产环境测量，但它点明了真正的工程目标：让一个超大模型能胜任长程任务，而不只是把它做大。

K3 还内置原生视觉理解，定位覆盖编码、知识工作、推理、图像和视频。这些能力拓宽了可能的 API 工作负载范围，但并不能告诉团队哪些负载在经济上划算。

答案要从上下文、输出、延迟和工具行为里找。

为什么 1M token 窗口不能取代上下文工程

Kimi 官方定价页列出的上下文窗口为 1,048,576 token。

这是很大的容量，但不是让你把每个请求都塞满的指令。

一个长时间运行的编码或研究 agent 会不断累积：

系统指令
权限与安全规则
工具定义
仓库文件与文档
检索到的证据
用户消息
assistant 推理内容
工具调用及其结果
重试、纠正和被放弃的分支

上下文也许装得下，任务却仍会变得更慢、更贵、更难控制。

长上下文把核心问题从"装不装得下"变成了"什么值得留在现场"。

一个生产会话应该分出四个层次：

稳定前缀： 持久的指令、固定的知识，以及被频繁复用的工具定义。
任务工作集： 当前目标所需的文件、证据、图像和工具。
完整会话状态： 维持推理与工具连续性所必需的消息。
可重启检查点： 经过验证的摘要，让任务无需永远背着所有失败分支也能恢复。

Kimi K3 的四层上下文架构：稳定前缀、任务工作集、完整会话状态和可重启检查点。

*只有把稳定指令、活跃工作集、完整会话状态和重启检查点分开管理，长上下文在运维上才真正有用。*

百万 token 窗口给了团队更多空间，但它取代不了检索、压缩、检查点和 token 预算。

Kimi K3 定价如何改变提示词架构

Moonshot 官方的 K3 定价如下：

缓存命中输入： 每 1M token $0.30
缓存未命中输入： 每 1M token $3.00
输出： 每 1M token $15.00

价格不含相关税费，且可能变动。采购前请核实官方页面的实时价格。

基本成本模型是：

input cost = cache-hit MTok x $0.30 + cache-miss MTok x $3.00
output cost = output MTok x $15.00

Kimi K3 官方 API 定价对比：缓存命中输入每百万 token $0.30，缓存未命中输入每百万 token $3.00，输出每百万 token $15.00。

*2026 年 7 月 17 日核查的定价显示，缓存命中与未命中的输入费率相差 10 倍，前缀稳定性因此成为一种成本控制手段。以上是 Kimi 官方 API 费率，不是 Velokey 定价；价格可能变动。*

十倍的输入价差，让提示词结构成为成本架构的一部分。

Kimi 的上下文缓存是自动的，没有需要手动管理的缓存 ID 或 TTL。API 会尝试复用重复出现的起始上下文，例如系统提示词、知识文档和工具定义。

但自动不等于保证。

如果应用在每次调用时改动提示词开头、重排工具顺序、往前缀里注入时间戳，或者以不同顺序序列化同一份知识，就可能把本可复用的上下文变成缓存未命中。

Moonshot 表示官方 API 在编码负载中的缓存命中率超过 90%。把它当成提供方自报的结果就好，而不是对另一个应用的承诺。生产团队该信的数字，是在自家流量上量出来的那一个。

至少要跟踪：

缓存命中输入 token
缓存未命中输入 token
推理与最终答案的输出 token
首 token 时间
总响应延迟
工具调用次数
重试率
每完成任务的成本

对 agent 来说，只看单次请求的价格是不够的。一个用户目标可能触发几十次模型调用、工具调用、重试和验证步骤。

为什么保留思考内容会改变模型路由

Kimi K3 始终进行推理。API 目前只支持 reasoning_effort="max"，响应中除最终的 content 外，还可能包含 reasoning_content。

对于多轮对话和工具调用，Kimi 的文档要求把完整的 assistant 消息加入下一次请求。开发者不应只保留可见的答案——返回的消息里可能还带着维持连续性所必需的推理和工具调用字段。

这同时影响成本和路由。

历史推理内容会持续占用上下文窗口并计入 token 消耗。因此，一个长 agent 会话的增长来源，不只是用户消息和文档。

这也意味着模型选择不能安全地当作无状态操作。

Moonshot 警告：当调用框架未能回传完整的思考历史，或者把另一个模型正在进行的会话中途切到 K3 时，K3 的质量可能变得极不稳定。

更安全的生产规则很简单：

> 在任务或会话边界做路由，然后把选中的模型固定住，直到一个刻意设置的检查点。

如果模型或提供方在任务中途失效，就构建一个重启包，包含已验证的事实、已完成的操作、当前文件、悬而未决的决策和剩余目标。让替换模型从这份显式状态启动，而不是在同一个工具循环里悄悄换掉模型 ID。

会话感知的模型路由：从任务分类和模型选择，到会话固定、稳定上下文、完整状态保留、工具循环、遥测，以及基于检查点的模型切换。

*在任务边界选定模型，在整个工具循环中固定它，只在刻意设置的检查点之后或新会话中更换模型。这是一条生产建议，不是 Kimi 官方的路由架构。*

这就是请求级路由和会话级路由的区别。

Kimi K3 在多模型体系中的位置

K3 的最大档推理模式，让工作负载分层从第一天起就很重要。

工作负载	Kimi K3 适配度	生产判断
仓库级编码	强候选	使用稳定的调用框架，保留状态，度量工具成功率。
复杂多工具研究	强候选	监控重试、证据质量和上下文增长。
视觉工程任务	候选	用真实的图像、视频、UI、CAD 或调试工作流来测试。
高价值知识综合	候选	当答案价值配得上长推理和输出成本时再用。
分类与打标签	弱默认	更便宜的模型往往更高效。
抽取与简单改写	弱默认	最大档推理通常是不必要的开销。
低延迟聊天	不明确	实测首 token 时间和总延迟。
自主生产操作	有条件	加上最小权限、沙箱、审批关卡和日志。

Moonshot 把过度主动列为当前的局限之一。当长任务遇到歧义或小障碍时，K3 可能做出出人意料的决定。

这让权限设计和提示词设计同样重要：

把读权限和写权限分开
API 密钥和生产凭证只放在服务端
破坏性或对外操作必须经过审批
定义明确的停止条件
记录每一次工具操作请求及其结果
评估恢复行为，而不只是成功的运行

能力最强的模型，不应自动获得最宽的权限。

Kimi K3 API vs 自托管

计划中的开源权重发布让本地部署进入了讨论范围，但这并不意味着本地部署自动胜出。

Moonshot 表示 K3 采用量化感知训练，权重为 MXFP4、激活为 MXFP8。官方建议使用 64 个及以上加速器的超节点配置进行部署。

这是建议值，不是公布的硬性下限，但已足以说明：全量 K3 推理服务是一个集群级的基础设施项目。

满足以下条件时，托管 API 是更务实的第一步：

流量处于早期或波动较大
团队想在采购基础设施前先验证质量
上线速度很重要
团队没有能力运维大型分布式推理栈
产品需要把 K3 和其他多个模型做对比

以下情况下，自托管才更站得住脚：

最终许可证允许预期用途
数据主权要求必须本地掌控
负载足够持续，值得配备专用算力
组织已经在运维大模型基础设施
团队能管好利用率、批处理、缓存、升级和故障恢复

权重开放，不等于硬件、网络、闲置算力、可观测性和工程时间都免费。

最稳妥的顺序是：先用 API 评估，再做基础设施投入。

Kimi K3 agent 的生产检查清单

在把生产流量发给 K3 之前，先回答这些问题。

工作负载适配

任务是否需要长程推理、大上下文、视觉或复杂工具？
结果的价值是否配得上最大档推理和输出 token 的成本？
首轮的分类、抽取或改写能否交给更便宜的模型？

会话设计

模型是否在任务全程被固定？
完整的 assistant 消息是否被存储并回放？
工作流失败后能否从检查点重启？
工具定义是否只在需要时才加载？

成本与延迟

输入 token 中缓存命中占多大比例？
推理历史增长得有多快？
首 token 时间和任务总时长是多少？
有多少开销来自重试和失败的工具调用？
按被采纳的结果算成本是多少，而不只是按请求算？

安全与运维

哪些操作需要人工审批？
凭证是否只存放在服务端？
破坏性操作是否默认被拦截？
工具调用、错误、token 用量、延迟和开销是否可观测？

评估

在真实工作负载上，K3 是否胜过一个强基线？
相对更便宜的基线，优势是否大到值回成本？
任务换到另一个模型上重启时会发生什么？
模型多久需要一次人工纠正？

评估的产出应该是一条质量-成本-延迟的边界曲线，而不是单个基准分数。

如何准备 OpenAI 兼容客户端，而不臆造模型 ID

本文核查时，Kimi K3 尚未出现在 Velokey 的实时目录中。可用性随时可能变化，所以在写集成代码之前，先查看实时模型目录并查询 models 端点。

不要根据一篇博客去猜模型 ID。

下面的示例列出一个 Velokey 账户当前可用的模型 ID，它不假设 K3 已经存在。

import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["VELOKEY_API_KEY"],
    base_url="https://api.velokey.ai/v1",
)

for model in client.models.list().data:
    print(model.id)

把 API 密钥放在服务端环境变量里。如果 GET /v1/models 里没有出现 Kimi K3 的模型 ID，说明该账户还无法通过 Velokey 使用它。继续用已验证可用的模型或官方 Kimi API，而不要硬编码一个未上架的 ID。

一旦新模型上架，OpenAI 兼容客户端能减少迁移工作。但应用仍然需要针对具体模型的评估、会话规则和遥测。接口兼容抹不平行为差异。

什么时候 Kimi K3 值这个钱

当一项任务对人来说很昂贵、难以拆分，且价值足以支撑一条长推理链时，Kimi K3 最有吸引力：大型重构、多工具研究任务、多模态工程工作流，或需要持续综合的复杂文档集。

把它当万能默认就没那么划算了。分类、抽取、打标签、简单改写和例行支持，正是多模型体系应该守住预算的地方。

生产决策不应只看 2.8T 这一个数字，而应基于缓存命中率、每完成任务的成本、会话稳定性、工具成功率、延迟、恢复行为和人工纠正频率。

这才是 Kimi K3 API 真正的故事：模型确实很大，但决定它是否好用的，是围绕它的会话架构。

Kimi K3 API 常见问题

Kimi K3 现在完全开源了吗？

截至 2026 年 7 月 17 日，Moonshot 表示完整模型权重将在 7 月 27 日前发布。K3 已经可以通过 Kimi 产品和官方 API 使用。在后续文章中把它描述为可下载之前，请先核实仓库、许可证、模型卡和技术报告。

Kimi K3 的上下文窗口有多大？

Moonshot 列出的是 1,048,576 token。大窗口增加了容量，但检索、缓存、历史控制和检查点依然不可或缺。

Kimi K3 官方 API 价格是多少？

Moonshot 的定价为：缓存命中输入每 1M token $0.30，缓存未命中输入每 1M token $3.00，输出每 1M token $15.00，不含相关税费。

Kimi K3 每个 token 都会用到全部 2.8T 参数吗？

不会。Moonshot 表示 Stable LatentMoE 架构从 896 个专家中激活 16 个。总参数量描述的是容量，稀疏激活限制了实际参与计算的部分。

可以在 Kimi K3 会话中途切换模型吗？

要谨慎。Moonshot 警告：思考历史不完整，或把另一个模型正在进行的会话切到 K3，都可能导致生成不稳定。请在会话边界做路由，或从已验证的检查点重启。

Velokey 上可以用 Kimi K3 吗？

本文于 2026 年 7 月 17 日核查时尚未上架。请通过实时模型目录和 GET /v1/models 确认当前账户级的可用性，不要依赖一篇静态博客的说法。

参考来源

披露：本文由 Velokey 发布，Velokey 为多家提供方的模型提供 OpenAI 兼容的 API 接入层。截至审阅时，Kimi K3 尚未出现在 Velokey 的实时目录中。

想用一个客户端对接当前和未来的模型选项，又不想臆造 ID？跟着 [Velokey 快速上手](https://docs.velokey.ai/quickstart)走一遍，然后只选择 GET /v1/models 返回的模型。