开发一个跨越时区、文化和技能的解决方案可能很困难。遵循这些核心原则来优化硬件和软件系统组件，有助于从一开始就取得最大成功。
您将学到什么？
- 硬件/软件协同设计的五项核心原则是什么？
- 这些原则如何帮助建立一个地域多元化的工程组织，在满足性能和开发进度目标的同时，成功开发复杂的解决方案？
硬件/软件协同设计旨在优化复杂电子系统的硬件和软件组件，同时满足项目的目标和设计限制（通常包括性能、成本和功耗）。
本文讨论了五项核心原则，这些原则帮助 Recogni 建立了一个地域多样化的工程组织，成功开发了机器学习（ML）芯片，同时实现了雄心勃勃的性能、功耗和开发进度目标。由于 ML 开发的非确定性，ML 软件是一个相当极端的软件案例。在这一独特软件领域的经验强调了上述五项核心原则中几项原则的重要性。
开发团队分布在两个位置：加州圣何塞和德国慕尼黑。圣何塞团队负责芯片和硬件设计、固件和软件开发以及数据采集和创建。慕尼黑团队负责开发与 ML 相关的软件，包括编译器以及从训练数据集到编译感知堆栈等必要的软件基础设施。
这种地理上的分离增加了使硬件和软件开发顺利融合的必要性和困难。这也使得硬件/软件协同设计的五项核心原则显得更加突出。
在讨论硬件/软件协同设计的五项核心原则之前，有必要先讨论并理解作为团队动态基础的两种不同的工程角色–硬件角色和软件角色。在这种情况下，我们开发团队的角色在某种程度上代表了各地的硬件/软件协同设计团队。
我们典型的芯片设计师是一位经验丰富的工程师，在其职业生涯中成功设计、测试并推出过许多芯片。这些工程师非常清楚他们工作的 “一次性 ”性质。重大硬件设计错误的后果是代价高昂的，包括硅设计成本的膨胀和额外设计迭代的宝贵时间损失。这些后果可能会导致一家初创公司夭折，从而使硬件设计团队倾向于保守的设计方法。
相反，我们典型的 ML 设计师只有五年或更短的工作经验，习惯于在一个非常有机、探索性和宽容的开发环境中工作。在某种程度上，这两个世界——硬件和软件——必须和谐共处，才能在预算范围内按时生产出理想的产品。
在某些基本方面，这两种角色是完全不同的，要把它们融合成一个专注的团队是非常困难的。然而，事实证明，将这两种不同的工程角色融合到一个协调一致的工程团队中，使其同步工作，是在最短的时间内开发出新的、创新的 ML 芯片的关键所在。五个核心原则指导着我们团队的建设和管理：
协同设计核心原则 1：确定性
硬件/软件协同开发的第一个核心原则是确定性。看待确定性的一种方法是提出这样一个问题：你对新任务（如实现新功能或新电路）的可预测性有多大信心？
某些工程学科——包括全栈软件工程、标准 CMOS 芯片设计和 PCB 设计——具有高度的确定性。高度确定性意味着，当需要应对新的工程挑战时，经验丰富的工程师或工程经理可以自信地预测开发时间表，说 “我以前做过这个”，或者至少说 “reddit 上的一个人实现过类似的东西”。
高度确定性并不意味着任务很容易完成。这项任务可能非常具有挑战性，可能需要非常熟练的工程师才能完成。但是，高水平的确定性意味着工程师或工程经理对完成任务所需的时间有更清晰的认识。换句话说，任务的依赖关系和关键路径都很清楚。
与此相反，一些工程学科（包括 ML 工程）在日常工作中普遍感觉到非确定性。即使神经网络堆栈在技术上是确定性的——相同的输入总是导致相同的输出——但最终产品的确定性却被淹没在 ML 网络纯粹、难以把握的复杂性和任意行为中。因此，ML 网络开发需要一种非常迭代的方法，这不是出于选择，而是出于必要。
当硬件/软件协同设计团队中的一部分人从事确定性较高的任务，而团队中的其他成员从事确定性较低的任务时，就会产生摩擦。克服这种潜在的摩擦根源，可以归结为移情互动。开发团队的双方都需要对对方的工作性质有高度的同理心。只有这样，才能实现硬件/软件协同设计的高度协同性和凝聚力，从而直接引出核心原则 2。
协同设计核心原则 2：沟通
当然，这并不是第一篇阐述开发团队成员之间良好沟通的重要性的文章。然而，在讨论硬件/软件协同设计时，我们了解到团队沟通的几个具体方面应该得到强调。
第一个方面是过度沟通的必要性。当面对一群想法迥异的人时，重复是极其重要的。重复、重复、再重复。
仅仅因为有人在三周前的站立会议上提到了某个缩写词的含义，并不能保证其他学科的团队成员也能内化该缩写词的理论含义和实际意义。即使是 “分割 ”这样一个简单的词，对于硬件芯片设计师和 ML 软件工程师来说，其含义也可能完全不同。
在大多数情况下，上下文可能会消除混淆，但密切相关的跨学科工程团队成员必须退一步，积极尝试设身处地地为团队中的同行着想。
另一个沟通挑战是心理上的。对一些团队成员来说，重复可能显得不自然，甚至是居高临下。团队成员必须克制自己的冲动，避免看似隐含的对抗或侮辱。最终目标应始终是清晰明了，团队成员在评估其他团队成员的沟通时应意识到这一点，并做出相应的调整。
另一个关键的沟通要素是将内部文档视为产品。完整、清晰的文档需求始于团队新成员的入职培训。要求清晰的内部文档从一开始就定下了正确的基调，从而形成一种非常合作、高度紧密的工作方式。
硬件/软件合作开发团队双方的可靠文档必须易于访问和查找。这里的沟通指导原则是 像对待亲密客户一样对待所有同事。为他们服务，与他们共鸣，与他们合作。
协同设计核心原则 3：管理
许多产品开发周期都包含由不同学科任务组成的关键路径，这些任务可能无法很好地同步。这种时间上的不匹配带来了挑战。例如，根据 Recogni 的经验，精确的时间产品化与 ML 不可避免且不可预测的迭代探索和创新需求并不匹配。
一个 ML 项目的复杂性突然从一个只需两周就能轻松完成的渐进式模型再训练任务急剧上升到一个全新的、从零开始的、涉及众多方面的、必须经过数月研究的项目，这种情况并不少见。
解决这种时间上的不匹配需要两个关键要素：
项目管理人员必须深刻理解所有相关学科各自的性质和面临的挑战，项目时间表必须略微保守一些，以考虑到重大的关键路径干扰。
管理包括 ML 工程师在内的混合团队的技术主管需要明白，细节决定成败，采取小步快跑的方式并反思抽象层带来的挑战对于成功完成项目至关重要。
例如，设想硅团队希望评估为新指令编写支持的价值，以支持新型神经网络架构。ML 团队应该怎么做？当然是测试新架构。然而，在 ML 领域，事情并不像最初看起来那么简单或明显。
例如，以下是发生在 Recogni 开发团队身上的一系列事件。发现了一篇附带代码的远程相关论文，这表明特定的 ML 堆栈可以使目标产品受益。更妙的是，已经在开发中的目标技术可以高效地执行这个新的 ML 栈。在这一点上，论文中的新 ML 堆栈似乎是天作之合。
然而，也许 100 多个超参数中的一个参数就能完全毁掉一个 ML 模型的性能，让设计团队基于错误的结论走上错误的道路。一个超参数值从 0.01 到 0.002 的非明显变化突然让 ML 堆栈起作用了，就像变魔术一样。欢迎来到变幻莫测的 ML 世界。
应对这一挑战的办法是采取 “小步快跑 ”的方式，而很多人都低估了这一点，尤其是那些刚刚接触 ML 的人，或者那些在过去几年中一直从事确定性更强、更容易掌握的工程学科的人。一开始就大干快上的 ML 开发团队可能会被调试淹没。大多数情况下，通往 ML 成功的最快途径是从小规模开始。
协同设计核心原则 4：谨防抽象化
任何严肃的产品级 ML 开发环境都需要抽象，因为抽象可以实现可扩展性。然而，抽象往往会带来被低估的风险，即错误地暗示自动性和通用性。
例如，原则 3 中设置错误的超参数之所以被设置为 0.01，可能只是因为一个模块长期以来一直是环境的一部分，导致开发人员认为超参数在这种设置下 “就是有效的”。毕竟，该设置确实有效了数月或数年，因此这并不是一个糟糕的假设。
然而，长期成功地使用这种设置，使得人们逐渐淡忘了 ML 模型对该超参数的重大敏感性。要在每次开发新产品时测试每一个 ML 超参数设置，这在经济上是不可行的。
对所有抽象层的适应性水平进行持续不断的反思，最好辅以一系列随机、经常性和自动化的端到端单元测试，有助于最大限度地降低与抽象相关的风险。
协同设计核心原则 5：范围与重点
我们有意识地决定创建一家公司，建立端到端参考系统，涵盖从汽车传感器到自捕获数据、芯片设计、神经网络设计、编译工具链、可视化等设计的各个方面，这是有充分理由的。这种全面的范围使我们的核心团队能够在一个完整的端到端系统中开发各自的堆栈部分，而不是孤立地进行开发。
由于设计范围广泛，团队可以观察到其工作在系统级的影响。然而，范围的扩大还带来了额外的好处：它为我们的团队创造了一个内部共享的叙事方式。所有硬件/软件开发团队都需要这种共同的叙述方式。
例如，对于开发 ML 处理芯片的公司来说，将图像传感器集成到参考平台中，理论上不应该是一个困难的要求。
对于硬件芯片设计师来说，图像传感器是一块嵌入式电子元件，他们必须在物理和逻辑上与之连接。对于 ML 感知工程师来说，传感器是神经网络输入层的数据源，而不是使用可能导致次优设计的合成数据集。物理传感器可生成真实世界的数据集，作为硬件工程师和 ML 开发人员之间共鸣互动的基础。
结论
这五项核心原则应融入每个硬件/软件开发项目中。正如我们在 Recogni 发现的那样，它们在 ML 开发领域尤为重要。这些核心原则旨在强调不同开发团队之间的沟通和共鸣，从项目开始到整个项目过程，直至项目结束。
遵守这些原则并不能保证成功。这中间还有很多艰苦的工作要做。但是，采用这些原则并将其付诸实践，就能为硬件/软件合作开发团队提供及时实现最终目标的机会。
作者：Gilles Backhus，Recogni联合创始人兼人工智能副总裁，Gilles Backhus 的职业生涯专注于实时人工智能开发，致力于解决世界上最重要的技术挑战。
来源：虚拟原型 Virtual Prototyping 2024年07月25日