途虎养车是一家线上线下一体化汽车服务平台。截至 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 架构，这是一种典型的中心化高可用集群方案。在公有云多租户、超大规模和高弹性的基础设施环境下，中心化调度可以更好地感知集群状态，并在坏盘、机器上下线、故障隔离等场景中降低对线上任务的影响，从而提升整体系统的稳定性和可运维性。
与此相比，JuiceFS + Ceph RADOS 采用组合式落地路径，通过 JuiceFS 承担统一文件系统层，由后端元数据引擎和 Ceph RADOS 分别承载元数据与数据存储能力。Ceph 通过 CRUSH 算法实现数据分布和故障域管理，底层数据组织更加去中心化。
在“存算分离”的设计思想下，盘古与 JuiceFS + Ceph RADOS 体现出不同的工程权衡。盘古采用偏重客户端的技术路径。当用户在计算节点挂载并写入盘古存储时，无论底层采用三副本策略，还是采用 9:3、4:2 等纠删码（EC）架构，数据切片分发、EC 计算和校验等逻辑都可以在客户端侧承担更多工作。这种设计能够减轻后端存储服务器的计算压力，有利于支撑公有云级别的大规模扩展，但也会在一定程度上消耗业务计算节点的网络和 CPU 资源，并提高客户端复杂度。
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 则面向大模型推理场景，用于在多级存储体系中承载上下文数据的缓存与访问加速，提升在线推理服务的响应效率。
第三层是存储协议层。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 进行数据交互。相比传统网关型存储架构，这种方式减少了多层转发开销，使客户端在完成元数据交互后，能够更直接地访问底层存储集群，从而缩短数据访问链路。
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 方案仍体现出明显的性能提升：
- 小文件写入性能提升明显。 小文件写性能提升约 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，造成严重的写放大和几千倍的空间浪费。
为缓解这一问题，我们通过升级引入 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（内存溢出）有关。
第一类是元数据备份引发的周期性 OOM。当集群文件数量达到千万级甚至亿级时，JuiceFS 默认每小时执行的周期性元数据备份会产生较大的备份文件。由于该备份任务会随机选择集群中的客户端执行，而底层 RADOS 架构对单次 Object 写入存在大小限制，例如 128MB，因此在大规模文件系统场景下，备份任务可能高频失败，并进一步导致 Mount Pod 内存持续增长，最终触发 OOM。
针对这一问题，我们关闭了 Mount Pod 的自动备份能力，禁止在线客户端执行自动备份，改由专用定时任务在后台统一处理元数据备份，从而避免业务客户端承担额外的备份压力。
第二类是页缓存增长引发的偶发性 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 推理集群提供更灵活的上下文数据管理和访问加速能力。
