大模型推理网关与成本治理架构：日均亿级Token的流量治理

一、业务全景：日均亿Token的真实痛点

1.1 业务背景与规模

随着大语言模型在企业内部的深度渗透，一个不可回避的事实摆在面前：Token就是新的API调用——而且更贵。我们所服务的AI原生平台，日均承载超过 1.2亿Token 的推理吞吐，覆盖智能客服、文档摘要、代码助手、数据查询、营销文案、知识问答等20+业务场景，接入GPT-4o、Claude-3.5、DeepSeek-V3、Qwen-Max等12个模型版本。当模型调用从"实验性验证"走向"生产级规模"，一个根本性的矛盾浮出水面：业务侧要的是能力与体验，平台侧要的是成本与稳定，而传统API网关对此几乎束手无策。

这不仅仅是一个技术问题，更是一个运营问题。在传统软件架构中，云计算资源的边际成本几乎可以忽略——多一个请求不过是多消耗一点点CPU。但LLM推理的边际成本是线性的：每多一个Token就意味着多一份与模型供应商的结算账单。这种"用多少付多少"的模式，让成本控制和流量治理变成了架构的核心命题，而非边缘优化。

1.2 传统网关为何失灵

在LLM推理场景下，传统API网关的核心假设被逐一打破。传统网关处理的是"请求-响应"范式——一个HTTP调用进来，转发到后端，拿到完整响应后返回。但LLM推理有三个本质差异导致传统模型完全不适配：

• 流式输出打破了请求-响应的原子性：SSE（Server-Sent Events）意味着一个推理请求可能持续数十秒、产出数百个Token Chunk，传统网关的连接管理和超时控制完全不适配
• Token是成本单位而非调用次数：同样一个API请求，输入100 Token和输入10000 Token的成本差10倍，传统网关的计费和限流模型建立在"调用次数"维度，无法刻画真正的资源消耗
• 模型能力是异构的：不同模型在推理、代码、多语言等维度能力差异极大，简单轮询或加权路由会导致"用大炮打蚊子"——高成本模型处理简单问题，或"用尺子量宇宙"——低成本模型扛不住复杂推理

更致命的是成本透明度的缺失。某月财务对账时发现：代码助手场景仅占调用量8%，却消耗了35%的Token预算——因为GPT-4o被无差别路由到了所有代码查询，包括大量模板化的格式化任务。这类"成本黑洞"在没有Token粒度监控的情况下几乎不可能被发现。

问题的深层根源在于：传统网关的治理维度是"请求"，而LLM的治理维度必须是"Token"。请求是无差别的计数单位，Token才是有差别的成本单位。这个认知转换，驱动了我们从零构建一个全新的LLM推理网关。

1.3 核心架构决策

面对上述痛点，我们做出了一系列架构层面的根本性决策，而非在传统网关上打补丁。这些决策在当时都引发了团队内部的激烈争论，但最终被生产数据证明是正确的：

下图展示了LLM推理网关在整个系统中的定位——它是传统API网关与下游模型服务之间的"智能中间层"：

┌─────────────────────────────────────────────────────────────────────────────┐
│                          客户端 / 业务应用层                                 │
│   ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐              │
│   │智能  │  │文档  │  │代码  │  │数据  │  │营销  │  │知识  │              │
│   │客服  │  │摘要  │  │助手  │  │查询  │  │文案  │  │问答  │              │
│   └──┬───┘  └──┬───┘  └──┬───┘  └──┬───┘  └──┬───┘  └──┬───┘              │
│      └─────────┴─────────┴─────────┴─────────┴─────────┘                  │
│                              │ 统一LLM SDK                                  │
│                              │ · 自动重试 + 指数退避                        │
│                              │ · 模型降级透明切换                            │
│                              │ · 客户端Token计数 + 预警                      │
└──────────────────────────────┼─────────────────────────────────────────────┘
                               ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                     传统 API 网关 (Nginx / Kong)                             │
│       认证鉴权 · 协议转换 · 全局负载均衡 · SSL终结 · 请求路由                 │
│       注：只做"网络层"治理，不感知Token和语义                                  │
└──────────────────────────────┼─────────────────────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│              ★ LLM 推理网关 (本文核心) ★                                     │
│                                                                             │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐         │
│  │语义缓存 │→│智能路由  │→│Token预算 │→│限流降级  │→│安全护栏  │         │
│  │Semantic │  │Smart    │  │Budget   │  │Rate     │  │Safety   │         │
│  │Cache    │  │Router   │  │Engine   │  │Limiter  │  │Guard    │         │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘         │
│       │            │            │             │            │               │
│       ▼            ▼            ▼             ▼            ▼               │
│  ┌─────────────────────────────────────────────────────────────────┐       │
│  │                  控制面 (Python Services)                         │       │
│  │  · 缓存向量索引(Qdrant)  · 路由策略引擎    · 预算核算服务        │       │
│  │  · 模型能力画像          · 灰度实验平台    · 内容审核服务        │       │
│  │  · 成本归因分析          · 复杂度评估器    · PII实体识别          │       │
│  └─────────────────────────────────────────────────────────────────┘       │
│                                                                             │
│  ┌─────────────────────────────────────────────────────────────────┐       │
│  │                  数据面基础设施                                    │       │
│  │  · Redis Cluster(预算计数/限流/会话) · Kafka(审计日志/指标)       │       │
│  │  · Consul(模型服务发现)            · Prometheus+Grafana(监控)     │       │
│  │  · Jaeger(分布式追踪)              · MinIO(审计归档)              │       │
│  └─────────────────────────────────────────────────────────────────┘       │
└──────────────────────────────┼─────────────────────────────────────────────┘
                               │
          ┌────────────────────┼────────────────────┐
          ▼                    ▼                    ▼
 ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
 │  GPT-4o 集群  │    │DeepSeek-V3   │    │  Qwen-Max    │    ...
 │  (强推理)     │    │  (性价比)     │    │  (中文优化)   │
 │  ¥60/M Token │    │  ¥8/M Token  │    │  ¥20/M Token │
 └──────────────┘    └──────────────┘    └──────────────┘
        

二、模型智能路由：能力感知与成本感知的双因子决策

2.1 路由问题的本质

模型路由不是简单的负载均衡。一个用户问"帮我把这段Java代码翻译成Python"，和一个用户问"证明黎曼猜想的最新进展"，对模型能力的需求天差地别——但它们可能来自同一个API Key、同一个业务场景。路由决策必须在 请求级别 做出判断，而非依赖静态的规则映射。

我们将路由问题形式化为一个双目标优化：在满足能力约束（模型对当前请求的解决能力不低于阈值）的前提下，最小化成本函数（预期Token消耗 × 单价）。这不是一个简单的排序问题，因为能力评估本身是非确定性的——我们需要在不调用模型的情况下预判"这个请求需要多强的模型"。

更深层的问题是：能力评估的"足够好"标准本身就是模糊的。一个代码格式化任务，GPT-4o能做到96%准确率，Qwen-Turbo也能做到89%——7%的差异是否值得7.5倍的价格差异？这取决于业务容忍度，而业务容忍度不是一个纯技术决策。因此，我们的路由系统本质上是一个参数化的决策框架，能力阈值和成本权重都可以按场景配置。

2.2 能力感知分层路由

我们的路由架构分为三层，每层逐步缩小候选集，最终收敛到最优模型。三层设计的核心思想是"粗筛+精排"——先以最低成本排除明显不适配的模型，再在候选集内做精细化的成本决策。

请求输入
   │
   ▼
┌──────────────────────────────────────────────────────────────┐
│ 第一层：场景分流（Scene Classification）                       │
│                                                               │
│ 通过请求标签提取意图通道                                        │
│ 分入：代码/推理/翻译/摘要/闲聊 等通道                            │
│                                                               │
│ 每个通道维护自己的候选模型集合                                   │
│ 例：代码通道 → [GPT-4o, Claude-3.5, DeepSeek]                │
│     闲聊通道 → [Qwen-Turbo, DeepSeek-Lite]                   │
│                                                               │
│ 实现：Socket ID + intent_tag → 通道映射表                       │
│ 延迟：<0.1ms (内存查找)                                        │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│ 第二层：复杂度评估（Complexity Scoring）                        │
│                                                               │
│ 轻量级评估器（非LLM调用，延迟 < 2ms）：                         │
│                                                               │
│ 输入特征向量：                                                 │
│   · 输入Token长度（归一化到0~1）                                │
│   · 关键词密度向量（TF-IDF提取，10维）                           │
│   · 历史对话轮次（0表示首轮，最大10轮截断）                      │
│   · 业务特征位码（是否含代码/表格/公式/多语言标记）              │
│   · 用户历史复杂度均值（滑动窗口，最近50次请求）                 │
│                                                               │
│ 模型：XGBoost，100棵树，深度6                                  │
│ 标注数据：10万条人工标注（含3轮交叉校验）                       │
│ 输出：复杂度评分 0~1                                           │
│ 分级准确率：83%（3级分类：低/中/高）                            │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│ 第三层：成本感知决策（Cost-Aware Selection）                    │
│                                                               │
│ Step 1：按复杂度评分过滤候选模型                                │
│   · 评分 > 0.7 → 仅保留强推理模型（能力评分>0.8的模型）        │
│   · 评分 0.3~0.7 → 中等模型优先（能力评分0.5~0.8）             │
│   · 评分 < 0.3 → 轻量模型即可（能力评分>0.3）                  │
│                                                               │
│ Step 2：在符合能力阈值的模型中计算预估成本                      │
│   预估成本 = est_output_tokens × model_price_per_1k           │
│   est_output_tokens = f(input_tokens, scene, complexity)      │
│   （输出Token预估同样使用场景化模型，误差<20%）                 │
│                                                               │
│ Step 3：选择预估成本最低的模型                                  │
│   如果多个模型成本差异<10%，选择当前负载最低的（稳定性优先）     │
└──────────────────────────────────────────────────────────────┘
        

复杂度评估器是整个路由的关键。它必须在极低延迟（< 2ms）内给出评估，因此不能调用LLM。我们训练了一个基于XGBoost的轻量分类器，在离线标注的10万条样本上达到了 83%的分级准确率。模型每周自动重训一次，使用过去7天的线上标注数据（用户反馈+人工抽检）来适应新的分布漂移。

2.3 路由策略的权衡与演进

路由策略并非一蹴而就。我们经历了三个演进阶段，每个阶段都伴随着明确的取舍：

2.4 模型能力画像的构建与维护

路由决策依赖"模型能力评分"，这个评分不是一个静态数字，而是一个多维度的动态画像。每个模型在每个场景下有不同的能力向量：

模型能力画像示例：

GPT-4o 能力向量：
┌─────────────────────────────────────────────┐
│ 维度         │ 评分  │ 置信区间  │ 样本量   │
│ 中文理解     │ 0.94  │ ±0.02    │ 12,000  │
│ 代码生成     │ 0.96  │ ±0.01    │ 8,500   │
│ 数学推理     │ 0.92  │ ±0.03    │ 3,200   │
│ 多语言翻译   │ 0.88  │ ±0.04    │ 1,800   │
│ 创意写作     │ 0.91  │ ±0.02    │ 5,000   │
│ 指令遵循     │ 0.95  │ ±0.01    │ 15,000  │
│ 幻觉率       │ 0.04  │ ±0.01    │ 10,000  │
│ 单价(元/MT)  │ 60.0  │ -        │ -       │
└─────────────────────────────────────────────┘

DeepSeek-V3 能力向量：
┌─────────────────────────────────────────────┐
│ 维度         │ 评分  │ 置信区间  │ 样本量   │
│ 中文理解     │ 0.91  │ ±0.02    │ 15,000  │
│ 代码生成     │ 0.93  │ ±0.02    │ 10,200  │
│ 数学推理     │ 0.89  │ ±0.03    │ 4,000   │
│ 多语言翻译   │ 0.82  │ ±0.05    │ 1,200   │
│ 创意写作     │ 0.85  │ ±0.03    │ 3,500   │
│ 指令遵循     │ 0.90  │ ±0.02    │ 12,000  │
│ 幻觉率       │ 0.06  │ ±0.02    │ 8,000   │
│ 单价(元/MT)  │ 8.0   │ -        │ -       │
└─────────────────────────────────────────────┘
        

能力画像的数据来源有三：(1) 人工评测benchmark——每月跑一次标准化测试集；(2) 线上A/B对比——灰度期间的采样比对；(3) 用户隐式反馈——采纳率、修改率、满意度评分。三者加权融合，时间衰减窗口30天，确保画像跟得上模型版本的迭代速度。

路由决策的Mermaid流程图：

graph TD
    A[/请求进入/] --> B[/场景标签解析/]
    B --> C{场景通道匹配}
    C -->|代码| D1[/代码通道候选集/]
    C -->|推理| D2[/推理通道候选集/]
    C -->|通用| D3[/通用通道候选集/]
    D1 --> E[/XGBoost复杂度评分/]
    D2 --> E
    D3 --> E
    E --> F{评分阈值判断}
    F -->|高复杂度>0.7| G[/保留能力评分>0.8的模型/]
    F -->|中复杂度| H[/保留能力评分0.5~0.8的模型/]
    F -->|低复杂度<0.3| I[/保留能力评分>0.3的模型/]
    G --> J[/预估输出Token×单价排序/]
    H --> J
    I --> J
    J --> K{成本差异<10%?}
    K -->|是| L[/选择负载最低的模型/]
    K -->|否| M[/选择成本最低的模型/]
    L --> N[/转发推理请求/]
    M --> N
        

三、Token预算引擎：请求级→用户级→租户级三级成本管控

3.1 为什么需要Token预算

LLM推理的成本爆炸是一个指数级问题。一个失控的循环调用、一个精心构造的超长上下文攻击、或者仅仅是业务方的一次需求变更，都可能在数小时内烧掉数万元Token费用。我们见过最极端的案例：某业务方在凌晨部署了一个带自动重试的批量翻译脚本，3小时消耗了 2800万Token，直接触发账单告警。由于没有预算上限机制，直到财务在次日出账时才被发现。

Token预算引擎的设计目标不是"限制使用"，而是让成本可控地释放业务价值。类比金融体系中的风控机制——银行不会因为风控而不放贷，而是在风险可控的前提下最大化信贷规模。同样，预算引擎的使命是让"每一Token都花在刀刃上"，而非简单地"少花Token"。

更重要的是，预算引擎为成本谈判提供了数据锚点。当业务方抱怨"Token不够用"时，我们不再是模糊地说"你们用得太多了"，而是拿出精确到用户、到场景、到时间段的Token消耗明细。数据驱动对话，远比情绪驱动对话有效。

3.2 三级预算体系架构

预算管控必须在不同粒度上生效，否则要么管太粗（租户级限额导致个体饥饿），要么管太细（请求级限制导致正常业务受挫）。我们设计了三级漏斗模型，每级有独立的预算额度和超限策略：

┌──────────────────────────────────────────────────────────────────┐
│                     租户级预算 (Tenant Budget)                    │
│                                                                  │
│  粒度：企业租户 / 月度额度                                        │
│  作用：硬上限，超过即熔断，拒绝该租户所有请求                       │
│  存储位置：Redis (tenant:{id}:budget:monthly)                     │
│  更新频率：实时预扣 + 5秒异步结算                                  │
│  示例：租户A本月Token预算 = 5亿Token                              │
│  告警阈值：80% / 90% / 95% 三级告警                               │
│                                                                  │
│  ┌────────────────────────────────────────────────────────┐     │
│  │              用户级预算 (User Budget)                     │     │
│  │                                                          │     │
│  │  粒度：用户ID / 日度额度                                  │     │
│  │  作用：防止单用户过度消耗，超出则降级                      │     │
│  │  存储位置：Redis (user:{id}:budget:daily)                 │     │
│  │  示例：用户U12345 今日Token额度 = 50万Token              │     │
│  │  特殊处理：VIP用户额度为普通用户的5倍，且不参与模型降级    │     │
│  │                                                          │     │
│  │  ┌──────────────────────────────────────────────────┐   │     │
│  │  │          请求级预算 (Request Budget)                │   │     │
│  │  │                                                    │   │     │
│  │  │  粒度：单次推理请求                                  │   │     │
│  │  │  作用：防超长输出、防循环生成、防上下文膨胀           │   │     │
│  │  │  来源：业务SDK传入 / 网关默认值 / 场景配置            │   │     │
│  │  │  示例：本请求最大输出Token = 4096                    │   │     │
│  │  │                                                    │   │     │
│  │  │  执行方式：                                         │   │     │
│  │  │  · 输入Token计数 → 超上限直接拒绝(400)               │   │     │
│  │  │  · 输出Token实时计数 → 达上限截断并标记              │   │     │
│  │  │  · 流式：每Chunk计数，超限发结束标记                 │   │     │
│  │  └──────────────────────────────────────────────────┘   │     │
│  └────────────────────────────────────────────────────────┘     │
└──────────────────────────────────────────────────────────────────┘

三级预算的拦截流程：
请求 → 请求级校验(输入Token超限?) → 用户级预扣(日额度不足?) → 租户级预扣(月额度不足?)
       ↓ 拒绝(400)              ↓ 降级/排队              ↓ 熔断(429)
       通过                     通过                     通过 → 进入推理管线
        

3.3 预扣+结算机制

三级预算之间通过预扣+结算机制协同工作，避免分布式计数的不一致问题。这是整个预算引擎中最精巧的部分——既要在毫秒级完成三级锁定，又要在推理完成后准确结算差额。

预扣+结算时序：

时间线 ─────────────────────────────────────────────────────→

请求入口        推理执行中          推理完成          异步结算
  │                │                  │                │
  ▼                ▼                  ▼                ▼
┌───────┐     ┌───────────┐     ┌──────────┐     ┌───────────┐
│Redis  │     │模型推理    │     │实际Token │     │异步Worker │
│Lua脚本│     │流式输出    │     │计数完成   │     │结算差额   │
│原子操作│     │各Chunk计数 │     │          │     │           │
└───┬───┘     └───────────┘     └────┬─────┘     └─────┬─────┘
    │                                │                  │
    │ 三级同时预扣                    │ 发送结算事件      │
    │ 预扣量 = input_tokens          │ 到Kafka           │
    │ × 预估输出系数                  │                  │
    │                                │                  │
    ├─ 租户级 -= pre_deduct           │                  ├─ 租户级 += diff
    ├─ 用户级 -= pre_deduct           │                  ├─ 用户级 += diff
    └─ 请求级(max_tokens) -= pre      │                  └─ 记录结算日志
                                  │
    预估输出系数按场景配置：        │
    · 代码生成: 3.0x               │
    · 文档摘要: 1.8x               │
    · 翻译:     1.2x               │
    · 闲聊:     1.5x               │
    （滑动窗口自动调整）            │
        

3.4 预算超限的降级策略

超限不等于拒绝。根据超限的级别，我们设计了差异化的降级策略——核心原则是"先降级后拒绝"：

3.5 Redis预算计数器的性能考量

三级预算需要在每个请求入口做三次Redis读写，这对Redis集群的压力不容忽视。在日均1.2亿Token的场景下，假设平均每次请求消耗3000 Token，日均请求量约4万次，峰值QPS约150。每个请求4次Redis操作（3次预扣+1次结算），理论上峰值Redis QPS约600，远在Redis Cluster的处理能力之内。

但真正的瓶颈不在QPS，而在Lua脚本的执行时间。我们使用的三级预扣Lua脚本需要原子地读取和更新三个Key，如果三个Key恰好落在不同的Redis分片上，Lua脚本无法跨分片执行。解决方案是将同一租户的三个预算Key通过Hash Tag强制路由到同一分片：`{tenant:123}:budget:monthly`、`{tenant:123}:user:456:budget:daily`、`{tenant:123}:request:budget`。这样做牺牲了数据分布的均匀性，但保证了原子性——在成本管控场景，正确性优先于负载均衡。

四、语义缓存架构：从精确匹配到语义相似度的命中率跃迁

4.1 精确匹配的极限

语义缓存是LLM网关最核心的成本优化手段。直观的想法是做精确匹配——相同的输入直接返回缓存的输出。但实际数据告诉我们，精确匹配的命中率低得惊人：仅3.2%。原因很简单——用户很少重复完全相同的提问。"帮我写一首关于春天的诗"和"写一首春天的诗"语义完全等价，但字符串截然不同。

更深层的问题是：LLM的输入不仅包含当前问题，还包含系统提示词（System Prompt）、历史对话上下文、few-shot示例等。这些"隐形变量"使得即使问题相同，完整的Prompt字符串也几乎不可能重复。传统的KV缓存（以完整Prompt为Key）在这种场景下基本失效。

我们做过一个实验：将同一个问题的100种不同表述（不同措辞、不同标点、不同上下文长度）发送给同一个模型，结果得到的答案内容高度一致（语义相似度>0.92），但精确匹配命中率是0%。这个实验清楚地表明：用户问题的"语义等价类"远小于"字符串等价类"，缓存的匹配维度必须从字符串升级到语义空间。

4.2 语义缓存的核心架构

我们的语义缓存架构围绕一个核心洞察构建：缓存键不是完整的Prompt，而是从Prompt中提取的"问题语义指纹"。整个架构分为四个阶段：

┌───────────────────────────────────────────────────────────────────────┐
│                      语义缓存处理流水线                                 │
│                                                                       │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐            │
│  │ 1 问题提取    │───→│ 2 向量编码    │───→│ 3 近似最近邻  │            │
│  │ Question     │    │ Embedding    │    │ ANN Search   │            │
│  │ Extraction   │    │              │    │              │            │
│  └──────────────┘    └──────────────┘    └──────┬───────┘            │
│       │                    │                     │                    │
│  从完整Prompt中         bge-large-zh            │                    │
│  剥离以下部分：         编码为1024维             │                    │
│  · System Prompt        向量 (延迟             │                    │
│  · 对话历史              < 5ms)                │                    │
│  · few-shot示例                               │                    │
│  · 用户个人信息                               ▼                    │
│                                       ┌──────────────┐            │
│  提取后的"纯问题"                      │ 4 相似度判定   │            │
│  作为缓存键的输入                       │ Similarity   │            │
│                                        │ Judgment     │            │
│                                        └──────┬───────┘            │
│                                               │                     │
│                                   ┌───────────┼───────────┐        │
│                                   │           │           │        │
│                                   ▼           ▼           ▼        │
│                             相似度>0.95   0.85~0.95   <0.85       │
│                             直接返回缓存   上下文增强   缓存未命中   │
│                             (零推理成本)   (追加缓存答案  (正常推理) │
│                                           作为参考)    写入缓存    │
│                                                        (条件判断)  │
└───────────────────────────────────────────────────────────────────────┘
        

关键的架构决策解读：

• 问题提取而非完整Prompt做键：这是一切的基础。剥离System Prompt后（同一场景下System Prompt通常是固定的），缓存命中率从3.2%跳到了 31%。剥离对话历史后又提升了8个百分点——因为用户经常在新对话中提出与旧对话相似的问题。
• 轻量Embedding模型而非大模型：我们使用bge-large-zh模型进行向量编码，单条延迟 <5ms，远低于调用LLM的数百毫秒。向量化是缓存的"入场券"，如果向量化本身就很慢，缓存的意义就大打折扣。我们曾尝试使用GPT-3.5做语义嵌入，延迟在200ms+，完全不可接受。
• 三级相似度阈值而非二值判定：高相似度(>0.95)直接返回，省去全部推理成本；中等相似度(0.85~0.95)将缓存答案作为参考上下文注入，降低推理难度但保留LLM的最终判断权；低相似度则视为未命中。这一设计将有效命中率从31%进一步提升到 47%——中等相似度的"上下文增强"虽然不省推理调用，但显著提升了回答质量和速度。

4.3 近似最近邻索引方案选型

向量检索是语义缓存的性能瓶颈。随着缓存条目增长到千万级，暴力搜索的延迟从毫秒级退化到秒级，完全不可接受。我们对三种主流ANN方案做了深度对比和生产验证：

4.4 缓存写入的策略与过滤

并非所有推理结果都值得缓存。无差别的缓存写入不仅浪费向量索引空间，还会降低检索质量（噪点条目干扰匹配）。我们设定了三条写入门槛：

• 确定性信心度高：模型输出的logprobs均值高于阈值。logprobs高意味着模型对答案很"确信"，这种答案不太可能因微小的输入变化而大幅改变。低logprobs的输出（如开放式创意写作）则不缓存——因为每次生成可能截然不同
• 非个性化内容：通过NER模型检测输出中是否包含用户特定信息（姓名、订单号、手机号等）。包含个人信息的答案对其他用户无价值，缓存反而有害
• TTL自适应：根据缓存条目的历史命中频率动态调整TTL。热门问题（24小时内被命中≥5次）TTL延长至7天；中等热度24小时后过期；冷门问题TTL仅2小时——自动淘汰无效缓存。这一策略让向量索引的规模稳定在 800万条 左右，避免了无限膨胀

4.6 中等相似度的上下文增强策略详解

三级相似度阈值中，"中等相似度"（0.85~0.95）的上下文增强策略是最精妙的——它既不直接返回缓存（风险太高），也不完全忽略缓存（浪费了已有的推理成果），而是将缓存答案作为"参考信息"注入到新推理的上下文中。

具体实现是将缓存答案封装为一段辅助提示词，插入到System Prompt和用户问题之间：

上下文增强的实现方式：

原始请求：
  System: 你是一个客服助手...
  User: 请问退货需要多长时间？

增强后的请求：
  System: 你是一个客服助手...
  Assistant: [参考答案-仅供你参考，请根据用户的实际提问重新组织回答]
             一般来说，退货处理时间为7-15个工作日...
  User: 请问退货需要多长时间？

关键约束：
  · 参考答案用特殊标记包裹，模型被指示"参考但不照搬"
  · 如果用户问题与缓存问题的语义差异被识别到（如细粒度NER差异），
    参考答案不被注入——避免"退货vs退款"式混淆
  · 参考答案的Token不计入用户预算（由平台承担）
  · 平均增加上下文开销：约200-500 Token/请求
        

实测效果：中等相似度场景下，注入参考答案后的首次完成率（无需用户追问即可解决问题）从62%提升到 81%——虽然还是调用了LLM推理，但对用户来说体验明显更好了。而且，由于模型有了参考方向，输出长度平均缩短18%，间接节省了Token成本。

4.5 缓存降级与容灾

语义缓存作为请求路径的"第一道关卡"，其自身的高可用至关重要。如果缓存系统故障导致所有请求都穿透到模型推理，后端将在数分钟内被击垮。我们设计了三级降级策略：

4.7 缓存效果的全景数据

语义缓存上线6个月后的全景数据，按场景维度统计：

值得关注的发现：代码助手的语义缓存命中率最低（18.7%），因为代码问题天然多样性高——即使功能相同，不同编程语言、不同代码上下文带来的语义差异远超文本场景。而翻译场景虽然精确匹配率最高（6.3%），但语义缓存的增益仍然巨大——因为"把这段话翻译成英文"有无数种表述。

另一个有趣的发现：营销文案场景的缓存命中率在工作日期间稳定在40%左右，但周末暴跌到15%以下——因为周末的文案需求更加发散（社交平台文案vs工作日邮件文案）。这验证了我们的TTL自适应策略的必要性——固定TTL在需求模式变化的场景下效率低下。

五、流式输出聚合：SSE多路复用与背压控制

5.1 流式输出的工程挑战

LLM推理的标志性特征是流式输出——模型生成一个Token就推送一个Chunk，用户看到的是"打字机效果"而非漫长的等待。这对网关的连接管理提出了全新的挑战。在最极端的场景下，单个网关节点需要同时维持 8000+个SSE长连接，每个连接持续5-30秒不等，期间持续产出Token Chunk。

传统网关的HTTP/1.1连接池模型在此彻底失效，原因有三：

• 连接池语义冲突：连接池的"借出-归还"语义假设请求会在短时间内完成，但SSE连接可能持续数十秒，连接池会被迅速耗尽
• 超时配置失配：传统网关的连接超时在5-10秒范围内，而LLM推理首批Token可能就需要3-5秒的"思考时间"，超时会被误判为故障
• 并发表达力不足：每个SSE连接需要一个独立Goroutine维护，8000并发意味着8000个Goroutine——虽然Go理论上可以承受，但内存和调度压力不可忽视，尤其在1ms级延迟抖动敏感的场景下

5.2 SSE代理架构设计

我们设计了一种基于HTTP/2的SSE代理方案，核心思想是将多个下游模型的SSE流聚合成一个统一的上游SSE流，同时处理好连接生命周期管理：

┌──────────────────────────────────────────────────────────────────────┐
│                       SSE代理架构                                     │
│                                                                      │
│  客户端                          LLM网关                   模型服务    │
│    │                               │                        │        │
│    │ ─── HTTP/2 请求 ───────────→ │                        │        │
│    │    (支持多路复用)             │                        │        │
│    │                               │ ─── HTTP/1.1 SSE ──→ │ GPT-4o │
│    │                               │ ←── Chunk 1 ──────── │        │
│    │ ←── Chunk 1 ──────────────── │                        │        │
│    │                               │ ←── Chunk 2 ──────── │        │
│    │ ←── Chunk 2 ──────────────── │                        │        │
│    │                               │ ...                    │        │
│    │                               │ ←── [DONE] ───────── │        │
│    │ ←── 流结束标记 ────────────── │                        │        │
│    │                               │                        │        │
│    │ ─── 第二个请求 ────────────→ │                        │        │
│    │   (同一HTTP/2连接复用)        │ ─── HTTP/1.1 SSE ──→ │        │
│    │                               │     DeepSeek-V3       │        │
│    │                               │ ←── Chunk ────────── │        │
│    │ ←── Chunk ────────────────── │                        │        │
│                                                                      │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │ 关键设计点：                                                    │ │
│  │                                                                │ │
│  │ 1. 上游HTTP/2多路复用 → 一个TCP连接承载多个SSE流               │ │
│  │ 2. 下游HTTP/1.1独立连接 → 兼容所有模型API                     │ │
│  │ 3. 连接池分两层：                                              │ │
│  │    · 推理连接池：长生命周期，绑定请求级别Context               │ │
│  │    · 控制连接池：短生命周期，用于健康检查/元数据查询           │ │
│  │ 4. 超时分层策略：                                              │ │
│  │    · 首Token超时：15s（容忍模型思考时间）                      │ │
│  │    · Chunk间隔超时：30s（容忍推理间歇）                        │ │
│  │    · 总超时：300s（防无限挂起）                                │ │
│  │ 5. 客户端断开感知：                                            │ │
│  │    · 心跳探测：每5s写入SSE注释行（:\n\n）                     │ │
│  │    · 写入失败 → 触发context cancel → 下游请求中止             │ │
│  └────────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘
        

5.3 背压控制：防止慢消费者拖垮网关

背压（Backpressure）是流式系统的经典难题。当客户端消费速度慢于模型产出速度时，未发送的Token Chunk会在网关内存中堆积。如果不加以控制，8000个慢消费者足以让网关节点OOM崩溃——我们确实在一次大促中踩了这个坑。

问题的根源在于：Go的HTTP response writer是带缓冲的，当客户端消费慢时，写入操作不会立即失败，而是数据堆积在Go运行时的写缓冲区中。缓冲区的大小由内核的TCP发送缓冲区（通常4MB~16MB）决定，在大并发下这些缓冲区迅速累积到GB级别。

我们的背压控制策略分为三层，形成梯度防护：

5.4 断线重连与输出恢复

移动端网络不稳定是常态，SSE连接断开后如何恢复输出是关键的体验问题。传统做法是客户端重新发起请求，但这意味着之前的推理结果全部浪费——模型已经生成的Token需要重新生成一遍。

我们的方案是在网关层维护一个输出快照缓冲：每个SSE流在网关保留最近30秒的Chunk快照，客户端重连时携带Last-Event-ID，网关从该ID之后继续推送。这个设计的代价是额外的内存开销（每个活跃连接额外30KB），但换来的收益是断线重连后零重复Token输出。

5.5 性能优化：零拷贝与缓冲区复用

SSE代理的另一个性能瓶颈是数据拷贝。传统的实现流程是：模型返回Chunk → 网关反序列化 → 业务逻辑处理 → 序列化 → 写入客户端。每一步都涉及内存分配和拷贝，在8000+并发的场景下，GC压力显著。

我们做了三个关键的零拷贝优化：

• Json Stream Parser：自定义流式JSON解析器，直接在原始字节流上解析SSE事件，避免将整个Chunk反序列化为内存对象。实测减少30%的内存分配。
• ByteBuf池化：借鉴Netty的对象池思想，预分配128KB的缓冲区池，SSE Chunk写入时从池中借用，完成后归还。避免每次写入都触发 make([]byte, N) 的新分配。
• Writev批量写入：将多个小Chunk合并为一次 writev 系统调用，减少内核态切换次数。在Token产出密集的阶段（模型生成代码块时），合并比例可达5:1。

三项优化叠加后，单节点可支撑的SSE并发从5000提升到 12000+，P99延迟从120ms降到65ms（不含模型推理时间）。

5.6 异常处理：部分失败的容错策略

流式输出的另一个难题是"部分失败"——模型已经输出了80%的内容，剩余20%的推理突然失败（如模型服务重启、网络抖动）。传统做法是整个请求标记为失败，但这意味着之前的输出全部浪费。

我们的策略是优雅降级：网关检测到下游SSE流异常中断时，立即向客户端发送一个"流中断"事件（event: stream_interrupted），附带已接收的全部内容和中断原因。客户端可以选择：基于已有内容继续使用（适用于大部分已完成的场景），或者重新发起请求。关键数据结构如下：

SSE流中断事件格式：
event: stream_interrupted
data: {
  "received_tokens": 3240,
  "total_estimated": 4096,
  "completion_percent": 79.2,
  "interrupt_reason": "model_service_unavailable",
  "resumable": true,
  "partial_content": "已接收的完整内容..."
}
        

实测中，约60%的流中断发生在输出已完成80%以上的阶段，用户通常可以直接使用部分结果。这一设计将流中断导致的"完全浪费"比例从100%降到 40%。

六、灰度发布与模型切换：零停机的A/B实验框架

6.1 模型灰度的独特挑战

传统微服务的灰度发布是代码层面的——同一服务的V1和V2版本，流量按比例切换即可。但模型灰度远比这复杂：它不是"替换代码"，而是"替换大脑"。同一个Prompt发给GPT-4o和DeepSeek-V3，输出的内容、风格、长度、准确度可能完全不同。

这意味着模型灰度无法简单回滚——一旦用户看到了不同风格的回答，即使切换回原模型，用户体验已经断裂。更棘手的是，模型输出风格的差异会导致用户行为变化——如果新模型回答更简洁，用户可能增加追问频次；如果新模型回答更详细，用户可能减少追问。这种"反馈效应"使得灰度实验的因果关系难以分离。

此外，模型切换还涉及Token成本的突变。GPT-4o和DeepSeek-V3的单Token成本差了将近 8倍，灰度10%的流量可能意味着成本飙升或骤降——这种成本突变必须在灰度实验设计中得到前置考量。

6.2 实验框架架构

我们设计了基于"实验组（Experiment Group）"的灰度框架，核心思想是把一次模型切换建模为一个可控的A/B实验，而非一个简单的流量切换操作：

┌─────────────────────────────────────────────────────────────────────┐
│                     灰度实验教学平台                                   │
│                                                                     │
│  实验配置：                                                           │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │ 实验名称: code-assistant-deepseek-migration                  │   │
│  │ 实验负责人: 张三                                               │   │
│  │ 实验目标: 验证DeepSeek-V3替代GPT-4o在代码场景的效果与成本     │   │
│  │                                                             │   │
│  │ 灰度比例阶梯：5% → 10% → 25% → 50% → 100%                   │   │
│  │ 每阶梯持续时间：48小时                                         │   │
│  │ 晋级条件：所有评估指标满足阈值                                  │   │
│  │ 流量分配策略：用户ID哈希 (同一用户始终看到同一模型)             │   │
│  │                                                             │   │
│  │ 对照组 (A): GPT-4o, 80%流量                                   │   │
│  │ 实验组 (B): DeepSeek-V3, 15%流量                              │   │
│  │ 实验组 (C): Qwen-Max, 5%流量 (次要候选)                      │   │
│  │                                                             │   │
│  │ 评估指标体系：                                                 │   │
│  │   · 业务指标: 代码采纳率(↑), 任务完成率(↑), 用户投诉率(↓)     │   │
│  │   · 质量指标: 回答准确率(↑)(人工抽样), 幻觉率(↓)(规则检测)    │   │
│  │   · 成本指标: 单次推理Token成本(↓), 场景总成本变化(监控)       │   │
│  │   · 稳定指标: P99延迟(≤), 首Token时间(≤), 错误率(≤)          │   │
│  │                                                             │   │
│  │ 自动回滚条件（任一触发立即回滚）：                             │   │
│  │   · 代码采纳率下降 > 10%                                     │   │
│  │   · 幻觉率上升 > 5%（绝对值）                                │   │
│  │   · 用户投诉量 > 基线的3倍                                   │   │
│  │   · P99延迟上升 > 50%                                       │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                     │
│  流量染色链路实现：                                                   │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐     │
│  │ 请求入口 │→→→│ 实验匹配 │→→→│ Header   │→→→│ 全链路   │     │
│  │ SDK/HTTP │    │ 一致性哈希│    │ 染色注入 │    │ 透传     │     │
│  └──────────┘    └──────────┘    └──────────┘    └──────────┘     │
│                                                                     │
│  染色Header：X-Experiment-Id=code-assistant-deepseek-migration     │
│             X-Experiment-Group=B                                   │
│             X-Experiment-Model=deepseek-v3                         │
└─────────────────────────────────────────────────────────────────────┘
        

6.3 零停机模型切换的三个关键机制

实现真正的"零停机"需要在连接层面做到无缝切换，我们依赖三个关键机制：

机制一：长连接养生

模型切换时不主动断开已有SSE连接，只对新请求路由到新模型。存量连接自然结束后，旧模型的负载降至零，再执行下线。实测中，存量连接的平均生命周期约15秒，30秒后99%的存量连接已结束。这意味着模型新旧版本的共存窗口极短，运维复杂度可控。

机制二：预热切换

新模型实例上线前，先发送若干预热请求（使用匿名化的历史真实请求），确保推理引擎的KV Cache和CUDA Kernel已编译就绪。避免首批真实请求打到冷启动的模型实例上——冷启动的首Token延迟可达正常的10倍以上（数秒级），这在用户体验上是不可接受的。

机制三：双写校验

灰度初期（5%流量阶段），对小比例流量同时发送给新旧两个模型，只返回旧模型的结果给用户，但在后台异步比对新旧模型的输出质量。这种"影子调用"虽然增加了少量成本（约5%额外推理消耗），但提供了最可靠的决策依据——直接在同一用户、同一请求的场景下对比两个模型的实测表现。

6.4 成本感知的灰度策略

模型切换带来的成本突变是灰度实验中容易被忽视的变量。我们在灰度框架中引入了成本预算机制：

• 实验成本预估：在创建灰度实验时，系统自动预估不同灰度比例下的成本变化。例如，将10%的GPT-4o流量切到DeepSeek-V3，预估月度成本下降约¥8万
• 成本熔断：如果灰度实验的实际成本超出预估的120%，自动暂停实验并通知负责人。防止因为意外的Token消耗模式（如新模型输出普遍更长）导致预算超支
• 成本归因标签：灰度实验的每一条请求都打上实验组标签，便于在ClickHouse中精确分离实验组和对照组的成本差异

这套机制让我们在一次大规模模型切换实验中，及时发现DeepSeek-V3在中文场景的平均输出长度比GPT-4o长40%——虽然单Token价格更低，但总成本并没有预期下降那么多。如果没有成本熔断，我们可能在全量切换后才发现"省了单价、多了用量"的尴尬局面。

七、限流降级策略：令牌桶+优先级队列+模型降级三板斧

7.1 LLM流量与传统流量的差异

LLM推理请求的"重量"差异极大。一个简单的翻译请求可能消耗500 Token、耗时2秒；一个复杂的代码审查请求可能消耗8000 Token、耗时25秒。如果用传统的"每秒请求数(QPS)"限流，轻量请求和重量请求被同等对待，要么保护过度（轻量请求被误限），要么保护不足（重量请求打垮后端）。

核心矛盾在于传统限流只计量维度"请求数"，而LLM场景的真实负载维度是"Token数"。一个QPS=100的流量可能只消耗10万Token/秒（轻量请求为主），也可能消耗500万Token/秒（重量请求为主），两者对后端的压力相差50倍。

因此我们的限流策略以Token/秒为核心度量，而非QPS。这要求网关在请求到达时就能预估Token消耗——而非等到推理完成后才知道。预估基于场景化的历史统计模型，准确率在85%以上。

7.2 三板斧架构

限流降级策略不是单一机制，而是一个分层防护体系。我们称之为"三板斧"，每一斧解决一个层面的问题：

                        请求入口
                           │
                           ▼
              ┌────────────────────────┐
              │  第一斧：令牌桶限流     │
              │  (Token-Rate Limiting) │
              │                        │
              │  限流维度：             │
              │  · 全局Token/秒         │
              │  · 租户Token/秒         │
              │  · 模型Token/秒         │
              │  · 用户Token/分钟       │
              │                        │
              │  实现：                │
              │  Redis + Lua原子脚本   │
              │  维度组合键哈希到同一槽 │
              │                        │
              │  预扣Token → 推理 → 结算│
              └──────────┬─────────────┘
                         │ 未超限
                         ▼
              ┌────────────────────────┐
              │  第二斧：优先级队列     │
              │  (Priority Queue)      │
              │                        │
              │  P0: 核心业务           │
              │      支付/交易确认等    │
              │      直接通过，不排队   │
              │                        │
              │  P1: 重要业务           │
              │      客服/知识问答等    │
              │      等待队列，超时5s   │
              │                        │
              │  P2: 普通业务           │
              │      文档摘要/翻译等    │
              │      等待队列，超时10s  │
              │                        │
              │  P3: 批量任务           │
              │      数据迁移/批量标注  │
              │      等待队列，超时30s  │
              │                        │
              │  实现：Redis Sorted Set │
              │  score=priority+时间戳  │
              └──────────┬─────────────┘
                         │ 队列未满
                         ▼
              ┌────────────────────────┐
              │  第三斧：模型降级       │
              │  (Model Degradation)   │
              │                        │
              │  触发条件：             │
              │  · 某模型负载>80%       │
              │  · 某模型错误率>5%      │
              │  · 某模型P99>阈值       │
              │                        │
              │  降级规则：             │
              │  负载80%→P3请求降级模型 │
              │  负载90%→P2以下降级     │
              │  负载95%→P1以下降级     │
              │                        │
              │  降级映射表（可配置）：  │
              │  GPT-4o → DeepSeek-V3  │
              │  Qwen-Max → Qwen-Turbo │
              │                        │
              │  降级保护：             │
              │  · 数学推理场景不降级   │
              │  · VIP用户不降级        │
              │  · 单用户降级率<30%/天  │
              └────────────────────────┘
        

7.3 令牌桶的关键实现细节

令牌桶在LLM场景的实现与传统场景有一个关键差异：Token消耗发生在推理过程中，而不是请求发送时。如果等推理完再扣减令牌，限流器看到的永远是"历史消耗"而非"实时压力"，会导致过载保护滞后——在推理高峰期间，限流器可能判断"还有余量"，但实际上模型端已经不堪重负。

我们采用"预扣+结算"模式：请求入口时，根据输入Token数量 + 历史 avg_output_tokens 预估输出Token，一次性从令牌桶中扣除。推理完成后，根据实际消耗结算差额。这一设计的代价是令牌桶的精度受限（预扣偏差），但换来的是实时的过载保护——在推理还未完成时，限流器就能感知到压力。

7.4 优先级队列的公平性设计

优先级队列最大的风险是"饥饿"——低优先级请求可能永远得不到服务。我们引入了两个公平性保障机制：

• 超时自动升级：请求在队列中等待超过其超时时间的50%时，优先级自动提升一级。P3请求等待15秒后升级为P2，再等5秒升级为P1，确保极端情况下不会无限等待。
• 最低服务保障：每个优先级级别维护"最少服务比例"——P3至少获得10%的吞吐量（当有P3请求排队时）。这避免了高优先级流量完全挤占低优先级的情况——毕竟，批量任务虽然不紧急，但业务方也在等结果。

八、可观测性与成本归因：Token维度的全链路监控

8.1 为什么需要Token粒度监控

在LLM网关之前，我们的监控维度停留在"请求次数"和"响应延迟"。但这两个指标对LLM场景严重不足：10个消耗500 Token的轻量请求，和1个消耗5000 Token的重量请求，在请求计数上差10倍，在Token消耗上却相同。如果只看请求量决策扩缩容，会严重低估实际的推理负载。

更关键的是成本归因。我们每个月在多家模型供应商上的账单超过 200万元，但传统的调用链追踪只能告诉你"哪个API被调了多少次"，无法回答"哪个业务场景、哪个用户、哪种请求类型消耗了多少Token"。没有这个信息，成本优化就是盲人摸象——你不知道砍哪一刀。

Token粒度监控的另一个价值是异常检测。某用户的Token消耗突然飙升3倍，可能是正常的业务增长，也可能是脚本bug导致的循环调用，也可能是被攻击。只有Token粒度的实时监控才能捕捉到这种异常模式。

8.2 全链路Token追踪架构

我们基于OpenTelemetry构建了全链路Token追踪体系，在请求经过的每个阶段都记录Span和Metrics：

请求进入
   │
   ├─ TraceID 生成 (全局唯一, W3C Trace Context)
   │
   ▼
┌──────────────────────────────────────────────────────────────┐
│  入口Span: llm_gateway.receive                                │
│  Tags: socket_id, tenant_id, user_id, scene                   │
│  Metrics: request_counter{scene} += 1                         │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│  语义缓存阶段                                                  │
│  Span: semantic_cache.lookup                                  │
│  Tags: cache命中=yes/no, similarity_score, cached_tokens      │
│  Metrics: cache_hit_counter{scene} += 1 (if hit)             │
│  Metrics: saved_tokens_counter{scene} += cached_tokens (if hit)│
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│  路由决策阶段                                                  │
│  Span: model_router.decide                                    │
│  Tags: scene, complexity_score, selected_model, route_reason  │
│  Metrics: route_counter{model, scene} += 1                    │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│  预算校验阶段                                                  │
│  Span: budget_checker.verify                                  │
│  Tags: tenant_budget_level, user_budget_level, pre_deduct     │
│  Metrics: budget_reject_counter{level} += 1 (if rejected)    │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│  模型推理阶段 (核心Span)                                       │
│  Span: model_inference.call                                   │
│  Tags: model_name, model_version                              │
│  Metrics:                                                     │
│    · input_token_counter{model, scene, tenant} += actual_input│
│    · output_token_counter{model, scene, tenant} += actual_out │
│    · inference_latency_ms{model} = actual_latency             │
│    · first_token_latency_ms{model} = first_chunk_latency      │
│    · finish_reason_counter{reason} += 1                       │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│  安全审查阶段                                                  │
│  Span: safety_guard.review                                    │
│  Tags: output_safe=yes/no, reject_reason                      │
│  Metrics: safety_reject_counter{reason} += 1 (if rejected)   │
└──────────────┬───────────────────────────────────────────────┘
               │
               ▼
┌──────────────────────────────────────────────────────────────┐
│  预算结算阶段                                                  │
│  Span: budget_settlement.settle                               │
│  Tags: actual_total_tokens, pre_deduct_diff, remaining_budget │
│  Metrics:                                                     │
│    · actual_token_counter{model, scene, tenant, user} += real │
│    · budget_diff_counter += (actual - pre_deduct)             │
└──────────────────────────────────────────────────────────────┘
        

8.3 成本归因的三大视角

全链路Token追踪的最终目标是支撑精细化的成本归因与决策。我们构建了三个维度的归因看板，每个看板服务于不同角色的决策需求：

8.4 实时指标与离线分析的协同

监控系统分为两层：实时层（基于Prometheus + Grafana），负责秒级指标聚合和告警；离线层（基于Kafka + ClickHouse），负责小时/天级的深度分析和归因报表。两者通过Kafka连接：实时指标同时写入Prometheus和Kafka，Kafka消费者将数据落盘到ClickHouse供离线查询。

这种双层的必要性在于：Prometheus擅长时间序列聚合，但不擅长多维度的ad-hoc查询（如"过去7天，租户X在场景Y下的Token消耗按模型分组的趋势"）。ClickHouse弥补了这一短板，使得成本归因分析不再受限于预定义的聚合维度。

九、安全合规护栏：内容审核、PII脱敏与输出过滤

9.1 LLM安全防护的特殊性

LLM的安全防护与传统Web安全有本质差异。传统安全防护的是"系统不被入侵"，而LLM安全还需要防护"系统不被滥用"和"输出不被污染"。具体来说，LLM网关面临三类独特的安全威胁：

• Prompt注入攻击：用户通过精心构造的输入，劫持模型的System Prompt，使其执行非预期行为（如泄露内部信息、生成恶意代码、绕过安全限制）。这是LLM场景最严重、最隐蔽的安全风险——攻击发生在"语义层"而非"网络层"
• PII泄露：模型在输出中暴露训练数据或上下文中包含的个人隐私信息（身份证号、手机号、邮箱、银行卡号等）。在金融行业，一次PII泄露事件就可能触发监管处罚
• 有害内容生成：模型被诱导生成暴力、色情、歧视性内容，或提供违法活动的详细指导。虽然主流模型都做了安全对齐，但"越狱"技术（jailbreak）在不断进化

我们的安全护栏架构采用"三明治模型"——输入过滤、推理监护、输出审查三层防护，任何一层拦截即终止请求。这种纵深防御的设计理念源自安全工程的"多层防线"原则——没有单一安全机制是100%可靠的。

┌─────────────────────────────────────────────────────────────────────┐
│                     安全护栏 "三明治模型"                              │
│                                                                     │
│  ┌──────────────────────────────────────────────────────────────┐  │
│  │ 第一层：输入过滤 (Input Guard)                                 │  │
│  │                                                              │  │
│  │  ┌────────────────────────┐  ┌────────────────────────────┐ │  │
│  │  │ PII检测与脱敏           │  │ Prompt注入检测              │ │  │
│  │  │                        │  │                            │ │  │
│  │  │ 检测手段：              │  │ 检测手段：                  │ │  │
│  │  │ · 正则匹配(手机/邮箱等) │  │ · 规则引擎(已知攻击模式)    │ │  │
│  │  │ · NER模型(姓名/地址等)  │  │ · 分类模型(未知攻击识别)    │ │  │
│  │  │ · 字典匹配(自定义敏感词)│  │ · Token分布异常检测         │ │  │
│  │  │                        │  │                            │ │  │
│  │  │ 处理方式：              │  │ 处理方式：                  │ │  │
│  │  │ · 替换为占位符再送模型  │  │ · 拒绝请求(400)           │ │  │
│  │  │ · 保留映射表用于还原    │  │ · 记录攻击日志+告警        │ │  │
│  │  │ · 延迟：<3ms(正则)     │  │ · 延迟：<5ms(规则)        │ │  │
│  │  │         <15ms(NER)     │  │         <30ms(模型)        │ │  │
│  │  └────────────────────────┘  └────────────────────────────┘ │  │
│  └──────────────────────────────────────────────────────────────┘  │
│                               │ 通过                               │
│                               ▼                                    │
│  ┌──────────────────────────────────────────────────────────────┐  │
│  │ 第二层：推理监护 (Inference Guard)                             │  │
│  │                                                              │  │
│  │  · Token生成实时监控                                          │  │
│  │    滑动窗口检测敏感关键词序列（窗口=128 Token）                  │  │
│  │    流式场景每32个Chunk检测一次                                  │  │
│  │                                                              │  │
│  │  · 上下文长度异常检测                                          │  │
│  │    单次请求Token消耗异常飙升 → 可能是循环生成                   │  │
│  │    阈值：输出Token > 场景均值×3 → 触发审查                      │  │
│  │                                                              │  │
│  │  · 模型调用频率异常                                            │  │
│  │    同一用户1分钟内 > 30次调用 → 可能是自动化攻击                 │  │
│  └──────────────────────────────────────────────────────────────┘  │
│                               │ 正常                               │
│                               ▼                                    │
│  ┌──────────────────────────────────────────────────────────────┐  │
│  │ 第三层：输出审查 (Output Guard)                                │  │
│  │                                                              │  │
│  │  ┌────────────────────┐  ┌────────────────────┐              │  │
│  │  │ 有害内容检测        │  │ PII二次检测         │              │  │
│  │  │                    │  │                    │              │  │
│  │  │ 轻量审核模型        │  │ 模型可能"创造"出    │              │  │
│  │  │ (延迟<50ms)        │  │ 合理的假PII数据      │              │  │
│  │  │                    │  │ (如生成符合规则的     │              │  │
│  │  │ 检测维度：          │  │ 身份证号)            │              │  │
│  │  │ · 暴力/色情/歧视   │  │                    │              │  │
│  │  │ · 违法活动指导      │  │ 输出侧同样需要       │              │  │
│  │  │ · 儿童安全隐患     │  │ PII脱敏处理          │              │  │
│  │  │                    │  │                    │              │  │
│  │  │ 处理：拦截输出      │  │ 处理：替换为掩码     │              │  │
│  │  │ + 返回安全提示      │  │ + 记录审计日志       │              │  │
│  │  └────────────────────┘  └────────────────────┘              │  │
│  │                                                              │  │
│  │  ┌────────────────────┐                                       │  │
│  │  │ 品牌合规检查        │                                       │  │
│  │  │                    │                                       │  │
│  │  │ · 禁止输出竞争对手  │                                       │  │
│  │  │   的产品具体信息    │                                       │  │
│  │  │ · 禁止输出未授权的  │                                       │  │
│  │  │   内部流程细节      │                                       │  │
│  │  └────────────────────┘                                       │  │
│  └──────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────┘
        

9.2 流式场景下的审查挑战与方案

流式输出让安全审查面临一个根本矛盾：完整性 vs 实时性。如果等全部Token生成完毕再审查，用户已经看到了有害内容；如果逐Token审查，单Token无法判断上下文语义（"杀"是烹饪用语还是暴力用语取决于上下文）。

我们的解决方案是增量滑动窗口审查：

• 每积累32个Token（约一次SSE Chunk推送），触发一次轻量审核模型推理
• 审核模型对最近128个Token的滑动窗口进行四分类语义安全判定：安全/可疑/有害/严重有害
• 判定为"有害"或"严重有害"时，立即中断SSE流并向客户端发送替代内容
• 判定为"可疑"时，继续输出但标记该Chunk为待复核，进入离线审计队列
• 客户端展示策略：有害内容拦截后替换为"抱歉，该内容无法展示"，保持对话界面的连贯性

9.3 PII脱敏的还原机制

输入侧的PII脱敏面临一个独特的痛点：脱敏后的Prompt可能导致模型输出质量下降。例如，"帮张三写一封请假信"脱敏后变成"帮[NAME]写一封请假信"，模型生成的信件开头是"尊敬的领导"，而非"尊敬的XX主管"——因为模型不知道张三的上级是谁。

我们的方案是双向映射表+延迟还原：网关维护请求级别的PII映射表（`[NAME_1]→张三`），模型输出中的占位符在返回客户端前自动还原为原始值。映射表的生命周期绑定请求，请求完成后立即销毁，不留持久化痕迹。这种设计的代价是网关需要对输出文本做字符串替换，但实测延迟增加<1ms，完全可以接受。

十、经验沉淀：6个生产级踩坑教训

以下六条经验，每一条都是"半夜告警"换来的。不是因为设计不严谨，而是因为LLM场景的边界条件远超传统系统的经验范畴。分享这些教训，是希望后来者不必再踩同样的坑。

架构全景总览

将所有子系统整合在一起，LLM推理网关的完整架构可以用以下Mermaid图概览：

graph TB
    subgraph Clients [/客户端层/]
        C1[/SDK-Python/]
        C2[/SDK-Java/]
        C3[/SDK-Go/]
        C4[/SDK-TS/]
    end

    subgraph Gateway [/传统API网关/]
        G1[/Nginx-Kong/]
    end

    subgraph LLMGW [/LLM推理网关数据面/]
        S1[/语义缓存/]
        S2[/智能路由/]
        S3[/Token预算/]
        S4[/限流降级/]
        S5[/安全护栏/]
        S6[/流式聚合/]
        S1 --> S2 --> S3 --> S4 --> S5 --> S6
    end

    subgraph Control [/控制面/]
        CP1[/路由策略/]
        CP2[/缓存索引/]
        CP3[/成本核算/]
        CP4[/灰度实验/]
        CP5[/安全审核/]
        CP6[/模型画像/]
    end

    subgraph Models [/模型服务/]
        M1[(/GPT-4o/)]
        M2[(/DeepSeek-V3/)]
        M3[(/Qwen-Max/)]
        M4[(/Claude-3.5/)]
    end

    subgraph Infra [/基础设施/]
        I1[(/Redis-Cluster/)]
        I2[(/Qdrant/)]
        I3[(/Kafka/)]
        I4[(/ClickHouse/)]
        I5[(/Prometheus/)]
        I6[(/MinIO/)]
    end

    Clients --> G1 --> LLMGW
    LLMGW <--> Control
    LLMGW --> Models
    LLMGW <--> Infra
        

这个架构的核心设计哲学可以归结为一句话：数据面追求极致速度，控制面追求极致智能，两者通过清晰接口解耦，各自独立演进。在日均亿级Token的生产压力下，这一哲学被反复验证——数据面的优化让我们扛住了6倍的流量增长，控制面的优化让我们在成本上持续精进。

技术栈总览

架构决策一览

核心指标成果

未来演进方向

LLM推理网关是一个仍在快速演进的系统。以下是我们正在探索或即将启动的三个方向：

方向1：多模态路由

当前路由仅处理文本模态。随着GPT-4o的多模态能力（图片输入、语音输出）逐步开放使用，路由决策需要从"文本复杂度"扩展到"多模态复杂度"——同一个问题，附带一张图片和不附带图片，对模型能力的需求完全不同。我们对路由评估器的特征工程进行了重构，新增图像Token估算、音频时长预测等多模态特征维度。

方向2：联邦推理调度

当前的模型调度是"选一个最优模型"。但某些复杂任务（如长文档摘要+关键信息提取）可以通过模型链式调用获得更好的效果——先用小模型做摘要，再用大模型做信息提取。我们正在设计一种声明式的"推理流水线"DSL，让业务方定义多步骤推理流程，网关负责编排和优化。

方向3：成本归属与定价引擎

当前的成本归因是事后分析的。我们的目标是实现实时成本归属——每个请求在发起前就能精确预估成本，并自动关联到业务成本中心。更进一步的愿景是：构建一套类似云计算的LLM定价引擎——按场景、按质量等级、按SLA分层定价，而非简单的Token用量计费。这将从根本上改变"模型调用是成本中心"的现状，使其成为"利润中心"。

未来架构演进愿景：

当前架构：                          未来架构：
┌─────────────────┐               ┌─────────────────────────────┐
│  请求 → 单模型  │               │  请求 → 推理流水线           │
│  选最优、直接调  │      →→→      │  · 多步编排（小→大→小）     │
│  事后成本统计    │               │  · 实时成本预估+归属          │
│                  │               │  · 多模态路由               │
└─────────────────┘               │  · 分层定价引擎              │
                                  └─────────────────────────────┘