1. 当350亿参数被塞进手机这件事到底难在哪第一次看到350亿参数跑在手机上这个说法我的反应和大多数人一样——不信。毕竟按照常规认知一个350亿参数的模型光是权重本身FP16精度下就要占掉接近70GB的存储空间。而一台主流旗舰手机的运行内存撑死也就12GB到16GB。这中间的差距不是优化一下能填平的是数量级的鸿沟。但这件事确实在发生。背后的核心矛盾行业里有个很形象的说法叫内存墙Memory Wall。它指的是算力增长的速度远远快于内存带宽和容量的增长速度导致模型跑不动的原因往往不是算不过来而是搬不动数据。对于端侧部署来说内存墙是比算力墙更致命的存在——手机的GPU算力其实不弱但内存带宽和容量是硬约束你没法给手机插一根内存条。所以350亿参数住进手机这个命题本质上要解决的不是一个工程问题而是一连串取舍问题精度换空间、空间换速度、速度换体验。每一步都在做减法但减完之后还得保证模型能用。这个能用的底线在哪里才是整件事最值得聊的部分。这篇文章适合两类人看一类是想搞清楚端侧大模型部署到底怎么回事的技术爱好者另一类是正在做端侧AI硬件部署、需要落地参数的工程师。我会把量化、KV缓存、内存占用计算这些核心环节拆开讲尽量给出可以自己动手验证的数字和方法而不是停留在概念层面。先说结论350亿参数进手机靠的不是某一个黑科技而是量化压缩 分层加载 KV缓存管理 算子优化这一整套组合拳。任何单一手段都做不到必须叠加。下面逐个拆。2. 量化把70GB的模型压到能塞进手机的第一步2.1 量化到底在做什么用生活化的方式说清楚量化的本质是把模型权重从高精度浮点数比如FP16每个数占2字节转换成低精度表示比如INT4每个数占0.5字节。你可以把它理解成把一张无损的RAW格式照片转成高质量JPEG——文件小了很多但肉眼看几乎没差别。关键在于几乎这两个字量化一定是有损的问题在于损失多少、损失在哪里。一个350亿参数的模型不同精度下的理论存储占用是这样的精度每参数字节数350亿参数理论占用手机能否承载FP324字节约140GB完全不可能FP162字节约70GB不可能INT81字节约35GB仍然不可能INT40.5字节约17.5GB接近临界INT2/三元0.25字节约8.75GB理论可行从这张表能看出来INT4是端侧部署的一个关键分水岭。到了INT4模型体积才第一次进入手机内存可能装得下的区间。但17.5GB对于一台16GB内存的手机来说依然超了。所以INT4还不够要么继续往INT2甚至三元量化走要么配合分层加载——也就是不把整个模型同时放进内存而是按需加载。这里有个很多人忽略的点量化不只是压权重激活值activation和KV缓存同样可以量化。权重占大头但KV缓存随着上下文长度增长会迅速膨胀后面会专门讲。2.2 INT4量化里那些看起来能用但实际翻车的坑我踩过最典型的一个坑是per-tensor量化和per-channel量化的选择。早期图省事直接对整个权重矩阵用一个统一的scale和zero-point结果模型输出直接崩了——生成的内容开始重复、逻辑断裂。原因很简单不同通道的权重分布差异极大用一个全局scale去套等于把分布窄的通道精度浪费了分布宽的通道又被截断。正确做法是per-channel量化甚至对某些敏感层用group-wise量化比如每128个权重一组共享一个scale。代价是scale本身也要存会带来额外开销但精度提升非常明显。实测下来group size取128是个比较平衡的选择再小收益递减再大精度掉得快。另一个坑是哪些层不能量化。不是所有层都对量化同样敏感。经验上第一层和最后一层、以及attention里的某些投影层对精度特别敏感强行INT4会明显掉点。常见的做法是这些层保留INT8甚至FP16其余层走INT4。这种混合精度策略能在体积和效果之间找到更好的平衡点。提示做量化时一定要留一个校准集calibration set用真实场景的输入去统计激活值分布。拿随机数据校准出来的scale实际推理时经常出问题。2.3 三元量化把每个参数压到极致三元量化ternary quantization是把权重限制在{-1, 0, 1}三个值上理论上每个参数只需要约1.58 bitlog2(3)。这是把压缩做到极致的思路350亿参数能压到7GB左右终于能舒服地放进手机内存了。但代价也很直接精度损失明显。三元量化对模型本身的结构和训练方式有要求通常需要量化感知训练QAT也就是在训练阶段就模拟量化的效果让模型适应这种极端压缩。直接对训练好的模型做后训练三元量化PTQ效果往往惨不忍睹。所以如果你看到某个模型宣称三元量化后依然能打大概率是做了QAT或者模型本身参数量足够大、冗余足够多扛得住这种压缩。小模型做三元量化基本等于自废武功。3. KV缓存端侧推理里最容易被低估的内存杀手3.1 为什么KV缓存会吃掉你的内存很多人算内存占用时只算模型权重忽略了KV缓存结果一跑长上下文就OOM内存溢出。KV缓存是什么简单说自回归生成时每生成一个新token都需要用到之前所有token的Key和Value。为了避免重复计算这些Key和Value会被缓存下来。上下文越长缓存越大。KV缓存的大小可以用这个公式估算KV缓存大小 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 精度字节数拿一个典型的350亿参数模型举例假设64层、每层64个头、头维度128、序列长度4096、FP16精度2 × 64 × 64 × 128 × 4096 × 2 字节 ≈ 8.6GB光是KV缓存就8.6GB比很多模型权重还大。这就是为什么端侧部署必须对KV缓存动手——KV缓存量化和KV缓存压缩是两个主要方向。3.2 KV缓存量化的实操要点KV缓存量化到INT8内存直接减半到INT4再减半。但KV缓存比权重更敏感因为它是动态生成的误差会随着生成过程累积。我的经验是Key和Value分开处理。Key对精度更敏感Value相对宽容。可以Key用INT8、Value用INT4。只对长上下文场景量化。短上下文时KV缓存本来就不大量化收益有限反而引入误差。配合滑动窗口。不是所有历史token都同等重要用滑动窗口只保留最近N个token的完整精度KV更早的做更激进的压缩。3.3 一个真实的内存预算表把权重和KV缓存放一起算才能看清端侧部署的真实内存账本。假设目标是一台16GB内存的手机系统和其他应用占掉4GB可用12GB项目INT4权重INT4权重INT8 KV三元权重INT4 KV模型权重17.5GB17.5GB7GBKV缓存(4K上下文)8.6GB4.3GB2.15GB合计26.1GB21.8GB9.15GB是否可行否否是这张表说明一个残酷的事实光靠INT4权重根本进不了手机必须权重和KV缓存同时压缩而且权重得压到三元级别。这就是为什么350亿参数进手机这件事本质上是一套组合方案而不是单点突破。4. 分层加载与内存调度不把鸡蛋放在一个篮子里4.1 为什么全量加载在端侧行不通即便压到9GB一台后台跑着微信、相机、各种服务的手机也很难稳定腾出9GB连续内存。而且手机内存管理是动态的你的模型占着大块内存系统随时可能因为内存压力把你杀掉。所以端侧部署普遍采用分层加载layer-wise loading策略不把整个模型一次性读进内存而是按层加载用完就释放。计算第N层时只把第N层的权重读进内存算完立刻释放再加载第N1层。这样做的好处是峰值内存占用大幅降低理论上只需要能装下最大的一层加上KV缓存即可。代价是频繁的IO操作如果权重存在闪存里每次加载都要读盘速度会成为瓶颈。4.2 分层加载的优化技巧纯分层加载太慢实际工程里会做几件事来平衡预取prefetch在计算第N层的同时异步把第N1层的权重读进来用计算时间掩盖IO时间。热点层常驻把频繁访问的层比如embedding层常驻内存不参与换入换出。权重分块把大层再切成小块进一步降低单次加载的峰值内存。这里有个反直觉的经验分层加载不一定比全量加载慢多少前提是IO和计算能重叠好。手机闪存的顺序读取速度其实不差只要预取策略得当计算单元基本不会饿着。4.3 内存映射mmap的妙用另一个常用手段是内存映射文件mmap。把量化后的权重文件直接映射到虚拟内存空间让操作系统按需调页。这样你不需要手动管理加载释放OS会帮你做。访问到哪一页就加载哪一页没访问的不占物理内存。mmap的好处是简单坏处是你无法精确控制内存占用OS的调页策略不一定符合你的预期。实测中mmap配合顺序访问模式效果最好随机访问会导致频繁缺页性能暴跌。所以用mmap时要尽量保证推理过程是顺序扫描权重的。5. 算子优化让量化模型真正跑得快5.1 量化不等于加速这是两回事很多人以为量化了模型就会变快其实不一定。量化主要省的是内存和带宽算力上的加速要看硬件是否支持低精度算子。如果硬件没有INT4的矩阵乘加速单元你量化到INT4运行时还得反量化回FP16再算反而更慢。所以端侧部署前一定要确认目标硬件的指令集支持情况。主流手机SoC的NPU通常对INT8有良好支持INT4支持参差不齐三元量化基本没有硬件原生支持得靠软件模拟。这就是为什么很多端侧方案最终落在INT8而不是更激进的精度上——硬件友好度是硬约束。5.2 算子融合减少内存往返内存墙的核心问题是数据搬运。每做一次算子就要把数据从内存读到计算单元算完再写回去。算子越多搬运次数越多带宽就越吃紧。算子融合operator fusion就是把多个连续的小算子合并成一个大算子中间结果不落内存直接在寄存器或片上缓存里传递。比如把矩阵乘 加偏置 激活函数融合成一个算子能显著减少内存往返。在端侧算子融合的收益比在服务器上更明显因为手机的带宽更宝贵。常见的融合模式包括MatMul Bias Activation 融合LayerNorm 相关算子融合Attention 里的 QKV 投影融合5.3 一个容易忽略的点反量化开销量化模型推理时权重是INT4但计算通常还是要在FP16或FP32下做除非硬件支持INT4计算。这就涉及反量化把INT4权重乘上scale加回zero-point还原成浮点。这个操作本身有开销如果每个权重都单独反量化开销会很大。优化方法是批量反量化一次处理一整块权重摊薄开销。更激进的做法是用查表法预先算好所有可能的反量化结果运行时直接查表避免重复计算。6. 实测中的那些意外与经验6.1 量化后模型变笨的具体表现量化掉点不是均匀的它往往集中在特定能力上。我实测下来量化对以下能力影响最大长链推理多步推理时误差累积容易中途跑偏数值敏感任务涉及精确计算、日期、数字的任务量化后错误率明显上升罕见知识训练数据里出现少的冷门知识量化后更容易丢失而对常识问答、文本分类、简单生成这类任务量化影响相对小。所以评估量化模型时不能只看一个笼统的分数要分任务类型看。6.2 校准集的选择比想象中重要前面提过校准集这里展开说。校准集的作用是统计激活值分布决定量化的scale。如果校准集和实际使用场景分布不一致量化效果会大打折扣。我的做法是校准集从真实业务数据里采样覆盖主要场景且要有一定长度。用太短的样本校准长上下文场景下会出问题。校准集规模一般几百到几千条就够太多收益递减。6.3 温度参数和量化误差的相互作用一个比较隐蔽的坑量化后的模型对采样温度temperature更敏感。低温接近贪心解码时量化误差容易被放大成明显的重复或死循环高温时又容易发散。实测下来量化模型适合用中等温度配合top-p采样比纯贪心或纯随机都稳。6.4 端侧部署的功耗账手机是电池供电的功耗和发热是绕不开的约束。大模型推理是重负载任务持续跑会让手机发烫、降频。所以端侧部署要考虑推理时长控制单次推理别太长避免持续高负载批处理大小端侧通常batch size1别想着批处理提吞吐NPU vs CPU vs GPU优先用NPU能效比最好GPU次之CPU最费电这些约束反过来又影响模型设计——端侧模型不是越小越好而是要在效果、速度、功耗之间找平衡。7. 从能跑到好用还差什么把350亿参数塞进手机技术上跑通只是第一步。真正决定体验的是首token延迟和生成速度这两个指标。首token延迟决定用户等待感生成速度决定阅读流畅度。端侧大模型如果生成速度低于每秒5个token体验就会明显卡顿。提升这两个指标除了前面说的量化和算子优化还有几个方向投机解码speculative decoding用一个小模型快速草拟大模型验证能显著提速前缀缓存系统提示词等固定前缀的KV缓存复用避免重复计算动态精度简单token用低精度算难token用高精度算这些技术叠加起来才能让端侧大模型从演示能跑变成日常能用。我个人在实际操作中的体会是端侧部署最难的从来不是某个单点技术而是在内存、算力、功耗、效果这四个约束下做全局取舍。你压得越狠效果掉得越多你想保效果内存就爆。找到那个平衡点靠的是大量实测而不是纸面计算。每次换一个模型、换一台设备这个平衡点都要重新找。这也是为什么端侧AI硬件部署到现在依然是个手艺活而不是一个能一键套用的标准流程。