1. 端侧大模型落地为什么现在成了一个真问题过去两年大模型的主战场一直在云端。参数越堆越大集群越铺越广推理成本按 token 计费谁家的模型更聪明谁就能拿到融资和订单。但到了 2025 年下半年一个明显的变化出现了越来越多的团队开始把注意力从模型能不能更强转向模型能不能更近。这个近指的就是端侧。端侧部署大模型说白了就是把模型跑在离用户最近的设备上——手机、PC、AR 眼镜、车机、工控盒子、边缘服务器。它解决的不是模型能力上限的问题而是响应延迟、数据隐私、离线可用、带宽成本这四个工程层面的硬约束。你在云端调一次 API往返几百毫秒起步遇到网络抖动直接超时而端侧推理可以把首 token 延迟压到几十毫秒且完全不依赖网络。对于超自动化场景——比如 RPA 流程编排、AI Agent 自主决策、AR 实时交互——这几十毫秒的差距往往就是能用和不能用的分界线。这篇文章面向的是正在做或准备做端侧大模型落地的工程师、架构师和产品负责人。我会把端侧部署的硬件选型逻辑、模型压缩与量化路径、推理引擎的取舍、以及它和超自动化、AI Agent、AR 眼镜这些场景怎么咬合一层层拆开讲。关键词覆盖大模型、端侧部署、超自动化、AI Agent、AR、大模型微调、端侧 AI 硬件部署、光波导 AR 眼镜、大模型量化、推理引擎。读完你应该能判断自己的项目到底该不该上端侧以及如果上第一步该踩在哪里。2. 端侧部署的硬件账本算力、内存、功耗的三方博弈2.1 先搞清楚端侧设备的算力天花板在哪端侧部署的第一个现实问题是你的目标设备到底有多少算力。这不是一个可以含糊的问题因为它直接决定了你能跑多大的模型、用什么量化精度、能接受多高的延迟。目前主流的端侧算力载体大致分四档。第一档是手机 SoC 里的 NPU比如高通骁龙 8 Gen 系列、联发科天玑系列NPU 算力在 30 到 70 TOPS 之间但实际可用算力受内存带宽限制跑 7B 模型量化版勉强能到每秒 10 到 20 token。第二档是 PC 端的独立显卡和核显RTX 4060 这类 8GB 显存的卡跑 7B INT4 模型可以到每秒 40 token 以上体验已经接近可用。第三档是专用边缘推理盒子比如搭载昇腾、寒武纪或高通 Cloud AI 芯片的设备算力从几十到上百 TOPS适合固定场景的批量推理。第四档是 AR 眼镜、手表这类超低功耗设备算力往往只有几 TOPS只能跑 1B 以下的小模型或者做端云协同。这里有个容易被忽略的点标称 TOPS 和实际推理吞吐之间差着一条内存带宽的鸿沟。大模型推理是典型的 memory-bound 任务每生成一个 token 都要把模型权重从内存里读一遍。所以你看设备参数时除了看 NPU 算力更要看内存带宽和内存容量。一个 7B 模型 INT4 量化后大约占 3.5 到 4GB 内存加上 KV Cache 和运行时开销8GB 内存是底线。如果设备只有 6GB 内存那基本只能考虑 3B 以下的模型。2.2 内存带宽才是真正的瓶颈我用一个生活化的类比来解释这件事。大模型推理就像是一个厨师做菜NPU 是厨师的刀工速度内存带宽是食材从仓库送到灶台的传送带速度。刀工再快传送带慢厨师也只能干等着。每生成一个 token都要把整个模型的权重过一遍7B 模型 INT4 大约 3.5GB如果内存带宽是 50GB/s那理论上每秒最多读 14 次权重也就是每秒 14 个 token 的上限。这就是为什么很多设备标称算力很高实际跑起来却很慢。所以在做端侧选型时我通常会先算一笔账目标模型大小除以设备内存带宽得到理论 token 上限再乘以 0.6 到 0.7 的效率系数就是实际能期待的吞吐。这个估算方法在多个项目里验证过误差基本在 20% 以内。2.3 功耗和散热决定了能不能持续跑端侧设备还有一个云端不存在的问题功耗墙和散热墙。手机跑大模型几分钟后就会因为发热降频吞吐直接腰斩。AR 眼镜更极端整机功耗预算可能只有 2 到 3 瓦NPU 能分到的可能不到 1 瓦。这意味着端侧部署不能只看峰值性能要看持续性能。我的经验是对于需要长时间运行的超自动化场景比如 Agent 持续监听事件并决策必须把模型的持续功耗控制在设备散热能力的 60% 以内。具体做法包括用动态量化降低计算量、用投机采样减少大模型调用次数、把非关键推理降级到小模型。这些手段后面会展开讲。3. 模型怎么塞进端侧量化、蒸馏与剪枝的实战取舍3.1 量化是端侧落地的第一道门槛把大模型塞进端侧量化几乎是无条件要做的第一步。量化的本质是用更低的数值精度表示模型权重和激活值从而减少内存占用和计算量。常见的精度从高到低有 FP16、INT8、INT4甚至 INT2。FP16 基本不用考虑7B 模型要 14GB 内存端侧设备扛不住。INT8 能把内存砍半到 7GB还是偏大。INT4 是目前的甜点7B 模型压到 3.5 到 4GB精度损失在可接受范围内大多数任务的表现下降不到 5%。INT2 虽然更小但精度崩塌明显除非是极低功耗场景且任务简单否则不建议。量化不是简单地把数值截断主流的做法有 GPTQ、AWQ、GGUF 这几类。GPTQ 是逐层量化加校准适合 GPU 推理AWQ 是激活感知的权重量化对精度保护更好GGUF 是 llama.cpp 生态的格式适合 CPU 和混合推理。选哪个取决于你的推理引擎后面会讲。提示量化后的模型一定要做任务级验证不能只看困惑度指标。我见过困惑度只涨了 0.1 但结构化输出全乱的案例因为量化对某些注意力头的破坏是非线性的。3.2 蒸馏让小模型继承大模型的能力如果目标设备实在跑不动 7B那就得考虑蒸馏。蒸馏的思路是让一个大模型教师去指导一个小模型学生训练把小模型的能力拉到接近大模型的水平。端侧常见的蒸馏产物是 1B 到 3B 的模型比如各种 Tiny 系列、Mini 系列。蒸馏的关键在于数据质量而不是数量。我做过一个项目用 5 万条高质量领域数据蒸馏出来的 1.5B 模型在特定任务上超过了通用 7B 模型。原因是通用大模型在垂直领域的知识密度低而蒸馏数据把领域知识压缩进了小模型。所以如果你有明确的垂直场景蒸馏的性价比远高于硬塞大模型。蒸馏的坑在于学生模型的能力上限受教师模型和数据结构限制。如果教师模型本身在某个任务上就弱蒸馏也救不了。另外蒸馏后的模型泛化能力会下降遇到训练分布外的输入容易崩所以要做好兜底策略。3.3 剪枝和 MoE 是进阶手段剪枝是去掉模型里不重要的权重或结构比如把某些注意力头或 FFN 神经元删掉。结构化剪枝能真正减少计算量非结构化剪枝主要省内存但计算量不减。剪枝的难点在于找到不重要的部分通常需要基于校准数据做重要性评估。MoE混合专家是另一条路让模型在推理时只激活部分参数。端侧 MoE 的好处是总参数量可以很大但激活量小比如总 8B 但每次只激活 2B。缺点是内存还是要装下全部参数所以对内存容量要求高对带宽要求相对低。目前端侧 MoE 的落地案例还不多主要在实验阶段。4. 推理引擎选型llama.cpp、MLC、ONNX Runtime 怎么选4.1 推理引擎决定了端侧体验的下限模型量化好了还得有引擎把它跑起来。端侧推理引擎的选择直接决定了你能支持哪些硬件、吞吐多少、内存占用多少。目前主流的几个选项各有侧重我按实际项目经验做个对比。引擎优势劣势适用场景llama.cpp生态成熟GGUF 格式通用CPU 推理强GPU 加速相对弱多模态支持一般PC、边缘盒子、CPU 为主的设备MLC LLM编译优化好跨平台GPU 支持强部署链路长模型转换麻烦手机、GPU 边缘设备ONNX Runtime微软生态算子覆盖广量化工具全大模型支持不如前两者专注Windows PC、工控设备TensorRT-LLMNVIDIA GPU 性能极致只支持 NVIDIA绑定深带独显的 PC、边缘服务器厂商自研 SDK针对自家 NPU 优化生态封闭迁移成本高特定芯片的定制设备选型的核心逻辑是先看硬件再看生态最后看性能。如果目标设备是 NVIDIA GPUTensorRT-LLM 是首选如果是手机MLC 或厂商 SDK 更合适如果是通用 PC 且要快速验证llama.cpp 最省事。4.2 llama.cpp 为什么是端侧验证的首选llama.cpp 我用了很久它的最大价值是降低验证门槛。你拿到一个 GGUF 格式的模型几行命令就能跑起来不需要复杂的编译和转换。对于端侧项目的前期验证阶段这个效率优势非常关键。它的另一个优势是 CPU 推理优化做得好用了 AVX2、AVX512 等指令集加速在没有独立显卡的设备上也能跑出可用速度。我实测过在一台 16GB 内存的轻薄本上跑 7B INT4 模型吞吐能到每秒 8 到 12 token做文本摘要、分类、简单对话完全够用。但 llama.cpp 的短板也明显GPU 加速不如 TensorRT 和 MLC多模态支持较弱长上下文的内存管理不够精细。所以它适合验证和小规模部署大规模生产环境要慎重。4.3 MLC 和 ONNX Runtime 的适用边界MLC LLM 的思路是把模型编译成目标平台的机器码从而获得更好的性能。它在手机端的表现确实比 llama.cpp 好尤其是 GPU 加速场景。但它的部署链路比较长需要先把模型转成 MLC 格式再编译再打包中间任何一步出错都要重来。所以 MLC 适合有专门工程团队、追求极致性能的项目。ONNX Runtime 的优势是生态和工具链。如果你的项目已经在用 ONNX 做模型部署那接入大模型推理会比较顺。它的量化工具比较完善支持动态量化和静态量化。但在大模型场景下ONNX Runtime 的优化不如专门的大模型引擎长上下文和 KV Cache 管理相对粗糙。5. 端侧大模型如何撑起超自动化与 AI Agent5.1 超自动化需要的是低延迟决策闭环超自动化的核心是把重复性业务流程自动化传统 RPA 靠规则和脚本遇到非结构化输入就歇菜。大模型加进来之后超自动化能处理文档理解、意图识别、异常判断这些原来做不了的环节。但这里有个关键约束自动化流程对延迟极其敏感。举个例子一个财务报销自动化流程每天要处理几千张发票。如果每张发票都要调云端大模型做 OCR 后的语义校验网络往返加排队单张处理时间可能到 2 到 3 秒一天下来就是好几个小时的额外延迟。而如果把一个 3B 的量化模型部署在本地边缘服务器上单张处理压到 200 毫秒以内整个流程的吞吐能提升一个数量级。这就是端侧大模型对超自动化的核心价值把 AI 决策嵌入到流程的每一个环节而不是作为一个外部服务去调用。决策闭环越短自动化的可靠性和效率越高。5.2 AI Agent 在端侧怎么扛并发AI Agent 是超自动化的进阶形态它不只是执行固定流程而是能自主规划、调用工具、根据反馈调整。端侧 Agent 的挑战在于并发。一个 Agent 可能同时要处理多个任务每个任务都要调模型推理如果模型推理是串行的并发能力就上不去。我的做法是分层处理。第一层是意图识别和路由用最小的模型比如 0.5B 到 1B做快速分类决定任务走哪条路径。第二层是具体任务执行用中等模型3B 到 7B做推理。第三层是复杂决策如果端侧模型搞不定再降级到云端。这样大部分请求在端侧就能闭环只有少数复杂请求才走云端并发压力大幅降低。另一个技巧是批处理推理。端侧推理引擎如果支持 batch可以把多个 Agent 的请求攒一批一起推理吞吐能提升 2 到 3 倍。代价是单请求延迟略微增加但对于非实时任务完全可以接受。5.3 Agent 框架在端侧的适配问题现在主流的 Agent 框架比如 LangChain、LangGraph、Spring AI大多是按云端 API 调用的模式设计的。搬到端侧会遇到几个问题一是框架本身的内存占用Python 运行时加依赖动辄几百 MB在内存紧张的设备上很奢侈二是框架的抽象层增加了延迟每次工具调用都要走一层封装三是很多框架默认同步阻塞不适合端侧的异步事件驱动模型。我的建议是端侧 Agent 不要直接套用云端框架而是做裁剪。保留核心的规划、工具调用、记忆管理逻辑去掉不必要的抽象层。如果一定要用框架优先选轻量级的或者用 Rust、Go 这类低开销语言重写关键路径。我见过用 FastAPI 加 LangGraph 做端侧 Agent 的方案在边缘服务器上跑没问题但往更小的设备上迁就很吃力。6. AR 眼镜场景端侧大模型最苛刻的试验场6.1 光波导 AR 眼镜的算力预算有多紧AR 眼镜是端侧大模型最极端的场景。以光波导方案的 AR 眼镜为例整机重量要控制在 80 克以内电池容量可能只有 1000 到 1500 毫安时整机功耗预算 2 到 3 瓦。分给计算芯片的功耗可能只有 1 瓦左右算力也就几 TOPS。在这种约束下跑 7B 模型是不可能的甚至 3B 都吃力。现实的做法是端云协同眼镜端跑一个 0.5B 到 1B 的小模型负责唤醒词识别、简单意图判断、本地缓存检索复杂推理走云端或配对的手机。这样既保证了响应速度又控制了功耗。6.2 端云协同的切分点怎么定端云协同的关键是找到合适的切分点。切得太靠端端侧算力不够切得太靠云延迟和隐私问题又回来了。我的经验是按延迟敏感度和隐私敏感度两个维度来切。延迟敏感且隐私敏感的任务比如实时翻译、人脸识别、本地文档检索必须放端侧。延迟不敏感但隐私敏感的任务比如个人健康数据分析可以端侧做预处理脱敏后再上云。延迟敏感但不涉及隐私的任务比如天气查询、路线规划可以走云端但要做好缓存。延迟和隐私都不敏感的任务比如模型更新、日志分析完全放云端。6.3 AR 交互对模型输出的特殊要求AR 眼镜的交互和手机、PC 完全不同。用户看的是叠加在现实世界上的信息注意力时间极短所以模型输出必须极度精简。一段 200 字的回答在手机上还能接受在 AR 眼镜上就是灾难。端侧模型需要做输出压缩把长文本压成短句、关键词、结构化卡片。这对模型微调提出了要求。通用的指令微调模型输出往往偏长需要针对 AR 场景做专门的微调训练模型输出简短、结构化、可直接渲染的内容。我做过一个实验用 2000 条 AR 场景的对话数据微调一个 1B 模型输出长度平均缩短了 60%而关键信息保留率在 90% 以上。7. 微调与提示词工程在端侧的差异化打法7.1 端侧微调的目标和云端不一样云端微调追求的是能力上限端侧微调追求的是在有限参数下把特定任务做到极致。这个目标差异决定了微调策略的不同。端侧微调更倾向于用 LoRA 这类低秩适配方法因为全量微调对端侧设备来说成本太高而且容易过拟合。LoRA 的好处是只训练一小部分参数显存占用低训练快而且可以多个 LoRA 适配器切换一个基座模型服务多个任务。在端侧场景我通常会用 4 到 8 的秩学习率设在 1e-4 到 3e-4 之间训练数据量控制在几千到几万条。数据质量比数量重要得多1000 条精标数据往往比 10000 条噪声数据效果好。7.2 提示词工程在端侧要更抠端侧的上下文窗口通常比云端小KV Cache 也占内存所以提示词不能像云端那样随便堆。我的原则是能省则省能结构化就结构化。系统提示词压缩到最短few-shot 示例控制在 2 到 3 个能用模板就不用自然语言描述。另外端侧模型的指令遵循能力通常弱于大模型所以提示词要更明确、更机械。比如不要写请根据用户输入判断意图而要写输出以下标签之一查询、下单、取消、其他。这种硬约束能显著提升小模型的稳定性。7.3 上下文工程在端侧的取舍上下文工程是最近很热的话题核心是如何管理模型的上下文窗口。端侧场景下上下文窗口小管理策略要更激进。我的做法是短期记忆用滑动窗口只保留最近几轮对话长期记忆用向量检索把关键信息存到本地向量库需要时检索注入工具调用结果做摘要压缩不要把原始返回全塞进上下文。这些策略在云端也适用但端侧的窗口更小所以压缩比要更高。我一般会把上下文占用控制在窗口的 60% 以内留出空间给模型输出和突发输入。8. 落地过程中踩过的坑和验证方法8.1 量化后精度崩塌的排查链路我遇到过一次典型的量化翻车一个 7B 模型 INT4 量化后通用对话看起来正常但在结构化输出任务上完全乱套JSON 格式频繁出错。排查过程是这样的先确认不是提示词问题换回 FP16 模型同样的提示词输出正常然后怀疑是量化精度问题换成 INT8 后问题消失确认是 INT4 的锅接着定位到具体层发现是输出层的量化误差累积导致 logits 分布偏移最后用混合精度量化输出层保持 INT8其他层 INT4问题解决。这个案例的教训是量化不是一刀切关键层要保留更高精度。输出层、注意力输出投影层、LayerNorm 层通常对精度更敏感值得单独处理。8.2 端侧推理的内存泄漏另一个坑是内存泄漏。端侧设备内存本来就紧张泄漏几百 MB 就可能导致 OOM。我遇到过一次Agent 长时间运行后内存持续增长最后崩溃。排查发现是 KV Cache 没有正确释放每次新对话都新建缓存但旧的没清。修复方法是显式管理缓存生命周期对话结束后主动释放。这类问题的验证方法是做长稳测试让 Agent 连续跑几个小时监控内存曲线。如果曲线持续上升基本就是泄漏。端侧部署一定要做长稳测试不能只测短时性能。8.3 端云切换的一致性验证端云协同场景下端侧和云端的模型输出可能不一致导致用户体验割裂。比如同一个问题端侧模型回答简短云端模型回答详细用户会困惑。解决办法是做输出格式对齐让端侧和云端模型都遵循同一套输出模板差异只在内容深度上。验证方法是构造一批测试用例分别用端侧和云端模型跑对比输出格式和关键信息。如果格式不一致率超过 5%就要调整提示词或微调数据。9. 我对端侧大模型落地节奏的个人判断做了几个端侧项目之后我最大的体会是端侧大模型不是把云端模型搬下来而是重新设计一套适配端侧约束的方案。硬件算力、内存带宽、功耗散热、上下文窗口每一个约束都会倒逼你做取舍。这些取舍没有标准答案只有适合具体场景的答案。如果你正准备启动端侧项目我的建议是先做最小验证选一个目标设备用 llama.cpp 跑一个量化模型测出真实的吞吐和延迟再决定要不要继续。很多项目死在想当然上以为设备能跑实际一测差得远。先验证再投入这个顺序不能反。另外端侧和云端不是对立的端云协同才是长期形态。端侧负责低延迟、隐私敏感、离线可用的部分云端负责复杂推理、知识更新、大规模并发的部分。把两者的边界划清楚比纠结要不要上端侧更有价值。 
长河君 · 2026/10/2 10:55:33 · 阅读 1.2k 端侧大模型部署实战：硬件选型、量化与推理引擎全解析
1. 端侧大模型落地为什么现在成了一个真问题过去两年大模型的主战场一直在云端。参数越堆越大集群越铺越广推理成本按 token 计费谁家的模型更聪明谁就能拿到融资和订单。但到了 2025 年下半年一个明显的变化出现了越来越多的团队开始把注意力从模型能不能更强转向模型能不能更近。这个近指的就是端侧。端侧部署大模型说白了就是把模型跑在离用户最近的设备上——手机、PC、AR 眼镜、车机、工控盒子、边缘服务器。它解决的不是模型能力上限的问题而是响应延迟、数据隐私、离线可用、带宽成本这四个工程层面的硬约束。你在云端调一次 API往返几百毫秒起步遇到网络抖动直接超时而端侧推理可以把首 token 延迟压到几十毫秒且完全不依赖网络。对于超自动化场景——比如 RPA 流程编排、AI Agent 自主决策、AR 实时交互——这几十毫秒的差距往往就是能用和不能用的分界线。这篇文章面向的是正在做或准备做端侧大模型落地的工程师、架构师和产品负责人。我会把端侧部署的硬件选型逻辑、模型压缩与量化路径、推理引擎的取舍、以及它和超自动化、AI Agent、AR 眼镜这些场景怎么咬合一层层拆开讲。关键词覆盖大模型、端侧部署、超自动化、AI Agent、AR、大模型微调、端侧 AI 硬件部署、光波导 AR 眼镜、大模型量化、推理引擎。读完你应该能判断自己的项目到底该不该上端侧以及如果上第一步该踩在哪里。2. 端侧部署的硬件账本算力、内存、功耗的三方博弈2.1 先搞清楚端侧设备的算力天花板在哪端侧部署的第一个现实问题是你的目标设备到底有多少算力。这不是一个可以含糊的问题因为它直接决定了你能跑多大的模型、用什么量化精度、能接受多高的延迟。目前主流的端侧算力载体大致分四档。第一档是手机 SoC 里的 NPU比如高通骁龙 8 Gen 系列、联发科天玑系列NPU 算力在 30 到 70 TOPS 之间但实际可用算力受内存带宽限制跑 7B 模型量化版勉强能到每秒 10 到 20 token。第二档是 PC 端的独立显卡和核显RTX 4060 这类 8GB 显存的卡跑 7B INT4 模型可以到每秒 40 token 以上体验已经接近可用。第三档是专用边缘推理盒子比如搭载昇腾、寒武纪或高通 Cloud AI 芯片的设备算力从几十到上百 TOPS适合固定场景的批量推理。第四档是 AR 眼镜、手表这类超低功耗设备算力往往只有几 TOPS只能跑 1B 以下的小模型或者做端云协同。这里有个容易被忽略的点标称 TOPS 和实际推理吞吐之间差着一条内存带宽的鸿沟。大模型推理是典型的 memory-bound 任务每生成一个 token 都要把模型权重从内存里读一遍。所以你看设备参数时除了看 NPU 算力更要看内存带宽和内存容量。一个 7B 模型 INT4 量化后大约占 3.5 到 4GB 内存加上 KV Cache 和运行时开销8GB 内存是底线。如果设备只有 6GB 内存那基本只能考虑 3B 以下的模型。2.2 内存带宽才是真正的瓶颈我用一个生活化的类比来解释这件事。大模型推理就像是一个厨师做菜NPU 是厨师的刀工速度内存带宽是食材从仓库送到灶台的传送带速度。刀工再快传送带慢厨师也只能干等着。每生成一个 token都要把整个模型的权重过一遍7B 模型 INT4 大约 3.5GB如果内存带宽是 50GB/s那理论上每秒最多读 14 次权重也就是每秒 14 个 token 的上限。这就是为什么很多设备标称算力很高实际跑起来却很慢。所以在做端侧选型时我通常会先算一笔账目标模型大小除以设备内存带宽得到理论 token 上限再乘以 0.6 到 0.7 的效率系数就是实际能期待的吞吐。这个估算方法在多个项目里验证过误差基本在 20% 以内。2.3 功耗和散热决定了能不能持续跑端侧设备还有一个云端不存在的问题功耗墙和散热墙。手机跑大模型几分钟后就会因为发热降频吞吐直接腰斩。AR 眼镜更极端整机功耗预算可能只有 2 到 3 瓦NPU 能分到的可能不到 1 瓦。这意味着端侧部署不能只看峰值性能要看持续性能。我的经验是对于需要长时间运行的超自动化场景比如 Agent 持续监听事件并决策必须把模型的持续功耗控制在设备散热能力的 60% 以内。具体做法包括用动态量化降低计算量、用投机采样减少大模型调用次数、把非关键推理降级到小模型。这些手段后面会展开讲。3. 模型怎么塞进端侧量化、蒸馏与剪枝的实战取舍3.1 量化是端侧落地的第一道门槛把大模型塞进端侧量化几乎是无条件要做的第一步。量化的本质是用更低的数值精度表示模型权重和激活值从而减少内存占用和计算量。常见的精度从高到低有 FP16、INT8、INT4甚至 INT2。FP16 基本不用考虑7B 模型要 14GB 内存端侧设备扛不住。INT8 能把内存砍半到 7GB还是偏大。INT4 是目前的甜点7B 模型压到 3.5 到 4GB精度损失在可接受范围内大多数任务的表现下降不到 5%。INT2 虽然更小但精度崩塌明显除非是极低功耗场景且任务简单否则不建议。量化不是简单地把数值截断主流的做法有 GPTQ、AWQ、GGUF 这几类。GPTQ 是逐层量化加校准适合 GPU 推理AWQ 是激活感知的权重量化对精度保护更好GGUF 是 llama.cpp 生态的格式适合 CPU 和混合推理。选哪个取决于你的推理引擎后面会讲。提示量化后的模型一定要做任务级验证不能只看困惑度指标。我见过困惑度只涨了 0.1 但结构化输出全乱的案例因为量化对某些注意力头的破坏是非线性的。3.2 蒸馏让小模型继承大模型的能力如果目标设备实在跑不动 7B那就得考虑蒸馏。蒸馏的思路是让一个大模型教师去指导一个小模型学生训练把小模型的能力拉到接近大模型的水平。端侧常见的蒸馏产物是 1B 到 3B 的模型比如各种 Tiny 系列、Mini 系列。蒸馏的关键在于数据质量而不是数量。我做过一个项目用 5 万条高质量领域数据蒸馏出来的 1.5B 模型在特定任务上超过了通用 7B 模型。原因是通用大模型在垂直领域的知识密度低而蒸馏数据把领域知识压缩进了小模型。所以如果你有明确的垂直场景蒸馏的性价比远高于硬塞大模型。蒸馏的坑在于学生模型的能力上限受教师模型和数据结构限制。如果教师模型本身在某个任务上就弱蒸馏也救不了。另外蒸馏后的模型泛化能力会下降遇到训练分布外的输入容易崩所以要做好兜底策略。3.3 剪枝和 MoE 是进阶手段剪枝是去掉模型里不重要的权重或结构比如把某些注意力头或 FFN 神经元删掉。结构化剪枝能真正减少计算量非结构化剪枝主要省内存但计算量不减。剪枝的难点在于找到不重要的部分通常需要基于校准数据做重要性评估。MoE混合专家是另一条路让模型在推理时只激活部分参数。端侧 MoE 的好处是总参数量可以很大但激活量小比如总 8B 但每次只激活 2B。缺点是内存还是要装下全部参数所以对内存容量要求高对带宽要求相对低。目前端侧 MoE 的落地案例还不多主要在实验阶段。4. 推理引擎选型llama.cpp、MLC、ONNX Runtime 怎么选4.1 推理引擎决定了端侧体验的下限模型量化好了还得有引擎把它跑起来。端侧推理引擎的选择直接决定了你能支持哪些硬件、吞吐多少、内存占用多少。目前主流的几个选项各有侧重我按实际项目经验做个对比。引擎优势劣势适用场景llama.cpp生态成熟GGUF 格式通用CPU 推理强GPU 加速相对弱多模态支持一般PC、边缘盒子、CPU 为主的设备MLC LLM编译优化好跨平台GPU 支持强部署链路长模型转换麻烦手机、GPU 边缘设备ONNX Runtime微软生态算子覆盖广量化工具全大模型支持不如前两者专注Windows PC、工控设备TensorRT-LLMNVIDIA GPU 性能极致只支持 NVIDIA绑定深带独显的 PC、边缘服务器厂商自研 SDK针对自家 NPU 优化生态封闭迁移成本高特定芯片的定制设备选型的核心逻辑是先看硬件再看生态最后看性能。如果目标设备是 NVIDIA GPUTensorRT-LLM 是首选如果是手机MLC 或厂商 SDK 更合适如果是通用 PC 且要快速验证llama.cpp 最省事。4.2 llama.cpp 为什么是端侧验证的首选llama.cpp 我用了很久它的最大价值是降低验证门槛。你拿到一个 GGUF 格式的模型几行命令就能跑起来不需要复杂的编译和转换。对于端侧项目的前期验证阶段这个效率优势非常关键。它的另一个优势是 CPU 推理优化做得好用了 AVX2、AVX512 等指令集加速在没有独立显卡的设备上也能跑出可用速度。我实测过在一台 16GB 内存的轻薄本上跑 7B INT4 模型吞吐能到每秒 8 到 12 token做文本摘要、分类、简单对话完全够用。但 llama.cpp 的短板也明显GPU 加速不如 TensorRT 和 MLC多模态支持较弱长上下文的内存管理不够精细。所以它适合验证和小规模部署大规模生产环境要慎重。4.3 MLC 和 ONNX Runtime 的适用边界MLC LLM 的思路是把模型编译成目标平台的机器码从而获得更好的性能。它在手机端的表现确实比 llama.cpp 好尤其是 GPU 加速场景。但它的部署链路比较长需要先把模型转成 MLC 格式再编译再打包中间任何一步出错都要重来。所以 MLC 适合有专门工程团队、追求极致性能的项目。ONNX Runtime 的优势是生态和工具链。如果你的项目已经在用 ONNX 做模型部署那接入大模型推理会比较顺。它的量化工具比较完善支持动态量化和静态量化。但在大模型场景下ONNX Runtime 的优化不如专门的大模型引擎长上下文和 KV Cache 管理相对粗糙。5. 端侧大模型如何撑起超自动化与 AI Agent5.1 超自动化需要的是低延迟决策闭环超自动化的核心是把重复性业务流程自动化传统 RPA 靠规则和脚本遇到非结构化输入就歇菜。大模型加进来之后超自动化能处理文档理解、意图识别、异常判断这些原来做不了的环节。但这里有个关键约束自动化流程对延迟极其敏感。举个例子一个财务报销自动化流程每天要处理几千张发票。如果每张发票都要调云端大模型做 OCR 后的语义校验网络往返加排队单张处理时间可能到 2 到 3 秒一天下来就是好几个小时的额外延迟。而如果把一个 3B 的量化模型部署在本地边缘服务器上单张处理压到 200 毫秒以内整个流程的吞吐能提升一个数量级。这就是端侧大模型对超自动化的核心价值把 AI 决策嵌入到流程的每一个环节而不是作为一个外部服务去调用。决策闭环越短自动化的可靠性和效率越高。5.2 AI Agent 在端侧怎么扛并发AI Agent 是超自动化的进阶形态它不只是执行固定流程而是能自主规划、调用工具、根据反馈调整。端侧 Agent 的挑战在于并发。一个 Agent 可能同时要处理多个任务每个任务都要调模型推理如果模型推理是串行的并发能力就上不去。我的做法是分层处理。第一层是意图识别和路由用最小的模型比如 0.5B 到 1B做快速分类决定任务走哪条路径。第二层是具体任务执行用中等模型3B 到 7B做推理。第三层是复杂决策如果端侧模型搞不定再降级到云端。这样大部分请求在端侧就能闭环只有少数复杂请求才走云端并发压力大幅降低。另一个技巧是批处理推理。端侧推理引擎如果支持 batch可以把多个 Agent 的请求攒一批一起推理吞吐能提升 2 到 3 倍。代价是单请求延迟略微增加但对于非实时任务完全可以接受。5.3 Agent 框架在端侧的适配问题现在主流的 Agent 框架比如 LangChain、LangGraph、Spring AI大多是按云端 API 调用的模式设计的。搬到端侧会遇到几个问题一是框架本身的内存占用Python 运行时加依赖动辄几百 MB在内存紧张的设备上很奢侈二是框架的抽象层增加了延迟每次工具调用都要走一层封装三是很多框架默认同步阻塞不适合端侧的异步事件驱动模型。我的建议是端侧 Agent 不要直接套用云端框架而是做裁剪。保留核心的规划、工具调用、记忆管理逻辑去掉不必要的抽象层。如果一定要用框架优先选轻量级的或者用 Rust、Go 这类低开销语言重写关键路径。我见过用 FastAPI 加 LangGraph 做端侧 Agent 的方案在边缘服务器上跑没问题但往更小的设备上迁就很吃力。6. AR 眼镜场景端侧大模型最苛刻的试验场6.1 光波导 AR 眼镜的算力预算有多紧AR 眼镜是端侧大模型最极端的场景。以光波导方案的 AR 眼镜为例整机重量要控制在 80 克以内电池容量可能只有 1000 到 1500 毫安时整机功耗预算 2 到 3 瓦。分给计算芯片的功耗可能只有 1 瓦左右算力也就几 TOPS。在这种约束下跑 7B 模型是不可能的甚至 3B 都吃力。现实的做法是端云协同眼镜端跑一个 0.5B 到 1B 的小模型负责唤醒词识别、简单意图判断、本地缓存检索复杂推理走云端或配对的手机。这样既保证了响应速度又控制了功耗。6.2 端云协同的切分点怎么定端云协同的关键是找到合适的切分点。切得太靠端端侧算力不够切得太靠云延迟和隐私问题又回来了。我的经验是按延迟敏感度和隐私敏感度两个维度来切。延迟敏感且隐私敏感的任务比如实时翻译、人脸识别、本地文档检索必须放端侧。延迟不敏感但隐私敏感的任务比如个人健康数据分析可以端侧做预处理脱敏后再上云。延迟敏感但不涉及隐私的任务比如天气查询、路线规划可以走云端但要做好缓存。延迟和隐私都不敏感的任务比如模型更新、日志分析完全放云端。6.3 AR 交互对模型输出的特殊要求AR 眼镜的交互和手机、PC 完全不同。用户看的是叠加在现实世界上的信息注意力时间极短所以模型输出必须极度精简。一段 200 字的回答在手机上还能接受在 AR 眼镜上就是灾难。端侧模型需要做输出压缩把长文本压成短句、关键词、结构化卡片。这对模型微调提出了要求。通用的指令微调模型输出往往偏长需要针对 AR 场景做专门的微调训练模型输出简短、结构化、可直接渲染的内容。我做过一个实验用 2000 条 AR 场景的对话数据微调一个 1B 模型输出长度平均缩短了 60%而关键信息保留率在 90% 以上。7. 微调与提示词工程在端侧的差异化打法7.1 端侧微调的目标和云端不一样云端微调追求的是能力上限端侧微调追求的是在有限参数下把特定任务做到极致。这个目标差异决定了微调策略的不同。端侧微调更倾向于用 LoRA 这类低秩适配方法因为全量微调对端侧设备来说成本太高而且容易过拟合。LoRA 的好处是只训练一小部分参数显存占用低训练快而且可以多个 LoRA 适配器切换一个基座模型服务多个任务。在端侧场景我通常会用 4 到 8 的秩学习率设在 1e-4 到 3e-4 之间训练数据量控制在几千到几万条。数据质量比数量重要得多1000 条精标数据往往比 10000 条噪声数据效果好。7.2 提示词工程在端侧要更抠端侧的上下文窗口通常比云端小KV Cache 也占内存所以提示词不能像云端那样随便堆。我的原则是能省则省能结构化就结构化。系统提示词压缩到最短few-shot 示例控制在 2 到 3 个能用模板就不用自然语言描述。另外端侧模型的指令遵循能力通常弱于大模型所以提示词要更明确、更机械。比如不要写请根据用户输入判断意图而要写输出以下标签之一查询、下单、取消、其他。这种硬约束能显著提升小模型的稳定性。7.3 上下文工程在端侧的取舍上下文工程是最近很热的话题核心是如何管理模型的上下文窗口。端侧场景下上下文窗口小管理策略要更激进。我的做法是短期记忆用滑动窗口只保留最近几轮对话长期记忆用向量检索把关键信息存到本地向量库需要时检索注入工具调用结果做摘要压缩不要把原始返回全塞进上下文。这些策略在云端也适用但端侧的窗口更小所以压缩比要更高。我一般会把上下文占用控制在窗口的 60% 以内留出空间给模型输出和突发输入。8. 落地过程中踩过的坑和验证方法8.1 量化后精度崩塌的排查链路我遇到过一次典型的量化翻车一个 7B 模型 INT4 量化后通用对话看起来正常但在结构化输出任务上完全乱套JSON 格式频繁出错。排查过程是这样的先确认不是提示词问题换回 FP16 模型同样的提示词输出正常然后怀疑是量化精度问题换成 INT8 后问题消失确认是 INT4 的锅接着定位到具体层发现是输出层的量化误差累积导致 logits 分布偏移最后用混合精度量化输出层保持 INT8其他层 INT4问题解决。这个案例的教训是量化不是一刀切关键层要保留更高精度。输出层、注意力输出投影层、LayerNorm 层通常对精度更敏感值得单独处理。8.2 端侧推理的内存泄漏另一个坑是内存泄漏。端侧设备内存本来就紧张泄漏几百 MB 就可能导致 OOM。我遇到过一次Agent 长时间运行后内存持续增长最后崩溃。排查发现是 KV Cache 没有正确释放每次新对话都新建缓存但旧的没清。修复方法是显式管理缓存生命周期对话结束后主动释放。这类问题的验证方法是做长稳测试让 Agent 连续跑几个小时监控内存曲线。如果曲线持续上升基本就是泄漏。端侧部署一定要做长稳测试不能只测短时性能。8.3 端云切换的一致性验证端云协同场景下端侧和云端的模型输出可能不一致导致用户体验割裂。比如同一个问题端侧模型回答简短云端模型回答详细用户会困惑。解决办法是做输出格式对齐让端侧和云端模型都遵循同一套输出模板差异只在内容深度上。验证方法是构造一批测试用例分别用端侧和云端模型跑对比输出格式和关键信息。如果格式不一致率超过 5%就要调整提示词或微调数据。9. 我对端侧大模型落地节奏的个人判断做了几个端侧项目之后我最大的体会是端侧大模型不是把云端模型搬下来而是重新设计一套适配端侧约束的方案。硬件算力、内存带宽、功耗散热、上下文窗口每一个约束都会倒逼你做取舍。这些取舍没有标准答案只有适合具体场景的答案。如果你正准备启动端侧项目我的建议是先做最小验证选一个目标设备用 llama.cpp 跑一个量化模型测出真实的吞吐和延迟再决定要不要继续。很多项目死在想当然上以为设备能跑实际一测差得远。先验证再投入这个顺序不能反。另外端侧和云端不是对立的端云协同才是长期形态。端侧负责低延迟、隐私敏感、离线可用的部分云端负责复杂推理、知识更新、大规模并发的部分。把两者的边界划清楚比纠结要不要上端侧更有价值。