Kimi K2.6 API Key 与价格：官方费用、速率限制与网页搜索收费

Kimi K2.6 API Key 与价格：官方费用、速率限制与网页搜索收费

如果你正准备注册一个 Kimi API Key 来运行 K2.6，那么 token 单价只是成本的一部分。缓存、速率限制等级、网页搜索费用，以及 agent 式重试，都会悄悄决定你每个月的账单。这篇指南会逐项拆开说明，并使用 Moonshot 目前在官方平台页面上公开的数字。

快速结论

• Kimi K2.6 使用 Moonshot 的 OpenAI 兼容 API，地址为 https://api.moonshot.ai/v1，任何 OpenAI SDK 都可以直接替换使用。
• Moonshot 平台页上公布的 K2.6 官方价格：
  • 缓存输入：¥1.10 / 1M tokens
  • 非缓存输入：¥6.50 / 1M tokens
  • 输出：¥27.00 / 1M tokens
  • 上下文窗口：262,144 tokens
• 你可以在 platform.moonshot.ai 注册账号后，在控制台中创建 API Key。
• 内置网页搜索按 ¥0.03 / 次调用 收费，另外搜索结果会进入下一次 /chat/completions 请求并消耗额外 token。
• 免费层级 Tier 0 提供 3 RPM、1 个并发请求，以及每日 token 上限。更重度的使用需要充值以提升到更高 tier。

下面我们会逐项展开，并说明这些数字背后的坑点。

如何创建 Kimi API Key

流程和大多数 LLM 提供商差不多：

1. 打开 platform.moonshot.ai 并登录或注册。
2. 如果系统要求，先完成账号验证。
3. 打开控制台中的 API keys 页面，点击 Create API key。
4. 立刻复制这个 key，它只会显示一次。
5. 可选但强烈建议：在跑任何 workload 之前，就设置预算上限和余额不足提醒。

把这个 key 当作密码来对待：应该放进环境变量或 secret manager，而不是写进源码文件里。如果泄露了，就在同一个控制台页面里立刻轮换。

对于新账号，有一点非常值得注意：Moonshot 采用按 累计充值金额 升级的 tier 式速率限制。一个全新账号会从 Tier 0 开始，限制非常紧，只适合少量测试请求，不适合常驻的 coding agent。在你开始做 benchmark 之前，最好先看完下面的速率限制部分。

Kimi K2.6 官方价格

Moonshot K2.6 价格页目前公布的数字如下：

项目	价格	单位
缓存输入	¥1.10	每 1M tokens
非缓存输入	¥6.50	每 1M tokens
输出	¥27.00	每 1M tokens
上下文窗口	262,144	tokens

这里有两点特别重要。第一，价格单位是 人民币（¥），不是美元。如果你要和 Anthropic 或 OpenAI 的价格比较，请自己做汇率换算，不要把 “¥6.50” 直接看成 “$6.50”。第二，缓存输入大约比非缓存输入便宜 6 倍。这一项几乎决定了长上下文和 agent 工作负载的经济性。

“cached input” 和 “uncached input” 是什么意思

Moonshot 和大多数前沿模型厂商一样，提供了 上下文缓存（context caching）：当你 prompt 中的一部分在近期已经出现过时，服务器可以跳过前缀的重复计算，并以更低的价格收费。

具体来说：

• 缓存命中（cached input）：你之前已经发送过的前缀（system prompt、历史对话、大段文档上下文）与服务端缓存中的内容匹配，此时按缓存价收费。
• 缓存未命中（uncached input）：新的 prompt 内容、顺序发生变化，或原本的前缀已从缓存中失效，这时按完整未缓存价格收费。

为什么这在真实工作流里很关键：

• 长上下文 RAG：如果你把 100K token 的知识库塞进 system prompt 并反复复用，缓存会把原本很痛的账单压到可接受范围。
• Agent 循环：每一步工具调用型 agent 通常都会重新发送 system prompt、工具 schema 和对话历史。没有缓存时，每一步都按 uncached 计费；有缓存时，只有新追加的工具结果和 assistant 回复按高价计费。
• 相同 prompt、不同用户：如果两个用户命中了同一套 system prompt，第二个用户会吃到缓存收益。

实用建议是：把 稳定、可复用 的部分（指令、长文档、工具定义）放在 前面，把用户特定、会变化的部分放在 后面。这样能最大化缓存命中率，并把输入成本压低 5 倍甚至更多。

OpenAI 兼容请求格式

Moonshot 的 API 与 OpenAI 兼容，这意味着任何 OpenAI SDK 都可以通过更换 base URL 和 API key 来使用。

curl

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k2.6",
    "messages": [
      {"role": "user", "content": "Explain caching in one paragraph."}
    ]
  }'

Python（OpenAI SDK）

from openai import OpenAI

client = OpenAI(
    api_key="your-moonshot-api-key",
    base_url="https://api.moonshot.ai/v1",
)

response = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[
        {"role": "user", "content": "Write a Python function to debounce calls."}
    ],
)
print(response.choices[0].message.content)

Thinking 模式与 Instant 模式

K2.6 默认启用 Thinking 模式。如果你想强制使用 Instant 模式（不生成 reasoning tokens），可以这样传：

response = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[...],
    extra_body={"thinking": {"type": "disabled"}},
)

Thinking 模式会生成需要按输出收费的 reasoning tokens。如果任务不需要它，关闭就是最直接的省钱方式。

多模态输入

K2.6 是原生多模态模型，支持文本、图像和视频输入。图像可以直接通过标准 OpenAI image_url 内容块传入。视频输入在官方 API 上可用，但 Moonshot 把第三方部署中的视频支持标记为实验性功能。如果你的产品依赖它，请务必做完整链路测试。

速率限制与账号层级

Moonshot 对账号应用按层级区分的速率限制。层级升级依据的是 累计充值金额，不是当前余额，而是你历史上一共充值了多少。

目前官方公布的层级结构大致如下：

Tier	累计充值	并发	RPM	TPM	TPD
Tier 0	¥0	1	3	500,000	1,500,000
Tier 1	¥50	更高	更高	更高	更高
…	…	…	…	…	…

Tier 1 及以上的具体数字可能会随着时间变化，因此在估算 workload 之前，请先去平台限额页面确认。几个实际建议：

• Tier 0 适合验证。 你可以完成集成、跑几次测试调用、确认 OpenAI SDK 正常工作，这些都可以在免费层内完成。
• Tier 0 不适合 coding agent。 每分钟 3 次请求、仅 1 个并发，会让任何真正的 agent loop 都卡得很厉害。
• 尽早充值换吞吐。 对于真实 workload，最便宜的解法通常是小额充值升到 Tier 1，而不是硬着头皮在 Tier 0 里做规避优化。

最容易被忽略的额外成本

按 token 的价格表并不是全部。生产环境里通常会悄悄冒出三类额外成本。

内置网页搜索。 Moonshot 提供了 $web_search 工具，模型可以在生成过程中调用。每次调用收费 ¥0.03。这听起来不高，但搜索结果内容随后会被插入到下一次 /chat/completions 请求里，作为额外输入 token，再按正常输入价格收费。一个爱搜索的 agent，如果每个用户回合搜十次，就会支付十次搜索费和十块输入 token 费用。

Reasoning tokens。 在 Thinking 模式下，模型会生成内部 reasoning tokens，它们按输出计费。简单问答时问题不大；但在工具循环型 agent 中，50 次工具调用累计出来的 reasoning 成本，很可能成为最大的费用项。如果任务不需要，关掉就对了。

Agent 重试与长时间循环。 Moonshot 自家的材料强调 K2.6 能在 12 小时里执行 4,000+ 次工具调用。这是很强的能力，也是一张很真实的账单。长时 agent 演示确实有价值，但也是最容易在不知不觉间烧掉 ¥10,000 的方式。运行 agent 工作流时，一定要限制最大步数和最大 token 数。

缓存未命中的模式。 调整 prompt 顺序、频繁修改 system message，或者面对大量上下文彼此差异很大的用户，都会降低缓存命中率。如果你发现 “input” 成本比预期大，通常问题就在这里。

Kimi K2.6 免费吗？

关于“免费”，其实有三种不同的问题，也有三种不同的答案：

在 kimi.com 浏览器端使用 Kimi。 Moonshot 的消费级产品通常带有一个按天限额的免费层。这不是 API，那里的对话不会消耗 API credits。

不付费使用 Kimi K2.6 API。 Tier 0 免费额度允许你在不充值的情况下发送少量请求。它足够做集成测试，但不足以支撑持续负载。超过 Tier 0 后，API 就是付费的。

通过 Ollama Cloud、OpenRouter 等渠道使用 Kimi K2.6。 这些都是独立计费系统，拥有自己的免费额度和价格，不等同于“官方 Kimi API”，即使底层路由到了同一个模型。

所以结论是：免费试用是有路子的，但通过官方 API 免费运行 K2.6 生产负载并不存在。

如何控制 Kimi API 成本

扩量前的简要清单：

• 在控制台设置硬预算上限。
• 开启余额不足提醒。
• 始终传入 max_tokens，尤其是在 agent loop 中。
• 稳定上下文放前面，用户特定内容放后面，以提高缓存命中。
• 对不需要的任务关闭 Thinking 模式。
• 给 $web_search 加显式开关，不要让每个 prompt 都触发。
• 给 agent loop 设置最大步数与超时。
• 记录每次请求的 input、output 和 cached-input token 数，这样你才能真正看清成本来自哪里。

最后建议

如果你在评估 Kimi K2.6 是否适合 coding agent 或长上下文工作流，它的成本结构是可行的，但不是天然便宜。headline token 价格有竞争力，cached input 的价格也非常不错——但前提是你真的把 prompt 设计成容易命中缓存。对于短、无状态且无法缓存的调用，K2.6 并不是最便宜的选择，尤其是 ¥27.00 / 1M 的输出价格，在大量代码生成的场景中会非常显眼。

对大多数团队来说，更合理的起点是：先充值到足以脱离 Tier 0，搭好集成，测量你在生产中的真实缓存命中率和 token 分布，然后再决定 K2.6 是否适合作为长期方案，或者是否应该改用价格结构更适合你工作流的模型。

FAQ

如何获取 Kimi API Key？
登录 platform.moonshot.ai，打开 API keys 页面并创建一个新 key。它只会显示一次，所以请立刻复制。同时建议一并设置预算上限。

Kimi K2.6 多少钱？
根据官方价格页，缓存输入是 ¥1.10 / 1M tokens，非缓存输入是 ¥6.50 / 1M tokens，输出是 ¥27.00 / 1M tokens，上下文窗口为 262,144 tokens。价格单位为人民币。

Kimi K2.6 可以免费使用吗？
Tier 0 免费层允许少量调用（3 RPM、1 并发、每日 token 上限），足够测试，不够生产使用。kimi.com 上的消费级免费层与 API 计费是分开的。

Kimi API 支持 OpenAI SDK 吗？
支持。Kimi API 与 OpenAI 兼容。只需把任意 OpenAI SDK 指向 https://api.moonshot.ai/v1，使用你的 Moonshot key，并将 model 设置为 kimi-k2.6。

Kimi API 的速率限制是什么？
速率限制按 tier 分级，并随累计充值金额提升。Tier 0（¥0）是 3 RPM、1 个并发请求，并带每日 token 上限。Tier 1 从累计充值 ¥50 开始，限制会明显提高。

Kimi 网页搜索多少钱？
内置 $web_search 工具按 ¥0.03 / 次收费。搜索结果内容随后会被加入下一次 chat completion 请求，并按正常输入 token 价格收费。

我可以把 Kimi K2.6 用在工具调用和 function calling 场景吗？
可以。K2.6 支持与 OpenAI 风格一致的工具调用和 function calling。不过 Moonshot 文档提到一个约束：在开启 Thinking 模式时，tool_choice 应设置为 auto 或 none，并且你必须在多轮工具调用之间保留 assistant 消息中的 reasoning_content。