Marico's space
最近被问了好几次怎么对比 LLM API 网关的价格，发现很多人都在犯同一个错误——盯着一个数字看，结果选出来的方案反而更贵。这篇把问题说清楚，顺便拿 XiuRouter 当例子，手把手演示该怎么比。
同一模型在不同网关上往往有不同的计费维度：输入、输出、缓存读取、缓存写入各自单价不同。网关还可能通过多条服务组或协议路由暴露同一个模型。把这些维度混在一起比较，"看起来便宜"的方案在实际负载下可能更贵。
对比两个方案之前，先把"在比什么"定义清楚。
一个可用的对比元组应该包含：
model
+ provider 或 source model
+ service group 或 route
+ API 协议
+ input 价格
+ output 价格
+ cache-read 价格
+ cache-write 价格
+ 货币和单位
+ pricing version 或 checked-at 时间上面任何一个字段变了，就可能不再是同一个东西了。
举个例子：
第一条原则很简单：比较一条完整的路由，而不是一个模型名称。
按 token 计费的 API 通常对不同 token 类型收取不同费率。
至少把这些桶分开：
标准化的成本计算公式是：
cost = input_tokens × input_rate
+ output_tokens × output_rate
+ cache_read_tokens × cache_read_rate
+ cache_write_tokens × cache_write_rate所有费率必须使用相同单位，比如每百万 token 的价格。
不要把缓存读取 token 加到未缓存输入里然后收两份钱。不要把输入费率套用到输出 token 上。不要假设缓存写入和缓存读取价格相同。
输入密集型和输出密集型的工作负载可能从同一张价格表里得出完全相反的结论。
来看一个假设的例子：
| 路由 | 输入 / 1M | 输出 / 1M | 缓存读取 / 1M |
|---|---|---|---|
| 路由 A | ¥3.5 | ¥35 | ¥0.35 |
| 路由 B | ¥7 | ¥21 | ¥0.70 |
假设某个负载使用：
加权后的成本：
路由 A = 8 × 3.5 + 2 × 35 + 5 × 0.35 = ¥99.75
路由 B = 8 × 7 + 2 × 21 + 5 × 0.70 = ¥101.5路由 A 的输入价格更低。路由 B 的输出价格更低。单看任何一个数字都看不出最终结论。
这些数字是示意性的，不代表 XiuRouter 或其他提供商的当前价格。用实际费率和你的 token 分布替换进去。
省钱的主张需要有参考来源。
记录这些内容：
如果网关把一个公开模型名映射到另一个 source model，这个映射必须在证据中可见。否则比较可能把两个不同的产品混在一起了。
XiuRouter 的公开定价 API 暴露了 pricing_version 和结构化的 reference_price 字段，包括 input、output、cache_read、cache_write 和 source_model。实时响应可能随着模型和路由变化而变化，所以把版本和对比结果一起存储，不要把单次响应当作永久数据。
价格和路由不是独立的。
网关可以通过多个服务组暴露同一个模型。更便宜的组可能有不同的可用性、权限或上游特性。密钥也可能被限制只能访问部分组或模型。
因此，把选定的服务组纳入估算和验收测试。
不要用最便宜的可见组做计算，然后实际流量走另一个组。
价格不能证明客户工作流能用。
OpenAI Chat Completions、OpenAI Responses、Anthropic Messages 和 Gemini GenerateContent 有不同的请求结构和行为。能跑通一个端点不代表能跑通另一个。
接受更低价格之前，确认这些：
一个失败的请求不会因为 token 费率更低就变经济。
表格只是估算。
用你计划使用的客户端配置跑一个小型的非破坏性任务，然后检查网关的请求或使用记录。
对于 XiuRouter，验证这些：
如果使用记录和估算不符，在扩大流量之前先排查路由。
常见原因包括：
Token 费率不一定是完整的商业成本。
检查对比是否还需要考虑：
不要把这些成本藏在一个无法解释的系数里。
选路由之前，确认这些：
这个方法得出的结论比"网关 A 永远更便宜"更小，但它是一个可以验证的结论。
当前模型和路由价格：XiuRouter 定价页面
机器可读的公开定价响应：XiuRouter API 定价端点
协议和端点边界：XiuRouter API 兼容性文档
价格、模型、服务组、协议支持和参考数据都可能变化。在用于生产决策之前，用线上目录重新跑对比，并用真实请求验证结果。