kimi k2.7 code 价格

你在项目里接上这个编程模型，跑了几轮改代码，月底一看账单跟心里估的差一截——多半不是单价变了，而是你没把输入、输出、缓存、重试这几笔分开算。这篇不背数字，只给你一套能复用的方法：先弄清它按什么计费，再去站内页面取当期单价，最后把用量记录倒推成金额。照着走一遍，下次报价和排期心里就有底。

你在项目里把这个编程模型接上，跑了几轮改代码，月底一看账单跟心里估的差一截。这事多半不是单价变了，而是你没把输入、输出、缓存、重试这几笔分开算。同一份用量，拆开和揉在一起，得出的数能差出好几倍。

这篇不背数字，只给你一套能复用的方法：先弄清它按什么计费，再去站内页面取当期单价，最后把用量记录倒推成金额。照着走一遍，下次给老板报价、给项目排期，心里就有底了。

先搞清楚它按什么收：计费单位与计价口径

编程类模型的账单基本都由「输入 token 加输出 token」两块组成，多数厂商对这两块给的单价不一样，输出通常更贵。所以别拿一个笼统的「每百万 token 多少钱」去乘总量，那样估出来的数只对聊天式短问答有效，放到改代码场景里会偏得离谱。

还有些平台会单独列出缓存读、缓存写的价目，命中缓存的输入便宜很多。但哪些请求能命中、命中之后怎么扣，属于计费口径问题，站内有专文讲账单差异，这里只提醒你换算时别把四项价格混成一项。混了，你后面所有推算都建立在错的前提上。

输入 token

你送进去的代码、历史对话、报错信息，按量计费

输出 token

模型吐出来的代码和解释，单价通常高于输入

缓存读 / 写

部分平台单列，命中缓存的输入更便宜，口径要单独看

计价链路

官方直连、云托管、聚合平台、中转站各有倍率和起扣规则

同一模型在不同入口可能不是同一份价目表。官方直连、云厂商托管、聚合平台、中转站，各有各的倍率和起扣规则。所以结论是：不要记数字，去 官方 API 价格（/official-api） 和 AI 模型库（/models） 核对当期单价与规格，再用 换模型前先比一比率和额度（/ai-nav/category/ai-api） 对齐不同渠道的口径。什么情况下这套不适用？当你只是想对比不同模型的相对贵贱、并不打算真按量结算时，看一个大致区间就够了，不必细究倍率。

一次编程任务的钱到底花在哪几块

第一块是读进去的上下文。IDE 插件或命令行工具通常会把相关文件、历史对话、仓库结构一起塞进请求，工程越大，这部分越容易失控。很多人的账单大头其实在这里，而不是在模型输出上。第二块是模型吐出来的代码和解释，改一个函数可能顺带输出整段文件，输出单价高，长答案的成本是短答案的数倍。

• 读进去的上下文：相关文件、历史对话、仓库结构，工程越大越容易失控
• 模型输出的代码与解释：顺手输出整段文件，长答案成本翻倍
• 来回次数：改、跑、报错、再改，每轮都重新带上上下文，前面内容被重复计费
• 重试与失败请求：网络抖动、限速重发，不少平台照样计费，要单独记一笔

第三块是来回次数。一次任务往往不是一问一答，而是改、跑、报错、再改的循环，每轮都要重新带上上下文，轮数越多，前面的内容被重复计费越多次。第四块是重试与失败请求，网络抖动、限速被卡之后的重发，很多平台照样计费。这块怎么算、算不算重复，站内已有专文，这里只让你把它当成一个独立账目记下来。

想快速估量级，用 模型成本计算器（/tools/model-cost-calculator） 和 Token 单价换算（/tools/token-price-calculator） 把这次任务的用量代进去，比心算靠谱。这两个工具不替你决定该不该用，只负责把你的用量翻译成金额。

实操：把用量记录倒推成金额的四步

1. 取数从平台后台或调用日志导出这段时间的输入 token、输出 token、缓存读写量、请求次数；字段不全就先按真实用量榜的对比思路补齐维度，缺维度后面一定算不准。
2. 拆开把探索性对话、正式改码、跑测试与重试分开统计。通常能一眼看出哪一类在吃预算，这一步比省单价更有用。
3. 套价按你在官方 API 价格页查到的当期单价，对每一类分别乘，再相加。走中转渠道的，先去中转站目录确认它的倍率换算方式，别默认一比一。
4. 复盘把预测值和实际账单并排放，差异超过你能接受的范围，就回到第一步看是哪个字段漏了，而不是急着换模型。固定流程参考一个月一次的账单核对指南。

这张表的价值在于强迫你把每一笔都落到一个格子里。四个格子填完，你才知道钱到底去哪了。填不满，说明你的日志维度不够，先去补齐再谈优化。

把这块成本压下来的几个动作（以及什么时候不适用）

控制喂进去的上下文：只带改动相关的文件片段，别整仓库硬塞。这一步省的是最贵的那部分输入，见效最快，也最容易被忽略。控制轮数：让模型先给方案再动手，别指望它一次写完整个模块，一次成功比三次返工便宜得多。

• 按任务分档：写样板、改注释在便宜档位跑，架构设计和疑难排查再用贵的
• 设预算闸门：给项目配用量告警，跑飞了当天就能发现，具体几道闸看预算告警那篇
• 定期对一遍价：单价和活动会变，用价格变动追踪看趋势，别拿几个月前的印象做预算
• 换模型前先比口径：不同渠道的倍率和起扣规则不同，直接比单价会得出错误结论

按任务分档这条，什么时候不适用？当任务对正确性要求极高、返工代价远大于省下的调用费时，就别为了省钱降档。同理，预算闸门也不是设得越紧越好，设得太紧会频繁打断正常开发，反而制造更多重试。用 价格变动追踪（/price-watch） 定期对一遍价，是因为单价和活动会变，拿几个月前的印象做预算，等于用旧地图找新路。