每次被问到端侧 AI 的性能问题我都会先反问一句你关注过张量进出 NPU 的方式吗同样是 7B 大模型笔记本上能流畅对话放到手机和迷你主机上却卡成幻灯片绝大多数时候不是模型结构的问题而是“张量到 NPU”这条执行链路没理顺。今天不聊云端的 4090专门把端侧 AI 的底层执行逻辑拆开讲看看从张量到 NPU 之间到底发生了什么。这里谈的“端侧 AI”包括手机、笔记本、迷你主机、摄像头、车载盒子这类设备上直接跑模型推理的场景。内容适合算法工程师、嵌入式开发者以及正在做端侧 AI 硬件部署、研究 ComfyUI 本地调用 NPU 的朋友。读完不需要你成为芯片专家但再遇到 NPU 占用率上不去、算子不支持这类毛病你会知道该往哪个方向查。下面开始。1. 张量AI 计算里那个“最熟悉的陌生人”1.1 从数字到四维张量先搞明白形状不少人对“张量”这个词有莫名的敬畏感总觉得它代表了什么高深数学。实际上你天天接触的数组就是张量只不过程度随维度增加“0 维张量”是一个标量比如模型的 temperature“1 维张量”是一排数比如词向量“2 维张量”是矩阵比如全连接层的权重“3 维以上”全部统称为张量。一个 7B 大模型在推理时输入和中间激活几乎全是一张张或多张维度的张量在来回流动。拿一张图片举例。你在端侧设备上送给模型一张 RGB 图片很多框架会把它组织成[1, 224, 224, 3]这个形状第一个 1 是 batch也就是一次处理几张图后面分别是高、宽、通道。模型内部做卷积或自注意力时会把这张图拆成若干小块每一块本质上又是一个小张量。理解了这一点后面看 NPU 报错就轻松了报错单上大量的“shape mismatch”翻译成人话就是“张量形状对不上运算没法继续”。我见过不少刚接触端侧部署的同学在 PyTorch 里反复打印tensor.shape总觉得心中有数一旦换到 ONNX 或者厂商 SDK看到[1,224,224,3]变成[1,3,224,224]就慌了。这就是张量的“维度顺序”问题也叫 layout。NPU 这类硬件对 layout 极其敏感——同样的数据用 NCHW通道在前和 NHWC通道在后存储计算单元访问内存的模式完全不同性能可能差出好几倍。所以第一步不是急着调算子而是先把张量的形状和 layout 用纸笔画清楚。1.2 张量不只是数值dtype 和 stride 往往决定成败观察张量不能只看形状还得看类型和存储方式。举个最常见的例子服务器上模型权重普遍是 FP32 或 FP16但端侧 NPU 为了省电和省带宽往往希望你把张量压成 INT8、INT4。同样一个[1024, 4096]的矩阵FP16 占 8MBINT8 只占 4MB这意味着从内存搬运到 NPU 计算单元的数据量直接减半。对于带宽受限的端侧设备这一步往往比算力提升更明显。另一个容易被忽略的是 stride步幅。张量在内存里不一定是连续排列的比如你做了一次切片、转置或拼接操作逻辑上还是一个正常形状物理上的数据却是“跳着放”的。NPU 计算时要求张量连续如果你把一个非连续张量直接丢给推理框架轻则多一次隐式拷贝重则直接报“memory not contiguous”的错。实际排查时我习惯先在 Python 里跑一句tensor.contiguous()把数据铺平再看tensor.stride()确认存储间隔这能挡掉一大半看似莫名其妙的端侧部署问题。2. 端侧 AI 的硬件分工CPU、GPU、NPU 到底谁在干活2.1 CPU 的边界能跑模型但不划算以前的端侧推理全靠 CPU摄像头里的人脸检测、手机里的语音识别都是用 CPU 的 SIMD 指令慢慢算。CPU 的优势是通用性强、调度灵活什么算子都能执行但劣势也明显单个核心能同时做的乘加运算太少而且功耗墙卡得死死的。跑一个 0.5B 的小模型还好真要跑 7B 大模型CPU 上每秒生成一两个 token 是常态用户根本没法用。更深层的原因是 Transformer 的结构。自注意力机制里有大量矩阵乘法比如Q和K的乘法形状可能是[ batch, seq_len, heads, head_dim]这需要每秒做几十亿次“乘加”。CPU 的 ALU 虽然也能算但并行度远不如专用芯片频率再高也追不回来。所以现在端侧跑大模型的基本共识是CPU 可以兜底但不能当主力。2.2 GPU 的贡献与限制能跑但电量和体积都不够很多人觉得笔记本上有个独显就能跑大模型了确实能跑但那是“插电状态下的短暂狂欢”。GPU 的并行度很高尤其适合矩阵乘法CUDA 生态又成熟所以很多端侧开发首先想到 GPU。问题是功耗和体积一张笔记本 GPU 动辄几十瓦风扇起飞、续航骤减这对手机、迷你主机、智能摄像头这类设备并不现实。另外端侧 GPU 的显存带宽也远不如服务器卡。大模型推理不只是“算得快”权重读取、KV Cache 读写都需要极高的带宽。GPU 如果腰里别着 DDR 内存而不是 GDDR/HBM带宽反而会成为比算力更严重的瓶颈。于是芯片厂商开始在 SoC 里塞另一块专门干张量计算的单元也就是 NPU。2.3 NPU 为什么是“端侧大模型”的主角NPU 的逻辑很简单与其用通用计算单元去硬算矩阵不如直接在硬件里铺一大排“乘加器”让张量数据像流水线上的工件一样流过去。因此 NPU 往往在很小的面积里堆了大量 MAC乘加运算单元而且用低精度定点计算单位功耗下的算力远高于 CPU 和 GPU。现在无论 AMD、Intel 还是高通、联发科新一代平台上的 NPU 都是为了大模型和张量运算专门设计的。但 NPU 不是万能的。它擅长的是规律性极强的矩阵乘法、卷积碰到动态分支、字符串处理、复杂控制流就比较痛苦。所以你在端侧跑一个完整的 agent 应用时往往是“NPU 管张量密集型算子CPU 管控制逻辑和数据处理”中间由 runtime 负责调配。理解了分工你才能解释为什么换了某款 NPU 后大模型计算部分明显变快但整个应用端到端延迟没怎么降——瓶颈很可能在数据预处理和 CPU 调度上。2.4 一次推理从应用到芯片的完整调度链把一次端侧推理拆开是理解底层执行逻辑的关键。应用层拿到一张图片或者一段文本后会先由推理框架把请求转成内部的“算子图”每个算子都长着张量输入和张量输出随后框架把算子图交给 runtime 调度器调度器根据算子的类型选择合适的加速设备再往下是厂商驱动和芯片固件负责把算子翻译成 NPU 能执行的指令。你平时调的device参数只是这条链路上最靠上的部分。这条链路告诉我们一个实用判断如果 NPU 没被用上不要只怪硬件。先从算子图里找有没有自定义算子、动态形状、非连续张量这些让 NPU 编译失败的元凶。很多所谓“NPU 不支持”其实是算子图里混入了框架无法加速的节点退化到了 CPU。后面我会给几个具体排查方法。3. NPU 执行张量计算的底层循环3.1 MAC 与阵列NPU 的“生产线”是怎么搭起来的NPU 最核心的运算叫乘加英文 MAC。一次矩阵乘法可以拆成无数个“先乘后加”的小操作C[i][j] A[i][k] * B[k][j]。一个乘加单元MAC每次就干这么一件事。NPU 之所以算得快是因为芯片里排列了成百上千个 MAC把它们串成一个矩阵阵列数据从左和上两个方向流进来结果从下或右流出去很像工厂里的流水线。这种结构叫脉动阵列最早在 Google TPU 上大规模使用后来很多端侧 NPU 也借鉴了类似思路。它的好处是复用一个权重矩阵被加载到阵列后可以在不同 batch 的输入上反复使用省去了重复到内存里搬数据的开销。这就解释了为什么“矩阵乘法”成了衡量 NPU 性能的核心 benchmark——因为它就是 NPU 的舒适区。3.2 张量分块和内存复用带宽瓶颈比算力更难缠理想情况下NPU 可以把整个矩阵一次塞进阵列但实际不可能。端侧 NPU 的片上 SRAM 往往只有几百 KB 到几 MB大模型的权重动不动就几个 GB必须在计算前把张量切成很多小块一块块地“喂”进去。这件事叫 tiling也就是分块。分块大小直接影响性能块太大片上内存放不下块太小数据搬运次数变多算力再高也会被带宽拖死。这里引入一个关键概念数据复用。以矩阵乘法为例假设我们把A的一个 64×64 小块和B的一个 64×64 小块同时加载进片上内存那么计算这 4096 个结果时数据只从外存读了一次。如果换成分块过细的方案同样的数据可能要反复读几十次耗电和时间都会成倍增长。所以看 NPU 理论算力之前先看它的带宽和片上缓存大小心里大概就有数了。3.3 从算子图到 NPU 指令一次前向是怎么被“翻译”的模型在端侧设备上运行不是直接把 PyTorch 模型扔给芯片。一般流程是先将模型导出为 ONNX 或厂商中间格式runtime 会做计算图优化比如把连续的算子融合成一个算子再交给编译后端做内存规划、指令调度。NPU 拿到手的不是一个“模型”而是一串紧凑的张量计算指令。这里有一个很多人踩过的坑NPU 对算子类型极其挑剔。矩阵乘法、卷积、GELU 这类算子很受欢迎但 LayerNorm、Softmax 里带的除法和指数运算很多 NPU 并没有专门单元要么用查表近似要么直接分派给 CPU。如果你的模型里这类算子占比高NPU 加速效果会明显打折。所以真正高效的端侧部署都会做“算子融合”把 LayerNorm 塞进前面的注意力计算里减少算子进出 NPU 的次数这是端侧 AI 优化里性价比最高的一步。3.4 TOPS 怎么算标称算力和真实利用率之间隔着什么厂商海报上写的 “40 TOPS” 看起来很吓人实际到手往往只有一半甚至更低。TOPS 指的是每秒万亿次整数运算假设主频 1GHz、一个周期执行 4096 次 INT8 乘加再乘个 2一次乘加等于两次操作大约就是 8 TOPS 左右具体由 MAC 数量和频率决定。问题在于这是“阵列满负荷、数据零等待”的理想值。真实推理中权重要从 DRAM 搬到 SRAM计算完的结果还要写回这些搬运时间都算在端到端延迟里。我实测过一些端侧 NPU跑经典 CV 模型时利用率能到 70% 以上但跑 Transformer 这类需要大量 KV Cache 读写的模型利用率经常掉到 40% 以下。所以选型别只盯 TOPS要看 TOPS/W、内存带宽和实际模型上的 benchmark。4. 端侧部署实操从 PyTorch 到 NPU 的完整链路4.1 选工具链ONNX Runtime、OpenVINO、RKNN 到底怎么选端侧 AI 硬件部署的第一件事不是写代码而是选对 runtime。我见过太多人把 PyTorch 模型拿到嵌入式设备上然后各种算子不支持其实就是没走厂商提供的工具链。这里给一个基于常见实践的选型参考运行框架典型硬件适用场景注意事项ONNX RuntimeCPU / GPU / 部分 NPU跨平台、快速验证需要单独安装 Execution ProviderOpenVINOIntel CPU / iGPU / NPU笔记本、迷你主机、边缘盒子对 Intel 平台优化好支持模型压缩RKNN ToolkitRockchip NPU开发板、摄像头、智能硬件静态形状模型更稳定动态形状易踩坑NCNN / TFLiteCPU / GPU / NPU手机端、轻量模型算子覆盖有限适合小模型如果你要做的正是 ComfyUI 这类绘图工具调用 Intel NPU思路也是一样的先装好 OpenVINO 以及对应的 ComfyUI 插件让插件把大模型的 UNet 或 DiT 部分切成“NPU 请求”与“CPU 请求”。实际使用中NPU 主要加速集成在 UNet 里的卷积和注意力矩阵乘而采样器、图像解码这类杂活依然留在 CPU。很多用户抱怨“NPU 没起作用”多数是插件版本和模型版本不匹配导致的回退到 CPU。4.2 模型导出与张量形状排查先打印再部署拿到一个 PyTorch 模型后我建议第一步先导出 ONNX并在导出时显式指定动态维度。下面这段代码是常见做法import torch model MyModel().eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, model.onnx, opset_version17, dynamic_axes{ images: {0: batch, 2: height, 3: width}, }, input_names[images], output_names[logits], )导出之后先别急着送上设备在电脑上用 ONNX 或者 OpenVINO 检查一下输入输出的张量定义import onnx m onnx.load(model.onnx) for inp in m.graph.input: shape inp.type.tensor_type.shape print(inp.name, [dim.dim_value for dim in shape.dim])这一步能提前暴露动态轴是否被错误固定成了静态值。很多端侧 NPU 需要静态形状才能最大程度优化内存布局如果你发现导出后的形状把 batch 写死了要么重新导出要么在 SDK 里配置动态 batch。还有一个细节导出前确保输入张量是连续的避免模型从一开始就有隐藏的permute和transpose操作给后续 NPU 编译增加额外负担。4.3 量化与校准FP16 到 INT8 的关键参数端侧 NPU 普遍对整数运算更有好感所以动态量化、静态量化是部署绕不开的环节。简单理解FP16 的张量每个数占 2 字节INT8 占 1 字节量化直接把权重量化和激活量化的存储开销减半很多 NPU 的乘加阵列还可以直接处理低精度数据速度快一倍。但量化不是简单的四舍五入而是找准“范围和零点”。per-tensor 量化方法简单但对通道间数值差异大的模型精度损失很大per-channel 量化逐通道做精度好但硬件实现更复杂。端侧部署常见做法是用一组校准数据几百张图片或几十条文本先跑一遍模型统计每个张量的数值分布然后用均方误差或 KL 散度找一个最优截断范围。以 OpenVINO 的工具链举例import nncf from openvino.runtime import Core ov_model Core().read_model(model.xml) calibration_dataset load_calibration_samples() # 典型几十个样本 quantized_model nncf.quantize(ov_model, calibration_dataset) ov.save_model(quantized_model, model_int8.xml)校准数据选得不好会造成“量化后精度突然崩掉”。我的建议是校准集一定要贴近真实业务数据分布。做图像分类就找同类照片而不是下载一堆风格迥异的网图。曾经有项目拿 ImageNet 图片做校准部署到工厂场景后准确率掉了 3 个点换成现场采集的样本后精度立刻回到正常范围。4.4 编译、准备请求与性能调优别让张量搬运白白烧电模型量化完后就要在目标设备上编译并创建推理请求。用 OpenVINO 的 NPU 插拔式部署流程大致是这样from openvino.runtime import Core core Core() compiled core.compile_model(model_int8.xml, NPU) request compiled.create_infer_request() # 假设输入形状是 [1, 3, 224, 224]填充数据可以用 np.fromfile 或 cv2 input_tensor request.get_input_tensor() input_tensor.data[:] preprocess_image(image.jpg) request.infer() logits request.get_output_tensor().data这里有几个很少有人写在文档里的细节。第一compile_model是一次性动作不要在每张图片推理时都调用否则大部分时间都花在编译上而不是计算上第二如果输入尺寸不变可以提前固定形状让 NPU 的内存规划做到最优第三有条件就使用异步推理让数据预处理和 NPU 计算同时进行端到端吞吐量能明显提升。另外尽量在模型里做“算子融合”。手动把LayerNorm 全连接合并到一个自定义算子或者用 runtime 的优化 pass 自动融合都能减少张量在 CPU 和 NPU 之间的往返次数。张量每次过接口都有拷贝成本这个开销在大模型场景下往往比想象中大得多。5. 常见问题与排查技巧实录5.1 NPU“没干活”如何判断模型真的跑在加速单元上最经典的问题明明选了 NPU跑起来 CPU 占用照样 100%速度也没快多少。我的第一反应永远是“查设备映射”。不同框架有不同的查询方式但共同点是看日志和性能计数器。OpenVINO 里可以用core.query_device(NPU)查看支持列表某些框架还能导出每层算子的设备映射比如标注MatMul_123: NPU还是LayerNorm_456: CPU。如果发现关键算子都落在 CPU 上原因通常是模型里有 runtime 不支持的动态形状、自定义算子或者不支持的精度。这时候最实用的办法是“异构执行”只把支持矩阵乘法的子图放到 NPU其余部分留在 CPU。很多框架有个模式叫HETERO:CPU,NPU或者类似的 device hint让 runtime 自动切分。注意异构不是银弹每次设备切换都有数据拷贝。5.2 算子不支持的报错拆图、替换、回退三步走端侧部署最常见的是这类报错Unsupported operator: xxx。遇到别慌按三步处理。先看这个算子是不是必要比如某些辅助算子来自后处理逻辑可以放到模型外部的 CPU 代码里不勉强塞进 NPU其次找替代实现很多算子可以用等价算子组合代替例如把Softmax手动拆成exp div看看 NPU 是否支持最后如果实在绕不开就强制该算子回退 CPU。我经常和团队说不要让一张算子图变成“要么全上 NPU要么全不上”的判断题。大部分产品场景是“大多数张量计算在 NPU少数控制逻辑在 CPU”这个混合状态才更贴近真实性能。关键是减少来回切换比如把需要回退的算子尽量聚在一起避免算子在 CPU 和 NPU 之间来回横跳。5.3 精度对不上先怀疑量化再怀疑 layout模型部署后出现精度下降优先怀疑量化。你需要在同一份输入上对比 FP32 模型与 INT8 模型的输出张量用最大绝对误差或者余弦相似度量化偏差。如果最大误差集中在某个输出通道那大概率是 per-tensor 量化带来的通道间干扰改成 per-channel 量化就能缓解。还有个隐蔽问题部分 runtime 默认输入要求是[N, C, H, W]但你的数据预处理生成的是[N, H, W, C]不转 layout 就直接送进去。这种错不是计算精度问题而是“张量含义”被理解错了。5.4 实时排查速查表平时调试端侧推理时我会按下面这张表一个个查过去建议收藏症状优先检查项常用处理NPU 占用率低算子设备映射、图切分查 runtime 日志异构拆分延迟高且 CPU 满载是否有算子回退 CPU换工具链版本替换算子首次推理极慢模型编译、驱动初始化warmup 一次后续复用已编译模型精度异常量化校准集、layout重做校准对齐 NCHW/NHWC内存暴涨KV Cache 未复用、异步队列无限堆积限制 batch固定最大序列长度6. 最后再唠叨几句我的调 NPU 真实体感把模型从张量一路搬到 NPU做了这么多轮我最大的感受是端侧 AI 的瓶颈从来不是某个硬件的“算力不够”而是整条链路里张量被搬运、转换、切分的次数太多。选 NPU 前先跑一遍你实际要用的模型看算子映射表调优前先打日志确认每个关键算子落在哪个设备发现精度不对先别怀疑芯片回头看看张量的 dtype 和 layout。我也建议真正想入门的朋友不要一上来就挑战最大的模型。找一个小分类网络或者一个 1B 左右的对话模型老老实实走一遍“导出-检查张量-量化-编译-跑性能”全流程。等你亲手在日志里看到某个算子因为一个 transpose 从 NPU 掉回 CPU又通过改代码让它回到 NPU 时你对“从张量到 NPU 的底层执行逻辑”的理解会比读十篇概念文章都扎实。端侧 AI 没有太多玄学把张量的每个细节盯住了性能自然会说话。