首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >312| AI 如何赋能谷歌,谷歌云的下一步是什么

312| AI 如何赋能谷歌,谷歌云的下一步是什么

作者头像
数据存储前沿技术
发布2026-04-21 20:37:54
发布2026-04-21 20:37:54
1540
举报

全文概览

代理式AI时代,企业架构面临重塑:AI代理不仅分析数据湖数据,还需代表人类实时行动,规模化运行。这对存储、网络和数据引擎提出新挑战——碎片化治理、批处理管道难以为继,瓶颈从数据移动转向延迟、身份验证和每令牌成本。谷歌凭借全栈控制(TPU计算、全球网络、Spanner事务引擎),从反应式转向执行式云平台,正抓住这一机遇。

Alphabet资本支出飙升至近2000亿美元,推动TPU/GPU双源策略,超大规模云总投7000亿。ETR数据显示,谷歌云IaaS/PaaS达420亿刀(份额11.5%),ML/AI净分57.4%,渗透率激增。投资者青睐其广告引擎支撑下的盈利改善(年运行率720亿)。Google Cloud Next前夕,谷歌能否将基础设施优势转化为企业ROI?TPU路线图如何优化推理经济性?代理数据云前提能否落地?这些问题关乎云存储从业者如何应对AI驱动的架构变革。

阅读收获

  • 市场份额洞察:谷歌云IaaS/PaaS 2026年预计420亿美元,份额升至11.5%,增量130亿;对比AWS/Azure基数优势,指导证券分析师评估份额转移趋势。
  • 支出势头量化:ETR净分云服务40%、ML/AI达57.4%,渗透率持续上升;存储从业者可借鉴,用于预测AI工作负载对数据引擎的需求扩张。
  • 基础设施策略:TPU作为容量/控制补充Nvidia,优化成本/瓦特;高校研究生成长路径,分析自研硅在代理式场景下的确定性和可审计性。
  • Next关注框架:六大点(ROI、模型路线图、代理数据云等),提供技术选型 checklist,提升研究生对全栈集成风险的评估。

👉 划线高亮 观点批注


突发分析 由 Dave Vellante[1] 撰写

代理式人工智能时代正在迫使企业架构进行重置。

代理不仅能分析存储在数据湖中的数据,还能代表人类采取行动——持续进行、以机器规模运行——这引入了大多数企业尚未为此设计的架构要求。所谓的“现代数据栈”开始看起来像一种新的遗留系统。拼凑在一起的系统、碎片化的治理、批处理管道以及基于边界的时代安全假设,在工作单元从仪表板查询转向自主决策循环时,就无法维持。在代理规模下,碎片化会成为运营和合规风险。

Cube 团队认为,谷歌有限责任公司(Google LLC)在这里拥有一种被低估的优势。我们的研究表明,在代理式时代获胜的架构将是那些表现为端到端系统的架构——模型、认知引擎和基础设施紧密集成,在单一可信边界内运行,并强制执行一致的安全控制,而不会在规模化时将经济性变成一种负担。这就是我们对谷歌的论点基础。谷歌拥有数十年的基础设施和数据工程卓越经验,Cube 团队认为它已做好准备,将其云服务从一个反应式智能系统演变为一个能够实时执行、大规模运行且可靠的环境。

谷歌能够可信地追求这一方向的一个关键原因是其全栈控制和深厚的工程基因。谷歌是少数几家能够端到端优化栈的玩家——计算层(包括张量处理单元)、全球网络、安全和身份表面、数据引擎以及最终实现企业价值的应用程序层。

这很重要,因为在代理式环境中,瓶颈会不断变化——数据移动、延迟、身份验证、策略执行、每令牌成本。拼凑式平台难以同时优化这些变量。集成式平台可以针对工作负载行为进行调优,并随着需求和约束的变化进行调整。

谷歌的优势不仅仅在于基础设施。该公司长期以来在大规模数据系统方面展现领导力——包括事务系统——Cube 团队认为这对企业成果故事至关重要。在代理式时代,数据库和事务层成为信任、策略和可审计性的执行点——不仅仅是存储库。如果代理要跨进程操作、协调行动并执行事务,系统必须在关键领域支持确定性,同时不牺牲速度。

市场正从拥有工具转向拥有成果。我们在定价模型中看到早期证据,这些模型奖励可衡量的结果而非席位。在我们看来,谷歌的 AI 原生执行、前沿模型实力、全栈控制以及跨云、本地和开源生态的灵活性,使其在 AI 从实验转向大规模始终在线执行时处于持续增长的位置。

在本突发分析中——在下周的 Google Cloud Next 之前——我们更新了对谷歌云的场景。我们将涵盖市场势头,使用企业技术研究(Enterprise Technology Research)数据审视支出信号,并以我们在 Google Cloud Next 2026 上关注的事项结束。

资本支出作为战略:谷歌的计算建设与 TPU/GPU 产品组合

过去几个季度驱动市场的故事是超大规模云厂商的资本支出——Alphabet Inc. 现在已牢固进入这一讨论。下面的图表捕捉了谷歌的承诺。大多数分析师原本预测大约 1195 亿美元的资本支出,而 Alphabet 自身的预测披露表明今年接近 2000 亿美元。公司隐含的范围应落在 1750 亿至 1850 亿美元左右。这是一个相对于先前预期的巨大上调,将 Alphabet 2026 年的支出置于不同于投资者以往预期“正常”增长曲线的类别中。

退后一步,Alphabet 并非孤例——这是科技领域前所未有的军备竞赛。当我们将谷歌纳入更广泛的超大规模云厂商集——亚马逊、微软、Meta 和 Oracle——总资本支出今年有望达到约 7000 亿美元。这些资本的主要用途是计算和数据中心基础设施。对于谷歌来说,这大致是相对于先前水平的翻倍,表明一家积极投入并试图满足海量 AI 需求的公司的信号。

本讨论的一个关键点是这些支出的实际购买内容。谷歌正在积极扩展其 TPU 基础设施——通过其长期硅合作伙伴 Broadcom Inc. 采购——同时确保获得 Nvidia Corp. 图形处理单元的访问权限。这种双源策略在超大规模云厂商中并不罕见。我们的观点是,Nvidia 在 GPU、网络、软件及相关库的全栈集成创造了性能/瓦特和时间价值的结构性优势,特别是随着下一代 Vera Rubin 系统推出。任何试图大规模服务广泛 AI 工作负载的超大规模云厂商都必须维持对 Nvidia 平台的显著访问,否则就有落后于依赖该生态的工作负载的风险。

同时,谷歌的 TPU 产品线为其提供了第二种战略选择——而且比其云竞争对手更成熟。TPU 允许谷歌在成本、供应和工作负载优化方面控制更多命运——然后在 Nvidia 是最佳匹配或需求超过可用 TPU 容量时使用 Nvidia 容量。

换言之,TPU 不仅仅是成本策略;它们是容量和控制策略,允许谷歌优化其垂直栈并填补硅替代品无法覆盖的空白。在计算需求超过供应的市场中,高质量计算将找到归宿。谷歌的 TPU 路线图为其吸收自身需求提供了途径,同时仍参与更广泛的以 GPU 为中心的生态。

近期含义是,谷歌正在像一家看到可持续需求的公司一样投资——并将 AI 基础设施视为多年的平台转型。我们将在本文中探讨更有趣的问题,即谷歌如何在上层栈利用这一基础设施优势——以及公司能否将这一资本支出激增转化为谷歌云的持续势头和为企业客户带来的差异化成果。

投资者奖励支出——因为谷歌展示了回报

正如我们在其他公司身上所见,这种规模的资本支出激增会引发 真正的投资者担忧[2]。通常的反应是支出增加、近期自由现金流降低,以及股价在投资回报变得更明确之前走低。但谷歌的情况并非如此。

上面的年度图表显示,过去 12 个月股价上涨约 118%,公司市值截至周五早间超过 4 万亿美元。图表上的点主要是与财报相关的事件和分析师修订,关键是,随着资本支出数字上调,华尔街的倾向更多是积极而非消极。

为什么市场给 Alphabet 这么多空间?我们的观点是,Alphabet 比大多数公司更可信地将增量基础设施支出与增量回报联系起来——主要是因为核心业务仍是广告。广告仍是资助建设的经济引擎,允许 Alphabet 吸收更大的投资周期,而不会立即像其他没有如此规模现金机的公司那样面临利润率压力。

话虽如此,将谷歌云视为重要战略业务而加以忽视将是错误。尽管它仍远小于广告业务,但它现在已成为一个有意义的增长引擎,并且正在变得更强劲。根据公司报告,谷歌云大致是一个 720 亿美元年运行率 的业务,其运营利润率已从几年前的亏损稳步改善到如今明确的盈利状况(见下图)。

我们在此强调两个关键点,包括:

  • 谷歌云在扩大规模的同时改善利润率——这种组合是市场奖励的,因为它表明了运营杠杆。
  • 其次,该业务以对这一规模的云平台来说仍很强劲的速度增长。即使广告资助资本支出周期,投资者仍希望看到证据表明云业务已成为持久增长向量,并且能够将 AI 建设转化为企业消费和利润。

本分析其余部分的背景是,Alphabet 处于相对独特的位置。它拥有资产负债表和利润引擎来资助大规模基础设施周期,并且拥有足够大且足够改善的云业务,使其成为 AI 投资回报故事的重要部分。(国内最像Google的是哪家公司呢?)

IaaS + PaaS:谷歌的市场份额增长是真实的,尽管领导者仍更大

让我们深入探讨基础设施即服务(IaaS)和平台即服务(PaaS),以便进行更清晰的超大规模云厂商苹果对苹果比较。下图是 theCUBE Research 对五大基础设施云的市场模型——亚马逊网络服务(Amazon Web Services)、微软 Azure、谷歌云平台(Google Cloud Platform)、阿里云和 Oracle。

上图有两个说明值得声明。

首先,谷歌不像 AWS 那样细分 GCP 收入,微软对 Azure 的定义历史上有所变动。因此我们进行三角验证——使用可用公司披露,加上我们自己的调查工作和 ETR 数据,构建一个跨提供商可比的 IaaS/PaaS 视图。其次,这是仅限基础设施云。不包括生产力应用或其他可能扭曲利润率和增长比较的相邻软件产品组合。

在此背景下,关键点是 GCP 在我们 2026 年估计中现在是一个 420 亿美元的 IaaS/PaaS 业务,增长率在 40% 中段。这相对于 2020 年——当时 GCP 按我们的模型是中个位数的亿美元业务——是一个重大进步。谷歌在绝对美元上仍远落后于两大领导者——AWS 预计约 1600 亿美元Azure 约 1200 亿美元(2026 年)——这种规模意味着 AWS 和微软每年抛出巨额年度收入增量。右最列的增量量化了这一点,AWS 和 Azure 各增加约 310 亿至 330 亿美元的 2025 至 2026 年增量收入,而 GCP 增加约 130 亿美元。130 亿美元的年度增量收入仍是很大数字——但两大领导者由于安装基数的规模而难以追赶。

谷歌开始显示进展的地方是份额。在我们的模型中,GCP 的 IaaS/PaaS 份额在 2026 年升至约 11.5%,同比上升约一个百分点。一个百分点听起来不多,但在 3700 亿美元的市场中很有意义。AWS 继续领先,但现在已成为份额捐赠者——2026 年降至约 43%(五大厂商中)——而 Azure 继续获得份额,升至约 33%。份额转移缓慢,但一直稳定。

Oracle 是该图表上的另一个值得注意的公司,主要是因为它从较小基数高速增长,并积极扩展容量。该公司对其高可用 AI 基础设施的需求充满信心。市场如此庞大,可信平台即使领导者主导也能快速增长。

谷歌的要点是,该公司的耐心资本——其基础设施纪律、硅策略和 AI 姿态——开始转化为可衡量的 IaaS/PaaS 势头。它仍是市场第三玩家,前两者庞大,但增长率和增量收入现在足够大,以至于份额增长在数据中显现并有意义。

ETR 支出势头:谷歌净分在高 30% 区间持稳;落后于 AWS 和 Azure,但账户渗透稳步改善

让我们通过 ETR 支出势头的视角审视谷歌云。这是我们最喜欢的 ETR 图表之一,因为它不仅显示总体分数,还显示底层客户意图和行为的组合。

快速复习如何阅读它。顶部的 浅绿色 代表 新采用——例如新账户。对于谷歌云,这是高个位数,这是成熟平台的典型。森林绿 条代表计划 增加支出 6% 或更多 的客户。在最近调查中,这是样本的约 41%灰色 代表平坦支出——±5%——约为 43%粉色 是支出下降 6% 或更多,红色 是流失。

净分是“绿减红”(蓝色线),是支出势头的衡量。谷歌云的净分约为 40%,过滤关键服务以大致匹配 AWS 报告收入。高于 40% 的任何值都被视为高度提升,因此这是一个非常强劲的数字,将谷歌云置于“高势头”区。另一条重要线是 渗透率(黄色),这是 ETR 样本渗透的代理。自 2023 年初以来稳步上升,这与更广泛的 ChatGPT 顺风和谷歌改善的商业执行一致。

几个突出点如下:

  • 组合健康,有意义比例的客户表示“支出上升”;
  • 流失低;
  • 平坦支出仍是最大桶——这是在平台达到规模时预期的;
  • 谷歌的势头更多由安装基数的扩展驱动,而非新标志,这是持久云增长的来源。

在此视图中,产品集有意广泛但仍聚焦云基础设施和平台服务——分析和数据、安全、机器学习、核心平台、容器及相关云服务。样本大小约 1000 客户,因此统计上有意义,并提供坚实方式跟踪谷歌的 AI 营销叙事是否转化为真实预算行为。

要点是,谷歌云的支出势头已长时间保持在 40% 附近,同时渗透率持续上升。这支持我们的论点,即谷歌不仅仅在谈论 AI 驱动其云势头,它正在将这一位置转化为企业账户份额的扩展。

谷歌的同行位置强劲,但仍落后于领导者

下一个 ETR 视图将谷歌云的位置置于上下文中,通过绘制两个变量。纵轴是 共享净分——ETR 在云计算部门账户中的支出势头指标。横轴是 重叠,本质上是渗透代理——每个厂商在共享账户集中的广泛出现。在此视图中,过滤 N 为 1709 账户,该图聚焦 2026 年 4 月的云计算部门。

从右上角的数字开始,谷歌云平台的净分是 38.2%,共享 N 为 529。这是一个强劲数字,略低于我们常作为高度提升标记的 40% 水平。令人印象深刻的是,微软 Azure 为 55.8%,N 为 1094AWS 为 44.1%,N 为 914。这两个厂商不仅发布更高净分,它们还在显著更高的渗透率下做到这一点,这就是为什么它们位于图表右侧更高位置的原因。

谷歌的位置是细微的。公司显然在上层势头梯队,但 在账户重叠和样本存在上仍显著落后于 AWS 和 Azure。这是市场轶事感受的量化表达——谷歌正在赢得更多业务并在账户中扩展,但从渗透角度仍在追赶,因为前两者已深度嵌入企业 IT 资产。

与下一层级的对比也很有用。Oracle 显示共享净分为 9.9%,N 为 303CoreWeave 为 19.4%,N 为 36。这些数字并不意味着这些厂商不重要——它们只是显示,在这个广泛云计算同行集中,支出势头和渗透仍高度集中在三大厂商中。重要的是,这是基于账户的指标,不指示收入规模。

在之前转义的分析报告中,笔者曾指出,在 ETR 这张图中,比较海外云巨头和国内厂商是不公平的。很高兴这一次的比较就没有把国内的云纳入进来。另外值得关注的是,本次将 NeoCloud 中的 CoreWeave 也纳入到观察视野,说明基于 GPU 加速计算的基础设施已逐渐纳入云计算考量的普遍范畴

相对于谷歌故事,我们注意两个重要点如下:

  • 谷歌的云势头是真实的,在此视图中保持在高 30% 区间,这引领我们即将探讨的前提,即谷歌的 AI 能力转化为企业支出行为。
  • 其次,战斗仍聚焦于广度而非增长率。谷歌可以快速增长,但仍难以“移动点”上的渗透,因为 AWS 和 Azure 继续增加巨额增量收入并在账户基数中保持普遍性。

AI 顺风在数据中:谷歌的 ML/AI 支出势头是大故事

下面的图表直击核心——为谷歌整体以及谷歌云具体赋能的 AI 顺风。数据是与先前云视图相同的 ETR 净分指标,但这里我们隔离 谷歌的机器学习/AI 部门。当我们这样做时,支出势头显著增强。

组合讲述了故事。新采用(浅绿色)约为 10%,高于先前的云视图。扩展是主要驱动因素。“支出上升 6% 或更多”队列(森林绿色)跃升至样本的 53%,而“平坦支出”下降至 33%。红色桶很小——支出下降和流失在此切片中仍低。

净分再次是绿减红,在这个 ML/AI 视图中净分达到非常令人印象深刻的 57.4%。ETR 净分数据中高于 40% 的任何值都被视为高度提升,因此这不是小幅改善——这是关于支出势头所在地的有力声明。

上面的另一个关键数据点是渗透率(黄色线),在所示期间急剧上升。这表明 ML/AI 足迹正在账户基数中扩散——不仅仅局限于少数早期采用者。换言之,谷歌的 AI 业务不仅在增长——它正在拓宽。

这一趋势是否说明了在下一阶段,企业基于 AI 构建的自动化 IT 系统将向具备自主算力以及强 AI 处理底座迁移?

要点是,AI 对谷歌来说不仅仅是营销叙事——它在调查数据中显现为有形的支出势头。 我们的前提一直是 ML/AI 部门正在拉动谷歌更广泛的云业务向前,这有助于解释为什么谷歌的云表现过去两年显著改善。

在 ML/AI 中,谷歌显示顶级支出势头,并有广泛渗透

让我们取相同的共享账户 XY 视图,并将其隔离到 ML/AI 而非广泛云计算。轴相同——纵轴 净分,横轴 重叠,这是账户渗透代理。在此切片中,过滤 N 为 1709 账户,该图反映 2026 年 4 月快照。

从右上角的数字开始。谷歌发布共享净分为 57.4%,共享 N 为 556。这是一个高度提升的支出势头信号,值得注意的是,谷歌在 ML/AI 中的共享 N 与先前云计算视图中的存在规模基本相同。含义是,当企业做出 AI 决策时,谷歌出现在云预算分配的相同账户的大部分中。这有助于解释为什么 AI 势头转化为云势头——采用路径通过平台运行。

同行比较也很有用。Anthropic PBC 为 77.8%,共享 N 为 499,这是例外势头,反映其如何快速进入企业。AWS 为 54.4%518,其中大部分可能包括 Anthropic 的销售渗透。OpenAI Group PBC 为 52.4%781。OpenAI 是更广泛微软 AI 足迹的有用代理,因为推理消费通常通过 Azure 流动。我们有意将微软排除在图表外,以最小化其普遍性的噪音。

另外两个观察突出如下:

  • 此视图显示 AI 支出由一小群具有强大企业吸引力的厂商驱动——谷歌显然在顶级队列中;
  • 谷歌是唯一拥有与 OpenAI 和 Anthropic 同级前沿模型的超大规模云厂商;
  • Meta Llama 显著较低,为 27.2%,共享 N 为 151,这表明尽管开源模型仍重要,但企业支出速度最快的地方是能力、分发和运营化最强的领域。值得注意的是,Llama 的位置在短时间内从领先转为落后。

要点是,谷歌的 AI 位置并非不透明。它在客户支出势头中显现为与市场上最重要的同行相当的水平,并有足够广泛的渗透来作为更广泛谷歌云业务的增长驱动。凭借从 TPU、基础设施、安全、模型到应用的 full-stack 故事,Cube 团队认为谷歌具有可持续竞争优势。

Google Cloud Next 2026:我们关注的六件事

最后,以下是我们本周在 Google Cloud Next 关注的重点。

|852x479
|852x479

|852x479

企业 AI 投资回报: 我们希望看到证据证明这一 AI 资本支出飙升为企业客户带来回报,而不仅仅是谷歌的广告业务。Alphabet 的资本支出激增戏剧性,投资者一直宽容。这种宽容持续如果客户能指出可衡量的回报——生产力、更低单位成本、更好吞吐量、更快部署真实工作负载的时间。我们将寻找证据表明客户经济性在改善,而不仅仅是谷歌主营业务。

前沿模型路线图: 我们希望澄清前沿模型路线图及其为企业打包的方式。Gemini、Vertex 及相关模型中有什么新内容真正改变采用?工具使用和推理至关重要,但更有趣的是开箱即用的内容来简化企业采用——例如治理控制、部署蓝图、评估和参考实现,而无需数千工程师构建才能投入生产。

TPU 和基础设施经济性: 我们希望以实际术语理解 TPU 路线图——成本/性能、每瓦成本、可用性、网络、推理效率——以及 Nvidia 在谷歌计划中的位置。谷歌正在构建自己的硅产品线,但也承认与 Nvidia 的关系。市场正向性能/瓦特作为门限指标移动,赢家将是那些能够端到端优化规模化工作负载经济性(训练和推理)的厂商,而不依赖头条基准。

第四:对 代理式数据云 前提的现实检查。我们希望看到谷歌是否能交付将信号与决策和行动闭环连接的系统,实时运行,而不将数据移动和治理变成昂贵过程。语义上下文、数据协调、实时激活、统一策略控制和更少胶水工作——所有这些来赋能大规模企业代理。这些是企业面临的困难任务,我们希望听到谷歌如何简化。

平台差异化—— 特别是在数据层,事务和分析与 AI 的集成。我们希望看到 BigQuery、事务引擎如 Spanner 和 AlloyDB 以及 Vertex 的更紧密对齐,以便 AI 系统能基于实时业务数据行动,而非仅历史分析数据。此处的指标是谷歌是否在减少集成负担——统一元数据、策略、血统和跨数据类型的访问控制。

生态和合作伙伴: 合作伙伴杠杆多年来一直是 AWS 势头的主要贡献者。谷歌的 AI 实力应转化为生态势头——更多合作伙伴构建、更多可重复解决方案、更多现场亲和力。我们将关注谷歌如何启用这些,以及是否在客户证明点中显现。

图片:theCUBE Research/Google Gemini

延伸思考

这次分享的内容就到这里了,或许以下几个问题,能够启发你更多的思考,欢迎留言,说说你的想法~

  1. 代理式AI下,存储系统如何平衡实时事务确定性与AI推理速度,避免碎片化风险?
  2. 谷歌TPU双源策略对Nvidia生态依赖有何影响,国内云厂商可借鉴哪些全栈优化路径?
  3. ETR数据显示ML/AI渗透扩散,企业数据湖屋向“代理数据云”转型的落地挑战是什么?

原文标题:As AI powers Google, what’s next for Google Cloud[3] ---【本文完】---

👇阅读原文,有问题试试和历史文章对话(欢迎 点赞/收藏/转发)。


  1. https://siliconangle.com/author/dvellante/ ↩
  2. https://thecuberesearch.com/306-breaking-analysis-cloud-earnings-bring-capex-clarity-concern-and-confusion/ ↩
  3. https://siliconangle.com/2026/04/18/ai-powers-google-whats-next-google-cloud/ ↩
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-04-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 王知鱼 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 资本支出作为战略:谷歌的计算建设与 TPU/GPU 产品组合
  • 投资者奖励支出——因为谷歌展示了回报
  • IaaS + PaaS:谷歌的市场份额增长是真实的,尽管领导者仍更大
  • ETR 支出势头:谷歌净分在高 30% 区间持稳;落后于 AWS 和 Azure,但账户渗透稳步改善
  • 谷歌的同行位置强劲,但仍落后于领导者
  • AI 顺风在数据中:谷歌的 ML/AI 支出势头是大故事
  • 在 ML/AI 中,谷歌显示顶级支出势头,并有广泛渗透
  • Google Cloud Next 2026:我们关注的六件事
    • 图片:theCUBE Research/Google Gemini
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档