量化

推理优化的核心矛盾 大模型推理面临一个核心矛盾：用户需要低延迟和高吞吐，但自回归生成天然是串行的。每生成一个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由于需要额外的反量化步骤，速度略慢。 ...

量化：让大模型跑得起的关键技术 大模型的推理成本是落地的最大障碍之一。一个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由于需要额外的反量化步骤，速度略慢。 ...

量化部署决策树 是否在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）： ...

引言 模型量化是LLM部署中最重要的优化手段之一。通过降低模型参数的精度，可以大幅减少显存占用和提升推理速度。但量化也带来了精度损失的代价。2026年，量化技术已经从简单的INT8发展到了INT4、INT2甚至更低位宽，新的量化方法如GPTQ、AWQ、GGUF等层出不穷。本文将通过实测数据揭示量化对性能的真实影响。 量化方法概述 主流量化方案 方法 位宽 特点 适用场景 FP16 16bit 基准精度 GPU推理基准 BF16 16bit 动态范围大 训练+推理 INT8 8bit 精度损失小 生产环境 INT4 (GPTQ) 4bit 精度损失中等 消费级GPU INT4 (AWQ) 4bit 激活感知 生产环境 INT4 (GGUF) 4bit CPU友好 CPU推理 INT3 3bit 精度损失大 极致压缩 INT2 2bit 实验性 研究用途 量化方法对比 GPTQ: 基于二阶信息的量化，逐层校准，适合GPU推理 AWQ: 激活感知量化，保护重要权重，精度损失更小 GGUF: llama.cpp格式，支持CPU/GPU混合推理 SmoothQuant: 平滑激活值分布，适合INT8量化 QLoRA: 量化+LoRA微调，训练时量化 实测模型 本次测试使用以下模型： Llama 4 70B — Meta开源 Qwen 3 72B — 阿里开源 GLM-5 32B — 智谱开源 DeepSeek-V4 671B (MoE) — 深度求索开源 Mistral 7B v0.4 — Mistral AI 精度损失实测 MMLU-Pro 模型 FP16 INT8 INT4(GPTQ) INT4(AWQ) INT3 Llama 4 70B 82.1% 81.3%(-0.8) 78.5%(-3.6) 79.8%(-2.3) 72.3%(-9.8) Qwen 3 72B 84.5% 83.7%(-0.8) 81.2%(-3.3) 82.1%(-2.4) 75.6%(-8.9) GLM-5 32B 86.2% 85.3%(-0.9) 82.5%(-3.7) 83.8%(-2.4) 76.8%(-9.4) DeepSeek-V4 85.8% 85.1%(-0.7) 82.3%(-3.5) 83.5%(-2.3) 76.2%(-9.6) Mistral 7B 65.2% 64.3%(-0.9) 61.5%(-3.7) 62.8%(-2.4) 55.3%(-9.9) 关键发现： ...

量化：用更少的比特做更多的事 LLM的参数量从7B到671B不断增长，但GPU显存的增长速度远跟不上。量化是缓解这一矛盾最直接的技术——用更少的比特表示模型参数和激活值，在不修改模型架构的前提下减少显存占用和加速推理。 2026年，量化技术已经形成了从INT4到FP8的完整谱系，每种精度都有其适用场景和工程权衡。 量化的基本原理 对称量化 将浮点数映射到整数的固定范围。以INT8为例： x_int8 = round(x_fp / scale) scale = max(|x_fp|) / 127 反量化：x_fp ≈ x_int8 × scale 非对称量化 引入零点偏移，处理分布不对称的情况： x_int8 = round((x_fp - zero_point) / scale) scale = (max(x) - min(x)) / 255 zero_point = min(x) 量化粒度 逐张量（per-tensor）：整个张量共用一个scale，最简单但精度损失大 逐通道（per-channel）：每个输出通道一个scale，精度好但额外参数多 逐组（per-group）：将通道分组，组内共用scale，是精度和效率的折中 def per_group_quantize(x, group_size=128): """分组量化""" original_shape = x.shape # 重排为 [out_features // group_size, group_size, in_features] x_reshaped = x.view(-1, group_size, original_shape[-1]) # 每组计算独立的scale scales = x_reshaped.abs().max(dim=1, keepdim=True).values / 127 # 量化 x_int8 = (x_reshaped / scales).round().clamp(-128, 127).to(torch.int8) return x_int8, scales def per_group_dequantize(x_int8, scales, original_shape): """分组反量化""" x_fp = x_int8.float() * scales return x_reshaped.view(original_shape) INT8量化 适用场景 INT8是最成熟的量化方案，几乎所有推理框架都原生支持。适用于： ...

引言 大模型的量化（Quantization）是将高精度浮点模型转换为低精度表示的技术。2026年，INT4量化已经从"实验性技术"成为"生产级方案"，让70B参数模型在消费级GPU上运行成为可能。 量化技术分类 按训练方式分类 量化方法 ├── 训练后量化（PTQ） │ ├── PTQ-W（权重量化） │ └── PTQ-A（激活量化） ├── 校准量化（Calibration-based） │ ├── LLM.int8() │ └── SmoothQuant ├── 感知量化（Aware Quantization） │ ├── AWQ（Activation-Aware） │ ├── GPTQ（Greedy Post-Training） │ └── QoQ（Quantization-out-of-Context） └── 量化感知训练（QAT） ├── QAT-F（全量化训练） └── LoRA-QAT（低秩量化） 按量化粒度分类 粒度 说明 精度损失 加速效果 逐层 每层一个缩放因子 低 中 逐通道 每个通道一个缩放因子 低 高 逐组 每组（如128个）一个缩放因子 中 最高 逐元素 每个权重一个缩放因子 高 有限 主流量化方案深度对比 AWQ（Activation-Aware Weight Quantization） 核心思想： 保护对激活值敏感的权重，对这些权重进行更精细的量化。 原理： ...