1. 先看清楚：AI芯片软硬件协同到底在解决什么问题1.1 算法迭代节奏，远快于芯片迭代周期做过AI芯片的人应该都有一种共同的焦虑：算法论文更新得快到离谱，而芯片的迭代慢到让人心慌。一个新型网络结构出来，往往不只是换了层数或者通道数，有时候会冒出全新的算子、新的数据排布方式、新的控制流模式。对软件团队来说，这可能只是框架里一个新算子，但对硬件团队来说，这可能意味着新的数据通路、新的指令需求，甚至新的片上互联策略。芯片从架构定义到拿到样片，周期通常以年为单位。如果中间还要经历仿真验证、后端实现、流片、封装、测试，那更是漫长的旅程。这中间任何一个环节出现返工，影响都不是几周能消化掉的。更麻烦的是，你在定义芯片架构的那一刻，参考的算法很可能已经被更新的结构取代。所以AI芯片设计天然带着一个错位问题：硬件实现的能力，总是要滞后于算法产生新需求的速度。所以软硬件协同设计的真正意义，不是让硬件去追无穷变化的新算法，而是把算法里的“共性计算”提炼出来，用有限且稳固的硬件结构去承载。我习惯把它比喻成物流公司。电商运营可以天天换促销方案，但物流公司不会每天改一次仓库结构。它能做的是把仓配能力抽象成干线、分拣、末端配送几个稳定模块，然后用流程系统去适配各种促销玩法。AI芯片也是一样，卷积、矩阵乘、归一化、激活这些是稳定模块，算法再怎么变，也大体还是这些基础动作的不同组合。软件的作用，就是把新组合翻译成硬件能理解的动作序列。这个逻辑想透了，就明白软硬件协同的第一落点，一定是对目标负载做计算特征的提炼，而不是一上来就画框图。1.2 硬件的“物理账本”：乘法器、带宽与精度的取舍芯片设计的残酷之处在于，它处处是取舍，而取舍的核心是物理账本。面积就那么大，功耗有上限，时钟频率也有上限，你总得决定把晶体管花在哪。AI计算的核心动作看着不多，无非乘加、激活、池化、归一化、数据搬移，但不同模型对这几类动作的比例差异非常大。硬件团队经常争论一个问题：同样是十万个单位的晶体管预算，是用来堆乘法阵列，还是用来堆片上存储？如果都堆到乘法阵列上，理论峰值算力很好看；如果堆到存储上，跑真实模型的时候有效算力可能会更高，因为数据不用反复从外部DDR读入，计算单元不用空转等待。这个取舍没有放之四海皆准的答案，完全取决于芯片的目标场景。如果是云端训练，算力密度和互联带宽都很重要；如果是边缘推理，能效比和存储带宽的匹配往往才是决定体验的关键。我见过不少团队在项目初期拍脑袋定了“算力必须多大、存储必须多少”的指标，结果做到一半发现瓶颈根本不在计算单元，而在片上数据供给不足，于是只能回头调架构，成本极高。靠谱的做法是拿真实模型提前跑Profile，统计计算密度、访存密度、算子分布，再根据这些数据反推资源比例。顺序不能反，否则后面全是补丁。精度是另一个容易在早期被轻视的账本。FP32实现简单，对齐生态容易，但面积和功耗都大。FP16用在训练场景相对稳定，推理端则普遍在往INT8甚至INT4靠。量化说起来只是把数据从32位变成8位，真正做起来会牵扯出缩放因子、溢出保护、反量化插入等一系列问题。硬件能不能高效支持混合精度，决定了软件团队后续的优化空间有多大。如果芯片定义阶段对混合精度的考虑过于乐观，后面所有软件适配都会被束缚住手脚。1.3 软硬件协同不是选项，是生存策略一个挺残酷的行业事实是，一款AI芯片的成败，很多时候不由峰值算力决定，而由“开发者拿到芯片之后，能不能在两周内把模型跑起来”决定。过去那种只卖芯片、软件随便做做的模式，在今天这个生态密度极高的市场里，基本走不通。软件栈在很多时候已经变成芯片的一部分。没有工具链的芯片，本质上是一块没有灵魂的硅片。软件栈的意义，是让上层开发者看到的不是寄存器、指令编码和内存映射，而是卷积层、Transformer Block、计算图里的算子节点。抽象得好，芯片就“好用”；抽象得差，即便底层算力再强，也很难被真实项目接纳。这也是为什么现在很多AI芯片团队的软件人数甚至超过硬件人数，因为软件栈的工程量和对细节的要求，一点不比硬件少。还有一个经常被忽视的点是反馈机制。模型运行慢，原因可能涉及硬件的仲裁策略、缓存命中率、调度器的同步开销，也可能只是编译器生成代码太保守。如果软件栈缺少细粒度的性能观测能力，开发者只能对着黑盒猜。我早期参与过一个项目，芯片跑某个经典分类模型时平均利用率只有三成，硬件团队坚持说逻辑仿真没问题，软件团队后来用片上计数器定位到某个仲裁器的轮询策略在高并发时产生大量空转周期。这种问题靠纸面推演几乎不可能发现。所以说软硬件协同真正落地，至少要做三件事：统一的任务模型、充分的观测机制、迭代式调优闭环。2. 硬件侧：算力路径与数据通路的取舍2.1 计算单元的三条路线：脉动阵列、SIMD与稀疏加速硬件侧的第一次核心决策，是计算单元用什么组织形式。业内主流路线大致有三类，每一类都有明显的性格，也有各自需要付出的软件代价。第一类是脉动阵列。大量乘加单元排成二维阵列，数据从阵列边缘流入，在计算单元之间流动的过程中完成乘加，中间结果不用频繁写回存储。它特别适合卷积和矩阵乘法这种数据复用率很高的负载，结构规整，面积效率高。但脉动阵列对数据布局很挑剔，编译器要把数据按特定Pattern提前排好，否则阵列内部会大量空转。可以说它把一部分复杂度从硬件转嫁给了编译器和运行时。第二类是向量处理单元。一条指令对一批数据做同样的操作，灵活度高，更接近传统处理器的风格，编译器对接相对容易。代价是控制逻辑和调度资源的开销更大，功耗面积不如纯阵列结构划算。很多芯片实际采用混合体：重计算密度的任务走阵列，灵活的小算子走通用向量核，两边各取所长。第三类是稀疏加速路径。经过剪枝的神经网络，权重里常有大量零，于是硬件通过稀疏检测跳过零值计算，节省能耗。但稀疏加速的好处并不总是能兑现，当零值分布不规则时，索引开销会抵消跳过计算省下的时间。我的建议是，不要一上来就赌稀疏加速。先把稠密场景下的基础性能做扎实，再把稀疏作为增量特性加入。否则验证复杂度和编译器适配难度会同步暴涨。三种路线的对比如下：技术路线核心优势主要短板最适合的负载脉动阵列数据复用高、面积效率好对数据布局敏感，编译器压力大卷积、矩阵乘等规整计算向量并行单元灵活易编程、对接方便功耗面积开销偏高多样化算子、控制密集场景稀疏加速跳过零计算、节省能耗索引开销大，动态稀疏难处理剪枝后模型、高稀疏度场景选择计算单元路线时，核心判断标准只有一个：目标负载里的算子，在数据复用率、规则度、稀疏比上是怎么分布的。我见过有团队一开始就押注某一种高级结构，结果跑通用模型时优势不明显，反而在编译器适配环节多花了几个季度。先保守、后激进，是AI芯片架构选型里一条比较稳的经验。2.2 “内存墙”问题的破解逻辑：逐层缓冲与近数据计算AI算力提升的速度长期快于访存带宽的提升速度。当计算单元规模上去了，真正的瓶颈往往不再是计算本身，而是数据能不能及时送到计算单元嘴边。这个“高速计算碰见低速存储”的矛盾，业内常叫内存墙。破解内存墙最主流的手段是分层存储。计算单元旁边配一个小而快的寄存器堆，外层是一级或两级的片上SRAM，再往外才是DDR或者HBM。每一级存储的目标都是把数据尽量留在离计算单元近的地方，让同一个数据被反复复用。举个例子，卷积计算里权重和输入特征如果能被充分复用，外部存储的访问次数能降低一个数量级。编译器要做的重要工作之一，就是把循环切块成能被片上缓存容纳的Tile，减少换入换出。实际项目里，缓存一致性开销往往被低估。多个计算核共享数据的时候，如果硬件没有足够高效的同步机制，软件只能频繁插入Barrier。Barrier一多，流水线就断，利用率损失立刻显现。更好的做法是在片上设计生产者-消费者结构的流水，让一个核算出的中间结果直接被下一个核消费，免去反复写回DDR再读回的开销。这种数据流式调度对编译器分析能力要求更高，但性能收益也最直观。2.3 多核互联与同步开销单核算力做到一定程度就必然走向多核。多核之间的互联结构决定了数据吞吐上限和延迟底线。AI芯片里的互联通常不是简单拉几条总线，而是根据实际访存模式定制的片上网络，需要支持广播、多播、点对点、归约等各种通信模式。很多AI算子天然容易拆分。卷积可以把输入特征图切到不同核；矩阵乘可以把大矩阵分块，分给不同核并行算。但拆分之后必然带来通信和同步。两个核算完各自的块，如果后面要拼接或者做全局归约，通信量一旦安排不好，整体性能就会被拖垮。所以软硬件协同设计时，要把通信原语直接在指令集和运行时层面表达出来，让上层的调度器可以直接操纵这些原语，而不是在驱动里硬拼。任务同步粒度是另一个工程难点。粒度太粗，空闲等待变大；粒度太细，同步本身的开销变大。硬件设计可以通过异步事件队列、乱序完成中断等机制来缓解，但最终仍要依赖调度器把任务切分和同步频率调到一个最佳平衡点。多核并发的调试通常也是仿真阶段最头疼的部分，因为并发Bug复现成本高，随机时序会让问题时隐时现。这点放到第五部分详细说。3. 软件侧：框架、编译器、运行时到底管多少事3.1 指令集设计：给编译器铺路，而不是给编译器挖坑指令集常被当成纯硬件的事情，但它其实直接决定了软件团队未来几年的幸福感。一套对编译器友好的指令集，一般具备三个特征。第一，表达能力强，一条指令能表达一个有意义的复杂操作，而不是把操作切得稀碎。第二，规则可预测，指令的延迟、副作用对上层可见且稳定。第三，接口分层清晰，既能表达粗粒度的张量操作，也能表达细粒度的标量控制。我最怕看到的是“单条大而美”的指令。一条指令试图同时完成取数、计算、写回、更新状态，听起来很强大，但编译器要做指令调度和寄存器分配时，副作用约束会带来巨大痛苦。反过来，指令太碎也有问题，一条卷积被拆成几百条微操作，程序体积膨胀，执行效率下降。比较健康的设计是分层指令集：粗粒度张量指令处理大块计算，细粒度向量和标量指令做控制与兜底，两层之间有清晰的边界和转换规则。指令编码也要预留扩展位。AI算子还在快速演化，指令集如果没有预留类型字段或者没有定长编码格式，后期加一条新指令会非常麻烦，甚至可能破坏解码器的时序。我在早期一个项目里吃过这个亏，当时为了省面积把Opcode压缩得太紧，后来想加一种新的数据模式，几乎没有空地可插，只能拿旧指令组合模拟，效率差强人意。好的指令集和危险的指令集有时只差几个决策：设计维度好设计危险设计指令粒度张量指令+标量指令分层单条指令塞入过多隐藏副作用行为规则性延迟和副作用稳定可预测隐藏依赖，乱序副作用难以追踪可扩展性预留Opcode和类型字段编码过于紧凑，后期无扩展空间3.2 算子调度与算子融合的收益逻辑软件栈里最能体现实力的部分是编译器。编译器先要对计算图做图优化。以典型卷积块为例，卷积、偏置相加、激活函数经常连在一起，如果编译器原样翻译，每一步中间结果都要写回内存再读出来，算力利用率会非常难看。算子融合就是把这些连续运算合成一个复合算子内核，让中间结果不出片上缓存，直接流向下一个计算节点。实践中，这往往是把一个模型从低利用率拉到高利用率的第一个大优化。算子调度是第二件大事。一个算子里可能有很多可并行的维度，比如卷积的批次、通道、空间位置。编译器要在计算核数量和片上内存约束下，决定怎么切块、怎么排循环、怎么做流水。这本质上是个搜索空间巨大的优化问题。工程上很少一上来就全局搜索最优，更现实的是先用代价模型做一轮启发式切分，再挑少数关键算子做自动调优，实测跑一遍，选出最优版本缓存下来，以后直接命中缓存。概念上，算子融合前后的差异可以这样看：# 融合前：Conv -> Bias -> ReLU，每一步都把中间结果写回内存 out = conv(x, w, b) out = bias_add(out, bias) out = relu(out) # 融合后：一次遍历完成，中间结果留在片上缓存 for tile in tiles(x): acc = conv_tile(tile, w, b) acc = bias_add_tile(acc, bias) out_tile = relu_tile(acc) write(out_tile)还有一个容易被忽略的经验：不要迷信全自动生成代码。某些特定模型的并行拆分策略，资深工程师手写的调度版本往往比自动生成的性能更好。两者其实不冲突，编译器要做的，是把常规优化自动化，同时把非常规优化路径通过可编程接口开放给专家。软件栈如果能提供灵活的扩展机制，有时候比做一个全自动的“神级编译器”更接地气。3.3 驱动与运行时：容易忽略却最常翻车的地方聊AI芯片软件栈，大家容易把聚光灯打在编译器和框架对接上，但实际项目里故障最多的层，往往是驱动与运行时。驱动负责管理设备内存、提交任务队列、处理中断；运行时负责给每个模型实例分配算力、排队、调度、监控。这两层离硬件最近，出问题时最难看，又直接影响系统稳定性。拿DMA传输来说，硬件通常会提供DMA部件来做数据搬移。DMA的触发条件、地址长度对齐、内存屏障要求，驱动里只要有一个细节处理不严，就可能出现偶发性数据错误。单核单任务调试时几乎不出现，多核多任务并发跑起来就随机爆发。排查这类问题像是在捉迷藏，因为错误往往不会稳定复现。运行时调度也是重灾区。很多推理场景需要多个模型并发共享同一颗芯片，比如视频流里同时跑检测、跟踪、超分。如果运行时只做静态资源切分，某个模型的负载波动变大时，另一个模型的延迟会跟着剧烈抖动。理想方案是支持动态重配，比如任务级抢占、内存冷热迁移、算力伸缩。但这些动态能力反过来对硬件也有要求，上下文切换要有快速保存和恢复机制，硬件设计之初没考虑，软件再怎么绕也补不回来。4. 从算法到物理芯片的实现路径4.1 第一步：用算法Profile定硬指标软硬件协同设计不是一上来就画电路图。比较规范的流程是先选定两三个目标模型，覆盖训练、推理、检测、分类、生成等不同形态，再写脚本统计分析这些模型的计算量分布、算子类型分布、访存量、并行度和稀疏度指标，然后换算成硬指标。举一个简单的例子。假设目标模型最重的计算集中在矩阵乘法上，总乘加次数已经通过Profile算出来了。如果期望延迟是十毫秒，那需要算力目标是多少TOPS一除就能得到。访存量同理，如果数据表明某个分类模型几乎每次推理都要把权重完整读一遍，那么权重存储的带宽和容量设计就应该重点倾斜。这些推导必须有实际数据支撑，而不是拍脑袋定寄存器数量。我特别想提醒的是，不只盯平均指标，要看P99甚至P99.9。推理服务用户能感受到的往往是最差延迟。如果架构只优化平均水平，输入尺寸一变高并发一来，延迟抖动会很刺眼。定义指标时，最好把典型尺寸、最大尺寸和尺寸切换频率都列出来，再据此决定缓存大小、调度策略和带宽余量。4.2 第二步：架构选型与微架构验证指标定了之后，架构师会并行探索多个备选微架构。A方案可能是大阵列加高带宽，B方案是多核流水加灵活调度，C方案在两者之间折中。每种方案都要做周期级仿真，拿前面提取的真实模型算子去跑，估算性能和面积功耗。我做架构评估时养成了一个习惯，就是准备一个“最差情况算子”。不能只挑最好算的矩阵乘来估，要拿注意力、不规则稀疏、动态形状这类最难处理的算子去压测，看新架构在坏场景下到底跌多惨。很多芯片标称算力很猛，一碰到动态形状就怂，上层框架的自动优化也没法发挥。最差情况算子在工具链还不完善时不太容易暴露，所以架构评审阶段最好把它列为必须交付的测试项。微架构阶段的功耗建模也值得重点关注。AI芯片往往是功耗受限产品，峰值算力好看但散热压不住，整机只能降频跑，实际性能和额定值差一大截。所以降频策略、局部关断机制、能效曲线，尽量在架构阶段就纳入评估，别等到物理设计阶段才手忙脚乱。4.3 第三步：工具链和软件栈怎么跟着硬件并行铺这是一个经常犯、又代价极高的错误：等硬件验证完才开始做软件。芯片设计周期这么长，如果软件栈不能在模拟器上提前调通，等流片回来才发现软硬件接口理解对不上，就只能秋后算账，一遍遍改，整体节奏被拖垮。正确姿势是让软件栈与硬件设计同步进行。硬件RTL还没写完时，先用功能模拟器把指令集模拟出来，软件团队在上面做编译器、驱动和运行时开发。等RTL稳定之后，再做指令级对拍，同一段程序在高精度模拟器和RTL仿真器上分别跑，比对结果和延迟，把硬件实现的错误提早抓出来。再往后可以用FPGA原型验证平台做更接近真实时序的验证。这样的并行开发很依赖一份稳定的“硬件抽象接口文档”。软硬件团队先在上面达成一致：指令编码、内存布局、中断号、设备寄存器地址、同步原语，全部白纸黑字定下来。接口一旦稳定，两边就能各干各的。每次改动都要走变更评审，哪怕只是一个寄存器位的含义调整，也可能让驱动里的某个宏出现偏差。这套接口管理流程，我觉得是软硬件协同里最容易被低估的“流程基建”。4.4 第四步：集成到已有AI框架的适配策略芯片软件栈最终要接进上层AI生态。主流的深度学习框架基本都带一套计算图中间表达，常见做法是以算子注册的方式把自家实现挂进框架，把模型里的节点替换成自己的算子实现。为了兼容已有模型库，还要有图改写和回退机制，能自动替换的节点就替换，替换不了的特殊节点，先退回CPU参考实现。这个阶段最忌全量自研。一个新芯片团队如果把框架里所有算子都自己实现一遍，成本极高，质量也不好保证。更务实的是聚焦高频和高计算量算子，比如卷积、矩阵乘、归一化、激活，把性能做到极致；边缘算子先用CPU实现保证正确性，后续再逐步替换。用户跑一个复杂模型，如果90%的计算时间都落在核心算子上，边缘算子哪怕性能一般，整体效果也过得去。这条路线符合二八法则，能让软件栈在早期更快达到可用状态。5. 真实项目里的高频坑与排查思路5.1 精度对不齐，到底在哪里丢精度几乎每个AI芯片项目都会遇到“仿真结果和参考框架输出不一致”的问题。精度对不齐大概是软硬件联调里最磨人的问题。我的排查顺序通常是自底向上：先查数据格式解析。输入图片通道顺序对不对，归一化因子是多少，是否需要转置。这些很低级，但出现频率出奇高。再查中间张量精度。每层输出是FP32还是FP16，累加器位宽是否足够，有没有因为累加精度不足导致误差逐层放大。然后查量化参数。INT8推理的缩放因子是逐张量还是逐通道，是否存在离群值导致量化范围被撑大。最后查异步和乱序。数据写回顺序和同步屏障有没有对齐，缓存里的数据是不是在错误的时间被读到。精度排查很依赖工具链的可观测性。芯片如果支持片上快照，能导出每一层中间结果，那排查就是对照实验。如果只能看到最终输出，就像蒙着眼睛解谜。所以我前面强调的观测机制，真不是可选项，而是诊断抓手。5.2 理论算力很高，实际利用率上不去“标称几百TOPS，跑起来只能用三成”，这是AI芯片圈最常见的抱怨之一。算力利用率上不去的原因通常归为三类：症状常见原因排查方向计算单元长期等数据片上缓存太小、外部带宽不足查等待周期占比，优化Tile切分大量计算核空闲算子并行度不足、批次太小增大Batch，多算子流水重叠频繁等待同步Barrier过密、锁竞争调整同步粒度，用异步指令掩盖延迟解决利用率问题的关键，是要有足够细的性能计数。把一次推理的时间拆成计算时间、数据搬移时间、同步等待时间三类，再去看最大的一项，优化方向往往就清楚了。最怕的是没有计数器，全靠经验和猜。我经历过一个项目，一开始所有人都认定瓶颈在带宽，加了计数器才发现同步等待占比最高，整个团队的努力方向都错了。5.3 仿真与实片表现不符还有一类很磨人的问题是仿真阶段各项指标都达标，一上实片性能就缩水。造成偏差的原因很多。功耗和散热是最常见的一种，仿真假定频率恒定，实片高负载跑一会儿温度上去就降频。另一类是时钟与复位的问题，仿真用的理想时钟，实片上有抖动和跨时钟域的不确定延迟，会让某些极端时序路径出问题。还有制造偏差，不同芯片个体之间存在性能差异，量产不做分级就会影响体验。应对这些问题，验证阶段就不能只跑“功能正确”的用例，还要专门设计高负载高温度的压力测试。让芯片跑到最高频、最大功耗、最热工况，看软硬件组合能扛多久。硬件没有这些压力数据，软件团队连优化空间在哪里都不知道。压测这一环其实很考验软硬件的配合能力，两边数据一凑，很多隐藏问题就浮出水面。6. 一些可以少走弯路的建议6.1 共建接口契约仓库软硬件团队一定要有一个共同维护的接口契约仓库，里面放着指令集手册、寄存器定义、内存布局、错误码表、同步原语说明。所有版本变更都走评审式流程。很多团队的矛盾，本质上是对同一份接口的两边理解不一致，到联调阶段才爆发。用一个清晰、单点维护的契约仓库，能提前化解大半问题。6.2 给软件团队一个功能模拟器给软件栈团队一个“假硬件”是性价比最高的投资。硬件RTL还没就绪时，先做一个支持指令集、能跑算子、带基本性能统计的功能模拟器。软件团队在这个模拟器上把编译器、驱动、运行时、量化工具全部跑通，等真实芯片回来，主要工作就变成性能打磨，而不是功能调试。那省下来的时间，往往是以月计的。6.3 让尾部延迟和能效曲线进入决策只看平均算力和平均延迟，会掩盖大量真实问题。建议每个AI芯片项目立项时都建立一个目标负载基准套件，包含真实模型、批量尺寸、输入分辨率分布。所有架构选型和软件优化都围绕这套基准做决策。基准不完美，但它提供了一个所有人可以共同参照的锚点，总比各说各话强。6.4 算法与硬件之间保持小步迭代算法团队和硬件团队不要只在评审会上碰头，最好建立一个小步迭代的沟通机制。算法团队有新结构想法时，硬件资源不太可能立刻跟上，但算法团队如果了解硬件的“禀赋”，在模型结构设计阶段就能偏向硬件友好，比如把动态尺寸改成静态形状，或者复用已有算子的组合。这种软性对齐经常比被迫改硬件省力得多。我在实操中越来越体会到，AI芯片的软硬件设计，本质上是磨合与妥协的艺术。技术方案当然重要，但真正决定项目走向的，往往是一些反复被验证的工程习惯：明确分工界面、建立观测手段、用小步迭代快速试错。最后再分享一个小技巧：把性能计数器当成一等公民来设计。很多AI芯片的性能计数器列表，重要性一点不比核心计算单元低。没有这些计数器，优化就像盲人摸象。这个内容后续还可以这样扩展，把编译器和工具链的适配过程单独拆开讲，包括算子库编写技巧、量化工具设计、性能剖析器打磨，那又是一个大课题。至少在当前这个阶段，我希望上面这些经验能让你少走一些弯路。
1. 先看清楚：AI芯片软硬件协同到底在解决什么问题1.1 算法迭代节奏，远快于芯片迭代周期做过AI芯片的人应该都有一种共同的焦虑：算法论文更新得快到离谱，而芯片的迭代慢到让人心慌。一个新型网络结构出来，往往不只是换了层数或者通道数，有时候会冒出全新的算子、新的数据排布方式、新的控制流模式。对软件团队来说，这可能只是框架里一个新算子，但对硬件团队来说，这可能意味着新的数据通路、新的指令需求，甚至新的片上互联策略。芯片从架构定义到拿到样片，周期通常以年为单位。如果中间还要经历仿真验证、后端实现、流片、封装、测试，那更是漫长的旅程。这中间任何一个环节出现返工，影响都不是几周能消化掉的。更麻烦的是，你在定义芯片架构的那一刻，参考的算法很可能已经被更新的结构取代。所以AI芯片设计天然带着一个错位问题：硬件实现的能力，总是要滞后于算法产生新需求的速度。所以软硬件协同设计的真正意义，不是让硬件去追无穷变化的新算法，而是把算法里的“共性计算”提炼出来，用有限且稳固的硬件结构去承载。我习惯把它比喻成物流公司。电商运营可以天天换促销方案，但物流公司不会每天改一次仓库结构。它能做的是把仓配能力抽象成干线、分拣、末端配送几个稳定模块，然后用流程系统去适配各种促销玩法。AI芯片也是一样，卷积、矩阵乘、归一化、激活这些是稳定模块，算法再怎么变，也大体还是这些基础动作的不同组合。软件的作用，就是把新组合翻译成硬件能理解的动作序列。这个逻辑想透了，就明白软硬件协同的第一落点，一定是对目标负载做计算特征的提炼，而不是一上来就画框图。1.2 硬件的“物理账本”：乘法器、带宽与精度的取舍芯片设计的残酷之处在于，它处处是取舍，而取舍的核心是物理账本。面积就那么大，功耗有上限，时钟频率也有上限，你总得决定把晶体管花在哪。AI计算的核心动作看着不多，无非乘加、激活、池化、归一化、数据搬移，但不同模型对这几类动作的比例差异非常大。硬件团队经常争论一个问题：同样是十万个单位的晶体管预算，是用来堆乘法阵列，还是用来堆片上存储？如果都堆到乘法阵列上，理论峰值算力很好看；如果堆到存储上，跑真实模型的时候有效算力可能会更高，因为数据不用反复从外部DDR读入，计算单元不用空转等待。这个取舍没有放之四海皆准的答案，完全取决于芯片的目标场景。如果是云端训练，算力密度和互联带宽都很重要；如果是边缘推理，能效比和存储带宽的匹配往往才是决定体验的关键。我见过不少团队在项目初期拍脑袋定了“算力必须多大、存储必须多少”的指标，结果做到一半发现瓶颈根本不在计算单元，而在片上数据供给不足，于是只能回头调架构，成本极高。靠谱的做法是拿真实模型提前跑Profile，统计计算密度、访存密度、算子分布，再根据这些数据反推资源比例。顺序不能反，否则后面全是补丁。精度是另一个容易在早期被轻视的账本。FP32实现简单，对齐生态容易，但面积和功耗都大。FP16用在训练场景相对稳定，推理端则普遍在往INT8甚至INT4靠。量化说起来只是把数据从32位变成8位，真正做起来会牵扯出缩放因子、溢出保护、反量化插入等一系列问题。硬件能不能高效支持混合精度，决定了软件团队后续的优化空间有多大。如果芯片定义阶段对混合精度的考虑过于乐观，后面所有软件适配都会被束缚住手脚。1.3 软硬件协同不是选项，是生存策略一个挺残酷的行业事实是，一款AI芯片的成败，很多时候不由峰值算力决定，而由“开发者拿到芯片之后，能不能在两周内把模型跑起来”决定。过去那种只卖芯片、软件随便做做的模式，在今天这个生态密度极高的市场里，基本走不通。软件栈在很多时候已经变成芯片的一部分。没有工具链的芯片，本质上是一块没有灵魂的硅片。软件栈的意义，是让上层开发者看到的不是寄存器、指令编码和内存映射，而是卷积层、Transformer Block、计算图里的算子节点。抽象得好，芯片就“好用”；抽象得差，即便底层算力再强，也很难被真实项目接纳。这也是为什么现在很多AI芯片团队的软件人数甚至超过硬件人数，因为软件栈的工程量和对细节的要求，一点不比硬件少。还有一个经常被忽视的点是反馈机制。模型运行慢，原因可能涉及硬件的仲裁策略、缓存命中率、调度器的同步开销，也可能只是编译器生成代码太保守。如果软件栈缺少细粒度的性能观测能力，开发者只能对着黑盒猜。我早期参与过一个项目，芯片跑某个经典分类模型时平均利用率只有三成，硬件团队坚持说逻辑仿真没问题，软件团队后来用片上计数器定位到某个仲裁器的轮询策略在高并发时产生大量空转周期。这种问题靠纸面推演几乎不可能发现。所以说软硬件协同真正落地，至少要做三件事：统一的任务模型、充分的观测机制、迭代式调优闭环。2. 硬件侧：算力路径与数据通路的取舍2.1 计算单元的三条路线：脉动阵列、SIMD与稀疏加速硬件侧的第一次核心决策，是计算单元用什么组织形式。业内主流路线大致有三类，每一类都有明显的性格，也有各自需要付出的软件代价。第一类是脉动阵列。大量乘加单元排成二维阵列，数据从阵列边缘流入，在计算单元之间流动的过程中完成乘加，中间结果不用频繁写回存储。它特别适合卷积和矩阵乘法这种数据复用率很高的负载，结构规整，面积效率高。但脉动阵列对数据布局很挑剔，编译器要把数据按特定Pattern提前排好，否则阵列内部会大量空转。可以说它把一部分复杂度从硬件转嫁给了编译器和运行时。第二类是向量处理单元。一条指令对一批数据做同样的操作，灵活度高，更接近传统处理器的风格，编译器对接相对容易。代价是控制逻辑和调度资源的开销更大，功耗面积不如纯阵列结构划算。很多芯片实际采用混合体：重计算密度的任务走阵列，灵活的小算子走通用向量核，两边各取所长。第三类是稀疏加速路径。经过剪枝的神经网络，权重里常有大量零，于是硬件通过稀疏检测跳过零值计算，节省能耗。但稀疏加速的好处并不总是能兑现，当零值分布不规则时，索引开销会抵消跳过计算省下的时间。我的建议是，不要一上来就赌稀疏加速。先把稠密场景下的基础性能做扎实，再把稀疏作为增量特性加入。否则验证复杂度和编译器适配难度会同步暴涨。三种路线的对比如下：技术路线核心优势主要短板最适合的负载脉动阵列数据复用高、面积效率好对数据布局敏感，编译器压力大卷积、矩阵乘等规整计算向量并行单元灵活易编程、对接方便功耗面积开销偏高多样化算子、控制密集场景稀疏加速跳过零计算、节省能耗索引开销大，动态稀疏难处理剪枝后模型、高稀疏度场景选择计算单元路线时，核心判断标准只有一个：目标负载里的算子，在数据复用率、规则度、稀疏比上是怎么分布的。我见过有团队一开始就押注某一种高级结构，结果跑通用模型时优势不明显，反而在编译器适配环节多花了几个季度。先保守、后激进，是AI芯片架构选型里一条比较稳的经验。2.2 “内存墙”问题的破解逻辑：逐层缓冲与近数据计算AI算力提升的速度长期快于访存带宽的提升速度。当计算单元规模上去了，真正的瓶颈往往不再是计算本身，而是数据能不能及时送到计算单元嘴边。这个“高速计算碰见低速存储”的矛盾，业内常叫内存墙。破解内存墙最主流的手段是分层存储。计算单元旁边配一个小而快的寄存器堆，外层是一级或两级的片上SRAM，再往外才是DDR或者HBM。每一级存储的目标都是把数据尽量留在离计算单元近的地方，让同一个数据被反复复用。举个例子，卷积计算里权重和输入特征如果能被充分复用，外部存储的访问次数能降低一个数量级。编译器要做的重要工作之一，就是把循环切块成能被片上缓存容纳的Tile，减少换入换出。实际项目里，缓存一致性开销往往被低估。多个计算核共享数据的时候，如果硬件没有足够高效的同步机制，软件只能频繁插入Barrier。Barrier一多，流水线就断，利用率损失立刻显现。更好的做法是在片上设计生产者-消费者结构的流水，让一个核算出的中间结果直接被下一个核消费，免去反复写回DDR再读回的开销。这种数据流式调度对编译器分析能力要求更高，但性能收益也最直观。2.3 多核互联与同步开销单核算力做到一定程度就必然走向多核。多核之间的互联结构决定了数据吞吐上限和延迟底线。AI芯片里的互联通常不是简单拉几条总线，而是根据实际访存模式定制的片上网络，需要支持广播、多播、点对点、归约等各种通信模式。很多AI算子天然容易拆分。卷积可以把输入特征图切到不同核；矩阵乘可以把大矩阵分块，分给不同核并行算。但拆分之后必然带来通信和同步。两个核算完各自的块，如果后面要拼接或者做全局归约，通信量一旦安排不好，整体性能就会被拖垮。所以软硬件协同设计时，要把通信原语直接在指令集和运行时层面表达出来，让上层的调度器可以直接操纵这些原语，而不是在驱动里硬拼。任务同步粒度是另一个工程难点。粒度太粗，空闲等待变大；粒度太细，同步本身的开销变大。硬件设计可以通过异步事件队列、乱序完成中断等机制来缓解，但最终仍要依赖调度器把任务切分和同步频率调到一个最佳平衡点。多核并发的调试通常也是仿真阶段最头疼的部分，因为并发Bug复现成本高，随机时序会让问题时隐时现。这点放到第五部分详细说。3. 软件侧：框架、编译器、运行时到底管多少事3.1 指令集设计：给编译器铺路，而不是给编译器挖坑指令集常被当成纯硬件的事情，但它其实直接决定了软件团队未来几年的幸福感。一套对编译器友好的指令集，一般具备三个特征。第一，表达能力强，一条指令能表达一个有意义的复杂操作，而不是把操作切得稀碎。第二，规则可预测，指令的延迟、副作用对上层可见且稳定。第三，接口分层清晰，既能表达粗粒度的张量操作，也能表达细粒度的标量控制。我最怕看到的是“单条大而美”的指令。一条指令试图同时完成取数、计算、写回、更新状态，听起来很强大，但编译器要做指令调度和寄存器分配时，副作用约束会带来巨大痛苦。反过来，指令太碎也有问题，一条卷积被拆成几百条微操作，程序体积膨胀，执行效率下降。比较健康的设计是分层指令集：粗粒度张量指令处理大块计算，细粒度向量和标量指令做控制与兜底，两层之间有清晰的边界和转换规则。指令编码也要预留扩展位。AI算子还在快速演化，指令集如果没有预留类型字段或者没有定长编码格式，后期加一条新指令会非常麻烦，甚至可能破坏解码器的时序。我在早期一个项目里吃过这个亏，当时为了省面积把Opcode压缩得太紧，后来想加一种新的数据模式，几乎没有空地可插，只能拿旧指令组合模拟，效率差强人意。好的指令集和危险的指令集有时只差几个决策：设计维度好设计危险设计指令粒度张量指令+标量指令分层单条指令塞入过多隐藏副作用行为规则性延迟和副作用稳定可预测隐藏依赖，乱序副作用难以追踪可扩展性预留Opcode和类型字段编码过于紧凑，后期无扩展空间3.2 算子调度与算子融合的收益逻辑软件栈里最能体现实力的部分是编译器。编译器先要对计算图做图优化。以典型卷积块为例，卷积、偏置相加、激活函数经常连在一起，如果编译器原样翻译，每一步中间结果都要写回内存再读出来，算力利用率会非常难看。算子融合就是把这些连续运算合成一个复合算子内核，让中间结果不出片上缓存，直接流向下一个计算节点。实践中，这往往是把一个模型从低利用率拉到高利用率的第一个大优化。算子调度是第二件大事。一个算子里可能有很多可并行的维度，比如卷积的批次、通道、空间位置。编译器要在计算核数量和片上内存约束下，决定怎么切块、怎么排循环、怎么做流水。这本质上是个搜索空间巨大的优化问题。工程上很少一上来就全局搜索最优，更现实的是先用代价模型做一轮启发式切分，再挑少数关键算子做自动调优，实测跑一遍，选出最优版本缓存下来，以后直接命中缓存。概念上，算子融合前后的差异可以这样看：# 融合前：Conv -> Bias -> ReLU，每一步都把中间结果写回内存 out = conv(x, w, b) out = bias_add(out, bias) out = relu(out) # 融合后：一次遍历完成，中间结果留在片上缓存 for tile in tiles(x): acc = conv_tile(tile, w, b) acc = bias_add_tile(acc, bias) out_tile = relu_tile(acc) write(out_tile)还有一个容易被忽略的经验：不要迷信全自动生成代码。某些特定模型的并行拆分策略，资深工程师手写的调度版本往往比自动生成的性能更好。两者其实不冲突，编译器要做的，是把常规优化自动化，同时把非常规优化路径通过可编程接口开放给专家。软件栈如果能提供灵活的扩展机制，有时候比做一个全自动的“神级编译器”更接地气。3.3 驱动与运行时：容易忽略却最常翻车的地方聊AI芯片软件栈，大家容易把聚光灯打在编译器和框架对接上，但实际项目里故障最多的层，往往是驱动与运行时。驱动负责管理设备内存、提交任务队列、处理中断；运行时负责给每个模型实例分配算力、排队、调度、监控。这两层离硬件最近，出问题时最难看，又直接影响系统稳定性。拿DMA传输来说，硬件通常会提供DMA部件来做数据搬移。DMA的触发条件、地址长度对齐、内存屏障要求，驱动里只要有一个细节处理不严，就可能出现偶发性数据错误。单核单任务调试时几乎不出现，多核多任务并发跑起来就随机爆发。排查这类问题像是在捉迷藏，因为错误往往不会稳定复现。运行时调度也是重灾区。很多推理场景需要多个模型并发共享同一颗芯片，比如视频流里同时跑检测、跟踪、超分。如果运行时只做静态资源切分，某个模型的负载波动变大时，另一个模型的延迟会跟着剧烈抖动。理想方案是支持动态重配，比如任务级抢占、内存冷热迁移、算力伸缩。但这些动态能力反过来对硬件也有要求，上下文切换要有快速保存和恢复机制，硬件设计之初没考虑，软件再怎么绕也补不回来。4. 从算法到物理芯片的实现路径4.1 第一步：用算法Profile定硬指标软硬件协同设计不是一上来就画电路图。比较规范的流程是先选定两三个目标模型，覆盖训练、推理、检测、分类、生成等不同形态，再写脚本统计分析这些模型的计算量分布、算子类型分布、访存量、并行度和稀疏度指标，然后换算成硬指标。举一个简单的例子。假设目标模型最重的计算集中在矩阵乘法上，总乘加次数已经通过Profile算出来了。如果期望延迟是十毫秒，那需要算力目标是多少TOPS一除就能得到。访存量同理，如果数据表明某个分类模型几乎每次推理都要把权重完整读一遍，那么权重存储的带宽和容量设计就应该重点倾斜。这些推导必须有实际数据支撑，而不是拍脑袋定寄存器数量。我特别想提醒的是，不只盯平均指标，要看P99甚至P99.9。推理服务用户能感受到的往往是最差延迟。如果架构只优化平均水平，输入尺寸一变高并发一来，延迟抖动会很刺眼。定义指标时，最好把典型尺寸、最大尺寸和尺寸切换频率都列出来，再据此决定缓存大小、调度策略和带宽余量。4.2 第二步：架构选型与微架构验证指标定了之后，架构师会并行探索多个备选微架构。A方案可能是大阵列加高带宽，B方案是多核流水加灵活调度，C方案在两者之间折中。每种方案都要做周期级仿真，拿前面提取的真实模型算子去跑，估算性能和面积功耗。我做架构评估时养成了一个习惯，就是准备一个“最差情况算子”。不能只挑最好算的矩阵乘来估，要拿注意力、不规则稀疏、动态形状这类最难处理的算子去压测，看新架构在坏场景下到底跌多惨。很多芯片标称算力很猛，一碰到动态形状就怂，上层框架的自动优化也没法发挥。最差情况算子在工具链还不完善时不太容易暴露，所以架构评审阶段最好把它列为必须交付的测试项。微架构阶段的功耗建模也值得重点关注。AI芯片往往是功耗受限产品，峰值算力好看但散热压不住，整机只能降频跑，实际性能和额定值差一大截。所以降频策略、局部关断机制、能效曲线，尽量在架构阶段就纳入评估，别等到物理设计阶段才手忙脚乱。4.3 第三步：工具链和软件栈怎么跟着硬件并行铺这是一个经常犯、又代价极高的错误：等硬件验证完才开始做软件。芯片设计周期这么长，如果软件栈不能在模拟器上提前调通，等流片回来才发现软硬件接口理解对不上，就只能秋后算账，一遍遍改，整体节奏被拖垮。正确姿势是让软件栈与硬件设计同步进行。硬件RTL还没写完时，先用功能模拟器把指令集模拟出来，软件团队在上面做编译器、驱动和运行时开发。等RTL稳定之后，再做指令级对拍，同一段程序在高精度模拟器和RTL仿真器上分别跑，比对结果和延迟，把硬件实现的错误提早抓出来。再往后可以用FPGA原型验证平台做更接近真实时序的验证。这样的并行开发很依赖一份稳定的“硬件抽象接口文档”。软硬件团队先在上面达成一致：指令编码、内存布局、中断号、设备寄存器地址、同步原语，全部白纸黑字定下来。接口一旦稳定，两边就能各干各的。每次改动都要走变更评审，哪怕只是一个寄存器位的含义调整，也可能让驱动里的某个宏出现偏差。这套接口管理流程，我觉得是软硬件协同里最容易被低估的“流程基建”。4.4 第四步：集成到已有AI框架的适配策略芯片软件栈最终要接进上层AI生态。主流的深度学习框架基本都带一套计算图中间表达，常见做法是以算子注册的方式把自家实现挂进框架，把模型里的节点替换成自己的算子实现。为了兼容已有模型库，还要有图改写和回退机制，能自动替换的节点就替换，替换不了的特殊节点，先退回CPU参考实现。这个阶段最忌全量自研。一个新芯片团队如果把框架里所有算子都自己实现一遍，成本极高，质量也不好保证。更务实的是聚焦高频和高计算量算子，比如卷积、矩阵乘、归一化、激活，把性能做到极致；边缘算子先用CPU实现保证正确性，后续再逐步替换。用户跑一个复杂模型，如果90%的计算时间都落在核心算子上，边缘算子哪怕性能一般，整体效果也过得去。这条路线符合二八法则，能让软件栈在早期更快达到可用状态。5. 真实项目里的高频坑与排查思路5.1 精度对不齐，到底在哪里丢精度几乎每个AI芯片项目都会遇到“仿真结果和参考框架输出不一致”的问题。精度对不齐大概是软硬件联调里最磨人的问题。我的排查顺序通常是自底向上：先查数据格式解析。输入图片通道顺序对不对，归一化因子是多少，是否需要转置。这些很低级，但出现频率出奇高。再查中间张量精度。每层输出是FP32还是FP16，累加器位宽是否足够，有没有因为累加精度不足导致误差逐层放大。然后查量化参数。INT8推理的缩放因子是逐张量还是逐通道，是否存在离群值导致量化范围被撑大。最后查异步和乱序。数据写回顺序和同步屏障有没有对齐，缓存里的数据是不是在错误的时间被读到。精度排查很依赖工具链的可观测性。芯片如果支持片上快照，能导出每一层中间结果，那排查就是对照实验。如果只能看到最终输出，就像蒙着眼睛解谜。所以我前面强调的观测机制，真不是可选项，而是诊断抓手。5.2 理论算力很高，实际利用率上不去“标称几百TOPS，跑起来只能用三成”，这是AI芯片圈最常见的抱怨之一。算力利用率上不去的原因通常归为三类：症状常见原因排查方向计算单元长期等数据片上缓存太小、外部带宽不足查等待周期占比，优化Tile切分大量计算核空闲算子并行度不足、批次太小增大Batch，多算子流水重叠频繁等待同步Barrier过密、锁竞争调整同步粒度，用异步指令掩盖延迟解决利用率问题的关键，是要有足够细的性能计数。把一次推理的时间拆成计算时间、数据搬移时间、同步等待时间三类，再去看最大的一项，优化方向往往就清楚了。最怕的是没有计数器，全靠经验和猜。我经历过一个项目，一开始所有人都认定瓶颈在带宽，加了计数器才发现同步等待占比最高，整个团队的努力方向都错了。5.3 仿真与实片表现不符还有一类很磨人的问题是仿真阶段各项指标都达标，一上实片性能就缩水。造成偏差的原因很多。功耗和散热是最常见的一种，仿真假定频率恒定，实片高负载跑一会儿温度上去就降频。另一类是时钟与复位的问题，仿真用的理想时钟，实片上有抖动和跨时钟域的不确定延迟，会让某些极端时序路径出问题。还有制造偏差，不同芯片个体之间存在性能差异，量产不做分级就会影响体验。应对这些问题，验证阶段就不能只跑“功能正确”的用例，还要专门设计高负载高温度的压力测试。让芯片跑到最高频、最大功耗、最热工况，看软硬件组合能扛多久。硬件没有这些压力数据，软件团队连优化空间在哪里都不知道。压测这一环其实很考验软硬件的配合能力，两边数据一凑，很多隐藏问题就浮出水面。6. 一些可以少走弯路的建议6.1 共建接口契约仓库软硬件团队一定要有一个共同维护的接口契约仓库，里面放着指令集手册、寄存器定义、内存布局、错误码表、同步原语说明。所有版本变更都走评审式流程。很多团队的矛盾，本质上是对同一份接口的两边理解不一致，到联调阶段才爆发。用一个清晰、单点维护的契约仓库，能提前化解大半问题。6.2 给软件团队一个功能模拟器给软件栈团队一个“假硬件”是性价比最高的投资。硬件RTL还没就绪时，先做一个支持指令集、能跑算子、带基本性能统计的功能模拟器。软件团队在这个模拟器上把编译器、驱动、运行时、量化工具全部跑通，等真实芯片回来，主要工作就变成性能打磨，而不是功能调试。那省下来的时间，往往是以月计的。6.3 让尾部延迟和能效曲线进入决策只看平均算力和平均延迟，会掩盖大量真实问题。建议每个AI芯片项目立项时都建立一个目标负载基准套件，包含真实模型、批量尺寸、输入分辨率分布。所有架构选型和软件优化都围绕这套基准做决策。基准不完美，但它提供了一个所有人可以共同参照的锚点，总比各说各话强。6.4 算法与硬件之间保持小步迭代算法团队和硬件团队不要只在评审会上碰头，最好建立一个小步迭代的沟通机制。算法团队有新结构想法时，硬件资源不太可能立刻跟上，但算法团队如果了解硬件的“禀赋”，在模型结构设计阶段就能偏向硬件友好，比如把动态尺寸改成静态形状，或者复用已有算子的组合。这种软性对齐经常比被迫改硬件省力得多。我在实操中越来越体会到，AI芯片的软硬件设计，本质上是磨合与妥协的艺术。技术方案当然重要，但真正决定项目走向的，往往是一些反复被验证的工程习惯：明确分工界面、建立观测手段、用小步迭代快速试错。最后再分享一个小技巧：把性能计数器当成一等公民来设计。很多AI芯片的性能计数器列表，重要性一点不比核心计算单元低。没有这些计数器，优化就像盲人摸象。这个内容后续还可以这样扩展，把编译器和工具链的适配过程单独拆开讲，包括算子库编写技巧、量化工具设计、性能剖析器打磨，那又是一个大课题。至少在当前这个阶段，我希望上面这些经验能让你少走一些弯路。