AI算力真正的瓶颈：工作流执行效率

AI 行业在过去几年里一直在讨论一个占据主导地位的基础设施问题：

算力不够。

企业争相 확보 GPU。云服务商不断扩充容量。各国政府出资建设新的数据中心。创业公司则在争夺额度、预留资源，以及最新加速器的使用权。

但这种围绕“短缺”的叙事掩盖了另一个问题。

我们已经拥有的算力中，有相当一部分并未得到有效利用。

Gartner 预测，2026 年全球 AI 支出将达到 2.59 万亿美元，同比增长 47%。Goldman Sachs 的基准模型则单独估算，2026 年 AI 年度资本支出约为 7650 亿美元。

这是一场规模空前的基础设施建设浪潮。

然而，购买更多 GPU，并不会自动带来更多有价值的 AI 工作成果。

只有当正确的工作负载被分配到正确的硬件上，能够成功启动、持续健康运行、产出预期结果，并且成本合理时，算力才能创造价值。

而这条执行链路依然脆弱得惊人。

5% 的利用率数据值得关注，也需要结合背景理解

CAST AI 的《2026 年 Kubernetes 优化状况报告》测量了数万个未经优化的生产级 Kubernetes 集群中的 GPU 利用率，这些集群运行在 AWS、Microsoft Azure 和 Google Cloud 上。

在所分析的集群中，GPU 平均利用率仅为 5%。

CAST AI 指出，在这样的利用率水平下，组织所拥有的 GPU 容量，大约是其工作负载在特定时刻实际消耗量的 20 倍。

这个结果令人震惊，但必须谨慎解读。

它并不意味着全球购买的每一块 GPU 中，都有 95% 被永久浪费。该测量针对的是一类特定的、未经优化的 Kubernetes 环境。有些未使用容量也可能是组织为了应对流量峰值、满足可靠性要求或处理调度约束，而有意预留的余量。

尽管如此，这一结果仍然揭示了一个重要事实：

已配置的算力和真正产生价值的算力，并不是一回事。

一家组织可能在技术上拥有大量 GPU 容量，却依然难以高效执行工作负载。

问题并不只是硬件是否可用，还在于围绕这些硬件的软件和运维体系。

算力浪费发生在多个层面

当人们听到“闲置 GPU”时，往往会想象一台完全无事可做的服务器。

但在实际场景中，AI 算力的低效要复杂得多。浪费会出现在工作负载生命周期的多个阶段。

1. 资源配置浪费

团队预留的容量经常超过应用实际消耗的容量。

之所以会出现这种情况，是因为基础设施的配置通常依据申请的资源量、预期峰值或宽泛的硬件类别，而不是工作负载实际表现出来的行为。

一个推理服务可能需要大量 GPU 显存，却只需要较少的持续计算能力。一个批处理工作负载可能会在高强度 GPU 处理和受 CPU 限制的数据准备之间交替运行。一个训练任务可能申请多个加速器，却无法均衡地使用它们。

硬件虽然已经分配出去，但其中的各个组件并不一定得到充分利用。

2. 工作负载配置浪费

即使任务已经被分配到 GPU 上，也可能无法高效使用这块 GPU。

Microsoft Research 在 2024 年的一项研究中，调查了 400 个平均 GPU 利用率不超过 50% 的工业级深度学习任务。研究人员共发现了 706 个独立的低利用率问题。

其中约 46% 与数据操作有关，约 45% 与深度学习模型有关。研究人员发现，GPU 利用率偏低通常源于 GPU 计算量不足，或系统其他位置执行的工作打断了 GPU 计算。

更关键的是，他们得出结论：大约 85% 的已识别问题，只需少量修改代码或脚本就能解决。

这意味着，低利用率并不总是不可避免的硬件限制。

数据加载效率低下；

batch size 设置不当；

同步操作过多；

模型配置与所选硬件不匹配；

存储或网络传输速度缓慢；

某些工作负载本就不应该独占一整块加速器。

GPU 可能处于活跃状态，但仍然没有得到高效利用。

最明显的一类算力浪费，是工作负载开始运行、持续消耗资源，最终却执行失败。

Microsoft 的研究人员此前调查过某个内部生产平台上的 4960 个失败深度学习任务。他们发现，48% 的失败发生在任务与平台的交互过程中，而不是核心程序逻辑中。

其中许多问题都与本地开发环境和任务最终执行环境之间的差异有关。

这种区别非常重要。

开发者的模型代码可能完全正确，却仍然会因为以下问题浪费算力：

不兼容的 runtime；

无效的容器 entrypoint；

错误的存储权限；

GPU 显存不足；

不受支持的加速器架构；

格式错误的环境变量；

特定云服务商的配置不匹配。

如果这些问题直到资源配置开始后才被发现，组织就需要付费来发现一个原本可能在执行前就能捕获的错误。

还有一类浪费不会直接体现在云服务账单上。

它体现在工程师耗费的时间里。

AI 团队经常要花费数小时，在不同云服务商的控制台之间切换、比较 GPU 类型、检查配额、查找日志、下载 artifacts、重启失败任务，并试图判断故障究竟来自自己的代码，还是来自基础设施。

一个导致 20 美元算力损失的失败工作负载，还可能额外消耗一位高薪工程师数小时的时间。

当团队同时使用多个云服务商时，这种运维负担会变得更加严重。每个平台都有自己的术语、API、容量行为、认证模型、日志、存储约定和故障状态。

最终形成的是一套碎片化的执行流程，只能依靠脚本、dashboard 和组织内部积累的经验勉强维系。

为什么增加更多 GPU 无法解决这个问题

面对容量压力，最自然的反应就是增加供给。

我们确实需要更多 GPU。AI 需求正在快速增长，许多组织也确实面临容量限制。

但仅仅增加供给，并不能解决工作负载放置不当、执行失败、配置低效、可观测性碎片化或预留资源闲置等问题。

如果没有更好的执行基础设施，增加容量可能只会让更多基础设施遭到错误分配。

因此，整个行业需要换一个问题来问。

我们可以从哪里获得更多算力？

我们该如何确保每个工作负载都能获得合适的算力，并成功将其转化为有价值的输出？

这是一个编排与执行问题。

AI 基础设施中缺失的抽象层

应用开发者通常不希望成为每种 GPU、每家云服务商、每个调度器、每种容器 runtime 和每个区域容量市场的专家。

他们只想描述一个工作负载，然后获得可预测的结果。

一个更强大的执行层应当能够：

在提交前理解工作负载：在配置昂贵的基础设施之前，检查资源需求、容器配置、runtime 限制、存储需求和预期输出。

在提交前理解工作负载：在配置昂贵的基础设施之前，检查资源需求、容器配置、runtime 限制、存储需求和预期输出。

将工作负载匹配到合适的算力：并非每个 AI 工作负载都需要速度最快或价格最高的 GPU。正确的选择取决于显存、架构兼容性、延迟、运行时长、可用性和成本。

将工作负载匹配到合适的算力：并非每个 AI 工作负载都需要速度最快或价格最高的 GPU。正确的选择取决于显存、架构兼容性、延迟、运行时长、可用性和成本。

将执行与单个云服务商解耦：开发者不应因为容量从一家云服务商转移到另一家，就必须重新构建整套运维工作流。

将执行与单个云服务商解耦：开发者不应因为容量从一家云服务商转移到另一家，就必须重新构建整套运维工作流。

让故障状态易于理解：日志、状态变更、重试、取消操作和 artifacts，都应该通过一致的界面对外提供。

让故障状态易于理解：日志、状态变更、重试、取消操作和 artifacts，都应该通过一致的界面对外提供。

保留执行历史：一个任务应该拥有持久化记录，展示它申请了什么、在哪里运行、使用了哪些资源、为什么失败或成功，以及最终产出了什么。

保留执行历史：一个任务应该拥有持久化记录，展示它申请了什么、在哪里运行、使用了哪些资源、为什么失败或成功，以及最终产出了什么。

在正式投入前进行估算：团队在启动工作负载之前，应该了解可能产生的成本，以及是否存在合适的可用容量。

在正式投入前进行估算：团队在启动工作负载之前，应该了解可能产生的成本，以及是否存在合适的可用容量。

这无法消除所有故障，也不能保证实现完美的利用率。

但它确实能让重要决策提前到执行生命周期的更早阶段，在这些决策变得昂贵之前完成。

从基础设施访问转向执行智能

第一代 AI 基础设施关注的是访问。

开发者能否获得一块 GPU？

下一代基础设施必须关注执行智能。

应该使用哪种 GPU？工作负载是否与它兼容？是否存在更便宜且同样合适的选择？容量是否真的可用？任务能否从故障中恢复？它的输出是否可验证？执行过程能否在不同云服务商之间迁移，而无须开发者重新设计工作流？

这些正在成为基础设施领域的核心问题。

在 Jungle Grid，这正是我们正在解决的问题。

我们正在构建一个执行层，让 AI 工作负载能够通过它完成提交、筛选、路由到可用算力、监控、重试，并最终以一致的日志和 artifacts 形式返回结果。

目标并不只是开放更多 GPU。

而是让异构算力像可靠的执行基础设施一样运作。

这种区别非常重要，因为 AI 的未来不会建立在单一云服务商、单一 GPU 类型或单一部署模式之上。

工作负载将越来越多地在 hyperscaler、专业 GPU 云、区域云服务商、私有集群和分布式基础设施之间流动。

最终胜出的抽象层不会是云服务商的 dashboard。

而是那个决定工作负载如何在所有这些平台之间流动的执行层。

围绕 AI 算力的讨论一直被“稀缺”主导。

稀缺确实存在，但它只是问题的一面。

问题的另一面是：昂贵的容量经常处于闲置状态、匹配不当、配置错误或运维碎片化，或者被那些永远无法产出有效结果的任务消耗掉。

能够解决这一问题的组织，将通过两种方式创造价值：

它们既会扩大算力的可访问性，也会大幅提升现有算力的生产效率。

在一个正准备为 AI 投入数万亿美元的行业里，即使执行效率只获得小幅提升，也可能产生极其深远的影响。

下一次基础设施突破，可能不只是一块速度更快的 GPU。

它也可能是一个确保我们不再浪费现有 GPU 的系统。

Gartner 预测，2026 年全球 AI 支出将增长 47%

CAST AI：《2026 年 Kubernetes 优化状况报告》

Microsoft Research：《深度学习任务低 GPU 利用率的实证研究》

Microsoft Research：《深度学习任务程序故障的实证研究》

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。