流量特征分析：模型推理请求的突发性、长尾延迟、资源消耗模式与异常流量识别
模型推理服务在生产环境中面临的流量模式与常规 Web 服务有显著差异。推理请求的突发性、长尾延迟以及资源消耗的非线性特征，直接决定了限流熔断策略的设计边界。若未深入理解这些特征，限流阈值要么过于保守导致资源浪费，要么过于激进导致服务雪崩。本节将系统拆解这四类核心特征，并给出可落地的异常流量识别方法。
2.1 推理请求的突发性特征
模型推理请求的到达模式通常呈现高方差、短时脉冲的特点，这与用户行为、上游服务重试、定时任务触发等因素密切相关。常见的突发模式包括：
- 用户行为突发：如大促活动、热点事件、A/B 实验流量切换，QPS 可在秒级从 100 飙升至 5000+。
- 上游重试风暴：当上游服务超时或报错时，重试请求在短时间内集中涌入，形成“重试放大”效应。
- 定时任务同步：离线批处理任务、模型预热、缓存刷新等定时操作与在线推理流量叠加。
- 冷启动突发：新部署的推理实例在刚注册到服务发现时，流量瞬间倾斜导致单实例过载。
关键指标：突发比（Burst Ratio）= 峰值 QPS / 平均 QPS。当突发比 > 5 时，传统固定速率限流器（如令牌桶固定速率）极易失效，需采用自适应限流或基于排队论的动态窗口算法。
工程建议：在流量入口处部署滑动窗口计数器（窗口粒度 100ms~1s），实时计算当前窗口的瞬时 QPS 与历史基线偏差，作为突发检测的原始信号。
2.2 长尾延迟特征与成因
模型推理的延迟分布通常不符合正态分布，而是呈现明显的长尾（Heavy Tail）特征。P99 延迟可能是 P50 延迟的 10~100 倍，这对限流熔断的响应时间阈值设定提出了极高要求。
| 延迟分位 | 典型值范围（LLM 推理） | 对限流策略的影响 |
|---|---|---|
| P50 | 200ms ~ 500ms | 作为正常流量基线，用于计算平均排队时间 |
| P95 | 1s ~ 3s | 触发慢请求降级或熔断预判的参考阈值 |
| P99 | 5s ~ 30s+ | 熔断器打开的核心依据，超过此值应直接拒绝新请求 |
| P99.9 | 30s ~ 120s+ | 通常由资源争抢或死锁引起，需立即触发熔断并告警 |
长尾延迟的主要成因包括：
- 显存/内存竞争：多个推理请求同时申请显存块，导致 CUDA 内存分配器产生阻塞。
- 动态批处理排队：请求在 Batch 队列中等待凑足批次大小，低优先级请求被高优先级请求“饿死”。
- 模型计算路径差异：输入序列长度差异导致 Transformer 计算量呈二次方变化，长序列请求显著拉长尾部。
- CPU/GPU 异构调度：预处理（CPU）与推理（GPU）之间的流水线阻塞，或 CPU 侧的 tokenizer 成为瓶颈。
2.3 资源消耗模式：非线性与异构性
模型推理的资源消耗与常规 CPU 密集型服务有本质区别，主要体现在显存（VRAM）、GPU 算力（SM 利用率）和内存带宽三个维度。资源消耗并非与 QPS 呈线性关系，而是受输入/输出序列长度、批次大小和模型架构的强烈影响。
| 资源维度 | 消耗模式 | 对限流熔断的启示 |
|---|---|---|
| 显存（VRAM） | 与模型参数量 + 批次大小 × 序列长度 成正比；KV Cache 随序列长度线性增长 | 显存使用率 > 85% 时应触发限流，防止 OOM 导致整卡服务中断 |
| GPU SM 利用率 | 计算密集型（大模型）在低并发时利用率低，高并发时迅速饱和 | SM 利用率 > 90% 且延迟上升时，应拒绝新请求以保护推理质量 |
| 内存带宽 | Attention 计算对 HBM 带宽敏感，带宽饱和后延迟急剧恶化 | 带宽利用率可作为限流的前置信号，比 QPS 更准确 |
| CPU 预处理 | Tokenizer、图像预处理等 CPU 操作在请求量高时成为瓶颈 | CPU 队列深度 > 2× 核数时，需对预处理阶段单独限流 |
常见误区：仅根据 CPU 或内存使用率来限流 GPU 推理服务。GPU 资源瓶颈（显存、SM、带宽）与 CPU 资源解耦，必须独立监控。推荐使用 NVIDIA DCGM 或 Prometheus GPU Exporter 采集细粒度 GPU 指标。
2.4 异常流量识别方法
异常流量识别是限流熔断策略的“感知层”。需要从统计特征、时序模式和业务语义三个层面建立检测机制。
2.4.1 统计特征检测
- Z-Score 异常检测：计算当前窗口 QPS/延迟的 Z-Score，当 |Z| > 3 时标记为异常。
- 移动平均偏差：使用 EWMA（指数加权移动平均）计算基线，当前值超过基线 ±3σ 时触发。
- 分位点漂移：P99 延迟在 1 分钟内上升超过 50%，即使 QPS 未变，也视为异常。
2.4.2 时序模式识别
- 周期性检测：通过 FFT 或自相关分析识别日/小时级周期，将周期性波动与异常突发区分。
- 突变点检测：使用 PELT 或 Binary Segmentation 算法识别流量均值或方差的突变点。
- 重试风暴识别：统计请求中 HTTP 5xx 响应比例，当 5xx 比例 > 10% 且 QPS 同步上升时，判定为重试风暴。
2.4.3 业务语义异常
- 无效请求洪水：输入序列长度极短（如 1 token）或极长（超过模型最大长度）的请求占比突增。
- 恶意探测流量：请求中携带特殊 token 或 prompt 注入模式，导致模型计算路径异常。
- 上游级联故障：来自同一上游 IP 或服务名的请求延迟同时升高，表明上游已发生故障。
落地实践：建议将异常流量识别模块设计为独立微服务，通过流式处理框架（如 Flink 或 Kafka Streams）消费请求日志，输出异常事件到限流决策引擎。检测延迟应控制在 100ms 以内，避免成为新的瓶颈。
2.5 流量特征与限流策略的映射关系
理解上述特征后，需要将其转化为具体的限流熔断参数。下表总结了不同流量特征对应的策略选择：
| 流量特征 | 推荐限流策略 | 关键参数 | 熔断触发条件 |
|---|---|---|---|
| 高突发（突发比 > 5） | 自适应令牌桶 + 排队等待 | 最大排队时间 500ms，队列深度 100 | 排队时间 > 1s 或队列满 |
| 长尾延迟（P99 > 5s） | 基于延迟的熔断器 | 滑动窗口 10s，P99 阈值 3s | 连续 3 个窗口 P99 超阈值 |
| 显存压力（使用率 > 85%） | 基于资源的限流 | 显存水位线 80%，回退线 70% | 显存 > 90% 持续 5s |
| 重试风暴（5xx 比例 > 10%） | 熔断 + 拒绝重试 | 错误率阈值 10%，最小熔断时间 30s | 错误率 > 10% 且 QPS 上升 |
| 序列长度异常（极短/极长） | 请求内容过滤 + 限流 | 最小长度 10 token，最大长度 4096 token | 异常请求占比 > 20% |
核心原则：流量特征分析不是一次性工作，而是持续演进的闭环。建议建立“特征采集 → 基线建模 → 异常检测 → 策略调整 → 效果评估”的反馈循环，每 24 小时自动更新基线模型，以适应模型迭代和业务变化。