途虎统一 AI 存储架构实践

**摘要：**途虎采用 JuiceFS、TiKV 和 Ceph RADOS，为 AI 训练、AI 推理及数据分析构建统一存储，在支持超过 1 亿个文件的同时，实现小文件写入速度最高提升 5.5 倍、小文件读取速度最高提升 3.2 倍。

途虎（9690.HK）是一体化的线上线下汽车服务平台。截至 2025 年底，我们的注册用户已增长至 1.623 亿，并在中国各地运营着 8,008 家服务中心。随着业务持续扩张，我们的基础设施需要支持日益多样化的数据管理和计算工作负载。多年来，为满足不同应用的需求，我们分别部署了 NFS、Alluxio、MinIO 和 SeaweedFS 等多种存储系统。尽管每种方案都解决了特定场景的问题，但整体存储架构变得愈发割裂，导致数据迁移成本高昂，运维难度也不断增加。

在评估统一存储架构时，结合现有的私有云基础设施和 Ceph 部署，我们基于 JuiceFS、TiKV 和 Ceph 对象存储集群（RADOS）构建了统一的 AI 存储平台。

如今，该平台通过一套存储基础设施统一承载 AI 训练、AI 推理和大数据处理工作负载，目前管理着超过 1 亿个文件。在低并发基准测试中，小文件顺序写入性能最高提升 5.5 倍，小文件读取性能最高提升 3.2 倍。

本文将介绍我们如何在现有 Ceph 基础设施之上设计并部署统一 AI 存储平台。我们还将分享多项生产环境优化实践，包括 Ceph RADOS 数据路径、纠删码池、降低小文件写放大，以及提升容器化部署的稳定性。

从多套存储系统到统一存储底座

在公司发展的早期阶段，为了最大限度提高开发速度并满足应用的即时需求，我们为不同应用分别建设了独立的存储基础设施。随着平台不断演进，这种方式逐渐导致生产环境中多套存储系统并存。

云原生计算、大规模 AI 训练和 AI 推理的快速普及，暴露出了这一架构的局限性。架构一致性、数据流动性、运维复杂度和存储性能方面的问题日益突出。

我们总结出了四项主要挑战。

**运维复杂度高：**生产环境依赖众多存储方案，包括 NFS、Alluxio、MinIO、Ceph、SeaweedFS 以及各种云块存储服务。每套系统都有各自的部署模式、访问协议、运维流程和故障排查方法。随着存储集群持续扩张，日常维护、容量规划和版本升级变得越来越困难。

**运维复杂度高：**生产环境依赖众多存储方案，包括 NFS、Alluxio、MinIO、Ceph、SeaweedFS 以及各种云块存储服务。每套系统都有各自的部署模式、访问协议、运维流程和故障排查方法。随着存储集群持续扩张，日常维护、容量规划和版本升级变得越来越困难。

**数据孤岛：**不同存储系统提供不同的接口，缺乏统一的数据访问层。AI 训练流水线通常需要符合 POSIX 规范的文件语义，而周边的数据处理、模型管理、备份和归档工具通常依赖对象存储 API。由于这些存储系统无法自然共享同一份数据，数据集经常需要在不同平台之间复制或同步。这增加了运维开销、存储消耗和工作流复杂度。

**数据孤岛：**不同存储系统提供不同的接口，缺乏统一的数据访问层。AI 训练流水线通常需要符合 POSIX 规范的文件语义，而周边的数据处理、模型管理、备份和归档工具通常依赖对象存储 API。由于这些存储系统无法自然共享同一份数据，数据集经常需要在不同平台之间复制或同步。这增加了运维开销、存储消耗和工作流复杂度。

**存储成本持续上升：**随着业务持续增长，文件数量和存储总容量都在快速增加。与此同时，包括硬件采购、数据中心资源和存储运维在内的基础设施成本也不断攀升。如何在保持性能和可靠性的同时提高存储利用率，成为基础设施团队的一项关键目标。

**存储成本持续上升：**随着业务持续增长，文件数量和存储总容量都在快速增加。与此同时，包括硬件采购、数据中心资源和存储运维在内的基础设施成本也不断攀升。如何在保持性能和可靠性的同时提高存储利用率，成为基础设施团队的一项关键目标。

**AI 工作负载提出了更高的性能要求：**AI 训练、AI 推理、存算分离和大数据分析，对底层存储系统的并发能力、吞吐量、访问延迟和稳定性提出了更高要求。尤其是大规模小文件访问、多节点并发读取、模型文件加载和在线推理服务，不仅要求存储系统提供稳定的容量支撑，还要求其在高并发条件下提供可预测的性能。

**AI 工作负载提出了更高的性能要求：**AI 训练、AI 推理、存算分离和大数据分析，对底层存储系统的并发能力、吞吐量、访问延迟和稳定性提出了更高要求。尤其是大规模小文件访问、多节点并发读取、模型文件加载和在线推理服务，不仅要求存储系统提供稳定的容量支撑，还要求其在高并发条件下提供可预测的性能。

因此，基于多套独立存储系统的现有架构已经无法支撑应用的长期增长。我们决定将分散的存储资源整合成统一的存储底座，在简化运维的同时，实现不同计算环境之间的无缝数据共享。

新存储平台围绕两大能力领域进行设计：

**面向基础设施和虚拟化工作负载的块存储：**该能力为虚拟机镜像、云硬盘和传统基础设施服务提供可靠的高性能存储。

**面向基础设施和虚拟化工作负载的块存储：**该能力为虚拟机镜像、云硬盘和传统基础设施服务提供可靠的高性能存储。

**面向云原生工作负载的统一数据访问：**涵盖 Kubernetes 应用、传统微服务、大数据分析、AI 训练、AI 推理，以及向量数据库等新兴中间件。其中，AI 训练和推理在文件语义、对象接口、数据吞吐量、小文件性能和多节点并发访问方面带来了更为集中的挑战。

**面向云原生工作负载的统一数据访问：**涵盖 Kubernetes 应用、传统微服务、大数据分析、AI 训练、AI 推理，以及向量数据库等新兴中间件。其中，AI 训练和推理在文件语义、对象接口、数据吞吐量、小文件性能和多节点并发访问方面带来了更为集中的挑战。

因此，构建统一的云存储底座，既需要面向虚拟化环境的块存储能力，也需要面向 AI 和云原生工作负载的数据访问能力。下一节将重点介绍后者，即如何基于 JuiceFS 构建统一的数据访问底座，以支持 AI 训练、AI 推理和大数据处理。

使用 JuiceFS 构建统一 AI 存储平台

在设计统一存储平台时，我们结合现有的私有云基础设施、存储投入和工作负载特征，评估了多种架构方案。

我们的首要目标是支持大规模数据访问、实现存算分离、提供多种访问协议，并在不引入不必要运维复杂度的前提下实现高可靠性。

我们没有从头构建新的分布式存储系统，而是选择了基于 JuiceFS、TiKV 和 Ceph RADOS 的模块化架构。这种方式既能复用现有的 Ceph 基础设施，又能引入统一文件系统，通过单一存储平台支持 AI 训练、推理和大数据处理工作负载。

该架构的一项关键设计原则是元数据与用户数据分离。

JuiceFS 提供统一文件系统层，元数据引擎和 Ceph RADOS 则分别独立负责元数据管理与数据存储。在存储层，Ceph 使用 CRUSH 算法分布数据并管理故障域，从而提供去中心化且高度可靠的存储后端。

该架构还采用了轻量级客户端模型。

JuiceFS 客户端负责文件系统语义、元数据操作、缓存管理和请求调度。数据写入 Ceph RADOS 后，无论通过副本还是纠删码实现，数据持久性都完全由存储集群负责。

这种职责划分使计算节点保持轻量，最大限度减少对 AI 训练工作负载的干扰，并充分利用现有 Ceph 部署已经具备的可靠性和可扩展性。

对于我们的私有云环境，与开发和维护一套集成式分布式存储系统相比，这种模块化方案显著降低了工程和运维开销。同时，它还能通过公共存储平台为 AI 训练、AI 推理和大数据工作负载提供统一访问能力。

统一 AI 存储架构

我们的统一 AI 存储平台由四个逻辑层组成。

最上层是应用工作负载，包括虚拟机、基于 Kubernetes 的容器化应用、传统微服务、AI 训练、AI 推理和 Apache Spark 作业。

缓存层由两个组件组成：

DataCache Pool：用于加速对训练数据集、模型文件和其他热点数据的重复访问，降低存储后端的负载。

DataCache Pool：用于加速对训练数据集、模型文件和其他热点数据的重复访问，降低存储后端的负载。

KVCache Pool：专为大语言模型（LLM）推理设计。它在多个存储层级之间缓存上下文数据，从而降低延迟并提升在线推理服务的响应速度。

KVCache Pool：专为大语言模型（LLM）推理设计。它在多个存储层级之间缓存上下文数据，从而降低延迟并提升在线推理服务的响应速度。

JuiceFS 在这里提供统一的数据访问入口。AI 训练作业通过 POSIX FUSE 或 CSI Driver 访问数据；大数据 Spark 作业通过 JuiceFS Hadoop Java SDK 访问数据；对象存储工具链则通过 JuiceFS S3 Gateway 访问同一份数据。这种方式围绕同一底层数据集统一了文件存储、对象存储和大数据访问接口，减少了系统之间的数据移动和冗余存储。

需要注意的是，虚拟机云盘等块存储场景主要由 Ceph RBD 处理，它属于整个云存储系统的块存储能力。本文重点介绍基于 JuiceFS 构建的文件、对象及大数据访问基础。尽管二者共享底层 Ceph 存储资源，但其访问语义和服务目标有所不同。

JuiceFS 采用元数据与数据解耦的架构。对于拥有数亿个文件的文件系统，元数据能力会直接影响路径解析、目录遍历、文件属性查询、小文件访问以及并发作业的启动性能。TiKV 提供分布式事务、强一致性、高可用性和水平扩展能力，能够为大规模文件系统提供稳定的元数据支持。我们为元数据层构建了一个由五个节点组成的 TiKV 集群。

在数据层，我们使用 Ceph RADOS 作为 JuiceFS 的底层数据存储引擎。Ceph RADOS 复用了现有私有云存储资源，降低了重复建设基础设施的成本。此外，通过创建用于物理数据存储的纠删码池，我们在保持可靠性的同时提高了物理磁盘容量利用率，缓解了数据增长带来的成本压力。

在该架构中，数据通信遵循两条路径：

客户端与 TiKV 之间的元数据路径，负责处理路径查找、目录结构、文件属性和状态信息

客户端与 TiKV 之间的元数据路径，负责处理路径查找、目录结构、文件属性和状态信息

客户端与 Ceph RADOS 之间的数据读写路径，负责实际的数据块访问

客户端与 Ceph RADOS 之间的数据读写路径，负责实际的数据块访问

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

生产部署与优化实践

关键场景部署与存储整合

在 LLM 应用场景中，我们公司为 MiniMax 等模型推理服务配备了专用的自建计算集群。同时，内部各应用线开发的定制模型在通过生产验证后，也逐步迁移到了 JuiceFS。因此，核心 LLM 推理和训练应用已开始统一迁移到新的文件存储基础设施，原有 NFS 集群和 Alluxio 存储集群则进入分阶段下线流程。

在核心中间件和备份场景中，包括大规模 ClickHouse 部署在内的多个核心中间件系统以及全量生产备份任务，也已经迁移至 JuiceFS。随着这套统一文件存储基础在容量、稳定性和访问效率方面得到验证，MinIO 和 SeaweedFS 也已进入下线流程，从而降低了并行维护多套存储系统的运维复杂度。

面向 AI 训练和推理的缓存加速

对于 AI 训练场景，训练数据通常呈现“一次写入、多次读取”的访问模式。我们利用 JuiceFS 社区版的本地数据缓存能力，将热点训练数据缓存在计算节点上。这能够降低后端存储压力，并提高多节点并发读取效率。

对于 LLM 推理场景，处理在线请求或执行迭代式 token 生成的模型，对上下文数据加载的延迟和吞吐量十分敏感。在单节点 GPU 显存和内存容量有限的情况下，我们采用多级缓存机制，将上下文数据缓存在多个层级中，从而提升在线推理的响应效率。

基准测试与小 I/O 优化

部署统一存储平台后，我们重点评估了它在小文件工作负载下的性能。

我们使用 juicefs bench 和 fio 对小文件操作及随机 I/O 进行了基准测试，对比新的 JuiceFS + Ceph RADOS 架构与此前的 JuiceFS + MinIO 部署。

为了尽量减少缓存带来的影响，测试期间禁用了所有本地缓存，使 I/O 请求直接由存储后端提供服务。需要说明的是，这些基准测试旨在验证架构，而不是衡量集群的峰值性能。测试仅使用四个客户端线程，在低并发条件下进行。

即使在低并发测试条件下，新架构仍展现出了显著的性能提升。

下面两个表格展示了 JuiceFS + MinIO 的测试结果：

下面两个表格展示了 JuiceFS + Ceph RADOS 的测试结果：

测试结果要点：

小文件写入吞吐量最高提升 5.5 倍，单个文件的写入延迟也显著降低。

小文件读取吞吐量最高提升 3.2 倍，实现了更高的读取吞吐量和更低的单文件读取延迟。

随机 I/O 性能同样有所提升。吞吐量和 IOPS 均有增长，其中随机写入 IOPS 提升超过 3 倍。

从架构角度来看，JuiceFS + MinIO 方案需要承担 S3 接口和对象存储网关的开销，而 JuiceFS + Ceph RADOS 方案则使用 librados 与底层存储集群进行更直接的交互，从而减少网关转发开销。因此，在小文件写入和随机写入等对访问路径敏感的场景中，Ceph RADOS 展现出了更为显著的性能优势。

然而，在随机小文件读取测试中，由于禁用了本地缓存，仍需要从物理磁盘实时检索数据。因此，读取性能并未像写入性能一样实现数量级的提升，但整体仍稳定提升了约 1.4 倍。

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

在纠删码（EC）模式下，传统 EC 算法要求与条带单元对齐。在 6+3 配置中，即使写入一个仅有 10 字节的微小文件，也需要填满 6 个各为 4 KB 的数据块，再加上 3 个编码块，最终占用 36 KB 的物理存储空间，造成严重的写放大和数千倍的空间浪费。

为了解决这一问题，我们引入了 Ceph 的 Fast EC 特性来优化小对象写入。

一方面，Fast EC 缓解了小文件的空间放大问题。启用后，小对象不再被强制填满整个条带。对于一个 10 字节的文件，其逻辑大小仍为 10 字节，而物理空间只占用第一个条带；在最小分配单元为 4 KB 并包含校验数据的情况下，物理占用可减少至 16 KB。

另一方面，Fast EC 也提升了小 I/O 场景下的读写效率。读取时不再需要获取完整条带；写入时可以使用校验增量写入（PDW），减少不必要的网络交互和 I/O 开销，从而提升小文件的整体读写性能。

JuiceFS Mount Pod 稳定性优化

在容器化环境中，AI 训练应用偶尔会遇到 bad file descriptor 错误，严重影响训练效率。排查发现，这些错误与 Mount Pod 内存不足（OOM）有关。

元数据备份引发的周期性 OOM： 当集群达到数千万乃至数亿个文件时，JuiceFS 默认每小时执行的元数据备份会生成大型备份文件。由于这些备份任务会随机分配给集群中的客户端，而底层 RADOS 架构对单个对象的写入大小有限制（例如 128 MB），因此在大规模文件系统场景下，备份任务可能反复失败，导致 Mount Pod 的内存占用持续增长，并最终触发 OOM。

为了解决这一问题，我们禁用了 Mount Pod 上的自动备份，防止在线客户端执行自动备份。取而代之的是，由专用的定时任务集中处理元数据备份，避免给应用客户端带来额外的备份压力。

页缓存增长引发的偶发性 OOM： 在频繁读取大量本地缓存的过程中，Linux 内核页缓存会持续增长。在这种情况下，即使容器的实际内存占用仅约为 1.1 GB，Kubernetes 依据包含页缓存的 working_set_bytes 作出 OOM 判断时，也可能在该指标升至较高水平（例如 33.5 GB）后触发 OOM Kill，造成客户端偶发断连。

为了解决这一问题，我们根据历史监控数据提高了 limits.memory。随后，我们对缓存资源进行了物理隔离，确保不同 PVC 不会共享同一个本地缓存目录。对于内存有限的节点（例如 CPU 节点），我们将本地缓存容量（数据缓存大小）限制在合理范围内（例如 10 GB 至 50 GB），并在达到上限后启用缓存回收。这可以防止容器内的内核页缓存不受控制地增长。

通过这些优化，Mount Pod 在大规模文件系统和高频缓存访问场景下的稳定性得到显著提升。这为将更多 AI 训练和推理工作负载接入统一文件存储底座奠定了坚实基础。

我们计划围绕以下三个方面，持续演进 AI 云存储基础设施：

从私有云到混合云的统一管理： 随着 AI 训练任务同时调度至私有云和公有云，存储底座需要具备更强的跨环境数据管理能力。在现有私有 Ceph RADOS 架构的基础上，我们将继续探索 JuiceFS 与公有云对象存储的集成。

通过尽可能将跨云数据同步、数据分发和访问路径管理下沉至存储层，可以降低应用对不同云环境差异的感知，提供更加一致的挂载路径和访问体验。这将提高训练任务在不同计算环境之间的迁移效率，并降低多云环境中的数据管理复杂度。

推进湖仓一体，减少跨系统数据流动： 此前，离线 HDFS 大数据集群与算法存储集群之间的数据流动依赖同步工具，增加了数据流水线的复杂度、数据冗余、同步延迟和管理成本。

我们计划进一步采用并完善 JuiceFS Hadoop Java SDK，使算法层的 Spark 作业能够直接读写底层统一存储池。这样，大数据计算、算法训练和数据归档便可围绕同一个存储底座运行，从而减少跨系统的数据复制和冗余存储，进一步打破数据孤岛，推进存算分离与湖仓一体。

构建分层存储，加速 LLM 推理： 随着 LLM 推理服务规模扩大，单一存储介质已无法同时满足成本、容量和延迟要求。我们计划构建数据分层和 KVCache 分层能力。