JuiceFS 多云 AI 存储全面最佳实践深度解析：42 倍小文件性能提升与 85% 吞吐增长

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

这篇文章就来聊聊星辰征途业务背后的存储实践，分享一下我们在统一存储选型、架构设计和性能调优中踩过的坑和积累的经验。目前，JuiceFS已经在生产环境稳定运行了一年多，管理的文件数超过1亿，业务横跨Oracle、DigitalOcean和GCP三朵云，成为了支撑模型训练、推理、数据处理和在线Agent的统一存储层。

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

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

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

第一类：模型训练
公司自研的模型，包括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语义和性能都不足；
• 缓存编排层：需要额外叠加底层存储，运维复杂。

相比之下，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美元。

在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来说，它看到的是自己的本地工作目录；对于平台侧来说，底层仍然是一套统一的存储系统，便于统一管理和计费。

如果未来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，无需跨节点拷贝。

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

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

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

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

06 小结

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

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