多租户与混合多云下的 AI 算力调度与存储优化实践
导语
随着 AI 基础设施的快速演进，算力架构正经历从单机房向跨机房、多云与混合云的深刻转型。在这一趋势下，企业内部的 AI 算力调度也从单集群孤岛迈向多集群联邦，大模型推理流量调度更是向异构算力感知与缓存亲和性方向深化。
然而，多租户与混合多云环境带来了算力分散、存储瓶颈及资源利用率低等严峻挑战。本文结合贝壳在 AI 基础设施领域的落地实践，探讨如何通过构建统一存储底座与统一资源池调度体系，打通数据流转壁垒，实施精细化调度，并优化大模型推理流量，最终实现基础设施的降本增效。
核心问题与挑战
在算力架构升级的过程中，我们面临以下核心痛点：
- 算力分散与组织壁垒：GPU 资源分布在不同机房、不同云环境，甚至受限于组织壁垒，导致管理困难，算力利用率低下，资源闲置与算力饥饿并存。
- 跨地域跨云数据流转慢：大模型训练数据集与模型文件体积庞大，跨区访问对象存储延迟高，严重拖慢训练与推理任务的启动速度。
- 异构 GPU 负载不均：同模型分布在不同机型上，GPU 卡的承载能力差异大，传统的公平调度策略会导致算力不均衡，低端卡积压，高端卡被过度抢占。
- 传统调度无法命中 KVCache：大模型多轮对话场景下，传统公平调度无法保证请求路由到具有历史上下文的实例，导致 KVCache 无法复用，首 Token 响应极慢。
方案与实践
针对上述挑战，我们从存储底座、算力调度和流量治理三个层面进行了体系化重构。
1. 统一存储底座：打破数据孤岛与流转瓶颈
为解决跨地域跨云数据访问慢的问题，我们基于 JuiceFS 与对象存储 KOS 构建了跨地域统一存储底座。
- JuiceFS 跨地域文件系统与多级缓存：利用 JuiceFS 的能力构建跨云多机房的数据缓存体系。通过元数据引擎的跨区同步架构，实现计算任务对远端数据的就近缓存加速读取。
- 对象存储 KOS 访问加速：KOS 引入 Proxy 协议代理层，结合一致性哈希与多级缓存机制，优先判断文件是否在本地缓存，有效降低跨区读取延迟，保障数据一致性。
- 镜像文件系统：实现跨区卷“一处写入，处处读取”。例如，用户在北京区创建普通卷并写入数据，该卷的元数据与数据可通过底座自动同步至其他区域，其他区域的计算任务挂载该卷时，自动接入本地元数据引擎与缓存，极大提高了数据流转效率。
2. 统一资源池调度：精细化运营提升算力利用率
无论 GPU 资源以何种形式交付，只要是以 Kubernetes 集群形式管理，就应纳入统一资源池。我们基于多集群联邦实现了算力的跨域调度。
- 多集群联邦与跨集群服务发现：借鉴开源方案（如 KubeVela 等）实现多集群工作负载分发与租户队列管理。通过 MCS API 实现跨集群服务发现，定义
ServiceExport将当前集群的服务暴露，并在联邦层面实现流量的就近访问。 - 精细化调度策略：
- 常驻+弹性与多粒度申请：保障核心业务常驻资源的同时，通过公有云弹性补充峰值需求。
- 资源出借与闲时复用：支持节点级别的资源出借。例如，节点每天 22 点到次日 8 点将 8C32G 4张 GPU 卡借给指定队列，实现物理资源在空闲时的最大化利用。
- 队列级调度：每个队列拥有独立调度策略，支持 binpack 或亲和性配置，结合超级节点与全局共享队列，实现真实基础设施下的高效调度。
3. 大模型流量调度：异构感知与缓存亲和
在模型服务层，传统的公平调度不再适用，我们引入了 AI 亲和的网关架构与多云负载均衡设计，针对流量现状进行深度治理。
- 异构算力错峰调度：同一模型在流量低峰期只保留部分高性能卡，当流量高峰期到来时，利用低端卡进行服务扩容。同时结合业务容忍度路由，将非实时请求导向低端算力，保障核心业务体验。
- 基于最小 Prefill 的均衡调度：在 GPU 资源异构存在差异的情况下，摒弃传统公平调度，采用全局队列与最小 Prefill 机制，将请求调度至当前计算负载最低的实例，实现真正的负载均衡。
- 缓存亲和性调度：针对多轮对话场景，流量调度层感知 KVCache 的局部性。尽可能将同一会话的后续请求路由至具有历史上下文的实例，复用 KVCache，有效提高 GPU 吞吐并大幅提升首 Token 速度。
原则/方法论沉淀
在多租户算力调度与存储优化的实践中，我们沉淀出以下核心原则：
- 统一底座：存储与算力调度均需建立跨云跨地域的统一抽象，消除数据孤岛与资源孤岛，这是全局优化的前提。
- 精细化调度：必须按租户、队列、卡型粒度进行资源分配与出借，粗放的公平调度在异构与多租户场景下必然失效。
- 成本驱动：降本的核心在于闲置资源复用（如闲时出借）与公有云弹性削峰，让每一张卡都在创造价值。
- 数据亲和：数据缓存与流量调度必须感知计算局部性（如 KVCache 亲和与就近访问），将计算推向数据，而非反之。
总结与行动建议
从存储底座的跨区加速，到算力资源的联邦调度与精细化出借，再到推理流量的异构与缓存亲和治理，三层架构协同发力，构成了多租户 AI 基础设施降本增效的完整闭环。
对于正在或即将面临多云多租户算力治理的工程团队，建议采取以下行动：
- 优先建设统一存储底座：数据流转的效率直接决定了算力调度的上限，优先解决跨区数据访问瓶颈。
- 打破集群边界，拥抱联邦调度：将分散的 Kubernetes 集群纳入统一资源池管理，为精细化运营提供全局视角。
- 重构推理网关，引入算力感知：在流量入口处实现异构算力与 KVCache 亲和性调度，这是提升大模型服务质量的捷径。
开放问题与延伸方向
- 跨区 JuiceFS 元数据同步的具体延迟指标与在极端网络分区下的数据一致性保障机制是怎样的？（关联统一存储底座，关注跨区架构的容灾底线）
- 多租户资源出借机制下，租户是否会因担心被抢占而产生资源囤积的隐性焦虑？（关联精细化调度，涉及运营策略与租户心理博弈）
- 闲时复用任务若未能在高峰期前及时退出，系统有何熔断机制以避免抢占影响核心业务？（关联资源出借策略，需关注调度安全兜底）
- KVCache 亲和性调度在面对长上下文或模型高频更新场景时，是否会导致缓存频繁失效反而增加开销？（关联流量调度，探讨缓存策略的适用边界）
- 统一存储底座在实现跨区加速之外，是否为模型版本灰度发布与多团队数据集共享复用带来了额外收益？（关联存储底座，挖掘基础设施的衍生价值）
- 基于最小 Prefill 的均衡调度在降低首 Token 延迟和提升用户体感方面，其实际收益表现如何？（关联流量调度，需量化验证调度算法收益）
- 能否将异构算力调度与 Serverless 弹性推理结合，实现基于流量预测的冷热实例自动伸缩？（关联异构调度，探索极致弹性的演进方向）
- 除了 KVCache 局部性，流量调度是否可以引入成本感知，将非实时请求路由至低碳或低价算力节点？（关联流量调度，拓展多维度的调度优化目标）
- 在存储、算力、流量三层统一架构的演进中，当前制约整体降本增效的最核心瓶颈在哪一层？（关联全局架构，反思下一步优化的优先级）
- 如何构建一套兼顾资源利用率与业务 SLA 的量化评估体系，以持续验证多租户精细化调度的 ROI？（关联方法论，呼吁建立可量化的持续评估机制）