Kimi K3 已面向需要用于编码、知识工作、视觉推理和智能体工作流的长上下文模型路由的 API 团队正式上线。简而言之：官方模型 ID 是 kimi-k3，Kimi 列出了 1,048,576 token 的上下文窗口，Kimi 的直连定价按每 100 万 token 公布，而 Flatkey 目前通过 OpenAI 兼容端点提供了一个 kimi-k3 路由。
本指南面向正在判断 Kimi K3 是否应当立即进入生产路由方案的产品团队。它涵盖 API 定价、上下文窗口限制、兼容性说明、路由检查，以及在发送真实流量之前需要回答的运营问题。请将 Kimi K3 已上线：API 定价、上下文窗口与路由说明 视为一份上线检查清单，而不仅仅是一则模型公告。
快速回答
对于正在搜索 Kimi K3 已上线：API 定价、上下文窗口与路由说明 的团队，发布当天的重要事实如下：
| 项目 | 当前有来源依据的细节 |
|---|---|
| 官方模型 ID | kimi-k3 |
| Kimi 直连端点模式 | 位于 https://api.moonshot.ai/v1 的 OpenAI 兼容 Chat Completions |
| 上下文窗口 | 1,048,576 tokens |
| 直连输入价格 | 每 100 万 token 3.00 美元 |
| 直连缓存输入价格 | 每 100 万 token 0.30 美元 |
| 直连缓存写入价格 | 5 分钟 TTL 为每 100 万 token 3.00 美元；1 小时 TTL 为每 100 万 token 6.00 美元 |
| 直连输出价格 | 每 100 万 token 15.00 美元 |
| 思考模式 | 始终启用；可通过 reasoning_effort 的 low、high 或 max 值控制强度 |
| Flatkey 路由 | kimi-k3 在 Flatkey 路由数据中位于 China LLM 组下可用 |
这次发布并不只是上下文窗口更大。Kimi 自己的模型列表将 K3 描述为截至目前能力最强的模型，拥有 2.8T 参数、原生视觉理解能力，以及用于软件工程、知识工作和深度推理的 100 万 token 上下文窗口。
Kimi K3 有哪些变化
Kimi K3 取代了旧的 Kimi 路由，成为团队应评估是否继续使用 Kimi 支持的模型。Kimi 的模型文档将 kimi-k2.5 和 moonshot-v1 系列标记为于 2026 年 8 月 31 日停止支持，并指引用户使用 kimi-k3 继续获得支持。
这对路由很重要。如果你的应用仍在配置中存储 moonshot-v1-*、kimi-latest 或更旧的 kimi-k2-* 别名，安全的做法不是盲目搜索替换。应将其视为一次路由迁移：
- 在代码、提示词、评测配置和客户工作区设置中找出每一个 Kimi 模型 ID。
- 将一个预发工作负载迁移到
kimi-k3。 - 运行上下文、工具调用、JSON、视觉和流式传输的冒烟测试。
- 比较可接受输出成本，而不仅仅是 token 价格。
- 在正式上线前添加一个回退路由。
Flatkey 团队可以在将 Kimi K3 作为主路由之前，使用同样的发布日评估流程以及 新模型评估清单。
Kimi K3 已上线：API 定价、上下文窗口与团队路由说明
K3 的直接 Kimi API 定价以每 100 万 token 的 token 价格公布。对于 Kimi K3 已上线：API 定价、上下文窗口与路由说明，当前直接定价如下：
| 计费项 | Kimi 直连价格 | 给产品团队的说明 |
|---|---|---|
| 缓存写入，5 分钟 TTL | $3.00 / 1M tokens | 若未指定 TTL，则为默认 TTL |
| 缓存写入，1 小时 TTL | $6.00 / 1M tokens | 仅在更长复用窗口值得这部分写入成本时有用 |
| 缓存输入 | $0.30 / 1M tokens | 当重复前缀命中上下文缓存时适用 |
| 输入 | $3.00 / 1M tokens | 适用于未缓存的提示词 token |
| 输出 | $15.00 / 1M tokens | 通常是智能体循环和冗长推理的最大成本驱动项 |
这是 Kimi K3 已上线：API 定价、上下文窗口与路由说明 中团队应转换为工作负载计算的部分。长上下文路由在输入价格上看起来很划算，但如果每次请求都会产生大量缓存写入、生成较长的推理输出，或重复低价值上下文，成本仍可能很高。
使用这个规划公式：
accepted_output_cost =
(cache_write_tokens * cache_write_rate)
+ (cached_input_tokens * cached_input_rate)
+ (uncached_input_tokens * input_rate)
+ (output_tokens * output_rate)
divided by accepted results
对于生产决策，请用真实样本运行该公式。将失败生成、重试、工具调用循环，以及被产品质量门禁拒绝的输出都计算在内。
上下文窗口与缓存说明
Kimi 为 Kimi K3 提供了 1,048,576 token 的上下文窗口。这使它适用于跨仓库编码任务、大型文档审查、多文件产品分析以及长时间运行的智能体会话。
但 100 万 token 的窗口并不意味着可以忽略上下文管理：
- 保持稳定前缀稳定，以便自动缓存能够工作。
- 当检索更便宜时，避免在每个请求中塞入所有文档。
- 对于不需要长篇推理的任务，限制输出长度。
- 为不受益于 100 万上下文的短请求保留一个更小的回退模型。
- 单独衡量延迟与价格，因为即使长提示词能够放得下，也会改变用户体验。
Kimi 的文档说明，自动缓存适用于常规模型请求，不需要缓存 ID、TTL 或额外参数。他们还指出，只有当上一轮提示词超过 256 tokens 时，新请求才可能命中前缀缓存。产品团队在承诺 Kimi K3 带来成本下降之前，应先在自己的日志中验证缓存行为。
API 兼容性与请求形态
Kimi 的快速开始示例使用 OpenAI Python SDK，并设置 base_url="https://api.moonshot.ai/v1" 和 model="kimi-k3"。这使得 Kimi K3 成为已经在使用 OpenAI 兼容 Chat Completions 客户端团队的一个实用候选。
兼容性细节仍需要在发布当天进行冒烟测试：
from openai import OpenAI
client = OpenAI(
api_key="MOONSHOT_API_KEY",
base_url="https://api.moonshot.ai/v1",
)
completion = client.chat.completions.create(
model="kimi-k3",
reasoning_effort="low",
messages=[
{"role": "user", "content": "总结此版本的路由风险。"}
],
)
print(completion.choices[0].message.content)
对于 Flatkey，请将模型 ID 保持为 kimi-k3，将兼容的调用通过 Flatkey 路由器转发，并在生产前通过 AI model catalog guide 工作流验证路由。模型页面是确认当前可用性、端点支持以及实际路由价格的正确位置。
Flatkey 团队的路由说明
Flatkey 当前的定价 API 显示 kimi-k3 可用，并通过 China LLM 组路由，同时支持 OpenAI 端点。Flatkey 的公开模型页面也展示了 Kimi K3 的模型路由，并说明它是一个具有 1M token 上下文的 chat/completions 模型。
在将 Kimi K3 添加到生产路由器之前，请记录这份路由审查记录。对于 Kimi K3 已上线：API 定价、上下文窗口与路由说明，当平台、产品和财务团队需要同一份事实依据时，它就是交接工件：
model_id: kimi-k3
provider: Moonshot AI / Kimi
route_owner: product-or-platform-team
primary_use_cases:
- long-context coding
- knowledge-work agent sessions
- visual reasoning review
context_window_tokens: 1048576
direct_pricing_checked_at: 2026-09-22
flatkey_route_checked_at: 2026-09-22
endpoint_contract:
chat_completions: required
streaming: test_required
structured_output: test_required
tool_calls: test_required
vision_input: test_required
cost_metric: cost_per_accepted_output
fallback_routes:
- short_context_default
- cheaper_coding_route
rollback_condition:
- error_rate_above_threshold
- accepted_output_cost_above_budget
- latency_p95_above_slo
这将 Kimi K3 已上线：API 定价、上下文窗口与路由说明 从一则发布公告转变为一份运营检查清单。
生产检查清单
在切换流量之前，请使用这份 Kimi K3 已上线：API 定价、上下文窗口与路由说明 检查清单：
| 检查项 | 需要核实的内容 |
|---|---|
| 模型 ID | kimi-k3 可在 staging 中正常使用，且不会被你生产环境密钥所缺少的账户层级隐藏 |
| 充值/访问 | Kimi 表示，K3 会在成功充值后解锁，账户层级会影响速率限制 |
| 上下文 | 你最大的提示词能放在 1,048,576 个 token 以内，并且还要为输出留出空间 |
| 输出预算 | max_completion_tokens 针对每个工作负载进行控制 |
| 推理力度 | low、high 和 max 会针对延迟、成本和质量进行测试 |
| 缓存 | 重复前缀工作负载在日志中确实命中了缓存 |
| 视觉 | 不应默认可直接使用公开图片 URL；Kimi 文档指出输入应使用 base64 或 ms://<file-id> |
| 工具 | 工具调用循环返回完整的助手消息，而不只是 content |
| 回退 | 在生产流量切换之前，已经准备好更便宜或更稳定的路由 |
| 计费 | 直接提供方日志与 Flatkey 使用日志对同一示例工作负载能相互核对 |
何时路由到 Kimi K3
当工作负载具有以下一种或多种特征时，Kimi K3 值得优先测试：
- 大型代码库上下文、长规划线程或多文档分析。
- 推理质量比原始延迟更重要的任务。
- 可受益于重复前缀缓存的工作流。
- 文本和视觉输入应在一次推理过程中完成的多模态审阅。
- 更大的上下文窗口可以减少脆弱检索拼接的智能体任务。
它不太可能成为每个请求的默认路由。简短的分类、抽取和支持消息任务，可能在更便宜、低延迟的模型上表现更好。实际的路由模式是：将 Kimi K3 保留给那些 1M 上下文、推理力度或视觉理解会改变可接受输出率的工作负载。
常见问题
Kimi K3 是否已通过 API 上线？
是的。Kimi 的 API 文档包含 Kimi K3 快速开始、模型列表、定价页面和上线横幅。Flatkey 路由数据也显示，截至 2026 年 9 月 22 日，kimi-k3 已可用于 OpenAI 风格路由。
Kimi K3 的上下文窗口是多少？
Kimi 将 Kimi K3 的上下文窗口标为 1,048,576 个 token。请将其视为容量，而不是建议在每次调用中发送所有可用文档。
Kimi K3 的 API 定价是多少？
直接的 Kimi 定价显示，K3 的价格为：每 100 万未缓存输入 token 3.00 美元、每 100 万已缓存输入 token 0.30 美元、每 100 万 cache-write token 3.00 美元或 6.00 美元（取决于 TTL），以及每 100 万输出 token 15.00 美元。上线前请查看 Flatkey 模型页面，以确认当前有效的 Flatkey 路由价格。
Kimi K3 是否支持推理控制？
是的。Kimi 表示 K3 始终开启思考模式，并支持顶层 reasoning_effort 字段，取值为 low、high 和 max，其中 max 为默认值。
团队应如何使用这篇《Kimi K3 已上线：API 定价、上下文窗口与路由说明》页面？
将其用作发布当天的分诊页面：确认官方定价和上下文信息，执行路由检查清单，计算已接受输出成本，然后再决定 Kimi K3 是成为主路由、备用路由，还是实验性路由。
结论
Kimi K3 已上线：API 定价、上下文窗口与路由说明之所以有用，是因为这次发布同时影响模型能力和生产运维。最重要的是 1M 上下文和新的旗舰 kimi-k3 路由。最终决策仍应取决于测得的已接受输出成本、延迟、缓存行为、工具调用可靠性以及备用方案的就绪程度。
Flatkey 帮助团队以更实用的方式完成评估：一个密钥、一个余额，以及通过共享 API 层进行模型路由，并且在上线前后都可以使用模型目录和使用日志来检查路由。
