AI 基础设施演进：从 GPU 供应到 Workload 执行层
深度分析 AI infrastructure 从「GPU 供应竞争」向「Workload 执行可靠性」的范式转变，揭示验证、资源配置、监控、故障恢复等的战略地位。
完整中文译文
AI 公司获得算力的方式比以往任何时候都多。但它们仍然缺少一个中立层，能够可靠地将工作负载意图转化为已完成的执行结果。
人们通常将 AI 基础设施视为一个供应问题。
谁拥有 GPU？哪家云服务商有可用容量？团队在哪里能以最低的每小时价格租用 H100？哪家提供商能以最低延迟提供模型服务？
这些问题很重要，但它们只描述了技术栈中的一个层次。
AI 应用最终需要的并不是访问某块 GPU，而是完成某个工作负载。
这个工作负载可能是一次推理请求、一条图像生成流水线、一次微调运行、一次模型评估、一个批处理作业、一个训练工作负载，或者由智能体启动的任意容器。
在结果送达用户之前，必须对作业进行验证、确定资源规格、调度放置、启动和监控，并在适当情况下进行重试，最后将结果传回发起请求的应用。
硬件只是这一过程的一部分。
更重要的基础设施问题正逐渐变成：
是什么将工作负载意图转化为可靠的执行？
一个围绕这一功能的独立类别正在形成：AI 工作负载执行层。
它位于超大规模云服务商、GPU 云、市场平台和推理服务提供商之上。
它位于 AI 应用、工作流系统和自主智能体之下。
它的职责不只是提供机器，而是接收工作描述，并管理从任务发起到获得完整结果的整个过程。
这一类别仍处于早期阶段。它的边界尚未确定，而且已有多家相邻领域的基础设施公司解决了其中一部分问题。
但这一底层功能正变得过于重要，运营复杂度也越来越高，不能再继续由每家 AI 公司内部的一组脚本来承担。
这正是 Jungle Grid 正在构建并准备进入的基础设施类别。
更多算力供应并不能消除执行复杂度
如今，AI 市场提供的算力获取方式比几年前丰富得多。
超大规模云服务商提供成熟的云原语和托管式批处理系统。
专业 GPU 云能够快速提供加速器容量。
市场平台聚合来自分布式运营商的机器。
Serverless AI 平台通过更高层的编程模型提供算力。
托管式推理提供商通过简单的 API 提供特定模型。
这种扩张有利于开发者，它带来了更多容量、更多定价模式和更充分的竞争。
但它也造成了碎片化。
来看四种现有方案：
AWS Batch 通过作业队列及其关联的计算环境来调度作业。
RunPod Serverless 为 AI 和其他计算密集型工作负载提供基于队列和负载均衡的端点。
Vast.ai 将分布式 GPU 市场与实例和 Serverless 执行产品结合起来。
Modal 提供一种 Serverless 计算环境，旨在隐藏大部分底层基础设施管理工作。
每种产品都解决了问题中有实际意义的一部分。
但每种产品也都有自己的执行模型、配置系统、生命周期状态、定价模式和运维假设。
集成一家提供商的团队必须理解该提供商表示作业的方式。
集成多家提供商的团队则必须理解所有这些方式。
容器要求；
第一次集成提供商时，它可能看起来只是一个简单的 API 项目。
到了第三家或第四家时，它就变成了一个基础设施平台。
此时，这家 AI 公司已经不再只是构建自己的产品。
它还要维护调度器、提供商抽象层、作业状态数据库、可观测性流水线、产物系统，以及一系列故障恢复流程。
这些工作不可或缺，但它们通常并不是公司原本打算构建的产品。
这是执行层正在成为独立类别的第一个原因：
算力越充裕，协调需求就越强。
AI 基础设施技术栈中缺失的一层
理解这个市场的一种有效方式，是将技术栈划分为三个层次。
1. 应用与智能体层
工作负载意图源自这一层。
它包括 AI 产品、编程智能体、企业内部系统、自动化平台、研究工具和开发者工作流。
这些系统决定需要完成什么任务。
编程智能体可能需要运行一套测试。
媒体产品可能需要生成数百张图片。
客服平台可能需要对积压的文档进行分类。
机器学习团队可能需要微调模型。
研究智能体可能需要启动一个长期运行的容器、跟踪其进度、检查日志并收集输出。
应用应该理解业务任务。
它不应该需要深入了解每一家能够完成任务的基础设施提供商。
2. 算力供应层
物理和虚拟算力位于这一层。
它包括超大规模云服务商、专业 GPU 云、分布式市场平台、Serverless GPU 平台、推理服务提供商和私有集群。
这些企业回答了一个关键问题：
计算可以在哪里进行？
它们的利益通常与帮助客户高效使用其自身基础设施保持一致。
超大规模云服务商希望工作负载留在自己的云中。
GPU 云希望客户使用自己的机器。
市场平台希望需求能够与其网络中的可用供给完成匹配和交易。
这并不意味着这些提供商能力不足。
这意味着它们在技术栈中处于不同的位置。
3. 执行层
执行层回答的问题是：
这个工作负载应该如何完成？
它接收工作负载意图、评估需求、识别可行的执行路径、分派工作，并通过持久化的生命周期管理作业。
成熟的执行层应该负责：
理解工作负载的需求；
在花费资金之前拒绝或纠正无效请求；
估算成本并识别可用容量；
选择执行目标；
安全地提交作业；
跟踪提供商状态和应用状态；
提供日志和运行时事件；
从符合条件的故障中恢复；
收集输出和产物；
返回稳定的终态结果。
这不仅仅是多云路由。
路由只是更大执行契约中的一个决策。
当开发者不再需要询问以下问题时，这一类别的重要性才真正体现出来：
我应该调用哪家提供商？
我如何在这些约束条件下完成这项工作？
为什么这一类别正在此刻形成
四项结构性变化正在推动执行功能脱离企业内部基础设施团队，形成一个独立市场。
算力供应正变得更加异构
没有任何迹象表明 AI 算力会收敛到一家统一的提供商。
不同供应商将继续在不同维度上保持优势：
区域可用性；
互连性能；
对特定模型或运行时的支持。
对于短时、延迟敏感的推理任务，某家提供商可能是正确选择。
另一家可能更适合可中断的批处理任务。
还有一家可能拥有当下唯一可用、且显存足以运行特定模型的 GPU。
对于敏感数据，私有集群可能是首选；而对于可重试的公开工作负载，市场平台可能完全可以接受。
从经济角度看，合理的架构并不总是：
选择一家云服务商，并把所有任务都交给它。
使用统一的工作负载接口，再由策略决定每个作业应该在哪里执行。
这种模式以前也曾出现过。
数据库越多，对数据集成和编排的需求就越大。
SaaS 产品越多，对工作流自动化的需求就越大。
云服务越多，对可观测性和基础设施管理的需求就越大。
算力提供商越多，就越有空间容纳一个负责协调它们的层。
AI 工作负载正变得越来越不统一
“AI 工作负载”这个词如今涵盖了执行要求截然不同的多种模式。
交互式推理请求可能需要在数秒内得到响应。
批量推理作业可能运行数小时，并且能够容忍排队。
微调工作负载可能要求达到特定的 GPU 显存阈值、上传数据集、处理检查点，并持久化产物。
图像流水线可能具有突发性和并行性。
训练任务可能需要多块具备合适网络互连能力的 GPU。
由智能体启动的容器可能需要持久化文件系统、外部存储和明确的取消策略。
这些作业不应该使用同一条简单规则进行调度。
标出的最低每小时价格，并不一定意味着每个成功完成的工作负载成本最低。
一台更便宜的机器如果在初始化后失败、拉取了不兼容的镜像，或者无法在规定时间内完成任务，其成本可能高于价格更高但可靠的执行路径。
执行层之所以有价值，是因为它能够判断工作负载的适配性。
这与展示机器目录不同。
算力市场帮助客户寻找硬件。
执行平台帮助客户完成工作。
AI 智能体正在成为基础设施的直接消费者
下一个重要的基础设施客户，可能不再是在仪表盘中选择选项的人类。
模型上下文协议（Model Context Protocol，MCP）为 AI 应用连接外部系统提供了一种标准方式。
MCP 服务器可以暴露工具，供模型调用以查询系统、调用 API 或执行计算。
这带来了一项新的接口要求。
AI 智能体应该能够：
获得一个标识符；
跟踪作业的生命周期；
检查相关日志；
在执行失败时作出适当响应。
它不应该需要成为云基础设施专家。
让自主系统直接访问原始云服务商 API，会把过多的基础设施复杂性转移到 AI 智能体的循环中。
AI 智能体必须理解实例系列、区域容量、Spot 实例行为、队列策略、镜像兼容性、凭证以及不同云服务商特有的状态模型。
更好的抽象应该更接近：
使用这些要求运行此工作负载。告诉我它的成本，让我随时了解进展，并返回结果。
执行层会把这一意图转化为基础设施操作。
这不仅仅是开发者体验的改进。
它还是构建可靠的智能体系统的必要条件。
机器需要能够以结构化、可预测、可观察且安全的方式反复调用接口。
可靠性正在进入产品层面
在实验阶段，作业失败只是带来不便。
在生产环境中，它是客户体验的一部分。
当 AI 产品承诺交付某个输出时，用户并不关心故障究竟源于应用、调度器、云服务商 API、GPU 缺失、容器损坏，还是产物上传失败。
他们只会感受到一件事：
产品没有完成工作。
因此，应用需要对以下棘手问题给出可靠的答案：
请求是否已被接受？
是否确实已获得计算容量？
作业仍在队列中，还是云服务商已经将其丢失？
重试是否会产生重复工作或重复费用？
计算是否已经完成，只是产物交付失败？
用户应该等待、取消，还是重新提交？
哪个系统负责维护最终状态？
仅提供原始计算资源访问能力无法解决这些问题。
执行层必须维护一份持久记录，准确说明跨系统发生了什么，即使这些系统返回的信息可能延迟、含糊或彼此不一致。
这个类别的长期价值，可能较少来自找到最便宜的 GPU，而更多来自让异构基础设施像一个可靠的产品一样运作。
执行层不只是 GPU 编排
“GPU 编排”是一种方便的简称，但它可能会把这个类别描述得过于狭窄。
完整的执行层所协调的内容远不止硬件选择。
系统需要理解具体请求的内容。
它是推理、训练、微调、图像生成、批处理，还是自定义容器？
内存需求是多少？
工作负载是否对延迟敏感？
它能否容忍中断？
是否需要上传文件？
完成后应该生成哪些输出？
如果没有明确的工作负载契约，每一个下游决策都会变成猜测。
有些作业根本不应该提交。
镜像可能无效。
资源请求可能无法满足。
工作负载可能无法在现有硬件上运行。
所需输入可能缺失。
请求的运行时可能违反某项策略或支出限制。
在分派前拒绝有问题的工作负载，比在容量配置完成后才发现问题成本更低。
估算与预留
一个实用的执行系统，应该在应用正式提交之前，告诉它工作负载看起来是否能够运行，以及可能需要多少成本。
这一估算应该与真实的执行条件相关联，而不能只依据静态价格表。
在可能的情况下，估算期间确定的执行路径应该保留足够长的时间，让客户可以提交作业，而无须重新启动整个决策过程。
放置策略是一项涉及多个变量的决策。
正确的目标可能取决于：
模型与容器兼容性；
预期启动时间；
云服务商的历史可靠性；
最便宜的机器只是众多候选信号之一。
持久的作业生命周期
即使各云服务商使用不同的术语，应用也需要一个稳定的状态模型。
一个实用的通用生命周期可能包含如下状态：
还可以提供额外的执行阶段和事件，以便进行更深入的检查。
客户不应该需要自行转换每个云服务商的内部状态机。
云服务商接受请求期间；
请求已接受但尚未配置资源期间；
工作负载运行期间；
计算完成但输出尚未存储期间；
账单核对期间。
每个失败阶段都需要不同的响应方式。
盲目重试可能会重复执行成本高昂的工作负载。
拒绝重试则可能会把原本可恢复的基础设施事故变成面向用户的失败。
恢复策略是执行层中最困难、也最有价值的部分之一。
日志与可观察性
日志、运行时事件、云服务商元数据和失败原因，都必须关联到应用使用的同一作业标识。
当执行路径跨越多个系统时，可观察性不能事后再补。
许多 AI 作业并不会返回一个很小的 JSON 响应。
执行层必须将这些产物与正确的客户和作业关联起来。
它必须安全地存储这些产物或代理对它们的访问，并区分计算成功与交付成功。
按使用量计费的 AI 产品需要知道每个工作负载的成本。
执行层所处的位置，使它能够把预估成本、已授权支出、云服务商用量、重试和最终账单关联到同一条工作负载记录。
正是这种组合，区分了执行平台与计算资源经销商。
云服务商提供容量。
执行层负责通往结果的整个运维路径。
这个类别不会在一个空白市场中出现。
目前已有若干类厂商占据了其中一部分市场。
超大规模云服务商的批处理与 AI 平台
AWS Batch 及其他云厂商的同类服务，在各自的生态系统内提供了成熟的调度能力。
例如，AWS Batch 会把提交的作业放入队列，并根据与队列关联的计算环境进行调度。
当客户决定专注于单一云平台，并且拥有足够的工程能力来配置以下内容时，这些系统非常强大：
周边基础设施。
它们的结构性局限在于缺乏中立性。
超大规模云服务商的设计目标，是让自身的基础设施更容易使用。
即使竞争对手的云平台或外部市场更适合客户，它也几乎没有动力将客户路由过去。
专业 GPU 云与市场
GPU 云和市场拓宽了加速器容量的获取渠道，相较于超大规模云服务商的原始基础设施，它们通常还提供明显更好的开发者体验。
它们的优势在于供给。
局限则在于，客户仍然必须决定何时使用该服务商，以及如何将其生命周期与产品的其他部分衔接起来。
其中一些公司可能会向上扩展，发展为更广泛的执行平台。
这是一条可信的竞争路径。
无服务器 AI 平台
Modal 等无服务器平台最接近执行层这个类别所需要的高级体验。
它们隐藏了服务器管理，能够扩缩工作负载，并为开发者提供更高效的编程模型。
两者在战略上的区别很微妙，但非常重要。
无服务器平台通常要求开发者采用它的运行时和部署模型。
中立的执行层则要求开发者描述工作负载，然后决定如何以及在哪里利用更广泛的资源供给来执行它。
两种模式都能够造就规模可观的业务。
它们有所重叠，但并不相同。
托管推理服务商
当所需模型已经可用，并且工作负载符合服务商支持的请求模式时，托管模型 API 是最简单的解决方案。
当客户需要以下能力时，这种抽象就不再那么完整：
微调工作流；
长时间运行的批处理作业；
任意容器。
托管推理可以占据 AI 消费市场的很大一部分，但不会消除更广泛的执行层类别。
内部基础设施团队
最先进的 AI 公司通常会自行构建这一层。
账单核对。
这证明了这一职能确实存在。
但这并不能证明每一家 AI 公司都应该自行构建它。
许多基础设施类别最初都是技术先进公司内部的系统。
当这一问题变得足够普遍，市场中的其他公司既想获得这种能力，又不想维护背后的复杂系统时，商业机会就会出现。
它的经济模式不同于传统 SaaS
AI 工作负载执行不会主要按席位定价。
它天然的经济计量单位是已完成的工作。
收入可能与以下因素相关：
模型推理量；
存储与产物传输；
企业政策和支持
这创造了一个有吸引力的扩展模式。
随着客户的产品增长，它提交更多的工作负载。
随着这些工作负载变得更加复杂，路由、可靠性、可观测性和恢复的价值随之增加。
基础设施供应商随着使用量扩展，而不是随着员工数量扩展。
但这个模式包含一个重要的陷阱。
一家购买计算资源并以小幅加价转售的公司可能会成为低利润的中介。
访问相同的商用容量并不是持久的护城河。
软件层必须围绕计算创造可衡量的价值：
更高的成功完成率；
更低的每个已完成作业的有效成本；
更少的手动干预；
统一的可观测性；
提供商独立性；
客户内部的基础设施工程减少。
关键指标不仅仅是通过平台流动的总收入。
而是在扣除底层执行成本后，可以保留多少高价值软件收入。
该类别中的赢家将不会因为找到了其他人看不到的 GPU 而变得有价值。
他们将因为使碎片化的基础设施表现得像一个可靠系统而获得价值。
防御性可以出现的地方
基础的多提供商适配器是可复制的。
成熟的执行网络更难复现。
几个复合优势可以随着时间逐步发展。
每个工作负载都会产生操作信息。
哪些工作负载类型在哪些硬件上成功；
哪些镜像可以跨不同运行时工作；
哪些区域提供可靠的容量；
冷启动在哪里变得不可接受；
哪些提供商经常返回延迟状态；
哪些路由看起来便宜但失败频繁。
它学习了广告容量和可靠容量之间的差异。
放置可以逐渐从静态规则转变为由实际执行信息指导的决策。
基础设施故障并不均匀。
工作负载可能因以下原因失败：
不兼容的驱动程序；
缺少的依赖项；
过期的凭证；
工件交付问题。
正确的响应取决于原因和发生的阶段。
已经处理过大量这些情况的平台可以开发出难以从公开文档复现的恢复行为。
服务于许多客户的平台获得了更广泛的需求模式视角。
它可以理解哪些容量将被需要，识别反复出现的瓶颈，协商提供商关系，预留战略供应，并在更大的网络中分散突发使用。
这不需要拥有每一个 GPU。
它需要成为有意义的需求来源。
一旦客户依赖一个系统来处理估算、提交、作业身份、状态、日志、回调、取消、工件和计费，集成就变成了操作上的重要组成部分。
转换成本不需要来自专有锁定。
它可以来自信任。
替换基础 API 端点很容易。
替换负责生产工作负载完成的系统要难得多。
中立的控制平面可以协调那些本身不会相互协调的提供商。
随着供应变得更多样化，这个位置变得更有价值。
执行层可以代表客户的工作负载政策，而不是一个底层云的商业利益。
Jungle Grid 的定位
Jungle Grid 构建在计算提供商上方，AI 应用和 AI 智能体下方。
它不是作为另一个单一 GPU 云进行定位的。
其执行工作流允许应用和 AI 智能体提交推理、训练、微调、批处理、图像和容器化作业，而 Jungle Grid 管理底层的基础设施操作。
这些操作包括：
应用可以通过 API 集成。
AI 智能体可以使用 Jungle Grid MCP 服务器作为工具表面，用于估算工作负载、提交异步作业、检查状态、读取日志、检索工件和取消非终端工作。
架构性赌注是工作负载合约应该保持稳定，即使底层容量发生变化。
开发人员不应该需要在其产品中硬编码提供商选择。
AI 智能体不应该需要推理原始 GPU 基础设施。
团队不应该需要为每个能运行其工作负载的后端构建单独的生命周期系统。
预期的路径是：
Intent → 筛选 → 估算 → 放置 → 执行 → 恢复 → 日志 → 工件
这是一个不同于拥有一个队列并出售对其访问权的公司建设策略。
机会不仅由 Jungle Grid 直接控制多少 GPU 定义。
而由：
多少 AI 工作可以通过其执行层流动；
这些工作完成的可靠性；
平台为客户移除多少操作复杂性。
AI 工作负载执行的投资者案例基于五个命题。
- AI 应用将启动更多远程工作
未来的 AI 产品不会完全由对托管语言模型的轻量级调用组成。
应用和 AI 智能体将越来越多地触发更长、更重和更专门的计算任务。
每个额外的工作负载都扩展了对执行基础设施的需求。
- 计算供应将保持碎片化
不同的提供商将继续在不同的领域中获胜，基于：
碎片化为中立控制层创造了条件。
- 大多数 AI 公司不会想要在内部构建这个层
连接到一个提供商是可管理的。
在生产中运行可靠的多提供商执行是一个永久性的工程承诺。
对于许多团队，购买这个层最终将比维护它更理性。
- 执行接口可以成为一个控制点
拥有工作负载提交、生命周期状态、日志、恢复和工件交付的公司坐在战略上重要的位置。
它看到来自应用的需求和来自基础设施的性能。
这创造了数据、集成