1. 推理优化与部署的整体思路拆解1.1 为什么推理优化是模型落地的第一道坎训练一个大模型动辄几十上百张卡跑几周但真正决定这个模型能不能用起来、用得起、用得爽的其实是推理阶段。我见过太多团队模型训得漂漂亮亮指标刷得飞起结果一上线就傻眼——单次请求延迟两秒起步并发一上来显存直接爆掉一张A100跑一个7B模型只能扛住个位数的QPS。这不是模型不行是推理优化没做到位。推理优化要解决的核心矛盾就一个在有限的硬件资源下把吞吐量做上去、把延迟压下来、把成本控住。这三个目标有时候是互相打架的。你想降延迟那就得牺牲批处理大小你想提吞吐那就得接受更高的单次延迟。所以优化的第一步不是急着上工具而是先搞清楚你的业务场景到底更看重什么。举个实际的例子。如果你做的是在线客服机器人用户发一条消息等三秒才回那体验直接崩了这时候延迟就是第一优先级量化到INT8甚至INT4都可以接受只要别把回答质量拉垮。但如果你做的是离线批量文档摘要一晚上要处理十万篇文档那吞吐量就是命根子延迟多个几百毫秒根本无所谓这时候就可以把batch size拉满用连续批处理把GPU利用率榨干。1.2 量化、蒸馏、模型选型三者的关系很多人把量化、蒸馏、模型选型当成三个独立的技术点来学其实它们是一条链上的三个环节解决的是不同层面的问题。模型选型是第一步决定了你的起点。你选一个7B的模型还是72B的模型选Qwen还是DeepSeek还是MiniMax这直接决定了你后面优化的天花板在哪里。选型选错了后面再怎么量化蒸馏都是事倍功半。蒸馏是第二步解决的是“大模型能力能不能搬到小模型上”的问题。你有一个72B的模型效果很好但部署成本太高那就用蒸馏把它的能力迁移到一个7B甚至3B的模型上。蒸馏的本质是让小模型去模仿大模型的输出分布学到大模型的“暗知识”。量化是第三步解决的是“模型能不能塞进更小的显存、跑在更便宜的硬件上”的问题。蒸馏完的模型可能还是太大那就用INT8、INT4量化把权重精度降下来让模型能在消费级显卡甚至边缘设备上跑起来。这三者的顺序不是死的。你也可以先量化再蒸馏或者选一个本身就很小但很强的模型直接量化部署。关键是要根据你的硬件预算、延迟要求和质量底线来灵活组合。1.3 不同部署场景下的优化策略选择部署场景大致可以分三类每类的优化策略完全不同。云端高并发场景你有A100/H100集群要服务成千上万的用户。这时候核心是吞吐量vLLM、TensorRT-LLM这类推理引擎是标配连续批处理、PagedAttention这些技术必须用上。量化方面INT8就够了INT4在云端性价比不高因为显存不是瓶颈算力才是。本地/边缘部署场景你只有一张4090或者甚至是一张RK3588这样的嵌入式板子。这时候显存是硬约束INT4量化几乎是必选项模型选型也要偏向小参数量的。Ollama、LM Studio这类工具就是为这个场景设计的开箱即用不用折腾太多底层配置。混合部署场景核心业务用云端大模型保证质量边缘侧用小模型做预处理和缓存。这时候蒸馏就派上用场了用云端大模型的输出蒸馏一个小模型放到边缘既保证了效果又控制了成本。我个人的经验是不要一上来就追求极致的优化。先把模型跑起来用真实流量压测找到瓶颈在哪里再针对性地优化。很多团队花了两周做量化结果发现瓶颈根本不在显存而在网络IO这就很尴尬了。2. 量化技术的核心细节与实操要点2.1 量化的基本原理从FP32到INT8到底损失了什么量化的本质是用更少的比特数来表示权重和激活值。FP32用32位浮点数表示一个参数INT8只用8位整数。理论上显存占用直接降到四分之一推理速度也能提升2到4倍因为整数运算比浮点运算快得多。但天下没有免费的午餐。从FP32到INT8你损失的是数值表示的精度。FP32能表示的范围大约是1.4e-45到3.4e38精度能到小数点后六七位。INT8只能表示-128到127这256个整数。所以量化的核心问题就是如何用256个整数尽可能准确地近似原来连续的浮点数分布。这里的关键概念是量化缩放因子scale和零点zero point。假设某一层的权重范围是[-2.5, 3.7]你要把它映射到[-128, 127]。缩放因子就是(3.7 - (-2.5)) / (127 - (-128)) 6.2 / 255 ≈ 0.0243。零点就是-128 - (-2.5 / 0.0243) ≈ -128 102.9 ≈ -25。推理的时候INT8的值乘以缩放因子再加上零点就还原成近似的浮点值。这个过程中每个权重都会引入量化误差。误差的大小取决于权重的分布。如果权重分布很集中那量化误差就小如果分布很分散有很多离群值那量化误差就大。这也是为什么有些模型量化后效果掉得厉害有些几乎无损——跟模型本身的权重分布特性有关。2.2 PTQ与QAT两种量化路线的选择逻辑量化分两条路线训练后量化PTQ和量化感知训练QAT。PTQ就是拿一个训练好的FP32模型直接做量化不需要重新训练。优点是快几分钟到几小时就能搞定。缺点是精度损失可能比较大尤其是量化到INT4的时候。PTQ里面又分几种最简单的就是直接对权重做min-max量化稍微好一点的是用KL散度找最优的截断范围再高级一点的是GPTQ、AWQ这些基于校准数据的量化方法。QAT是在训练过程中模拟量化误差让模型学会适应量化后的精度损失。具体做法是在前向传播的时候插入伪量化节点把权重和激活值量化后再反量化这样模型在训练时就能“感知”到量化带来的误差从而调整权重来补偿。QAT的精度通常比PTQ好很多尤其是低比特量化但代价是需要重新训练成本高。我个人的建议是INT8量化用PTQ就够了INT4量化优先考虑AWQ或GPTQ如果效果还不满意再上QAT。INT8的精度损失通常很小PTQ完全能hold住。INT4就比较敏感了AWQ和GPTQ通过分析权重的重要性来保护关键通道效果比朴素的min-max量化好很多。2.3 实操用GPTQ对模型做INT4量化下面以GPTQ为例走一遍完整的量化流程。假设你有一个7B的模型想量化到INT4跑在一张24G显存的卡上。首先安装依赖pip install auto-gptq transformers accelerate datasets然后准备校准数据。GPTQ需要一批校准数据来统计权重的分布通常用几百条就够了。校准数据的质量很重要最好用跟你的业务场景接近的数据。from datasets import load_dataset calib_dataset load_dataset(wikitext, wikitext-2-raw-v1, splittrain) calib_texts [text for text in calib_dataset[text] if len(text) 100][:512]接下来加载模型并执行量化from transformers import AutoModelForCausalLM, AutoTokenizer from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig model_name Qwen/Qwen2.5-7B-Instruct quantize_config BaseQuantizeConfig( bits4, group_size128, desc_actFalse, ) tokenizer AutoTokenizer.from_pretrained(model_name) model AutoGPTQForCausalLM.from_pretrained(model_name, quantize_config) calib_data [tokenizer(text, return_tensorspt) for text in calib_texts[:128]] model.quantize(calib_data) model.save_quantized(./qwen2.5-7b-int4-gptq) tokenizer.save_pretrained(./qwen2.5-7b-int4-gptq)这里有几个参数需要解释一下。group_size128表示每128个权重共享一个缩放因子group_size越小精度越高但显存开销越大128是一个比较平衡的选择。desc_actFalse表示不按激活值大小重排权重设为True精度会好一点但推理速度会慢一些。量化完成后加载量化模型做推理from auto_gptq import AutoGPTQForCausalLM model AutoGPTQForCausalLM.from_quantized( ./qwen2.5-7b-int4-gptq, devicecuda:0, use_safetensorsTrue, )实测下来7B模型INT4量化后显存占用从14G左右降到4G左右一张4090能轻松跑起来推理速度大概提升2倍。效果方面在通用对话任务上几乎感觉不到差异但在一些需要精确计算的任务上会有轻微下降。注意量化后的模型不能直接用于继续训练只能做推理。如果你后续需要微调要么在FP32模型上微调完再量化要么用QLoRA在量化模型上做轻量微调。2.4 量化避坑指南这些坑我替你踩过了第一个坑校准数据分布不对。我见过有人用英文维基百科校准一个中文模型结果量化后中文效果掉得厉害。校准数据一定要跟你的目标场景匹配中文模型就用中文数据校准代码模型就用代码数据校准。第二个坑group_size设得太小。有人觉得group_size越小越好设成32甚至16结果显存没省多少推理速度反而慢了。group_size128是经过大量实验验证的甜点值除非你有特殊需求否则别乱改。第三个坑忽略激活值量化。很多人只量化权重不量化激活值。权重INT4加上激活值FP16显存是省了但计算还是浮点运算速度提升有限。真正要提速权重和激活值都要量化这就是W4A16和W8A8的区别。W8A8的加速效果最明显但精度损失也最大。第四个坑量化后不做评估。量化完直接上线结果用户反馈回答质量下降。量化后一定要在你的业务测试集上跑一遍评估对比量化前后的指标差异。如果掉点超过可接受范围要么换量化方法要么调整量化参数。3. 知识蒸馏的落地方法与核心环节3.1 蒸馏的本质小模型如何学到大模型的暗知识知识蒸馏这个概念是Hinton在2015年提出来的核心思想是让一个小模型学生去模仿一个大模型教师的输出分布。为什么这样有效因为大模型的输出不仅仅是一个硬标签而是一个软分布。比如一个分类任务大模型对一张猫的图片可能输出“猫0.9狗0.08兔子0.02”这个软分布包含了类间相似性的信息也就是所谓的“暗知识”。小模型学这个软分布比只学硬标签“这是猫”能获得更多的信息量。在大模型时代蒸馏的形式变得更加多样。最常见的是黑盒蒸馏你只能拿到教师模型的输出文本用这些文本作为训练数据去微调学生模型。这种方式实现简单但信息量有限因为只用了教师模型的最终输出没用上logits分布。另一种是白盒蒸馏你能拿到教师模型的完整logits用KL散度来约束学生模型的输出分布。这种方式信息量更大效果通常更好但要求你能访问教师模型的内部状态。还有一种比较新的思路是特征蒸馏不仅让学生模型学教师模型的输出还让学生模型的中间层特征去逼近教师模型的中间层特征。这种方式对模型结构有要求通常需要教师和学生模型有相似的架构。3.2 黑盒蒸馏实操用大模型生成训练数据黑盒蒸馏是最容易落地的方案因为你只需要调用大模型的API或者用本地部署的大模型生成数据就行。下面走一遍完整流程。第一步准备种子指令。你需要一批多样化的指令来覆盖你的目标场景。可以从公开数据集中采样也可以自己构造。关键是多样性要覆盖不同的任务类型、不同的难度级别、不同的输入长度。seed_instructions [ 解释一下什么是量化交易, 写一个Python函数计算斐波那契数列, 把下面这段话翻译成英文今天天气真好, 总结一下这篇文章的主要观点, # ... 更多指令 ]第二步用教师模型生成回答。如果你用API直接调用就行如果用本地模型可以用vLLM批量推理。from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) def generate_response(instruction): response client.chat.completions.create( modelqwen2.5-72b-instruct, messages[{role: user, content: instruction}], temperature0.7, max_tokens1024, ) return response.choices[0].message.content distill_data [] for inst in seed_instructions: resp generate_response(inst) distill_data.append({instruction: inst, response: resp})第三步用生成的数据微调学生模型。这里用LoRA做轻量微调成本低效果好。from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from trl import SFTTrainer model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj, k_proj, o_proj], lora_dropout0.05, ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./distilled-qwen-7b, num_train_epochs3, per_device_train_batch_size4, gradient_accumulation_steps4, learning_rate2e-4, warmup_ratio0.1, logging_steps10, save_strategyepoch, ) trainer SFTTrainer( modelmodel, argstraining_args, train_datasetformatted_dataset, tokenizertokenizer, ) trainer.train()这里有几个关键点。r16是LoRA的秩秩越大表达能力越强但参数量也越大16是一个比较通用的值。target_modules指定了要微调的模块通常选注意力层的投影矩阵就够了。学习率2e-4是LoRA微调的常用值比全量微调的学习率大一个数量级。3.3 蒸馏数据的质量控制垃圾进垃圾出蒸馏的效果很大程度上取决于数据的质量。我见过太多人随便生成几万条数据就开始训结果学生模型学了一堆废话。数据质量控制有几个关键点。第一指令要有多样性。不要全是问答对要有生成任务、分类任务、改写任务、推理任务。指令的长度也要有变化短的十几个字长的几百个字。任务难度也要有梯度简单的和复杂的都要有。第二回答要经过筛选。教师模型不是万能的有些回答质量很差。可以用一个奖励模型或者另一个大模型来给回答打分过滤掉低质量的样本。也可以设置一些规则比如回答太短的、包含重复内容的、格式不对的直接丢掉。第三数据量要适中。不是越多越好。对于7B模型1到5万条高质量数据通常就够了。数据太多反而容易过拟合而且训练成本也上去了。我一般会先用1万条训一版看效果再决定要不要加数据。第四要保留一部分验证集。从生成的数据里留出5%到10%作为验证集用来监控训练过程中的效果变化。如果验证集loss开始上升说明过拟合了该停了。3.4 蒸馏与量化的组合拳先蒸后量还是先量后蒸蒸馏和量化的组合顺序会影响最终效果。我的经验是先蒸馏后量化效果更好。原因很简单蒸馏是在FP32精度下进行的学生模型能充分学习教师模型的知识。如果先量化再蒸馏学生模型本身就已经有量化误差了再学教师模型的知识误差会累积。而且量化后的模型做训练很麻烦需要特殊的训练框架支持。先蒸馏后量化的流程是用教师模型生成数据微调学生模型得到一个FP32的学生模型然后再对这个学生模型做量化。这样每一步都在当前精度下做到最优最终效果也最好。当然如果你的硬件资源实在有限也可以先量化再蒸馏用QLoRA在量化模型上做微调。这种方式显存占用小但效果会打折扣。我实测过一个7B模型先蒸馏后量化INT4在业务测试集上比原始7B模型提升了12个百分点比直接量化INT4的版本提升了8个百分点。这个提升还是很可观的。4. 主流模型选型与部署方案对比4.1 模型选型的核心维度不只看参数选模型不能只看参数量。7B不一定比13B差72B也不一定适合你的场景。我一般从五个维度来评估。第一任务匹配度。你的任务是通用对话、代码生成、数学推理还是文档理解不同模型在不同任务上的表现差异很大。Qwen系列在中文理解和代码生成上比较均衡DeepSeek在数学和推理上很强MiniMax在长文本处理上有优势。选模型之前先在你的业务测试集上跑一遍评测别光看榜单。第二硬件需求。7B模型FP16需要14G显存INT8需要7GINT4需要4G。13B模型对应翻倍。72B模型FP16需要144G至少两张A100。你的硬件决定了你能选多大的模型。如果只有一张4090那7B INT4是甜点区。第三推理速度。同样7B模型不同架构的推理速度能差一倍。有些模型用了GQA分组查询注意力KV Cache占用小推理速度快。有些模型层数多但每层参数少并行度高。选型的时候要实际测一下吞吐量和延迟。第四生态支持。模型有没有被vLLM、TensorRT-LLM、Ollama这些主流推理框架支持有没有现成的量化版本社区活跃度怎么样这些都会影响你的部署效率。Qwen和DeepSeek的生态支持是最好的基本上所有框架都第一时间适配。第五许可协议。商用场景要特别注意模型的许可协议。有些模型禁止商用有些要求署名有些完全开放。选型的时候一定要看清楚。4.2 本地部署工具选型Ollama vs vLLM vs LM Studio本地部署工具的选择取决于你的使用场景和技术水平。Ollama是最容易上手的。一行命令就能拉取模型并启动服务自带模型管理和量化版本。适合个人开发者和小团队快速验证。缺点是定制化能力弱不支持复杂的批处理配置。ollama pull qwen2.5:7b ollama run qwen2.5:7bvLLM是生产级推理引擎。支持连续批处理、PagedAttention、张量并行吞吐量比Ollama高一个数量级。适合有并发需求的线上服务。缺点是需要自己写服务端代码配置相对复杂。pip install vllm python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9LM Studio是图形化工具适合不熟悉命令行的用户。支持模型下载、量化、对话测试界面友好。缺点是只能单机使用不适合服务端部署。我的建议是验证阶段用Ollama生产环境用vLLM个人体验用LM Studio。三者不冲突可以配合使用。4.3 不同硬件平台上的部署方案消费级显卡4090/309024G显存7B INT4模型是甜点。用vLLM部署max-model-len设4096到8192gpu-memory-utilization设0.9。并发量大概能到20到50 QPS取决于输入输出长度。数据中心显卡A100/H10080G显存可以跑13B FP16或者72B INT4。用vLLM加张量并行两张A100跑72B INT4吞吐量能到几百QPS。嵌入式设备RK3588等算力和显存都很有限只能跑1B到3B的小模型。用ONNX Runtime或者NCNN做推理INT8量化是必须的。这种场景下模型选型比优化更重要选一个本身就很小但能力不错的模型。CPU部署没有GPU的情况下用llama.cpp做推理。7B INT4模型在高端CPU上大概能跑到5到10 token/s勉强能用。适合对延迟不敏感的场景。4.4 模型选型速查表模型参数量中文能力代码能力推理能力推荐场景最低显存(INT4)Qwen2.5-7B7B优秀优秀良好通用对话、代码助手4GQwen2.5-72B72B优秀优秀优秀高质量对话、复杂推理40GDeepSeek-V3671B MoE优秀优秀优秀高并发云端服务多卡DeepSeek-R1-7B7B良好良好优秀数学推理、逻辑分析4GMiniMax-Text-01456B MoE优秀良好优秀长文本处理多卡Llama-3.1-8B8B一般优秀良好英文场景、代码生成5G这张表是我根据实际使用经验整理的不是绝对标准。选型的时候还是要以你自己的评测结果为准。5. 常见问题与排查技巧实录5.1 量化后模型输出乱码或重复这是量化最常见的问题通常有几个原因。原因一量化参数不对。group_size设得太小或者太大desc_act设错了。解决办法是换一组参数重新量化先用默认参数跑一遍看看。原因二校准数据太少或质量太差。校准数据少于128条或者内容全是重复的。解决办法是增加校准数据到512条以上确保内容多样化。原因三模型本身不适合量化。有些模型的权重分布特别分散量化后误差很大。解决办法是换一个模型或者用量化感知训练来补偿。排查步骤先用FP16模型跑一遍确认原始模型没问题然后逐步降低量化比特数从INT8到INT4看在哪一步开始出问题。如果INT8就有问题那大概率是量化工具或参数的问题如果INT8没问题INT4有问题那是低比特量化的固有精度损失需要换更高级的量化方法。5.2 蒸馏后学生模型效果不如预期蒸馏效果不好通常不是蒸馏方法的问题而是数据的问题。排查一检查数据质量。随机抽100条数据人工看一下教师模型的回答是不是准确、完整、格式规范。如果教师模型本身回答就不好学生模型肯定学不好。排查二检查数据分布。统计一下指令的长度分布、任务类型分布。如果80%的数据都是短指令那学生模型处理长指令的能力肯定不行。排查三检查训练配置。学习率是不是太大了epoch是不是太多了LoRA的秩是不是太小了这些都会影响最终效果。我一般会先跑一个小的实验用1000条数据训1个epoch看loss曲线和验证集效果确认配置没问题再放大。排查四检查评估方式。你用什么指标评估的如果是用另一个大模型打分那个大模型本身靠谱吗建议用人工评估加自动评估结合的方式自动评估看趋势人工评估看细节。5.3 部署后并发上不去并发上不去瓶颈可能在好几个地方。瓶颈一GPU利用率低。用nvidia-smi看GPU利用率如果低于50%说明推理引擎没有充分利用GPU。解决办法是开连续批处理调大max-num-seqs或者换vLLM。瓶颈二显存不够导致频繁换入换出。如果显存占用接近100%GPU会频繁做内存交换速度急剧下降。解决办法是降低max-model-len或者用量化减少显存占用。瓶颈三CPU预处理成为瓶颈。tokenization和detokenization是在CPU上做的如果CPU太弱会成为瓶颈。解决办法是用多进程做预处理或者用更快的tokenizer。瓶颈四网络IO瓶颈。如果请求和响应数据量很大网络带宽可能成为瓶颈。解决办法是压缩传输数据或者用流式输出减少单次传输量。5.4 常见问题速查表问题现象可能原因排查方法解决方案量化后输出乱码量化参数错误换默认参数重新量化调整group_size和desc_act量化后效果下降明显校准数据不匹配检查校准数据分布用业务数据做校准蒸馏后效果差训练数据质量低人工抽检数据过滤低质量样本增加数据多样性推理速度慢未开连续批处理查看GPU利用率换vLLM开连续批处理显存溢出模型太大或batch太大查看显存占用量化模型减小batch size并发上不去CPU预处理瓶颈监控CPU利用率多进程预处理优化tokenizer模型加载失败格式不兼容检查模型格式转换格式或换推理框架5.5 独家避坑技巧技巧一量化前先做一轮评测。把FP32模型在你的测试集上跑一遍记录各项指标。量化后再跑一遍对比差异。这样你才能知道量化到底损失了多少是否在可接受范围内。技巧二蒸馏数据要人工抽检。不要完全信任教师模型的输出。我一般会随机抽200条数据人工看一遍把明显有问题的挑出来。这个工作量不大但能避免很多坑。技巧三部署前做压力测试。用locust或者wrk做压力测试逐步增加并发观察延迟和吞吐量的变化。找到系统的拐点也就是延迟开始急剧上升的那个并发数把线上流量控制在这个拐点以下。技巧四保留一个FP16的fallback。量化模型虽然快但偶尔会遇到一些边界情况效果不好。保留一个FP16的版本作为fallback当量化模型置信度低的时候切换到FP16模型。这样既保证了大部分请求的速度又保证了极端情况的质量。技巧五监控推理服务的各项指标。GPU利用率、显存占用、请求延迟、吞吐量、错误率这些指标都要监控。出了问题能快速定位。我一般用Prometheus加Grafana做监控vLLM自带metrics接口接入很方便。6. 从零搭建一个量化蒸馏部署流水线6.1 整体架构设计把前面讲的串起来一个完整的流水线大概是这样的第一步选一个教师模型比如Qwen2.5-72B部署在云端。第二步准备种子指令覆盖你的业务场景。第三步用教师模型生成回答构建蒸馏数据集。第四步选一个学生模型比如Qwen2.5-7B用蒸馏数据做LoRA微调。第五步对微调后的学生模型做INT4量化。第六步用vLLM部署量化后的学生模型。第七步做压力测试和效果评估不达标就回到第四步调整。这个流水线的好处是每一步都可以独立优化。教师模型可以换蒸馏数据可以加学生模型可以调量化方法可以选。整个流程跑通一次之后后续迭代就很快了。6.2 关键环节的自动化脚本蒸馏数据生成的自动化脚本import json from openai import OpenAI from tqdm import tqdm client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) def generate_distill_data(seed_file, output_file, model_name): with open(seed_file, r) as f: seeds [line.strip() for line in f if line.strip()] results [] for seed in tqdm(seeds): try: resp client.chat.completions.create( modelmodel_name, messages[{role: user, content: seed}], temperature0.7, max_tokens1024, ) answer resp.choices[0].message.content if len(answer) 20: results.append({instruction: seed, output: answer}) except Exception as e: print(fError: {e}) continue with open(output_file, w) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(fGenerated {len(results)} samples) generate_distill_data(seeds.txt, distill_data.json, qwen2.5-72b-instruct)量化脚本from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig from transformers import AutoTokenizer from datasets import load_dataset model_name ./distilled-qwen-7b quantize_config BaseQuantizeConfig(bits4, group_size128, desc_actFalse) tokenizer AutoTokenizer.from_pretrained(model_name) model AutoGPTQForCausalLM.from_pretrained(model_name, quantize_config) calib load_dataset(wikitext, wikitext-2-raw-v1, splittrain) calib_texts [t for t in calib[text] if len(t) 100][:512] calib_data [tokenizer(t, return_tensorspt) for t in calib_texts[:128]] model.quantize(calib_data) model.save_quantized(./distilled-qwen-7b-int4) tokenizer.save_pretrained(./distilled-qwen-7b-int4)部署脚本python -m vllm.entrypoints.openai.api_server \ --model ./distilled-qwen-7b-int4 \ --dtype auto \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 64 \ --port 80006.3 效果评估与迭代优化评估要分两个层面自动评估和人工评估。自动评估用业务测试集跑一遍对比蒸馏量化前后的指标。常用的指标有准确率、BLEU、ROUGE、困惑度等。如果是对话任务可以用GPT-4或者人工打分。人工评估抽100到200条样本从准确性、流畅性、有用性三个维度打分。准确性看回答是否正确流畅性看语言是否自然有用性看是否解决了用户的问题。如果评估结果不达标迭代方向有几个增加蒸馏数据量、提高蒸馏数据质量、调整LoRA参数、换量化方法、换学生模型。我一般会先看bad case分析错误类型然后针对性地补充数据或者调整训练配置。整个流水线跑通一次大概需要一天时间其中蒸馏数据生成占大头。后续迭代如果只调整量化参数或者部署配置几个小时就能搞定。最后分享一个小技巧蒸馏数据生成的时候可以用多个教师模型分别生成然后取交集或者用投票的方式筛选。这样得到的数据质量更高学生模型学到的知识也更鲁棒。我试过用Qwen和DeepSeek两个教师模型分别生成然后只保留两个模型回答一致的样本虽然数据量少了但效果明显更好。
