ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

端侧大模型实测:从1B到8B,手机部署选型与性能优化指南

2026/9/19 18:42:30 拓冰建站 浏览量
端侧大模型实测:从1B到8B,手机部署选型与性能优化指南 1. 端侧大模型到底是个什么局这两年大模型从云端往手机端迁移的速度比我预想中快了不少。2024年的时候大家还在讨论“手机跑7B模型是不是噱头”到了2025年下半年各家旗舰芯片的NPU算力已经普遍摸到40到80 TOPS这个区间内存也从上代的12GB起步逐渐向16GB甚至24GB靠拢。硬件底子变了软件生态也跟着动——llama.cpp、MLC-LLM、Ollama的移动端适配、各家厂商自己的推理框架都在抢这个赛道。但问题也随之而来手机现在到底能跑什么模型跑起来体验怎么样是能日常用还是只能跑个Demo看看热闹我前后折腾了大概十几台设备从骁龙8 Gen 2到天玑9400从8GB内存的中端机到16GB的旗舰把主流的端侧模型方案基本都过了一遍。这篇内容就是把这几个月的实测结论、踩过的坑、以及一些参数选择的逻辑整理出来给想入局端侧大模型的朋友一个参考。先说结论性的判断当前手机端能“实用”运行的模型参数规模集中在1B到8B之间量化等级以Q4_K_M和Q4_0为主MoE架构是突破内存瓶颈的关键方向NPU的利用率决定了续航和发热表现。超过14B的模型在手机上不是不能跑而是跑起来之后手机会变成一个暖手宝而且响应速度会让你怀念功能机时代。这篇文章适合几类人看一是想在手机上部署本地大模型的折腾党二是做端侧AI应用开发、需要选型的工程师三是对MoE、NPU这些概念感兴趣但还没动手的爱好者。我会从架构选型、模型筛选、实操部署、问题排查几个维度展开尽量把“为什么这么选”讲清楚而不是只给一堆命令让你抄。2. 手机跑大模型的核心约束与架构选型2.1 内存带宽才是真正的天花板很多人一上来就看NPU的TOPS算力觉得算力越高模型跑得越快。这个思路在端侧是错的。手机跑大模型第一约束是内存带宽第二是内存容量第三才是算力。原因很简单大模型推理是典型的memory-bound任务。每生成一个token都需要把模型的权重从内存里读一遍。一个7B模型在Q4量化下大约占3.5到4GB意味着每生成一个token就要搬运约4GB的数据。手机用的LPDDR5X带宽大概在60到80GB/s理论上限就是每秒15到20个token。实际因为各种开销能跑到10到15 tok/s就算不错了。这就解释了一个现象为什么有些手机NPU算力标得很高但跑模型反而不如算力低一些的机型。因为NPU算力再高内存带宽喂不上数据算力单元就在那空转。所以选设备的时候优先看内存带宽和内存容量其次才看NPU算力。2.2 NPU、CPU、GPU到底该用谁端侧推理有三个计算单元可选CPU、GPU、NPU。我实测下来的体感是这样的计算单元优势劣势适用场景CPU兼容性最好任何模型都能跑速度慢功耗高调试、验证、小模型GPU速度快生态成熟功耗高发热明显短时间推理、游戏场景NPU能效比最高续航好算子支持有限适配麻烦长时间运行、日常使用CPU方案最省心llama.cpp直接编译就能跑但速度确实一般。8GB内存的骁龙8 Gen 2跑Qwen2.5-3B Q4大概5到7 tok/s能用但谈不上流畅。GPU方案速度最快用OpenCL或者Vulkan后端同样模型能到15到20 tok/s。但问题是功耗跑十分钟手机就开始烫然后降频速度又掉回来。NPU方案是方向能效比能比GPU好3到5倍。但坑在于算子支持——不是所有模型的所有层都能映射到NPU上遇到不支持的算子就得回退到CPU一来一回反而更慢。目前高通QNN、联发科NeuroPilot、华为达芬奇这几套NPU工具链对Transformer架构的支持已经比较好了但对一些新的注意力变体比如滑动窗口注意力、分组查询注意力的某些实现还在追赶。2.3 MoE架构为什么成了端侧突破口MoE混合专家架构在端侧的价值比在云端还大。云端用MoE主要是为了在同等算力下扩大参数量端侧用MoE则是为了在同等内存占用下提升模型能力。原理不复杂传统稠密模型每次推理都要激活全部参数MoE模型每次只激活一部分专家。比如一个8x7B的MoE模型总参数量56B但每次推理只激活2个专家实际计算量相当于14B。如果做量化内存占用可以压到8GB左右但能力接近14B稠密模型。这对手机意味着什么意味着你可以在16GB内存的旗舰机上跑一个能力接近14B的模型而速度接近7B模型。这就是为什么2025年下半年开始端侧MoE模型突然多了起来——Phi-3.5-MoE、Qwen2.5-MoE的端侧裁剪版、以及一些专门为端侧设计的MoE变体。但MoE在端侧也有代价专家路由的开销。每次推理都要计算路由权重决定激活哪些专家这个计算虽然不大但在端侧这种算力紧张的环境下也会吃掉一部分性能。另外MoE模型的内存占用是“总参数量”决定的不是“激活参数量”决定的所以内存容量依然是硬门槛。3. 当前手机能跑的模型清单与实测数据3.1 1B到3B流畅但能力有限这个区间是当前手机端最稳的档位。1B到3B的模型Q4量化后内存占用在0.6到2GB之间任何8GB以上的手机都能轻松跑起来速度普遍在15到30 tok/s体验接近打字交流。我实测过的几个Qwen2.5-1.5B-Instruct Q4_K_M骁龙8 Gen 2CPU推理约18 tok/sNPU推理约35 tok/s。日常问答、简单翻译、文本摘要够用但复杂推理和长文本理解明显吃力。Llama-3.2-3B-Instruct Q4_0天玑9200GPU推理约22 tok/s。英文能力比同尺寸Qwen好中文一般。Gemma-2-2B-it Q4_K_M骁龙8 Gen 3NPU推理约40 tok/s。谷歌的模型在端侧优化做得不错但中文支持是短板。这个档位的定位很明确轻量级助手。适合做输入法联想、通知摘要、简单问答这类任务。别指望它写代码或者做复杂推理。3.2 7B到8B能力够用但速度是瓶颈7B到8B是端侧的“甜点区”也是争议最大的区间。能力上确实能打Q4量化后内存占用3.5到4.5GB16GB内存的手机跑起来没问题。但速度就参差了从5 tok/s到20 tok/s都有取决于设备和推理框架。实测数据模型设备量化推理框架速度Qwen2.5-7B-Instruct骁龙8 Gen 3 16GBQ4_K_Mllama.cpp CPU8 tok/sQwen2.5-7B-Instruct骁龙8 Gen 3 16GBQ4_K_MQNN NPU18 tok/sLlama-3.1-8B-Instruct天玑9400 16GBQ4_0MLC-LLM GPU14 tok/sMistral-7B-Instruct骁龙8 Gen 2 12GBQ4_K_Mllama.cpp CPU6 tok/s这里有个关键发现NPU加速对7B模型的提升非常明显。同样的Qwen2.5-7BCPU跑8 tok/sNPU能到18 tok/s翻了一倍多。但前提是模型能完整映射到NPU上这需要模型架构和NPU工具链匹配。7B档位的实用场景本地知识库问答、文档摘要、代码补全。速度上如果能在15 tok/s以上体验就比较接近云端小模型了。低于10 tok/s的话等待感会比较明显。3.3 MoE模型端侧的新变量MoE在端侧是2025年才真正开始落地的。我测了几个Phi-3.5-MoE-instruct总参数42B激活参数6.6B。Q4量化后内存占用约22GB16GB手机跑不动需要24GB内存的机型。速度方面激活参数少计算量不大但内存带宽压力大实测约10 tok/s。Qwen2.5-MoE-A2.7B总参数14B激活2.7B。Q4量化后约8GB16GB手机能跑。速度约15 tok/s能力接近7B稠密模型。DeepSeek-V2-Lite总参数16B激活2.4B。Q4量化后约9GB速度约12 tok/s。MoE在端侧的核心价值是用内存换能力。你多花4GB内存换来的是接近翻倍的能力提升。但前提是你的手机有那么多内存。目前来看16GB是MoE端侧部署的起步线24GB才能比较从容。3.4 14B以上能跑但别指望实用14B以上的模型在手机上跑属于“技术验证”范畴。我试过Qwen2.5-14B Q4在24GB的骁龙8 Gen 3上跑速度约4 tok/s而且手机背面温度十分钟内就到45度以上。32B的模型我也试过内存直接爆了靠swap硬撑速度掉到1 tok/s以下完全不可用。所以我的判断是当前手机端实用模型的上限是8B稠密或14B MoE激活参数3B以内。超过这个范围要么内存不够要么速度太慢要么发热失控。4. 实操部署从零跑通一个端侧模型4.1 工具链选择llama.cpp还是MLC-LLM端侧部署目前两条主流路线llama.cpp和MLC-LLM。llama.cpp的优势是模型格式统一GGUF、量化方案成熟、CPU推理稳定。缺点是NPU支持还在早期GPU后端性能一般。适合想快速验证、不想折腾工具链的人。MLC-LLM的优势是编译优化做得好GPU和NPU后端性能强。缺点是模型需要先编译流程复杂而且对模型架构的支持不如llama.cpp广。适合追求极致性能、愿意花时间折腾的人。我的建议是先用llama.cpp跑通确认模型能力符合预期再考虑用MLC-LLM做性能优化。别一上来就搞MLC-LLM编译报错能把你劝退。4.2 模型下载与量化选择模型下载渠道主要是Hugging Face和ModelScope。GGUF格式的模型直接搜“模型名-GGUF”就能找到。量化等级的选择逻辑Q4_K_M最推荐的档位。质量和体积平衡最好7B模型约4GB。Q4_0比Q4_K_M略小质量略低但兼容性最好老设备首选。Q5_K_M质量更好体积大约多15%内存够就上这个。Q8_0几乎无损但体积翻倍手机端不推荐。Q2_K体积最小但质量下降明显只适合内存极度紧张的情况。注意量化等级不是越高越好。Q4_K_M和Q5_K_M在端侧的实际体验差距很小但内存占用差了不少。省下来的内存留给KV Cache更划算。4.3 在Android上跑通llama.cppAndroid上跑llama.cpp最省事的方式是用Termux。步骤不复杂# 安装Termux后更新包管理器 pkg update pkg upgrade # 安装编译工具 pkg install git cmake make clang # 克隆llama.cpp git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 编译CPU版本 cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j$(nproc) # 下载模型以Qwen2.5-1.5B为例 # 从Hugging Face下载GGUF文件到本地 # 运行推理 ./build/bin/llama-cli -m /path/to/model.gguf -p 你好 -n 128编译过程大概需要5到10分钟取决于手机性能。跑起来之后你会看到模型逐字输出。第一次跑建议用1.5B的小模型验证流程跑通了再换大模型。4.4 NPU加速的配置要点NPU加速目前最成熟的是高通的QNN方案。需要用到Qualcomm AI Engine Direct SDK把模型转成QNN格式。流程大致是用ONNX导出模型用QNN转换工具转成QNN模型在应用中调用QNN Runtime这个过程比llama.cpp复杂得多而且不是所有模型都能顺利转换。我试过Qwen2.5-7B转QNN注意力层的某些算子不支持最后回退到CPU速度反而比纯CPU还慢。实操心得NPU加速不是万能药。转换之前先查一下NPU工具链支持的算子列表确认模型架构能完整映射。如果模型里有自定义算子或者新注意力变体大概率会回退。联发科的NeuroPilot和华为的达芬奇也是类似逻辑工具链成熟度比高通稍差一些但基本流程一致。5. 常见问题与排查技巧实录5.1 模型加载失败内存不足还是格式问题最常见的报错是“failed to load model”。原因通常有两个内存不够或者GGUF文件损坏。排查顺序先看文件大小确认下载完整。然后用llama.cpp的--verbose参数看详细日志如果卡在分配内存的阶段就是内存不够。这时候要么换更小的量化等级要么换更小的模型。避坑技巧Android系统对单个应用的内存有限制即使手机有16GB内存Termux也不一定能用到全部。建议在开发者选项里把“每个应用的内存限制”调到最大或者用root权限运行。5.2 推理速度突然变慢热降频还是内存交换跑着跑着速度掉一半大概率是两个原因手机热降频或者内存不够开始用swap。热降频的判断很简单摸一下手机背面烫手就是降频了。解决办法是加散热背夹或者降低并发数。内存交换的判断看free -h如果swap使用量在涨就是内存不够。这时候只能换更小的模型或量化等级。5.3 输出乱码或重复量化损失还是采样参数问题模型输出重复、乱码、答非所问通常是量化损失太大或者采样参数没调好。先检查量化等级Q2_K和Q3_K_S这类低比特量化质量损失确实明显。换成Q4_K_M试试。如果换了还不行调采样参数--temp 0.7 --top-p 0.9 --repeat-penalty 1.1。温度太高会乱说太低会重复。5.4 NPU回退导致速度不升反降NPU加速最坑的情况是部分层跑在NPU上部分层回退到CPU数据在两边来回拷贝速度比纯CPU还慢。判断方法是看推理日志如果有“fallback to CPU”之类的提示就是回退了。解决办法是换一个NPU支持更好的模型或者等工具链更新。别硬扛回退问题不是调参能解决的。5.5 常见问题速查表现象可能原因排查方法解决方向加载失败内存不足/文件损坏看文件大小和verbose日志换小模型/重新下载速度骤降热降频/内存交换摸温度/看swap加散热/换小模型输出乱码量化损失/采样参数换量化等级/调tempQ4_K_M/调采样NPU变慢算子回退看推理日志换模型/等工具链应用闪退内存超限看系统日志调内存限制/root6. 端侧大模型的实用边界与选型建议6.1 什么场景适合端侧什么场景不适合端侧大模型不是要替代云端而是补位。适合端侧的场景有几个特征隐私敏感、网络不稳定、响应延迟要求高、任务相对简单。比如本地文档问答文档不想上传云端端侧模型就能派上用场。再比如输入法联想需要毫秒级响应云端往返延迟受不了端侧模型更合适。还有离线翻译、通知摘要这类任务端侧模型完全能胜任。不适合端侧的场景也很明确复杂推理、长文本生成、多模态理解、需要最新知识的任务。这些场景要么算力不够要么内存不够要么模型能力不够。硬上端侧只会得到糟糕的体验。6.2 设备选型的三个硬指标如果你打算入手一台专门跑端侧大模型的手机看三个指标就够了内存容量16GB起步24GB更好。8GB只能跑3B以下12GB能跑7B但MoE吃力。内存带宽LPDDR5X起步带宽越高越好。这个指标比NPU算力重要得多。NPU工具链成熟度高通QNN目前最成熟联发科次之其他平台还在追赶。工具链成熟度决定了你能不能真正用上NPU。至于CPU和GPU反而不是重点。端侧推理很少靠CPU和GPU扛主力它们更多是兜底和调试用。6.3 模型选型的决策树选模型可以按这个逻辑走先看内存8GB选1.5B到3B12GB选7B Q416GB选7B Q5或MoE-A3B24GB选MoE-A7B。再看任务中文任务优先Qwen系列英文任务Llama和Gemma都可以代码任务选DeepSeek-Coder或Qwen-Coder。最后看速度如果NPU支持好优先NPU推理如果NPU回退严重老老实实CPU推理。个人经验别追求“最大能跑什么模型”追求“最稳能跑什么模型”。一个稳定跑15 tok/s的7B模型比一个勉强跑5 tok/s的14B模型实用得多。6.4 后续可以关注的方向端侧大模型这个领域变化很快几个值得关注的方向MoE的端侧优化专家路由开销能不能进一步降低、NPU算子覆盖新注意力机制能不能快速支持、内存压缩技术KV Cache的量化、稀疏化、模型蒸馏用大模型蒸馏出更适合端侧的小模型。我个人的判断是2026年端侧实用模型的上限会推到14B稠密或30B MoE激活3B以内但前提是内存带宽和容量继续提升。如果内存技术没有突破那端侧模型的能力提升就会遇到瓶颈。最后分享一个我踩过的坑别在主力机上折腾端侧大模型。推理时的发热和耗电会影响日常使用而且调试过程中频繁的编译和加载会拖慢手机。搞一台二手旗舰专门用来折腾体验会好很多。