硅基流动API价格多少

很多开发者第一次接硅基流动，卡在「价格页看得懂字、算不出自己的账」：按什么单位计费、不同模型档位差在哪、充值和结算对不上怎么查。这篇不贴死数字，只讲清计费结构，并给出一条从查价到复盘的动作路径，让你打开站内页面就能自己算出一个月大概花多少。

很多开发者第一次接硅基流动，卡在同一个地方：价格页看得懂字，算不出自己的账。按什么单位计费、不同模型档位差在哪、充值和结算对不上怎么查，这三件事没理清，预算就只能拍脑袋。这篇不贴死数字，只讲清它的计费结构，再给一条从查价到复盘的动作路径。

结论先放这：硅基流动的价格是「按 token、输入输出分开收」的口径，你花多少钱取决于两个变量——你选的模型档位，和你的输入输出配比。打开站内页面把当时的单价抄下来，乘你自己的用量，一个月大概花多少是能自己算出来的。下面逐节说怎么做。

先弄清它按什么单位收钱

硅基流动走的是按 token 计费的路子，输入和输出分开计价。这一点最容易被忽略：很多人看价格页只扫一眼数字，默认输入输出一个价，结果估算出来和实际账单差一大截。输出 token 通常单价更高，而对话类应用输出占比不低，所以别把两者当一个价看。

token

模型处理文本的最小计量单位，中文大致一个字到两个字算一个 token，英文一个词可能拆成多个

输入计价

你发给模型的内容（提示词、上下文、检索回来的资料）按这个口径算钱

输出计价

模型生成给你的内容按这个口径算钱，通常和输入不是一个价

档位

同一平台上不同模型的单价差距很大，档位差异主要来自模型规模和是否开源权重

具体每个模型什么价，别靠记忆，价格会调。先去 /official-api/providers/siliconflow 核对模型清单与计费口径，页面标什么就以什么为准。这一条是所有后续估算的起点，取数取错了，后面全白算。

价格档位是怎么排出来的

硅基流动的档位大致按模型体量排：小参数量模型便宜，大参数量模型贵，多模态（能看图、能听音频）的通常再上一档。你不需要背住哪个模型在哪一档，只要理解「档位 = 模型能力上限」这个对应关系，选型时就不会盲目往高价档冲。

同一模型在不同调用方式下的实际单价也可能不同，比如实时调用和批处理、是否命中缓存。如果你在做成本敏感的项目，这些差异比模型本身的标价更值得关注。判断适不适用：如果你只是做分类、抽取这类轻任务，没必要选高价位档，小模型跑出来的效果往往够用。

• 先按任务复杂度初筛档位，别一上来就全站用最贵的那个模型
• 把「能不能等」作为第二个筛选条件：能等就跑批处理，不能等才走实时
• 注意缓存机制：重复的固定前缀如果命中缓存，实际成本会低于标价
• 选型定下来之后再去核对单价，顺序别反，先看价容易被数字带偏

查价的正确姿势：三个页面配合看

单看一个价格页容易漏信息。建议三个站内页面配合着看：先用 /official-api/providers/siliconflow 看平台当前有哪些模型和计费入口，再到 /models 对照模型规格，确认参数量和上下文长度是否匹配你的任务，最后用 /tools/token-price-calculator 把单价换算成「一次调用多少钱」。

1. 第一步：取平台当前口径打开 /official-api/providers/siliconflow，记下你要用的模型当时的输入、输出单价，以及有没有批处理、缓存的特殊口径。验证方式：同一模型在两个页面上的价格描述是否一致。
2. 第二步：对规格到 /models 确认这个模型的参数量、上下文长度、支持哪些输入类型。验证方式：你的任务需要的上下文长度是否在支持范围内，不够就得换模型，价格跟着变。
3. 第三步：换算成单次成本用 /tools/token-price-calculator 输入你一次调用的平均输入输出 token，得出单次调用成本。验证方式：拿这个数乘你预估的调用次数，看是否落在预算区间。
4. 第四步：交叉验证把算出来的月成本和 /tools/model-cost-calculator 的结构再对一遍，两个工具口径一致才说明你没填错参数。

这三步的价值在于把「单价」翻译成「一次调用多少钱」和「一个月多少钱」。单价是平台口径，后两个才是你自己的账。很多人卡住就是因为停在第一步，没往下换算。

用你自己的用量倒推月成本

估算的准确性取决于你的用量数据，不取决于单价查得多细。先记录一周的日均 token 消耗，输入和输出分开记，再乘 30 天。一周数据比拍脑袋准得多，也能看出工作日和周末的波动。如果你还没上线，就用测试环境的调用日志代替。

# 思路示意，不是可运行命令；实际用你自己的日志字段
日均输入token = 一周输入总量 / 7
日均输出token = 一周输出总量 / 7
月成本 ≈ (日均输入token × 输入单价 + 日均输出token × 输出单价) × 30

按 /tools/model-cost-calculator 的结构填：调用次数 × 单次平均 token × 对应档位单价。这里最容易低估的是冗余——重试、超时重发、长上下文都会让实际值比理论估算高出一截。建议在理论值上留出余量再定预算，别按理论值卡死。

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

压成本不等于换便宜模型，很多时候是调度问题。最有效的一条是按任务分流：短任务交给小模型，复杂任务才走高价位档，而不是全站一个模型跑到底。同一套系统里跑两三个模型是常态，路由逻辑本身不复杂。

• 按任务分流：分类、抽取走小模型，推理、生成走大模型
• 收敛固定前缀：把每次都要重发的系统提示收敛成短且稳定的形式，减少输入 token
• 能等就等：可以延迟的活跑批处理，别用实时价做批处理的活
• 控制上下文：历史对话做裁剪或摘要，不是无限往里塞
• 监控重试：失败重发会直接放大 token 消耗，先把重试率降下来

这些动作的前提是你已经知道钱花在哪一类调用上。如果日志里没记模型名和 token 数，先补日志再做优化，否则优化就是盲调。另外注意不适用的情况：如果平台正在做限时活动或你有赠送额度，按标价算出来的节省比例会失真，这时候看实际账单更有意义。

上线后怎么核对钱花在哪

上线之后，账目核对要从日志开始。把每次调用的模型名、输入输出 token、时间戳记进日志，字段口径参考 /usage。没有这些字段，账单和预估对不上时你只能干瞪眼。记录成本很低，事后补就很麻烦。

1. 核对第一步：看总量把一段时间内的日志 token 总量和平台账单对一下，差距大说明有调用没记录，或在别处也调了模型。
2. 核对第二步：查模型混用按模型名分组统计，看是否存在预期外的模型被调用，尤其是灰度或实验代码忘了关。
3. 核对第三步：查重试放大统计失败率和重发次数，重试是账单超预估最常见的原因之一。
4. 核对第四步：比对充值记录把充值与实际消耗按月对一次，参考每月对账的思路，发现长期漂移就回到估算环节重新取数。

对账频率不用太高，按月做一次就够，但第一次上线后的头两周建议多看几次，把异常早点暴露出来。/price-watch 这类价格追踪页也值得定期扫一眼，平台调价时你未必会收到通知。

什么情况下这套算法不适用

上面这套从取价到估算的流程，建立在「按标价、稳定用量、官方直连」三个前提上。任何一个不成立，算出来的数就只能当参考，不能当预算依据。提前知道边界，比事后解释账单为什么超了更有用。

中转渠道这块要单独说一句：如果你不是官方直连，而是通过中转站接入，计费口径和倍率完全可能不一样，这时候拿官方标价去比没有意义。中转站的费率怎么看、和官方价怎么对照，站内有专门的文章讲，这里不重复。判断标准很简单：你的请求最终打到谁那里，就按谁的账算。

还有一类容易忽略的情况：模型换代。平台上的模型会上下线，新模型的定价逻辑可能和老模型不同，历史单价不再可比。这时候不要拿旧数据套新模型，老老实实去 /official-api/providers/siliconflow 和 /models 重新取一遍数。