当前位置：首页 > 文章列表 > 科技周边 > 业界新闻 > CNCF 讨论 AI 平台的 CPU 与 GPU 协同时关注哪些运维问题

CNCF 讨论 AI 平台的 CPU 与 GPU 协同时关注哪些运维问题

来源：17golang原创 2026-09-07 01:51:46 0浏览收藏

AI 平台的运维重点正在从“有多少张 GPU”转向“CPU、GPU、内存、存储和网络能否协同完成一次请求”。CNCF 近期关于异构 AI 基础设施的讨论，给出的关键信号并不是又一个单独的 GPU 产品，而是要把整条工作负载链路纳入同一个云原生资源模型。

如果 GPU 利用率不高，先不要急着扩 GPU 或判定资源浪费。应先确认 CPU 预处理、模型加载、数据通道、调度等待和应用端延迟分别处于什么状态，再决定调度、扩容或观测动作。

要点速览

调度对象是完整流水线，GPU 只是推理环节。
扩缩容要结合队列、Token 吞吐和首 token 延迟，CPU 指标不能单独代表推理压力。
可观测性要把节点/容器资源与应用指标、日志、链路和成本关联起来。

调度先看完整工作负载，而不是只数 GPU

一条常见的推理链路可以拆成：数据进入后由 CPU 做预处理，模型从存储加载，GPU 执行推理，CPU 再做后处理，最后交给应用。任何一段供给不足，GPU 都可能处于等待状态。此时继续增加 GPU，吞吐未必提高，反而会扩大空闲的昂贵容量。

数据入口、CPU预处理、模型存储、GPU推理、CPU后处理和应用出口组成的异构资源链路 — 图1：把 AI 请求拆成完整资源链路后，GPU 只是其中一个环节。

因此资源申请应同时表达计算、内存、数据和拓扑约束。Kubernetes 传统 device plugin 能把 GPU 等设备作为可调度资源暴露给节点，但它更接近“某个容器要几个设备”的模型。官方文档中的 DRA 则通过 DeviceClass、ResourceClaim 和设备属性筛选，让工作负载以更声明式的方式申请设备，并支持设备共享等能力。实际采用时仍要确认驱动、节点拓扑和调度器版本是否匹配，不能只改 Pod 清单。

扩缩容和可观测性要围绕等待关系设计

普通 Web 服务常用 CPU 或请求数触发 HPA，但模型推理的瓶颈可能是排队、批处理、KV cache、模型加载或 GPU 节点冷启动。CNCF 的云原生 AI 工程讨论也把 Token 吞吐、首 token 延迟、队列深度和缓存命中率列为需要与基础设施指标并看的信号。

看到的信号	不能直接推出	更合适的下一步
GPU 利用率低	一定是需求不足	检查 CPU 供给、数据读取、调度等待和请求队列
CPU 利用率高	一定要增加 GPU	区分分词、检索、后处理是否成为流水线瓶颈
队列和首 token 延迟上升	只调高 Pod 副本数就够了	同时检查可分配设备、模型加载时间和节点容量
吞吐稳定但成本上升	资源已经达到最佳状态	按模型、租户和 GPU 秒数拆分成本与利用率

请求队列、Token吞吐、首token延迟驱动CPU GPU容量池扩缩容并回流遥测 — 图2：用应用指标解释资源利用率，才能区分需求不足、上游供给不足和调度等待。

落地时可以把扩容拆成两层：服务层根据队列、吞吐或延迟调整推理副本；容量层根据设备余量和节点准备时间预留或扩展 GPU 节点。缩容则要加冷却窗口，避免批处理和模型缓存刚建立就被回收。对于多租户平台，还要把 ResourceQuota、队列优先级和拓扑约束一起考虑，否则单个团队的突发请求会把共享容量变成隐性争抢。

监控指标要回答“谁在等谁”

建议用 OpenTelemetry 统一应用遥测，用 Prometheus 保存指标，并把 CPU/GPU 的节点级、容器级数据和请求级指标通过工作负载、模型、租户等标签关联。至少要能回答四个问题：请求是否在排队，CPU 是否喂不饱 GPU，模型是否卡在加载或缓存，GPU 是否因为设备故障或拓扑不匹配而不可调度。

指标不要只做大盘展示，还要和动作绑定。例如首 token 延迟升高且队列增长，优先检查服务副本和可用设备；GPU 利用率低但 CPU 预处理饱和，先扩 CPU 或调整流水线；节点有硬件异常，先隔离节点再让调度器继续放置新任务。CNCF 的相关实践还强调成本观测，因为“每秒 Token”只有和 GPU 秒数、延迟目标放在一起，才足以支持容量决策。