问题1：SLO 定义中「延迟」从何时开始计时？

典型争议：合同写「P99延迟≤300ms」，但未明确是否包含队列等待时间。某客户投诉：「我的请求在队列卡了2秒才进GPU，这算违约吗？」这种情况在工程实践中非常普遍，特别是在高峰流量期间，队列积压会成为延迟的主要来源。

工程事实： - DeepSeek 推理栈默认策略：从请求进入执行队列（即获GPU资源）开始计时，排队时间不计入SLA。技术上通过API网关的X-Request-Start时间戳标记，确保只计算实际GPU计算时间。 - 反例警示：若将排队纳入统计，需承诺「最大排队时长」（如50ms），否则突发流量下必然违约。某团队曾因未隔离排队时间，P99飙至800ms被罚款。这个案例说明，不合理的延迟定义会导致不可控的SLA违约风险。

技术细节： 1. 时间戳埋点：在vLLM引擎的SamplingParams中注入start_time字段，确保仅计算实际执行耗时。这个埋点需要精确到微秒级，避免时间统计误差。 2. 队列监控分离：使用Prometheus的histogram_quantile函数分别统计execution_latency和queue_latency，这两个指标必须分开监控和告警。 3. 合同陷阱：警惕「端到端延迟」这类模糊表述，必须明确定义测量起止点。建议在合同中明确写出类似「延迟测量从请求获得GPU资源开始，到最后一个token返回结束」的条款。

补充建议： - 在API文档中明确说明延迟的计算方式，避免客户误解 - 为关键客户提供队列延迟的独立监控视图 - 考虑实现动态排队超时机制，当排队时间超过阈值时自动拒绝请求

问题2：如何设计容量模型守住300ms底线？

关键参数： 1. 并发与批处理：DeepSeek-V4在A100-80G上，FP16精度时单卡最优并发为8（实测bs=8时P99=280ms，bs=16骤增至520ms）。这个非线性增长关系说明批处理大小对延迟影响巨大。 2. KV Cache命中率：连续对话场景需预热cache，首轮请求延迟可能达450ms，后续轮次可稳定在200ms内。这表明有状态的推理服务需要特殊的容量规划。 3. 动态降级：当队列深度＞10时自动触发： - 短上下文优先（截断至4k tokens） - 非关键请求转异步模式 这种降级策略可以有效防止系统过载。

检查清单： - [ ] 压力测试需覆盖bs=1/4/8/16四种场景，确保全量程性能可预测 - [ ] 监控看板分离「排队延迟」与「执行延迟」，设置独立的告警阈值 - [ ] 错误预算消耗速率报警阈值设为每小时5%，提前预警SLA风险

容量规划实战： - 计算实例数公式：实例数 = 峰值QPS/(单卡最优并发×每卡吞吐) - DeepSeek-V4基准值：在AWS p4d实例（8×A100）上： - 4k上下文：单卡吞吐32 req/s（P99=290ms） - 32k上下文：单卡吞吐9 req/s（P99=610ms） 这个数据说明上下文长度对吞吐量影响巨大。 - 冷启动补偿：预留20%缓冲实例应对KV cache未命中场景，这是保证稳定延迟的关键。

补充建议： - 实现基于预测的自动扩缩容，而不仅依赖实时指标 - 为不同上下文长度配置不同的服务等级 - 定期重新校准基准性能数据，模型迭代后要及时更新

问题3：合同条款怎么写才能技术可行？

避坑条款示例：

"服务延迟"指从请求获GPU资源到返回最后一个token的时间，排除：
a) 网络传输时间
b) 客户端处理时间
c) 排队等待时间
补充承诺：95%请求排队时长≤100ms（需配合自动扩缩容）

这种明确定义可以避免90%的SLA争议。

血泪案例： 1. 金融客户陷阱：要求「端到端P99≤200ms」但未排除网络波动，团队被迫部署边缘节点导致成本翻倍。这个案例说明模糊的SLA定义会带来巨大的隐性成本。 2. 医疗行业教训：合同未定义「超时」是否包含人工审核时间，引发法律纠纷。这表明SLA必须明确每个时间段的归属。

条款谈判技巧： - 坚持使用服务端可观测到的延迟作为唯一指标，避免依赖客户端数据 - 对「上下文长度」「并发数」等关键参数设置明确上限，防止性能不可控 - 要求客户承诺流量突增不超过基线200%，保护系统稳定性

补充建议： - 在合同中加入「技术可行性审查」条款 - 为特殊要求设置附加费用条款 - 明确SLA的测量方法和数据来源

边界讨论：什么时候该拒绝SLA承诺？

高风险场景： - 需支持＞16k上下文且要求低延迟（DeepSeek-V4在32k满上下文时P99约650ms） - 客户不接受动态降级（如医疗问答必须完整响应） - 无法控制上游流量突发（如电商秒杀场景） 这些场景都可能超出技术能力范围。

替代方案： - 按token计费：将延迟风险转移为成本问题 - 分级SLA： - 黄金级：P99≤300ms（额外收费） - 白银级：P95≤300ms（默认） - 青铜级：异步响应（成本最低） 这种分级策略可以提供灵活的解决方案。

补充建议： - 建立SLA可行性评估流程 - 为高风险场景设计专门的架构方案 - 保持一定的技术余量应对突发情况

运维应急预案（检查清单）

1. 【熔断】当连续3分钟P99＞350ms时：
2. 自动拒绝新会话请求
3. 现有请求降级至8k上下文
4. 【扩容】队列深度持续＞15时：
5. 自动拉起spot实例
6. 流量切换至低精度模型（如FP16→INT8）
7. 【补偿】错误预算耗尽后：
8. 暂停计费直至恢复
9. 发送事故报告（含根本原因分析） 这个预案需要定期演练。

补充建议： - 建立多级应急响应机制 - 实现自动化的故障转移能力 - 保持足够的应急资源储备

总结：SLA是技术能力与商业博弈的平衡

• 技术底线：必须明确定义测量指标与边界条件，这是SLA可执行的基础。
• 成本公式：延迟每降低100ms，基础设施成本可能增加40-60%，这个trade-off必须清晰传达给客户。
• 最佳实践：先用非关键业务验证SLA可行性，再逐步扩大承诺范围，这种渐进式策略可以控制风险。

最终建议：建议团队建立SLA设计指南，包含技术可行性检查表、合同条款模板和应急响应流程，这将系统性提升SLA管理能力。同时要定期review现有SLA的执行情况，持续优化技术实现和商业策略。