kimi api价格

准备用Kimi接长文档处理、报告解析这类应用时，最容易卡的往往不是代码，而是算不清账：文档动辄几万字，输入输出混在一起，一次跑完到底落在哪一档、会不会因为重试和缓存多花钱，事前很难判断。这篇按「先定档位、再看用量、最后对场景」的顺序拆一遍，让你在动手前就能估出大致量级，并知道哪些情况下这套估法不成立。

准备用 Kimi 接长文档处理、报告解析这类应用时，最容易卡的往往不是代码，而是算不清账。文档动辄几万字，输入和输出混在一起，一次跑完到底落在哪一档、会不会因为重试和缓存多花钱，事前很难判断。更麻烦的是，长文本任务和普通聊天的成本结构完全相反，拿聊天机器人的经验去估，往往会严重跑偏。

这篇按「先定档位、再看用量、最后对场景」的顺序拆一遍。目标是让你在动手前就能估出大致量级，知道钱主要花在哪几个维度上，也清楚哪些情况下这套估法不成立。所有具体单价、上下文上限这类会变的数字，一律到站内对应页面核对当时的口径，别照搬任何二手结论。

为什么长文本应用要先把计费档位搞清

Kimi 这类平台的定价通常按模型能力分档，长文本档和通用档的单价口径不是一回事。选错档位比写错代码更费钱，因为代码错了你能立刻看到报错，档位错了要到月底看账单才发现。所以在写第一行业务代码之前，先把档位这件事定下来。

• 长文本任务的输入占绝对大头，成本结构和短对话场景完全相反，用后者的估法会严重低估总账
• 档位决定的不只是单价，还包括上下文上限、并发能力和是否支持缓存，这几项直接决定架构怎么搭
• 同一份文档分段送和整篇送，token 计数可能差出一截，档位选择会和切分策略互相牵制
• 不适用的情况：如果你的应用输入常年只有几百字，档位差异被总量稀释，这时优先看调用次数而不是档位

一档价到底由哪几个维度决定

很多人以为档位就是一个单价数字乘以 token 总量，其实计价口径里藏着好几个维度，任何一个理解错都会让估算偏离。下面这几个是最常被忽略的。

输入侧

长文档、附件、多轮历史全部计入，同一篇文章分段送和整篇送，token 数可能差出一截

输出侧

摘要类任务输出通常远小于输入，逐段改写类任务会让输出反超，两类必须分开估

缓存与命中

重复送同一份长文档时，缓存读写是否分开计价、命中条件是什么，会明显改变总账

附加项

超长上下文是否加价、并发或速率限制是否绑档位、失败重试是否重复计费，都要在动手前问清

这四项里新手最容易漏掉的是缓存口径和重试计费。缓存听起来是省钱的，但如果你的前缀每次都变，命中率接近零，反而多了一层复杂度。重试更隐蔽，客户端超时自动重发一次，你可能以为只调用了一次。当时的真实数字，到 Kimi 官方平台：长文本成本参考（/official-api/providers/moonshotai） 核对。

长文本应用的成本长什么样

长文本应用的典型形态是「大输入、小输出、低调用次数、单次金额高」。这和聊天机器人「小输入、中输出、高调用次数」是两条完全不同的曲线。一次百页文档解析的成本，可能抵得上几百次普通问答，所以优化重点在文档预处理，而不在提示词微调上抠字。

• 省钱位置一：先做去重和切分再送，别把整本书塞进一次请求
• 省钱位置二：把稳定不变的前缀做成缓存，比如固定的系统提示和格式说明
• 省钱位置三：对非关键段落降级到低档模型，只把核心章节送到高档档位
• 省钱位置四：压住重试，超时阈值和重连策略要按长文档的实际耗时设，别用短请求的经验值
• 不适用的情况：文档每天全量变化、缓存几乎命中不了时，缓存那条路基本无效，只能从切分粒度下手

哪一档配哪类场景

档位不是越贵越好，也不是越省越好，关键是匹配场景。下面按四类常见长文本场景给判断标准，你可以直接对号入座，再对照站内当前的价格口径决定。

1. 先确认场景归类把你的应用归到上表四类中的一类，如果同时沾两类，按成本占比更高的那类定档
2. 再确认瓶颈问自己当前最怕的是答不准、太慢还是太贵，三个只能优先保一个，其余两个接受折中
3. 最后核对数字拿选定的档位到站内价格页核对当时的单价和上下文上限，确认架构能跑通再开工

这里有个容易忽略的点：实时性要求高的场景，档位往往还绑并发与响应速度。这时候比价不是第一优先级，先确认能不能稳定拿到配额，否则再便宜也接不了生产流量。

动手前怎么估一遍花费

估算这件事，重点不是算出一个精确数字，而是得到一个区间，并知道区间为什么这么宽。下面五步按顺序走一遍，基本能覆盖大部分长文本项目。

1. 用真实样本跑分词别用字数除以固定系数硬猜，中文、表格、代码的密度都不一样，拿几篇真实文档实测一遍
2. 算输入总量按「文档数 × 单篇 token × 重试系数」算，重试系数一般按 1.1 到 1.3 留余量
3. 单独估输出抽取类按字段数估，摘要类按原文比例估，改写类要按接近一比一估，三类别混用同一套系数
4. 套换算工具拿总量去 Token 单价换算（/tools/token-price-calculator） 和 模型成本计算器（/tools/model-cost-calculator） 各套一遍，得到区间而不是单点
5. 交叉校验用 真实用量榜（/usage） 上同类任务的量级做对照，偏差过大就回头查分词方式

五步里最容易被跳过的是第一步。用字数硬猜看着快，但中文长文档里表格和代码的 token 密度差异很大，猜出来的数可能差出好几成，后面所有步骤都建立在错误基础上。

账单和预估对不上时先查哪几处

账单比预估高，是长文本项目最常见的问题。别急着怀疑单价涨了，按下面这个顺序排查，多数情况能在半小时内定位。

• 先看隐藏输入：系统提示、工具定义、检索回来的片段都会被计入，这些在估算时最常漏
• 再看重试：超时后客户端自动重发、流式中断后重连，都会产生第二次计费，日志里要有请求标识才查得出来
• 然后看缓存口径：命中率低于预期，常见原因是前缀每次都被改写，或者文档顺序变了导致前缀不匹配
• 最后看并发与限额：被限流后排队重试的请求本身不额外花钱，但会让你误以为单价变高
• 对不上的定期复核方法，可参考 价格变动追踪（/price-watch） 记录的口径变化

哪些情况下这套判断不成立

前面这套估法和档位判断，适用范围是「输入以文本为主、文档相对稳定、调用量可预测」的项目。碰到下面几种情况，就别硬套了，换一套思路更省事。

• 平台调整计费口径时，历史估算会整体失效，任何按旧口径做的对比都不能直接沿用
• 如果你的应用是超高频短请求，档位差异被调用量淹没，此时瓶颈是并发和延迟，不是单价
• 文档里图片、表格、扫描件占比很高时，token 估算误差会明显放大，必须按实际解析结果校准
• 预算极度敏感且总量很大的项目，可能需要重新考虑自建还是调用，这时候光比档位已经没有意义

估算的价值不是算准，而是知道哪几个变量会让结果翻倍。