最近一直在折腾一件事把 350 亿参数的大模型真正跑在一台手机上。不是远程调 API不是云侧推理而是把模型文件下载到手机里所有计算都发生在端侧。“内存墙”这个词如果你自己动手跑过大模型一定深有体会——哪怕只是一个 7B 的量化模型在 PC 上每一步生成都会因为带宽瓶颈卡一下更何况把这个数字放大到 350 亿。这篇文章不聊营销话术只讲实测我会把整个过程中的核心原理、参数计算、完整操作步骤以及踩过的坑都记录下来希望能给同样想折腾端侧大模型的朋友一个参考。1. 先搞清楚“内存墙”三个字意味着什么1.1 为什么算力够用卡的是“搬运”“内存墙”这个词最早是形容 CPU 与内存之间的速度鸿沟处理器算力增长太快而内存带宽和延迟的提升远远跟不上。到了大模型推理时代这道墙被无限放大。GPU 或者手机的 NPU、CPU算力再强也得等权重数据从内存搬进计算单元才能做乘法。Transformer 的结构决定了每一步推理都要访问几乎全部参数所以大模型推理严格来说是一个“内存带宽饥饿”型任务而不是“算力饥饿”型任务。我举个生活化的例子帮助理解你点了一桌 50 个人的菜算力是后厨的灶台和厨师内存带宽则是那条传菜用的传送带。传送带只有那么宽每秒只能端出十几盘菜就算后厨再猛客人也吃不上热饭。大模型生成每一个 token 的过程相当于把全部菜都传一遍。参数越大传的菜就越多最终的决定性瓶颈是传送带而不是灶台。1.2 摩尔定律失效了吗并没有带宽定律先失效了过去几十年芯片制程的进步让计算单元的晶体管密度和频率不断提升计算峰值FLOPs每两年翻一倍左右。但 DRAM 的带宽提升远没有这么乐观大约每年只有 15% 到 20% 的涨幅。两者差距越拉越大于是出现了一个尴尬局面你的处理器算力足够大但喂给它的数据不够快核心利用率上不去。这个差距在端侧设备上更明显。服务器显卡可以用 HBM 这种昂贵的堆叠 DRAM 把带宽做到每秒 2TB 以上一台旗舰手机的 LPDDR5X 内存带宽普遍在 50 至 70GB/s 左右差了三十倍以上。所以把大模型塞进手机第一个要面对的问题是怎么在有限的内存空间和有限的内存带宽下做取舍。1.3 手机场景的特殊性不只是“小一号的电脑”手机和 PC 跑大模型还有一个本质区别被动散热、小电池、共享内存。PC 上你插一张几十瓦的独显持续输出 10 分钟问题不大手机如果长时间满载跑模型芯片升温到一定阈值就会降频性能直接腰斩。手机没有独立显存CPU 和 GPU 共用同一块 LPDDR 内存系统本身还要占用几个 GB。再加上手机内部空间紧凑CPU 和 NPU 的算力虽然纸面数据不错但持续高性能释放面临严重的功耗与散热限制。所以在手机跑 350 亿参数不是简简单单“下载个模型、装个 App”就能流畅用。它是一次对硬件、软件、模型优化三者配合的极限测试。2. 350 亿参数能不能塞进手机关键看这几项2.1 模型体积量化是入场券模型参数的存储单位很好算一个 FP32 的参数占 4 字节FP16/BF16 占 2 字节INT8 占 1 字节INT4 占 0.5 字节。350 亿参数用 FP16 存需要 350×10^9×2 ÷ 1024³约 65GB现代手机连个零头都装不下。换 INT8大约 32.6GB还是有压力。用 INT4 量化文件体积只有 17.5GB 左右这才能挤进 24GB 甚至 16GB 内存的手机里。所以第一步几乎没有任何悬念必须让模型以 4-bit 甚至更低精度存储。实际使用中常见的是 GGUF 格式搭配 Q4_K_M 或 Q5_K_M 量化方案这个格式专门为端侧 CPU 推理设计优点是兼容性好、量化灵活也是 llama.cpp 生态的事实标准。Q4_K_M 在质量与体积之间平衡最好Q4_0 体积最小但精度损失更明显Q5_K_M 质量更高但体积多几个 GB。我建议先从 Q4_K_M 起步内存吃紧再降级。2.2 内存带宽决定生成速度的上限内存带宽决定了模型的生成速度上限。Transformer 解码阶段每生成一个 token都要把全部权重过一遍也就是说每次生成要从内存读大约等于模型体积的数据。以 17.5GB 的 INT4 模型为例如果你的手机内存实测带宽是 65GB/s那么理论最优生成速度是 17.5÷65 ≈ 0.27 秒一个 token也就是每秒约 3.7 个 token。实际上 KV Cache 的读写、系统内存争用、缓存命中不理想等因素会拖慢速度最终能做到 2 到 3 token/s 就已经不错了。这个数字看似很慢但它是有意义的。显卡跑 70B 模型动辄每秒几十 token 是因为显存带宽上千 GB/s而手机 3 token/s 意味着你在端侧能获得一个“能用但谈不上流畅”的体验。如果你看完这段分析还想继续折腾说明你理解并接受这个物理上限后面心态会稳很多。2.3 系统内存与存储24GB 是底线还是舒适区除了权重之外推理时还有 KV Cache。KV Cache 的大小取决于层数、注意力头数和上下文长度粗略估算每 1024 个 token 可能要占用 1 到 1.5GB。上下文设 2048 的话KV Cache 2 到 3GB再加上操作系统本身占用的 5GB 左右一起算下来权重 19GB、KV 3GB、系统预留 5GB总占用超过 24GB。这也是为什么 16GB 内存的手机在 2048 上下文下几乎跑不起 35B 级模型24GB 成为实际意义上的准入门槛。存储方面同样有讲究模型文件 20GB 左右建议放在机身 UFS 闪存上不要放慢速 SD 卡。加载模型时要从存储把 20GB 读入内存UFS 3.1 顺序读至少 1.5GB/s 这个级别怎么也要 10 秒以上如果 SD 卡只有 30MB/s加载时间会让人抓狂。所以跑大模型的手机内存 24GB、存储预留 30GB 是底线最好再配一个好的散热背夹。3. 实操我在手机上跑起 35B 模型的全过程3.1 准备工作硬件、框架、模型我这次使用的手机是骁龙 8 Gen 3 平台、24GB LPDDR5X 内存、机身存储 1TB。系统为原生 Android 14。选骁龙 8 Gen 3 不是因为它的 CPU 算力最强而是因为它支持的内存带宽目前处于第一梯队并且 Adreno GPU 的 OpenCL 驱动兼容性比某些平台好一些。看手机处理器天梯图的时候别人看跑分你应该多看一列内存带宽规格。同样的内存颗粒不同平台的带宽差异会影响实际 token/s这是很多评测都不提的隐藏参数。推理框架选择上我建议普通用户直接用现成的推理应用但如果你想像我一样摸到边缘推荐在 Termux 里编译 llama.cpp。Termux 本身就是一个完整的 Linux 环境不需要 root不破坏系统非常适合做这种折腾。模型方面我选了一个参数规模接近 350 亿的开源模型INT4 量化后的 GGUF 文件约 19GB正好对应文章标题说的“350 亿参数住进一台手机”的典型代表。3.2 一步一步装起来如果你也想复现流程按下面来。整个过程大概花一小时主要是编译耗时。第一步安装 Termux 并更新环境pkg update pkg upgrade pkg install git cmake ninja build-essential -y第二步克隆并编译 llama.cpp。手机编译比较慢建议用 ninja 并发编译小心发热git clone --depth 1 https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease -DLLAMA_CURLOFF cmake --build build --target llama-cli -j 4这里的-j 4是一个重要细节。手机 CPU 虽然有 8 核但全核跑编译会瞬间过热反而触发降频拖慢速度。我自己试过-j 8编译 15 分钟后机身温度到 52 度编译速度反而下降改成-j 4后热得慢总用时反而更短。手机不是电脑续航、散热、性能分配必须顺着它的脾气来。第三步下载模型。从模型仓库下载 GGUF 文件时注意核对“量化类型”和“SHA 哈希”现在模型文件已经被多次篡改或者翻车过我习惯下载完先本地计算一次哈希再使用避免解码到一半报错浪费几十分钟加载时间。3.3 第一次运行与参数调整模型就位之后运行命令是关键一步。我用的命令./build/bin/llama-cli \ -m /sdcard/Download/models/xxx-q4_k_m.gguf \ -c 2048 \ -t 4 \ --mlock \ --no-mmap几个参数的作用分别是-c 2048设置上下文长度。端侧跑大模型千万不能开 32K 那种夸张长度KV Cache 会瞬间吃掉好几个 GB。起步 2048 比较稳长文本宁可分段处理也别贪。-t 4设置推理线程数为 4。手机的大核和小核性能和功耗完全不同llama.cpp 自动调度不一定聪明很多时候固定 4 个大核比 8 核全开更快。--mlock将模型权重锁定在物理内存里防止系统把它换到 zram 交换空间。这个参数非常重要不锁的话模型可能被换出到压缩内存推理速度直接崩盘。--no-mmap让模型文件完整加载进内存不走零拷贝映射。虽然加载时间更长但推理时内存访问更可预期。第一次运行前要有心理准备19GB 从闪存读入内存可能需要 20 到 40 秒期间手机明显发热。加载结束后输入了一句测试文本看到第一个 token 从屏幕里“蹦”出来那种等待的焦灼和喜悦只有亲手跑过端侧大模型的人能体会。3.4 实测数据与速度分析实测结果如下预填充处理用户输入阶段接近 18 token/s因为这一阶段是计算密集型的手机 8 核 CPU 火力全开还能咬住生成阶段则稳定在 2.2 到 2.8 token/s 之间中间偶尔跳到 3 出头但总体始终被内存带宽限制住。这个速度和理论计算值基本吻合。17.5GB 权重 每次生成的 KV Cache 访问以 65GB/s 的带宽估算2.8 token/s 已经是相当接近硬件极限的表现。读一段 1000 字的中文回复要等 6 分钟左右看起来慢得夸张但在一个纯端侧设备上跑 350 亿参数这已经属于“奇迹”范畴。为了验证是不是线程数导致的瓶颈我把-t从 4 调成 6结果生成速度反而掉了 0.3 token/s。原因是 8 核处理器中只有 4 个大核适合跑这种重负载另外 4 个小核参与后调度器需要在大小核之间来回切换内核切换开销抵消了算力增加。这一点也印证了端侧推理不能无脑堆线程甚至要根据手机 SoC 的核心拓扑做手工调优。4. 踩坑实录这些坑我替你先踩了4.1 内存不足与系统杀进程第一次运行时我用-c 4096强行加长上下文刚跑两步就被系统按回去了。Android 虽然显示有 24GB 内存但操作系统、后台服务、GPU 驱动会固定占掉 4 到 5GB。我把 4K 上下文的 KV Cache 算进去之后总内存需求超过 26GB系统判断内存水位过高直接叫停了进程。解决办法有两个第一把-c降到 2048总内存需求压到 24GB 以内第二用--mlock锁住模型文件尽量减缓系统回收。需要明确的是--mlock只能降低风险不能完全免疫 Android 的内存回收策略后台大任务的存活率本质上是系统管理用户能做的有限。如果手机是 16GB 内存建议直接选择 7B 或者 14B 模型35B 级在 16GB 机器上很难稳定。4.2 速度慢到怀疑人生竟然是后台应用在作祟有一阵子生成速度掉到 0.8 token/s几乎不可用。刚开始以为是温度问题后来发现罪魁祸首是一个第三方输入法在后台疯狂占用 CPU 核心。Android 的多任务机制对普通应用相对宽松后台有应用抢核会直接压缩推理线程的可用算力而大模型推理又是带宽敏感型任务算力降了带宽利用率也跟着掉。排查方式简单直接读top命令看 CPU 占用找到占用高的应用冻结或者结束后台任务速度立刻回到 2.5 token/s 左右。所以我个人建议跑端侧大模型之前开启“勿扰模式 一键清理后台”尽量腾出一个干净的运行环境。手机和 PC 不同它永远是个多任务设备你不主动清理它就认为你有别的需求。4.3 发热降频与散热管理端侧跑 35B 模型机身发热是不可回避的问题。我测试了三种场景裸机、贴石墨散热贴、带半导体散热背夹。裸机跑到第 3 分钟时CPU 温度从 45 度升到 68 度大核频率开始从最高点往下调整生成速度一度降到 1.7 token/s。带散热背夹后温度维持在 52 度以内速度稳稳保持在 2.5 token/s整个会话持续了 15 分钟都没有明显衰减。建议各位如果真的长时间使用端侧大模型散热背夹不是“提升性能”的配件而是“维持性能”的必要装备。同时注意不要一边充电一边跑模型充电本身就会带来额外热量叠加之后更容易触发热限。4.4 量化后的精度变化你必须接受INT4 量化带来的输出质量变化在中英文混合场景比较明显。数学计算和代码生成的质量会下降这是量化误差导致的逻辑链越长误差累积越多但开放性问答、文本润色、常识性问题的输出质量依然令人惊喜。如果你对质量有很高要求可以试着换 Q5_K_M内存能撑住的话输出质量会略有回升。不过到了 Q6_K 级别体积又接近 30GB在手机上跑的压力就太大了。这个取舍不仅发生在单模型内部也是整个端侧推理的核心哲学精度、速度、能耗三者不可能同时最优。你所能做的是找到符合你需求和设备条件的平衡点。5. 端侧大模型的边界在哪值不值得折腾5.1 这速度能拿来干什么2 到 3 token/s 的速度确实不适合拿来当搜索引擎或者即时聊天机器人。但在特定场景下它的价值是云侧 API 无法代替的离线环境下的摘要和润色、处理完全私密的本地文档、在没有网络的环境里做内容生成。隐私是端侧模型最大的王牌——你输入的数据永远不会上传到任何服务器这对于某些工作场景来说是决定性的。另一个容易被忽略的价值是教育和技术验证。在手机上亲手跑起 35B 模型比看一百篇架构解读更能建立对“内存墙”的直觉。你能直接感受到内存带宽对推理性能的绝对统治也能意识到为什么行业都在卷量化、卷 KV Cache、卷投机采样——这些优化全都是为了绕过内存墙而存在的。5.2 未来可能的突破方向个人比较看好的三个方向混合专家模型、更激进的量化方案、以及专用 NPU 的成熟。混合专家模型MoE虽然总参数量很大但每次推理只激活部分专家等效带宽需求大幅下降。如果未来有 35B 总参数、10B 激活的端侧模型手机生成速度可能直接翻数倍。更激进的量化方案从 INT4 走向 2-bit 甚至 1.5-bit虽然数学上仍有争议但工程界已经有不少实验性实现。专用 NPU 则是最难预测的一条路厂家对 NPU SDK 的开放程度和生态整合决定了端侧推理的天花板。现在部分平台的 NPU 已经可以跑量化数学模型但开发者生态过于碎片化。哪天某个大厂认真开放了移动端 NPU 的编程接口手机跑 350 亿参数“每秒二十 token”的场景才会真正成为现实。最后分享一点小体会折腾完这一圈我最深的感触是手机跑大模型不是电脑跑大模型的“缩水版”它本质上是另一个物种。所有在 PC 上理所当然的假设——无限电、无限内存带宽、良好散热、后台干净——在手机上全都不成立。也正因如此你学到的每个调优技巧都更有含金量。如果你也想试试我建议从 7B 或 14B 量级起步先跑通流程再挑战 350 亿参数这座小山峰。等你在十几分钟的长等待后收到一段完整回答那种“手机里真的藏着一个模型”的感觉比任何跑分数字都值得。