AI 基础设施完整交付包样板¶

样板项目：多模型推理服务 + 成本路由
用途：把“会部署模型”提升到“能证明性能、成本、稳定性权衡”的交付包。

一、需求文档¶

1.1 背景¶

当请求规模上来后，单一模型服务通常会遇到三类问题：

1. 高峰期尾延迟明显恶化
2. 大模型成本过高
3. 切换版本或降级时缺少明确回滚条件

1.2 目标¶

构建一个支持分级路由、流式输出、可观测与灰度回滚的推理服务。

1.3 验收标准¶

二、架构图与技术设计¶

flowchart TD
    U[客户端] --> GW[API 网关]
    GW --> RT[路由层]
    RT --> SM[小模型推理池]
    RT --> LM[大模型推理池]
    RT --> CA[缓存层]
    SM --> OBS[Metrics / Logs / Trace]
    LM --> OBS
    RT --> Q[排队与限流]
    Q --> OBS
    OBS --> AL[告警系统]
    OBS --> RB[回滚与值班 Runbook]

2.1 设计重点¶

• 简单问题优先走小模型，复杂问题再升级到大模型。
• 路由层必须暴露命中率、升级率、降级率。
• 高峰期优先保证稳定，再追求吞吐最大化。

2.2 异常路径¶

• 小模型质量不达标：升级到大模型
• 大模型池拥塞：触发限流或回退简化响应
• GPU OOM：摘除节点并切回上一版本

三、SLO 与核心指标¶

3.1 错误预算¶

• 月度可用性 99.9%，错误预算约 43.2 分钟 / 月。
• 若 P99 连续超标且伴随错误率抬升，立即停止扩量并回滚。

四、压测与 Benchmark 报告¶

4.1 基线¶

• 基线 A：单模型单实例
• 基线 B：单模型 + 批处理
• 当前方案：多模型路由 + 缓存 + 限流

4.2 必测指标¶

4.3 记录模板¶

五、成本报告¶

5.1 成本结论模板¶

• 哪类请求适合小模型
• 哪些请求必须保留大模型兜底
• 路由收益是否足以覆盖系统复杂度增长

六、发布记录¶

七、事故复盘¶

7.1 事故标题¶

某次量化版本上线后，吞吐提升但尾延迟和质量同时恶化。

7.2 现象¶

• 平均吞吐变好
• P99 明显变差
• 部分复杂请求质量下降

7.3 根因¶

• 压测只看平均吞吐，忽略尾延迟
• 路由阈值没有随模型能力变化同步调整

7.4 处置¶

• 回滚到上一版本
• 新增按请求类型分桶压测
• benchmark 报告必须同时展示 TTFT / P95 / P99 / 成功率

7.5 追踪动作¶

1. 灰度前必须做复杂请求集回归
2. 路由阈值改为配置化
3. 事故后补值班 Runbook 与回滚脚本检查项

八、简历条目¶

• 设计并实现多模型推理服务，建立 TTFT、P95/P99、GPU 利用率、成本等指标闭环，具备灰度、限流、降级与回滚能力。
• 构建推理 benchmark 与事故复盘体系，能够从平均吞吐、尾延迟、任务成功率三条线同时评估优化收益与风险。

九、面试讲解结构¶

1. 问题定义：为什么只看吞吐是不够的
2. 架构设计：路由、缓存、限流、观测、回滚
3. benchmark：如何对比基线与优化方案
4. 事故复盘：量化带来吞吐收益但损伤尾延迟
5. trade-off：性能、质量、成本、复杂度如何取舍

十、配套文档¶

• AI 基础设施交付线
• 可观测性、告警分级与值班 Runbook
• 容量规划与故障注入检查清单