用 n8n 监控同款开放模型的 API 价差

同一个开放权重模型，换一家 API 服务商，报价可能相差数倍。作者以 Llama 3.3 70B 为例，标题给出的价格范围是每 100 万 tokens 0.155 至 0.78 美元，并做了一个每 5 分钟检查一次报价的监控工具。

它的价值是帮助开发者看清：为了延迟、上下文长度或精度固定使用某家服务商，究竟多付了多少。不过，这套监控比较的是标价，还不能直接回答哪家最适合生产环境。

同一套权重，为什么还要比较服务商

开放权重模型可以由不同服务商部署，再通过 API 提供给开发者。模型名称相同、权重相同，并不代表服务价格相同，也不代表部署条件完全一致。

作者的监控从 OpenRouter 的公开模型端点数据读取服务商及其每 token 报价，不需要 API key，每 5 分钟刷新一次。这里的端点（endpoint），可以理解为某家服务商提供某个模型的具体 API 入口。

标题中的 Llama 3.3 70B，报价从每 100 万 tokens 0.155 美元到 0.78 美元。但正文没有列出对应服务商、采样时间和详细报价表，也没有明确说明标题价格是否采用下文的混合成本口径。这组数字可以说明作者观察到的价差，不能当作随时有效的采购清单。

把报价变成提醒，需要先统一比较口径

输入和输出通常分别计费，直接比较某一项价格容易误判。作者假设每生成 1 个输出 token，需要 3 个输入 tokens，据此计算每 100 万 tokens 的混合成本。按这个比例，输入占 75%，输出占 25%。

这个处理让报价可以放在一起比较，但也带来了一个前提：实际业务的输入输出比例，得与假设足够接近。长上下文问答和大量生成代码的请求，成本结构可能不同，排名也可能跟着变。

监控接着做了三层处理：

• 排除状态值为负，或近期可用率为 0% 的端点，避免把已经无法调用的低价入口算进去。
• 按模型计算中位数、均值和标准差，把比中位数低至少 15% 的服务商标出来。
• 如果最便宜与最贵的服务商使用不同量化精度，就发出警告，例如 fp4 与 fp16 不适合直接比较。

量化可以理解为用较低精度表示模型参数。它可能降低部署成本，也可能影响输出表现，所以「同一个模型」仍需继续核对精度。

低价提醒只是筛选入口，不是切换服务商的结论。

整套流程跑在 n8n 上，并做了重复过滤：同一服务商与模型组合，6 小时内不会重复提醒，除非价格变动超过 5%。结果发到免费的 Telegram 频道。这个设计减少重复通知，但原文没有交代如何衡量提醒是否有用，也没有给出实际节省费用的案例。

我的判断

作者做对的一点，是没有把最低标价直接包装成最优选择。他明确承认，这些价格没有计入延迟、吞吐量、限流和可靠性，便宜端点还可能有更短的上下文窗口或更低精度，切换前也要检查服务条款。

这套工具最适合已经直签某家服务商，或者手动固定服务商的人。按照作者的说法，OpenRouter 默认路由偏向价格，使用默认设置的人可能已经拿到了较便宜的选择。不过，原文没有提供默认路由与手动选价的对照数据，因此不能据此保证默认路由总能拿到最低价。

我会把固定的 3∶1 比例和低于中位数 15% 的阈值看作实用起点。作者没有给出验证过程，它们目前属于经验设定。尤其是可用率过滤只排除了明显不可用的端点，并没有建立可靠性评分；量化警告也只比较最便宜与最贵的服务商，不能替代逐个端点核查。

此外，这份数据来自 OpenRouter 的端点列表，原文没有证明它覆盖全部服务商，也不包含直签折扣。它更适合发现值得进一步检查的价差。

能拿来做什么

• 如果你的 Node 服务直接调用固定供应商，可以先用真实请求统计输入与输出 tokens 的比例，再按这个比例重算成本，避免套用 3∶1 得到失真的排名。
• 如果你为了延迟、上下文长度或量化精度固定了 OpenRouter 服务商，可以用报价监控估算这项选择的成本，再决定是否值得保留。
• 如果准备迁移 API 供应商，可以先筛出低价候选，再用同一批业务请求检查输出质量、延迟、吞吐量和限流，并核对上下文窗口与服务条款。
• 如果用 n8n 搭建类似监控，可以借鉴 6 小时去重、价格变动超过 5% 才提前重报的规则，再根据实际价格波动调整提醒频率。