智能客服大模型选型实战：如何通过模型压缩与微调提升响应效率
摘要：面对智能场景里“大模型一上线，GPU就冒烟”的尴尬，本文把 LLaMA-2、ChatGLM-6B 拉到一起跑分，用 AWQ/GPTQ 把 16 GB 压到 4 GB，再套 LoRA 做领域微调，最终把推理延迟从 1.8 s 打到 0.6 s，准确率还稳在 90% 以上。全部代码与踩坑笔记一并奉上，方便直接搬进生产环境。
一、背景：客服场景的三座大山
- 高并发延迟：高峰期 200 QPS，原模型 RTF≈0.3，用户平均等待 1.8 s，体验差评。
- 显存溢出：一张 A10 只有 24 GB，FP16 加载 7 B 模型就占 14 GB，再加 KV Cache 直接 OOM。
- 成本失控：为了抗峰值，运维同学把副本数拉到 12，GPU 账单每月多 3 W+，老板脸色发青。
一句话：不瘦身，就上不了线。
二、技术对比：LLaMA-2 vs ChatGLM-6B 实测
在统一硬件（A10 / CUDA 11.8 / PyTorch 2.1）下，用官方示例脚本连续跑 1 k 条客服日志，结果如下：
| 指标 | LLaMA-2-7B-FP16 | LLaMA-2-7B-INT4(AWQ) | ChatGLM-6B-FP16 | ChatGLM-6B-INT4(GPTQ) |
|---|---|---|---|---|
| 显存占用 | 14.2 GB | 4.1 GB | 12.8 GB | 3.9 GB |
| 吞吐量(token/s) | 68 | 205 | 72 | 198 |
| 首 token 延迟(ms) | 680 | 220 | 650 | 210 |
| QA 准确率 | 92.3 % | 91.8 % | 90.5 % | 90.1 % |
结论：INT4 量化后速度×3，显存×0.3，准确率掉点 <1%，可接受。
三、核心方案：压缩 + 微调双管齐下
1. 模型压缩：AWQ 还是 GPTQ？
- AWQ：保留 1% 权重通道为 FP16，计算走 INT4，对“激活值异常大”的客服口语更鲁棒。
- GPTQ：纯 INT4，压缩率更高，适合显存极度紧张的场景。
本文主力用 AWQ，因为客服语料里“啊吧呢嘛”语气词多，激活值分布肥尾，AWQ 掉点更少。
2. 领域微调：LoRA 只动 0.8% 参数
- 冻结原模型，只在 q、k、v 投影矩阵插入 rank=16 的旁路。
- 训练数据：脱敏后的 18 W 条“用户问题-客服答案”对，最大长度 512。
- 训练时长：单卡 A100 2.5 h，loss 降到 1.42 停止。
四、代码实战：从量化到部署
以下脚本把“量化→微调→推理”串成一条流水线，并实时打印 GPU 占用，方便观察。
# compress_and_serve.py 1 import torch, gc, time, json 2 from transformers import AutoModelForCausalLM, AutoTokenizer 3 from awq import AutoAWQForCausalLM # pip install autoawq 4 from peft import PeftModel 5 from pynvml import nvmlDeviceGetHandleByIndex, nvmlDeviceGetMemoryInfo 6 7 MODEL_ID = "meta-llama/Llama-2-7b-hf" 8 CALIB_DATA = "calib_1k.jsonl" # 校准集：随机抽 1 k 条日志 9 LORA_PATH = "./lora-ckpt" 10 11 # -------------- 1. 量化 -------------- 12 def calib_loader(): 13 with open(CALIB_DATA) as f: 14 for line in f: 15 yield json.loads(line)["prompt"][:512] 16 16 model = AutoAWQForCausalLM.from_pretrained(MODEL_ID) 17 model.quantize(calib_loader, quant_config={ "q_group_size": 128, "w_bit": 4 }) 18 model.save_quantized("./llama2-7b-awq") 19 20 # -------------- 2. 加载 LoRA -------------- 21 tokenizer = AutoTokenizer.from_pretrained(MODEL_ID) 22 base = AutoModelForCausalLM.from_pretrained("./llama2-7b-awq", device_map="auto") 23 lora_model = PeftModel.from_pretrained(base, LORA_PATH) 24 25 # -------------- 3. 带监控的推理 -------------- 26 def gpu_mem(): 27 h = nvmlDeviceGetHandleByIndex(0) 28 return nvmlDeviceGetMemoryInfo(h).used // 1024 ** 2 29 30 prompt = "用户问：‘我订单怎么还没到货？’\n客服答：" 31 inputs = tokenizer(prompt, return_tensors="pt").to("cuda:0") 32 33 print("显存占用:", gpu_mem(), "MB") 34 st = time.time() 34 out = lora_model.generate(**inputs, max_new_tokens=64, temperature=0.3) 35 print("耗时:", time.time()-st, "s") 36 print("回复:", tokenizer.decode(out[0], skip_special_tokens=True))把脚本放到容器里docker run --gpus all -v $PWD:/ws pytorch:2.1-cuda11.8，一键python compress_and_serve.py即可看到：
显存占用: 4187 MB 耗时: 0.58 s 回复: 亲，您的订单已于昨日傍晚出库，预计今晚 21:00 前送达，可在 App 内查看实时轨迹哦～五、性能验证：RTF 对比
| 阶段 | RTF(=生成时间/音频时长) | 相对加速 |
|---|---|---|
| FP16 原始 | 0.30 | 1× |
| INT4 量化 | 0.10 | 3× |
| INT4+LoRA | 0.09 | 3.3× |
说明：客服答案按 60 字（≈3 s 语音）估算，RTF 越小越实时。
六、避坑指南
1. 校准集别乱拿
- 错例：用 Wiki 百科当校准集 → 口语场景激活值分布漂移，量化后 PPL 暴涨 27 %。
- 正例：从线上日志随机抽 1 k 条，覆盖“查订单/退差价/开发票”三类高频意图，分布与真实流量一致。
2. 防止灾难性遗忘
- 混合训练：LoRA 数据 + 5 % 通用指令数据（如 Alpaca-5k）一起喂，保证通用能力不掉。
- 学习率调小：1 e-4 → 5 e-5，验证集每 200 step 早停，可避免“答非所问”。
3. KV Cache 别忘开
- 推理时
use_cache=True，并在 AWQ 量化配置里把version="gemm"，才能走 CUDA kernel，否则速度回到“解放前”。
七、延伸：把模型搬进 Triton
如果业务流量再上台阶，单卡 200 QPS 仍扛不住，可以把上述 INT4 模型导出到NVIDIA Triton Inference Server：
- 用
awq_to_trtpy脚本把权重转 TensorRT-AWQ 格式。 - 写
config.pbtxt，开instance_group { count: 4 }多实例。 - 开
dynamic_batching+max_queue_delay: 5 ms，自动拼 batch。 - 压测结果：单 A10 吞吐提升到 680 token/s，RTF 再降一半。
踩坑提示：TensorRT 8.6 才原生支持 AWQ，低于此版本会报错“scale tensor dtype mismatch”。
八、小结
- 量化（AWQ/GPTQ）是“瘦身”第一步，能把显存压到 1/3，速度×3。
- LoRA 微调只动 0.8 % 参数，领域意图准确率提升 4~5 %，且训练成本极低。
- 校准集、混合数据、KV Cache 三个细节决定上线后“能用”还是“翻车”。
- 后续再上 Triton + TensorRT，可继续榨干 GPU，轻松应对千级并发。
整套流程在我们内部客服系统跑了三个月，目前稳定服务 500 QPS，GPU 账单降了 62 %，老板终于把眉头舒展开。希望这份笔记也能帮你把大模型真正“压”进生产环境，祝调参愉快!
