小模型与端侧部署

本页介绍如何在资源受限的环境中运行大语言模型——小模型与端侧部署：通过模型压缩（量化、蒸馏、剪枝）和专用推理引擎，让 LLM 跑在手机、笔记本、甚至边缘设备上。它与LLM 推理优化一脉相承，但关注点从”云端高吞吐”转向”端侧低延迟、低功耗、隐私优先”。

核心直觉

端侧部署 = 把大模型塞进小设备。

云端 LLM 像大型发电厂——功率大但要拉电线（网络）、有延迟、还费钱。端侧小模型像自带电池的太阳能板——功率小但随取随用、零延迟、不传数据。

量化（Quantization）= 把书从精装变平装：内容差不多，但纸张更薄、更轻便。FP16（16 位浮点数）权重压成 INT4（4 位整数），体积缩到 1/4，手机也能塞下。
蒸馏（Distillation）= 大老师教小学生：用 70B（700 亿参数）大模型的输出训练 1.5B（15 亿参数）小模型，小学生虽然不如老师，但常见问题也能答对八成。
剪枝（Pruning）= 删掉不重要的知识：模型里很多参数贡献很小，直接设为零或删掉，模型变小但性能损失有限。
专用推理引擎 = 为小设备量身定制的引擎：llama.cpp、MLC-LLM 等框架针对 CPU/移动 GPU 做了极致优化，让消费级设备也能流畅运行。
SLM（Small Language Model，小语言模型）= 精简版 LLM：通常指参数量在 0.5B-7B 的语言模型，专门为端侧或低成本场景设计。2025 年的主流 SLM 包括 Qwen 2.5（0.5B-7B）、Gemma 3（1B-4B）、Llama 3.2（1B-3B）等。

原理详解

量化：降低数值精度

模型权重默认用 FP16（16 位浮点数，每个参数占 2 字节）存储。量化的核心思想是：用更少的位数表示同一个数，牺牲微小精度换取大幅压缩。

要理解为什么这可行，可以想象一张 1024×768 的照片——如果你把每个像素值从 0-65535（16 位）截断到 0-255（8 位），肉眼几乎看不出差别。模型权重也一样——大部分权重的精确低位对最终输出的影响微乎其微。

FP16 → INT8：每个权重从 16 位变成 8 位整数，体积减半，精度损失几乎不可察觉。
FP16 → INT4：每个权重从 16 位变成 4 位整数，体积压缩到 1/4。这是端侧部署的主流选择——7B 模型从 14GB 压缩到约 3.5GB，手机/笔记本就能跑。精度有一定损失，但经过 AWQ/GPTQ 等算法优化，效果接近 FP16。
FP16 → 1.5-2 bit（2025 前沿）：BitNet 等极端量化方案将每个权重压缩到 1-2 位，体积缩小 8-16 倍。虽然精度损失更大，但配合专用训练方法（QAT，量化感知训练），仍能保持可用的性能。

量化分两种时机：

训练后量化（PTQ, Post-Training Quantization）：模型训练完成后直接压缩。简单快速，但极端压缩（如 INT4）可能精度下降明显。GPTQ、AWQ、GGUF 都属于此类。PTQ 的关键是找到合适的”缩放因子”（scaling factor）和”零点”（zero-point），将浮点数映射到整数范围。
量化感知训练（QAT, Quantization-Aware Training）：在训练过程中模拟量化误差，让模型提前适应低精度。精度更好，但需要重新训练，成本高。2025 年微软的 BitNet b1.58 就是典型的 QAT 方法，将所有权重训练为三值（-1, 0, +1）。

GPTQ vs AWQ 量化算法对比：

特性	GPTQ	AWQ
全称	Generative Pre-trained Transformer Quantization	Activation-aware Weight Quantization
核心思路	逐层用二阶信息（Hessian 矩阵的逆）最小化量化误差	保护对激活值（activations）贡献大的”显著权重”不被压缩
精度	INT4 下优秀	INT4 下略优于 GPTQ（部分任务）
速度	量化过程较慢（需计算逆矩阵）	量化过程更快
适用场景	精度优先	速度优先，端侧部署更常用

蒸馏：知识迁移

知识蒸馏的核心思想是：用大模型（教师）的输出作为训练数据，训练小模型（学生），让小模型学到接近大模型的能力。 这个概念最早由 Geoffrey Hinton 在 2015 年提出——核心洞察是”暗知识”（Dark Knowledge）：教师模型的输出概率分布包含了比”正确答案”更丰富的信息（比如”这个错误答案有多接近正确答案”）。

具体做法：

用教师模型（如 GPT-4 或 70B 模型）对大量问题生成高质量回答（含推理过程）。
用这些”问题 → 教师回答”数据对微调学生模型（如 1.5B/7B 模型）。
学生模型学会模仿教师的输出风格和推理能力。

蒸馏的关键优势：训练数据由教师模型自动生成，不需要人工标注。DeepSeek-R1 蒸馏系列（R1-Distill-Qwen-1.5B 到 70B）就是典型例子——用 R1 的推理数据微调 Qwen 架构小模型，让 1.5B 小模型也具备不错的数学推理能力。

蒸馏的三种方式：

输出蒸馏（Response Distillation）：学生直接模仿教师的最终输出文本。最简单、最常用。
** logits 蒸馏（Logits Distillation）**：学生不只模仿最终文本，还模仿教师在每个位置的输出概率分布（logits）。这保留了”暗知识”——比如教师对”巴黎是法国的___“的 logits 可能同时给了”首都”90% 和”最大城市”8%，这种分布信息比只给”首都”更丰富。
特征蒸馏（Feature/中间层 Distillation）：学生模仿教师中间隐藏层的表示。对齐更深层的语义理解，但需要师生模型架构兼容。

剪枝：去除冗余参数

剪枝的核心思想是：识别并删除对输出贡献小的参数（权重接近零的连接或整个注意力头），减小模型体积。

直觉理解：训练好的神经网络中，很多连接的权重值非常小（接近零），删掉这些连接就像修剪树枝——去掉枯枝不会影响大树的健康，反而让它更精简。

非结构化剪枝（Unstructured Pruning）：逐个将不重要的权重设为零。压缩率高但硬件利用率低（稀疏矩阵运算——大部分元素为零的矩阵乘法——在很多硬件上没有专门加速，实际推理速度反而可能变慢）。
结构化剪枝（Structured Pruning）：整行、整列或整个注意力头（Attention Head）地删除。压缩率不如非结构化，但推理速度实际更快（因为不用处理稀疏矩阵，常规矩阵运算可以直接用）。
半结构化剪枝（Semi-Structured Pruning，如 N:M 稀疏）：每 N 个权重中保留 M 个非零。NVIDIA Ampere+ GPU 硬件支持 2:4 稀疏模式（每 4 个权重保留 2 个），可获得 2 倍加速。这是 2025 年剪枝研究的重点方向。

在 LLM 时代，剪枝不如量化和蒸馏常用——因为量化的收益更直接、实现更简单。剪枝主要用于极致压缩场景。

端侧推理引擎

端侧部署需要专门的推理引擎，因为云端框架（vLLM、TensorRT-LLM）假设有高端 GPU 和充足内存：

llama.cpp：纯 C/C++ 实现，零外部依赖，支持 CPU/GPU 混合推理，使用 GGUF 量化格式。是 Ollama、LM Studio 等工具的底层引擎。支持从 1.5-bit 到 8-bit 的多种量化级别，覆盖 x86（AVX/AVX2/AVX512/AMX）、ARM（NEON/Accelerate/Metal）、GPU（CUDA/HIP/Vulkan/SYCL）等多种后端。2025-2026 年已演进到支持 Qwen3.5 等最新模型。详见LLM 推理优化。
MLX（Apple）：Apple 针对 Apple Silicon（M1-M4 芯片）优化的机器学习框架。2026 年 Ollama 开始采用 MLX 作为 Apple Silicon 上的推理引擎，通过**多 Token 预测（MTP, Multi-Token Prediction）**技术——每步预测多个 token 而非一个——在 Apple Silicon 上实现了高达 90% 的速度提升。
MLC-LLM：基于 TVM/MLC 编译器，支持 iOS、Android、浏览器（WebGPU，一种让浏览器直接调用 GPU 的 Web 标准）。能在 iPhone 上流畅运行 Llama 3 8B。
ONNX Runtime / ExecuTorch：微软和 Meta 分别推出的跨平台推理引擎，支持移动端和嵌入式设备。

原理图解

模型压缩三板斧

端侧 vs 云端部署对比

量化的位宽与体积关系

动手实践

用 Ollama 在本地运行量化小模型

# 前提：安装 Ollama 并执行 ollama pull qwen2.5:3b（约 2GB，INT4 量化）
from openai import OpenAI

# Ollama 提供 OpenAI 兼容 API，本地 11434 端口
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

response = client.chat.completions.create(
    model="qwen2.5:3b",  # 3B 参数 INT4 量化，笔记本即可流畅运行
    messages=[{"role": "user", "content": "用三句话解释什么是量化。"}],
)
print(response.choices[0].message.content)
# 无需网络，延迟通常在 100ms 以内

用 llama.cpp Python 绑定加载 GGUF 模型

# 前提：pip install llama-cpp-python
from llama_cpp import Llama

# 加载 GGUF 格式的 INT4 量化模型（约 2-4GB 文件）
llm = Llama(
    model_path="./qwen2.5-3b-instruct-q4_k_m.gguf",  # Q4_K_M 是 llama.cpp 最常用的 INT4 变体
    n_ctx=2048,       # 上下文窗口（token 数）
    n_gpu_layers=-1,  # -1 表示尽可能用 GPU 加速
)

output = llm(
    "用一句话解释什么是知识蒸馏。",
    max_tokens=80,
    stop=["\n\n"],
)
print(output["choices"][0]["text"])

用 AutoAWQ 将 HuggingFace 模型量化为 INT4

# 前提：pip install autoawq transformers
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = "Qwen/Qwen2.5-7B-Instruct"  # 原始 FP16 模型
quant_path = "Qwen2.5-7B-Instruct-awq"    # 量化后保存路径

# AWQ 量化配置
quant_config = {
    "zero_point": True,     # 使用零点校准，提升精度
    "q_group_size": 128,    # 量化分组大小，128 是平衡精度和速度的常用值
    "w_bit": 4,             # 目标位宽：4-bit
    "version": "GEMM",      # GEMM 适合 GPU，GEMV 适合 CPU
}

# 加载模型并执行量化
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)
# 量化后体积从约 14GB 降到约 4GB，可直接用 vLLM 或 transformers 加载推理

实践要点

先量化、再蒸馏、最后剪枝：压缩三板斧的优先级。量化收益最大（4 倍压缩）、实现最简单（几行代码），应最先做。量化后仍不满足要求才考虑蒸馏或剪枝。三者也可以组合使用——先蒸馏出更小的模型，再量化，最后剪枝。
INT4 是端侧甜点：INT4 量化在体积和精度间取得了最佳平衡。GPTQ 和 AWQ 两种算法效果接近，AWQ 在部分任务上略优。GGUF 格式的 Q4_K_M 是 llama.cpp/Ollama 生态中最常用的量化配置——“K”表示使用 K-Quant 方法（对不同层使用不同量化精度），“M”表示中等精度级别。
上下文窗口按需设置：端侧设备的内存有限，KV-Cache（推理时缓存的 Key-Value 张量，避免重复计算注意力）随上下文长度线性增长。对话场景设 2048-4096 即可；文档摘要场景可适当增大，但要监控内存占用。例如 Qwen 2.5 3B 在 4K 上下文下 KV-Cache 约占 300MB-1GB 内存（取决于具体配置）。
预热很重要：模型首次加载需要从磁盘读入权重（几秒到几十秒）。交互式应用应在启动时预加载模型，避免用户等待。在移动端，还应考虑后台保活——切换 App 回来时模型不应被系统杀掉重新加载。
隐私是端侧部署的核心卖点：医疗、金融、法律等敏感数据不出设备的场景，端侧部署是合规友好的方案——数据全程在本地处理，不经过任何云端。这在 GDPR（欧盟通用数据保护条例）和 HIPAA（美国健康保险流通与责任法案）合规场景中尤为关键。
小模型能力有上限：3B 以下模型在复杂推理、长文本理解上明显弱于大模型。关键场景建议用云端大模型兜底，端侧小模型处理简单高频任务。
Minions 模式——端云协同：Stanford Hazy Research 实验室 2025 年提出的 Minions 方法，让端侧小模型（如 Llama 3.2）与云端大模型（如 GPT-4o）协作——小模型负责本地数据处理和隐私任务，大模型负责复杂推理。这种”端云分工”模式兼顾隐私、成本和能力，是端侧部署的新方向。

典型应用

Apple Intelligence：Apple 在 iOS 18 中内置 3B 参数的端侧语言模型（~AFM 模型），处理文本摘要、邮件回复建议、通知优先级等高频任务——全部在设备本地运行，隐私数据不离开手机。复杂任务才回退到云端 Private Cloud Compute（PCC，Apple 的隐私保护云端推理服务）。
Google Gemini Nano：Pixel 8/9 和三星 Galaxy S24/S25 内置 Gemini Nano 模型，实现端侧录音摘要、智能回复、魔法编辑等功能，完全离线运行。Gemini Nano 2 进一步提升了推理能力。
Ollama / LM Studio 本地开发：开发者在 MacBook 上用 Ollama 跑 Llama 3 8B 或 Qwen 2.5 7B，做 Prompt 调试和原型开发——零 API 费用、无速率限制、数据不外泄。2026 年 Ollama 支持 MLX 引擎后在 Apple Silicon 上速度提升高达 90%。
离线翻译与写作助手：军事、外交通信等完全断网场景，用端侧小模型做实时翻译和文本生成；隐私要求高的企业（律所、医院）用端侧模型做内部文档处理。
车载与 IoT 语音助手：车机系统、智能音箱用端侧小模型做语音交互，延迟低（100ms 以内）、不依赖网络连接、断网也能用。
OpenAI gpt-oss 开源模型：2025 年 OpenAI 发布了开源模型 gpt-oss:20b 和 gpt-oss:120b，可通过 Ollama 本地运行，并与 OpenAI Codex CLI 集成，实现完全本地的 AI 编程助手。

典型类库与工具

类库 / 工具	语言	说明
llama.cpp	C/C++	端侧推理首选，支持 GGUF 量化（1.5-8 bit），CPU/GPU 混合，Ollama 的底层引擎
Ollama	Go/C++	封装 llama.cpp（以及 MLX），一行命令本地部署模型，CLI 极简，2026 年支持 MLX + MTP
MLX	Python/C++	Apple 的机器学习框架，针对 Apple Silicon 优化，支持多 Token 预测加速
MLC-LLM	Python/C++	支持 iOS、Android、WebGPU 的跨平台推理引擎
GGUF	格式	llama.cpp 生态的量化模型格式，支持多种量化级别（Q2_K 到 Q8_0）
AutoGPTQ / AutoAWQ	Python	自动化 GPTQ/AWQ 量化工具，将 HuggingFace 模型转为 INT4
ExecuTorch	C++/Python	Meta 推出的端侧 AI 推理框架，支持移动和嵌入式设备
BitsAndBytes	Python	训练时量化库（NF4/INT8），支持 QLoRA 微调

术语表

术语	英文	解释
量化	Quantization	将模型权重从高精度（FP16）压缩到低精度（INT8/INT4），减少体积和内存占用
知识蒸馏	Knowledge Distillation	用大模型的输出训练小模型，使小模型学到接近大模型的能力
剪枝	Pruning	删除模型中对输出贡献小的参数，减小模型体积
小语言模型	SLM (Small Language Model)	参数量通常在 0.5B-7B 的语言模型，专为端侧或低成本场景设计
训练后量化	PTQ (Post-Training Quantization)	模型训练完成后直接进行量化，简单快速
量化感知训练	QAT (Quantization-Aware Training)	训练过程中模拟量化误差，精度更好但需重新训练
GGUF	GGUF (GPT-Generated Unified Format)	llama.cpp 生态的量化模型文件格式，支持多种量化级别
K-Quant	K-Quant	llama.cpp 的分层量化方法，对不同层使用不同精度（如 Q4_K_M）
端侧部署	On-Device Deployment	在用户设备（手机、笔记本、IoT）本地运行模型，不依赖云端
浮点精度	FP16/FP32	16 位/32 位浮点数，模型权重的默认精度
多 Token 预测	MTP (Multi-Token Prediction)	每步预测多个 token 而非一个，加速自回归推理
KV-Cache	KV-Cache	推理时缓存的 Key-Value 张量，避免重复计算注意力，随上下文长度线性增长
暗知识	Dark Knowledge	教师模型输出概率分布中包含的丰富信息，比正确答案本身更有指导价值