关卡阅读材料 // 07
机架级推理
把四位量化、Prefill / Decode 分工、KV Cache 路由与故障恢复组合成机架级推理系统，同时保留清晰的状态边界。
建议边读边写下答案；时长包含代码推演与练习。
进入互动关卡→- 01导读与目标05 MIN
- 02心智模型08 MIN
- 03概念深挖15 MIN
- 04代码推演12 MIN
- 05历史生态08 MIN
- 06练习复盘12 MIN
Learning Path 从加速应用继续延伸到端到端工作流、网络与 AI 基础设施；性能分析必须覆盖计算、数据移动和系统编排。
本课是超出 CUDA 基础的系统综合：NVFP4 处理数值与搬运，Prefill/Decode 处理服务阶段，KV 路由与迁移处理网络和故障状态。
- 课程 03、05、06
- 理解 KV Cache
- 基本请求路由与健康检查概念
- Dynamo 或 TensorRT-LLM（可选）
- Nsight Systems
- Prometheus / 请求日志
- NIXL / RDMA 环境（高级）
导读与目标
先记住这一句
压缩必须带 Scale，放置必须理解阶段，恢复必须知道状态在哪里。
完成后你应该能够
- 01
解释 NVFP4 的 E2M1、微块 E4M3 Scale 与 Tensor FP32 Scale。
- 02
比较聚合与分离式 Prefill / Decode 的收益、成本和适用流量。
- 03
设计 Cache-aware、Load-aware 与 Topology-aware 的路由判断。
- 04
把 Worker、Token、KV Cache、端点和 Retry 拆成可恢复状态。
建立心智模型
- 01压缩
NVFP4 用 E2M1 保存数值，每 16 个值共享 E4M3 Scale，并用 FP32 Tensor Scale覆盖全局范围。
- 02分工
Prefill 处理 Prompt 并生成 KV Cache；Decode 依赖缓存持续生成 Token，两者的扩容压力不同。
- 03恢复
Worker、已输出 Token、KV Cache、端点健康与 Retry 分属不同状态边界，故障策略必须逐一处理。
概念深挖
低位数需要更细粒度范围
只有全局 Scale 时，离群值会挤压其它数值；微块 Scale 让局部值更充分利用 E2M1 范围。
分离式推理增加 KV 路径
独立扩容 Prefill 与 Decode 的代价是显式传输或暴露 KV Cache，收益必须用真实流量验证。
请求状态不等于 KV Cache
迁移可保留已输出 Token 与重试信息，但缓存是否幸存取决于后端与故障类型，可能需要重建或重传。
两级缩放把局部与全局范围分开
E2M1 只有极少的可表示值，直接 Cast 会让饱和与舍入非常严重。NVFP4 为每 16 个连续值使用一个 E4M3 微块 Scale，让局部离群值只影响自己的小块；再用每张量 FP32 Scale 覆盖 E4M3 Scale 本身无法表达的全局范围。
更细粒度 Scale 会增加元数据、量化逻辑和布局约束。模型是否保持质量仍取决于权重与激活分布、校准或训练方法以及算子支持。四位表示降低了存储与搬运，但不能被描述成无需验证的等价替换。
停下来想一想为什么每 16 个值的 Scale 之外还要 Tensor FP32 Scale？＋
参考答案E4M3 微块 Scale 本身的动态范围有限；第二级 FP32 Scale 负责覆盖整个张量的全局范围并避免 Scale 溢出。
Prefill 与 Decode 是两种资源曲线
Prefill 一次处理 Prompt Token，通常包含较大的矩阵计算并生成 KV Cache；Decode 每步生成少量 Token，却要反复读取已积累的 KV Cache，更受并发、输出长度与缓存容量影响。把两者放在同一 Worker 最简单，但长 Prompt 可能阻塞持续 Decode。
分离式服务让两个 Pool 独立配置 TP 与副本数量，却把 KV 传输加入关键路径。只有当阶段干扰、扩容独立性或缓存复用收益超过传输与编排成本时，它才值得。需要用真实 Prompt/Output 分布比较聚合与分离方案。
停下来想一想短 Prompt、短输出且单机低负载时，分离式服务一定更快吗？＋
参考答案不一定。KV 传输与路由增加固定开销，简单聚合 Worker 可能更合适。
恢复必须先画状态地图
一次流式请求至少包含原始 Prompt、采样参数、已输出 Token、随机状态、KV Cache 位置、当前 Worker 与 Retry 计数。Worker 失效时，有些状态在前端，有些在缓存服务，有些只在失效进程显存中。恢复策略必须说明每一项从哪里取回。
请求迁移可以把已输出 Token 与请求元数据交给健康 Worker，避免客户端无限等待；KV Cache 可能被远端保存、重新传输，或从 Prompt 与 Token 重建。健康检查需要先从服务发现中移除故障端点，并用 Retry Limit 防止故障风暴。
停下来想一想只保存已输出 Token，能否无成本恢复 Decode？＋
参考答案不能保证。新 Worker 仍需要对应 KV Cache；若缓存未保存或不可访问，就需要重传或重新 Prefill。
把概念放回代码
01prefill = router.pick_prefill(prompt, cache_overlap)02kv_meta = prefill.run(prompt)03decode = router.pick_decode(load, topology)04stream = decode.resume(kv_meta, emitted_tokens)05if decode.unhealthy():06 migrate(request_state, healthy_worker, retry_limit)代码逐段推演
- 01PREFILL按缓存重叠与负载选择生产者
已有前缀缓存的 Worker 可减少重复 Prefill，但选择还要考虑排队与拓扑。
- 02KV META传递位置与格式，而非假装缓存消失
元数据应描述缓存块、传输端点、模型版本、dtype 与布局，让 Decode 能正确接收。
- 03DECODE在负载与拓扑间选消费者
低负载 Worker 若跨越更昂贵链路也未必最优；路由需要综合分数与健康状态。
- 04MIGRATE迁移请求状态并限制重试
先移除故障端点，再保留已发 Token、恢复或重建 KV，并确保客户端不会收到重复片段。
知识图谱
补充参考 · 不要求一次读完，也不计入核心 60 分钟
核心术语
- NVFP4
- 面向 Blackwell Tensor Core 路径的 4 位浮点 Recipe，使用更细粒度的局部 Scale 与更高层级 Scale 管理动态范围。
- Prefill
- 并行处理 Prompt、生成首个输出所需状态和 KV Cache 的阶段，通常更偏计算密集。
- Decode
- 复用 KV Cache 逐步生成新 Token 的阶段，常受显存容量、带宽和并发影响。
- KV Cache
- 保存各层历史 Key/Value 的状态，使 Decode 不必为每个新 Token 重算整个上下文。
- TTFT / ITL
- 首 Token 延迟与 Token 间延迟，分别观察请求启动体验和持续生成节奏。
带数字推演
- 01代入公式
2 × 32 × 8 × 128 × 4096 × 2 = 536,870,912 字节。
- 02换算容量
单请求约 512 MiB；8 个同规格并发请求仅原始 KV 就约 4 GiB。
- 03估传输下界
若有效链路为 100 GB/s，512 MiB 的理想传输下界约 5 ms，实际还会更高。
诊断手册
TTFT 高但 Prefill GPU 不忙
- 先检查
- 队列、路由、Cache Miss、KV 传输路径与网络回退
- 需要的证据
- 带 Request ID 的 Queue→Prefill→Transfer→Decode Trace
ITL 随并发快速恶化
- 先检查
- Decode Batch、KV 容量/带宽、调度公平性与输出长度
- 需要的证据
- 按并发和输出长度分组的 ITL 分布、KV 占用与 Batch 时间
分离式吞吐低于聚合基线
- 先检查
- KV 字节量、传输带宽、跨拓扑域路径和两类 Worker 配比
- 需要的证据
- 相同流量下的聚合/分离对照，以及实际传输协议与带宽
从硬件到生态
- 01单 Worker 聚合推理
Prefill、KV 状态与 Decode 位于同一执行单元。
路径简单，但两类阶段不能独立扩缩容。 - 02Paged KV + Cache-aware Routing
KV 被按块管理，路由同时考虑缓存局部性与活跃负载。
调度成为避免重复 Prefill 和内存浪费的关键。 - 03分离式机架级推理
Prefill/Decode 独立部署，并通过 NIXL 等路径搬运 KV。
计算、显存、网络、服务发现与故障恢复共同决定体验。
硬件与生态坐标
Blackwell 引入 FP4 加速路径与更细粒度缩放；NVL72 把多个计算托盘组织进机架级 NVLink 域。Dynamo、TensorRT-LLM 等软件负责路由、缓存传输、并行配置与恢复，把“GPU 编程”扩展成系统编程。
练习与复盘
Decode Worker 在输出三个 Token 后失效，安全恢复至少需要区分哪两类状态？
- A. 已输出 Token 与 KV Cache
- B. CSS 与字体
- C. Block 数与 CPU 核心数
查看答案＋
Token 可用于避免重复输出，而 KV Cache 可能需要重新传输或重建；两者不能被当成同一个恢复对象。
一个张量含少量大离群值。只用一个全局 Scale 与微块 Scale 相比，哪个更容易压缩普通小值？
提示＋
谁决定整个范围？
参考答案＋
全局 Scale 更容易被离群值主导，使普通小值只使用很少量化级别；微块 Scale 把影响限制在局部 16 值块。
Prefill Pool 空闲、Decode Pool 饱和时，继续增加 Prefill Worker 有用吗？
提示＋
识别当前瓶颈阶段。
参考答案＋
通常无助于端到端吞吐，甚至增加资源浪费。应扩容或优化 Decode，调整路由、Batch、并行度或 KV 容量。
Worker A 有 80% Prompt 前缀缓存但负载高，Worker B 无缓存但空闲。路由应固定选 A 吗？
提示＋
这是一个多目标决策。
参考答案＋
不应固定。要比较缓存命中节省的计算与 A 的排队时间，并考虑 KV 位置与链路；用估计完成时间而不是单一指标。
Decode Worker 输出三个 Token 后失效。写出至少五个恢复步骤。
提示＋
端点、请求、Token、KV、Retry。
参考答案＋
标记并移除故障端点；冻结请求与已发 Token 游标；选择健康 Worker；定位、传输或重建 KV；携带采样与 Retry 状态恢复；去重输出；超过上限时明确失败。
可选实践实验
不计入核心 60 分钟 · 需要相应 CUDA / GPU 环境
实验目标
建立可观测的 Prefill→KV→Decode 请求轨迹
比较聚合与分离式推理，把每次请求的排队、Prefill、KV 传输、Decode 与恢复状态记录成一条可解释轨迹。建议步骤
- 01
先运行聚合 Worker 基线，记录 Prompt/Output 长度、TTFT、ITL、总延迟和 KV 占用。
- 02
若环境支持，拆分 Prefill / Decode Pool，并为请求记录所选 Worker、缓存命中、KV 字节与传输时间。
- 03
注入一个 Decode Worker 故障，记录服务发现移除、已发 Token 游标、KV 处理和 Retry 次数。
- 04
按短/长 Prompt 与短/长输出分组比较；不要用单一平均值判断分离式方案。
提交一条完整请求 Trace、聚合/分离对比表和故障恢复状态图。无法运行 GPU Serving 时，可用确定性模拟器完成状态与指标设计。
设计一个同时考虑 Cache Overlap、Queue Delay 与 KV Transfer Cost 的路由分数，并用三组请求反例测试。