文章提到腾讯基于 KubeRay 联邦实现跨集群调度，但未展开联邦架构本身。KubeRay Federation 是一个开源方案，由小红书工程师向社区提交（kuberay#4561），其核心是让多个 K8s 集群共享一个 Ray 集群，仅一个集群运行 GCS，其余作为 Worker 加入。这与字节跳动百万节点的 K8s 集群联邦（控制面单元化）不同：KubeRay 联邦更轻量，专为 AI 工作负载设计，不涉及跨集群应用编排，而是专注算力池的统一。

文章提到 Ray 的 Single-Controller 统一编排任务流，但没提一个关键局限：Ray 的全局控制存储 GCS 目前是单点故障，运行在 Head Node 上。GCS 集中管理所有系统状态（对象表、函数表、事件日志），虽然这让调度器、对象存储等组件可以无状态化以简化故障恢复，但一旦 Head Node 宕机，整个 Ray 集群无法恢复。腾讯在万卡实践中通过 KubeRay 联邦+自动化容灾机制缓解了这一问题，但 GCS 单点仍是 Ray 架构的固有硬伤。

文章聚焦 K8s+Ray 的调度层，但万卡集群真正卡脖子的往往是网络。腾讯星脉网络通过多轨道架构、TiTa 协议和 GOR 全局路由控制器，将 0.1% 的丢包对算力的损失控制在 50% 以内，使集群通信效率达 90% 以上。星脉提供 3.2T 通信带宽，提升 40% GPU 利用率，是腾讯万卡调度的网络前提。调度层的弹性伸缩与容灾，依赖网络层的零丢包、低延迟保障——否则再好的调度策略也无法高效执行。

文章强调 Ray 的进程级调度如何灵活，但在 AI 训练场景中，另一条技术路线——Volcano 调度器——通过 Gang Scheduling（成组调度）解决容器死锁问题。K8s 原生调度器依次调度 Pod，在资源不足时导致部分容器运行、部分挂起，造成资源浪费。Volcano 要求同一 Job 的 Pod 要么全部成功调度，要么全部不调度，避免了“竹篮打水”。两种方案并不互斥：Ray 在进程级做细粒度编排，Volcano 在 Pod 级做批量准入，各有适用场景。

KubeRay Federation 的方案由小红书工程师提出并贡献给社区，腾讯也基于它构建了万卡集群。但跨集群联邦在 K8s 生态中已有 Karmada、Federation v2 等成熟方案，KubeRay 联邦是否值得另起一套？关键变量在于：当 AI 集群规模从万卡走向十万卡，单一 Ray 集群的 GCS 单点压力是否可接受？如果 Ray 社区未来解决 GCS 高可用，KubeRay 联邦还会被需要吗？这些问题的答案将决定这条技术路线的生命周期。