1. 从“能跑”到“跑得动”AI芯片软硬件协同设计的真实门槛很多人第一次接触AI芯片设计脑子里想的都是算力数字——多少TOPS、多少TFLOPS、支持什么精度。但真正做过一轮完整流片的人都知道算力只是纸面参数决定一颗芯片能不能用的是软硬件之间那条看不见的“配合链路”。我见过太多项目硬件指标漂亮得不行结果编译器跑不通、算子覆盖率不到六成、实际推理延迟是理论值的七八倍最后只能降频使用或者干脆换方案。这一篇要聊的就是AI芯片软硬件设计里最容易被低估的那部分——软硬件协同设计。它不是一个具体的工具或者某一行代码而是一整套从架构定义阶段就要开始考虑的方法论。适合谁看如果你正在做AI加速器的架构设计、编译器开发、算子库适配或者你是一个想从纯软件转向芯片领域的工程师这里面的经验应该能帮你少走不少弯路。我个人的背景偏系统软件侧但过去几年深度参与过几个AI加速项目的软硬件联调踩过的坑从指令集定义一直延伸到运行时调度。下面这些内容一部分来自实际项目复盘一部分来自和硬件同事反复争论后达成的共识。我会尽量把“为什么这么设计”讲清楚因为AI芯片这个领域脱离场景谈架构基本等于空谈。2. 软硬件协同到底在协同什么三个层次的耦合关系2.1 第一层指令集与编程模型的耦合AI芯片的指令集和通用CPU完全不是一个思路。CPU的指令集设计追求通用性和正交性而AI芯片的指令集往往围绕张量操作和数据搬运来组织。这里第一个要做的决策就是编程模型是偏向硬件的显式控制还是偏向软件的隐式描述显式控制的典型代表是指令级并行加手动DMA程序员或者编译器需要明确指定数据从哪搬到哪、什么时候开始计算、什么时候同步。这种方式的优点是硬件利用率高、延迟可预测缺点是编程复杂度极高编译器优化空间有限。隐式描述则是用类似Tensor IR的方式表达计算由编译器负责映射到硬件资源上编程友好但编译器负担重且容易出现“编译器以为的硬件行为”和“实际硬件行为”不一致的情况。我参与过的一个项目最初选择了显式控制路线理由是团队硬件背景强、对性能把控有信心。结果到了算子适配阶段光是卷积的几种变体就写了十几套手写调度维护成本爆炸。后来不得不引入一层中间表示来抽象相当于在显式和隐式之间找了一个折中。这个教训很直接指令集设计阶段就要想清楚编译器的能力边界不能等到硬件定型了再让软件团队去“硬适配”。2.2 第二层存储层次与数据流的耦合AI芯片的存储层次设计直接决定了数据搬运的开销。通用处理器的缓存层次是透明的硬件自动管理但AI芯片往往有显式的片上存储比如SRAM scratchpad需要软件或编译器来管理数据放置。这里有一个很关键的权衡片上存储越大能容纳的中间结果越多数据搬运越少但面积和功耗成本越高。我见过一个设计片上SRAM给了很大的容量结果发现大部分算子根本用不满反而因为SRAM的访问延迟和bank冲突问题导致性能不如预期。后来分析发现问题出在数据流设计上——算子的切分方式和存储层次不匹配导致数据在片上反复搬运SRAM容量大反而成了负担。正确的做法是先分析目标算子集的数据复用模式确定哪些数据需要常驻片上、哪些可以流式通过、哪些必须回写到外部存储。然后根据这个分析来反推存储层次的大小和带宽。这个过程需要软件团队和硬件团队坐在一起用真实的算子trace来驱动决策而不是拍脑袋定参数。2.3 第三层运行时调度与硬件资源的耦合运行时调度是软硬件协同里最“脏”的部分。硬件资源是固定的但实际负载是动态的。多租户场景下多个推理任务可能同时到达如何分配计算单元、如何管理内存、如何保证公平性和实时性这些都需要运行时系统来处理。我遇到过一个典型问题硬件支持多任务并行但运行时调度器是按顺序分配资源的导致并行度上不去。后来改成基于优先级的抢占式调度又发现上下文切换的开销比预期大很多因为片上存储的状态保存和恢复需要搬运大量数据。最终的方案是做了一个折中——对高优先级任务保留硬件上下文快速切换的能力对低优先级任务则采用批处理方式减少切换频率。这个例子说明运行时调度策略必须和硬件的中断机制、上下文保存能力一起设计。如果硬件不支持快速上下文切换软件层面的抢占式调度就是空中楼阁。3. 编译器在AI芯片上的真实处境不只是翻译3.1 算子覆盖率编译器团队最头疼的KPI如果你问一个AI芯片编译器团队的负责人最关心什么指标大概率不是编译速度而是算子覆盖率。所谓算子覆盖率就是目标模型中的算子有多少能被编译器正确且高效地编译到硬件上。现实情况是一个主流深度学习模型可能包含几百种算子变体而编译器团队的人力永远有限。我见过一个项目编译器初期只支持了三十几个核心算子结果客户拿了一个包含自定义算子的模型过来直接跑不通。后来不得不加了一个“回退到CPU”的机制但性能惨不忍睹。提高算子覆盖率的策略有几个方向。一是算子融合把多个小算子合并成一个大的计算图节点减少编译和调度的开销。二是自动代码生成用模板化的方式覆盖常见算子模式减少手写工作量。三是开放自定义算子接口让用户能够用DSL描述自己的算子编译器负责映射。这三条路各有代价算子融合可能限制调度灵活性自动代码生成可能产生冗余代码开放接口则增加了编译器的复杂度和验证成本。我的经验是在项目初期就要明确算子覆盖的目标范围是只支持主流模型的常见算子还是要支持任意自定义算子。这个决策直接影响编译器的架构设计。如果目标是后者那从一开始就要把可扩展性放在第一位哪怕牺牲一些初期性能。3.2 内存分配编译器最容易翻车的地方AI芯片的片上存储通常不大编译器需要精确地分配每一块内存。这里最常见的问题是内存碎片和bank冲突。内存碎片好理解就是分配和释放的顺序导致大块连续内存被切碎后续的大张量分配不进去。解决办法通常是做静态内存规划在编译期就确定所有张量的生命周期和内存布局避免运行时动态分配。但静态规划的代价是灵活性差遇到动态shape的模型就麻烦了。Bank冲突则更隐蔽。片上SRAM通常分成多个bank如果多个计算单元同时访问同一个bank就会产生冲突导致访问延迟增加。编译器在做内存分配时需要把频繁同时访问的数据分散到不同bank上。这个优化需要编译器理解硬件的bank结构和访问模式属于典型的软硬件协同优化点。我踩过的一个坑是编译器在做内存规划时只考虑了容量约束没有考虑bank冲突结果仿真时性能只有预期的60%。后来在内存分配算法里加入了bank-aware的约束性能才回到正常水平。这个教训是编译器的内存分配必须把硬件微架构参数作为一等公民不能只当成一个容量问题。3.3 调度与流水线让硬件跑满的艺术AI芯片的性能很大程度上取决于流水线的效率。编译器需要把计算任务划分成多个阶段让数据加载、计算、结果写回能够重叠执行。理想情况下硬件应该像一条满载的流水线每个周期都有有效工作。但现实往往不理想。常见的问题包括数据依赖导致流水线停顿、资源冲突导致某些阶段成为瓶颈、同步开销吃掉并行收益。编译器需要做指令调度、软件流水、循环展开等一系列优化来缓解这些问题。这里有一个反直觉的经验过度优化有时反而会降低性能。我见过一个编译器为了追求极致的指令级并行把循环展开得太大导致指令缓存溢出取指成为瓶颈。后来减少了展开因子性能反而提升了。这说明编译器优化需要有一个全局视角不能只盯着局部指标。4. 硬件设计阶段就要回答的软件问题4.1 MAC阵列的尺寸不是越大越好MAC乘累加阵列是AI芯片的计算核心它的尺寸设计是一个典型的软硬件权衡问题。阵列越大峰值算力越高但灵活性越差对小算子的利用率越低。举个例子一个256x256的MAC阵列在处理大矩阵乘法时效率很高但遇到卷积核较小的层可能只有部分阵列被利用。而一个64x64的阵列虽然峰值算力低但对各种尺寸的算子适应性更好。怎么选我的建议是根据目标模型的计算分布来决定。先统计目标模型集中各层的矩阵维度分布然后选择一个能够覆盖主要计算量的阵列尺寸。如果目标模型以大矩阵为主那就选大阵列如果模型比较杂那就选中等尺寸加灵活的切分机制。还有一个容易被忽略的点MAC阵列的尺寸要和存储带宽匹配。如果阵列很大但数据供给跟不上阵列就会饿死。我见过一个设计算力密度很高但片上存储带宽不足实际利用率不到30%。后来重新平衡了算力和带宽的比例利用率才提上去。4.2 数据精度的选择不是越低越好AI芯片支持的数据精度越来越多从FP32到FP16到INT8甚至INT4。精度越低算力越高、功耗越低但模型精度损失也越大。这里的关键问题是哪些层可以降精度哪些层必须保持高精度。通常的做法是做精度敏感度分析逐层测试不同精度下的模型准确率变化。对精度不敏感的层用低精度敏感的层保持高精度。但硬件设计不能只考虑一种精度。如果硬件只支持INT8那遇到需要FP16的层就没办法了。所以现在的AI芯片通常支持混合精度但混合精度的硬件设计复杂度很高需要处理不同精度之间的转换和对齐。我的经验是在硬件设计阶段就要确定精度支持的组合方式。是每种精度独立计算还是支持混合精度流水线独立计算的设计简单但灵活性差混合精度流水线灵活但验证复杂度高。这个决策需要和软件团队一起做因为编译器需要知道硬件支持哪些精度组合才能生成正确的代码。4.3 片上网络的拓扑结构决定多核扩展性当AI芯片从单核走向多核片上网络NoC的设计就变得至关重要。NoC的拓扑结构决定了核间通信的带宽和延迟直接影响多核扩展的效率。常见的拓扑包括总线、环形、网格和交叉开关。总线结构简单但扩展性差核多了之后带宽成为瓶颈。环形结构扩展性好一些但延迟随核数增加而增加。网格结构适合二维扩展但路由算法复杂。交叉开关带宽最高但面积和功耗成本随核数平方增长。选择哪种拓扑取决于目标工作负载的通信模式。如果模型主要是数据并行核间通信少那简单的总线或环形就够了。如果模型有大量的模型并行或者需要频繁的核间同步那就需要更高带宽的NoC。我参与过的一个多核项目最初用了环形NoC结果发现某些层的all-reduce操作成为瓶颈。后来改成了网格加层次化路由性能提升明显。这个经验是NoC设计必须基于真实的通信trace不能凭直觉选拓扑。5. 软硬件联调阶段的典型问题与排查思路5.1 功能对不上从仿真到硅后的差异定位软硬件联调最让人崩溃的就是功能对不上。仿真时一切正常到了FPGA原型或者硅后结果就是不对。这时候需要一套系统的排查方法。第一步是缩小范围。把问题定位到具体的算子或者具体的层。方法是用一个极简的模型比如单层卷积跑测试确认基础功能是否正常。如果单层正常再逐步增加层数直到复现问题。第二步是对比中间结果。在软件参考实现和硬件执行之间逐层对比中间张量的数值。差异可能来自计算精度、数据布局、或者同步问题。我遇到过一个案例差异出现在某个特定的通道数上后来发现是硬件在处理非对齐通道时的边界条件有bug。第三步是检查数据搬运。很多功能问题其实出在数据搬运上比如DMA配置错误、地址对齐问题、或者缓存一致性问题。用硬件调试器抓取数据搬运的trace对比预期行为往往能快速定位。5.2 性能不达标从瓶颈分析到优化落地性能不达标是另一个常见问题。理论算力很高实际跑起来只有零头。这时候需要做瓶颈分析。首先看计算利用率。如果计算单元大部分时间空闲那瓶颈可能在数据供给或者调度上。用性能计数器统计计算单元的活跃周期如果活跃度低就去看存储带宽和DMA效率。其次看存储带宽利用率。如果带宽跑满了但计算单元还是饿着那可能是数据复用没做好需要优化数据流或者增加片上存储。最后看同步开销。多核或者多流水线之间的同步如果太频繁开销会吃掉并行收益。这时候需要优化调度策略减少不必要的同步。我踩过的一个坑是性能分析时只看了平均值没看分布。后来发现某些层的延迟特别高拉低了整体性能。针对这些热点层做优化后整体性能提升了一倍多。所以性能分析一定要看分布不能只看均值。5.3 精度损失从数值分析到硬件修正精度损失是AI芯片特有的问题。低精度计算、近似计算、累加顺序不同都可能导致最终结果和软件参考不一致。排查精度问题首先要确定可接受的误差范围。不同的应用对精度的要求不同分类任务可能容忍1%的准确率下降但检测任务可能对某些关键数值非常敏感。然后要逐层分析误差来源。是量化误差、累加误差、还是激活函数的近似误差用高精度参考实现逐层对比找到误差最大的层然后针对性地调整。硬件层面的修正手段包括增加累加器位宽、调整量化策略、优化激活函数的近似算法。但要注意精度和性能往往是对立的提高精度可能意味着降低算力或者增加功耗。所以需要在精度和性能之间找到一个平衡点这个平衡点应该由应用需求来决定而不是由硬件团队单方面决定。6. 一个可复用的软硬件协同设计检查清单6.1 架构定义阶段的必问问题在架构定义阶段软件团队和硬件团队需要一起回答以下问题目标模型集是什么主要算子的计算特征和数据复用模式是什么编程模型是显式控制还是隐式描述编译器的能力边界在哪里片上存储的层次和容量如何设计数据流如何规划支持哪些数据精度混合精度的处理方式是什么多核扩展的通信模式是什么NoC拓扑如何选择运行时调度的策略是什么硬件需要提供哪些支持这些问题没有标准答案但必须要有明确的答案。我见过太多项目硬件团队先定架构软件团队后适配结果就是各种拧巴。正确的做法是软硬件团队从第一天就坐在一起用真实的模型和算子trace来驱动架构决策。6.2 开发阶段的协同节奏开发阶段最大的挑战是软硬件进度不同步。硬件流片周期长软件需要提前在仿真器或者FPGA上开发。这时候需要一个好的仿真环境能够尽可能准确地模拟硬件行为。我的建议是仿真器的精度和速度要分阶段权衡。早期可以用高层仿真快速验证功能后期需要用周期精确的仿真来验证性能。但周期精确仿真很慢不能所有测试都用它。所以需要建立一个分层的验证体系不同阶段用不同的仿真精度。另外软件团队要尽早介入硬件验证。不要等硬件流片回来再开始软件适配那时候发现问题就晚了。在FPGA原型阶段就应该跑真实的模型发现的问题可以反馈到硬件设计中进行修正。6.3 流片后的优化空间流片后硬件就固定了但软件优化还有很大空间。常见的优化方向包括算子融合把多个算子合并减少数据搬运和调度开销。内存布局优化调整张量的内存布局减少bank冲突和访问延迟。调度策略优化根据实际负载动态调整调度策略提高硬件利用率。精度自适应根据层的敏感度动态选择精度在精度和性能之间找平衡。这些优化不需要改硬件但需要深入理解硬件微架构和软件栈。我见过一个项目流片后通过软件优化把性能提升了40%这说明软硬件协同设计不是一次性的而是一个持续的过程。7. 写在最后一些个人体会做AI芯片的软硬件协同设计最深的体会是没有完美的架构只有合适的权衡。每一个设计决策都有代价关键是要知道代价是什么以及这个代价是否可接受。另一个体会是沟通比技术更重要。软硬件团队之间的信息不对称是很多问题的根源。硬件团队觉得软件团队应该能适配软件团队觉得硬件团队应该提供更好的支持。解决这个问题的唯一办法就是坐下来用数据说话用真实的模型和trace来驱动决策。最后如果你正在做AI芯片相关的工作我的建议是不要只盯着算力数字。算力只是起点真正决定芯片价值的是软硬件协同的效率。一个算力中等但软硬件配合默契的芯片往往比一个算力很高但软件跑不动的芯片更有竞争力。这个道理我在实际项目中反复验证过。
1. 从“能跑”到“跑得动”AI芯片软硬件协同设计的真实门槛很多人第一次接触AI芯片设计脑子里想的都是算力数字——多少TOPS、多少TFLOPS、支持什么精度。但真正做过一轮完整流片的人都知道算力只是纸面参数决定一颗芯片能不能用的是软硬件之间那条看不见的“配合链路”。我见过太多项目硬件指标漂亮得不行结果编译器跑不通、算子覆盖率不到六成、实际推理延迟是理论值的七八倍最后只能降频使用或者干脆换方案。这一篇要聊的就是AI芯片软硬件设计里最容易被低估的那部分——软硬件协同设计。它不是一个具体的工具或者某一行代码而是一整套从架构定义阶段就要开始考虑的方法论。适合谁看如果你正在做AI加速器的架构设计、编译器开发、算子库适配或者你是一个想从纯软件转向芯片领域的工程师这里面的经验应该能帮你少走不少弯路。我个人的背景偏系统软件侧但过去几年深度参与过几个AI加速项目的软硬件联调踩过的坑从指令集定义一直延伸到运行时调度。下面这些内容一部分来自实际项目复盘一部分来自和硬件同事反复争论后达成的共识。我会尽量把“为什么这么设计”讲清楚因为AI芯片这个领域脱离场景谈架构基本等于空谈。2. 软硬件协同到底在协同什么三个层次的耦合关系2.1 第一层指令集与编程模型的耦合AI芯片的指令集和通用CPU完全不是一个思路。CPU的指令集设计追求通用性和正交性而AI芯片的指令集往往围绕张量操作和数据搬运来组织。这里第一个要做的决策就是编程模型是偏向硬件的显式控制还是偏向软件的隐式描述显式控制的典型代表是指令级并行加手动DMA程序员或者编译器需要明确指定数据从哪搬到哪、什么时候开始计算、什么时候同步。这种方式的优点是硬件利用率高、延迟可预测缺点是编程复杂度极高编译器优化空间有限。隐式描述则是用类似Tensor IR的方式表达计算由编译器负责映射到硬件资源上编程友好但编译器负担重且容易出现“编译器以为的硬件行为”和“实际硬件行为”不一致的情况。我参与过的一个项目最初选择了显式控制路线理由是团队硬件背景强、对性能把控有信心。结果到了算子适配阶段光是卷积的几种变体就写了十几套手写调度维护成本爆炸。后来不得不引入一层中间表示来抽象相当于在显式和隐式之间找了一个折中。这个教训很直接指令集设计阶段就要想清楚编译器的能力边界不能等到硬件定型了再让软件团队去“硬适配”。2.2 第二层存储层次与数据流的耦合AI芯片的存储层次设计直接决定了数据搬运的开销。通用处理器的缓存层次是透明的硬件自动管理但AI芯片往往有显式的片上存储比如SRAM scratchpad需要软件或编译器来管理数据放置。这里有一个很关键的权衡片上存储越大能容纳的中间结果越多数据搬运越少但面积和功耗成本越高。我见过一个设计片上SRAM给了很大的容量结果发现大部分算子根本用不满反而因为SRAM的访问延迟和bank冲突问题导致性能不如预期。后来分析发现问题出在数据流设计上——算子的切分方式和存储层次不匹配导致数据在片上反复搬运SRAM容量大反而成了负担。正确的做法是先分析目标算子集的数据复用模式确定哪些数据需要常驻片上、哪些可以流式通过、哪些必须回写到外部存储。然后根据这个分析来反推存储层次的大小和带宽。这个过程需要软件团队和硬件团队坐在一起用真实的算子trace来驱动决策而不是拍脑袋定参数。2.3 第三层运行时调度与硬件资源的耦合运行时调度是软硬件协同里最“脏”的部分。硬件资源是固定的但实际负载是动态的。多租户场景下多个推理任务可能同时到达如何分配计算单元、如何管理内存、如何保证公平性和实时性这些都需要运行时系统来处理。我遇到过一个典型问题硬件支持多任务并行但运行时调度器是按顺序分配资源的导致并行度上不去。后来改成基于优先级的抢占式调度又发现上下文切换的开销比预期大很多因为片上存储的状态保存和恢复需要搬运大量数据。最终的方案是做了一个折中——对高优先级任务保留硬件上下文快速切换的能力对低优先级任务则采用批处理方式减少切换频率。这个例子说明运行时调度策略必须和硬件的中断机制、上下文保存能力一起设计。如果硬件不支持快速上下文切换软件层面的抢占式调度就是空中楼阁。3. 编译器在AI芯片上的真实处境不只是翻译3.1 算子覆盖率编译器团队最头疼的KPI如果你问一个AI芯片编译器团队的负责人最关心什么指标大概率不是编译速度而是算子覆盖率。所谓算子覆盖率就是目标模型中的算子有多少能被编译器正确且高效地编译到硬件上。现实情况是一个主流深度学习模型可能包含几百种算子变体而编译器团队的人力永远有限。我见过一个项目编译器初期只支持了三十几个核心算子结果客户拿了一个包含自定义算子的模型过来直接跑不通。后来不得不加了一个“回退到CPU”的机制但性能惨不忍睹。提高算子覆盖率的策略有几个方向。一是算子融合把多个小算子合并成一个大的计算图节点减少编译和调度的开销。二是自动代码生成用模板化的方式覆盖常见算子模式减少手写工作量。三是开放自定义算子接口让用户能够用DSL描述自己的算子编译器负责映射。这三条路各有代价算子融合可能限制调度灵活性自动代码生成可能产生冗余代码开放接口则增加了编译器的复杂度和验证成本。我的经验是在项目初期就要明确算子覆盖的目标范围是只支持主流模型的常见算子还是要支持任意自定义算子。这个决策直接影响编译器的架构设计。如果目标是后者那从一开始就要把可扩展性放在第一位哪怕牺牲一些初期性能。3.2 内存分配编译器最容易翻车的地方AI芯片的片上存储通常不大编译器需要精确地分配每一块内存。这里最常见的问题是内存碎片和bank冲突。内存碎片好理解就是分配和释放的顺序导致大块连续内存被切碎后续的大张量分配不进去。解决办法通常是做静态内存规划在编译期就确定所有张量的生命周期和内存布局避免运行时动态分配。但静态规划的代价是灵活性差遇到动态shape的模型就麻烦了。Bank冲突则更隐蔽。片上SRAM通常分成多个bank如果多个计算单元同时访问同一个bank就会产生冲突导致访问延迟增加。编译器在做内存分配时需要把频繁同时访问的数据分散到不同bank上。这个优化需要编译器理解硬件的bank结构和访问模式属于典型的软硬件协同优化点。我踩过的一个坑是编译器在做内存规划时只考虑了容量约束没有考虑bank冲突结果仿真时性能只有预期的60%。后来在内存分配算法里加入了bank-aware的约束性能才回到正常水平。这个教训是编译器的内存分配必须把硬件微架构参数作为一等公民不能只当成一个容量问题。3.3 调度与流水线让硬件跑满的艺术AI芯片的性能很大程度上取决于流水线的效率。编译器需要把计算任务划分成多个阶段让数据加载、计算、结果写回能够重叠执行。理想情况下硬件应该像一条满载的流水线每个周期都有有效工作。但现实往往不理想。常见的问题包括数据依赖导致流水线停顿、资源冲突导致某些阶段成为瓶颈、同步开销吃掉并行收益。编译器需要做指令调度、软件流水、循环展开等一系列优化来缓解这些问题。这里有一个反直觉的经验过度优化有时反而会降低性能。我见过一个编译器为了追求极致的指令级并行把循环展开得太大导致指令缓存溢出取指成为瓶颈。后来减少了展开因子性能反而提升了。这说明编译器优化需要有一个全局视角不能只盯着局部指标。4. 硬件设计阶段就要回答的软件问题4.1 MAC阵列的尺寸不是越大越好MAC乘累加阵列是AI芯片的计算核心它的尺寸设计是一个典型的软硬件权衡问题。阵列越大峰值算力越高但灵活性越差对小算子的利用率越低。举个例子一个256x256的MAC阵列在处理大矩阵乘法时效率很高但遇到卷积核较小的层可能只有部分阵列被利用。而一个64x64的阵列虽然峰值算力低但对各种尺寸的算子适应性更好。怎么选我的建议是根据目标模型的计算分布来决定。先统计目标模型集中各层的矩阵维度分布然后选择一个能够覆盖主要计算量的阵列尺寸。如果目标模型以大矩阵为主那就选大阵列如果模型比较杂那就选中等尺寸加灵活的切分机制。还有一个容易被忽略的点MAC阵列的尺寸要和存储带宽匹配。如果阵列很大但数据供给跟不上阵列就会饿死。我见过一个设计算力密度很高但片上存储带宽不足实际利用率不到30%。后来重新平衡了算力和带宽的比例利用率才提上去。4.2 数据精度的选择不是越低越好AI芯片支持的数据精度越来越多从FP32到FP16到INT8甚至INT4。精度越低算力越高、功耗越低但模型精度损失也越大。这里的关键问题是哪些层可以降精度哪些层必须保持高精度。通常的做法是做精度敏感度分析逐层测试不同精度下的模型准确率变化。对精度不敏感的层用低精度敏感的层保持高精度。但硬件设计不能只考虑一种精度。如果硬件只支持INT8那遇到需要FP16的层就没办法了。所以现在的AI芯片通常支持混合精度但混合精度的硬件设计复杂度很高需要处理不同精度之间的转换和对齐。我的经验是在硬件设计阶段就要确定精度支持的组合方式。是每种精度独立计算还是支持混合精度流水线独立计算的设计简单但灵活性差混合精度流水线灵活但验证复杂度高。这个决策需要和软件团队一起做因为编译器需要知道硬件支持哪些精度组合才能生成正确的代码。4.3 片上网络的拓扑结构决定多核扩展性当AI芯片从单核走向多核片上网络NoC的设计就变得至关重要。NoC的拓扑结构决定了核间通信的带宽和延迟直接影响多核扩展的效率。常见的拓扑包括总线、环形、网格和交叉开关。总线结构简单但扩展性差核多了之后带宽成为瓶颈。环形结构扩展性好一些但延迟随核数增加而增加。网格结构适合二维扩展但路由算法复杂。交叉开关带宽最高但面积和功耗成本随核数平方增长。选择哪种拓扑取决于目标工作负载的通信模式。如果模型主要是数据并行核间通信少那简单的总线或环形就够了。如果模型有大量的模型并行或者需要频繁的核间同步那就需要更高带宽的NoC。我参与过的一个多核项目最初用了环形NoC结果发现某些层的all-reduce操作成为瓶颈。后来改成了网格加层次化路由性能提升明显。这个经验是NoC设计必须基于真实的通信trace不能凭直觉选拓扑。5. 软硬件联调阶段的典型问题与排查思路5.1 功能对不上从仿真到硅后的差异定位软硬件联调最让人崩溃的就是功能对不上。仿真时一切正常到了FPGA原型或者硅后结果就是不对。这时候需要一套系统的排查方法。第一步是缩小范围。把问题定位到具体的算子或者具体的层。方法是用一个极简的模型比如单层卷积跑测试确认基础功能是否正常。如果单层正常再逐步增加层数直到复现问题。第二步是对比中间结果。在软件参考实现和硬件执行之间逐层对比中间张量的数值。差异可能来自计算精度、数据布局、或者同步问题。我遇到过一个案例差异出现在某个特定的通道数上后来发现是硬件在处理非对齐通道时的边界条件有bug。第三步是检查数据搬运。很多功能问题其实出在数据搬运上比如DMA配置错误、地址对齐问题、或者缓存一致性问题。用硬件调试器抓取数据搬运的trace对比预期行为往往能快速定位。5.2 性能不达标从瓶颈分析到优化落地性能不达标是另一个常见问题。理论算力很高实际跑起来只有零头。这时候需要做瓶颈分析。首先看计算利用率。如果计算单元大部分时间空闲那瓶颈可能在数据供给或者调度上。用性能计数器统计计算单元的活跃周期如果活跃度低就去看存储带宽和DMA效率。其次看存储带宽利用率。如果带宽跑满了但计算单元还是饿着那可能是数据复用没做好需要优化数据流或者增加片上存储。最后看同步开销。多核或者多流水线之间的同步如果太频繁开销会吃掉并行收益。这时候需要优化调度策略减少不必要的同步。我踩过的一个坑是性能分析时只看了平均值没看分布。后来发现某些层的延迟特别高拉低了整体性能。针对这些热点层做优化后整体性能提升了一倍多。所以性能分析一定要看分布不能只看均值。5.3 精度损失从数值分析到硬件修正精度损失是AI芯片特有的问题。低精度计算、近似计算、累加顺序不同都可能导致最终结果和软件参考不一致。排查精度问题首先要确定可接受的误差范围。不同的应用对精度的要求不同分类任务可能容忍1%的准确率下降但检测任务可能对某些关键数值非常敏感。然后要逐层分析误差来源。是量化误差、累加误差、还是激活函数的近似误差用高精度参考实现逐层对比找到误差最大的层然后针对性地调整。硬件层面的修正手段包括增加累加器位宽、调整量化策略、优化激活函数的近似算法。但要注意精度和性能往往是对立的提高精度可能意味着降低算力或者增加功耗。所以需要在精度和性能之间找到一个平衡点这个平衡点应该由应用需求来决定而不是由硬件团队单方面决定。6. 一个可复用的软硬件协同设计检查清单6.1 架构定义阶段的必问问题在架构定义阶段软件团队和硬件团队需要一起回答以下问题目标模型集是什么主要算子的计算特征和数据复用模式是什么编程模型是显式控制还是隐式描述编译器的能力边界在哪里片上存储的层次和容量如何设计数据流如何规划支持哪些数据精度混合精度的处理方式是什么多核扩展的通信模式是什么NoC拓扑如何选择运行时调度的策略是什么硬件需要提供哪些支持这些问题没有标准答案但必须要有明确的答案。我见过太多项目硬件团队先定架构软件团队后适配结果就是各种拧巴。正确的做法是软硬件团队从第一天就坐在一起用真实的模型和算子trace来驱动架构决策。6.2 开发阶段的协同节奏开发阶段最大的挑战是软硬件进度不同步。硬件流片周期长软件需要提前在仿真器或者FPGA上开发。这时候需要一个好的仿真环境能够尽可能准确地模拟硬件行为。我的建议是仿真器的精度和速度要分阶段权衡。早期可以用高层仿真快速验证功能后期需要用周期精确的仿真来验证性能。但周期精确仿真很慢不能所有测试都用它。所以需要建立一个分层的验证体系不同阶段用不同的仿真精度。另外软件团队要尽早介入硬件验证。不要等硬件流片回来再开始软件适配那时候发现问题就晚了。在FPGA原型阶段就应该跑真实的模型发现的问题可以反馈到硬件设计中进行修正。6.3 流片后的优化空间流片后硬件就固定了但软件优化还有很大空间。常见的优化方向包括算子融合把多个算子合并减少数据搬运和调度开销。内存布局优化调整张量的内存布局减少bank冲突和访问延迟。调度策略优化根据实际负载动态调整调度策略提高硬件利用率。精度自适应根据层的敏感度动态选择精度在精度和性能之间找平衡。这些优化不需要改硬件但需要深入理解硬件微架构和软件栈。我见过一个项目流片后通过软件优化把性能提升了40%这说明软硬件协同设计不是一次性的而是一个持续的过程。7. 写在最后一些个人体会做AI芯片的软硬件协同设计最深的体会是没有完美的架构只有合适的权衡。每一个设计决策都有代价关键是要知道代价是什么以及这个代价是否可接受。另一个体会是沟通比技术更重要。软硬件团队之间的信息不对称是很多问题的根源。硬件团队觉得软件团队应该能适配软件团队觉得硬件团队应该提供更好的支持。解决这个问题的唯一办法就是坐下来用数据说话用真实的模型和trace来驱动决策。最后如果你正在做AI芯片相关的工作我的建议是不要只盯着算力数字。算力只是起点真正决定芯片价值的是软硬件协同的效率。一个算力中等但软硬件配合默契的芯片往往比一个算力很高但软件跑不动的芯片更有竞争力。这个道理我在实际项目中反复验证过。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
