30 秒看懂
在 2026 年 4 月接受 Matthew Berman 采访时,Google Cloud 首席执行官 Thomas Kurian 讨论了数据中心长期规划、TPU 经济性、企业智能体,以及向与 Gemini 竞争的 AI 实验室提供算力的决定。他还谈到就业、代码审查和网络安全风险,并表示 Google 正在研究应将模型发布的安全界限划在哪里。性能、客户成效与预测均为 Kurian 的说法;这场谈话没有独立证实 TPU 的成本优势或 Anthropic Mythos 模型传闻中的规模。
- 1算力既是产品也是投入Kurian 表示,Google 通过 Gemini、云服务以及向其他模型提供商供应 TPU 算力等多种方式为基础设施筹资。
- 2社区担忧他指出能源成本和当地就业是关键问题,并介绍了 Google 关于能源与数据中心部署的计划。
- 3TPU 的经济性Kurian 认为客户重视 TPU 的总体拥有成本,但没有提供与 NVIDIA 的独立并列比较。
- 4训练与推理芯片TPU 8t 主要为训练设计,8i 则针对推理;Kurian 解释了智能体工作负载如何影响系统设计。
- 5竞争对手也是客户Kurian 表示,与 Anthropic 竞争的同时为其提供服务符合 Google 的平台战略,也需要作出产能分配决策。
- 6网络安全与发布阈值Kurian 表示,Google 仍在研究高能力模型的发布界限,并介绍了检测、优先级排序和修复工具。
要点建议
- Kurian 表示,Google 会平衡 Gemini 和外部客户的算力需求,因为对外销售有助于资助基础设施。
- Google 设计的 TPU 8t 主要用于训练,TPU 8i 主要用于推理,但两者也可支持其他工作负载。
- Kurian 认为,网络、内存、编译器软件和能效与芯片性能同样重要。
- 他说企业智能体改变了对内存、存储、通用计算和延迟的需求。
- Google Cloud 在与 Claude 竞争的同时向 Anthropic 提供服务,高管需要在内部和外部用户之间分配紧缺产能。
- Kurian 将 AI 辅助代码审查和网络安全视为对人工监督的补充;他表示模型发布阈值仍在讨论中。
按章节阅读整理后的全文
产能与 TPU 业务
Berman 询问 Google 如何同时满足自家模型和外部客户的需求。Kurian 介绍长期规划、商业化与算力分配。
Matthew Berman 采访 Google Cloud 首席执行官 Thomas Kurian,讨论算力、TPU 业务、Anthropic、智能体和安全。这场访谈发表于 2026 年 4 月;涉及公司的表现和客户案例均来自 Kurian 的叙述。
Berman 问,Google 如何在训练和服务 Gemini 的同时向竞争实验室提供算力。Kurian 表示,Google 既从自己的模型中获利,也从使用其芯片的其他公司获得收入。他将产能归因于多年在土地、电力、数据中心建设和芯片方面的规划。
Kurian 表示,Google 拓宽了能源来源、锁定房地产资源,并将更多数据中心工作转向预制制造。他认为,部署事先组装和测试好的单元,可以缩短机器上线时间。他还提到,Google 在开发自有 TPU 的同时,与 NVIDIA 长期保持合作。
他说 TPU 需求既来自 AI 实验室,也来自金融市场和高性能计算等领域。他以 Citadel 和美国能源部为例,说明 TPU 的应用正扩展到原本的 AI 工作负载之外。
当被问及不同用途的商业化收益比较时,Kurian 没有给出详细拆分。他表示,拥有芯片知识产权让 Google 可以通过多个渠道获得利润。他还介绍了在部分客户靠近交易场所的数据中心部署 TPU 的做法。
Kurian 认为,服务不同客户能让 Google 接触更多需求,也能在与供应商谈判时汇总需求规模。Berman 问,一家追求先进 AI 的公司为什么不把所有可用算力留给自己的模型。
Kurian 回答说,企业需要持续现金流来资助基础设施和训练。他表示,Google 会平衡客户产能、内部需求和资本要求;他的观点是,外部收入是支持进一步投资的一种方式。
当被问及 Gemini 是否也面临算力限制时,Kurian 预测未来十年算力需求都会超过供给。他认为,在资源紧缺时拥有自研芯片有助于改善 Google 的经济性。这是他的预测,不是对未来供应或成本的经验证保证。
Kurian 没有披露训练与推理算力的详细分配。他表示,云业务约占 Alphabet 资本投资的一半,Gemini 和 Google 的模型对云业务增长贡献显著;他仅将其作为粗略参考。
数据中心与就业
Kurian 回应能源和当地社区的担忧,并举出企业 AI 应用案例。他还介绍 Google Cloud 的招聘与网络安全工作。
Berman 询问当地社区反对数据中心的问题。Kurian 认为能源账单和就业是社区主要关切,并介绍了表后供电、替代能源和分散建设等 Google 方案。
Kurian 表示,Google 非常关注电源使用效率,也就是计算负载之外设施所需的额外能源。他还称公司的能效和社区投资表现出色。谈话没有提供独立比较,也不能证明某个具体项目对电网没有影响。
谈到公众对 AI 的信心,Kurian 表示必须通过实际应用展示好处。他介绍一家德国保险客户使用基于 Gemini 的智能体,并称部分查询从数分钟缩短到几秒钟,且该机构没有因此裁员。这只是一个公司案例,不能证明整个经济体的就业或服务质量情况。
Kurian 还介绍了与美国临床肿瘤学会的合作,帮助临床医生处理复杂的诊疗指南。他说准确性和避免幻觉至关重要,并以 Citigroup 计划中的财富建议应用为另一个可能用途。这些是对应用和目标的描述,不能证明医疗或金融输出始终正确。
Berman 直接询问,随着 AI 提高生产力,Google Cloud 是否仍在招聘。Kurian 表示,在服务需求保持强劲的情况下,公司正在增加产品、销售和前线部署工程人员。
Kurian 表示,模型既可以发现代码漏洞,也可以协助修复。他介绍了计划用于持续测试、发现结果排序和辅助修复的安全智能体,并将这项工作与 Google 收购 Wiz 联系起来。Berman 将 Google 的招聘与 Block 宣布的裁员作对比;Kurian 表示,各公司根据自身需求作出选择。
TPU、工作负载与系统设计
双方讨论总体拥有成本,并解释 TPU 8t 和 8i。Kurian 描述模型工作负载的变化及智能体背后的基础设施。
Berman 问 NVIDIA 和 Google 哪一家的每 token 总成本更低。Kurian 表示许多客户认为 Google 平台的总体拥有成本最优,并以强劲需求为例。他没有提供受控比较,因此访谈不能确定两个平台的相对成本。
Kurian 表示,芯片性能只是整个系统的一部分。他介绍说,TPU 8t 可扩展至 9,600 颗芯片,8i 的一个 pod 可连接 1,152 颗,并配备高带宽网络和可预测的延迟。Google 后来公开介绍了这些配置,以及 8t 最多 2 PB 的共享内存。
在硬件之上,Kurian 将 JAX、XLA、Pathways 和 PyTorch 方面的工作列为编程与编译器技术栈的一部分。他用“有效吞吐量”表示实际有用的吞吐,并称 Google 为应对预期中的能源限制,优化了每瓦特的 token 数或收益。
谈到长期计划会发生多大变化,Kurian 表示,历代硬件和软件的经验会不断积累,但客户反馈仍会改变优先事项。他说,打造专门推理芯片的决定反映了一种预期:模型提供商最终需要靠推理收入支持训练。
Berman 询问第八代芯片为何分成两类。Kurian 说,Ironwood 同时用于训练和推理;8t 主要用于训练,但部分客户可能用它推理;8i 主要用于推理,也可以训练较小的模型。
Kurian 将企业 AI 应用大致分为三个阶段:问答和研究;图像、音频和视频生成;以及使用工具、与业务系统交互的智能体。这是他对产品演进的概括,这些类别并非互斥。
企业智能体可能需要操作客户管理或供应链软件,并理解这些系统返回的信息。Kurian 将智能体定义为可以接受任务委派的模块,具有技能和工具,其中可能包括操作电脑。
他以 Xfinity、Walmart、Bosch 和 Merck 为例,介绍这些机构在客户服务、排班、制造和研究中使用 Google 技术。这些是 Kurian 对客户用途的描述,实际范围和成效因实施方式而异。
Berman 问这些工作负载如何影响芯片分工。Kurian 表示,问答、媒体生成和智能体的输入输出模式不同;较长的任务还会影响系统需要保留多少上下文和中间信息。
Kurian 以键值缓存和内存管理为例。智能体可能运行数小时,而频繁搬移状态可能带来高昂成本。操作电脑也需要传统计算,因此 Google 除开发 AI 加速器外,还与 Intel 合作并开发基于 Arm 的处理器。
推理通常需要分布在更靠近用户的位置以控制延迟,而训练可以集中在大型设施中。Kurian 表示,8i 无需水冷也能运行,因此可以部署在更多数据中心。他将其作为跨系统设计决策的一个例子。
谈到协同设计,Kurian 介绍了用于大规模训练和低延迟推理的存储系统。他引用托管 Lustre 每秒 10 TB 的吞吐量,以及快速存储系统每秒 15 Tb 的数据;这些是公司对不同系统给出的数字,单位也不同。
Kurian 还谈到 Virgo 网络,并表示 Google 为智能体工作负载协调网络、存储和算力。他认为下一个瓶颈是面向消费者的智能体所需虚拟机和本地存储的成本,因为这些智能体可能需要反复启动和停止工具。
在他的旅行规划例子中,智能体可以查询多个服务并计算预算。Kurian 认为,对消费者来说,让虚拟机无限期运行成本太高,因此高效启停、存储和资源共享对大规模普及很重要。
Anthropic 与更大的模型
Kurian 讨论向竞争对手供货以及大模型服务。他还将企业数据视为智能体训练挑战的来源。
Berman 再次提到 Anthropic:它使用 Google 基础设施,而 Claude 与 Gemini 竞争。Kurian 认为这对平台公司而言很正常,Google 的不同业务可以既向同一家机构供货又与其竞争。他以 Apple 关系为另一个合作与生态竞争并存的例子。
Kurian 表示,产能有限时,Sundar Pichai 和高管团队会决定如何在 Gemini、Anthropic 和其他实验室之间分配资源。他没有给出公式或分配比例,但认为在需求强劲时拥有自研芯片是有利条件。
Berman 询问传闻中拥有 10 万亿参数的 Mythos 模型,以及 Google 是否也达到这一规模。Kurian 没有确认传闻,也没有披露对应的 Gemini 参数量。他表示 Google 预计将推出更多 Gemini 版本,并对服务大型模型的能力有信心。
Kurian 将解耦式服务列为扩展大型模型的一种方式,并表示 Google 设计模型时会考虑服务部署。他声称 Google 的 TPU 服务技术栈效率最高,这是公司的说法;访谈没有提供公开的独立比较。
当被问及预训练扩展是否放缓时,Kurian 表示,从他负责的芯片设计、系统设计和产能角度看,他没有看到这种放缓。这一回答不能证明每个模型都会随着算力增加而继续以相同速度提升。
谈到数据,Kurian 从非结构化文本、音频和视频转向企业记录。他说,引用一份文档可能比较直接,但解释根据不断变化的表格计算出的库存答案要复杂得多:智能体必须选择正确字段,并让推理过程可追溯。
Kurian 表示,包含大量字段和控件的企业应用,为模型训练和轨迹优化提供了具有挑战性的实例。在他看来,Google 的企业业务能提供反馈,帮助 Gemini 学会使用复杂系统。
编程、网络安全与重点工作
Kurian 解释 AI 辅助开发以及持续审查的作用,最后谈到安全风险和 Google Cloud 在基础设施及客户方面的重点。
Berman 问及 Google 在智能体编程方面落后的批评。Kurian 表示,许多工程师使用名为 JetSki 的内部编程工具,并向 Google DeepMind 反馈。他的说法描述了内部采用情况,但没有独立衡量 Google 相对竞争对手的位置。
Berman 说自己在小项目中很少逐行审查,询问 Google 如何既加快速度又保持质量。Kurian 认为代码行数不是好的生产力指标:资深工程师可能用更精简的代码解决同一问题。他更看重交付了哪些功能。
Kurian 表示,Google 保留同行审查,并在资深工程师审查前使用 Gemini 检查代码、扫描安全漏洞。他还介绍了将云工具提供给模型用于故障排查的做法。这些用途旨在减少日常工作,而审查仍是他所描述流程的一部分。
Berman 提出一个风险:随着 AI 生成、审查和调试代码,人们可能逐渐失去对代码的理解。Kurian 同意这是行业风险:提示词无法描述复杂系统中的每一种行为或异常。他说,仍然需要人使用工具并处理安全问题。
Kurian 追问,模型能否可靠地发现自己生成的代码中的错误。他表示 Google 正在探索包括监督模型在内的方法,同时继续同行审查。他说,其组织内每天有数千人使用内部工具进行编程、测试和审查。
Berman 问及 Anthropic 因网络安全能力而限制 Mythos Preview 的决定,以及 Google 是否为 Gemini 的公开发布设有明确阈值。Kurian 表示,Google 仍在研究界限应划在哪里。Anthropic 当时已宣布限制预览访问;访谈没有确定 Mythos 的参数量。
Kurian 问,攻击者可能获得的开放模型还能够发现哪些漏洞。他认为,既然模型可用于发现缺陷,就需要相应的防御工具来修复漏洞、确定发现结果的优先级并持续测试系统。
他介绍了部署修复的操作挑战:不仅要编写补丁,还要找出所有运行易受攻击代码的位置并替换它们。Berman 问,AI 发现漏洞是否构成反对开源软件的理由;Kurian 表示 Google 既使用也贡献开源软件,并打算帮助保障其安全。
被问及什么让他夜不能寐时,Kurian 列出了长期产能规划、数据中心、网络和 TPU,以及解决网络安全等重要客户问题。他表示,在所述时期内,Google 的 Gemini Enterprise 每分钟 token 处理量从 100 亿增加到 160 亿,企业用户环比增长 40%;这些都是他提供的公司数据。
Kurian 最后强调,在技术快速变化的情况下,需要预判客户需求。Berman 对他的分享表示感谢。
同频道的其他文章
34:21EN → 简体中文
0:26EN → 简体中文
0:36EN → 简体中文
0:21EN → 简体中文
25:50EN → 简体中文
32:20EN → 简体中文