从需求到上线：一次多模型路由的踩坑全记录

需求背景：为什么需要动态路由？

在现代金融合规系统中，AI模型的部署需要考虑多重因素。以某银行合规工单系统为例，其业务场景存在典型的"双峰特征"：

1. 高精度合规条款解析
   需要处理复杂的法律文书和合同条款，要求：
2. 支持32k以上的长上下文窗口（DeepSeek-V4 32k版本）
3. 具备法律术语理解能力（F1-score需>0.92）

4. 容忍较高延迟（SLA约定≤8秒）

5. 实时工单分类路由
   处理客服对话和邮件工单，要求：

6. 亚秒级响应（P99≤1.2秒）
7. 支持代码片段识别（选用DeepSeek-Coder 6B量化版）
8. 高并发处理能力（≥500RPS/GPU）

初期采用的轮询策略暴露了三个致命问题： - 资源利用率失衡：32k模型占用了78%的显存却只处理了15%的请求 - 长尾延迟失控：早高峰时段P99延迟突破3秒红线 - 冷启动雪崩效应：每日首次请求超时率高达34%

第一版方案：基于显存占用的粗暴路由

最初的解决方案尝试通过简单规则分流：

def route_request(prompt: str) -> str:
    if any(keyword in prompt for keyword in ["条款", "合同", "第x章"]):
        if get_gpu_memory() < 80:  # 显存占用百分比
            return "deepseek-v4-32k"
        else:
            return "deepseek-coder-6b-fp16"  # 降级方案
    elif "工单分类" in prompt:
        return "deepseek-coder-6b-int4"
    else:
        return "default-7b-chat"

该方案在压力测试中暴露的四大问题：

1. 显存判断滞后性
   vLLM的显存指标有3-5秒延迟，导致实际已OOM仍被路由到v4实例

2. 冷启动时间误判
   v4模型需要90秒预热才能达到最佳性能，但监控系统将其标记为"就绪"状态

3. 量化模型精度陷阱
   6B-int4在处理包含数学公式的工单时，分类准确率骤降28%

4. 流量突增无弹性
   遇到监管检查时，合规解析请求瞬时增长10倍，没有自动扩容机制

关键改造：四层路由决策因子

1. 实时负载监控体系改造

• 指标采集：
  通过定制vLLM Exporter暴露关键指标：
• KV cache利用率（阈值>75%触发告警）
• 单请求显存消耗（滑动窗口预测）

• 预热状态标记（0-100%进度条）

• 动态权重计算：
  每个实例的可用分计算公式：
  

  score = 0.4*(1 - mem_usage) + 0.3*(1 - queue_len/10) + 0.2*warmup_progress + 0.1*(1 - error_rate)

2. 会话亲和性实现方案

对于需要多轮交互的合规审查场景： - 使用工单ID的MurmurHash绑定到特定GPU - 通过Redis维护会话上下文指纹 - 设计跨实例上下文迁移机制（平均耗时47ms）

3. 成本优化策略

模型类型	单请求基准成本	高峰溢价系数	降级路径
deepseek-v4-32k	1.8	2.1	→ coder-6b-fp16
deepseek-coder-6b	1.0	1.2	→ 自研规则引擎

4. 熔断与降级机制

• 三级熔断策略：
• 单实例超时3次 → 标记为降级状态
• AZ级错误率>5% → 切换备用可用区

• 全区域不可用 → 启用本地缓存模式

• 优雅降级方案：

• 关闭低优先级功能（logprobs、beam search）
• 输出长度限制（动态调整max_tokens）
• 返回最近3天相似工单的缓存结果

上线后观测到的反常识现象

预热策略的优化历程

初始的整点预热策略导致明显规律性延迟毛刺： - 00:00准时触发所有实例预热 - 导致持续90秒的请求堆积 - 整点时段P99延迟达到12秒

改进方案： 1. 改为 staggered warmup（错峰预热） 2. 开发按需预热触发器：

def trigger_warmup():
    if predict_load(next_30min) > current_capacity * 0.7:
        start_background_warmup()

3. 预热过程分级进行（先加载基础参数，再初始化KV cache）

量化模型的真实成本分析

6B-int4模型看似节省显存，但存在隐藏成本： - 上下文回填开销：
处理8000token的工单时，需要8次分段推理，显存碎片导致有效吞吐降低40% - 精度损失补偿：
需要额外15%的重复请求来验证结果一致性 - 监控盲区：
量化误差积累导致每周必须重启实例，否则准确率每周下降2.3%

生产环境配置演进（2026Q2）

routing_matrix:
  - rule_name: "long_context_priority"
    condition: "input_length > 8000 || contains_legal_terms(prompt)"
    primary_target: "deepseek-v4-32k"
    fallback_chain: ["deepseek-coder-6b-fp16", "legacy-rule-engine"]
    cost_params:
      base_weight: 1.5
      surge_multiplier: 2.0
    throttle_config:
      max_rps: 50
      burst_window: 10s

  - rule_name: "urgent_ticket"
    condition: "prompt_contains('紧急') && request_time.hour in [9,11,14,16]"
    priority: "high"
    resource_guarantee:
      min_gpu_mem: 12GB
      reserved_cores: 4
    timeout_policy:
      initial_timeout: 1500ms
      retry_backoff: 200ms

关键架构决策解析

1. 为什么放弃传统负载均衡方案？

经过对比测试，商用LB存在三大硬伤：

指标感知缺陷： - 无法获取KV cache命中率（影响吞吐的关键指标） - 不识别模型特有状态（如LoRA适配器加载进度）

性能损耗对比：

方案类型	平均延迟增加	吞吐量影响	功能完整性
Nginx+LB	28ms	-22%	60%
自研路由层	4.8ms	+30%	100%
Service Mesh	53ms	-35%	85%

业务适配需求： - 需要支持AB测试流量染色 - 必须实现请求级计费标签注入 - 依赖动态降级策略编排

2. 流量突增的七级防御体系

1. 第一道防线 - 前置过滤：
2. 识别并拒绝明显恶意请求（正则表达式匹配）

3. 单客户端速率限制（Token Bucket算法）

4. 弹性扩容流程：

   graph TD
     A[监控触发] -->|RPS>阈值| B(启动EC2竞价实例)
     B --> C{预热完成?}
     C -->|否| D[返回降级响应]
     C -->|是| E[加入路由池]
     E --> F[渐进式流量切换]

5. 终极降级方案：

6. 启动规则引擎+关键词匹配的混合模式
7. 返回预审通过的合规条款模板
8. 人工审核队列优先处理VIP客户

3. 待解决的核心挑战

显存碎片难题： - 混合精度模型切换后产生显存空洞 - 当前解决方案：每4小时执行显存整理（导致约15秒服务中断） - 评估中的替代方案：NVIDIA的CUDA内存池插件

跨AZ一致性： - 会话状态同步延迟导致重复推理 - 正在测试的方案： - 通过RDMA实现GPU内存直通 - 采用CRDT算法解决状态冲突 - 最终一致性窗口控制在500ms内

成本与性能的帕累托前沿： - 当前P99延迟与单位成本的关系曲线显示： - <1.5秒区间：成本呈指数级上升 - 1.5-2.5秒：最佳性价比区间 - >3秒：实际成本反而回升（由于重试等因素）