小米存储团队自 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 场景与大数据场景的存储需求。
在云原生领域，我们自 2021 年起已开始引入 JuiceFS，并持续进行内部自研与迭代优化。同时，我们也与 JuiceFS 开源社区保持了紧密的合作关系，共同推动技术演进与场景落地。
在 AI 场景中，模型训练与推理大量依赖 POSIX 语义，这与 JuiceFS 的能力天然契合。与此同时，在大数据领域，我们原本就在推进大数据上云过程中的 HDFS 替代工作，业内已有诸多成熟实践，基于 HDFS 协议进行适配改造同样具备可行性。
综合多协议支持、弹性扩展、多云适配和高性能读写等因素，我们最终选择以 JuiceFS 作为统一文件存储基座的核心组件，解决此前多平台、多业务使用不同文件系统带来的数据流转复杂、接入成本高和运维分散等问题。
存储层能力建设
我们的核心目标，是基于 JuiceFS 构建统一的文件存储层，对外提供大容量、高性能的存储能力和标准化接入接口，统一支撑大数据、云原生和 AI 三类核心业务场景。
在客户端层面，我们充分利用 JuiceFS 的多协议能力，提供 POSIX、Hadoop SDK、Python SDK、S3 网关等多种接入方式，目前这些方式已经在内部业务中得到实际应用。
在数据面，整体架构主要分为容量层、性能层和缓存层：
- 容量层：以公有云对象存储为基础，面向 EB 级存储规模建设，支持多云部署，可覆盖不同战略机房和多家云厂商环境。
- 性能层：基于 Ceph 和全闪机器进行大规模调优，用于承载 AI 训练等对吞吐和时延要求较高的场景。
- 缓存层：针对 AI 训练数据集"一次写入、多次读取、极少修改"的特点，基于 NVMe 和 RDMA 自研高性能分布式缓存系统，用于降低重复读取成本并提升训练数据访问效率。
在控制面，我们对社区版能力进行了定制化改造。元数据方面，自研了基于 Raft 协议的分布式元数据服务，以满足内部基建系统打通和多系统接入需求，并提升系统可靠性与扩展性；后台管理方面，建设了统一管理服务，负责数据生命周期管理、分层存储、垃圾回收，以及热数据从容量层向性能层或缓存层的预热等能力。
通过上述建设，JuiceFS 在小米内部逐步成为统一文件存储基座，既能支撑大规模容量型存储，也能满足 AI 训练场景下的高性能访问需求。目前，相关架构已经在线上生产环境运行，并支撑了大模型训练所需的高吞吐访问能力。
03 业务实践
在统一文件存储基座建设过程中，JuiceFS 已逐步覆盖小米内部的大数据、云原生和 AI 等核心业务场景。从整体规模看，该方案能够支撑 EB 级存储规模和千亿级文件数量；从能力建设看，则通过容量层、性能层和缓存层的协同设计，兼顾大规模存储与高性能访问需求。下面将结合大数据上云和 AI 存储链路两个典型场景，介绍 JuiceFS 在小米内部的具体实践。
场景 1： 大数据上云与湖仓存储统一
早期，小米大数据体系主要基于 Hadoop 生态建设，其中 HDFS 采用的是上一代存算耦合架构。在实际运行过程中，这一架构逐渐暴露出性能波动、运维复杂、综合成本偏高等问题。相比之下，云存储在弹性扩展、资源利用和成本控制方面具有更明显的优势。因此，自 2021 年起，小米开始系统推进大数据上云。
上云路径：从冷数据到湖仓层
小米大数据上云整体经历了三个阶段。
第一阶段是冷数据上云。我们首先将 HDFS 中的冷数据迁移至云存储，这一过程持续了两年多。
第二阶段是湖仓层上云。在这一阶段，我们自研了统一的湖仓层文件系统，推动大数据存储架构从存算耦合向存算分离演进。
第三阶段是基于 JuiceFS 建设统一存储基座。在完成 JuiceFS 技术选型后，我们将湖仓层整体迁移至 JuiceFS。湖仓建设本身可以利用 Iceberg 社区原生支持的对象存储接入能力，例如 OSS、S3 等协议。但小米业务覆盖国内外多个区域，并同时使用多家云服务，如果逐一适配不同云厂商，接入和维护成本都会较高。
因此，我们最终选择通过 JuiceFS 统一接入不同云存储。上层服务只需通过 SDK 切换后端存储地址，即可完成不同云环境下的访问适配，从而大幅降低多云接入复杂度。
在数据迁移方面，小米自研的数据工厂平台支持将表的底层存储透明切换至新架构，并在后台逐步完成原有数据向云上的迁移，整个过程对业务方基本无感知。同时，JuiceFS 支持多云和本地化部署。如果未来出于成本或战略考虑需要切换至自建存储，也可以通过 JuiceFS 将数据平滑迁回，为业务保留更高的架构灵活性。
热表缓存加速，计算提效
数据上云后，我们进一步分析了湖仓层的数据访问模式。对于日常报表和分析任务，计算通常集中在天级或周级的热数据上，并不需要频繁扫描全量数据。因此，湖仓层的性能优化重点并不是简单提升全量读取能力，而是提升热数据的访问效率和任务执行稳定性。
基于这一特点，我们与湖仓层协同建设了热表预热能力。系统会根据每日访问统计识别热点表及其热分区，并在任务执行前通过预热接口将相关数据提前加载至缓存层。对于每天早上 8 点前需要完成的周期性报表任务，热数据可以在计算开始前完成缓存预热，从而减少任务执行过程中的远端读取和重复访问。
经线下和线上测试，热表缓存后，相关计算效率提升约 10%--20%，计算耗时和计算资源消耗均有所下降。目前，缓存规模已达到 PB 级，平均吞吐量约为 200 GB/s。缓存层的引入也降低了跨云专线压力和云存储 API 调用成本：通过提高热数据命中率，可以减少重复跨云读取，从而降低带宽消耗和访问费用。
大数据应用收益
性能方面：切换至 JuiceFS 后，顺序读写性能明显提升，部分场景下提升超过 1 倍。相关计算任务上线后，整体任务耗时降低约 10%--30%。
成本方面：从小米内部成本口径看，统一存储架构显著降低了存储成本。其中，国内场景存储成本降低约 70%，海外场景降低约 90%。海外原方案主要基于云主机和 EBS 构建 HDFS 三副本，副本率较高，导致整体存储成本偏高。
稳定性与运维方面：在原有混部架构下，大量计算任务运行时容易挤占节点资源，导致节点负载升高，并进一步影响存储性能。采用存算分离架构后，计算任务运行在独立计算节点上，任务耗时更加稳定，后续扩容和规模化管理也更加灵活。
场景 2： AI 一站式存储
AI 存储分为三个阶段：
- 原始数据阶段：需存储大量原始数据，经处理（如 ETL 处理）后用于训练，产出训练数据集，再投入高性能训练环境供训练任务运行。
- 训练阶段：训练任务需要高吞吐、低延迟的数据访问能力，以降低 IO 等待时间并提升 GPU 利用率；训练完成后产出模型文件，用于后续推理任务。
- 推理阶段：模型文件需快速分发至具体节点，以便推理任务启动时快速拉取。
此前，数据在多个系统间流转，业务方与自身均感受不便。统一采用 JuiceFS 后，可基于不同类型满足多样化深度需求。
各阶段需求与方案对比
AI 一站式存储需要覆盖原始数据、训练数据和模型文件三个阶段，不同阶段对容量、性能、成本和分发效率的要求各不相同。下表对各阶段的业务需求、此前方案和当前方案进行了对比。
高性能缓存加速，提效降本
在 AI 训练场景中，训练数据集通常具有"一次写入、多次读取、极少修改"的特点，属于典型的读多写少访问模式，适合通过缓存提升数据访问效率。
以内部智驾训练场景为例，数据集在成熟后，一个版本周期内数据量可能继续增长，但已有数据通常很少修改。此前采用的高性能文件存储虽然能够满足训练性能要求，但对于这类以重复读取为主的数据访问模式而言，存在一定的性能冗余和成本浪费。因此，我们开始推进基于 JuiceFS 的高性能缓存加速方案。
缓存方案具备多方面优势：
- IO 路径短：客户端直接操作文件，IO 路径大幅缩短，响应迅速。
- 性能优化：通过 RDMA 和零拷贝优化，性能显著提升。与之前的高性能存储相比，吞吐量提升 20%以上，且仍在持续优化。
- 成本降低：原基于 PFS 的存储采用副本机制，虽部分场景使用 EC 编码，但副本因稳定性更高而应用更普遍。采用缓存方案后，可实现单副本存储，成本降低 60%以上。
- 资源整合利用：在支持 CPU 训练时，GPU 机器通常挂载有 NVMe 盘，单机约有 10TB 左右空间。此前这些资源在业务场景中分散使用，利用率不高。现在，我们将分散的 NVMe 资源统一纳入缓存池，为就近的 GPU 训练和数据处理任务提供加速能力。
04 未来规划
面向未来，我们将重点围绕以下三个方向持续演进。
首先，持续提升统一文件存储基座的稳定性、性能和扩展性。随着 AI 业务快速发展，训练、推理和数据处理任务对存储系统的吞吐、时延和可靠性提出了更高要求。后续我们将继续优化底层架构和关键链路，提升系统在大规模并发访问场景下的服务能力。
其次，加强海量数据的生命周期管理。当前业务数据规模持续增长，但不同类型数据在存储层级、访问频率和保留周期上的管理仍有进一步优化空间。我们将结合数据冷热特征、业务访问模式和成本模型，优化分层存储、数据归档、预热和清理策略，降低单位存储成本，提升整体资源利用率。
最后，持续完善数据管理与分析能力。在统一文件存储基座之上，我们将进一步建设面向业务的数据管理能力，帮助用户更清晰地理解数据分布、访问行为和资源使用情况，为后续的数据治理、成本优化和业务决策提供支撑。
以上是小米在统一文件存储基座建设中的阶段性实践。我们也期待与业界同行持续交流，共同探索更多技术实践。
我们希望本文中的一些实践经验，能为正在面临类似问题的开发者提供参考，如果有其他疑问欢迎加入 JuiceFS 社区与大家共同交流。