M53：设备约束下的 Serving：质量—内存—速度三角

内容类型：预习教材（不代表已完成）
日期：2026-10-15
阶段：P1 · AI Model Engineering 90
周次：W8 · 推理、KV Cache、量化与 serving
节奏：周四案例与连接
状态：教材已备；学习未完成
标签：serving、batching、context、quantization、device-constraints

一句话定义

设备约束下的推理设计是在模型质量、权重与 KV 内存、首 token/生成速度及并发之间选择工作点，而不是寻找所有维度同时最优的配置。

学习目标

1. 能分析 batch、context、量化、cache 和本地后端的相互影响。
2. 能把工作负载映射到质量—内存—速度三角。
3. 能形成一个有假设、有降级顺序的设备约束案例。

核心知识

Batch 增加可提高矩阵利用率和总吞吐，但每个并发序列都需要 cache，且等待凑 batch 会增加延迟。continuous batching 能缓解固定批次浪费，却增加调度复杂度。

Context 增长提高可用输入范围，但 prefill 计算、attention 和 cache 内存上升。最大 context 是能力上限，不等于每个请求都应填满；检索裁剪、分块或分层摘要常比盲目加长更经济。

Quantization 降低权重字节，并可能使更多模型放入本机内存。质量影响取决于位宽、量化粒度、校准数据、异常通道和后端实现。低位权重仍可能用更高精度做部分累加或 KV cache。

Cache 策略在重复前缀、会话和并发中决定内存换计算。Prefix cache 可复用相同系统提示，但必须确保缓存键包含模型、模板、权限和内容版本，避免跨用户泄漏。

后端如 MLX、llama.cpp 或平台原生运行时，有不同内核、模型格式、量化支持与设备路径。模型规格相同不保证端到端行为和性能相同。

机制/推导

一个简化容量约束是：

可用内存 ≥ 权重 + KV cache × 并发 + 临时张量 + 运行时余量

若不满足，可以按任务价值选择：减少并发、缩短 context、量化权重/KV、使用更小模型或迁移设备。顺序并非固定。实时助手可能先保延迟，批处理可牺牲延迟换吞吐；高风险字段抽取可能先保精度。

质量—内存—速度三角并不意味着每次优化必有损失；更好内核可能同时改善速度和内存。但在固定设备和成熟实现下，极端参数通常带来取舍，应以测量而非口号判断。

最小练习或观察步骤

1. 选择设备与工作负载：例如 16GB 本机、8k 文档问答、最多 2 个并发。
2. 列出权重、KV cache、上下文、输出和运行时余量的粗略内存预算。
3. 写三个候选配置：大模型低并发、小模型高并发、量化模型中等 context。
4. 为每个配置预测 TTFT、吞吐、质量风险和内存风险，并明确这些只是待测假设。
5. 定义降级顺序：内存不足先改什么，延迟超标先改什么，质量下降先回退什么。
6. 画三角图，将三个配置放入相对位置，不需要虚构数值。

常见误区

• 最大上下文越长，实际请求质量必然越好。
• 量化只影响内存，不可能影响生成。
• Prefix cache 只看文本相同，不把租户和权限纳入缓存键。
• 只按模型参数量估算并发容量，忽略 KV cache。
• 用离线批处理 benchmark 代表在线交互体验。

金融 / Web3 / 文档场景连接

本地处理敏感文档可减少数据外发，却把内存、模型更新和审计责任带到设备端。跨客户复用 prefix cache 尤其需要隔离；链上分析若包含长交易历史，可先聚合结构化事实，再把有限证据交给模型，而非全部塞入 context。

自检问题

1. batch 增大为何可能同时提高吞吐和增加延迟？
2. 权重能装入内存为何不代表并发可行？
3. Prefix cache 的安全缓存键应包含哪些边界？
4. 什么工作负载会优先牺牲吞吐来保质量或延迟？

专业课程对齐

• 精读 Stanford CS336 的 inference systems、memory accounting 与 parallelism 课题，将设备预算拆成 weights、KV cache、temporary tensors 和 runtime headroom。
• 精读 vLLM PagedAttention 的分页 cache 设计，理解连续逻辑序列与非连续物理块如何支持并发。
• 选读 PyTorch Tutorials 的 quantization、performance tuning 与 profiler 主题，仅用于校验后端是否真正使用目标 dtype/kernel。

深入学习提示

先按 CS336 做静态内存表，再用 vLLM 理解动态 cache，最后考虑量化。为一个明确工作负载手算 available ≥ weights + KV_per_request×concurrency + temp + margin，并把 TTFT、TPOT、throughput、quality 和 coverage 作为独立列。代码/配置路径要确认实际 context 上限、KV dtype、prefix-cache key 与 batch scheduler，避免跨权限复用前缀。反例是量化权重缩小 50% 就假定总内存同比下降，或为追求总 tokens/s 增大 batch，却忽略交互请求的排队延迟。

学后填写区

• 设备与工作负载：
• 三个候选配置：
• 最大资源风险：
• 我的降级顺序：
• 需要真实测量的假设：