10. 如何设计一个 LLM Gateway / Router（模型路由、fallback、负载均衡）？

简单回答

LLM Gateway 是大模型应用和多个模型 Provider 之间的中间层，核心功能是统一接口、智能路由、fallback 容灾和负载均衡。路由策略可以基于任务类型、成本、延迟、模型能力等维度。一个好的 Gateway 能让业务层无感知地切换模型、自动处理故障、并优化整体成本。

详细解释

为什么需要 LLM Gateway？

实际生产中很少只用一个模型。你可能同时用 GPT-4（质量最好但最贵）、GPT-3.5（便宜快速但能力弱）、Claude（长上下文好）、自建模型（成本可控但能力有限）。不同场景用不同模型，模型 Provider 可能宕机需要 fallback，token 成本需要优化。如果每个业务方自己管理这些逻辑，代码会非常混乱。

LLM Gateway 就是把这些复杂性封装成一个统一的服务层。对上游（业务层）暴露统一的 API 接口，对下游（多个模型 Provider）做路由和管理。

核心功能

统一接口是最基础的功能。不管底层用的是 OpenAI、Anthropic、自建模型还是开源模型，上游看到的都是一个统一的请求/响应格式。格式转换、认证管理、错误码映射都在 Gateway 层完成。

智能路由是核心价值。路由策略可以基于多个维度：任务类型（简单问答走 GPT-3.5，复杂推理走 GPT-4，长文档走 Claude）；成本预算（当月 token 预算快用完了，自动降级到便宜模型）；延迟要求（实时对话走低延迟模型，后台任务走高质量模型）；模型能力匹配（代码任务走 CodeLLama 或 DeepSeek Coder）；请求特征（input 长度超过某个阈值自动路由到支持长上下文的模型）。

路由可以是规则驱动的（if-else 逻辑），也可以用一个小的分类模型来自动判断请求应该路由到哪个模型（称为 Router Model）。

Fallback 容灾是生产中必须有的。如果首选模型超时或返回错误，自动切换到备选模型。Fallback 链通常是：首选模型 → 同级别备选模型 → 降级模型 → 缓存兜底。每一级的切换要快（秒级），不能让用户感知到明显的延迟。

负载均衡也是必要的。如果同一个模型有多个实例（比如自建了多个 vLLM 服务），需要在实例间做负载均衡。LLM 的负载均衡和传统 HTTP 服务有一个区别——不能简单用 round robin，因为不同请求的 token 量差异很大，一个长请求可能占满一个实例的全部显存。更好的策略是按当前 pending token 数做加权分发。

其他功能

Token 用量追踪和计费：统计每个用户/团队/项目的 token 消耗，对接计费系统。Prompt Caching：如果多个请求有相同的 system prompt 前缀，可以复用 cache，降低成本。速率控制：按用户、团队或全局维度做限流。日志和监控：记录所有请求的路由决策、模型选择、延迟、token 消耗等。

已有方案

开源方案中，LiteLLM 是最常用的 LLM Gateway，支持 100+ 模型 Provider 的统一接口和路由。还有 Portkey、Helicone 等 SaaS 产品。也有很多团队选择自建，因为路由逻辑和业务场景强相关。

面试时可以这样答

LLM Gateway 本质上是业务层和多个模型 Provider 之间的中间层。核心解决三个问题：统一接口让业务层不需要关心底层用的是哪个模型；智能路由根据任务类型、成本、延迟等维度选最合适的模型；fallback 容灾在模型故障时自动切换，保证可用性。

路由策略可以是规则驱动的——简单问答走便宜模型，复杂推理走强模型，长文档走支持长上下文的模型。也可以用一个小的 Router Model 来自动分类。

负载均衡要注意不能用简单的 round robin，因为不同请求的 token 量差异很大，应该按 pending token 数加权分发。 Fallback 链通常是：首选模型 → 同级备选 → 降级模型 → 缓存兜底。切换要快，用户尽量无感知。

开源方案中 LiteLLM 比较成熟，支持主流模型 Provider 的统一接口。但路由逻辑和业务场景耦合很深，很多团队最终还是自建。

常见追问

1. Router Model 怎么训练？需要什么数据？
2. 不同模型的输出格式不一致怎么处理？
3. Fallback 切换时，已经流式输出了一部分怎么办？