你以为接了一次 API 才花几分钱，月底账单却翻了三倍——问题多半出在「你没看懂 Kimi 是怎么计费的」
很多团队第一次把 Kimi（Moonshot）接进产品时，都被同一个问题绊住：文档里写着「每百万 token 几分钱」，可真跑起来，月消耗和预想差出一大截。差距不在模型贵，而在计费单位、上下文长度档位、输入与输出的价差、以及缓存命中等几个细节叠加之后的结果。看懂这一套规则，你才真正能控制成本。
一句话认识它：Moonshot 定价指的是月之暗面 Kimi 开放平台（platform.moonshot.cn）对大模型调用收多少钱[1]，核心规则是按 token 计费、输入与输出分别计价、上下文越长单价越高，并支持上下文缓存与预付费资源包来降本[2]。它卖的不是「一次问答」也不是「一个账号」，而是你每次请求实际消耗的 token 数量。
先说最反直觉的一点：你付的钱，和「调用次数」几乎没关系
和订阅制产品不同，Kimi 开放平台走的是用量计费（pay-as-you-go）。一次普通的「问一句话、答一句话」可能只消耗几百个 token，成本低到可以忽略；但当你把几千字的产品文档塞进 system prompt、又要求它产出一篇长文，单次请求的 token 量就可能冲到几万甚至十几万。下面这页就专门把计费里最容易让人算错的地方拆开讲清楚。
新手最容易算错账的三个地方
- 把「一次调用」当成计费单位：实际计费的是 token 数，长上下文 + 长输出会让单次成本成倍放大，调用次数少不代表账单小。
- 忽略输入比输出便宜的价差：大多数模型输出 token 单价明显高于输入；只盯着输入价格估算，会严重低估真实开销。
- 忘了上下文长度档位：同样一个模型，8k、32k、128k 不同上下文窗口往往对应不同单价，长上下文那一档通常更贵。
把账算对的三条心法
- 先估 token 再估钱：中文约 1 个汉字 ≈ 1 到 2 个 token（视分词而定），先把典型请求的输入、输出长度估出来，再乘单价。
- 输入 / 输出分开测算：用「输入单价 × 输入量 + 输出单价 × 输出量」的拆解公式，比只看一个笼统单价更接近真实账单。
- 用缓存摊薄固定前缀：system prompt、知识库前缀这类每次都重复的内容，命中上下文缓存后通常只需按更低费率计费，长期能省下一大块。
务必说明：下文给出的都是计费结构与估算方法，具体每一档的单价、免费额度、资源包折扣与币种，以官方定价页 https://platform.moonshot.cn/pricing 的实时公示为准；厂商会不定期调整价格与档位，下结论前请先比对官网。
六块计费要素：一笔 Kimi API 账单到底由什么组成
把「调用 Kimi 花了多少钱」这件事拆开，背后是六块相对独立、又能叠加影响的计费要素。理解每一块，你就能定位到底是哪个环节把成本推高了。
① 计费单位：Token
Kimi 按 token 而非字符或次数收费。token 是模型切分文本的最小单位，中文里一个字往往对应一到两个 token，英文单词则按子词切分。所有成本都从「你这次请求消耗了多少 token」算起。
② 输入与输出分开计价
发给模型的提示（prompt）算输入 token，模型生成的内容算输出 token，二者单价通常不同，输出往往更贵。做成本测算时必须分别估算，不能混为一谈。
③ 上下文长度档位
同一模型常按上下文窗口（如 8k / 32k / 128k）划分档位，支持更长上下文的档位单价更高。如果你的任务用不到超长上下文，选短档位能直接降本。
④ 上下文缓存 Cache
对每次请求都重复出现的长前缀（如系统提示、知识库片段），平台可提供上下文缓存，命中的部分按更低费率计费。高频固定前缀场景下，缓存是主要的省钱杠杆。
⑤ 模型分级与套餐
Kimi 开放平台提供不同代际与定位的模型（如 K2 系列、K1.5、K1 等），旗舰模型能力强但单价高，轻量模型便宜，按任务难度选模型是控制单价的关键手段。
⑥ 视觉 / 文件多模态
当请求包含图片、文件或长文档理解时，除文本 token 外还可能产生对应的视觉或文档 token 开销，这类多模态输入会单独计入消耗，需在估算时额外考虑。
一套可照抄的成本估算流：从一句需求到月账单
下面把「怎么把 Kimi 的账算明白」落成四步。你可以只取其中几步，但建议至少走完前三步再谈预算。
- 统计典型请求的体积：先量出你线上最典型的几条请求——system prompt 多长、每次塞进多少知识库、用户问题平均多长、模型平均回多长，分别折算成输入 / 输出 token。
- 乘上对应单价：拿到官方定价页的各档输入 / 输出单价后，用「输入单价 × 输入量 + 输出单价 × 输出量」算出单次成本，长上下文与缓存命中要按各自费率分别处理。
- 放大到月调用量：把单次成本乘以你预估的日均 / 月均调用次数，得到基准月账单；再按峰值倍率留出余量，避免大促或突发流量把预算打穿。
- 用缓存与模型降级压价：对固定前缀开启上下文缓存，对简单任务改用轻量模型，必要时采购预付费资源包锁定折扣，最后回到第 2 步复核一遍省了多少。
按量后付费，还是预付费资源包？两种模式怎么选
按量后付费更适合谁
- 刚接入、用量不稳的团队：先小流量试跑，按真实消耗结算，不用先押一笔钱，方便快速验证场景是否成立。
- 波动很大的业务：调用量时高时低、难以预估月度总量的项目，后付费不会被资源包额度闲置拖累。
- 做 POC 与demo：演示、评测、内部试用阶段，用多少算多少，财务上最干净。
预付费资源包更适合谁
- 用量明确且持续的线上业务：每月消耗稳定、规模可观时，资源包通常带折扣，长期比纯后付费更省。
- 预算需要前置锁定：财务要求先把钱花在明处、控制现金流节奏的团队，资源包能把成本前置可视化。
- 对单价敏感的大户：调用量越大，资源包摊下来的边际单价越低，规模效应明显。
三个最容易踩的坑：钱就是这么悄悄花超的
把整个知识库塞进每轮对话。每轮都把几千字文档重复发一遍，输入 token 会随轮次线性累加；正确做法是把它放进可缓存的固定前缀，或改用检索后只送相关片段，避免重复计费。
用 128k 档位跑其实很短的任务。上下文档位越高单价通常越高，明明用不到长窗口却默认开最高档，等于为用不上的能力持续付费；按真实长度选档能直接降本。
忽视输出长度上限与截断重试。输出被截断后重新发起长请求，会重复消耗输入；用合理的 max_tokens 与停止条件控制产出，比放任模型长生成更省。
常见问答
Kimi 开放平台到底按什么收费？
按 token 用量计费，输入（prompt）与输出（completion）分别计价，不同上下文长度档位对应不同单价，并支持上下文缓存与预付费资源包。具体每一档的单价与免费额度以官方定价页实时公示为准。
输入 token 和输出 token 价格一样吗？
通常不一样，输出 token 的单价一般高于输入。做成本测算时务必把输入、输出分开估算，只盯输入价格会严重低估真实账单。视觉、文件等多模态输入也可能单独计费。
上下文缓存（Cache）能省多少？
对每次请求都重复出现的长前缀（如系统提示、固定知识库片段），命中缓存的部分按更低费率计费，高频固定前缀场景下是主要的省钱杠杆。具体折扣比例与命中规则以官方文档说明为准。
不同模型（K2 / K1.5 / K1 等）怎么选最划算？
旗舰模型（如 K2 系列）能力强、单价高，适合攻坚复杂任务；轻量模型便宜，适合摘要、分类、抽取等简单任务。按任务难度分级选型，把贵模型留给真正需要的地方，是控制单价最有效的手段之一。
预付费资源包和后付费哪个更省？
用量稳定且规模可观的线上业务，资源包通常带折扣，长期更省；用量波动大、还在验证阶段的团队，按量后付费更灵活、不被闲置额度拖累。可先用后付费摸清真实量，再决定是否切资源包。
怎么快速估算我接 Kimi 后的月成本？
先量出典型请求的输入、输出 token 长度，乘上官方各档单价得到单次成本，再乘以预估月调用量并留峰值余量；对固定前缀开启缓存、对简单任务降级模型后复核一遍。本文第四节的「四步估算流」可照着套用。
参考资料
- 来源：Moonshot AI（月之暗面）Kimi 开放平台官方定价页（各模型 / 各上下文档位的输入、输出单价与资源包说明）：https://platform.moonshot.cn/pricing
- 来源：Kimi 开放平台官方文档（计费单位、token 概念、上下文缓存与调用方式）：https://platform.moonshot.cn/docs
- 来源：Kimi 开放平台控制台与计费说明（资源包、免费额度、用量查询入口）：https://platform.moonshot.cn/console
- 来源：月之暗面公司官方主页（Kimi 产品定位与模型家族概览）：https://www.moonshot.cn/
- 来源：Kimi 模型能力说明（K2 / K1.5 等模型的上下文、多模态与适用场景）：https://platform.moonshot.cn/
- 来源：大模型 token 计费通用概念参考——主流开放平台按 token 计价与输入 / 输出价差的通行做法（以各家官方文档为准）：https://en.wikipedia.org/wiki/Large_language_model
青衣网络 AI 观察团队 · 最后更新 2026-08-25 | 本文基于 Moonshot / Kimi 开放平台公开信息整理，旨在帮助用户理解其计费结构与成本测算方法；具体单价、免费额度、资源包折扣、模型档位与币种随时可能调整，实际接入与预算请以官方定价页与文档最新公示为准。