1. 先把“慢”量化出来性能基线到底怎么定端侧跑大模型这事儿我前前后后摸索了小半年。标题里说慢80倍听着像夸张其实真不是。同一台手机同一个模型不同的部署方式推理速度能差出两个数量级。我最早拿到一台旗舰机跑一个7B模型生成速度只有不到2 token/s而同一台机器上别人的调优方案能跑到100多token/s。那一刻我才意识到端侧推理的性能瓶颈远不是“手机性能不够”这么一句能糊弄过去的。在动手排查之前必须先搞清楚一件事你到底在跟谁比比的是什么指标。端侧LLM推理一般看两个数字首 token 延迟prefill 耗时和生成速度decode 速度单位 token/s。很多人只看后者但实际体验里首 token 如果磨蹭到三五秒哪怕后续生成飞快体感依然是卡顿的。排查的时候两份数据都要记录。另外还得知道你所在机型的理论硬件天花板。举个例子一台手机的内存带宽如果是 50GB/s那么跑一个 FP16 精度的 7B 模型每生成一个 token几乎所有模型权重都要从内存过一遍光是读权重就需要 14GB 左右的数据量。拿 50GB/s 带宽去算decode 的上限就是大约 3.5 token/s。如果实际速度接近这个数说明系统已基本跑满属于硬件极限如果远低于这个数那就是软件层面出了问题值得往下查。我把自己遇到的“慢80倍”拆成几类原因列了个表后面逐一展开疑似因素表现特征排查难度量化精度与模型格式速度长期偏低但 CPU/内存占用不高低推理框架的算子实现同模型在不同框架下差异极大中异构计算单元未生效GPU/NPU 占用为0CPU 满载中上下文长度与 KV Cache 配置首 token 随对话变长急剧增加中系统调度与功耗限制跑几分钟后速度突然腰斩高注意排查过程中每一步都要记录实测数据。不要靠体感判断机器是不会说谎的但人的记忆会。2. 理论瓶颈优先先判断是不是内存带宽卡死的端侧的 LLM 推理绝大部分时间都耗在 decode 阶段而这个阶段本质上是memory-bound的。什么意思就是计算单元CPU/GPU/NPU在等内存喂数据计算本身反而不是瓶颈。用一个生活化的类比你把一箱货从仓库搬到柜台搬货的人动作再快如果传送带每小时只能送一箱整体速度就由传送带决定。内存带宽就是那条传送带。所以排查的第一步不是打开 profile 工具看算子耗时而是先算一笔账。把模型参数量、量化位数、内存带宽三者摆在一起算出理论下限。计算公式很简单单 token 理论解码耗时 模型权重字节数 / 有效内存带宽拿 7B 模型举例FP167 × 10^9 × 2 14GBINT87 × 10^9 × 1 7GBINT47 × 10^9 × 0.5 3.5GB如果手机内存带宽实测约 50GB/s这个数据可以通过内存读写 benchmark 工具测出来那么FP16 理论最快 50 / 14 ≈ 3.5 token/sINT8 理论最快 50 / 7 ≈ 7 token/sINT4 理论最快 50 / 3.5 ≈ 14 token/s注意这只是理想值。真实场景里还拿不到满带宽能有理论值的60%就算不错了。也就是说INT4 推理跑到 8~10 token/s已经说明系统优化得相当好。我最初踩的坑就在这。第一次用默认设置加载模型框架给的是 FP16 格式手机跑出 1.8 token/s我一度以为手机坏了。后来查了内存带宽又算了理论值才发现 1.8 token/s 离 3.5 token/s 的理论上限还很远但方向已经对了——瓶颈不在 CPU 算力而在内存搬运。从那之后我所有的排查都从带宽估算开始。如果实测速度连理论值的 20% 都不到那基本可以排除硬件天花板的问题重点查软件配置。这是整个排查过程里性价比最高的一步建议所有人在动工具链之前先把这笔账算明白。3. 量化格式和框架选型同一台手机两个世界算完带宽账之后下一步就是审视手里的模型格式。端侧跑 LLM模型文件不是随随便便从网上下个权重就能用的它需要经过特定的转换和打包流程而这个流程中的量化精度选择直接决定推理速度的量级。3.1 量化格式的影响GGUF 与 MLC 的差异我对比过两种最常见的技术路线。一种是以 llama.cpp 生态为代表的 GGUF 格式另一种是某厂商主导的 MLC 方案。这两者在手机上的表现天差地别。GGUF 的优点是生态成熟、支持广泛几乎所有端侧推理框架都能加载它。但正因为它的通用性它在特定硬件上的优化深度往往不够。在 CPU 上跑小模型GGUF 表现尚可一旦模型增大或者想调用 NPUGGUF 的适配就开始吃力了。MLC 则是从头编译到特定硬件平台的方案它对 GPU/加速单元的利用更充分。同样的 7B INT4 模型我用 GGUF 加载只能跑到 6 token/s换成 MLC 之后直接跳到 18 token/s。差距接近三倍而手机和模型完全没变。如果你追求的是极限性能优先考虑能够针对目标硬件编译优化的部署方案如果更看重通用性和可移植性GGUF 是稳妥选择但要做好性能折中的心理准备。3.2 量化精度的选择不止看 INT4/INT8很多人觉得量化就是把 FP16 变成 INT8 或 INT4精度降得越低越快。这个直觉大体没错但端侧场景还有一层更关键的考量分组量化的粒度。常见的 INT4 量化有两种实现一种是对整个权重矩阵做一个全局缩放因子简单粗暴但精度损失大另一种是按通道或按组分别计算缩放因子精度保留更好但计算时要做反量化。后者虽然多了一些计算量但因为 decode 阶段是 memory-bound多一点计算反而无所谓带宽省下来了速度照样翻倍。我个人的建议是优先选group size 32 或 64 的 INT4 量化不要用全局量化。实测下来在 7B 模型上这两种方案的困惑度差异不大但推理速度差出 20% 以上。还有一个分组细节某些框架支持混合量化也就是 attention 部分保留更高精度MLP 部分压到 INT4。我在尝试了一种混合方案后首 token 延迟和生成质量都得到了不错的平衡。这个方向值得折腾但前提是你已经能熟练跑通基础 INT4 流程。4. 异构计算单元NPU 没生效等于白买旗舰机如果量化格式已经优化到位速度还是不理想那问题大概率出在“算力单元没用对”上。手机端侧跑 LLM理想状态下应该尽量把计算任务卸载到 GPU 或 NPU让 CPU 只做调度和预处理。但实际情况是很多框架默认跑在 CPU 上压根没去碰那些加速单元。4.1 怎么看算子到底跑在哪排查方法很直接打开系统性能监测工具观察 CPU、GPU、NPU 的占用率。如果发现 CPU 多核满载而 GPU/NPU 占用几乎为零那就是典型的主计算路径没有走异构加速。另一个隐蔽的情况是部分算子回退到 CPU。整个模型大部分层在 NPU 上跑但某个激活函数或者归一化层在 NPU 上没有对应实现框架只能把这一个算子挪回 CPU。这一挪往往伴随频繁的数据拷贝性能损耗比想象中大得多。我遇到过一次NPU 已经发挥了 80% 的算力但整体速度依然比全 CPU 还慢就是因为来回拷贝把带宽全耗光了。4.2 算子回退的排查与解决思路定位算子回退靠的是带 graph 信息的 profiling 工具。以我常用的一个性能分析工具为例它能导出每一层算子的执行设备和耗时。我照着输出排查发现某归一化层被标注为 CPU 执行单层耗时 8ms 左右看起来不多但模型有几十层而且每次都要做设备间数据拷贝累积起来就是灾难。解决办法一般有两条路。一是换一个对该算子有 NPU 实现的框架版本或后端二是手动重写模型结构把不支持 NPU 的算子替换为等价的组合操作。第二种方案技术要求高但效果直接。再补充一个不少人都忽视的点内存布局。异构计算要求张量在内存里按特定顺序排布如果框架没有做 layout 转换加速单元就只能干瞪眼。我见过一个案例同样的模型在开启某个内存布局优化开关后速度直接翻倍。这种开关在不同框架里名字不同但一般都会在文档里标注为“XX layout optimization”之类值得每一个做端侧推理的人都仔细翻一遍。5. 上下文长度与 KV Cache罪魁祸首常常是长对话很多人在排查性能时只盯着量化格式和推理框架忽略了对话长度的影响。实际上当上下文从几十个 token 涨到几千个 token 时推理耗时不是线性增长而是近似平方级增长。为什么因为这涉及 KV Cache 的读写和注意力计算的复杂度。5.1 KV Cache 到底占了多少资源先说一个容易误解的点。模型权重是静态的加载后大小不变但 KV Cache 是动态的随上下文长度增长。7B 模型的权重 INT4 量化后也就 4GB 左右但 KV Cache 如果按 FP16 存上下文到 4096 时可能占掉 1GB 以上。内存占用增加还不是最要命的关键在访问模式——每次生成一个 token都要把整个 KV Cache 读一遍来做 attention 计算这直接挤占内存带宽。从带宽估算的角度来看上下文越长KV Cache 读写的开销占比就越高甚至可能超过权重读取的开销。这就能解释一个现象短对话时速度正常长了之后逐渐变慢像是什么东西在累计消耗。我在某个 8B 模型上实测上下文从 512 涨到 4096decode 速度掉了将近一半。5.2 缓存策略的调整方向知道原因之后解决思路就很清晰压缩 KV Cache。常见的做法有几种使用量化 KV Cache把缓存从 FP16 压到 INT8 甚至 INT4内存占用和带宽占用同步下降。启用窗口注意力只保留最近 N 个 token 的 KV更早的丢弃。对某些任务影响不大但能显著压住内存。滑动窗口与摘要结合把历史内容做摘要塞进上下文清掉旧的缓存兼顾长对话和性能。我实测过启用 INT8 量化 KV Cache 之后长上下文的 decode 速度回升了近 30%而且生成质量几乎无损。如果你的框架不支持这些选项也可以考虑调整底层缓存分配策略但这就属于进阶工程了。6. 数据搬运优化性能杀手藏在内存拷贝里前面说的带宽、量化、算子都是显性问题。排查到后期我逐渐把目光移向一个更容易被忽略的地方——数据搬运。端侧推理有一个特点CPU、GPU、NPU 各有各的内存空间张量在它们之间流转时免不了内存拷贝。如果框架没有做好内存池复用和零拷贝优化花的全是在别人看不见的地方。6.1 重复分配导致减速的隐形开销我调试过一个场景推理循环里每个 token 都要重新分配一段临时缓冲区。单次分配只要几微秒听起来可以忽略但乘以生成几百个 token 的过程再加上内存碎片整理整体时间就上去了。排查这种问题的最佳手段是看内存分配器的统计。如果发现分配次数远大于理论需求基本可以确定存在重复分配。解决方式也简单在加载模型时预分配好最大可能需要的缓冲区推理循环里只复用不重开。我做了一次这样的调整整体 decode 速度提升了约 12%改动量却只有十几行。6.2 算子融合减少中间张量的读写另一个优化方向是算子融合。所谓算子融合就是把多个连续的小算子合并成一个复合算子让中间结果留在寄存器或片上缓存里不用每次都写回主内存再读出来。举个常见的例子自注意力里的 QKV 投影如果分别做三个矩阵乘法每次都要把中间结果写回内存如果合成一个大的矩阵乘法一次搞定省掉两次搬运。这在内存带宽受限的设备上省出的时间相当可观。有些推理框架已经内置了自动融合能力但也有些需要手动指定融合开关。我的经验是拿到一个新框架先看它的融合策略文档再决定模型结构上要不要做针对性的重写。7. 系统调度与功耗限制手机不是服务器跑久了会“累”前面所有优化都做完之后还有一类问题容易让人抓狂短时间内速度正常跑几分钟后突然下降一大截。这类问题根源往往不在推理框架而在手机系统的调度策略和散热机制。7.1 CPU/GPU 降频与功耗墙手机芯片的算力峰值只能维持很短暂的时间一旦温度上来或者功耗超过阈值系统就会主动降频。跑大模型恰好是那种让芯片长时间处于高负载的场景所以降频几乎是必然的。排查方式持续跑一个固定长度的生成任务实时记录每一秒的生成速度和芯片温度。如果速度变化曲线和温度曲线高度相关那就说明撞上了功耗墙。策略上也分几种。最直接的是给手机加散热背夹或者把手机放在金属表面物理降温虽然朴素但确实有效。软件层面可以从框架端调低推理频率让芯片不用总是冲在最高频以换取更平稳的长期速度。这两句话听着矛盾其实不冲突与其几分钟高频后被强制降频不如全程以一个中等但稳定的频率跑长期看总吞吐反而更高。7.2 线程数与内存带宽争抢还有一个容易被忽略的调度问题线程数不是越多越好。解码阶段是 memory-bound多开线程并不能提升内存带宽上限反而会因为线程上下文切换和缓存争抢拖慢整体速度。我见过有人把端侧推理线程调到八个结果速度反而比四个线程慢了一截。合适的线程数通常等于性能核数量而不是总核心数。建议做一次线程数扫描从 1 到 8 逐个测试画一条曲线选定平台上的最优值。不同处理器的合适线程数可能不同但做一次测试就能确定以后不再踩坑。8. 实测结论与排查顺序复盘最后把整条排查路线做一个系统性复盘方便别人遇到类似问题时直接按图索骥。先总结我这台手机从“慢80倍”到正常速度的关键变化调整项调整前调整后速度变化量化格式FP16INT4 分组量化从 1.8 提升到 8 token/s推理框架GGUF硬件编译优化方案从 8 提升到 18 token/sKV CacheFP16INT8 量化长上下文提升约 30%算子融合未开启手动开启额外提升约 10%线程数84稳定性和平均速度小幅提升整个排查过程有一个清晰的顺序我建议严格按这个顺序来不要一上来就折腾框架和算子估算带宽理论极限确认硬件天花板判断是不是在瞎忙。检查量化格式优先用 INT4 分组量化确认模型权重不是拖累。对比推理框架跑同一个模型换两三种方案看数据不要迷信单一框架。确认加速单元是否生效观察 CPU/GPU/NPU 占用排查算子回退。调整 KV Cache 策略长对话场景下量化缓存收益明显。优化数据搬运和缓存复用检查临时内存分配开关算子融合。监控系统调度跑长任务记录温度与速度曲线找到功耗墙。9. 排查之外几条值得长期坚持的习惯性能问题排查完再分享几条我沉淀下来的工作习惯对以后做端侧模型部署帮助很大。第一每次改动只动一个变量。单位时间里只改量化格式、或只改线程数、或只改 KV Cache 策略然后记录完整数据。一次改三处速度变化了也不知道是谁的功劳、谁的锅。第二建立一个本地的模型测试集。不用太大覆盖几个常见任务就行短问答、代码生成、长文总结。每次调整后都跑一遍观察的不只是速度还有输出质量。我见过有人只顾优化速度最后模型生成的文本质量已经明显下滑却因为没有测试集而浑然不觉。第三保留所有配置的记录。每种模型、每种框架、每台设备都记下当时的完整参数组合和实测数据。这种记录多了以后新项目可以直接翻阅历史数据不用从头开始排查。我的文档里存了几十行这样的记录每次接手新手机先查同芯片的记录能省掉大量重复工作。做端侧推理很多时候不是某个单一配置决定成败而是一系列细节的叠加。80倍的差距看起来夸张拆解到每一步不过是量化格式差3倍、框架差2倍、缓存差30%、算子融合差10%再算上调度和线程的损耗累积起来就是夸张的数字。把这套排查思路跑通一次以后再遇到类似的性能问题你也会像我一样先拿出纸笔算一笔带宽账而不是干瞪眼怀疑手机坏了。