量化

7B模型的能力边界 日常问答：完全够用 代码补全：优秀 简单代码生成：可用 复杂推理：吃力 长文档理解：勉强 优势 本地部署：消费级显卡可跑 速度快：比大模型快10倍 成本低：几乎零成本 隐私好：数据不出本机 应用场景 个人助理 边缘设备 高频简单任务 数据敏感场景 结论 不是所有任务都需要大模型。正确做法：任务路由——简单任务用小模型，复杂任务用大模型。

边缘AI优势 数据不出设备，隐私好 不需要网络，离线可用 延迟低 没有API费用 现状 7B模型量化后可在旗舰手机运行 端侧AI助手正在成为标配 苹果、华为、高通都在推 局限 模型能力不如云端大模型 复杂任务还是要调云端 占用手机存储

为什么本地部署突然香了 2026年本地大模型能跑生产环境，靠的是三件事： 量化技术成熟（4-bit/3-bit几乎不掉点） 推理框架优化（vLLM、SGLang的吞吐提升10倍） 开源模型追上来了（Qwen3、DeepSeek V4本地版） 硬件选型 场景 推荐配置 成本 个人开发 RTX 4090 24GB 1.5万 团队部署 2×A100 80GB 20万 CPU推理 至强+128GB内存 3万 部署流程 选模型：Qwen3-72B-Instruct 或 DeepSeek-V4-70B 量化：AWQ 4-bit，质量损失<2% 框架：vLLM，连续批处理 接入：OpenAI兼容API，直接对接现有应用 踩坑记录 KV Cache管理是吞吐关键，max_model_len不要设太大 多轮对话要自己管理history，框架不管 量化后有些推理能力会下降，代码模型建议保留更多精度

引言：为什么需要量化？ 大语言模型的参数量和计算量呈指数级增长。一个72B模型在FP16精度下需要约144GB显存，而通过INT4量化可压缩至约36GB——单卡A100 80GB即可运行。量化已成为大模型部署的必经环节，但不同的量化方案在精度、速度和硬件兼容性上差异显著。 三大量化方案原理 INT8量化 INT8将FP16的权重映射到[-128, 127]的整数范围。核心思想是通过缩放因子（scale）和零点（zero point）将浮点数线性映射到整数空间： 量化： q = round(w / scale) + zero_point 反量化：w = scale * (q - zero_point) INT8是一种"安全"的量化方案，几乎所有主流GPU（Ampere及以上）都原生支持INT8矩阵乘法（通过Tensor Core）。 INT4量化 INT4将权重压缩到4位整数，范围仅为[-8, 7]。这意味着每个参数仅占0.5字节，相比FP16压缩了8倍。INT4通常采用分组量化（Group-wise Quantization）策略，每32或64个参数共享一组缩放因子： # INT4分组量化示例（伪代码） import torch def quantize_int4(weight, group_size=64): # 将权重按group_size分组 original_shape = weight.shape weight = weight.reshape(-1, group_size) # 计算每组的缩放因子 w_max = weight.abs().max(dim=-1, keepdim=True).values scale = w_max / 7.0 # INT4范围: [-8, 7] # 量化 q_weight = torch.round(weight / scale).clamp(-8, 7).to(torch.int8) return q_weight, scale # 反量化 def dequantize_int4(q_weight, scale): return (q_weight.float() * scale).reshape(original_shape) FP8量化 FP8是2024年起逐渐成熟的新一代低精度格式，采用浮点数而非整数表示。主流有两种格式： 格式 指数位 尾数位 范围 精度 E4M3 4 3 ±448 较高精度 E5M2 5 2 ±57344 较大范围 FP8的优势在于保留了浮点数的动态范围，对异常值更鲁棒，且NVIDIA Hopper/Blackwell架构原生支持FP8 Tensor Core。 ...

引言：小模型的时代来了 2026年，一个反直觉的趋势正在发生：参数量1B-7B的小模型正在快速蚕食大模型的应用场景。Phi-4-mini、Qwen3-4B、Gemma 3-2B等模型在经过精心训练和量化后，能力已经超越了2023年的70B级模型。更重要的是——它们能在手机、笔记本、甚至Raspberry Pi上运行。 小模型能力跃升的秘密 1. 高质量合成数据训练 微软Phi系列率先证明了"数据质量比数据量更重要"的理念。Phi-4-mini仅3.8B参数，却通过精心筛选的合成数据训练，在MMLU上达到了72.4分，超过了2023年的Llama 2-70B。 2. 知识蒸馏 从大模型向小模型蒸馏知识，是提升小模型能力的核心手段： # 知识蒸馏简化示例 - 从Qwen3-72B蒸馏到Qwen3-4B import torch from transformers import AutoModelForCausalLM, AutoTokenizer teacher = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3-72B") student = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3-4B") # 蒸馏损失函数 def distillation_loss(student_logits, teacher_logits, labels, alpha=0.7, temperature=2.0): # KL散度损失 - 学习教师的软标签 kl_loss = torch.nn.functional.kl_div( torch.nn.functional.log_softmax(student_logits / temperature, dim=-1), torch.nn.functional.softmax(teacher_logits / temperature, dim=-1), reduction="batchmean", ) * (temperature ** 2) # 标准交叉熵损失 ce_loss = torch.nn.functional.cross_entropy( student_logits.view(-1, student_logits.size(-1)), labels.view(-1) ) return alpha * kl_loss + (1 - alpha) * ce_loss 3. 架构优化 小模型采用了多项架构创新来提升效率： GQA（分组查询注意力）：减少KV缓存内存占用 RoPE扩展：支持更长上下文 SwiGLU激活：比传统ReLU更高效 边缘端部署性能对比 模型 参数量 INT4量化后大小 手机端推理速度 MMLU分数 Phi-4-mini 3.8B 2.1GB 18 tokens/s 72.4 Qwen3-4B 4.0B 2.3GB 16 tokens/s 74.1 Gemma3-2B 2.0B 1.4GB 32 tokens/s 68.3 Llama4-1B 1.2B 0.8GB 55 tokens/s 59.7 测试设备：iPhone 16 Pro（A18 Pro芯片），MLX推理框架 ...

推理优化的核心矛盾 大模型推理面临一个核心矛盾：用户需要低延迟和高吞吐，但自回归生成天然是串行的。每生成一个token都需要完整的前向传播，而KV Cache的显存占用随序列长度线性增长。本文系统梳理当前主流的推理优化技术。 KV Cache优化 KV Cache的工作原理 在自回归生成中，前面token的Key和Value可以缓存复用，避免重复计算。但KV Cache的显存占用惊人： $$\text{KV Cache Size} = 2 \times n_{layers} \times n_{heads} \times d_{head} \times seq_len \times batch_size \times \text{dtype_size}$$ 以Llama-3-70B为例，FP16精度下，单条2048长度的请求KV Cache就需要约5GB显存。 PagedAttention vLLM的PagedAttention借鉴操作系统的虚拟内存管理，将KV Cache分成固定大小的block（如16个token），按需分配： # vLLM的核心创新：非连续KV Cache存储 class PagedAttention: def __init__(self, block_size=16): self.block_size = block_size self.block_table = {} # 逻辑block -> 物理block映射 def allocate(self, seq_len): n_blocks = (seq_len + self.block_size - 1) // self.block_size return [self._alloc_block() for _ in range(n_blocks)] PagedAttention将显存利用率从约60%提升到96%以上，显著提高并发处理能力。 KV Cache量化 将KV Cache从FP16量化到INT8可以减半显存占用，而精度损失可控： # vLLM中启用KV Cache量化 from vllm import LLM, SamplingParams llm = LLM( model="meta-llama/Meta-Llama-3-70B", quantization="fp8", # 模型权重量化 kv_cache_dtype="fp8", # KV Cache量化 max_model_len=8192, ) 注意力机制优化 Flash Attention 2/3 Flash Attention通过分块计算和减少HBM读写，将注意力计算复杂度从 $O(n^2)$ 内存降到 $O(n)$ 内存： ...

大模型越来越大，但部署环境千差万别。不是每台设备都有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）：训练后量化，无需重新训练 ...

端侧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论坛

量化：让大模型跑得起的关键技术 大模型的推理成本是落地的最大障碍之一。一个70B参数的模型在FP16精度下需要约140GB显存，而INT4量化只需要约35GB——直接让单卡部署成为可能。 但量化不是免费的午餐。精度降低必然带来质量损失，问题是损失多少、哪种方案损失最小。我们在统一环境下对三种主流量化方案进行了系统对比。 三种方案简介 GPTQ：基于二阶Hessian信息的后训练量化方法。通过逐层补偿量化误差来保持模型质量。优势是不需要校准数据量太大，劣势是量化过程较慢。 AWQ（Activation-aware Weight Quantization）：通过分析激活值分布来识别"重要"权重，对重要权重保持高精度，非重要权重进行量化。核心洞察是并非所有权重对模型输出的贡献相同。 INT4（含NF4/FP4变体）：将权重压缩到4比特。NF4（NormalFloat 4）由QLoRA提出，针对正态分布的权重进行了优化。FP4则保留了浮点数的指数-尾数结构。 测试设置 硬件：单张A100 80GB 模型：Llama-3-70B、Qwen-2.5-72B、Mistral-Large 基准：FP16未量化版本 评估数据集：MMLU、HumanEval、GSM8K、C-Eval 测试场景：单序列推理和批量推理 核心结果 质量对比 方案 MMLU HumanEval GSM8K C-Eval 平均损失 FP16 82.1 74.4 88.3 85.7 0% AWQ-INT4 80.8 72.1 86.1 84.3 ~2.0% GPTQ-INT4 80.3 71.5 85.7 83.9 ~2.6% NF4 81.2 72.8 86.9 84.6 ~1.6% INT4-naive 76.5 66.2 80.1 79.3 ~7.8% NF4在质量保持上略优于AWQ和GPTQ，但差异在统计意义上并不显著（除naive INT4外）。三种成熟方案的损失都控制在3%以内，对于大多数应用场景完全可接受。 速度对比 方案 单序列(tokens/s) 批量32(tokens/s) 首Token延迟(ms) FP16 45.2 820 120 AWQ-INT4 112.5 2100 65 GPTQ-INT4 98.3 1850 78 NF4 105.7 1950 70 AWQ在推理速度上领先，这得益于其更优化的内核实现（vLLM的AWQ后端经过深度优化）。GPTQ由于需要额外的反量化步骤，速度略慢。 ...