Bryan Cantrill：为什么软件与硬件必须共同设计

2018 年，我在这里谈过系统中不断累积的复杂性。有人问有没有办法解决这种爆炸式增长，我的回答基本上是大家都跳进湖里算了。我欠那位提问者一个道歉：那是个懒惰的答案。我们可以构建更好的系统，这就是我今天要谈的。

Marc Andreessen 在 2011 年写的《为什么软件正在吞噬世界》已经困扰了我近 15 年。风险投资领域的观点文章有一种奇特的能力：让我强烈赞同，又强烈反对，有时甚至是在同一句话里。

旧金山 Exploratorium 有一件展品，包含一条温热线圈和一条凉爽线圈。单独触摸都无害，交错在一起却像热炉一样。这种热栅错觉由 Torsten Thunberg 于 1896 年描述。读风险投资观点文章时，我的感受很相似。

一项 2019 年的研究试图更精确地考察这种神经反应。我曾借助大语言模型寻找一篇更早的论文，它却把一篇新得多的论文当成原文给了我。无论如何，这种错觉很适合比喻我的反应：对，但同时又强烈反对。

Andreessen 预测，创业型科技公司将颠覆传统行业。现在我们可以回头检视这些预测。他比较基础设施成本的部分最有说服力：2000 年，Loudcloud 托管一个互联网应用每月约需 15 万美元；2011 年在 Amazon 上则约需 1500 美元。

云计算让任何人都能以低得多的入门成本使用弹性、软件定义的基础设施，进而催生了大量软件即服务产品。这部分是对的；我的异议在于，当一切都被描述为软件吞噬行业时，有些重要东西就被忽略了。

比如摄影被软件吞噬的说法。自 2011 年以来，手机相机进步巨大，但计算摄影依赖硬件和软件共同作用。我们都从中受益：随身带着相机，以过去难以想象的方式记录家人和生活。

Andreessen 把 Shutterfly、Snapfish 和 Flickr 列为新摄影领域的领导者。这些公司确实存在，但它们并不是我刚才描述的那场变革的领导者。他举出的 Groupon、LivingSocial 和 Foursquare 等其他例子，如今回头看也不一样了。

文章预见医疗和教育将迎来下一波变革。软件显然对两者都很重要，但 Chromebook 对教育的影响尤其重大：便宜、耐用的硬件与软件结合，使许多孩子在疫情期间能够远程学习。

医疗也多次被集成系统改变：CT、MRI 和超声都是重要技术。把这一切简单称为软件吞噬医疗过于简化了。这种说法把创新等同于创办初创公司和经济颠覆，尽管成熟公司也会创新，尊重现有系统约束的工作也可以很有价值。

使用电子表格不会让你成为软件公司；编写软件也不一定意味着你的产品就是软件。更深层的错误是把硬件和软件视为互不相干，并暗中把硬件贬为利润微薄的商品。回头看，Nvidia、TSMC、AMD 和 Apple 都说明了物理世界与软件同样重要。

要理解这个问题，我们需要先问软件究竟是什么。我曾采访 K 的创造者 Arthur Whitney，他向 Ken Iverson 学过 APL。我问软件类似什么，他回答：诗歌。对 Arthur 来说，用极少字符表达内容具有一种美感。

软件确实很奇妙。它兼具信息和机器的属性：这是能够运行的知识，复制成本基本为零。但尝试严格定义软件时就会遇到问题。它是否必须依靠物理硬件存在？是否必须是图灵完备的？

也许软件可变，而硬件不可变。但软件可以烧录到掩膜 ROM 中，FPGA 则是可以改变的硬件。一个足够宽泛、能涵盖我们所称软件的定义，也可能将数千年前欧几里得的最大公约数算法包括在内。

软件有非凡的持久力；它可以比运行它的硬件、甚至编写它的人存在得更久。这也是我此前悲观想法错误的原因之一：软件的改进可以持久保留。千年虫也揭示了旧假设能存活多久。

在 Sun，我们约三分之一的千年虫问题与闰年有关。年份能被 4 整除就是闰年，但世纪年除外；能被 400 整除的世纪年又是例外。有些程序写入了前两条规则，却漏掉第三条，因此错误地把 2000 年当成平年。

其中一个错误出现在 Unix 的 at 命令相对月份语法中。如果任务目标日期是 2000 年 2 月 29 日，它可能会被安排到 3 月 1 日。人们对千年虫非常焦虑；灾难没有出现，部分原因正是大家花了大量时间准备。

跨年之后，一位银行 CIO 告诉我，他们 45% 的千年虫问题来自同一个平台：IBM 1401。这是一台 20 世纪 50 年代的机器。它的软件通过多层模拟硬件得以存续，而这些模拟硬件又运行在其他模拟硬件之上。在这样的技术栈中，软硬件边界究竟在哪里？

我们知道硬件和软件都重要。关键问题是如何将它们结合起来创造一个系统。这正是 Oxide 软硬件共同设计的理念。

在 Sun 早期的产品中，我们能修复自己的软件错误，但其他供应商提供的固件反复导致严重问题，我们却无法修复。在 Oxide，我们决定自行设计板卡、机架和交换机，并从最底层开始尽可能多地编写软件。

我尤其想摆脱基板管理控制器，也就是 BMC：服务器内部的这台计算机曾给我们造成许多问题。我们用更容易理解、软件由自己控制的服务处理器替代它。我们仍然依赖某些组件中的专有软件，这依然是个问题。

我原以为我们只需稍微修改参考设计。但一旦用自己的服务处理器替换 BMC，实际上就要自己设计板卡。我们不制造自己的芯片，但把各种组件集成到复杂 PCB 上是可以解决的问题，也会带来否则无法获得的机会。

我们还决定需要自己的交换机。我担心投资人会问起这件事，因为听上去雄心太大了。大多数人却没有问。有些人告诉我们，他们知道我们能解决技术问题，却怀疑市场；我认为他们搞反了。技术工作风险极高，但如果机器能运行，市场将会很大。

在寻求天使投资时，一位经验丰富的基础设施工程师终于问起交换机。我承认我们打算自己做。他说这正是他想投资的原因：他的公司也是替换外部交换机后才真正独立。如今我们的交换机已经运行，它提供了一些否则很难实现的能力。

我们取消了传统 BMC，为服务处理器构建了自己的操作系统 Hubris，调试器叫 Humility。我们还取消了交换机操作系统和 UEFI BIOS；在所有决定中，去掉 UEFI 也许是风险最大的。

UEFI 处在很底层，必须初始化复杂机器的足够多部分，才能找到并启动操作系统。随后，在操作系统启动前，这些工作中的许多又实际上会被撤销。这一层增加了复杂性和启动时间，其中的漏洞还可能让攻击者控制系统的“脑干”。

有些人告诉我们，去掉它是不可能的。我们的软件从第一条指令开始接管，以整体方式启动系统，而不是先启动一个独立加载器，再让系统倒退。我们自行初始化 PCIe 引擎、多个核心和其他组件。

DDR 内存仍然需要在每次启动时进行训练，以找到能在高速、有噪声的并行接口上传输可靠数据的参数。在 AMD 平台上，这由封装内隐藏核心中的平台安全处理器完成，因此 DIMM 在我们执行第一条指令前就已完成训练。

这使我们与所选择的部件紧密耦合，而这正是设计初衷。我们在 2019 年选择了 AMD。通用系统围绕可互换部件优化，而更紧密的集成需要做出选择。如今我们已经交付系统和下一代 sled，我们不后悔掌控这一层；事实上，这条路比我们预计的更快让系统运转起来。

如果说有什么遗憾，那就是仍有一些层不受我们控制。我喜欢研究故障，因为故障揭示了系统如何运作。遇到的问题加强了我们对共同设计的信念，尽管调试时我们有时也会怀疑公司是否能撑下去。

在第一块板卡上，CPU 开始上电序列后会等待 1.25 秒，然后重新开始。我们以为供电余量不足，调查了好几周。AMD 最终告诉我们，供电余量异常充足。当设计不同于参考设计时，每一处差异都会成为嫌疑对象。

一个嫌疑点是服务器 CPU 上低电平有效的键盘重置引脚，尽管这台服务器永远不会接键盘。AMD 曾表示可以让它悬空，但走投无路的我们还是将它接到固定电位。一位工程师对引脚进行了精细操作；结果没有任何变化，这反而让人稍微松了一口气。

真正的问题出在稳压器固件。CPU 通过协议请求调整电压，稳压器也确实改变了电压；但它没有发送 VOTF 完成报文，因此 CPU 无法知道请求已经完成，便重新开始整个序列。

AMD 的电源验证工具检查了电压，却没有检查完成报文。稳压器供应商已经修复固件，但固件嵌在一个很少有机会重新刷写的部件中。我们创办公司部分是为了摆脱固件错误，结果第一个咬住我们的正是固件错误。

第二个问题涉及我们的 Chelsio 网卡。在极少数机器上，它偶尔无法训练好全部 PCIe 通道。经过漫长的底层调试和对启动软件的反复修改，我们发现第二次重置网卡总能让它正常工作。

供应商追查后发现，这个错误已经存在了 19 年。其他系统通常会执行两次重置，从而掩盖了网卡中这个独立的问题。我们只重置了一次，因为那就是一次重置。生态系统中其他地方的变通办法投下了极长的影子。

第三个故障最早出现在 Jane Street。某个 sled 上的十块硬盘每隔一两天就会同时重置。操作系统仍有进行中的 I/O，失去设备后便重新启动。我们最初怀疑硬盘或者自己的 PCIe 初始化过程。

真正的元凶是 sled 后部的中间总线转换器，它将 54 伏直流电转换为 12 伏。在约 3% 的 sled 上，输出偶尔会从 12 伏降到约 8 伏，持续几毫秒。其他稳压器能承受这种下降，硬盘却不能，于是它们一起重置。

我们修改服务处理器固件，让硬盘热插拔控制器充当见证者：它们可以记录最低和最高电压。这确凿地显示了电压下降。我们还在工厂测试转换器，防止受影响的 sled 出货，同时与供应商合作解决问题。

供应商最终发现，输入电压检测电路的工作余量太小。物理组件之间的差异可能使它错误地检测到输入电压下降，短暂降低输出后再恢复。硬盘重置与看似简单的总线转换器相隔很远；如果无法观察整个系统，这个故障可能一直像幽灵一样存在。

这就是为什么以软件为主导的思路很危险。我们需要把这些东西放在一起设计。Alan Kay 说得很好：真正认真对待软件的人会自己做硬件。结果可以是一个稳健、高性能的系统，并在远高于共同设计所在层的地方实现新功能。

一位观众问，Oxide 还有哪些软件不受自己控制。我提到稳压器固件、SSD 固件以及 CPU 封装内隐藏核心上运行的软件。我们不一定要自己编写每一部分，但需要软硬件接口透明，才能理解它们在做什么。

我们的下一个工作领域是网卡。Chelsio 提供固件，虽然由我们交付并编写驱动。我们正在使用带有高速接口硬核的 AMD Versal 部件开发基于 FPGA 的网卡，以便在不必自行构建每个困难组件的情况下控制更多行为。

目前的交换机使用 Intel Tofino，其底层软件仍是专有的。下一代产品方面，我们与 Xsight Labs 合作记录 X2 的底层指令集，并打算编写和开源自己的 P4 编译器。专有固件是我们使用 Tofino 时遇到的最大问题之一。

我们并不是为了自己做而自己做。SSD 固件和闪存转换层很难开发，只有理由充分时我们才会承担这项工作。只要可能，我们希望使用现成部件，同时要求接口足够透明，以便构建良好的系统。

有人问到芯片和硬件设计。我解释说，我们已经在使用 FPGA，并预计它们会发挥更大作用，包括用于网卡。硬件描述工具很难用。我们将来可能设计 ASIC，也许从信任根开始，但安全芯片和专有 ASIC 工具链使这成为一项重大工程。

一位观众问，这些硬件工作能够带来哪些更高层功能。当我们同时控制交换机和网卡时，就拥有了可编程网络结构。防火墙、虚拟私有网络、租户配置和端到端可观测性都可以实现；如果这些层不受我们控制，做到这些就会非常困难。

电源管理是一个令人兴奋但我们尚未实现的可能性。一个机架也许能够消耗 33 千瓦，但被限制在 20 千瓦，由控制平面决定如何在 CPU 之间分配电力。这可能改变我们在机架中布置设备和调度任务的方式。

有人问如何在快速学习和深入设计之间取得平衡，我强调要做原型。我们越来越多地制造小板卡，研究单个组件或想法。简单的低速板卡可以非常快地完成布局；一位同事从构思到将设计发送给板卡制造商，只用了 11 小时。

目标是在组装完整系统之前尽可能调试所有东西，只留下必须依靠集成机器才能解决的问题。不要不断给原型增加想法、拖延进度：针对一个问题做一块小板卡，拿回来后进行实验。我们越来越倾向于快速这样做。

一位观众问到 GPU。它们显然很重要，但我认为这里有个艰难选择：与 Nvidia 合作，或者与它竞争。Nvidia 非常封闭，也希望掌控系统的更多部分，因此我很难看出合作如何能让 Oxide 提供独特价值。

我们打算构建加速器 sled，但它必须让我们提供比通用服务器更多的价值。我对 AMD 和其他替代方案感兴趣。我听说训练系统存在的可靠性和散热问题令人担忧；我们需要一个能让我们交付更稳健系统的合作伙伴。

其他推理加速器也是有趣的可能性。GPU 运行推理可能不是能源效率最高的方式，规模较小的供应商也许能提供我们需要的透明度。我们希望与客户共同实现整体电源管理和真正的多租户等实用能力，而后者在 GPU 上仍然很难做到。

我也对将 CPU 和加速器集成在同一封装中感兴趣，正如 AMD 的 MI300A 所做的那样，不过我目前还看不到我们明确的实现路径。关键是提供有用的产品，并同样从系统层面关注性能和可靠性。

最后一个问题涉及 AMD 的 openSIL，这是一项开放底层芯片初始化过程的工作。它出现在我们决定采用 AMD 之后。我们支持它：它公开了我们自己的平台代码所依赖的实现细节，使我们不必经历漫长的许可流程就能开放软件。我们不打算自己使用 openSIL，但其他供应商也应该开放这些层。

AMD 还发现超大规模企业也有一些开放初始化的类似需求。我们一直告诉他们，透明度的重要性并不只限于我们这家特殊的公司。我非常支持这项工作。谢谢大家。