推理平台怎么选：别看跑分，看官方公开了什么
上周有人拿着一张表来问我选哪家。表上七八家推理平台，横着是”首 token 延迟""吞吐""稳定性评分”，格子里全是漂亮的数字。我问他这些数字哪来的，他说是搜来的，某篇测评。我又问那篇测评写了测试时间、并发数、prompt 长度、区域没有，他翻了半天，没有。
这就是问题所在。推理平台的速度和质量本来就是随模型版本、随机房负载、随你自己的调用形态变动的东西，一个不写测试条件的数字，跟没有是一样的。更麻烦的是，这类数字有很强的传播性——A 抄 B，B 抄 C，最后所有文章都在说同一句”某某最快”，谁也找不到源头。你拿它做选型，等于拿传闻做选型。
所以我换了一个维度：看这家平台的官方文档，究竟主动公开了什么。
为什么”公开了什么”是个有效的选型信号
这不是退而求其次的替代品，它本身就是一个直接的工程信号。
你可以想一下，一个平台如果把逐模型的速率限制表贴出来，意味着什么。意味着你在写代码之前，就能算出这个模型在你的账号层级上一天最多能跑多少请求、多少 token；意味着你能提前设计限流和队列，而不是等线上开始报 429 才回过头来加退避重试；意味着你做容量规划的时候有个确定的分母。
反过来，一个平台不公开限速，你要拿到同样的信息就只能靠试——低并发起步，慢慢加压，观察什么时候开始被拒，把观察结果记下来当成经验值。这个过程要花时间，而且结论会过期，平台调整了策略你不会收到通知。这份成本是真金白银的，只是它不出现在任何对比表里。
价格同理。逐模型的公开定价意味着你在立项阶段就能把成本算出来，能跟业务方谈；不公开，你就只能先接、先跑，等账单出来才知道自己在什么水位上。
错误码清单也是。一份完整的错误码文档意味着你的异常处理分支可以照着写，哪些该重试、哪些重试也没用、哪些要报警，一目了然；没有清单，你就得靠线上真出问题的时候现场猜。
所以”公开度”衡量的其实是你需要自己补多少功课。这个维度的好处在于它可验证——文档里有就是有，没有就是没有，我写下来的每一条你都能自己去官方页面对一遍。
下面这些内容，来自我在 2026-08-07 前后逐页核对的八家平台官方文档。核不到的，我会明写核不到。
接入形态对照：先分清哪些是”改配置”，哪些是”改代码”
这张表是选型时第一个要看的，因为它决定了迁移成本的量级。
| 平台 | 接入范式 | base_url / endpoint | 鉴权环境变量 | 模型 ID 形式 |
|---|---|---|---|---|
| Groq | OpenAI 兼容 | https://api.groq.com/openai/v1 | GROQ_API_KEY | 扁平名，如 llama-3.3-70b-versatile |
| DeepInfra | OpenAI 兼容 | https://api.deepinfra.com/v1/openai | DEEPINFRA_TOKEN | 两段式 deepseek-ai/DeepSeek-V3 |
| Novita AI | OpenAI 兼容 | https://api.novita.ai/openai | 文档写 ${API_KEY} | 两段式 deepseek/deepseek-r1 |
| Cerebras | OpenAI 兼容 | https://api.cerebras.ai/v1 | CEREBRAS_API_KEY | 扁平名 gpt-oss-120b |
| Together AI | OpenAI 兼容 | https://api.together.ai/v1 | TOGETHER_API_KEY | 两段式 MiniMaxAI/MiniMax-M3 |
| Fireworks AI | OpenAI 和 Anthropic 双兼容 | https://api.fireworks.ai/inference/v1 | FIREWORKS_API_KEY | 三段式 accounts/fireworks/models/deepseek-v3p1 |
| Nebius Token Factory | OpenAI 兼容 | https://api.tokenfactory.nebius.com/v1/ | NEBIUS_API_KEY | 两段式带日期 deepseek-ai/DeepSeek-R1-0528 |
前七家共享一个特点：官方文档都明确说了，已经在用 OpenAI 客户端库的，改 base_url、换 key、换模型 ID 这三处就能跑。DeepInfra 的文档把这句话说得最直白——从标准 OpenAI 配置切过来只需要这三处改动，现有客户端库改动极小即可工作。
这张表里有两个坑要单独点出来。Fireworks 的 base_url 比别家多一段 inference，抄的时候少一段，表现是 404 而不是鉴权错误，排查方向很容易跑偏。Nebius 官方写法带末尾斜杠，照抄就好，不要自作主张去掉。模型 ID 命名的差异更容易埋雷，Together 的两段式如果只填后半截，报错看起来像权限问题，我见过有人因此去查 key 权限查了半天——这一类坑我在模型 ID 命名那篇里单独展开过。
Replicate 要单列。 它不是 OpenAI 兼容端点，有自己的 predictions API：
- 社区模型走
https://api.replicate.com/v1/predictions，官方模型走https://api.replicate.com/v1/models/{model}/predictions，Deployments 走https://api.replicate.com/v1/deployments/{deployment}/predictions - 鉴权
Authorization: Bearer $REPLICATE_API_TOKEN - 请求体的关键字段是
version（模型版本 ID）和input（输入参数对象），另有webhook（完成回调 URL）和webhook_events_filter（触发回调的事件类型数组） - 请求头里
Prefer: wait可以启用同步模式并指定等待秒数（如wait=5），Cancel-After设置自动取消超时，格式如1m30s、2h
默认是异步的：提交任务，然后轮询或等回调拿结果。这不是”多改两行”的差别，是调用范式的差别——你的业务代码要按提交-等待-取回的形态组织，超时、重试、结果持久化都是另一套写法。所以在比价格之前，先回答”我要不要一个任务式 API”这个问题，答错了后面全白搭。
公开信息完整度：这才是真正拉开差距的地方
接入形态八家都清晰。往下走一层，差距就出来了。
Groq：目前我核对过的平台里，公开信息最全的一家
我用”最全”这个词是有具体所指的，指的是它公开的信息条目最多，不是指它跑得快或者服务好——那些我没核实，也不打算写。
公开了逐模型的速率限制表。 层级只有 Free Plan 和 Developer Plan 两档，免费层的官方原表长这样：
| 模型 | RPM | RPD | TPM | TPD |
|---|---|---|---|---|
| orpheus-arabic-saudi | 10 | 100 | 1.2K | 3.6K |
| orpheus-v1-english | 10 | 100 | 1.2K | 3.6K |
| llama-3.1-8b-instant | 30 | 14.4K | 6K | 500K |
| llama-3.3-70b-versatile | 30 | 1K | 12K | 100K |
| gpt-oss-120b | 30 | 1K | 8K | 200K |
| gpt-oss-20b | 30 | 1K | 8K | 200K |
| qwen3.6-27b | 30 | 1K | 8K | 200K |
| whisper-large-v3 | 20 | 2K | — | — |
官方另外说明了两件事：速率限制适用于组织级别，不适用于个别用户；先撞到哪个阈值，哪个就生效。
有了这张表，很多事情当场就能算清楚。拿 llama-3.3-70b-versatile 来说，TPM 是 12K、TPD 是 100K，用日限除以分钟限：100000 ÷ 12000 ≈ 8.3，也就是说只要满速跑 8 分多钟，一天的 token 配额就见底了。同理它的 RPM 是 30、RPD 是 1K，按 30 RPM 满打满算不到 34 分钟就把日请求数用完。这两个数摆在一起，结论很明确：免费层是用来验证接口和调通链路的，不是用来承接任何持续流量的。
再看 llama-3.1-8b-instant，TPD 500K 对 TPM 6K，500000 ÷ 6000 ≈ 83 分钟；RPD 14.4K 对 RPM 30，理论上 30×60×24 = 43200，日限 14.4K 明显更紧。所以在这个模型上，先撞到的大概率是日限而不是分钟限。这类判断你只有在平台公开了表格的时候才做得出来，否则就只能等 429。
公开了错误码清单。 成功类有 200 OK 和 206 Partial Content（range 头分段返回）。4xx 一串：400 语法非法、401 缺失或无效凭据、403 权限不足、404、413 请求体过大、422 格式合法但语义错误、424 Failed Dependency（Remote MCP 鉴权问题时出现）、429 请求过多，另有两个自定义码——498 表示 Flex Tier 容量超限，499 表示调用方取消请求。5xx 有 500、502、503（维护或过载）。错误响应体里是一个 error 对象，含 message 描述文本和 type 分类（如 invalid_request_error）。
这份清单的价值在于，你的重试策略可以照着分支写：429 和 5xx 退避重试，400/422 重试一百次也没用要改请求，401/403 直接报警别浪费配额，499 是你自己取消的不用告警。没有这份清单，这些分支就得靠线上事故一条条攒出来。
官方明确 5xx 响应不计费。 这一条对做成本核对的人很实在——账单对不上的时候，你至少知道服务端错误不该出现在账单里。
公开了 OpenAI 兼容的不支持参数清单。 这是我最看重的一条，因为绝大多数平台只说”我们兼容 OpenAI”，不说哪里不兼容。Groq 明确列了：logprobs、logit_bias、top_logprobs 不支持；messages[].name 不支持；N 如果传必须等于 1；temperature 传 0 会被转换成 1e-8；音频格式 vtt、srt 不支持。
temperature: 0 那条尤其值得盯一眼。很多人的代码里为了追求确定性输出会硬编码 0，在这里它会被悄悄改成一个极小值——行为上接近，但不是同一件事，如果你的测试用例依赖严格复现，这就是个隐性差异。这类兼容性缺口怎么在迁移时系统性地扫出来，我在OpenAI 兼容迁移那篇里写过一套验收方法。
DeepInfra：公开了逐模型三档价
按每 100 万 token 计价，区分输入、缓存输入、输出三档（$ / 1M tokens）：
| 模型 | 输入 | 缓存输入 | 输出 |
|---|---|---|---|
| DeepSeek-V4-Pro | $1.30 | $0.10 | $2.60 |
| DeepSeek-V4-Flash | $0.09 | $0.018 | $0.18 |
| DeepSeek-V3.2 | $0.26 | $0.13 | $0.38 |
| DeepSeek-V3.1-Terminus | $0.27 | $0.13 | $0.95 |
| DeepSeek-V3.1 | $0.25 | $0.13 | $0.95 |
三档价里最有信息量的是中间那列。V4-Pro 的缓存输入 $0.10 对普通输入 $1.30，差了大约一个数量级；V4-Flash 是 $0.018 对 $0.09，同样是明显的折扣。如果你的业务里有大段固定前缀——系统提示词、few-shot 示例、检索出来的固定文档——把它们稳定地放在 prompt 开头，让缓存命中，省下来的是实打实的钱。这个优化只有在平台公开了缓存档价格的时候你才做得出账，否则你连”值不值得为此改 prompt 结构”都判断不了。
做个算术演示，按上表标价：跑 100 万输入 token、20 万输出 token 的 V4-Flash，成本是 0.09 + 0.18 × 0.2 = $0.126。如果其中 80 万输入能走缓存，就变成 0.09 × 0.2 + 0.018 × 0.8 + 0.036 = 0.018 + 0.0144 + 0.036 = $0.0684，差不多砍掉一半。这只是按官方标价做的算术演示，你自己的实际账单取决于缓存命中率，别拿它当承诺。
Novita AI：公开了逐模型两档价，模型 ID 带版本快照
按每百万 token（/Mt）：
| 模型 | 输入 | 输出 |
|---|---|---|
| Deepseek V4 Flash 0731 | $0.14 /Mt | $0.28 /Mt |
| Deepseek V4 Flash | $0.14 /Mt | $0.28 /Mt |
| Deepseek V4 Pro | $1.6 /Mt | $3.2 /Mt |
| Deepseek V3.2 | $0.269 /Mt | $0.4 /Mt |
| DeepSeek-OCR 2 | $0.03 /Mt | $0.03 /Mt |
注意第一行那个 0731 后缀，这是带日期快照的模型条目。带版本快照的好处是可复现——你锁定一个快照，模型行为不会在你不知情的时候变；代价是你要自己负责跟进版本，快照不会永远在。这个取舍在 Nebius 的 deepseek-ai/DeepSeek-R1-0528 上也是一样的。
Novita 的定价页上同时列了 GPU 价格，说明它既卖模型 API 也卖 GPU；具体型号和价格我没有逐项核实，这里不写，以官方定价页为准。
就 DeepSeek V4 Pro、V4 Flash、V3.2 这三个模型口径而言，DeepInfra 的挂牌价低于 Novita。这个结论只在这三个口径上成立，不能推广成”DeepInfra 全线更便宜”，也不涉及任何性能或质量差异——那些我没核实。三家更细的横向拆解在Groq、DeepInfra、Novita 怎么选里。
Replicate：公开了 GPU 按秒价与模型 token 价，异步 API 细节完整
GPU 按秒计费：
| GPU | 标识 | 价格 |
|---|---|---|
| Nvidia A100 (80GB) | gpu-a100-large | $0.001400/sec |
| 2x Nvidia A100 (80GB) | gpu-a100-large-2x | $0.002800/sec |
| Nvidia H100 | gpu-h100 | $0.001525/sec |
| Nvidia L40S | gpu-l40s | $0.000975/sec |
按秒价换算成小时价（本文按官方标价做的算术，不是官方原文表述）：A100 是 0.0014 × 3600 = $5.04/小时，双卡 A100 是 $10.08/小时，H100 是 0.001525 × 3600 = $5.49/小时，L40S 是 0.000975 × 3600 = $3.51/小时。换成小时之后你才好跟自建的账放在一起比，自建还是买 API那篇算过这笔账的框架。
语言模型按 token 计费的部分有个细节要留神——官方页面上输入按「每百万」标价、输出按「每千」标价，单位不统一：
| 模型 | 输入 | 输出 |
|---|---|---|
anthropic/claude-3.7-sonnet | $3.00 / million input tokens | $0.015 / thousand output tokens |
deepseek-ai/deepseek-r1 | $3.75 / million input tokens | $0.01 / thousand output tokens |
换算是可以做的：$0.015/千 = $15/百万，$0.01/千 = $10/百万（同样是本文按官方标价换算）。我特意把这一条写出来，是因为混单位是成本估算里最常见的翻车点之一——差一个千倍，季度预算就报废了。你自己做表的时候，第一件事是把所有平台的价格统一到同一个单位再比，别在 Excel 里混着放。
按秒计费加异步 API 的组合，指向的是很明确的一类场景：跑图、跑批、跑长任务。你为实际占用的 GPU 秒数付费，任务提交完就可以去干别的，靠 webhook 收结果。这跟聊天补全那种要求低延迟、要求流式输出的场景是两个方向。
Cerebras / Together AI / Fireworks AI / Nebius：接入层清晰，其余是空白
这四家我核实到的是接入层的事实——base_url、鉴权方式、OpenAI 兼容性、模型 ID 形式，也就是上面那张对照表里的内容。Cerebras 的官方快速开始提供 Python、Node.js、cURL 三种示例；Together 提供官方 Python / TypeScript SDK 与 REST 三种调用方式；Fireworks 的部署形态有 Serverless 和 Dedicated GPU 等，功能上支持流式、函数调用、结构化输出、推理。
Fireworks 有一条别家没有的：它同时提供 OpenAI 兼容端点和 Anthropic SDK 兼容端点。如果你手上有一堆按 Anthropic SDK 写的存量代码，这条意味着你有一条低成本的迁移路径，不用把调用层重写一遍。这是个结构性的差异，不是营销话术。
Nebius 还有个可观察到的现象：docs.nebius.com/studio/... 会 307 跳转到 docs.tokenfactory.nebius.com，说明这条产品线做过更名或迁移。我只陈述这个现象，不推测原因和时间。对你的实际影响是：写文档、存书签、往内部 wiki 里贴链接的时候，用跳转后的域名，别用旧的。
我没能核实到的，也一并写清楚
这一节不是免责声明，它本身就是选型信息。一个平台把价格藏起来，就是你要多做的一份功课。
- Groq 的逐模型 token 单价：官方定价页当前抓不到价格数字，以 Groq 官方定价页为准。能确认的只有计费形态：按 token 计费、Free 与 Developer 两层、5xx 不计费、存在 Flex Tier（这一点是从 498 错误码的定义反推出来的）。
- Groq 的免费层是否有赠送额度、有效期：没核实到。
- DeepInfra 的速率限制与并发上限：官方文档对应页面返回 404，一个数都给不了。是否有免费额度、注册赠送，同样没核实到。
- Novita 的免费额度、优惠券、RPM/TPM：没核实到。它定价页上的 GPU 型号与价格我也没逐项核实。
- Replicate 的免费额度、速率限制、冷启动时间、实际延迟：没核实到。冷启动这一项我特别想强调——按秒计费的模式下冷启动是直接影响账单的，但我没有可引用的数字，所以不给。你要自己在真实负载上测。
- Cerebras / Together / Fireworks / Nebius 四家的价格、免费额度、速率限制、完整模型清单：都没核实到。Nebius 的定价页返回 404。
把缺口摊开看，规律很清楚：限速这一项，八家里只有 Groq 公开；价格这一项，公开的是 DeepInfra、Novita、Replicate 三家。 剩下的你都得自己去控制台看，或者去问销售。这不是说那些平台不好，是说你在做预算和容量规划的时候，得为它们额外留出”打听清楚”的时间。
没有限速数据怎么稳妥起步，方法其实是固定的：低并发开局，一个方向慢慢加压，把 429 出现的临界点记下来；请求侧先把指数退避加上，别等出问题再补；用小批量真实流量先跑出自己的单位成本，再按这个成本去推月度预算。这套做法即使平台公开了限速也该做，因为公开的数字是账号层级的上限，不等于你在具体时段拿得到的实际容量。
按需求分支的决策路径
我不给总排名，排名这东西一定是错的——它假设所有人的约束一样。下面按约束分支，你对号入座。
要成本可算、要在立项阶段就能给业务方一个数：往有公开定价的那三家里选。DeepInfra 的三档价加缓存档最适合做精细测算；Novita 的两档价简单直接；Replicate 是按秒或按 token 的双口径。剩下几家不是不能用，是你得先花时间把价格问清楚，别在没有数字的时候硬编预算。
要容量可预测、业务有明确的峰值形状：Groq 是唯一一家把逐模型限速表贴出来的。哪怕你最后不用它，这张表也值得看一眼——它能校准你对”免费层能干什么”的预期。其他家你就得按上面说的低并发试探法自己摸。
要迁移成本尽可能低：先看模型 ID 形式跟你现有配置的距离。你的配置文件里如果已经是两段式的组织/模型名，切到 DeepInfra、Novita、Together、Nebius 基本是改字符串；如果是扁平名，Groq 和 Cerebras 更顺手；Fireworks 的三段式最长，配置项和校验逻辑都要动一动。别小看这个，模型 ID 是最容易在灰度期间填错、而且报错信息还会误导你的地方。
要跑长任务、跑图、跑批：Replicate 的任务式 API 加按秒计费是为这类场景设计的。同步聊天场景硬套过去会很别扭。
手上有 Anthropic SDK 的存量代码：Fireworks 的双兼容端点是这批里唯一的现成路径。
以后可能自建、想先摸清 GPU 的账：Replicate 有公开的 GPU 按秒价，Novita 也卖 GPU（具体价格以官方定价页为准）。用公开的按秒价换算成小时价，跟自建方案摆在一起比，比拍脑袋靠谱。
要做多家回退、不想被单点绑死：那你关注的重点会从”选谁”变成”怎么把多家收敛到一层”，多上游网关那篇讲的就是这个。
多接一家的成本，得先算清楚
“多接一家做回退”这句话说起来轻，落到工程上有个固定的成本。
配置层面是三处：base_url、鉴权 key、模型 ID 映射。听着简单，但模型 ID 映射这一处经常被低估——你原来那套 gpt-oss-120b 到了两段式平台叫什么、三段式平台叫什么，得有一张真实维护的映射表，还得有人在模型上下线时更新它。
验收层面是一整轮：参数兼容性要过一遍（还记得 Groq 那份不支持参数清单吗，别家有没有类似的缺口你得自己扫）、流式输出的分块格式要对、函数调用和结构化输出的行为要对、错误码语义要对、超时和重试策略要按新平台的特性重调。这一轮做完才叫”接上了”，只跑通一个 hello world 不算。
然后是持续成本：两家的模型版本各自演进，你的映射表要跟着走；两家的账单要分别对；出问题的时候排查路径多了一条分支。
所以判断标准是明确的——只有当”单家挂掉给你造成的损失”明显大于上面这些成本时，多接一家才值得做。 一个内部工具，挂了等半小时也没事，那就别接第二家，把精力放在把一家用好上。一个直接影响收入的线上功能，那第二家就是保险，该接。介于中间的，先把第二家的接入代码写好、验收过、放在配置开关后面不启用，也是个折中办法。
一条务实的路线
如果你现在什么都还没接，我建议这么走：
先接一家把业务跑通。 选哪家？按上面的分支挑最贴合你主约束的那个。这一步的目标不是选对，是先有一个能产出真实调用数据的环境——你现在手上的所有估算都是纸面的。
用真实负载测出自己的单位成本。 不是看别人的对比表，是看你自己的：一次典型请求平均消耗多少输入 token、多少输出 token、缓存命中率多少、失败重试占多少比例。有了这四个数，你才能把任意一家的挂牌价代进去算出月度账单。在这之前谈”哪家便宜”都是空的，因为便宜与否取决于你的输入输出比——输出重的业务和输入重的业务，最优解可能完全不同。
再按分支决定第二家接谁。 这时候你已经知道自己的瓶颈是成本、是容量、还是可用性，选择会比一开始清楚得多。而且你手上有了真实数据，可以拿同一批请求去新平台跑一遍做对照，那才是有出处的对比数字——你自己测的，条件你自己知道。
这条路线唯一的要求是别在第一步上纠结太久。选型表做得再漂亮，也没有一周真实流量的数据有用。
自查清单
- 你手上那张对比表里的性能数字，能翻到测试时间、并发数、prompt 长度和区域吗？翻不到就划掉。
- 候选平台里，哪几家公开了逐模型价格？哪几家公开了限速？把”没公开”的格子留白，别用估算填。
- 所有价格是否已经统一到同一个单位再比？特别留意输入按百万、输出按千标价的混单位情况。
- 你的主约束到底是成本可算、容量可预测、迁移成本低，还是跑长任务？只有一个第一优先级，写下来。
- 你的模型 ID 配置是扁平名、两段式还是三段式？这决定了往哪几家切最省事。
- 有 Anthropic SDK 存量代码吗？有的话双兼容端点这条路径要评估。
- 打算多接一家的话，三处配置改动加一轮完整验收的成本估过了吗？收益大于它吗？
- 在没有官方限速数据的平台上，你的低并发起步方案、退避重试和 429 监控都就位了吗？