JuiceFS Blog

GPFS、Alluxio、JuiceFS 怎么选？一文看懂架构与适用场景

Thu, 23 Jul 2026 06:25:36 +0000

AI 工作负载的存储需求很难用单一指标衡量。训练、推理、模型分发、Agent 和数据湖等场景，对吞吐、延迟、并发访问、POSIX 兼容性、一致性、成本和运维复杂度的要求各不相同。因此，AI 存储选型需要回到具体业务场景，而不是简单比较“性能更高”或“成本更低”。

这篇文章会先从 AI 工作负载的典型 I/O 模式出发，梳理不同业务对存储系统提出的实际挑战；随后围绕 GPFS、Alluxio 和 JuiceFS 展开比较，分析它们在架构设计、文件系统语义、缓存机制、成本模型和适用边界上的差异，以及它们在不同 AI 场景中的适用性。

01 AI 工作负载的 I/O 模式和存储挑战

在 AI 场景中，我们接触到的企业需求可以大致归纳为以下几类。

智驾：大规模数据生产与训练

智驾是当前 AI 存储中数据规模较大的场景之一。大量路采车辆会持续产生图片、视频、传感器和轨迹数据，经过清洗、标注和格式转换后进入模型训练流程。常见数据格式包括 .mcap、.pack、TFRecord、LMDB 等。由于数据链路长、格式多、训练任务重，这类场景对底层存储的稳定性和可扩展性要求较高。

LLM 模型：全流程数据访问

基础模型场景覆盖数据清洗、模型训练、checkpoint 读写和推理服务等多个阶段。模型权重、训练数据和中间结果会在不同环节被反复访问，存储系统需要支撑长时间任务运行，并在任务异常、节点故障或训练恢复时保持稳定的数据访问能力。

多模态模型：小文件、聚合数据和模型文件并存

AIGC 场景包括文生图、图生图、文生视频、图生视频、3D 生成等业务形态。训练输入可能是大量图片、视频片段，也可能被聚合为 LMDB、Parquet 等格式以提升训练效率。训练过程中还会产生 checkpoint，并最终输出 safetensors 等模型文件，因此数据形态比单一训练场景更复杂。

算力平台：多云协同与模型分发

算力平台更关注模型和数据在不同环境之间的分发。用户可能从外部模型仓库拉取模型，也可能上传自己的模型，然后在不同集群、不同云环境中运行训练或推理任务。此时，关键问题是如何减少重复拷贝，让不同计算环境能够以一致方式访问同一批数据。

量化金融：性能要求与成本压力并存

量化金融的数据规模通常小于智驾和多模态 AIGC，但随着 Transformer、神经网络训练、时序建模和市场图结构建模等方法被引入，存储成本开始成为更明确的选型因素。

近期，在与量化客户的交流中，我们明显感受到，量化团队对存储成本的关注正在上升。GPFS 这类高性能文件存储本身更偏性能优先，尤其在大容量、全闪配置下，整体投入会比较高。以部分线下部署场景为例，如果选择大容量全闪 GPFS，存储投入可能接近一套 5090 GPU 集群的成本。

AI Agent：短生命周期沙箱中的数据共享

AI Agent 是一个正在快速发展的新场景。它通常涉及大量短生命周期的 Sandbox，每个 Sandbox 执行一个子任务，生命周期可能只有几秒，甚至更短。

这类任务运行时间短，但上下文、模型文件、工具文件和中间结果需要在子任务之间共享。如果每个 Sandbox 都独立完成文件系统挂载，而挂载过程本身需要数秒，就可能影响任务调度效率。更可行的方式，是在宿主机侧预先挂载，再通过 bind mount、PVC 或类似机制暴露给 Sandbox 使用。

从存储角度看，AI Agent 关注的不是单纯容量，而是短生命周期任务下的数据连续性、共享访问和挂载效率。随着 Agent 应用复杂度提升，这类场景对文件系统语义和数据共享能力的要求会继续上升。

场景	典型 I/O 模式	主要存储挑战	选型关注点
智驾	大文件吞吐、mmap 随机读、小文件读	数据规模大、训练链路长、随机读压力高	吞吐、缓存、元数据能力、容量成本
LLM 模型	大文件读写、混合读、checkpoint 读写	全流程访问、长期任务稳定性要求高	稳定吞吐、并发访问、故障恢复
多模态模型	小文件读、聚合大文件读、模型文件访问	小文件与大文件并存，多任务并发明显	缓存、元数据管理、多任务并发
算力平台	模型分发、跨集群访问、多云协同	数据需要跨环境一致访问	统一命名空间、多云分发、缓存治理
量化金融	大文件顺序读、小文件读、训练/回测访问	成本敏感度上升，性能与成本需平衡	容量成本、扩展方式、长期运维
AI Agent	小 I/O、多客户端共享、短生命周期访问	挂载效率、数据连续性、任务隔离	文件系统语义、共享访问、挂载方式

AI 工作负载的典型 IO 模式与存储需求

02 GPFS vs JuiceFS

从 PFS 到 GPFS：并行文件系统的能力边界

要理解 GPFS，首先需要理解 PFS（Parallel File System，并行文件系统）。一个比较直观的理解是：并行文件系统通过数据和元数据分离，让多个客户端能够并行访问底层存储资源。在这种架构中，元数据和数据走不同路径。客户端不需要把所有 I/O 都汇聚到单一节点，而是可以并行访问底层磁盘或存储节点。这样，数百个计算节点可以同时读写底层块设备或存储资源，从而打破单一路径的网络瓶颈，实现横向扩展。

image: 并行文件系统架构
caption: 并行文件系统架构

GPFS、Lustre、BeeGFS 等都属于典型的并行文件系统。GPFS 全称为 General Parallel File System，后来更名为 IBM Storage Scale，是一套成熟度很高、覆盖场景广的并行文件系统，在高性能计算领域长期占据重要位置。它在吞吐、并发访问和一致性方面优势明显，适合对性能和可靠性要求较高的场景；但在 AI 基础设施持续扩张、降本诉求增强的背景下，很高的成本和复杂部署也会成为选型中的现实制约。

GPFS 的交付形态与典型适用场景

GPFS 典型应用包括量化金融、基因测序、物理仿真和气象科学等。在国内，用户通常会通过云厂商或硬件厂商接触到不同形态的 IBM Storage Scale / GPFS 方案。

版本	名称	GPFS 版本
阿里云	CPFS	ECE 版本。阿里云是GPFS的最早期使用者，定制化了多租权限等能力
火山云	VePFS	ECE 版本
百度云	PFS	ECE 版本
腾讯云	GooseFSx	ECE 版本
浪潮、华三	GPFS	ECE 版本，主要用于线下 IDC 机房
IBM 原厂	IBM Storage Scale System	SSS 专用完全体，支持平滑扩缩容等高级场景，原厂支持，进口硬件，价格昂贵

这些产品通常可以理解为基于 IBM Storage Scale ECE 版本的 OEM 或定制化形态。ECE 即 Erasure Code Edition，核心能力之一是支持基于多块磁盘和 I/O Server 构建存储池，并通过纠删码等机制管理数据可靠性。用户提供磁盘和 I/O Server 后，系统可以基于这些资源创建元数据三副本，并通过纠删码方式组织数据，从而形成一套具备可靠性保障的并行文件系统。

在线下 IDC 场景中，用户也可能通过浪潮、华三或直接从云商购买线下版本等方式采购 GPFS 相关方案。这类方案通常会结合国产服务器和存储硬件，价格相比 IBM 原厂整体方案可能更低，也更适合一些本地机房性价比部署需求。

不过，这类方案需要关注交付和运维保障。GPFS 是一套复杂系统，实际运行中会涉及硬件、网络、磁盘、License、原厂服务和集成商实施等多个环节。尤其在故障排查、版本升级和性能调优时，厂商支持、实施经验和响应效率都会直接影响最终使用效果。

IBM 原厂方案通常以 IBM Storage Scale System 形式交付，可以理解为更完整的一体化方案，在扩缩容、复杂场景支持和原厂服务方面更有保障。相应地，它的软件成本也更高。原厂方案单 PB 需要数百万元人民币，更适合预算充足、对原厂支持和完整能力要求较高的场景，但也要接受本地技术支持不足，需要等待印度、美国等区域响应的情况。

架构优势与代价：Metanode、Token 锁与强一致性

GPFS 的架构优势主要体现在 Metanode 和分布式 Token 锁两个机制上：前者影响元数据协调方式，后者影响多客户端并发访问时的一致性控制。

在 Metanode 机制下，GPFS 集群通常包含 I/O Server、数据盘和元数据盘，元数据存储在元数据盘上。与固定中心化元数据服务不同，GPFS 会让客户端参与部分元数据协调。

image: GPFS Metanode 元数据
caption: GPFS Metanode 元数据协调与数据访问路径

也就是说，GPFS 会让不同客户端在不同文件或 inode 上承担协调角色，而不是把所有元数据请求集中到一个固定节点。因此，GPFS 客户端之间需要保持通信关系，通常通过 1191 端口维护节点连接。一旦出现网络波动或连接异常，cluster manager 需要判断节点状态，并将异常节点踢出集群，避免脑裂和数据不一致。

这种设计的优势在于分散元数据协调压力，在网络和磁盘足够稳定的情况下，可以支撑较强的并发访问能力。但它也对集群环境提出了更高要求：如果网络质量不佳，或底层磁盘响应变慢，就可能影响整体协调效率，严重时出现卡顿、Long Waiters，甚至需要通过重启恢复。这类问题并不一定来自 GPFS 能力不足，而是其高性能、强一致架构对网络、磁盘和集群状态管理要求较高。

分布式 Token 锁是 GPFS 一致性能力的另一项关键机制。它会对读写操作进行 Token 管理：读需要获取读 Token，写需要获取写 Token。当多个客户端访问同一个文件时，GPFS 会通过 Token 的授予、撤销和转移，控制并发读写关系。

image: GPFS Token
caption: GPFS Token 撤销与授予流程

例如，客户端 A 持有某个文件的写 Token，此时客户端 B 要读取或修改同一文件，GPFS 就需要向 A 发起 Token revoke。A 收到请求后，需要将相关脏数据落盘并释放 Token，B 才能继续访问。这个过程保证了较强的一致性，但也依赖网络和磁盘能够稳定、快速地完成响应。

如果在 Token revoke 过程中，底层磁盘写入变慢，或者网络出现波动，就可能出现 Long Waiters。实际排障中，请求长时间等待在 Revoke Token 或 Reopen Token 相关操作上并不少见。这也是 GPFS 架构中优势与代价并存的地方：它通过 Token 机制提供强一致和并发控制能力，但这套机制本身也会增加系统复杂度。

在早期 IB 网络或高质量光纤网络环境下，低延迟、高可靠网络能够较好地支撑这套机制。但在一些新的尤其是 RoCE 部署环境中，如果网络条件、硬件质量或运维能力达不到要求，尤其是在数百个客户端同时处于一个集群中的时候，Token 协调带来的稳定性压力就会更加明显。

总体来看，这套机制能够支撑高性能并行访问，但也对网络、磁盘稳定性和集群运维能力提出了较高要求。客户端异常退出时，还需要处理 Token 回收和集群状态恢复。因此，选型时需要评估团队是否具备相应的部署、监控和故障处理能力。

从实际使用经验看，GPFS 在部署和使用中还需要关注几个工程问题：。

mmap 场景。 GPFS 在 mmap 场景下有特殊机制，例如通过 pagepool 等方式减少内存拷贝、提升性能。但这也意味着它与操作系统内存管理之间存在更复杂的交互，一般不建议在缺乏充分验证的情况下大规模依赖 mmap 访问模式。
热点文件和大目录。 热点文件、热点目录、海量小文件或大量客户端并发操作同一目录时，元数据协调和锁管理都可能成为性能瓶颈。实际使用中通常需要通过目录拆分、数据分片和访问模式优化来降低这类风险。
运维管理和监控体系。 GPFS 的管理界面对新用户并不算友好，部分监控信息也不够直观。很多团队会外接 Grafana 等监控体系，以便更好地观察集群状态、性能指标和异常信息。
CES、AFM 等组件。 CES、AFM 等能力可以支撑更多复杂场景，但也会引入额外配置、运维和故障排查成本。对于缺少长期 GPFS 运维经验的团队来说，这部分复杂度需要提前评估。
容量规划。 很多 GPFS 或 CPFS 形态的产品更强调扩容能力，缩容通常不如扩容灵活。因此，部署早期需要做好容量规划，避免初始容量过大带来长期成本压力，或容量过小影响后续业务扩展。

性能比较

直觉上，很多人会认为：JuiceFS 作为基于对象存储和独立元数据服务的文件系统，很难与 GPFS 这样的并行文件系统直接比较。但在一些 AI 负载场景中，两者确实存在可比较的空间。

需要注意的是，GPFS 更依赖底层磁盘、存储服务器、网络、客户端和并行文件系统机制的整体配合；JuiceFS 则更多受到对象存储性能、元数据服务、客户端缓存、分布式缓存组和挂载模式等因素影响。因此，比较两者时，不能只看单个性能数字，而要结合具体 I/O 模式、部署架构、数据规模和访问路径来判断。

以下测试基于 JuiceFS 企业版进行，社区版与企业版的核心架构一致，社区版用户也可以参考相关测试方法和结果。

顺序读：GPFS 单节点更强，JuiceFS 依靠缓存组扩展吞吐

单节点场景下，两者的性能模型差异比较明显。从测试结果看，在单节点配置两块 400Gbps 网卡的情况下，GPFS 单节点顺序读可以达到约 100GB/s。

JuiceFS 在 TCP 模式下（200Gbps 网卡），单节点顺序读峰值测试约为 20GB/s；RDMA 模式下（400Gbps*2 网卡），单节点顺序读达到约 55GB/s。如果业务需要更高的聚合吞吐，可以通过增加缓存节点横向扩展整体带宽。例如，在我们一个智驾客户的场景中，部署了约 150 台缓存节点，每台节点配置 160Gbps 网卡，最终聚合出约 2.3TB/s 的业务吞吐能力。

顺序写：GPFS 强在同步写，JuiceFS 依赖 writeback 扩展吞吐

顺序写场景下，如果只看同步写语义，GPFS 更有优势。它的写入能力来自底层并行存储系统，数据写入后可以按照强一致文件系统语义被其他客户端访问，更适合对写入可靠性、实时可见性和一致性要求较高的场景。

JuiceFS 的顺序写需要区分同步写和 writeback。同步写模式下，数据需要写入后端对象存储，性能会受到后端存储、协议开销和网络链路影响；开启 writeback 后，数据会先写入客户端本地缓存，再异步上传到对象存储，聚合吞吐可以提高，但实时可见性和一致性语义会发生变化。

因此，强同步持久化和实时可见场景更适合 GPFS；能够接受异步上传语义的业务，则可以利用 JuiceFS writeback 提升吞吐。

随机读：GPFS 在高并发下更强，JuiceFS 在部分场景中也具备竞争力

在 4K 单进程随机读测试中，我们对比了 JuiceFS、GPFS 和本地盘/tmp（EXT4）这些不同文件系统。

image: 单进程表现
caption

iodepth 为 1、2、4 时，JuiceFS 均高于 GPFS；
iodepth 提高到 8 后，GPFS 开始超过 JuiceFS，随后基本稳定在 80K IOPS 左右；
JuiceFS 在 iodepth 为 4 和 8 时达到约 68K IOPS，之后随着 I/O 深度继续提高，性能逐步回落。

多进程随机读时，情况会更复杂。当多个进程并发读取同一文件时，GPFS 的一致性和锁机制可能引入额外开销。为进一步验证这一影响，我们分别测试了多进程读取同一文件和不同文件的性能。

image: 多进程读
caption

GPFS 读取不同文件时，IOPS 随 numjobs 增加快速上升，在 numjobs=12 时达到约 433K；
GPFS 读取同一文件时，性能在 numjobs=2 后逐步下降，表明一致性协调可能带来额外开销；
JuiceFS 在 numjobs=12 时达到约 258K IOPS，之后基本稳定在 250K IOPS 左右。

测试均关闭了本地缓存，数据由分布式缓存提供。结果显示，GPFS 在高并发随机读场景下性能更高，JuiceFS 也保持了较高的随机读能力，可以满足大多数 AI 训练的要求。

随机写：GPFS 高并发更强

随机写更能体现两类系统的架构差异。JuiceFS 的随机写表现取决于是否开启 writeback。不开启时，性能主要受后端对象存储影响；开启后，则更多反映客户端与本地缓存路径的处理能力。

在开启 writeback，并将 cache-dir 设置为本地 NVMe 盘的测试条件下，这组 4K 多进程随机写结果可以看到：

image: 多进程写
caption

numjobs 从 1 增加到 3 时，JuiceFS 从约 28K IOPS 提升到约 56K IOPS，明显高于 GPFS；
numjobs=12 时，JuiceFS 约 51K IOPS，GPFS 约 50K IOPS，性能基本接近；
numjobs=16 后，GPFS 提升到约 66K IOPS，并在 numjobs=20 时达到约 81K IOPS；JuiceFS 则保持在 50–60K IOPS 区间。

这组测试说明：GPFS 在随机写性能上有一定优势，JuiceFS 在开启 writeback 后差距不大。但随机写的需求在 AI 业务中并不常见，不用作为重点评估方向。

选型小结

GPFS 更适合预算充足，并对低延迟、强一致、高并发访问和随机写能力要求较高的场景，例如传统 HPC、科学计算和部分量化金融业务。相应地，其性能也依赖稳定的网络、存储硬件和专业运维能力。

对比维度	GPFS（对称式去中心化）	JuiceFS（存储与元数据分离）
元数据架构	分散的内嵌本地内存	独立的外部高性能数据库（云原生、轻量）
数据存储层	昂贵且强绑定的共享 SAN / 并行盘	低成本、高可靠、高弹性的对象存储
锁与并发机制	分布式 Token 锁（保障强一致）	乐观并发机制（社区版）单线程处理核心（企业版）
典型场景	部分 HPC、科学计算场景	AI 研究、训练、推理加速大规模数据管理

围绕当下的 AI 研究、训练、推理加速，和大规模数据管理所面临的扩展性、性能、成本、多云管理等问题，JuiceFS 是更适合的方案，并在上述提及的所有领域中得到生产验证。

03 Alluxio vs JuiceFS

Alluxio 是企业在 AI 存储选型中经常会拿来和 JuiceFS 比较的方案。两者都可以基于对象存储提供文件系统访问和缓存加速能力，但在产品定位、数据组织方式和元数据架构上存在明显差异。

在产品演进路径方面，两者也有所不同：Alluxio 当前面向 AI 场景的能力更新更多集中在 Enterprise AI 产品线上。Alluxio 开源仓库最新 release 为 v2.9.4，发布时间是 2024 年 6 月；JuiceFS 保持开源版与企业版并行演进，很多新的能力会先在开源版中发布、验证和打磨，稳定后再逐步进入企业版，服务更多企业用户。

核心架构差异

第一，数据组织与一致性边界

Alluxio 采用 1:1 透明缓存，不改变源文件在底层存储中的组织方式。已有数据无需提前导入或重新组织，缓存层也可以按需接入或移除。

image: juicefs 与 alluxio 不同点
caption: Alluxio 与 JuiceFS 组织数据的方式不同

JuiceFS 则会将文件切分为数据块写入对象存储，并通过元数据服务维护文件系统语义和数据块映射。业务侧看到的是完整文件系统，而对象存储中保存的是由 JuiceFS 管理的数据块，并非原始文件。

这也带来了 source of truth 和一致性边界的差异。Alluxio 的真实数据通常仍位于对象存储或其他 UFS 中，缓存层主要负责加速访问；如果业务绕过 Alluxio 直接修改底层数据，就需要处理缓存刷新、失效或重新同步问题。

JuiceFS 则由元数据服务和对象存储共同构成完整文件系统，文件状态和数据映射由 JuiceFS 统一维护，业务读写也需要经过 JuiceFS。因此，其一致性边界位于文件系统内部，不依赖缓存层与底层数据之间的额外同步。

第二，缓存与命名空间的组织方式不同。

Alluxio 更强调统一命名空间和共享缓存池。它可以将 OSS、S3、HDFS、Ceph、MinIO、NAS 等多个底层存储接入同一命名空间，并通过一套分布式缓存统一加速。对于已经存在多套存储、不希望迁移或重新组织数据的场景，这种方式更加灵活。不过，当多个业务共享同一缓存池时，通常需要通过目录、优先级和 TTL 等策略进行资源管理与隔离。

image: 命名空间与缓存
caption: 命名空间与缓存组织对比

JuiceFS 通常以独立文件系统为管理单元。不同对象存储后端，例如 OSS、COS、TOS，通常会创建不同的文件系统，并配置各自的缓存池。相比 Alluxio 强调跨数据源的统一视图和缓存共享，JuiceFS 更强调文件系统、权限和数据治理边界的清晰。

此外，JuiceFS 企业版也可以将多个 Bucket 接入同一个文件系统，并使用同一套缓存资源进行加速。这使其在保持文件系统管理边界的同时，也能够覆盖部分多数据源统一访问场景。

第三，元数据架构不同。

Alluxio 企业版将缓存和部分状态管理分散到 Worker。Worker 不仅承担数据缓存，也参与缓存状态和数据位置等信息的管理，使数据访问更贴近计算节点或 GPU 节点。协调与管理组件仍然存在，但缓存访问相关状态并非全部集中在独立元数据服务中。相应地，当 Worker 频繁重启或扩缩容时，需要关注缓存状态和数据位置的恢复与协调。

image: 分布式缓存对比
caption: 分布式缓存架构对比

JuiceFS 则将核心文件系统元数据交由独立元数据服务统一管理。开源版可以使用 Redis、TiKV 等元数据引擎，企业版则提供高可用元数据服务，以支持一致性和事务能力。分布式缓存节点只负责缓存数据块，因此缓存节点异常主要影响缓存命中率和访问性能，不会改变文件系统元数据状态。

架构差异如何影响实际使用

第一，POSIX 兼容性。

Alluxio 可以通过文件系统接口暴露对象存储或其他 UFS 中的数据，文件系统语义并不完整。时间戳、文件锁、硬链接、软链接、扩展属性、ACL 等能力，可能需要额外开启，或存在使用边界。对于只读加速、轻量访问场景，这些问题通常影响不大；但如果业务希望把它作为完整文件系统使用，就需要慎重考虑。

JuiceFS 的目标，是在对象存储之上提供完整的文件系统能力。因此，我们会不遗余力地补齐 POSIX 兼容性，不只覆盖目录、权限、时间戳、文件锁等常见语义，也会持续支持 ioctl 设置 immutable、只读等更细粒度的系统调用。从实际使用情况看，JuiceFS 的 POSIX 兼容性已经能够覆盖绝大多数业务场景，接近百分百 POSIX 兼容。

第二，写入与写放大。

Alluxio 保持源文件形态，这对透明访问很友好，也降低了已有数据接入成本。但在随机写、覆盖写或局部修改场景下，需要关注写放大问题。原因在于，对象存储通常不支持对对象内容进行原地修改；如果底层仍然保持 1:1 文件布局，局部修改可能需要触发更大范围的数据重写，甚至重新写回整个对象或文件。

JuiceFS 采用数据切块方式。随机写或追加写时，文件系统可以只处理受影响的数据块，并更新对应元数据，不必完全受对象存储原始文件形态限制。因此，在局部修改和随机写场景下，JuiceFS 更容易控制写放大。相应地，如果业务需要把 JuiceFS 中的数据恢复成对象存储中的原始文件形态，通常需要通过额外的导出或转存机制实现。

第三，部署与工程能力。

Alluxio 企业版支持全组件 Kubernetes 部署，也可以支持不落对象存储的临时写缓存场景，例如临时解压、中间结果计算、短时间使用后丢弃的数据等。这类能力更贴近缓存层和计算侧加速需求。

JuiceFS 企业版目前元数据服务通常部署在虚拟机或物理机上，主要是出于元数据稳定性和系统可靠性的考虑。JuiceFS 更强调长期文件系统能力，例如大规模元数据管理、回收站、事务原子性、缓存治理、平滑升级和开源生态。在已有实践中，JuiceFS 已经支持 5000 亿级文件规模，这也是它作为完整文件系统在大规模数据管理场景中的重要能力体现。

选型建议

Alluxio 和 JuiceFS 的差异，不是简单的功能多少，而是解决问题的方向不同。

如果数据已经存放在对象存储、HDFS、Ceph、MinIO 或 NAS 中，业务不希望迁移或重新组织数据，只想增加一层可插拔的缓存来提升读取性能，可以考虑 Alluxio。

如果希望以对象存储为基础构建完整的文件系统，同时支持读写混合负载、完整 POSIX 语义、强一致性、弹性元数据扩展、万级客户端并发和多云数据管理，JuiceFS 会更匹配。

04 小结

GPFS、Alluxio 和 JuiceFS 面向的核心问题并不相同：GPFS 更偏向高性能计算中的低延迟和高并发读写，Alluxio 主要解决已有数据的缓存加速，JuiceFS 则是在对象存储之上提供完整、可扩展的文件系统。

因此，选型时不应只比较单项性能，还要先明确业务需要的是高性能共享存储、数据加速层，还是面向多云和大规模场景的完整文件系统，再结合一致性、数据规模、成本和运维要求做判断。

支撑亿级文件规模：途虎养车 JuiceFS + Ceph RADOS 存储优化实践

Wed, 15 Jul 2026 09:28:48 +0000

途虎养车是一家线上线下一体化汽车服务平台。截至 2025 年底，平台注册用户达 1.623 亿，工场店达到 8008 家。随着业务规模持续扩大，途虎养车的底层基础设施需要支撑更复杂的数据管理和计算场景。此前，平台长期并存 NFS、Alluxio、MinIO、SeaweedFS 等多套存储系统，存在架构割裂、数据流动成本高、运维复杂度高等问题。

在统一存储底座的选型过程中，途虎养车参考了盘古在大规模 AI 存储场景中的架构思路，并结合自身私有云环境和已有 Ceph 存储基础，最终选择以 JuiceFS + TiKV + Ceph RADOS 的组合式方案构建统一 AI 存储基座。该系统统一支撑 AI 训练、AI 推理和大数据处理等场景，目前已支撑亿级文件规模，在低并发基准测试中，小文件顺序写性能最高提升 5 倍，小文件读性能最高提升 3 倍。

本文将围绕选型思路、架构设计和生产落地展开，重点介绍途虎养车如何在已有 Ceph 基础设施上构建统一 AI 存储基座，并从 Ceph RADOS 数据路径、纠删码 Pool 容量效率、小文件写放大优化和容器化稳定性治理等角度，分享统一存储底座在生产环境中的实践经验与后续规划。

01 建设背景：从多套存储并存到统一云存储底座

在业务快速发展的早期阶段，存储系统更多是围绕具体业务需求独立建设，以满足当时的交付效率和场景诉求。随着系统规模扩大，这种按场景建设的方式逐渐形成了多套存储并存的格局。尤其是在业务向大规模 AI 训练、AI 推理和云原生计算演进后，底层存储在架构统一性、数据流动性、运维复杂度和性能稳定性方面的问题开始集中显现。

主要痛点体现在以下几个方面。

第一，运维成本较高。线上长期并存 NFS、Alluxio、MinIO、Ceph、SeaweedFS 以及各类云盘等多套存储系统。不同系统的部署方式、访问接口、运维模型和故障处理方式各不相同，导致整体技术栈较为割裂。随着集群规模扩大，日常维护、容量规划、故障排查和版本升级的复杂度持续上升。

第二，数据孤岛问题明显。不同存储系统之间缺乏统一的数据访问路径，数据在文件存储、对象存储和大数据访问体系之间流动成本较高。在 AI 训练场景中，核心训练链路通常依赖 POSIX 文件语义，而周边的数据处理、模型管理、备份归档等工具链又大量使用对象存储接口。多种访问方式之间无法自然互通，导致数据需要在不同系统之间反复迁移或同步，增加了链路复杂度和存储冗余。

第三，数据规模增长带来成本压力。随着业务规模持续扩大，文件数量和数据总量都在快速增长。与此同时，硬件采购、机房资源和存储运维成本也在上升。如何在保证可靠性和性能的前提下，提高存储资源利用率、降低总体拥有成本，成为基础设施建设中必须重点考虑的问题。

第四，AI 负载对性能和可靠性提出了更高要求。AI 训练、AI 推理、存算分离和大数据计算等场景，对底层存储的并发能力、吞吐能力、访问时延和稳定性提出了更高要求。尤其是在大规模小文件访问、多机并发读取、模型文件加载和在线推理服务中，存储系统不仅要具备稳定的容量支撑能力，还需要在高并发场景下保持可预期的性能表现。

在上述背景下，原有多套存储系统并存的方式已经难以支撑业务的长期演进。我们希望通过统一云存储底座的建设，逐步收敛分散的存储能力，降低多套系统并行带来的运维复杂度，并提升数据在不同计算形态之间的流动效率。

从建设目标来看，这套统一云存储底座需要重点覆盖两类能力方向。

一是面向基础设施与虚拟化负载的块存储能力。这类能力主要服务于私有云和虚拟机环境，目标是为云盘、虚拟机镜像和传统基础设施服务提供高性能、高可靠的块存储支撑。

二是面向云原生与多元化计算负载的数据访问能力。这类能力主要服务于 Kubernetes 等容器化环境，覆盖传统微服务、大数据计算、AI 训练、AI 推理以及向量数据库等新型中间件负载。其中，AI 训练和 AI 推理对文件语义、对象接口、数据吞吐、小文件性能和多机并发访问能力提出了更集中的挑战。

因此，统一云存储底座的建设既包括面向虚拟化环境的块存储能力，也包括面向 AI 与云原生负载的数据访问能力。下文将重点展开后者，即如何基于 JuiceFS 构建统一的数据访问底座，支撑 AI 训练、AI 推理和大数据处理等场景。

02 基于 JuiceFS 建设统一 AI 存储基座

盘古架构参照与技术权衡

在统一存储基础设施的建设过程中，我们重点参考了阿里云在 2023 年公开展示的面向 AI 场景优化的自研分布式存储系统“盘古”。通过分析其面向大规模训练场景的存储架构演进思路，我们结合自身私有云环境、已有存储基础和业务负载特点，对统一存储底座的技术路线进行了系统性的对比与权衡。

如果将分布式存储系统拆解为元数据层和数据存储层，可以看到盘古与 JuiceFS + Ceph RADOS 在目标上有一定相通之处：二者都需要支撑大规模数据访问、存算分离、多协议接入和高可靠存储。但在具体实现路径上，两者存在明显差异。

阿里云盘古采用分布式 Master 架构，这是一种典型的中心化高可用集群方案。在公有云多租户、超大规模和高弹性的基础设施环境下，中心化调度可以更好地感知集群状态，并在坏盘、机器上下线、故障隔离等场景中降低对线上任务的影响，从而提升整体系统的稳定性和可运维性。

image: 盘古架构
caption: 盘古架构

与此相比，JuiceFS + Ceph RADOS 采用组合式落地路径，通过 JuiceFS 承担统一文件系统层，由后端元数据引擎和 Ceph RADOS 分别承载元数据与数据存储能力。Ceph 通过 CRUSH 算法实现数据分布和故障域管理，底层数据组织更加去中心化。

在“存算分离”的设计思想下，盘古与 JuiceFS + Ceph RADOS 体现出不同的工程权衡。盘古采用偏重客户端的技术路径。当用户在计算节点挂载并写入盘古存储时，无论底层采用三副本策略，还是采用 9:3、4:2 等纠删码（EC）架构，数据切片分发、EC 计算和校验等逻辑都可以在客户端侧承担更多工作。这种设计能够减轻后端存储服务器的计算压力，有利于支撑公有云级别的大规模扩展，但也会在一定程度上消耗业务计算节点的网络和 CPU 资源，并提高客户端复杂度。

image: 盘古与 JuiceFS 对比
caption: 盘古与 JuiceFS 对比

JuiceFS + Ceph RADOS 架构则更偏向“轻客户端 + 后端存储集群承载数据可靠性”的模式。在该架构中，JuiceFS 客户端主要负责文件系统语义、元数据交互、缓存管理和数据访问调度；实际数据写入 Ceph RADOS 后，底层采用多副本还是纠删码，主要由 Ceph 存储集群内部完成。这样可以让计算节点侧保持相对轻量，降低对业务训练进程的干扰，同时复用已有 Ceph 存储资源。

对于我们的私有云环境而言，重新建设一套类似盘古的一体化分布式存储系统，意味着较高的研发和运维投入。相比之下，基于 JuiceFS + Ceph RADOS 的组合式方案，可以在已有 Ceph 资源基础上快速构建统一文件系统层，并通过多协议接入能力支撑 AI 训练、AI 推理和大数据处理场景。

统一 AI 存储基座架构

我们最终选择基于 JuiceFS 构建统一 AI 存储基座。整体架构从上至下可以分为四个层级。

第一层是工作负载层。这一层涵盖虚拟机、Kubernetes 容器化业务、传统微服务架构，以及 AI 训练、AI 推理和大数据 Spark 计算任务。

第二层是缓存层。缓存层包括分布式数据缓存池（DataCache Pool）与分布式键值缓存池（KVCache Pool）。其中，DataCache 主要用于加速训练数据集、模型文件和热点文件的重复读取，降低后端存储压力；KVCache 则面向大模型推理场景，用于在多级存储体系中承载上下文数据的缓存与访问加速，提升在线推理服务的响应效率。

image: 途虎统一云存储架构
caption: 途虎统一云存储架构

第三层是存储协议层。JuiceFS 在这一层提供统一的数据访问入口。AI 训练任务可以通过 POSIX FUSE 或 CSI Driver 访问数据；大数据 Spark 任务可以通过 JuiceFS Hadoop Java SDK 接入；对象存储工具链可以通过 S3 Gateway 访问同一份数据。通过这种方式，文件存储、对象存储和大数据访问接口可以围绕同一套底层数据形成统一访问路径，减少不同存储系统之间的数据搬运和重复存储。

需要说明的是，虚拟机云盘等块存储场景主要由 Ceph RBD 承担，它属于整体云存储体系中的块存储能力；本文重点讨论的是基于 JuiceFS 构建的文件、对象和大数据访问底座。二者可以共享底层 Ceph 资源体系，但在访问语义和服务对象上需要区分。

第四层是存储引擎层。JuiceFS 采用数据与元数据分离的架构。对于亿级文件规模的文件系统来说，元数据能力直接影响路径解析、目录遍历、文件属性查询、小文件访问以及并发任务启动时的整体性能。TiKV 具备分布式事务、强一致性、高可用和水平扩展能力，能够为大规模文件系统提供稳定的元数据支撑。于是在元数据层，我们构建了一个由五个节点组成的 TiKV 分布式集群。

在数据层，我们采用 Ceph RADOS 作为 JuiceFS 的底层数据存储引擎。Ceph RADOS 可以复用现有私有云存储资源，降低重复建设成本；同时，通过构建纠删码 Pool 存放物理数据，可以在保证可靠性的前提下提升物理磁盘净容量利用率，缓解数据规模增长带来的存储成本压力。

在这套架构下，系统的数据通信可以划分为两条路径：一条是客户端与元数据引擎 TiKV 之间的元数据交互路径，主要负责路径查找、目录结构、文件属性和状态信息等操作；另一条是客户端与底层数据存储引擎 Ceph RADOS 之间的数据读写路径，主要负责实际数据块的存取。

通过 librados，JuiceFS 可以与底层 Ceph RADOS 进行数据交互。相比传统网关型存储架构，这种方式减少了多层转发开销，使客户端在完成元数据交互后，能够更直接地访问底层存储集群，从而缩短数据访问链路。

image: 途虎 JuiceFS 架构图
caption: 途虎 JuiceFS 架构图

03 生产落地与优化实践

核心场景落地与存储体系收敛

在大模型业务场景中，公司已划分专门的自建算力集群，用于承载通义千问、MiniMax 等模型推理服务。同时，内部业务线自研的各类定制化模型在通过生产验证后，也已逐步接入 JuiceFS 文件系统。由此，核心大模型推理与训练应用开始统一接入新的文件存储底座，原有网络文件系统集群和 Alluxio 存储集群也进入分批下线阶段。

在核心中间件与后台备份场景中，包括大规模 ClickHouse 应用在内，线上多类核心中间件系统以及全量业务生产备份任务，也已完成对 JuiceFS 文件系统的接入。随着统一文件底座在容量、稳定性和访问效率方面逐步验证，原有 MinIO、SeaweedFS 等存储集群也开始进入停机和下线序列，从而降低多套存储系统并存带来的日常维护复杂度。

AI 训练与推理场景的缓存加速

针对 AI 训练场景，训练数据通常具有“一次生成、多次读取”的特点。我们利用 JuiceFS 社区版的本地数据缓存能力，将训练集中的热点数据缓存在计算节点侧，从而降低后端存储压力，并提升多机并发读取效率。

针对大模型推理场景，模型在对外提供在线服务或进行 Token 迭代生成时，对上下文数据加载的延迟和吞吐较为敏感。在单机显存和内存容量有限的情况下，我们通过分层缓存机制，对上下文数据进行分级缓存和访问加速，从而提升在线推理服务的响应效率。

性能压测与小 I/O 调优

在统一存储底座落地后，我们重点验证了海量小文件场景下的读写性能。基于前文所述的 JuiceFS + Ceph RADOS 架构，我们使用 juicefs bench 与 fio 对小文件读写和随机 I/O 能力进行了压测对比，以评估该方案在关闭本地缓存、低并发条件下的实际表现。

为尽量排除缓存因素对结果的影响，测试中关闭了所有本地缓存，以透传模式进行压测。需要说明的是，该轮测试主要用于快速验证架构可行性，当时仅在客户端配置了 4 个并发线程进行局部测算，因此测试数据并不代表集群的真实性能峰值。

即便在低并发的基准测试条件下，JuiceFS + Ceph RADOS 方案相比原有 JuiceFS + MinIO 方案仍体现出明显的性能提升：

image: MinIO 与 Ceph RADOS 压测对比
caption: MinIO 与 Ceph RADOS 压测对比

小文件写入性能提升明显。小文件写性能提升约 5.5 倍，单文件写入耗时也明显下降。
小文件读取性能提升约 3.2 倍。读取速率和单文件读取耗时均有改善。
随机 I/O 能力整体提升。随机读写的吞吐和 IOPS 均有不同程度提升，其中随机写 IOPS 提升超过 3 倍。

从架构层面看，JuiceFS + MinIO 方案需要经过 S3 接口和对象存储服务链路，而 JuiceFS + Ceph RADOS 方案可以通过 librados 更直接地与底层存储集群交互，减少网关层转发开销。因此，在小文件写入和随机写入等对访问链路较敏感的场景下，Ceph RADOS 后端表现出更明显的性能优势。

不过，在随机读取小文件的测试中，由于关闭了本地缓存，数据仍需要从底层物理盘实时检索，因此读取性能没有像写入一样出现数倍提升，但整体仍保持了约 1.4 倍的稳定提升。

小文件空间放大与写放大优化

在纠删码（EC）模式下，传统的 EC 算法需要根据条带单元（Stripe Unit）进行对齐。在 6+3 的场景下，即使写入一个 10 字节的超小文件，系统也需要填充 6 个 Data Chunk 至 4KB，再叠加 3 个 Coding Chunk，导致实际物理占用高达 36KB，造成严重的写放大和几千倍的空间浪费。

image: 写放大优化前后对比
caption: 写放大优化前后对比

为缓解这一问题，我们通过升级引入 Ceph 的 Fast EC 特性，对小对象写入进行优化。

一方面，Fast EC 可以缓解小文件空间放大问题。开启后，小对象不再强制填充整个条带，而是仅写入所需条带。以 10 字节小文件为例，逻辑大小仍然保持 10 字节，物理空间则占用第一个条带；在最小分配单元为 4KB 并叠加校验数据后，物理空间占用可降至 16KB。

另一方面，Fast EC 也有助于提升小 I/O 场景下的读写效率。读取时无需读取完整条带，只需提取所需数据；写入时则可以利用奇偶校验增量写入（PDW）减少不必要的网络交互和 I/O 消耗，从而改善小文件整体读写性能。

JuiceFS Mount Pod 稳定性优化

在容器化环境下，AI 训练应用曾偶发 Bad file descriptor 报错，严重影响训练效率，排查后发现与 Mount Pod 的 OOM（内存溢出）有关。

image: 周期性 OOM 客户端内存占用
caption: 周期性 OOM 客户端内存占用

第一类是元数据备份引发的周期性 OOM。当集群文件数量达到千万级甚至亿级时，JuiceFS 默认每小时执行的周期性元数据备份会产生较大的备份文件。由于该备份任务会随机选择集群中的客户端执行，而底层 RADOS 架构对单次 Object 写入存在大小限制，例如 128MB，因此在大规模文件系统场景下，备份任务可能高频失败，并进一步导致 Mount Pod 内存持续增长，最终触发 OOM。

针对这一问题，我们关闭了 Mount Pod 的自动备份能力，禁止在线客户端执行自动备份，改由专用定时任务在后台统一处理元数据备份，从而避免业务客户端承担额外的备份压力。

image: 偶发性 OOM 客户端内存占用
caption: 偶发性 OOM 客户端内存占用

第二类是页缓存增长引发的偶发性 OOM。在业务频繁读取大量本地缓存时，Linux 内核页缓存会持续上升。此时，即使容器实际资源使用量只有约 1.1GB，Kubernetes 的 OOM 判断仍可能以 working_set_bytes 为依据。由于该指标包含页缓存，当其上升到较高水平，例如 33.5GB 时，就可能触发 OOM Kill，导致客户端偶发断连。

针对这一问题，我们首先结合历史监控数据，合理调大并设置 limits.memory。其次，对缓存资源进行物理隔离，避免所有 PVC 共享同一个本地缓存目录。对于 CPU 节点等内存相对较小的机器，则将本地缓存容量（Data Cache Size）限制在合理区间，例如 10GB 至 50GB，并在达到上限后开启主动回收机制，避免容器内核页缓存无序增长。

通过上述优化，Mount Pod 在大规模文件系统和高频缓存访问场景下的稳定性得到改善，也为后续更多 AI 训练和推理任务接入统一文件底座提供了保障。

04 未来规划

围绕 AI 云存储基础设施的持续演进，我们后续将重点推进三个方向：

从私有云到混合云的统一管理：随着 AI 训练任务在私有云与公有云之间并行调度，存储底座需要进一步提升跨环境的数据管理能力。后续我们将在现有私有化 Ceph RADOS 架构基础上，继续探索 JuiceFS 对公有云对象存储的接入能力。

通过将跨云数据同步、数据分布和访问路径管理尽可能下沉到存储层，可以减少上层训练任务对不同云环境差异的感知，使应用侧能够获得更加一致的挂载路径和访问体验。这样既有利于提升训练任务在不同算力环境之间的迁移效率，也能降低多云环境下的数据管理复杂度。

推进湖仓一体化，减少跨系统数据搬运：过去，HDFS 离线大数据集群与算法存储集群之间往往需要依赖同步工具进行数据搬运。这种方式不仅增加了链路复杂度，也容易带来数据冗余、同步延迟和管理成本。

后续我们计划进一步引入和完善 JuiceFS Hadoop Java SDK 的使用方式，使算法层的 Spark 任务能够直接读写底层统一存储池。通过这种方式，大数据计算、算法训练和数据归档可以围绕同一套存储底座协同运行，减少不同系统之间的数据复制和重复存储，从而进一步打破数据孤岛，推动存算分离和湖仓一体化落地。

构建多级分层存储，支撑大模型推理加速：随着大模型推理服务规模扩大，单一存储介质已经难以同时满足成本、容量和访问延迟要求。后续我们将从数据层分层和 KVCache 分层两个方向推进能力建设。

在数据层分层方面，当前 JuiceFS 的数据分层能力更多面向公有云对象存储场景。针对私有化 Ceph RADOS 环境，我们计划与社区继续合作，探索在同一套 JuiceFS 文件系统下挂载多个不同性能等级的 Ceph 存储池，例如 NVMe Pool 与 HDD Pool，使不同冷热程度、不同访问频率的数据能够进入更合适的存储层级。

在 KVCache 分层方面，随着大模型推理逐步向 PD（Prefill/Decode）分离的分布式架构演进，传统依赖单机显存承载上下文数据的方式会面临容量和成本瓶颈。后续我们将依托统一存储底座，逐步探索由 HBM（显存）、DRAM（内存）、本地 SSD 到共享存储组成的四级 KVCache 分层能力，为大规模 AI 推理集群提供更灵活的上下文数据管理和访问加速能力。

JuiceFS 社区版 1.4 发布：让海量数据管理更低成本、更高效、更可控

Tue, 07 Jul 2026 07:48:00 +0000

JuiceFS 社区版 1.4 今日正式发布，这是自 2021 年推出开源版本以来的第五个重要版本。该版本为长期支持版本（LTS），我们将继续维护 v1.4 和 v1.3，v1.2 将停止更新。目前，JuiceFS 在 GitHub 上已获得超过 14.2K Stars。根据用户匿名上报数据，社区版数据总量超过 1.4 EB，较 2022 年增长超 700 倍。

随着 JuiceFS 被用于更多大规模数据管理、高并发访问和多用户共享场景，成本控制、元数据效率和资源治理等长期关注的问题进一步凸显，也成为 JuiceFS 1.4 重点优化的方向。历时一年开发，JuiceFS 1.4 版本周期内社区新增 issue 366 个，合并 PR 515 个，共有 59 位贡献者参与其中。感谢每一位参与反馈、贡献和共建的伙伴，帮助 JuiceFS 持续面向复杂生产环境演进。

01 降低存储成本：文件与目录级分层存储

随着文件系统数据规模增长，不同数据在访问频率、性能要求和保存周期上的差异会逐渐扩大。统一使用同一种存储类型，难以同时满足高频访问数据的性能需求和低频访问数据的成本控制需求。对象存储通常按访问特征提供不同 Storage Class，包括标准存储、低频访问存储和归档存储。

JuiceFS 从 v1.1 开始支持通过 --storage-class 设置对象存储类型，但配置粒度主要是文件系统默认值或挂载点。JuiceFS 1.4 将 Storage Class 纳入文件系统语义，支持按文件或目录设置存储层级；目录级配置可被后续新建的文件和子目录继承，便于按项目、数据集或业务目录进行分层管理。

存储层级可以根据使用的对象存储厂商自由配置, 写入新数据时，JuiceFS 会根据文件或父目录的配置，将数据写入对应的对象存储类型；对于已有数据，也可以通过调整元数据配置，并配合对象存储侧的数据迁移能力，将其迁移到新的存储层。这一能力可用于 AI 训练数据集、日志归档、备份数据、历史实验数据和离线分析结果等场景。对于归档型存储，仍需评估取回延迟和取回费用。更多实现细节、使用方式和后续演进可参考：JuiceFS v1.4 分层存储设计解析

02 提升元数据性能：批量删除、克隆与热点读取优化

在海量小文件、大目录和高并发访问场景中，性能瓶颈往往来自元数据操作。JuiceFS 1.4 针对元数据操作中的写入事务开销和热点读取开销，分别优化了批量删除、批量克隆和 Redis 客户端缓存能力。

批量删除与克隆：减少事务开销

过去删除大量文件时，系统需要逐个处理文件，并依次更新目录项、inode、空间统计、回收站和配额等元数据。JuiceFS 1.4 将同一目录下多个非目录文件的删除合并为批量事务，减少逐文件操作带来的重复开销，适用于大目录清理、临时数据回收、训练样本清理和日志目录删除等场景。

批量克隆针对的是目录复制、快照场景。juicefs clone 不会复制底层数据块，而是在元数据层创建新的文件记录，并复用源文件的数据块引用。JuiceFS 1.4 在此基础上进一步减少逐文件克隆产生的元数据事务，将同一目录下多个文件的克隆操作批量处理，适用于 AI 数据集版本管理、实验环境准备和大规模目录快照等场景。

image: 不同元数据下批量效率的提升
caption: 不同元数据后端下批量删除（左图）与批量克隆的吞吐提升

Redis 客户端缓存：降低热点元数据读取开销

在高并发读取中，路径解析、目录项查询和文件属性查询会产生大量重复请求；当 Redis 作为元数据引擎时，这些请求需要在客户端和 Redis 之间往返，可能影响访问延迟并增加 Redis 负载。

JuiceFS 1.4 将热点 inode 属性和目录项缓存在客户端本地，命中缓存时可减少对 Redis 的重复查询；当相关元数据发生变化时，再通过缓存失效机制更新本地状态。需要注意的是，这一能力缓存的是元数据，不是文件内容。

该能力适用于读多写少、热点路径稳定的工作负载，例如 AI 训练数据加载、大规模容器启动和多任务并发读取。更多实现细节可参考：大规模元数据操作优化：批量删除、克隆与 Redis 缓存全解析

03 运维管理增强：用户配额与回收站统计

在分布式存储环境中，存储资源通常由多个用户、项目和业务共享使用。如果缺乏有效的约束机制，单一主体的异常写入或误操作，可能迅速消耗大量空间或 inode，进而影响系统稳定性与成本控制。配额管理正是为共享环境建立可预测资源边界的重要手段。

JuiceFS 社区版 1.4 新增用户和用户组维度的配额能力，使管理员可以按身份查看、配置和限制资源使用情况。它将资源管控从“文件系统 / 目录维度”扩展到“用户 / 用户组维度”，更适合共享集群、AI 训练平台等多用户环境。在多客户端并发场景下，JuiceFS 通过异步统计机制降低元数据访问压力，并让用量统计逐步收敛。详情查看：分布式架构下配额设计：JuiceFS 的实现与典型案例

配额类型	作用范围	主要解决问题	典型使用场景
文件系统总配额	整个文件系统	防止整体资源失控	成本预算控制、容量上限
子目录配额	目录子树	阻断异常写入行为	防止误操作、小文件风暴
用户配额	单个用户	不同业务互不影响	多租户数据管理
用户组配额	项目或部门	成本分摊与团队限制	AI 项目共享环境

JuiceFS 1.4 还增强了回收站空间统计能力。在大规模文件系统中，文件删除后可能仍在回收站保留一段时间，导致“已删除但空间未释放”的情况。1.4 支持通过 summary 工具快速查看回收站相关用量，帮助管理员定位空间占用来源，并据此制定清理、保留或扩容策略。

04 功能拓展：同步、备份与变更追踪

sync 增强，让大规模同步更可靠

在大规模迁移、跨云同步、备份和归档场景中，用户往往需要应对任务中断、数据保护和带宽竞争等问题。JuiceFS 1.4 针对这些场景增强了 juicefs sync，新增断点续传、数据加解密和全局流量控制能力。

断点续传用于降低任务中断后的恢复成本。同步过程中，JuiceFS 会记录任务进度；当任务异常退出或手动中断后，可以基于已保存的状态继续执行，减少重复扫描和重复处理。该能力适用于对象数量大、任务周期长或跨云链路不稳定的迁移与备份场景。

image: checkpoint
caption: checkpoint 的保存、恢复与清理流程

在跨云备份和归档场景中，客户端加密是常见的合规要求。JuiceFS 1.4 支持在 sync 链路中完成加密写入、解密恢复或重新加密，减少对外部加密工具的依赖。该能力适用于异地备份、敏感数据迁移、密钥轮换和合规审计等场景，但需要同时管理好密钥保存和恢复流程。

全局流量控制用于多个同步任务并发时的带宽约束。相比单进程限速，1.4 可以统一管理多个 sync 任务的整体带宽使用，减少同步任务对线上业务和其他网络任务的影响。该能力适用于跨云传输、多任务并发备份、机房迁移和共享出口链路等场景。实现原理请查看：JuiceFS PB 级数据同步优化：断点续传、安全与带宽控制

Changelog：元数据变更可追踪

JuiceFS 社区版 1.4 新增元数据变更日志（Changelog）能力，用于记录文件系统中的元数据变更事件。此前，问题排查主要依赖客户端访问日志（access log），但访问日志只能反映单个挂载点的操作视角；在多个客户端并发访问同一文件系统时，往往难以还原完整的跨客户端操作链路。Changelog 从元数据层记录文件创建、属性修改、删除等变更，为问题定位、操作审计和增量处理提供统一依据。

当出现误删、异常重命名、权限或属性被意外修改等问题时，管理员可以基于 Changelog 查看相关变更记录，减少对单个客户端日志的依赖，缩短排查路径。这也为操作审计提供了更统一的元数据变更来源。

在备份、迁移和恢复场景中，Changelog 可作为增量处理的参考依据。对于大规模文件系统，两次全量备份或迁移任务之间可能发生大量变化；通过记录这段时间内的元数据变更，Changelog 可以为后续增量备份、增量迁移或恢复流程提供输入，减少对全量扫描的依赖。

05 多环境适配增强

JuiceFS 社区版 1.4 也进一步增强了对不同使用环境的适配能力。在 Windows 客户端方面，1.4 优化了跨平台访问的一致性和稳定性，包括用户映射、权限映射和文件访问行为等细节。对于同时使用 Linux 和 Windows 客户端访问同一文件系统的场景，这些优化有助于减少混合操作系统环境下的兼容性问题。

在 Java SDK 和大数据生态方面，1.4 新增 Kerberos 支持，补齐 Hadoop 安全模式下的用户认证能力。此前 1.3 已支持 Ranger，用于文件访问规则和权限控制；Kerberos 侧重认证“用户是谁”，Ranger 侧重控制“用户能访问什么”。二者结合后，可以更好地适配大数据平台中的认证与权限管理体系。

在存储后端方面，1.4 新增基于 SMB/CIFS 协议的存储接入能力，使 JuiceFS 可以更直接地对接已有 NAS 或文件共享系统，扩展在存量基础设施环境中的适用范围。

06 数据规模稳步增长，AI 场景持续拓展

根据用户匿名上报的数据，目前文件系统总数近 70,000 个，数据总量超 1.4 EB，使用规模仍在持续扩大。

image: 文件系统数据
caption: JuiceFS 社区版文件系统数量与数据总量变化

过去一年，AI 应用继续从模型训练扩展到推理服务、Agent 和多云调度等场景，对数据存储提出了更高要求。这些变化也体现在社区用户分享的实践案例中，覆盖大模型、智能驾驶、量化投资、算力平台等多个方向。感谢这些用户分享真实实践，为更多正在建设 AI 数据基础设施的团队提供参考。

新增案例：

AI 训练与大模型
合合信息：构建统一存储，支撑 PB 级 AI 训练
 多模态“卷王”阶跃星辰：打造高效经济的大模型存储平台
 AI 战略下架构演进：小米基于 JuiceFS 的统一存储实践

AIGC
稿定科技：多云架构下的 AI 存储挑战
 3D-AIGC 存储架构演进：光影焕像存储实践

自动驾驶 & 机器人
九识智能：自动驾驶多云亿级文件存储
 海量小文件 + 多云协同：地瓜机器人存储优化之路

推理 & Agent
共绩科技：跨云弹性推理场景下，模型分发如何跟上算力调度
 星辰征途：多云、 Agent 场景下的存储实践

量化金融
Ariste AI 量化投资高性能存储实践

大数据
韩国国民搜索 NAVER：打通 Hadoop 与 Kubernetes 存储实践

❤️ 感谢每一位为项目提供反馈、分享案例、贡献代码、完善文档、答疑解惑！因为每一位的参与，推动了 JuiceFS 的快速成长。

📥 欢迎大家前往下载使用 JuiceFS 1.4：https://github.com/juicedata/juicefs/releases/tag/v1.4.0

JuiceFS PB 级数据同步优化：断点续传、安全与带宽控制

Thu, 18 Jun 2026 07:28:58 +0000

在数据迁移、跨云同步与对象存储备份等场景中，juicefs sync 常用于执行大规模数据同步任务。当数据规模达到 TB 到 PB 级、对象数量达到数百万甚至数十亿级时，单次任务执行周期通常会延长到数小时甚至数天。

在这个过程中，系统运行过程中通常会逐步暴露出以下几类问题：

任务在网络抖动、进程异常退出或节点重启后，难以从一致状态继续执行，往往需要重新扫描或重复处理；
数据备份场景可能存在明文暴露风险并可能面临合规与安全要求；
多个同步任务并发运行时，带宽资源竞争明显，整体传输过程缺乏有效的全局控制手段。

围绕这些场景，JuiceFS 1.4 在 sync 中提供了三项能力增强：断点续传、数据加解密，以及全局流量控制。本文将围绕这三项能力，介绍其适用场景、实现机制和使用方式。

01 断点续传

在早期版本中，用户同步过程中遇到错误或者中断，重新执行任务时，juicefs sync 需要重新扫描源端和目标端，再判断哪些对象已经完成、哪些对象仍需复制。对于上亿级对象或大量大文件场景，仅重新扫描本身就可能带来显著的时间成本和对象存储请求开销。

为了解决这一问题，我们在 JuiceFS 1.4 中为 sync 引入了断点续传机制。启用后，sync 会将任务进度保存到目标端。当任务中断后，用户只需重新执行相同命令，sync 就会自动查找并加载与当前源端、目标端及关键参数匹配的 checkpoint，从上次未完成的位置继续执行，避免从头重新处理。

工作原理

启用断点续传后，sync 会在目标端保存一个 JSON 格式的状态文件，文件名格式如下：

.juicefs-sync-checkpoint.<hash>.json

其中，<hash> 由源端、目标端和关键同步参数计算得到，用于确保当前任务只加载与自身匹配的 checkpoint，避免不同同步任务之间误用状态文件。

断点续传的运行流程如下图所示：

image: Checkpoint 的流程
caption: juicefs sync checkpoint 的保存、恢复与清理流程

sync 启动后，首先在目标端查找与当前任务匹配的 checkpoint。
如果找到匹配项，则从上次保存的状态恢复执行；如果未找到，则按正常流程扫描并开始同步。sync 会并发遍历多个前缀，每个前缀都有独立状态，包括是否已完成遍历、上次遍历到的位置、待同步对象以及同步失败的对象。
从 checkpoint 恢复时，sync 会先从每个前缀中记录的待同步对象和失败对象重新加入任务队列，对于上次尚未遍历完成的前缀，则从记录的位置继续扫描并同步；已经完成遍历的前缀只会继续处理 checkpoint 中尚未完成的对象。
任务运行过程中，sync 会按设定间隔异步保存当前进度，默认每 10 秒保存一次。
任务正常完成后，checkpoint 文件会被自动删除；如果任务中断或失败，则会保留下来，供下次执行相同命令时继续恢复。

image: 集群模式
caption: 集群模式架构示意图

在集群模式下，checkpoint 只有一份，由 Manager 统一维护。Worker 不直接读写目标端的 checkpoint 文件，而是负责从 Manager 拉取任务、执行同步并回传结果。Manager 会将 Worker 回传的完成对象、失败对象、统计信息和 multipart 状态合并到全局 checkpoint 中。

使用方式

# 启用断点续传
juicefs sync --enable-checkpoint SRC DST

# 自定义 checkpoint 保存间隔（默认 10s）
juicefs sync --enable-checkpoint --checkpoint-interval 30s SRC DST

# 忽略已有 checkpoint，强制从头同步
juicefs sync --enable-checkpoint --checkpoint-force-reset SRC DST

02 数据加解密

在跨云备份和归档场景中，客户端加密是常见的合规要求，例如数据主权、静态数据保护、敏感数据迁移等。此前，juicefs sync 没有原生加解密能力，用户如果希望将数据加密后写在目的端，通常需要借助外部工具额外处理。

在 JuiceFS 1.4 中，我们将流式加解密能力集成到 sync 流程中，使用户可以在数据同步的同时完成加密、解密或重新加密，主要支持以下三类场景：

加密写入：将明文数据加密后写入目标端，适用于加密备份和归档场景。
解密恢复：从源端读取加密数据，解密后写入目标端，适用于数据恢复或明文迁移。
重新加密：使用旧密钥解密源端数据，再使用新密钥加密后写入目标端，适用于密钥轮换或加密算法迁移。

工作原理：分块流式加密

为了支持对象存储的 Range GET，并避免一次性加载大文件带来的高内存占用，sync 采用固定 1 MiB 分块的流式加密方案。每个文件会先被拆分为多个明文块，再分别加密写入目标端。

原始文件结构可以理解为：

[chunk 1: 1 MiB][chunk 2: 1 MiB] ... [chunk N: ≤1 MiB]

加密后，每个明文块会对应生成一个加密块。每个加密块由 4 字节头部和密文数据组成，其中 4 字节头部用于记录该块的实际密文长度，即 ct_len：

每个加密块： [4B ct_len][ciphertext + padding]

加密后的文件： [encrypted chunk 1][encrypted chunk 2] ... [encrypted chunk N]

加密块的大小由明文块大小和加密开销共同决定，可以理解为 plainChunkSize + overhead。其中，plainChunkSize 固定为 1 MiB，overhead 取决于所使用的加密算法和密钥类型。

image: 分块流式加密
caption: juicefs sync 分块流式加密的基本结构与读写方式

这种设计的好处是，随机读取时只需要根据偏移定位到对应的加密块，并下载相关块数据，不必读取整个文件。相应地，加密后的对象会包含额外头部、填充和加密元数据，因此目标端对象通常会比原始明文文件更大。

支持的算法

参数值	对称算法	密钥封装	适用场景
aes256gcm-rsa（默认）	AES-256-GCM	RSA	通用场景
chacha20-rsa	ChaCha20-Poly1305	RSA	对 AES 硬件加速支持有限的环境
sm4gcm	SM4-GCM	SM2	需要国密算法的场景

使用方式

下面以 RSA 密钥为例说明加密、解密和重新加密的使用方式。

生成密钥对：

# 生成 RSA 私钥（公钥内嵌其中，JuiceFS 自动提取）
openssl genrsa -out private.pem 2048

# 带密码保护的私钥
openssl genrsa -aes256 -out private.pem 2048

场景一：加密写入目标端

juicefs sync /local/data s3://mybucket/backup 
    --encrypt-rsa-key /path/to/private.pem

场景二：解密读取源端，用于数据恢复或明文迁移。

juicefs sync s3://mybucket/backup /local/data 
    --decrypt-rsa-key /path/to/private.pem

场景三：重新加密，用于密钥轮换或算法迁移。

# 解密旧密钥加密的数据，用新密钥重新加密写入新存储
juicefs sync s3://old-bucket/encrypted s3://new-bucket/re-encrypted 
    --decrypt-rsa-key /path/to/old-private.pem 
    --encrypt-rsa-key /path/to/new-private.pem

如果私钥设置了密码，可以通过环境变量传入。

# 加密场景使用 JFS_ENCRYPT_RSA_PASSPHRASE
export JFS_ENCRYPT_RSA_PASSPHRASE="your-passphrase"
juicefs sync /local/data s3://mybucket/backup --encrypt-rsa-key private.pem

# 解密场景使用 JFS_DECRYPT_RSA_PASSPHRASE
export JFS_DECRYPT_RSA_PASSPHRASE="your-passphrase"
juicefs sync s3://mybucket/backup /local/data --decrypt-rsa-key private.pem

注意

加密后的数据采用 JuiceFS 私有格式存储，需通过 juicefs sync 并提供对应密钥进行解密读取。
请妥善备份加解密所用私钥；私钥一旦丢失，已加密数据将无法解密访问。

03 全局流量控制

在早期版本中，juicefs sync 已经支持通过 --bwlimit 对单个 sync 进程限速。但在多个 sync 进程同时运行时，例如分布式同步中的多个 Worker，或多个独立同步任务共享同一条出口链路，单进程限速并不能约束整体带宽使用量，仍然可能导致出口带宽被打满，影响其他业务流量。

我们在 JuiceFS 1.4 中新增了 --traffic-control-url 参数。用户可以将多个 sync 进程接入同一个外部流量控制服务，由该服务统一分配带宽配额，从而实现跨进程、跨任务的全局限速。

工作原理

全局流量控制采用令牌桶模型。多个 sync 进程在传输数据前，都会向同一个流量控制服务申请字节配额：

image: 全局流量
caption: juicefs sync 全局流量控制实现流程

每个 sync 进程在传输数据前，会向控制服务申请一定数量的字节配额（credit）。控制服务根据当前总带宽使用情况，决定本次授予多少配额，以及配额的有效时间。配额用完后，sync 会继续申请新的配额；如果配额即将过期但尚未用完，未使用的部分会提前归还给控制服务。

控制服务通过 HTTP 接口提供配额申请和归还能力，接口需由用户自行实现或接入现有服务：

POST /traffic-control
Content-Type: application/json

请求：
{"bytes": 1048576}
  bytes > 0: 申请 bytes 字节的额度
  bytes < 0: 归还 |bytes| 字节的未使用额度

响应：
{"granted": 524288, "expired": 1000}
  granted: 本次授予的字节数
  expired: 额度有效期（毫秒）

在同步过程中，sync 会在传输数据前向流量控制服务申请配额。如果当前没有可用配额，传输会阻塞等待，直到获得新的配额。通过这种方式，多个同步任务可以共享同一个全局带宽上限，避免并发任务各自限速但总流量失控的问题。

使用方式

# 先部署流量控制服务（示例：监听 8080 端口，限制总带宽 100 Mbps）
# （服务实现由用户自行决定，juicefs 只负责调用接口）

# 多个 sync 进程接入同一个控制服务
juicefs sync SRC1 DST1 --traffic-control-url http://127.0.0.1:8080/traffic-control &
juicefs sync SRC2 DST2 --traffic-control-url http://127.0.0.1:8080/traffic-control &

--traffic-control-url 可与 --bwlimit 同时使用，两个限制独立生效：--bwlimit 用于限制单个 sync 进程的最大带宽，--traffic-control-url 用于控制多个 sync 进程的全局带宽。

# 单进程不超过 50 Mbps，同时所有进程合计不超过服务端配置的上限
juicefs sync SRC DST 
    --bwlimit 50 
    --traffic-control-url http://controller:8080/traffic-control

04 小结

JuiceFS 1.4 对 sync 的增强包括：断点续传降低了任务中断后的恢复成本，数据加解密提高了数据备份的安全性，全局流量控制则帮助多个同步任务更有序地共享带宽。对于数据迁移、跨云同步、对象存储备份和加密归档等场景，用户可以根据任务规模、网络环境和安全要求，灵活组合使用这些能力。

星辰征途 42 倍小文件性能提升、85% 吞吐增长：多云 AI 场景下的 JuiceFS 存储实践

Fri, 12 Jun 2026 03:17:00 +0000

星辰征途是一家聚焦 AI 搜索与电商场景多模态 AIGC 应用的初创公司，成立两年多，业务主要面向海外市场。公司目前的主要产品包括：Gensmo（gensmo.com）聚焦时尚穿搭，提供虚拟试穿、造型推荐和商品搜索；ZooClaw（zooclaw.ai）面向更广泛的生活与工作场景，提供 AI Agent 服务。

本文将介绍星辰征途业务背后的存储实践，分享我们在统一存储选型、架构设计和性能调优中的思考与经验。目前，JuiceFS 已在生产环境使用一年多，管理文件数超过 1 亿，业务横跨 Oracle、DigitalOcean 和 GCP 三朵云，并成为支撑模型训练、推理、数据处理和在线 Agent 的统一存储层。

01 统一存储需求与建设思路

四类场景，四种 I/O 诉求

到目前为止，星辰征途在存储上主要涉及四类场景，支撑 Gensmo 和 ZooClaw 的业务。

image: 业务类型
caption: 星辰征途业务类型

第一类：模型训练
公司自研模型包括 Gensmo 的 try-on 模型和视频生成模型，用于向 C 端和 B 端客户展示穿搭效果、360° 模型动作或特效场景。模型训练涉及大文件的顺序写入和 checkpoint 保存，对存储系统要求：高容量、高性能顺序 I/O。

第二类：模型推理服务
推理服务对 I/O 的核心需求是高并发顺序读，数据加载到本地缓存以提高命中率。

第三类：数据处理
我们会抓取海外独立电商站的商品、服饰、评价等数据，用于训练模型和业务运营分析。该场景面临大量小文件（单张图片几百 KB），对存储系统的高 IOPS 并发能力是挑战。

工程优化方面，我们使用 Ray Data 并行处理，将海量小文件聚合成 Parquet 大文件（几十 GB 到上百 GB），形成可复用的数据基础层，后续 embedding、检索、推荐等任务重复使用，大幅降低对文件系统的压力，同时兼顾训练和推理场景的需求。

第四类：在线 Agent
在线 Agent 场景与前面主要的离线场景不同，虽然存在大量小文件，但这些文件是在线服务生成，且每个 Agent 的数据只读写自身，不涉及跨 Agent 分布式处理。存储系统需支撑高并发访问和快速响应，但不要求跨 Agent 数据协调。

综合来看，这四类场景对存储系统提出了两类要求：离线训练、推理和数据处理需要高吞吐、高并发和缓存能力；在线 Agent 则更关注低延迟、数据隔离和稳定性。在明确这些业务需求之后，一个自然的问题是：是否需要考虑多云架构？从平台建设之初，我们的答案就是肯定的。

云中立不是理念，是议价能力

云中立的目的不是追求技术本身，而是满足基础设施团队的核心需求：保持算力和资源的可漂移性以及与不同云供应商的议价能力。

对于海外业务，如果计算和存储长期绑定在单一云供应商，随着业务增长或价格变化，灵活调整算力就会受限。尤其在 AI 场景中，GPU 资源价格和供应波动很大：当前便宜的资源，过一段时间可能价格上升或供应不足；业务增长后需要的计算规模，也可能原云供应商无法满足。

因此，我们希望存储层与具体云厂商解耦，使数据保持云中立。这样，训练、推理或在线 Agent 工作负载可以漂移到更符合成本和性能要求的云上，而不需要反复复制或重新配置数据。

POSIX：统一存储体验的基础

另一个在平台建设需要考虑的核心问题就是：如何让研发团队在多云、多对象存储环境下获得一致的操作体验。

对于单一业务场景来说，直接使用对象存储已经足够。但当训练、推理、数据处理和在线 Agent 共用同一套数据体系时，不同对象存储接口带来的开发和运维成本会被不断放大。因此，我们希望在底层存储之上提供统一抽象，而 POSIX 文件系统语义正是最适合承载这种抽象的方式。

通过 JuiceFS，我们将底层对象存储（无论是 GCS、S3 还是 R2）统一映射为 POSIX 文件系统，并挂载为本地路径。这样一来，从本地开发到生产环境，研发团队面对的始终是同一套文件系统接口和访问路径，而无需关心底层数据究竟存储在哪朵云、使用哪种对象存储。

简单来说，理想的云存储体验，是让工程师无需感知底层多云环境的存在，他们看到的永远是一条本地路径的数据。这也是我们后续选择 JuiceFS 的重要原因之一。

02 选型：从 GCS Fuse、S3 Fuse 到 JuiceFS

由于离线和在线场景的需求差异明显，存储选型也呈现出两条不同路径。

离线：调研业界主流方案后，一开始就选了 JuiceFS

在离线场景中，我们面对的是多云环境和高吞吐需求。因此，在系统搭建之前，团队对业界主流方案进行了调研，并根据核心诉求逐一对比：

自建并行文件系统：性能最强，但成本高、绑定硬件且跨云能力有限；
云托管并行文件系统：省心，但锁定单一云厂商，成本仍高；
裸 FUSE：成本低，但 POSIX 语义和性能都不足；
缓存编排层：需要额外叠加底层存储，运维复杂。

方案	云中立	POSIX 语义	高吞吐	分布式缓存	成本 / 运维
自建并行文件系统（如 Lustre）	❌ 绑定硬件	✅	✅✅	部分	成本高，运维重
云托管并行文件系统（如 Filestore）	❌ 锁定单云	✅	✅	✅	成本高，运维较轻
对象存储 + FUSE（S3FS / GCS Fuse）	⚠️ 锁云	❌	❌	❌	成本低，运维轻
缓存编排层（Alluxio / Fluid）	✅	✅	✅	✅	需叠加底层存储，运维重
JuiceFS	✅ 后端任选	✅ 完整	✅	✅ 内建	对象存储成本，CSI 接入

相比之下，JuiceFS 同时满足了我们对云中立、完整 POSIX、内建分布式缓存和对象存储后端 的核心要求，而其他方案基本都会缺少其中一环。因此，在离线场景下，我们没有太多犹豫，一开始就选定了 JuiceFS。

Agent：从 GCS Fuse 踩坑，迁到 JuiceFS

早期业务主要部署在 Google 云上，使用 Google Cloud Storage（GCS）通过 GCS Fuse 挂载到 GKE Pod。实践中发现，这种方案无法满足在线 Agent 对稳定性、性能和云中立的要求。

最主要的问题是 SIGKILL 场景下的数据丢失。GCS Fuse 采用异步 write-back 机制，应用进程的 write 返回成功后，数据可能仍停留在本地缓冲区，并未真正写入 GCS。一旦 Pod 被 OOM kill 或 SIGKILL，已经“看起来写成功”的数据可能永久丢失，在 Agent 场景中会直接表现为会话数据丢失。

第二类问题是小文件性能和 POSIX 语义不足。Agent 工作目录中通常包含多个小文件，并存在频繁追加写入。GCS Fuse 在 open、stat 等操作上延迟较高，同时对 rename、flock、symlink 等 POSIX 语义支持不完整，难以满足在线服务的稳定运行要求。

第三类问题是云锁定和高并发稳定性。GCS Fuse 基本绑定在 GCP 生态内使用，不符合我们对云中立的要求；在高并发 Agent 场景下，稳定性也存在不足。

基于这些问题，我们尝试将在线 Agent 场景迁移到 JuiceFS。

JuiceFS 能解决数据丢失问题，关键在于它的写路径和独立元数据引擎。JuiceFS 将数据和元数据分离：数据 chunk 先上传到对象存储，元数据再原子提交到独立元数据引擎，这之后才算写成功。也就是说，写成功真正意味着数据已经落地，SIGKILL 不会丢失已确认的数据。

更本质地说，GCS Fuse 是以文件系统形式暴露对象存储，而 JuiceFS 是基于对象存储构建真正的文件系统。正是这层独立元数据引擎，加上完整 POSIX 支持、云中立、内建分布式缓存和生态工具链，使 JuiceFS 更符合在线 Agent 对可靠性、一致性和高并发访问的要求。目前，在线 Agent 已在生产环境稳定运行，JuiceFS 也成为公司多场景下的统一存储方案。

03 新架构：JuiceFS 在多云的部署

离线：多云算力漂移，统一元数据 + R2

针对离线场景云中立、算力漂移和高吞吐的需求，我们设计了如下架构：

底层对象存储选择 Cloudflare R2 作为后端。R2 不绑定任何云厂商，且对出站流量免费，非常适合跨云的高吞吐训练场景。相比之下，其他对象存储如 GCS 或 AWS S3 虽然存储成本低，但出站流量费用可能极高，会显著增加离线训练成本。例如，GCS 一个月 1TB 的存储费用约 20 美元，但出站流量可能高达 20–140 美元。

image: 架构
caption: 离线场景存储架构

在 R2 之上，我们部署了 JuiceFS 企业版，实现多云的统一文件系统。无论算力在 Oracle 还是 DigitalOcean，训练、推理或数据处理任务都使用同一套路径，工程师无需感知底层云变化。

算力层包括 Oracle 上的 H100 GPU 和 DigitalOcean 上的 H200 GPU，运行 Slurm 和 KubeRay 的训练与推理统一方案。每个 GPU 节点的本地 NVMe 构建分布式缓存，形成跨节点共享缓存池。数据集首次访问时从 R2 回源，后续基本命中缓存，以吸收跨云访问带来的延迟。

基础设施管理通过 Terraform 完成 IaaC 编排，所有网络、存储、训练任务、Ray 集群和推理引擎均可一键部署。只要云厂商支持 Kubernetes，计算资源和任务都可以无缝拉起，实现跨云快速扩展和资源调整。

在线：低延迟优先与云内独立元数据

在线 Agent 场景以 ZooClaw 为例，核心诉求是为大量 Agent 提供统一存储底座，并实现统一管理、目录隔离和计费，更关注低延迟、小文件写入和高并发访问。如果存储链路跨云，I/O 延迟会明显上升，不适合在线服务。因此，我们尽量让对象存储、元数据服务和业务 Pod 都部署在同一朵云内。

目前这套在线架构部署在 GCP 上，底层对象存储使用本云的 Google Cloud Storage（GCS），元数据层则在 GCP 私有 VPC 内部署独立的三节点 Raft 集群。这样可以让对象存储、元数据服务和业务 Pod 都留在同一云内，降低访问延迟，并提高小文件写密集场景下的 IOPS 表现。

在 Kubernetes 层面，我们通过 JuiceFS CSI 挂载同一个 RWX PVC，不同 bot Pod 使用各自的 subPath 访问独立目录，并通过 token 按环境限制访问范围，实现文件系统级的数据隔离。对于每个 Agent 来说，它看到的是自己的本地工作目录；对于平台侧来说，底层仍然是一套统一的存储系统，便于统一管理和计费。

image: 流程
caption: 在线场景存储架构

如果未来 GCP 的资源或成本不再合适，这套架构仍然具备漂移能力。我们基于 Terraform 和 Kubernetes 进行编排，可以在另一朵云上拉起同样的计算和存储结构，再将对应的元数据与数据同步过去。在线 Agent 业务天然可以按 bot、用户或租户分批切换，因此不需要一次性整体迁移。

回顾离线与在线两个场景，二者的目标不同：离线关注跨云共享、算力漂移和高吞吐，在线 Agent 则关注低延迟、高并发，同时保留按需漂移能力。因此，我们没有为所有场景套用同一种后端方案，而是在 JuiceFS 之上按场景做差异化设计。这样既保留了统一的数据管理和工程使用体验，也让每个场景都能选择更合适的元数据和对象存储部署方式。

04 调优实践：分布式缓存 / writeback / S3 Gateway

在统一架构落地后，我们仍需根据不同业务场景进行针对性的性能优化和访问策略调整。

同一个缓存，两套优化策略

分布式缓存是 JuiceFS 中非常关键的能力，直接影响 IOPS、吞吐和访问延迟。在离线和在线两个场景中，缓存的目标与实现方式存在显著差异。

在离线场景中，核心目标是支撑大规模训练和数据处理的高吞吐，同时保障跨云共享和算力漂移。为此，我们尽量将 R2 中的数据缓存到本地。训练、推理和数据处理运行在配备 NVMe SSD 的 H100、H200 GPU 节点上，单节点约 50T，十几台节点可形成几百 T 的分布式缓存空间。首次访问数据需要从 R2 回源，速度相对较慢，但首读完成后，训练、数据处理和推理任务基本能命中缓存，I/O 性能接近本地访问。在离线场景中，因写入的是大规模 checkpoint 或模型权重文件（单个文件可达数百 GB 至数 TB），数据安全要求极高，因此通常不启用 writeback，以确保写入绝对安全。

在线 Agent 场景的核心目标是低延迟、高并发的小文件访问，同时保证每个 Agent 的数据隔离。缓存主要用于提升小文件写入和访问性能，每个 Agent Pod 挂载同一个支持 RWX 的 PVC，并通过 subPath 隔离目录，缓存失效时间设置为 3,600 秒，覆盖高频访问场景。由于每个 Agent 通常只访问自己的目录，这种缓存策略不要求严格跨 Agent 数据一致性，数据仅在必要的离线分析或运营排查中与对象存储保持最终一致。

在线场景中，为了进一步提升小文件写入和高并发性能，缓存策略可以配合 writeback 使用。Writeback 的核心目标是以可控的数据安全风险换取更高的写入吞吐。这意味着，在单个节点上运行的多个 Agent，如果某个 Agent 在写入过程中出现异常，仅会影响该 Agent 的单次产物，如 PPT、图片或临时文档，这些数据可以重新生成。借助 writeback，在线 Agent 在高并发、小文件写入时能够获得明显的性能提升，同时仍保持系统整体的稳定性和数据隔离。

一份数据，多种接口

S3 Gateway 在我们的架构中承担数据分发层角色，将 JuiceFS 中的数据以标准 S3 接口对外提供服务。在 Agent 场景下，无论是配置文件，还是生成的 PPT、图片或视频，数据最终都存放在同一套 JuiceFS 文件系统中。然而，这些数据往往需要以 URL 的形式分享给外部用户，POSIX 挂载方式显然不适用。

因此，我们通过 JuiceFS S3 Gateway 将同一份数据直接暴露为标准 S3 接口。内部服务继续使用 POSIX 接口，而外部系统通过 S3 或 HTTP 协议访问同一份数据，无需额外复制。为了提升安全性和访问性能，我们在 S3 Gateway 前增加了 Cloudflare Worker 和 CDN：用户请求先通过 Worker 完成路径校验和访问控制，再转发到 Gateway 获取数据，同时通过 CDN 边缘缓存和 ETag 校验减少回源请求。

这种设计带来了两个核心收益：第一，多层访问隔离保证数据安全，包括 JuiceFS 目录隔离、S3 Gateway 权限控制以及 Worker 层的代码级校验；第二，通过 CDN 缓存减少跨区域访问的延迟，提高大文件（如视频或图片）的访问性能。对于全球用户而言，这意味着即使数据存储在 GCP 美东区域，用户也可以从最近的边缘节点高效访问内容。

从整体架构来看，内部训练、推理和 Agent 服务使用 POSIX 文件系统，而对外分发则通过 S3 Gateway 提供标准接口。同一份数据支持多种访问方式，无需额外复制。

05 性能调优结果

离线场景：顺序写吞吐提升 ~4×，缓存命中读 7–8 GB/s

在离线场景下，我们对顺序读写进行了性能基准测试。图表中展示了优化前后的对比：

顺序写：单进程写入模型产出或 checkpoint 时约 700 MB/s，利用多进程、多节点并行写入可超过 1 GB/s，足以支撑大规模训练场景下的顺序写入需求。
顺序读：数据处理阶段，将小文件聚合成大文件并加载到分布式缓存后，顺序读命中缓存可达到 6.7–7.8 GB/s，接近本地 NVMe 性能。模型推理任务也可直接从本地缓存加载 checkpoint，无需跨节点拷贝。

测试项（JuiceFS on R2，离线）	无优化基线	优化后（分布式缓存 + 调参）
顺序写：大块	~231 MB/s	~714 MB/s
顺序写：大批量 20–50 GB	~256–265 MB/s	840 MB/s ~ 1.1 GB/s
顺序读：分布式缓存命中	-	6.7 ~ 7.8 GB/s
顺序读：冷读回源 R2	-	~427 MB/s

分布式缓存还带来了工程效率上的收益。训练、推理和数据处理可以共享同一套文件路径，减少了 checkpoint 在不同节点或服务之间复制的需求。新产出的模型权重可直接被推理服务加载，降低了数据流转成本，也提升了训练到部署的衔接效率。

在线场景：小文件写入性能提升 ~42×，大文件吞吐提升 ~85%

最初方案中，元数据服务部署在 OCI，后端对象存储使用 R2，在线业务在 GCP 访问时需要跨公网，请求链路中的元数据 RTT（Round-Trip Time）约为 12.7 ms，小文件吞吐只有约 24 files/s；同时，R2 偶发 30 s PUT 超时，甚至会影响 bot 的稳定性。

优化措施包括：一是开启 writeback 并调整缓存 TTL，大文件写入吞吐提升约 85%；二是将元数据和对象存储迁移到 GCP 内网，元数据在私有 VPC 三节点 Raft 集群，对象存储改为 GCS 并结合 NVMe 缓存。优化后，元数据 RTT 降至约 5.8 ms，小文件吞吐提升至约 1000 files/s，整体性能约提升 42 倍。

06 小结

经过一年多实践，JuiceFS 已成为星辰征途基础设施中的核心存储层。它不仅支撑超过 1 亿文件、横跨三朵云和多类业务场景的稳定运行，更重要的是统一了训练、推理、数据处理和在线 Agent 的存储体系。

对于一家海外初创公司而言，灵活且运维简便的基础设施至关重要，这有助于团队将精力集中在业务创新上。统一存储体系为上层业务和研发提供一致接口，而底层资源可以根据场景灵活调度：离线场景围绕算力成本实现动态漂移，在线场景优先保证低延迟和高并发，同时保留按需迁移能力。这样的设计既保持了上层体验的一致性，又使算力成本可议价、资源可漂移，为未来扩展到更多云和区域奠定了基础。

JuiceFS 1.4｜大规模元数据操作优化：批量删除、克隆与 Redis 缓存全解析

Wed, 03 Jun 2026 09:04:50 +0000

在 AI 训练、数据集管理等大规模文件访问场景中，随着文件数量和访问并发增加，元数据层往往更早成为性能瓶颈。无论是删除百万级小文件、克隆大规模数据集，还是高并发目录遍历，元数据引擎的响应能力都会直接影响上层业务效率。

JuiceFS 社区版 1.4 在元数据引擎层面引入了三项优化：批量删除（Batch Unlink）、批量克隆（Batch Clone）和 Redis 客户端缓存（Client-Side Caching），分别面向大规模删除、元数据克隆和热点元数据读取场景，减少事务提交、网络交互和重复查询开销。在 100,000 个文件的 flat 目录测试中，批量删除最高提升 93 倍，批量克隆最高提升 24 倍。本文将从问题背景、设计思路和性能收益三个方面介绍这些优化。

01 删除：从逐个回收到批量事务

在 JuiceFS 的元数据与数据分离架构下，删除文件不仅移除目录项，还需要更新 inode 引用计数、回收空间和 inode、处理回收站、调整配额等多项元数据操作，这些操作通常必须在同一个事务中完成。

当目录中包含数十万甚至数百万个文件时，早期 rm -rf 的逐文件删除方式会迅速暴露性能瓶颈：每个 unlink 请求都需要经过 FUSE 协议在内核态与用户态之间交互，并触发一次独立的元数据事务提交。文件数量越多，系统调用、上下文切换、网络往返和事务提交开销累积越明显。

JuiceFS 此前已引入 juicefs rmr 命令来缓解这一问题。rmr 绕过 FUSE 协议层，通过控制文件直接将删除请求投递到客户端内部，同时支持多线程并发删除（默认 50 线程），相比 rm -rf 有显著提升。但 rmr 的每次删除仍然是独立的事务——十万个文件就需要十万次事务。本次的批量删除优化，正是要在 rmr 的基础上，将同一目录下的多次独立事务合并为一次批量事务，进一步消除网络开销。

核心优化思路

解决这个问题的关键在于将"多次小事务"合并为"少量大事务"。JuiceFS 在元数据引擎层面新增了 BatchUnlink 接口，它允许客户端将同一目录下的多个非目录文件在一次调用中批量删除。

在递归清空目录时，JuiceFS 会同时从两个层面减少删除开销：一方面，不同子目录之间可以并发处理，充分利用多线程删除能力；另一方面，在同一目录内部，会将普通文件和符号链接等非目录条目按批次提交给 BatchUnlink 处理。这样，原本需要逐个发起的 unlink 操作，就可以在元数据层面合并为更少的批量事务。

需要注意的是，BatchUnlink 并不直接批量删除目录。目录删除遵循递归顺序：先清空子目录中的内容，再删除子目录本身。因此， BatchUnlink 的作用范围限定在同一目录下的普通文件和符号链接上。这个限制既保证了递归删除语义的正确性，也避免了批量操作影响目录树结构的一致性。

image: JuiceFS 删除操作优化路径
caption: JuiceFS 删除操作优化路径

各引擎的实现策略

在 BatchUnlink 的实现中，JuiceFS 针对不同元数据后端采用了相应的批量化策略，以减少事务提交次数和网络往返。

在 SQL 后端（MySQL、PostgreSQL 等），原来的逐条删除意味着每次都要执行独立的 INSERT、DELETE、UPDATE 语句序列。引入 BatchUnlink 后，系统会先通过一次批量查询获取所有待删除条目的 edge 记录，再通过一次带行锁的批量查询获取所有涉及的 inode 属性。随后，在同一个事务内批量执行 edge 删除、inode 状态更新（nlink 递减或标记为待清理）、delfile 条目插入等操作。原来 N 个文件的删除需要 N 次独立事务，现在只需要一次。

在 Redis 后端，优化策略则利用了 Redis 的 Pipeline 和事务机制。原来的逐条删除每次都需要独立的命令交互，而 BatchUnlink 将多个文件的 HDEL（删除 dentry）、ZADD（加入待清理队列）、SET（更新 inode 属性）、INCRBY（更新统计计数）等命令全部放入一个 Pipeline 中，在单次 MULTI/EXEC 事务中原子执行。为了控制单次事务中的命令总量，避免阻塞 Redis 单线程过久，批次大小固定为 250 个条目。

在 TiKV 后端，BatchUnlink 同样将多次删除操作合并到单次事务中，利用 TiKV 的批量写入能力减少网络往返和事务开销。对于分布式 KV 后端而言，这类批量化操作可以更充分地发挥后端的并发写入能力。

以下是在 100,000 个文件 flat 目录下，使用 juicefs rmr --threads 16 的测试结果，可以看到批量删除在不同元数据后端上均带来了明显提升，其中 TiKV 和 Redis 的收益更为显著。

image: 批量删除的吞吐提升
caption: 不同元数据后端下批量删除的吞吐提升

02 克隆：从逐条复制到批量引用

JuiceFS clone 常用于快速生成文件或目录副本，例如训练数据集版本管理、实验数据快照和大规模目录复制等场景。其高效之处在于创建副本时不会立即拷贝底层数据块，而是在元数据层创建新的文件记录，并复用源文件已有的数据块引用；后续只有副本发生写入时，系统才会为被修改的部分分配新的数据块。因此，clone 可以减少完整复制带来的时间和存储开销。

对于克隆大目录，与删除类似，逐文件处理会导致大量短事务和网络交互，由此产生大量元数据操作。批量克隆的核心是将同一目录下多个文件的克隆操作合并为一次批量事务。递归克隆目录时，系统会流式分批读取目录条目，将每批中的所有非目录条目收集后一次性批量克隆。

实现上的一个关键优化是"inode 预分配"：在进入事务之前，系统先通过 nextInode 为所有待克隆条目预先分配好目标 inode。这避免了在事务内部频繁申请 inode 导致锁竞争。进入事务后，系统批量查询所有源文件属性（带行锁），构建好所有目标 node、edge、chunk、symlink、xattr 的插入数据，然后一次性批量插入。

批量克隆在不同元数据后端中的实现仍然会利用各自的批量写入能力，这一节不再展开写入细节。不同后端的性能提升幅度不仅取决于事务模型和网络交互成本，也与批量写入 node、edge、chunk 引用等元数据记录的效率有关。

具体测试结果如下表所示，在包含十万个文件的 flat 目录上，我们使用 juicefs clone 对比了优化前后的克隆性能，MySQL 后端提升最为显著，约 24 倍；Redis 后端约 5 倍，TiKV 后端约 2 倍。

image: 批量克隆的吞吐提升
caption: 不同元数据后端下批量克隆的吞吐提升

03 Redis 客户端缓存：将热点元数据缓存在本地

在高并发元数据访问场景，如 AI 训练数据集加载、大规模容器启动等，客户端与 Redis 元数据引擎之间的网络往返是主要的性能瓶颈。

以内核 VFS 的路径解析为例：当进程执行 open("/mnt/jfs/dataset/images/cat.jpg") 时，VFS 层需要逐级解析每个路径分量——先 lookup dataset，再 lookup images，最后 lookup cat.jpg。

image: 内核 VFS 路径解析
caption: 内核 VFS 路径解析

如果 images 目录下包含数十万个文件，而训练任务需要随机访问其中的文件，那么每次 lookup 都需要向 Redis 发起一次 GET 请求。在高并发场景下，这会造成大量的网络往返和 Redis CPU 消耗。即使 Redis 本身单次查询只需几十微秒，但加上网络延迟后，每次 lookup 可能就需要几百微秒甚至毫秒级。当数千个训练进程同时进行文件访问时，这个开销会被急剧放大。

实现原理：基于 Redis 6.0 客户端缓存机制

Redis 6.0 引入了客户端缓存（Client-Side Caching）功能，允许客户端在本地缓存热点键值，并由 Redis 服务器在键被修改时主动推送失效通知。JuiceFS 基于这一能力，将两类核心元数据缓存在客户端内存中：

第一类是 inode 属性缓存。以 inode 号为键，缓存该文件的完整属性数据（类型、大小、权限、时间戳等）。这类缓存通过 Redis 客户端驱动层的钩子机制透明实现：查询时自动先检查本地缓存，命中则直接返回，完全跳过网络请求；修改时则自动清除对应缓存，业务逻辑无需感知。

第二类是 目录条目缓存（entry cache）。以"父目录 inode + 路径分隔符 + 文件名"为键，缓存目录 lookup 的结果。与 inode 属性缓存不同，这类缓存的检查逻辑内嵌于目录查找路径本身，而非通过驱动层透明拦截。当某个目录的条目失效时，通过前缀匹配清除该目录下的所有相关缓存。这样一来，路径解析或重复访问同一目录下的热点条目时可以直接命中本地缓存。

引入客户端缓存后，核心挑战在于多客户端挂载场景下的元数据一致性维护。当多个客户端共享同一个 JuiceFS 文件系统时，某一客户端对文件或目录执行创建、删除、重命名或属性更新等操作后，其他客户端本地缓存中的相关 inode 属性或目录项结果可能随之失效。如果缺少有效的缓存失效机制，后续访问就可能命中过期元数据，导致客户端观察到的目录项或文件属性与后端元数据状态不一致。

为此，JuiceFS 基于 Redis 的客户端缓存机制，引入 Tracking 与广播失效（BCAST）模式。客户端连接 Redis 后，会声明需要跟踪的元数据 key 前缀；当这些 key 被修改时，Redis 会向相关客户端发送失效通知。客户端收到通知后，会根据 key 类型清理对应的 inode 属性缓存或 entry cache，使后续访问重新从元数据引擎获取最新结果。

此外，客户端初始化时，JuiceFS 会对挂载点根目录下的元数据进行预热。由于这部分文件通常访问频率最高，实测表明该优化能够有效提升整体访问性能。

通过上述机制，热点元数据可以在客户端本地复用；一旦相关元数据发生变化，对应缓存会被及时淘汰，从而降低过期元数据被继续使用的风险。

适用场景与注意事项

Redis 客户端缓存最适合读多写少、热点元数据重复访问明显的场景，例如 AI 训练数据集加载——训练过程中数据集通常只读不写，任务会反复访问相同目录和文件，因此 inode 属性缓存和 entry cache 更容易命中，进而减少重复 lookup 和远端元数据查询。

如果客户端与 Redis 元数据引擎之间存在较高网络延迟，例如跨可用区部署，本地缓存的收益会更加明显。

使用该能力时，需要确保 Redis 版本为 6.0 及以上。默认缓存过期时间为 1 分钟，用于在网络闪断、连接异常等情况下为失效通知机制提供兜底，避免过期元数据长期保留在客户端本地缓存中。对于强一致性行更高的场景，可以根据实际需求缩短缓存过期时间，或关闭客户端缓存，以降低读取过期元数据的风险。

04 小结

这三项优化分别覆盖了元数据的写、复制和读三条路径：

批量删除将同一目录下的多次独立 unlink 合并为一次批量事务
批量克隆将同一目录下的多次独立 clone 合并为一次批量事务
Redis 客户端缓存在客户端本地缓存热点元数据，将读操作延迟从网络级降到内存级，通过广播失效保证多客户端一致性。

其中 BatchUnlink 和 BatchClone 都是内部接口，用户无需直接调用，只需选择正确的操作方式即可命中优化（例如，删除大目录用 juicefs rmr，复制目录用 juicefs clone）。

需要注意的是，批量操作的核心是把同一目录下的普通文件合并为一次批量事务；子目录则通过并发 goroutine 递归处理。因此，越是大型的目录，优化的收益越明显。

以上优化均已在 JuiceFS 社区版 1.4 中可用，升级客户端版本即可获得性能收益。

共绩科技：跨云弹性推理场景下，模型分发如何跟上算力调度

Wed, 27 May 2026 03:43:00 +0000

共绩科技 2023 年成立于清华，面向 AIGC 企业和科研机构提供算力平台与 MaaS 服务，致力于缓解弹性算力需求与供给之间的错配。平台通过聚合 IDC 闲置资源和边缘资源，以容器化服务为主，为 AI 推理、视频渲染、数据处理和数据合成等波动性场景提供可快速调度的算力资源。

在跨云弹性推理场景中，计算任务可以调度到不同地域、云环境和集群，但模型文件和业务数据体积较大，难以像计算资源一样快速迁移。尤其是在线推理场景，模型仓库以读为主且访问频繁，存储访问能力会直接影响服务启动、弹性扩容和请求延迟。

为此，共绩科技基于 JuiceFS 封装了“对象存储加速”方案，将用户已有对象存储接入弹性推理集群，并通过统一命名空间、元数据导入、FUSE 挂载、分布式缓存和数据预热，提升模型仓库在跨云、跨集群环境中的访问效率。以一家头部文生图模型社区实践为例，该方案支撑了几十 TB 级模型仓库、checkpoint 与 LoRA 动态加载，以及高峰期数百卡弹性资源扩容，并将弹性集群的额外延迟控制在客户验收范围内。

01 弹性需求广泛存在，供给却难以匹配

随着 AI 应用快速发展，算力需求持续增长，但不同场景的资源使用特征并不相同。相比训练任务相对稳定的资源需求，AI 推理、数据处理和数据合成等场景通常具有更强的波动性：办公类应用可能在白天流量更高，娱乐类应用可能在傍晚或周末迎来高峰；项目制的数据处理任务则可能在短时间内集中消耗大量算力，任务结束后又进入空窗期。对于中小团队或探索型业务而言，弹性算力还能帮助其更清晰地评估单次请求成本与商业收益之间的关系。

但在供给侧，算力基础设施建设属于重资产投入。资源方通常并非不具备弹性服务能力，而是更倾向于通过长期整租回收成本、降低风险。这使得市场上低价、稳定、弹性三者难以同时满足：整租资源价格较低且供应稳定，但缺乏弹性；Spot 资源价格低且具备弹性，但供应不确定；On-demand 资源弹性和稳定性较好，但成本较高。在中国市场，这种矛盾进一步表现为交易主要集中在整租订单，弹性资源供给占比较低。

image: 弹性算力供给的三角权衡
caption: 弹性算力供给的三角权衡

共绩科技希望解决的，正是弹性算力需求与供给之间的错配问题。通过聚合 IDC 闲置资源及更分散的边缘资源，平台以容器化服务为主，为 AI 推理、视频渲染、数据处理和数据合成等场景提供可快速调度的算力资源，在较低资源成本基础上，帮助用户在业务高峰时快速拉起任务、调度至不同集群并承接弹性需求。资源方也可以在整租之外，提高闲置资源的利用率和变现效率。

02 算力可以调度，存储如何跟上？

随着弹性算力平台的发展，计算资源的调度相对容易实现。容器镜像可以通过镜像仓库和分发网络同步到不同集群，计算任务可以由调度系统在不同资源池中拉起，业务流量也可以通过统一接入层和流量治理能力进行分发。

但模型和数据文件通常体积较大，跨云、跨集群迁移成本高、耗时长，难以匹配计算资源秒级拉起和释放的节奏。因此，在跨云弹性推理架构中，真正限制系统弹性的往往不是算力调度，而是数据和模型的分发效率。

不同业务场景对存储的要求并不相同。第一类是模型训练、开发和调试场景。这类场景通常涉及复杂的读写需求，包括代码仓库、模型文件、实验结果和中间状态等。同时，开发调试对环境稳定性要求很高，用户无法接受主机频繁切换导致状态丢失。因此，在这类场景中，平台通常会为用户提供长期稳定的计算资源和运行环境，相关存储需求也可以通过集群内已有的稳定存储体系来承载。

第二类是数据处理场景。这类业务又可以分为两种情况：如果单次数据处理的业务价值较高，能够覆盖跨云网络传输成本，就可以直接构建数据处理流水线，从 S3 或其他对象存储持续拉取数据，在计算集群内处理后再流式写回。此时系统不必依赖大规模本地存储。如果数据规模更大，或者单次处理的经济价值较低，本地存储更多也只是一次性缓存，数据在处理流程中流过即可，并不需要长期沉淀在计算集群内。

真正更具挑战的是在线推理场景。在线推理业务不能接受服务中断，但弹性算力平台所使用的资源可能来自闲置资源池，存在被撤出的可能。一旦某个机房或集群资源不可用，平台必须能够及时将任务迁移到其他供应商或其他集群。这意味着不仅计算任务要能够迁移，模型文件和相关存储访问能力也必须能够同步迁移。

在线推理虽然对服务连续性和跨集群迁移能力要求更高，但它的存储访问模式也相对更明确。与训练、开发和调试场景相比，推理业务通常以读为主，核心需求集中在高效加载模型、读取模型权重和访问模型仓库上。对于大型模型和在线应用而言，模型加载速度直接影响服务启动时间、弹性扩容效率和请求响应稳定性。因此，推理场景并不适合简单沿用传统读写混合型存储架构，而更适合围绕模型分发、只读访问和缓存加速进行专门优化。

此外，弹性算力平台通常并不承载用户完整的业务系统。用户的主云账号、业务数据库、模型管理系统，甚至部分固定算力资源，往往已经存在于其他云或自有环境中。平台要接入用户业务，就必须与其现有模型仓库和模型管理流程兼容，不能要求用户重新迁移整套系统。

因此，要支撑跨云弹性推理，需要的不只是计算调度能力，而是一套面向模型推理场景的跨云高性能存储与模型分发方案：既要支持大模型仓库的托管和高性能读取，又要适配用户已有的模型管理体系，并能够在资源跨云、跨集群迁移时提供稳定的数据访问能力。

03 Why JuiceFS：跨云统一访问、强一致元数据与高性能缓存

面对跨云弹性推理场景，存储系统需要同时满足几个条件：

能够在不同云和不同集群之间提供统一访问入口，支持共享读写和统一元数据管理；
能够兼容用户已有的对象存储和模型仓库，避免用户迁移现有数据；
同时还要具备较低的运维复杂度和较好的读性能。

在存储方案选型过程中，我们曾评估过 Ceph。Ceph 技术成熟，适合在单一数据中心或相对稳定的资源域内构建统一存储。但在跨云弹性推理场景下，Ceph 对网络稳定性和运维能力要求较高，整体接入成本相对更高，因此没有作为最终方案。

Alluxio 也曾进入评估范围。但在多云环境下，多个集群需要并发访问同一份底层对象存储数据，且业务并非完全只读，也存在少量写入。该场景对数据强一致性要求较高，因此 Alluxio 最终未作为生产方案。

最终选择 JuiceFS，主要是因为它以对象存储作为数据底座，并通过独立元数据服务提供统一命名空间和一致的文件系统视图，能够让多个集群以文件系统方式访问同一份模型数据。这种架构既适合跨云、跨集群的模型分发和共享读取，也能够较好兼容用户已有的对象存储和模型仓库，降低数据迁移和业务接入成本。

进一步采用 JuiceFS 企业版，则主要看重其分布式缓存能力和元数据托管能力。在这个场景中，JuiceFS 的价值并不只是提供一个文件系统接口，而是把对象存储、统一命名空间、元数据管理和缓存加速组合成一套更适合跨云弹性推理的存储访问层。

image: JuiceFS 企业版架构图
caption: JuiceFS 企业版架构图

04 实践方案：基于JuiceFS 的对象存储加速

基于 JuiceFS，平台封装了“对象存储加速”产品，用于将用户已有的对象存储接入弹性推理集群，并以高性能文件系统的形式提供给业务使用。整体流程如下。

首先是创建文件系统。用户提供对象存储的访问凭证，例如 S3 兼容存储的 AK/SK。凭证权限可以根据业务需求配置为只读或读写，平台基于该对象存储创建对应的 JuiceFS 文件系统。

其次是导入元数据。平台通过 JuiceFS import 能力扫描对象存储中的文件元数据，并将其导入 JuiceFS 元数据服务。这样，用户原本存放在对象存储中的模型文件，就可以在 JuiceFS 中以文件系统目录的形式被访问。

第三是建立缓存组。在可能承载任务的各个集群内，平台会建立 JuiceFS Cache Group，形成分布式缓存组。任务运行前，平台可以先对模型文件进行数据预热，将热点数据提前缓存到目标集群，减少推理服务启动时从远端对象存储拉取数据的耗时。

第四是挂载到业务 Pod。用户业务运行时，平台通过 FUSE 客户端将 JuiceFS 文件系统挂载到业务 Pod 中。对于应用而言，模型文件表现为本地文件系统路径，因此通常不需要改造原有的模型读取逻辑。

第五是启用节点缓存。除了集群级 Cache Group，FUSE 客户端所在节点也可以提供本地缓存，用于提升重复读取和模型加载性能，进一步降低对远端对象存储的直接访问。

这个“对象存储加速”产品，本质上是将 JuiceFS 的元数据导入、分布式缓存、数据预热和 FUSE 挂载流程产品化，使用户已有的对象存储能够以更接近本地文件系统的方式服务于跨云推理任务。

此外，JuiceFS 的 Cache Group 与文件系统访问入口相对独立。这个特性一方面会增加平台侧的管理复杂度，因为平台需要同时管理文件系统、缓存组、挂载入口和任务调度之间的关系；另一方面，也为后续按集群、按用户或按业务场景进行缓存隔离、独立调度和精细化管理提供了基础。

05 业务实战：头部文生图模型社区

场景、挑战与验收标准

在这套对象存储加速方案中，一个比较典型的实践案例来自国内头部文生图模型社区，其托管了几十 TB 规模的模型数据，既包括体积较大的 checkpoint 基座模型，也包括数量更多、体积相对较小的 LoRA 模型。在实际推理过程中，业务通常需要先加载 checkpoint，再加载一个或多个 LoRA，完成组合推理。

该公司自身已经拥有较大规模的算力资源，规模达到数千卡级别。但由于其面向创意设计等生产场景，业务负载具有明显波动性，整体平均利用率不到 50%。在工作日的上午和下午高峰时段，负载甚至可能达到常规承载水位的 140%，导致服务体验下降。因此，客户需要一种高度弹性的算力供给方式。

共绩为其提供的是一种高弹性的资源模式：仅在工作日高峰时段，即上午 10:00–12:00 和下午 14:00–18:00，提供数百卡规模的算力支持，其余时间资源规模降为 0。

image: 扩缩容效果
caption: 闲时调度在业务峰谷场景中的扩缩容效果

这意味着平台需要在分钟级时间窗口内完成数百卡资源的快速扩容，而在非高峰时段完全不占用资源。对客户而言，这种模式可以在峰值时段获得大量算力支持，同时避免为低谷资源付费；对平台而言，也可以更高效地利用闲置算力资源，具备较好的商业价值。

但这一场景的技术挑战也非常突出。首先，这类几十 TB 级模型仓库无法简单复制到每一个弹性集群。其次，推理服务并不是在启动时一次性加载全部模型，而是会随着用户请求持续发生模型读取和切换，访问频率较高。这意味着对象存储加速方案不仅要支持大规模模型仓库访问，还要在持续动态加载场景下保持稳定的读取性能。

与此同时，该公司对性能要求非常严格。在验收过程中，会将部分生产流量引入弹性集群进行测试，并要求弹性集群与其自有集群相比，推理耗时的中位数和平均值差异都必须控制在 2 秒以内。考虑到单次推理耗时本身在几十秒量级，这一要求意味着对象存储加速方案几乎不能引入额外延迟。在最初几轮测试中，弹性集群的推理耗时中位数和平均值均比客户自有集群高出约 10 秒，未能通过验收。

性能优化：降低弹性集群的额外延迟

优化首先从中位数入手。中位数偏高意味着有相当比例的请求都存在性能损耗，而不是少量偶发请求造成的长尾问题。通过 JuiceFS 监控发现，集群缓存命中率没有达到预期。在当前架构下，一旦缓存未命中，请求就需要跨公网访问客户在阿里云上的对象存储进行回源，这会显著拉高模型加载耗时，并进一步影响推理请求延迟。

针对这一问题，平台利用 JuiceFS Cache Group 的隔离能力，为该客户分配专属缓存节点，并预留充足缓存空间，对核心模型数据进行充分预热。完成预热后，核心模型访问路径基本实现 100% 缓存命中，有效避免了跨公网回源带来的性能损失。

第二个影响中位数的因素是元数据访问延迟。由于平台采用跨集群统一架构，元数据服务需要通过公网访问，例如使用 JuiceFS 云服务或部署在其他云主机上，因此元数据访问延迟会影响整体模型读取性能。

针对这一问题，平台采取了两项措施：一是开启 JuiceFS 的 open cache，将元数据尽可能缓存到本地内存中。由于该场景以只读访问为主，适合通过缓存降低元数据访问开销。二是优化集群网络限流策略。尽管平台无法直接控制边缘机房的网络设备，但可以通过节点级限流，避免单个节点占满带宽，从而提升整体网络稳定性。完成这些优化后，集群整体性能明显提升，中位数逐步达到客户要求。

当中位数达标后，平均值仍然存在偏差。这说明系统中仍存在长尾请求，即少量请求耗时显著高于正常水平，并拉高了整体平均值。进一步分析发现，这主要与节点本地缓存，也就是 FUSE 缓存配额有关。由于缓存容量较小，相比客户自有集群，弹性集群更容易发生缓存换出，导致部分请求需要重新加载模型数据，从而拉高平均推理耗时。针对这一问题，平台在生产环境中扩大了 FUSE 本地缓存配额，降低缓存换出频率，改善长尾表现，最终使平均值指标也满足验收要求。经过上述优化，系统顺利通过验收，并稳定运行。

多租户缓存治理

场景验证通过后，这套能力也进一步进入多租户运行阶段。随着不同租户按时间片复用同一批弹性节点，新的问题开始暴露出来，即节点缓存竞争问题。

在弹性资源模型下，FUSE 客户端退出时不会主动清理节点缓存。这个设计在单租户场景下是合理的，因为历史缓存可以被后续任务复用，从而提高命中率。但在多租户场景下，前一个租户的数据可能长期占用节点缓存空间，使后续租户无法获得足够缓存资源，最终不得不回源访问对象存储，导致性能明显下降。

为了解决这一问题，共绩在每个节点上部署了独立的守护进程，由该进程在业务 FUSE 客户端启动前执行全局缓存垃圾回收。具体策略参考 JuiceFS FUSE 客户端的实现，采用 2-random 策略，在回收效率和性能之间取得平衡。同时，各节点之间通过 Kubernetes 分布式锁进行协调，只有抢到锁的客户端才执行 GC，避免多个客户端同时回收缓存，从而造成额外的网络和 I/O 压力。

通过这一机制，我们有效缓解了多租户场景下缓存资源被历史任务占用的问题，使不同租户在共享弹性资源时，仍然能够获得相对稳定的缓存性能。

06 结语

弹性算力要稳定承接生产流量，不能只依赖计算调度，还需要模型数据和热点数据在跨云、跨集群环境中保持稳定访问。

基于 JuiceFS，共绩科技将对象存储、统一命名空间、元数据管理、分布式缓存和 FUSE 挂载能力组合起来，形成了一套面向弹性推理场景的对象存储加速方案。它并不是简单地把对象存储挂载成文件系统，而是围绕模型推理的访问模式，提供可预热、可缓存、可隔离、可治理的数据访问层。

以上是共绩科技在弹性算力与跨云存储加速方向上的阶段性探索和实践。随着 AI 推理场景持续演进，模型分发、缓存治理和多集群数据访问仍会不断出现新的工程问题。我们也希望与更多开发者、AI 应用团队和基础设施从业者交流，共同探讨弹性算力场景下更稳定、更高效的数据访问方案。

降低数据存储成本：JuiceFS v1.4 分层存储设计解析

Fri, 22 May 2026 06:20:12 +0000

JuiceFS 社区版 1.4 增强了分层存储能力，支持以单文件或目录为粒度指定对象存储类型，使用户可以在文件系统语义下管理不同数据的存储层级。本文将围绕这一能力，介绍其应用背景、方案演进、使用模型、实现思路以及后续演进方向。

01 核心背景

在实际业务中，不同文件的访问频率和性能要求往往差异明显：一部分数据需要被频繁读取或写入，对访问延迟和吞吐较为敏感；另一部分数据写入后很少再被访问，更多关注长期保存成本。分层存储正是为了解决这一问题，即根据数据的访问特征，将其匹配到更合适的存储层，从而兼顾性能与成本。

通常可以根据访问特征将数据分为几类：

热数据：访问频繁，通常要求低延迟和较高吞吐；
低频数据：访问频率较低，但在需要时仍希望能够快速读取；
归档数据：主要用于长期保存，访问频率极低，可以接受一定的恢复等待时间，以换取更低的存储成本。

对象存储本身已经提供了类似的分层能力。以 Amazon S3 为例，S3 Standard 适合频繁访问的数据，S3 Standard-IA 适合低频访问但仍需要毫秒级读取的数据，而 Glacier / Deep Archive 更适合长期归档场景。不同存储类型在访问延迟、最低存储时长和费用模型上存在差异。

S3 主要存储类对比表
存储类型	使用案例	首字节延迟	最低存储持续时间费用
S3 Standard	用于对经常访问的数据进行通用存储	毫秒	不适用
S3 Standard-IA	需要毫秒级访问的不经常访问的数据	毫秒	30 天
S3 Glacier Deep Archive	存档非常少访问且成本非常低的数据	小时	180 天

对于构建在对象存储之上的 JuiceFS 来说，关键是将这些能力转化为文件系统层面的分层管理能力：用户按文件、目录或数据集设置存储层级，JuiceFS 负责映射到底层对象存储，并处理写入、迁移和归档恢复等操作。

02 JuiceFS 分层方案的演进

JuiceFS 分层能力的演进，本质上是从“被动不感知对象存储类型”，逐步发展到“可在文件和目录粒度管理主动存储层级”。

在 v1.1 以前，JuiceFS 尚未提供存储类型配置能力。用户虽然可以在对象存储侧手动调整对象的 Storage Class，但这些变化不会被 JuiceFS 在文件系统层面统一感知和管理。对于标准层、低频层等支持实时访问的对象，通常不会影响正常读写；但如果对象被转入归档类存储，则可能因无法直接读取而导致访问异常。

从 v1.1 开始，JuiceFS 支持通过 --storage-class 设置对象存储类型。例如，可以在 format 时指定文件系统的默认 Storage Class，也可以在 mount 时覆盖当前挂载点写入数据所使用的存储类型。这使 JuiceFS 开始具备使用对象存储分层能力的基础，但配置粒度仍主要停留在文件系统默认值或挂载点级别，无法针对具体目录、单个文件或不同业务数据集进行精细化管理。

v1.4 进一步将分层能力推进到文件和目录粒度。用户可以根据数据冷热程度，为单个文件或目录设置对应的存储层级；当目录设置了特定层级后，后续在该目录下新建的文件和子目录也可以自动继承这一配置。相比此前的默认值或挂载点级设置，v1.4 更适合按项目、目录、数据集或文件冷热程度进行分层管理。

03 分层存储如何配置

JuiceFS v1.4 分层存储的关键在于：将对象存储的 Storage Class 转化为文件系统可管理的存储在使用层面，JuiceFS v1.4 分层存储可以理解为两个步骤：先建立 Tier ID 与对象存储 Storage Class 的映射关系，再将文件或目录设置到对应的 Tier ID。通过这一方式，用户可以按文件、目录或数据集组织分层策略，而不需要在每次写入时直接指定底层对象的存储类型。

image: 映射示意图
caption: Tier ID 与 Storage Class 映射示意图

例如，可以将 Tier ID 1–3 分别映射到不同的对象存储类型：

juicefs config redis://localhost --tier-id 1 --tier-sc STANDARD_IA -y
juicefs config redis://localhost --tier-id 2 --tier-sc INTELLIGENT_TIERING -y
juicefs config redis://localhost --tier-id 3 --tier-sc GLACIER_IR -y

完成映射后，可以为单个文件或目录设置存储层级：

juicefs tier set redis://localhost --id 1 /path/to/file
juicefs tier set redis://localhost --id 2 /path/to/dir

目录级设置具有继承语义。为目录设置 tier-id 后，后续在该目录下新建的文件或子目录会自动继承父目录的存储层级；如果需要处理目录下已有的数据，则可以使用 -r 参数递归设置：

image: 继承与存量递归
caption: 目录继承与存量递归设置

juicefs tier set redis://localhost --id 2 /path/to/dir -r

对于 Glacier 等归档类存储，读取前通常需要先发起恢复请求：

juicefs tier restore redis://localhost /path/to/dir -r

04 技术实现原理

从实现角度看，JuiceFS v1.4 分层存储的关键，是将文件或目录的分层信息纳入元数据管理，并在写入、迁移和读取流程中根据 tier-id 选择相应的对象存储行为。

image: 各行为流程
caption: 写入、迁移与归档读取流程

元数据设计 JuiceFS 使用 tier-id 记录文件或目录所属的存储层级。tier-id 取值为 0 时，表示使用默认存储层；取值为 1–3 时，则对应用户配置的对象存储 Storage Class。

这样，存储层级不再只是对象存储侧的外部状态，而是成为 JuiceFS 可以在文件系统语义下感知和管理的元数据信息。后续写入新数据、迁移存量数据或检查文件状态时，JuiceFS 都可以基于这一元数据判断目标存储类型。

存量数据迁移 对于已有数据，修改存储层级不仅需要更新元数据中的 tier-id，还需要改变对象存储中已有对象的实际 Storage Class。递归设置目录时，JuiceFS 会处理目标目录下的文件和子目录，并通过对象存储的复制能力，将已有对象迁移到新的存储类型。

如果只是修改某个 tier-id 对应的 tier-sc 映射，已有对象的实际存储类型不会自动变化。此时需要使用 tier set --force 显式触发变更，使存量对象改为新的 Storage Class。

写入流程 新文件写入时，JuiceFS 会根据文件自身或父目录继承得到的 tier-id，确定数据应写入的对象存储类型。对于已经设置存储层级的目录，新建数据可以直接进入对应的存储层，避免先写入默认层后再迁移。

读取流程 对于标准层、低频层等支持实时访问的存储类型，读取过程对业务基本透明，JuiceFS 可以按正常流程从对象存储中读取数据。

对于 Glacier、Deep Archive 等归档类存储，对象通常不能直接实时读取。需要用 juicefs tier restore 命令先解冻文件，该命令会向对象存储服务发起恢复请求，对象能否读取以及何时可读，取决于云厂商的恢复机制；恢复完成后，业务再重新发起读取。

因此，归档层更适合长期保存、极低频访问的数据，不适合仍需随时在线读取的业务路径。实际使用时，需要同时评估存储成本、恢复时间和恢复成本。

05 后续演进方向

降低归档类存储的操作成本：归档类存储虽然具有较低的长期存储成本，但在写入、恢复、提前删除和生命周期转换等方面通常存在更复杂的成本模型。如果直接将数据写入归档类型，在频繁变更或批量迁移场景下，可能带来额外的操作成本。

后续，JuiceFS 可结合对象存储的生命周期管理机制，先将数据写入标准存储类型，并在对象上附加相应的 Object Tag。用户随后可以通过云厂商的生命周期规则，根据标签自动、批量地将数据转换到低频或归档存储层。这样既能保留 JuiceFS 在文件系统层面的分层管理能力，也可以利用对象存储原生的批量转换机制，降低批量归档和层级转换过程中的额外开销。

扩展到多桶、多云的分层管理：当前分层存储主要基于同一对象存储后端内的不同 Storage Class。后续，JuiceFS 也可以进一步将“层级”概念扩展到不同存储桶、不同对象存储服务，甚至不同云之间，使分层管理不再局限于单一存储后端。

例如，可以将热数据放置在以本地高性能 SSD 为后端的 MinIO 中，将冷数据或归档数据放置在云厂商的低成本归档存储桶中，并通过策略将数据从热层逐步迁移到冷层。通过这种方式，JuiceFS 有机会在统一文件系统命名空间下，实现跨桶、跨云、跨介质的数据分层管理。

AI 战略下架构演进：小米基于 JuiceFS 的统一存储实践

Tue, 12 May 2026 08:08:00 +0000

小米存储团队自 2021 年起推进基于 JuiceFS 的文件存储平台建设，最初主要面向云原生及部分业务场景提供文件存储能力。2024 年，小米提出全面 AI 战略后，原有异构存储体系在选型接入、数据流转和研发运维等方面的问题进一步显现。基于多协议接入、弹性扩展、多云适配和高性能访问等能力，团队最终确立了以 JuiceFS 为核心建设统一文件存储基座的方向，用于统一支撑大数据、云原生和 AI 等业务场景。

围绕这一目标，平台进一步建设了容量层、性能层和缓存层等核心能力，在降低多系统接入和数据流转复杂度的同时，兼顾大规模存储与高性能访问需求。过去两年，随着生成式 AI 和智能驾驶等业务快速发展，该平台已支撑大模型、智驾训练、推理加速和大数据上云等典型场景。目前，平台已具备支撑千亿级文件数量和 EB 级存储规模的能力，并可覆盖从原始数据、训练数据到模型文件分发的 AI 存储链路。

01 AI 战略下存储架构挑战

2023 年之前，小米与大多数公司类似，在不同业务场景中分别建设了多套存储系统。其中，大数据领域主要基于 HDFS 构建数据平台；AI 相关业务由于当时大模型尚未大规模兴起，主要依赖云上的 PFS/NAS 等高性能文件存储服务。

在此期间，我们也开始引入 JuiceFS，并配套建设内部自研 FDS（File Storage Service），通过 CSI Driver 等组件为云原生及部分业务场景提供文件存储能力。随着业务需求持续演进，这些存储系统在各自场景中独立迭代、独立维护，逐渐形成了较为复杂的异构存储格局。

2024 年，小米正式提出全面 AI 战略。原有存储架构在选型、接入、数据流转和研发运维等方面的短板开始集中显现，主要体现在以下几个方面：

选型与接入成本高：存储系统类型多、能力边界不一，业务团队需要分别理解和适配，使用门槛较高；
数据流转效率低：系统间缺乏统一访问方式，跨系统数据拷贝频繁，影响研发效率；
研发运维力量分散：多套系统独立维护和演进，资源难以聚焦到 AI 战略所需的核心基础设施建设中。

针对这些问题，我们在 2024 年进行了深入的内部讨论和架构调整，开始重新梳理面向 AI、大数据和云原生场景的统一存储架构。

02 基于 JuiceFS 建设统一文件基座

选型思考：多协议支持、弹性、多云、高性能

JuiceFS 是一款天然支持多协议、具备弹性扩展能力、提供高性能读写的分布式文件系统，能够完整适配原生 AI 场景与大数据场景的存储需求。

image: 1JuiceFS 架构图.drawio
caption: JuiceFS 社区版架构图

在云原生领域，我们自 2021 年起已开始引入 JuiceFS，并持续进行内部自研与迭代优化。同时，我们也与 JuiceFS 开源社区保持了紧密的合作关系，共同推动技术演进与场景落地。

在 AI 场景中，模型训练与推理大量依赖 POSIX 语义，这与 JuiceFS 的能力天然契合。与此同时，在大数据领域，我们原本就在推进大数据上云过程中的 HDFS 替代工作，业内已有诸多成熟实践，基于 HDFS 协议进行适配改造同样具备可行性。

综合多协议支持、弹性扩展、多云适配和高性能读写等因素，我们最终选择以 JuiceFS 作为统一文件存储基座的核心组件，解决此前多平台、多业务使用不同文件系统带来的数据流转复杂、接入成本高和运维分散等问题。

image: 小米存储架构演进
caption: 基于 JuiceFS 的统一文件存储基座架构演进

存储层能力建设

我们的核心目标，是基于 JuiceFS 构建统一的文件存储层，对外提供大容量、高性能的存储能力和标准化接入接口，统一支撑大数据、云原生和 AI 三类核心业务场景。

在客户端层面，我们充分利用 JuiceFS 的多协议能力，提供 POSIX、Hadoop SDK、Python SDK、S3 网关等多种接入方式，目前这些方式已经在内部业务中得到实际应用。

image: 存储基座技术架构
caption: JuiceFS 统一文件存储基座技术架构

在数据面，整体架构主要分为容量层、性能层和缓存层：

容量层：以公有云对象存储为基础，面向 EB 级存储规模建设，支持多云部署，可覆盖不同战略机房和多家云厂商环境。
性能层：基于 Ceph 和全闪机器进行大规模调优，用于承载 AI 训练等对吞吐和时延要求较高的场景。
缓存层：针对 AI 训练数据集“一次写入、多次读取、极少修改”的特点，基于 NVMe 和 RDMA 自研高性能分布式缓存系统，用于降低重复读取成本并提升训练数据访问效率。

在控制面，我们对社区版能力进行了定制化改造。元数据方面，自研了基于 Raft 协议的分布式元数据服务，以满足内部基建系统打通和多系统接入需求，并提升系统可靠性与扩展性；后台管理方面，建设了统一管理服务，负责数据生命周期管理、分层存储、垃圾回收，以及热数据从容量层向性能层或缓存层的预热等能力。

通过上述建设，JuiceFS 在小米内部逐步成为统一文件存储基座，既能支撑大规模容量型存储，也能满足 AI 训练场景下的高性能访问需求。目前，相关架构已经在线上生产环境运行，并支撑了大模型训练所需的高吞吐访问能力。

03 业务实践

在统一文件存储基座建设过程中，JuiceFS 已逐步覆盖小米内部的大数据、云原生和 AI 等核心业务场景。从整体规模看，该方案能够支撑 EB 级存储规模和千亿级文件数量；从能力建设看，则通过容量层、性能层和缓存层的协同设计，兼顾大规模存储与高性能访问需求。下面将结合大数据上云和 AI 存储链路两个典型场景，介绍 JuiceFS 在小米内部的具体实践。

场景 1：大数据上云与湖仓存储统一

早期，小米大数据体系主要基于 Hadoop 生态建设，其中 HDFS 采用的是上一代存算耦合架构。在实际运行过程中，这一架构逐渐暴露出性能波动、运维复杂、综合成本偏高等问题。相比之下，云存储在弹性扩展、资源利用和成本控制方面具有更明显的优势。因此，自 2021 年起，小米开始系统推进大数据上云。

image: 大数据上云
caption: 大数据上云

上云路径：从冷数据到湖仓层

小米大数据上云整体经历了三个阶段。

第一阶段是冷数据上云。我们首先将 HDFS 中的冷数据迁移至云存储，这一过程持续了两年多。

第二阶段是湖仓层上云。在这一阶段，我们自研了统一的湖仓层文件系统，推动大数据存储架构从存算耦合向存算分离演进。

第三阶段是基于 JuiceFS 建设统一存储基座。在完成 JuiceFS 技术选型后，我们将湖仓层整体迁移至 JuiceFS。湖仓建设本身可以利用 Iceberg 社区原生支持的对象存储接入能力，例如 OSS、S3 等协议。但小米业务覆盖国内外多个区域，并同时使用多家云服务，如果逐一适配不同云厂商，接入和维护成本都会较高。

因此，我们最终选择通过 JuiceFS 统一接入不同云存储。上层服务只需通过 SDK 切换后端存储地址，即可完成不同云环境下的访问适配，从而大幅降低多云接入复杂度。

在数据迁移方面，小米自研的数据工厂平台支持将表的底层存储透明切换至新架构，并在后台逐步完成原有数据向云上的迁移，整个过程对业务方基本无感知。同时，JuiceFS 支持多云和本地化部署。如果未来出于成本或战略考虑需要切换至自建存储，也可以通过 JuiceFS 将数据平滑迁回，为业务保留更高的架构灵活性。

热表缓存加速，计算提效

数据上云后，我们进一步分析了湖仓层的数据访问模式。对于日常报表和分析任务，计算通常集中在天级或周级的热数据上，并不需要频繁扫描全量数据。因此，湖仓层的性能优化重点并不是简单提升全量读取能力，而是提升热数据的访问效率和任务执行稳定性。

基于这一特点，我们与湖仓层协同建设了热表预热能力。系统会根据每日访问统计识别热点表及其热分区，并在任务执行前通过预热接口将相关数据提前加载至缓存层。对于每天早上 8 点前需要完成的周期性报表任务，热数据可以在计算开始前完成缓存预热，从而减少任务执行过程中的远端读取和重复访问。

经线下和线上测试，热表缓存后，相关计算效率提升约 10%–20%，计算耗时和计算资源消耗均有所下降。目前，缓存规模已达到 PB 级，平均吞吐量约为 200 GB/s。缓存层的引入也降低了跨云专线压力和云存储 API 调用成本：通过提高热数据命中率，可以减少重复跨云读取，从而降低带宽消耗和访问费用。

image: 热表预热架构
caption: 热表预热架构

大数据应用收益

性能方面：切换至 JuiceFS 后，顺序读写性能明显提升，部分场景下提升超过 1 倍。相关计算任务上线后，整体任务耗时降低约 10%–30%。

成本方面：从小米内部成本口径看，统一存储架构显著降低了存储成本。其中，国内场景存储成本降低约 70%，海外场景降低约 90%。海外原方案主要基于云主机和 EBS 构建 HDFS 三副本，副本率较高，导致整体存储成本偏高。

稳定性与运维方面：在原有混部架构下，大量计算任务运行时容易挤占节点资源，导致节点负载升高，并进一步影响存储性能。采用存算分离架构后，计算任务运行在独立计算节点上，任务耗时更加稳定，后续扩容和规模化管理也更加灵活。

场景 2： AI 一站式存储

AI 存储分为三个阶段：

原始数据阶段：需存储大量原始数据，经处理（如 ETL 处理）后用于训练，产出训练数据集，再投入高性能训练环境供训练任务运行。
训练阶段：训练任务需要高吞吐、低延迟的数据访问能力，以降低 IO 等待时间并提升 GPU 利用率；训练完成后产出模型文件，用于后续推理任务。
推理阶段：模型文件需快速分发至具体节点，以便推理任务启动时快速拉取。

image: AI存储流程
caption: AI 存储流程

此前，数据在多个系统间流转，业务方与自身均感受不便。统一采用 JuiceFS 后，可基于不同类型满足多样化深度需求。

各阶段需求与方案对比

AI 一站式存储需要覆盖原始数据、训练数据和模型文件三个阶段，不同阶段对容量、性能、成本和分发效率的要求各不相同。下表对各阶段的业务需求、此前方案和当前方案进行了对比。

方案比对
使用场景	业务需求	前期方案	当前方案
原始数据	• 大容量、低成本存储 • 支持高并发数据处理 • 适配百 PB 级及以上数据规模	• 直接使用对象存储 • HDFS • 其他低成本存储系统	JuiceFS 容量型存储 • 底层依托多云对象存储，屏蔽云厂商差异 • 支撑 EB 级容量和千亿级文件规模 • 支持百万级并发任务处理
训练数据	• 高吞吐、低延迟访问 • 降低 IO 同步等待时间 • 提升 GPU 利用率	• PFS、NAS 等高性能文件存储 • 性能较好，但系统成本较高	JuiceFS 性能型 / 缓存型存储 • 支持 TB/s 级吞吐和低延迟访问 • 结合异步 checkpoint 机制，降低 IO 同步耗时 • 通过缓存加速提升训练数据访问效率
模型文件	• 模型文件快速分发 • 支持高效拉取和加载 • 保障推理服务快速启动	• P2P 分发 • 工作流分发 • PFS 等高性能文件存储	JuiceFS 缓存加速分发 • 利用缓存机制提升模型加载效率 • 单机顺序加载性能最高可达 16 GB/s • 相比本地盘、FDS 等方案，加载耗时可降低数倍

高性能缓存加速，提效降本

在 AI 训练场景中，训练数据集通常具有“一次写入、多次读取、极少修改”的特点，属于典型的读多写少访问模式，适合通过缓存提升数据访问效率。

以内部智驾训练场景为例，数据集在成熟后，一个版本周期内数据量可能继续增长，但已有数据通常很少修改。此前采用的高性能文件存储虽然能够满足训练性能要求，但对于这类以重复读取为主的数据访问模式而言，存在一定的性能冗余和成本浪费。因此，我们开始推进基于 JuiceFS 的高性能缓存加速方案。

image: 训练流程
caption: 智驾场景训练流程

缓存方案具备多方面优势：

IO 路径短：客户端直接操作文件，IO 路径大幅缩短，响应迅速。
性能优化：通过 RDMA 和零拷贝优化，性能显著提升。与之前的高性能存储相比，吞吐量提升 20%以上，且仍在持续优化。
成本降低：原基于 PFS 的存储采用副本机制，虽部分场景使用 EC 编码，但副本因稳定性更高而应用更普遍。采用缓存方案后，可实现单副本存储，成本降低 60%以上。
资源整合利用：在支持 CPU 训练时，GPU 机器通常挂载有 NVMe 盘，单机约有 10TB 左右空间。此前这些资源在业务场景中分散使用，利用率不高。现在，我们将分散的 NVMe 资源统一纳入缓存池，为就近的 GPU 训练和数据处理任务提供加速能力。

04 未来规划

面向未来，我们将重点围绕以下三个方向持续演进。

首先，持续提升统一文件存储基座的稳定性、性能和扩展性。随着 AI 业务快速发展，训练、推理和数据处理任务对存储系统的吞吐、时延和可靠性提出了更高要求。后续我们将继续优化底层架构和关键链路，提升系统在大规模并发访问场景下的服务能力。

其次，加强海量数据的生命周期管理。当前业务数据规模持续增长，但不同类型数据在存储层级、访问频率和保留周期上的管理仍有进一步优化空间。我们将结合数据冷热特征、业务访问模式和成本模型，优化分层存储、数据归档、预热和清理策略，降低单位存储成本，提升整体资源利用率。

最后，持续完善数据管理与分析能力。在统一文件存储基座之上，我们将进一步建设面向业务的数据管理能力，帮助用户更清晰地理解数据分布、访问行为和资源使用情况，为后续的数据治理、成本优化和业务决策提供支撑。

以上是小米在统一文件存储基座建设中的阶段性实践。我们也期待与业界同行持续交流，共同探索更多技术实践。

分布式架构下配额设计：JuiceFS 的实现与典型案例

Thu, 23 Apr 2026 04:48:05 +0000

但在分布式系统中，配额管理并不只是“设置上限”这么简单。系统需要在多客户端并发写入、元数据异步更新和整体吞吐之间取得平衡；同时，配额规则也需要落实到不同层级的管控对象上。为此，JuiceFS 提供了覆盖全局、目录以及用户维度的多层级配额能力，以支持从整体容量控制到个体与团队约束的不同场景。

本文将介绍这套配额机制的设计与实现，包括核心数据结构、同步模型，以及写入与删除流程中的校验与统计更新逻辑；同时，也会结合典型案例，说明配额统计、空间释放和超限写入等场景中的常见现象。

01 JuiceFS 支持的配额类型与资源维度

JuiceFS 配额支持两类资源维度：

Space：表示已使用的存储空间。这里的统计采用文件系统侧的占用口径，并按块粒度进行对齐计算；后文“写入链路”部分将进一步解释 4 KiB 对齐下的增量估算方式。
Inodes：表示已使用的 inode 数量。在大量小文件场景下，inode 往往比 space 更早成为约束瓶颈，因此也必须纳入配额治理范围。

围绕这两类资源，JuiceFS 当前支持四种配额类型。

配额类型	作用范围	主要解决问题	典型使用场景
文件系统总配额	整个文件系统	防止整体资源失控	成本预算控制、容量上限
子目录配额	目录子树	阻断异常写入行为	防止误操作、小文件风暴
用户配额	单个用户	不同业务互不影响	多租户数据管理
用户组配额	项目或部门	成本分摊与团队限制	AI 项目共享环境

其中，用户配额和用户组配额预计将在社区版 1.4 中发布。

在实际使用中，一个常见、有效的组合策略是：

文件系统总配额做兜底；
目录配额专治“个体滥用”和“小文件风暴；
用户/组配额用于多租户管理。

这种分层限制既能控制整体资源上限，也能避免单个主体的异常增长影响其他业务。

02 配额实现机制

同步模型与数据结构

配额实现的难点在于“如何在多客户端并发写入下，以可接受的代价完成检查、统计和收敛”。JuiceFS 的客户端分布在多个节点上，会持续发起创建、写入、截断、删除等资源变更操作；如果每次变更都要求后端执行强一致检查与更新，写入路径将承担难以接受的额外开销。

因此，配额机制需要同时满足两个目标：

性能：避免每次写入都触发一次后端强一致更新。
一致性：多客户端并发写入时，确保系统用量最终收敛，并尽可能在写入前阻止超限操作。

基于这一权衡，JuiceFS 采用了“本地累计、周期 flush、定期 refresh”的同步模型：客户端先在本地内存中累计资源增量，由后台任务定期批量持久化到元数据后端；同时，客户端再周期性从后端拉取最新配额配置和基准用量，逐步对齐各自的全局视图。客户端之间不直接通信，而是以元数据后端作为统一的状态汇聚点。换句话说，JuiceFS 的配额并不追求每次操作上的强一致，而是在周期同步下实现最终一致的资源管控。

image: 存储架构
caption

在当前实现中，配额增量每 3 秒持久化一次（flushQuotas）；客户端约每 12 秒从后端重新加载一次最新的配额配置和基准用量（随挂载心跳触发的 refresh 调用）。这意味着，在极端情况下，不同客户端之间看到的全局视图可能存在约 12 秒的偏差，但会在后续同步过程中逐步收敛一致。

配额信息由 Quota 结构体统一管理，它表征单个配额实体，可适配目录、用户、用户组等不同类型的管控对象。其核心设计是将基准用量与增量用量解耦：

UsedSpace / UsedInodes：表示“后端已持久化的基准用量”。
newSpace / newInodes：表示“本客户端本地累计的增量”，尚未 flush 到后端。

type Quota struct {
    MaxSpace, MaxInodes   int64  // 最大空间和 inode 限制
    UsedSpace, UsedInodes int64  // 已使用的空间和 inode
    newSpace, newInodes   int64  // 待同步的新增使用量
}

在 inode 统计上，还需要特别考虑硬链接。不同配额类型对硬链接的计数语义并不相同。对于目录配额，统计按目录项进行：在某目录下创建一个硬链接，该目录的空间与 inode 用量各增加 1，删除时相应递减。对于用户配额和用户组配额，统计则按文件对象（inode）去重：同一文件即使存在多个硬链接，在 UID/GID 维度下也只计一次，因此创建或删除硬链接不会改变对应用户或用户组的用量。

配额存储

在配额存储机制方面，文件系统总配额作为全局“红线”，其容量与 Inode 上限直接持久化于元数据引擎中，由客户端在挂载时加载并执行硬限制拦截，确保底层资源不被穿透。

相比之下，目录、用户和用户组配额的检查与增量累计更多依赖客户端侧完成。客户端在内存中维护以 inode、UID、GID 为键的索引结构，并周期性从后端同步对应的 Quota 信息，从而在高频 I/O 场景下保持较低的查询开销。需要强调的是，客户端内存中的状态只是运行时缓存和增量视图，配额配置与基准用量的权威来源仍然是元数据后端。

配额检查

仅有同步模型和存储结构还不够，配额逻辑还必须嵌入具体的资源变更路径中。一次写入并不只是简单的数据追加，它可能同时伴随 inode 创建、块分配、目录项变化以及父级统计更新；在多客户端并发条件下，这些变化会共同作用于同一组配额约束。因此，只有把检查和统计更新真正放入写入、创建、截断、删除等操作路径，才能避免执行层面的超限写入和统计失真。

image: 22
caption: 写入文件： Quota 检查与更新流程图

写入前：增量估算与多维配额检查

当用户发起写入、创建或截断等可能改变资源用量的操作时，客户端首先估算该操作带来的资源增量，包括空间占用与 inode 变化。

空间增量基于底层数据块的实际分配粒度（如 4 KiB 对齐）进行估算，因此需要进行块级对齐计算。inode 的增量主要发生在创建类操作中，例如新建文件或目录。

在获得本次操作的资源增量后，客户端会在实际写入前执行配额校验。校验范围覆盖多个维度，包括用户与用户组配额、文件系统总配额以及所在目录树的目录配额。若任一维度在本次操作后可能超出限制，则请求会被拒绝，并返回配额超限或空间不足等错误。

通过在写入路径前置校验，可以在资源变更发生前阻断风险，避免后续清理或回滚带来的复杂处理。

写入后：本地累计增量与后台批量同步

写入成功后，本次操作产生的资源增量将被纳入相应的用量统计，并按既定收敛机制与全局状态对齐。具体来说，三类统计都会受到影响：

全局层面：文件系统整体用量会增加（或减少）；
目录层面：相关目录子树的用量也会随之变化；
用户/用户组层面：对应主体的用量同样需要累加。

这些更新首先反映在客户端本地累计的增量中，而不会立即以强一致方式写回后端；随后再由后台任务批量 flush，并通过周期性的 refresh 与其他客户端逐步对齐，最终完成全局收敛。

03 用量统计（stats）：实现配额系统的基础

配额机制要发挥作用，前提是系统能够以较低开销掌握当前资源用量。无论是规模庞大的目录树，还是数量众多的用户与用户组，如果每次检查都依赖实时全量扫描，性能成本都会难以接受。因此，高效且可靠的用量统计机制，是配额系统得以落地的前提。

目录 stats

目录配额约束的是整个目录子树的空间与 inode 总量，而不是单个文件的大小，因此需要依赖目录级用量统计作为支撑。

需要特别注意的是，目录统计（DirStats）与目录配额（Quota）的统计口径并不相同：目录统计仅计算当前目录下一级子目录和子文件的用量总和，属于单层统计；而目录配额统计的是整个目录子树的总用量，属于递归统计。这一设计使得目录统计能够以更低的开销维护，而目录配额则提供完整的子树用量视图。

实现这类统计的关键，在于大规模目录树下保持低开销与高可用性。JuiceFS 延续了与配额机制一致的思路：本地高频更新、后台批量持久化。客户端在内存中维护目录用量增量；当写入、删除等操作发生时，先在本地记录变化，再由后台任务定期批量同步到元数据后端。

同时，系统不会在挂载时全量加载目录树统计。在目录规模较大时，全量加载会带来显著的耗时与内存开销。因此目录统计采用按需获取策略：仅在配额检查、用量汇总、运维查询等需要精确用量的场景下，才从后端加载对应目录的统计数据。

当用户通过 df 或应用通过 statfs 获取用量信息时，JuiceFS 在性能与准确性之间做了折中：

优先使用本地缓存的已用空间和 inode 进行快速计算；
如果本地基准不完整（如刚启动）或需要更高实时性，再从后端拉取最新的全局计数进行校准；
最后叠加本地未同步的增量，以使结果更贴近当前节点的真实写入状态。

在得到已用量之后，客户端再结合是否配置了总容量上限来计算 total 和 avail：

若已配置上限，总容量按该值，剩余可用容量为“上限减去已用”；
若未配置上限，则返回动态估算的总容量，确保 df 等工具正常显示。

另外，从根目录查询配额时，系统会展示最大空间和 inode 上限，便于管理员了解全局资源限制。

此外，JuiceFS 将在 1.4 版本中支持对回收站（Trash）的目录统计进行实时更新。当文件被删除移入回收站或从回收站恢复、清理时，系统会即时更新回收站目录的统计信息，确保管理员能够准确掌握回收站的空间占用情况。

用户、用户组 stats

用户和用户组统计只会在对应的配额特性开启后才开始采集。开启前，内核路径中的 updateUserGroupStat 调用会直接返回，不产生实际统计。开启后，客户端会在本地以内存 map 维护用量数据，以 uid 和 gid 作为 key，并在所有可能引起用量变化的路径上更新相应统计。

需要特别注意的是，首次通过 juicefs quota set --uid 或 --gid 为某个用户或用户组设置配额时，系统会立即执行一次全局扫描，对已有文件进行全量遍历，以初始化存量统计数据。完成初始化后，后续的新增写入和删除操作则转为增量更新，无需再次执行全量扫描。

04 常见案例

1. 文件已删除，为什么文件系统总配额没有下降？对象存储账单为什么也没有变化？

这通常并不是统计错误，而是文件系统语义与统计模型共同作用的结果。

例如，在 JuiceFS 中启用回收站后，删除操作并不会立即释放空间，而是先将文件移动到回收站以便后续恢复。因此，回收站中的文件仍会计入文件系统总配额和用户组配额，但不再计入原目录配额。

另一个常见原因，是文件系统统计与对象存储侧计费之间本来就存在时间差。JuiceFS 的配额统计采用“本地累计 + 后台周期同步”的模型，短时间内不同客户端或不同统计接口之间可能尚未完全收敛；与此同时，对象存储侧也可能尚未完成垃圾回收（GC）或生命周期清理。因此，在短时间内看到文件系统用量、配额统计与对象存储账单不完全一致，通常属于预期现象，只要后续能够逐步收敛，一般不视为系统异常。

此外，还需要注意，配额和 statfs 展示的是文件系统视角下的空间占用与剩余容量，而对象存储账单则基于底层对象的实际存储模型，受分片、合并、延迟回收和生命周期规则等因素影响，两者本就不一定完全一致。

2. 配额已满，为什么追加写入已有文件时没有立即报错？

这通常与 JuiceFS 某些写入路径中的异步提交流程有关。对应用而言，write 系统调用可能先成功返回，而实际的数据提交与相应的配额判定会在后续阶段完成。因此，从调用方视角看，追加写入似乎“成功”了，但最终数据未必真正持久化；如果后续提交阶段判定超出配额，对应写入仍可能失败。

换句话说，应用看到 write 返回成功，并不等价于这次写入已经完成最终提交。在涉及配额限制的场景中，更稳妥的做法是结合后续错误处理、关闭文件时的返回状态以及实际文件大小变化来判断写入是否真正生效。

3. 配额还没用满，为什么创建文件却失败了？

这类现象通常与最终一致统计模型下的短暂视图偏差有关。

例如，某个卷设置了 2000 个 inode 的总配额，系统中已经存在 1999 个文件，按理说还可以再创建 1 个文件。但在极端并发或刷新时序特殊的情况下，客户端本地缓存与后端基准计数之间可能出现短暂不一致，从而导致内存中的已用 inode 统计暂时偏大，最终提前拒绝了原本合法的创建请求。

这类问题本质上来源于“本地累计 + 周期同步”的收敛模型：它避免了每次操作都依赖后端强一致更新的高开销，但也意味着在极端情况下，系统可能出现短时间的误判。通常这类误判会随着后续同步逐步消失，必要时也可以通过重试来缓解。

这也说明，在分布式环境下，配额限制更适合被理解为一种高效且近实时的约束机制，而不是对每一次并发操作都做完全同步的强一致判断。

4. 写入超出配额后，为什么“失败”的文件还留在目录里？

这并不是 JuiceFS 独有的行为，在遵循 POSIX 语义的文件系统中，这类现象并不罕见。

例如，用户为某个目录设置了 1 GiB 配额，然后使用 dd 尝试写入一个 2 GiB 文件。文件系统会先允许前 1 GiB 的合法写入；直到后续写入触发配额上限时，才返回 Disk quota exceeded。因此，最终留下一个大小约为 1 GiB 的“未写完文件”，并不意味着系统行为异常，而是说明前半部分数据已经成功写入，后续部分才因超限而失败。

文件系统负责报告错误，但不会替应用程序决定是否删除已经成功写入的数据。是否清理这种不完整文件，应由应用程序自行处理。这也是标准的 POSIX 语义：文件系统负责返回错误，应用程序负责后续清理与恢复。

05 小结

在分布式文件系统中，配额并不是一个简单的“计数器功能”，而是一套需要在性能、一致性与治理粒度之间权衡的系统设计。JuiceFS 通过写前校验、本地累计以及后台周期同步，在尽量降低写入路径开销的同时，使各类用量统计在最终一致模型下逐步收敛。基于这一机制，配额控制既覆盖文件系统全局容量，也支持目录、用户和用户组等多个层级，从而满足多租户隔离、个体约束和团队资源治理等典型场景的需求。

如果在实际使用中遇到问题，或有不同的实践思路，欢迎在评论区分享与交流。