利用 NVIDIA Run:ai 模型流技术降低大型语言模型推理的冷启动延迟

部署大语言模型（LLM）在优化推理效率方面带来了显著挑战。其中，冷启动延迟——即模型加载到 GPU 显存所需的时间较长——会直接影响用户体验和系统的可扩展性。随着生产环境日益复杂，高效模型加载的需求愈发突出。这些模型通常需要数十至数百 GB 的内存，在应对不可预测的流量增长时，容易引发延迟问题并加剧资源压力。冷启动延迟不仅影响最终用户的体验，也对整体运营效率构成挑战。

本文将介绍 NVIDIA Run:ai Model Streamer，这是一款开源的 Python SDK，旨在通过从存储中读取模型权重的同时，将其直接流式传输至 GPU 显存，从而有效缓解加载过程中的性能瓶颈。我们对该工具进行了基准测试，对比了其在本地 SSD 和 Amazon S3 上的表现，测试对象包括 vLLM 默认的 Hugging Face (HF) Safetensors 加载器以及 CoreWeave Tensorizer。

本文介绍的实验表明，NVIDIA Run:ai Model Streamer 能显著缩短模型加载时间，有效降低云环境中的冷启动延迟。该技术兼容 Safetensor 格式，无需进行权重转换，简化了部署流程。研究结果强调了存储选择与并发流在高效部署大语言模型中的关键作用。为提升推理性能，建议采用 NVIDIA Run:ai Model Streamer 以减少冷启动延迟、充分利用存储吞吐能力，并加快整体推理速度。

如何将模型加载到 GPU 进行推理？

为提供背景信息，本节将介绍将机器学习模型加载到 GPU 显存以进行推理的两个主要步骤：首先从存储设备读取权重至 CPU 内存，再将其传输至 GPU。理解这一过程对于优化推理延迟至关重要，特别是在大规模或基于云的部署场景中。

• 将权重从存储设备读取到 CPU 显存：模型的权重从存储设备加载到 CPU 显存中。权重可以采用 .pt、.h5 和 .safetensors 等各种格式，也可以采用自定义格式；存储可以是本地、集群范围或云端。请注意，.safetensors 格式因广泛采用而用于本文目的。但是，其他格式可能会在其他地方使用。
• 将模型迁移到 GPU：模型的参数和相关张量会迁移到 GPU 显存。

从 Amazon S3 等基于云的存储中加载模型通常需要额外的步骤：模型权重首先被下载到本地磁盘，随后加载至 CPU 内存，最后再传输到 GPU 显存。

传统上，这些步骤按顺序执行，因此模型加载时间成为扩展推理过程中尤为关键的瓶颈之一。

模型流转换器的工作原理是什么？

Model Streamer 是一款基于高性能 C++ 后端的 SDK，旨在加速从多种存储源（如网络文件系统、云存储、本地磁盘等）将模型加载至 GPU 的过程。该工具通过多线程技术，将对象存储或文件存储中的张量并发读取至 CPU 内存中的专用缓冲区。每个张量均具备唯一标识符，支持读取与传输操作的并行执行：部分张量从存储系统读取到 CPU，同时其他张量从 CPU 传输至 GPU，从而实现高效的流水线处理。

该工具充分利用了 GPU 与 CPU 拥有独立子系统的特点。GPU 可通过 PCIe 直接访问 CPU 内存，无需 CPU 干预，从而实现存储读取与内存传输的并行重叠。实验在配备 NVIDIA A10G GPU 和第二代 AMD EPYC CPU 的 AWS g5.12xlarge 实例上进行，该架构为高吞吐量的并行数据处理提供了良好的性能平衡。

Model Streamer 的主要特点包括：

• 并发：多个线程并行读取模型权重文件，包括对分割大型张量的支持。
• 均衡的读取工作负载：工作根据张量大小和饱和存储带宽进行分配。
• 支持多种存储类型：适用于 SSD、远程存储和云对象存储 (如 S3) 。
• 无张量格式转换： 原生支持 Safetensors，避免转换用度。
• 易于集成：提供 Python API 和迭代器，类似于 Safetensors，但具有并发背景读取功能。轻松集成 vLLM 和 TGI 等推理引擎。

有关设置和使用方法的更多详细信息，请参阅 Model Streamer 文档。

HF Safetensors Loader 的工作原理是什么？

HF Safetensors Loader 是一款开源工具，提供一种安全且高效的格式，用于保存和加载多个张量。它采用内存映射文件系统，以减少数据复制。在 CPU 上，张量可直接映射到内存中；在 GPU 上，则通过 PyTorch 创建空张量，并使用 cudaMemcpy 传输数据，从而实现接近零拷贝的加载过程。

CoreWeave Tensorizer 的工作原理是什么？

CoreWeave Tensorizer 是一款开源工具，可将模型权重及其对应的张量序列化为单个文件。Tensorizer 无需先将整个模型加载到内存中再移至 GPU，而是支持通过 HTTP/HTTPS 或 S3 源直接流式传输模型数据张量，实现高效加载。

加载与推理引擎的碰撞：使用 vLLM 加载权重

没有推理引擎，模型服务便无法完整。目前有许多可用的推理引擎和服务器可供选择，本文将重点介绍 vLLM 及其模型加载功能。在基准测试研究中，我们仅采用了 vLLM 进行实验。

vLLM 框架默认采用 Hugging Face 安全传感器模型进行加载，同时也支持通过 CoreWeave Tensorizer 从 S3 端点加载模型。需要注意的是，使用 Tensorizer 库时，需先将模型权重从安全传感器格式转换为 Tensorizer 所需的格式。

比较三种存储类型的模型加载器性能

我们对比了三种存储类型下不同模型加载器（NVIDIA Run:ai Model Streamer、CoreWeave Tensorizer 和 HF Safetensors Loader）的性能表现。

1. 实验# 1：GP3 SSD – 使用各种加载程序测量的模型加载时间。
2. 实验# 2：IO2 SSD – 在 IO2 SSD 上测试相同的加载程序，以评估更高的 IOPS 和吞吐量的影响。
3. 实验# 3：Amazon S3 – 比较云存储中的加载程序；排除 Safetensors 加载程序，因为它不支持 S3。
4. 实验# 4：使用不同加载程序的 vLLM – 将模型 Streamer 集成到 vLLM 中，以测量各种存储类型的满载和就绪时间，并将其与默认的 HF Safetensors Loader 和 Tensorizer 进行比较。Safetensors Loader 未纳入 S3 测试。

所有测试均在冷启动条件下进行，以排除缓存带来的影响。针对 S3 测试，两次运行之间设置了至少两分钟的间隔，以确保结果准确。Tensorizer 实验采用按照 Tensorizer 配方 进行序列化的模型，基准测试也严格遵循其 推荐的流程，两种情况下均未启用可选的哈希功能。

实验设置

实验按照表1中列出的设置进行。

在涉及 Tensorizer 的实验中，采用 Tensorizer 框架提供的 recipe 将同一模型序列化为该框架专用的张量格式。

实验 1 个结果：GP3 SSD 

在本次初始实验中，我们比较了使用 GP3 SSD 存储时不同模型加载器的加载性能。我们评估了并发性对 Model Streamer 的影响（如图 1 所示），并探讨了工作进程数量对 Tensorizer 性能的作用。对于 Model Streamer 而言，提升并发性（即从存储设备向 CPU 内存并发读取数据的线程数量）可显著缩短模型加载时间。

在并发数为 1 时，Model Streamer 加载模型耗时 47.56 秒，略快于 HF Safetensors Loader 的 47.99 秒。当并发数提升至 16 时，加载时间降低至 14.34 秒，吞吐量稳定在约 1 GiB/s，接近 GP3 SSD 的峰值吞吐能力。进一步性能提升受限于存储吞吐能力。

Tensorizer 也表现出类似的行为。单个工作进程的加载耗时为 50.74 秒，与 Safetensors Loader 接近。在使用 16 个工作进程时，其加载时间缩短至 16.11 秒，吞吐量达到 984.4 MiB/s，接近 GP3 SSD 的带宽水平。

GP3 SSD 的存储吞吐量限制成为 Model Streamer 和 Tensorizer 的性能瓶颈，制约了整体表现，这促使我们在“实验 2”中对高吞吐量的存储解决方案进行测试。

实验# 2：IO2 SSD 

在第二个实验中，我们采用了 IO2 SSD，其吞吐量显著高于 GP3 SSD。与之前相同，我们分析了并发性对 Model Streamer 的影响（如图 3 所示），以及 Tensorizer 上工作进程数量的影响。

在并发数为 1 时，Model Streamer 与 HF Safetensors Loader 的加载时间相近，分别为 43.71 秒和 47 秒。随着并发数的增加，Model Streamer 搭配 GP3 SSD 的性能优势更加明显。当并发数达到 8 时，模型加载时间缩短至 7.53 秒，相比 HF Safetensors Loader 快了 47 秒。

对于 Tensorizer 而言，性能也取得了显著提升。使用八个工作者时达到最优表现，模型加载时间缩短至 10.36 秒（图 4）。此外，由于受到存储吞吐量的限制，继续增加工作进程数量并未带来进一步的性能提升。

尽管 IO2 SSD 的理论最大吞吐量可达 4 GiB/s，但我们的实验中始终未能突破上限：使用 Model Streamer 时达到 2 GiB/s，使用 Tensorizer 时为 1.6 GiB/s。这表明实际吞吐量受限于 AWS 基础架构，而非加载程序本身。

实验# 3: S3 

在云存储方面，实验3比较了以Amazon S3作为存储介质时，Model Streamer与Tensorizer的性能表现。由于HF Safetensors Loader不支持S3，因此未将其纳入本次基准测试。在Tensorizer的测试中，我们尝试了不同数量的工作节点，并为图6选取了表现最优的结果，其中使用16个工作节点时达到了最佳性能。

结果表明，在所有测试的并发级别下，Model Streamer 的性能均优于 Tensorizer。在并发数为 4 时，Model Streamer 在 28.24 秒内完成了模型加载。随着并发数的增加，其性能持续提升，在并发数达到 32 时，加载时间缩短至 4.88 秒；而 Tensorizer 在 16 个工作节点时的最佳表现仍需 37.36 秒。由此可见，Model Streamer 在从云存储加载模型时展现出更高的效率。

请注意，在这些实验中，我们观察到 AWS S3 上存在意外的缓存行为。当实验被快速连续重复执行时，模型加载时间显著缩短，这可能是由于某种形式的 S3 缓存机制所致。为确保结果的一致性，并避免受到“热缓存”状态的影响，我们在每次测试运行之间设置了至少 3 分钟的间隔时间。所呈现的结果均是在该等待间隔之后记录的，以确保反映的是冷启动条件下的真实性能。

‾实验# 4：包含所有加载程序的 vLLM

该实验将多种模型加载器集成至 vLLM，以测量从模型加载到推理准备的完整耗时。Model Streamer、Safetensors Loader 和 Tensorizer 在本地存储（GP3 SSD 和 IO2 SSD）上进行了测试。由于 Hugging Face Safetensors 不支持从 S3 加载，因此未参与 S3 场景的对比。Tensorizer 在 S3 环境下结合 vLLM 进行了测试，并与 Model Streamer 的表现进行了比较。

对于每个 vLLM 和 Model Streamer 实验，我们均采用了先前实验中确定的最佳并发级别，具体如下：

• 对于 GP3 SSD，并发级别为 16 (图 1) 。
• 对于 IO2 SSD，并发级别也为 8 (图 3) 。
• 对于 S3 存储，使用了更高的并发级别 32 (图 5) 。

同样，在 Tensorizer 与 vLLM 的集成中，我们采用了此前实验中确定的最佳工作节点数量。具体而言：

• GP3 SSD：16 名工作人员
• IO2 SSD：8 名工人
• S3：16 名工人

与 HF Safetensors Loader 相比，Model Streamer 在 GP3 SSD 和 IO2 SSD 上的总准备时间分别缩短至 35.08 秒和 28.28 秒，减少了 66.13 秒和 62.69 秒。Tensorizer 在 GP3 SSD 上耗时 36.19 秒，在 IO2 SSD 上耗时 30.88 秒，相比 Safetensors，时间大约减少了一半。在 S3 存储上，Model Streamer 的整体就绪时间为 23.18 秒，而 Tensorizer 为 65.18 秒。

开始使用 NVIDIA Run:ai Model Streamer

冷启动延迟仍是实现响应迅速、可扩展的大型语言模型推理的关键瓶颈，尤其在动态或云原生环境中尤为突出。我们的基准测试表明，NVIDIA Run:ai Model Streamer 在本地和远程存储场景下均显著提升了模型加载速度，性能优于其他常见加载方案。通过支持权重的并发加载与 GPU 显存的流式传输，该技术为大规模生产环境中的推理工作负载提供了高效且切实可行的解决方案。

如果您正在构建或扩展推理系统，尤其是在使用大模型或基于云存储的场景下，以下建议可立即带来显著优化效果：采用 NVIDIA Run:ai Model Streamer 可有效降低冷启动延迟，充分提升存储吞吐量，并加快推理速度。该工具能够无缝集成至 vLLM 等主流框架，支持高并发与多存储环境，是一种切实可行且收益可观的性能优化方案。