LLM 路由器和网关
INFRO vs Requesty
Requesty 是兼容 OpenAI 的路由网关：一个端点覆盖数百个模型，具备回退、负载均衡和基于延迟的路由策略、自动缓存、按团队、用户和密钥设置的预算、针对 PII 和密钥的护栏、已批准模型列表，以及响应中的每请求成本。你可以按模型使用 Requesty 的密钥或你自己的密钥。它与 INFRO 的重合程度比这份清单中大多数产品都更高——分歧在于范围，而不在于路由是否值得做。
何时 Requesty 是更好的选择
- 你的工作负载以文本为主，并且很可能一直如此。INFRO 为媒体承载的额外界面，是你用不上的成本。
- 你需要把处理保留在欧盟。Requesty 的文档记载了欧盟端点和欧盟托管的模型；区域化处理在 INFRO 的路线图上，目前不可用。
- 你想要对某些模型使用平台的提供商密钥，对其他模型使用你自己的密钥。INFRO 只会在你连接的账号上运行。
- 他们特有的缓存或路由策略行为符合你想要的工作方式——请把两边的文档都读一遍，因为这是一次真正的评估，而不是营销问题。
这一节不是客套。如果其中某一条说的正是你，请选择 Requesty——一个听了我们的建议却用错了这一层的客户，对我们来说比从未成为客户更糟。
两者真正的分歧所在。
- 四种模态，还是一种
- 一次 6 秒视频渲染的路由问题——任务耗时数分钟，通过 webhook 返回，产出的文件还必须比提供商的保留期活得更久——与路由一次聊天补全是不同的问题。同时承载这两者，正是 INFRO 所做的设计决策。
- 钱花在哪里，由谁持有
- 对以媒体为主的产品来说，支出集中在图像、视频和音频上，而这些恰恰是以文本为先的网关仪表盘中最不容易看到的工作负载。INFRO 涵盖这四种模态，并以同样的方式归因其成本——按你自己提供商的费率，在你自己的账号上。无论哪种情形，INFRO 都不收取其中任何部分，因此它的动力是让这笔支出一目了然，而不是让它增长。
- 治理是一款产品，而不是一个设置
- 成员角色、四个层级的上限、模型允许列表和管理审计轨迹，为平台团队提供一套通用的控制，并从 Business 套餐起提供 SAML/OIDC 单点登录和 SCIM 目录同步。
并排对比。
我们这一栏也有横线。一方全是勾的对比没人会信，而且理应如此。
| 能力 | Requesty | INFRO |
|---|---|---|
| 文本模型访问 | 是 | 是 |
| 图像、视频和音频 | 部分图像和音频端点；文档未提及视频 | 是 |
| 路由和回退 | 是 | 是 |
| 你自己的提供商账号 | 部分按模型，在路由策略内 | 是每个请求 |
| 分析和成本追踪 | 是 | 是 |
| 支出控制 | 是团队、用户和密钥 | 是组织、项目、成员、密钥 |
| 护栏 | 是PII 和密钥；报告或脱敏 | 部分聊天内容模式匹配加提示词分类器；Business 套餐 |
| 与提供商自己的账单对账 | 否 | 部分OpenAI 和 Anthropic，Business 套餐；会说明差异 |
| 欧盟数据驻留 | 是欧盟端点和欧盟托管的模型 | 否在路线图上 |
| 异步任务和带签名的 webhook | 部分 | 是 |
| 现已可用 | 是 | 是自助注册 |
这是我们对各产品公开文档的解读，截至 2026年10月。我们不引用竞争对手的价格——他们的价格会变，对别人的业务给出一个错误的数字，不如不给。认为某一行有误？请告诉我们，我们会更正。
已经在用 Requesty？阅读从 Requesty 迁移的指南：哪些代码要改，哪些可以沿用，哪些不行。