小米端侧大模型部署：LLM剪枝与量化实战指南

简介：这份PDF资料聚焦小米大模型端侧部署的落地探索，面向大模型算法工程师、端侧AI开发者及对轻量化部署感兴趣的技术人员，系统梳理了端侧AI的重要性、LLM端侧部署挑战与相关技术路径。内容涵盖可靠性、隐私安全、个性化服务与成本效益四大端侧优势，并对比云端与端侧在算力、内存、功耗、带宽上的差异，深入讲解剪枝、量化、Sheared LLaMA、TransAct等模型压缩与推理加速方案，以及模型分片、内存瓶颈优化等部署实践。资源包内含1个PDF文件，大小约4.23MB，结构完整、图文并茂，适合作为端侧大模型技术调研与方案设计的参考材料。目前已有144人学习，可帮助读者快速建立端侧部署知识框架，理解小米在轻量化、本地化方向上的技术定位与突破思路。

1. 端侧大模型部署：为什么小米把「轻量化」当成主力突破方向

去年底我拿到这份《小米大模型端侧部署落地探索》的 PDF，第一反应不是「又一个发布会材料」，而是翻到第 6 页看那张云端 VS 端侧的算力对比表——A100 显存带宽接近 1.6TB/s，手机 NPU 大约 70G/s，差了二十多倍。这个数字基本决定了端侧 LLM 部署的所有技术路线：你不可能靠堆硬件解决，只能从模型结构、数值精度、内存搬运三个方向抠。

端侧 AI 说白了就是在手机、音箱、车机这类终端上直接跑推理，不依赖网络回传。它解决的是四件事：断网可用、数据不出本地、按用户习惯做个性化、大规模铺开时省云端算力成本。小米做这件事的底气是设备保有量大，软件乘硬件的组合能把轻量化和本地部署真正推到量产。这份材料适合两类人看：一类是想搞清楚端侧 LLM 到底卡在哪的算法工程师，一类是准备把大模型往终端搬、需要一份技术选型参照的部署工程师。下面我按「挑战在哪 → 剪枝怎么做 → 量化怎么落 → 避坑 → 进阶验证」的顺序，把这份材料拆成能照着复现的笔记。

2. 端侧部署的硬约束：算力、内存、带宽三座大山怎么量化

2.1 云端和端侧的差距不是「小一点」，是数量级

材料里那张对比表值得逐行拆。云端服务器用 A100 这类卡，算力数百 TFLOPS，显存大容量且带宽接近 1.6TB/s，功耗设计本来就是给高功耗环境用的，散热要求高。端侧这边，手机算力相对低，内存和存储通常几个 GB 到十几 GB，NPU 带宽约 70G/s，还是低功耗设计。

真正要命的是内存瓶颈。材料里给了一个很具体的账：6B 模型，FP16 权重就要 12GB 左右，而手机内存总共约 16G。也就是说光把权重塞进去，系统和其他 App 就没剩多少了，KV cache 还没算。这就是为什么端侧部署第一步永远是「把模型变小」，而不是「把推理写快」。

推理速度这块材料给了一个很接地气的锚点：母语读者平均阅读速度 300 到 500 字每分钟，约 50+ 字每秒；快速阅读者能到 500 到 700 字每分钟，约 100+ 字每秒。端侧推理如果不做优化，20 tokens/s 以内。这个对比的意思是——用户对「生成速度」的容忍度其实参照的是自己的阅读速度，你跑到 50 tokens/s 以上，体验就接近「读得比生成快」，不会觉得卡。所以优化目标不是无限快，而是先跨过这条体验线。

2.2 推理时延拆成两项，优化才有抓手

材料把推理时延拆成：推理时延 = 计算时间 + 数据搬运时间。这个拆法很关键，因为它直接对应两类手段：

• 减少计算量：剪枝、量化
• 减小数据搬运：剪枝、量化、投机推理

注意剪枝和量化同时出现在两栏里，说明它们既省算力又省带宽。而投机推理主要省的是「搬运」这一侧的时间——用小模型快速起草、大模型并行验证，把串行的搬运摊薄。这个公式是我看这份材料时觉得最实用的一句话，因为它把「玄学调优」变成了两个可以分别测量的量：你先 profile 一下，到底是算得慢还是搬得慢，再决定往哪个方向使劲。

2.3 一个可复现的显存与带宽估算脚本

在动手剪枝量化之前，我习惯先算一遍理论下限，避免做完发现还是塞不进去。下面这段脚本按材料给的参数口径估算权重显存、KV cache 和理论搬运时间，参数都可以改。

# 端侧 LLM 显存与带宽粗算，参数按材料口径可调 def estimate(model_params_b, bits, seq_len, batch, n_layers, n_kv_heads, head_dim, mem_gb, bw_gbs): # 权重显存：参数量 × 每参数字节数 bytes_per_param = bits / 8 weight_gb = model_params_b * 1e9 * bytes_per_param / (1024**3) # KV cache：2(K和V) × 层数 × batch × 序列长 × kv头数 × 头维度 × 2字节(fp16) kv_gb = (2 * n_layers * batch * seq_len * n_kv_heads * head_dim * 2) / (1024**3) total_gb = weight_gb + kv_gb # 理论搬运时间：把权重从内存搬到计算单元，按 NPU 带宽估 move_ms = weight_gb * 1024 / bw_gbs * 1000 print(f"权重显存: {weight_gb:.2f} GB") print(f"KV cache: {kv_gb:.2f} GB") print(f"合计: {total_gb:.2f} GB / 可用 {mem_gb} GB " f"-> {'塞得下' if total_gb < mem_gb else '塞不下，继续压'}") print(f"单次权重搬运理论下限: {move_ms:.1f} ms") # 6B 模型，FP16，序列 2048，batch 1，32 层，8 个 KV 头，头维度 128 estimate(6, 16, 2048, 1, 32, 8, 128, mem_gb=16, bw_gbs=70)

逻辑说明：bits控制量化位宽，改成 4 就是 w4 场景；n_kv_heads和head_dim决定 KV cache 大小，这也是后面 TransAct 那类结构剪枝要动的地方。参数说明：mem_gb填设备可用内存，bw_gbs填 NPU 带宽。跑一遍你会看到 FP16 的 6B 模型权重就 11GB 出头，加上 KV cache 直接顶到 16G 上限，结论很明确——不量化不剪枝，端侧没戏。这个脚本我一般放在项目最开始跑一次，作为「必须压到多少」的硬指标。

3. LLM 剪枝：结构化剪枝为什么是硬件最友好的那条路

3.1 三种剪枝的取舍，先看硬件支持

材料把剪枝分成非结构化、结构化、半结构化三类，并直接给了一句结论：结构化剪枝目前硬件支持最友好。这句话背后是血泪经验——非结构化剪枝虽然稀疏率高、理论压缩比好看，但产生的是不规则稀疏，通用 NPU 和移动 GPU 很难真正加速，经常是「模型小了但没变快」。半结构化（比如 2:4）需要特定硬件支持，端侧不一定有。结构化剪枝直接剪掉整个层、整个 head、整个维度，剪完还是规整的稠密矩阵，硬件能实打实加速。

结构化剪枝具体剪什么？材料列了剪层、剪 Head、剪维度。剪层是砍掉整个 Transformer block，剪 Head 是减少注意力头数，剪维度是缩 hidden dim。这三种对 KV cache 的影响完全不同，这也是后面选型的分水岭。

3.2 Sheared LLaMA 的启发和它的短板

材料引了 Sheared LLaMA（ICLR'24），它的做法是同时剪深度（层数）和 hidden dim。剪枝的校准目标是：加 mask 训练模型，优化「一般损失 + mask 稀疏度损失」，让模型在剪枝过程中自己学出哪些结构可以丢。材料给了一个很重要的结论：剪枝 + 少量恢复训练，能超越相同大小的预训练模型。这句话是剪枝这件事「有意义」的根基——否则你剪完还不如直接训个小模型，那剪枝就白做了。

但材料对 Sheared LLaMA 的评价很直接：损失较大，KV cache 压缩不足。原因在于它剪 hidden dim 时，对 KV cache 的压缩不够狠。KV cache 大小取决于层数、KV 头数、头维度，你光剪 hidden dim 不一定等比缩 KV。端侧长上下文场景下，KV cache 经常是压垮内存的最后一根稻草，所以这个短板在端侧是致命的。

3.3 TransAct：保留深度、缩模块内激活维度

材料重点讲的是他们自己的 TransAct（ACL'2024），结构设计有三个特点：

1. 保留深度和 hidden dim
2. 减小 MHA 和 MLP 模块内的激活维度
3. 参数量相近时，KV cache 显著减小

这个思路和 Sheared LLaMA 正好相反：不动深度和 hidden dim，专挑模块内部的激活维度下手。好处是 KV cache 能实打实降下来，因为 MHA 内部的激活维度直接关联 KV 的投影维度。材料还给了剪枝后的计算量和端到端时延（w4a16）对比，说明这套结构剪枝配合 4bit 权重、16bit 激活，端到端时延有可测量的下降。

3.4 一个结构化剪枝的 mask 校准骨架

下面这段代码演示结构化剪枝里「加 mask + 稀疏度损失」的校准循环骨架，思路对齐材料里 Sheared LLaMA 的校准目标，具体层结构按你的模型替换。

import torch import torch.nn as nn class MaskedLinear(nn.Module): """带可学习 mask 的线性层，mask 趋近 0 的维度可被剪掉""" def __init__(self, in_features, out_features): super().__init__() self.weight = nn.Parameter(torch.randn(out_features, in_features)) self.bias = nn.Parameter(torch.zeros(out_features)) # mask 用 sigmoid 参数化，保证在 (0,1) 区间 self.mask_logit = nn.Parameter(torch.zeros(out_features, 1)) def forward(self, x): mask = torch.sigmoid(self.mask_logit) return x @ (self.weight * mask).T + self.bias def sparsity_loss(model, target=0.5): """鼓励 mask 稀疏：让平均 mask 值靠近 target""" total, count = 0.0, 0 for m in model.modules(): if isinstance(m, MaskedLinear): mask = torch.sigmoid(m.mask_logit) total = total + mask.mean() count += 1 return abs(total / max(count, 1) - target) # 校准循环：一般损失 + 稀疏度损失 def calibrate(model, dataloader, steps=1000, lam=0.1): opt = torch.optim.AdamW(model.parameters(), lr=1e-4) for step, batch in enumerate(dataloader): if step >= steps: break out = model(batch["input_ids"]) task_loss = nn.functional.cross_entropy( out.logits.view(-1, out.logits.size(-1)), batch["labels"].view(-1)) loss = task_loss + lam * sparsity_loss(model) opt.zero_grad() loss.backward() opt.step() if step % 100 == 0: print(f"step {step} task {task_loss.item():.3f} " f"sparsity {sparsity_loss(model).item():.3f}")

逻辑说明：MaskedLinear把每个输出维度乘一个可学习 mask，训练中 mask 会向 0 或 1 分化，趋近 0 的维度就是可以剪掉的。sparsity_loss控制整体稀疏程度，lam是稀疏度损失权重。参数说明：target是期望的平均 mask 值，越小剪得越狠；lam太大会伤任务性能，我一般从 0.05 到 0.1 起步。跑完校准后，把 mask 低于阈值的维度真正物理剪掉，再做少量恢复训练——这一步对应材料说的「剪枝 + 少量恢复训练超越同尺寸预训练模型」。注意恢复训练的数据量不用大，但质量要高，否则剪完的模型会明显掉点。

4. LLM 量化：把浮点转定点，w4a16 在端侧怎么落地

4.1 量化的本质和端侧收益

材料对量化的定义很干脆：在深度学习领域，量化是将浮点数值转化为定点数值的方法。落到端侧，收益有两块——模型体积变小（权重从 FP16 的 2 字节降到 4bit 的 0.5 字节，6B 模型从 12GB 降到约 3GB），以及定点运算在 NPU 上通常比浮点快、功耗低。

材料里剪枝效果对比用的是 w4a16，也就是权重 4bit、激活 16bit。这个组合在端侧很常见，因为权重占内存大头，压权重收益最大；激活保持 16bit 是为了不把精度伤太狠，毕竟激活对数值误差更敏感。你如果一上来就 w4a4，大概率精度崩掉，得不偿失。

4.2 量化不是「转完就完」，校准集决定成败

量化最容易被低估的是校准。权重量化分对称和非对称，激活量化要处理离群值（outlier），这些都需要校准集来统计数值分布。校准集选得不好，量化后的模型在特定任务上会突然掉点，而且这种掉点在通用评测上看不出来，上线才翻车。

我一般会这么做：校准集从真实业务分布里采样，覆盖长短输入、中英文、代码和普通文本，不要只用维基百科那种干净语料。校准样本数几百条通常够用，太多收益递减。量化完必须做端到端评测，不只看 perplexity，还要看具体任务的准确率。

4.3 一个权重量化的最小实现

下面这段代码演示对称权重量化的核心逻辑，把 FP16 权重映射到 4bit 整数再反量化，方便你理解量化误差从哪来。

import torch def quantize_weight_symmetric(w, bits=4): """对称权重量化：把浮点权重映射到 [-2^(bits-1), 2^(bits-1)-1]""" qmax = 2 ** (bits - 1) - 1 # 每个输出通道单独算 scale，避免全局 scale 被大值主导 scale = w.abs().amax(dim=1, keepdim=True) / qmax scale = scale.clamp(min=1e-8) # 防止除零 q = torch.round(w / scale).clamp(-qmax - 1, qmax) return q.to(torch.int8), scale def dequantize(q, scale): """反量化回浮点，用于验证误差""" return q.float() * scale # 模拟一层权重 w = torch.randn(4096, 4096) * 0.02 q, scale = quantize_weight_symmetric(w, bits=4) w_hat = dequantize(q, scale) err = (w - w_hat).abs().mean().item() print(f"4bit 量化平均绝对误差: {err:.6f}") print(f"原始显存: {w.numel()*2/1024**2:.1f} MB, " f"量化后: {q.numel()*1/1024**2:.1f} MB (int8 存储)")

逻辑说明：quantize_weight_symmetric按输出通道算 scale，这是 per-channel 量化，比 per-tensor 精度好很多，代价只是多存一点 scale。clamp防止除零。参数说明：bits改成 8 就是 w8，改成 4 就是 w4；dim=1表示按输出通道，如果你的权重布局不同要相应调整。跑完看平均绝对误差，如果误差大得离谱，通常是权重里有极端离群值，需要先做离群值处理或者换非对称量化。注意这段只是演示原理，真正部署要用成熟量化工具链，手写量化容易在算子融合上出问题。

4.4 剪枝和量化的叠加顺序

材料把剪枝和量化并列，但实际落地有顺序问题。我的经验是先剪枝再量化：剪枝改变的是模型结构，量化改变的是数值表示。你先量化再剪枝，剪枝后的结构可能破坏量化时的 scale 统计，得重新校准；先剪枝再量化，量化一次到位。而且剪枝后的模型更小，量化校准也更快。这个顺序在材料里没明说，但从它把剪枝放在量化前面讲，能看出这个倾向。

5. 端侧部署避坑：五条我踩过的血泪记录

5.1 只看参数量不看 KV cache，长上下文直接 OOM

现象：模型权重明明塞得下，一跑长上下文就内存溢出。原因：KV cache 随序列长度线性增长，6B 模型 32 层、8 个 KV 头、头维度 128，序列 4096 时 KV cache 能到几个 GB，权重之外还要留这份。解决：用第 2 章那个估算脚本先算 KV cache，长上下文场景优先选 KV cache 友好的结构（比如 TransAct 那类缩模块内激活维度的），或者上 KV cache 量化。

5.2 非结构化剪枝剪完没变快

现象：稀疏率做到 70%，模型文件小了一半，但端侧推理速度几乎没变。原因：非结构化剪枝产生不规则稀疏，通用 NPU 没有对应的稀疏加速单元，实际还是按稠密算。解决：端侧优先结构化剪枝，剪层、剪 Head、剪维度，剪完是规整稠密矩阵，硬件能真加速。材料那句「结构化剪枝目前硬件支持最友好」就是踩过这个坑才写的。

5.3 量化校准集太干净，上线掉点

现象：量化后通用评测 perplexity 几乎没掉，但业务任务准确率掉了好几个点。原因：校准集用的是干净通用语料，没覆盖业务里的特殊分布（长数字、代码、专有名词），这些恰恰是量化误差最大的地方。解决：校准集从真实业务分布采样，覆盖长短输入和多语言多模态，量化后必须跑端到端业务评测，不能只看 perplexity。

5.4 忽略数据搬运，只优化计算

现象：算子换成更快的实现，计算时间降了，但端到端时延没怎么动。原因：材料那个公式——推理时延 = 计算时间 + 数据搬运时间。端侧带宽只有约 70G/s，权重搬运经常是瓶颈，你优化计算但搬运没变，总时间自然不动。解决：先 profile 分清是算得慢还是搬得慢，搬得慢就上量化（减小搬运量）和投机推理（摊薄串行搬运），别一头扎进算子优化。

5.5 恢复训练数据量堆太大，反而过拟合

现象：剪枝后做恢复训练，数据越多越久，验证集反而变差。原因：剪枝后的模型容量变小，大量恢复训练容易过拟合到恢复数据上，而且材料说的「少量恢复训练」重点在少量。解决：恢复训练数据质量优先，量控制在能恢复性能即可，配合早停，验证集掉点就停。别把恢复训练当成重新预训练。

6. 进阶验证：怎么确认你的端侧部署真的达标

前面讲的是怎么压、怎么剪、怎么量化，这一章讲怎么验证——因为端侧部署最容易自欺欺人的地方就是「实验室跑通」和「真机达标」之间的差距。我一般会走三层验证，缺一层都不敢说落地。

第一层是理论下限验证，用第 2 章那个估算脚本，确认权重加 KV cache 在目标设备可用内存内，且单次权重搬运理论下限低于你的时延预算。这一层不过，后面都白搭。

第二层是数值精度验证，剪枝和量化后各跑一遍端到端评测。这里有个具体技巧：不要只看平均指标，要看分桶指标。把测试集按输入长度、语言、任务类型分桶，看哪个桶掉点最狠。量化误差往往集中在长尾分布上，平均指标会把它平均掉。我一般会做一张这样的对比表：

第三层是真机验证，在目标设备上跑真实场景，重点看三件事：峰值内存有没有触顶、长时间运行的功耗和发热、以及连续多轮对话下 KV cache 会不会累积到 OOM。实验室用单轮短输入测出来的时延，和真机多轮长上下文完全是两回事。

这里有个我踩过的坑值得单独说：真机验证一定要用和量产一致的推理框架和算子库。我见过实验室用 PyTorch 跑得好好的，换成端侧推理框架后因为某个算子没做量化融合，时延直接翻倍。所以第三层验证的框架必须和最终部署一致，否则测了个寂寞。

最后给一个我自己的习惯：每次端侧部署上线前，我都会强制走一遍「估算 → 分桶评测 → 真机多轮」这三层，任何一层不过就不发版。这套流程帮我拦下过好几次「实验室达标、真机翻车」的事故。端侧部署没有后悔药，压模型的时候多花一天验证，比上线后回滚省心得多。希望这份拆解帮到你，把这份材料里的剪枝量化思路真正落到自己的端侧项目上。

本文还有配套的精品资源，点击获取