企业 AI 路由器设计
不同的模型有不同的优势、延迟特性、资源需求和可用性特征。将一个模型硬编码到每个消费应用中，会将这些决策推到错误的架构层。
梯形图转SCL | 博途AI辅助编程文档 | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
在 GCP 上构建受治理的多模型推理层，而不将企业应用与单个大语言模型耦合
大多数企业大语言模型集成都始于一个简单的决策：
应用应该调用哪个模型？
一旦组织开始运营多个模型，这个问题就会变得棘手。
不同的模型有不同的优势、延迟特性、资源需求和可用性特征。将一个模型硬编码到每个消费应用中，会将这些决策推到错误的架构层。
在尝试从 Workato 进行开源大语言模型集成时，我得出了不同的设计：
应用应该请求 AI 能力。AI 基础设施应该决定哪个模型执行它。
由此产生的架构使用一个模型路由器控制四个开放权重模型，位于单个受治理的 API 之后。
这个路由层变得比原始的大语言模型部署本身更有趣。
1、从模型集成到模型抽象
传统的集成看起来像这样：
应用
│
▼
特定大语言模型
有多个模型时，很快就会变成：
应用 A ──► 模型 A
应用 B ──► 模型 B
应用 C ──► 模型 C
现在每个应用都需要了解：
- 模型名称，
- 端点，
- 认证，
- 能力，
- 可用性，
- 替代模型，
- 以及可能的推理参数。
我想要相反的关系。
┌──► 模型 A
│
企业 ├──► 模型 B
应用 ─► 路由器
├──► 模型 C
│
└──► 模型 D
企业应用看到一个 AI 服务。
路由器看到一个模型组合。
这个边界是架构的核心。
2、架构
外部设计有意保持简单：
企业消费者
│
Workato / 应用
│
▼
GCP API 网关
│
▼
模型路由器
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
模型 A 模型 B 模型 C 模型 D
│ │ │ │
└─────────┴─────────┴─────────┘
│
GPU 推理
底层基础设施使用 GCP、容器化推理和 vLLM。
这些组件在运营上很重要，但它们不是架构上的贡献。
重要的组件是API 契约和推理引擎之间的路由器。
3、路由器实际做什么
路由器不仅仅是反向代理。
反向代理回答：
这个 HTTP 请求应该去哪里？
模型路由器回答：
哪个模型应该执行这个 AI 工作负载？
概念上，请求经过四个阶段。
请求
│
▼
1. 验证
│
▼
2. 工作负载分类
│
▼
3. 候选模型选择
│
▼
4. 执行 + 回退
│
▼
标准化响应
因此，客户端不需要指定它想要使用的物理部署。
而不是：
{
"model": "物理模型名称",
"prompt": "..."
}
外部契约可以暴露逻辑能力：
{
"task": "general_generation",
"messages": [...]
}
内部：
general_generation
│
▼
路由器
/ | \
▼ ▼ ▼
M1 M2 M3
│
▼
选定的模型
模型名称变成基础设施关注点，而不是应用关注点。
4、选择是一个约束问题
路由器不应该简单地轮询分发请求。
大语言模型不是同一服务的可互换副本。
因此，第一阶段是资格认定。
对于请求 r，让部署的模型为：
路由器首先根据约束产生合格子集：
- 模型可用性，
- 支持的任务，
- 所需上下文长度，
- 基础设施容量，
- 工作负载特征。
只有在此之后，路由器才应该对候选模型进行排名。
广义评分函数可以表示为：
其中：
- Q = 预期任务适用性，
- L = 预期延迟，
- C = 推理成本或资源压力，
- A = 当前可用性，
- w 表示分配给每个因素的重要性。
确切的系数是实施策略。
架构要点更为重要：
模型选择成为显式策略，而不是偶然的应用配置。
5、路由示例
考虑四个具有不同预期角色的模型。
模型 A → 通用生成
模型 B → 更强的推理工作负载
模型 C → 轻量级/低延迟请求
模型 D → 备用或回退能力
简短的分类或转换请求可能不需要最大的模型。
简短确定性任务
│
▼
路由器
│
▼
轻量级模型
更复杂的请求可能遵循不同的路径。
复杂推理任务
│
▼
路由器
│
▼
更高能力模型
这也避免了一个常见的反模式：
仅仅因为最昂贵或资源最密集的模型可用，就对每个请求都使用它。
6、回退是路由的一部分
模型选择也为架构提供了处理故障的自然位置。
假设首选路由是：
请求
│
▼
模型 B
如果模型 B 不健康、过载或不可用，服务不一定立即失败。
路由表可以定义：
首选
│
▼
模型 B
│
失败
▼
模型 A
│
失败
▼
模型 D
因此，路由器可以区分：
模型故障
和：
AI 服务故障
这不是一回事。
对于开放模型，这变得特别有用，因为不同的运行时或模型版本可以实验性地引入，而不会将这种波动暴露给企业消费者。
7、稳定的契约，变化的模型
这引出了我认为设计中最重要的特性。
从 Workato 的角度来看：
POST /v1/chat/completions
保持稳定。
在它后面：
今天
路由器 ──► 模型 A
稍后
路由器 ──► 模型 B
更晚
路由器 ──► 模型 A/B/C/D
动态选择
业务工作流不会改变。
这就是架构解耦。
它允许 AI 工程团队更改：
- 模型版本，
- 运行时配置，
- GPU 分配，
- 路由规则，
- 回退优先级，
- 甚至模型系列，
而无需将这些更改强制到每个企业工作流中。
8、为什么保持 OpenAI 兼容的契约？
推理层使用 vLLM，它提供 OpenAI 兼容的 HTTP 接口。
这很有用不是因为需要 OpenAI 本身，而是因为 API 形状已成为实用的互操作性契约。
流程变成：
客户端
│
│ 标准请求
▼
路由器
│
│ 模型特定决策
▼
推理运行时
│
▼
开放模型
响应也可以在返回给客户端之前进行标准化。
因此，路由器隔离了两种形式的变化：
北向
稳定的企业 API
─────── 路由器边界 ───────
南向
变化的模型和运行时
这类似于抽象层在分布式系统其他地方扮演的角色。
9、GCP 层——刻意无聊
支持性基础设施是有意传统的。
Workato
│
▼
API 网关
│
▼
容器化路由器
│
▼
vLLM 推理
│
▼
开放权重模型
模型工件可以独立存储在 Cloud Storage 中，并挂载到推理环境中，而不是烘焙到应用程序镜像中。
API 网关提供外部 API 边界。
对于 POC，API 密钥身份验证足以证明集成路径。
对于包含敏感信息的生产工作负载，应引入更强的身份控制、服务身份验证、私有网络、配额、集中日志记录和密钥管理。
重点不是发明新的 GPU 部署模式。
重点是保持路由抽象下方的基础设施可替换。
10、Workato 成为 AI 消费者，而不是 AI 运行时
这显著改变了 Workato 的职责。
Workato 应该知道：
业务事件
↓
业务工作流
↓
AI 能力请求
它不应该需要知道：
GPU
模型检查点
vLLM 进程
上下文限制
模型健康状况
回退顺序
路由策略
这属于 AI 平台。
因此，集成变得简单：
Workato 配方
│
▼
HTTP 请求
│
▼
受治理的 AI API
这种模式同样可以服务其他消费者：
┌── Workato
│
AI 网关 ◄────────┼── Copilot / 代理
│
├── Web 应用
│
└── 内部服务
因此，相同的模型组合可以重用，而无需为每个企业平台重建推理集成。
11、更广泛的模式：内部 AI 控制平面
最初连接企业自动化与开放模型的方法指向更广泛的架构。
企业层
│
┌────────────────┼────────────────┐
│ │ │
Workato 代理 应用
│ │ │
└────────────────┼────────────────┘
│
▼
AI API 网关
│
▼
模型路由器
│
┌────────────┼────────────┐
▼ ▼ ▼
模型 A 模型 B 模型 C 模型 D
路由器成为 AI 控制平面的起点。
未来的策略可以包括：
- 工作负载分类，
- 延迟，
- 模型健康状况，
- 容量，
- 任务适用性，
- 成本，
- 隐私要求，
- 模型评估分数，
- 以及最终的租户特定策略。
企业消费者与这些决策保持隔离。
12、关键教训
最初最重要的问题是：
如何将开源大语言模型连接到 Workato？
实现该架构后，我认为这是错误的抽象级别。
更好的问题是：
企业应用如何消费 AI 而不与单个模型耦合？
我的答案是：
稳定的 API
+
模型路由器
+
显式选择策略
+
多个开放模型
+
回退
然后，单个模型就变成了可替换的基础设施。
这对于企业 AI 架构来说可能比模型本身的选择更重要。
原文链接：One API, Multiple Open LLMs: Designing a Model Router for Enterprise AI
汇智网翻译整理，转载请标明出处
