CNCF AI 工作负载资源与基础设施报告，平台团队应先核对哪些容量约束

AI 集群容量不应该从“还有多少张 GPU”开始问。CNCF 在 2026 年 11 月 6 日发布的《Resource And Infrastructure Challenges For AI Workloads》把问题拆成硬件拓扑、资源异构、GPU 共享、扩展、I/O 瓶颈、容错弹性和预算约束。对平台团队来说，最有用的结论是：先画出工作负载从数据到 GPU、再到恢复和成本的完整链路，再决定扩容还是改调度。

官方报告地址：https://www.cncf.io/reports/resource-and-infrastructure-challenges-for-ai-workloads/

先把报告变成一张资源关系图

报告列出的约束不是七个互不相干的采购指标。拓扑决定 GPU 之间怎么通信，异构性决定哪些任务能被放到哪些节点，共享策略影响排队和隔离，I/O 决定 GPU 是否吃得饱，容错与弹性决定一次失败要付出多少重跑成本，预算则把这些结果约束在可接受范围内。

因此，容量评估的对象应该是“任务完成能力”，而不是裸资源数量。比如同样的 GPU 数量，如果数据从远端存储读取、跨节点通信拥塞，或者失败后只能从头重跑，账面利用率并不能代表真实产出。

拓扑与异构 GPU：先确认任务能否稳定落位

第一轮核对先不改参数，记录任务需要的 GPU 类型、显存、互联方式、节点间带宽和放置约束。训练任务尤其要区分单节点通信与跨节点通信；推理任务则要把模型副本、请求路由和故障转移后的落位一起记录。

这一步的输出最好是一份按工作负载分组的落位表：哪些任务可以混部，哪些任务必须同节点，哪些任务只能使用特定 GPU。没有这张表，后面的扩容很可能只是把不匹配的资源继续堆起来。

把 I/O、恢复和成本落到可测指标

I/O 瓶颈经常隐藏在 GPU 利用率之外。要同时记录数据读取等待、存储吞吐、网络拥塞、检查点写入时间和恢复后的预热时间。长任务还要统计失败重跑率与一次重跑消耗的 GPU 小时；否则“偶尔失败”会在月度账单里变成持续的容量缺口。

建议把容量账本写成四列：资源信号、证据、风险、动作。资源信号是高排队、低有效吞吐或检查点过慢；证据是调度事件、通信指标、I/O 等待和恢复记录；风险是延迟、重跑或成本超限；动作才是调度调整、数据路径优化、检查点策略或扩容。

成本指标不要只看 GPU 使用率，至少补充单位有效吞吐成本、排队时间、失败重跑占比和扩缩容等待。报告讨论的是挑战地图，不是某个 Kubernetes 发行版的功能清单；平台团队仍需用自己的工作负载压测验证边界。

常见问题

CNCF 这份报告是否等于一套 Kubernetes 配置方案？

不是。它提供的是 AI 工作负载的资源与基础设施问题框架，具体调度器、存储和 GPU 共享实现仍要结合环境验证。

GPU 利用率很高，是否说明容量一定不够？

不一定。高利用率可能来自真正的算力饱和，也可能伴随 I/O 等待、排队或低效重试，必须结合有效吞吐和完成时间判断。

平台团队应该从哪一项开始核对？

先选成本最高或失败后最难恢复的一类任务，画出拓扑、数据、检查点和恢复链路，再用同一组指标比较调度、存储和扩容方案。