AI网关：跨分散团队扩展集中推理
TL;DR · AI 摘要
AI模型网关通过集中控制层解决分散团队的推理混乱，平衡模型选择自主权与安全、权限和成本管控，推荐使用LiteLLM和Doubleword等开源工具优化AI基础设施。
核心要点
- AI模型网关统一管理多个模型提供商，解决分散团队的推理混乱问题
- 集中式控制层支持安全策略、RBAC权限和成本监控，同时允许团队自主选择最佳模型
- 开源工具如LiteLLM和Doubleword可简化AI基础设施部署
结构提纲
按章节快速跳转。
介绍AI模型网关的重要性及演讲者背景，说明分散团队面临的推理混乱挑战
- ·问题分析
解释'推理混乱'现象及其对工程团队造成的安全、成本和管理问题
阐述AI模型网关的核心功能：统一接口、策略控制、多模型支持和监控能力
对比分析LiteLLM和Doubleword等开源工具的适用场景与技术优势
- ·实施策略
提出平衡团队自主权与集中管控的实施框架及最佳实践
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- AI模型网关
- 问题解决
- 推理混乱
- 多供应商管理
- 核心功能
- 统一接口
- 策略控制
- 监控分析
- 开源工具
- LiteLLM
- Doubleword
金句 / Highlights
值得收藏与分享的关键句。
AI模型网关通过统一接口管理多个模型提供商，解决分散团队的推理混乱问题
集中式控制层支持安全策略、RBAC权限和成本监控，同时允许团队自主选择最佳模型
开源工具如LiteLLM和Doubleword可帮助团队在3周内完成AI基础设施部署
[InfoQ首页](https://www.infoq.com/ "InfoQ Homepage")[演讲录播](https://www.infoq.com/presentations "Presentations")AI网关：在分散团队中扩展集中式推理
观看演讲
速度：
下载
46:51
/presentations/ai-gateway-scalability/en/slides/Ari-1779280458969.jpg)
摘要
Meryem Arik 讨论了现代工程团队面临的"推理混乱"问题，以及AI模型网关如何提供关键控制层。她解释了在赋予分散团队选择最佳模型的自主权与保持安全、基于角色的访问控制（RBAC）及成本管控的集中式监督之间取得平衡的方法。通过探索LiteLLM和Doubleword等开源解决方案，可以优化您的AI基础设施。
演讲者简介
Meryem Arik 是Doubleword（前身为TitanML）的联合创始人兼首席执行官。她经常在TEDx和QCon等领先会议上发表关于推理技术和企业AI的见解。Meryem因对AI领域的贡献被《福布斯》评为30位30岁以下杰出人才。
关于会议
QCon AI 是一个由从业者主导的活动，专注于安全扩展这些工作负载所需的技术实践。它提供了直接获取同行组织在生产环境中使用的架构方案和故障指标的途径。
INFOQ 活动
/filters:no_upscale()/sponsorship/eventsnotice/3ecacfe1-02d1-4d54-a048-8ee871a77bb/resources/1EonWebinarMay21-transcript-1774373522295.png)2026年5月21日，美国东部时间中午12点
#### 设计即便携：多云系统的数据迁移与恢复模式
主讲人：Eric Minick - Harness高级DevOps解决方案总监，Aaron Newcomb - Harness高级产品营销经理
#### 构建自主可靠性：将AI嵌入可观测性架构
主讲人：Justin Griffin - NeuBird AI产品主管
#### AI分析时代的日志重构
主讲人：Nicolas Jung - Datadog日志产品经理
演讲实录
Meryem Arik：我是Meryem，Doubleword的CEO。我曾在牛津大学研究物理学，还是橄榄球的忠实粉丝。
我将谈论AI模型网关——这其实是个相当枯燥的话题。这并非我们公司直接从事的业务。你们可能会问，为什么我对这个主题感兴趣？我们在四年前创立Doubleword时，始终专注于推理问题。推理过程就是实际运行模型的过程。我们服务的客户中，虽然我们提供推理服务，但通常并非他们唯一的供应商。他们可能同时使用OpenAI、Mistral，以及自行训练的自托管微调模型。我们发现他们在管理多个供应商时陷入混乱局面，因此不得不帮助他们解决这个问题。
AI模型网关是整理这种混乱环境的有效工具，当存在多个模型供应商时尤为有用。由于我们反复遇到这类问题，最终开发了开源的AI模型网关。我们从头开始构建这类系统，但并未将其商业化。但我们坚信AI模型网关至关重要，认为每个人都应该使用。
你们的组织目前是否部署了AI模型网关？比如LiteLLM或OpenRouter。我将尝试说服各位，每个人都需要部署AI模型网关，即使从最小规模开始。这是本次演讲的目标。
演讲大纲
推理需求
每个应用程序对推理的需求都各不相同，不存在一统天下的单一模型。这就像 Nano Banana（一种小型香蕉品种），我觉得它很出色。例如，针对不同用例，你可能需要不同种类的模型，就像不同品种的猎犬。这里用一个英式狩猎的比喻来类比：假设你要去狩猎（这是一项高雅的活动），你可能需要一只寻回犬（左边的那只）。它们的主要功能是定位猎物并指示射击目标。你还需要西班牙猎犬，用于驱赶猎物。它们会冲进森林，把鸽子惊飞起来，方便你射击。最后，你需要寻回犬在狩猎结束时帮你找回猎物。
若想成功执行狩猎或构建成功的用例，你需要多种模型无缝协作。在选择合适模型时，需考虑三个维度：应用质量、非性能因素和推理性能。
- 应用质量：模型是否能有效解决你的问题？它是否能准确回答所有问题，还是全盘皆输？适合的任务模型应能给出正确答案。
- 非性能因素：这些通常是枯燥但至关重要的约束条件。例如，某些公司可能因与特定供应商的协议，要求所有服务必须运行在 AWS 上；或因数据驻留要求（如 GDPR 合规），需选择欧盟或墨西哥地区的模型。
- 推理性能权衡：即使某个模型在质量上表现卓越，但如果每次调用成本高达 25 美元，显然不可行。我稍后会详细分析这些维度。
你的用例团队需要评估模型在任务中的实际表现。例如：
- 模态类型：是嵌入任务、图像处理还是语音识别？每种任务需要不同类型的模型。
- 性能或智能水平：可通过基准测试和 Elo 分数（类似棋手等级分）评估。
- 领域适应性：特定领域（如医疗保健）可能需要定制化模型。例如，癌症筛查需要高度专业化的模型。
若要赋能用例团队，需为他们提供构建优质应用所需的所有模型，并帮助选择最优解。
非性能因素往往最枯燥，但至关重要。例如：
- 与特定供应商的协议（如 AWS 用户可能更倾向使用 OpenAI 服务）。
- 数据驻留要求（如 GDPR 合规需在欧盟地区部署）。
作为中央推理团队，需为分散的团队提供满足这些约束条件的模型访问权限。
推理性能是第三个关键考量：
- 成本：是否符合用例预算？例如，若你的用例是每月收费 5 美元的在线女友聊天机器人，需确保推理成本极低；而癌症筛查服务因收费较高，可接受更高成本。
- 延迟：是否需要超低延迟？例如使用 Cerebras 等擅长低延迟的平台。或是否支持异步推理？
- 吞吐量与速率限制：需根据用例需求选择匹配的推理服务商。
不同推理服务商在这些维度上的权衡各不相同。以 Nano Banana 为例，它在多用例适配性上表现突出。以下是具体场景分析：
- 编码助手：如 Claude Code，这类交互式工具需超低延迟。试想，当你在编写代码时，若自动补全需要等待五分钟，体验将极其糟糕。因此，这类场景需要同时具备高质量和超低延迟的模型。
通过提供合适的工具，中央推理团队可帮助分散的用例团队高效选择模型，平衡去中心化创新与中心化基础设施的需求。
集中式推理能力
现在我将论证一个观点：推理工具需要集中管理，尽管我们讨论过用例应去中心化且团队需要被赋权。如果将这一逻辑推向极致，我会让每个团队完全自由选择他们认为适合特定用例的工具。最终结果将是混乱不堪——每个团队都在调用各种不同的模型，API密钥满天飞，简直是一团灾难。这种情况在大约18个月或12个月前或许还能接受，当时可能只有一个团队在实验，所有人都使用OpenAI，因为那是当时最好的模型。但现在情况不同了。假设我现在有12个用例团队，可能在使用8种不同模型，比如OpenAI、Fireworks和AWS。或许我们已经有37个不同的API密钥，因为团队出于不明原因不断生成新的密钥。甚至有人未经批准就使用了未经审核的产品。
更糟糕的是，某个实习生可能在周末无意中花费了4000美元——我实际见过真实案例，金额远超这个数字。这就是当去中心化团队随意选择工具时会陷入的失控局面。我们需要在赋权团队的同时保持对全局的控制。集中管理推理工具的原因有很多，我将列举几个关键点：如果你在自托管语言模型，必须集中管理推理。请举手示意是否有自托管模型？比如在自有VM或数据中心部署模型。自托管场景下集中管理尤为重要，因为需要最大化GPU利用率。GPU极其昂贵，如果不集中管理，五个团队各自部署Qwen或Jet模型会导致严重浪费。
我们还需要在不同用例间平衡负载以提升利用率。自托管环境的另一个关键需求是监控可靠性和运行时间——自托管系统通常更为脆弱。对于使用托管服务商（按token计费）的团队，集中管理同样必要：可以协商批量折扣、签订数据留存协议、提升速率限制等。
一个题外话：我最喜欢本演讲中的彩蛋是Nano Banana为某张图片伪造了签名，我觉得非常有趣。无论何种推理需求，集中管理都有诸多必要性：实施差异化的访问策略（比如限制实习生访问客户数据微调的模型）、审计追踪（需要记录所有模型的输入输出）、成本控制（这至关重要，稍后会详细展开）、监控可靠性、实施公司级护栏策略、以及通过数据控制满足地域合规要求。我的第二个核心观点是：如果希望实现有效治理和成本优化，推理阶段的集中化管理至关重要。我们要避免陷入混乱，同时确保团队获得所需工具。
这正是AI模型网关的设计初衷。显然这里有一个与传统API网关的类比。这来自Kong，而且我认为很多人使用API网关。但拥有API网关与拥有AI模型网关存在显著差异。原因在于，来自AI模型的请求与普通API请求具有不同的特性。我们需要监控相关指标，而这些在传统网关中可能未被关注。我可能需要实施护栏机制（guardrails）之类的控制措施，而传统网关中没有对应的类比。我需要模型感知路由（model-aware routing）等特性，这超出了传统网关的能力范围。我的AI模型网关能完成一系列任务，我将逐一介绍。
第一个是统一API访问。这更多是用例团队受益而非中央团队。作为用例团队，我希望能够轻松切换模型。如果没有模型网关，这通常会比较困难，因为不同模型可能使用略微不同的数据格式。对于访问控制，这对自托管模型尤为重要。假设我通过vLLM部署了模型或在自有基础设施上自托管模型，vLLM本身不包含身份验证或授权功能。我需要在此基础上构建访问控制机制。我希望确保日志记录、监控和可审计性已内置。一年后如果我们问为何做出某个决策，我们需要能追溯具体原因。
或者当后续需要微调模型时，我仍需保留数据用于微调。模型路由是AI模型网关提供的宝贵功能。例如，我可能需要根据请求难度路由模型，或根据负载情况路由模型。假设ChatGPT或OpenAI再次宕机，我希望自动将所有请求路由到Anthropic或其他提供商以避免停机。成本控制至关重要，我们希望按组进行管理。稍后我会详细说明。同样需要按组设置速率限制，防止某个实习生周末花掉4000美元。作为公司，我们可能还需要实施护栏机制、故障转移或统一提示词管理，这些都能通过模型网关实现。
这是AI模型网关的典型架构概览。我有多个应用，对应我之前提到的分散式创新场景。所有这些应用都可以自由选择最适合其用例的模型。底部是向团队开放的所有模型，可能包括自托管推理、批量ASIC推理（这是我们所做的）、OpenAI、Anthropic等不同模型。所有来自用例的请求都会通过模型网关。每个请求会关联提示词和元数据。元数据可能包含应用上下文信息，例如需要满足的服务等级协议（SLA）是实时响应还是可延迟10分钟。元数据还可能包含数据处理要求，例如是否需要在特定时间后删除数据，以及路由需求，如目标模型和可接受的故障转移选项。所有请求通过模型网关后，会执行日志记录、监控、身份验证和API密钥检查，然后发送到目标模型并返回结果。
在此架构中至关重要的是，由于模型网关处理每个请求，其延迟必须极低且对用例开发团队完全透明。我们不希望阻碍开发团队的工作，只是确保组织层面的合理性。该网关可收集大量信息，可用于生成分摊报告、设置告警，或进行用户评分等操作。这成为所有请求的核心枢纽，具有强大功能。
以下是几个可尝试的模型网关选项。最流行的是LiteLLM，功能最全面。这是我们自己的开源方案，性能最高。Portkey专注于护栏机制。Bifrost声称性能也很高。前四个均为开源方案，OpenRouter同样广受欢迎。我倾向于选择开源方案，因为最好能自托管。以下是可尝试的不同选项，使用起来非常简单。强烈建议尝试其中一个。接下来我将介绍这些模型网关提供的常见功能。以下截图来自不同供应商，但功能高度相似。首先是控制AI使用情况的界面。这是用例开发者的视图，作为分散式团队的一员，我能看到所有可访问的模型列表，具体取决于我的角色和所属组。在这种情况中，我有一系列可能自托管的模型，还有一些作为API提供商的模型。作为用户，我可以进入这里并指定，我需要使用GPT-5 Nano模型来处理这个用例，获取该模型的API密钥，然后以团队已知的方式通过模型网关进行开发。这对于用例团队了解实际可用的模型来说是一个非常实用的方式。大多数提供商都提供了类似的界面。请求日志是一个非常有用的功能，但有时可能带来风险。需要谨慎控制谁有权访问什么内容。我们希望使用模型网关的一个重要原因，就是能够追踪所有进出的请求，确保不违反政策，例如。我希望记录所有传入请求的日志，包括提供服务的模型，以及诸如耗时、成本等其他指标。基于角色的访问控制（RBAC）可能是个雷区，因此权限管理至关重要。我们和其他很多提供商一样，倾向于围绕“组”这一概念构建解决方案。这是将用户映射到不同模型和权限的最简单方式，非常方便。
回到这里，我可以设置类似这样的规则：这个声明检测模型可能是使用PII（个人身份信息）进行微调的模型。我只想将该模型分配给X、Y、Z组。我们可以讨论预算和速率限制，这也是人们最期待模型网关功能的原因之一。我确实希望控制团队能花多少钱，以及他们能处理多少请求。这借鉴了LiteLLM的做法。每次创建组时，我可以指定该组的预算，例如“实习生预算”，并设定实习生的预算上限为15美元。同时可能需要设置速率限制。比如，实习生的项目优先级不高，因此给她一个很低的速率限制。而另一个负责关键任务型旗舰用例的团队，我会给予极高的预算，因为我要确保该用例始终可用。这类预算和速率限制都可以在模型控制层进行配置，这是团队申请模型访问权限时不可或缺的一部分。
所有这些措施的影响是：分散的用例团队非常喜欢模型网关，因为它能帮助他们更快创新。我们并未通过过度集中化的方式限制他们。例如，如果中央团队规定只能使用AWS Bedrock，这会是一种限制。但通过网关，他们仍能获取所需的模型和工具，确保用例高效运行，还能轻松在不同模型间切换。当新模型推出且架构略有差异时，他们无需重构系统。对于中央推理团队而言，他们获得了所需的控制权，同时不会限制分散团队的灵活性。他们可以确保一致的访问控制和治理流程，无需担心预算失控等问题。这显然是个双赢的选择。此外，模型网关的实施非常简单，不到半天即可完成，使用轻量且成本低廉。我的第三个结论是：模型网关是确保集中管控使用权限，同时赋能团队的正确工具。
总结要点
我的三个核心观点：团队需要自由选择适合其用例的工具，否则他们将开发出质量低劣的应用。推理阶段的集中化管理至关重要，既能确保治理，又能优化成本。AI模型网关是实现这一目标的理想工具，且存在多种开源方案可供尝试，如LiteLLM、Doubleword和Bifrost。最后，如果想阅读启发本次讨论的博文，可访问此链接：https://fergusfinn.com/blog/control-layer/，内容精炼且极具参考价值。
问答环节
参与者1：我认为这可能自然扩展到类似MCP网关的功能，还是应该作为独立网关存在？特别是当涉及可扩展性时，如果有代理和工具发起多个请求而非单一请求的情况，该如何处理？
Meryem Arik：这个模型网关，我之前提到的其实是一个非常简化的网关，它本质上只是处理LLM调用。这确实非常基础。实际上，随着用例变得越来越复杂，推理时涉及的内容会更多。不仅仅是MCP。你的模型网关应该成为更多功能的载体。其中之一就是代理（agent），即具备代理功能的网关。我之前提到的这些请求像是简单的LLM调用，但实际情况并非如此。这种情况已经开始改变——有时我可能需要调用整个代理而非LLM，让它完成任务的一部分。这面临同样的问题。我希望这个模型网关也能作为代理网关和MCP网关。作为企业，我不会让团队随意使用任何MCP服务器，因为存在大量安全风险。我可能需要预批准某些MCP服务器，同时保持统一管控。这些模型网关还是新兴领域。我认为大部分相关项目不超过12个月历史，已经逐渐演变为代理网关和MCP服务器网关。我相信12个月后还会有更多新功能。这是一个非常关键的枢纽点。
Participant 2：在此基础上，是否必须接受某些抽象层级更高的端点无法处理？例如集成在Office套件中的Notepad。它们可以直接与模型通信，无论是Copilot、ChatGPT还是Gemini。是否现实地讲，我们能通过Copilot网关路由流量时仍能理解其流向，以及如何计算成本，即使它已深度集成到平台中？
Meryem Arik：我认为答案是，当原生嵌入时确实很难做到。这取决于微软愿意向你开放多少控制权。反过来，Microsoft Office确实提供了其他类型的管控和治理方式。或许这种权衡是可以接受的。当我讨论网关选项时，确实存在更多选择，但大多数是厂商特定方案。例如Databricks有自己的网关，微软也有。我特意不推荐这些，因为从理念上我认为网关应独立于底层基础设施。我不希望将网关绑定到Databricks，因为未来可能需要切换到Snowflake或其他平台。保持独立层设计是个明智选择，这是我个人的看法。
目前，我们主要通过声明式方式使用："我需要访问某个特定模型"。但这未必总是最佳选择。例如使用ChatGPT时，它后台会不断更换模型，Claude和其他模型也是如此。它们实际上会自行判断"这个模型最适合回答你的问题"。可以想象，中央团队可能需要为特定任务选择最佳思维模型或数据标注模型。
我目前不积极推广这种能力（尽管有些公司和供应商在做），是因为我认为模型网关不应太智能。它应尽可能减少处理工作以避免延迟。另外，我认为用例团队需要自由设计用户所需体验。存在两种观点：有些公司如Not Diamond会构建智能路由系统，将请求路由到最合适的模型而无需用户知晓。但我认为模型网关应保持智能，同时赋予用例团队更多自主权。
Participant 4：关于安全性的问题。您推荐的四个网关是否适合需要联邦认证、将Entra ID等系统作为授权体系的大型企业环境？
Meryem Arik：是的。我们的产品虽然不专门构建网关，但已为大型企业客户构建了生产级解决方案。大多数供应商都支持SSO集成，我们当然也提供SSO，并且具备企业级特性，尤其是自托管版本——可部署在自有环境并连接现有SSO系统。
Participant 5：你主要讨论了内部使用AI网关的场景。
Meryem Arik：这里讨论的是面向外部应用的场景，还是模型本身对外暴露的情况？
Participant 5：是的，我们的客户将通过我们的AI网关交互，而非他们自己的代理系统或连接公共端点的平台服务。例如通过Teams或Google Agentspace这类可信公共端点访问我们发布的MCP服务器。
Meryem Arik: 这很合理。你们肯定已经有网关了，因为这是分发密钥等操作的方式。需要考虑不同的因素吗？如果按照我的观点，即模型网关应该简单且健壮的学派来看。其实不然。是否有特定于内外网逻辑差异的考虑？我认为模型网关本身作为一个概念是相当相似的。因为作为集中化的推理团队，你可以将工作视为为外部使用案例团队提供服务。
Participant 5: 那么将这些现代AI网关与传统API网关进行比较，是否可以扩展或使用类似Apigee的工具来构建AI网关？
Meryem Arik: 我们看到一些客户尝试这样做。但最终他们通常选择放弃。原因在于，专门针对AI模型网关设计的产品会提供更多便捷功能。例如，提示管理可能是你希望模型网关具备的功能。或者，当新模型发布时，你希望原生支持略有不同的API等。我们观察到一些企业客户，尤其是大型企业，最初尝试使用传统API网关，但后来转向专用的AI模型网关。特别是如果像我们之前讨论的，这些网关可能同时充当模型控制平面（MCP）网关、向量数据库网关或代理网关时，让它们与AI原生架构保持一致更有意义。这就是我们看到的情况。因此存在足够的差异性，使其值得作为独立解决方案存在。
Participant 6: 至少从我的理解来看，当提到"企业就绪"时，企业中究竟应该由谁来配置它？因为谈到访问控制时，你提到的配置方式通常是与员工身份验证或端点相关联的。它们能否与Entra集成到该层级？能否在微软内部配置后自动反映到该平台？还是需要单独进入该平台，为各个团队分配独立的访问令牌？因为现在出现一个问题：如果需要专门组建一个团队来处理这些配置，他们如何与实际负责身份验证的团队协作？在现实世界中这会如何运作？
Meryem Arik: 通常的运作方式是，该平台的所有者是平台团队。许多企业正在CTO办公室下建立AI平台团队。与身份提供商（IDP）的交互方式是，正如我之前提到的关于使用组权限？所有这些都应从Entra等系统导入。我本可以创建自定义组，但更希望使用与IDP同步的现有组。例如，工程团队信息应从那里导入并整合到平台中，遵循"尽可能减少重复工作"的原则。具体实现可能包括将这些组映射到平台内的权限。所有身份验证和组信息都应保留在Entra或其他IDP系统中。
Participant 7: 你提到的模型质量评估标准，其中输出质量部分有多少取决于模型本身？有多少取决于提示？
Meryem Arik: 我认为应将质量视为提示、用例和模型的三元组合。例如，如果我试图让模型模仿莎士比亚风格，但提示中要求模仿狄更斯风格，显然无法达成目标。不应单独评价模型是否擅长某项任务。这就像赛马和骑手的关系，需要成对或三元组合来考量。我永远不会单纯因为模型表现差而否定它，而是应该否定"该模型在特定提示下无法满足用例需求"。用例难以集中构建的原因在于，需要领域专业知识来迭代优化提示。
Participant 8: 在治理方面通常有哪些工具？模型网关是否作为中心枢纽可集成不同系统，还是它本身提供治理和护栏功能？
Meryem Arik: 这取决于你认为模型网关应承担多少职责。例如Portkey已集成护栏功能，而我们选择不内置。因为我们认为治理和护栏措施具有高度应用和用例特定性，更适合在网关外部实现。可以选择内置或不内置这些功能。大多数供应商都支持OpenTelemetry原生集成，因此可以直接连接到Datadog等监控工具，用于可观测性管理。
Participant 9: 当你提到保持轻量级和简单性时，有哪些架构模式用于实现这一点？因为我们需要扩展这些模型，任何涉及状态管理的内容都会让扩展变得困难。状态卸载可能是关键。你提到的其他方法还有哪些？有哪些架构模式能帮助保持这种简单性？
Meryem Arik: 这取决于你认为模型网关应承担多少职责。例如Portkey已集成护栏功能，而我们选择不内置。因为我们认为治理和护栏措施具有高度应用和用例特定性，更适合在网关外部实现。可以选择内置或不内置这些功能。大多数供应商都支持OpenTelemetry原生集成，因此可以直接连接到Datadog等监控工具，用于可观测性管理。
Meryem Arik: 保持极简？我们尽量避免让系统有状态化。我们设计的核心是追求极致性能。我们选择自研而非使用LiteLLM的原因在于其延迟表现非常糟糕。例如，我们从头开始用Rust编写，这极大提升了效率。我们不会强制客户通过护栏（guardrails）访问服务，这类设计也会显著增加延迟。在设计模型网关时，我们专注于找出所有公司和应用都必须具备的基础功能，其他部分则基于此灵活构建。
Participant 10: 你们能接受的延迟上限是多少？
Meryem Arik: 理论上应该接近零。因为从设计上它本应是极轻量级的技术组件。我们做过一些基准测试，与Bifrost和LiteLLM对比。结果差异显著。在每秒请求数指标上，我们的硬件配置达到约200，而LiteLLM仅能处理60左右，因为它引入了大量额外开销。不过他们近期可能已优化。这个测试数据约一个月前的结果。理想情况下，网关应尽可能接近理论极限。我们坚信模型网关应近乎“隐形”，这就是我们选择自研的原因。它必须足够轻量级。即使像LiteLLM这样的工具，虽然我们曾认为它在大规模场景下表现较慢，但若未达到巨量规模，我们确实知道有不少团队用它并很满意。
Participant 11: 当你们提到AI网关需要同时管理代理（agents）和服务器网关时，现实中公司可能已有数百个可用模型，甚至可能拥有数千甚至数万代理。平台如何管理这种规模？模型数量多时或许可行，但若要为2万个代理中的某个分配网关，实际操作起来会非常混乱。
Meryem Arik: 没有统一管理难道不会更混乱吗？
Participant 11: 在API网关场景中情况不同。通常是开发API的团队拥有访问权限。如果有一个中心化团队需要为其他团队反向分配数千个资源，这显然不合理。
Meryem Arik: 在我们的模式中，用例团队（use case teams）负责构建API。例如，作为用例团队，当我开发代理类工作负载时，会自行注册到网关系统。我们不期望中心化团队为所有代理建模并管理下游资源。通常采用按需请求模式：某个团队可能提出需要使用新Qwen模型，能否通过Bedrock注册？他们提交请求后获取API密钥即可。
查看更多[演讲实录](https://www.infoq.com/transcripts/presentations/)
录制于：
2026年5月20日
作者：
- Meryem Arik
TitanML联合创始人