01 统一存储需求与建设思路四类场景四种 I/O 诉求第一类模型训练公司自研模型包括 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 | ❌ 锁定单云 | ✅ | ✅ | ✅ | 成本高运维较轻 | | 对象存储 FUSES3FS / GCS Fuse | ⚠️ 锁云 | ❌ | ❌ | ❌ | 成本低运维轻 | | 缓存编排层Alluxio / Fluid | ✅ | ✅ | ✅ | ✅ | 需叠加底层存储运维重 | | JuiceFS | ✅ 后端任选 | ✅ 完整 | ✅ | ✅ 内建 | 对象存储成本CSI 接入 |相比之下JuiceFS 同时满足了我们对云中立、完整 POSIX、内建分布式缓存和对象存储后端的核心要求而其他方案基本都会缺少其中一环。因此在离线场景下我们没有太多犹豫一开始就选定了 JuiceFS。Agent从 GCS Fuse 踩坑迁到 JuiceFS早期业务主要部署在 Google 云上使用 Google Cloud StorageGCS通过 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 美元。在 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 StorageGCS元数据层则在 GCP 私有 VPC 内部署独立的三节点 Raft 集群。这样可以让对象存储、元数据服务和业务 Pod 都留在同一云内降低访问延迟并提高小文件写密集场景下的 IOPS 表现。在 Kubernetes 层面我们通过 JuiceFS CSI 挂载同一个 RWX PVC不同 bot Pod 使用各自的 subPath 访问独立目录并通过 token 按环境限制访问范围实现文件系统级的数据隔离。对于每个 Agent 来说它看到的是自己的本地工作目录对于平台侧来说底层仍然是一套统一的存储系统便于统一管理和计费。如果未来 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 访问时需要跨公网请求链路中的元数据 RTTRound-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 的存储体系。对于一家海外初创公司而言灵活且运维简便的基础设施至关重要这有助于团队将精力集中在业务创新上。统一存储体系为上层业务和研发提供一致接口而底层资源可以根据场景灵活调度离线场景围绕算力成本实现动态漂移在线场景优先保证低延迟和高并发同时保留按需迁移能力。这样的设计既保持了上层体验的一致性又使算力成本可议价、资源可漂移为未来扩展到更多云和区域奠定了基础。