我最早被“300亿参数大模型装进手机”这句话勾住是在一次内部方案评审会上。当时我们正在做一个移动端AI助手用户反馈最多的不是功能少而是“转3秒出结果”、“网络一差就废了”。团队里有人提了一嘴要不我们把模型直接塞到手机里跑会场上安静了两秒然后做推理优化的同事笑了“你知道30B的FP16权重有多大吗60GB。手机内存才多少”但三个月后我们真把这事儿跑通了。当然不是把完整的300亿参数模型原封不动塞进去——而是把模型压缩到能装的状态再让端侧和云端各管一段活。这里面涉及的内存账、算力账、路由策略、量化细节远比想象中有意思。这篇文章就把整套思路摊开讲清楚适合正在做端侧AI、或者想给App接入大模型能力但卡在“模型太大、手机装不下”的同学参考。1. “300亿参数装进手机”到底装了啥先算一笔内存和算力的账先说结论严格意义上的“把300亿参数模型完整装进手机并全量跑完”在今天的技术条件下仍然不现实。但工程上我们说的“装进”是“符合实际约束的部署方案”不是“原封不动全放进去”。1.1 30B模型原始的“体积”有多大先算一笔最基础的账。30B就是300亿个参数参数在计算机里要以一定精度存储精度每参数字节数总内存占用可行性FP324字节120GB服务器级FP16/BF162字节60GB服务器级INT81字节30GB大内存工作站INT40.5字节约15GB旗舰手机勉强混合量化部分层INT4/部分INT8约0.6字节约17-18GB旗舰手机可行15GB的权重看起来2024-2025年的24GB内存旗舰机能塞下。但这只是权重本身。推理过程中还要额外占用KV Cache根据上下文长度和层数不同4K上下文大概还要1-2GB、激活值batch1时通常几百MB、操作系统和App本身的内存。全部加一起24GB内存的手机其实已经到极限了几乎没有余量给系统做内存调度安卓后台一杀模型就得重新加载体验崩得很快。所以第一层结论是靠纯量化硬塞只能塞一个“能跑但很难用”的30B模型。真正在线上跑得畅通的端侧方案是下面几件事的组合。1.2 算力账手机芯片的天花板在哪内存装得下只是第一步还得看算力跑不跑得动。大模型生成一个token大概需要把整个权重从头到尾扫一遍。假设我们用INT4量化后的30B模型每生成一个token理论最小数据搬运量就是15GB所有参数读一遍。手机内存带宽按当前旗舰LPDDR5X的水平算大约60-70GB/s实际受芯片和通道数影响会有折扣15GB ÷ 60GB/s ≈ 0.25秒也就是说每个token耗时250毫秒左右大约每秒生成4个token。这个速度是什么概念正常阅读速度大约是每秒4-6个字所以这个速度勉强能“边看边出”但对话体验会拖沓明显有等待感。而云端一张H100用FP16跑30B模型单卡能做到每秒生成几百甚至上千token体验差距是数量级的。加上手机NPU做LLM推理时指令流水线、内存带宽、算子支持都有限制实际速度可能比理论更低。算完这笔账结论已经很清楚端侧跑30B的大活了实际上是跑不动的。那为什么还有“300亿参数装进手机”的说法因为工程上有取舍——把30B模型“切”、化、压成多个形态端侧跑轻量的那部分云端跑重的那部分。1.3 结论先行端侧不是“全跑”而是“能分担一点就分担一点”我调试完第一版端侧方案后对“装进手机”这个说法的理解变得非常具体端侧的目标不是替代云端而是在带宽受限、弱网、隐私敏感这三类典型场景里把一部分任务接住。其余的重活儿还是交给云端。设计得好的端云协同系统用户根本感觉不到任务是在哪边跑的。他只知道有网时又快又聪明没网时慢一点但基本功能不瘫。2. 端侧与云端怎么“各管一段”延迟、隐私、成本的三角路由标题叫“端侧云端各管一段”关键问题其实是哪些活儿分给端侧哪些留给云端怎么分这不是一句“简单的任务走端侧、复杂的走云端”就能概括的。分的标准至少涉及三个维度延迟敏感度、隐私敏感度、计算成本。2.1 端侧负责什么敏感数据与低延迟交互我在实际项目里给端侧划定了三类典型场景与个人数据直接相关的任务比如“总结一下我最近收到的银行验证码”“从通讯录里找出合作过的人”。这类任务如果把数据传到云端就会涉及隐私合规、数据脱敏、用户信任等一系列问题。端侧跑一个3B-7B的小模型即使效果差一点但用户数据不出设备安全上就立住了。低延迟交互类任务比如输入法联想、语音助手的短指令理解、“不要转圈”的连续对话。这类任务对延迟极度敏感200ms和2s的差异是“可用”和“不可用”的界限。端侧哪怕生成质量弱一点胜在“秒回”。断网兜底飞机、地铁、地下车库网络说断就断。端侧模型的价值不是“跑得最好”而是在极端情况下“还能干活”。2.2 云端负责什么重生成、深推理与知识更新云端承担的是端侧做不动或做不好的事长文本连贯生成写文章、写代码、做方案这类任务动辄生成几千字端侧4 token/s的速度会让用户以为程序卡死了。复杂推理链数学题、逻辑分析、多步规划。这类任务对生成质量和推理一致性要求极高量化后的小模型在这里容易出现“逻辑断裂”和“一本正经胡说八道”。知识密度高的问答端侧模型的知识截止日期是训练时决定的云端可以通过检索增强等方式拿到更新的信息。2.3 路由策略怎么定这不只是一个网络请求各管一段的落地核心是一个“路由决策模块”。它通常有两个形态前置意图分类器和动态策略控制器。第一个阶段用一个非常轻量的分类模型甚至不需要是LLM一个几MB的文本分类器就行判断当前请求属于哪一类隐私类、短交互类、复杂生成类、知识问答类。分类准确率做到95%以上路由就基本可靠。第二个阶段根据实时网络状态动态调整。比如用户连着Wi-Fi、信号好复杂任务直接走云端用户只有一格信号、带宽紧张哪怕任务复杂一点也可以先让端侧给一个初步结果再在后台上云做精修。这就是所谓的“动态路由”。提示路由决策一定不能让用户感知到明显的“切换”。端侧和云端的会话状态需要共享用户从离线切回在线时上下文不能丢。这就引出了后面会细讲的会话同步问题。3. 把30B模型“塞”进手机的完整链路量化、蒸馏、转换、部署四步走这一节讲实际操作。从拿到一个30B开源模型到它真正跑在手机里中间要经过四步加工。每一步都有绕不开的坑。3.1 第一步量化压缩但不是无脑INT4量化是大模型瘦身的最直接手段。原理一句话模型参数里存储的权重本来是浮点数如果把相邻权重映射到更少的离散取值上就能用更少的bit表示。实际操作中有几个经验值INT8量化8bit质量损失已经很小常见模型几乎无损。但30B的INT8仍然是30GB手机装不下。INT4量化4bit模型体积降到15GB左右但质量损失开始显现。尤其是数学推理、代码生成这类任务错误率可能上升好几个百分点。混合精度量化不是一律砍到4bit。Embedding层、LayerNorm层、最后几层输出层这些对精度敏感的部分保留8bit或16bit中间的大块线性层用4bit。这样能在体积只增加1-2GB的情况下大幅挽回模型质量。我用GPTQ和AWQ都做过实测对比。GPTQ是训练后量化的经典方案AWQ则在少量校准数据上做权重缩放实测AWQ在中等参数规模模型上的质量保持稍微好些尤其是在“数学逻辑类”任务上的回退幅度更小。但GPTQ的社区支持和工具链更全跑起来更省事。没有绝对的好坏具体选哪个取决于你手上的模型和任务。数据准备注意量化前需要准备校准数据集。不要随便拿样本文本去校准最好用跟目标任务接近的数据。比如你要做代码助手校准数据就应该是代码片段而不是新闻语料。这个细节直接影响量化后的质量上限。3.2 第二步蒸馏或裁剪实在塞不下就换个思路量化解决的是“同一架构下的瘦身”但如果15GB连你都觉得太大就得考虑蒸馏或裁剪了。知识蒸馏的目标是“训练一个小模型去模仿大模型的行为”。你把30B的模型当老师用它的输出和中间表示去训练一个3B-14B的“学生模型”。最终部署的其实是学生模型但它的能力向老师模型靠拢。裁剪则是另一条路观察模型里哪些层、哪些注意力头对输出贡献小把它们剪掉再微调补偿。实际落地中裁剪的收益通常比蒸馏小但胜在不用重新训练适合算力不够的团队。提示做端侧模型选型时“从30B蒸馏到7B”往往比“直接训练一个7B原生模型”效果更好。原因是老师在语义理解、长距离依赖上已经学会了更丰富的模式学生模型能继承一部分。这是当前端侧模型和云端大模型“共用血缘”的主要方式。3.3 第三步模型格式转换与算子适配模型还是PyTorch格式时没办法直接跑在手机NPU上。要经过格式转换进入移动端推理引擎的“辖区”。这一步是工程上最容易翻车的地方。目前主流的移动端推理框架包括llama.cpp纯C实现支持GGUF格式在CPU上就能跑部署灵活社区活跃。适合原型验证和CPU兜底。配合Android的LLM Runtime或iOS的Core ML也能调度GPU/NPU。MLC-LLM基于TVM编译栈跨平台做得比较好能把相同的模型编译成针对不同硬件优化的代码。MNN / NCNN国内用的多移动端算子覆盖广但对LLM这类新架构的算子支持更新相对慢。公共经验是先用llama.cpp在开发机上把模型跑通做功能和效果验证再考虑用MLC或特定厂商SDK做NPU优化。从PyTorch到ONNX再到移动端格式中间会遇到大量算子兼容问题。什么Transpose算子版本不支持、SiLU激活函数在某个NPU后端没有实现、Attention Mask的广播规则不一致……这类问题会在第5节集中展开。3.4 第四步运行时框架与内存驻留策略模型转换完了最后是运行时策略。这里有一条很重要的经验不要让整个模型永久驻留内存。可以在App启动时只加载一部分比如前几层快速给出一个“正在准备”的界面响应当用户真正发起请求时再按需把后续层加载进来。也可以用mmap方式把权重文件映射到虚拟内存让系统按页加载减少冷启动开销。另外如果手机内存实在紧张还有一个妥协方案不加载完整30B模型而是加载一个蒸馏后的7B端侧模型同时保留一个“云端调用300亿参数模型”的通道。这样端侧保底云端兜底体验反而比“硬挤”更顺滑。4. 端云协同的通信协议与会话状态同步上下文不能断端侧和云端各跑一部分最麻烦的问题不是“谁跑”而是“两边怎么对接”。做过的人都知道模型本身不难难的是一切都要围绕“上下文不能断”这个目标来设计。4.1 会话切片与KV Cache复用对话是一个持续状态。用户先说“帮我写个方案”然后又补充“用口语化一点”再补充“加一段产品背景”。这三句话之间有依赖如果第一句走云端、第二句走端侧、第三句又走云端就需要把上下文完整传过去。最常见的实现方式端侧模型在执行对话时维护自己的会话ID和上下文缓冲。当某个请求需要上云时把当前会话的压缩文本摘要比如最后N轮对话或者更精简的关键信息随请求一起发给云端。云端拿到上下文后重新构建自己的KV Cache并不是把端侧的KV Cache直接搬过来——因为两个模型结构不同、分词器可能也不同直接搬是不可能的。实际可迁移的只有“文本状态”不是“模型状态”。这条原则背后的逻辑很直白端侧小模型和云端大模型的架构、分词表、上下文长度都不同KV Cache无法直接移植。所以端云协同里的“状态同步”本质上是**“会话文本的连续传输”**而不是“模型内存的迁移”。4.2 断网兜底端侧模型单独扛端云协同最考验系统的场景是用户在弱网环境发起了一个“本该走云端”的复杂请求。我的处理方式是三层降级有网且信号好复杂请求走云端端侧只做路由和预处理。有网但带宽差请求会等一段时间如果云端延迟超过阈值系统自动切到端侧模型跑一个简化版本同时提示“当前网络不稳定结果由设备端生成”。完全断网端侧模型全权接管虽然能力弱一些但基础的摘要、改写、对话、信息提取都能完成。这个“先云端、超时降级、再端侧”的策略需要调用超时机制和结果质量评估做配合。比较稳的做法是给端侧模型设一个可接受的质量底线宁可在复杂任务上给个“不完美但正确”的答案也不要让用户面对一个空白页。4.3 延迟和成本的实测数据以我自己的一个测试项目为例端侧部署的是一个约7B参数的INT4模型约4GB云端是完整30B模型场景端侧延迟云端延迟成本短指令理解“设个明早8点的闹钟”150-350ms800-2000ms含网络端侧0成本3-5句对话续写4-8秒1-2秒端侧0成本云端按token计费2000字长文生成几十秒起步5-10秒端侧发热严重云端合算这个表格说明了一个反直觉的事实短任务端侧又快又省长任务端侧慢且体验差。所以“各管一段”的边界不是按任务复杂度一刀切而是按输出长度和延迟需求做函数式的划分。你甚至可以根据实测数据画一条“端云切换阈值曲线”——当预计生成token数超过某个值时直接判给云端。5. 部署实测踩过的坑精度回退、算子缺失、发热降频写完上面这些也来说说真正动手时会遇到的硬骨头。这一节全是实测经验每一条都对应着一次线上事故或调试到凌晨的经历。5.1 量化后模型“变傻”了最开始我把一个30B模型量化到INT4本地跑起来测试发现它连“鲁迅原名是什么”这种常识题都能答错。当时第一反应是量化工具的问题后来查资料才明白INT4量化对模型的embedding层影响特别大因为它涉及的权重数量大而且和具体token的嵌入紧密相关。解决办法是混合量化embedding层、LayerNorm层保持FP16或者INT8只有注意力层和FFN层用INT4。实测在体积几乎不变的情况下常识问答和逻辑推理的准确率能回升一大截。5.2 算子不支持导致的崩掉与回退LLM的推理过程里很多算子在移动端NPU上是“不存在”的。最常见的几个RMSNorm很多端侧NPU没有直接实现需要分解为LayerNorm缩放操作或者退回到CPU执行。Softmax的数值稳定性在FP16下大logits可能会溢出需要优化过的online softmax实现。RoPE旋转位置编码不是每个推理引擎都原生支持需要手动实现或走ONNX自定义算子。这种情况下最实用的方案是给每个算子做“NPU/CPU”双通道跑之前检测算子支持表不支持的直接走CPU。代价是部分层慢一些但至少不崩。真正要上量时再针对高频算子和芯片厂商的SDK团队开case做适配。5.3 发热降频是端侧推理的最大敌人手机不是服务器没有风扇散热靠热管和机身。实测连续跑5分钟的7B模型推理手机温度可以从28度升到45度以上然后系统开始降频token生成速度直接掉一半。更尴尬的是温度上来后亮度降低用户还以为App出了问题。应对方案有几个层次控制单次推理时长上限超过阈值就强制切云端。推理前检查电池温度和剩余电量温度过高时主动降级到“小模型快速回答”模式。在UI上做“优化模式”开关让用户自己选择“性能优先”还是“省电优先”。5.4 上下文限制与KV Cache爆炸端侧模型一般上下文窗口小2K-8K而云端能做到32K-128K。用户一旦在端侧发起长对话KV Cache很快就会占满内存。如果不做处理轻则速度骤降重则直接OOM崩溃。通用的处理是滑动窗口只保留最近N轮的对话和关键历史摘要更早的内容压缩成一段摘要文本。这样KV Cache上限可控但代价是模型可能丢失部分细节——这属于工程上的无奈取舍设计初期就要和产品说清楚。6. 给也想做端云混合部署的人几条实际建议最后聊几条总结性的经验都是踩过坑之后才确定的思路。6.1 哪里拿模型、怎么选端侧规格开源模型是目前做端侧部署的主流来源。社区里常见的几类模型包括中文能力较强的Qwen系列、Llama系列、GLM系列和Mistral系列。选端侧模型时不要只看总参数量更关注模型的实际内存占用量化后在目标任务上的量化回退程度社区工具链成熟度转换、微调、量化教程多不多踩坑记录多不多刚开始做的话建议不要直接挑战30B量化后塞手机而是先从一个7B或14B模型开始跑通全链路再逐步升级。6.2 先跑通最小闭环再做性能优化第一版架构别急着上NPU加速、算子融合、KV Cache复用这些高级优化。用llama.cpp在CPU上先把“端侧模型能跑、能切换、能降级”这件事跑通然后用真实的用户流量看路由准确率和延迟分布最后再针对瓶颈做优化。很多团队一上来就追求“芯片原生速度”结果在算子兼容性上耗了一个月连基本链路都没通。6.3 监控体系要从第一天上端云协同比纯云端部署多了一个复杂度你很难判断一个回答是端侧生成的还是云端生成的、网络情况如何、切换是否成功。所以从第一天起就要埋日志点请求路由到了哪端、延迟多少、是否发生降级、量化模型是否超时或OOM。没有这些数据你后面做的所有“优化”都是凭感觉。我在实际部署中的体会是不要执着于“把完整模型装进手机”这句话的表层含义。它的本质是“端侧承担一部分云端承担一部分给用户一个完整体验”。内存账、算力账算清楚之后“各管一段”不是一个妥协方案而是在现有硬件条件下最优的架构选择——这比“单纯把模型塞进去”有挑战得多也值得做得多。