争议点：排队时间是否该计入SLO

某金融客户合同要求「P99延迟≤300ms」，技术团队坚持「从请求进入执行队列开始计算」。用户实际体验的排队2秒被「合法」排除在外——这是技术正确还是商业欺诈？

工程现实：队列延迟的四种来源

1. 突发流量毛刺：DeepSeek-V4的vLLM后端默认采用paged attention，单个请求KV cache分配延迟约15-50ms，但突发流量会导致调度器排队
2. 长文本惩罚：32k上下文请求会挤占推理槽位，实测显示8k与32k请求混合部署时，短文本P99延迟可能恶化3倍
3. 冷启动代价：未预热模型分片首次加载需300-800ms（视显存带宽），AWS EC2 g5.2xlarge实测数据
4. 批处理反作用：为提高吞吐开启dynamic batching后，首个请求常需等待batch_size填满，在低QPS时段人为增加延迟

技术实现细节

vLLM调度器工作原理

DeepSeek-V4基于vLLM的BlockManager实现动态显存分配，每个请求会被拆分为多个逻辑块（block）。当并发请求数超过可用block时，请求进入等待队列。关键参数包括： - block_size：默认64（对应128 tokens） - max_num_seqs：单卡最大并行序列数（受显存限制） - preemption_mode：抢占策略（recompute/swap）

混合精度推理优化

采用FP16计算+INT8 KV cache的混合精度方案，相比纯FP16可减少约40%显存占用。但需注意： - 当上下文长度>16k时，INT8量化误差可能累积 - 需在模型加载时指定quantization="int8-kv"参数

SLO分层定义方案（含DeepSeek实践）

层级1：端到端承诺（含队列）

• 适用场景：直接面向终端用户的API产品
• 监控项：从TCP握手完成到最后一个token返回的时间
• DeepSeek-API现行标准：免费版承诺P99≤800ms（含排队），实测今年Q3数据为724ms
• 实现方案：
• 在Nginx层注入$request_time变量
• 对gRPC流式响应使用bidirectional streaming时间戳

层级2：纯推理时间

• 适用场景：私有化部署后的内部系统集成
• 监控项：/generate接口从第一个block输出到结束的时间
• 典型值：A100 80GB单卡运行DeepSeek-V4-32k，FP16精度下P99≈210ms
• 测量方法：
• 使用vLLM原生stats接口获取execution_time
• 排除prefill阶段的解码耗时

容量规划检查清单

1. 显存占用建模：
2. 每并发所需显存 = 模型参数量 * 精度 + KV cache（batch_size * seq_len * 2 * hidden_size * num_layers / tensor_parallel）
3. DeepSeek-V4-32k在FP16下实测每并发约28GB
4. 熔断策略：
5. 当队列深度＞3倍平均处理时间时触发HTTP 503
6. 动态禁用长上下文请求（＞16k）优先保障短文本SLO
7. 补偿措施：
8. 对超时请求返回已生成的部分结果+incomplete=true标记
9. 异步回调机制（需配合Server-Sent Events断线重连）

错误预算的实战算法

# 以月度SLO 99.9%为例
def error_budget_calc():
    total_seconds = 30 * 86400  # 一个月秒数
    allowed_downtime = total_seconds * (1 - 0.999)  # 259秒
    burn_rate = (violation_seconds / allowed_downtime) * 100
    if burn_rate > 200:  # 双倍消耗时触发告警
        trigger_scale_out()

观测体系关键指标

1. Prometheus指标：
2. deepseek_inference_queue_duration_seconds（分bucket统计）
3. vllm_kv_cache_utilization_ratio（＞0.8时预警）
4. OpenTelemetry埋点：
5. 在API网关注入X-Request-Start时间戳
6. 对gRPC流式响应标注每个chunk的服务器端耗时

典型故障场景处理

案例1：KV cache碎片化

现象：P99延迟周期性飙升至1.2s 根因：长时间运行后block分配产生外部碎片 解决方案： - 启用block_reuse_policy="lru"参数 - 每4小时主动重启worker（需配合模型预加载）

案例2：显存泄漏

现象：延迟随uptime线性增长 排查工具： - nvidia-smi --query-gpu=memory.used --format=csv -l 1 - vLLM的memory_stats API 修复方案： - 限制最大并发请求数 - 升级至vLLM 0.3.2+修复known memory leak

合同条款建议

1. 必须明确定义：
2. 延迟起算时间点（请求到达网关/进入执行队列）
3. 排除场景（冷启动、用户侧网络问题等）
4. 推荐补充条款：
5. 最大排队时长SLA（如P95≤500ms）
6. 超时补偿方案（部分结果返回/积分补偿）

最终建议：ToB合同必须定义「延迟起算点」，技术团队若坚持排除队列时间，则应额外承诺「最大排队时长SLA」——这在负载均衡器配置中是可测量的。同时建议采用混合SLO策略：基础版承诺含队列时间，高级版可购买专属计算资源获得纯推理时间保障。