硅基流动api价格 kimi-k2.5

很多人接上硅基流动、跑通一次对话之后，就卡在「这一笔到底怎么算的」上：计费是按输入输出分开报，还是合成一个数；余额扣得比预想快，是单价的问题还是用量的问题。这篇不背具体数字，只给你一套看单价的路径、拆用量的顺序和核账的动作，让你每次调价或换模型时都能自己算一遍。

很多人接上硅基流动、跑通一次对话之后，就卡在「这一笔到底怎么算的」上：计费是按输入输出分开报，还是合成一个数；余额扣得比预想快，是单价的问题还是用量的问题。这篇不背具体数字，只给你一套看单价的路径、拆用量的顺序和核账的动作，让你每次调价或换模型时都能自己算一遍。

先说清楚前提：任何写死的单价都可能过期。硅基流动上的模型会上下架、会调价，别人文章里的旧数字更不能信。所以下面的内容都是「去哪看、怎么看、怎么算」，具体数值一律到站内页面核对当时的挂牌。

单价去哪看，别背截图

第一件事是找到权威口径。到 /official-api/providers/siliconflow 看当前挂出来的计费说明，那里才是你下单时真正生效的价。截图、群聊转发、旧文章都只能当参考，不能当依据。

• 先确认计价单位：页面是不是按「每百万 token」报，还是按千 token，单位不同差几个数量级，看错单位后面全错
• 再确认输入价和输出价是不是分开列，只抄一个合并价的话，输入输出比例一变就对不上
• 留意是否区分缓存命中、批处理、不同规格档位，有就一起抄下来，缺一项后面就算不准
• 同一个模型在硅基流动和在模型原厂官方价可能不是一个数，比价前先确认两边是不是同一计价单位、同一口径
• 把抄下来的三项（输入、输出、缓存或规格差异）记在同一个地方，下个周期再抄一次做对比

账单拆成哪几块

一次请求通常拆成输入部分和输出部分，两段单价不同，输出往往更贵，所以「回答越长越费钱」是有依据的。如果调用带了系统提示、检索回来的资料、历史多轮上下文，这些也算输入，会一并进账。

输入 token

你发给模型的内容，包括系统提示、历史对话、检索资料

输出 token

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

请求次数

用于判断是否因重试、超时重发产生了重复计费

预扣与结算

余额减少和实际计费之间可能有时间差，不要拿余额跳动当账单

把用量日志里的输入 token、输出 token、请求次数三项分开记，混在一起就别想核对。具体扣费口径以平台说明为准，遇到不确定的地方先看站内文档再下结论。

从用量倒推花费的核对顺序

对账不要一上来就乘单价，先固定统计口径，再分组乘价，最后和账单比。顺序错了，差异会看起来像「单价涨了」，其实只是区间没对齐。

1. 拉出请求记录确认统计区间和账单周期是不是同一天开始、同一天结束，跨天的数据先切齐
2. 按模型分组同一份数据里混着几个模型时，先分组，再各自乘以对应单价，不要用一个平均价糊弄
3. 分别乘输入与输出输入 token 乘输入价，输出 token 乘输出价，两段相加才是这一组的成本
4. 和账单比对不上就查失败重试、超时重发是否也计了费，这部分最容易制造假差异
5. 记录偏差连续两三个周期都出现同一方向的偏差，才值得去追，单次差异先放着

如果你只想知道「现在大概什么水平」，别背数字，直接到 /price-watch 看当时的价格追踪，那里比任何文章都更贴近实时。

在不换模型的前提下把账压下来

单价你改不了，但用量结构可以改。下面四件事不涉及换模型，任何接口都能做，做完再看账单会直观不少。

• 缩短输入：把固定不变的指令和历史对话做精简，避免每轮都重发一大段
• 控制输出：明确要求回答长度和格式，长段落是最直接的成本来源
• 按任务分层：简单分类、抽取类任务没必要用贵的档位，先看 /models 里有没有更便宜的同类可选
• 批量思路：能离线跑、不要求秒回的活，先确认平台有没有更省的提交方式，再决定值不值得等

这里有个不适用的场景：如果你的任务是长文档理解或复杂推理，强行压输入输出可能让回答质量掉到不可用，这时候省钱不如先把任务拆小、只对必要部分调用。