1. 缘起一个微处理器分析师与AI基准测试的相遇我职业生涯的大部分时间都在与晶体管、指令集和缓存延迟打交道。作为《微处理器报告》的分析师和Real World Technologies的运营者我的世界是由SPECint、功耗墙和IPC每周期指令数构成的。直到几年前我对于机器学习的理解还停留在大学时期数学课上接触到的统计模型以及后来在分析专利数据时那些试图预测成功率的、效果时好时坏的算法尝试。转折点发生在2017年一次为一家专注于机器学习加速器的初创公司提供专利组合分析的技术咨询。那是我第一次真正深入硬件层面去理解为了高效运行矩阵乘法和卷积运算芯片架构师们正在如何重新思考计算单元、内存层级和数据流。这扇门一旦打开就再也关不上了。我意识到我们正站在一个堪比个人电脑或智能手机兴起的拐点。但和那些时代不同驱动这场变革的“杀手级应用”——深度学习其性能评估却是一片混沌。当时业界充斥着各种“峰值算力”TOPS的数字游戏就像早年只比拼CPU主频GHz一样片面。一个在特定小模型上跑得飞快的加速器面对真实的、复杂的ResNet或Transformer模型时可能完全失灵。硬件工程师、软件开发者、采购决策者大家都在迷雾中摸索缺乏一个像SPEC之于通用计算那样公认的“标尺”。就在这时我通过行业内的朋友听说了MLPerf。MLPerf最初给我的印象是一群来自谷歌、百度、伯克利、斯坦福的“疯子”他们想为机器学习系统打造一套基准测试。这立刻引起了我的共鸣。我深知好的基准测试如SPECcpu如何能引领整个行业朝着提升真实性能的方向健康发展而糟糕的基准又如何催生“基准营销”误导设计最终损害用户利益。我在智能手机基准测试的乱象中见过太多反面教材。机器学习系统更为复杂涉及硬件、框架、算法、数据预处理等多个层面如果没有一个设计精良的基准混乱只会更甚。于是我抱着学习和观察的心态混进了他们的邮件列表和早期讨论。一个关键的争论点吸引了我是否以及如何测量训练系统的功耗这问题直击要害。训练一个大型模型可能消耗相当于一个小镇数日的电量能效与绝对性能同样重要。我的一位朋友曾主导创建了SPECpower_ssj2008我们没少讨论其中测量方法、环境标准化等令人头疼的细节。我觉得自己在这方面积累的经验或许能帮上点忙便在2018年初就这个问题与MLPerf的几位核心成员包括Dave Patterson和Jonah Alben进行了一些交流。2. 为何选择深入参与不止于兴趣与MLPerf社区的初步接触让我决定不再只做旁观者。原因有几个层面它们共同构成了一种“必须加入”的推力。2.1 与顶尖头脑共事的机会这个名单本身就是一种吸引力。Greg Diamos来自百度DeepSpeech团队也是早期基准测试工具DeepBench的推动者Jonah Alben领导了多代NVIDIA GPU架构设计在硬件/软件协同设计上有着教科书级的成功经验还有来自谷歌TPU团队、英特尔前Nervana团队、微软Azure的关键贡献者。这些人不是在预测未来他们就是在建造未来。与他们讨论问题就像站在技术浪潮的源头。我记得有一次与Greg讨论不同框架下卷积操作的细微差别他随手举出的实例立刻澄清了我苦思许久的疑惑。这种高质量的信息交换是独自阅读论文无法比拟的。2.2 填补行业空白的使命感2018年机器学习加速器如雨后春笋般涌现但评估它们就像用不同的尺子量身高。有的用ImageNet的Top-1准确率有的用每秒处理的图片数但 batch size、预处理流程、精度格式FP32, FP16, INT8各不相同结果根本无法直接对比。业界急需一套“通用语言”。MLPerf汇聚了来自学术界和工业界最懂机器学习系统的人他们既有理论高度又深知工程实现的痛点。我看到这是最有希望打造出这套“通用语言”的团队。我的背景——对计算机架构的深入理解、对基准测试哲学的认同以及对功耗测量复杂性的认知——恰好可以补充团队在纯粹硬件评估和系统级度量方面的视角。2.3 个人学习的绝佳路径我自认在硬件架构方面已有一定积累但机器学习是一个软件定义一切的领域。框架TensorFlow, PyTorch、调度器、编译器优化这些对我而言还是一片亟待探索的大陆。MLPerf的工作要求你不仅要知道硬件怎么跑还要知道软件怎么喂以及为什么这么喂。参与基准测试的定义是理解整个软件栈最直接、最深刻的方式。你需要弄明白为什么ResNet-50的特定残差块结构对缓存不友好需要理解Transformer模型中自注意力层的计算与内存访问特征。这不是纸上谈兵而是要落实到可重复运行的代码和可测量的结果上。于是在2018年5月斯坦福教师俱乐部的那次MLPerf社区会议上当Kim Hazelwood一位从终身教授转型为Facebook工程经理的杰出女性问是否有人愿意做会议记录时我几乎是下意识地举了手。她后来笑称这是她的“战地提拔”。事实证明在一个工程师更热衷于设计而非文档的群体里主动承担记录工作是融入并理解全局最快的方式。这份“秘书”工作成了我深入MLPerf核心的通行证。3. 从记录员到联合主席在MLPerf的实践与成长我的角色很快从记录员演变为更积极的贡献者。随着v0.5训练基准套件开发工作的展开我们成立了多个工作组。我几乎参加了所有组的会议并逐渐对团队的整体努力有了全面的理解。自然而然地当社区成员有问题时我常常成为那个被询问的对象。大概基于这种积累我被邀请与Vijay Janapa Reddi、Carole-Jean Wu、Christine Cheng和Greg Diamos一同协助领导推理Inference工作组。这项工作我一直做到现在并担任推理基准的联合主席。3.1 基准测试开发的“脏活累活”开发一套公允的基准测试远非定义几个模型和数据集那么简单。它是一场在理想化标准与现实世界复杂性之间的持续博弈。我们早期就遇到一个典型问题卷积操作的“填充”Padding。卷积神经网络CNN中的卷积层在处理图像边缘时需要决定如何填充像素。是填0SAME填充还是直接丢弃边缘VALID填充虽然所有主流框架都支持卷积但默认的填充方式或可选模式可能存在细微差别。这会导致即使模型结构相同不同框架下的计算图和最终精度也可能有微小差异。我们的目标是支持多框架那么就必须决定是强制统一为一种填充方式可能对某个框架不公还是允许几种等效的填充模式这类问题在MLPerf中变得司空见惯。我们形成了一套应对流程。简单的问题比如允许几种公认等效的卷积填充方式通常由“提交工作组”讨论后快速裁决。而更复杂、更具争议的问题例如在机器翻译基准中是使用德语-英语还是英语-法语语料对则会提交给“专题工作组”。在那里一两名成员会花一两周时间通过实验或咨询领域专家深入研究后再提出建议方案。3.2 拥抱“最小可行产品”与快速迭代MLPerf的一个核心原则是快速开发和迭代这更像是软件工程而非传统硬件基准测试的做法。在机器学习领域这是必须的。新算法、新模型、新优化技术出现的速度远远超过一个“优雅而缓慢”的开发周期所能跟上的。我们最初学到的经验远比我们事先能预见到的挑战要多得多。因此我们刻意选择发布一个“最小可行产品”MVP并用版本号v0.5明确承认这一点。v0.5训练基准套件并不完美但它对工业界和学术界已经具有了实际意义和价值。它为我们赢得了发展势头、可信度以及无数宝贵的教训——而这些教训正是未来版本得以改进的基石。这个过程教会我如何评估早期那些乐观的愿景并将其精简为少数几个真正值得追求的关键要素。3.3 “勉强共识”下的协作艺术管理MLPerf这样一个多元化的团体本身就是一门学问。我们的成员来自专注于系统、芯片、IP、软件和服务的不同公司其中不少是直接竞争对手。每家公司的优先级和利益诉求都不尽相同。我们在MLPerf内部运作的原则是“勉强共识”。我们不指望每个决定都能让所有人满意但总体上我们希望大多数人感到满意并且确保没有人持续感到不满。这需要前瞻性以及极其强大和主动的沟通。决策过程是审慎的。它可能需要多轮讨论、征集反馈和投票——这似乎与我们“快速迭代”的原则有些矛盾——但由此产生的决策更加坚实、更经得起推敲。为了保持快速节奏作为领导者我们必须主动提出问题提前准备初步提案寻找志愿者并确保相关领域的专家参与。我们必须鼓励每个人表达观点尤其是那些我们预见到可能与普遍共识相左的意见。只有在所有观点都得到表达后我们才能找到有效的折中方案。当达成一个共识性的妥协后会由各公司的MLPerf代表带回内部审议。代表们反馈后我们可能会进行调整然后最终定案。在这个过程中领导者的角色不是决策者而是协调者确保每个人都能做出恰当的贡献。我花了相当长时间才适应这种角色它要求更多的倾听、归纳和引导而非直接给出技术答案。4. 攻坚克难MLPerf遇到的技术深水区基准测试的开发过程也是不断暴露机器学习系统底层复杂性的过程。我们遇到的挑战很多都超出了最初的设想迫使我们去挖掘集体智慧。4.1 大规模训练的收敛难题我们最初天真地认为只要提供了模型和数据集硬件厂商就能跑出结果。但很快发现在大规模分布式系统例如使用数百甚至上千个加速器上训练模型要保证其收敛到预期的精度本身就是一个巨大的研究课题。批量大小Batch Size、学习率Learning Rate、优化器选择如SGD, Adam之间的耦合关系在规模放大后会变得极其敏感。例如为了确保大规模提交的可行性我们不得不允许甚至鼓励使用像Adam这样基于动量的优化器并对相关超参数的调整范围进行界定。这不仅仅是“跑个分”而是涉及到深度学习优化理论的前沿。我们不得不与提交者紧密合作理解他们的调参策略确保其合规且可复现同时又不至于将基准测试变成纯粹的“调参竞赛”。4.2 框架差异性与行为统一支持多框架TensorFlow, PyTorch, MXNet等是我们的一个关键目标旨在保证公平性。但这带来了巨大的工程挑战。除了前面提到的填充问题更复杂的操作如翻译模型中的“束搜索”并非所有框架都原生支持或者实现的行为存在差异。我们的解决方案是定义“参考实现”。我们为每个基准任务提供了一套经过验证的、符合规范的代码实现通常基于某个主流框架。提交者可以选择基于参考实现进行优化也可以使用自己的实现但必须通过严格的“等效性测试”证明其输出结果不仅是最终精度有时还包括中间层的数值分布与参考实现在一定容差范围内是一致的。这套等效性验证机制的设计和实现本身就是一项艰巨的任务。4.3 推理基准的独特挑战与训练相比推理基准的制定又有其独特的复杂性这也是我作为推理工作组联合主席深度参与的部分。延迟与吞吐量的权衡推理场景下延迟Latency和吞吐量Throughput是核心指标且往往相互矛盾。一个优化了吞吐量的批处理系统单次查询的延迟可能很高。MLPerf推理基准要求同时报告在不同约束条件如目标延迟下的性能这更贴近真实应用场景如自动驾驶要求低延迟内容推荐可能更关注高吞吐量。精度与效率的博弈推理端广泛使用量化技术将FP32模型转换为INT8甚至更低精度来提升效率。但量化可能会带来精度损失。我们需要定义清晰的精度目标例如与FP32参考模型的精度差距必须在1%以内并设计相应的校准和验证流程。系统与芯片级测试推理不仅测试芯片本身还考验整个软件栈的效率包括运行时库、驱动程序、模型编译/优化工具链甚至操作系统调度。MLPerf推理基准允许提交“芯片级”结果仅测量加速器本身和“系统级”结果测量端到端应用性能以满足不同评估需求。5. 经验与洞察给技术从业者的建议回顾这段旅程我获得的远不止是对机器学习技术栈的理解。以下是一些可能对同行尤其是考虑参与开源标准或复杂协作项目的工程师们有价值的体会。5.1 主动承担“不起眼”的工作从担任会议记录员开始我得以快速了解全局。在任何一个协作项目中总有一些必要但大家都不太愿意做的工作比如文档、会议纪要、流程梳理。主动承担这些工作是建立信任、展示责任心并快速融入核心圈子的有效途径。它让你有机会听到所有讨论理解分歧的根源从而在后续提出更有建设性的意见。5.2 在快速迭代中寻找平衡MLPerf的“MVP快速迭代”哲学非常适用于当今快速变化的技术领域。不要试图一开始就设计出完美无缺的方案。先推出一个虽然简单但核心价值明确的版本获取反馈学习然后快速改进。关键在于版本迭代必须有清晰的规则和向后兼容性的考虑不能让早期采用者的努力白费。我们的版本号从v0.5到v0.7再到v1.0每个版本都在扩大测试范围、完善规则但核心的评估理念保持连贯。5.3 沟通是复杂协作的生命线在MLPerf我们依赖Slack、邮件列表、定期视频会议和线下峰会进行沟通。我学到的最重要一课是过度沟通好于沟通不足。对于任何可能影响多方的决定都要提前以书面形式提出给予充分的评论时间。会议不是为了争论而是为了对已充分讨论的提案做出决议。会后的纪要必须清晰记录决策内容、理由以及待办事项并分发给所有相关方。在跨公司、跨时区的协作中清晰的书面记录是无价的。5.4 理解并尊重多元动机参与MLPerf的成员其个人和公司的动机各不相同。学术研究者可能关注前沿探索和发表机会硬件公司希望展示其产品优势软件公司关心生态兼容性云服务商则看重端到端解决方案的表现。一个好的基准测试必须在一定程度上满足这些多元化的需求而不是被单一利益所主导。这要求参与者具备同理心能够从他人角度思考问题并在技术争论中寻找最大公约数。6. 面向未来MLPerf的演进与个人的召唤如今MLPerf已经发布了多个版本的训练和推理基准涵盖了从图像分类、目标检测、自然语言处理到推荐系统等多种负载。它已成为业界评估AI硬件和软件性能的事实标准之一。但工作远未结束。新的模型架构如Vision Transformer, Diffusion Models、新的计算范式如稀疏计算、图神经网络、新的系统考量如隐私保护下的联邦学习评估不断涌现。MLPerf需要持续演进增加新的基准改进现有基准并探索如能效、公平性、可解释性等更广泛的评估维度。对我个人而言这段经历是一次完美的“跨界”学习。它让我将对计算机架构的深刻理解与机器学习的软件和算法层面连接起来形成了一个更完整的系统视角。这种视角对于分析AI芯片的未来趋势、评估技术路线的优劣至关重要。所以我的建议与David Kanter在原文中的呼吁一致如果你对机器学习系统的性能评估感兴趣无论你是硬件工程师、软件开发者、研究员还是学生不要犹豫不要被看似高深的门槛吓退。MLPerf的仓库在GitHub上是公开的。你可以从阅读代码、复现现有结果开始理解基准测试的每一个细节。如果你发现了某个模型或框架的优化技巧可以尝试提交你的实现。社区始终欢迎新的贡献者。这个领域仍有无数未解决的问题而答案不会自动出现它需要更多人的好奇、投入和协作。参与像MLPerf这样的项目不仅仅是贡献代码更是参与到定义行业未来标准的进程中与最顶尖的同行一起亲手为这个快速发展的领域铺设轨道。这种经历所带来的技术视野、人脉网络和个人成长是任何单一公司内部工作都难以比拟的。