逆向 NVIDIA 的 cuda-checkpoint：他们发现慢的不是 PCIe，而是 Linux 在清零内存
作者：林岚｜OC 技术编辑
林岚
据 Doubleword 的技术分析，NVIDIA 驱动里有一项不太出名的 cuda-checkpoint 能力：冻结正在运行的 CUDA 进程，把 GPU 状态序列化到主机内存，释放 GPU，之后再恢复到原来的执行状态。研究者通过观察闭源驱动行为，把一次 checkpoint/restore 周期提速了约 4 倍。
一句话结论：这项优化没有让 PCIe 凭空变快，而是发现大部分时间花在主机端分配并清零大量 4KiB 内存页；换用透明大页或预先准备缓冲区后，数据传输才接近硬件应有的速度。
为什么需要 checkpoint？大模型服务启动时要加载权重、建立 CUDA context、分配显存并初始化运行时，冷启动可能很慢。如果能保存一个已经准备好的 GPU 进程状态，需要时直接恢复，就能让推理实例更快上线，也可以暂时把闲置实例从 GPU 中移走。
研究者先用 NVIDIA 自带的计数器示例验证：进程冻结后从 nvidia-smi 消失，GPU 文件映射和文件描述符被关闭，但恢复后设备内的计数值仍然连续。观察 /proc 可以看到，进程匿名内存突然增加约 398MiB，里面包含设备内存内容和约 10MiB 驱动状态。
cuda-checkpoint 外部工具本身做的事情并不多。它找到目标进程里由 libcuda 创建的服务线程，通过管道发送 lock、checkpoint、restore、unlock 命令，真正复制和重建状态的是目标进程中的闭源驱动代码。直接使用管道协议，可以省掉每个命令重复初始化 CUDA context 的开销；生产环境更适合使用 NVIDIA 支持的 cuCheckpointProcess C API，避免依赖未公开协议。
更大的瓶颈出现在 staging buffer。约 8.6GiB 状态的 checkpoint 需要 2.8 秒，其中 mmap(... MAP_POPULATE) 单独占 2.08 秒。Linux 必须先为缓冲区分配并清零每一页，才把内存交给进程。默认 4KiB 页意味着重复大量小操作。
打开 Transparent Huge Pages 后，内核可以用 2MiB 页承载这块匿名内存，清零开销明显下降。进一步通过 LD_PRELOAD 识别大块映射并提供提前清零的缓冲区，checkpoint 在测试中降到约 540 毫秒，有效带宽约 15.5GiB/s。完整 checkpoint/restore 周期因此提高约 4 倍。
这不是一个拿来即用的通用补丁。测试基于 RTX 4090、特定驱动和内核设置；LD_PRELOAD 干预闭源驱动分配存在兼容风险，直接说私有管道协议也缺乏稳定保证。最可复用的结论是诊断方法：先拆分初始化、内存准备、PCIe 复制和 context 重建，再确定真正值得优化的阶段。
关键事实
cuda-checkpoint可以把 CUDA 进程状态移到主机内存并原样恢复。- 原始 checkpoint 约 3GiB/s、restore 约 8GiB/s，远低于测试机器 PCIe 带宽。
- 8.6GiB checkpoint 中，内存映射与清零占据大部分耗时。
- 透明大页和预分配缓冲区让完整周期提速约 4 倍。
OC 判断
这篇分析的价值不只是一个 4 倍数字，而是证明 GPU 服务性能问题经常发生在 CPU、内核和内存管理层。AI 基础设施团队如果只盯着 CUDA kernel，很容易错过真正拖慢冷启动的普通系统调用。
为什么重要
- 开发者：优化 GPU 服务前应分别测量 context 初始化、页错误、内存复制和恢复成本。
- 企业：更快 checkpoint 能提高弹性推理和 GPU 复用率，但私有协议方案需要严格兼容测试。
- 用户：模型服务的“秒开”体验，背后可能依赖保存和恢复整个运行状态，而不是每次重新加载模型。
评论
围绕这篇文章补充信息、提出问题或分享观察。