模型量化:GGUF/AWQ/GPTQ部署方案专栏:AI/LLM工程化实战 - 从Prompt到Agent的完整落地指南模块6 模型微调与部署篇 第61篇摘要摘要:模型量化把FP16权重压到INT47B模型显存从14GB降到4GBGGUF、AWQ、GPTQ三种方案各管一块地盘本文讲透量化原理、精度损失实测和选型方法附llama.cpp、AutoAWQ、GPTQ三份完整代码本专栏限时¥59.90(原价¥99)TL;DR 核心要点速览FP16的7B模型权重占14GB显存INT8砍到7GBINT4砍到3.5GB这是量化的全部动机GGUF是llama.cpp的专属格式CPU和GPU混合推理Ollama、llama-cpp-python都吃这个格式AWQ按激活值感知保留重要通道INT4精度接近FP16vLLM和SGLang原生支持GPTQ用Hessian矩阵补偿逐层量化误差transformers一行from_pretrained就能加载我的客服场景实测:意图识别准确率FP16为97.8%AWQ INT4为96.9%GPTQ INT4为96.2%GGUF Q4_K_M为95.8%7B模型INT4量化后推理速度基本不掉vLLM场景下吞吐还能比FP16高5%到10%代码生成和数学任务量化后掉点多常识问答掉点少上线前按任务类型实测校准数据几百条就够但分布必须贴近线上输入用通用语料校准中文场景会明显掉点本专栏限时¥59.90(原价¥99)开篇故事:一张24GB显卡装不下7B模型我所在的公司做电商客服机器人模型方案定的是Qwen2.5-7B-Instruct买了A10 24GB的云GPU。第一天部署就出事了transformers加载FP16权重光权重就吃14GB再加上激活和KV cache上下文超过2000个token就OOM服务反复重启。我翻着部署日志想骂人7B的模型配上24GB的卡按账面上算绰绰有余实际跑起来却连基本对话都撑不住。运维同事在旁边说了一句把模型量化了再上线隔壁组用INT4跑同样的模型4GB权重加8GB KV cache稳得很。当天下午我把模型换成GGUF的Q4_K_M版本A10上跑起来上下文开到8192都不慌。从那次开始我才认真把量化原理读了一遍也把GGUF、AWQ、GPTQ三种方案逐一在自家任务上做了对比实验。这篇文章就是那段时间踩坑和实测的完整记录。回头看那次事故教训就一句话部署前先算显存账。权重、KV cache、并发余量三样一起算缺一样都会在线上出事。量化把这道账算简单了14GB的权重变成4GB剩下的空间全部变成业务的缓冲。后来我们组把这个经验固化成模板所有模型部署前先填一张显存预算表量化与否由这张表决定不再靠临场拍脑袋。一、量化原理:FP16到INT8/INT4发生了什么1.1 先算一笔显存账一个FP16数字占2字节INT8占1字节INT4占0.5字节。70亿参数的模型权重部分是70亿乘2字节约13GB业界习惯叫14GB。换成INT8是7GBINT4是3.5GB。显存需求一路腰斩。推理时显存有三块开销权重、激活值、KV cache。权重省下来的空间直接变成KV cache的余量上下文长度就能翻好几倍。我遇到的OOM就是权重挤占了KV cache的空间量化之后同一张卡能装的并发和上下文完全不是一个量级。KV cache的规模可以估。7B模型每层KV维度是4096乘2按32层、FP16算每个token约占0.5MB2048个token的上下文就是1GB。做服务端容量规划时KV cache按峰值上下文长度乘并发数来算这部分常常比权重还占地方。量化权重等于给KV cache腾位置这也是INT4在服务端高并发场景下收益最大的原因。1.2 量化映射一张图讲清楚量化做的事是拿一个低位宽的整数去近似一个高位宽的浮点数。公式是这样。q clamp(round(x / scale) zero_point, 0, 2^bits - 1)反量化恢复近似值。x_hat (q - zero_point) * scalescale由权重范围决定。INT4下2^bits减1等于15如果权重范围是[-1, 1]scale等于2除以15约0.133。权重0.5量化成4反量化回来是0.53误差0.03。权重范围越大scale越大舍入误差越明显。所以量化之前先做一次分布统计把异常值截掉比什么都管用。误差有两类来源。一类是舍入误差连续值落到离散整数格子上。另一类是截断误差超出范围的数值被clamp掐掉。两类误差叠加就是量化模型掉点的来源。1.3 校准数据是精度的天花板AWQ和GPTQ这类方案要靠一小批校准数据统计激活分布决定哪些通道值得保留更高精度。校准数据一般几百条就够不需要标注普通文本就行。但分布必须贴近线上真实输入。我踩的第一个坑就在这用英文通用语料c4校准部署中文客服场景意图识别准确率从97.8%掉到93.1%掉了近5个点。换成公司真实客服对话的prompt做校准集准确率回到96.9%。同样的模型、同样的位宽校准数据换一批结果差4个点。校准数据选得对不对直接决定量化精度的上限。校准数据的实操流程我固定走三步。采样从生产日志里按意图类型分层抽500条保证每个业务方向都有覆盖。清洗去掉重复、截断、包含敏感信息的样本长度控制在512 token以内。检查跑一遍统计确认高频词和线上一致比如客服场景里退货物流这类词要高频出现。三步做完才开始量化。1.4 量化粒度:按多少权重共享一个scalescale和zero_point不是每个权重都单独存的那样存储开销等于没量化。常见三种粒度。per-tensor整层权重共享一个scale存储开销最小精度最差。per-channel按输出通道共享精度中等。per-group把通道内每128个权重分成一组各组独立scale精度最高。group越小越精细但scale也要多存。128一组是工程上最常用的平衡点AWQ、GPTQ默认都是这个值。1.5 离群值:量化精度的隐形杀手大模型的权重分布有个特点大部分值集中在0附近的小区间但存在少量绝对值很大的离群权重。这些离群值会把scale撑大其余权重全部被压扁精度损失集中爆发。处理手法有几种。先做clip把分布两端1%的极端值截掉再算scale能显著改善。AWQ更进一步对含离群值的通道做额外缩放把整数格子的利用效率拉高。我实测过同一模型不处理离群值INT4掉4.2个点做完clip只掉2.3个点。量化工具链默认都做了这层处理自己手写量化时必须补上这一步不然结果差一大截。1.6 量化到多少位宽才够用INT8损失很小普遍掉0.5个点以内适合对精度敏感的金融、医疗场景。INT4是性价比甜点区掉1到3个点显存只剩四分之一。INT3和INT2看着诱人7B模型压到2GB以内但输出质量明显崩代码生成基本没法用。我见过一个团队为了塞进8GB显存的卡用INT2上线当天就被用户投诉第二天换回INT4。位宽选择要按任务容忍度来别按显卡容量来。1.7 激活值量化:另一条线权重量化解决的是加载和存储推理时激活值仍然是FP16。激活值量化是独立的方向把中间计算结果也压到INT8甚至FP8主要收益在推理时减少显存带宽压力。NVIDIA的FP8推理和KV cache量化都属于这条线。对7B这个规模激活值量化的收益远小于权重量化前者省几个百分点显存后者直接省四分之三。做工程决策时优先做权重量化激活值量化等权重方案定了再评估两条线别混在一起判断。给个参考70B以上模型和长上下文场景KV cache量化才有明显回报7B单卡场景可以先不碰。二、GGUF/AWQ/GPTQ三种方案对比2.1 GGUF:llama.cpp的随身格式GGUF是llama.cpp项目定义的文件格式一个文件里打包了权重、tokenizer、chat模板和超参数拷到哪都能跑。它的量化方式是纯权重量化分Q2_K、Q4_K_M、Q6_K、Q8_0等档位Q4_K_M是最常用的平衡档。档位选择有规律Q8_0接近INT8精度权重体积约8GBQ4_K_M精度和体积的平衡点Q2_K体积最小但输出质量明显下降。个人使用从Q4_K_M起步显存富余再往上加档位。优势在CPU推理和混合推理没有GPU也能跑M系列芯片上速度还不错。劣势是GPU推理框架不认它vLLM、TGI都不直接加载GGUF要转格式。2.2 AWQ:激活感知的后来者AWQ全称Activation-aware Weight Quantization思路和别的方案不一样。它观察校准数据跑过模型后的激活值分布发现权重不是同等重要少部分通道对激活贡献大。量化时保留这些重要通道的高精度其余通道才压到INT4。实测精度损失是三家里最小的代码生成和数学这类敏感任务上优势更明显。vLLM、SGLang、TensorRT-LLM原生支持AWQ生产环境GPU推理首选的量化格式。2.3 GPTQ:老牌通用方案GPTQ是逐层做权重量化每量化完一层用Hessian矩阵补偿误差把误差往后面的层推整体损失最小化。它是2023年的方案社区积累的GPTQ模型最多HuggingFace上带GPTQ后缀的仓库一抓一大把。transformers原生支持加载AutoGPTQ负责量化。精度和速度跟AWQ在同一水平略逊一点点。2.4 三方对比表维度GGUFAWQGPTQ量化方式纯权重量化K-quants多档位激活感知按通道缩放权重逐层加Hessian补偿适用框架llama.cpp、llama-cpp-python、OllamavLLM、SGLang、TensorRT-LLMtransformers、AutoGPTQ、vLLM精度损失中等Q4_K_M实测掉2到4个点最小接近FP16较小推理速度CPU可跑GPU推理比AWQ/GPTQ略低GPU推理快vLLM吞吐最高GPU推理快内存占用最低权重可放CPU内存低约FP16的四分之一低约FP16的四分之一适用场景个人电脑、Mac、边缘设备、单机小工具生产高并发GPU服务transformers生态、微调后快速部署2.5 生态与迁移成本选方案还要算一笔迁移账。GGUF的生态在个人工具链Ollama、LM Studio、llama.cpp全套围绕它转换到生产GPU服务就要转格式多一道工序。AWQ和GPTQ在服务端框架里的支持度互有重叠vLLM两个都认TGI更偏向GPTQ和自有量化格式。如果你的模型来自HuggingFace社区GPTQ仓库最多省掉自己量化的时间。如果你的模型是自己微调的AWQ的量化流程最顺手因为AutoAWQ直接吃transformers模型目录。我现在的团队默认组合是微调模型加AWQ社区现成模型加GPTQ本地调试加GGUF三条线互不打架。这个组合还有一个好处三种格式之间用统一脚本互转safetensors转GGUF再转回流程都是现成的工具链团队里任何一个人接手都能跑通。三、用llama.cpp跑GGUF推理llama.cpp提供Python绑定llama-cpp-python装完就能加载GGUF文件跑推理。Windows环境建议直接装预编译wheel避免本地编译要装MSVC的麻烦。下载模型用huggingface-cli选q4_k_m的单文件版本就行。# run_gguf.py# llama.cpp加载GGUF模型跑推理的完整脚本# 安装: pip install llama-cpp-python huggingface-hub# 下载模型: huggingface-cli download Qwen/Qwen2.5-7B-Instruct-GGUF \# --include *q4_k_m.gguf --local-dir ./models# 生成的qwen2.5-7b-instruct-q4_k_m.gguf约4.4GBfromllama_cppimportLlama# 模型路径指向刚下载的gguf单文件# n_ctx2048控制上下文窗口,调大会多占内存# n_gpu_layers-1表示全部层放GPU,CPU推理填0即可llmLlama(model_path./models/qwen2.5-7b-instruct-q4_k_m.gguf,n_ctx2048,n_gpu_layers-1,verboseFalse,# 关掉启动日志,只留推理结果)prompt用一句话解释什么是模型量化,控制在30字以内# create_chat_completion走llama.cpp内置的chat模板# Qwen的模板会自动拼system和user消息resllm.create_chat_completion(messages[{role:user,content:prompt}],temperature0.7,# 采样温度,0.7适合对话max_tokens256,# 限制生成长度,避免失控输出)# 取第一条候选的回复内容answerres[choices][0][message][content]print(回答:,answer)# usage里带completion_tokens,可用来估算每秒速度tokensres.get(usage,{}).get(completion_tokens,0)print(生成了,tokens,个token)我在这台机器上跑过对比。纯CPU推理i9-13900K跑7B的Q4_K_M约12 token/s写一段500字的回答要等40秒个人工具能接受生产环境绝对不行。GPU加速后同样的模型到55到65 token/s跟未量化的FP16模型差距在5%以内。这个结论很重要量化换来的主要是内存和带宽计算能力基本没变。llama.cpp的显存占用也可以量化着看。7B的Q4_K_M权重4.4GBn_ctx开2048时KV cache约0.5GB加上计算缓冲整体5.5GB出头。8GB显存的笔记本显卡能完整放进去这是很多个人开发者把GGUF当首选的原因。n_ctx开到8192KV cache涨到2GB左右显存不够时llama.cpp会自发把一部分层放到CPU速度掉一半但不会崩。llama-cpp-python还有一个实用姿势跑服务模式一行命令把模型变成OpenAI兼容API。llama-server --model ./models/qwen2.5-7b-instruct-q4_k_m.gguf --port 8080启动后http://localhost:8080/v1就是OpenAI兼容端点开发机上拿它模拟生产接口调试业务代码等上线再切真服务体验一致。GGUF的另一个价值在格式统一。不管是HuggingFace上的原始权重还是第57篇LoRA、第58篇QLoRA微调后合并的模型都能用llama.cpp自带的转换脚本导出成GGUF。转换命令大概长这样。python convert_hf_to_gguf.py ./qwen2.5-7b-instruct --outfile qwen2.5-7b-instruct-f16.gguf导出FP16的GGUF后再用llama-quantize压到目标位宽。这个流程让微调产物和部署格式解耦训练在transformers生态部署在llama.cpp生态两边互不污染。四、AutoAWQ量化一个7B模型下面代码用AutoAWQ把Qwen2.5-7B-Instruct量化成INT4。需要一张20GB以上显存的GPUA10 24GB大概35到45分钟跑完。量化完成后权重约4GB加载占显存接近5GB。# quantize_awq.py# 用AutoAWQ把Qwen2.5-7B-Instruct量化到INT4并保存# 安装: pip install autoawq transformers datasets# 前置: 一张20GB以上显存的GPU,建议先装好CUDA# 产出: ./qwen2.5-7b-awq-int4目录下的4bit权重fromdatasetsimportDatasetfromawqimportAutoAWQForCausalLMfromtransformersimportAutoTokenizer# 量化后的保存目录,后续vLLM/TGI直接加载这个目录quant_path./qwen2.5-7b-awq-int4model_idQwen/Qwen2.5-7B-Instruct# 校准数据选贴近线上场景的prompt,我这里是客服问答# 数量几十条就够,复制扩充到32条,多了收益很小calib_prompts[帮我写一封给客户的道歉邮件,解释一下什么是反向传播,把这段python代码改成java,今天下单什么时候能发货,]*8# 先加载FP16原模型,量化流程跑在GPU上modelAutoAWQForCausalLM.from_pretrained(model_id,device_mapauto,# 自动分配显存)tokenizerAutoTokenizer.from_pretrained(model_id,trust_remote_codeTrue,)# w_bit4是INT4,q_group_size128是分组大小# zero_pointTrue保留零点,精度略高一点quant_config{zero_point:True,q_group_size:128,w_bit:4,version:GEMM,# GEMM通用矩阵乘法,兼容性最好}# 校准数据格式是{text: 内容},一行一条datasetDataset.from_list([{text:s}forsincalib_prompts])# 量化主流程,跑一次约35到45分钟# 期间显卡吃满,别开其他大程序model.quantize(tokenizer,quant_config,calib_datasetdataset,)# 权重和tokenizer一起存下来,方便推理框架加载model.save_quantized(quant_path)tokenizer.save_pretrained(quant_path)print(量化完成,权重保存到,quant_path)量化完成后做一件必做的小事把量化前后两个模型在同一个评测集上跑一遍。我常用的动作是拿50条线上真实问题让两个模型分别回答人工对比打分。别只看困惑度这类指标任务效果才是业务关心的。AWQ量化的结果在客服场景上我实测掉点不到1个点可以直接上线。再给一段加载已量化模型的代码方便复现推理效果。AutoAWQ量化完的目录用transformers直接加载就行权重文件带量化参数框架会自动识别。# load_awq.py# 用transformers加载已量化的AWQ模型做推理# 安装: pip install transformers4.44 autoawqfromtransformersimportAutoModelForCausalLM,AutoTokenizer# 上一段脚本保存的量化目录awq_path./qwen2.5-7b-awq-int4# device_mapauto自动识别AWQ量化并分卡加载modelAutoModelForCausalLM.from_pretrained(awq_path,device_mapauto,)tokenizerAutoTokenizer.from_pretrained(awq_path)# 和FP16模型同一套调用方式,业务代码零改动messages[{role:user,content:今天下单什么时候能发货}]texttokenizer.apply_chat_template(messages,tokenizeFalse,add_generation_promptTrue)inputstokenizer(text,return_tensorspt).to(model.device)outmodel.generate(**inputs,max_new_tokens128)print(tokenizer.decode(out[0][inputs[input_ids].shape[1]:],skip_special_tokensTrue))加载AWQ模型时常见一个报错缺autoawq或版本过老会提示找不到量化模块。解决办法是升级autoawq到最新版再把transformers升到4.44以上。vLLM加载AWQ模型不经过transformers见第62篇的部署流程。五、GPTQ模型加载与推理对比GPTQ模型的加载比量化还简单HuggingFace上现成的仓库直接from_pretrained。transformers从4.44版本开始原生支持GPTQ装了auto-gptq或gptqmodel就行。# load_gptq.py# 用transformers加载GPTQ量化模型做推理对比# 安装: pip install transformers4.44 auto-gptq optimum# 下载模型: huggingface-cli download TheBloke/Qwen2.5-7B-Instruct-GPTQ-Int4 \# --local-dir ./gptq_model# 注意: TheBloke仓库对非英文模型可能改名,按实际名称调整importtorchfromtransformersimportAutoModelForCausalLM,AutoTokenizer# GPTQ仓库的本地路径gptq_path./gptq_model# device_mapauto会自动识别GPTQ量化结构并加载# torch_dtypefloat16是加载量化权重时的常规设置modelAutoModelForCausalLM.from_pretrained(gptq_path,device_mapauto,torch_dtypetorch.float16,)tokenizerAutoTokenizer.from_pretrained(gptq_path)defgenerate(prompt:str,max_new:int128)-str:# 必须走chat模板,不套模板的回答质量差一截msgs[{role:user,content:prompt}]texttokenizer.apply_chat_template(msgs,tokenizeFalse,add_generation_promptTrue,)# 转成输入张量,搬到模型所在设备inputstokenizer(text,return_tensorspt).to(model.device)outmodel.generate(**inputs,max_new_tokensmax_new,do_sampleFalse,# 贪心解码,结果可复现方便对比pad_token_idtokenizer.eos_token_id,)# 只截取新增回答部分,去掉输入prompt的tokennew_tokensout[0][inputs[input_ids].shape[1]:]returntokenizer.decode(new_tokens,skip_special_tokensTrue)# 同一道题,对比GPTQ模型的实际输出print(generate(用一句话解释什么是模型量化))我在客服数据集上做了三方案实测同一批200条意图识别样本。FP16基线准确率97.8%AWQ INT4是96.9%GPTQ INT4是96.2%GGUF Q4_K_M是95.8%。常识问答类任务掉点普遍在1到3个点。代码生成和数学推理掉得更多GSM8K数学题上AWQ掉5到8个点这类任务上线前必须单独评测。再贴一组输出对比同一道推理题三种模型的实际回答差异比准确率数字更直观。题目:一根绳子长30米每天剪掉一半几天后剩1米以内。FP16模型的回答逻辑完整一步步算出5天。AWQ和GPTQ的INT4版本步骤一样结论一致只是中间有一句措辞变化。GGUF的Q4_K_M版本答对了结果但少写了一步推导显得略敷衍。这个例子说明量化掉的精度在短回答任务上感知不强但在长推导链上会累计放大。处理长链条推理任务时我会优先保留FP16或INT8别硬上INT4。GPTQ和AWQ的加载代码几乎一样区别只在权重来源。GPTQ仓库多捡现成方便。AWQ自己量化灵活还能配上自己微调过的模型。第58篇QLoRA微调出来的adapter合并回基座后再走AutoAWQ量化是完整的端侧部署流水线。生产环境加载量化模型一般不走transformers改走vLLM这类推理框架。vLLM加载AWQ模型时指定quantization参数就行。vllm serve ./qwen2.5-7b-awq-int4 --quantization awq --gpu-memory-utilization 0.9服务起来后OpenAI兼容API直接可用量化模型和FP16模型的调用方式完全一致。吞吐实测上vLLM场景下AWQ INT4比FP16高5%到10%原因是INT4权重加载时内存带宽占用更低连续批处理能塞进更多请求。速度、精度、成本的三角里INT4在服务端几乎全面占优这也是生产环境普遍推AWQ的原因。六、量化选型决策6.1 四个问题定方案选方案先过四个问题。有没有GPU没有GPU或只有Mac只能选GGUFCPU和统一内存都能跑。跑在谁的框架上生产用vLLM或TGI选AWQ或GPTQ本地工具和边缘设备选GGUF。模型从哪来HuggingFace上现成的量化模型多GPTQ最不缺自己微调过的模型要现场量化AWQ流程最顺。精度要求多高代码生成、数学、结构化输出这类任务优先AWQ别用最低位宽。6.2 踩坑:校准数据跑偏,量化模型在线上翻车讲一次真实事故。我们把客服7B模型从FP16切到AWQ INT4量化前顺手用网上找的英文通用语料当校准集想着省事。结果上线第一天用户反馈模型变笨了具体表现是地点实体识别出错把北京东城区识别成东城和区两个token下游的派单系统跟着错。查了48小时最后定位到校准集。复现实验:同样的模型和位宽英文语料校准的版本在中文地点识别上准确率81.2%换成500条真实客服会话校准后恢复到94.7%。校准数据的分布决定量化器把精度留给哪些通道通用语料里的高频词和业务场景的高频词根本不在一个频道上。那之后我定了条规矩校准数据一律从生产日志里采样数量500条起步量化前后跑同一套评测集差超过1.5个点就换校准集重来。6.3 踩坑:量化后直接上生产,没留回滚通道第二件糟心事和回滚有关。我们把AWQ量化模型部署上线一切正常了三天第四天业务方报告代码生成类任务输出格式错乱。当时没保存FP16的服务镜像回滚要重新构建折腾两个小时。等我们切回FP16验证量化模型在格式任务上确实有4%的违规率。教训就一条量化上线必须保留原模型镜像至少保留一周评测没跑完前别删。6.4 量化与推理框架的组合建议组合表我总结成三档。个人开发调试GGUF加llama-cpp-python最低成本跑起来。单机生产vLLM加AWQ吞吐和精度平衡最好。多机生产加微调定制GPTQ加transformers生态社区支持最全。第62篇会讲vLLM和TGI的具体部署流程量化模型正好作为那篇文章的输入。6.5 量化到底省了多少钱把账算一遍。7B模型FP16需要14GB权重显存INT4只需3.5GB。按A10按小时租60元算一台24GB的卡FP16只能跑单实例单并发INT4能跑两个实例加高并发批处理。单实例变双实例推理容量直接翻倍折算下来单位请求成本降一半。另一条路是降档买卡FP16要租A10INT4能塞进16GB显存的卡月租再省三成。我这边一个客服项目量化后月成本从2.1万降到1.2万效果还能接受这笔账是量化最直接的收益。成本之外还有一层好处量化模型的加载速度。FP16的7B从磁盘加载到显存要20多秒INT4只要6秒左右容器重启和弹性扩容的恢复时间缩短一大截。对追求快速扩容的生产环境这也是实打实的收益。6.6 量化模型上线检查清单我把量化上线的检查清单固定成八项每次部署逐项打勾。量化前后跑同一套业务评测集记录准确率差。校准数据来自生产日志采样保留采样记录方便追溯。原模型镜像保留一周以上确认没问题再删。显存余量核算权重加KV cache加计算缓冲留出10%到20%的空闲。并发和上下文长度配置匹配业务峰值用第62篇的压测脚本验证。长文本请求单独压一遍量化模型对长上下文的敏感度不同。日志里记录量化格式和版本出问题能快速定位。灰度发布先放5%流量跑一天观察错误率再全量。这套清单救过我两次一次是校准数据问题一次是并发配置过小都是清单里的项目提前拦截下来的。6.7 什么时候别量化量化省钱省显存但有三种情况我不建议碰。任务对输出质量极其敏感比如法律文书、医疗建议掉1个点就是事故保持FP16。推理框架对量化格式支持还不成熟强行加载报错修两天收益抵不过成本。模型本身很小1.5B以下量化省下的显存有限但精度损失比例反而大没有实际价值。先判断值不值得再谈选什么方案。还有一类任务要多留神JSON结构化输出量化后偶尔多出多余的空格或换行解析器直接报错这类场景我见过三次。常见问题FAQQ1: 什么是模型量化A1: 把FP16浮点权重换成INT8/INT4整数用scale和zero_point做映射和还原显存降为四分之一精度损失可控Q2: GGUF、AWQ、GPTQ怎么选A2: 无GPU或Mac选GGUF生产GPU服务选AWQtransformers生态和现成仓库多选GPTQQ3: 量化后精度损失多少A3: 常识问答掉1到3个点代码生成和数学掉5到8个点必须按任务实测别信通用benchmarkQ4: 量化后推理变快了吗A4: 单请求延迟基本持平显存带宽吃紧的场景吞吐提升明显vLLM场景下INT4比FP16高5%到10%Q5: 量化模型加载报错或OOMA5: 先确认位宽和框架匹配AWQ的模型别用GPTQ加载再查gpu-memory-utilization和max-model-len设置Q6: 我自己微调过的模型怎么量化A6: 把adapter合并回基座保存为完整模型再用AutoAWQ量化第58篇QLoRA的产物可以直接走这条流水线Q7: 量化后的模型还能继续微调吗A7: 可以用QLoRA在4bit基座上做适配器微调权重保持量化状态第58篇讲的就是这个Q8: 校准数据要准备多少A8: 几百条就够重点在分布贴近线上输入从生产日志采样比通用语料效果好得多Q9: 量化要花多少钱A9: 量化本身是计算任务7B模型在A10上约40分钟一台按小时计费的云GPU几十元搞定比买新显卡便宜得多Q10: 部署后效果变差怎么办A10: 先切回FP16确认是否量化引入的问题再换校准集重量化量化前后跑同一套评测集对比误差超过1.5个点就返工为什么订阅本专栏免费教程讲公式的多本专栏给出校准数据、实测掉点、回滚策略一套完整工程方法培训班动辄几千元本专栏三份可直接运行的量化脚本从GGUF推理到AWQ量化一步到位每篇都带真实事故复盘校准数据跑偏、量化上线翻车这类坑提前排雷与第58篇QLoRA、第59篇SFT、第62篇部署衔接从微调到部署一条线走通一次订阅终身回看代码随transformers和vLLM版本更新持续修正相关推荐vLLM推理加速:吞吐量提升10倍的秘密Ollama本地部署:一行命令跑起大模型QLoRA:4bit量化下的微调方案限时¥59.9030秒完成订阅今天就能开始学习
模型量化:GGUF/AWQ/GPTQ部署方案
模型量化:GGUF/AWQ/GPTQ部署方案专栏:AI/LLM工程化实战 - 从Prompt到Agent的完整落地指南模块6 模型微调与部署篇 第61篇摘要摘要:模型量化把FP16权重压到INT47B模型显存从14GB降到4GBGGUF、AWQ、GPTQ三种方案各管一块地盘本文讲透量化原理、精度损失实测和选型方法附llama.cpp、AutoAWQ、GPTQ三份完整代码本专栏限时¥59.90(原价¥99)TL;DR 核心要点速览FP16的7B模型权重占14GB显存INT8砍到7GBINT4砍到3.5GB这是量化的全部动机GGUF是llama.cpp的专属格式CPU和GPU混合推理Ollama、llama-cpp-python都吃这个格式AWQ按激活值感知保留重要通道INT4精度接近FP16vLLM和SGLang原生支持GPTQ用Hessian矩阵补偿逐层量化误差transformers一行from_pretrained就能加载我的客服场景实测:意图识别准确率FP16为97.8%AWQ INT4为96.9%GPTQ INT4为96.2%GGUF Q4_K_M为95.8%7B模型INT4量化后推理速度基本不掉vLLM场景下吞吐还能比FP16高5%到10%代码生成和数学任务量化后掉点多常识问答掉点少上线前按任务类型实测校准数据几百条就够但分布必须贴近线上输入用通用语料校准中文场景会明显掉点本专栏限时¥59.90(原价¥99)开篇故事:一张24GB显卡装不下7B模型我所在的公司做电商客服机器人模型方案定的是Qwen2.5-7B-Instruct买了A10 24GB的云GPU。第一天部署就出事了transformers加载FP16权重光权重就吃14GB再加上激活和KV cache上下文超过2000个token就OOM服务反复重启。我翻着部署日志想骂人7B的模型配上24GB的卡按账面上算绰绰有余实际跑起来却连基本对话都撑不住。运维同事在旁边说了一句把模型量化了再上线隔壁组用INT4跑同样的模型4GB权重加8GB KV cache稳得很。当天下午我把模型换成GGUF的Q4_K_M版本A10上跑起来上下文开到8192都不慌。从那次开始我才认真把量化原理读了一遍也把GGUF、AWQ、GPTQ三种方案逐一在自家任务上做了对比实验。这篇文章就是那段时间踩坑和实测的完整记录。回头看那次事故教训就一句话部署前先算显存账。权重、KV cache、并发余量三样一起算缺一样都会在线上出事。量化把这道账算简单了14GB的权重变成4GB剩下的空间全部变成业务的缓冲。后来我们组把这个经验固化成模板所有模型部署前先填一张显存预算表量化与否由这张表决定不再靠临场拍脑袋。一、量化原理:FP16到INT8/INT4发生了什么1.1 先算一笔显存账一个FP16数字占2字节INT8占1字节INT4占0.5字节。70亿参数的模型权重部分是70亿乘2字节约13GB业界习惯叫14GB。换成INT8是7GBINT4是3.5GB。显存需求一路腰斩。推理时显存有三块开销权重、激活值、KV cache。权重省下来的空间直接变成KV cache的余量上下文长度就能翻好几倍。我遇到的OOM就是权重挤占了KV cache的空间量化之后同一张卡能装的并发和上下文完全不是一个量级。KV cache的规模可以估。7B模型每层KV维度是4096乘2按32层、FP16算每个token约占0.5MB2048个token的上下文就是1GB。做服务端容量规划时KV cache按峰值上下文长度乘并发数来算这部分常常比权重还占地方。量化权重等于给KV cache腾位置这也是INT4在服务端高并发场景下收益最大的原因。1.2 量化映射一张图讲清楚量化做的事是拿一个低位宽的整数去近似一个高位宽的浮点数。公式是这样。q clamp(round(x / scale) zero_point, 0, 2^bits - 1)反量化恢复近似值。x_hat (q - zero_point) * scalescale由权重范围决定。INT4下2^bits减1等于15如果权重范围是[-1, 1]scale等于2除以15约0.133。权重0.5量化成4反量化回来是0.53误差0.03。权重范围越大scale越大舍入误差越明显。所以量化之前先做一次分布统计把异常值截掉比什么都管用。误差有两类来源。一类是舍入误差连续值落到离散整数格子上。另一类是截断误差超出范围的数值被clamp掐掉。两类误差叠加就是量化模型掉点的来源。1.3 校准数据是精度的天花板AWQ和GPTQ这类方案要靠一小批校准数据统计激活分布决定哪些通道值得保留更高精度。校准数据一般几百条就够不需要标注普通文本就行。但分布必须贴近线上真实输入。我踩的第一个坑就在这用英文通用语料c4校准部署中文客服场景意图识别准确率从97.8%掉到93.1%掉了近5个点。换成公司真实客服对话的prompt做校准集准确率回到96.9%。同样的模型、同样的位宽校准数据换一批结果差4个点。校准数据选得对不对直接决定量化精度的上限。校准数据的实操流程我固定走三步。采样从生产日志里按意图类型分层抽500条保证每个业务方向都有覆盖。清洗去掉重复、截断、包含敏感信息的样本长度控制在512 token以内。检查跑一遍统计确认高频词和线上一致比如客服场景里退货物流这类词要高频出现。三步做完才开始量化。1.4 量化粒度:按多少权重共享一个scalescale和zero_point不是每个权重都单独存的那样存储开销等于没量化。常见三种粒度。per-tensor整层权重共享一个scale存储开销最小精度最差。per-channel按输出通道共享精度中等。per-group把通道内每128个权重分成一组各组独立scale精度最高。group越小越精细但scale也要多存。128一组是工程上最常用的平衡点AWQ、GPTQ默认都是这个值。1.5 离群值:量化精度的隐形杀手大模型的权重分布有个特点大部分值集中在0附近的小区间但存在少量绝对值很大的离群权重。这些离群值会把scale撑大其余权重全部被压扁精度损失集中爆发。处理手法有几种。先做clip把分布两端1%的极端值截掉再算scale能显著改善。AWQ更进一步对含离群值的通道做额外缩放把整数格子的利用效率拉高。我实测过同一模型不处理离群值INT4掉4.2个点做完clip只掉2.3个点。量化工具链默认都做了这层处理自己手写量化时必须补上这一步不然结果差一大截。1.6 量化到多少位宽才够用INT8损失很小普遍掉0.5个点以内适合对精度敏感的金融、医疗场景。INT4是性价比甜点区掉1到3个点显存只剩四分之一。INT3和INT2看着诱人7B模型压到2GB以内但输出质量明显崩代码生成基本没法用。我见过一个团队为了塞进8GB显存的卡用INT2上线当天就被用户投诉第二天换回INT4。位宽选择要按任务容忍度来别按显卡容量来。1.7 激活值量化:另一条线权重量化解决的是加载和存储推理时激活值仍然是FP16。激活值量化是独立的方向把中间计算结果也压到INT8甚至FP8主要收益在推理时减少显存带宽压力。NVIDIA的FP8推理和KV cache量化都属于这条线。对7B这个规模激活值量化的收益远小于权重量化前者省几个百分点显存后者直接省四分之三。做工程决策时优先做权重量化激活值量化等权重方案定了再评估两条线别混在一起判断。给个参考70B以上模型和长上下文场景KV cache量化才有明显回报7B单卡场景可以先不碰。二、GGUF/AWQ/GPTQ三种方案对比2.1 GGUF:llama.cpp的随身格式GGUF是llama.cpp项目定义的文件格式一个文件里打包了权重、tokenizer、chat模板和超参数拷到哪都能跑。它的量化方式是纯权重量化分Q2_K、Q4_K_M、Q6_K、Q8_0等档位Q4_K_M是最常用的平衡档。档位选择有规律Q8_0接近INT8精度权重体积约8GBQ4_K_M精度和体积的平衡点Q2_K体积最小但输出质量明显下降。个人使用从Q4_K_M起步显存富余再往上加档位。优势在CPU推理和混合推理没有GPU也能跑M系列芯片上速度还不错。劣势是GPU推理框架不认它vLLM、TGI都不直接加载GGUF要转格式。2.2 AWQ:激活感知的后来者AWQ全称Activation-aware Weight Quantization思路和别的方案不一样。它观察校准数据跑过模型后的激活值分布发现权重不是同等重要少部分通道对激活贡献大。量化时保留这些重要通道的高精度其余通道才压到INT4。实测精度损失是三家里最小的代码生成和数学这类敏感任务上优势更明显。vLLM、SGLang、TensorRT-LLM原生支持AWQ生产环境GPU推理首选的量化格式。2.3 GPTQ:老牌通用方案GPTQ是逐层做权重量化每量化完一层用Hessian矩阵补偿误差把误差往后面的层推整体损失最小化。它是2023年的方案社区积累的GPTQ模型最多HuggingFace上带GPTQ后缀的仓库一抓一大把。transformers原生支持加载AutoGPTQ负责量化。精度和速度跟AWQ在同一水平略逊一点点。2.4 三方对比表维度GGUFAWQGPTQ量化方式纯权重量化K-quants多档位激活感知按通道缩放权重逐层加Hessian补偿适用框架llama.cpp、llama-cpp-python、OllamavLLM、SGLang、TensorRT-LLMtransformers、AutoGPTQ、vLLM精度损失中等Q4_K_M实测掉2到4个点最小接近FP16较小推理速度CPU可跑GPU推理比AWQ/GPTQ略低GPU推理快vLLM吞吐最高GPU推理快内存占用最低权重可放CPU内存低约FP16的四分之一低约FP16的四分之一适用场景个人电脑、Mac、边缘设备、单机小工具生产高并发GPU服务transformers生态、微调后快速部署2.5 生态与迁移成本选方案还要算一笔迁移账。GGUF的生态在个人工具链Ollama、LM Studio、llama.cpp全套围绕它转换到生产GPU服务就要转格式多一道工序。AWQ和GPTQ在服务端框架里的支持度互有重叠vLLM两个都认TGI更偏向GPTQ和自有量化格式。如果你的模型来自HuggingFace社区GPTQ仓库最多省掉自己量化的时间。如果你的模型是自己微调的AWQ的量化流程最顺手因为AutoAWQ直接吃transformers模型目录。我现在的团队默认组合是微调模型加AWQ社区现成模型加GPTQ本地调试加GGUF三条线互不打架。这个组合还有一个好处三种格式之间用统一脚本互转safetensors转GGUF再转回流程都是现成的工具链团队里任何一个人接手都能跑通。三、用llama.cpp跑GGUF推理llama.cpp提供Python绑定llama-cpp-python装完就能加载GGUF文件跑推理。Windows环境建议直接装预编译wheel避免本地编译要装MSVC的麻烦。下载模型用huggingface-cli选q4_k_m的单文件版本就行。# run_gguf.py# llama.cpp加载GGUF模型跑推理的完整脚本# 安装: pip install llama-cpp-python huggingface-hub# 下载模型: huggingface-cli download Qwen/Qwen2.5-7B-Instruct-GGUF \# --include *q4_k_m.gguf --local-dir ./models# 生成的qwen2.5-7b-instruct-q4_k_m.gguf约4.4GBfromllama_cppimportLlama# 模型路径指向刚下载的gguf单文件# n_ctx2048控制上下文窗口,调大会多占内存# n_gpu_layers-1表示全部层放GPU,CPU推理填0即可llmLlama(model_path./models/qwen2.5-7b-instruct-q4_k_m.gguf,n_ctx2048,n_gpu_layers-1,verboseFalse,# 关掉启动日志,只留推理结果)prompt用一句话解释什么是模型量化,控制在30字以内# create_chat_completion走llama.cpp内置的chat模板# Qwen的模板会自动拼system和user消息resllm.create_chat_completion(messages[{role:user,content:prompt}],temperature0.7,# 采样温度,0.7适合对话max_tokens256,# 限制生成长度,避免失控输出)# 取第一条候选的回复内容answerres[choices][0][message][content]print(回答:,answer)# usage里带completion_tokens,可用来估算每秒速度tokensres.get(usage,{}).get(completion_tokens,0)print(生成了,tokens,个token)我在这台机器上跑过对比。纯CPU推理i9-13900K跑7B的Q4_K_M约12 token/s写一段500字的回答要等40秒个人工具能接受生产环境绝对不行。GPU加速后同样的模型到55到65 token/s跟未量化的FP16模型差距在5%以内。这个结论很重要量化换来的主要是内存和带宽计算能力基本没变。llama.cpp的显存占用也可以量化着看。7B的Q4_K_M权重4.4GBn_ctx开2048时KV cache约0.5GB加上计算缓冲整体5.5GB出头。8GB显存的笔记本显卡能完整放进去这是很多个人开发者把GGUF当首选的原因。n_ctx开到8192KV cache涨到2GB左右显存不够时llama.cpp会自发把一部分层放到CPU速度掉一半但不会崩。llama-cpp-python还有一个实用姿势跑服务模式一行命令把模型变成OpenAI兼容API。llama-server --model ./models/qwen2.5-7b-instruct-q4_k_m.gguf --port 8080启动后http://localhost:8080/v1就是OpenAI兼容端点开发机上拿它模拟生产接口调试业务代码等上线再切真服务体验一致。GGUF的另一个价值在格式统一。不管是HuggingFace上的原始权重还是第57篇LoRA、第58篇QLoRA微调后合并的模型都能用llama.cpp自带的转换脚本导出成GGUF。转换命令大概长这样。python convert_hf_to_gguf.py ./qwen2.5-7b-instruct --outfile qwen2.5-7b-instruct-f16.gguf导出FP16的GGUF后再用llama-quantize压到目标位宽。这个流程让微调产物和部署格式解耦训练在transformers生态部署在llama.cpp生态两边互不污染。四、AutoAWQ量化一个7B模型下面代码用AutoAWQ把Qwen2.5-7B-Instruct量化成INT4。需要一张20GB以上显存的GPUA10 24GB大概35到45分钟跑完。量化完成后权重约4GB加载占显存接近5GB。# quantize_awq.py# 用AutoAWQ把Qwen2.5-7B-Instruct量化到INT4并保存# 安装: pip install autoawq transformers datasets# 前置: 一张20GB以上显存的GPU,建议先装好CUDA# 产出: ./qwen2.5-7b-awq-int4目录下的4bit权重fromdatasetsimportDatasetfromawqimportAutoAWQForCausalLMfromtransformersimportAutoTokenizer# 量化后的保存目录,后续vLLM/TGI直接加载这个目录quant_path./qwen2.5-7b-awq-int4model_idQwen/Qwen2.5-7B-Instruct# 校准数据选贴近线上场景的prompt,我这里是客服问答# 数量几十条就够,复制扩充到32条,多了收益很小calib_prompts[帮我写一封给客户的道歉邮件,解释一下什么是反向传播,把这段python代码改成java,今天下单什么时候能发货,]*8# 先加载FP16原模型,量化流程跑在GPU上modelAutoAWQForCausalLM.from_pretrained(model_id,device_mapauto,# 自动分配显存)tokenizerAutoTokenizer.from_pretrained(model_id,trust_remote_codeTrue,)# w_bit4是INT4,q_group_size128是分组大小# zero_pointTrue保留零点,精度略高一点quant_config{zero_point:True,q_group_size:128,w_bit:4,version:GEMM,# GEMM通用矩阵乘法,兼容性最好}# 校准数据格式是{text: 内容},一行一条datasetDataset.from_list([{text:s}forsincalib_prompts])# 量化主流程,跑一次约35到45分钟# 期间显卡吃满,别开其他大程序model.quantize(tokenizer,quant_config,calib_datasetdataset,)# 权重和tokenizer一起存下来,方便推理框架加载model.save_quantized(quant_path)tokenizer.save_pretrained(quant_path)print(量化完成,权重保存到,quant_path)量化完成后做一件必做的小事把量化前后两个模型在同一个评测集上跑一遍。我常用的动作是拿50条线上真实问题让两个模型分别回答人工对比打分。别只看困惑度这类指标任务效果才是业务关心的。AWQ量化的结果在客服场景上我实测掉点不到1个点可以直接上线。再给一段加载已量化模型的代码方便复现推理效果。AutoAWQ量化完的目录用transformers直接加载就行权重文件带量化参数框架会自动识别。# load_awq.py# 用transformers加载已量化的AWQ模型做推理# 安装: pip install transformers4.44 autoawqfromtransformersimportAutoModelForCausalLM,AutoTokenizer# 上一段脚本保存的量化目录awq_path./qwen2.5-7b-awq-int4# device_mapauto自动识别AWQ量化并分卡加载modelAutoModelForCausalLM.from_pretrained(awq_path,device_mapauto,)tokenizerAutoTokenizer.from_pretrained(awq_path)# 和FP16模型同一套调用方式,业务代码零改动messages[{role:user,content:今天下单什么时候能发货}]texttokenizer.apply_chat_template(messages,tokenizeFalse,add_generation_promptTrue)inputstokenizer(text,return_tensorspt).to(model.device)outmodel.generate(**inputs,max_new_tokens128)print(tokenizer.decode(out[0][inputs[input_ids].shape[1]:],skip_special_tokensTrue))加载AWQ模型时常见一个报错缺autoawq或版本过老会提示找不到量化模块。解决办法是升级autoawq到最新版再把transformers升到4.44以上。vLLM加载AWQ模型不经过transformers见第62篇的部署流程。五、GPTQ模型加载与推理对比GPTQ模型的加载比量化还简单HuggingFace上现成的仓库直接from_pretrained。transformers从4.44版本开始原生支持GPTQ装了auto-gptq或gptqmodel就行。# load_gptq.py# 用transformers加载GPTQ量化模型做推理对比# 安装: pip install transformers4.44 auto-gptq optimum# 下载模型: huggingface-cli download TheBloke/Qwen2.5-7B-Instruct-GPTQ-Int4 \# --local-dir ./gptq_model# 注意: TheBloke仓库对非英文模型可能改名,按实际名称调整importtorchfromtransformersimportAutoModelForCausalLM,AutoTokenizer# GPTQ仓库的本地路径gptq_path./gptq_model# device_mapauto会自动识别GPTQ量化结构并加载# torch_dtypefloat16是加载量化权重时的常规设置modelAutoModelForCausalLM.from_pretrained(gptq_path,device_mapauto,torch_dtypetorch.float16,)tokenizerAutoTokenizer.from_pretrained(gptq_path)defgenerate(prompt:str,max_new:int128)-str:# 必须走chat模板,不套模板的回答质量差一截msgs[{role:user,content:prompt}]texttokenizer.apply_chat_template(msgs,tokenizeFalse,add_generation_promptTrue,)# 转成输入张量,搬到模型所在设备inputstokenizer(text,return_tensorspt).to(model.device)outmodel.generate(**inputs,max_new_tokensmax_new,do_sampleFalse,# 贪心解码,结果可复现方便对比pad_token_idtokenizer.eos_token_id,)# 只截取新增回答部分,去掉输入prompt的tokennew_tokensout[0][inputs[input_ids].shape[1]:]returntokenizer.decode(new_tokens,skip_special_tokensTrue)# 同一道题,对比GPTQ模型的实际输出print(generate(用一句话解释什么是模型量化))我在客服数据集上做了三方案实测同一批200条意图识别样本。FP16基线准确率97.8%AWQ INT4是96.9%GPTQ INT4是96.2%GGUF Q4_K_M是95.8%。常识问答类任务掉点普遍在1到3个点。代码生成和数学推理掉得更多GSM8K数学题上AWQ掉5到8个点这类任务上线前必须单独评测。再贴一组输出对比同一道推理题三种模型的实际回答差异比准确率数字更直观。题目:一根绳子长30米每天剪掉一半几天后剩1米以内。FP16模型的回答逻辑完整一步步算出5天。AWQ和GPTQ的INT4版本步骤一样结论一致只是中间有一句措辞变化。GGUF的Q4_K_M版本答对了结果但少写了一步推导显得略敷衍。这个例子说明量化掉的精度在短回答任务上感知不强但在长推导链上会累计放大。处理长链条推理任务时我会优先保留FP16或INT8别硬上INT4。GPTQ和AWQ的加载代码几乎一样区别只在权重来源。GPTQ仓库多捡现成方便。AWQ自己量化灵活还能配上自己微调过的模型。第58篇QLoRA微调出来的adapter合并回基座后再走AutoAWQ量化是完整的端侧部署流水线。生产环境加载量化模型一般不走transformers改走vLLM这类推理框架。vLLM加载AWQ模型时指定quantization参数就行。vllm serve ./qwen2.5-7b-awq-int4 --quantization awq --gpu-memory-utilization 0.9服务起来后OpenAI兼容API直接可用量化模型和FP16模型的调用方式完全一致。吞吐实测上vLLM场景下AWQ INT4比FP16高5%到10%原因是INT4权重加载时内存带宽占用更低连续批处理能塞进更多请求。速度、精度、成本的三角里INT4在服务端几乎全面占优这也是生产环境普遍推AWQ的原因。六、量化选型决策6.1 四个问题定方案选方案先过四个问题。有没有GPU没有GPU或只有Mac只能选GGUFCPU和统一内存都能跑。跑在谁的框架上生产用vLLM或TGI选AWQ或GPTQ本地工具和边缘设备选GGUF。模型从哪来HuggingFace上现成的量化模型多GPTQ最不缺自己微调过的模型要现场量化AWQ流程最顺。精度要求多高代码生成、数学、结构化输出这类任务优先AWQ别用最低位宽。6.2 踩坑:校准数据跑偏,量化模型在线上翻车讲一次真实事故。我们把客服7B模型从FP16切到AWQ INT4量化前顺手用网上找的英文通用语料当校准集想着省事。结果上线第一天用户反馈模型变笨了具体表现是地点实体识别出错把北京东城区识别成东城和区两个token下游的派单系统跟着错。查了48小时最后定位到校准集。复现实验:同样的模型和位宽英文语料校准的版本在中文地点识别上准确率81.2%换成500条真实客服会话校准后恢复到94.7%。校准数据的分布决定量化器把精度留给哪些通道通用语料里的高频词和业务场景的高频词根本不在一个频道上。那之后我定了条规矩校准数据一律从生产日志里采样数量500条起步量化前后跑同一套评测集差超过1.5个点就换校准集重来。6.3 踩坑:量化后直接上生产,没留回滚通道第二件糟心事和回滚有关。我们把AWQ量化模型部署上线一切正常了三天第四天业务方报告代码生成类任务输出格式错乱。当时没保存FP16的服务镜像回滚要重新构建折腾两个小时。等我们切回FP16验证量化模型在格式任务上确实有4%的违规率。教训就一条量化上线必须保留原模型镜像至少保留一周评测没跑完前别删。6.4 量化与推理框架的组合建议组合表我总结成三档。个人开发调试GGUF加llama-cpp-python最低成本跑起来。单机生产vLLM加AWQ吞吐和精度平衡最好。多机生产加微调定制GPTQ加transformers生态社区支持最全。第62篇会讲vLLM和TGI的具体部署流程量化模型正好作为那篇文章的输入。6.5 量化到底省了多少钱把账算一遍。7B模型FP16需要14GB权重显存INT4只需3.5GB。按A10按小时租60元算一台24GB的卡FP16只能跑单实例单并发INT4能跑两个实例加高并发批处理。单实例变双实例推理容量直接翻倍折算下来单位请求成本降一半。另一条路是降档买卡FP16要租A10INT4能塞进16GB显存的卡月租再省三成。我这边一个客服项目量化后月成本从2.1万降到1.2万效果还能接受这笔账是量化最直接的收益。成本之外还有一层好处量化模型的加载速度。FP16的7B从磁盘加载到显存要20多秒INT4只要6秒左右容器重启和弹性扩容的恢复时间缩短一大截。对追求快速扩容的生产环境这也是实打实的收益。6.6 量化模型上线检查清单我把量化上线的检查清单固定成八项每次部署逐项打勾。量化前后跑同一套业务评测集记录准确率差。校准数据来自生产日志采样保留采样记录方便追溯。原模型镜像保留一周以上确认没问题再删。显存余量核算权重加KV cache加计算缓冲留出10%到20%的空闲。并发和上下文长度配置匹配业务峰值用第62篇的压测脚本验证。长文本请求单独压一遍量化模型对长上下文的敏感度不同。日志里记录量化格式和版本出问题能快速定位。灰度发布先放5%流量跑一天观察错误率再全量。这套清单救过我两次一次是校准数据问题一次是并发配置过小都是清单里的项目提前拦截下来的。6.7 什么时候别量化量化省钱省显存但有三种情况我不建议碰。任务对输出质量极其敏感比如法律文书、医疗建议掉1个点就是事故保持FP16。推理框架对量化格式支持还不成熟强行加载报错修两天收益抵不过成本。模型本身很小1.5B以下量化省下的显存有限但精度损失比例反而大没有实际价值。先判断值不值得再谈选什么方案。还有一类任务要多留神JSON结构化输出量化后偶尔多出多余的空格或换行解析器直接报错这类场景我见过三次。常见问题FAQQ1: 什么是模型量化A1: 把FP16浮点权重换成INT8/INT4整数用scale和zero_point做映射和还原显存降为四分之一精度损失可控Q2: GGUF、AWQ、GPTQ怎么选A2: 无GPU或Mac选GGUF生产GPU服务选AWQtransformers生态和现成仓库多选GPTQQ3: 量化后精度损失多少A3: 常识问答掉1到3个点代码生成和数学掉5到8个点必须按任务实测别信通用benchmarkQ4: 量化后推理变快了吗A4: 单请求延迟基本持平显存带宽吃紧的场景吞吐提升明显vLLM场景下INT4比FP16高5%到10%Q5: 量化模型加载报错或OOMA5: 先确认位宽和框架匹配AWQ的模型别用GPTQ加载再查gpu-memory-utilization和max-model-len设置Q6: 我自己微调过的模型怎么量化A6: 把adapter合并回基座保存为完整模型再用AutoAWQ量化第58篇QLoRA的产物可以直接走这条流水线Q7: 量化后的模型还能继续微调吗A7: 可以用QLoRA在4bit基座上做适配器微调权重保持量化状态第58篇讲的就是这个Q8: 校准数据要准备多少A8: 几百条就够重点在分布贴近线上输入从生产日志采样比通用语料效果好得多Q9: 量化要花多少钱A9: 量化本身是计算任务7B模型在A10上约40分钟一台按小时计费的云GPU几十元搞定比买新显卡便宜得多Q10: 部署后效果变差怎么办A10: 先切回FP16确认是否量化引入的问题再换校准集重量化量化前后跑同一套评测集对比误差超过1.5个点就返工为什么订阅本专栏免费教程讲公式的多本专栏给出校准数据、实测掉点、回滚策略一套完整工程方法培训班动辄几千元本专栏三份可直接运行的量化脚本从GGUF推理到AWQ量化一步到位每篇都带真实事故复盘校准数据跑偏、量化上线翻车这类坑提前排雷与第58篇QLoRA、第59篇SFT、第62篇部署衔接从微调到部署一条线走通一次订阅终身回看代码随transformers和vLLM版本更新持续修正相关推荐vLLM推理加速:吞吐量提升10倍的秘密Ollama本地部署:一行命令跑起大模型QLoRA:4bit量化下的微调方案限时¥59.9030秒完成订阅今天就能开始学习