摘要

  • 甲骨文 zettascale 集群网络宣称最多支持 131,072 块 GPU，但同一套文档写明实例供给受 RDMA 网络可用主机容量限制，并专门提供容量预检接口（容量预检说明）。
  • “最大规模”随 GPU 代际变化：A100 手册为 32,768 块，zettascale 博客为 131,072 块；三层 Clos 拓扑对应约 2 微秒、5 微秒、8 微秒的分层单向时延（架构说明）。
  • 默认租户限额为 15 个集群网络、每实例池 500 个实例，且集群网络仅限部分区域与可用域（服务限额），声明规模并不等于可调度规模。

一套按 GPU 代际分层的“最大规模”

甲骨文公开的集群规模数字并非单一常量，而是随加速器代际变化。面向 A100 的解决方案手册描述的是“最多 4,096 台裸金属节点、每节点 8 块 GPU，即 32,768 块 GPU”（方案手册）；而 zettascale 集群网络的架构博客给出的是 131,072 块 GPU、每 GPU 400 Gbps 无阻塞带宽、三层 Clos 拓扑，以及第一层最多 256 块 GPU（约 2 微秒单向时延）、第二层最多 2,048 块 GPU（约 5 微秒）、第三层最多 131,072 块 GPU（约 8 微秒）的分层时延结构（架构博客）。这一分层本身就是一个信息：集群越大，GPU 之间最远路径的通信时延越高。训练任务的并行策略必须容忍这一梯度，而这决定了“最大集群”与“最优集群”并非同一个数。

甲骨文的集群网络定义是：一组通过高带宽、超低时延 RDMA 网络连接的同类 HPC、GPU 或优化型裸金属实例，节点间时延“低至个位数微秒”，与本地 HPC 集群相当（集群网络概念）。文档列出的受支持机型有限——BM.GPU.A100-v2.8、BM.GPU.H100.8、BM.GPU4.8、BM.HPC2.36 与 BM.Optimized3.36——并明确创建多个 HPC、GPU 或优化型实例通常需要申请服务限额提升（高性能计算机型）。

声明规模不等于可调度规模

甲骨文自己的运维文档写得比市场口径更谨慎。创建集群网络时，“实例会被持续供给，直到实例池达到所需数量，但受集群 RDMA 网络中节点的可用主机容量限制”（创建集群网络）。文档还专门提供 CreateComputeCapacityReport 接口，让客户在创建集群网络之前先查某个机型是否有可用容量。换言之，甲骨文的接口设计本身就承认：请求的集群规模不会自动变成可调度的集群规模。

  • 默认服务限额中，集群网络为每租户 15 个，实例池实例上限为 500；控制台中显示的值代表该租户当前签约的额度，并非可无限申请的架构上限（服务限额）。
  • 集群网络仅支持部分区域与可用域，且要求该可用域的硬件支持该功能。
  • 资源调整同样“受集群 RDMA 网络节点可用主机容量限制”，因此扩容失败是文档明确预期的情形。

这也解释了为什么甲骨文没有公开某个“已交付满配 131,072 GPU 单集群”的可核实证据。可获得的是容量上限声明加上聚合交付披露：财年 Q1 FY27 季度交付 850 兆瓦 AI 数据中心容量、单季向 AI 云客户交付超过 30 万块 GPU，同时管理层表示 AI 需求“增长快于供给”（季度业绩）。这些数字描述的是总量，不是单集群的调度边界。

读者应当据此追问的三件事

第一，单集群的可调度规模究竟由什么决定——是 RDMA 网络的主机容量，还是 GPU 内存结构的域边界，抑或电力与许可？文档把集群网络与计算集群列为两个独立产品（后者还支持 GPU 内存集群），但没有公开单一数字的最大可调度集群。第二，分层时延如何在训练任务上体现：2 微秒、5 微秒、8 微秒是网络层的单向参考值，不等于端到端训练步时间，但会改变通信密集任务的扩展效率。第三，也是最具操作性的：当采购决策依赖“最大规模”时，供应商的架构博客与运维文档给出的上限并不是同一个数。

待核实之处：甲骨文未公开某个完整配置、同时在线的 131,072 GPU 单集群的交付证据；上述时延与带宽数字来自甲骨文自身的架构披露，尚未见独立的第三方测量；集群网络的默认限额可申请提升，因此“15 个集群网络、500 实例”描述的是默认配置而非硬性上限。

来源