LLM 系统中的路由、负载均衡与故障转移

Source: Dev.to

模型和提供商路由

• 硬编码的提供商脆弱 – 早期系统常将单一提供商和模型锁定在代码库中。当需求变化（成本、准确性、供应商锁定）时，整个应用必须更新。
• 基于提供商的路由 将此逻辑下沉到基础设施。请求只说明 需要什么，而不是 谁来提供。网关根据配置和运行时条件决定将流量发送到何处。

关键概念

负载均衡与并发处理

当流量持续增长时，吞吐量和并发比峰值基准更为重要。

常见痛点

• 单个 API key 触顶，导致限流。
• “热点”服务使提供方负载过高，出现延迟峰值并引发级联重试。
• 未协调的突发导致服务意外同步流量峰值。

网关解决方案

1. 多密钥负载均衡 – 将请求分配到多个凭证上，平滑吞吐并遵守每个密钥的限制，这些限制往往低于整体需求。
2. 并发整形 – 施加背压并限制每个提供方的并发调用，以保持使用在安全范围内。
3. 吞吐平滑 – 优先保证可预测性，而非偶尔的速度突发；在负载下的稳定延迟通常比拥有长尾延迟的快速尾部更有价值。

在网关中集中处理这些问题，可免去在各个服务中不断调优的需求。

故障转移和回退行为

LLM 失败很少是干净的。请求可能：

• 部分成功，然后在流式传输一些 token 后超时。
• 仅在特定负载模式下失败。

两层弹性

决策逻辑

• 何时重试？ – 盲目重试会放大故障。重试应根据请求类型、预期延迟和下游影响来决定。
• 何时回退？ – 如果违反了延迟或成本约束，则回退到次要模型或提供商。
• 何时快速失败？ – 对于不可重试的错误（例如身份验证失败），应立即返回错误。

处理部分失败对流式响应和使用工具的代理尤为重要。网关可以在这些情况下强制执行一致的行为，而不是让每个服务自行猜测。

为什么此层应该放在网关中

路由、负载均衡和故障转移是 横切关注点。当它们存在于应用代码中时：

• 跨服务的逻辑碎片。
• 小的差异累积，增加运维复杂度。

专用网关将逻辑集中，使其更易于推理、测试和演进。

maximhq / bifrost – 最快的 LLM 网关（比 LiteLLM 快 50 倍），具备自适应负载均衡器、集群模式、护栏、支持 1 000+ 模型 &  15

快速入门

在不到一分钟的时间内，从零搭建一个可投入生产的 AI 网关。

步骤 1 – 启动 Bifrost 网关

本地安装并运行

npx -y @maximhq/bifrost

或使用 Docker

docker run -p 8080:8080 maximhq/bifrost

步骤 2 – 通过 Web UI 配置

打开内置的网页界面：

open http://localhost:8080

（在 Windows 上可以使用 start http://localhost:8080，或直接在浏览器中打开该 URL。）

步骤 3 – 发起你的第一个 API 调用

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{"role": "user", "content": "Hello, Bifrost!"}]
  }'

就这样！ 你的 AI 网关已经运行，并配有可视化配置、实时监控等功能的网页界面。

为什么选择 Bifrost？

Bifrost 负责路由、故障转移以及其他基础设施层面的决策，让应用只需描述 需要什么。网关则决定 如何 满足这些请求，从而保持应用代码的简洁，并且能够在不进行统一重新部署的情况下进行全系统范围的改动。

随着基于 LLM 的系统规模扩大，这一基础设施层变得至关重要。提前采用 Bifrost，可以让扩展过程更顺畅，整体系统也更易于运维。