推理平台比价怎么比：吞吐、限流与冷启动三项对照

你打开几个推理平台的报价页，看到同一个开源权重的每百万 token 单价不一样，挑最便宜的接上去，跑了两天发现排队、被限流、冷启动等半分钟，成本反而更高。这篇不讲哪家好，只讲怎么比：三个可量化的维度、各自的测法，以及什么情况下某一项可以忽略。

你打开几个推理平台的报价页，看到同一个开源权重的每百万 token 单价不一样，挑最便宜的接上去，跑了两天发现排队、被限流、冷启动等半分钟，账单反而更高。这篇不讲哪家好，只讲怎么比：三个可量化的维度、各自的测法，以及什么情况下某一项可以忽略。

核心思路是先确认规格对齐，再按自己的请求形状实测，最后把三项和价格放进同一张表里加权看。三项分别是吞吐、限流、冷启动，缺一项都可能得出反向结论。

为什么不能只看每百万 token 标价

同一个权重在不同平台上的单价差异，常常不是同一件事在比价。量化档位不同、上下文长度怎么分档、缓存命中算不算折扣，这些口径先对齐再谈价格。你可以先到 /inference 和 /models 核对两边的规格描述是否指同一个东西，再动手比较。

标价

每单位用量的单价，只是个乘法因子

账单

标价乘以实际用量，排队重试和冷启动空转都算进用量

规格对齐

量化档位、上下文分档、缓存口径三项先确认一致

吞吐：测你自己的请求形状，不测平台宣传值

1. 量一条延迟基线到 /tools/speed-test 打一次基础延迟，作为后续对比的参照点，换机器或换时段要重测。
2. 用真实 prompt 压一轮长上下文和长输出各准备一组，记录首 token 时间和每秒输出 token 数，别用玩具样例。
3. 拉高并发再压一轮并发上去后如果单请求明显变慢，说明算力在共享，你的实际耗时和账单时间都会拉长。
4. 记成三列并发档位、首 token 时间、输出速度，后面和价格放一起看才能得出结论。

• 固定变量：同一模型、同一参数、同一网络位置，缺一项数据就不能放一起比
• 区分单请求吞吐和并发吞吐，两者结论可能完全相反
• 宣传值通常取最优条件，你自己测的值才对应真实账单
• 压测时留意报错类型，被限流误当成性能差是最常见的误判

限流：看口径，更要看触发后的行为

限流的维度决定它对你有多大影响。按请求数限和按 token 数限，对长短请求混合的业务是两种命运；按并发数限则和你的峰值形状直接相关。问清楚维度比问清楚阈值更有用。

触发后的行为同样重要。直接报错最好排查，静默排队会让延迟悄悄变大，降级到更小模型则最麻烦：回答质量掉了，账单照走。你可以到 /sites 和 /official-api 分别看中转站与官方直连的限制说明，中转站的上游限制往往不写在明面上，只能小额实测。

冷启动：serverless 平台最容易被忽略的一项

冷启动包含模型加载、显存分配、首次编译等环节，和请求间隔直接相关：间隔越长越容易冷。测法是记录首次请求和间隔一段时间后的首次请求耗时差，而不是测平均值，平均值会把冷启动完全抹平。

• 面向人的交互场景冷启动很致命，用户能直接感觉到
• 离线批量任务几乎可以不管，首次慢一点整体无感
• 持续有流量的调用只在扩容瞬间遇到冷启动
• 控制手段：定时保活、长任务合并成批、或选常驻实例方案
• 常驻实例的计价方式和按量不同，要单独比一次

把三项和价格放一张表里

一行一个平台，列固定下来，数字一律以自己实测为准。给每列一个权重：交互类任务给延迟和限流高权重，离线任务给单价和吞吐高权重，权重不同结论可能反过来。

定好观察周期，用 /price-watch 跟价格变动，用 /usage 对一下自己的真实用量，别拿几个月前的印象做决策。迁移前先想清楚退出成本：换平台要改的 base url、参数、缓存策略，这些工作量也要算进总账，否则省下的单价可能还不够填迁移的坑。