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芯片相关的工作，我的建议是：不要只盯着算力数字。算力只是起点，真正决定芯片价值的是软硬件协同的效率。一个算力中等但软硬件配合默契的芯片，往往比一个算力很高但软件跑不动的芯片更有竞争力。这个道理，我在实际项目中反复验证过。
