弹性需求广泛存在，供给却难以匹配

随着 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 GroupFUSE 客户端所在节点也可以提供本地缓存用于提升重复读取和模型加载性能进一步降低对远端对象存储的直接访问。这个“对象存储加速”产品本质上是将 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 结语