Google Cloud Blog 中文 笔记

Google Cloud Blog 中文

cloud.google.com/blog 是 Google Cloud 的官方博客。它提供了 Google Cloud 产品和服务的新闻、更新和见解,以及云计算行业中的趋势和创新。 博客上有 Google Cloud 的专家、工程师和思想领袖撰写的文章,涵盖了人工智能、机器学习、数据分析、安全等广泛的主题。文章经常包括技术教程、案例研究和最佳实践,使博客成为开发者、IT 专业人士和对 Google Cloud 感兴趣的商业领袖的宝贵资源。 博客组织良好,文章按主题、产品和行业分类。访问者可以浏览最新的文章、搜索特定的主题或订阅博客的 RSS 订阅以跟踪最新的新闻和更新。 博客的一些关键特点包括: - 关于 Google Cloud 产品和服务的深入文章,如 Google Cloud Platform、Google Cloud Storage 和 Google Cloud AI Platform - 如何使用 Google Cloud 服务的技术教程和指南 - 来自 Google Cloud 客户的案例研究和成功故事 - 对行业趋势和创新见解和分析 - Google Cloud 的合作伙伴关系和协作的新闻和更新 - 与 Google Cloud 专家和思想领袖的采访 总之,Google Cloud 博客是任何对云计算、人工智能和相关技术感兴趣的人的宝贵资源。

笔记线程

CdXz5zHNQW_xA5im0bBF2.gif
软件行业面临周期性的架构变革:在 Web 规模爆发之后,出现了仓库级计算和容器技术,而张量处理单元(TPU)则是为了满足深度学习需求而开发。谷歌还推出了 Titanium,以提供基于硬件的安全保障。如今,一个根本性的转变正在发生,即代理式人工智能(agentic AI)的兴起:AI 代理不再仅限于回答问题,而是能够执行行动。这些代理正越来越多地编写代码、运行工具并编排工作流,从而迅速消耗计算和存储资源。传统的计算原语已不足以以低成本和低延迟运行数百万个此类代理。这催生了一种新的形态,即 Agent Compute Engine,一项谷歌云服务,为 AI 代理提供硬件隔离的微虚拟机(microVM)。Agent Compute Engine 旨在弥合虚拟机隔离性与容器的速度和密度之间的差距。现有虚拟机启动和停止速度过慢,难以满足频繁暂停和恢复代理的需求;而容器虽然快速,却缺乏某些代理任务所需的隔离性和内核级控制。该系统需要高效地管理代理,识别其活跃或空闲状态,以避免资源浪费并保留工作状态。Agent Compute Engine 被设计为一个统一平台,为持久化、硬件隔离的计算提供微虚拟机抽象。这一新架构支持多样化的工作负载,包括交互式代理界面、自主软件工程、大规模评估以及针对谷歌服务的轻量级沙箱。安全至关重要,采用纵深防御策略,以通过 Titan 硅芯片和 Titanium IPUs 实现的硬件根信任为基石。主机完整性通过无状态、不可变设备得以维持,代理会话则在单租户微虚拟机内进行隔离。零密钥架构确保敏感凭证不会驻留在沙箱内,即使 guest 操作系统被攻破也能保障安全。网络访问受到严格限制,所有流量均通过中介代理流转,由策略驱动的出站代理机制进行管控。对传输中及静态数据均实施了端到端加密。系统配备了自动补丁、运行时检测以及持续的安全措施,并严格分离代理运行环境与沙箱。系统基于“沙箱可能被攻击者控制”的假设运行,因此不持有任何凭证,且无直接网络访问权限。治理通过一等代理身份实现,由注册表和认证管理器统一管理;该认证管理器充当代理的保险库和代理。
CdXz5zHNQW_XUm165nYZ0.png
CdXz5zHNQW_U6mQXXQiGC.png
PyTorch Conference 2026 推出了用于在 Google Cloud 及其他基础设施上运行 PyTorch 的新产品与集成方案。TorchTPU 作为 Google TPU 的原生 PyTorch 栈,现已在 GitHub 上开源。这使得用户能够借助 vLLM、SGLang 和 Hugging Face 等熟悉工具,在 TPU 上实现模型的无缝训练、推理与服务部署。该集成为用户提供包括 TPU、GPU 和 CPU 在内的多种计算选项,并保持一致的操作模型。TorchTPU 支持以最小代码改动和熟悉的 API 在 TPU 上运行现有的 PyTorch 工作负载;它支持 eager 模式调试,并通过 torch.compile 优化 TPU 利用率与内存使用。Hugging Face 模型现可原生运行于 TorchTPU,通过设置 device_map="tpu" 简化部署。推理优化通过 TorchTPU 与服务引擎的集成以及跨 TPU 和 GPU 的舰队路由实现。vLLM 在 TPU 上提供高吞吐服务与内存效率,支持连续批处理与量化等特性。SGLang 通过在请求间复用 KV 缓存,加速 TPU 上的代理式与结构化工作负载。llm-d 1.0 作为 CNCF Sandbox 项目,将 PyTorch 服务引擎与 Kubernetes 连接,以支持分布式 LLM 推理。TorchTitan 提供原生的 PyTorch 分布式高性能大规模训练,已在数千个 TPU 上得到验证。VeRL 这一流行的强化学习框架现已包含 TPU 后端,支持可扩展的后训练与强化学习工作负载。Ray 已添加原生 TorchTPU 支持,可在单一工作流中编排跨多种加速器的 AI 流水线。LiteRT 作为 Google 的端侧 AI 推理解决方案,现已加入 PyTorch 生态系统,使 PyTorch 模型能够在多样化设备上运行。TPU 代理套件也已在 GitHub 上进入早期预览阶段,用于自动化 PyTorch 模型在 TPU 上的接入、诊断与性能调优。
CdXz5zHNQW_YCinlopqHk.jpeg
Google 正在举办一场峰会,探讨公共部门如何通过技术实现雄心勃勃的目标。公共部门领导层面临着在复杂性和资源有限的背景下,对速度与效率日益增长的需求。尽管许多机构已采用 AI 智能体,但其广泛普及仍受限于遗留数据孤岛和集成挑战。Google 旨在通过安全、可扩展的技术简化这些流程。该公司推出了 Gemini 智能体,这是一款适用于各类工作任务的通用助手,能够与现有系统集成并遵循组织的安全控制策略。"Gemini for Government Services"是一个专为公共部门安全和工作流需求设计的新平台,能够在无需数据迁移的情况下实现与现有系统的安全连接。Wiz 智能体现已在通过 FedRAMP 认证的"Wiz for Gov"环境中可用,以加速关键优先事项(如后量子密码学)的修复工作。Wiz 还通过其"Scan for Good"计划提供免费的安全评估服务。企业级搜索能力正被引入 Google Distributed Cloud 上的 Gemini,以支持隔离环境(air-gapped environments),从而在不牺牲互联网安全的前提下对机密数据进行分析。与 America.gov、SUNY、能源部、美国陆军及战争部的合作,展示了 Google 技术如何推动任务成效。这些合作聚焦于简化联邦服务访问、推进研究、加强国家安全以及优化后勤。凯斯西储大学(Case Western Reserve University)正利用 Gemini 提升学习与研究能力。Google 强调其作为智能体时代任务合作伙伴的角色,鼓励公共部门实体携手共建并创造影响力。
代理系统对企业日益重要,但拥有严格数据主权要求的组织在部署时面临挑战。将敏感数据发送至公有云往往不可行,而构建私有 AI 堆栈则耗时漫长。Google 分布式云(GDC)的隔离式创新现已解决这一问题,使代理系统能够直接部署在敏感数据所在之处。关键进展包括由 Gemini 驱动的企业主机搜索、对开放权重模型的支持、开箱即用的 ISV 应用程序以及加速的基础设施。GDC 旨在将孤立的基础设施转变为具备灵活性的现代代理创新平台,其灵活性源于基础模型与开放模型。GDC 上的 Gemini 企业搜索提供对话式界面,用于查询主权边界内庞大的数据仓库。它支持文本、音频和视频等多模态数据,具备低延迟推理和内置的检索增强生成(RAG)能力。GDC 隔离式现已普遍可用,支持 Gemini 3.5 Flash 以及 Gemma、Mistral 等领先的开放模型,赋予工作负载选择权。该平台具备全新的、升级的基础设施即服务(IaaS)堆栈,可共同运行 AI 与传统工作负载。其中包括搭载 NVIDIA Blackwell GPU 的 A4 Ultra 机器类型,用于高性能代理基础设施,以及高可用托管网络解决方案。不断扩展的 ISV 合作伙伴生态系统将 Teradata、Solo.io 和 Mattermost 等熟悉软件原生引入 GDC。这些集成使组织能够在不牺牲数据隐私、不遗留熟悉工具的前提下利用 AI,在合规、安全且受控的隔离环境中将敏感数据转化为可操作的洞察。
CdXz5zHNQW_WoYmLn2p8a.png
CdXz5zHNQW_vlOyaZLNoM.jpeg
CdXz5zHNQW_eem4fhIiKn.png
汽车行业正迅速向软件定义车辆转型,将核心功能从物理硬件迁移至数字系统。虽然信息娱乐系统和高性能计算系统常采用云原生方法开发,但许多关键微芯片和控制模块仍采用硬连线方式。这造成了显著瓶颈,使得制造后的更新与扩展变得困难,并将昂贵的缺陷修复工作推至开发周期的末端。Google 通过与 RemotiveLabs 等合作伙伴合作及其 Horizon 平台,旨在解决这些效率低下问题。Android Automotive OS(AAOS)已利用基于 Arm 的 Google Cloud 实例上的 Cuttlefish 等虚拟测试环境,实现座舱软件的无缝开发。RemotiveTopology 将该虚拟模型扩展至整车电气与电子(E/E)架构。通过将车辆网络转化为“车辆即代码”,RemotiveTopology 构建了一个完整的模拟 E/E 架构,连接 AAOS 与其他车辆系统。这使得开发者能够按需启动完整的虚拟车辆,实现持续的信号与跨域可见性。该系统基于标准 Linux 工具构建,可在多种平台上运行,从笔记本电脑到 Google Cloud。这种方法促进了所有车载系统在虚拟环境中尽早而非晚期的集成,在涉及物理硬件之前完成。关键的跨域交互(例如 ADAS 事件出现在信息娱乐集群中)可从一开始就持续测试。这种早期集成显著降低了在开发后期发现缺陷的可能性和成本。最终目标是实现可扩展的软件开发,即使针对最小的车辆组件,从而弥合通往完全软件定义车辆的差距。Google Cloud 基于 Arm 的基础设施(包括 Axion 的裸金属 C4A 实例)确保了云端开发软件与实际车辆控制模块之间的对等性。这一整体系统首次实现了整车系统的云端开发与集成测试,并可直接迁移至物理车辆。其优势十分显著,据早期客户参与情况衡量,集成周期可加快超过 10 倍。虚拟系统对于跟上 AI 辅助工作流至关重要,后者能够快速生成、测试和完善车辆软件。RemotiveTopology 使该架构易于访问,在 GitHub 上提供开源的简化车辆模型,可立即使用而无需新的第三方工具。制造商可以利用现有工具链,轻松将 RemotiveTopology 集成到基于 Arm 的 Google Cloud 环境中。对于那些目前仅将虚拟开发局限于座舱的厂商,是时候通过这一创新方法将云端虚拟开发扩展至整车了。
现代 AI 代理充当简单的调度器,快速处理提示和 API 调用。然而,生物技术任务(如蛋白质折叠和化合物筛选)是复杂的持续模拟,与快速的 API 查找截然不同。由于超时和知识产权暴露风险,标准 AI 范式无法应对这些高需求的工作流。构建企业级研发代理需要一种新方法,超越单体助手模式。这涉及一个三层架构,将认知编排、计算执行和企业治理分离开来。执行层负责繁重的科学计算,工作负载在专用 GPU 或托管云端点上运行。为减轻 GPU 冷启动惩罚,维持热池和预加载权重对于响应性至关重要。容器化的 NVIDIA 推理微服务(NIMs)确保快速原型开发,同时为专有化学信息保持严格的数据隔离。认知层使用分层多代理结构编排代理工作流。关键的编排模式包括进程内原生代理交接以提升速度,以及通过云存储按引用传递大型负载以保持上下文窗口紧凑。工作流逻辑与生化推理解耦,将规划任务分配给通用大语言模型,将领域专业知识分配给专用模型。评估采用基于上下文的评估而非僵化的截断阈值,从而在药物候选评估中实现动态风险容忍度。性能最佳实践强调优化 I/O 和负载大小,而非原始 token 速度。将客户端并发与后端机制对齐,并避免深层工具链同样至关重要。按引用传递大型负载以及流式传输中间阶段完成结果可提升可见性和效率。将端到端管道封装在单一、清晰的接口之后可简化计算。Gemini 平台提供企业治理,包括代理身份、用于安全入口/出口的代理网关以及用于已批准工具的代理注册表。Model Armor 检查提示和负载的安全性。非对称自主权在可逆的自动化操作与需要人工审批的不可逆操作之间取得平衡。这种解耦的架构确保了可扩展、安全且可审计的研究系统,以应对未来复杂的模拟任务。
CdXz5zHNQW_EljdokhaYM.png
时序执行平台对于分布式系统和 AI 代理至关重要,但在工人部署与扩展方面面临挑战。传统方法通常涉及管理 Kubernetes 或虚拟机,导致持续的成本支出和扩展延迟。时序云(Temporal Cloud)现已推出基于 Cloud Run 的无服务器工人(Serverless Workers),以解决这些问题。这些工人以“工人池”(worker pool)的形式部署,由时序自动扩展,即使在空闲时也可缩容至零。这消除了管理集群或自动伸缩器的需求,且无需修改工人代码。Cloud Run 工人池专为持续运行的后台任务设计,与时序工人的运作方式相契合。时序云通过 Cloud Run Admin API 监控任务队列并调整工人池规模。每个工人构建版本运行在独立的池中,允许旧版本在需要前缩容至零。该技术实现了 AI 的自动扩展代理工人,高效处理长运行工作流,并支持突发式批量处理,同时节省成本。此前,在 Cloud Run 上运行时序工人需要针对端口监听和实例计费进行变通处理。工人池消除了这些限制,无需管理端点,以更低成本提供稳定的 CPU 资源。扩展过程不会引发修订版本更替(revision churn),时序云通过监控任务积压延迟来管理增长。缩容策略更为保守,以确保可用性,并支持可配置的工人优雅关闭。时序云上的时序无服务器工人还强制实施时序工人版本控制(Temporal Worker Versioning),这是针对有状态、确定性工作流的关键功能。部署新代码会为每个版本创建独立的工人池,防止运行中途出现错误。工作流可保留在其原始版本上,或根据工作流类型配置为自动升级。设置流程包括:将工人容器化、作为 Cloud Run 工人池部署、授予时序云相应权限,并创建工人部署版本。此新功能目前处于预览阶段。
CdXz5zHNQW_Mquaroke6P.png
BigQuery 生成式 AI 函数允许用户将大型语言模型直接集成到 SQL 查询中,以执行分类和 sentiment 分析等任务。这些函数按 token 计费,因此对于大规模使用而言,主动进行预算管理至关重要。Google Cloud 已通过由 IAM 管理的每日配额,为这些函数引入了基于 token 的成本管理。存在四种每日配额:每日 AI 输入 token、每日每用户 AI 输入 token、每日 AI 输出 token 以及每日每用户 AI 输出 token。这些配额在全球范围内生效,涵盖 BigQuery 中的特定生成式 AI 函数,但不包括嵌入函数。管理员可以直接在 Google Cloud 控制台中查看和调整配额,也可以通过 API 进行程序化操作。为了有效管理成本,用户可以立即降低配额或申请增加配额(通常会自动批准)。在“配额与系统限制”页面监控使用情况,有助于检测用量激增并合理调整预算。Token 配额作为一种预防性的、针对 AI 的护栏,与更广泛的 Cloud Billing 支出上限有所区别。执行机制包括在达到配额时停止工作,具体表现为预先拒绝查询或在查询过程中中断 LLM 调用。AI.COUNT_TOKENS 函数有助于在不产生额外成本的情况下估算输入 token 用量。通过理解 token 定价并估算用量,管理员可以设定适当的配额值以符合预算目标。最佳实践包括:从每用户配额开始,使用 AI.COUNT_TOKENS 测量输入数据,注意输出 token 成本较高,并根据实际观察到的用量迭代调整限制。实施这些基于 token 的护栏可为 BigQuery 中的生成式 AI 提供成本可预测性。
CdXz5zHNQW_TKvYyrBXNC.png
支付延迟促使合规团队怀疑存在欺诈行为,需要数据科学家识别待调查的交易。该流程包括摄入并清洗原始交易日志、训练欺诈检测模型、对新交易进行评分以及自动化整个工作流程。Antigravity IDE 中的 Data Agent Kit 简化了这一端到端流程。该套件提供 MCP 工具和 Markdown 技能,用于将代理连接到 Google Cloud 数据服务,并提供数据栈交互的指导。它还使用户能够直接从其 IDE 管理 Google 的代理数据云(Agentic Data Cloud)。初始阶段,通过代理生成的 Notebook 将交易日志加载至 BigQuery。数据加载完成后,创建一个 dbt 项目以清洗和丰富 BigQuery 数据,包括处理重复数据并与参考信息进行关联。该 dbt 项目还包含针对交易的唯一性测试。接下来,生成一个训练 Notebook,利用带有已知欺诈标签的历史数据构建随机森林(Random Forest)欺诈检测模型。随后,将训练好的模型应用于推理 Notebook,对未标记的交易进行评分。欺诈概率超过指定阈值(例如 50%)的交易将被发送至 Spanner 表以供审查。此流程生成了供合规团队调查的交易短名单。最后,利用 Apache Airflow 托管服务(Managed Service for Apache Airflow)自动化整个工作流程,确保其每日运行。代理生成 Airflow DAG 定义及部署配置,编排数据加载、转换和评分步骤。该自动化管道持续将潜在欺诈交易填充至审查队列。
CdXz5zHNQW_pxgNhwMrDK.gif
商业智能用户常受限于标准化仪表板和有限的图表选项,进行深度分析时需依赖繁琐的 CSV 导出。使用典型的网格化工具设计满足特定需求(如高管简报或客户门户)的自定义仪表板也颇具挑战。此前,这导致需要构建自定义应用程序;虽然 AI 现已加速了这一过程,但仍受限于生产部署问题。这些问题包括缺乏受管数据、行级安全以及清晰的审核路径。为解决这些问题,Looker 推出了 Looker Data Apps,它将 AI 的速度与 Looker 的治理框架相结合。数据应用是由 AI 生成、托管于 Looker 内的交互式 Web 应用程序,专为特定运营工作流而设计。它们提供量身定制的布局,支持用户输入以进行场景测试和模拟,并将分析结果与执行任务(如更新记录或触发事件)相连接。这些应用基于 Looker 语义层构建,利用 AI 开发工具开发。与仪表板相比,数据应用通过启用主动执行和自定义 Web 组件,超越了仪表板的聚合可视性和标准化图表功能。Looker Data Apps 基于受管数据,通过语义层确保准确性和一致性。它们将分析转化为行动,提供可定制的、多页面的 Web 应用体验。面向企业设计,这些应用继承现有的语义模型、行级安全和访问控制。它们支持零代码部署由 AI 代理生成的应用,且终端用户交互无需运行时令牌成本。部署数据应用如同嵌入仪表板般简单,可无缝集成到外部门户中。Looker Data Apps 使原型在数分钟内即可转变为生产级工具,弥合基础仪表板与复杂自定义系统之间的差距。
CdXz5zHNQW_y0AsX1lPrs.gif
在原版发布十年后,Google 推出了其《站点可靠性工程》(Site Reliability Engineering)一书的完全重写的第二版。此次更新源于计算领域的深刻变革,包括人工智能的兴起、微服务架构的普及以及多云环境的广泛应用。第一版聚焦于早期云采用和单体架构,而新版则致力于解决在复杂、现代且全球扩展的系统中维持可靠性的挑战。过去十年间,SLO、监控、自动化和可靠性测试等实践已显著成熟。例如,SLO 已从基本的可用性指标演变为以用户为中心、多层级且具备自动执行机制的系统;监控已从静态仪表板转变为利用 OpenTelemetry 和分布式追踪技术进行快速根因分析。自动化已从自定义脚本演进为声明式的基础设施即代码(IaC)及内部开发者平台;可靠性测试现已涵盖持续韧性检查以及生产环境中的金丝雀发布验证。容量管理已转向动态自动扩缩容并与云 FinOps 对齐。SRE 的组织模式也已超越专用团队,呈现多样化发展。新版还深入探讨了 SRE 与人工智能的双重角色,阐述 SRE 如何支持 AI 基础设施,以及 AI 如何提升运营可靠性。内容涵盖大型语言模型的运行,以及利用 AI 工具改进事件定级和事后报告生成。尽管技术不断进步,SRE 的核心原则以及以可靠性为核心的文化的重要性依然未变。这本重写版旨在成为下一代生产系统的权威路线图。
CdXz5zHNQW_oDLtzwcL21.jpeg
CdXz5zHNQW_nRdt9JT0eP.jpeg
Google 自豪地宣布发布 MCP Toolbox Java SDK 1.0 版本,增强了面向企业级 Java 的代理编排能力。该 SDK 提供了类型安全的代理管理,这对于关键任务型 AI 部署至关重要,得益于 Java 在并发和状态管理方面的能力。模型上下文协议(MCP)充当通用接口,通过解耦 AI 模型与数据源来简化集成,从而消除了建立大量自定义连接的需求,降低了安全风险和维护开销。Java SDK v1.0 的关键改进包括:为灵活的网络实现提供传输层抽象,以及解耦的客户端认证以增强安全合规性。对默认参数的原生支持减少了负载大小,而剪枝绑定参数则防止敏感数据暴露给大语言模型(LLM)。标准化的版本选择和健壮的会话跟踪确保了协议的一致性。开发人员可以轻松地为出站请求附加自定义标头以添加元数据。一个实际案例展示了一款使用 AlloyDB 和 Spring Boot 的自主交通礼宾应用程序。该代理通过整合非结构化的宠物政策与结构化日程及预订功能来回答复杂的旅行查询。MCP Toolbox 通过 tools.yaml 配置将自然语言意图映射为安全的 SQL 查询。状态型代理架构通过 Spring Boot 和 LangChain4j 实现,在 HTTP 会话内管理对话记忆。此架构实现了关注点的清晰分离,具备声明式代理接口和工具执行服务。SDK 简化了会话管理,定义了代理角色,并实现了类型安全的工具执行。认证默认通过应用默认凭据(ADC)进行安全保护,消除了硬编码密钥。运行时警告会提醒开发人员注意明文 HTTP 传输中潜在的凭据泄露风险。MCP Toolbox 与 Spring Boot 代理的解耦特性允许在 Google Cloud Run 上独立扩展。开发人员可以轻松地将 SDK 依赖项添加到 Maven 或 Gradle 项目中。GitHub 仓库和演示应用程序等资源可供入门使用。