Kimi K3 API 指南：价格、1M 上下文、模型 ID 与生产选型
快速结论： Kimi K3 已经正式发布，不再是传闻中的模型名称。Moonshot 已公布直连 API 模型 ID、价格、架构概述、多模态能力和 1,048,576 token 上下文。它主要面向长程软件工程、端到端知识工作和深度推理，而不是低成本的日常对话。
Kimi K3 核心信息
下表只收录 Moonshot 截至 2026 年 7 月 16 日正式文档确认的信息。
| 项目 | Kimi K3 官方信息 | 对开发者的意义 |
|---|---|---|
| Moonshot 直连模型 ID | kimi-k3 | Moonshot 用户可使用该直连路由，但这不代表 EvoLink 路由已经确认 |
| 参数规模 | 2.8 万亿参数 | K3 是超大规模旗舰模型，但官方尚未公开完整的自部署架构细节 |
| 核心架构 | Kimi Delta Attention + Attention Residuals | 重点改善效率、长上下文和长程推理 |
| 上下文窗口 | 1,048,576 tokens | 能容纳更大的代码仓库、文档集合、工具历史和长任务状态 |
| 输入模态 | 文本、图片和视频 | 可用于代码截图、架构图、设计评审、文档和多模态研究 |
| 推理模式 | 始终开启 | 轻量请求可能承担不必要的延迟和输出成本 |
| 推理控制 | 发布时仅支持 reasoning_effort="max" | 暂时不能选择更快、更便宜的推理档位 |
| 工具控制 | Tool Calling、tool_choice、动态加载工具 | 适合拥有大量工具或动态工具目录的 Agent |
| 结构化输出 | JSON Mode 和严格 JSON Schema | 适用于信息提取、工作流状态和机器可读结果 |
| 上下文缓存 | 自动启用 | 稳定的长前缀命中缓存后，可以显著降低输入成本 |
| 开源权重 | 官方来源暂未确认 | 目前不要把 K3 描述成开源或可自行部署模型 |
Kimi K3 模型 ID 取决于接入渠道
K3 并不存在一个可以在所有产品中通用的模型字符串。Moonshot 开放平台 API 与 Kimi Code 订阅产品使用不同的模型 ID、上下文权益和计费方式。
| 接入渠道 | 模型 ID | 上下文与权限 | 计费方式 |
|---|---|---|---|
| Moonshot 开放平台 API | kimi-k3 | 直连 API，官方文档最高 1,048,576 tokens | 按 token 计费 |
| Kimi Code | k3 | Moderato 最高 256K；Allegretto 及以上最高 1M | 会员额度 |
| Kimi Code 标准编程模型 | kimi-for-coding | K2.7 Code，最高 256K | 会员额度 |
| Kimi Code 高速编程模型 | kimi-for-coding-highspeed | K2.7 Code 高速版，最高 256K | Allegretto 及以上，额度消耗更快 |
| EvoLink | 尚未公布 | 预计 2026 年 7 月 17 日完成验证上线 | EvoLink 价格尚未公布 |
kimi-k3；在支持 Kimi Code 的编程客户端中使用 k3。尤其需要注意，kimi-for-coding 对应的是 K2.7 Code，并不是 K3 的别名。Kimi Code 套餐也解释了为什么不同开发者选择 K3 后看到的上下文长度不同：官方说明 Andante 不支持 K3，Moderato 的 K3 上限为 256K，Allegretto 及更高套餐才可使用最高 1M 上下文。
K3 相比 K2 系列改变了什么？
K3 不是简单地把 K2.6 上下文扩大到 1M。Moonshot 将它描述为当前能力最强的模型，并明确公布了 Kimi Delta Attention 混合线性注意力与 Attention Residuals 的架构组合。
对产品团队来说，更值得关注的是实际工作负载变化：
| 维度 | K2.6 基线 | K3 变化 | 产品影响 |
|---|---|---|---|
| 上下文 | 262,144 tokens | 1,048,576 tokens | 可以处理更大的仓库、文档集合、工具记录和多轮任务 |
| 推理模式 | 可以开启或关闭 Thinking | 始终开启推理 | 更聚焦困难任务，但轻量请求缺少成本控制空间 |
| 推理参数 | K2 系列使用 thinking | K3 使用顶层 reasoning_effort | 迁移不能只替换模型字符串 |
| 工具目录 | 标准 Tool Calling | 新增 tool_choice 与动态工具加载 | Agent 可以只加载当前真正需要的工具 |
| 模型定位 | 通用多模态与 Agent 模型 | 软件工程和知识工作的旗舰模型 | 应优先用最困难的真实任务测试，而不是只跑聊天提示词 |
reasoning_effort，不要继续发送 K2.x 的 thinking 参数。因此，仅仅更换 model 字段并不等于完成迁移。哪些团队应该优先评估 Kimi K3？
当完成一个高难任务的业务价值远高于 token 成本时，K3 才最容易体现价值。
| 团队或工作负载 | 评估优先级 | 原因 |
|---|---|---|
| 需要处理大型代码仓库的 Coding Agent 团队 | 高 | 1M 上下文和长程任务定位直接匹配仓库级工作 |
| 需要综合大量长文档的研究产品 | 高 | 更大的上下文与结构化输出可以减少手动切片和编排 |
| 拥有大量工具的 AI 基础设施团队 | 高 | 动态工具加载和强制工具调用能解决真实的工具选择问题 |
| 多模态评审与知识工作 | 中高 | K3 可以同时接收文本、图片和视频 |
| 高并发客服聊天 | 初期较低 | 始终推理和高输出价格可能没有必要 |
| 分类、打标签和短文本提取 | 初期较低 | 更轻量的模型通常具备更好的成本和延迟表现 |
| 私有部署或开源权重方案 | 等待 | 官方尚未确认 K3 权重和许可证 |
因此，不能仅凭某个 Benchmark 标题决定 K3 的生产价值。团队需要衡量它是否减少了重试、人工修改和模型升级次数，或者完成了便宜模型无法完成的任务。
Moonshot API 价格与实际成本
Moonshot 对 K3 整个上下文范围采用统一价格，没有按短上下文和长上下文分档：
| Token 类型 | Moonshot 直连价格（每百万 token） |
|---|---|
| 缓存命中输入 | ¥2 |
| 缓存未命中输入 | ¥20 |
| 输出 | ¥100 |
以上是 Moonshot 官方直连 API 价格，并不是 EvoLink 价格。在 EvoLink 路由、供应渠道、计费封装和生产行为完成验证前，不能提前发布 EvoLink 的 K3 报价。
不要混用三套不同的价格口径：
- Moonshot 开放平台采用上表的 token 计费；
- Kimi Code采用会员额度与套餐权益，不等同于直连 API 单价；
- 第三方网关或聚合平台自行决定供应渠道、可用性和价格。Reddit、X 等社区出现的美元报价可以说明市场关注点，但不能作为 Moonshot 官方价格或未来 EvoLink 价格。
常见调用成本示例
以下示例按照 Moonshot 直连价格计算，不包含重试、工具费用、存储、税费、网关价格或失败请求成本。
| 请求规模 | K3 未缓存价格估算 | 输入命中缓存后的估算 |
|---|---|---|
| 20K 输入 + 5K 输出 | ¥0.90 | ¥0.54 |
| 100K 输入 + 20K 输出 | ¥4.00 | ¥2.20 |
| 500K 输入 + 50K 输出 | ¥15.00 | ¥6.00 |
| 1M 输入 + 100K 输出 | ¥30.00 | ¥12.00 |
缓存会显著改变长上下文成本。例如，稳定的 500K token 代码库或知识前缀，第一次未缓存输入约 ¥10，命中缓存后输入部分约 ¥1。不过输出仍然昂贵，因此仍需控制工具循环、回答长度、重试策略和最大输出预算。
K3 与 K2.6 直连价格对比
| 模型 | 缓存输入/MTok | 未缓存输入/MTok | 输出/MTok | 上下文 |
|---|---|---|---|---|
| Kimi K2.6 | ¥1.10 | ¥6.50 | ¥27 | 262,144 |
| Kimi K3 | ¥2.00 | ¥20.00 | ¥100 | 1,048,576 |
K3 未缓存输入约为 K2.6 的 3.1 倍，输出约为 3.7 倍。这意味着更合理的生产策略是：普通任务使用成本更低的模型，只在任务难度、上下文规模或工具复杂度需要时升级到 K3。
真正应该计算的是“成功任务成本”
标价只是成本的一部分。只要高级模型能减少重试或完成便宜模型无法完成的工作，它仍然可能更经济。反过来，如果模型对简单任务过度思考并生成很长的答案，即使能力很强，也未必适合作为默认路由。
建议重点记录：
| 指标 | 能说明什么 |
|---|---|
| 首次任务成功率 | K3 是否减少重试和人工介入 |
| 补丁或交付物通过率 | 生成结果能否通过实际代码或业务评审 |
| 工具调用准确率 | 是否选对工具并构造正确参数 |
| 上下文缓存命中率 | 长前缀是否获得预期成本优势 |
| 每个成功任务的输出 token | 始终推理是否带来过多输出成本 |
| 获得可接受结果的总时间 | 更强推理是否抵消了生成速度差异 |
| 回退与恢复比例 | 路由能否稳定承载生产流量 |
真正有用的比较不是“谁的 token 单价最低”，而是“哪个路由能在满足延迟和可靠性要求的前提下，以最低的可接受结果成本完成任务”。
开发者控制：推理、工具调用与多模态输入
推理行为与请求参数
K3 始终开启推理。Moonshot 官方文档说明：
- K3 使用
reasoning_effort控制推理； - 当前只支持
max档位； - 不要对 K3 使用 K2.x 的
thinking参数； - 流式响应会分别返回推理增量
reasoning_content和最终答案content； - 多轮对话和工具调用必须把完整的 assistant message 原样加入下一次请求。
最后一条是 Agent 集成中最容易被忽略的问题。如果应用只保存最终文本，丢弃推理字段或工具调用信息，后续轮次可能无法保留模型所需的任务状态。
top_p、惩罚参数或一次生成多个候选。相比反复调参数，提示词设计、任务拆分和应用层模型路由会更加重要。Tool Calling 是 K3 最值得关注的开发者能力
K3 新增了两个对生产 Agent 非常实用的控制：
tool_choice：可以强制模型先调用工具，避免在必须检索或执行操作时直接凭记忆回答。- 动态工具加载：只有在相关工具真正需要时，才把定义注入对话。
大型工具目录可以采用以下流程：
| 阶段 | 应用动作 | 价值 |
|---|---|---|
| 初始化 | 只提供工具搜索函数和少量通用工具 | 减少首轮 Prompt 大小 |
| 检索 | 对需要外部操作的任务强制先搜索工具 | 减少脱离数据的直接回答 |
| 加载 | 只注入选中的完整工具定义 | 提升工具选择准确率并节省上下文 |
| 执行 | 使用匹配的 tool call ID 返回工具结果 | 正确维持 Agent 循环 |
| 继续 | 在历史中保留完整 assistant message | 保留推理、工具和任务状态 |
这不仅是 token 优化。大量功能相似的工具会干扰模型选择，动态加载可以把“寻找正确工具”变成 Agent 架构的一部分。
多模态输入及当前限制
K3 支持文本、图片和视频，但 Moonshot 直连接口存在明确规则：
- 视觉消息的
content必须使用对象数组； - 官方 K3 快速开始暂不支持公网图片 URL；
- 图片可以使用 base64 数据；
- 上传文件可通过 Moonshot 的
ms://文件引用； - 视频可以先上传，再作为文件输入。
这些属于 Moonshot 直连接口行为。未来 EvoLink 路由的文件上传方式、URL 支持和兼容层可能不同，不能提前假设两套接口完全一致。
长上下文、缓存与常见接入问题
1M 上下文不等于可以忽略上下文工程
百万 token 窗口让更大任务成为可能，但并不代表放进去的每个 token 都有价值。把整个仓库、全部工具定义、完整日志和所有历史一次性发送，依然可能增加成本、延迟与干扰。
更合理的做法是：
| 上下文策略 | 适用方式 |
|---|---|
| 稳定缓存前缀 | 仓库规范、架构文档和长期知识资料 |
| 生成前检索 | 大型文档库中只有部分内容与当前任务相关 |
| 动态工具定义 | 工具数量很大的 Agent |
| 上下文检查点 | 需要恢复、复盘和人工审核的长任务 |
| 输出预算 | 防止复杂推理产生不必要的长输出 |
| 压缩与总结 | 保留关键决策，移除已经失效的执行细节 |
最有效的 K3 工作流，未必会使用完整的 1M 上下文。
为什么 Kimi K3 只显示 256K、返回 401 或额度消耗变高？
发布初期的多个高频问题，实际来自混淆 Moonshot API 行为与 Kimi Code 会员行为。
| 现象 | 常见原因 | 排查方式 |
|---|---|---|
| K3 只显示 256K 上下文 | Kimi Code 账号是 Moderato，或客户端仍使用较低的默认上下文 | 检查套餐；Kimi Code 的 1M 权益需要 Allegretto 及以上，部分客户端还需把上下文设置为 1048576 |
| 请求返回 401 | 当前 Kimi Code 套餐不包含所选模型或上下文权益 | 核对会员档位，升级后重新登录或刷新鉴权 |
| 模型选择器里没有 K3 | 编程客户端缓存了旧的模型列表 | 更新或重启客户端，并选择 k3，不要误选 kimi-for-coding |
| 切换 K3 后额度消耗突然增加 | Kimi Code 切换模型后不会沿用之前模型的上下文缓存 | 切换模型时新建会话，避免把超长旧会话直接带入 K3 |
reasoning_effort 返回 400 | 参数值不受支持，或请求发到了错误的 API 渠道 | Moonshot 直连 K3 当前使用官方支持的 max |
| 后续轮次丢失状态或工具上下文 | 应用只保存最终文本，没有保留完整 assistant message | 保留推理字段、Tool Calls 和完整 assistant 响应 |
部分第三方 Coding 客户端还会提供自己的上下文设置。账号具备 1M 权益，不代表所有客户端都会自动发送最大上下文。
生产评估与待确认事项
目前仍未确认的事项
Moonshot 的 K3 API 文档已经相当完整，但仍有一些重要问题需要继续观察：
| 待确认问题 | 当前安全结论 |
|---|---|
| 官方完整 Benchmark 表 | 本次核对的发布文档中没有可复现的完整 K3 Benchmark 表 |
| 独立第三方评测 | 需要等待使用一致 Harness 的独立测试 |
| 开源权重 | 官方来源暂未确认 |
| 开源许可证 | 不能根据旧版 Kimi 模型推断 K3 许可证 |
| 激活参数量和专家结构 | K3 快速开始文档没有公开 |
| 真实长上下文检索质量 | 必须使用代码仓库和长文档任务验证，而不是只看窗口长度 |
| 发布期 API 延迟 | 需要按上下文规模和时间持续测量 |
| 失败请求计费 | 需要结合最新政策和真实账单核对 |
| EvoLink 模型 ID 与价格 | 需要等待 EvoLink 完成路由验证 |
社区第一批演示认为 K3 在编程和 Web 构建上表现强劲，同时也出现了速度慢、过度思考和发布首夜报错的反馈。这些只能用于设计测试用例，不能作为正式模型事实或生产保证。
Kimi K3 生产评估步骤
不要只用一个效果惊艳的 Prompt 评估 K3。应该建立能代表真实客户价值的小型任务集。
第一步：建立当前基线
选择 20–50 个真实任务，覆盖：
- 代码仓库理解；
- 多文件代码修改；
- Bug 定位；
- 长文档综合分析；
- 结构化数据提取；
- 多模态评审；
- 多步工具调用。
记录当前模型的成功率、延迟、输入输出 token、重试次数和人工审核时间。
第二步：测试 Moonshot 直连 K3
如果直连测试符合团队的采购、数据与区域要求，可以使用 Moonshot 官方路由。保持提示词、工具和验收标准一致，并分别记录首次未缓存成本和后续缓存成本。
第三步：决定未来的路由角色
K3 不需要替换所有基线模型才有价值。它可以作为：
- 便宜模型失败后的升级路由；
- 仓库级 Coding Agent 模型；
- 长文档综合分析模型；
- 工具密集型任务的专用模型；
- 用户主动选择的高级模型。
第四步：EvoLink 接入后重新验证
当 EvoLink 发布经过验证的 K3 路由后，需要重新执行一组兼容性测试：
- 模型 ID 和请求结构；
- 推理字段保留；
- 流式输出；
- Tool Calling 和结构化输出；
- 图片、视频输入；
- 1M 上下文处理；
- 缓存与账单统计；
- 超时、重试和模型回退。
EvoLink 用户现在应该怎么准备？
EvoLink 的价值不是把每个新模型立刻变成默认路由，而是让模型选择、成本控制、供应商回退和迁移变得更简单。
K3 尚未接入期间，团队可以：
- 查看 EvoLink 当前模型目录，不要假设不存在的 K3 路由。
- 建立可重复运行的业务验收集，等待 K3 接入后直接复测。
- 把模型选择放进配置层，不要在业务代码中写死单一供应商。
- 为高级模型设置明确的成本和延迟升级阈值。
- 阅读 AI 模型路由指南，设计多模型选择逻辑。
- 关注 Kimi K3 在 EvoLink 的接入状态。
真正的生产机会是模型可选性：普通任务使用经济路由，高难任务使用高级推理，并在某个供应商变慢或不可用时保留回退路径。
常见问题
Kimi K3 正式发布了吗？
是。Moonshot 已于 2026 年 7 月 16 日在官方模型列表、快速开始、价格页面和直连 API 示例中公布 Kimi K3。
Kimi K3 官方模型 ID 是什么？
kimi-k3。这不代表未来 EvoLink 一定使用相同的路由名称。Kimi Code 的 k3 和 kimi-k3 是同一个模型吗？
kimi-k3，Kimi Code 使用 k3；接口、计费方式和套餐限制不同。kimi-for-coding 是 Kimi K3 吗？
kimi-for-coding 标记为 K2.7 Code。客户端和会员套餐支持 K3 时，应选择 k3。为什么 Kimi Code 中的 K3 只有 256K？
1048576。为什么调用 K3 会返回 401？
401 可能代表当前会员档位不包含所请求的模型或上下文权益。请先核对套餐，刷新登录状态，并在新会话中重试。
为什么切换到 K3 后额度消耗更快？
Kimi Code 官方说明切换模型后不会复用原模型的上下文缓存。切换到 K3 时新建会话，可以避免把长历史带到无法沿用旧缓存的新路由。
Kimi K3 上下文有多长？
Moonshot 官方文档给出的上下文窗口是 1,048,576 tokens。
Kimi K3 支持图片和视频吗？
支持。Moonshot 文档确认 K3 可以接收文本、图片和视频。直连 API 的视觉输入需要使用官方规定的 base64 或文件格式。
Kimi K3 可以关闭推理吗？
reasoning_effort 当前也只支持 max。Kimi K3 API 价格是多少？
Moonshot 直连价格为：缓存输入 ¥2/百万 token、未缓存输入 ¥20/百万 token、输出 ¥100/百万 token。这不是 EvoLink 价格。
Kimi K3 开源了吗？
本次核对的官方发布来源中没有找到 K3 权重与许可证。Moonshot 正式发布权重和许可证前，不应将其描述为开源模型。
Kimi K3 可以在 EvoLink 使用吗？
是否应该用 K3 替换 K2.6 或现有模型？
不应该直接全部替换。K3 的 Moonshot 直连价格明显更高，应先测试长上下文、编程、研究、多模态和工具密集型任务，再决定它适合做专用、升级还是高级路由。
开发者应该先测试什么？
优先测试目前受限于仓库规模、文档数量、长工具历史或复杂推理的任务，并记录成功任务成本与人工修改量。
参考来源
- Moonshot：Kimi K3 快速开始与模型介绍
- Moonshot：Kimi K3 直连 API 定价
- Moonshot：当前模型列表
- Moonshot：模型参数参考
- Moonshot：Kimi K3 工具调用最佳实践
- Moonshot：直连 API 限速档位
- Kimi Code：模型 ID、套餐、上下文限制与切换行为
社区讨论仅用于识别开发者的测试问题和早期采用顾虑。本文中的模型事实、价格、模型 ID、限制和 API 行为均以 Moonshot 官方文档为依据。
