1. 内存墙是什么，为什么是这道坎
把350亿参数装进一台手机，这个标题听起来像某种极限装修：要在几十平方米的套内面积里，塞进一套别墅的家具。很多人的第一反应是“算力够不够”，但真正动手做过端侧模型部署的人会告诉你，卡住你的往往不是FLOPS，而是内存。
1.1 算力跟得上，内存先崩了
先算一笔账。一个350亿参数的模型，如果用最常见的FP16（半精度浮点）存储，每个参数占2个字节，光模型权重就是：
350亿 × 2字节 = 70GB
哪怕你用INT8量化，每个参数1个字节，也要35GB。而目前主流旗舰手机的运行内存，基本是12GB到24GB之间，顶配游戏手机偶尔到24GB，但系统、前台应用、后台进程还要吃掉一大半。也就是说，光是模型本体，就能把手机的物理内存撑爆，更别提推理时还要中间激活值、KV Cache、临时缓冲区。
这就引出了“内存墙”的本质：模型体积的增长速度，远远超过了硬件内存容量的增长速度。算力的提升还能靠制程堆叠、NPU并行度来缓解，但内存这条通道，尤其是手机这种封闭式小电量的场景，墙壁是真的厚。服务器端有数百GB的HBM带宽，手机上的LPDDR5X虽然也在进步，但带宽和容量都被功耗墙死死摁住。你就算把算力堆到每秒几十万亿次，内存喂不饱芯片，芯片只能空转。
简单说，内存墙不是“不够快”，而是“装不下”和“喂不快”两层叠加。装不下是容量，喂不快是带宽。部署350亿模型上手机，本质就是同时绕着这两堵墙走。
1.2 手机端的实际“装修面积”：内存容量与带宽
我们看手机的核心配置，除了SOC天梯图上的GPU频率、NPU算力，真正影响大模型体验的还有两个指标：内存容量和内存带宽。
目前旗舰机普遍使用LPDDR5X，频率越高的版本带宽越高。比如LPDDR5X 8533Mbps，配64bit总线，理论带宽约68GB/s。听起来不少，但你要知道，跑一个350亿参数的INT4量化模型，权重依然有17.5GB，即使全部常驻内存，每生成一个token都要把全部权重读一遍。如果是预填充阶段，输入序列越长，计算量越大，但内存带宽依然决定了下限。你拿68GB/s的带宽去读17.5GB权重，理论上一遍就要0.26秒。生成50个token，光读权重就要十几秒，这还没算计算时间。这个数字已经接近无法忍受了。
再加上手机内存是共享的，系统、相机、微信都住在里面。模型常驻后，其他应用的内存可能被挤爆，冷启动、杀后台都是家常便饭。实际部署时，真是要一边算“模型住多大”，一边算“留给系统生活多少空间”，像极了装修时反复测量房间尺寸。
所以，端侧部署350亿模型，本质是一场“内存精装修”：既要压体重，又要提带宽利用率，还得给系统留出呼吸空间。这也是后文所有技术的出发点。
2. 把350亿参数塞进去：三条主路
2.1 量化：把Float的高精度家具压缩成低精度
量化是端侧部署的第一选择，也是目前落地最成熟的手段。核心思路很简单：权重里的数值，不一定都需要16位甚至32位精度。好比一张照片，你不需要每个像素都是真彩色，适当压缩到256色，远处看依然能辨认。
常见做法有几种：
- FP16：半精度，只把体积减半，基本无损，但70GB对350亿来说还是太大。
- INT8：每个参数1字节，体积是FP16的一半，356亿模型约35GB，依然偏大。
- INT4：每个参数只有0.5字节，350亿模型约17.5GB，这是目前手机端能真正放下的量级。
- 混合精度：比如头部层保留FP16，中间层用INT8，注意力层用INT4。因为不同层对精度敏感度不同，结合部作用大，保精度。
INT4量化看起来是救星，但直接无脑量化的后果是：模型变成“口齿不清的复读机”，输出词不达意。因为权重数值范围窄了，极值分布如果集中，量化损失就放大。
实操时要做校准。业界通用的做法是拿一批代表性数据，统计权重和激活值的分布，用MinMax、Percentile、KL散度等方法确定缩放因子。更进阶的是GPTQ、AWQ这类算法，它们会分析哪部分权重重要，量化时对重要部分保留更高精度，并调整激活值权重。实测下来，AWQ在350亿模型上比朴素INT4要稳定得多，困惑度下降明显少。
还有一点必须提醒：量化不是只看权重，还要看激活值。激活值如果不做量化，推理时照样高精度，数据在内存里来回转换，带宽压力没减少。所以真正的端侧部署都是“权重激活一起量化”，也就是W4A4。不过W4A4对工程实现要求高，有些推理引擎支持不好，容易踩坑。
2.2 剪枝与稀疏化：拆掉非承重墙
量化是压缩数值精度，剪枝则是砍掉结构。神经网络里不是每个参数、每个神经元都有用。有些神经元学到的权重接近零，对输出几乎没影响，就像装修时有些隔断墙本身不是承重墙，敲掉也不影响结构安全。
剪枝常见两种：
- 结构化剪枝：整行、整列或者整个注意力头剪掉。好处是推理引擎好优化，因为维度变小了，矩阵乘法可以直接跳过。坏处是精度损失相对大，需要微调恢复。
- 非结构化剪枝：把权重矩阵里绝对值很小的单个参数置为0。稀疏度高，但矩阵运算本来就稠密，跳跃式读取反而可能拖慢速度，除非硬件支持稀疏加速。手机上大多数NPU没有RDMA类似的稀疏加速指令，收益有限。
剪枝通常和量化叠加使用。先剪枝砍掉一部分参数，再量化压缩剩余参数。但要注意，一次砍太多会伤筋动骨，一般稀疏度20%~50%之间需要反复评估。我在尝试把350亿模型剪到50%之后再INT4量化，效果就明显掉线，对话连贯性差了很多。最后还是把剪枝比例降到30%，配合AWQ量化，才保住可用状态。
剪枝对端侧的一个额外好处是能减少显存占用，也能减少内存带宽消耗，因为不读那些零值了。但前提是推理引擎真的跳过零值计算，而不是照读矩阵。很多现成的推理框架对稀疏支持有限，你需要选对后端。
2.3 蒸馏：请一个“说话方式一样”的小模型替代
如果量化、剪枝之后还是太大，那就换思路：不直接压缩大模型，而是训练一个小模型来模仿大模型的行为。这个过程叫知识蒸馏。
具体来说，用350亿模型当老师，生成大量问答对和思维链数据，然后训练一个70亿甚至30亿的“学生”模型。学生模型的参数更少，但学习的是老师的输出分布，不仅仅是答案，还包括回答的风格、推理步骤、错误模式。相当于把老师脑中的知识“蒸馏”到学生脑子里。
蒸馏的难点在于数据质量。不是随便拿一些问答让老师跑一遍就行。老师会犯错的，学生如果照着错误答案学，就把错误放大了。要经过答案过滤、去重、人工抽检，甚至用老师自己打分的方式清洗数据。我的经验是，蒸馏出一个70亿模型，其数据清洗工作量比训练100亿模型的原始数据还要烦琐。但结果是值得的——70亿INT4量化只有3.5GB，手机上随便跑，还能留出充足内存给系统。
不过蒸馏有个陷阱：学生模型永远无法完全超越老师。如果老师本身能力有限，学生学再像也只是“缩小版”。而且蒸馏过程需要一大笔离线训练成本，不是普通个人开发者能轻易做的。实际项目中，很多人是拿来别人蒸馏好的开源小模型，而不是自己从头蒸馏。
所以三条路的组合策略通常是这样：先看手里开源模型本身多大，能用INT4住进目标机型的，就直接量化；住不进去的，先蒸馏或剪枝到70~130亿规模，再量化。这三个操作不是互斥的，我自己的流程是先蒸馏（如果需要），再做AWQ INT4，最后在极小代价下微调恢复精度。
3. 实战：350亿模型在手机上的部署流程
3.1 选型与量化参数计算
项目目标是“350亿模型跑在手机上”，首先得定义“跑得动”的标准。是只让它回答“今天天气怎么样”，还是要能完成复杂推理？不同需求直接决定你能接受的量化后精度、内存占用、推理延迟。
我当时的设想是：在手机上本地运行一个离线对话助手，不需要联网，能回答常识、写邮件、做摘要，偶尔写点代码。目标机型定在16GB内存的骁龙8 Gen 2手机，SOC算力属于当时第一梯队，LPDDR5X带宽约68GB/s。模型权重预算：最多占用8GB内存，剩下8GB留给系统和前台应用。这样才不会一加载模型，微信就被杀了。
于是反推：8GB内存能放什么参数规模的INT4模型？INT4下每个参数0.5字节，8GB对应160亿参数。所以350亿参数模型直接INT4都超预算。得先蒸馏或剪枝到约130亿参数，才能用INT4塞进8GB。另一条路是保留350亿但用3 bit甚至2 bit量化，但那种精度损失巨大，我已经不做这种极端方案了。
最终方案：拿一个130亿参数的开源基座，用AWQ量化到INT4，权重占用约6.5GB，再预留1.5GB用于激活值、KV Cache和推理缓冲区。总内存峰值控制在8GB附近。这个预算计算必须提前做，不然跑到一半内存溢出，App闪退，一切白忙。
AWQ量化的实操步骤，主要包括：
- 准备校准数据集：几百条到几千条有代表性的文本，覆盖代码、对话、常识问答、摘要等。
- 用HuggingFace上的AWQ工具，指定权重位宽、组大小（group size）。group size越小精度越好，比如128比32占用大，但误差小。
- 运行量化，观察每层的量化损失，通常有日志输出。
- 用测试集对比量化前后的PPL（困惑度）和实际表现。
组大小是个重要参数。group size为128时，权重占用会比group size为256时略高，因为每组需要额外的缩放因子，但精度也更好。在130亿模型上，我用group size 128，量化后模型体积在6.6GB左右，可以接受。如果你发现内存紧张，可以换group size 256，体积能再少几百MB，但输出质量略有下降。
3.2 推理引擎与NPU加速
模型量化好只是一个文件，真正跑起来要靠推理引擎。端侧推理引擎比较常用的是llama.cpp、MLC-LLM、MNN、NCNN，还有各手机厂商自研的端侧引擎。选择时主要看两点：是否支持你的量化格式（尤其是AWQ），是否能用上NPU。
llama.cpp是老牌选择，纯CPU推理也能跑，支持ARM平台的NEON指令优化。在骁龙8 Gen 2上，用CPU跑130亿INT4模型，大概每秒生成8~12个token，虽然不快，但能接受。如果启用GPU（Adreno）或者NPU加速，速度能翻倍，但工程复杂度上升。
MLC-LLM的特点是能编译到Vulkan后端，利用GPU通用算力。它的优化比llama.cpp更激进，但遇到不同SOC适配时可能踩坑，比如Adreno驱动有bug、Mali的Vulkan支持不全。我当时在骁龙芯片上跑得很顺，换到天玑芯片就出现计算错误，改回CPU后端才稳定。
NPU加速是另一个话题。手机SOC里的NPU通常针对特定算子做优化，但不是所有的Transformer算子都能跑。很多厂商提供的端侧模型格式，是专门用NPU编译过的。想要自己跑开源模型，通常只能体验“CPU为主、GPU为辅”的方案。NPU这个“装修队”对图纸要求太苛刻，自己改造模型结构时，它根本不接手。
我自己的经验是：第一版先跑llama.cpp的纯CPU后端，把功能跑通，再去调GPU。CPU版本虽然token生成慢，但它稳定、可控、没有内存越界错误。跑通后，再切换到支持GPU的MLC-LLM，收益是生成速度能提升到20~30 token/s，但发热和功耗也上去了。手机如果没插电，连续对话10分钟，机身会明显发热，甚至触发降频。
另外，手机端推理不能只看峰值速度，更要看持续性能。NPU/GPU最容易在10分钟满载后降频，导致后半段速度还不如CPU稳定。如果做的是交互应用，建议设置“性能模式”和“省电模式”，根据用户场景动态切换。
3.3 交互与系统集成细节
模型跑起来以后，真正的工程问题才刚刚开始。手机App不是命令行，你得一帧一帧地调UI、管内存、保后台。
首先是模型加载方式。一个6.5GB的模型文件，从磁盘加载到内存需要时间。你可以选择启动时做完整加载，但会有明显白屏等待；也可以做“懒加载”，等用户第一次输入再加载，但首次交互延迟高。折中方案是：启动时先加载一部分核心层，其他层按需mmap。现在的推理引擎支持内存映射文件，可以让页面先显示出来，模型在后台静默加载。
其次是内存动态申请。推理过程中，KV Cache是逐步增长的，对话长度越长，缓存占用越大。如果不做限制，用户聊了半小时，模型占的内存可能从6.5GB涨到10GB，然后被系统杀掉。因此必须限制最大生成长度和历史上下文轮数，超出部分做裁剪或摘要压缩。我设定最大上下文2048个token，超过后自动遗忘较早的消息。
还有前后台切换。手机系统对App的内存压力很敏感。模型常驻时，你切到微信再切回来，可能模型已经被回收了。解决办法是监听App生命周期，在onStop时保存推理状态，在onResume时重新加载模型。重新加载6.5GB文件大概需要3~5秒，可接受。如果想更快，可以用Android的绑定服务方式保持一个常驻进程，但会被系统标记为内存大户，容易触发低内存清理。
实际开发中还有个细节：模型文件放在App私有目录，还是放在外部SD卡？外部存储虽然空间大，但IO速度和安全性不可控。我建议把模型文件放在App私有目录，并且做分片校验，防止下载损坏。用户要是手动清理空间，模型文件没了，App会出现加载失败，这个要做好错误提示。
4. 效果与体验：跑起来的模型能干什么
4.1 对话、写作、摘要等本地任务
用130亿INT4模型在手机上跑起来后，第一个感受是“有点意思，但还没有惊艳”。它能完成流畅的日常对话，比如问它“推荐一份周末旅行计划”，它能给出结构条理的方案。写邮件、写请假条、翻译短句都很自然。代码方面，简单脚本能写，复杂逻辑容易跑偏。摘要任务表现不错，给一篇长文，它能提炼出关键点。
但和云端大模型比，差距是明显的。350亿参数蒸馏到130亿再INT4，知识密度下降是硬件上的铁限制。比如问它“唐朝有哪些诗人”，它能答李白杜甫；问它“XX冷门小说的主角叫什么”，它大概率胡编。端侧模型更适合做碎片化、即时性的辅助，而不是百科问答。
不过本地部署有一个云模型比不了的优势：隐私和离线。所有数据不出设备，不用担心对话被上传，也不依赖网络。在飞机上、地铁隧道里，它照样工作。作为个人助理，这种“数据不出门”的价值，对很多用户来说是硬需求。
我在测试里尝试用一个在线联网的350亿模型和手机端130亿模型同时做会议纪要整理。电话内容实时转写后交给本地模型摘要，隐私性拉满。虽然摘要质量不如大模型，但胜在响应快、零网络延迟、无审校等待。尤其是敏感财务数据，本地模型处理完不留痕，让人安心。
4.2 功耗、发热与流畅度平衡
手机上跑大模型，最直观的问题不是“能不能用”，而是“能撑多久”。我实测130亿INT4在骁龙8 Gen 2上，CPU+GPU同时混合推理，最初几秒速度很快，大约28 token/s，但3分钟后发热上来，速度降到15 token/s，再过几分钟稳定在10 token/s。整机功耗约8~9W，这个数字对手机来说是比较高的，玩游戏也不过如此。
如果你把手机放在桌上对话，背面会明显发热。冬天当暖手宝倒是不错，夏天就有点难受。如果想解决发热，只能限制推理核心频率，比如把大核锁频到2.0GHz，功耗降到5W，速度会降到8 token/s。这个速度对交互式对话来说勉强能接受，但如果你想让它写一段长代码，等待的时间会让人烦躁。
电池续航也是问题。满电状态下，连续高强度对话，差不多1小时掉电30%左右。和刷视频比，耗电感人。所以实际产品里得加提示：本地模型适合短会话，不适合长时间连续输出。还有一种策略是“先快后缓”：开始生成时用高性能模式，让首token快；后续逐token输出时降频，因为用户已经看到了内容，等待感会被分散。
对了，还有一个容易被忽略的体验点：手机内存不足时，系统会杀掉后台应用，包括正在推理的进程。就算你模型只占6.5GB，但系统里微信、地图、浏览器同时开着，剩余内存不足2GB，模型很容易被杀死。建议App启动时检查系统可用内存，如果低于阈值，提示用户关闭部分后台应用。否则用户正聊到兴头上，App突然重启，之前对话内容全丢。
5. 常见问题与避坑实录
5.1 动态shape与内存碎片
模型部署中出现最多的崩溃，其实是内存碎片。手机进程的内存空间有限，大模型反复申请释放KV Cache，会产生大量碎片。时间一长，明明总内存还算够，却连一个连续的MB都申请不出来。App直接OOM闪退。
我的做法是：给推理引擎设置一个预分配的KV Cache池，比如固定分配512MB作为缓存区，动态长度在这个池子里扩展，绝不会再向系统申请新内存。对话完成后缓存复用，而不是释放回系统。这样能避免碎片，副作用是那个缓存区常驻，占用不会再降。但为了稳定，值得。
另一个坑是不定长输入。手机端应用如果允许用户粘贴超长文本，模型prefill阶段可能一次性做超长矩阵乘，内存峰值暴涨。必须做文本长度截断，比如输入Token不超过1024，超出部分先做提取或分段处理。
5.2 量化后精度下降的补偿
INT4量化后，模型在部分考题类的任务上明显变笨。比如逻辑推理、数学计算，容易出错。我当时尝试了两种补偿方式。
第一种是通过LoRA微调。在量化后的模型上，找一个辅助数据集，用PEFT方式继续训练少量步数，调整量化造成的误差。效果是有的，尤其是恢复“说话口吻”和“格式遵循能力”。但微调需要GPU图形卡，不是手机能干的活。
第二种是加权采样。推理时动态选择不同量化精度的权重，关键层用FP16，非关键层用INT4。这需要推理引擎支持混合精度。llama.cpp可以通过量化为不同层设不同位宽，但操作起来比较麻烦，而且混合精度加载时，内存占用会比纯INT4高一点。如果你目标是极致均衡，可以试。
还有一个容易踩的坑：校准数据集分布太偏。如果你用代码数据集校准，而实际使用时主要做中文对话，量化误差会被放大。最好校准数据覆盖最终任务场景。我的第一次量化全用英文数据，导致中文对话能力明显下降，后来混入中文微博、知乎、百科语料才恢复。
5.3 端云协同的取舍
即便能在手机上放下130亿模型，有些场景还是要“端云结合”，别一根筋全本地。
举个例子：用户问“今天北京的天气”，本地模型不知道实时天气，这时候就得申请云端接口。端侧模型的价值不是替代云模型，而是解决隐私、离线、低延迟的需求。所以架构上可以做“端上优先，云端兜底”：
- 本地能回答的，比如写文案、摘要、闲聊，离线推理。
- 本地答不了或权限敏感的，比如实时查询、图片识别，走云端。
- 本地生成的草稿，用户可以选择分享或同步到云端继续处理。
这种混合方式既能保护隐私，又能保证问答的完整度。我做的App里有一个开关“离线模式”，开启后强制所有请求走本地，关闭后自动判断，需要联网的调用云端API。用户对这个设计反馈很好，既给了选择权，又不会因为模型能力不足而完全放弃使用。
当然，端云协同也有坑。比如用户开了离线模式后，对本地模型的能力产生过高期望，结果发现它不会实时天气，觉得是产品垃圾。所以UI上要说明哪些是本地能力、哪些需要联网。同时云端API的接入要考虑鉴权和流量费用，不要一个请求把用户流量包跑完。
5.4 手机适配与碎片化
最后聊一下机型适配。手机处理器天梯图上的SOC五花八门，骁龙、天玑、麒麟、苹果A系列，它们的内存带宽、NPU算力、驱动质量差异巨大。你在骁龙8 Gen 2上调好的推理参数，换到天玑9200上可能直接算错，因为GPU后端的指令集和缓存策略不同。
我的建议是：最低支持标准定在“CPU能跑”，保证任何手机都能用，只是速度慢。然后对于骁龙和天玑分别做GPU优化分支。测试机型至少覆盖三档：旗舰芯片（比如8 Gen 3）、中端芯片（比如7系列）、旧芯片（比如骁龙865）。中端芯片可能能运行，但速度会在5 token/s以下，体验很差，所以要在设置里体现“设备性能”提示。
另外，国产手机的MIUI、ColorOS等系统，对后台进程的管控非常激进。你App常驻6GB内存，很容易被系统当成耗电大户一键清理。应对方式是用前台服务并提供持续通知，让系统知道这个App正在干活。还有不少手机系统对单个App有内存限制，需要在厂商后台申请豁免，这又是另一套沟通流程。
老实说，把350亿或者130亿模型塞进手机，技术上已经没有无法逾越的障碍了。真正难的是性能和用户体验的平衡，以及一大堆系统底层的“破事”。但换个角度想，这些“破事”恰恰是端侧工程师的价值所在。模型算法大家都能跑，能把跑起来的发热、卡顿、杀进程处理干净的，才是真正能交付产品的人。
我自己的习惯是每做一个新端侧项目，先写一个“体验日记”：第一天跑通，第二天调速度，第三天开始折腾热降频，第四天处理各种崩溃。几轮下来，你会对内存墙和功耗墙有切身的敬畏。350亿参数住进一台手机，听起来是模型体积的胜利，实际上是一次又一次对系统资源的极限施压。这个过程没有玄学，就只有一行一行代码地跟内存分配、缓存复用、芯片驱动较劲。
