共绩科技 2023 年成立于清华，面向 AIGC 企业和科研机构提供算力平台与 MaaS 服务，致力于缓解弹性算力需求与供给之间的错配。平台通过聚合 IDC 闲置资源和边缘资源，以容器化服务为主，为 AI 推理、视频渲染、数据处理和数据合成等波动性场景提供可快速调度的算力资源。
在跨云弹性推理场景中，计算任务可以调度到不同地域、云环境和集群，但模型文件和业务数据体积较大，难以像计算资源一样快速迁移。尤其是在线推理场景，模型仓库以读为主且访问频繁，存储访问能力会直接影响服务启动、弹性扩容和请求延迟。
为此，共绩科技基于 JuiceFS 封装了“对象存储加速”方案，将用户已有对象存储接入弹性推理集群，并通过统一命名空间、元数据导入、FUSE 挂载、分布式缓存和数据预热，提升模型仓库在跨云、跨集群环境中的访问效率。以一家头部文生图模型社区实践为例，该方案支撑了几十 TB 级模型仓库、checkpoint 与 LoRA 动态加载，以及高峰期数百卡弹性资源扩容，并将弹性集群的额外延迟控制在客户验收范围内。
01 弹性需求广泛存在，供给却难以匹配
随着 AI 应用快速发展，算力需求持续增长，但不同场景的资源使用特征并不相同。相比训练任务相对稳定的资源需求，AI 推理、数据处理和数据合成等场景通常具有更强的波动性：办公类应用可能在白天流量更高，娱乐类应用可能在傍晚或周末迎来高峰；项目制的数据处理任务则可能在短时间内集中消耗大量算力，任务结束后又进入空窗期。对于中小团队或探索型业务而言，弹性算力还能帮助其更清晰地评估单次请求成本与商业收益之间的关系。
但在供给侧，算力基础设施建设属于重资产投入。资源方通常并非不具备弹性服务能力，而是更倾向于通过长期整租回收成本、降低风险。这使得市场上低价、稳定、弹性三者难以同时满足：整租资源价格较低且供应稳定，但缺乏弹性；Spot 资源价格低且具备弹性，但供应不确定；On-demand 资源弹性和稳定性较好，但成本较高。在中国市场，这种矛盾进一步表现为交易主要集中在整租订单，弹性资源供给占比较低。
共绩科技希望解决的，正是弹性算力需求与供给之间的错配问题。通过聚合 IDC 闲置资源及更分散的边缘资源，平台以容器化服务为主，为 AI 推理、视频渲染、数据处理和数据合成等场景提供可快速调度的算力资源，在较低资源成本基础上，帮助用户在业务高峰时快速拉起任务、调度至不同集群并承接弹性需求。资源方也可以在整租之外，提高闲置资源的利用率和变现效率。
02 算力可以调度，存储如何跟上？
随着弹性算力平台的发展，计算资源的调度相对容易实现。容器镜像可以通过镜像仓库和分发网络同步到不同集群，计算任务可以由调度系统在不同资源池中拉起，业务流量也可以通过统一接入层和流量治理能力进行分发。
但模型和数据文件通常体积较大，跨云、跨集群迁移成本高、耗时长，难以匹配计算资源秒级拉起和释放的节奏。因此，在跨云弹性推理架构中，真正限制系统弹性的往往不是算力调度，而是数据和模型的分发效率。
不同业务场景对存储的要求并不相同。第一类是模型训练、开发和调试场景。这类场景通常涉及复杂的读写需求，包括代码仓库、模型文件、实验结果和中间状态等。同时，开发调试对环境稳定性要求很高，用户无法接受主机频繁切换导致状态丢失。因此，在这类场景中，平台通常会为用户提供长期稳定的计算资源和运行环境，相关存储需求也可以通过集群内已有的稳定存储体系来承载。
第二类是数据处理场景。这类业务又可以分为两种情况：如果单次数据处理的业务价值较高，能够覆盖跨云网络传输成本，就可以直接构建数据处理流水线，从 S3 或其他对象存储持续拉取数据，在计算集群内处理后再流式写回。此时系统不必依赖大规模本地存储。如果数据规模更大，或者单次处理的经济价值较低，本地存储更多也只是一次性缓存，数据在处理流程中流过即可，并不需要长期沉淀在计算集群内。
真正更具挑战的是在线推理场景。在线推理业务不能接受服务中断，但弹性算力平台所使用的资源可能来自闲置资源池，存在被撤出的可能。一旦某个机房或集群资源不可用，平台必须能够及时将任务迁移到其他供应商或其他集群。这意味着不仅计算任务要能够迁移，模型文件和相关存储访问能力也必须能够同步迁移。
在线推理虽然对服务连续性和跨集群迁移能力要求更高，但它的存储访问模式也相对更明确。与训练、开发和调试场景相比，推理业务通常以读为主，核心需求集中在高效加载模型、读取模型权重和访问模型仓库上。对于大型模型和在线应用而言，模型加载速度直接影响服务启动时间、弹性扩容效率和请求响应稳定性。因此，推理场景并不适合简单沿用传统读写混合型存储架构，而更适合围绕模型分发、只读访问和缓存加速进行专门优化。
此外，弹性算力平台通常并不承载用户完整的业务系统。用户的主云账号、业务数据库、模型管理系统，甚至部分固定算力资源，往往已经存在于其他云或自有环境中。平台要接入用户业务，就必须与其现有模型仓库和模型管理流程兼容，不能要求用户重新迁移整套系统。
因此，要支撑跨云弹性推理，需要的不只是计算调度能力，而是一套面向模型推理场景的跨云高性能存储与模型分发方案：既要支持大模型仓库的托管和高性能读取，又要适配用户已有的模型管理体系，并能够在资源跨云、跨集群迁移时提供稳定的数据访问能力。
03 Why JuiceFS：跨云统一访问、强一致元数据与高性能缓存
面对跨云弹性推理场景，存储系统需要同时满足几个条件：
- 能够在不同云和不同集群之间提供统一访问入口，支持共享读写和统一元数据管理；
- 能够兼容用户已有的对象存储和模型仓库，避免用户迁移现有数据；
- 同时还要具备较低的运维复杂度和较好的读性能。
在存储方案选型过程中，我们曾评估过 Ceph。Ceph 技术成熟，适合在单一数据中心或相对稳定的资源域内构建统一存储。但在跨云弹性推理场景下，Ceph 对网络稳定性和运维能力要求较高，整体接入成本相对更高，因此没有作为最终方案。
Alluxio 也曾进入评估范围。但在多云环境下，多个集群需要并发访问同一份底层对象存储数据，且业务并非完全只读，也存在少量写入。该场景对数据强一致性要求较高，因此 Alluxio 最终未作为生产方案。
最终选择 JuiceFS，主要是因为它以对象存储作为数据底座，并通过独立元数据服务提供统一命名空间和一致的文件系统视图，能够让多个集群以文件系统方式访问同一份模型数据。这种架构既适合跨云、跨集群的模型分发和共享读取，也能够较好兼容用户已有的对象存储和模型仓库，降低数据迁移和业务接入成本。
进一步采用 JuiceFS 企业版，则主要看重其分布式缓存能力和元数据托管能力。在这个场景中，JuiceFS 的价值并不只是提供一个文件系统接口，而是把对象存储、统一命名空间、元数据管理和缓存加速组合成一套更适合跨云弹性推理的存储访问层。
04 实践方案：基于JuiceFS 的对象存储加速
基于 JuiceFS，平台封装了“对象存储加速”产品，用于将用户已有的对象存储接入弹性推理集群，并以高性能文件系统的形式提供给业务使用。整体流程如下。
首先是创建文件系统。用户提供对象存储的访问凭证，例如 S3 兼容存储的 AK/SK。凭证权限可以根据业务需求配置为只读或读写，平台基于该对象存储创建对应的 JuiceFS 文件系统。
其次是导入元数据。平台通过 JuiceFS import 能力扫描对象存储中的文件元数据，并将其导入 JuiceFS 元数据服务。这样，用户原本存放在对象存储中的模型文件，就可以在 JuiceFS 中以文件系统目录的形式被访问。
第三是建立缓存组。在可能承载任务的各个集群内，平台会建立 JuiceFS Cache Group，形成分布式缓存组。任务运行前，平台可以先对模型文件进行数据预热，将热点数据提前缓存到目标集群，减少推理服务启动时从远端对象存储拉取数据的耗时。
第四是挂载到业务 Pod。用户业务运行时，平台通过 FUSE 客户端将 JuiceFS 文件系统挂载到业务 Pod 中。对于应用而言，模型文件表现为本地文件系统路径，因此通常不需要改造原有的模型读取逻辑。
第五是启用节点缓存。除了集群级 Cache Group，FUSE 客户端所在节点也可以提供本地缓存，用于提升重复读取和模型加载性能，进一步降低对远端对象存储的直接访问。
这个“对象存储加速”产品，本质上是将 JuiceFS 的元数据导入、分布式缓存、数据预热和 FUSE 挂载流程产品化，使用户已有的对象存储能够以更接近本地文件系统的方式服务于跨云推理任务。
此外，JuiceFS 的 Cache Group 与文件系统访问入口相对独立。这个特性一方面会增加平台侧的管理复杂度，因为平台需要同时管理文件系统、缓存组、挂载入口和任务调度之间的关系；另一方面，也为后续按集群、按用户或按业务场景进行缓存隔离、独立调度和精细化管理提供了基础。
05 业务实战：头部文生图模型社区
场景、挑战与验收标准
在这套对象存储加速方案中，一个比较典型的实践案例来自国内头部文生图模型社区，其托管了几十 TB 规模的模型数据，既包括体积较大的 checkpoint 基座模型，也包括数量更多、体积相对较小的 LoRA 模型。在实际推理过程中，业务通常需要先加载 checkpoint，再加载一个或多个 LoRA，完成组合推理。
该公司自身已经拥有较大规模的算力资源，规模达到数千卡级别。但由于其面向创意设计等生产场景，业务负载具有明显波动性，整体平均利用率不到 50%。在工作日的上午和下午高峰时段，负载甚至可能达到常规承载水位的 140%，导致服务体验下降。因此，客户需要一种高度弹性的算力供给方式。
共绩为其提供的是一种高弹性的资源模式：仅在工作日高峰时段，即上午 10:00–12:00 和下午 14:00–18:00，提供数百卡规模的算力支持，其余时间资源规模降为 0。
这意味着平台需要在分钟级时间窗口内完成数百卡资源的快速扩容，而在非高峰时段完全不占用资源。对客户而言，这种模式可以在峰值时段获得大量算力支持，同时避免为低谷资源付费；对平台而言，也可以更高效地利用闲置算力资源，具备较好的商业价值。
但这一场景的技术挑战也非常突出。首先，这类几十 TB 级模型仓库无法简单复制到每一个弹性集群。其次，推理服务并不是在启动时一次性加载全部模型，而是会随着用户请求持续发生模型读取和切换，访问频率较高。这意味着对象存储加速方案不仅要支持大规模模型仓库访问，还要在持续动态加载场景下保持稳定的读取性能。
与此同时，该公司对性能要求非常严格。在验收过程中，会将部分生产流量引入弹性集群进行测试，并要求弹性集群与其自有集群相比，推理耗时的中位数和平均值差异都必须控制在 2 秒以内。考虑到单次推理耗时本身在几十秒量级，这一要求意味着对象存储加速方案几乎不能引入额外延迟。在最初几轮测试中，弹性集群的推理耗时中位数和平均值均比客户自有集群高出约 10 秒，未能通过验收。
性能优化：降低弹性集群的额外延迟
优化首先从中位数入手。中位数偏高意味着有相当比例的请求都存在性能损耗，而不是少量偶发请求造成的长尾问题。通过 JuiceFS 监控发现，集群缓存命中率没有达到预期。在当前架构下，一旦缓存未命中，请求就需要跨公网访问客户在阿里云上的对象存储进行回源，这会显著拉高模型加载耗时，并进一步影响推理请求延迟。
针对这一问题，平台利用 JuiceFS Cache Group 的隔离能力，为该客户分配专属缓存节点，并预留充足缓存空间，对核心模型数据进行充分预热。完成预热后，核心模型访问路径基本实现 100% 缓存命中，有效避免了跨公网回源带来的性能损失。
第二个影响中位数的因素是元数据访问延迟。由于平台采用跨集群统一架构，元数据服务需要通过公网访问，例如使用 JuiceFS 云服务或部署在其他云主机上，因此元数据访问延迟会影响整体模型读取性能。
针对这一问题，平台采取了两项措施：一是开启 JuiceFS 的 open cache，将元数据尽可能缓存到本地内存中。由于该场景以只读访问为主，适合通过缓存降低元数据访问开销。二是优化集群网络限流策略。尽管平台无法直接控制边缘机房的网络设备，但可以通过节点级限流，避免单个节点占满带宽，从而提升整体网络稳定性。完成这些优化后，集群整体性能明显提升，中位数逐步达到客户要求。
当中位数达标后，平均值仍然存在偏差。这说明系统中仍存在长尾请求，即少量请求耗时显著高于正常水平，并拉高了整体平均值。进一步分析发现，这主要与节点本地缓存，也就是 FUSE 缓存配额有关。由于缓存容量较小，相比客户自有集群，弹性集群更容易发生缓存换出，导致部分请求需要重新加载模型数据，从而拉高平均推理耗时。针对这一问题，平台在生产环境中扩大了 FUSE 本地缓存配额，降低缓存换出频率，改善长尾表现，最终使平均值指标也满足验收要求。经过上述优化，系统顺利通过验收，并稳定运行。
多租户缓存治理
场景验证通过后，这套能力也进一步进入多租户运行阶段。随着不同租户按时间片复用同一批弹性节点，新的问题开始暴露出来，即节点缓存竞争问题。
在弹性资源模型下，FUSE 客户端退出时不会主动清理节点缓存。这个设计在单租户场景下是合理的，因为历史缓存可以被后续任务复用，从而提高命中率。但在多租户场景下，前一个租户的数据可能长期占用节点缓存空间，使后续租户无法获得足够缓存资源，最终不得不回源访问对象存储，导致性能明显下降。
为了解决这一问题，共绩在每个节点上部署了独立的守护进程，由该进程在业务 FUSE 客户端启动前执行全局缓存垃圾回收。具体策略参考 JuiceFS FUSE 客户端的实现，采用 2-random 策略，在回收效率和性能之间取得平衡。同时，各节点之间通过 Kubernetes 分布式锁进行协调，只有抢到锁的客户端才执行 GC，避免多个客户端同时回收缓存，从而造成额外的网络和 I/O 压力。
通过这一机制，我们有效缓解了多租户场景下缓存资源被历史任务占用的问题，使不同租户在共享弹性资源时，仍然能够获得相对稳定的缓存性能。
06 结语
弹性算力要稳定承接生产流量，不能只依赖计算调度，还需要模型数据和热点数据在跨云、跨集群环境中保持稳定访问。
基于 JuiceFS，共绩科技将对象存储、统一命名空间、元数据管理、分布式缓存和 FUSE 挂载能力组合起来，形成了一套面向弹性推理场景的对象存储加速方案。它并不是简单地把对象存储挂载成文件系统，而是围绕模型推理的访问模式，提供可预热、可缓存、可隔离、可治理的数据访问层。
以上是共绩科技在弹性算力与跨云存储加速方向上的阶段性探索和实践。随着 AI 推理场景持续演进，模型分发、缓存治理和多集群数据访问仍会不断出现新的工程问题。我们也希望与更多开发者、AI 应用团队和基础设施从业者交流，共同探讨弹性算力场景下更稳定、更高效的数据访问方案。
