OpenLake 开源：面向 LLM 推理与训练的高吞吐低延迟存储系统

面向大模型推理与训练场景，一款名为 OpenLake 的开源存储系统正式发布。该项目主打小随机 I/O 场景下的高吞吐与低延迟，目标是把存储性能推到 GPU 算力能"吃饱"的水平。团队在 96 节点集群上的实测显示，OpenLake 可实现百万级并发 IOPS、小对象读取延迟低至约 600 µs、整体吞吐量达到 MinIO 和 RustFS 等主流对象存储的约 8 倍。

核心性能：8 倍吞吐与百万级 IOPS

OpenLake 将自己定位为"让 GPU 不再等存储"的基础设施层。团队在实验中对比了 MinIO、RustFS、Ceph 三种主流架构，分别覆盖 4KB 小 I/O 与 128MB 大 I/O 两类场景。在 96 节点集群上，OpenLake 达到了：

• 100 万以上并发 IOPS
• P99 尾部延迟 4 ms
• 小对象读取最低延迟约 0.6 ms
• 相比 MinIO 与 RustFS，吞吐量提升约 8 倍

团队强调，在高吞吐下 OpenLake 的 P50 与 P99 延迟差异很小，具备可预测的吞吐表现与较低的 CPU 开销。

关键设计：Thread-per-core 与 io_uring

小文件服务 GPU 的瓶颈主要来自三类开销：元数据查找、跨核争用以及阻塞系统调用。每次从 NIC 到 GPU 的内存拷贝都会增加延迟，影响 TTFB（Time To First Byte）。

OpenLake 采用了 pinned thread-per-core 设计：每个线程绑定到一个物理 CPU 核，完整请求由同一个核端到端处理，保证 per-core 的 L1/L2 缓存在请求期间持续命中、避免跨核迁移。

同时，所有内核 I/O 都通过 io_uring 完成：命令放入提交队列、完成结果从完成队列收割，引擎不再因等待磁盘而阻塞。

突破物理带宽：Deferred Materialization

200 Gb/s（25 GB/s）网络互连下，把 50 GB 数据搬到 GPU 显存理论耗时约 2 秒。OpenLake 引入 "logical throughput" 概念，通过延迟物化（Deferred Materialization）打破这一物理上限：

• 在客户端 GPU 节点上对数据进行无损融合压缩后再离开存储
• 数据到达时再解压，解码吞吐超过 600 GB/s，约为 25 GB/s 线路速率的 20 倍以上
• 跨链路传输的物理字节更少，解压在 GPU 上仅占不到 0.5% 的算力，远快于 NIC 落地速率
• 配合自研 FUSE 适配器与 CUDA kernel 压缩，自动判断负载是否适合压缩

团队表示，这一思路的关键不在于压缩本身，而在于用远快于 NIC 的解压速度，把"链路有效带宽"做到额定值之上。

RDMA 与 PacedRDMA：直连 GPU 显存

OpenLake 在节点间流量中使用 RDMA，旁路内核与 CPU，让数据直接从 NIC 落到 GPU 显存。在 A100 上，从远端存储读取 KV block 时，可将 PCIe 带宽压到约 96% 的利用率。

由于绕过内核空间意味着失去 TCP 范式下的拥塞控制能力，团队设计了 PacedRDMA：一种基于历史用量、动态分配过量信用（credit）给高负载客户端、并从空闲客户端回收的策略。它可以在不改动 SQ/CQ 队列深度的前提下，吸收推理场景下 KV 检索产生的突发 I/O。

元数据：去中心化设计

中心化元数据存储是单点故障，也会给每次请求增加一个额外往返。OpenLake 采用去中心化元数据方案：

• 通过对对象位置做哈希决定数据归属
• 拥有数据的节点同时拥有其元数据，以本地文件方式保存版本、权限、大小、归属等属性
• 维护一个 write-through 的内存缓存以保证读取延迟
• 每个节点管理本地通过 o_direct 打开、并由 page cache 缓冲的文件描述符池，按访问模式与数据大小自动选择

上手方式与许可

OpenLake 兼容 S3 API，无需修改业务代码，仅需简单配置即可接入现有工作负载。项目以 Apache 2.0 协议开源，团队在文档中给出了基于临时 VM 的快速构建步骤，包括安装编译依赖、安装 Rust 工具链、克隆并构建守护进程等流程。