LLM Gateway/Router 概念详解

📍 一、路由方案（Router）—— 选模型的学问

1. 路由策略演进路线

阶段策略做法适用场景风险
V1 固定规则路由 if (scene == "翻译") → 模型 A 第一版 Gateway，大多数业务 规则靠人维护，容易滞后
V2 成本优先/级联路由 小模型先试，失败/低置信度再升级 分类、摘要、客服 FAQ 小模型误判会传导
V3 语义/分类路由 用 embedding 计算相似度路由 问题类型稳定、流量大 分类器会随业务漂移，需定期重训
V4 学习型路由 基于历史质量/成本/延迟训练 Router 多模型、多任务、大流量 依赖标注数据和评测闭环
V5 个性化路由 结合用户偏好、历史交互 C 端助手、教育、内容平台 隐私和一致性成本高
V6 Agentic 路由 多轮任务中动态切换模型 复杂 Agent、长链路 调试和成本控制难度大

2. 路由决策的 7 个维度

路由决策因素:
  - scene: 业务场景（意图分类/复杂推理/法务审核）
  - input_tokens: 输入长度（判断是否超上下文窗口）
  - output_length: 输出长度控制（成本和延迟）
  - user_tier: 用户套餐（免费/付费/企业）
  - risk_level: 风险等级（低/中/高）
  - model_health: 模型健康状态（429/P95 延迟/异常）
  - historical_quality: 历史质量（某模型在某类任务上的成功率）

3. 负载均衡策略（同模型多实例）

策略原理适用场景性能开销
simple-shuffle（默认） 随机选择 高并发、通用场景 最低
least-busy 选活跃请求数最少的 高并发、避免热点 中
latency-based 选历史延迟最短的 延迟敏感的交互应用 中
cost-based 选成本最低的 成本敏感的批量处理 低
usage-based 选 RPM/TPM 使用率最低的 精确控制流量分配 高（需 Redis）

⚠️ 关键坑： 不能用简单 Round Robin！不同请求的 Token 量差异巨大，一个长请求可能占满实例全部显存。应该按 pending token 数加权分发。

4. Fallback 链设计

Fallback 触发频率 = 主模型失败后，系统被迫切换到备用模型的次数。

举个接地气的例子：

假设你配置了这样的路由链：

GPT-4 (主) → GPT-3.5 (备) → 本地模型 (最后)

正常情况：

  • 100 次请求 → 100 次都用 GPT-4 → Fallback 频率 = 0%

出问题时：

  • 100 次请求 → GPT-4 挂了 30 次 → 系统自动切换到 GPT-3.5 → Fallback 频率 = 30%

为什么要监控这个指标？

Fallback 频率含义该做的事
0-5% 正常波动 不用管
10-30% 主模型不太稳定 检查主模型服务状态
>50% 主模型基本挂了 赶紧修！或者临时切到备用
>90% 主模型完全不可用 主模型可以下线了

代码里长这样：

// 每次触发 fallback 时计数
if (primaryServiceFailed)
{
    _fallbackCounter++;  // +1
    _totalRequests++;
    
    var fallbackRate = _fallbackCounter / _totalRequests;  // 30%
    
    // 如果频率太高，发告警
    if (fallbackRate > 0.3)
    {
        _logger.LogWarning("主模型 fallback 频率过高：{Rate}", fallbackRate);
    }
}

简单说： 这个指标告诉你主模型有多不靠谱。频率越高，说明主模型越拉胯，得赶紧修或者换人。

错误类型处理：

错误类型是否适合 Fallback处理方式
网络瞬断 ✅ 短重试后切备用
供应商 5xx ✅ 重试 + 熔断 + 切供应商
429 限流 ✅（谨慎） 读 Retry-After，排队或切模型
上下文超限 ❌ 压缩上下文或换长上下文模型
参数错误 ❌ 修请求，不要重复打供应商
安全拒答 ❌ 进入业务拒答或人工流程

冷却机制： 某部署失败 N 次后放入冷却期（如 30 秒），避免继续向故障部署发送请求。

🏗️ 二、网关架构（Gateway）—— 管全生命周期

Gateway vs Router 区别

维度RouterGateway
职责 模型选择 统一接入 + 路由 + 限流 + fallback + 观测 + 成本治理
决策粒度 单次请求选模型 请求全生命周期治理
输入 用户问题、任务类型、预算 请求 + 用户 + 租户 + 场景 + Prompt + 模型 + 供应商 + 策略
输出 目标模型 完整调用结果 + usage + 日志 + 错误 + 成本 + fallback 轨迹

简单说：Router 负责选模型，Gateway 负责把整次模型调用管起来。

Gateway 核心能力模块

┌─────────────────────────────────────────────────────────┐
│                    LLM Gateway                          │
├─────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐     │
│  │  统一接入   │  │  模型路由   │  │  优雅降级   │     │
│  │  (Provider  │  │  (Router)   │  │  (Fallback) │     │
│  │   Adapter)  │  │             │  │             │     │
│  └─────────────┘  └─────────────┘  └─────────────┘     │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐     │
│  │  限流配额   │  │  成本统计   │  │  观测审计   │     │
│  │  (Token     │  │  (Usage +   │  │  (Trace +   │     │
│  │   Budget)   │  │   Cost)     │  │   Logging)  │     │
│  └─────────────┘  └─────────────┘  └─────────────┘     │
│  ┌─────────────┐  ┌─────────────┐                       │
│  │  缓存层     │  │  模型注册表 │                       │
│  │  (精确 +    │  │  (tier-* →  │                       │
│  │   语义)     │  │   真实模型) │                       │
│  └─────────────┘  └─────────────┘                       │
└─────────────────────────────────────────────────────────┘

1. 统一接入（Provider Adapter）

核心价值： 业务代码不直接调用 OpenAI/Anthropic/DeepSeek SDK，只依赖 Gateway 统一接口。

2. 限流与配额（Token Budget）

传统 API 按 QPS 限流，LLM 必须按 Token 限流！

四层限流：

  • 用户级：防滥用
  • 租户级：控成本、做套餐隔离
  • 模型级：防热门模型被打满
  • 供应商级：防外部依赖拖垮系统

3. 成本统计（成本归因）

必须记录的字段：

字段说明
request_id 业务请求唯一 ID
attempt_id 模型调用尝试（fallback/重试会产生多个）
tenant_id 租户/团队
scene 业务场景（客服/摘要/代码生成）
prompt_version Prompt 版本
model_tier 内部模型层级（tier-fast/tier-flagship）
model 实际调用模型
input_tokens / output_tokens Token 用量
cost 按当前价格计算的成本
latency_ms / ttft_ms 总延迟 / 首 Token 延迟
fallback_used 是否发生 fallback

有了这些才能回答：

  • 哪个租户成本最高？
  • 哪个功能最烧 Token？
  • 哪个 Prompt 版本导致输出变长？
  • 哪个模型在某场景下性价比最好？

4. 观测与审计

一次调用的 Trace 示例：

{
  "request_id": "req_202605210001",
  "attempt_id": "att_01",
  "tenant_id": "team_java",
  "scene": "knowledge_qa",
  "prompt_version": "rag_qa_v7",
  "provider": "openai",
  "model_tier": "tier-balanced",
  "model": "gpt-4-turbo",
  "route_reason": "scene=knowledge_qa,cost_priority=true",
  "input_tokens": 4210,
  "output_tokens": 612,
  "cost": 0.0059,
  "ttft_ms": 680,
  "latency_ms": 4120,
  "fallback_used": false
}

5. 缓存策略

缓存类型做法适合场景风险
精确缓存 请求完全一致时返回旧结果 FAQ、固定说明 个性化场景容易错
Prompt 缓存 稳定长前缀自动命中 长系统提示、稳定工具 Schema 前缀变化会让收益消失
语义缓存 语义相似的问题复用旧答案 客服 FAQ、低风险问答 相似≠相同，容易答偏

不适合缓存的场景：

  • 带用户权限的问题
  • 查询实时状态的问题
  • 金融/医疗/法务建议
  • 包含私密上下文的多轮对话

🎯 三、主流方案对比

方案适合团队优点缺点
自研 有工程能力、路由逻辑与业务强耦合 完全可控、深度定制 开发成本高
LiteLLM 快速落地、支持 100+ 模型 成熟、开箱即用 路由逻辑通用，难定制
Cloudflare AI Gateway 需要全球边缘节点 低延迟、内置缓存 依赖 CF 生态
Kong AI Gateway 已有 Kong 基础设施 与传统网关集成好 AI 特性相对少

📊 对比总表

维度自研LiteLLMCloudflare AI GatewayKong AI Gateway
定位 完全定制 Python 开源网关 边缘云网关 传统 API 网关扩展
语言 任意 (.NET/Java/Go) Python JavaScript/Worker Lua/Kong Plugin
部署 自己搞定 自建/托管 SaaS (边缘节点) 自建/云托管
成本 开发成本高 低 按请求付费 中 (开源 + 企业版)
延迟 可控 取决于部署 极低 (边缘) 取决于部署
模型支持 自己接 100+ 主流供应商 主流供应商
路由能力 完全定制 配置化 规则 + 语义 规则 + Plugin
观测 自己建 内置 内置 内置 + Plugin
适合阶段 规模化/特殊需求 快速落地 全球用户 已有 Kong 设施

1️⃣ 自研 LLM Gateway

架构图

┌─────────────────────────────────────────────────────────────┐
│                    自研 LLM Gateway                          │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │  认证层     │  │  路由层     │  │  降级层     │         │
│  │  (JWT/     │  │  (规则/     │  │  (Retry/    │         │
│  │   OAuth)   │  │   语义/ML)  │  │   Fallback) │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │  限流层     │  │  观测层     │  │  缓存层     │         │
│  │  (Token    │  │  (Trace/    │  │  (精确/     │         │
│  │   Budget)  │  │   Cost)     │  │   语义)     │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│                          ↓                                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              Provider Adapter Layer                  │   │
│  ├──────────┬──────────┬──────────┬──────────┬─────────┤   │
│  │  OpenAI  │  Azure   │  Anthropic│  Qwen   │  Ollama │   │
│  │  Adapter │  Adapter │  Adapter  │  Adapter│  Adapter│   │
│  └──────────┴──────────┴──────────┴──────────┴─────────┘   │
└─────────────────────────────────────────────────────────────┘

核心代码结构（.NET 示例）

LLMGateway/
├── Gateway.Core/              # 核心抽象层
│   ├── IGateway.cs
│   ├── IModelRouter.cs
│   ├── IProviderAdapter.cs
│   └── Models/
│       ├── LLMRequest.cs
│       ├── LLMResponse.cs
│       └── TokenUsage.cs
│
├── Gateway.Routing/           # 路由逻辑（业务耦合）
│   ├── RuleBasedRouter.cs
│   ├── SemanticRouter.cs
│   ├── CostOptimizer.cs
│   └── Config/
│       └── RoutePolicy.cs
│
├── Gateway.Providers/         # 供应商适配
│   ├── OpenAIAdapter.cs
│   ├── AzureOpenAIAdapter.cs
│   ├── DashScopeAdapter.cs
│   └── OllamaAdapter.cs
│
├── Gateway.Middleware/        # 中间件
│   ├── AuthMiddleware.cs
│   ├── RateLimitMiddleware.cs
│   ├── RetryFallbackMiddleware.cs
│   └── LoggingMiddleware.cs
│
├── Gateway.Observability/     # 观测
│   ├── CostTracker.cs
│   ├── TraceCollector.cs
│   └── MetricsExporter.cs
│
└── Gateway.API/               # HTTP 入口
    ├── Controllers/
    │   └── ChatController.cs
    └── Program.cs

✅ 优点

优势说明
完全可控 路由逻辑、重试策略、缓存策略全部自己说了算
深度定制 可以针对电池分析场景做特殊优化（如 CC 阶段识别）
技术栈统一 用 .NET/Java 团队现有技能，不用学 Python
无厂商锁定 不依赖任何 SaaS，想迁移就迁移
成本透明 没有中间商赚差价，只付模型钱
posted @ 2026-08-06 15:24  天才卧龙  阅读(24)  评论(0)    收藏  举报