做推理 SoC 这几年项目立项时最容易收到的 PPT 都是一句话我们要做一颗 NPU 很强的芯片。但真正走到回片调试你才会发现一颗 SoC 到底行不行往往不取决于它的 TOPS 标了多少而是 NPU、存储和互联这三件事有没有在架构阶段就算清楚。我前后经手过几颗从 NPU 规格定义到回片点亮全流程的芯片踩过的坑不少也沉淀了一些可以复用的设计思路。这篇文章不打算复述教材里的体系结构通识而是按一颗高性能推理 AI SoC 的真实设计推进顺序拆解 NPU、存储层级、片内和片间互联这三个核心子系统每一步为什么这么定关键参数怎么算出来以及哪些地方是流片后才发现、几乎回不了头的环节。如果你正在规划芯片项目、做 NPU 相关的 IP 评估或者单纯想搞明白“推理芯片的算力瓶颈到底在哪”这篇文章应该能给你一条比 spec 文档清晰得多的主线。1. 需求拆解与整体架构思路设计一颗推理 SoC 的第一步不是选核、不是堆算力而是把目标场景的模型需求翻译成硬件可执行的指标。很多团队上来就定“我要 100 TOPS”但 100 TOPS 的 NPU 配一个 30GB/s 的 DDR 控制器跑大模型照样喘不上气。这就是需求和架构没对齐的典型表现。1.1 推理场景为什么需要专用芯片通用 CPU 和 GPU 做推理不是不行只是越往后越难受。模型的算子组合越来越固定访存行为却越来越沉重通用计算单元大量时间在等数据算力峰值连一成都用不满。CPU 侧的问题是并行度不够GPU 侧的问题是能效比和系统复杂度不划算。推理 SoC 对 NPU 的核心要求本质上是把一组特定模型的执行效率压到极致把功耗和时延压进可用区间。从产品角度说端侧需要低功耗、小面积、确定的时延边缘侧和数据中心边缘侧需要更高吞吐和更可控的能效比。一颗好的推理 SoC不会去和训练 GPU 拼浮点峰值而是在“特定算子集、特定 batch 下的单位功耗推理次数”这个维度上做文章。这也决定了架构选型时会比较激进——比如为了跑 Transformer 系模型直接把 attention 的 fused 算子做成硬件原语而不是依赖软件去拼。推理负载还有个特点算子和执行流相对固定不需要通用可编程性做得特别强。所以 NPU 架构设计的自由度比 CPU/GPU 大得多硬件可以针对固定数据流模式深度定制。前几年各家推理芯片架构百花齐放根源也在这里——没有历史包袱没有通用生态要兼容怎么高效怎么来。1.2 从目标模型反推硬件指标架构设计真正的起点是把“延时 20ms”“功耗 5W”这类目标换算成算力、带宽、容量三个硬指标。这里用一个 7B 参数的大模型端侧推理场景做个示例推演。先看算力。7B 模型生成一个 token大约需要 2 × 7B 14 GFLOPs 的计算量。如果目标是一个 token 20ms那需要的算力就是 14 GFLOPs / 0.02s ≈ 700 GFLOPs 0.7 TOPS。这个数字放在今天看很低随便一颗 NPU 都能超过。再看带宽。假设权重用 INT4 量化7B 参数就是 3.5GB。每生成一个 token理论上要把全部权重从 DRAM 过一遍。20ms 内搬完 3.5GB带宽需要 175GB/s。这个数字就比较吓人了普通 LPDDR5 也就 50~70GB/s 水平。算力只要 0.7 TOPS带宽却要求 175GB/s这中间差了至少 3 倍——这就是为什么存储设计在推理 SoC 里比算力更关键。所以真正落地时不可能每个 token 都把全部权重从外部 DRAM 读一遍。必须引入权重驻留、KV cache 复用、多 batch 共享权重等优化手段。这也直接决定了片内 SRAM 容量、NPU 数据流和外部存储带宽的分配方向。架构师在这个阶段要反复做模型花销分析跑一遍目标模型的完整访存轨迹统计权重读取量、激活读写量、中间张量溢出量才能倒推出合理的存储层级配置。这套方法论我建议每个项目都认真做。芯片不是软件流片后发现带宽不够不是改一行配置能解决的那是几百万美金的沉没成本。2. NPU 计算单元算力从哪来NPU 是最容易让人兴奋的部分也是设计里看得最清楚的一部分。它本质是一个超大规模的乘累加阵列外加精心设计的片上缓存和数据调度机制。这里把最关键的设计决策逐一拆开。2.1 MAC 阵列规模怎么定NPU 的顶峰算力公式很直接TOPS MAC 数量 × 时钟频率 × 2。乘一次加一次算两次计算所以要乘 2。反过来从目标算力可以推出 MAC 总量。假设目标 100 TOPS INT8频率目标 1GHz那MAC 数 100 × 10^12 / (2 × 10^9) 50,000。也就是需要 5 万个乘累加器。听起来不多但每个 MAC 背后要配寄存器、数据选择逻辑和布线资源实际面积放大一个数量级不止。如果按每组 16×16 的 MAC 子阵列来组织大概需要 196 组左右。频率的选择比 MAC 数量更敏感。频率往上走时序收敛难度指数上升电压也得跟着抬功耗密度暴涨。所以在先进工艺下宁可把阵列做大一点、跑低频也不要追高频。低频大阵列的功耗效率和面积效率通常都更好这也是 NPU 和 CPU 设计理念差异比较大的地方。CPU 追单核频率是因为串行逻辑绕不开NPU 的计算天然并行堆并行度成本更低。2.2 数据流策略与片上 Buffer 分配MAC 阵列本身不产生算力只有数据喂得进去算力才兑现。这就牵扯到数据流策略。学术界把数据流分成三类权重驻留weight stationary、输出驻留output stationary、输入驻留input stationary。字面意思就是尽量把哪类数据留在片上反复使用。推理场景里权重是固定的复用次数最高所以权重驻留通常优先级最高。具体做法是把一个 tile 的权重加载到片上 SRAM然后把这个 tile 对应的所有输入和输出都算完再换下一组权重。这样权重从外部 DRAM 读取的频率大大降低。但 Transformer 模型又不太一样——attention 计算里激活复用的价值也很大QK^T 的结果要被 softmax 之后继续用中间张量很占空间。所以成熟设计不会只支持一种数据流而是让编译器根据算子在 weight stationary 和 output stationary 之间切换。片上 buffer 的容量分配也很有讲究。假设总片上存储 8MB我习惯的分法是权重 4MB、激活 2MB、输出/临时 2MB。权重给最多因为它承担的是省 DRAM 带宽的主要任务输出累积尽量留在片上避免频繁写回外部存储因为写回同样消耗带宽。这个比例不是固定的如果你的模型里激活特别大可能要把激活比例调上去但“权重优先”这个原则基本不变。2.3 精度支持与量化取舍推理芯片默认支持 INT8这是过去几年的事实标准。但最近越来越多的模型开始用 INT4 做 weight-only 量化FP8 在推理里也开始出现。设计上要早做决定因为这直接影响 MAC 阵列的硬件结构。INT8 MAC 和 FP16 MAC 的面积差很多。一个 FP16 乘法器的面积大概是 INT8 的 2~3 倍而且功耗也高不少。如果目标场景根本不需要 FP16 精度硬塞进去就是浪费。我在实际项目里的取舍是主力用 INT8 MAC 阵列配少量 FP16 向量单元处理特殊算子INT4 通过软件量化工具链转成两个 INT8 运算的组合或专门的小位宽单元。FP8 的话E4M3 和 E5M2 两种格式各有优劣主要看模型动态范围需求硬件上需要额外的指数处理逻辑设计复杂度明显上升不是刚需就别轻易上。低精度带来的收益不仅是算力翻倍更重要的是带宽减半。同样一个 7B 模型INT4 比 INT8 少读一半权重存储带宽压力降一个级别。所以现在很多推理 SoC 走 INT4 路线本质是在缓解存储墙而不是单纯拼 TOPS。2.4 指令调度与多级并行有了阵列和 buffer还得解决“怎么让它们一直忙”的问题。NPU 通常用粗粒度指令控制一条指令完成一个 tile 的计算DMA 负责数据搬运两者通过硬件同步机制协作。最核心的技巧是乒乓缓冲ping-pong buffer——MAC 阵列计算当前 tile 的时候DMA 已经在搬运下一个 tile 的数据了。这样计算和搬运完全重叠外部存储延迟被掩盖掉。多核 NPU 里还要考虑多核调度。如果 16 个 NPU 核同时跑数据搬运的协调就复杂了。常见做法是主核负责任务切分把不同的 tile 分配给不同从核每个核有自己的指令队列和本地 buffer。核间通信靠共享存储和事件同步尽量减少锁和原子操作因为锁竞争在高并行度下很容易成为新的瓶颈。我见过不少项目单核效率很高一上多核就在同步机制上翻车利用率掉到 50% 以下。3. 存储层级带宽和容量怎么匹配存储设计是推理 SoC 里最容易被低估的部分。很多团队把精力全花在 NPU 算力上存储随便挂个 LPDDR 控制器就完事结果流片后跑模型才发现算力有 80% 在等数据。存储墙这东西教科书上讲了几十年落到自己芯片上感受才真切。3.1 存储墙到底卡在哪算力提升的速度远快于 DRAM 带宽提升的速度这是存储墙的本质。一颗 DNN 芯片的单位成本里DRAM 访存消耗的能量比片内计算高一两个数量级。推理模型越大权重读取量越大这个差距越明显。举一个模型示例一个 7B 模型INT8 权重 7GB如果完全驻留在外部 DRAM就算带宽 100GB/s把所有权重过一遍也要 70ms光这个就远超通常的推理时延预算。所以存储墙不是说换个快一点的 DRAM 就能解决而是要在架构层面做精细的层级设计热点数据尽量留片上不可留片上的数据结构化地搬到外部让外部 DRAM 只承担它最该承担的部分。3.2 多级存储的容量与带宽设计原则推理 SoC 的存储层级一般是这样寄存器/累加器 → L1 scratchpad局部共享 SRAM → L2 共享 SRAM → 外部 DRAM。每一层容量递增、带宽递减接口带宽近似满足“上一层是下一层的 1/N”的经验法则。具体到一个中等规模推理芯片L1 可以配 512KB × 4 组L2 配 8MB外部接 LPDDR5 或 DDR5。L1 带宽是 MAC 阵列直接消费的必须做到每周期能喂满计算单元L2 负责多核共享和中间结果暂存外部 DRAM 只承担冷数据的读取和最终结果写回。层与层之间的数据搬运由 DMA 引擎负责搬运粒度对齐 cache line 或 DRAM page这样可以最大化 burst 效率。容量到底够不够判断标准是“权重驻留率”。假设模型某一层权重 2MBL2 有 4MB 可用那至少能装两层驻留率高外部带宽压力就小。如果模型一层权重就 8MBL2 只有 4MB那只能拆 tile 跑外部带宽马上变成瓶颈。所以 L2 容量和模型权重尺寸的匹配关系要在架构定义阶段就用真实模型跑一遍。3.3 外部存储方案选型HBM、LPDDR、DDR 怎么选外部存储选型决定了芯片的成本、功耗和可达到的带宽上限。常见的几个选择各有适用场景我整理了一个对比存储方案单颗带宽典型容量成本/功耗适合场景LPDDR5/5X50~100GB/s8~32GB中等端侧、边缘盒、低功耗设备DDR550~100GB/s16~128GB中低通用边缘计算、服务器边缘GDDR6200~500GB/s8~32GB中高高吞吐推理、边缘加速卡HBM2E/HBM3500~1000GB/s8~64GB很高数据中心推理、大模型加速带宽和成本成正比这是硬道理。HBM 贵在 interposer 和 TSV 工艺但确实能解决很多痛苦——模型权重驻留在 HBM 里带宽不再是瓶颈设计重心可以从“省带宽”转向“提高计算利用率”。但手端设备根本放不下 HBMLPDDR 是唯一合理选择。我的建议是不要把选择留给后端。架构初期就用目标模型的访存轨迹做带宽预演如果外部带宽需求超过单颗 LPDDR 的 70%赶紧考虑双通道或多个 LPDDR 颗粒不要指望优化能省下来。带宽这东西省一点容易省一多半基本不可能除非你的模型结构特别规整。3.4 数据布局与内存分配策略硬件确定了软件侧的内存分配同样关键。模型权重加载到 DRAM 时布局要对齐、通道交织、Tile 化这些听起来偏软件但直接决定 DMA 搬运效率。DMA 搬运的最小单元通常是 64B 或 128B如果你把数据排布成跨 page 的小块每次搬运可能触发页冲突和 bank 冲突实际带宽掉 30% 以上。正确的做法是把模型按层按通道切成大块连续内存确保每次 DMA burst 能拿到足够长的连续数据。权重、激活、输出分别划在独立内存区域避免互相干扰。编译器在生成指令时就要完成内存规划这个规划的质量会直接影响最终的端到端推理时延而且差得不是一星半点。4. 互联设计让数据和指令流动起来互联设计在推理 SoC 里经常被一笔带过但其实是回片后最容易出鬼问题的部分。一个 NPU 核的内部可以做到很干净一堆核连起来、再连到 CPU、连到外部接口问题就开始冒出来了。4.1 片内互联拓扑总线、Crossbar、Mesh小规模 SoC 用 AXI 总线就行简单可靠工具链成熟。但到了 16 核 NPU 以上总线带宽不够仲裁也麻烦必须上 NoC片上网络。拓扑选择上有几条路。Crossbar 延迟低任意两个节点直达但面积和布线随端口数平方增长频率也做不高。Mesh 是面积效率最高的方案多跳延迟可以通过优化路由来缓解但 QoS 设计复杂。还有 Ring 拓扑带宽和面积介于两者之间适合中小规模。以一个 16 核 NPU 为例我做过 4×4 mesh 的方案。每跳的数据位宽是 128bit 1GHz单跳理论带宽 16GB/s但这只是理想值。实际要考虑路由计算、仲裁冲突、流控反压有效带宽能到 60%~70% 就算不错。多核同时访问共享 L2 时mesh 的拥塞点往往在 L2 控制器的输入端口这里要配足够深的缓冲和合理的仲裁策略。4.2 一致性是个陷阱这里想认真提醒一下推理 SoC 的存储一致性设计不比计算单元简单而且很容易被低估。CPU 和 NPU 之间到底要不要做 cache 一致是整个互联架构最容易走弯路的地方。推理链路里CPU 负责调度和任务管理真正跑数据流的是 NPU 的 DMA 和计算阵列。NPU 的数据流动是从 DRAM → DMA → 片上 SRAM算完再 DMA 写回完全没有软件 cache 参与。这种情况下强行做完整的硬件 cache 一致性方案比如用 CCIX 或 AMBA CHI代价非常大——大量的 snoop 开销、目录开销、验证复杂度换来的收益却很小因为 NPU 根本不需要在 CPU cache 里找数据。更合适的选择是让 NPU 走非一致路径直接物理地址访问 DRAMCPU 只维护描述符和同步信号。同步机制用门铃中断和事件信号比如 CPU 写好一组描述符后发起一次 DoorbellNPU 收到后开始搬数据算完再发一个中断通知 CPU 读结果。这个方案省掉了大量一致性协议的开销设计和验证都轻松很多。前提是描述符和结果缓冲所在的 cache 区域要做好显式 flush不然真会出现 CPU 改了描述符内存NPU 拿到的还是旧值的问题。这个坑我后面还会细说。4.3 外部互联PCIe、CXL 和多卡组网推理芯片很少孤立存在要么挂到服务器主机上要么组多卡集群。外部互联的带宽和时延特性直接决定系统能跑多大的模型、多快的同步。PCIe Gen5 x16 理论带宽 64GB/s但这是双向总和。实际做 DMA 读时有效带宽取决于包大小和延迟。如果数据包只有几百字节带宽利用率会掉得很惨大块传输才能逼近理论值。所以和主机通信时DMA 描述符的聚合设计很重要尽量攒成大块再发。CXL 是在 PCIe 物理层之上扩展出的缓存和内存语义协议用来做内存池化、设备间共享内存很合适。对推理 SoC 来说多颗芯片通过 CXL 共享一个内存池是缓解单颗芯片容量不足的一种方案。但要注意CXL 的带宽上限受 PCIe 物理层约束别指望它是免费午餐。多卡推理集群里更常见的还是 PCIe Switch 加 RDMA over Ethernet 的组合先通过 PCIe 做主机内部通信跨节点走以太网和 RDMA。同步梯度或分布式推理中间结果时RDMA 的单边读写能显著降低 CPU 开销这个对扩展性非常关键。4.4 多 Die 互联与 Chiplet 方案单颗 Die 做到一定程度良率和成本会非常难看NPU 计算密度太高一块 die 塞不下足够多的 SRAM 和 IO。越来越多的推理 SoC 走 chiplet 路线计算 die、存储 die、IO die 分开做再用 Die-to-Die 接口互联。Die-to-Die 接口有两条路线UCIe 和自定义 SerDes。UCIe 是现在最被看好的标准化方案优势是成熟的物理层定义、低功耗、跨工艺可复用适合做可扩展的 chiplet 生态。自定义 SerDes 可以做到更高带宽或更低的片内功耗但验证成本高而且一旦以后想换供应商的 die接口规格不统一就麻烦。我的个人倾向是只要不是极端性能需求优先选 UCIe把精力留给真正出差异化的 NPU 架构和存储方案。Chiplet 方案里还有一个容易忽略的问题Die 间互联的功耗和热。Die-to-Die SerDes 每比特的能耗虽然比片内互连高但比走 PCB 的外部接口低一两个数量级这本身就是收益。不过多个 die 堆叠或并排放置时热点分布会变化封装设计和散热方案要在早期就介入不然后端会说“你这个 floorplan 我压不了功耗”。4.5 启动流程与固件初始化顺带说一下 SoC 启动这虽然不是互联直接相关但和整个系统的“可用性”强相关。推理 SoC 的启动流程一般是BootROM 最先跑完成最基础的时钟、PLL 和复位配置然后从外部存储加载引导程序引导程序再初始化 DRAM 控制器、NPU 电源域和 NPU 固件。NPU 固件跑起来之后才把模型权重从外部存储搬进 NPU 的 SRAM 或后续外部内存。这里有个实际易踩的坑NPU 固件本身要加载到 scratchpad 或专用的 SRAM 区域而且这个加载过程也走 DMA。如果启动时 NPU 对应的电源域还没就绪DMA 可能访问到未上电区域产生总线错误。所以固件加载顺序和电源域上电顺序必须严格对齐。这个需要 RTL 和固件团队联合确认不能各写各的回片前就要把启动时序理一遍。5. 回片之后常见问题与排查经验硬件回片只是开始真正打磨是在调试阶段。这一节整理了我在多颗推理 SoC 上实际遇到并解决过的问题按出现的频率排序希望能帮你少走弯路。5.1 带宽地板效应利用率上不去的头号原因现象很典型NPU 峰值算力很漂亮跑 benchmark 单算子效率也不错一跑完整模型利用率就只有三四成。排查时先用性能计数器看 stall cycle 分布如果wait_dma占比超过一半基本可以断定是带宽问题而不是计算单元的问题。对策要从几个方向同时做一是调 tile 大小让每次 DMA 搬运的块更大二是把权重预取窗口从 1 个 tile 扩到 2~3 个 tile让 DMA 提前跑三是检查数据在 DRAM 里的排布是否连续有没有跨页导致读放大。我遇到过最夸张的一次只是把 L2 预取窗口扩大Transformer 模型吞吐提升了 40%。这种优化不用动硬件收益却非常可观建议回片后第一件事就做这个。5.2 功耗瞬态冲击回片后最容易翻车NPU 从 idle 跳到全速运行瞬间电流变化极大这个冲击如果没处理好最直接的后果是电压跌落然后时序违规逻辑出错看起来就是偶发性的计算错误特别难查。排查和预防的经验设计阶段在 NPU 电源域预留足够的去耦电容面积别为了省面积把 decap 砍掉。动态调频调压的爬坡策略要设计成逐级渐变不要直接跳变。回片后的测试要专门做瞬态功耗冲击测试用真实模型跑 idle→full load 的切换观察电压噪声波形确认留有足够裕量。这个测试建议放在最初一轮越早发现问题越好改。5.3 DMA 死锁与描述符 Cache 一致性问题多路 DMA 同时搬运时如果资源分配顺序设计得不好会出现死锁DMA A 占着 buffer 1 等 buffer 2DMA B 占着 buffer 2 等 buffer 1两边都在等谁也动不了。防护办法是规定所有 DMA 通道对共享 buffer 的分配顺序一致要么低编号优先要么用一个硬件优先级表并且预留超时中断方便现场抓状态。另一个容易踩的是描述符被 CPU 篡改的假象。我们曾遇到 DMA 行为完全不可预测搞了很半天才发现是 CPU 改描述符时命令写到了 cache 里但 DMA 读的是 DRAM两边数据不一致。解决办法就是在 CPU 写完描述符后显式执行 cache line 刷新。这个需要在软件驱动里加两行代码但很多人第一次做 NPU 集成时容易漏掉。5.4 工具链和编译器硬件没问题问题在算子映射回片后另一个高频问题是“同一颗芯片换个模型性能差好几倍”。硬件本身没 bug是编译器没把算子映射好。最常见的是卷积用矩阵乘实现时没做 im2col 优化稀疏的算子硬生生跑成了稠密计算浪费大量 MAC 周期或者 attention 里的 QK^T、softmax、PV 被拆成多段中间张量来回来回搬带宽瞬间爆炸。我强烈建议在架构阶段就把算子融合的接口定义清楚至少让编译器有能力把 attention 的整体计算、LayerNormQKV 融合成一个硬件调度单元。我自己经手的一个项目里把 QK^T 和 softmax 做算子融合后端到端推理时延降了 30% 以上而且没有改一行 RTL。5.5 别忽略系统级验证的覆盖场景系统级验证环节经常拖到最后才做结果也是最容易让项目翻车的。光验证 NPU 单点和存储读写还不够一定要把系统级的数据流场景跑通CPU 启动固件 → NPU 加载模型 → DMA 开始搬运 → NPU 计算 → 结果写回 → CPU 读结果这个全链路要尽可能早地在仿真环境里跑起来。还有一个场景是异常注入。DRAM 访问延迟在真实系统里是波动的遇到刷新周期、bank 冲突一次访问可能比平均延迟多好几倍。但如果总线协议里没有超时处理可能直接挂死。这个在 FPGA 原型验证时很容易测出来。建议在架构定义时就把超时、重试、错误上报这些机制写清楚不要等到后端流片之后再补那就真的晚了。我做了几颗推理芯片之后最深的体会是算力是“买得到”的——堆 MAC、堆面积总能把峰值做上去但带宽是“攒出来”的互联是“求出来”的它们需要全链路一起参与设计而不是最后再补。很多团队把重心放在 NPU 的 TOPS 数字上流片后才发现真正决定产品体验的其实是存储带宽和互连调度。如果你也在规划一颗新的推理 SoC我建议立项初期就认真做一次全链路模型推演把目标模型的访存轨迹完整跑一遍再用这个轨迹去反复压测存储和互连架构。这一步做扎实了后面回片后的麻烦会少很多。