苹果在2023年WWDC上展示的那个只有几十亿参数却能在iPhone上流畅跑通Transformer的案例算是把“端侧模型”这个概念真正烧到了大众视野里。紧接着是高通在骁龙峰会上强调AI算力然后是Meta的Llama系列推出手机版……等到2024年上半年几乎所有做AI的人都在讨论同一个问题模型到底该不该回到设备端。这个讨论背后有一个很扎心的现实——数据量在暴涨带宽却在原地踏步云端的成本曲线越来越陡峭而用户对隐私的要求已经从“可选项”变成了“默认项”。“设备即环境”这个提法就是在这样的背景下从一个北大系创业团队的对外分享里冒出来的。那篇文章观点很鲜明移动端、PC端、甚至IoT设备本身才是大模型真正该落地的环境而不是远在机房里的GPU集群。这篇文章想从实操的角度来拆一拆端侧模型这件事。我会把自己在不同设备上部署和调试模型的经验摊开来讲包括为什么“设备即环境”不只是一个口号、端侧模型在工程上到底要过哪些关、选型时怎么避坑以及现阶段它到底能做什么、不能做什么。这篇文章适合三类人第一类是正在纠结模型方案选型的产品和技术负责人第二类是搞移动端或嵌入式开发想在自己的App里塞进AI能力的工程师第三类是纯粹对“AI到底怎么运行”这件事好奇的爱好者。不管你属于哪一类我尽量不讲虚的全部按实操逻辑来。1. “设备即环境”到底在说什么1.1 一句话版本模型跟着设备走传统的AI服务模式是“模型在云端设备当终端”——你把数据发到服务器服务器跑完推理再返回结果。这种模式有它的好处算力集中模型可以做得很大效果也确实更好。但它有三个天花板很难突破延迟、隐私、成本。延迟方面即便5G网络已经铺得很广一次完整往返也需要几十到上百毫秒如果涉及多轮对话或长文本处理延迟会更高。而对于一些实时性要求高的场景——比如AI助手的语音交互、AR眼镜的实时识别、自动驾驶的应急决策——几百毫秒的延迟是不能接受的。隐私方面把数据上传到云端意味着用户的语音、图像、聊天记录都要经过网络链路这对医疗、金融、办公等场景来说几乎是政策红线。成本方面就更直接了大模型的推理成本虽然已经降下来不少但用户量一旦上去按Token计费的云端推理账单可以吃掉整个产品的毛利。“设备即环境”的逻辑是把模型从云端搬到设备上——手机、PC、手表、音箱、车载系统、边缘网关每个设备都内置一个本地模型。设备不再是一个“哑终端”而是一个完整的AI运行环境。这样一来延迟变成了本地计算的时间隐私问题因为数据不出设备而大幅缓解边际成本也趋近于零。更重要的是模型可以针对设备的使用习惯、个人数据进行本地微调和个性化适配这是云端方案很难做到的。这个说法最早在行业里流传时被一些人看成“噱头”——毕竟云端的Scaling Law还在继续更大的模型就有更好的效果凭什么要回到小模型但2023年和2024年的技术进展恰恰说明了一个反直觉的事实小模型的能力提升速度超过了大家的预期。1.2 “设备即环境”的四个底层判断如果要把这个口号拆成工程上可执行的方向我理解下来有四条第一Transformer基础架构在端侧同样有效。不要以为端侧模型和云端模型是两套完全不同的技术路线。今天跑在手机上的那些3B30亿参数、7B70亿参数模型和云端跑的那些70B700亿参数、上百B的大模型底层都是同一套Transformer架构、同一个训练范式和同一种对齐方法。这意味着云端积累的很多经验、代码和工具链可以很大程度复用。第二芯片算力已经越过了“能用”的门槛。苹果A17 Pro的神经网络引擎算力大约是35 TOPS高通的骁龙8 Gen 3大约45 TOPS即便是中端芯片也有了10 TOPS以上的算力。每秒数十亿次的操作跑一个几十亿参数的模型做推理已经有了基本的硬件基础。更关键的是内存带宽在悄悄提升——LPDDR5X甚至LPDDR5T的带宽跑进了每秒几十GB这让模型权重在内存和设备端NPU/GPU之间的搬运速度不再成为瓶颈。第三模型压缩技术进入了成熟期。量化量化为INT8、INT4、蒸馏把大模型“教”给一个小模型、剪枝这些技术在2022年时还更多停留在论文里到2023年已经有大量生产级工具可以做。特别是在量化领域对一个7B模型做4-bit量化后模型大小可以压到3.5GB左右已经可以塞进手机App里了。对普通用户来说这种压缩带来的效果损失已经很难察觉。第四端侧模型能提供云端做不到的体验。因为它跑在本地它了解你手机上装了哪些App、你的日程是什么、你打字习惯是什么、你拍照的构图偏好是什么。这些信息不需要离开设备模型可以直接在本机数据上运行这样的个性化能力和隐私合规性是云端方案无法复制的优势。这四个底层判断是“设备即环境”从概念走向产品的关键。接下来我重点聊聊端侧模型在工程上到底要过哪些关口。2. 端侧模型落地必须过的四个技术关2.1 参数规模与内存的数学账先说一个基本的算术问题。一个7B参数的模型用FP16精度存储每个参数需要2字节那么权重部分就要占14GB内存。14GB什么概念一台普通PC的可用内存可能也就16GB一部手机的总内存可能也就8GB到16GB。根本塞不进去。那怎么把它塞进设备答案是量化。量化的核心思路是用更少的比特数来表示权重。FP32是32位浮点FP16是16位INT8是8位整数INT4是4位整数。同一个7B模型FP16要14GBINT8只要7GBINT4只要3.5GB。手机12GB内存的机型跑INT4量化后的7B模型操作系统和应用挤一挤理论上是可行的中端机型配个1.5B或3B的模型更是绰绰有余。但量化的代价是什么两个字精度。模型权重从FP16变成INT4数值表达范围会缩小某些原本能答对的问题可能会答错。不过近两年的量化算法已经越来越好——比如GPTQ、AWQ、QLoRA这些方案在4-bit位宽下能把损失控制在极小范围尤其是对推理任务来说很多场景的表现已经几乎无损。所以内存这一关的结论很清晰如果要在设备端跑模型你首先要完成一次“量化决策”——决定你的业务能接受多大精度损失再反推模型大小和位宽。没有一个参数配置是放之四海皆准的。2.2 内存带宽决定了推理速度的天花板就算模型量化后塞进了内存能不能流畅运行还要看另一个关键指标内存带宽。Transformer模型做推理时每个Token的生成都需要把模型的所有权重从内存搬运到计算单元。权重越大、带宽越低单位时间内能生成的数据就越少。举个例子一个7B INT4模型权重约3.5GB如果内存带宽是25GB/s大概相当于当前主流旗舰手机的水准那么理论上每秒最多能搬运大约7轮完整权重也就是说每秒输出最多7个Token左右。你再叠加模型的思路消耗实际速度可能也就是每秒2到5个Token。这个速度看个短回复还行但要是让它生成一段长文体验就会比较着急了。带宽问题的另一个解法是减小模型本身。1.5B INT4模型的权重不到1GB同样带宽下理论上Token生成速度可以提高到四倍以上。这也是为什么端侧模型普遍以任务为导向、以轻量为主——不是大家不想跑大模型是内存带宽这个物理瓶颈卡在这儿。提升带宽这件事短期内不会魔法式地改善但芯片厂商已经在做——统一的SoC内存设计比如苹果M系列和骁龙平台的LPDDR5X就是在把CPU、GPU和NPU之间的数据搬运距离缩短。这条路的趋势是“通吃”——端侧模型会越来越流畅但前提是你把模型大小和位宽匹配到设备硬件上。2.3 模型架构决定“能不能留在这个设备上”很多人以为端侧模型只是在模型文件大小上做文章顶多就是量化一下。实际上从架构层面做轻量化才是根本性的解法。业界这两年在模型架构上有两个值得一提的创新路径。一个是基于MoE混合专家架构的原理是把一个完整的模型拆分成多个专家模块每个Token只激活其中一部分专家。这样即便模型的总参数很大单次计算只走一个子路径计算量和内存需求就降下来了。所以你就能看到有些“手机端MoE模型”总参数有14B但每个Token只激活2B左右的参数跑起来反而快。这个思路的效果就像一个大翻译团队平时只有几个人在忙而不是所有人同时上。另一个方向是线性注意力机制以及它的变体。传统的Transformer注意力机制是平方级复杂度——序列越长计算量越夸张。而线性注意力把复杂度降到了线性模型就能在更长上下文上保持较低的算力消耗。不过要提醒的是这类结构在长文本任务上的能力相比标准注意力还有差距属于“有得有失”的权衡。架构选型这件事没有绝对的好坏只有适不适合你的设备。因为端侧设备的差异——旗舰机和中端机、笔记本和手机——决定了你既可以用诸如LLaVA系列的1.8B多模态模型也可以尝试在8GB内存的平板上跑7B纯文本模型。关键是构建出“设备能力→模型架构→任务目标”的匹配链路。2.4 推理引擎最后十公里的关键模型文件有了设备也匹配上了最后一个大坑是推理引擎。所谓推理引擎就是把模型文件加载到设备利用设备的GPU/NPU执行计算的那层软件。行业内目前比较主流的方案有llama.cpp及其各种绑定、MLC-LLM、ExecuTorch、ONNX Runtime等。其中llama.cpp是社区生态最丰富的支持多种硬件后端通过GGUF格式的模型文件运行跨平台性好甚至可以在树莓派上跑MLC-LLM则是TVM社区的作品在设备适配自动化方面做得比较深ExecuTorch是PyTorch的官方端侧方案如果你已经有PyTorch模型它能把模型直接导出到设备端运行。推理引擎的选择有一个经验性的评判标准看这个引擎对目标硬件后端的优化程度包括是否支持异构计算、是否支持INT4反量化指令、是否针对特定芯片比如高通Hexagon DSP、苹果ANE做了算子优化。不同引擎在同一个设备上的性能差距可能有两三倍所以不能只看“能跑”就当完了还得看“跑得有多好”。3. 实测与选型不同设备上我踩过的坑3.1 选型前的决策清单我给团队做端侧模型选型时总会先拉一个决策清单把问题标准化任务的复杂程度是需要开放式生成还是只需要分类/抽取/打分如果只是后者1B以下的模型很可能就够了。目标设备的硬件基线团队能容忍的最低配设备是什么是按旗舰机优化还是要兼容三年前的千元机精度和速度的取舍离线基准测试中INT4与INT8的差异是否能被业务接受内存峰值控制类似4K上下文长度时KV Cache会额外占用多少内存有些场景还要做多轮对话内存峰值要留足余量。框架的团队熟悉度团队是PyTorch技术栈还是TensorFlow/其他这决定了后期调优的顺畅程度。我把这个清单跑过好几轮帮你排掉了许多暗坑。3.2 旗舰手机上的实操记录旗舰机是目前端侧模型最好的测试环境。我自己在一台12GB内存的安卓旗舰上部署过7B INT4模型。初始跑通用任务时觉得效果完全能接受但在长文本摘要、多轮对话这类场景速度掉到每秒2-3个Token体验非常糟糕。后来我做了一次调整把上下文长度从4K降到2K并用半精度加载实测速度提升到8-9 Token每秒。这个改变自然带来记忆能力下降但配合检索外部内容来补足之后产品体验整体是合格的。这个经验后来成为我在团队内部反复讲的一个原则端侧模型要配合检索系统让模型的“记忆”通过外置手段补齐而不是指望一个小模型把全部上下文记在脑子里。另一件事是NPU与GPU的选择。很多App开发者在调用NPU时以为NPU肯定比GPU更快。实际上NPU擅长的是卷积和一些固定结构的算子对Transformer中的部分算子适配还不够好。我在实测中遇到过几次NPU反而比GPU慢的情况。我的建议是同一机型上做一次GPU与NPU的端到端延时对比不要拍脑袋决定。对了还有发热降频。持续跑模型会把SoC推到高负载发热后频率下降速度可能降到峰值的一半。实测跑一个长文生成任务最初几秒可能28 Token每秒三分钟后掉到14。如果你们的App有这种长任务场景必须在产品层面做交互缓冲比如分段生成、暂停机制等别让性能衰减直接暴露给用户。3.3 中端设备与PC端的现实中端机6-8GB内存在跑3B INT4模型时还算顺畅但跑7B就会出现严重的抖动。原因很简单内存不够用系统频繁换页性能瞬间崩溃。对于中端设备我的建议是直接选1.5B-3B模型精度优先用INT8内存占用和速度都能保持稳定。别抱有“压缩一下就能跑更大的模型”的幻想——压缩之后精度损失和速度损失全来了产品依然用不了。PC端的情况比手机乐观得多。现在主流的PC一般16GB内存起步部分甚至32GB。7B INT4模型在M系列芯片或者带独立GPU的笔记本上可以跑到每秒15-25个Token体验已经和云端接近。对于桌面办公场景本地跑小模型做文档摘要、代码补全、会议纪要已经可以实际投入使用了。我在实际项目里对PC端的建议是尽量利用已有的GPU如果没有GPU就选CPU推理引擎。CPU跑7B INT4如果内存带宽够好速度能做到6-10 Token每秒——用来做离线批处理是够的做实时聊天稍吃力。所以PC端到底用不用端侧模型取决于你的使用场景而不是硬件行不行。4. 常见问题与排查技巧实录4.1 量化后效果崩了如果你量化完模型发现回答质量肉眼可见地下降第一反应不要急着换回FP16。先检查几件事是不是量化校准数据“偏科”了。很多量化工具用到校准数据集这个数据集要和你的业务分布接近——如果你做的是医疗问答拿通用文本去校准量化后专业能力会变得很“癫”。换一份贴近业务的校准数据重跑一次往往能救回一大半的准确率。另外检查是否有算子不兼容导致的退化。某些量化方案只覆盖了部分算子剩下没覆盖的算子继续走FP16这样会有层间精度错配结果飘忽不定。解决方法是可视化每一层的数值分布找错配点或者干脆换推理引擎。4.2 显存/内存不够一跑就崩这类问题的排查规律是先看KV Cache。Transformer推理时KV Cache随着上下文长度线性增长长上下文场景下它吃掉的内存可能比模型权重还大。我实测过7B INT4说不定权重才3.5GBKV Cache在4K上下文中吃掉近1GB。很多开发者只算了权重大小就上了忽略了KV Cache。所以内存不够时的第一个操作是把上下文长度砍半试试。另一个技巧是“分块加载”。部分推理引擎支持权重分块加载——不是一次性把完整权重读入内存而是按层按块按需加载。用途不大TTFT首Token生成时间会拉长但能解决内存紧张的设备问题。如果你做的是一个偶尔才用AI功能的工具类应用分块加载是策略上划算的方案。4.3 端侧模型API的适配坑在端侧做工程和云端的不同在于云端模型一般都有开放API比如OpenAI兼容接口而端侧推理引擎各有各的调用方式。这导致端侧模型很难做统一的业务逻辑封装。我们在团队内部的做法是在推理引擎之上再套一层自定义的、统一的抽象层把加载、推理、流式输出、错误处理封装成同一套接口后续换引擎时只改底层适配代码。补充一个重要经验端侧模型的错误处理必须额外用心。设备端资源有限模型加载失败、内存溢出、耗电异常、进程被杀都是常态。云端跑挂了可以重试端侧跑挂了用户只会觉得你的App是个垃圾。所以端侧推理必须做异常状态监测在日志里埋点并且预先设计“降级到云端的方案”——这是产品上线前的必选项。5. 端侧模型能做与不能做的事5.1 能力边界别拿3B模型去对标GPT-4端侧模型再进步它的能力边界就摆在那里。你不可能用一个1.5B模型去代替GPT-4做复杂推理、长程规划或高难度创作。这不只是能力大小的问题而是模型在训练时面对的语料和算力都不一样。端侧模型现阶段真正擅长的场景有三类第一类是轻量生成任务比如短消息回复建议、命名实体识别、情感分类、信息抽取第二类是端到端的语音交互比如在离线状态下完成唤醒词检测、语音识别和简单对话第三类是隐私敏感的个人助理比如日程提取、知识检索、笔记整理这些数据不需要上传云端就能在设备上完成。还有一个重要心得端侧模型应该和云端模型做“协同”而不是“对立”。端侧模型负责低成本、低延迟、隐私安全的初筛和轻量处理云端模型负责高质量、大参数、复杂推理的重任。一套真正好的AI产品架构往往是这个分工逻辑而不是非此即彼。5.2 下一步的想象力从单设备到多设备协同“设备即环境”这个概念如果往深处再推一步就是多设备协同的分布式AI环境。你有一部手机、一台笔记本、一副耳机、一块手表、一台家里的智能音箱——每个设备上都有一个不同容量级别的端侧模型它们各自处理能力范围内的任务必要时再通过加密协议共享推理中间状态。举个具体的例子你在户外时智能手表上的轻量模型完成活动数据监测和紧急语音助手回到家手表把部分中间状态同步给智能音箱音箱上的更强模型接手更复杂的指令在书房打开笔记本最强的端侧模型接手深度任务比如长文档分析、代码开发辅助。设备协同数据不出家庭或个人的设备网络就完成了一整套从轻到重的AI服务。这个场景离我们其实不远。苹果的“Apple Intelligence”已经把端侧AI和跨设备协同作为基础架构了Android生态也在跟进。现阶段要做到跨设备无缝协同还有不少标准化工作要推进但方向上设备不再是孤立计算的碎片而是AI服务的分布式节点。作为一个下场布设过不少端侧模型的人我的真实体会是与其纠结“端侧模型到底行不行”不如接受一个事实——端侧模型不是万能的但在它适合的场景里它的价值是云端替代不了的。隐私、延迟、成本和个性化这四个维度任何一个对业务有实质影响的项目都值得认真评估一遍端侧方案。而“设备即环境”这句话恰好把这个方向概括得足够准确你的设备就是你的AI环境。