K8s 平台支撑 AI 负载的缺口
推荐指数 57.0 NO. 026 · 2026.08.29
发布2026/08/28
为什么值得看
CNCF 指出多数 Kubernetes 平台虽能跑容器，但面对 AI 工作负载时在 GPU 调度、资源碎片化和训练推理混合部署上暴露短板。平台工程师需要重新评估现有集群架构，否则 AI 项目会卡在基础设施层。
编辑判断
真正的问题不是 K8s 能不能跑 AI，而是平台团队还在用管理微服务的思维管 GPU 集群。训练任务需要数小时独占整卡，推理服务要毫秒级弹性扩缩容，这两者的调度策略完全矛盾，传统 HPA/VPA 机制直接失效。
目前业内有两种解法：一是用 Volcano + Yunikorn 做 gang scheduling 把训练任务打包调度，二是用 vLLM 的 continuous batching 把推理 GPU 利用率拉到 90% 以上。但很少有团队把这两层打通。
如果你所在的公司正准备把 AI workload 搬上现有 K8s，建议先做一件事：统计过去 30 天 GPU 的实际利用率，多数团队会发现自己连 40% 都不到，这时候买更多卡不如先修调度层。
相关内容
K8s Is Not Enough for The Coming Fracture of AI & Data Infrastructure K8s 不足以应对 AI 与数据基础设施的分裂趋势，需要具备状态感知和上下文感知的新型编排层，以及更先进的硬件和网络抽象能力。 跑 AI 大模型的 K8s 与普通 K8s 有什么不同？ 对比 AI 场景下 K8s 的特殊需求，分析 HPA/VPA 弹性机制的局限，以及 AI 驱动的预测性扩缩容和故障预测技术架构。 Koordinator：K8s 资源调度优化项目 开源 K8s 调度优化方案，通过动态资源配额调整和智能负载调度，提升大规模容器环境的资源利用率与性能。 AI 赋能 K8s 运维：K8sGPT 让集群故障自动诊断 基于 AI 的 K8s 智能诊断工具，自动扫描集群异常并生成解决方案，支持多类 AI 后端和本地模型部署。