如何在 EvoLink 使用 Kimi K3：接入与迁移指南
快速结论： Kimi K3 已经正式发布，不再是传闻中的模型名称。Moonshot 已公布直连 API 模型 ID、价格、架构概述、多模态能力和 1,048,576 token 上下文。它主要面向长程软件工程、端到端知识工作和深度推理，而不是低成本的日常对话。
kimi-k3 生产路由在 EvoLink 上线。请在 Kimi K3 模型页查看当前价格与工作负载定位，并按照 EvoLink API 文档使用最新请求结构。上线状态文章继续保留为发布记录。Kimi K3 核心信息
下表只收录 Moonshot 截至 2026 年 7 月 27 日正式资料确认的信息。
| 项目 | Kimi K3 官方信息 | 对开发者的意义 |
|---|---|---|
| Moonshot 直连模型 ID | kimi-k3 | Moonshot 用户可使用该直连路由，但这不代表 EvoLink 路由已经确认 |
| 参数规模 | 2.8 万亿总参数，每 Token 激活 1040 亿 | 稀疏激活提高计算效率，但完整专家权重仍需要生产级存储和服务能力 |
| 核心架构 | Kimi Delta Attention + Attention Residuals | 重点改善效率、长上下文和长程推理 |
| 上下文窗口 | 1,048,576 tokens | 能容纳更大的代码仓库、文档集合、工具历史和长任务状态 |
| 输入模态 | 文本、图片和视频 | 可用于代码截图、架构图、设计评审、文档和多模态研究 |
| 推理模式 | 始终开启 | 轻量请求可能承担不必要的延迟和输出成本 |
| 推理控制 | reasoning_effort 支持 low、high、max，默认 max | 可在不关闭推理的前提下评估质量、延迟与输出成本 |
| 工具控制 | Tool Calling、tool_choice、动态加载工具 | 适合拥有大量工具或动态工具目录的 Agent |
| 结构化输出 | JSON Mode 和严格 JSON Schema | 适用于信息提取、工作流状态和机器可读结果 |
| 上下文缓存 | 自动启用 | 稳定的长前缀命中缓存后，可以显著降低输入成本 |
| 开放权重 | 约 1.56 TB 完整仓库，采用自定义 Kimi K3 License | 许可证允许自部署，但高效推理仍是大型集群工程 |
评估时仍需区分 Moonshot 直连 API 与 EvoLink 路由的价格、计费和请求行为。EvoLink 路由已经上线，但生产团队仍应验证自身工作负载的延迟、缓存、工具和失败恢复表现。
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 | kimi-k3 | 经过验证的生产路由，已公布上下文与请求行为 | 模型页显示实时价格 |
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 可以同时接收文本、图片和视频 |
| 高并发客服聊天 | 初期较低 | 始终推理和高输出价格可能没有必要 |
| 分类、打标签和短文本提取 | 初期较低 | 更轻量的模型通常具备更好的成本和延迟表现 |
| 私有部署或开放权重方案 | 按需求评估 | 权重与许可证已经公开，但 Moonshot 建议使用 64+ 加速器超节点获得高效推理 |
因此，不能仅凭某个 Benchmark 标题决定 K3 的生产价值。团队需要衡量它是否减少了重试、人工修改和模型升级次数，或者完成了便宜模型无法完成的任务。
Moonshot API 价格与实际成本
Moonshot 对 K3 整个上下文范围采用统一价格，没有按短上下文和长上下文分档：
| Token 类型 | Moonshot 直连价格（每百万 token） |
|---|---|
| 缓存命中输入 | ¥2 |
| 缓存未命中输入 | ¥20 |
| 输出 | ¥100 |
不要混用三套不同的价格口径：
- 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控制推理； - 支持
low、high与max，默认使用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 支持和兼容层可能不同，应以 EvoLink 文档为准，不能假设两套接口完全一致。
长上下文、缓存与常见接入问题
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 使用 low、high 或 max，并确认参数位于请求顶层 |
| 后续轮次丢失状态或工具上下文 | 应用只保存最终文本，没有保留完整 assistant message | 保留推理字段、Tool Calls 和完整 assistant 响应 |
部分第三方 Coding 客户端还会提供自己的上下文设置。账号具备 1M 权益，不代表所有客户端都会自动发送最大上下文。
生产评估与待确认事项
开放权重发布确认了什么，哪些仍需测试
Moonshot 的 K3 API 文档已经相当完整，但仍有一些重要问题需要继续观察：
| 待确认问题 | 当前安全结论 |
|---|---|
| 官方完整 Benchmark 表 | Moonshot 已公开完整表格和方法说明；厂商自测结果只能作为评估输入，不能直接当作生产保证 |
| 独立第三方评测 | 需要等待使用一致 Harness 的独立测试 |
| 开放权重 | 已确认：约 1.56 TB，共 96 个 safetensors 分片 |
| 许可证 | 已确认自定义 Kimi K3 License；需审查 Model-as-a-Service 与大型产品条款 |
| 激活参数量和专家结构 | 已确认：激活 1040 亿参数、896 个专家、每 Token 选择 16 个 |
| 真实长上下文检索质量 | 必须使用代码仓库和长文档任务验证，而不是只看窗口长度 |
| 发布期 API 延迟 | 需要按上下文规模和时间持续测量 |
| 失败请求计费 | 需要结合最新政策和真实账单核对 |
| EvoLink 模型 ID 与价格 | 模型 ID 为 kimi-k3；当前价格以模型页为准 |
社区第一批演示认为 K3 在编程和 Web 构建上表现强劲，同时也出现了速度慢、过度思考和发布首夜报错的反馈。这些只能用于设计测试用例，不能作为正式模型事实或生产保证。
Kimi K3 生产评估步骤
不要只用一个效果惊艳的 Prompt 评估 K3。应该建立能代表真实客户价值的小型任务集。
第一步：建立当前基线
选择 20–50 个真实任务，覆盖：
- 代码仓库理解；
- 多文件代码修改；
- Bug 定位；
- 长文档综合分析；
- 结构化数据提取；
- 多模态评审；
- 多步工具调用。
记录当前模型的成功率、延迟、输入输出 token、重试次数和人工审核时间。
第二步：测试 Moonshot 直连 K3
如果直连测试符合团队的采购、数据与区域要求，可以使用 Moonshot 官方路由。保持提示词、工具和验收标准一致，并分别记录首次未缓存成本和后续缓存成本。
第三步：决定未来的路由角色
K3 不需要替换所有基线模型才有价值。它可以作为：
- 便宜模型失败后的升级路由；
- 仓库级 Coding Agent 模型；
- 长文档综合分析模型；
- 工具密集型任务的专用模型；
- 用户主动选择的高级模型。
第四步：在 EvoLink 路由上重新验证
kimi-k3 路由上执行一组兼容性测试：- 模型 ID 和请求结构；
- 推理字段保留；
- 流式输出；
- Tool Calling 和结构化输出；
- 图片、视频输入；
- 1M 上下文处理；
- 缓存与账单统计；
- 超时、重试和模型回退。
EvoLink 用户现在应该怎么准备？
EvoLink 的价值不是把每个新模型立刻变成默认路由，而是让模型选择、成本控制、供应商回退和迁移变得更简单。
正式向 K3 路由放量前，团队应该：
- 查看 Kimi K3 模型页与 EvoLink API 文档。
- 建立可重复运行的业务验收集，在 EvoLink 路由上直接复测。
- 把模型选择放进配置层，不要在业务代码中写死单一供应商。
- 为高级模型设置明确的成本和延迟升级阈值。
- 阅读 AI 模型路由指南，设计多模型选择逻辑。
- 关注 Kimi K3 在 EvoLink 的接入状态。
真正的生产机会是模型可选性：普通任务使用经济路由，高难任务使用高级推理，并在某个供应商变慢或不可用时保留回退路径。
继续完成 Kimi K3 选型
| 下一步决策 | 对应文章 |
|---|---|
| 从可复用且有来源的任务开始评测 | Kimi K3 提示词与用例 |
| 比较 K3 与 OpenAI 的旗舰编程路线 | Kimi K3 vs GPT-5.6 Sol |
| 比较 K3 与 Anthropic 的高端长任务路线 | Kimi K3 vs Claude Opus 4.8 |
| 测量延迟、输出、缓存与单次成功任务成本 | Kimi K3 Token 效率 |
常见问题
Kimi K3 正式发布了吗？
是。Moonshot 已于 2026 年 7 月 16 日在官方模型列表、快速开始、价格页面和直连 API 示例中公布 Kimi K3。
Kimi K3 官方模型 ID 是什么？
kimi-k3。Kimi Code 仍使用独立的产品别名 k3。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 支持 low、high 和 max，默认使用 max。Kimi K3 API 价格是多少？
Moonshot 直连价格为：缓存输入 ¥2/百万 token、未缓存输入 ¥20/百万 token、输出 ¥100/百万 token。这不是 EvoLink 价格。
Kimi K3 开源了吗？
Kimi K3 可以在 EvoLink 使用吗？
kimi-k3 路由。请查看 Kimi K3 模型页、API 文档和接入状态文章。如果你正在评估 xAI 的下一代模型，可通过 Grok 4.6 对比 Kimi K3把可调用的 K3 作为生产基线。是否应该用 K3 替换 K2.6 或现有模型？
不应该直接全部替换。K3 的 Moonshot 直连价格明显更高，应先测试长上下文、编程、研究、多模态和工具密集型任务，再决定它适合做专用、升级还是高级路由。
开发者应该先测试什么？
优先测试目前受限于仓库规模、文档数量、长工具历史或复杂推理的任务，并记录成功任务成本与人工修改量。
参考来源
- Moonshot：Kimi K3 快速开始与模型介绍
- Moonshot：Kimi K3 直连 API 定价
- Moonshot：当前模型列表
- Moonshot：模型参数参考
- Moonshot：Kimi K3 工具调用最佳实践
- Moonshot：直连 API 限速档位
- Kimi Code：模型 ID、套餐、上下文限制与切换行为
- Kimi K3 开放权重仓库与模型卡
- Kimi K3 License
- Moonshot：Kimi K3 架构、基础设施与可用方式
社区讨论仅用于识别开发者的测试问题和早期采用顾虑。本文中的模型事实、价格、模型 ID、限制和 API 行为均以 Moonshot 官方文档为依据。
