1. 移动端部署 DeepSeek 前先过一顿“算账”这两个月我一直在折腾端侧大模型手上的项目从语音摘要、写作助手到端侧知识库问答都试了一轮。最直观的感受是模型面世的速度远远跑在了硬件适配前面。去年不少团队还在用 10B 以上的大模型做云端推理今年开源社区里已经到处都是 1.5B、3B、7B 的蒸馏小模型甚至还有人在 4G 内存的旧手机上跑通了对话。于是问题就变成一个非常现实的问题这类低参数量模型能不能可靠地吃下移动端那颗 NPU 的性能做到平时不发热、断网也能用、随手打开就能说话。先说结论能但别把 NPU 当成“免费的算力黑箱”。DeepSeek 系列尤其特殊——它是典型的 Transformer 大模型结构在浮点算力、显存带宽、动态形状三个方面都刚好踩在移动端的痛点上。把它搬到手机 NPU 上真正卡壳的往往不是模型的“肚子”有多大而是四个字喂不喂得饱。1.1 内存墙、带宽墙与功耗墙很多教程会告诉你“量化到 INT4 就好啦”但实际操作中每个阶段的瓶颈完全不同。我把它们拆成三堵墙来理解容量墙模型权重多大内存就得预留多大。以 7B 模型为例FP16 权重要占 14GBINT8 也要 7GBINT4 才能压到 3.5GB 左右。手机内存一般 8GB 起步但系统、App、NPU 驱动、推理框架还要瓜分一部分。结论很简单7B 基本是移动端的上限5B、3B、1.5B 才是日常。带宽墙LLM 解码是一个“权重搬运”任务。每生成一个 token就要把整套权重从内存搬到计算单元过一遍。手机上 LPDDR 内存带宽也就几十 GB/s就算 NPU 算力再猛带宽不够时依然会被拖住。实测中 7B INT4 在旗舰平台和新款中端平台的差别远没有想象中大——因为大家都在内存带宽的瓶颈上排队。功耗墙GPU 解 LLM 确实快但峰值功耗很容易破 6W、8W几秒就烫手。NPU 优势不在“峰值算力”而在“能效比”。同一道矩阵乘NPU 的 INT8 算力功耗往往只有 GPU 的零头这对需要连续出字的对话场景太关键了。所以我把 DeepSeek 蒸馏小模型视作移动端 NPU 的“标准身材”。参数量、上下文长度、精度损失都控制在一个相对合理的区间适合被拿来当试验田。1.2 DeepSeek 这个系列哪些分支适合端侧DeepSeek 是一个庞大的模型家族不是所有版本都能下放到移动端。开源的蒸馏系列里有几个不同参数档位1.5B、7B 等还有大参数量的主模型。端侧我们真正值得关注的是蒸馏小参数量分支它们保留了强推理和指令跟随能力但参数规模小了一个量级。顺带提一句很多人忽略了一个问题上下文长度。端侧模型就算权重很小KV Cache 也会随着上下文长度线性膨胀。比如 7B 模型配备 40 层结构hidden size 在几千缓存 4K token 可能就要吃掉几百 MB 内存如果做 32K 长文档光 KV Cache 就能冲破 2GB。所以部署前先问自己应用真的需要 32K 上下文吗大多数助手场景 2K 到 4K 已经非常够用。这个取舍直接决定能不能在 8GB 手机上稳定跑。1.3 NPU 为什么比 CPU/GPU 更值得押注手持设备上有三块可编程计算单元CPU 擅长串行和复杂调度GPU 擅长大规模并行浮点计算NPU 则是为“定点矩阵乘加”定制的专用加速器。LLM 的解码阶段里80% 以上的计算量集中在矩阵乘而矩阵乘正好是 NPU 的“主场”。只要把算子映射对路NPU 就能以比 GPU 低得多的功耗完成同样的矩阵乘。但反过来也要有个预期NPU 不是万象通用处理器。它对各种“怪算子”的支持非常有限比如一些非线性激活函数、注意力里的 softmax、某些开方和除法可能根本没有实现。这部分代码要么走 CPU要么用等价算子替换。理解这一点后面才不会被“不支持该算子”的报错弄到怀疑人生。2. 移动 NPU 的“势力范围”它擅长什么、卡在什么如果你之前只在 PC 上用 GPU 跑大模型第一次接触手机 NPU 会很不习惯。NPU 的编程模型更像一个“保姆式加速器”你告诉它算子图和张量在哪它把你的输入切成 tile逐块搬进内部缓存算完再搬出来。整个过程高度规律但灵活性很差。2.1 核心计算DSA 专用架构的长处与短板NPU 内部通常由大量 MAC乘加阵列组成配合深度流水线、大缓存和专用数据搬移引擎。这种 DSA 架构的优点是在定点计算上效率极高INT8 算力可以做到同功耗 GPU 的好几倍而且访存模式固定无需复杂的指令调度。短板也来自这种“专用”不支持复杂、动态的访存模式。比如 gather、scatter 这类操作在 NPU 上实现起来效率极低或者干脆不支持。对非规则 shape 不友好。模型如果频繁改变序列长度NPU 的编译器和执行引擎就会反复重新 partition推理延迟出现明显毛刺。算子之间如果存在大量“小而碎”的张量运算NPU 的流水线会被打断性能可能连 CPU 都不如。在端侧跑 DeepSeek 这类模型时“破碎算子”是躲不开的。经典例子是注意力机制里的 softmax 和残差连接这些都是逐元素操作NPU 也许加速不了常规做法是在 CPU 上完成再把中间结果交给 NPU 做下一步矩阵乘。于是推理过程里就出现了一条隐形而重要的“算子分工”——这也是整条部署链路里最容易被低估的部分。2.2 一张算子支持表值多少钱动手前最好先找齐三份材料NPU 的算子支持列表、推理框架的算子融合能力、模型里实际出现的算子集合。把它们并排放在一起立刻就知道哪些算子要重写、哪些要改成结构等价的替代方案。实际操作里我总结了一个简化的算子分类法类型代表算子NPU 上的通常待遇处理策略矩阵运算MatMul、Conv、Gemm强项直接映射尽量合并成更大算子张量变换Reshape、Transpose、Concat可能支持但低效能省则省或放 CPU逐元素Softmax、LayerNorm、SiLU部分支持精度敏感算子替换或 CPU 回退动态控制动态 Shape、条件分支基本不支持固定长度、静态化输入量化敏感RMSNorm、RoPE量化误差容易被放大部分保持 FP16 或更高精度很多人看到“矩阵乘能跑”就开心了结果部署完发现延迟惨不忍睹。实际原因往往是一个 softmax 回退 CPU 导致张量在两个单元之间来回倒腾每次拷贝都是几百微秒。算力省下的钱全被数据搬运烧光了。2.3 模型结构层面的“NPU 友好化”改造顺着上面的表我可以给 DeepSeek 蒸馏模型做一个通用的结构体检哪些结构是 NPU 的救命恩人哪些是杀手标准 Transformer DecoderLayer 基本是 NPU 友好的Self-Attention 里的大矩阵乘是主力MLP 也是纯粹的大矩阵乘。KV Cache 的拼接操作是个隐形坑。每次生成一个新 token都要把之前的 KV 和新的 K、V 拼起来。如果 NPU 对 Concat 支持得不太好建议把整块 KV 内存预分配写入时用“索引定位”而不是反复拼接。RoPE旋转位置编码通常需要三角函数运算NPU 不划算我会把它提前在 CPU 上算好对应的旋转矩阵或者干脆在拼接前直接作用于 K、V 张量上减少 NPU 侧的非矩阵算子。这些改造不改变模型的数学本质只改变计算图的表现形式是工程上最划算的一步。3. 从权重到能跑转换、量化、对齐三步走部署 DeepSeek 到 NPU我在实践中基本沿一条主线拿到开源权重转成中间图格式再交给端侧推理框架最后落到 NPU 驱动。每一步都有各自的坑。3.1 选基底用什么权重、什么导出方式先选定参数量。我个人建议从 1.5B 或 7B 的版本开始不要一上来就挑战 14B。接着要做的第一步是把模型转成通用图格式。为什么这一步不能少因为 NPU 工具链只认它们定义的算子图多数平台没有能力直接解析训练框架的 checkpoint 结构。转换时注意两点尽量固定输入尺寸。虽然框架支持动态 batch 和动态序列长度但 NPU 的预编译器需要先做内存规划尺寸固定能让它生成更理想的执行计划。把不需要的训练算子剪掉。导出时务必冻结 BatchNorm、Dropout 这类训练期算子同时关掉梯度计算否则图上会残留一堆 NPU 完全不认识的东西。我在这个环节见过最离谱的报错是模型的输出只是差了一个平方最后发现是转换时把某个激活函数“吞掉”了导致数量级不一致。这里强烈建议导出后先用 CPU 跑一遍转换图与原始权重输出做一个逐层 Debug 对比。3.2 量化INT8 起步INT4 看技术耐心移动端 NPU 默认走定点计算INT8 是最稳妥的起步点。通过 INT87B 模型权重可以从 14GB 降到 7GB 左右基本上 12GB 内存设备可以跑继续压到 INT4 则是 3.5GB能落到 8GB 的机器上。但 INT4 不是一个免费午餐。常见做法有两种PTQ训练后量化拿几百条有代表性的 prompt 跑一遍模型统计每个通道的数值范围再映射到整数。优点是快缺点是在敏感算子比如注意力中的 softmax 输入、最后的分类层上误差会放大。QAT量化感知训练把量化误差“模拟”进前向过程从头微调几个 epoch。效果好但需要准备训练数据很多人没有这个条件。我在实操中的折中方案是“混合精度”整体 INT8 或 INT4但对几个特别敏感的算子RMSNorm、最后的 LM Head单独保留 FP16。这样做能在内存只增加一点点的情况下把困惑度损失明显拉低。用滑块验证时输出质量肉眼可见地变好了。3.3 和 NPU 驱动的“最后一公里”对齐转换完了不等于能直接跑在 NPU 上。端侧推理框架在加载图之后还会做一次底层算子映射。这里有两种映射结果图编译框架把整个计算图交给 NPU 编译器一次生成可执行 plan。优点是执行效率高缺点是如果图里有不支持的算子整个编译可能直接失败。算子回退框架把图拆成几段支持的段走 NPU不支持的段自动落到 CPU。日常部署建议开这个模式既能跑通又能通过日志看到哪些算子被回退了。判断是否“跑好”有一个简单指标看回退算子的个数和出现比例。昨天我自己跑一个 DeepSeek 蒸馏 7B 模型算子总共有 400 多个回退到 CPU 的只有十几个且都是小算子整体延迟影响在 10% 左右。如果回退比例超过 30%那基本别指望 NPU 性能了先去处理图结构吧。4. 真机调试的实测细节内存、上下文与分载策略图能转完、算子能映射只是“能跑”的起点。真机上的性能又是另外一回事。下面这些细节几乎每一项都是从反复装机中总结出来的。4.1 内存池和 KV Cache 的规划手机上跑 LLM最怕的不是 CPU 算得慢而是内存突然吃紧。推理框架默认会在加载模型时申请一整块内存这块内存不能随便缩小否则执行时可能出现成套的分配失败。我的建议是加载模型前先把应用里可释放的缓存全部释放。为 NPU 预留固定的“工作内存池”不要让系统 memory manager 频繁参与。KV Cache 提前一次性分配最大长度所需的空间。比如序列长度上限设为 4096就把 KV Cache 直接按 4096 分配好。如果只设 2048生成中途报“KV cache exceeded”整个对话就要重启。这个例子我踩过体验极差。4.2 延迟构成首次 token 与稳定吞吐端侧 LLM 有感体验主要看两个指标首 token 延迟从输入到见到第一个字的时间。它包含 prefill 阶段和模型加载、编译、预热等。生成吞吐每秒能吐出多少个 token主要被内存带宽限制。我在一个集成测试环境里用 7B INT4 在旗舰级移动平台上测得首 token 延迟约 2.5 到 4 秒生成速度约 8 到 12 token/s。如果你跑出更差的数字先别怪硬件大概率是前文提到的算子回退过多或者内存带宽分配被其他任务抢了。另一个容易忽略的因素是“保暖问题”连续推理会让 SoC 温度上升触发降频速度可能跌掉一半。持续对话场景必须预留散热阈值。4.3 多核协同NPU 主算CPU 打杂单一 NPU 跑完整图是最理想的状态但现实不是。更稳的架构是“NPU 主算CPU 打杂”NPU 负责 DecoderLayer 里的大矩阵乘这也是计算量的大头。CPU 负责 LayerNorm、Softmax、RoPE 等小算子。数据传输通过共享内存完成避免无谓拷贝。这个分工想做得好需要推理框架支持“异构执行”。好的框架能自动把计算图切成多个子图分配给不同计算单元。如果框架不支持就得自己把切分点定在模型结构最“自然”的地方——通常是 DecoderLayer 的边界。切分点选得好性能提升往往立竿见影。4.4 带着温度看结果功耗与热量曲线聊天应用连续跑三分钟后盖温度能明显感知。于是我把功耗曲线拆开来看模型加载瞬间有一段突刺推理过程中通常稳定在几个瓦特但连续输出时热量会积累。功耗优化的几个方向给 NPU 设定频率上限性能换温度。输出阶段采用“批处理缓存”让同一批上下文的生成更加连续。必要时限制输出 token 速度例如把每秒 10 token 降到 7 token换回更稳的温度。实测在 30℃ 环境下把 NPU 频率上限设在中等档连续生成 5 分钟温度能控制在可接受范围内速度损失可以接受。这个平衡点每个设备不一样建议做成可配置项让用户自己权衡。5. 性能评估什么样的结果算“部署成功”部署成功不等于能跑也不等于跑得快而是达到了“可用”的基准。我给自己的项目定了一套明确的及格线模型加载时间不超过 5 秒。首 token 延迟不超过 4 秒。稳定生成速度不低于 6 token/s。连续工作 10 分钟不因过热退出。对话输出的语义完整度与云端模型差距不明显。5.1 我自己的实测数据参考因为不同机型的 NPU 驱动和内存带宽差异很大单点数字其实没什么横向参考意义。我把自己环境里的结果列出来权当给大家一个“量级参考”档位参数量量化精度首 token生成速度备注轻量1.5BINT80.8-1.2s25-40 token/s接近流畅对话主力7BINT4/混合2.5-4s8-12 token/s可用但有等待感极限7BINT83.5-6s5-8 token/s一般不建议日常用注意这些结果都是“上一代旗舰平台”上取得的新平台通常还有 20% 以上的提升空间。5.2 别只看速度还要测输出稳定性跑分只是第一关更关键的是“输出稳定性”。端到端质量测试时我会准备三类用例知识问答考察事实性是否会因为量化出现幻觉明显增多。数学推理考察多步推理是否崩坏这是量化误差最敏感的场景。长文本摘要考察上下文超过 2K 后输出是否开始跑偏。量化模型常见问题是短文本无感到长上下文中段就开始逻辑断裂。这通常和 RoPE、注意力计算的数值精度有关。所以我在部署结束后一定会拿长文本做一轮回归而不是只看几个 prompt 的结果。这里没有捷径只能靠数据说话。6. 绕不开的深坑动态形状、预热与兼容性最后这部分算是我送给后来人的“排雷手册”。任何一条都能让看似完美的部署计划推倒重来。6.1 动态形状是 NPU 性能案发现场Transformer 在推理时序列长度从 1 到 4096 不断变化。如果计算图把序列长度当成动态维度NPU 编译器可能做不到静态内存规划每次都要重新推导开销。我的做法是预填阶段用小批处理一次计算完整 prompt。解码阶段固定 batch1把输入长度统一成固定 chunk。把“生成第 N 个 token”的过程用静态形状的算子子图表达。这样做之后性能毛刺明显减少延迟曲线更平滑。6.2 模型预热第一次调用慢到离谱很多失败案例源于“第一次慢”。第一个问题发过去可能要等十几秒后面才快起来。原因很简单NPU 编译和显存初始化都在首次触发。处理办法是启动 App 后立即在后台跑一次“预热推理”哪怕只生成一个空 token把编译、内存申请、驱动初始化全部完成。用户真正开始对话时性能就正常了。6.3 兼容性矩阵驱动版本和框架版本锁死移动端碎片化是老生常谈但大模型让这个问题变本加厉。同一种 NPU 在不同系统版本上的行为都可能不一样更别说不同厂商的驱动实现。我的做法是把驱动版本、框架版本、模型文件哈希记录进诊断日志。不可能做到全机型覆盖重点维护“主力旗舰机型 中端热门机型”两条线。遇到无法解释的崩溃先把环境版本回退到上一个稳定组合。这里没有银弹。作为工程人员只能把“版本锁”和“灰度验证”做扎实任何一个 NPU 算子实现出现偏差都会表现为神秘的性能劣化或偶发崩溃。6.4 端云混合才是更成熟的落地姿势回到开头说的DeepSeek 移动到 NPU真正的落地形态不一定是“所有请求都在端侧完成”。我最后确定的架构是端云混合端侧小模型负责短对话、离线场景、敏感隐私数据。云端大模型负责长文档、复杂推理和高质量生成。通过上下文压缩和路由规则把请求智能分流。这样做的好处很明显省电、省流、私密还能在断网时保住基本体验。而端侧 NPU 部署正是这套架构里最关键的“地面部队”。它不需要取代云端只需要在离线时刻扛住主阵地。我在整个项目里最大的体会是“能不能用 NPU 跑 DeepSeek”其实不是一个二元问题。很多团队做到“能跑”就停了但真正有价值的反而是后面那两步——能不能跑得稳能不能在限定功耗里持续输出。如果你也准备入这个坑建议从 1.5B 起步先把算子支持表摸透再一步步往上提参数量。每多跑通一档你就会更清楚 NPU 的边界在哪里而这份“边界感”比任何跑分都值钱。