你点开这篇文章，大概率是刚拿到 Kimi K3 的 API 权限，对着计费页面犯迷糊。别着急，实际跑测的账单细节与常见踩坑点，都整理在了下面。 价目表上的数字，和你实际付的钱不是一回事
官方公开的定价其实很直白，国际站按美元结算，缓存未命中的输入 token 是 3 美元每百万，命中缓存就只要 0.3 美元，输出 token 统一 15 美元每百万。国内开放平台的人民币定价也差不离，输入 20 元每百万 token，缓存命中 2 元，输出 100 元每百万，换算汇率后基本持平。
但你别以为照着单价乘用量就能算出账单。不少开发者第一次调完接口对账时，算出来的数字和实际账单差了快一倍，常会误以为系统扣错了费用。翻了半天才在文档不起眼的位置看到说明 ——K3 自带的深度推理过程，产生的所有推理 token，全都是按输出价格计费的。
说真的，这个设计挺容易踩坑的。
你看着输出只有几百字的回答，背后可能藏着几千字的思考过程。实际测试数据显示，复杂推理、代码调试这类场景里，推理 token 能占到总输出 token 的一半还多，等于你实际为输出付的钱，是表面文字长度的两倍左右。要是你的业务主打逻辑分析、数学求解这类重思考的场景，做预算的时候可得往高了估，别到时候账单出来吓一跳。
1M 的上下文窗口看着唬人，真要一次性塞满输入，其实也没贵得离谱。按缓存未命中算，一百万输入 token 也就 3 美元，折人民币二十出头。但你得想清楚，这么长的上下文喂进去，模型输出加推理的 token 量不会少，这部分才是真正的开销大头。
上下文缓存，是真能帮你省大钱
很多人刚上手的时候根本没注意缓存机制，平白多花好多冤枉钱。
K3 的缓存是自动生效的，不用你额外写代码配置。它按 256token 的块粒度来判断，只要你请求里的前缀内容和之前某次请求重合，重合的部分就按缓存价计费，直接打一折。这个机制对多轮对话、固定系统提示的场景特别友好，几乎是白给的省钱福利。
举个最常见的例子，你做一个带固定人设的客服机器人，系统提示词每次调用都一模一样，那从第二次调用开始，系统提示的部分就全走缓存了。要是用户一直在同一个话题里聊，前面的对话历史也会不断命中缓存，越往后聊，输入成本越低。
长文档问答场景下的感受会格外明显。上传一份几十万字的行业报告，第一次提问的时候整份文档都按原价计费，后面再接着问同一份文档里的内容，文档部分的输入就全走缓存了，输入成本直接降到原来的十分之一。连续问十几个问题，平均下来单轮的输入成本几乎可以忽略不计。
当然也不是所有场景都能吃到缓存红利。你每次请求都传全新的内容，缓存就基本没用，该多少就是多少。所以做业务设计的时候，尽量把固定不变的内容放在请求最前面，别每次都打乱顺序，能省不少钱。
国内站和国际站，该选哪个接入
不少人纠结走国内开放平台还是国际站，其实差别没你想的大。
定价换算下来基本持平，国内站用人民币充值，不用考虑汇率波动，对国内开发者友好很多。最低充值门槛也低，小额充值就能激活使用，适合个人开发者先试水。不过要注意，新用户送的那些代金券，大多不能用来抵扣 K3 的费用，得实际充值后才能调用。
速率限制这块，两边都是和账户累计充值金额挂钩的。充的钱越多，每秒能发的请求、每天能处理的 token 量上限就越高。个人开发者随便用用的话，低档位的限速基本够了；要是做线上业务，就得提前算好峰值流量，该充钱提档位就充，不然高峰期被限流就麻烦了。
企业用户的话，国内站还能走定制合作，有专属的技术支持，也能谈更优惠的阶梯价。用量大的团队直接找商务谈，比按量付费划算不少。国际站也有企业方案，但沟通和付款都麻烦点，根据团队实际情况选就行。
不同场景，你的预算该估多少
光看单价没概念，几个常见场景的实际开销算下来，你心里大概就有谱了。
要是只是个人开发调试，每天调用个几十次，每次几千 token，一个月下来也就几十块钱，一杯奶茶钱都不到。哪怕天天拿来改代码、查资料，正常使用一个月百八十块也足够了，比开会员还灵活划算。
如果是中小团队做内部工具，比如做个文档总结、代码审查的小应用，每天几十万 token 的用量，一个月下来大概几千块。摊到团队每个人头上，比买其他办公软件便宜多了，效率提升还明显。
要是做面向用户的线上产品，就得仔细算了。按每个用户每天产生 1 万 token 算，一千个活跃用户一天就是一千万 token，光输出部分一天就得大几百，一个月下来几万块是跑不了的。这种场景一定要把缓存利用到极致，再做好用户侧的用量限制，不然账单很容易失控。
极端测试场景下，一次性喂进去五十万 token 的行业报告，让模型做完整的梳理和分析，最后输出加推理一共花费不到两美元。折人民币十几块钱，换人工分析师得干大半天，这笔账怎么算都值。
几个没人特意说的控费小技巧
实际使用过程中，总结出几个实用的省钱小细节，大多是踩坑踩出来的经验。
第一件事，调用接口的时候一定要设 max_completion_tokens 的上限。别用默认值，默认值十几万 token，真要是模型放飞自我写起来，一次调用就能花掉十几块。根据你的业务场景设个合理值，比如正常问答设个两千，写长文设一万，足够用了还能防意外。
第二，尽量把重复的内容往前放。缓存是按前缀匹配的，系统提示、固定的规则说明这类不变的内容，统一放在请求最开头，别每次都插在中间或者后面，缓存命中率会高很多。
第三，定期去控制台看账单明细。里面会分开列缓存命中和未命中的 token 量，还有输出 token 的明细。要是发现缓存命中率特别低，就得回去调整下请求结构，别稀里糊涂花冤枉钱。
还有个小提醒，别拿生产密钥随便测脚本。有开发者曾因忘换测试密钥，循环跑了一百次长文档调用，账单直接多了好几十。虽然钱不多，但也够让人肉疼的。
K3 的定价配得上它的能力，摸透缓存和计费规则，成本完全可控。真要上手，先充几十块跑两天测试，心里很快就有数了。
AI 速览
