加载、编译缓存与预热：从进程启动到真正就绪

01 · 模型进程存在，为什么还不能马上接请求

启动时可能要定位检查点、读文件、建立模型对象、安装权重、形成设备布局、搬运到设备，再初始化算子、编译或调优、建立图与工作区。第一轮请求如果触发这些工作，会遇到明显等待。

本篇优化准备阶段。少等10秒启动不代表每个稳态token都快10秒；预热只把某些成本移到对外就绪之前，也消耗时间和资源。

依据：PyTorch · mmap / meta / assign模型加载教程 ↗ · PyTorch · 编译缓存与兼容检查教程 ↗

02 · 启动依赖先画清，再安排并行

教学示意 · 不代表硬件实测

检查点清单 / 模型配置
       ↓
读取与解码权重块 → 必要的布局转换 → 安装/搬运
       ↓（按实现允许分块或并行）
完整模型参数、buffer及设备依赖就绪
       ↓
复用兼容编译产物 / 编译调优
       ↓
运行典型形状，建立必要运行时状态
       ↓
校验输出、资源预算与就绪条件 → 对外服务/训练

读取、转换和搬运可以按安全块组织流水，但有共享磁盘、网络或CPU瓶颈时，增加并发可能只增加竞争。分片加载也要避免每rank把全部权重重复拉取；并行度不能直接当带宽倍数。

依据：PyTorch · mmap / meta / assign模型加载教程 ↗ · PyTorch · Distributed Checkpoint接口与兼容范围 ↗

03 · 少做无用初始化和重复复制

思路	解决什么	边界
meta构建	先建立shape等元信息，避免生成随后被覆盖的随机权重	meta Tensor没有有效数据，安装参数后才能运行。
mmap/按需读取	避免一次将全部文件拷入CPU临时内存，允许按需访问	映射不是免I/O，访问页仍要读取；格式/平台支持要核对。
赋值/替换式安装	减少已初始化模型与检查点之间的重复复制	参数对象可能改变，优化器/引用绑定要匹配。
分片与有界加载	按需要读取并控制临时副本	分片、布局转换、设备内存及通信必须协调。

自设20 GiB权重载荷，先建20 GiB随机模型再整体读20 GiB检查点，可能同时形成约40 GiB两份CPU载荷，之后还可能有转换副本。meta+合适安装能避免某些重复存储；mmap映射的虚拟容量也不能当成所有页已驻留。这里只是对象账本，不是实测峰值。

PyTorch加载教程给出mmap、meta及load_state_dict(assign=True)入口。若安装改变参数对象，先建立的optimizer可能仍持有旧引用；稳妥路径是完成参数安装再绑定optimizer，特殊swap机制另按版本确认。

依据：PyTorch · mmap / meta / assign模型加载教程 ↗

04 · 编译缓存存方案，结果缓存存答案

编译缓存保存图、生成内核、调优选择等执行产物；它不是之前请求的输出，也不是KV缓存。新输入仍要计算。复用可省编译等待，权重文件读取和设备运行成本不会自动消失。

教学示意 · 不代表硬件实测

教学缓存身份：
计算图/配置 + shape guard或分档 + dtype/stride
后端/编译器版本 + 目标设备特征 + 编译选项
# 权重是否属于身份，取决于产物是否内嵌/特化了权重。
# 若只是同图的新权重，不能无条件断言必须重编，也不能盲目复用。

PyTorch编译缓存文档说明了多个缓存层及兼容检查。不同层可能命中或未命中，portable artifact也不表示跨任意GPU、版本和配置通用。不要为了“命中”跳过guard或兼容性检查。

依据：PyTorch · 编译缓存与兼容检查教程 ↗ · PyTorch · torch.compile ↗

05 · 预热准备什么，不能只跑一次小输入

选择覆盖实际需求的典型shape、dtype、batch、上下文与执行路径；让必要编译、算子加载、调优、内存池和图建立发生在对外就绪之前。预热范围要有预算，不能穷举所有可能输入。

一个batch=1短序列预热，并不证明大batch、长上下文、其他适配器或分档都已准备。未知形状仍可能触发额外编译；可接受动态路径、限制支持范围或采用新的就绪策略，应明确选择。

训练预热如果执行optimizer.step，会改变参数、moment、随机数和数据位置；要使用隔离副本或保存并恢复完整状态。服务预热的临时请求、KV和输出也应清理，不能意外带入真实请求。

依据：PyTorch · 编译缓存与兼容检查教程 ↗ · NVIDIA · CUDA Graphs任务图、捕获与运行 ↗

06 · 冷启动、预热就绪和首次请求分别计时

自设启动权重读取/安装6秒，缓存命中后产物加载0.5秒，未命中编译8秒。三个shape桶各需0.2秒运行时预热；未预热shape的首请求另有0.4秒懒初始化，稳态执行0.05秒。所有项在演示中串行，不预测实际设备。

早点ready，首请求就一定没有准备成本吗？

编译缓存预热桶数首请求落点

读取/安装6 s；按桶0→1→2预热，各0.2 s；已覆盖执行0.05 s，未覆盖另加0.4 s。本例编译阶段已覆盖三桶，未覆盖仅运行时懒初始化；真实系统仍可能重编译。

完整预热三个桶：未命中就绪14.6秒，命中就绪7.1秒，覆盖桶的首请求0.05秒。只预热一个桶更早就绪，但请求落到另一个桶时需0.45秒。把这一额外准备忽略，会让就绪标准和首请求表现不一致。

此例编译阶段已覆盖三个桶，因此未覆盖桶只剩运行时懒初始化；真实系统还可能在新shape重新编译，应记录实际路径。

07 · 就绪探针应覆盖真正依赖

仅检查进程活着或端口打开，不能证明参数已完整、通信组可用或目标请求路径已预热。就绪条件应按服务/训练需求定义：必要参数、buffer、设备搬运、参与rank和典型路径均满足，并核对资源预算。

教学示意 · 不代表硬件实测

安装和检查完整参数/buffer
确认设备搬运与必要通信初始化已完成
载入兼容产物或完成规定编译
运行预算内的代表输入并检查结果
清理临时请求与恢复训练状态
确认实际就绪条件，开始接入工作
# readiness与模型结果质量检查各有范围。

图捕获常绑定当前进程的缓冲和执行资源；磁盘里的编译产物命中，不等于这个进程的图、地址和workspace已经建立。M018讲编译，M019讲捕获重放，本篇将它们放回启动生命周期。

依据：NVIDIA · CUDA Graphs任务图、捕获与运行 ↗ · PyTorch · 编译缓存与兼容检查教程 ↗

08 · 小脚本验证兼容性、绑定与预热状态

下载脚本用教学缓存键比较兼容/不兼容产物；用可变参数对象说明安装后旧optimizer引用可能失效；用带随机数的标量训练step演示预热改变状态，以及完整快照恢复后的结果。时间线另检查缓存命中和预热覆盖，不调用真实torch.load、编译器或设备。

教学示意 · 不代表硬件实测

记录从启动到ready的各阶段与关键路径
区分冷/热文件缓存和冷/热编译缓存
列出预热范围、未覆盖shape及资源预算
测试首请求与第二次请求，训练则核对恢复状态
按同资源比较扩容/恢复总耗时
# 把启动收益与稳定运行的tokens/s分开报告。

依据：PyTorch · mmap / meta / assign模型加载教程 ↗ · PyTorch · 编译缓存与兼容检查教程 ↗

09 · 验收和跨平台读法

加载：参数完整性、dtype/布局、实际读取字节、临时副本峰值。
缓存：命中层、兼容检查、guard与必要重新编译。
预热：覆盖桶、首次额外等待、CPU/设备容量和清理。
训练：参数绑定、optimizer状态、RNG与数据进度恢复。
系统：启动到ready、冷/热首请求、扩容和故障恢复时间。

GPU/NPU的文件加载思路可以相通，但编译产物、算子初始化、图和设备资源通常各有格式及版本要求。不能直接共享另一平台的二进制缓存来宣称启动已优化。

依据：vLLM Ascend · 支持功能矩阵（main） ↗

mmap为什么不等于权重已经全部读进物理内存？
编译缓存命中后，为什么仍可能要建立新进程的图和缓冲？
预热训练step后只恢复权重，为什么可能仍改变后续训练？

流程位置与关联方法

这个方法可能出现在多个位置；计算线包含模型计算与算子实现，执行线包含运行时、内存和通信。

I-B0 · 服务初始化与预热 T-B0 · 初始化分布式训练

资料与核查范围

原理依据以原始论文和官方文档为主；算例与时间线是教学推导。文档核查日期：2026-10-10。引用 main / latest 文档时，实际接口以安装版本为准。

代码为接入片段或教学伪代码；本页没有声称完成 NVIDIA / 昇腾硬件实测。