模型压缩

1.5TB到214GB的"减肥"奇迹 2026年9月1日，腾讯发布混元Hy4轻量版。这个版本最震撼的不是跑分，而是一个纯粹的工程数字：Hy4 preview的权重文件体积从约1.5TB，压缩到了约214GB。换句话说，原来要存1500GB的模型，现在只需要214GB，体积缩小到原来的七分之一。 为什么压缩到1/7还能打 大模型"压缩"听起来简单，做起来极难。常见手段包括量化（把16位浮点权重压成8位甚至4位）、蒸馏（用大模型教小模型）、剪枝（去掉不重要的参数）。但每一种手段都会带来能力损失：量化过头会让模型"变笨"，蒸馏会丢掉教师模型的深层推理能力，剪枝可能直接废掉某些能力维度。 腾讯混元Hy4轻量版这次公布的能力对比，关键在于"几乎不损失"： 能力维度 Hy4 preview原版 Hy4轻量版 权重体积 约1.5TB 约214GB 体积比 100% 约14% 长文理解 基准 几乎持平 多轮长上下文检索 基准 基本同一水平 数学能力 基准 小幅回落 长文理解几乎持平、多轮长上下文检索基本同一水平——这两项是大模型在企业场景最核心的能力，也是最容易被压缩毁掉的部分。很多模型一压缩，长上下文的"记忆力"就断崖式下跌，因为注意力机制对参数精度非常敏感。混元轻量版能在压到1/7体积后还保持长上下文检索能力，说明其压缩方案不是粗暴的低比特量化，而是结合了结构化剪枝、算子融合、注意力优化等一整套工程组合拳。 唯一承认的代价是数学能力"小幅回落"。这其实是一种诚实：数学推理对参数精度最敏感，任何压缩都会在这一项上先露馅。腾讯没有把数学也说成"持平"，而是如实标注"小幅回落"，这种数据透明度在国产大模型里反而少见。 为什么这件事比跑分更重要 大模型行业在2026年已经进入"推理成本决定生死"的阶段。一个1.5TB的模型，部署需要多张H100级别的GPU，每次推理的硬件折旧和电费都很高；压到214GB后，可能单台8卡服务器就能跑，推理成本直接降一个数量级。 对C端用户来说，这意味着混元的长文档、长对话功能可以以更低价格开放；对开发者来说，API调用成本下降后，基于混元构建Agent的经济模型就成立了。2026年下半年大模型竞争的主线已经不是"谁的参数大"，而是"谁能把同等能力做到最便宜"。 行业影响 混元Hy4轻量版给整个行业立了一个标杆：原来旗舰级长上下文模型是可以做到1/7体积而几乎不损失核心能力的。这会倒逼其他厂商重新审视自己的模型发布策略——以后发布一个模型，光说"我们参数大"没用，还得说"我们压缩后还剩多少体积、掉多少分"。 从更宏观的视角看，这也是国产大模型在"效率工程"上的一次集体补课。过去大家拼训练规模，现在开始拼推理效率。1.5TB→214GB这个数字，本质上是在回答一个问题：大模型能不能以可负担的成本走进千万级用户的日常应用。 压缩背后的工程取舍 1.5TB压到214GB，背后大概率不是单一手段能完成的。合理的推测是三层组合：第一层是结构化稀疏与专家剪枝，混元Hy4本身是MoE架构，激活参数远小于总参数，可以把大量低利用率专家先裁掉；第二层是混合精度量化，对注意力层和MLP层用不同的位宽策略，对长上下文关键的KV缓存路径保持较高精度；第三层是算子融合与KV缓存优化，让推理时不再为每一层单独分配中间缓冲区。这种分层压缩才能解释"长上下文几乎不损失"——因为它在关键路径上保留了精度，只在非关键路径上动刀。 数学能力小幅回落，则从侧面印证了这套逻辑：数学推理依赖长链路上的高精度数值运算，一旦数值精度下降，多步推理的误差会累积放大。腾讯把这一项如实标出来，而不是藏在跑分背后，说明其工程团队对压缩损伤的分布有清晰的定量认知。 对企业用户的启示是：以后选模型不能只看"压缩后体积小"，还要看压缩损伤落在哪些能力维度。如果你的场景以长文档检索、摘要、客服为主，混元轻量版几乎是白捡的红利；如果你的场景重度依赖数学推理或代码竞赛题，可能还是要跑一版原版对比再决定。 guijiagi.com 会持续跟踪主流大模型在量化、蒸馏、推理优化上的最新进展。

蒸馏的本质 知识蒸馏（Knowledge Distillation）的核心思想：用一个强大但昂贵的"教师模型"指导训练一个小而快的"学生模型"，让小模型在特定任务上接近大模型的表现。 这不是简单的模仿——而是一种知识迁移技术。 蒸馏的三层含义 1. 响应蒸馏（Response Distillation） 最直接的方式：让学生模型学习教师模型的输出分布。 传统方法（分类任务）： 教师模型: soft_targets = softmax(logits_T / T) 学生模型: soft_pred = softmax(logits_S / T) 蒸馏损失: KL(soft_targets || soft_pred) * T² 温度参数T软化概率分布，让学生能学到"次优答案也有一定概率"的暗知识。 大模型时代： 教师(GPT-4): prompt → 优质回答 学生(小模型): prompt → 学习生成同样的回答 SFT训练: loss = CrossEntropy(student_output, teacher_answer) 2. 特征蒸馏（Feature Distillation） 不只学输出，还学中间表示： 教师中间层特征: h_T = Teacher.layer_k(input) 学生中间层特征: h_S = Student.layer_j(input) 蒸馏损失: MSE(project(h_S), h_T) + α * CE(output, label) 需要设计投影层（projection layer），因为教师和学生的隐藏维度可能不同。 对于Transformer模型，可以蒸馏： 注意力权重分布 隐藏状态向量 前馈网络中间表示 3. Agent蒸馏（Agent Distillation） 2026年的新趋势——不只是蒸馏静态回答，而是蒸馏Agent行为： ...

为什么需要边缘AI？ 云计算解决了大规模AI部署问题，但很多场景无法依赖云端： 隐私要求：医疗、金融数据不能上云 延迟要求：自动驾驶、实时翻译需要毫秒级响应 离线场景：野外、飞机模式、网络不稳定 成本控制：大量设备同时运行，云推理成本不可控 边缘AI的目标：在手机、车载芯片、IoT设备上本地运行AI模型。 模型压缩四件套 1. 量化 将模型从FP32压缩到INT8/INT4： 精度 模型大小(7B) 精度损失 推理速度 FP16 14GB 0% 基准 INT8 7GB <1% 1.5-2x INT4 3.5GB 1-3% 2-3x 2-bit 1.75GB 5-10% 3-4x 移动端推荐INT4量化，使用GGUF格式（llama.cpp生态）。常用方案： GPTQ：基于二阶信息的权重量化 AWQ：基于激活分布的权重量化 GGUF Q4_K_M：移动端最常用格式 2. 蒸馏 将大模型知识"蒸馏"到小模型： Teacher模型(70B) → 生成回答/中间表示 → Student模型(1B)学习 任务特定蒸馏：只蒸馏目标任务的能力，而非通用能力。效果通常比直接训练小模型好20-30%。 3. 剪枝 移除不重要的参数： 结构化剪枝：移除整个attention head或MLP中间维度，可实际加速 非结构化剪枝：移除稀疏参数，需特殊硬件支持 移动端推荐结构化剪枝，因为标准硬件就能获得加速。 4. 架构搜索（NAS） 针对特定硬件搜索最优模型结构： 确定目标硬件的延迟/功耗预算 搜索满足约束的最高精度模型 MobileNet、EfficientNet就是NAS的经典成果 移动端推理引擎 llama.cpp C++实现，无依赖 支持GGUF格式 iOS/Android均可运行 支持CPU推理和GPU加速 典型使用: 1. 将模型量化为GGUF格式 2. 编译llama.cpp for Android/iOS 3. 通过JNI或C API调用 4. 管理上下文窗口和内存 MLC-LLM 基于TVM编译器 自动优化模型到目标硬件 支持GPU加速（Metal/Vulkan） 跨平台：iOS/Android/Web ONNX Runtime Mobile 微软出品，支持ONNX格式 Android/iOS支持完整 包体积极小（<10MB运行时） 支持NNAPI/CoreML后端加速 平台原生方案 iOS：CoreML + MLX Android：ML Kit + NNAPI 华为：CANN + NPU 端侧部署实战 iOS部署 // 使用MLX框架运行LLM import MLX import MLXLMCommon let model = try await loadModel(name: "qwen-2-1.5b-4bit") let result = try await model.generate( prompt: "你好", maxTokens: 256 ) 关键配置： ...

蒸馏：用小模型继承大模型的能力 知识蒸馏是模型压缩领域最优雅的技术——让小模型（学生）学习大模型（教师）的内部表示，而非简单地学习标签。一个好的蒸馏方案可以让7B模型逼近70B模型的效果。 Logits蒸馏：经典方法 原理 教师模型的logits（softmax前的输出）包含了类别间的相似度信息——“软标签"比"硬标签"信息量更大： class LogitsDistillationLoss(nn.Module): def __init__(self, temperature=2.0, alpha=0.5): self.temperature = temperature self.alpha = alpha # 蒸馏loss与CE loss的权重比 def forward(self, student_logits, teacher_logits, labels): # 蒸馏损失：KL散度 soft_teacher = F.log_softmax( teacher_logits / self.temperature, dim=-1 ) soft_student = F.log_softmax( student_logits / self.temperature, dim=-1 ) distill_loss = F.kl_div( soft_student, soft_teacher.exp(), reduction="batchmean" ) * (self.temperature ** 2) # 标准交叉熵损失 ce_loss = F.cross_entropy(student_logits, labels) return self.alpha * distill_loss + (1 - self.alpha) * ce_loss 温度参数的作用 温度 $T$ 控制软标签的"软度”： $T=1$：标准softmax，概率分布较尖锐 $T=2-5$：分布更平滑，类别间关系更明显 $T \to \infty$：均匀分布 实践中 $T=2-4$ 效果最好。温度的平方项补偿了梯度缩放——高温softmax的梯度会被 $1/T^2$ 缩小。 在线蒸馏vs离线蒸馏 离线蒸馏：先训练好教师模型，再蒸馏学生模型。简单稳定但教师的错误会被继承。 在线蒸馏：教师和学生同时训练，教师不断更新： class OnlineDistillation: def __init__(self, teacher, student, alpha=0.5): self.teacher = teacher self.student = student self.alpha = alpha def train_step(self, batch): # 教师前向（不更新梯度） with torch.no_grad(): teacher_logits = self.teacher(batch) # 学生前向 student_logits = self.student(batch) # 蒸馏损失 distill_loss = self._distill_loss(student_logits, teacher_logits) ce_loss = F.cross_entropy(student_logits, batch["labels"]) loss = self.alpha * distill_loss + (1 - self.alpha) * ce_loss loss.backward() 特征蒸馏：学习中间表示 原理 Logits蒸馏只利用了最终输出，特征蒸馏还利用了中间层的表示： ...

大模型越来越大，但部署环境千差万别。不是每台设备都有A100，不是每个场景都能容忍秒级延迟。模型压缩技术就是连接"大模型能力"和"有限部署资源"的桥梁。本文将系统梳理剪枝、量化、蒸馏三大压缩技术的原理与工程实践。 一、模型压缩的必要性 1.1 部署场景的多样性 场景 内存限制 延迟要求 功耗限制 云端GPU 80GB <2s 无 边缘服务器 16GB <1s 100W 手机端 4-8GB <500ms 5W IoT设备 <1GB <100ms <1W 一个70B参数的模型FP16需要140GB内存——只有云端GPU能跑。要部署到手机，需要压缩20-40倍。 1.2 压缩的三个维度 模型体积: 参数量 × 每参数字节数 推理速度: 与参数量和计算量相关 内存占用: 参数 + KV Cache + 激活值 压缩目标: 在保持精度的前提下，最小化以上三者 二、量化：最实用的压缩技术 2.1 量化原理 将高精度浮点数（FP16/FP32）映射到低精度整数（INT8/INT4）： FP16: 0.1234, 0.5678, -0.2345 (16 bit/参数) INT8: 映射到 [-128, 127] (8 bit/参数) → 压缩2倍 INT4: 映射到 [-8, 7] (4 bit/参数) → 压缩4倍 2.2 量化方法对比 PTQ（Post-Training Quantization）：训练后量化，无需重新训练 ...

大模型蒸馏技术：让小模型拥有大智慧 知识蒸馏是连接大模型和小模型的桥梁——让小模型以更低的成本获得接近大模型的能力。2026年，蒸馏技术已经从简单的输出模仿发展到多维度的知识传递，成为模型部署流程中不可或缺的一环。 蒸馏的基本原理 知识蒸馏的核心思想是让student模型学习teacher模型的行为。最基础的形式是软标签蒸馏：teacher模型对每个输入输出一个概率分布（软标签），student模型不仅学习正确答案，还学习teacher的输出分布。 软标签比硬标签（正确答案）包含更多信息。例如，在情感分类中，teacher可能输出"正面:0.7, 中性:0.2, 负面:0.1"。这个分布告诉student：这个样本倾向于正面，但与中性也有一定相似度——这种"暗知识"是硬标签无法提供的。 蒸馏方法的演进 输出层蒸馏 最早的蒸馏方法只关注最终输出。KL散度损失函数让student的输出分布逼近teacher的输出分布： L = α * KL(softmax(z_t/T) || softmax(z_s/T)) + (1-α) * CE(y, z_s) 其中z_t和z_s分别是teacher和student的logits，T是温度参数，α是损失权重。 温度T的作用至关重要。T=1时，蒸馏等同于标准训练；T较大时，软标签中的"暗知识"被放大，student能学到更多teacher的细微判断。最佳温度通常在2-10之间，需要根据任务调整。 中间层蒸馏 输出层蒸馏的局限是student只能在最终输出层面模仿teacher。但如果teacher和student的架构差异较大，输出层面的模仿可能不够有效。 中间层蒸馏让student的隐藏层表示逼近teacher的隐藏层表示。由于两个模型的隐藏层维度可能不同，通常需要一个线性映射将student的隐藏层投影到teacher的维度： L_hidden = MSE(W * h_s, h_t) 其中W是可学习的映射矩阵，h_s和h_t分别是student和teacher的隐藏层输出。 中间层蒸馏显著提升了student的性能——在我们的实验中，相比纯输出蒸馏，中间层蒸馏让student在推理任务上的准确率额外提升5-8个百分点。 注意力蒸馏 注意力蒸馏让student学习teacher的注意力分布。teacher的注意力模式包含了它"关注什么"的信息——这对理解teacher的推理过程很有价值。 注意力蒸馏在机器翻译等任务上特别有效，因为对齐信息（源语言的哪个词对应目标语言的哪个词）主要体现在注意力分布中。 渐进式蒸馏 渐进式蒸馏不是一次性蒸馏，而是分阶段进行：先用简单任务蒸馏，再逐步引入更复杂的任务。这类似于人类学习的"从易到难"过程。 在渐进式蒸馏中，每个阶段的teacher可以提供不同形式的指导：简单阶段提供软标签，复杂阶段提供推理过程（CoT），最复杂阶段提供完整的解题轨迹。 蒸馏大模型到小模型 选择合适的teacher-student对 不是所有大模型都适合做teacher，也不是所有小模型都适合做student。选择原则： Teacher选择：选择在目标任务上表现最好、输出分布最平滑的模型。输出分布越平滑，暗知识越丰富。经过RLHF训练的模型输出分布往往较尖锐（过度自信），不是最佳teacher。我们通常使用base模型（未经RLHF）作为teacher。 Student选择：student的架构应与teacher尽量相似，以最大化知识迁移效率。如果teacher是Transformer decoder，student也应该是。层数和宽度可以缩减，但基本结构应保持一致。 数据选择 蒸馏数据的质量和多样性比数量更重要。我们使用以下策略构建蒸馏数据集： Teacher生成数据：让teacher模型生成大量高质量的回答，作为student的训练数据。这比使用原始训练数据更有效，因为teacher的输出已经包含了它的"知识"。 难度分层：按任务难度对数据进行分层，确保student逐步学习从简单到复杂的模式。 领域覆盖：确保蒸馏数据覆盖student需要处理的所有领域。如果student主要用于代码生成，蒸馏数据应以代码为主。 实践效果 我们将一个70B模型蒸馏到7B模型，结果如下： 指标 Teacher (70B) Student (7B) Student (7B, 从头训练) MMLU 78.5 71.2 62.3 GSM8K 85.1 74.6 58.2 HumanEval 72.3 65.8 51.4 蒸馏相比从头训练的提升约9-16个百分点，且student的推理速度约为teacher的10倍。 ...

大模型蒸馏技术：让小模型拥有大智慧 知识蒸馏是连接大模型和小模型的桥梁——让小模型以更低的成本获得接近大模型的能力。2026年，蒸馏技术已经从简单的输出模仿发展到多维度的知识传递，成为模型部署流程中不可或缺的一环。 蒸馏的基本原理 知识蒸馏的核心思想是让student模型学习teacher模型的行为。最基础的形式是软标签蒸馏：teacher模型对每个输入输出一个概率分布（软标签），student模型不仅学习正确答案，还学习teacher的输出分布。 软标签比硬标签（正确答案）包含更多信息。例如，在情感分类中，teacher可能输出"正面:0.7, 中性:0.2, 负面:0.1"。这个分布告诉student：这个样本倾向于正面，但与中性也有一定相似度——这种"暗知识"是硬标签无法提供的。 蒸馏方法的演进 输出层蒸馏 最早的蒸馏方法只关注最终输出。KL散度损失函数让student的输出分布逼近teacher的输出分布： L = α * KL(softmax(z_t/T) || softmax(z_s/T)) + (1-α) * CE(y, z_s) 其中z_t和z_s分别是teacher和student的logits，T是温度参数，α是损失权重。 温度T的作用至关重要。T=1时，蒸馏等同于标准训练；T较大时，软标签中的"暗知识"被放大，student能学到更多teacher的细微判断。最佳温度通常在2-10之间，需要根据任务调整。 中间层蒸馏 输出层蒸馏的局限是student只能在最终输出层面模仿teacher。但如果teacher和student的架构差异较大，输出层面的模仿可能不够有效。 中间层蒸馏让student的隐藏层表示逼近teacher的隐藏层表示。由于两个模型的隐藏层维度可能不同，通常需要一个线性映射将student的隐藏层投影到teacher的维度： L_hidden = MSE(W * h_s, h_t) 其中W是可学习的映射矩阵，h_s和h_t分别是student和teacher的隐藏层输出。 中间层蒸馏显著提升了student的性能——在我们的实验中，相比纯输出蒸馏，中间层蒸馏让student在推理任务上的准确率额外提升5-8个百分点。 注意力蒸馏 注意力蒸馏让student学习teacher的注意力分布。teacher的注意力模式包含了它"关注什么"的信息——这对理解teacher的推理过程很有价值。 注意力蒸馏在机器翻译等任务上特别有效，因为对齐信息（源语言的哪个词对应目标语言的哪个词）主要体现在注意力分布中。 渐进式蒸馏 渐进式蒸馏不是一次性蒸馏，而是分阶段进行：先用简单任务蒸馏，再逐步引入更复杂的任务。这类似于人类学习的"从易到难"过程。 在渐进式蒸馏中，每个阶段的teacher可以提供不同形式的指导：简单阶段提供软标签，复杂阶段提供推理过程（CoT），最复杂阶段提供完整的解题轨迹。 蒸馏大模型到小模型 选择合适的teacher-student对 不是所有大模型都适合做teacher，也不是所有小模型都适合做student。选择原则： Teacher选择：选择在目标任务上表现最好、输出分布最平滑的模型。输出分布越平滑，暗知识越丰富。经过RLHF训练的模型输出分布往往较尖锐（过度自信），不是最佳teacher。我们通常使用base模型（未经RLHF）作为teacher。 Student选择：student的架构应与teacher尽量相似，以最大化知识迁移效率。如果teacher是Transformer decoder，student也应该是。层数和宽度可以缩减，但基本结构应保持一致。 数据选择 蒸馏数据的质量和多样性比数量更重要。我们使用以下策略构建蒸馏数据集： Teacher生成数据：让teacher模型生成大量高质量的回答，作为student的训练数据。这比使用原始训练数据更有效，因为teacher的输出已经包含了它的"知识"。 难度分层：按任务难度对数据进行分层，确保student逐步学习从简单到复杂的模式。 领域覆盖：确保蒸馏数据覆盖student需要处理的所有领域。如果student主要用于代码生成，蒸馏数据应以代码为主。 实践效果 我们将一个70B模型蒸馏到7B模型，结果如下： 指标 Teacher (70B) Student (7B) Student (7B, 从头训练) MMLU 78.5 71.2 62.3 GSM8K 85.1 74.6 58.2 HumanEval 72.3 65.8 51.4 蒸馏相比从头训练的提升约9-16个百分点，且student的推理速度约为teacher的10倍。 ...

端侧AI部署：让大模型跑在手机上 将大模型部署到移动设备上，是AI普惠化的关键一步。端侧部署意味着无需网络连接、零延迟响应、数据不出本地——这些优势在隐私敏感场景和网络不稳定环境中至关重要。但手机的计算资源和功耗约束使得这一目标充满挑战。 端侧部署的约束 一部现代智能手机的计算资源：CPU算力约5-10 TOPS，NPU算力约15-30 TOPS，内存8-16GB，可用内存通常2-4GB，功耗预算不超过3-5W。在这些约束下运行一个数十亿参数的模型，需要全方位的优化。 模型压缩三板斧 量化 量化是最有效的压缩手段。将模型权重从FP16量化到INT4，模型体积缩小到1/4，推理速度提升2-4倍，精度损失通常在1-3%以内。 INT4量化的关键挑战是保持精度。我们采用了GPTQ和AWQ两种方案对比：GPTQ在通用任务上表现略好，AWQ在激活值异常多的模型上更稳定。最终我们选择了AWQ，因为它对硬件友好——大多数移动NPU对INT4运算有专门优化。 剪枝 剪枝通过移除不重要的权重来减少模型参数。结构化剪枝（移除整行或整列）对硬件友好但精度损失较大，非结构化剪枝（移除单个权重）精度保持好但难以在实际推理中获得加速。 在实践中，我们发现幅度剪枝在30%稀疏度以下几乎无损，但超过50%后精度急剧下降。对于端侧部署，30%的结构化剪枝加上INT4量化是一个不错的平衡点。 蒸馏 知识蒸馏用大模型训练小模型，让小模型在保持紧凑的同时获得接近大模型的能力。我们使用了一个7B模型作为teacher蒸馏出1.5B的student模型。关键技巧包括：使用中间层特征匹配而非仅匹配输出logits、采用渐进式蒸馏从易到难、以及使用大模型生成的合成数据增强训练集。 推理引擎优化 模型压缩只是第一步，推理引擎的优化同样关键。 KV Cache管理 在端侧设备上，内存是稀缺资源。一个1.5B模型在INT4量化下约占800MB，但生成1024个token的KV Cache可能需要额外的600MB。我们实现了动态KV Cache管理：根据可用内存动态调整缓存大小，在内存不足时采用滑动窗口策略丢弃最早的KV。 计算图优化 将模型转换为移动端推理格式后，计算图优化可以带来显著加速。关键技术包括：算子融合（将连续的矩阵乘法和激活函数融合为单个算子）、内存复用（重用中间张量的内存空间）、以及常量折叠（在编译期计算常量表达式）。 我们使用ONNX Runtime作为端侧推理引擎，其内置的图优化pass在我们的测试中带来了约40%的推理加速。 NPU加速 现代手机的NPU是端侧AI的杀手锏。与CPU相比，NPU在矩阵运算上的能效比高出10倍以上。但NPU的编程模型比CPU复杂得多——需要将模型转换为NPU支持的算子集合，不支持的算子会fallback到CPU，造成性能损失。 我们花了大量时间在算子适配上：将模型中的所有算子映射到高通Hexagon NPU支持的指令集，仅保留3个无法替换的算子在CPU上运行。最终NPU利用率达到95%以上。 实际性能 经过全栈优化，我们在骁龙8 Gen 3平台上部署了一个1.5B参数的INT4量化模型： 模型体积：850MB 内存占用：1.2GB（含KV Cache） 生成速度：18 tokens/s 功耗：2.8W 首token延迟：380ms 这个性能水平已经可以支撑大多数端侧AI应用——从智能助手到文档摘要，从实时翻译到照片描述。 结语 端侧AI不是云端AI的替代品，而是互补品。未来的AI应用将是端云协同的——简单任务在端侧即时处理，复杂任务卸载到云端。端侧AI的发展正在缩小与云端模型的差距，而隐私和延迟优势是其不可替代的护城河。 本文同步发布于 硅基AGI论坛

端侧AI部署：让大模型跑在手机上 将大模型部署到移动设备上，是AI普惠化的关键一步。端侧部署意味着无需网络连接、零延迟响应、数据不出本地——这些优势在隐私敏感场景和网络不稳定环境中至关重要。但手机的计算资源和功耗约束使得这一目标充满挑战。 端侧部署的约束 一部现代智能手机的计算资源：CPU算力约5-10 TOPS，NPU算力约15-30 TOPS，内存8-16GB，可用内存通常2-4GB，功耗预算不超过3-5W。在这些约束下运行一个数十亿参数的模型，需要全方位的优化。 模型压缩三板斧 量化 量化是最有效的压缩手段。将模型权重从FP16量化到INT4，模型体积缩小到1/4，推理速度提升2-4倍，精度损失通常在1-3%以内。 INT4量化的关键挑战是保持精度。我们采用了GPTQ和AWQ两种方案对比：GPTQ在通用任务上表现略好，AWQ在激活值异常多的模型上更稳定。最终我们选择了AWQ，因为它对硬件友好——大多数移动NPU对INT4运算有专门优化。 剪枝 剪枝通过移除不重要的权重来减少模型参数。结构化剪枝（移除整行或整列）对硬件友好但精度损失较大，非结构化剪枝（移除单个权重）精度保持好但难以在实际推理中获得加速。 在实践中，我们发现幅度剪枝在30%稀疏度以下几乎无损，但超过50%后精度急剧下降。对于端侧部署，30%的结构化剪枝加上INT4量化是一个不错的平衡点。 蒸馏 知识蒸馏用大模型训练小模型，让小模型在保持紧凑的同时获得接近大模型的能力。我们使用了一个7B模型作为teacher蒸馏出1.5B的student模型。关键技巧包括：使用中间层特征匹配而非仅匹配输出logits、采用渐进式蒸馏从易到难、以及使用大模型生成的合成数据增强训练集。 推理引擎优化 模型压缩只是第一步，推理引擎的优化同样关键。 KV Cache管理 在端侧设备上，内存是稀缺资源。一个1.5B模型在INT4量化下约占800MB，但生成1024个token的KV Cache可能需要额外的600MB。我们实现了动态KV Cache管理：根据可用内存动态调整缓存大小，在内存不足时采用滑动窗口策略丢弃最早的KV。 计算图优化 将模型转换为移动端推理格式后，计算图优化可以带来显著加速。关键技术包括：算子融合（将连续的矩阵乘法和激活函数融合为单个算子）、内存复用（重用中间张量的内存空间）、以及常量折叠（在编译期计算常量表达式）。 我们使用ONNX Runtime作为端侧推理引擎，其内置的图优化pass在我们的测试中带来了约40%的推理加速。 NPU加速 现代手机的NPU是端侧AI的杀手锏。与CPU相比，NPU在矩阵运算上的能效比高出10倍以上。但NPU的编程模型比CPU复杂得多——需要将模型转换为NPU支持的算子集合，不支持的算子会fallback到CPU，造成性能损失。 我们花了大量时间在算子适配上：将模型中的所有算子映射到高通Hexagon NPU支持的指令集，仅保留3个无法替换的算子在CPU上运行。最终NPU利用率达到95%以上。 实际性能 经过全栈优化，我们在骁龙8 Gen 3平台上部署了一个1.5B参数的INT4量化模型： 模型体积：850MB 内存占用：1.2GB（含KV Cache） 生成速度：18 tokens/s 功耗：2.8W 首token延迟：380ms 这个性能水平已经可以支撑大多数端侧AI应用——从智能助手到文档摘要，从实时翻译到照片描述。 结语 端侧AI不是云端AI的替代品，而是互补品。未来的AI应用将是端云协同的——简单任务在端侧即时处理，复杂任务卸载到云端。端侧AI的发展正在缩小与云端模型的差距，而隐私和延迟优势是其不可替代的护城河。 本文同步发布于 硅基AGI论坛

量化部署决策树 是否在H100上部署？ ├─ 是 → FP8量化（原生加速，精度最佳） └─ 否 → 显存是否足够FP16？ ├─ 是 → FP16（无精度损失） └─ 否 → INT8还是INT4？ ├─ 精度要求高 → INT8 (W8A8) └─ 显存优先 → INT4 (GPTQ/AWQ) GPTQ量化 # 使用AutoGPTQ进行量化 from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig # 量化配置 quantize_config = BaseQuantizeConfig( bits=4, # 4-bit量化 group_size=128, # 分组大小 desc_act=False, # 是否按激活降序排列 ) # 准备校准数据 calibration_data = load_calibration_dataset(n_samples=128, max_length=512) # 加载模型并量化 model = AutoGPTQForCausalLM.from_pretrained( "Qwen/Qwen3-32B", quantize_config, ) model.quantize(calibration_data) # 保存量化模型 model.save_quantized("./qwen3-32b-gptq-4bit") AWQ量化 # 使用AutoAWQ进行量化 from awq import AutoAWQForCausalLM model = AutoAWQForCausalLM.from_pretrained("Qwen/Qwen3-32B") quant_config = { "zero_point": True, "q_group_size": 128, "w_bit": 4, "version": "GEMM" } model.quantize( calibration_data, quant_config=quant_config ) model.save_quantized("./qwen3-32b-awq-4bit") vLLM部署量化模型 # GPTQ模型部署 vllm serve ./qwen3-32b-gptq-4bit \ --quantization gptq \ --dtype float16 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 # AWQ模型部署 vllm serve ./qwen3-32b-awq-4bit \ --quantization awq \ --dtype float16 \ --max-model-len 8192 # FP8模型部署（H100） vllm serve ./model \ --quantization fp8 \ --kv-cache-dtype fp8 Ollama部署 # 从GGUF文件创建Ollama模型 cat > Modelfile <<EOF FROM ./qwen3-32b-q4_k_m.gguf PARAMETER num_ctx 8192 PARAMETER temperature 0.7 EOF ollama create my-qwen -f Modelfile ollama run my-qwen 量化效果对比 以Qwen3-32B为例（单卡A100 80GB）： ...