这篇延续了我前几篇的思路，只是这次想聊点更偏"设计哲学"的东西，而不是继续堆一些具体模块的电路方案。入行AI芯片这十来年，我最大的感受是：这个领域最难的从来不是晶体管怎么画、电路怎么调，而是软件和硬件之间那条模糊边界怎么定。哪怕你手头的NPU设计得再精巧，编译器不给力、运行时调度毛糙、上层框架不支持，最终落地就是一坨废铁。反过来也一样，软件团队把网络结构搞得花里胡哨，但硬件数据流固定死了，刷不掉重访、挪不动内存，性能照样被杀得很难看。
所以这篇文章我会把视角放在"软硬件协同设计"这个完整的闭环上，从算法特性和场景约束出发，顺着数据流、存储层级、工具链、验证部署、平台方案对比这几个维度往下拆。标题里的6，我也准备聚焦在"第6代AI芯片结构中常见的设计取舍"这个大方向上——不问具体电路参数，而是问一个更根本的问题：为什么这一代的AI芯片设计，几乎所有的关键性能都卡在数据搬运和工具链融合上，而不是卡在算力峰值。看懂了这个逻辑，很多关于CNN、Transformer、大模型部署的浮层问题就都能自己找答案了。
1. 场景定义先行：AI芯片为什么不能从晶体管开始设计
前几年有不少团队找我审方案，PPT第一页永远是"我们要做一个XX TFLOPS的AI芯片"，第二页开始就是架构图、内存规划、接口列表。我基本会先打断他们，问一句：你目标跑什么模型？这些模型的张量形状、精度需求、数据复用特征你摸过没有？大多数时候他们会愣住——因为大部分人在做AI芯片软硬件设计时，习惯上是从芯片本身出发，而不是从算法运行特征出发。
1.1 从算子图到芯片架构的映射逻辑
AI芯片和传统CPU/MCU设计最大的不同点在于：CPU设计可以追求通用性，跑什么程序都行，性能指令集兜底；但AI芯片追求的是能效比，也就是每瓦能跑多少次有效运算。而能效比的来源，不是你主频多高、乘法器多快，而是你对访存、数据流、并行度这些结构性选择做了多少针对性优化。
举个最典型的例子：矩阵乘。神经网络里的大部分计算时间都耗在矩阵乘和卷积上。一个Transformer的self-attention、MLP模块、CNN的卷积核，都对应着一批高密度矩阵乘。这些运算的特点是：计算密度高、数据可复用性强、不依赖复杂控制逻辑。你完全可以把它们映射成脉动阵列(Systolic Array)，也可以做成一堆处理单元加片上SRAM的分布式架构，只要把数据喂进去，累加器足够，计算吞吐就能顶上去。
但如果你只看到矩阵乘，忽略了其他算子——比如LayerNorm、Softmax、各种激活函数，以及卷进Embedding里的查表操作，那么你的芯片可能会在矩阵乘上跑出极其漂亮的理论性能，一到真实模型就被这些非矩阵算子拖到地板上。这种"算力失衡"就是软硬件设计没有从"算法场景"出发的典型后果。
所以我在做这一代架构定义时，第一个动作不是画框图，而是拿目标模型做算子切分统计，统计出这个模型跑一遍推理需要多少次矩阵乘、多少次elementwise、多少次非线性算子、它们之间的依赖关系长什么样，以便确定硬件加速器中需要多大比例的专用运算单元、多深的流水线，以及需要什么样的指令流支持。
1.2 精度、稀疏性与融合层对硬件取舍的约束
要定义数据和计算框架，还要搞清楚两个东西：精度和稀疏度。FP32、FP16、BF16、INT8、INT4这些数值格式，不只是软件层的事，它直接决定了乘法器阵列的规模、存储带宽压力、累加器的位宽，甚至决定了你在片上要不要做数值饱和、舍入等处理逻辑。
比如有些团队想在芯片里直接支持INT4推理，那捆绑死的问题就来了：INT4的矩阵乘虽然快，但你量化误差能不能扛住？预训练模型直接压INT4很多就掉点，需要量化感知训练(QAT)或者校准集调优。如果软硬件设计团队没有一起把这个链路打通，只是硬件支持INT4，到了软件层发现模型掉点严重，又回不来，那这个特性就废掉一半。
稀疏性也是绕不开的点。现在主流模型经剪枝蒸馏之后，权重和激活里会有大量零值。硬件层要做稀疏加速，就意味着你要在数据通路上设计跃零逻辑、稀疏索引解析、动态掩码处理。编译器侧则要先做稀疏格式转换，把稠密张量压缩成稀疏存储，再在指令层把可跳过的计算给标识出来。过高估计稀疏收益，往往到最终部署时才意识到，稀疏推理在batch size较小、动态输入形状较复杂的场景下，收益根本吃不满。所以我的习惯是在设计阶段就定下目标稀疏剖面的软硬件分工：谁来剪枝,谁来压缩,谁在运行时跳过,量化到一个可验证的标准。
卷积里的融合层也是同样的道理：Custom op、BatchNorm折叠、ReLU折叠，这些在训练框架里是software的事，但在推理芯片里就是module的阶段拼接。软件编译器和硬件片内控制逻辑需要共同决定，在哪个数据点做folding、中间结果是否落到SRAM、能不能减少一次DRAM刷新。很多时候你以为硬件吃掉了一大块计算，实际性能提升却全来自融合优化——中间张量不在DDR里来回倒腾了。
2. 数据流设计和片内存储：真正决定AI芯片性能的骨架
这几乎是我在AI芯片软硬件设计里最想分享的部分：一个AI芯片的performance，往往不取决于MAC阵列的峰值吞吐，而取决于数据如何"喂"进计算阵列、以及中间结果如何被安排。如果说MAC阵列是发动机，数据流和存储层级就是供油管路和变速箱，管路设计不合理，发动机马力再大也会被憋死。
2.1 三种经典数据流拓扑：脉动阵列、NVDLA式稀疏引擎、存内计算
先谈脉动阵列。Google TPU的经典路线，数据按固定节奏在阵列里相邻单元间流动，权重和激活从两侧注入，部分和沿阵列方向累加。它的好处很明显：寄存器级数据复用非常充分，访存外部存储器的次数被大幅降低，对固定shape的矩阵乘特别友好。代价也很明显：灵活性差，一旦矩阵尺寸和阵列大小不匹配，边缘处理就麻烦，而且动态形状和大规模不规则网络对数据映射的编译器要求极高，软件层做不好，硬件利用率下来非常难看。
然后是NVDLA式的稀疏引擎。它的思路是：不做密集脉动阵列，而是让处理单元自己去"挑食"，跳过稀疏数据，只对非零数据做计算。你可以把它想成一条自动化分拣线，空箱子直接被跳过，省掉了无效搬运。这类架构对稀疏模型的支持好，控制逻辑也更灵活，但代价是控制复杂度上去了，而且片上互连的压力会变大，因为处理单元需要更灵活的输入路由来调度数据。
存内计算则是更进一步，干脆把计算挪到存储阵列里面。SRAM或者Flash单元里面既存权重，又做乘累加。对推理场景，它的能效非常可观，因为不需要把权重搬到运算单元，数据搬运的能耗被压到最低。但现在的问题也很实在：精度受限、工艺兼容性麻烦、数字存内计算还好一点，模拟存内计算还面临温度漂移和噪声问题。而且落到实际部署时，编译器要支持的指令集和传统NPU差异很大，生态成本拦住了不少人。
这三种拓扑不是谁好谁坏，而是看你的目标模型在哪个形态上收益最大，以及你的软件工具链能承受多大复杂度。我见过不少做脉动阵列的团队，最后发现编译器根本没法把任意shape的算子映射到固定阵列上，不得不退化成一种"半脉动"的状态，性能热不起来。反过来，做稀疏引擎的团队如果模型剪枝做得好，每一步推理省掉60%的MAC，其实比堆峰值算力更划算。
2.2 存储层级规划：SRAM、L2 Buffer、DRAM的容量与带宽分配
判断AI芯片存储规划是否合理的几个核心指标：数据重访率、片上容量上的命中率、带宽利用率。所谓重访率，就是同一份数据在计算过程中被重复加载了几次。如果一份权重每算一个输出就要重新读一次，性能必然被带宽锁死。
所以我现在设计片内存储时，第一件事是摸清目标模型的"访存足迹"，也就是模型运行过程中到底哪些数据驻留在片上，哪些数据必须要流式刷新。比如一张1080P输入图像，经过一段高层网络之后产生的特征图有多大，又要被后续的卷积核复用多少次。如果片上SRAM能装下整个特征图平面，那么卷积滤波核就可以在这个平面上滑动计算，完全省掉重复DRAM访问。装不下的话，就要走tiling策略，把平面切块，但这样又会产生边缘重叠数据的重复存储。这时候你要决定边缘冗余(halo overhead)大到什么程度可以接受，片上空间在weights、激活、部分和之间怎么切分。
更细节的还有：哪些层之间可以实现内核融合(kernel fusion)，让多个算子的中间结果直接留在片上，不进DRAM；哪些数据必须要做双缓冲(Double Buffer)，让数据预取和计算并行起来。软件编译器在求解这些问题时，本质上做的是图优化加存储规划和调度。硬件给你提供的SRAM大小、BANK数目、端口数量、读带宽，直接决定了软件能做出的最优调度的上限。
我在第6代架构里很看重"带宽倍增"和"存储利用率"这两个指标，甚至比算力更看重。因为大模型时代，DDR或HBM的带宽增长速度远远跟不上算力增长。你这一代如果能把数据复用率从5倍拉到15倍，等效带宽就是乘3。软硬件协同设计的一半工作，就是在存储规划上抠这种性价比。
2.3 近存计算与存内计算的适用边界
很多朋友问，那我不行就做近存计算(CIM，或者叫processing near memory)呗，把DRAM逻辑也集成进SoC里，离得近一点，带宽不就高了吗？近存计算当然有效，特别是对访存密集型的算子，比如召回、KV Cache读取，效果非常显著。但它不是银弹。因为近存计算能做到的实际是缩短了物理距离，如果计算阵列与存储之间还有复杂的路由和接口逻辑，带宽瓶颈依然存在，只是换了一种形式。
存内计算则更像是在存储单元上"贴计算的膜"，好处是极限省电，坏处是灵活性比较差，一旦算法里的算子形态变化，底层计算逻辑很难跟着变。当前端到端大模型推理追求的是全场景自适应，我的个人意见是：存内计算更适合做某个特定算子组的高能效加固模块，把它当作NPU主计算链路上的一个加速协处理器，而不是全芯片的通用计算主架构。
所以第6代结构里，我会刻意区分主算路径和专用加速路径。主算路径走通用NPU的SIMD/VLIW加上矩阵加速器，解决各种算子组合的通用性。专用路径则放几个固定功能的存内计算小单元，专门负责高密度的查表、KV Cache的attention计算、或者某一个特别频繁的子网络。这样既保留了灵活性，也拿到了高能效的边际收益。
3. 工具链融合：编译器、运行时与仿真平台的三层接力
芯片设计出来只是第一步，能不能被模型用起来，完全是另一场硬仗。AI芯片落地最难啃的骨头，公认是"工具链"——编译器把模型算子翻译成芯片指令，运行时把调度、内存、电源控制在硬件上落地，仿真平台则在流片前验证这一切是否真能work。三层接力，哪一层断了都白搭。
3.1 编译器IR设计：从ONNX/TorchScript到硬件指令的中间层
做AI芯片编译器，第一步就是定义中间表示(IR)。AI训练框架各有各的表达，ONNX、TorchScript、TensorFlow GraphDef，这些前端IR不能直接映射到芯片指令，因为芯片指令天生是"数据流+控制流"的低层表达。所以几乎每个NPU编译器都要做自己的中间IR层，把高层框架的算子图转换成一张张张量指令序列。
我见过很有问题的设计：直接把ONNX算子一对一映射成硬件指令。表面上看省事，但遇到复杂图优化就废了。因为硬件指令里的算子粒度、数据排布、流水要求，跟ONNX里的算子粒度完全不是一回事。真正的做法应当是：先在前端IR上做算子融合和代数化简，把LayerNorm里的mean/var计算、softmax里的exp/max规约合并成定制的融合算子，再到中端IR上用tile切分、循环重排、向量化等手段变换成硬件友好的表达，最后在后端做寄存器分配和指令排布。
这个过程的复杂度和架构设计强相关。如果芯片数据流设计得规整，编译器后端只需做简单映射。如果你的硬件到处都是特例逻辑，编译器就得为每个特例写路径，开发量翻倍。所以架构师评审工具链时一定要有一条铁律：所有硬件feature都要有编译器可见的代价模型，编译优化路径必须在架构定稿前走通一到两个目标模型，否则就是纸面设计。
3.2 异构调度与运行时管理
就算有了编译器，芯片真正跑起来的实时调度还是大问题。一个SoC里往往同时有CPU、NPU，还有各种DSP和专用IP核，模型推理时你要决定：哪些算子在NPU上跑，哪些部分在CPU上兜底，数据从DMA通道怎么搬，电源域和时钟怎么切换。
运行时管理(Runtime)的核心职责是：把编译好的任务按照依赖关系排成DAG，以最优路径上板。一个高效Runtime还要处理多模型串并行(特别是现在AI Agent场景，动不动有多个模型协同跑)、动态shape输入、QoS保障，以及异常重试。这些逻辑如果在设计阶段不考虑，流片后调度颗粒度不对，即便芯片理论算力再高，实际整机吞吐也上不去。
软件侧这块比较常见的误区是：团队花了大功夫把编译器和Runtime做得很复杂，但硬件侧没有足够的硬件同步机制、事件计数器、中断通道来配合。调度只能在软件上等轮询，性能白白损耗。所以软硬件协同设计里，需要的不是"软件适配硬件"或"硬件适配软件"的单向努力，而是在架构层面一起定义哪些控制逻辑放在硬件、哪些放在软件。
3.3 仿真平台的价值：cycle级模拟与功耗估算
在没有流片之前，你靠什么验证整个软硬件栈能work？答案是仿真平台。这里我特别强调cycle级仿真(cycle-accurate simulation)的重要性：每个指令执行需要多少周期、每个内存访问要多少延迟、数据冲突和bank冲突怎么被模拟出来。只有做到这种精度，软件开发团队才能提前在上面调优，而不是等拿到样片后一脸茫然。
与cycle级仿真孪生的是功耗估算。AI芯片的功耗大头往往不在MAC本身，而在数据搬运和SRAM的漏电。早期功耗估算如果只在门级做完，边界条件缺运费，后面交给板级设计的人去处理，很容易超标。所以我在前几代项目里坚持：仿真平台要和功耗模型挂钩，让每个访存行为、每个时钟门控状态都能把功耗开销带回虚拟平台，这样软件团队可以定量地比较不同调度策略的功耗差异。
仿真平台还有一个隐性收益：团队磨合。硬件、编译器、架构团队围着一个仿真环境debug，很多软硬件接口的糊涂账会提前暴露，而不是在流片后爆发。这一步看起来不直接产生芯片性能，但它在真实产品化道路上的价值，比多堆几个MAC要大得多。
4. 验证与部署：算力峰值达标不等于整机可用
我见过不少把benchmark数字写在网页第一行的AI芯片，真到客户现场一部署，掉链子了。原因五花八门，但核心就一条：测试和验证的维度太窄，只盯着算力峰值和框架跑分，没有把真实部署链路中的约束当回事。
4.1 后仿与实测之间那些躲不掉的误差源
电路设计阶段的仿真做得很漂亮，不代表成品就一定跑得短平快。我用链路误差来归一下类，大概有这么几个层次：
- 时钟频率误差：时序收敛情况、片上电压降IR drop、温度变化，都会让实际主频和设计目标之间出现偏移。如果设计时留给后端和物理实现的裕量不够，芯片即使能点亮，主频也拉不高。
- 功耗和热设计误差：仿真用的功耗画像和真实跑模型时的发热分布差异很大。电源管理策略（DVFS调频）做得不够智能，会触发降频保护，直接把性能打七折。
- 内存子系统误差：真实DRAM的刷新、page miss、bank冲突，以及多核访问冲突，往往比仿真里的理想模型要复杂得多。特别是多路NPU同时访问同一个内存控制器时，仲裁开销会导致带宽雪崩式退化。
- 驱动和固件误差：底层驱动初始化时序、DMA描述符管理、中断延迟处理，如果固件层的时序假设和真实硬件行为不一致，就会成为隐藏的“变速齿轮”。
所以成熟的部署验证流程，我建议不要只看单个模型的benchmark。至少要准备三类测试：真实模型端到端延迟测试、多个模型并发运行的吞吐混布测试、长稳加压测试(比如72小时高负载)。这三类全过了，才算对“整机可用”这件事有一点底气。
4.2 多芯片级联、多模型协作的一致性问题
现在的AI应用场景已经不太是"单模型跑单帧"了。AI Agent场景里，可能需要一个端侧大模型连续多轮对话，中间还有漫长的KV Cache维护和上下文增量，一个任务可能切成多个子任务在同一个SoC的多核上并行。这个时候，芯片的软硬件协同设计要面对的不只是单核加速问题，而是“多核一致性”和“任务切分”问题。
多核一致性指什么？比如两个NPU核各自在跑同一个网络切片，它们中间需要交换部分结果。如果共享内存做不好互斥和同步，会产生数据竞争；如果必须经过DRAM往复传数据，那交换延迟又把性能拉下来。软硬件协同在这里的解法是：设计高效的核间通信原语，比如共享SRAM邮箱、硬件屏障、核间中断；同时编译器要自动识别哪些算子间需要核间通信，插入同步点和数据传输指令。
多模型协作则更复杂，加载地址空间如何隔离，多个context如何切换，推理请求的高并发如何不互相干扰。这些问题最终都会映射到Runtime的调度策略和硬件的多级调度机制上。如果算法团队和架构团队没有对齐，很容易出现：算法把模型切得太碎，核间通信开销大于计算收益；或者架构做了硬核隔离，但软件侧没法充分利用。
4.3 性能调试时的常用指标与工具
做AI芯片性能调优，指标体系最好从第一天就统一起来。我常用的几个核心指标：
- 有效算力利用率：真实负载下MAC阵列平均利用率，而不是算力峰值。
- 数据搬移能耗占比：数据搬移相关能耗占总能耗的比例，理想状态应小于30%。
- 存储带宽利用率：DRAM或片内SRAM实际吞吐和理论峰值吞吐的比值。
- 端到端延迟与P99延迟：特别在服务场景中，要看尾部延迟，平均延迟很容易骗人。
工具层面，我建议团队不急着自研复杂Profiler，先用好厂商自带的性能计数器，比如arm的Cycle Counter和SoC里的PMU事件，先把采样维度做够。等自研工具链成熟了，再把硬件事件和编译器的算子映射图做关联，形成一张“算子-指令-访存-功耗”的透视表。我曾经用这套方法查过一次性能损耗：最终发现某个卷积层之所以慢，是因为它的数据排布在DRAM里跨行不连续，导致DMA burst效率掉了70%。这种问题，不从软硬件协同的全局视角看，根本定位不到。
5. 从英伟达到瑞芯微：其实每个平台都在讲同一套设计故事
可能有人觉得这些思路太抽象，那我用市面上几个真实的AI芯片平台来对照一下，你把它们拆开看，会发现无论卖多少钱、用什么工艺，底层逻辑其实都是同一套软硬件协同设计的范本。
5.1 市售主流平台的软硬件协同设计剖面
比较有代表性的是英伟达的Jetson Orin系列。它的底层硬件是一堆Tensor Core加CUDA核的混合体，真正让它“能打”的是庞大的软件栈——CUDA生态、TensorRT编译器，以及专门为DLA(深度学习加速器)设计的指令调度器。你在Jetson上跑模型时，TensorRT会帮你做层融合、精度选择(FP16/INT8)、kernel auto-tuning，一层一层把硬件能力榨干。这是典型的“硬件很猛，但软件把硬件变成易用工具”的路线。
另一条有代表性的是瑞芯微的RK3588系列。它的NPU算力不算巅峰，但胜在异构集成度高，CPU、GPU、NPU之间有一套统一的Runtime调度，轻量模型可以直接用其提供的RKNN工具链完成量化、优化、部署。这种平台更适合做端侧全功能产品原型，门槛低、迭代快。它的软硬件设计故事便更侧重于“在有限算力内做好调度和功耗平衡”，让你觉得似乎性能没那么极限，但产品能稳定量产。
从这两个平台的对比来看，所谓“AI芯片软硬件设计”的真正差距，不在MAC阵列有多大，而在于：编译器工具链是否成熟、Runtime调度是否顺畅、仿真验证环境是否齐备、部署链路是否平顺。很多宣称能对标大厂芯片的团队，最后都倒在这个软件生态的深坑里。
5.2 设计评审清单：每次流片前我都会自问的几个问题
结合这么多年的经验，我在每次tapeout前都会拉一张设计评审清单，专门对着软硬件协同设计的风险点过一遍。你可以直接拿来用：
- 目标模型列表是否明确？每个模型的关键算子和访存特征是否都已量化？
- 编译器是否能跑通目标模型的端到端POC？不能的话，具体卡在哪一层？
- 数据流设计对动态shape的容忍度如何？有没有为NLP变长输入留好缓冲策略？
- 芯片多核扩展时，核间通信和存储一致性是否已在硬件原语层解决？
- 片上存储容量与带宽分配，是否足够覆盖目标模型的所有tiling策略？
- 功耗模型是否已经接入仿真平台，软件团队能否评估不同调度的功耗差异？
- 是否有覆盖面足够的系统级测试方案，而不只是单模型跑分？
- 固件和Runtime的初始化时序、异常处理路径，是否已经和硬件行为对齐？
这张清单看起来短，但每一条展开都是满满的坑。尤其是第一条，如果目标不明确，后面全是扯淡。我在项目初期花了整整四周时间只做模型工作负载分析，被别人嫌慢，等到系统联调的时候，那些时间全赚回来了。软硬件协同设计就是这样，前期多想一步，后期少走十步。
6. 关于“第6代AI芯片结构”的一点个人设计哲学
既然标题里有“6”，最后我也说几句我对第6代AI芯片结构的总体看法。这代结构，算法侧已经全面进入Transformer化和大模型化，端侧又面临着低功耗和高并发的双重要求。硬件侧单靠算力堆叠已经撞上能效墙，再往下卷峰值的边际收益极低。整个设计重心，会从“算得快”转向“送得省、排得顺、融合得深”——送得省是数据流设计，排得顺是调度与存储，融合得深是算子融合与软硬协同。
我近几年参与的项目里，最成功的几个都不是最强算力的方案，而是那种“硬件设计带着全链路软件一起迭代”的项目。流片前，软件团队已经能在仿真平台上跑通目标模型的精度和延迟基线；流片后四周内，真实芯片就能无缝接上原有软件生态。这种团队不一定做得了最前沿的存算一体大突破，但他们把软硬件协同这件事做扎实了，做一版成一版。
我还特别想提醒一点：别被HBM和先进封装那些耀眼名词带偏。对于绝大多数端侧和边缘产品，DDR4/DDR5带宽只要设计时规划得当，加上高效的片内复用，往往就够用了。盲目上HBM不仅成本吓人，还逼着你在软硬件栈上做更多妥协。选型这事，适合远比“账面数字好听”要紧。
至于cortex CPU的大小核调度、DSP的扛指标方式、针对CV任务ISP与NPU的联动设计，这些细项每一块都能写好久，以后有机会再单独拆开聊。这一个系列的终点，其实并不是某一个具体的电路方案，而是一套能持续迭代、让软件发挥硬件潜力的方法论。这也是你如果准备入行AI芯片设计，最值得花时间沉淀的东西。
