在谷歌，未来属于多架构：AI与自动化正助力我们实现这一目标

Google Axion处理器作为我们首款基于Arm架构的定制CPU，在为谷歌云客户和内部服务提供性能与能效方面迈出重要一步，与谷歌云上同类实例相比，价格性能提升高达65%，能效提高达60%。

我们将Axion处理器投入测试：运行谷歌生产服务。如今我们的集群同时包含x86和基于Arm的Axion机器，谷歌生产服务能够同时在多种指令集架构上运行任务。这意味着大多数为x86编译的二进制文件现在需要同时编译为x86和Arm版本——考虑到谷歌环境包含超过10万个应用程序，这绝非易事！

我们近期发布了题为《仓库级指令集迁移》的论文预印本，分析了我们对谷歌巨型单体仓库Google3的38,156次提交。简而言之，论文描述了结合辛勤工作、自动化与AI的技术方案，使我们达到当前水平。目前我们在生产环境中同时为Arm和x86架构提供谷歌服务，包括YouTube、Gmail和BigQuery，已迁移超过3万个应用到Arm架构，Arm硬件已完全投入使用且每月部署更多服务器。

让我们简要了解实现谷歌多架构的两个关键步骤：迁移模式分析，以及探索AI在代码移植中的应用。

迁移所有谷歌服务至多架构

从仅支持x86转向同时支持Arm和x86的过程中，多架构团队和应用所有者都预计需要处理架构差异问题，如浮点运算偏差、并发性、平台特定运算符等特性以及性能问题。

初期我们采用典型软件实践迁移了F1、Spanner和Bigtable等核心任务，配备每周会议和专职工程师。在此阶段我们发现了上述问题，但数量远少于预期。事实证明，现代编译器和消毒剂等工具已消除了大多数意外情况。相反，我们大部分时间用于处理以下问题：

• 修复因过度适配现有x86服务器而失效的测试
• 更新复杂的构建和发布系统（通常针对最老旧且流量最高的服务）
• 解决生产环境配置的部署问题
• 谨慎避免影响关键系统稳定性

通过这种方式迁移十几个应用完全可行，我们成功在集群管理系统Borg上运行这些应用。正如一位工程师所言：“大家都盯着完全不同的工具链，以为所有东西都会崩溃。实际上主要困难来自配置和各种琐碎事务。”

然而，仅迁移少数大型任务远远不够。尽管约60%的运行计算集中在Top 50应用中，但谷歌单体仓库中剩余应用的使用量分布曲线相对平缓。能在多架构上运行的任务越多，Borg就越能高效地将它们调度到计算单元中。为实现Arm服务器的高利用率，我们需要处理剩余10万多个应用的长尾列表。

多架构团队无法有效联系这么多应用所有者，仅安排会议的成本就难以承受！因此我们依赖自动化技术，最大限度减少应用团队本身的参与。

自动化工具

我们拥有多种自动化工具来源，其中部分在开始多架构迁移前已在谷歌广泛使用：

• Rosie：支持以编程方式生成大量提交并引导其通过代码审查流程。例如，提交可能仅包含在任务Blueprint中启用Arm的一行代码：arm_variant_mode = ::blueprint::VariantMode::VARIANT_MODE_RELEASE
• 消毒剂与模糊测试器：捕获x86与Arm间执行的常见差异（如被x86的TSO内存模型隐藏的数据竞争）。提前发现这类问题可避免重新编译到新ISA时出现非确定性、难以调试的行为
• 持续健康监测平台：用于部署和监控多架构任务的新自动化框架，自动驱逐在Arm上引发问题（如崩溃循环或吞吐量极低）的任务，供后续离线调优和调试

我们还开始使用基于AI的迁移工具CogniPort——下文将详细说明。

分析

我们对代码单体仓库的38,156次提交构成了整个ISA迁移项目的大部分提交，涵盖从Bigtable等大型任务到无数小型任务。为分析这些提交，我们将提交信息和代码差异以100个为一组输入Gemini Flash LLM的100万token上下文窗口，生成四大类别下的16个提交分类。

获得最终列表后，我们再次通过模型运行提交，让其为每个提交分配16个类别之一（同时设置“未分类”类别，通过捕获异常值提高分类稳定性）。

整体分析覆盖约70万行变更代码。我们将ISA迁移时间线按每日/每月变更代码行数进行归一化绘制。

如图所示，启动多架构工具链时，最大比例的提交属于工具和测试适配。随时间推移，代码适配相关的提交比例增加，这与我们迁移的首批大型应用相吻合。此阶段重点更新共享依赖项中的代码，解决代码和测试中的常见问题以准备规模化。在最终阶段，几乎所有提交都涉及配置文件和支持流程。在此后期阶段，合并提交数量快速上升，体现了向整个仓库的规模化迁移。

值得注意的是，大多数迁移相关提交规模较小。最大的提交通常针对大型列表或配置，而非表示单个文件更复杂的固有复杂性或精细更改。

用AI自动化ISA迁移

现代生成式AI技术为自动化剩余ISA迁移流程提供机遇。我们开发了名为CogniPort的智能体来填补这一空白。CogniPort基于构建和测试错误运作。如果在流程任何阶段，Arm库、二进制文件或测试构建失败或测试报错，该智能体会介入并尝试自动修复问题。作为第一步，我们已使用CogniPort的Blueprint编辑模式生成不适合简单更改的迁移提交。

该智能体包含三个嵌套的智能体循环，如下图所示。每个循环执行LLM以生成一步推理和工具调用。工具执行后输出结果会附加到智能体上下文中。

最外层的智能体循环是协调器，重复调用另外两个智能体（构建修复智能体和测试修复智能体）。构建修复智能体尝试构建特定目标并对文件进行修改，直到目标成功构建或智能体放弃。测试修复智能体尝试运行特定测试并进行修改，直到测试成功或智能体放弃（在此过程中可能使用构建修复智能体解决测试中的构建失败）。

测试CogniPort

虽然我们最近才将CogniPort使用规模提升到较高水平，但通过选取上述数据集中未经AI辅助创建的历史提交，有机会更正式地测试其行为。聚焦于可干净回滚的代码与测试适配类提交（类别1-8），我们生成了包含245个提交的基准集。然后回滚这些提交，评估智能体是否能修复它们。

尽管没有特殊提示或其他优化，早期测试结果非常鼓舞人心，成功修复30%的失败测试。CogniPort在测试修复、平台特定条件判断和数据表示修复方面特别有效。我们相信随着对此方法进一步优化投入，将取得更大成功。

多架构未来

目前我们仍需通过自动化处理数万个应用。为覆盖未来代码增长，所有新应用默认设计为多架构。我们将继续使用CogniPort修复测试和配置，同时与应用所有者合作处理更复杂的更改。（本项目的一个重要经验是：应用所有者通常非常了解自己的代码！）

然而，基于以下多种因素，我们对推动谷歌单体仓库实现生产服务架构中立的目标越来越有信心：

• 所有用于生产服务的代码仍集中在巨型单体仓库中可见
• 构建、运行和调试多架构应用所需的大部分结构性更改已完成
• Rosie和近期开发的CHAMP等现有自动化工具使我们能够持续扩展发布和部署目标，而无需过多干预
• 最后同样重要的是，基于LLM的自动化将使我们能够处理多ISA谷歌舰队中剩余的长尾应用

本博客及相关论文代表大型团队的工作成果。论文作者包括Eric Christopher、Kevin Crossan、Wolff Dobson、Chris Kennelly、Drew Lewis、Kun Lin、Martin Maas、Parthasarathy Ranganathan、Emma Rapati和Brian Yang，与数十名参与Arm移植工作的谷歌同事合作完成。