作者简介

Nilesh Agarwal,Inferless 联合创始人 &CTO

关于 Inferless

Inferless ：无服务器 GPU 推理无需管理服务器即可扩展机器学习推理，轻松部署复杂的自定义模型。获得 Sequoia、Antler 和 Blume Ventures 的支持。

大语言模型（LLM）推理任务需在分布式 GPU 实例之间频繁快速加载超大模型文件（通常 GB 级别）。传统单层存储方案（纯本地磁盘或纯远程云存储）已无法满足规模化服务的吞吐与延迟需求。举例来说，如果成千上万的推理节点各自从云对象存储拉取 20–100 GB 的模型，网络带宽与存储 I/O 很快就会成为瓶颈。

为解决这一难题，现代 AI 基础设施通常采用兼顾性能与成本的三层存储架构：

1. 热存储层（ Hot Tier）—— 支持 POSIX 接口的本地 NVMe

2. 每个计算节点配备高速 NVMe SSD（或基于 NVMe 的实例存储），挂载为 POSIX 文件系统。该层提供"热"数据访问能力，单节点吞吐可达 2.5GB/s 以上，延迟极低，可以确保模型文件能以近似内存速度读取。

3. 温存储层（Warm Tier）—— 集群内文件共享

4. 在集群层面，节点之间可以互相共享数据。每台机器暴露服务接口（或接入分布式文件系统），使其他节点可从已缓存模型的同伴节点以 2GB/s 的局域网（LAN）速度获取文件，避免所有节点重复访问云存储。

5. 冷存储层（Cold Tier ）—— 云对象存储

6. 持久化的对象存储（如 AWS S3、Azure Blob、Google Cloud Storage 等）充当“冷”存储，负责保存所有模型与数据资产。它的容量近乎无限、可靠性高，但单次访问延迟较高（数百毫秒），单连接吞吐量也较低。冷存储层是上层缓存未命中时的数据来源，并用于初次填充热/温存储层；利用多线程并行拉取，仍可达到约 1 GB/s 的聚合带宽。

这种分层设计通过三大优势显著加速模型加载，同时将从慢速存储重复传输的数据量最小化：

1. 本地 NVMe 层实现最大速度读取；

2. 集群共享层避免跨节点重复下载；

3. 云存储层保障数据持久性与轻松同步。

该架构现已成为云端 LLM 服务的最佳实践，可实现本地磁盘 2.5GB/s、节点间 1.5GB/s 的读取吞吐，而直接访问远程存储时大约为 1GB/s。下面将逐层解析设计要点，并探讨实现该架构的技术方案。

一层存储：热存储 —— 本地 NVMe，支持 POSIX 文件接口

定义

热存储层通常是每台 GPU 服务器上的本地 NVMe SSD，采用 POSIX 兼容的文件系统（如 ext4 或 XFS）格式化，使应用程序能够以标准方式读写数据。该层作为被频繁访问数据（如模型权重、词汇文件等）的高速缓存，通过 PCIe 总线直接向 CPU/GPU 提供数据，延迟极低。许多云端 GPU 实例类型自带高性能临时 NVMe 存储，或支持挂载基于 NVMe 的存储卷，这些都可以被用于构建热存储层。

性能表现

NVMe SSD 提供极高的顺序读取吞吐量和超低延迟。实际使用中，单块 NVMe 硬盘即可实现每秒数 GB 的数据流传输。例如，在从 NVMe 上的页面缓存加载 .safetensor 模型文件时，读取吞吐量可达约 2.5 GB/s，一个 512 MB 的模型文件仅需约 0.2 秒 即可完成加载（原耗时约 1 秒）。现代 NVMe（如 PCIe 4.0/5.0）驱动器的顺序读速度可以稳定在 5–7 GB/s，因此，通过适当优化，实现单文件 2 GB/s 的读取目标完全可行。

此外，NVMe 层的访问延迟仅为数百微秒，略高于系统内存，但远远低于网络或云存储的延迟（通常为毫秒级）。

POSIX 文件接口优势

将该缓存以标准文件系统形式暴露，对于确保兼容性至关重要。主流的 LLM 推理框架（如 TensorFlow、PyTorch、Hugging Face 等）无需修改代码即可通过内存映射（mmap）或常规读取方式加载模型文件。类似于 POSIX 的接口支持完整的文件操作以及 mmap 功能，确保即使是需要文件系统支持的库（例如 torch.load 加载模型检查点，或使用 mmap 读取 Safetensors 文件）也能无缝运行。事实上，Safetensors 格式特别适合基于 mmap 的随机访问读取，这种操作在本地 SSD 或内存上表现最佳，而在高延迟的远程存储中则效果较差。

实际应用

在部署 LLM 服务时，通常会将模型文件预先加载到各个节点的 NVMe 上（可提前预置或首次使用时加载）。这个过程可能涉及从温存储层或冷存储层复制文件到本地磁盘。一旦模型被缓存到 NVMe 上，之后的所有读取都会命中本地文件系统缓存。为了进一步优化性能，常会采用如预读（read-ahead）和预取（prefetching）等技术。例如，在启动时顺序读取模型文件，将其完整加载至操作系统页缓存，使得后续访问几乎无等待（直接从内存或磁盘读取）。

二层存储：温存储 ——集群内模型数据共享

定义

温存储层指的是集群（或同一可用区）内部的存储机制，它允许节点之间以局域网速度互相获取数据。它本质上形成了一个“温”数据的分布式缓存，这些数据虽然不一定存在于本地磁盘，但距离远比远程云对象存储近、访问速度也更快。

温存储层主要的设计模式：点对点文件服务（Peer-to-Peer File Serving）：

将模型下载到本地 NVMe 上的各个都可充当其他节点的文件服务器。实现方式可以很简单，比如在每台机器的缓存目录上运行 NFS 或 HTTP 服务器，也可以使用更复杂的 P2P 系统。当某节点需要访问本地尚未缓存的模型时，首先通过查询服务或哈希表检查是否有其他节点已缓存该模型，随后直接从该节点拉取文件。鉴于云内部网络带宽通常很高（10 Gbps ~ 1.25 GB/s，25 Gbps 或更高）且延迟低，这种方式的吞吐量远超从远程对象存储拉取。而且还能避免冗余流量：只需一个节点从冷存储层下载，其他节点便可共享该副本。此机制类似 BitTorrent 式分发或 Kubernetes 在大规模集群中使用的镜像缓存。

性能表现

温存储层的目标是通过网络实现每秒数 GB 的传输速率。若设计合理，集群内的数据共享可以接近网卡的线速。例如，系统允许节点之间直接访问彼此 NVMe 上缓存的数据。在实际生产环境中，从一个节点读取一个 100 GB 的模型文件，其温层读取吞吐量达 1.5 GB/s，远远超越了早前基于 HDFS 等方案的表现。从理论上讲，这种机制可以向本地集群提供高达 10 GB/s 的数据服务能力。

三层存储：冷存储 —— 云 Blob/对象存储

定义

冷存储层通常是云端对象存储服务或分布式 blob 存储系统，用于存放所有模型、checkpoints 和数据集的持久副本。典型代表包括 Amazon S3、Google Cloud Storage、Azure Blob Storage，或本地部署的对象存储系统如 Ceph RADOS Gateway、MinIO 和 Cloudian。该层之所以称为"冷"存储，是因为这层数据并不会在每次推理时直接访问，而是仅在缓存未命中或首次加载新模型时才会被拉取。冷存储的优化重点在于持久性、可扩展性和成本，而非低延迟。它可以存储 PB 级别的数据，具备高达 “十一个九” 的数据持久性（99.999999999%），但单个读取请求通常延迟较高（约 50–200 毫秒），单线程吞吐也有限（例如单线程从 S3 读取速度通常为 100–200 MB/s，但可通过多线程或分段 GET 请求提升）。

在架构中的作用

对象存储是整个系统的“单一可信源”（source of truth）。所有数据最初都来源于此（如从训练作业上传或由模型开发者发布），而上层的热存储和温存储仅是对部分数据的缓存。冷存储层确保当缓存节点丢失（例如实例终止）或温存储层中未缓存特定模型时，可以从中可靠地获取数据。在云环境中使用托管对象存储极为方便，因为它具备高持久性和全球可访问性。例如，训练后的模型存入 S3 桶中，位于其他区域/云的推理集群也可按需访问该模型。冷存储也通常作为很少使用的模型的归档，这样可避免这些模型占用昂贵的 NVMe 本地空间，只有在真正需要时才加载到热/温存储层。

性能特性

冷存储是三层中最慢的一层，但可以通过并发优化。云对象存储本质上是分布式系统，具备高聚合带宽。例如 AWS S3 对于大文件或大并发请求的场景，可以提供数 Gbps 的吞吐。因此，对冷存储层的优化建议包括使用多线程并发拉取和分块请求（range GET）加速传输。

成本考虑

云对象存储不仅按存储容量计费，还对数据出口流量（egress）和 API 请求收费。如果从冷存储层拉取一个 50 GB 的模型到 100 个节点，而这些节点不在同一区域或之前没有缓存该模型，将产生大量的出口流量费用。因此，减少对冷存储的直接读取不仅能提升性能，也能显著节省成本。每一次温存储命中都可能节省数十次 S3 GET 请求和数十 GB 的数据流量。

三层存储架构的实现指南

在为 LLM 推理设计和运行三层存储堆栈时，需遵循以下核心原则，以实现效益最大化

预取与预热

提前为已知负载预热缓存。如果已知某个模型即将部署到 N 个节点上，建议让一个节点提前从冷存储（如 S3）拉取模型文件，然后通过温层将其分发给其他节点。部分系统支持在所有节点上显式执行预取缓存操作。若无此功能，也可以先启动一个模型实例让其从 S3 加载数据（填满温缓存），再启动其他实例复用缓存。

高带宽网络

确保集群网络带宽足够应对负载。当新的模型分发到多个节点时，集群内的网络传输将迎来峰值。例如，若 8 台机器每台都需以约 1 GB/s 的速度下载 50 GB 数据，总流量将高达约 400 Gbps。因此，集群至少应配备 10 GbE 网络接口（针对大型 LLM 推理集群建议使用 25 GbE 或更高）。

并发 I/O 与异步加载

LLM 框架通常支持与其他工作并行加载。可以开启多个线程，并发地从本地磁盘或其他节点读取模型文件的不同部分，充分发挥多个 NVMe 队列或 TCP 连接优势。许多缓存系统会自动实现并发加载，但如果是自建系统，切勿使用单线程方式来拷贝大文件。此外，建议使用大块读取（large read sizes），或启用预读（如 Linux 块设备/文件的 readahead 设置），以最大限度地利用磁盘带宽。

监控并优化缓存命中率

持续监控推理节点是否频繁访问冷存储层。如果发现同一模型文件频繁触发 S3 读取，说明温存储层容量不足或配置有误。目标是在模型初次加载后，后续所有读取操作应来自本地 NVMe（最优） 或其他节点的 NVMe（次优）。此外，建议配置相关指标（如缓存命中率），并通过 S3 访问日志或云监控工具检查是否有重复的 GET 请求发生。目标是实现模型重复加载时接近 100% 的缓存命中率， 否则需要扩大缓存空间或调整缓存驱逐策略。

缓存驱逐与空间管理

明确每个节点的 NVMe 中应分配多少空间用于缓存模型，并选择合适的驱逐策略。如果 SSD 容量有限，而需要缓存的模型较多，应使用 LRU（最近最少使用）或 LFU（最不经常使用）策略来驱逐旧模型，为新模型腾出空间。部分系统会自动处理这一过程。应确保驱逐不会影响关键数据，例如，如果 NVMe 同时用于操作系统或临时文件，建议对模型缓存进行逻辑分区（如单独挂载或设置专用目录），以便更好地管理空间。此外，还可以考虑在模型写入冷存储时进行压缩（某些系统支持），以节省远程存储的空间和传输成本。

结论

在云端部署大规模 LLM 推理时，存储系统需满足数百张 GPU 的高吞吐、低延迟数据供给需求。三层存储架构（本地 NVMe 高速层、集群共享缓存层、云对象存储层）已成为行业最佳实践，其核心优势在于：本地 SSD 的高速读写、局域网的高带宽传输能力，以及云存储的持久性与弹性。通过缓存、预取和分布式文件服务等技术手段，可以实现接近硬件极限的模型加载速度（每秒 GB 级吞吐），从而将 GPU 等待模型权重加载的空闲时间降到最低。

对于正在构建 LLM 推理基础设施的组织来说，构建统一存储架构时，需在便利性、成本与控制力之间做出权衡。托管服务可以降低运维负担，但灵活性较低；而开源方案则提供完全控制权，但需要更多的运维能力。所幸这些模式都已相对成熟，即便在起步阶段采用简单方案（例如使用 NFS 缓存 S3 内容），也可以随着需求的增长逐步演进为更加分布式、可扩展的系统。采用这种分层的存储架构，是避免存储瓶颈成为 AI 部署障碍的关键。当架构设计合理时，GPU 将更多时间用于推理运算，减少因数据加载而处于空闲状态的时间，同时借助高效缓存机制，也能有效控制云带宽成本。