kimi k2.5 token 价格

做按 token 付费的项目时，最常卡住的两件事是：不知道 K2.5 这一档到底按什么口径收，以及拿到单价后算不出自己一个月要花多少。这篇不讲玄学，只把单价构成、输入输出与缓存的分工、长文本场景下 token 怎么膨胀讲清楚，再给一套可以直接照着做的估算与核对流程，数字一律去站内对应页面看当期版本。

K2.5 的计费单位到底是什么

很多人问 K2.5 的 token 价格，第一步其实不是看单价，而是先弄清楚「一次请求到底被拆成哪几段来数」。数错了段，后面看报价永远对不上账单。

输入和输出不同价，是因为生成每个输出 token 都要跑一次完整前向计算，而输入部分可以并行批量处理。所以同一段文字，作为输入发过去和作为输出返回来，成本结构不一样。具体倍数到站内价格页核对当时数字，别用记忆里的旧比例去估算。

同一句话，中英文 token 数为什么差很多

token 是按子词切分的，不是按字数。常见英文单词往往一两个 token 就装得下，中文常用字可能要一到两个 token 甚至更多，遇到生僻字、专业术语、表情符号、连续数字和代码符号，切得更碎。所以「一千字」在中文里换算成 token，可能明显多于同等信息量的英文。

• 中文按「字」估算最不靠谱，尤其是长文档摘要场景
• 代码、JSON、URL 里的符号切分很碎，token 数往往高于预期
• 混排的中英段、大量空格缩进，都会额外增加 token
• 想知道准确值，就别手算，用分词工具或平台返回的 usage 字段核对

哪些内容一般不算钱

1. 被拒的请求参数格式错、鉴权失败、触发风控被直接拒掉，通常不产生计费，但也别把它当免费额度去刷。
2. 超时或中断未返回的部分连接断掉、你主动取消、服务超时，已经产出的部分怎么算，各家规则不一致，以对方页面上的计费说明为准。
3. 重试要按新请求看失败后自动重试，很可能被当成一次独立请求，两次都计费。写重试逻辑时把这点考虑进去。
4. 免费额度与赠送额度通常优先抵扣，但不代表超出部分不计费，抵扣顺序也要看页面说明。

最后强调一句：字数和 token 数不是一回事。做成本预估时，拿一段你自己的真实输入去跑一次，看返回的 usage 里输入输出各多少，再乘单价，比拍脑袋按字数换算准得多。若你只是想横向比价，记得各家的分词方式不同，同样的中文文本在不同平台上 token 数可能不一样，直接比单价会失真。

单价去哪看，别背数字

先说一句得罪人的话：网上那些把单价直接写进标题的文章，你看到的时候大概率已经不准了。官方来源页会随版本、档位、计费口径调整，写死的数字就是给自己埋雷。所以这一节不给你数字，只给你查数字的路径和顺序，照着走，你自己查到的永远是最新的。

1. 第一步：先看官方平台页去模型供应方的官方平台，找计费或定价那一栏，确认当前在售档位和对应的 token 单价口径（输入、输出是否分开算）。这一步只看官方，不看任何二手转述。
2. 第二步：对照站内价格追踪页把官方当前数字和站内价格追踪页的变动记录比一比，重点看最近一次调整的时间点。如果追踪页还是旧值，说明它还没跟上，以官方为准。
3. 第三步：走中转站的话再乘倍率如果调用是经中转站转发的，官方单价只是成本基线，你实际付的是「官方单价 × 渠道倍率」，有的还叠加固定加价。这两个数必须分开看。
4. 第四步：数字对不上就核对口径先确认是不是同一档位（不同上下文长度、不同模型规格可能分档），再确认是不是同一时间口径（含不含缓存命中价、按次还是按 token）。口径不一致，比出来的差异没意义。

官方单价

模型供应方公布的 token 计费基准，是成本参考，不是你最终付的钱。

渠道倍率

中转站在官方单价之上乘的系数，决定你实际结算价的那一层。

时间口径

同一单价是否对应同一个生效时间段，以及是否含缓存、促销等特殊计价。

档位

按输入输出、上下文长度或模型规格区分的不同价目，不同档位单价本来就不一样。

输入、输出、缓存三笔账怎么分开

很多人第一次看账单会懵：明明只调了一次，为什么账单上冒出好几行。原因是请求里不同的内容走了不同的计费口径。你发过去的那部分（系统提示、历史对话、当前提问、挂上去的资料）算输入；模型吐回来的那部分算输出；如果请求里有一部分被缓存命中，那部分按缓存价走，不再按普通输入价算。三笔账各自独立，谁多谁少都可能，所以要分开看。

缓存这一项最容易被忽略。命中与未命中在单价上通常不是一回事，但它只回答一个问题：会不会影响总账。同一段内容，命中就便宜、不命中就按普通输入算，重复发同样的前缀，命中率高的时候总账能明显降下来。要不要专门为它优化，取决于你的对话是不是每次都带着同一大段前缀——如果每次都换人换题，那这块基本省不到。

长对话是成本翻倍最常见的原因。第一轮可能只有几百字，聊到后面每一轮都把前面所有内容重发，输入量是滚雪球式的。判断方法很简单：把最近几轮请求的输入量拉出来，看是不是一轮比一轮大，且没有收敛。如果是在收敛，说明正常；如果一直线性上涨，那就是历史没做裁剪。

1. 先分清三笔账翻账单或用量明细，看输入、输出、缓存是不是分开列的，分开列就分别记三个数，别只看总数
2. 查历史有没有滚大对比最近几轮请求的输入量，看是否随轮次持续上涨；上涨且不回落，说明每轮都在重发全量历史
3. 查缓存有没有用上看命中量占输入的比例，比例长期很低说明前缀一直在变，或者压根没走缓存路径
4. 换成金额再判断到 /tools/token-price-calculator 把三项量填进去，直接看这一次调用大概花多少，比盯着单价直观得多

• 自查顺序建议：先看总金额，再看是输入占大头还是输出占大头，最后才去看缓存命中率，反过来容易钻进细节出不来
• 如果输出占大头，重点在提示词约束长度和格式；如果输入占大头，重点在历史裁剪和前缀复用
• 多轮助手类应用，建议给历史设一个轮数或字数上限，超出就做摘要或丢弃早期轮次
• 批量任务别沿用同一个超长系统提示，能拆短就拆短，短提示重复调用反而更容易命中
• 这套判断不适用于一次性短请求，那种场景输入本来就不大，拆账的意义有限

长文本场景下的 token 膨胀

同一个问题，问法不同，烧掉的 token 能差出好几倍。原因通常不在你问的那段正文，而在于每次请求都要被重复带上的那部分——系统提示、格式示例、几轮对话历史。这些内容不会因为你这次只关心一句话就自动变小，它们按次计费。

判断该不该改造，看一个比例就够了：单次请求里，那段每次都不变的固定前缀，占整次输入的多少。如果超过一半，说明你花的大头不是内容本身，而是重复搬来搬去的脚手架，这时候拆开或者做缓存往往比硬塞更划算。反过来，前缀很短、正文才是大头，那就没必要折腾。

• 固定前缀占单次输入超过一半，先考虑精简系统提示和示例，而不是先换模型；
• 同一份材料要被追问三轮以上，优先做一次要点提取，再基于要点多轮问；
• 问题之间彼此独立、只关心文档某几段，拆开发往往比整篇塞更省；
• 需要跨段推理、前后文互相印证，长上下文反而更省，因为省掉了重复投喂；
• 已经出现「每轮都在重发同一大段」，先去站内计价页核对当前的输入计费口径

1. 先量出固定前缀把你每次都原样带上的系统提示、示例、历史消息拼起来，估一下它的长度，再和这次真正想问的正文比一比。比例超过一半就进入下一步。
2. 做一次减脂砍掉示例里用不到的格式说明、把多轮历史压成一句结论。减完再量一次比例，如果掉到一半以下，可能就不用动结构了。
3. 决定拆还是合问题互相独立就拆成多次短请求；需要通读和跨段对比就整篇塞，并接受它的固定成本只付一次。
4. 回头看实际用量按新问法跑几轮，对比改造前后的输入量变化。具体口径和数字以站内页面当时展示的为准，别拿印象里的旧数据做判断。

用自己的用量倒推花费

算自己的账，别抄别人的数字。同一个模型，有人每月花几十块，有人花几千块，差别不在单价，在你的用量结构：请求有多密、输入有多长、输出有多啰嗦、重试有多少。先把自己的基线量出来，再谈花多少钱。

1. 挑一个典型任务选你日常跑得最多、最有代表性的那类请求，比如客服问答、文档摘要、代码补全。别挑最复杂的，也别挑最简单的，挑中间的那条主线。
2. 记录三个数连续跑几天，记下请求次数、每次输入的大致长度、每次输出的大致长度。手工记也行，写个小脚本打日志也行，关键是别凭印象。
3. 把长度换算成 token中文大约一个字一个 token 上下，英文和代码按词和符号拆，会更碎一些。粗略估就行，不用抠到个位，误差留一成就够。
4. 算单任务成本输入 token 数乘输入单价，输出 token 数乘输出单价，两边加起来就是一次请求的钱。单价去站内价格页对照，别用记忆里的数。
5. 乘月频次，再加余量单次成本乘一个月大概跑多少次，得到理论月花费。然后往上加两到三成，留给重试、失败重发、调试期的试错。

站内的用量统计页和价格追踪页可以拿来对照：用量页帮你看清自己的请求分布，价格页帮你确认当期单价有没有变。但这两边都只是参照，真正决定预算的是你上面记的那几列数。如果用量页显示的请求数比你手记的多出一大截，先查有没有隐藏的轮询或定时调用，再改预算。

• 预算按上浮两到三成做，别按理想值做，调试期的浪费是真实成本
• 单价会变，重算时要回站内价格页确认当期数字，别沿用上个月的
• 输入长度比输出长度好控制，想省钱先砍输入，比如精简上下文和示例
• 月末对一次账：实际花费和预估值差多少，差得多说明基线该重新量

什么情况下单价说了不算

看单价有一个很容易踩的坑：那个数字通常是「按成功一次调用」算出来的理想值，而你的账单是按「实际扣了多少 token、扣了几次」结算的。中间只要多出重发、多轮追问、口径切换，两条线就会分叉。所以别只盯单价，要盯「每完成一个任务花了多少」。

• 被限速打断 → 客户端自动重试，失败的那次往往也计了输入 token，账单调用的次数比你以为的多
• 首轮答得勉强能用但不达标 → 追问两三轮，总 token 是首轮的几倍，成本要按最终成功的那个任务算
• 同一批请求里混了长上下文和短上下文 → 单价一样，实际单次消耗差好几倍
• 结算口径不同 → 批处理、缓存命中、阶梯档位会让单价和实际结算价分叉

1. 先把「任务」和「调用」分开数一周的日志里，同一个业务目标下有几个请求算一个任务。用「成功任务数」做分母，而不是请求总数。
2. 把重试和追问单独打标请求头带一个自增的 trace id，重试沿用同一个。事后统计每个 trace 实际发出几次、失败几次，重试率就出来了。
3. 算两个数再对照一个数=调用次数 × 单价，另一个数=实际计费 token 总量折算出来的钱。两个数差得越多，说明单价越不能直接用。
4. 口径不确定就去站内核对缓存、批处理、阶梯档位这类规则各家写法不同，别凭印象，去 计价说明（/pricing） 看当时的定义，再回来套自己的模型。

反过来，凡是「失败要重发」「要追问才满意」「一天跑几千上万次」的用法，单价就只是个起点。真正决定预算的是重试率、追问轮数和结算口径这三件事，把这三个变量记下来，比记住任何一个单价数字都有用。具体到某个模型的当期单价和口径，去站内页面看当时的数字，别拿旧印象套。

月末核对清单：三步对平账

月末对账不是财务的事，用 Kimi 这类按 token 计费的接口时，自己动手核一遍才不会到月底被账单吓一跳。下面这三步按顺序做，半小时内能跑完，做完你就知道这个月的钱大概花在哪、下个月该从哪省。

1. 第一步：对调用量打开平台后台的用量统计页，把本月的请求数抄下来，再跟你自己服务端日志里打到 Kimi 的条数比一比。两边差在几个百分点以内算正常，通常来自重试、超时后重发、或者日志漏记；如果差出一大截，先查你的网关是不是把失败的请求也算了进去，或者有没有别的服务在偷偷调同一个 key。
2. 第二步：对计费项把输入 token、输出 token、缓存命中这三块拆开看占比。你自己预估的比例和后台给的比例对不对得上，重点看输出：输出单价通常比输入高，输出占比突然涨上来，多半是模型话变多、或者你把 max_tokens 设太宽。缓存那栏如果一直是零，说明你的提示词没命中缓存，这块本来能省的钱就白白流走了。
3. 第三步：对异常请求按单次消耗从高到低排一下，把最贵的那几十条捞出来看。常见原因是上下文没控制住——把整篇文档、整段历史对话原样塞进去，一次就吃掉大量输入 token。找到这类请求后，回头改你的截断逻辑或者检索环节，比调模型参数管用得多。

• 对量之前先把时区对齐，平台按自然月算，你的日志如果是 UTC，跨月那几小时会对不上
• 重试逻辑要单独打标记，不然它会把一次真实调用算成好几次
• 缓存那块建议单独拉一个趋势看，命中率掉了就是提示词结构变了
• 异常请求不要只看绝对值，结合请求类型看，长文总结天然就比短问答贵

不改效果的前提下降成本

降成本这件事，很多人第一反应是换更便宜的档位，但真正动起来你会发现，最直接的收益往往来自另一头：把每次都在重复发送的那一大段固定内容砍掉。系统提示、角色设定、少样本示例、历史对话，如果每轮都原样带上去，那这部分钱是每次都在花的。先把它们做精简，效果不改，账单先降一截。

• 把系统提示里可有可无的礼貌用语、重复约束合并成几条硬规则，能删就删
• 历史消息不要全量回传，只保留最近几轮加上必要结论，早期内容做摘要
• 固定示例能减到一两个就够，别把整本说明书塞进提示词
• 同一会话里反复出现的背景资料，考虑放外部检索，按需取用而不是每轮都带

简单分类、关键词抽取、格式转换这类活，对模型能力的要求本来就不高，用和复杂推理同档的配置属于浪费。反过来，如果一个任务本身就需要长链条思考，硬压到低档只会让你反复重试，反而更贵。判断标准很简单：先看这个任务错一次要花多少人力去兜底，兜底成本远高于省下的那点用量，就别降档。具体每档的当前单价，到站内的价格页核对当时的数字，别凭印象。

同样一段内容，输出侧的计费通常高于输入侧，所以让模型少说废话，回报往往比压缩输入更明显。做法不是简单加一句「简短回答」，而是在提示里把输出结构定死：要几行、要什么字段、不要解释。凡是要求它「详细说明」「多举几个例子」的地方，都要问一句这个详细到底有没有人看。

1. 定输出格式在提示词里写清输出是几行、什么字段、是否允许额外解释，越具体越好
2. 做对比拿同一批输入跑两版提示，一版放开写，一版限定格式，比较输出长度和可用率
3. 看废弃率如果限定格式后，人工还要去补解释，说明限制过头了，往回收一点

最怕的情况是为了省钱，把召回质量悄悄做没了，而这个问题往往要等用户投诉才暴露。稳妥的做法是拿一小批真实流量做影子对比，新旧两套配置同时跑，把结果放一起看差异。差异在可接受范围内再放量，放量也分批走。判断「可接受」的标准要提前写下来，别等出了结果再找理由说服自己。具体比对的字段和口径，可以参考站内指南中心里关于评测流程的说明。

• 选一批有代表性的真实输入，覆盖常见和边缘情况
• 新旧配置各跑一遍，保留完整输出做逐条比对
• 重点看漏召回、格式错、答非所问这三类问题
• 差异超标就先改提示词，改不动再考虑回滚档位
• 放量按比例分批，每批观察一段再继续