现状
这类代理通常做什么
持有提供商密钥,为每个团队签发内部密钥,重试和故障转移,记录请求,根据手工维护的价格表为 token 计价,并拒绝超出配额的团队。
维护它们的成本
总得有人负责价格表、新模型、每家提供商的新参数、日志背后的数据库,以及代理本身的值班。
两种迁移方式
替换它:服务调用 INFRO,由 INFRO 调用你的提供商。或者暂时把它保留在 INFRO 后面:把代理作为 openai-compatible 连接接入,然后逐个迁移它的上游。
你自己写的代理完全满足你的需要,这本身是有价值的。如果它存在的原因是以下之一,就保留它。
- 它会修改请求:提示词模板化、向上下文注入检索内容、用你自己的模型进行 PII 脱敏,或对响应进行后处理。INFRO 的护栏是模式规则和决策模型检查;它不会在请求路径中运行你的代码。
- 它必须运行在你的网络内或指定区域内。INFRO 的套餐托管在 Cloudflare 的网络上;自托管或混合部署通过企业协议提供。
- 它提供的是任何提供商 API 都不提供的模型,比如你在内部 GPU 上托管的权重,除此之外别无其他。INFRO 可以把该服务器作为
openai-compatible连接进行路由,但服务器仍归你所有。 - 它很小,有人负责,也没人要求预算、归因或故障转移。那么网关就是一次没有收获的迁移。
需要的修改,每项一行。未在此列出的内容都保持不变。
| 你的代理 | INFRO | |
|---|---|---|
| 基础 URL | 你的代理的内部主机。 | https://api.infro.io/v1(OpenAI 格式)、/v1/messages(Anthropic 格式)、/v1/responses(OpenAI Responses)。 |
| 密钥 | 由你的代理为每个团队或服务签发的内部密钥。 | 每个服务一个 INFRO 网关密钥,各自带有模型允许列表、提供商列表、IP 范围、环境和支出限额。 |
| 模型 ID | 你的代理定义的任何别名。 | vendor/model,或路由规则名称:路由规则是一个别名,解析为你连接的有序列表,在控制台中编辑。 |
| 请求头 | 你自己的团队、用户或功能请求头。 | X-INFRO-Feature、X-INFRO-User-Id、X-INFRO-Trace-Id,或请求体中的 metadata.user_id、metadata.session_id、metadata.tags。 |
之前 · 你的代理
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://llm-proxy.internal.example.com/v1",
apiKey: process.env.LLM_PROXY_KEY,
defaultHeaders: { "X-Team": "search" },
});
await client.chat.completions.create({
model: "default-chat",
messages: [{ role: "user", content: "Hello" }],
});之后 · INFRO
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://api.infro.io/v1",
apiKey: process.env.INFRO_API_KEY, // one key per service
defaultHeaders: { "X-INFRO-Feature": "search" },
});
await client.chat.completions.create({
model: "default-chat", // a route with the same name
messages: [{ role: "user", content: "Hello" }],
});保留你的别名
为代理定义的每个别名创建一条同名路由规则,服务就能继续发送同样的 model。密钥可以固定到指定的路由规则,从而无法直接调用模型。
一次迁移一个服务
把代理本身作为一个 openai-compatible 连接接入,并添加为路由目标。服务可以先切换到 INFRO;之后再把上游从代理迁移到直连。
团队变为项目
每个团队的配额变为项目预算和每个密钥的支出限额。成员可以被限定在他们负责的项目中。
你当前设置的功能与 INFRO 的对照,并已按网关实际实现的内容核对。 有一行显示 INFRO 没有对应项。
| 你的代理 | 它在那里的作用 | 在 INFRO 中 |
|---|---|---|
| 密钥保管库形式相同 | 提供商密钥存放在代理的配置或密钥存储中。 | 提供商连接,静态加密封存,每个提供商可有多个密钥,备用密钥排在最后。 |
| 内部密钥形式相同 | 代理为每个团队或服务签发的密钥。 | 网关密钥,带有模型允许列表、提供商列表、IP 范围、环境、支出限额、轮换和停用开关。 |
| 重试和回退形式相同 | 代理中的代码。 | 按优先级或权重分配目标的路由规则,针对请求的条件规则,以及按故障类型的规则(429、5xx、超时、连接、凭据、内容审核)。 |
| 配额形式相同 | 每个团队的 token 或美元计数器。 | 按组织、项目、成员、密钥和终端客户设置的预算,在达到上限时以 402 拒绝,并发情况下同样有效。 |
| 价格表不同 | 一张手工维护的按 token 计价表。 | 来自 INFRO 目录的厂商公开价、你录入的协商价,两者都未知时为 unpriced,绝不为零。 |
| 请求日志不同 | 你自己数据库中的记录。 | 控制台中的请求日志和追踪记录、GET /v1/requests、导出,以及发送到你的 OpenTelemetry 采集器的 span。提示词采集在你开启之前一直关闭。 |
| 提示词和响应转换无对应 | 使用你自己的逻辑进行模板化、检索和脱敏。 | 不提供。护栏按模式和决策模型检查进行拦截、遮盖或标记;INFRO 不运行你的代码。 |
| 自托管模型不同 | 代理后面的 vLLM、TGI 或 Ollama。 | 一个指向该服务器的 openai-compatible 连接,像其他提供商一样路由。服务器仍由你自己运行。 |
| 自行运行不同 | 它运行在你部署它的地方。 | 托管服务。自托管或混合部署通过企业协议提供,而不是一个套餐。Enterprise — 通过企业协议提供,而非自助开通。 |
INFRO 不做的事
- 在请求路径中运行你自己的代码:提示词模板化、检索、自定义转换。
- Batch、Files、微调和 Realtime,或在 OpenAI、Azure OpenAI、Mistral 或 OpenAI 兼容端点之外的提供商上使用嵌入。
- 区域固定;数据驻留在路线图上,目前不提供。
- 没有企业协议的自托管部署。
哪些无法迁移过来
- 你的代理的日志。没有导入工具;把它们留在原处即可。
- 它的价格表。改为在控制台中录入协商价;公开价来自目录。
- 自定义转换。它们保留在你的代码中,在调用 INFRO 之前执行。
问题
- INFRO 能放在我们现有的代理前面吗?
- 能。把代理作为
openai-compatible连接接入,填入它的基础 URL 和密钥,在迁移其上游期间像任何提供商一样路由到它。 - 我们的提供商合同会改变吗?
- 不会。你连接自己持有的提供商账号,你的提供商继续按你自己的价格直接向你收费。INFRO 是订阅制,对模型支出加价 0%。
- 哪些仍由我们的代码负责?
- 任何会修改提示词或响应的操作:模板化、检索、自定义脱敏、后处理。
来源
本页中关于 SDK 行为的内容来自以下来源,阅读于 2026年10月19日。
- OpenAI — openai-node README (baseURL and defaultHeaders)阅读于 2026年10月19日
- OpenAI — openai-python README (base_url and default_headers)阅读于 2026年10月19日