你可能遇到过这种情况：同一个开源权重，A 平台按 token 报价、B 平台按小时租卡、C 平台按显存规格给价，看着都便宜，真跑起来账单差一大截。这篇不替你下结论说哪家好，而是给一套把三种计价方式拉到同一张表上的换算思路，顺带讲清楚冷启动、排队和吞吐数字该在什么条件下才成立。算的时候拿站内实时页面上的数字填，别用记忆里的旧价。
同一个开源权重，A 平台按 token 报价、B 平台按小时租卡、C 平台按显存规格给价，看着都便宜，真跑起来账单可能差一大截。原因不是谁在骗人，而是三种计价方式默认的前提不一样：按 token 的假设你只付实际算力、按小时的假设你占着资源不放、按显存的假设你自己能把它用满。
这篇不替你下结论说哪家好，只给一套把三种计价拉到同一张表上的换算思路，顺带讲清冷启动、排队和吞吐数字在什么条件下才成立。算的时候拿站内实时页面上的数字填，别用记忆里的旧价，报价变动频率比你想象的高。
三种计费口径，怎么拉到一张表上
按 token 计费最直观，但要确认三件事：输入和输出是不是同一个单价、有没有按上下文长度分档、有没有最低消费或起步量。很多平台的贵不是贵在单价，而是贵在你没注意到的分档规则上，长上下文场景尤其明显。
按小时租卡的核心难点是「每小时能跑多少 token」这个数你估不出来，就没法跟按 token 的比。估的时候别用满载峰值，用你任务的真实负载，包括等待和数据加载的空转时间，空转时间照样计费。
| 口径 | 换算成什么 | 关键前提 |
|---|---|---|
| 按 token | 直接得到单次任务成本 | 确认输入输出单价和分档 |
| 按小时租卡 | 除以每小时有效 token 产出 | 估得出真实吞吐，剔除空转 |
| 按显存 | 本质是按时租卡的变体 | 卡型和显存决定能跑多大、多少并发 |
换算用的单价和规格统一到 开源模型比价（/inference） 与 GPU 租用比价（/compute/gpu-rental） 当天的数字上。两边口径不一样是常态，别拿一家按 token 的价硬套另一家按小时的价，那是两套账。
冷启动和排队，算不算进成本
- 按 token 计费的通常把冷启动藏在感知不到的地方，但你的等待时间是真实存在的，交互式场景要折进去；
- 按时租卡的话，冷启动时间和排队等待是纯亏，模型没加载完、任务没排上，机器照样在计费；
- 判断标准：有人等着看结果的交互式场景对排队敏感，批量离线任务对排队不敏感，可以忍；
- 不适用的情况：如果任务本身就要跑满整段时间、机器不会闲着，排队影响就很小，别为这点差异换平台。
还有个容易漏的隐性成本是重试和失败重跑。按 token 计费时失败请求可能也扣费，按时租卡时失败意味着这段时间白烧。把你的失败率乘进单次任务成本里，比事后对账划算。
吞吐、并发这些指标怎么读才不被误导
看到任何吞吐数字，先问三件事：什么卡、什么量化档位、多长上下文。缺一个这个数字就不能横向比。同一张卡跑不同量化档，产出速度能差出好几倍，拿满载小上下文的数字去估长上下文任务的成本，必然低估。
并发数不等于吞吐。高并发下单位时间产出可能反而不涨，因为显存和带宽被抢。先看你自己的任务需要多少并发，再去看那个并发下的表现，别被峰值数字带走。
- 建基线用固定输入输出长度、固定上下文测一轮，记录当时的时间和卡型，参考 接口测速（/tools/speed-test） 的做法。
- 分时段复测至少在不同时段各测一次，单次测出来的数字波动很大，高峰期和低谷期能差一截。
- 换算成任务时间把每秒产出换算成「一次真实任务要多久」，这个数比抽象的吞吐率有用得多。
落到你自己任务的单位成本
先把一个真实任务的输入输出量估出来，用 模型成本计算器（/tools/model-cost-calculator） 和 Token 单价换算（/tools/token-price-calculator） 各算一遍，两个口径的结果对不上是正常的，对不上说明你有前提没统一。
再按你实际要跑的频次乘出月度用量，拿去和 真实用量榜（/usage） 上的同类任务对照，看自己的量级是否离谱。量级差一个数量级，往往是你假设的并发或失败率有问题。
- 单位成本
- 一次任务从进到出总共花多少钱，包含重试
- 有效吞吐
- 扣掉冷启动、排队、空转之后真正产出的量
- 隐性成本
- 冷启动、排队、重试、失败重跑这四项
显存需求先按 部署测算（/models/deploy） 和 加速卡规格库（/compute/gpus） 确认能不能放下。放不下的方案直接排除，别在价格表里纠结。不适用的情况：如果你对输出质量极度敏感，便宜方案跑出来的结果不能用，单价再低也不省，这时候该看的是质量门槛不是价格。
定方案前的对照清单
- 列出候选的每一条路各自按什么口径报价，写在纸上别记脑子里；
- 统一换算到一个共同单位，比如「一千次任务的成本」；
- 把冷启动、排队、重试、失败重跑这四项隐性成本按你的场景各标一个权重；
- 价格和规格一律到站内实时页面核对当时的数字，别用旧截图；
- 小额实测一轮再决定，这一步别省，纸面换算和真跑总有出入。
| 场景 | 排队敏感度 | 优先看什么 |
|---|---|---|
| 交互式对话 | 高 | 响应延迟和冷启动 |
| 批量离线 | 低 | 单位任务成本 |
| 周期性批处理 | 中 | 按时租卡能不能跑满 |
| 高并发服务 | 高 | 该并发下的真实吞吐 |
如果你的任务对延迟要求高又跑不满整段时间，按 token 计费通常更容易算清账；反过来任务能稳定占满资源、对排队不敏感，按时租卡或按显存可能更划算。判断依据是你的负载曲线，不是平台的宣传口径。
下一步把候选平台当天的报价和规格拉出来，按上面的清单换算成同一个单位再比；站内比价页和测速工具的数字会随行情变，确认时以当时页面为准。→常见问题
同一个开源权重，为什么两家平台价格差好几倍？
大概率不是同一件事：一家可能按 token 计费、另一家在按小时租卡，或者量化档位、上下文长度、并发上限完全不同。先把两边的口径对齐，再谈差价合不合理。对不上口径的差价，看多少遍也看不出结论。具体数字以站内实时页面为准。
按小时租卡是不是一定比按 token 便宜？
不一定。跑得满、任务密集、不需要弹性的时候，租卡常常更划算；但如果你的调用是零散的、时有时无，租卡会有大量空转时间，反而更贵。分界线在于你的卡利用率能不能撑起来，估不准就先按零散调用算一遍再比。
吞吐数字很高，为什么我实际跑起来还是慢？
平台标的吞吐通常是在特定卡型、特定量化档位、较短上下文下测的峰值。你自己的任务如果有长上下文、复杂输入、多轮重试，实际速度会明显低于那个数。看吞吐时先确认测试条件和你自己的场景对不对得上，对不上就别拿它做决策依据。
