背景（Background）→ 挑战（Challenge）→ 方案（Solution）→ 结果（Result）→ 复盘（Retrospective）

背景：
业务线需要接入 70B 大模型能力，用于 [具体场景]。但公司只有 4 张 A100-80G GPU。

挑战：
- 70B 模型 FP16 显存约 140GB，单卡放不下
- 延迟要求 P99 小于 500ms，不能接受明显降级
- 需要在 2 周内完成从选型到上线的全过程

方案：
1. 推理引擎选型：对比 vLLM、TGI，最终选择 vLLM（Continuous Batching + PagedAttention）
2. 量化方案：INT8 量化（权重 + KV Cache），显存从 140GB 降到 70GB
3. 并行策略：Tensor Parallel（TP2），模型切分到 2 张卡
4. 部署架构：基于 K8s，每个 Pod 挂载 2 张 GPU，HPA 自动扩缩容
5. 监控体系：GPU 利用率、延迟、吞吐、错误率 4 个核心 dashboard

结果：
- P99 延迟 400ms，吞吐 100 tok/s，GPU 利用率 75%
- 按时上线，支撑了 [X] 个业务线
- 成本比预期方案降低约 30%

复盘：
如果重来，我会更早引入 Prefix Caching（在 multi-turn 场景下 TTFT 可再降 50%），
并且在一开始就建立更完善的 benchmark 体系，而不是上线后再补。

背景：
线上 13B 模型运行了 3 个月后，GPU 成本成为业务增长的瓶颈。
管理层要求"在保持服务质量的前提下降低 40% GPU 成本"。

挑战：
- 量化后精度不能明显下降（业务要求 小于1% 的精度损失）
- 线上服务不能中断，需要平滑切换
- 需要验证量化效果后再全量切换

方案：
1. 量化选型：
   - 对比 INT8、INT4、FP8（虽然 A100 不支持 FP8，但评估了未来迁移成本）
   - 最终选择 INT8，因为精度损失可控（小于0.5%），且工具链成熟
2. 精度验证：
   - 在 WikiText-2 上计算 PPL：FP16 = 6.2 提升到 INT8 = 6.5（增长 4.8%，可接受）
   - 业务 AB 测试：用户满意度无显著差异（p 大于 0.05）
3. 灰度发布：
   - 先切 5% 流量到量化模型
   - 观察 48 小时无异常后，逐步提升到 50%、100%
4. 成本核算：
   - INT8 量化后，单实例可服务的请求数翻倍
   - GPU 数量从 16 张减少到 10 张

结果：
- GPU 数量减少 37.5%（16 减少到 10 张），年节省约 [X] 万元
- P99 延迟从 350ms 降到 280ms（量化减少了计算量）
- 精度损失 小于0.5%，用户无感知

复盘：
最大的教训是灰度发布的时间应该更长。我们在 5% 流量只观察了 24 小时
就加速到 50%，差点漏掉一个边界 case。后来建立了 72 小时的灰度标准。

背景：
公司计划上线大模型服务，但业务量不确定（可能从日均 1 万到 10 万请求）。
需要一套既能扛峰值又不至于平时浪费 GPU 的弹性方案。

挑战：
- GPU 资源昂贵，不能按峰值全量配置
- 推理服务的启动时间较长（模型加载 1-2 分钟），不能临时起实例
- 需要保证 SLA 99.9%

方案：
1. 容量规划：
   - 基准：单实例（1 张 A100）支撑峰值 QPS = [X]，P99 小于 500ms
   - 预估日均 1 万请求，需要 2 实例
   - 预估峰值 10 万请求，需要 20 实例
2. K8s 弹性方案：
   - HPA：基于自定义指标（QPS + 延迟）自动扩缩容
   - 预热池：始终保持 3 个预热实例（模型已加载），秒级接管流量
   - 冷启动队列：新实例按需启动，模型预加载完成后加入服务
3. 成本控制：
   - 缩容到最低 2 实例（覆盖基础负载）
   - 使用 Spot 实例降低扩容成本（约节省 60%）

结果：
- 在实际运行中，峰值 QPS 达到 [X] 时自动扩容到 15 实例，SLA 99.95%
- 平均 GPU 利用率从固定部署的 30% 提升到弹性部署的 65%
- 相比固定部署方案，GPU 成本降低约 55%

复盘：
Spot 实例虽然便宜，但存在被回收的风险。我们遇到过一次 Spot 实例被回收
导致延迟短时升高的事件。后来引入了多 AZ 部署 + 快速迁移机制，
确保单节点故障不影响整体 SLA。

背景：
某天凌晨，线上推理服务的 P99 延迟从 400ms 突然飙升到 2000ms，
持续了约 30 分钟，影响了 [X] 个业务线。

挑战：
- 故障发生在凌晨，团队不在岗
- 需要快速定位根因并恢复服务
- 事后需要建立预防机制

方案：
1. 快速响应：
   - 告警触发后 5 分钟内响应
   - 先看监控大盘：单个实例延迟异常，其他实例正常
2. 排查过程：
   - 检查 GPU 利用率：异常实例 GPU 利用率 100%，但吞吐极低
   - 检查 KV Cache 使用率：接近 100%，说明显存耗尽
   - 检查请求日志：发现某个业务线发了大量超长 prompt（8000+ token）
3. 紧急修复：
   - 重启异常实例（1 分钟恢复）
   - 临时限制 prompt 长度 小于 4096
4. 长期方案：
   - 启用 prompt 长度自动检测和告警
   - 超长 prompt 路由到专用大 batch 实例
   - 建立 prompt 长度分布的持续监控

结果：
- 故障持续时间从 30 分钟缩短到 MTTR 小于 5 分钟
- 同类故障零复发
- 建立了完整的异常检测和自动防御机制

复盘：
这次故障暴露了我们两个问题：
1. 缺乏对输入长度的保护和监控（应该在上线时就做）
2. 告警策略不够精细（GPU 利用率高但吞吐低，这本身就是异常信号）

后来我们把"高 GPU 利用率 + 低吞吐"加入了告警规则。

背景：
开源 vLLM 在某些场景下表现不够理想（如超长文本、特殊 batch 模式），
需要对核心模块进行定制化改造。

挑战：
- 需要在不影响稳定性的前提下修改核心代码
- 改造后需要和上游版本保持同步
- 需要充分测试，确保不会引入新 bug

方案：
1. 问题分析：
   - 通过 profiling 发现 scheduler 在处理大量长 prompt 时效率较低
   - 根因：prefill 任务排队策略不够智能
2. 方案设计：
   - 修改 scheduler 的优先级策略：短 prompt 优先，长 prompt 延迟调度
   - 实现 chunked prefill 的调优版本
3. 测试验证：
   - 建立完整的 benchmark suite（覆盖 prefill、decode、混合场景）
   - CI 集成，每次 commit 自动跑 benchmark
4. 上游同步：
   - 改造代码尽量保持和上游接口兼容
   - 定期 cherry-pick 上游安全 patch

结果：
- 长 prompt 场景下的 P99 延迟降低 40%
- 混合负载下吞吐提升 25%
- 改造方案后来被社区部分采纳

复盘：
二次开发的成本比预期高。维护 fork 版本需要投入至少 0.5 人月的工作量。
如果未来社区版本覆盖了我们的需求，应该尽快迁移回上游。

成果 = 指标名称 + 优化前值 + 优化后值 + 改善幅度 + 业务影响

示例："GPU 利用率从 45% 提升到 75%，意味着同样数量的 GPU 能服务的请求量增加了 67%，
相当于每年节省了约 200 万的硬件成本。"

技术指标 → 商业语言 的转换示例：

"P99 延迟从 800ms 降到 400ms"
  → "用户体验提升了一倍，客户投诉率降低 60%，CSAT 从 3.8 提升到 4.5"

"GPU 利用率从 45% 提升到 75%"
  → "同等 GPU 资源下服务能力提升 67%，相当于年节省约 200 万硬件成本"

"SLA 从 99% 提升到 99.9%"
  → "月度不可用时间从 7.3 小时降到 43 分钟，核心业务中断风险降低 90%"

"支持了 3 条新业务线"
  → "为每条业务线节省了一个月的开发周期，整体上市时间提前 6 周"