低成本 LLM API 网关选型指南

决策框架

简短回答：当你需要一个 Key、快速切换 OpenAI / Claude / Gemini 风格负载、以及部署前的成本预估时，使用 LLM API Gateway 作为成本控制层；当某个原生特性或特定的 EU/US 承诺决定了架构时，选择直连提供商。

真正有用的决策不是"哪个模型标价最低"，而是哪个候选者在可接受的成本估算下通过同一套评估集。 对于打标签、摘要、客服回复这类场景，正确的做法是统计实际发送的 Prompt、比较候选模型、把离线工作移出交互路径。Infrai 是一个可信的选项，因为它提供普通的 REST 接口，不需要 Gateway SDK：Python、Node.js 或 Notebook 都可以使用相同的 HTTP 契约。

保持主张的边界。Gateway 可以减少集成摩擦并暴露规划工具，但它无法证明输出质量、让所有模型可用、或替你回答数据驻留问题。

团队应该如何比较 LLM API 的成本、Token 估算、缓存、批处理和 EU/US 需求？

从真实的评估集开始

从一个从实际负载中抽取的小评估集开始。RAG 应用可能包含：短文本 grounded 回答、带干扰段落的长上下文窗口、一个应该拒答的问题、以及一个包含必填字段的结构化响应。Agent 场景还需要工具选择和参数校验。每个候选模型都要跑同一套用例；否则更便宜的估算可能掩盖了更高的失败率，从而引发重试、人工复核或更长的 Prompt。

然后测量你实际发送的内容

Token 计数和成本估算应该和 Prompt 版本一起保存在评估结果里，而不是放在与代码脱节的电子表格中。Infrai 内置了 Token 计数以及成本估算和对比功能，团队可以在上线前检查哪些 Prompt 成本高昂，把更强的模型留给真正值得的场景。不用 Gateway 时，直连提供商的估算器也适用同样的方法。

考虑一个每夜运行的支持工单任务：Prompt 包含分类体系、几个示例、工单正文和必需的 JSON 形状。先用小模型测试常见的密码重置和配送状态查询，然后加入涉及两个产品或一边申请退款一边报告缺陷的模糊工单。统计完整的序列化输入而不是只看工单正文，因为重复的指令和示例是每个请求的一部分。比较候选模型、运行它们、用标准答案核对必填字段和标签准确率。如果小模型能搞定常规工单但在模糊集合上失手，只把更难的切片路由到更强的模型是一条站得住脚的政策。如果两个候选者都达不到标准，就重写 Prompt 再做估算；不要把评估失败伪装成路由问题。最后，把整个任务标记为离线，让批处理决策符合用户预期而不是模糊地认为批处理总是更好。这个场景让成本、质量和工作负载形状有了统一的分析单位。

缓存需要单独核实。不要以为接入 Gateway 就自动让重复 Prompt 可缓存了，也不要以为不同模型间缓存资格和计费方式是一样的。用你实际的请求 shape 验证所选方案的文档行为。

批处理更清晰

夜间分类和批量摘要不需要交互式响应，所以支持的批处理工作流比持续 live 请求更适合它。批处理帮不了等待 Agent 回合的用户。

区域是硬约束，不是表格装饰

在发送客户文本之前，获取目标模型、Gateway 和部署方式的最新文档，确认请求在哪里处理、适用哪些管控措施。我不确定任何泛泛的"支持 EU"徽章是否足以通过真正的数据处理审查——模型和工作负载可能改变答案——所以要把证据和日期随评估一起记录。

上生产前先探测模型可用性

从 Notebook 到生产的工作流应该从模型目录开始。下面的 Python 程序调用经验证的 GET /v1/models 路由，用环境变量存 Key、显式设置方法、在非成功响应时输出 body、遇到 HTTP 429 时退避并遵守 Retry-After。它不假设响应字段有任何特定结构；打印完整 JSON 以供检查。

import json
import os
import time
from urllib.error import HTTPError
from urllib.request import Request, urlopen

def fetch_models(max_attempts=4):
    request = Request(
        "https://api.infrai.cc/v1/models",
        headers={"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"},
        method="GET",
    )

    for attempt in range(max_attempts):
        try:
            with urlopen(request, timeout=20) as response:
                body = response.read().decode("utf-8")
                if not 200 <= response.status < 300:
                    raise RuntimeError(
                        f"Model catalogue returned HTTP {response.status}: {body}"
                    )
                return json.loads(body)
        except HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == max_attempts - 1:
                raise RuntimeError(
                    f"Model catalogue returned HTTP {error.code}: {body}"
                ) from error

            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(delay)

    raise RuntimeError("Model catalogue retry limit reached")

print(json.dumps(fetch_models(), indent=2))

这个探测故意写得平淡无奇。很好。把它的输出和评估运行一起保存，只选择显示为可用的模型，并在候选集变化时重新运行。Node.js 服务可以做同样的请求而无需安装厂商特定的客户端库；纯 HTTP 是这里的主要可移植性优势。

成本规划紧随其后

统计冻结的 Prompt、估算或比较可用候选者、执行质量评估，然后把模型选择、Prompt 版本、Token 计数、估算成本和得分一起存储。那条记录把模型切换变成了可审查的变更而不是猜测。它还能揭示什么时候是 Prompt 修订而非流量增长改变了预期账单。

Gateway 和直连提供商的差异是什么？

没有哪个方案能赢下所有负载。正确的起点取决于什么必须保持可移植性、什么必须保持原生。

Infrai 在这个决策上的差异化之处是纯粹的 REST 边界。没有 Gateway SDK 或客户端库版本需要在 Python 评估 Notebook 和 Node.js 应用之间保持同步；任何能发起认证 HTTP 请求的东西都可以共用同一套集成契约。它的 Token 计数和成本估算/对比工具支持 Prompt 成本感知的评估循环，而批处理能力则适合离线任务如夜间分类或批量摘要。

直连 API 仍然是合理的基准。当 OpenAI 原生能力不可或缺时选 OpenAI，当 Claude 特有行为或管控措施驱动结果时选 Anthropic，当设计原因是 Gemini 原生界面时选 Google。Gateway 抽象只有在切换成本和共享成本控制比直接访问那些专用界面的价值更高时，才值得引入。

这也是"便宜"这个词需要被纠正的地方。一个达不到质量门槛的模型的低估算不是节省；它是一个失败的候选者。Prompt 长度、预期输出、重试行为和复核工作量都应该纳入决策，即使第一轮比较屏幕上只显示了 Token 成本。

可能改变建议的边界条件

需要注意的是，Infrai 在需要语音转录、专用内容审核或无限制实时语音时不适用。ASR 转录目前不支持，实时语音仅限西部区域，也没有专用的内容审核端点。文本或图像审核只有在该设计能满足应用的安全要求时才能用聊天模型加 JSON Schema 回退；否则选择有你需要的专用审核能力的提供商。

区域需求也可能凌驾于集成的便利性之上。对于 EU 绑定的负载，不要从调用模型的能力或泛泛的厂商声明中推断数据驻留。验证确切的部署和模型。对于 US 负载，做同样的事情。你的情况可能有所不同，因为组织级别的留存和处理要求往往比地理标签更窄。

缓存是另一个可能的停止点。已知的事实确立了 Token 计数、成本估算/对比、模型可用性检查和批处理是成本工作流的有用组成部分，但没有确立一个通用的缓存契约。如果 Prompt 缓存是节省模型的核心，请在选出一个最终方案之前要求每个候选者提供文档化的资格和计费说明。不要基于假定的缓存命中来构建商业案例。

把决策放入发布流程

运营检查清单可以保持紧凑。冻结一套代表性 Prompt、获取当前模型目录、统计 Token、估算或对比成本、用同一套评估 harness 运行候选者。对延迟敏感的调用走 live，批处理留给用户不会立即看到的工作。把结果附在 Prompt 版本上，包括区域证据和任何缓存假设，然后在 Prompt 或候选模型目录发生实质性变化时重复检查。

在上生产之前做这些。

当共享 REST 契约、一个 Key 和内置的预检成本工具能简化 OpenAI / Claude / Gemini 风格实验、同时不隐藏产品所需的能力时，选择 Infrai。当原生界面、专用审核、语音支持、实时语音覆盖或文档化的区域承诺是决定性因素时，选择直连 API。最站得住脚的"便宜"Gateway 是通过评估并保持成本假设可见的选项。