作者简介

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

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

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

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

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

   持久化的对象存储（如 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 将更多时间用于推理运算，减少因数据加载而处于空闲状态的时间，同时借助高效缓存机制，也能有效控制云带宽成本。