没搞过 AI 芯片的人第一次看到 NPU、TPU 这几个缩写多半会以为是 GPU 的某个变种。实际用下来这玩意的脾气跟 GPU 完全不是一回事。它在跑大模型推理的时候确实快但这个“快”不是你写几行代码就能白捡的它要求你把数据搬移、算子切分、内存复用都算计到极致。这篇文章专门拆一下 NPU/TPU 硬件加速这章的核心逻辑从硬件原理一路聊到性能调参的实战细节希望能帮那些刚接触 AI 加速硬件的人少走几周的弯路。1. NPU 和 TPU 的架构设计为什么要跟 GPU 去中心化1.1 从“通用并行计算”到“特定算子计算”的思路转变GPU 的核心思路是通用并行它假设你扔给它成千上万个线程它能帮你把这些线程的大规模计算并行调度起来但这个调度本身是有成本、有冗余的。你做卷积、做矩阵乘GPU 的底层硬件仍然在按通用指令流的模式去取指、译码、调度只是它靠庞大的计算单元数量把这个覆盖掉了。NPU 和 TPU 的思路就“野”得多它们认为既然 AI 训练和推理最终都能收敛到矩阵乘加、卷积、归一化这些固定计算模式那我就把这些模式直接在芯片里做成物理电路把“软件算子”变成“硬件流水线”。你在跑矩阵乘的时候数据从片上缓存流动到计算单元阵列按固定节拍计算完按固定路径写回。这个过程中根本没有“调度”这个环节或者说调度在硬件布局阶段就已经完成了运行时不产生额外开销。我用一个生活化的类比GPU 像是那种全能型厨师你点什么菜他都能做但每道菜都要临时看菜谱、找锅找料NPU/TPU 更像预制菜工厂的流水线它只做十几道固定菜式但每道菜从下锅到装盘都是固定路径速度当然快代价是你不能指望它在流水线上给你做剁椒鱼头。这就是 NPU/TPU 的最大特点你拿到手里的不是一个可编程计算设备而是一组被固化的“计算流水线”你要做的不是写代码而是把自己的计算流程“贴合”到这些流水线上。1.2 脉动阵列和片上存储硬件加速的命根子这章标题里的 TPU早期架构核心是脉动阵列Systolic Array这个设计非常老八十年代就有学术底子但真正量产并大放异彩是在深度学习时代。脉动阵列的直观理解是它把一堆乘法器组织成二维网格数据从左到右、从上到下像波浪一样在阵列里流动每个乘法器负责把流经它的权重和激活值相乘并累加。这个设计最狠的地方在于数据复用。比如做矩阵乘 C A × BA 的每个元素会被多条权重乘加复用。传统架构里每个元素要么从寄存器反复读取要么从缓存反复加载脉动阵列里A 的一个元素进入阵列后被一路传递、与多列权重相乘全程只经历一次全局加载。这种数据复用直接让“从内存取数”这个最耗电、最耗时的环节急剧减少计算能效自然就上去了。但是脉动阵列有个要命的前提你的数据流必须按它的节奏喂进去不能跳着给。这意味着你的算子必须能被拆解成前一层输出直接成为下一层输入的模式。好在卷积和矩阵乘天然满足这个条件这也解释了为什么 NPU/TPU 只在深度学习场景里凶猛一旦你要跑随便一个图算法性能立刻跌到不忍直视。片上存储是另一个关键设计。经常有人问“为什么 AI 芯片缓存做得这么大、层级这么多”答案是AI 芯片的运算单元一旦铺开每秒能吞吐的数据量是惊人的如果全部依赖外部存储数据带宽瞬间成为瓶颈。NPU/TPU 普遍在每颗芯片内部塞入大容量 SRAM用软件显式管理数据块手动把下一轮计算要用的数据提前搬进片上让计算单元一直处于有活干的状态。这个“手动搬数据”的步骤就是你写 NPU 程序时最常做的事情也是加速效果能不能发挥出来的分水岭。2. 工具链和开发模式为什么程序员拿到 NPU 后第一时间感觉“倒退十年”2.1 编译器和调度器你不再直接控制线程如果你是从 CUDA 切到 NPU 的开发者最初的不适应会非常强烈。CUDA 里你可以明确创建线程块、控制共享内存、弄同步屏障NPU/TPU 的开发模式下你写的往往是一种“算子级”的描述语言然后一个专用编译器负责把算子映射到硬件流水线上。你连“线程”这个概念都感知不到更不用说手动控制了。实际开发时你会面对两种层级的工具一种是底层接口允许你把数据搬运进片上存储、启动计算指令、等待完成标志每一个动作都需要你显式写代码控制另一种是高层封装你可以只写算子逻辑和算子间的连接关系编译器负责调度、分配缓存和生成数据搬运指令。多数团队的首选方案是先走高层封装原因很简单纯手写底层调度代码量会膨胀 5 到 10 倍而且极易出错。不过我强烈建议你在熟悉高层封装后抽出时间读一遍编译器生成的中间表示你会对“编译器到底怎么理解你的算子”有一个直观认知。实际工作经验告诉我能读懂中间表示的人调优能力比只会改超参数的人高一个档次。比如我曾在调试一个卷积时发现编译器生成的循环顺序和我预期的完全不一样数据访问局部性差了一截这个信息不到 IR 层根本看不出来。2.2 存储层级的手动管理与限制NPU/TPU 的存储层级通常包括全局内存、片上存储、寄存器/累加器三层容量差异悬殊。全局内存可能十几个甚至上百 GB片上存储通常不过几十 MB。这意味着不管你的模型多大计算过程里数据和中间结果总得在层级之间来回搬迁。如何在有限片上空间里划分每个张量的存放区如何让数据的生命周期不重叠以复用空间这是每个写 NPU 程序的人必须解决的问题。实际操作中的技巧是“双缓冲轮转”把片上区域切成两块一块给当前计算用另一块预先装载下一轮计算所需的数据。计算结束后立刻切换角色搬运和计算并行执行。这个策略能极大掩盖数据搬运延迟。初次上手的人最容易犯的错就是数据搬运和计算串行执行计算单元等数据空转性能损失动辄减半。你自己写几千行调度代码的时候才能真切体会到硬件加速其实是一门“让数据别闲着”的功夫。2.3 低精度量化的硬件底层支持NPU/TPU 通常对低精度计算有物理级支持INT8 的乘加单元吞吐量是 FP32 的好几倍少数情况还支持更激进的格式。要想充分榨取性能模型量化几乎是必经之路。但实践中有个常见误区很多新手认为“硬件支持 INT8我只要把模型直接转 INT8 就完事”。实际上精度转换带来的量化误差、动态范围裁剪、溢出保护这些都需要你在模型侧做校准和适配。硬件提供的是低精度计算的高速通道但能不能让模型在低精度下不崩是你要解决的另一半问题。通常做法是用少量真实分布的数据做校准集统计激活值范围确定合适的缩放因子再在推理时把缩放融合进算子。这里面经验值很重要校准集数据量不用太大但覆盖度必须够否则某些极端层会被裁剪得面目全非。3. 芯片选型和实践如何避开工具链的坑把模型真正跑起来3.1 针对性选型比对算力、功耗与生态成熟度我的工作中接触过不少团队算法模型跑得六六的一到选型就犯难。从事这个领域的人应该记住一句话芯片选型不只是选性能更是选生态。主流可选的大致分几类各有侧重某类面向数据中心训练/推理优势是软件栈成熟和社区资料多模型迁移最平滑某类强调低功耗和边缘部署适合端侧场景但工具链相对封闭算子覆盖度有限某类主打高能效比浮点或整型矩阵算力密度高适合大规模推理集群但需要投入较大精力做算子适配。我整理过一个简易选型维度供你在开始前对照选型维度关键问题实操建议算子覆盖度模型里的算子是否全部被硬件工具链支持先跑官方算子清单再看自定义算子成本工具链成熟度编译器是否稳定报错信息是否友好试用两周重点踩算子移植流程存储带宽片上SRAM和外部显存带宽是否匹配模型计算量用实际模型跑一遍 profiler看带宽利用率生态资料有没有成熟案例、社区解答速度和深度如何别只看文档去技术社区看真实踩坑帖生产部署经验是否有人已经跑过同等规模的应用同行业案例往往比资料索引更可信如果你是用 PyTorch 训练模型的那类开发者建议优先考虑支持 ONNX 转换或自带前端解析器的方案迁移成本最低。如果公司有成规模的 C 部署团队可以考虑自定义算子空间更大的硬件。反过来如果团队主要用 Python、对底层不太熟选封闭但易用的方案反而能更快落地。3.2 开发环境搭建和编译流程要真正上手一套可复现的开发环境是第一步。通常是这样的流程安装厂商提供的 SDK包含编译器、运行时、调试器、性能剖析器准备交叉编译环境把 host 代码和 device 代码分开编译链接模型转换工具把训练好的模型格式转换成芯片专用格式用模拟器做初步验证再用真实硬件跑性能基线。我在环境搭建阶段吃过一个亏最初没有检查编译器的版本兼容性随便装了个旧版本结果新算子怎么编都报错。后来发现新发布的模型转换工具依赖的编译器内部接口变了旧版本缺了一组关键优化 pass。这类问题官方文档不一定写清楚建议你搭建环境时多做一次版本匹配测试专门拿一个小模型从头到尾跑通确认链路没问题再上大模型。3.3 第一个推理程序的完整实现与逐步调优写第一个推理程序建议别上来就搞大模型。我通常的做法是挑一个非常小的卷积网络比如几个卷积层加一个全连接层把流程完全走通再做性能基线记录。下面是一个轻量推理流程的伪代码# 伪代码加载模型并执行编译 import npu_compiler as nc model_path models/mini_cnn.onnx preprocessed_input preprocess_data(raw_input) compiled_executable nc.compile( model_path, targetnpu, precisionint8, calibrate_datacalibration_samples ) # 加载权重到设备端 compiled_executable.load_weights(weight_path) # 执行推理返回输出 output compiled_executable.run(preprocessed_input)这个流程看起来简单但里面每一步都有隐藏细节。compile阶段你指定的精度选项直接决定了后续是否需要量化校准preprocess_data的输入尺寸、通道顺序、归一化参数必须和训练时严格一致曾经有人用 BGR 顺序的训练数据、在推理时放成 RGB 顺序精度暴跌而不自知。load_weights阶段要注意权重文件的二进制格式和布局是否匹配芯片要求不少芯片对权重做特殊重排直接从框架导出的权重不能直接塞进去。跑通之后的调优工作更加关键。官方工具链都会提供 profiling 工具可以输出算子耗时、带宽占用、缓存命中率等关键指标。我调优时习惯先看两条一是“计算单元利用率”看看核心是不是大部分时间在“忙”二是“数据搬运等待时间”这是最容易捡性能的地方。如果数据搬运等待高得离谱优先考虑双缓冲、加大批处理或调整算子融合策略。4. 把性能榨干的几个硬核技巧数据流重排、算子融合与并行策略4.1 数据流重排从“按逻辑写”到“按硬件走”很多框架导出的模型算子内部的数据排布是为通用性设计的不是为你的目标芯片设计的。比如标准的 NCHW 布局在 GPU 上跑得顺畅但在某些 NPU/TPU 上可能不如 NHWC 或者硬件自定义的 NC1HWC0 布局效率高。编译器通常会自动做布局转换但生成的转换算子本身也有代价。如果你能提前把模型各层的张量布局统一成芯片偏好的格式就能省去大量转换开销。有一个折衷方案先让编译器自动转换用 profiler 观察各层耗时再用布局融合的手段人工消除转换层。数据重排这类优化对最终性能影响极大尤其是卷积层数多、张量维度变化频繁的模型好的布局策略可以直接带来翻倍提速。这里的判断准则是能用硬件原生布局跑就绝不用通用布局加转换层。我在做一个图像处理 Demo 时把模型里的中间张量统一改成目标芯片的 five-dimensional 布局后整体推理时间少掉三成。这意味着什么呢编译器自动安排布局转换虽然可靠但它无法像人工那样纵览全局知道哪些算子可以共享同一种布局从而避免不必要的重排。4.2 算子融合消除中间张量的搬运成本GPU 编程常提 kernel fusionNPU 世界里算子融合的意义更加极致。因为 NPU/TPU 的片上存储极其有限中间张量一旦落到全局内存再读回来就是一笔巨大的开销。为了规避这一点真正的高手会刻意把一系列操作融合进同一个计算流水线让中间结果始终在片上完成传递。最常见的一类是“卷积 激活 归一化”融合。硬件编译器中通常会有一组预定义融合模式但仅靠编译器自动匹配往往不够。你需要从数据流的角度自己识别可融合模式。一个处理技巧是把所有算子按“是否改变张量形状”“是否需要跨层通信”分成不同类别凡是只在元素级做变换的算子都优先尝试与上下游融合成一个算子组。这样做最大的收益不仅仅是省搬运连“启动一次计算流水线”的固定开销也一并省下来了。4.3 多核并行和流水线级联现代 NPU/TPU 不止一个计算核心通常是一组核心互联。要榨干芯片性能不能只靠单个算子的优化还要让多个核心并行跑不同任务或者把一个大型算子的计算拆到多个核心上并行。并行策略的核心依据是“算子之间是否存在数据依赖”。如果两个算子处理的数据互不相干那就可以在不同核心上并行执行如果存在依赖则需要做任务切分把计算拆成若干独立分片分别给每个核心算。在工程实践中常把“数据并行”和“模型并行”搭配起来用让 Transformer 类大模型也能在多核心上流水式跑起来。这里的瓶颈往往在于核心间的数据通信所以一旦并行任务的通信代价超过计算收益就要果断回退到单核心串行执行。我对并行优化的个人经验是先用 profiler 看清楚每个核心的占用率如果某些核心长期空闲表明任务分配不均如果核心都在忙但整体吞吐上不去就要怀疑是否核心间通信太过密集。两种情况的化解手段是完全不同的。5. 常见报错与排查经验实录5.1 算子不支持或编译失败识别是“硬件限制”还是“用法错误”这类问题在 NPU/TPU 开发中最常见。提示信息往往只说某算子不支持但背后原因可能千差万别。我自己排查时会按以下顺序逐步缩小范围先把模型简化成只含该算子的最小示例确认问题是否可复现再检查该算子的输入形状、数据类型、布局是否在工具链支持范围内然后查官方文档或社区确认是否有已知问题记录如果找不到答案就用不同数据格式或参数组合做二分法定位具体触发条件若确认是硬件本就不支持就要考虑算子分解或替代实现。这里有个经验值得分享有时候报“算子不支持”实际是输入张量的形状里混进了动态维度工具链不支持动态形状导致编译期无法静态分配缓存。只要你把动态部分改成固定维度同样的算子马上就能编译通过。遇到报错先别急着换算子先检查形状里有没有变量。5.2 精度异常排查低精度量化后的“假溢出”和缩放因子的问题许多团队在把 FP32 模型切换成 INT8 推理时会碰到精度不如预期的问题。排查看似复杂其实按因果链排查并不难先用全 FP32 跑一遍 baseline确认问题不在算法本身把模型逐层替换成 INT8定位到精度显著下滑的具体层检查该层激活值的动态范围是否存在极端离群值如果范围分布异常用校准数据集重新统计 min/max或改用更稳健的校准方法某些层如果数值波动太大可以考虑保留 FP16 或混合精度执行不必全模型一律 INT8。我印象很深的一个案例是某模型量化后输出完全不靠谱查来查去发现是归一化层之后跟的激活函数在 INT8 里溢出而校准集数据没覆盖到激活峰值区间。后来在数据预处理里加了一小段峰值样本重新校准精度立刻恢复正常。5.3 性能不达标或芯片“空转”问题排查代码跑起来了精度也对但速度不到官方宣称的一半这种情况最让人挫败。我建议用下面的思路来排查打开 profiler统计每个算子的计算时间和数据搬运时间如果某个算子搬运时间远大于计算时间优先优化数据布局和批量大小如果多个算子的计算时间都不长但整体耗时就长检查是否有频繁的任务启动开销如果双缓冲没生效检查是否搬运指令和计算指令没有真正重叠如果多核利用率不均检查任务切分逻辑是否合理。用一张表格来汇总性能排查的常见信号和对策能让你少走弯路现象可能原因优先对策计算单元利用率低数据搬运阻塞算子等待输入开启双缓冲预取下一块数据大量时间耗费在算子启动融合不足小算子过多算子融合减少启动次数多核利用率不均数据依赖导致串行分片调整切分策略优化数据通信反复出现布局转换中间张量布局不一致统一硬件偏好布局消除转换层精度下降明显量化参数不准或溢出重新校准混合精度保留敏感层这些排查似乎在用一堆工具但真正的判断依据是你对硬件流水线的理解是否到位。你越清楚数据是怎么流动的就越容易从现象反推原因。6. 一条务实的进阶路线从“能跑”到“会调”经常有人问我“我没有硬件条件怎么学 NPU/TPU 开发”这个问题关键不在于你有没有实体卡而在于你有没有弄清数据流和计算模式。即使只是在模拟器上跑一个模型并用 profiler 观察算子耗时分布你也能获得一半以上的实战感知。真正稀缺的是调试经验和性能优化手感而这需要一次次跟硬件“较劲”才能积累。我建议刚入门的开发者按这样的路线走用官方模拟器编译并跑通一个小模型记录 baseline把编译中间表示打开看一遍逐个尝试数据布局变更、算子融合、双缓冲这三类基础优化记录每次性能变化找一个规模中等、结构典型的模型比如带残差连接或注意力机制的完整走一遍量化校准的流程观察 profiling 输出里的“搬运等待”和“计算利用率”两个核心指标理解它们如何随优化措施变化。这条路线不看任何书都能走完全部都是动手内容但走完之后你对硬件加速的理解会远超那些只背概念的初学者。我个人在实践中的一个最重要心得是不要一开始就追求“代码技巧的华丽”先把一个朴素但功能正确的实现跑通再用 profiling 数据指导优化。很多自以为聪明的优化方案在真实硬件上完全没有收益甚至加剧了数据移动。硬件加速的本质是“理解物理世界的搬运成本”而不是“写出更炫的算法结构”。最后分享一个我一直沿用的习惯每次拿到新硬件或新工具链我会先在一个固定的测试模型上做完整的性能基线包括编译耗时、单算子耗时、端到端延迟、峰值内存占用等。以后不管做模型优化还是工具链升级只要重跑一遍基线任何性能回退都无所遁形。这个方法在多个项目中帮我在第一时间发现问题希望你也能试试。