Kimi API 价格与计费（2026）：K2 系列与长上下文成本

Kimi API 采用按量计费，不提供订阅制。比价时只看“每百万 Token 多少钱”很容易选错：真正决定账单的是型号、上下文长度、缓存命中率和输出长度。K2 系列提供 262,144 Token 上下文，K3 进一步到 1,048,576，长上下文能力强，也意味着输入侧更容易累积成本。

本文拆解 K2 系列的计费结构、长上下文的成本来源、可复现的测算方法和降本顺序，不写死单价。具体价格以官方文档和站内模型价格为准。

说明：Moonshot、Kimi 是其权利人的商标。模型型号、上下文长度和计费规则可能调整，本文以 2026 年 10 月的常见情况为例，采购前请再次核对官方页面。

一、K2 系列怎么分工

型号	定位	上下文	适合任务	成本关注点
`kimi-k2.6`	通用	262,144	对话、抽取、客服、文档处理	缓存命中率
`kimi-k2.7-code`	代码	262,144	代码生成、仓库问答、Agent	输入长、工具结果多
`kimi-k2.7-code-highspeed`	代码高速版	262,144	低延迟补全、交互式编码	单价与吞吐的平衡
`kimi-k3`	新一代	1,048,576	超长文档、复杂多步任务	长上下文与缓存写入

型号会迭代，K2 系列后续可能增加新版本。采购时以官方模型列表和站内模型价格为准，不要把本文的型号名当成永久承诺。

通用任务不必默认上最大上下文。把整份资料塞进 1M 上下文，输入成本会随轮数快速累积；先用检索缩小范围，再让模型读关键片段，通常更划算。代码任务则相反，仓库结构和工具返回往往必须保留，重点是稳定前缀、提高缓存命中。

二、账单由三块组成

K2 系列按“缓存命中输入、缓存未命中输入、输出”三项计费。K3 另把缓存写入按 5 分钟和 1 小时两档 TTL 单独计价，所以不能用一个平均单价乘总 Token。

计费项	什么时候产生	成本影响	控制手段
缓存未命中输入	首次出现的提示词、文档、工具结果	随上下文线性增长	检索、摘要、裁剪历史
缓存命中输入	重复的 system prompt、固定前缀	通常明显低于未命中	稳定前缀、固定工具顺序
输出 Token	模型生成内容与思考	长输出放大账单	限制 `max_completion_tokens`
缓存写入（K3）	写入缓存前缀	按 TTL 档位计价	只缓存稳定复用的内容

把一次请求拆开，成本公式是：

单次请求成本 =
  未命中输入 Token × 未命中单价
+ 命中输入 Token × 命中单价
+ 输出 Token × 输出单价

K3 还要加缓存写入项。响应里的 usage 会给出 prompt_tokens、completion_tokens 和 prompt_tokens_details；其中缓存命中与缓存写入都算在 prompt_tokens 里，未缓存部分要用总数减去这两项。

三、长上下文为什么容易贵

场景	典型 Token 结构	主要成本	优化方向
长文档问答	输入大、输出中等	文档反复传入	检索加缓存
代码仓库 Agent	输入输出都大	工具结果和历史	摘要、裁剪、缓存
多轮客服	输入随轮数累积	历史消息重复	滚动摘要
批量抽取	输入中等、输出短	文档重复读取	批处理加小模型

差异通常来自五处：

输入随轮数累积：每轮都把全文再传一次，账单会按轮数近似翻倍。
缓存命中率：固定前缀能复用；每次都变的时间戳、随机 ID、动态排序会让缓存失效。
工具输出：一次搜索或代码执行返回整段日志，下一轮又原样带回，成本会叠加。
输出长度：开放式的“详细分析”最容易产生长输出，而输出通常比缓存命中输入贵。
型号错配：简单分类用大模型，或复杂任务用不合适的型号反复重试，都会放大成本。

四、做一次可复现的测算

选 20–50 条真实任务，覆盖简单、中等、复杂三档，写清验收标准。
先用 Token 估算接口量化输入，不要用字数猜。
同一批任务分别跑 kimi-k2.6 和代码型号，记录质量、延迟与返工次数。
从响应 usage 读取输入、输出、缓存命中与缓存写入。
用“每完成一个合格任务”的成本比较，而不是每百万 Token 的标价。
把重试、失败请求和缓存写入一起算进单任务成本。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.cn/v1",
)

resp = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "user", "content": "把这段合同抽取成 JSON：……"}],
    max_completion_tokens=1024,
)

u = resp.usage
print("输入", u.prompt_tokens, "输出", u.completion_tokens)
print("缓存明细", getattr(u, "prompt_tokens_details", None))

流式调用要加 stream_options={"include_usage": True}，完整用量只在最后一块返回。金额要用合同或价格页的实际单价去乘，不要沿用几个月前的截图。

五、把成本降下来的顺序

先做缓存：固定 system prompt、工具定义和知识库前缀，用 cached_tokens 验证是否真的命中。
再减输入：检索只召回相关片段，历史消息做摘要，不要把整库塞进上下文。
限制输出：设置合理的 max_completion_tokens，要求 JSON 或固定字段，减少客套话。
做型号路由：通用任务用 kimi-k2.6，代码任务用 K2.7 代码版，超长材料再考虑 K3。
长请求改流式：流式不直接改变单价，但能减少超时和断连带来的重试。
监控与告警：按项目、型号、场景看用量，设预算上限，每周复盘消耗排名。

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

六、预算和账单怎么管

一个项目一把 Key，按项目设日预算，避免一个业务打满全部额度。
每月按“项目、型号、场景”三个维度对账，找出增长最快的调用。
缓存命中率、重试次数和平均输出长度要单独记录，否则优化效果无法证明。
需要人民币付款和发票的团队，可以用国内 AI 网关统一多模型账单；具体价格和发票规则以模型价格为准。

常见问题

K2 和 K3 哪个更划算？

取决于任务。K2 系列上下文 262,144，覆盖多数文档和代码场景；K3 上下文更大，适合超长材料。按“完成一个合格任务”的总成本比较，不要只看单价。

缓存能省多少？

取决于前缀复用率和命中率。缓存命中输入通常明显低于未命中，命中还会延长缓存有效期；但前缀每次都变、或前缀太短，就不会命中。

流式输出会更便宜吗？

不会直接改变单价。它的价值是降低长请求超时、连接中断和重试带来的隐性成本。

为什么账单比估算高？

常见漏算项包括历史消息、工具返回、文档全文、重试、长输出和缓存未命中。用请求日志按 usage 对账，才能定位差异。

国内团队怎么用人民币结算？

可以通过提供人民币充值和发票的 AI 网关调用 Kimi，统一多模型账单。具体可用型号、价格和发票规则以模型价格为准。

下一步

先在中商起航 AI 网关创建测试 Key，用 kimi-k2.6 和代码型号各跑一批真实任务，记录 Token、缓存命中与质量，再决定主力型号。模型可用性与价格以模型价格为准。