基于《大规模语言模型：从理论到实践（第2版）》第10章 大语言模型效率优化
爆款小标题：显存不够、延迟太高？原书第10章效率优化与 vLLM 推理实战
为什么这一节重要
大模型推理面临显存占用大、延迟高、吞吐难提升等问题。权重量化（INT8/INT4）可显著减小模型体积与带宽；稀疏化与知识蒸馏可从结构或规模上降本；vLLM 等推理框架则通过 PagedAttention 与连续批处理把吞吐拉高，是当前高并发推理的主流选择之一。原书第 10 章系统讲了这些技术。本节把量化/稀疏/蒸馏的作用与 vLLM 的核心思想讲清，并给出选型与避坑要点，便于你在资源与延迟约束下做出正确决策。
学习目标
- 理解权重量化（如 INT8/INT4）、稀疏化与知识蒸馏在「模型体积与推理速度」上的作用（原书第10章）。
- 掌握 vLLM 等推理框架的连续批处理、PagedAttention 等核心思想。
- 能根据显存与延迟需求初步选择量化方案与推理框架。
一、量化：INT8/INT4 与校准（原书第 10 章）
将权重（或激活）从 FP16/BF16 降到 INT8 或 INT4，可减少显存占用与内存带宽，从而加速推理或允许更大 batch。动态量化按 tensor 或按层统计 min/max 后做线性映射，无需校准集但精度可能略逊；静态量化用校准集（一批代表性输入）统计每层激活的 scale 与 zero_point，再固定用于推理，通常精度更稳。INT4 相比 FP16 权重大致可降到约 1/4（4 bit vs 16 bit），显存与带宽压力明显下降；但需注意精度损失与校准质量，部分模型或任务（如长文本、复杂推理）对量化敏感，需在目标任务上做效果与延迟对比，避免「理论上省显存、效果崩了」。原书第 10 章对量化方法、校准流程与常见问题有进一步说明。
常见量化方案：AWQ、GPTQ 等针对 LLM 的量化方法在保持精度的同时进一步压缩；GGUF 等格式支持多种量化等级（Q4、Q5、Q8 等）的模型存储与加载。选型时需结合框架支持（如 vLLM、llama.cpp）与目标任务上的实测效果，不同模型对同一量化方法的敏感度不同。
推理时显存的影响因素：除权重大小外，KV Cache（与 batch、序列长度成正比）、激活（与 batch、序列长度相关）同样占显存。量化主要减小权重与部分激活，KV Cache 通常仍为 FP16/BF16，长序列或大 batch 时 KV Cache 可能成为瓶颈；vLLM 的 PagedAttention 即针对 KV Cache 做优化。单次推理显存 ≈ 模型权重 + KV Cache × batch × seq_len × 2（K 和 V）× 每元素字节数，估算容量时需同时考虑权重与 KV Cache。
二、稀疏化与知识蒸馏（原书第 10 章）
稀疏化（Sparsity）：通过剪枝将部分权重置零，减少计算量与显存。非结构化剪枝按元素置零，压缩率高但需要稀疏计算库支持；结构化剪枝按通道、块或头置零，便于在通用硬件上加速。稀疏化常与量化组合使用，先剪枝再量化，进一步压缩。原书第 10 章对稀疏化的典型做法与效果有讨论。
知识蒸馏：用**大模型（教师）的输出来指导小模型（学生）**训练——学生拟合教师的 logits、隐藏状态或生成分布，从而在较小参数量下保持一定能力。蒸馏后的小模型推理更快、显存更小，适合延迟敏感或资源受限场景；代价是能力通常弱于教师，需根据业务在「效果」与「效率」间权衡。
三、vLLM：PagedAttention 与连续批处理（原书第 10 章）
PagedAttention：传统实现中，KV Cache 按请求连续分配，不同请求的生成长度不同会导致显存碎片（已完成请求释放的块难以被新请求复用）。vLLM 将 KV Cache 按固定大小「块」管理，类似操作系统虚拟内存分页，不同请求可共享物理块池，减少碎片并提高显存利用率，从而在相同显存下支持更长序列或更大 batch。原书第 10 章将 vLLM 作为高并发推理的代表框架介绍。
连续批处理（Continuous Batching）：传统静态批处理需等一批请求凑齐后再一起解码，请求到达时间不同、生成长度不同时，会出现「早到的等晚到的、短序列等长序列」，GPU 利用率与用户体验都受影响。连续批处理允许新请求随时加入、已完成序列随时释放，不等待整批；调度器在每个时间步选择「当前最值得算」的一组 token，使 GPU 持续满载，吞吐显著提升。在「请求到达分散、生成长度不一」的在线场景下，连续批处理相比静态批处理在吞吐与 P99 延迟上通常更有优势。原书第 10 章对 vLLM 的调度与批处理有进一步说明。
四、案例：vLLM 部署与量化实操步骤
完整可运行脚本（依赖：pip install vllm）：
#!/bin/bash
# 用法：bash vllm_deploy.sh 或 MODEL=Qwen/Qwen2-7B-Instruct bash vllm_deploy.sh
set -e
python -c "import vllm" 2>/dev/null || { echo "请先安装: pip install vllm"; exit 1; }
MODEL=${MODEL:-"Qwen/Qwen2-0.5B-Instruct"}
echo "启动模型: $MODEL"
python -m vllm.entrypoints.openai.api_server \
--model "$MODEL" \
--tensor-parallel-size 1 \
--max-model-len 2048 \
--gpu-memory-utilization 0.9
# 另开终端调用：curl http://localhost:8000/v1/completions -H "Content-Type: application/json" -d '{"model":"'$MODEL'","prompt":"你好","max_tokens":64}'
预量化模型加 --quantization awq；调 --max-num-seqs、--gpu-memory-utilization 优化吞吐与显存。
五、工程实战要点
1. 量化后的验证
量化后务必在目标任务上做精度与延迟对比，避免「理论上省显存、效果崩了」。建议用业务相关的评估集（如客服问答、代码补全）跑一遍，对比量化前后的准确率、BLEU 等；同时测延迟与吞吐，确认量化带来的加速在实际部署中能体现。
2. 首 token 延迟 vs 吞吐
部署时区分「首 token 延迟」与「吞吐」，不同业务对二者要求不同。交互式对话更关注首 token 延迟（用户等待感）；批量任务更关注吞吐（单位时间处理量）。vLLM 等框架通过连续批处理提升吞吐，但首 token 延迟可能受 batch 内其他请求影响；需根据业务做 batch size、实例数等配置的权衡。
3. 量化与框架的兼容
不同推理框架对量化格式的支持不同：vLLM 支持 AWQ、GPTQ 等；llama.cpp 支持 GGUF；Hugging Face 的 transformers 支持 bitsandbytes 等。选型时需确认目标框架是否支持你的量化格式，以及是否有针对该格式的优化（如 fused kernel）。
六、常见误区 & 避坑指南
- 误区：无脑 INT4。避坑：部分模型或任务对量化敏感，需做小规模验证。
- 误区：只看单次推理延迟。避坑：批处理与连续批处理会显著影响吞吐，需按业务压测。
课后思考题
- 若将 7B 模型从 FP16 量化为 INT4，理论上权重大约变为原来的多少？推理时除了权重大小，还有哪些因素影响显存？
- 「连续批处理」与「静态批处理」在「请求到达时间不同」的场景下，对吞吐与延迟各有什么影响？
