kimi k2.5 价格

很多人第一次接 Kimi，看到「输入价、输出价、缓存价」几个字段就以为懂了，结果月底账单一对，差出一截；写代码时走 Code API，又搞不清它和普通对话接口是不是同一套价。这篇不讲缓存怎么生效，只解决一件事：把 K2.5 和 Code API 的计价口径对齐，给你一张能照着走的核对清单，剩下具体数字去站内页面看当时的行情。

很多开发者第一次接 Kimi，看到输入价、输出价、缓存价几个字段就以为懂了，结果月底账单对不上，差出一截。问题通常不在单价本身，而在于没搞清自己到底在为哪几类用量付钱。

这篇不讲缓存怎么生效，也不给具体数字，只解决一件事：把 K2.5 和 Code API 的计价口径对齐，给你一张能照着走的核对清单。具体单价去站内页面看当时行情，别背数字，行情会变。

先把计价拆成几段：你到底在为哪几件事付钱

计价的第一层不是模型，而是用量类型。输入、输出、缓存读、缓存写这四类，在很多平台上是分开计价的。最容易踩的坑是把缓存读当成普通输入价去乘，实际它可能便宜也可能因为写入而额外计费，得逐项确认。

输入 token

你发给模型的全部内容，包括系统提示、历史对话、代码文件

输出 token

模型生成返回的内容，通常单价高于输入

缓存读

命中缓存后读取的那部分，是否单独计价要看平台口径

缓存写

把内容写进缓存的动作，有些平台会单独收一次

• 确认长上下文是否有超长段加价区间：同样是百万 token 输入，长度不同可能不是同一个价
• Code API 与通用对话接口是否共用一套单价，多数情况口径一致，但调用入口、限速和可用模型清单不一样
• 计费单位是 token 不是字数，中英文混排、代码块、工具调用返回的 JSON 折算方式都不同
• 工具调用（function call）产生的参数和返回值同样计入 token，别漏算

查价格时别只看一个数：报价页哪几列要一起看

报价页给的通常是每百万 token 的单价，而你的用量日志记的是原始 token 数，两步换算不能跳。更关键的是报价页往往有好几列，输入一列、输出一列、缓存一列，只看最显眼那个数必然算错。

如果你走的是官方之外的渠道，先去站内中转站目录看它的计费口径和倍率怎么标。渠道价和官方价是两套账，混在一起算出来的数字没有任何参考价值。到 Kimi 官方平台：长文本成本参考（/official-api/providers/moonshotai） 核对当前单价，到 AI 模型库（/models） 看模型规格，再用 Token 单价换算（/tools/token-price-calculator） 把用量套进去。

从用量倒推花费：四步核对流程

1. 导出日志拉最近一周调用记录，至少保留时间、模型名、输入 token、输出 token、是否命中缓存这几列
2. 分组求和按模型加计费类型分组，得到四类用量的原始数字，别直接拿总数乘一个单价
3. 自算金额拿站内当期单价分别相乘再相加，结果和账单数字并排写下来
4. 查差额差额超出你能接受的阈值时，先查重试重发、长上下文截断后重跑、测试流量混进正式环境这几项，而不是先怀疑单价

这个流程的重点在第四步。绝大多数账单差异不是单价变了，而是用量统计口径和你的直觉不一致。把差额先归因到用量侧，能省掉大量和平台扯皮的时间。

Code API 和普通接口，成本结构差在哪

编程场景的输入里往往塞了大段代码和文件内容，输入 token 占比远高于聊天场景，所以输入单价对 Code 用量更值钱。反过来，一轮任务里模型可能连续多轮读写文件，输出 token 会成倍增长，按单次调用的直觉去估会严重偏低。

• 先在测试环境跑一个有代表性的任务，记录完整一轮的 token 总量，再乘日均任务数
• Code 场景重试和回滚很常见，要专门统计失败请求的 token 消耗，这部分是纯浪费
• 把工具返回的 JSON 也算进输入，它在 Code 场景里占比不小
• 区分探索性调用和正式调用，探索阶段可以放宽，正式环境要收紧

能立刻做的三件事，把成本压回可预期

一是把不必要的历史上下文裁掉，只保留当前任务需要的文件和最近几轮对话。长上下文任务的成本曲线不是线性的，砍掉冗余上下文的收益往往立竿见影。

二是给项目设预算阈值并挂告警，具体怎么设可以参考站内 预算告警怎么设：把跑飞限制在一晚以内的 5 道闸（/guides/budget-alert-five-gates）。三是建立每周复盘，把用量、账单、重试次数三个数放一张表里看趋势，异常通常在趋势里先露头。

如果实在拿不准自己的量级该按哪档估，别去猜，先跑一周真实流量再回来算。行情和单价以站内当期页面为准，任何时候「现在的数字」都比记忆里的可靠。