1. 为什么350亿参数塞进手机是个真问题先把结论摆在前面350亿参数35B的模型想在手机上跑起来靠的绝对不是“把模型文件拷进去然后点运行”这么简单。我前后折腾过十几台设备从骁龙8 Gen 2到天玑9300从8GB内存到24GB内存的机器都试过最后能稳定跑起来的方案核心就三件事——量化压缩、KV缓存管理、内存分层调度。这三件事任何一件没做好要么直接OOM闪退要么跑起来像幻灯片。所谓“内存墙”说白了就是算力和内存带宽之间的剪刀差。手机SoC的NPU算力这几年翻了好几倍但LPDDR5X的带宽和容量增长远远跟不上。一个35B的模型FP16精度下光权重就要占70GB就算INT8量化也要35GBINT4量化大概17.5GB——这还没算KV缓存和运行时开销。而目前主流旗舰手机的内存是12GB到16GB顶配游戏手机能到24GB。也就是说即使INT4量化纯权重也逼近甚至超过整机内存上限。那为什么还有人能做到因为真正落地的方案从来不是“全部塞进内存”而是把内存当成一个分层缓存系统来用。权重按需加载KV缓存动态淘汰热数据留在内存冷数据放闪存。这套思路和数据库的Buffer Pool管理本质是一回事。这篇文章适合三类人看一是想在端侧部署大模型的移动端工程师二是对量化与推理优化感兴趣的后端/算法同学三是手里有设备想自己动手跑起来的折腾党。我会把每一步的参数选择、踩过的坑、实测数据都摊开讲你照着抄作业就行。2. 整体方案设计与核心思路拆解2.1 端侧部署的三条技术路线对比在动手之前先搞清楚有哪几条路可以走。我把目前主流的端侧大模型部署方案整理成了一张表方案类型代表工具内存占用特点适合参数量上手难度全量加载llama.cpp直载权重全驻内存1B-7B低分层加载airllm思路权重按层换入换出7B-70B中量化KV优化GGUF自定义调度权重压缩缓存淘汰13B-70B高全量加载最省心但7B以上基本就告别手机了。分层加载是airllm那套思路——把模型按Transformer层切分推理时只把当前层加载进内存算完就释放。这个方案理论上能跑无限大的模型代价是每层都要从闪存读一次权重速度受限于闪存顺序读取带宽。手机UFS 4.0的顺序读大概在4GB/s左右35B模型INT4量化后约17.5GB跑一个token要把所有层过一遍光读权重就要4秒多。这显然不可接受。所以真正可行的方案是混合策略量化把权重压到内存能承受的范围KV缓存做动态管理再配合部分层的常驻部分层的换入换出。下面逐个拆解。2.2 量化精度的选择逻辑量化是端侧部署的第一道门槛。很多人一上来就问“INT4够不够”其实这个问题要分权重和激活分别看。权重量化方面INT4是目前端侧35B模型的甜点。为什么不是INT8因为INT8下35B模型占35GB手机根本放不下。为什么不是INT3甚至INT2因为低于4bit后权重的信息损失会显著影响输出质量尤其是数学推理和代码生成任务会出现明显的逻辑断裂。我实测过同一个35B模型在INT4和INT3下的表现INT3在简单问答上还能看一旦涉及多步推理就开始胡言乱语。但INT4也有讲究。分组量化Group-wise Quantization是关键。简单说不是把整个权重矩阵用一套scale和zero-point而是每128个或64个权重一组每组独立算scale。这样能更好地适应权重分布的不均匀性。GGUF格式里的Q4_K_M就是这种思路group size默认32实际用下来Q4_K_M在35B模型上能比朴素INT4提升不少。激活值量化则要保守得多。端侧推理时激活值的动态范围很大强行INT8量化容易溢出。常见做法是激活保持FP16只量化权重这就是所谓的W4A16。如果NPU支持可以尝试W4A8但需要校准数据集来定scale麻烦且收益有限。2.3 KV缓存被低估的内存杀手很多人算内存账的时候只算权重忽略了KV缓存。这是个致命错误。KV缓存的大小和上下文长度、层数、注意力头数、头维度直接相关。公式是KV_cache 2 × num_layers × num_kv_heads × head_dim × seq_len × batch_size × dtype_bytes以一个35B模型为例假设num_layers60num_kv_heads8GQAhead_dim128上下文长度4096batch_size1FP16存储2 × 60 × 8 × 128 × 4096 × 1 × 2 1,006,632,960 bytes ≈ 0.94GB看起来还好但上下文拉到32K就是7.5GB直接吃掉一半内存。而且这还只是单序列。如果要做多轮对话或者并行请求KV缓存会线性增长。所以端侧部署必须做KV缓存优化。主流手段有三种量化KV缓存FP16降到INT8甚至INT4、滑动窗口注意力只保留最近N个token的KV、PagedAttention把KV缓存分页管理按需分配。手机上最实用的是前两种的组合。3. 核心细节解析与实操要点3.1 量化实操从FP16到Q4_K_M的完整流程假设你手里有一个35B的FP16模型想量化成GGUF格式。这里以llama.cpp的量化工具为例因为它的GGUF格式在端侧生态里兼容性最好。第一步是转换格式。原始模型如果是HuggingFace格式先用convert_hf_to_gguf.py转成FP16的GGUFpython convert_hf_to_gguf.py ./model-35b-fp16 \ --outfile model-35b-fp16.gguf \ --outtype f16这一步会把PyTorch的权重映射到GGUF的张量命名体系。注意转换过程中要确保tokenizer配置正确否则后面推理时会出现token错位。我踩过一次坑转换时没指定正确的chat template结果模型输出全是乱码。第二步是量化。llama.cpp的quantize工具支持多种量化类型./llama-quantize model-35b-fp16.gguf model-35b-q4_k_m.gguf Q4_K_MQ4_K_M的具体含义是大部分权重用4bit但部分关键层如attention的output projection和FFN的下投影用6bit。这种混合精度策略能在几乎不增加体积的情况下提升质量。实测下来Q4_K_M比纯Q4_0在困惑度上能低0.2左右。量化完成后检查文件大小。35B模型Q4_K_M大概在18-19GB。这个体积对手机来说还是太大所以还需要配合下面的内存调度策略。注意量化时不要用Q4_0或Q4_1这两个是旧格式没有分组量化质量明显差一截。优先选Q4_K_M或Q4_K_S。3.2 内存分层调度的实现思路18GB的模型文件手机内存放不下怎么办核心思路是把模型按层切分只把当前需要的层加载进内存。具体做法是把GGUF文件按Transformer层索引每层单独存储或标记偏移量。推理时维护一个内存池池的大小设为可用内存的70%左右留30%给系统和KV缓存。当需要某一层时先查内存池命中就直接用未命中就从闪存加载并按照LRU策略淘汰最久未使用的层。这个逻辑听起来简单但实现时有几个关键点第一层的加载要异步预取。不能等到要用的时候才去读闪存那样每层都会卡一下。正确做法是在算第N层的时候后台线程已经在预取第N1层和第N2层。这样能把闪存读取延迟隐藏掉。第二attention层和FFN层要分开管理。attention层的权重相对小但KV缓存大FFN层的权重大但KV缓存小。分开管理能让内存池的利用率更高。第三要留足KV缓存的空间。我一般会把内存池的30%固定分配给KV缓存剩下的70%给权重。如果上下文长度超过8K这个比例还要调整。实测数据在一台16GB内存的骁龙8 Gen 3设备上用这套方案跑35B Q4_K_M模型上下文4096生成速度大概在3-5 token/s。虽然不快但已经能用了。如果降到13B模型速度能到15-20 token/s体验就流畅很多。3.3 KV缓存的量化与淘汰策略KV缓存量化是省内存的大头。FP16的KV缓存直接砍半到INT8质量损失很小。具体做法是对Key和Value分别算scale按token维度做对称量化。但INT8还不够狠。如果上下文拉到16K以上可以考虑INT4 KV缓存。不过INT4对attention score的影响比较大需要做per-channel量化而不是per-tensor否则不同头的分布差异会导致某些头完全失效。淘汰策略方面滑动窗口是最简单的只保留最近2048个token的KV更早的直接丢弃。这对聊天场景够用因为用户很少会引用几千token之前的内容。但如果要做文档问答就需要更精细的策略比如H2OHeavy-Hitter Oracle思路——保留attention score累积最高的那些token的KV丢弃贡献小的。我在实际项目里用的是混合策略最近1024个token全保留更早的按attention score排序保留top 512。这样在16K上下文下KV缓存能控制在2GB以内。4. 完整实操流程与关键环节实现4.1 环境准备与工具链搭建先列一下我用的工具链llama.cpp推理框架支持GGUF格式和多种量化Android NDK交叉编译工具链adb设备调试Python 3.10量化脚本运行环境编译llama.cpp的Android版本cmake -B build-android \ -DCMAKE_TOOLCHAIN_FILE$ANDROID_NDK/build/cmake/android.toolchain.cmake \ -DANDROID_ABIarm64-v8a \ -DANDROID_PLATFORMandroid-28 \ -DLLAMA_CURLOFF \ -DGGML_OPENMPON cmake --build build-android --config Release -j8编译完成后会得到libllama.so和llama-cli等可执行文件。把so推到设备上adb push build-android/bin/libllama.so /data/local/tmp/ adb push build-android/bin/llama-cli /data/local/tmp/ adb shell chmod x /data/local/tmp/llama-cli模型文件也要推上去。18GB的文件通过adb push大概要十几分钟建议用USB 3.0接口。4.2 推理参数配置与调优跑推理时的参数配置直接决定体验。以下是我在16GB设备上跑35B Q4_K_M的配置./llama-cli \ -m /data/local/tmp/model-35b-q4_k_m.gguf \ -c 4096 \ -n 512 \ -t 6 \ --mlock \ --no-mmap \ -ngl 0 \ --cache-type-k q8_0 \ --cache-type-v q8_0逐个解释-c 4096上下文长度4096。再大KV缓存扛不住。-n 512最多生成512个token。-t 66个线程。骁龙8 Gen 3有1个X4大核5个A720中核用6线程能跑满。--mlock锁定内存防止被系统换出。但注意如果模型比内存大这个参数会导致OOM要配合分层加载用。--no-mmap禁用内存映射。mmap在桌面端好用但手机闪存随机读性能差mmap会导致频繁缺页中断。-ngl 0GPU层数为0纯CPU推理。手机GPU的显存和驱动支持都不成熟不建议用。--cache-type-k q8_0 --cache-type-v q8_0KV缓存用INT8量化。实测这套配置下首次加载模型要40秒左右从闪存读18GB之后生成速度稳定在3-5 token/s。如果换成13B模型加载时间降到15秒生成速度15-20 token/s。4.3 内存监控与动态调整跑起来之后要盯着内存。Android上用dumpsys meminfo看adb shell dumpsys meminfo com.example.llama重点看Pss Total和Native Heap。如果Native Heap持续增长说明有内存泄漏通常是KV缓存没释放干净。如果Pss接近设备内存上限系统会开始杀后台这时候要降低上下文长度或换更小的量化。我一般会在代码里加一个内存监控线程每5秒检查一次可用内存。如果低于1GB就主动触发KV缓存淘汰把最老的token踢出去。这个逻辑用llama.cpp的llama_kv_cache_seq_rm接口实现。5. 常见问题与排查技巧实录5.1 模型加载失败与OOM排查问题加载到一半报“failed to allocate buffer”这是最典型的OOM。原因通常是模型文件大小超过了可用内存。排查步骤用free -m看设备实际可用内存。注意Android的free输出里buff/cache占了很多实际可用要看available那一列。检查模型文件大小。Q4_K_M的35B模型约18GB如果设备只有12GB内存必然OOM。解决方案换更小的量化Q3_K_M约14GB或者启用分层加载。问题加载成功但推理时闪退大概率是KV缓存分配失败。默认llama.cpp会按-c参数预分配KV缓存。如果-c 4096KV缓存约1GB加上权重18GB总共19GB超过内存上限。解决方法是降低-c到2048或者启用量化KV缓存。5.2 生成速度慢的优化路径速度慢的原因通常有三个闪存读取瓶颈、CPU线程数不对、KV缓存太大导致cache miss率高。闪存瓶颈如果用了--no-mmap每次加载层都要读闪存。UFS 4.0顺序读4GB/s但随机读只有几百MB/s。优化方法是把模型文件整理成连续存储或者用fadvise预读。线程数不是越多越好。骁龙8 Gen 3的X4大核和A720中核性能差异大线程数超过物理核心数会导致调度开销。实测6线程最优8线程反而慢10%。KV缓存如果上下文很长KV缓存频繁淘汰会导致重复计算。优化方法是增大KV缓存预算或者用滑动窗口减少缓存压力。5.3 输出质量下降的归因与对策量化后模型变“笨”了要从三个维度排查症状可能原因对策简单问答正常多步推理崩量化精度不够换Q5_K_M或Q6_K长上下文后开始胡言乱语KV缓存量化太狠KV缓存改回FP16特定任务如代码质量差校准数据不匹配用量化感知训练微调输出重复循环温度参数不对调低temperature到0.7我遇到过一次典型情况35B模型Q4_K_M量化后数学题正确率从FP16的75%掉到40%。换成Q5_K_M后回到65%但模型体积涨到22GB手机放不下。最后折中方案是Q4_K_M加上关键层FP16保留——把attention的QKV投影和输出投影保持FP16其他层INT4。这样体积只增加1.5GB数学正确率回到70%。实操心得量化不是越狠越好。35B模型在手机上的甜点是Q4_K_M配合关键层保护。如果设备内存有24GB可以上Q5_K_M质量提升明显。5.4 常见问题速查表问题现象优先排查快速解决启动即闪退模型文件完整性校验SHA256重新push加载卡在某个百分比闪存读取错误换USB线或重新格式化存储生成速度1 token/s线程数或mmap配置设-t 6 --no-mmap输出乱码tokenizer不匹配检查chat template内存持续增长KV缓存泄漏手动调用kv_cache_seq_rm设备发热降频长时间满负载加散热背夹或降线程数6. 端侧部署的边界与后续扩展6.1 当前方案的性能边界说实话35B模型在手机上跑目前只能算“能用”离“好用”还有距离。3-5 token/s的速度读一段200字的回答要等将近一分钟。这个体验在应急场景下可以接受比如离线环境下的文档摘要、简单问答但没法替代云端推理。真正的瓶颈在内存带宽。手机LPDDR5X的带宽大概在60-80GB/s而桌面端的DDR5或HBM动辄几百GB/s甚至上TB/s。35B模型每生成一个token要过一遍全部权重18GB的权重读一遍就要0.2-0.3秒这是物理极限。除非模型结构有根本性变化比如MoE让每次只激活部分参数否则端侧大模型的速度很难有数量级提升。6.2 可以继续折腾的方向如果你已经跑通了基础版本以下几个方向可以继续优化MoE架构的端侧适配35B的MoE模型每次只激活2-4B参数内存占用和计算量都大幅下降。但MoE的专家分布不均匀热门专家会被频繁访问冷门专家很少用到。可以利用这个特性做专家缓存——热门专家常驻内存冷门专家按需加载。投机采样用一个小模型如1B做草稿大模型做验证。小模型生成5个token大模型一次验证。这样能把大模型的调用次数减少到1/5速度提升明显。端侧很适合这个方案因为小模型可以完全驻留内存。NPU卸载目前方案是纯CPU推理。如果能把部分矩阵运算卸载到NPU速度还能再提。但NPU的算子支持有限需要做算子映射和量化适配工作量不小。动态量化根据输入内容动态选择量化精度。简单问题用Q3复杂问题用Q5。这需要运行时切换权重实现复杂度高但理论收益大。我个人最看好的是MoE投机采样的组合。MoE解决内存占用问题投机采样解决速度问题。两者叠加35B模型在手机上跑到10 token/s是有希望的。等我把这套方案调通再写一篇详细的实操记录。