项目故事（STAR 格式）
用结构化的项目叙事框架，把你的技术经验变成面试官能记住的故事
项目故事讲述框架
五步法叙事结构
背景（Background）→ 挑战（Challenge）→ 方案（Solution）→ 结果（Result）→ 复盘（Retrospective）
每个环节的篇幅建议：
| 环节 | 篇幅 | 要点 |
|---|---|---|
| 背景 | 15%（约 1 句） | 业务场景、你的角色 |
| 挑战 | 20%（约 1-2 句） | 技术难点、资源约束 |
| 方案 | 40%（约 3-5 句） | 具体做了什么、为什么这么做 |
| 结果 | 15%（约 1-2 句） | 量化数据、业务影响 |
| 复盘 | 10%（约 1 句） | 学到了什么、如果重来怎么做 |
讲述节奏控制
- 1 分钟版本：挑战 → 方案核心 → 结果（适合技术面快速问答）
- 3 分钟版本：完整五步法（适合 Manager 面或深度追问）
- 5 分钟版本：五步法 + 细节展开 + 架构图（适合项目深挖环节）
项目故事模板
故事一：70B 大模型生产部署
背景：
业务线需要接入 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 人月的工作量。
如果未来社区版本覆盖了我们的需求，应该尽快迁移回上游。
如何用量化指标展示成果
关键指标体系
在讲述任何项目时，尽量用以下指标量化成果：
| 指标类别 | 具体指标 | 示例 |
|---|---|---|
| 性能 | P50/P99 延迟、TTFT | P99 从 800ms 降到 400ms |
| 吞吐 | QPS、tok/s | 吞吐从 50 tok/s 提升到 120 tok/s |
| 成本 | GPU 数量、单请求成本 | GPU 减少 37.5%，年节省 X 万 |
| 资源 | GPU 利用率、显存利用率 | GPU 利用率从 45% 到 75% |
| 质量 | 精度损失、SLA | PPL 增长 4.8%，SLA 99.9% |
| 效率 | 上线时间、MTTR | MTTR 从 30 分钟到 5 分钟 |
| 团队 | 晋升人数、技术分享数 | 团队 3 人晋升，12 场技术分享 |
量化公式模板
成果 = 指标名称 + 优化前值 + 优化后值 + 改善幅度 + 业务影响
示例："GPU 利用率从 45% 提升到 75%，意味着同样数量的 GPU 能服务的请求量增加了 67%，
相当于每年节省了约 200 万的硬件成本。"
项目复盘的关键点
复盘四问
每个项目故事最后都应该有一个简短复盘，回答以下四个问题：
-
做对了什么：项目中哪些决策和方法是有效的？
- "INT8 量化的选择是正确的，精度损失在可接受范围内"
-
做错了什么：哪些环节可以做得更好？
- "灰度发布的时间太短，差点漏掉边界 case"
-
如果重来会怎么做：基于事后认知的改进方案
- "一开始就建立 benchmark 体系，而不是上线后再补"
-
提炼了什么方法论：可复用的经验和教训
- "任何优化方案都应该先做 AB 测试再全量切换"
复盘的价值
面试官特别看重复盘能力，因为：
- 体现你有自我反思的习惯
- 证明你对项目有全局理解（不只是执行者）
- 展示你能从经验中提炼方法论（可迁移的能力）
- 表明你有持续改进的思维
面试视角：项目讲述的注意事项
- 准备 3-5 个故事：覆盖不同类型（部署、优化、扩容、故障、创新）
- 每个故事有记忆点：用一句话概括项目核心（如"把 GPU 成本砍掉 40%"）
- 能画图：每个故事都准备一张简化的架构图，能白板画出来
- 数据可验证：准备的数据要真实可信，面试官可能追问细节
- 准备深挖版本：每个故事准备一个 5-8 分钟的深度版本，应对 Manager 面的追问
- 关联岗位：在讲述时自然关联到 FDE 岗位需要的能力（技术深度、工程能力、管理思维）
下一节：行为面试