版权与内容来源声明本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容均在附表 A 中标注来源引用官方原文保持原样不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式也不对任何收益结果作承诺。转载请注明出处。第 1 章 端侧部署的第一步把「能不能跑」变成一道账端侧部署指的是把模型直接放在开发板、手机或边缘盒子上推理而不是调用云端接口。对嵌入式工程师来说这件事的开场白不该是「先下个模型跑跑看」而是先摊开一张资源表——就像选芯片前先看 RAM、Flash 和主频一样。1.1 嵌入式人的老习惯正好用得上嵌入式项目里方案评审的第一张纸通常是资源预算代码段多少、堆栈留多少、要不要外挂 DDR。转到大模型这张纸的栏目名换了一下思路几乎原样搬过来原来的「代码段 常量表」对应模型权重原来的「堆」对应推理时的缓存原来的「系统占用」对应运行时和操作系统。这个迁移不需要你先补算法课它需要的是你早就有的那种「先算再动手」的纪律。1.2 「能跑」和「跑得合适」是两道题把模型丢到板子上跑不动再换一个更小的——这条路能出结果但它跳过了算账。跳过的代价是你不知道离「刚好放得下」还有多远也不知道该压哪一头。正确的顺序是四步先算权重占用 → 再留出 KV Cache 和运行时 → 再决定量化到几比特 → 最后才上板验证。这里的量化把权重从高精度用更少的位数来存和 KV Cache推理时缓存历史、避免重复计算先记住名字后面逐一展开。下面这张表先把端侧大模型的四个内存分块与嵌入式熟悉的资源项对上号。传统嵌入式的资源项端侧大模型的对应项什么时候会增长代码段 / 常量表模型权重换成更大的模型时堆KV Cache、临时张量上下文变长、并发变多时线程栈推理线程栈一般较小可先忽略系统占用运行时 操作系统与框架和日志级别有关记住一句话板子标称的内存不等于能跑的内存。第 2 章 权重要占多少一个能背下来的粗算公式这一章只解决一个问题给定参数量它的权重至少要占多少内存。答案是乘一下就能得出来。2.1 公式与每参数字节数粗算公式就一行权重占用GB≈ 参数量 × 每个参数占的字节数 ÷ 10^9其中「每个参数占的字节数」由存储格式决定。同一份参数量格式不同占用成比例变化这张表建议直接背下来。存储格式每个参数的字节数7B 参数模型的权重粗算FP3232 位浮点4约 28 GB16 位浮点BF16 等2约 14 GB8 比特整数量化1约 7 GB4 比特量化0.5约 3.5 GB2 比特量化0.25约 1.75 GB需要提醒的是这是纯权重的下界。真实的量化文件还要额外存放缩放系数等少量元数据占用通常会比算出来的高几个百分点。2.2 举几个具体的例子把公式套进常见规模7B 参数16 位浮点约 14 GB4 比特量化约 3.5 GB1B 参数16 位浮点约 2 GB4 比特量化约 0.5 GB0.5B 参数16 位浮点约 1 GB4 比特量化约 0.25 GB。一眼能看出的结论量化到 4 比特权重占用大致降到 16 位浮点的四分之一。这正是端侧能跑起来的关键。下面这个小脚本可以把参数量和字节数的换算固化下来换模型时改一个数字就行。⚠️代码待验证defweight_gb(params_billion,bytes_per_param):# 参数量以「亿」为单位输入total_bytesparams_billion*1e9*bytes_per_paramreturntotal_bytes/1e9# 换算回 GB十进制print(round(weight_gb(7,2),1))# 7B 参数、16 位浮点 → 约 14 GBprint(round(weight_gb(7,1),1))# 8 比特整数量化 → 约 7 GBprint(round(weight_gb(7,0.5),1))# 4 比特量化 → 约 3.5 GB2.3 这只是权重账还没算完很多人算到这里就停手了然后上板发现还是不够。原因很简单权重之外推理过程还要额外占用三块——运行时与框架本身、KV Cache、以及系统与安全余量。这三块的合计有时能和 4 比特权重本身相当。第 4 章会把它们摆到同一张预算表里。第 3 章 量化档位用占用换质量账要算明白量化是端侧部署绕不开的一步但它不是免费的。它省下的是内存和带宽付出的是与原始模型之间的差距。这一章讲清楚常见档位各是什么代价以及什么时候会明显掉质量。3.1 量化到底做了什么人话解释量化就是不再用高精度比如 32 位浮点去存每一个权重而是用更少的位数来存常见的是降到 8 比特或 4 比特的整数。位宽越低占用越小、内存带宽压力越小但与原始权重之间的误差也越大。这里有一个本地推理里绕不开的名字GGUF。它是 llama.cpp 使用的模型文件格式量化后的权重就按这个格式打包下载时所谓的「量化版本」通常就是一个 GGUF 文件。llama.cpp 官方 README 在描述自身能力时写明它支持「1.5-bit、2-bit、3-bit、4-bit、5-bit、6-bit 和 8-bit 整数量化用于更快的推理与更低的内存占用」——也就是说量化档位本质上就是「每个权重用几位来表示」的不同选择。3.2 常见档位的代价对照不同档位不是简单的「越低越好」而是「低到某个点之后质量问题开始盖过省下的空间」。下表把三档的代价摆在一起质量风险一列为经验性归纳不是普适保证。量化档位中文表述相对 16 位浮点的占用质量风险经验性典型用途8 比特整数量化约二分之一很小内存够用想少折腾4 比特量化约四分之一中等与方法和模型相关端侧采用较多的选择3 比特及更低更低明显上升极限压缩场景Hugging Face 官方 Transformers 量化文档截至 2026-10-07给出的总体结论与此一致8 比特方法内存约省一半准确率「非常接近」未量化的基线4 比特方法内存约省四分之三准确率「相对较高」低于 4 比特属于「明显下降」区间其中 2 比特尤其明显。3.3 什么时候会明显掉质量以及怎么验证先说「什么时候」。有三类信号值得警惕第一位宽压到 3 比特及以下时掉的往往不是闲聊能力而是需要精确性的任务——代码、数学、结构化输出比如必须输出固定格式的 JSON会先出问题。第二不是所有权重都同等重要。AWQ 论文《AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration》arXiv:2306.00978指出大模型里并非所有权重都一样关键只保护约 1% 的显著权重就能大幅降低量化误差而且判断哪些通道显著要看激活的分布而不是看权重本身的大小。这意味着「同一个比特数不同量化方法的结果可能差很多」。第三量化方法本身有区别。GPTQ 论文《GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers》arXiv:2210.17323采用逐层的、基于近似二阶信息的一次性权重量化其摘要称可把位宽降到每个权重 3 或 4 比特相对未压缩基线的精度下降可忽略。再说「怎么验证」——不要凭感觉。可执行的做法是固定评测用例做前后对比先挑 20~50 条覆盖你真实任务的用例用原模型和量化模型各跑一遍逐条比对结果而不是只跑一两个问题就下结论。⚠️代码待验证cases[用例1,用例2,用例3]# 前后对比骨架示例建议 20~50 条并覆盖代码/数学/结构化输出defrun(model_name,prompt):# 调用对应模型返回文本结果...forcaseincases:baserun(原模型,case)quantrun(量化模型,case)print(一致ifbasequantelse不一致,case)# 文本需按任务归一化后再比不要逐字比对判断标准可以定得很朴素如果一般问答看不出差别但结构化输出开始出错说明位宽已经压到边界如果错误集中在长输出、多步推理这类用例上优先考虑换更高档位或换量化方法而不是继续往下压。第 4 章 内存预算表四块账哪块常被低估第 2 章只算了权重。这一章把四块账摆到同一张表上并指出那块经常被漏算的部分。4.1 四块账分别是什么模型权重第 2 章已经会算。运行时框架本体、推理库、可能的算子内核通常几百 MB 到 1 GB 量级与后端有关。KV Cache推理时缓存每层已经算过的 Key 与 Value避免重复计算随上下文长度和并发数增长。系统操作系统占用加上一块安全余量。四块里经常被低估的是 KV Cache。原因在于它不像权重那样是个固定数字而是随上下文长度和并发数近似线性增长的。4.2 KV Cache 的粗算一个通用的粗算式如下2 表示 Key 与 Value 两份KV Cache 字节数 ≈ 2 × 层数 × 序列长度 × 隐藏维度 × 每元素字节数 × 并发数⚠️待验证上式是通用工程粗算未按具体模型的实现核验实际是否共享 KV、注意力结构如何都会带来差别请以你所用推理框架的实测为准。套一组数字感受一下24 层、隐藏维度 2048、16 位浮点每元素 2 字节、上下文 4096、单请求——KV Cache 约 0.8 GB若并发开到 4 路就涨到约 3.2 GB。这个数字已经接近 4 比特 7B 模型的权重占用本身。⚠️代码待验证defkv_cache_gb(layers,hidden,seq_len,batch,bytes_per_elem2):# 2 Key 与 Value 两份total2*layers*seq_len*hidden*bytes_per_elem*batchreturntotal/1e9# 层数 × 序列长度 × 隐藏维度 × 元素字节 × 并发print(round(kv_cache_gb(24,2048,4096,1),2))# 单请求、4K 上下文print(round(kv_cache_gb(24,2048,4096,4),2))# 4 路并发4.3 一张可填的预算表把四块账放在一起就是下面这张表。建议每次换模型、换板子都重新填一遍。分块粗算依据示例值4 比特 7B、单请求、4K 上下文模型权重参数量 × 每参数字节数约 3.5~4 GB运行时与框架框架 推理库约 0.3~1 GB视后端KV Cache4.2 节的粗算式约 0.8 GB系统与安全余量操作系统 预留建议不低于可用内存的 20%合计四项相加约 5.5 GB 起⚠️代码待验证[内存预算表 · 待填] 板子可用内存 ____ GB ① 模型权重 ____ GB 参数量 × 每参数字节数 ② 运行时与框架 ____ GB ③ KV Cache按最大并发算 ____ GB 2 × 层数 × 上下文 × 隐藏维度 × 字节 × 并发 ④ 系统与安全余量 ____ GB 建议不低于可用内存的 20% 合计 ____ GB 余量 可用内存 − 合计 ____ GB 为正才算放得下看到这张表就能明白一块标称 8 GB 的板子跑一个 4 比特 7B 模型、再加几路并发余量其实并不宽裕。第 5 章 嵌入式老本行哪些经验直接能用前面讲的都是「新东西」但真正让你比只会调 API 的人走得稳的恰恰是那些看起来「过时」的嵌入式经验。5.1 算子与内存布局量化推理的本质是把逐元素的浮点乘加换成整数乘加再乘一个缩放系数。当你要判断「为什么这个后端慢」「为什么某些算子被退回 CPU 跑」时内存布局的知识直接派上用场数据是按行还是按列存放、是否分块、有没有对齐要求都会影响后端能否用上它优化过的内核。写过 DMA 搬运和缓存行对齐的人读这类问题会比纯算法背景的人更快。5.2 定点数经验几乎是同一套概念做过定点 DSP、接触过 Q 格式、处理过饱和与溢出的人对「缩放系数、零点、量化误差、饱和截断」这些概念一点都不陌生——它们正是权重量化里的核心概念。你不是在学一个全新的领域而是在给熟悉的定点思维换一个应用对象。5.3 用带宽视角看量化端侧解码常常是内存带宽受限而不只是算力受限。量化把每个权重从 2 字节降到 0.5 字节省下的主要就是「搬数据的量」。这正是嵌入式人熟悉的 bus 带宽思维与其纠结主频不如先看要搬运多少字节。端侧部署资料包里面整理了 llama.cpp 官方仓库说明与量化相关论文的阅读索引配合本章的算子与内存布局对照看更顺。放在资料包里扫码即可获取第 6 章 NPU 与加速器委托这条线先看什么内存算清楚之后才会轮到「能不能用上加速器」。这一章讲清委托机制以及上板前该核什么。6.1 委托delegate到底做了什么委托delegate指的是推理框架把一部分能加速的算子树交给专门的硬件后端GPU 或 NPU去计算剩下的部分回退到 CPU。注意关键词是「一部分」——它是部分加速不是把整个模型搬走。这一点决定了它能不能帮上你取决于你的模型里有多少算子在目标硬件上被支持。6.2 官方口径与上板核查清单LiteRT 是 Google AI Edge 面向端侧的运行时。其官方仓库 READMEgoogle-ai-edge/LiteRT截至 2026-10-07自述定位为「Google’s on-device runtime for high-performance ML GenAI deployment on edge platforms」并写明提供 GPU/NPU 加速其新版 Compiled Model API 的一个卖点是「自动的加速器选择不再需要显式创建 delegate」。该 README 的平台表中NPU 覆盖高通、联发科、Google Tensor、Intel 等多家厂商。另一边llama.cpp 官方 README 的后端表也列出了 Ascend NPU、Snapdragon、AdrenoOpenCL、Metal、Vulkan、OpenVINO 等目标——说明「多后端 委托」不是某一家框架的私有做法。上板前建议逐项核对下面这张清单任何一项没确认都可能让「加速」变成「白等」。核查项为什么重要怎么核支持的量化格式有些 NPU 只接受特定量化格式查该硬件后端文档算子覆盖率不支持的算子会退回 CPU看框架的委托/回退报告回退是否可见静默回退会让你误以为已加速对比 CPU 单跑与开委托的耗时是否支持离线编译影响启动时的首次延迟查是否提供提前编译选项内存峰值委托可能额外占内存实测峰值别只看静态估算6.3 一个务实的顺序先 CPU 跑通建议的顺序是先让模型在 CPU 上跑通、把第 4 章的预算表填准再去试 NPU 或 GPU 委托。顺序反了你会同时面对「模型放不下」和「加速器不支持某些算子」两个问题定位起来非常费劲。先确定能跑再讨论跑得快。第 7 章 落地小结五步走加上三个停手判据把前面六章压缩成一份可执行流程。不需要记住所有公式只需要记住顺序和红线。7.1 五步走定目标多长的上下文、几路并发、最终跑在什么硬件上算下界用第 2 章公式算权重选一个初始量化档位填预算表加上运行时、KV Cache、系统余量看合计是否放得下做对比用固定评测用例跑原模型与量化模型确认质量可接受上板实测测内存峰值与延迟再考虑开委托加速。7.2 三个停手判据判据的作用是告诉你「什么时候该停手换方案」而不是硬扛。内存预算表合计已经超过板子可用内存的约七成就先降档或减并发别硬上质量固定用例里结构化输出开始出错就换更高档位或换量化方法不要继续压比特数加速开了委托之后内存或延迟没有改善甚至更差就去查是不是发生了回退回退严重时退回纯 CPU 方案往往是更省心的选择。内存预算与量化速查表把本章的五步流程和三个停手判据做成了一张可打印的清单方便对着填。放在资料包里扫码即可获取附表 A本文引用事实与出处对照表事实出处文档名 发布方 链接本文位置llama.cpp 支持 1.5/2/3/4/5/6/8 比特整数量化用于更快推理与更低内存占用llama.cpp READMEggml-orghttps://github.com/ggml-org/llama.cpp第 3 章llama.cpp 后端覆盖 Ascend NPU、Snapdragon、Adreno(OpenCL)、Metal、Vulkan、OpenVINO 等llama.cpp READMESupported backends 表ggml-orghttps://github.com/ggml-org/llama.cpp第 6 章论文题名与编号GPTQ: Accurate Post-Training Quantization for Generative Pre-trained TransformersarXiv:2210.17323ICLR 2023arXiv 摘要页https://arxiv.org/abs/2210.17323第 3 章GPTQ 摘要称可把位宽降到每个权重 3 或 4 比特精度下降相对基线可忽略arXiv 摘要页https://arxiv.org/abs/2210.17323第 3 章论文题名与编号AWQ: Activation-aware Weight Quantization for LLM Compression and AccelerationarXiv:2306.00978MLSys 2024 Best PaperarXiv 摘要页https://arxiv.org/abs/2306.00978第 3 章AWQ 摘要称并非所有权重同等重要只保护约 1% 的显著权重即可大幅降低量化误差且显著通道应依据激活分布判断arXiv 摘要页https://arxiv.org/abs/2306.00978第 3 章量化定义用量化降低加载与使用模型的内存需求把权重以更低精度存储同时尽量保留准确率Transformers 量化文档OverviewsHugging Facehttps://huggingface.co/docs/transformers/main/en/quantization第 2、3 章量化档位结论8 比特约省一半内存、准确率非常接近基线4 比特约省四分之三、准确率相对较高低于 4 比特明显下降2 比特尤其明显Transformers 量化文档Hugging Facehttps://huggingface.co/docs/transformers/main/en/quantization第 3 章LiteRT 自述为「Google’s on-device runtime for high-performance ML GenAI deployment on edge platforms」提供 GPU/NPU 加速新版 Compiled Model API 提供自动加速器选择LiteRT READMEgoogle-ai-edgehttps://github.com/google-ai-edge/LiteRT第 6 章LiteRT 平台表中 NPU 覆盖高通、联发科、Google Tensor、Intel、Broadcom 等LiteRT READMEPlatforms Supported 表google-ai-edgehttps://github.com/google-ai-edge/LiteRT第 6 章每参数字节数与权重占用换算表KV Cache 粗算式待验证本文自算与通用工程粗算未引官方原文第 2、4 章附表 B术语速查表术语一句话解释本文哪里用到端侧部署把模型放到板子、手机或边缘设备上本地推理而非调云端接口第 1 章量化用更少的位数存权重如从 32 位浮点降到 8 比特或 4 比特整数换取更小的占用第 3 章比特表示数值用的二进制位数位数越少占用越小、误差越大第 3 章GGUFllama.cpp 使用的模型文件格式量化后的权重按它打包第 3 章KV Cache推理时缓存每层已经算过的 Key 与 Value避免重复计算随上下文增长第 4 章权重模型里被训练出来的参数推理时要全部加载第 2 章量化误差量化后的数值与原始数值之间的差距位宽越低通常越大第 3 章显著权重对激活影响特别大的少数权重通道量化时要重点保护第 3 章委托delegate把部分算子树交给 GPU/NPU 计算其余回退 CPU 的机制第 6 章算子推理时的基本计算单元如矩阵乘、激活函数第 5 章定点数用整数加固定缩放系数表示小数嵌入式里常见第 5 章内存带宽单位时间能搬运的数据量量化能降低对它的压力第 5 章写在最后这篇用到的资料写这篇文章时把相关的官方文档和源码又翻了一遍顺手也整理了几份配套的东西大模型学习路线图从零基础到能自己动手做 Agent按阶段说明每一步该学什么、哪些可以先跳过《LangChain LangGraph MCP 智能体开发实战》视频课7 个模块从私有化部署、EmbeddingRAG 到 MCPAgent 全流程AI 大模型知识库在线可查Agent Skills 从入门到落地、Claude Skills 完全指南等专题按目录浏览即可640 套 AI 大模型行业报告 经典 PDF 书籍看行业落地案例和别人怎么做的时候用得上大模型零基础到精通教学视频跟着敲一遍比只读文档快得多资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「AI」优先通过。资料按「先路线、再动手、最后查漏」的顺序整理好了建议先看学习路线那一份照着它挑一条适合自己当前基础的路径再往下看。