通过 EvoLink 统一对话 API 接入 Moonshot AI 的 Kimi K3(也常被搜索为 Moonshot K3)。集成前可先测试长上下文编程、工具调用、结构化输出。
Kimi K3 是一条面向复杂任务的旗舰推理路由，适合截图还原与交互式前端原型、大型代码仓库、多文档证据综合、长时间运行的智能体，以及确实需要 105 万 Token 工作上下文的知识任务。
Kimi K3
Moonshot 旗舰推理模型
kimi-k3截图还原 UI、网页与动画原型、大型代码仓库开发、多文档综合、多步工具调用智能体，以及能够通过减少重试和人工修改来抵消旗舰模型成本的困难任务。
所有费率按每百万 Token 计,同时显示美元与 Credits,以你账户当前的价格为准。
集成前先估算一次 Kimi K3 请求的费用。计算器按你账户的当前费率计算,官方价格仅作对照。
官方价预估 $0.0076 · 省 $0.0004(5%)
最低计费:每次请求 0.01 Credits。
快速测试
日常开发
生产评估
通过 EvoLink 统一 API 调用 Moonshot 的 2.8 万亿参数旗舰模型 Kimi K3。它在视觉理解、截图还原、前端与动画原型上出现了鲜明的首发信号，也适合跨文件代码修改、长文档分析、持续推理和多步工具调用，并支持 1,048,576 Token 上下文、提示词缓存与结构化输出。
Kimi K3 在 EvoLink 上以模型 ID kimi-k3 提供,支持 Chat Completions · Responses · Anthropic Messages,和其他模型共用同一把 API 密钥与余额。它提供 1.05M 上下文窗口,最大输出 1.05M Token,并支持长上下文编程、工具调用、结构化输出。
数字取自 EvoLink 路由配置;能力以 API 当前实际提供为准。
先确定任务确实需要旗舰模型，再利用长上下文、持续推理和提示词缓存降低信息丢失与重复处理。三项能力必须结合使用，单独追求上下文长度并不会自动提高结果质量。
1,048,576 Token 上下文可以同时保留相关代码、规格文档和历史工具结果，减少切块造成的信息损失。仍应先检索真正相关的内容，并及时压缩已经失去价值的上下文。
K3 适合需要连续分析、规划和执行的长链路任务，但推理过程和最终答案都会消耗 Token。1,048,576 Token 是默认最大输出容量，不是每次请求都应该达到的目标。
仓库说明、系统提示词、参考资料和工具 Schema 保持稳定时，重复请求更容易形成缓存命中。频繁更换模型、提示词结构或关键配置，会增加长前缀重新处理的成本。
新模型不应该因为参数更大就成为所有请求的默认选择。Kimi K3 更适合作为复杂任务路由：当百万上下文、持续推理或多步工具调用能够减少重试、模型交接和人工返工时，它的更高成本才有机会转化为更低的任务总成本。
当一个工程任务同时依赖架构说明、多个服务、历史测试、大型 Diff 和分散在不同文件中的约束时，可以让 K3 保持更完整的工作上下文。评估时应看补丁能否直接采用、代码审查耗时和返工次数，而不只是单段代码是否漂亮。
适合同时处理规格文档、论文、合同、日志或知识库证据，并在同一上下文中追踪它们之间的关系。但百万 Token 只是容量，不代表应该塞满无关资料；检索、文档结构和证据筛选仍然决定回答质量。
适合需要连续选择工具、生成结构化结果、执行代码或反复操作外部系统的流程。要在多轮请求中保留完整助手消息、推理内容、工具调用 ID、参数和结果，否则长链路任务仍会因为状态缺失而失败。
短对话、分类、改写、简单字段抽取和对延迟敏感的界面操作通常用不到最大推理能力与百万上下文。先用成本更低的模型处理常规流量，只在任务难度确实上升时再切换到 K3。
首批社区实测可以帮助团队确定评估方向，但不能代替同一任务、同一工具链、同一预算和统一验收标准下的独立测试。既要看最出彩的 Demo，也要把速度、成本和稳定性问题放进生产评估。
截图还原 UI、网页原型、交互页面、小游戏和动画，是首批实测中最稳定的亮点。真正接入前仍应使用自己的设计系统、响应式断点、无障碍要求和技术框架复测，避免把单个视觉 Demo 当成通用结论。
页面做得漂亮，不代表后端修改、仓库级重构、工具调用和长时间 Agent 运行同样稳定。应在真实 Issue、测试用例、多文件 Diff、工具失败恢复和补丁通过率上验证 Kimi K3，而不是从一次生成结果外推整体编程能力。
部分首发反馈提到模型在开始输出前会进行较长推理。评估 Kimi K3 API 时要记录首个可用结果耗时、总运行时间、推理与输出 Token、重试和人工修改，最终比较完成一项可交付任务的总成本。
Moonshot 已按自定义许可证发布约 1.56 TB 的 Kimi K3 仓库。2.8 万亿总参数和官方 64+ 加速器建议，仍要求单独规划存储、并行推理、吞吐与运维成本。
产品后端与批量任务走 EvoLink API;编码与分析类工作可直接在 Codex、Claude、Gemini 里调用 Kimi K3。两条路径共用同一把 EvoLink API 密钥、余额、模型 ID 与请求记录。
适合:产品后端、批量任务、自动化流水线
向 EvoLink 发送 OpenAI 兼容的 Chat Completions(或 Anthropic Messages)请求,自行控制模型 ID、系统提示、输出预算、工具与结构化输出。
适合:在 Codex、Claude、Gemini 里做编码、评审与分析
把任务、要带入的材料和验收标准交给 Agent,由它组装请求、通过 EvoLink 调用 Kimi K3,并把回答连同 token 用量一起返回。
这个示例是最短可运行的请求:一条 OpenAI 兼容的 Chat Completions 调用,带系统提示、用户消息和输出预算。完整参数与响应说明见 API 标签页。
curl -X POST https://api.evolink.ai/v1/chat/completions \
-H "Authorization: Bearer $EVOLINK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "kimi-k3",
"messages": [
{ "role": "system", "content": "You are a senior engineer reviewing a pull request." },
{ "role": "user", "content": "Review this diff and list every risky change with file and line:\n<diff>" }
],
"max_tokens": 2048,
"temperature": 0.2
}'
# The response includes choices[0].message and a usage object
# (prompt_tokens, completion_tokens, and cached tokens when a prefix is
# reused).对照 API 文档检查模型 ID、messages 数组和参数范围,去掉该路由不支持的字段。
检查 Authorization bearer token,并在控制台确认可用余额。
提示词 token 超过了 Kimi K3 的上下文窗口。裁剪或只检索相关材料,并复用缓存前缀。
退避并带抖动重试;用批处理或队列代替并发突发。
重试前检查敏感内容、格式错误的 tool-call 参数和 JSON schema 不匹配。
能力适合并不等于接入一定正确。上线前应确认调用入口、模型标识、上下文状态和会话策略，避免把产品入口差异误判成模型能力问题。
EvoLink API 路由使用 kimi-k3，Chat Completions 与 Anthropic Messages 请求保持一致。
EvoLink 的 Kimi K3 模型路由记录为 1,048,576 Token 上下文。部分编程客户端或会员方案可能采用更小的默认限制，因此应确认实际调用路由和客户端配置，不能把某个产品入口的 256K 限制当成所有 K3 API 的统一上限。
多轮智能体任务需要回传完整助手消息、推理内容、工具调用 ID、参数和工具执行结果。只保留最终文本会破坏状态连续性，即使上下文窗口足够大，也可能导致后续步骤判断错误。
更换模型或大幅调整推理配置可能使原有缓存与上下文假设失效。路由发生明显变化时应开启新会话，并重新记录缓存命中、输出长度和工具调用表现。
稳定不变的仓库说明、参考文档、系统提示词和工具 Schema 可形成可重复使用的缓存前缀；自动缓存读取命中时使用独立优惠价格。
可以在同一工作上下文中保留相关代码、规格、文档和智能体状态，但不要把上限当成目标。先检索真正相关的证据，并按照任务难度设置输出预算。
Kimi K3 的价格是否合理，取决于它能否在真实任务中减少切块、重试、工具失败和人工返工。应使用同一批生产样本比较模型，而不是只看一次请求的输入价格。
如果 K3 能用更少的重试和人工修改交付可用结果，更高的 Token 单价可能对应更低的任务总成本；如果没有形成这类收益，就应继续把流量留在轻量模型。
先根据真实任务确认 Kimi K3 是否能减少重试和人工修改，再结合价格、上下文、缓存方式与任务类型选择生产路由。
| 模型 | Kimi K3 | Claude Opus 4.8 | Gemini 3.1 Pro |
|---|---|---|---|
| 输入 / 输出 | $2.85 / $14.25 | $4.5 / $22.5 | $1.865 / $11.183 |
| 上下文 | 1.05M | 1M | 1M |
| 缓存 | 自动缓存读取 | 读写缓存 | 上下文缓存 |
| 适用场景 | 截图还原 UI、网页与动画原型、大型代码仓库开发、多文档综合、多步工具调用智能体，以及能够通过减少重试和人工修改来抵消旗舰模型成本的困难任务。 | 适合作为长时间编程智能体、复杂审查和高判断力专业流程的高端基线。 | 适合文档密集型任务、视觉证据和跨提供方回退测试的长上下文多模态模型。 |
可以。Kimi K3 已作为正式生产模型展示，页面优先读取后端实时价格，并使用官方价格作为兜底。
Chat Completions 与 Anthropic Messages 均使用 kimi-k3。
可以。继续使用同一个 EvoLink API 密钥，通过兼容 Chat Completions 或 Anthropic Messages 的方式调用 kimi-k3。
EvoLink 路由记录的是 1,048,576 Token。256K 通常来自特定 Kimi Code 套餐或客户端默认配置。
保留真正相关的代码、文档和工具结果，同时配合检索、稳定缓存前缀与上下文压缩，不要为了用满窗口而加入无关内容。
首批社区实测在截图还原 UI、网页原型、小游戏、动画和视觉交互方面反馈较好。真正选型时仍应使用自己的组件库、响应式规范、无障碍检查和代码质量标准复测。
目前还没有稳定的独立结论。部分首发反馈提到开始输出前思考时间较长，因此应在代表性任务上记录首个可用结果耗时、总 Token、重试次数和最终交付通过率。
模型或关键配置变化可能使原有缓存失效。切换路由时建议开启新会话，并重新记录缓存命中和输出长度。
根据任务难度限制最大输出，同时观察推理 Token 和最终答案 Token。1,048,576 Token 是容量上限，不是常规请求目标。
需要先测试延迟和成本。短对话、分类、改写与轻量抽取通常应继续使用更小的模型。
K3 重点评估长上下文和复杂智能体收益；GPT 与 Claude 可作为前沿能力基线，GLM 与 DeepSeek 可作为成本敏感型基线。
比较首次成功率、交付通过率、重试、输出 Token、缓存命中、工具调用、总耗时、人工修改量和回退频率。
