17.3 从需求到部署、压测与监控
选型决策、技术叠加与端到端交付
一条请求的源码与数据流复盘
假设系统收到 1024 token prompt、最多生成 32 token、当前有其他运行请求。追踪时不要先问“用了哪些优化”，先在每一步记录状态：
| 阶段 | 输入/输出 | 状态改变 | 应测量/验证 |
|---|---|---|---|
| API/tokenizer | 文本→token_ids | 建 Request | token 数、模板和特殊 token |
| Admission/Scheduler | waiting→本轮计划 | 占 token 预算与 KV 块 | 排队时间、block free、prefix hit |
| Prefill | packed tokens→最后 logits | 写 1024 份 KV（可分 chunk） | position、mask、TTFT、GEMM/Attention 时间 |
| Sampler | logits→首 token | 更新输出与停止条件 | seed、top-p/top-k、logit 差异 |
| Decode loop | 1 token→下一个 logits | 每步追加 KV、动态混批 | TPOT、KV 带宽、Graph 命中 |
| 完成/取消 | 输出→流式响应 | 释放或缓存 KV | 请求生命周期、块守恒、尾延迟 |
工程练习 A：实现。在一张 GPU 上跑 RMSNorm → RoPE → Attention → logits 的最小 PyTorch reference；分别替换一个 CUDA/Triton Kernel，每次用固定输入检查 allclose 与边界 shape。工程练习 B：服务。运行 CPU-only 的 MiniEngine 示例，以两条不同长度请求模拟连续批处理，打印每轮 request_id / computed / scheduled / physical blocks / free blocks；再自行扩展到三条请求与 Prefix 共享。工程练习 C：诊断。人为注入错误的 RoPE position 与缺少 release，分别使用逐层比较和块守恒定位；再给一个 GEMM 做 Roofline/NCU 记录。
验收标准：能画出 API→Scheduler→KV Manager→ModelRunner→Attention Backend→Sampler 调用链；能解释 vLLM 的分页缓存与迭代调度、FlashAttention 的 IO tiling、PagedAttention 的逻辑到物理映射；能用一个实测指标和一个反证排除错误瓶颈假设。源码导读从上一章的链接进入，按固定版本记录，不把“框架一定如此”写成跨版本定论。
可交付的部署实验包
按“需求与输入分布 → 环境和模型版本 → Baseline → 单项实验 → 组合验证 → 容量与上线”组织目录。每一步保存可复现命令、原始请求 / 响应统计与变更原因，而不只保留最终最佳值。
交付物至少包含配置表、任务质量表、压力曲线、错误 / 取消记录、内存账本、关键时间线、容量估计和回退路径。第 14 章检查产品协议，第 16 章检查长期服务，第 18 章检查资源受限设备；同一个模型在这些环境里的最佳方案可能不同。