# 7.10 谬误与陷阱 在面向 DNN 的商用 DSA 发展的第一个十年里，谬误与陷阱随处可见。 ## 陷阱：与常规软件不同，DNN 可能迅速变化 图 7.5 展示了 Google 生产环境中 DNN 推理模型组合在四年间的变化。第一篇 BERT 论文发表于 2018 年，两年后，它已占工作负载的四分之一以上。不仅如此，即使模型类型不变，其规模也在持续快速增长。四年间，推理应用的存储占用和计算需求平均每年增长到原来的 1.5 倍。 训练方面的增长更快。2024 年，人们对拥有数千亿乃至数万亿参数的大语言模型充满期待。GPT-3 论文发表两年后，LLM 已占 TPU v4 工作负载的四分之一。 DSA 体系结构设计者的挑战是：通过专用化提高 DNN 性能，同时保持足够的灵活性，既支持现有模型快速增长，也能容纳不断出现的新 DNN。 ## 谬误：对于 DNN 硬件，每秒推理次数（IPS）是公平的综合性能指标 IPS 不适合作为 DNN 推理硬件的单一、总体性能指标，因为它本质上与应用中一次典型推理的复杂度成反比，而复杂度取决于 DNN 层的数量、大小和类型等因素。例如，TPU v1 运行四层 MLP1 时达到 360,000 IPS，运行 89 层 CNN1 时却只有 4700 IPS；同一个 TPU 的 IPS 相差 75 倍！因此，把 IPS 作为唯一的速度指标，比用 MIPS 或 FLOPS 衡量传统处理器还容易误导，应当更坚决地摒弃。 与本书上一版出版时不同，如今已有机器学习工作负载的行业标准基准 MLPerf。再以 IPS 或每秒峰值运算次数这样的间接指标宣称性能，已经没有理由。本章选择介绍哪些 DSA 时，就以 MLPerf 结果作为参考；本章所有 DSA 都有 MLPerf 成绩。 ## 陷阱：新 DSA 的编译器需要很长时间才能成熟 传统编程语言的开源编译器，让评估新型常规 CPU 变得相当容易；但对于 DNN DSA，情况并非如此。Google、NVIDIA 等公司的团队，为 JAX、PyTorch 和 TensorFlow 开发了各自的新型编译器和库。2017 年以来，虽然许多初创公司都在开发新的 DNN DSA，但其中大多数至今还没有提交过一次 MLPerf 结果。原因可能是：它们的软件栈还未能展现出体系结构设计者预期的性能。 ## 谬误：推理要求低延迟，所以批大小必须为 1 图 7.31 列出了 MLPerf 基准和生产应用的延迟约束，以及它们在 TPU v4 lite 上使用的批大小。延迟约束以 99% 的查询必须满足的时间上限表示，这是合理的做法。即使某些批大小达到数百，TPU v4 lite 仍能满足延迟约束。还需注意量级差异：对 CPU 来说，微秒级延迟有时就会造成性能问题，而推理延迟通常以毫秒计。 | 类型 | DNN | 延迟约束 | 批大小 | | --- | --- | ---: | ---: | | MLPerf | ResNet50 | 15 ms | 16 | | MLPerf | SSD | 100 ms | 4 | | MLPerf | GNMT | 250 ms | 16 | | 生产应用 | MLP0 | 7 ms | 512 | | 生产应用 | MLP1 | 20 ms | 128 | | 生产应用 | CNN0 | 1 ms | 16 | | 生产应用 | CNN1 | 32 ms | 16 | | 生产应用 | RNN0 | 60 ms | 8 | | 生产应用 | RNN1 | 10 ms | 32 | | 生产应用 | BERT0 | 5 ms | 128 | | 生产应用 | BERT1 | 10 ms | 64 | {#fig-7.31 num="7.31" caption="MLPerf 与生产应用在 TPU v4 lite 上的延迟约束和批大小（Jouppi，2021）" .wide .expand} ## 陷阱：不支持多租户 与 CPU 一样，推理 DSA 也应支持多租户。如果一个应用使用许多模型，让这些模型共享硬件，可以降低成本和延迟。例如，翻译 DNN 需要支持许多语言对，语音 DNN 则必须处理多种方言。另一个原因只是良好的软件工程实践：例如，先让少量客户试用新特性，或逐步部署新版本，以降低软件更新出现问题的风险。Google 八种生产推理工作负载中，有六种需要多租户。 其中三个应用的最大存储占用达到 1300–3000 MB，远远超过 2024 年单个插槽中 SRAM 能容纳的范围。如前所述，DNN 规模预计还会继续增长，而未来工艺中 SRAM 的改进速度较慢（见第 1 章图 1.18）。对于部署在云中的设备，多租户带来的一个结果是：enclave 等安全特性正在成为保护客户数据的必要条件。例如，NVIDIA 的 A100 和 H100 GPU 支持 enclave。 ## 陷阱：设计 DSA 时不了解体系结构历史 在通用计算中未能成功的思想，可能恰好适合 DSA，因此熟悉历史的体系结构设计者可能具有竞争优势。DNN 加速器的两项重要特征，都可追溯到 20 世纪 80 年代：脉动阵列（Kung 和 Leiserson，1980），以及超长指令字（Very Long Instruction Word，VLIW）（Fisher，1983）。前者降低了 TPU 中大型 MXU 的面积和功耗，后者简化了指令级并行的利用。我们建议读者认真发掘本书每章末尾“历史回顾”中的内容，寻找能够改进自己所设计 DSA 的宝贵思想。 ## 谬误：DNN 训练期间没有 I/O Facebook 开发了一条数据存储与集成流水线，为由数万个 GPU 组成的机器学习集群提供数据（Zhao，2022）。深度学习推荐模型（DLRM）在 Facebook 广泛使用，消耗了大部分机器学习训练周期。数据存储和集成需求增长迅速：2020–2022 年间，存储容量增长到原来的 2 倍，在线数据摄取带宽增长到 4 倍。Facebook 三个集群的 DLRM 能耗平均分布为：存储占 28%，预处理占 22%，训练占 50%。 ## 谬误：训练一个 DNN 模型的排放，相当于五辆汽车的全生命周期排放 这个标题于 2019 年出现在 *MIT Review* 和 *New Scientist* 中，此后又出现在多篇研究论文里。这一说法针对的是 Evolved Transformer 的训练，原文指向 7.9 节和图 7.25。[^energy-crossref] 其源头是一篇论文（Strubell，2019）：作者试图估算发现 Evolved Transformer 的 NAS 所产生的碳排放，而原始论文（So，2019）并未报告这个数据。由于无法获取进行 NAS 的 Google 所对应的 4M 数据，研究者改用 GPU，并采用数据中心 PUE 与能源清洁程度的平均值。这种可以理解的替代方式，使排放估算值达到 Google 实际使用 TPU v2 和自身数据中心进行 NAS 时排放量的约 5 倍。 NAS 的计算成本也存在误解。Evolved Transformer 的 NAS 先使用较小的代理任务搜索最佳模型，以节约时间、资金和能源，再把找到的模型扩展到完整规模。然而，外部研究者假定搜索一直使用完整规模的任务。 这使 NAS 的计算量估计达到实际值的 18.7 倍。原文给出的总体高估倍数为 88，并在括号中列出 \(5\times18.7\)。[^emissions-arithmetic] 遗憾的是，*MIT Review* 和 *New Scientist* 的记者，以及后来许多引用该论文的作者，又把 Evolved Transformer NAS 的一次性成本，与每次训练产生、相对很小的成本混为一谈，进一步放大了错误。 发现 Evolved Transformer 的 NAS 所产生的排放，是训练一次该模型的 1300 倍。因此，Evolved Transformer 的实际训练排放，约为所宣称的“五辆汽车全生命周期排放”的 1/120,000，原文列式为 \(5\times18.7\times1300\)：实际为 2.4 kg，而不是 284,019 kg。若再考虑在 Google 俄克拉何马州数据中心使用 TPU v4 训练 Primer 带来的进一步改进（见图 7.25），训练一个与 Transformer 效果相当的模型，排放降至 0.2 kg，即约为五辆汽车全生命周期排放的 1/1,400,000。 [^energy-crossref]: 译注：图 7.25 及 Evolved Transformer 能耗讨论实际位于 7.8 节；原文此处指向 7.9 节。 [^emissions-arithmetic]: 译注：\(5\times18.7=93.5\)，与原文给出的 88 不完全相符，可能涉及前一因子的取整，但原文未解释。下文的 120,000 倍、1,400,000 倍均为近似倍数。