L4

模型网关

Model Gateway Layer — 统一推理 API · 智能路由 · 流量治理 · 安全认证 · 外部 Provider 集成 · 语义缓存

层级编号 L4 对外接口 OpenAI 兼容 REST API 依赖方向 ↓ L3 (模型路由表) / ↔ 外部 Provider 关键用户 应用开发者 · 平台工程师 · 安全团队 路由延迟 < 5ms (内部) · < 1ms (路由决策) 吞吐规模 10K+ QPS · 100+ 模型端点

2. 层级定位与边界

L4 模型网关是整个 AI 平台的统一的模型推理入口。所有上层应用 (L5/L6/L7) 面向 OpenAI 兼容 API 编程,由 L4 负责将请求智能路由到内部部署的模型或外部 Provider。L4 是平台中唯一与外部模型供应商通信的层级,也是安全边界、限流熔断和流量治理的核心执行点。

L4 的核心职责包括:提供 OpenAI 兼容的统一推理 API、基于模型路由表的智能路由决策、外部 Provider 协议适配、API 鉴权和访问控制、限流/熔断/降级等流量治理、语义缓存加速、请求/响应审计日志、以及计费数据采集。

L4 模型网关定位 · 对外暴露 OpenAI 兼容 API · 对内路由到内部部署或外部 Provider L4 边界规范摘要 B4 · 向上层 (L5+) 提供 OpenAI 兼容 API (/v1/chat/completions 等) 统一鉴权 (API Key / OAuth 2.0 / OIDC) 一致的错误格式和状态码 流式响应 (SSE) 支持 请求级超时和重试语义 B4 · 不暴露 内部模型部署细节 (地址/引擎/版本) 底层 Provider 切换逻辑 模型权重或元数据存储位置 内部熔断/降级状态 B3 · 向下层 (L3) 调用 模型路由表查询 别名 → 版本 → 端点映射 模型能力元数据(上下文长度等) B4 · 外部 Provider Anthropic / OpenAI / Google / 通义千问 百度千帆 / 字节豆包 / DeepSeek / Moonshot 智谱 / Azure OpenAI / 自建推理 内部组件边界 路由引擎 ↔ 路由表缓存 认证模块 ↔ 密钥管理服务 限流器 ↔ Redis 计数器 语义缓存 ↔ GPTCache + Redis 审计日志 ↔ 日志采集管道 关键 KPI 路由决策延迟 < 1ms 网关附加延迟 < 5ms 网关可用性 ≥ 99.99% 缓存命中率 ≥ 40% (语义) 关键原则 L4 是唯一与外部 Provider 通信的层级 内部模型部署细节对上层完全透明 所有请求必须通过 L4 的鉴权和限流 外部 Provider 故障不影响内部推理 L7 · 业务应用层智能问数 · 数字人 · 智能客服 · AI 编程 L6 · 多 Agent 管理平台Agent 编排 · Skill 市场 · Tool 注册 L5 · 模型基础应用平台Agent 平台 · Dify · RAG · MCP 接入 边界 B4 (L5↔L4) L4 暴露 OpenAI 兼容 API L5 仅通过 L4 访问模型推理 L5 不感知 L4 内部路由逻辑 L4 · 模型网关 ★ (当前层级) 统一 API 入口 → 通过 /v1/chat/completions, /v1/embeddings 等 OpenAI 兼容端点暴露 智能路由 → 精确匹配 · 负载均衡 (Least Connection / Round Robin / Weighted / Adaptive) · 智能降级 · 成本优化 · A/B 测试 流量治理 → 限流 (Token Bucket / Sliding Window per API Key) · 熔断 (Hystrix Pattern) · 超时控制 · 请求队列 (优先级) · 语义缓存 (GPTCache+Redis) 安全认证 → API Key HMAC 签名 · OAuth 2.0 / OIDC SSO · 模型级访问控制 · 内容安全 (输入过滤 + 输出审核) · 审计日志 (敏感数据脱敏) 外部 Provider → Anthropic · OpenAI · Google · 阿里百炼 · 百度千帆 · 字节豆包 · DeepSeek · Moonshot · 智谱 · Azure OpenAI 协议适配器 → 每个 Provider 的专有 API 协议 → 统一适配为 OpenAI 兼容格式 缓存 → Redis (限流 + 路由表) + GPTCache (语义缓存 Semantic Caching) + Local LRU (高频路由) ☁ 外部 Provider Anthropic · OpenAI · Google · 百炼 · 千帆 ▼ L4 规约不变项 ⚠ 架构规约: L4 边界的四条不变原则 ① 上层只通过 OpenAI 兼容 API 访问模型 ② L4 是唯一与外部 Provider 通信的层级 ③ 内部部署细节对上层完全透明 ④ 所有请求必须通过鉴权和限流 边界 B3 (L4↔L3) L4 从 L3 查询模型路由表 L3 返回别名→版本→端点映射 L4 缓存路由表在本地 + Redis L3 · 模型市场 模型注册中心 · 模型发现与搜索 · 版本管理 (SemVer + Alias) · 标准化评测平台 · 排行榜 · 生命周期管理 L2 · 模型部署层 vLLM · TensorRT-LLM · TGI · SGLang · Triton · Xinference · Ollama · FastChat — 推理引擎管理 + 弹性伸缩 + 灰度发布 L1 · 基础设施与算力管理层 K8s 编排 · GPU/NPU 算力池 · MinIO/Ceph 对象存储 · PostgreSQL · Redis Cluster · Prometheus · Kong/APISIX 硬件底座 · NVIDIA A100/H100 · 企业级 NVMe SSD · Redis 集群 · 负载均衡器

3. 边界规范

上游 → L5 模型应用平台 提供:OpenAI 兼容的 REST API(Chat Completions、Completions、Embeddings、Audio、Images),所有上层应用统一通过此 API 调用模型推理,不暴露任何内部部署细节。
不提供:L4 不暴露底层模型部署的物理地址、推理引擎类型、模型版本号;不暴露路由策略、Provider 切换逻辑;不暴露限流配额和熔断状态。
关键约束:L5 只能通过 L4 访问模型推理,不允许直接调用 L2 推理端点或外部 Provider。
下游 → L3 模型市场 查询:L4 从 L3 查询模型路由表获取别名到版本到端点的完整映射关系,以及模型的上下文长度、支持的参数等能力元数据。
缓存:L4 将 L3 返回的路由表缓存在本地 LRU Cache 和 Redis 中,缓存 TTL 可配置(默认 60s),路由表变更时 L3 通过 Redis Pub/Sub 通知 L4 缓存失效。
外部 Provider L4 是平台中唯一与外部模型供应商通信的层级。通过协议适配器将各 Provider 的专有 API 协议转换为 OpenAI 兼容格式。当前支持 Anthropic、OpenAI、Google Gemini、阿里百炼、百度千帆、字节豆包、DeepSeek、Moonshot、智谱、Azure OpenAI。
关键原则:外部 Provider 故障不扩散到内部推理链路;Provider 切换对上层完全透明;Provider API Key 在 L4 的安全模块中加密存储。
内部模块 路由引擎 ↔ 路由表缓存:路由引擎每次决策前先查本地 LRU 缓存,未命中则查询 Redis 集群,Redis 也未命中则回源到 L3。
认证模块 ↔ 密钥管理服务:认证模块调用内部 KMS 验证 API Key 有效性,支持 HMAC 签名验证和 OAuth 2.0 token 校验。
限流器 ↔ Redis:限流器基于 Redis 的计数器和有序集合实现 Token Bucket 和 Sliding Window 算法,支持分布式限流。
语义缓存 ↔ GPTCache + Redis:GPTCache 通过 embedding 相似度匹配缓存命中,缓存结果存储在 Redis 中。
审计日志 ↔ 日志管道:所有请求和响应的摘要记录通过异步管道发送到 ELK / Loki 集群。

4. 统一 API 协议

L4 对外暴露与 OpenAI API 完全兼容的 REST 接口,上层应用可以使用标准的 OpenAI SDK 或任何兼容 HTTP 客户端直接访问。所有 Provider 差异在 L4 内部封装,对调用者完全透明。

4.1 Chat Completions

核心端点 /v1/chat/completions 提供完整的对话补全功能,支持流式和非流式响应、多轮对话、Function Calling、工具调用等多种 OpenAI 原生特性。

POST/v1/chat/completions对话补全 (核心端点)
POST/v1/completions文本补全 (兼容 Legacy)
POST/v1/embeddings文本向量化
POST/v1/audio/transcriptions语音转文字
POST/v1/audio/speech文字转语音 (TTS)
POST/v1/images/generations图像生成

4.2 模型指定方式

请求中的 model 参数支持多种格式,L4 根据不同的格式采用相应的路由策略:

方式格式示例说明路由策略
基础指定 qwen3-235b-a22b 直接使用模型 ID,L4 解析别名映射到当前 production 版本 精确匹配 + 别名解析
版本指定 qwen3-235b-a22b@v1.2.0 使用 @ 符号指定具体版本号,跳过别名解析 精确匹配
LoRA 适配器 qwen3-235b-a22b+lora:finance-v1 使用 +lora: 后缀指定加载的 LoRA 适配器 精确匹配 + LoRA 注入
外部 Provider openai/gpt-4o / anthropic/claude-3.5-sonnet 使用 provider/ 前缀,L4 将请求转发到外部 Provider Provider 路由
路由策略 router:cost-optimized:qa-v1 使用 router: 前缀并指定策略名称,L4 按策略自动选择模型 策略路由

4.3 请求/响应示例

标准 Chat Completions 请求

curl -X POST https://gateway.api.internal/v1/chat/completions \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3-235b-a22b",
    "messages": [
      {"role": "system", "content": "你是一个专业的金融助手。"},
      {"role": "user", "content": "请分析2026年Q1中国经济数据的主要趋势。"}
    ],
    "temperature": 0.7,
    "max_tokens": 4096,
    "stream": false
  }'

// 响应 (非流式)
{
  "id": "chatcmpl-9a8b7c6d5e4f3a2b1c0d",
  "object": "chat.completion",
  "created": 1717000000,
  "model": "qwen3-235b-a22b",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "从2026年Q1的经济数据来看,中国经济呈现出以下几个主要趋势..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 42,
    "completion_tokens": 256,
    "total_tokens": 298
  }
}

流式请求 (SSE)

curl -X POST https://gateway.api.internal/v1/chat/completions \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3-235b-a22b",
    "messages": [
      {"role": "user", "content": "讲个笑话"}
    ],
    "stream": true
  }'

// 响应 (SSE 流)
data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]}
data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"从前"},"finish_reason":null}]}
data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"有"},"finish_reason":null}]}
data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"个"},"finish_reason":null}]}
data: [DONE]

外部 Provider 路由

curl -X POST https://gateway.api.internal/v1/chat/completions \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o",
    "messages": [{"role": "user", "content": "Hello, world!"}]
  }'

// L4 内部将请求转换为 OpenAI API 格式并转发
// L4 将 OpenAI 的响应重新包装为标准格式返回给调用方

curl -X POST https://gateway.api.internal/v1/chat/completions \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-3.5-sonnet",
    "messages": [{"role": "user", "content": "介绍一下你自己"}]
  }'

// L4 内部通过协议适配器将请求从 OpenAI 格式转换为 Anthropic Messages API 格式
// 从 Anthropic 收到响应后,L4 再将响应转换回 OpenAI 兼容格式

错误响应格式

// 所有错误统一使用 OpenAI 兼容的错误格式
{
  "error": {
    "message": "Rate limit exceeded. Quota: 1000 RPM. Reset: 2026-06-02T10:00:00Z",
    "type": "rate_limit_error",
    "param": null,
    "code": "rate_limit_exceeded"
  }
}

// 常见错误码
// 400  Bad Request      — 请求参数错误 (invalid model, invalid messages)
// 401  Unauthorized    — API Key 无效或过期
// 403  Forbidden       — 无权限访问模型
// 429  Rate Limit      — 超出速率限制或配额上限
// 500  Internal Error  — 网关内部错误
// 502  Bad Gateway     — 上游 Provider 不可用
// 503  Service Unavailable — 熔断器打开

5. 智能路由引擎

L4 的路由引擎是网关最核心的组件,支持五种路由策略,可根据请求特征自动选择最优的模型和目标端点。路由决策在微秒级完成,不影响整体请求延迟。

5.1 精确匹配路由

基础 Exact Match Routing

根据 model 参数精确匹配已注册的模型 ID,经别名解析后路由到对应的部署端点。这是最直接的路由方式,适用于上层应用明确指定所需模型的场景。别名解析结果缓存在 L4 本地,TTL 可配置。

延迟: < 0.5ms 别名缓存: Redis + Local LRU 典型场景: 生产环境固定模型

5.2 负载均衡路由

均衡 Load Balancing Routing

当同一模型部署了多个实例(如多副本推理服务),L4 支持四种负载均衡算法,均匀分布请求流量:

算法原理适用场景特点
Least Connection 将请求分配给当前活跃连接数最少的实例 长连接场景,各请求处理时间差异大 自适应性强,避免请求堆积
Round Robin 按轮询顺序依次分配请求 实例规格均匀、请求处理时间相近 实现简单,无状态
Weighted 按权重比例分配,权重反映实例容量 异构实例混合部署(如 A100 8x 权重 vs 4x) 权重可基于 GPU 数量或显存动态调整
Adaptive 基于实时延迟数据,将请求发往当前 P50 延迟最低的实例 GPU 利用率不均、需要延迟优化 延迟窗口 30s,每 5s 更新一次排名

5.3 智能降级路由

高可用 Smart Fallback Routing

当主模型不可用时,L4 自动按配置的降级链切换到备用模型。降级链支持多级配置,每一级可以指定不同的模型和不同的 Provider。切换过程对调用方完全透明(响应头中增加 X-Fallback-Chain 标记)。

降级触发条件:主模型返回 5xx 错误、超时(可配置,默认 30s)、熔断器打开、或者主模型 P99 延迟超过阈值。链式降级支持回退(当备份 1 也失败时继续到备份 2),每一级可以设置独立的超时时间。

5.4 成本优化路由

成本 Cost-Optimized Routing

通过内置的复杂度分类器,自动估计输入问题的难度和复杂度,将简单查询路由到小型低成本模型,将复杂查询路由到高性能大模型。在保证响应质量的前提下显著降低推理成本。

复杂度等级判定条件路由目标成本对比
简单 单轮对话、简单问答、打招呼、信息查询 Qwen3-8B 或类似小模型 ≈ 1x
中等 多轮对话、知识问答、翻译、摘要、解释类 Qwen3-32B 或类似中等模型 ≈ 4x
复杂 数学推理、代码生成、逻辑分析、长文档理解 Qwen3-235B-A22B 或同级别大模型 ≈ 10x
高难度 专业领域深度分析、高级数学证明、复杂 Agent 调用 openai/gpt-4o 或 anthropic/claude-3.5-sonnet ≈ 30x

复杂度分类器基于以下特征判断:消息长度、轮数、是否包含代码、数学符号密度、关键词匹配等。分类器支持离线训练(基于历史请求日志)和在线自适应调整。

典型效果:企业客服场景中约 60% 的请求被分类为"简单",路由成本降低约 70%。

5.5 A/B 测试路由

实验 A/B Testing Routing

支持按百分比将流量分配到不同模型版本。每个 A/B 测试实验自动采集延迟、Token 用量、完成率等指标,支持可视化对比。适用于新模型版本上线前的灰度验证和生产环境逐步放量。

5%
灰度验证
25%
小范围放量
50%
半量验证
100%
全量发布

实验配置示例:

// A/B Test 配置 (存储在 L4 配置中心)
{
  "experiment_id": "ab-20260601-qwen-v1.2.0",
  "model": "qwen3-235b-a22b",
  "baseline_version": "v1.1.0",
  "candidate_version": "v1.2.0",
  "traffic_split": {
    "baseline": 70,   // 70% 流量到 v1.1.0
    "candidate": 30   // 30% 流量到 v1.2.0
  },
  "metrics_collection": {
    "ttft": true,
    "tpot": true,
    "completion_rate": true,
    "user_satisfaction": true   // 通过响应 header 跟踪
  },
  "duration": "7d",
  "auto_promote": {
    "enabled": true,
    "condition": "candidate.ttft < baseline.ttft * 1.1 && candidate.completion_rate > baseline.completion_rate"
  }
}

5.6 路由器配置 YAML 示例

# L4 模型网关 — 路由引擎主配置
# 文件路径: /etc/l4-gateway/routes.yaml

version: "v1"
gateway:
  name: "ai-platform-gateway"
  listen: ":8080"
  log_level: "info"

# ── 路由规则定义 ──
routes:

  # 规则 1: 精确匹配 — 生产环境固定模型
  - id: "exact-match-production"
    match:
      model: ["qwen3-235b-a22b", "qwen3-32b"]
      source: "production"
    action:
      type: "route"
      target: "internal"
      resolve_alias: true          # 解析 production 别名
      load_balancer:
        algorithm: "adaptive"      # adaptive | least_connection | round_robin | weighted
        window_seconds: 30
    fallback:
      - model: "deepseek-v2-chat"
        timeout_ms: 15000
      - model: "openai/gpt-4o-mini"
        timeout_ms: 20000

  # 规则 2: 负载均衡 — 多副本部署
  - id: "load-balanced-embedding"
    match:
      model: ["bge-m3-embedding", "text-embedding-v3"]
      type: "embedding"
    action:
      type: "route"
      target: "internal-embedding"
      load_balancer:
        algorithm: "least_connection"
    rate_limit:
      rpm: 6000
      burst: 200

  # 规则 3: 成本优化 — 按复杂度路由
  - id: "cost-optimized-chat"
    match:
      model: "router:cost-optimized:general-chat"
    action:
      type: "cost_optimized"
      classifier: "complexity-v2"
      tiers:
        - complexity: "simple"
          model: "qwen3-8b"
        - complexity: "medium"
          model: "qwen3-32b"
        - complexity: "complex"
          model: "qwen3-235b-a22b"
        - complexity: "expert"
          model: "openai/gpt-4o"
    metrics:
      collect: true
      export_path: "/metrics/routing"

  # 规则 4: 外部 Provider 路由
  - id: "external-provider"
    match:
      model_prefix: ["openai/", "anthropic/", "google/"]
    action:
      type: "route"
      target: "external"
      protocol_adapter: true      # 启用协议适配器
    circuit_breaker:
      enabled: true
      failure_threshold: 5
      timeout_ms: 30000
      half_open_after_ms: 60000
    timeout:
      request_ms: 60000
      connection_ms: 5000
      first_token_ms: 15000

  # 规则 5: A/B 测试
  - id: "ab-test-v1.2.0"
    match:
      model: "qwen3-235b-a22b"
      experiment: "ab-20260601-qwen-v1.2.0"
    action:
      type: "ab_test"
      baseline:
        version: "v1.1.0"
        weight: 70
      candidate:
        version: "v1.2.0"
        weight: 30
      metrics:
        - "ttft"
        - "tpot"
        - "completion_rate"

# ── 默认规则 ──
default_route:
  action:
    type: "route"
    target: "internal-fallback"
  fallback:
    - model: "qwen3-8b"
    - model: "openai/gpt-4o-mini"
    - cache: true

6. 外部 Provider 集成

L4 提供标准化的外部模型供应商集成框架。每个 Provider 通过协议适配器接入,适配器负责将 OpenAI 兼容请求转换为目标 Provider 的 API 格式,并将响应转换回 OpenAI 兼容格式。

6.1 供应商卡片

Claude 3.5 Sonnet · Claude 3.5 Haiku · Claude 3 Opus
  • 协议适配: Messages API → OpenAI
  • 支持 Stream / Thinking
  • 支持 Tool Use / Vision
GPT-4o · GPT-4o-mini · GPT-4-Turbo · o1-mini · o3-mini
  • 协议适配: 原生兼容, 透传
  • 支持 Stream / Vision
  • 支持 Function Calling
Gemini 1.5 Pro · Gemini 1.5 Flash · Gemini 2.0 Flash
  • 协议适配: Gemini API → OpenAI
  • 超长上下文 (1M tokens)
  • 支持多模态输入
通义千问-Max · 通义千问-Plus · 通义千问-Turbo · Qwen3 系列
  • 协议适配: 百炼 DashScope → OpenAI
  • 国内低延迟节点
  • 价优, 中文能力强
ERNIE-4.0 · ERNIE-3.5 · ERNIE-Speed · ERNIE-Lite
  • 协议适配: 千帆 API → OpenAI
  • 企业级安全合规
  • 文心系列模型
Doubao-pro-32k · Doubao-pro-128k · Doubao-lite
  • 协议适配: 火山引擎 → OpenAI
  • 超低延迟推理
  • 高性价比
DeepSeek-V2 · DeepSeek-Coder-V2 · DeepSeek-R1
  • 协议适配: DeepSeek API → OpenAI
  • 开源模型 API 版
  • 代码能力突出
Moonshot-v1-8K · Moonshot-v1-32K · Moonshot-v1-128K
  • 协议适配: Moonshot API → OpenAI
  • 超长上下文
  • 中文对话优化
GLM-4 · GLM-4-Plus · GLM-4-Air · GLM-4-Flash
  • 协议适配: 智谱 API → OpenAI
  • 开源闭源全系列
  • 国内合规中心部署
GPT-4o · GPT-4 · GPT-4-Turbo · Embedding-3
  • 协议适配: Azure OpenAI → OpenAI
  • 企业级 SLA 保障
  • 合规区域化部署

6.2 协议适配器架构

协议适配器 (Protocol Adapter) 是 L4 网关中负责将外部 Provider 的专有 API 协议转换为 OpenAI 兼容格式的核心组件。每个 Provider 都有独立的适配器实现,遵循统一的适配器接口规范。

协议适配器架构 — 将各 Provider 专有 API 统一转换为 OpenAI 兼容格式 请求到达 /v1/chat/completions 模型路由引擎 (模型 → Provider 映射) Anthropic Adapter OpenAI Req → Anthropic Messages API Anthropic Resp → OpenAI 格式 Stream: SSE-Anthropic → SSE-OpenAI OpenAI Adapter 原生兼容, 请求透传 响应格式校验和微调 支持所有 OpenAI 特性 Google Gemini Adapter OpenAI Req → Gemini API Gemini Resp → OpenAI 格式 多模态内容格式转换 阿里百炼 / 百度千帆 Adapter DashScope / Qianfan → OpenAI 国内专属 API 路由优化 DeepSeek / Moonshot / 智谱 Adapter 多 Provider 共享适配器框架 OpenAI 兼容度较高的 Provider 字节豆包 / Azure OpenAI Adapter 火山引擎 / Azure → OpenAI 企业级安全性合规集成 统一 OpenAI 格式响应

6.3 Provider 配置 YAML

# L4 模型网关 — 外部 Provider 配置
# 文件路径: /etc/l4-gateway/providers.yaml

version: "v1"

providers:

  # ── Provider: Anthropic ──
  - name: "anthropic"
    enabled: true
    base_url: "https://api.anthropic.com/v1"
    api_key:
      secret_ref: "kms://anthropic-api-key"   # 通过 KMS 引用加密密钥
    adapter: "anthropic"                       # 使用 Anthropic 适配器
    models:
      - id: "claude-3.5-sonnet"
        mapped_name: "claude-3-5-sonnet-20241022"
        features: ["stream", "thinking", "tool_use", "vision"]
      - id: "claude-3.5-haiku"
        mapped_name: "claude-3-5-haiku-20241022"
        features: ["stream", "tool_use"]
      - id: "claude-3-opus"
        mapped_name: "claude-3-opus-20240229"
        features: ["stream", "thinking", "vision"]
    timeout:
      request_ms: 120000
      first_token_ms: 30000
    circuit_breaker:
      failure_threshold: 10
      half_open_after_ms: 60000
    rate_limit:
      rpm: 500
      tpm: 200000

  # ── Provider: OpenAI ──
  - name: "openai"
    enabled: true
    base_url: "https://api.openai.com/v1"
    api_key:
      secret_ref: "kms://openai-api-key"
    adapter: "openai"                          # OpenAI 适配器 (原生兼容)
    models:
      - id: "gpt-4o"
        mapped_name: "gpt-4o-2024-11-20"
        features: ["stream", "vision", "function_calling", "json_mode"]
      - id: "gpt-4o-mini"
        mapped_name: "gpt-4o-mini-2024-07-18"
        features: ["stream", "vision", "function_calling"]
    timeout:
      request_ms: 60000
      first_token_ms: 15000
    circuit_breaker:
      failure_threshold: 5

  # ── Provider: 阿里百炼 (DashScope) ──
  - name: "alibaba-bailian"
    enabled: true
    base_url: "https://dashscope.aliyuncs.com/api/v1"
    api_key:
      secret_ref: "kms://dashscope-api-key"
    adapter: "dashscope"
    models:
      - id: "qwen-max"
        mapped_name: "qwen-max-2026-01-25"
        features: ["stream", "function_calling"]
      - id: "qwen-plus"
        mapped_name: "qwen-plus"
        features: ["stream"]
    timeout:
      request_ms: 120000
    rate_limit:
      rpm: 2000

  # ── Provider: 百度千帆 ──
  - name: "baidu-qianfan"
    enabled: true
    base_url: "https://aip.baidubce.com/rpc/2.0/ai_custom"
    api_key:
      secret_ref: "kms://qianfan-api-key"
    adapter: "qianfan"
    models:
      - id: "ernie-4.0"
        mapped_name: "ernie-4.0-8k"
        features: ["stream"]
      - id: "ernie-3.5"
        mapped_name: "ernie-3.5-8k"

  # ── Provider: Azure OpenAI ──
  - name: "azure-openai"
    enabled: true
    base_url: "https://${resource}.openai.azure.com/openai/deployments/${deployment}"
    api_key:
      secret_ref: "kms://azure-openai-key"
    adapter: "azure-openai"
    models:
      - id: "gpt-4o"
        deployment_name: "gpt-4o"
        api_version: "2024-10-01-preview"
      - id: "text-embedding-3-large"
        deployment_name: "text-embedding-3-large"
        api_version: "2024-10-01-preview"

7. 流量治理

L4 在推理请求的完整路径上实施了多层流量治理机制,确保网关在高负载、部分故障等异常场景下的稳定性和可用性。

7.1 限流

🔴 Token Bucket 算法

基于令牌桶算法实现突发流量平滑。桶容量和填充速率按维度(API Key / 用户 / 模型)独立配置。超出桶容量的请求直接返回 429。支持预热模式(冷启动时逐步增加速率)。

典型配置: 1000 RPM + 200 Burst

🔵 Sliding Window 算法

基于 Redis 有序集合实现滑动窗口限流,精确控制在时间窗口内的请求总数。支持 1s / 1min / 1h / 1d 级的窗口。每个请求的时间戳以毫秒精度记录在 Redis Sorted Set 中。

典型配置: 10000 RPD + 1000 RPM

🟢 多维限流

限流维度支持组合:API Key 级(防止单个用户滥用)、用户级(同一 Key 下多用户)、模型级(防止单个模型过载)、IP 级(防范 DDoS)。优先级从高到低依次检测。

优先级: API Key → User → Model → IP

🟡 配额管理

支持基于 Token 量的配额控制(TPM - Tokens Per Minute)。每个请求的 prompt + completion tokens 计费后扣除配额。可在管理控制台查看各 API Key 的实时配额使用情况。

配置: TPM + RPM + RPD 三级配额

7.2 熔断器

熔断器基于 Hystrix 模式实现,保护上游推理服务和外部 Provider 不被过载请求压垮。

1
Closed (正常)
2
失败次数 ≥ threshold (默认 5)
3
Open (熔断开启)
4
等待 half-open-ms (默认 60s)
5
Half-Open (放行试探)
6
成功? 回到 Closed / 失败? 回到 Open
# 熔断器配置示例
circuit_breaker:
  enabled: true
  # 熔断触发条件
  failure_threshold: 5                    # 连续失败 5 次触发熔断
  failure_rate_threshold: 0.5             # 或 50% 请求失败
  request_volume_threshold: 20            # 最少请求量阈值(防止低流量误触发)
  # 熔断行为
  timeout_ms: 30000                       # 请求超时计入熔断统计
  half_open_after_ms: 60000               # 60s 后进入半开状态
  # 半开试探
  half_open_max_requests: 3               # 半开状态最多放行 3 个请求试探
  # 滑动窗口
  sliding_window_size: 10                 # 统计最近 10 个请求
  sliding_window_ms: 60000                # 时间窗口 60s

7.3 降级链路

降级链路定义了请求在多个 Provider 之间的故障转移顺序。每一级可以配置不同的模型、Provider 和超时时间,支持链式和并行两种降级模式。

# 降级链路配置
fallback_chain:
  # 链式降级 (Primary → Backup 1 → Backup 2 → Cache → Default)
  strategy: "chain"
  levels:
    - name: "primary"
      type: "model"
      model: "qwen3-235b-a22b"
      timeout_ms: 30000
      conditions:                           # 触发降级的条件
        - "status_code >= 500"
        - "timeout"
        - "circuit_breaker_open"

    - name: "backup-1"
      type: "model"
      model: "deepseek-v2-chat"
      timeout_ms: 20000

    - name: "backup-2"
      type: "model"
      model: "openai/gpt-4o-mini"
      timeout_ms: 15000

    - name: "cache-stale"
      type: "cache"
      max_age: 3600                         # 最多使用 1h 前的缓存
      timeout_ms: 500

    - name: "default"
      type: "static"
      response: "抱歉,AI 推理服务暂时不可用,请稍后再试。"
      status_code: 503

7.4 超时控制

L4 支持三层超时控制,精确管理请求的每个阶段的时间预算。

超时类型说明默认值可配置范围
请求超时 (Request Timeout) 整个请求从开始到完成的超时时间,包含所有路由和重试 60s 5s – 600s
连接超时 (Connection Timeout) 建立与上游服务的 TCP 连接的超时时间 5s 1s – 30s
首 Token 超时 (First Token Timeout) 从请求发出到接收到第一个响应 Token 的超时时间。对于流式请求,首 Token 延迟反映了模型 Prefill 阶段耗时 15s 3s – 120s

7.5 请求队列

当请求超出瞬时处理能力时,L4 将请求放入优先级队列排队等待处理,而不是直接拒绝。

优先级说明典型场景队列超时
P0 / Critical 关键生产流量,优先处理 线上客户对话、实时推理 5s
P1 / High 重要业务流量 内部业务系统、质检 15s
P2 / Normal 常规流量 非实时分析、批量任务 60s
P3 / Low 低优先级流量 后处理、离线评测 300s

7.6 语义缓存

L4 集成了基于 GPTCache + Redis 的语义缓存系统,通过语义相似度匹配复用之前已缓存的结果,显著降低重复请求的延迟和成本。

📝
请求入站
原始请求 + messages
🧬
Embedding
请求转为向量
🎯
语义搜索
GPTCache 相似度匹配
Cache Hit
直接返回缓存结果
🗄️
Redis
缓存存储
# 语义缓存配置
semantic_cache:
  enabled: true

  # ── 缓存引擎 ──
  engine: "gptcache"
  embedding_model: "bge-m3-embedding"       # 用于计算语义相似度的 Embedding 模型
  similarity_threshold: 0.92                 # 语义相似度阈值, >= 0.92 视为命中
  max_cache_size: 50000                      # Redis 最大缓存条目数

  # ── 缓存范围 ──
  cacheable_models:                          # 仅对指定模型启用缓存
    - "qwen3-235b-a22b"
    - "qwen3-32b"
    - "openai/gpt-4o-mini"
  cacheable_temperature: [0, 0.1]            # 仅缓存低 temperature 的确定性请求
  max_input_length: 4096                     # 超过此长度的请求不缓存

  # ── 缓存策略 ──
  ttl:
    hits: 3600                               # 缓存命中后刷新 TTL
    default: 300                             # 默认缓存 TTL (5分钟)
    max: 86400                               # 最大缓存 TTL (24小时)

  # ── 精准缓存 (Exact Match) ──
  exact_match:
    enabled: true                            # 完全相同的请求直接命中 (绕过语义搜索)
    ttl: 3600                                # 精准匹配结果缓存 1h

  # ── 指标 ──
  metrics:
    hit_rate_threshold: 0.4                  # 目标命中率 ≥ 40%
语义缓存效果:在典型的对话场景中,语义缓存命中率可达 40%-60%。对于 FAQ、文档问答等高频重复请求的场景,命中率可超过 70%。缓存的平均命中延迟 < 50ms(包含 Embedding 计算时间),而一个完整的推理请求通常需要 1-10s,缓存命中可节省 95% 以上的响应时间。

8. 安全与认证

L4 是平台的安全边界,所有请求在路由前必须通过多层安全检测。安全模块包括认证授权、访问控制、内容安全和审计日志四个子模块。

8.1 API Key 认证

所有请求必须携带有效的 API Key。L4 支持标准 Bearer Token 方式和 HMAC 签名两种认证方式。

# ── Bearer Token (标准方式) ──
curl -X POST https://gateway.api.internal/v1/chat/completions \
  -H "Authorization: Bearer sk-proj-xxxxxxxxxxxx" \
  ...

# ── HMAC 签名认证 (安全增强) ──
# 请求头:
#   X-Api-Key:      sk-xxxxxxxx         # API Key ID
#   X-Timestamp:    2026-06-02T10:00:00Z # 请求时间戳 (防重放)
#   X-Nonce:        3a7f...e9b2         # 随机数 (防重放)
#   X-Signature:    ...                  # HMAC-SHA256 签名
#
# 签名计算: HMAC-SHA256(secret, method + path + timestamp + nonce + body)

curl -X POST https://gateway.api.internal/v1/chat/completions \
  -H "X-Api-Key: sk-proj-xxxxxxxx" \
  -H "X-Timestamp: 2026-06-02T10:00:00Z" \
  -H "X-Nonce: 3a7f9c2e1b5d8f4a6c0e" \
  -H "X-Signature: e4a5f8c7d9b2a1e3f6c0d8b7a4e9f2c1d5a6b3c8e7f0d9a2b4c6e1f7a3d5b9" \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3-235b-a22b","messages":[{"role":"user","content":"hello"}]}'

8.2 OAuth 2.0 / OIDC 企业 SSO

支持通过 OAuth 2.0 和 OpenID Connect 协议与企业的统一身份认证系统集成,适用于企业级内部使用场景。

# OAuth 2.0 配置
oauth:
  enabled: true
  providers:
    - name: "company-sso"
      type: "oidc"                                  # OIDC
      issuer_url: "https://sso.company.com/oidc"
      client_id: "l4-gateway"
      client_secret:
        secret_ref: "kms://oidc-client-secret"
      scopes: ["openid", "profile", "email"]
      role_mapping:                                  # 从 OIDC claim 映射角色
        roles_claim: "application_roles"
        mapping:
          - role: "admin"
            permissions: ["*"]
          - role: "developer"
            permissions: ["chat:write", "embedding:write"]
          - role: "viewer"
            permissions: ["chat:read"]

8.3 模型级访问控制

L4 支持细粒度的模型级访问权限控制,可以精确到每个 API Key 允许访问的模型列表。

// API Key 权限配置示例
{
  "api_key_id": "sk-proj-xxxxxxxx",
  "owner": "finance-team",
  "permissions": {
    "allowed_models": [
      "qwen3-235b-a22b",
      "qwen3-32b",
      "openai/gpt-4o",
      "router:cost-optimized:general-chat"
    ],
    "denied_models": [
      "openai/gpt-4o"     // 即使在上面的列表中, 也被拒绝
    ],
    "rate_limits": {
      "rpm": 1000,
      "tpm": 50000,
      "rpd": 50000
    },
    "allowed_endpoints": [
      "/v1/chat/completions",
      "/v1/embeddings"
    ]
  },
  "effective_at": "2026-06-01T00:00:00Z",
  "expires_at": "2026-12-31T23:59:59Z"
}

8.4 内容安全

L4 在请求进入和响应返回两个阶段分别执行内容安全检查,确保进出平台的推理内容符合安全规范。

检测点检测内容检测方式违规处理
输入过滤 用户发送的 prompt 内容 正则 + 关键词 + NLP 分类模型 + 敏感词库 拦截并返回 400 含违规详情
输出审核 模型生成的 response 内容 实时规则引擎 + 异步 LLM 审核 实时: 截断 + 替换; 异步: 记录审计 + 通知
提示注入检测 检测越狱 (Jailbreak) 和提示注入 (Prompt Injection) 攻击 专用检测模型 + 规则模式库 拦截请求, 记录告警
敏感信息检测 检测个人身份信息 (PII)、银行卡号、身份证号等 正则 + NLP 实体识别 自动脱敏 (Masking) 后放行

8.5 审计日志

所有请求和响应的关键信息通过异步管道记录到审计日志系统,支持合规审计和安全事件溯源。

// 审计日志记录格式 (JSON, 异步写入 ELK/Loki)
{
  "audit_id": "aud-20260602-001-xxxxx",
  "timestamp": "2026-06-02T10:30:00.123Z",
  "request": {
    "method": "POST",
    "path": "/v1/chat/completions",
    "model": "qwen3-235b-a22b",
    "api_key_hash": "sha256:a3f7...e9b2",       // API Key 哈希 (不记录原始 Key)
    "user_id": "user-finance-001",               // 如果启用了用户认证
    "source_ip": "10.0.1.100",
    "user_agent": "OpenAI-Python-Client/1.30.0",
    "prompt_tokens": 42,
    "prompt_length": 156,
    "messages_count": 2,
    "content_types": ["text"],
    "has_images": false
  },
  "response": {
    "status_code": 200,
    "completion_tokens": 256,
    "total_tokens": 298,
    "ttft_ms": 180,
    "total_latency_ms": 3450,
    "model_used": "qwen3-235b-a22b",        // 实际路由到的模型
    "provider": "internal",                       // internal | openai | anthropic | ...
    "cache_hit": false,
    "fallback_chain_used": null,
    "router_strategy": "exact_match"
  },
  "security": {
    "content_filter_passed": true,
    "pii_detected": false,
    "prompt_injection_detected": false
  },
  "cost": {
    "estimated_cost_usd": 0.0012
  }
}

// 审计配置: 每 500ms 或 1000 条记录批量写入
// 敏感字段 (完整 messages 内容) 仅在必要且授权的情况下记录
// 默认 messages 只记录 token 数量和类型, 不记录原文
安全注意事项:所有外部 Provider 的 API Key 存储在内部 KMS (密钥管理服务) 中,L4 配置文件中仅引用 KMS 密钥路径,不存储明文。审计日志默认不记录完整的请求/响应内容,仅在合规审查时通过专门授权接口临时开启完整记录。

9. 网关性能指标

L4 模型网关作为平台模型推理的统一入口,在引入丰富功能的同时严格控制附加延迟。以下是网关自身的性能指标目标。

< 5ms
网关附加延迟 P50
额外延迟 (不含推理时间)
< 15ms
网关附加延迟 P99
额外延迟 (不含推理时间)
< 1ms
路由决策延迟
路由引擎决策时间
99.99%
网关可用性
月可用性 SLA
10K+
QPS 吞吐
单网关实例
< 100ms
缓存命中延迟
语义缓存命中响应时间
指标SLISLO测量方式
网关附加延迟 P50 / P99 网关处理时间 (总延迟 − 上游推理时间) P50 < 5ms · P99 < 15ms Prometheus Histogram
路由决策延迟 路由引擎从接收请求到输出目标端点的耗时 P99 < 1ms Micrometer Timer
API 可用性 健康检查端点 /health 的 HTTP 200 响应率 ≥ 99.99% 月度监控 (Prometheus + Blackbox Exporter)
错误率 非 429 的 5xx 错误占总请求比例 < 0.1% Prometheus Counter
语义缓存命中率 缓存命中请求数 / 总请求数 ≥ 40% GPTCache Metrics
缓存命中延迟 从请求入站到返回缓存结果的 P99 耗时 < 100ms Prometheus Histogram
限流准确度 限流器实际通过量 / 配置配额 ±5% Redis Counter 校验
认证延迟 API Key 验证 + 权限检查耗时 P99 < 2ms Micrometer Timer
熔断恢复时间 熔断器从 Open 到 Half-Open 再到 Closed 的时间 < 90s 熔断器状态监控
审计日志投递延迟 请求完成到审计日志写入存储的延迟 P99 < 5s Kafka Lag + 日志写入时间
性能保障措施:L4 网关采用无状态设计,支持水平扩展。路由表缓存在本地 LRU Cache 中,路由决策无需跨进程通信。限流计数器基于 Redis Pipeline 批量操作,单次限流检查耗时 < 0.1ms。语义缓存的 Embedding 计算在独立的 GPU 实例上异步执行,不阻塞主请求路径。

10. API 规范

L4 模型网关对外暴露的所有端点。所有端点遵循 OpenAI 兼容格式,支持标准 OpenAI SDK 和 HTTP 客户端直接访问。

核心推理端点

POST/v1/chat/completions对话补全 (核心端点, 支持流式和非流式)
POST/v1/completions文本补全 (兼容 OpenAI Legacy 格式)
POST/v1/embeddings文本向量化
POST/v1/audio/transcriptions语音转文字 (基于 Whisper 或其他 ASR)
POST/v1/audio/translations语音翻译 (转写+翻译为英语)
POST/v1/audio/speech文字转语音 (TTS)
POST/v1/images/generations图像生成 (基于 Stable Diffusion / DALL-E)
POST/v1/images/edits图像编辑
POST/v1/moderations内容审核

模型查询端点

GET/v1/models列出当前可用模型列表
GET/v1/models/{model}获取模型详情 (能力元数据)

管理端点

GET/health健康检查
GET/ready就绪检查
GET/metricsPrometheus 指标暴露
GET/v1/dashboard/usage获取当前用量统计

Chat Completions 请求 Schema

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer sk-xxxxxxxx

{
  // ── 必需 ──
  "model": "qwen3-235b-a22b",             // 模型 ID (支持各种指定方式)
  "messages": [                                 // 消息列表
    {"role": "system", "content": "你是一个助手。"},
    {"role": "user", "content": "你好"}
  ],

  // ── 生成参数 ──
  "temperature": 0.7,                           // 温度 (0-2, 默认 1)
  "top_p": 0.9,                                 // Top-P 采样 (0-1, 默认 1)
  "max_tokens": 4096,                           // 最大生成 Token 数
  "stop": ["\n\n"],                             // 停止词
  "frequency_penalty": 0,                       // 频率惩罚 (-2 到 2)
  "presence_penalty": 0,                        // 存在惩罚 (-2 到 2)
  "seed": 42,                                   // 随机种子 (确定性生成)

  // ── 流式 ──
  "stream": false,                              // 是否 SSE 流式返回

  // ── 高级功能 ──
  "tools": [                                    // Tool/Function Calling
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "获取天气信息",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {"type": "string"}
          },
          "required": ["location"]
        }
      }
    }
  ],
  "tool_choice": "auto",                        // none | auto | required | {"type":"function","function":{"name":"..."}}

  // ── 响应格式 ──
  "response_format": {
    "type": "json_object"                       // text | json_object
  },

  // ── L4 扩展参数 ──
  "x_l4": {
    "routing_strategy": "cost_optimized",       // 覆盖默认路由策略
    "experiment_id": "ab-20260601",             // A/B 测试 ID
    "cache_enabled": true,                      // 是否启用语义缓存
    "timeout_ms": 30000,                        // 覆盖请求超时
    "tags": {                                   // 自定义标签 (用于审计和计费)
      "project": "finance-qa",
      "environment": "production"
    }
  }
}

// 响应 Schema
{
  "id": "chatcmpl-9a8b7c6d5e4f3a2b1c0d",
  "object": "chat.completion",
  "created": 1717000000,
  "model": "qwen3-235b-a22b",              // 实际使用的模型 (可能与请求不同)
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "你好!有什么可以帮助你的吗?"
      },
      "finish_reason": "stop"                    // stop | length | content_filter | tool_calls
    }
  ],
  "usage": {
    "prompt_tokens": 42,
    "completion_tokens": 15,
    "total_tokens": 57
  },
  // L4 扩展响应头 (以 X-L4- 开头的响应头)
  "x_l4": {
    "provider": "internal",                      // 实际路由到的 Provider
    "cache_hit": false,                          // 是否缓存命中
    "fallback_chain_used": null,                 // 是否触发了降级链
    "routing_strategy": "exact_match",           // 实际使用的路由策略
    "latency_ms": 2850                           // 网关总处理时间
  }
}

11. 技术选型

以下表格列出了 L4 层的技术组件选型、版本和选型理由。核心决策是选择自建模型网关而非现成的 LiteLLM 方案,以获得更大的定制灵活性。

领域选型版本备选选型理由
核心网关引擎 自建 Go 网关 (基于 Gin + 定制中间件) LiteLLM · Kong · APISIX 自建网关可根据平台七层架构深度定制路由逻辑和协议适配器;Go 语言性能优异,单机 QPS 10K+;路由引擎可精确控制每微秒延迟。LiteLLM 虽然开箱即用但无法满足复杂的路由策略和内部模型调度需求。
缓存 (限流/路由表) Redis Cluster 7.2+ Memcached · Redpanda Redis 的计数器 (INCR) 和有序集合 (ZADD) 原生支持限流算法;Pub/Sub 支持 L3 路由表变更通知;Pipeline 批量操作降低延迟;Cluster 模式支持水平扩展。
语义缓存 GPTCache + Redis 0.3+ RedisVL · Milvus GPTCache 专门为 LLM 语义缓存设计;支持 embedding 相似度匹配、TTL 管理、精准匹配回退;与 Redis 原生集成;轻量级,无需额外部署向量数据库。
API 网关 (流量入口) Kong / APISIX Kong 3.6+ / APISIX 3.8+ Nginx · Envoy 作为 L4 网关的前置流量入口,负责 TLS 终止、域名路由、基础的 IP 黑白名单和 DDoS 防护。Kong 和 APISIX 均支持丰富的插件生态。APISIX 在性能上略胜,Kong 生态更成熟。
认证 / 授权 自建认证服务 + KMS Keycloak · Auth0 API Key 发行和验证自建轻量服务;API Key 哈希存储 + HMAC 签名验证;KMS (HashiCorp Vault / 阿里云 KMS) 存储 Provider API Key 密钥。
限流引擎 自建 (基于 Redis) Kong Rate Limiting 插件 需要细粒度的多维限流 (API Key + User + Model + IP),Kong 插件无法满足。自建实现 Token Bucket + Sliding Window 双算法。
熔断器 自建 (Hystrix 模式) Resilience4j · Hystrix Go 语言生态中的熔断器库 (如 gobreaker) 提供基本功能。自建实现以更好地与路由引擎集成,支持 Provider 级和模型级熔断。
可观测性 Prometheus + Grafana + OpenTelemetry Prometheus 2.52+ Datadog · Elastic APM Go 应用通过 Prometheus client 暴露指标;OpenTelemetry 实现分布式追踪,追踪请求从 L5 到 L4 到 Provider 的全链路。
审计日志 Kafka + ELK / Loki Kafka 3.6+ 直接写 Elasticsearch Kafka 作为审计日志缓冲队列,削峰填谷;ELK 用于存储和检索;与平台已有日志基础设施复用;支持审计日志的归档和合规保留。
请求 ID 追踪 OpenTelemetry + 自定义 Trace ID 每个请求生成唯一 Trace ID,贯穿 L5 → L4 → Provider → L4 → L5 完整路径;在响应头中透传 x-request-id 供客户端排查问题。
配置管理 etcd / 配置文件 3.5+ Consul · Nacos 路由规则、Provider 配置、限流配额等动态配置通过 etcd 热更新,无需重启网关。静态配置 (Provider API Key 路径) 使用本地 YAML 加载。
协议适配器 自建适配器框架 (Go 插件模式) LiteLLM 内置适配器 每个 Provider 独立适配器实现,插件化加载;支持热插拔新增 Provider。适配器接口统一: OpenAI Request → Provider Request → Provider Response → OpenAI Response。
选型决策说明:
  • 自建 vs. LiteLLM:LiteLLM 提供了 100+ Provider 的适配器,但在复杂路由策略 (成本优化、A/B 测试、自适应负载均衡) 和深度定制方面不足。自建网关可完全控制路由逻辑、协议转换和性能优化。投入成本约 4 人月完成核心功能。
  • Kong/APISIX 作为前置 vs. 自建做全部:复用 Kong/APISIX 的成熟 TLS 终止、域名路由、基础限流能力,自建网关专注模型路由和协议适配。职责分离,各司其职。
  • GPTCache vs. 通用向量数据库:GPTCache 专为 LLM 缓存场景设计,语义缓存命中延迟 < 100ms,引入通用向量数据库 (Milvus 等) 会增加 10-50ms 的查询延迟且需要额外运维。
  • Redis Cluster vs. 单机 Redis:网关作为平台入口,Redis 是限流和路由缓存的核心依赖。Cluster 模式保障高可用,避免单点故障导致网关不可用。