Moonshot API 指 Moonshot AI 开放平台提供的模型接口，也就是 Kimi 背后的开发者平台。它按 Token 用量计费，没有订阅套餐。很多团队做预算时会在两个地方出错：一是还在调用已经下线的 moonshot-v1 型号，二是把输入、缓存写入、输出和重试混成一个平均单价。本文按 2026 年 10 月的公开文档拆解计费结构，具体价格以站内模型价格和官方文档为准。

说明：Moonshot、Kimi 是其权利人的商标。本文仅作技术说明，不代表与权利人存在隶属或代理关系。模型名单、上下文长度和计费规则可能调整，采购前请再次核对官方页面。

一、先分清“当前模型”和“已下线模型”

截至 2026 年 10 月，开放平台文档列出的主力型号是 kimi-k3、kimi-k2.6、kimi-k2.7-code 和 kimi-k2.7-code-highspeed。旧的 moonshot-v1 系列已经退出：moonshot-v1-8k、-32k、-128k、-auto 及对应视觉预览版均在 2026 年 8 月 31 日下线，同一天下线的还有 kimi-k2.5。更早的 kimi-k2 预览版、kimi-latest 等也已停止服务。

模型 上下文 计费结构 状态与注意
kimi-k3 1,048,576 输入、缓存命中、缓存写入、输出 当前旗舰，官方建议作为迁移目标
kimi-k2.6 262,144 输入、缓存命中、输出 通用与多模态，成本敏感场景常用
kimi-k2.7-code 262,144 输入、缓存命中、输出 代码生成、仓库问答与 Agent
kimi-k2.7-code-highspeed 262,144 输入、缓存命中、输出 低延迟代码任务
moonshot-v1-8k/32k/128k 按型号名 旧版按长度分档 2026-08-31 已下线

旧教程里的型号名不能直接照抄。moonshot-v1-8k 的“8k”本身就是上下文档位，调用失败不是 Key 的问题，而是型号已经不存在。迁移时先改模型名，再核对上下文和计费项，不要只做字符串替换。

二、计费单位：一条请求拆成四项

当前账单通常由四类 Token 组成：缓存未命中的输入、缓存命中的输入、缓存写入和输出。K3 的缓存写入按 5 分钟与 1 小时两档 TTL 单独计价；K2 系列的价格页没有单列缓存写入项。把一次请求写成公式：

单次请求成本 =
  未命中输入 Tokens × 未命中单价
+ 缓存命中输入 Tokens × 命中单价
+ 缓存写入 Tokens × 对应 TTL 单价（仅 K3）
+ 输出 Tokens × 输出单价

官方文档给了一个有用的换算：标准中文文本大约 1.5 到 2 个汉字对应 1 个 Token。用字数直接乘单价会低估输入量，正式测算应使用 POST /v1/tokenizers/estimate-token-count 估算接口，或直接读取响应里的 usage。

Chat Completions 的用量字段是 usage.prompt_tokens、usage.completion_tokens，缓存明细在 usage.prompt_tokens_details.cached_tokens 和 cache_write_tokens。Messages API 的 input_tokens 不含缓存部分，总输入要把 input_tokens、cache_read_input_tokens、cache_creation_input_tokens 相加。流式调用要设置 stream_options.include_usage=true。

三、缓存怎么计费、为什么没命中

上下文缓存按前缀匹配，不是按整段对话匹配。前缀中任何一处变化，该位置之后的内容都无法复用。常见破坏前缀的行为包括：在 system prompt 里插入时间戳或随机 ID、每次重排工具定义、动态拼接知识库片段、切换 TTL 档位。缓存还按组织隔离，跨组织不会共享。

K3 的缓存写入在首次写入时计费，TTL 固定为 5 分钟或 1 小时，写入后不能中途改档；命中会按原 TTL 免费续期，不会再次收取写入费。两档缓存不互通。若前缀尾部不足一个完整缓存块，这部分通常按未命中处理。

缓存不是“开了就省钱”的开关，而是前缀工程。把 system prompt、工具定义、固定示例和知识库公共部分放最前，变量放最后，再用 cached_tokens 验证命中率。

四、长上下文成本：贵在重复传输

K3 支持 1,048,576 Token 上下文，K2 系列为 262,144 Token。K3 采用统一的按量计费，不再像旧版 moonshot-v1 那样按 8k、32k、128k 分长度档，所以不能拿旧版的分档价格表来推算 K3。

长上下文本身不是问题，问题是同一份材料每一轮都被重新传入。一次 20 万 Token 的文档问答，连续追问十轮且每轮都带全文，输入成本会随轮数快速累积；工具日志、网页正文和代码结果也会留在历史里继续计费。更常见的做法是：先检索相关片段，再让模型阅读；多轮对话用滚动摘要；稳定部分做成缓存前缀；只对必须保留的原文使用长上下文。

长上下文还会放大延迟和失败率。非流式长请求更容易遇到网关超时，重试又会带来新的输入用量。长任务应优先使用流式输出，并设置合理的读超时。

五、重试与失败请求怎么算

官方错误码把 429 分成三类：rate_limit_reached_error 是组织级并发、RPM、TPM 或 TPD 触顶；exceeded_current_quota_error 是余额或额度不足；engine_overloaded_error 是服务端容量过载。只有余额类问题能靠充值解决，容量过载充值也不能直接消除。500、503 通常建议稍后重试；长请求的网关超时则更适合改流式，而不是原样重发。

失败请求是否计费，官方文档没有给出“失败免费”的承诺。稳妥做法是不要假设重试没有成本，用请求日志和 usage 对账，并把重试次数单独统计。重试策略可以按下面的顺序落地：

  1. 先按错误码分类，欠费、参数错误和内容审核失败不要重试。
  2. 只对 429 限流、500、503 和网络中断做有限重试。
  3. 使用指数退避加随机抖动，并遵守 Retry-After。
  4. 给重试设上限和总时长，避免一直占用并发。
  5. 工具调用要有幂等键或去重表，防止重复下单、重复发消息。
  6. 记录 request_id、模型名、Token 用量和重试次数，便于对账。

六、预算估算：从 Token 到月度上限

预算不要从“每百万 Token 多少钱”倒推，而要从真实任务倒推。选 20 到 50 条有代表性的任务，覆盖简单、中等、复杂三档，写清验收标准；再用估算接口量输入，读取真实调用的 usage，用“完成一个合格任务的总成本”比较型号。

import os
import requests

resp = requests.post(
    "https://api.moonshot.cn/v1/tokenizers/estimate-token-count",
    headers={"Authorization": f"Bearer {os.environ['MOONSHOT_API_KEY']}"},
    json={
        "model": "kimi-k3",
        "messages": [{"role": "user", "content": "把这段合同抽取成 JSON：……"}],
    },
    timeout=30,
)
print(resp.json()["data"]["total_tokens"])

估算出单次输入后，还要补上四块：历史消息、工具返回、缓存未命中的比例、重试带来的额外调用。离线批处理可以评估 Batch API，官方文档称其较同步调用低约四成，但目前只支持 kimi-k2.7-code 和 kimi-k2.6，kimi-k3 尚未支持。

预算控制建议分三层：按项目设日预算和月预算，控制台达到上限后会拒绝该项目请求，但执行可能有约十分钟延迟；按 Key 或成员拆分，避免一个业务打满全组织额度；按模型和场景做周度对账，找出增长最快的调用。余额预警只能防突然断供，不能替代预算。

七、降本顺序与对账习惯

降本顺序不要反。先做缓存和输入治理，再限制输出，最后才考虑换型号；否则只是把错误答案做得更便宜。

  1. 固定 system prompt、工具定义和知识库前缀，验证 cached_tokens。
  2. 用检索和摘要减少每次传入的原文，历史消息做滚动摘要。
  3. 设置 max_completion_tokens，要求 JSON 或固定字段，减少开放式长输出。
  4. 按任务路由型号：通用任务用 kimi-k2.6，代码任务用 K2.7 代码版，超长材料再上 K3。
  5. 长请求改流式，降低超时和断连带来的重试。
  6. 离线任务走 Batch API，实时任务保留同步接口。
  7. 每月按项目、型号、场景三个维度对账，单独记录缓存命中率、重试次数和平均输出长度。

对账单至少要有：调用时间、项目、模型、输入 Token、缓存命中 Token、缓存写入 Token、输出 Token、重试次数、request_id。缺少这些字段，账单出现差异时只能猜。

常见问题

moonshot-v1-8k 还能继续调用吗？

不能。moonshot-v1 全系已在 2026 年 8 月 31 日下线，官方建议迁移到 kimi-k3。迁移时不仅要改模型名，还要重新核对上下文长度、计费项和输出参数。

缓存命中为什么没有生效？

先检查前缀是否被时间戳、随机 ID、动态排序或工具重排破坏；再确认请求间隔没有超过 TTL；最后确认缓存写入和读取在同一组织、同一 TTL 档位。用 cached_tokens 判断，不要凭感觉。

长上下文一定更贵吗？

不一定，但重复传入长材料通常会贵。成本取决于输入被重复的次数、缓存命中率和输出长度。先用检索缩小范围，再决定是否使用百万级上下文。

失败请求会计费吗？

官方文档没有承诺失败免费。不要假设重试零成本，应通过请求日志和 usage 核对，并把重试次数纳入单任务成本。

最新价格在哪里看？

以站内模型价格和 Moonshot/Kimi 官方文档为准。价格、模型名单和缓存规则都可能调整，不要沿用旧截图。

下一步

先在中商起航 AI 网关创建测试 Key，用 kimi-k2.6 和 kimi-k3 各跑一批真实任务，记录输入、输出、缓存命中与重试，再决定主力型号和月度预算。具体价格与可用型号以模型价格为准。

相关阅读：