01 行业大事件

几个GPU工作数天≈10人团队工作大半年

英伟达用AI高效设计芯片

「同样是移植一个新的技术库，如果使用人力，我们需要一个 10 人左右的团队工作大半年，但借助 AI，我们只需要花几天时间运行几个 GPU 就能完成大部分工作。」

近几年，芯片设计成为 AI 落地的一个重要领域，谷歌、英伟达、三星、西门子等多家公司都已经计划或开始尝试在芯片设计中使用 AI。其中，同时在芯片设计和 AI 领域深耕多年的英伟达有着得天独厚的优势。在前段时间的 GTC 大会上，英伟达首席科学家、计算机架构大师 Bill Dally 介绍了他们在这方面取得的进展以及所使用的 AI 工具。

以下是 Bill Dally 在 GTC 大会上的介绍原文。

预测电压降

作为 AI 专家，我们自然希望利用 AI 来设计更好的芯片。我们有几种不同的方法：一是利用现有的计算机辅助设计工具（并融入 AI），例如我们有一个可以绘制 GPU 中用电位置的地图，它还可以预测电压网下降多少——电流乘以电阻压降，被称为 IR 压降。在传统的 CAD 工具上运行该流程需要三个小时。

这是一个迭代的过程，所以进行起来有点麻烦。我们想训练一个 AI 模型来处理相同的数据。我们做了一系列的设计来进行这样的操作，然后就可以输入电源图了，最后推断时间只需三秒。当然，如果算上特征提取的时间，我们要花 18 分钟，很快就能得到结果。

我们没有使用卷积神经网络，而是用到了图神经网络，这是为了估计电路中不同节点的开关频率。同样，我们能够比传统工具更快地获得非常准确的功率估计，并且只需很少的时间。

预测寄生参数（parasitics）

我特别喜欢的一项工作是用图神经网络预测寄生参数。之前这项工作要花费大量时间，因为以前的电路设计是一个迭代的过程，你要画一个原理图，就像左边这张图。但你不知道它的性能如何，直到设计师采用该原理图进行 layout，提取寄生参数，再运行电路仿真，才会发现设计可能不符合规格，才能知道电路的性能。

接下来，设计师就要修改原理图，并再次通过 layout 来验证电路的有效性。这是一个非常漫长、反复甚至不人道的劳动密集型工作。

现在，我们可以训练图神经网络来预测寄生参数，而无需进行 layout。因此，电路设计人员可以非常快速地进行迭代，而无需手动执行 layout 步骤。事实表明：我们的神经网络对寄生参数的预测非常准确。

布局、布线挑战

我们的神经网络还可以预测布线拥塞（routing congestion），这对于芯片 layout 至关重要。在传统的流程中，我们需要制作一个网表（net list），运行布局和布线过程，这可能非常耗时，通常需要几天的时间。但如果不这么做，我们就无法得到实际的布线拥塞并发现最初布局的缺陷。我们需要对其进行重构并以不同的方式布局 macro 以避免出现下图所示的红色区域（穿过该区域的电线过多，类似于交通堵塞）。

现在借助神经网络，无需运行布局和布线，我们就可以获取这些网表并使用图神经网络大致预测拥塞的位置，准确率也非常高。这种方法暂时还不完美，但它能够显示出存在问题的区域，然后我们就能采取行动并非常快速地进行迭代，而无需进行完整的布局和布线。

自动化标准单元迁移

以上方法都是在用 AI 评价人类已经完成的设计，但实际上更令人兴奋的是用 AI 来实际设计芯片。

我来举两个例子。第一个是我们称之为 NV cell 的系统，它使用模拟退火和强化学习来设计我们的标准单元库（标准单元库是底层电子逻辑功能的集合，例如 AND、OR、INVERT、触发器、锁存器和缓冲器）。所以在每次技术迭代的时候，比如从 7 纳米迁移到 5 纳米，我们都会拥有一个单元库。我们实际上有成千上万个这样的库，它们必须用新技术重新设计，有一套非常复杂的设计规则。

我们借助强化学习来放置晶体管，但随之而来的可能是一堆设计规则错误，而这正是强化学习所擅长的。设计芯片就像一个雅达利游戏，但它是一个在标准单元中修复设计规则错误的游戏。通过强化学习检查和修复这些设计规则错误，我们基本上能够完成标准单元的设计。

下图显示的是该工具完成度为 92% 的单元库，没有设计规则或电气规则错误。这些单元中的 12% 比人类设计的单元要小。总的来说，在单元复杂性方面，该工具做得和人类设计的单元一样好，甚至比人类的还好。

这对我们有两大好处。一是节约大量劳动力。同样是移植一个新的技术库，如果使用人力，我们需要一个 10 人左右的团队工作大半年，但借助 AI，我们只需要花几天时间运行几个 GPU 就能完成大部分可以自动化的工作（92%），然后再由人来完成剩下的 8%。很多时候我们都能拿到更好的设计，所以这个方式不光节省人力，效果也比人类手工的结果好。

原文链接：

https://www.hpcwire.com/2022/04/18/nvidia-rd-chief-on-how-ai-is-improving-chip-design/

如何解释AI做出的决策？一文梳理算法应用场景和可解释性

本文结合《Explanation decisions made with AI》指南，重点对算法的应用场景和可解释性分析进行了梳理总结。

英国的?Information Commissioner’s Office （ICO）和 The Alan-Turing Institute 联合发布了《Explanation decisions made with AI》指南。该指南旨在为机构和组织提供实用建议，以帮助向受其影响的个人解释由 AI 提供或协助的程序、服务和决定，同时帮助机构和组织遵循欧盟?GDPR 等与个人信息保护相关的政策要求。该指南分为三个部分，第 1 部分：可解释 AI 的基础知识；第 2 部分：可解释 AI 的实践；第 3 部分：可解释 AI 对机构 / 组织的意义。指南最后给出了主流的 AI 算法 / 模型的适用场景，以及对这些算法 / 模型的可解释性分析，可作为实践任务中结合应用场景特点选择能够满足领域要求的可解释性的 AI 算法 / 模型的参考。

本文结合《Explanation decisions made with AI》指南，重点对算法的应用场景和可解释性分析进行了梳理总结。此外，我们还解读了一篇医学领域可解释性方法的最新论文—《评估药物不良事件预测中基于注意和 SHAP 时间解释的临床有效性》，以了解关于可解释性方法的最新研究进展。

识别形式语言能力不足，不完美的Transformer要克服自注意力的理论缺陷

最近一两年，transformer 已经在 NLP、CV 等多样化任务上实现了卓越的性能，并有一统 AI 领域的趋势。那么，推出已近五年的注意力机制真的是所有人需要的吗？近日，有论文检验了 transformer 在两种形式语言上的理论缺陷，并且设计了方法克服这种缺陷。文章还研究了可能出现的长度泛化的问题，并提出了相应的解决方案。

尽管 transformer 模型在许多任务中都非常有效，但它们对一些看起来异常简单的形式语言却难以应付。Hahn (2020) 提出一个引理 5），来试图解释这一现象。这个引理是：改变一个输入符号只会将 transformer 的输出改变 𝑂(1/𝑛)，其中 𝑛 是输入字符串的长度。

因此，对于接收（即判定某个字符串是否属于某个特定语言）只取决于单个输入符号的语言，transformer 可能会以很高的准确度接受或拒绝字符串。但是对于大的 𝑛，它必须以较低的置信度做出决策，即给接受字符串的概率略高于 ?，而拒绝字符串的概率略低于 ?。更准确地说，随着 𝑛 的增加，交叉熵接近每个字符串 1 比特，这是最坏情况的可能值。

近期，在论文《Overcoming a Theoretical Limitation of Self-Attention》中，美国圣母大学的两位研究者用以下两个正则语言（PARITY 和 FIRST）来检验这种局限性。

Hahn 引理适用于 PARITY，因为网络必须关注到字符串的所有符号，并且其中任何一个符号的变化都会改变正确答案。研究者同时选择了 FIRST 作为引理适用的最简单语言示例之一。它只需要注意第一个符号，但因为更改这个符号会改变正确答案，所以该引理仍然适用。

尽管该引理可能被解释为是什么限制了 transformer 识别这些语言的能力，但研究者展示了三种可以克服这种限制的方法。

02 程序员专区

Git 2.6发布

分布式版本控制工具Git 2.6正式发布，该版本由717个非合并提交完成，该版本修复了向后兼容缺陷、对UI、Workflow&功能、性能、内部实施、开发支持进行了修复与功能开发，其中* "git name-rev --stdin "已被弃用，使用时会发出警告。

W3C发布WebAssembly 2.0初版草案

该草案一共包括3个部分，分别是：WebAssembly Core Specification，描述了2.0版本的WebAssembly核心标准，是一种安全的、可移植的、为高效执行和紧凑表示而设计的低级代码格式；WebAssembly JavaScript Interface --2.0版提供了一个明确的JavaScript API，用于与WebAssembly进行交互；WebAssembly Web API --2.0版本，描述了WebAssembly与更广泛的网络平台的整合。

Boost 1.79.0发布，可移植的C++库

可移植C++库Boost 发布了1.79.0版本，该版本对库了进行了大量更新，涉及Asio、Assert、Atomic、Beast、Core、Describe、Filesystem、Geometry、Integer、IO、Iterator、JSON、LEAF、Log等。