AI 基础设施正成为一个工作负载路由问题

Google News 凸显了 AI 基础设施中一个更为尖锐的矛盾：拥有更多加速器，已不再保证能实现高效、可靠的推理。

这篇题为“AI Infrastructure Is Becoming a Workload Routing Problem”的报道，重新审视了一个痴迷于芯片供应的行业。更棘手的挑战在于，决定每一项请求应在何处运行。

这一决策会随模型、提示词长度、响应时限、可用内存、地理位置、缓存状态和可接受的运营成本而变化。NVIDIA 仍是核心硬件供应商，但 Google、Microsoft、AMD、Intel 以及云原生项目正在拓展可选路径。

由此形成的竞争，并不只是 NVIDIA 与替代芯片之间的较量。它也是大规模算力采购与工作负载感知型编排之间的竞争；后者是一层软件，负责将每项任务分配给合适的资源。

这种差异之所以重要，是因为推理——即运行已训练模型以生成答案的过程——与训练的运作方式不同。它持续发生，并包含多种类型的请求。

简短的分类任务、长文档分析和实时语音对话，对系统提出的要求各不相同。将它们统一送往同一条硬件路径，要么浪费容量，要么损害用户体验。

Google News 信号是一组基础设施动作的集合

重要的变化并非某一款芯片的发布。多家厂商如今正围绕不同的工作负载类别设计 AI 系统。

原始分析指出了几项相互关联的发展动态，包括新的推理加速器、专用内存设计、扩大的先进封装产能，以及在异构硬件之间部署请求的软件。

Microsoft 于 2026 年 1 月推出了专为推理打造的加速器 Maia 200。根据其 Maia 200 specifications，该芯片采用 216GB HBM3e 内存，带宽达 7 TB/s。

Microsoft 还表示，Maia 200 原生支持 FP8 和 FP4 计算。这些低精度格式可减少许多推理操作所使用的数据量，在模型质量仍可接受时提升吞吐量。

该公司称，这款芯片包含 272MB 片上 SRAM 和超过 1400 亿个晶体管。它将这些组件置于经过重新设计的系统中，以高效移动模型数据。

这些是公司自行公布的规格，并非覆盖所有生产工作负载的独立测量结果。其意义在于所体现的设计优先级：内存数据移动、token 生成和高效推理，而不是单一的通用性能评分。

Google 在 4 月的 Cloud Next 上提出了类似的系统论点。其扩展后的基础设施产品组合包括两款第八代 TPU、由 NVIDIA 驱动的裸金属实例、新 CPU、专用缓存存储以及编排更新。

这一组合之所以重要，是因为它否定了所有任务都应使用同一种加速器的观点。Google 正在一个统一的托管基础设施层中提供不同组件。

Google 还为其 Inference Gateway 引入了预测式路由。该公司表示，该系统利用实时容量信息，将首个 token 的生成时间缩短了 70% 以上。

首个 token 生成时间衡量的是用户在模型开始回答前的等待时长。它对于语音代理、交互式助手和面向客户的应用尤为重要。

Google 表示，同一次发布还实现了更快的节点启动、更快的模型加载以及更短的 pod 启动时间。每项改进都针对需求到达与有效计算开始之间的一种不同延迟。

因此，这篇 Google News 报道指向了一场广泛的运营转变。AI 基础设施正在成为由路由软件连接起来的一组专用执行路径。

这并不意味着加速器供应变得无关紧要。大型集群、高带宽内存、先进封装和高速网络仍然不可或缺。

然而，这些资源如今也带来了第二个问题。运营商必须决定哪种资源应承接每一项请求，并证明该决策符合性能与政策要求。

为什么推理工作负载路由如今至关重要

推理已成为持续性的运营支出，因此微小的部署错误会在每一次用户请求中不断累积。

训练通常将计算集中于规模大、经过规划的任务中。工程师可以预留集群、协调模型检查点，并围绕既定运行进行优化。

推理则更缺乏秩序。需求会因小时、地理区域、产品功能、客户、模型版本和输入长度而变化。

Gartner 预计，推理将在 2026 年支撑 AI 优化基础设施支出的 55%。其 infrastructure forecast 还指出，当年推理支出将超过以训练为重点的工作负载。

这项预测只是众多估算中的一种，但其方向与当前的产品开发相符。云服务商正在投资于模型训练完成后管理请求的服务系统。

一项生产级 AI 服务可能需要处理交互式聊天、批量摘要、嵌入、代码辅助、图像生成、安全检查以及代理工具调用。这些工作负载并不存在唯一的理想配置。

交互式语音请求优先考虑低延迟和可预测的响应时间。后台摘要任务则可以等待更大的批次，从而提高硬件利用率。

嵌入所需的计算通常少于生成式响应。长上下文分析对内存施加更大压力，而图像和视频生成则可能需要长时间占用加速器。

智能体系统让这种不匹配更加明显。一条用户指令可能触发规划、检索、多次模型调用、工具执行、验证和最终响应。

用户看到的是一项任务。基础设施看到的则是一连串具有不同延迟、内存和可靠性要求的工作负载。

路由决定这些步骤是交由高端 GPU、定制加速器、更小的模型、缓存结果还是延迟批处理队列。它还可以决定由哪个区域处理受监管的数据。

路由层还必须考虑键值缓存状态。KV 缓存储存从先前 token 计算得出的信息，使模型能够避免重复部分工作。

将请求发送给拥有相关缓存的工作节点，可以减少延迟和加速器周期。即便目标节点采用更快的芯片，发送到其他位置也可能丧失这一优势。

这正是普通负载均衡不足以应对问题的原因。传统负载均衡器通常会将流量引向健康且有剩余容量的服务器。

推理工作负载路由需要更多上下文。它必须理解模型身份、提示词特征、缓存位置、硬件兼容性、服务目标和数据政策。

Microsoft Research 将自身的推理研究描述为具备工作负载感知和成本感知能力。其团队正在一并研究资源分配、请求调度、批处理、路由和 KV 缓存。

这种方法承认了一项重要的系统事实：改进某一层，可能只是转移瓶颈，而非消除瓶颈。

如果模型权重加载缓慢，再快的加速器也收效甚微。当路由导致缓存碎片化，或在热门模型周围形成长队列时，增加服务器的帮助也会减弱。

因此，压力落在云服务商、模型托管方和平台工程团队身上。他们必须将多样化硬件转变为依然具备一致体验的服务。

Google AI 基础设施让控制平面成为产品本身

Google 正将路由和编排视为核心基础设施功能，而不是围绕其芯片的后台工具。

在 Cloud Next 上，Google 描述了一套覆盖 TPU、NVIDIA 系统、CPU、存储、网络、缓存和 Kubernetes 的 AI 技术栈。控制平面将这些资源连接起来。

控制平面是负责部署、配置、扩缩容和策略的软件。它决定基础设施应如何响应，然后各个工作节点才会执行请求。

Google 的 AI infrastructure update 将其托管 Kubernetes 服务 GKE 置于智能体工作负载编排的中心。这一定位颇具启示性。

该公司本可以只宣传其最新 TPU 的性能。相反，它也强调模型加载、启动速度、缓存存储、预测式路由，以及对开放推理框架的兼容性。

TPU 8t 面向高吞吐量工作负载，包括大型训练任务。TPU 8i 则通过独立的芯片与系统设计满足推理需求。

Google 还提供 NVIDIA Vera Rubin 系统，以及基于 x86 或 Arm 的 CPU 选项。这为客户创造了选择空间，但也增加了平台内部的调度复杂性。

平台必须知道哪些模型可在哪些加速器上运行。它必须考虑精度格式、内存容量、可用内核、数据移动和预期排队时间。

客户通常需要的是可靠的端点，而不是一个硬件研究项目。Google 必须吸收其中的大部分复杂性，同时仍为成熟买家提供足够的控制能力。

这形成了文章的核心竞争：采购同质化容量，还是智能地运营异构容量。

同质化资源池可简化兼容性、可观测性和事故响应。工程师可以标准化内核、部署流程、性能预期和故障回退行为。

异构资源池可以让硬件与工作负载更精准匹配。它们可能降低对单一供应商的依赖，并避免将高端加速器用于只需低成本资源的任务。

但多样性也带来了转换成本。在一个技术栈上正常运行的模型，经过量化、内核替换、编译器变更或调度器调整后，可能表现不同。

由此导致的故障未必会表现为宕机。用户可能收到更慢的响应、更短的上下文处理能力、不一致的输出，或更多工具调用错误。

Google 的方向表明，胜出的云平台将隐藏其中大部分复杂性，同时又不会让资源部署完全不透明。

客户将越来越多地询问：工作负载在何处运行、由哪个模型变体响应、使用了何种精度，以及故障回退是否改变了性能。

这些问题对受监管和对延迟敏感的应用至关重要。当服务商宣传较低成本，却未披露背后的技术取舍时，它们同样重要。

这正是 Google AI 基础设施与 NVIDIA 一体化方案竞争的地方。Google 通过其云软件协调多条硬件路径。

NVIDIA 提供紧密连接的硬件和软件技术栈，同时也在将其编排能力扩展到分布式地点。两种方案都将路由置于核心位置，但在所有权和集成方式上有所不同。

这场竞争不会在每种工作负载上产生简单的赢家。其可衡量的结果将是：在基础设施利用率提升的同时，客户是否能获得可预测的服务。

硬件多样性带来了软件税

更多加速器选择可以降低对供应商的依赖，但每增加一条路径，都会扩大测试和运营负担。

Microsoft 的 Maia 200 展现了定制芯片的吸引力。Microsoft 可以围绕自身的数据中心、软件和模型服务需求设计推理加速器。

该公司表示，Maia 200 已支持 Microsoft Foundry 和 Microsoft 365 Copilot 工作负载。内部服务提供了一个由 Microsoft 控制产品和基础设施层的环境。

外部工作负载则构成更严峻的考验。另一家模型提供商会带来其自身的质量要求、部署实践、内核、延迟目标和客户承诺。

基准测试可以表明一款芯片能够快速完成某项既定任务，但无法证明复杂的生产服务在流量激增、故障、模型升级和区域容量受限时仍能保持一致表现。

Intel 正通过 Crescent Island 探索另一条路径：这是一款面向风冷企业服务器、专注于推理的 GPU。该公司指定采用 160GB LPDDR5X 内存，而非许多高端加速器使用的 HBM。

这一选择反映了工作负载之间的取舍。高带宽内存拥有卓越的数据传输能力，但也伴随着供应、封装、功耗和系统设计方面的限制。

基于 LPDDR 的设计可以在不同的功耗和设施限制下，瞄准更大的内存容量。其适用性仍取决于模型、延迟目标、软件成熟度和实际应用。

与此同时，AMD 正在扩展其机架级基础设施和封装合作关系。其战略将 Instinct 加速器与 EPYC CPU 及更广泛的系统组件相结合。

这些路径挑战了这样一种假设：AI 需求会清晰地对应某一种硬件类别。它们也扩大了基础设施团队需要面对的兼容性矩阵。

软件必须跟踪哪些模型适合部署在每个内存池中。它还需要针对所选精度和加速器验证可用的内核。

运营团队同样需要可观测性，即关于系统内部实际发生情况的证据。有价值的记录包括排队时间、缓存命中、所选硬件、模型版本、重试和回退行为。

没有这些记录，较低的平均成本可能会掩盖更差的尾延迟。尾延迟衡量最慢的一部分请求，而这往往决定了用户对可靠性的感受。

平均响应时间可能有所改善，但少量请求却可能变得异常缓慢。语音助手和交互式智能体尤其容易受到这种模式的影响。

路由故障还可能带来合规问题。系统可能将请求发送至某个可用区域的容量，而该区域与数据驻留要求相冲突。

因此，部署策略既是一项经济规则，也是一项治理规则。它必须同时保障成本、性能、隐私和服务一致性。

这正是硬件多样性带来的软件税。它可能值得投入，但前提是流量规模和工作负载差异足以证明这项投资合理。

需求尚不确定的创业公司通常更适合采用托管模型 API。过早构建具备硬件感知能力的路由，可能会让工程师分心，偏离产品质量和客户采用。

大型平台面临的则是相反的风险。将每个请求一视同仁，可能会在数百万次重复操作中浪费昂贵的容量。

分界线在于使用密度。当团队拥有足够多的持续性流量，能够对工作负载进行分类、衡量结果并改进部署策略时，路由才会产生价值。

开放路由标准挑战封闭的基础设施孤岛

路由层正变得具有足够的战略重要性，以至于供应商正在竞争塑造其接口和标准。

Google 并非独自构建这一层。它与 Red Hat、IBM Research、CoreWeave 和 NVIDIA 共同创建了 llm-d。

该项目是一个面向分布式模型推理的 Kubernetes 原生框架。Kubernetes 协调容器化应用，而 llm-d 则增加了对模型服务状态的认知。

Cloud Native Computing Foundation 于 2026 年 3 月 12 日接纳 llm-d 成为 Sandbox 项目。Sandbox 身份表明其已进入早期社区治理阶段，并不意味着生产成熟度或得到保证的互操作性。

根据 llm-d 项目，其能力包括感知前缀缓存的路由、预填充与解码分离、缓存卸载，以及具备硬件感知能力的扩缩容。

预填充是处理用户输入 token 的阶段。解码则生成输出 token，两者通常具有不同的资源和内存行为。

将这些阶段分离后，运营团队可以独立扩缩容。与此同时，这也增加了更多部署决策，以及组件之间更多的网络通信。

该项目支持来自 NVIDIA、AMD、Intel 和 Google 的加速器。其既定目标是在模型、加速器和云之间实现广泛的可移植性。

这一目标回应了买方的真实担忧。与某一种芯片或云绑定的路由层，可能会让运营智能变成另一种形式的锁定。

然而，开放接口并不能消除硬件差异。每种加速器仍有不同的内核、内存行为、网络能力和性能特征。

真正的可移植性需要经过验证的结果，而不仅仅是共享 API。运营团队需要针对输出质量、吞吐量、延迟、缓存效率和故障恢复，获得可比较的衡量指标。

NVIDIA 也在将路由扩展到单个集群之外。其 AI Grid 设计将分布式基础设施视为一个可编程平台。

该公司的 AI Grid 架构 会根据延迟、主权、成本、节点健康状态、利用率和缓存可用性来部署工作负载。

这种方法可以在中心数据中心、大都市设施、电信站点和边缘站点之间路由推理。地理位置成为调度决策的一部分。

实时语音服务受益于就近执行，因为网络延迟会直接影响对话流畅性。后台任务则通常可以在容量可用时部署到更远的位置。

受监管的医疗请求可能需要位于获批司法管辖区。媒体工作负载则可能优先考虑网络带宽，因为其传输的数据量远大于文本。

NVIDIA 的设计强化了 Google News 所强调的同一论点：AI 基础设施正在演变为跨硬件和地理位置的部署问题。

不过，供应商都有动力将其偏好的技术栈描述为天然的控制层。Google 会在 GKE 管理工作负载时获益，而 NVIDIA 则会在其软件协调整个网格时获益。

开放项目承诺中立性，但其成熟度和治理方式仍需审视。Sandbox 项目可能快速演进、更改接口，或缺乏大型企业所要求的运营历史。

云服务提供商也可能选择性地开放路由控制。客户可能获得某个延迟等级或区域偏好，却无法得知实际由哪种加速器处理了请求。

这种抽象可以简化运营，却会使审计更加复杂。如果提供商隐藏部署证据，买方就无法评估硬件替换的影响。

因此，决定性的标准不仅涉及路由，也涉及可观测性。它必须描述的不只是请求应被发送到哪里，还包括部署之后实际发生了什么。

Google News 读者接下来应关注什么

只有当供应商公开可衡量的部署控制能力和生产结果时，路由论点才具备可信度。

第一个信号是 Google 在预测式 Inference Gateway 路由方面的进展。客户应关注其在不同模型、流量峰值和缓存条件下的独立结果。

Google 报告称，无需人工调优即可将首个 token 的生成时间缩短超过 70%。更广泛的证据应显示，这些收益是否能在经过筛选的配置之外持续存在。

重要指标包括中位延迟、尾延迟、缓存命中率、请求失败率和加速器利用率。模型质量应在每一条经过测试的路径上保持稳定。

疲弱的结果将表明，预测式部署是在转移复杂性，而非解决复杂性。持续的生产收益则会强化 Google 的主张：编排可以胜过人工调优。

第二个信号是 llm-d 等加速器中立框架的采用情况。仅有项目活跃度并不足够。

应关注托管服务、稳定接口、参考部署，以及在 NVIDIA、AMD、Intel 和 Google 硬件上的可比较基准测试。企业案例研究应记录故障和回退行为，而不只是峰值吞吐量。

跨供应商部署将强化开放路由模式。碎片化实现或面向特定硬件的分支，则会削弱有关实用可移植性的主张。

第三个信号是客户能否访问部署证据。云端仪表板和 API 应披露模型变体、延迟等级、缓存行为、区域和回退事件。

买方未必需要手动选择每一款芯片，但确实需要足够的证据，将基础设施决策与用户体验和运营结果联系起来。

其影响不止于云工程。产品团队需要了解，较慢的智能体行为究竟来自模型、检索管道、工具执行，还是基础设施部署。

企业买方需要证据表明，敏感请求始终留在获批区域。开发者则需要在提供商更换底层硬件时，依然获得可预测的 API。

知识工作者感受到的最终结果，可能是更快的回答、延迟的语音响应，或不可靠的智能体。路由对这种体验的决定作用，远超多数接口所揭示的程度。

Google News 的标题捕捉到了一个真实的转变，但这一转变尚未完成。供应商已经描述了实现工作负载感知型基础设施所需的控制平面、芯片和开放框架。

现在，他们必须证明这些系统能够在生产压力下正常运行。未来三个月将显示，路由会成为一种透明的运营能力，还是云复杂性的又一层隐藏机制。

对于 AI 构建者而言，眼下的行动很直接：按工作负载衡量请求，而不要将推理视为一个混合类别。跟踪上下文长度、延迟、缓存使用、重试、模型选择，以及在可获取时的硬件部署情况。

然后提出 Google News 引出的更难问题：每个请求是否都抵达了最便宜且可靠的路径，还是平台仍在将所有任务发往恰好可用的加速器？