openlake
基于 Rust + io_uring 的高性能 LLM 存储引擎，实现百万级 IOPS 与亚毫秒延迟，让 GPU 永远不挨饿
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
基于 Rust + io_uring 的高性能 LLM 存储引擎，实现百万级 IOPS 与亚毫秒延迟，让 GPU 永远不挨饿
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
2026 年，一家中型 AI 实验室在部署 Llama-4 70B 模型时发现了一个诡异的现象：8 张 H100 GPU 组成的推理集群，GPU 利用率始终徘徊在 40% 左右。换句话说，有超过一半的 GPU 算力在"等米下锅"。运维团队排查了网络、CUDA 驱动、甚至重装了 PyTorch——问题依旧。
真正的问题出在存储上。在 LLM 推理和训练过程中，GPU 需要频繁访问 KV Cache（Key-Value 缓存）、模型 Checkpoint、以及 Embedding 向量数据。当这些数据的读写速度跟不上 GPU 的计算速度时，GPU 就只能空转等待。传统对象存储（如 S3）的吞吐量通常只有 1-2 GB/s，而单张 H100 的数据需求峰值可达 10-20 GB/s——整整 10 倍的差距。
这就是 OpenLake 要解决的问题。
OpenLake 是一个基于 Rust 构建的高性能存储引擎，专门为 LLM 推理和 GPU 训练场景优化。它通过 Linux io_uring 异步 I/O、RDMA（远程直接内存访问）和 GPUDirect Storage 等底层技术，在存储路径上实现了百万级 IOPS、亚毫秒级延迟，让 GPU 的利用率从 40% 提升到接近饱和。
在 AI 基础设施领域，计算（GPU）一直是最耀眼的明星，而存储往往被当作配角。但随着模型规模越来越大、推理请求越来越密集，存储已经从一个"配角"变成了制约 AI 系统吞吐量的核心瓶颈。
具体来说，LLM 工作负载对存储提出了三个特殊挑战：
小 I/O 高频访问：KV Cache 由大量细粒度的 Key-Value 块组成，每次推理请求可能需要随机读取数万个 KV 块。传统存储在处理小文件随机读时性能急剧下降。
超低延迟要求：推理的 Token 生成速度直接影响用户体验。如果存储延迟超过 1ms，每次 KV 块读取都会拖累整个推理流水线的吞吐量。
突发带宽需求：训练时的 Checkpoint 保存需要在短时间内写入数百 GB 数据。如果存储带宽不足，整个训练任务就会被迫暂停等待。
OpenLake 正是为解决这三个问题而生的。它的设计哲学是：让存储跟上 GPU 的速度，而不是让 GPU 适应存储的速度。
OpenLake 的技术选型非常明确：用 Rust 语言在系统层面做极致的性能优化，而不是在上层通过缓存或预取做"曲线救国"。
OpenLake 的核心 I/O 引擎构建在 Linux io_uring 之上。io_uring 是 Linux 5.1 引入的新一代异步 I/O 接口，相比传统的 epoll + 同步 read/write 模式，io_uring 提供了真正的零拷贝、批量提交、轮询模式等特性，可以将存储 I/O 的系统调用开销降低到接近零。
OpenLake 的实现策略是：每个物理 CPU 核心运行一个独立的 pinned compio 运行时。compio 是 Rust 生态中基于 io_uring 的异步运行时，它确保 I/O 请求在整个热路径中都保持在同一个 CPU 核心上，避免了跨核心竞争和锁争用。
这种设计的性能收益是显著的：在多核 NVMe 环境下，OpenLake 可以轻松突破百万级 IOPS，而延迟稳定在 600 微秒左右——比传统对象存储快了近 10 倍。
在需要跨节点访问存储的场景中，OpenLake 支持 RDMA（Remote Direct Memory Access）技术。RDMA 允许数据直接从远程 NVMe 网卡写入本地 GPU 内存，完全绕过两端的 CPU 和操作系统内核。这消除了传统网络存储中 CPU 复制和上下文切换的开销。
更关键的是 GPUDirect Storage（GDS） 的支持：当 OpenLake 与支持 GDS 的 NVIDIA GPU（如 A100/H100）配合使用时，数据可以从 NVMe 直接流向 GPU 显存，无需经过主机内存中转。在官方 benchmark 中，OpenLake 在 A100 上实现了 96% 的 PCIe 利用率——这意味着存储带宽几乎完全饱和。
OpenLake 的另一个核心技术优势是零拷贝。在数据从 NVMe 到 GPU 的整个路径上，OpenLake 尽量避免中间缓冲和内存拷贝。数据通过 Linux io_uring 直接提交给 RDMA 引擎，再由 RDMA 网卡直接写入 GPU 显存，整个过程无需 CPU 介入。
这种设计让 OpenLake 在带宽指标上远超传统方案：官方数据显示，OpenLake 的吞吐量是主流对象存储的 8 倍，读取延迟降低到 600 微秒，而数据吞吐量可以达到网卡物理带宽的 96% 以上——相当于在一条标称 100 Gbps 的网络链路上，实际传输的有效数据量超过了标称带宽。
OpenLake 并非一个通用存储系统，而是针对 AI 工作负载做了深度定制。它的核心功能覆盖了 LLM 生命周期的关键环节：
这是 OpenLake 最具差异化的功能。在 LLM 推理中，KV Cache 是 attention 计算的中间结果，其大小与上下文长度成正比。对于 100K 上下文的请求，KV Cache 可能占用数百 GB 显存，远远超出单卡显存容量。
OpenLake 提供了 KV Cache 的分布式持久化存储方案。它将 KV Cache 数据以高效的方式存储在 NVMe 或分布式存储节点上，并通过 RDMA 实现 GPU 显存与存储之间的直接数据交换。在官方的一篇博客中，团队展示了用 OpenLake 管理 100 TB KV Cache 的案例，配合延迟物化（Deferred Materialization）技术，推理吞吐量提升了 8 倍。
在 v0.8 版本中，OpenLake 引入了 ExANS——一个专门针对 BF16 格式 KV Cache 的无损 GPU 压缩算法。ExANS 由 GPU 执行压缩，数据在离开 GPU 节点前就完成了压缩，减少了跨网络传输的数据量。官方数据显示，ExANS 可以实现 1.51 倍的 KV Cache 存储成本节省。
配合延迟物化技术，ExANS 在客户端 GPU 节点侧进行压缩，然后以超过 600 GB/s 的速度在存储节点侧解码。由于解码速度远高于网卡速率（25 GB/s），解码本身几乎不会成为瓶颈——相当于在一条公路上运了更多的货物，而货物到达后还能以超快速度卸货。
在大规模分布式训练中，定期保存 Checkpoint 是防止训练中断时丢失进度的必要手段。OpenLake 针对 Checkpoint 的写入模式做了专门优化：训练任务可以在不暂停的情况下，以流式方式将 Checkpoint 数据写入 OpenLake 存储。由于 OpenLake 支持极高的写入吞吐量，整个 Checkpoint 保存过程可以在秒级完成，相比传统方案（可能需要数分钟）大幅减少了训练中断时间。
训练数据预处理阶段通常涉及大量小文件的随机读取。OpenLake 针对这种模式优化了元数据访问和随机读性能，确保训练数据加载管线不会成为 GPU 的瓶颈。结合 io_uring 的批量提交能力，OpenLake 可以同时处理数万个小文件的并发读取请求。
对于 Agent 应用和长对话场景，OpenLake 提供了上下文数据的持久化存储能力。它可以将对话历史、Memory 数据和 Agent 状态以结构化的方式存储，并支持高速检索。这为构建长时间运行的 Agent 系统提供了可靠的数据基础设施。
对于大多数用户而言，部署的便捷性是选择存储系统的关键因素。OpenLake 在这一方面做得相当周到，提供了从轻量到生产级的多种部署方式。
对于想要快速上手的开发者，OpenLake 提供了两个预构建的 Docker 镜像：
openlake.Dockerfile：编译后的 CLI 工具镜像，适合单机使用和基准测试。使用多阶段构建，最终镜像基于 Debian Slim，大小和安全性都有保障。运行方式极为简单：docker run openlake/openlake:latest --help
openlaked.Dockerfile：OpenLake 服务守护进程镜像，提供 RPC 接口和 S3 兼容 API。它支持可选的 RDMA 构建（通过 --build-arg RDMA=1），以及硬件拓扑感知（hwloc）和 NUMA 亲和性配置。
两个镜像都遵循最小权限原则，以专用非 root 用户（openlake:openlake）运行，并使用 tini 作为 PID 1 进程管理。
对于生产环境，OpenLake 提供了完整的 Helm Chart，支持 Kubernetes 集群一键部署。Chart 提供了丰富的配置项：
local-path（测试环境）或 Ceph/Longhorn 等生产级存储类；支持多盘聚合（diskCount）replicaCount）和纠删码策略（defaultParityCount）OpenLake 还提供了一个基于 Next.js + React 构建的 Web 控制台（console/ 目录），计划部署在 Cloudflare Workers 上。该控制台提供了集群拓扑、健康状态、容量和遥测数据的可视化监控。
整体来看，OpenLake 的部署复杂度属于中等。Docker 验证环境可以在 10-15 分钟内完成，但如果需要发挥 RDMA 和 GPUDirect Storage 的全部性能，则需要支持 RDMA 的网卡、NVIDIA GPU + GDS 支持、以及 Kubernetes 集群环境。基础存储加速功能在非 RDMA 环境下也能带来显著收益。
OpenLake 采用 Rust Workspace 的 Monorepo 架构，根目录的 Cargo.toml 声明了完整的成员包：
crates/openlake_io：核心 I/O 引擎，封装 io_uring 和 compio 运行时crates/openlake_storage：存储引擎核心，包含数据布局、压缩（ExANS）和元数据管理crates/openlake_kv_client：KV Cache 客户端 SDKcrates/openlake_server：RPC 服务器和 S3 兼容 API 层cli/：命令行工具包console/：Next.js + React Web 控制台（前端），计划部署在 Cloudflare Workers| 组件 | 技术选型 |
|---|---|
| 核心语言 | Rust 1.88+ |
| 异步运行时 | compio（基于 io_uring） |
| HTTP 层 | cyper（hyper + axum on compio） |
| TLS | rustls + aws_lc_rs |
| 压缩 | ExANS（自研 GPU codec） |
| Web 前端 | Next.js 16 + React 19 + TailwindCSS |
| 可视化 | Recharts |
| 部署 | Docker + Helm + Cloudflare Workers |
OpenLake 的代码质量给人留下了深刻印象：README 提供了详尽的功能说明、快速开始指南和 benchmark 数据；CONTRIBUTING.md 详细说明了开发流程、代码规范和 PR 审核流程；Workspace 配置清晰，依赖版本锁定（Cargo.lock），Rust 1.88 最低版本要求确保了最新语言特性的使用。
传统对象存储（如 MinIO、Ceph RGW）在设计时并未考虑 AI 工作负载的特性——小 I/O 性能差、延迟高、无法利用 RDMA/GDS。OpenLake 通过重新设计存储引擎和 API，专为 AI 场景优化。
OpenLake 于 2026 年 7 月正式开源，截至目前已获得 2,351 stars，增长势头强劲。v0.8 版本引入的 ExANS 压缩技术进一步巩固了其在 KV Cache 管理领域的领先地位。考虑到大模型上下文窗口持续增长的趋势（从 4K 到 128K 再到 1M），KV Cache 存储将成为未来 AI 基础设施的关键瓶颈，OpenLake 的市场空间值得期待。
硬件门槛较高：RDMA 和 GPUDirect Storage 是 OpenLake 性能优势的关键，但这两项技术需要特定的硬件支持。在没有 RDMA 的环境下，OpenLake 相比传统 NVMe 存储的性能优势会大打折扣。
分布式生态尚在成熟中：作为 2026 年才开源的项目，OpenLake 的分布式存储生态系统（包括监控、告警、自动故障恢复等）还在快速迭代中。
Rust 生态的学习成本：对于习惯 Python/Java 的 AI 开发者，Rust 的所有权系统和编译期检查可能需要一定的学习曲线。
OpenLake 代表了 AI 存储基础设施的一个新方向：不再试图用缓存和预取来弥补存储的性能差距，而是从底层 I/O 开始重新设计，让存储真正成为 GPU 的"高速公路"。
对于正在构建高性能 LLM 推理服务或分布式训练平台的团队，OpenLake 是一个值得关注的技术选项。其 Apache-2.0 许可证允许自由使用和修改，多层次的部署方式（从 Docker 到 Kubernetes）降低了试用门槛，而 Rust + io_uring + RDMA 的技术组合在性能上具有足够的吸引力。
推荐阅读：