AI模型部署实战：从量化压缩到推理加速的全链路指南

AI模型部署为什么总卡在推理环节

大模型训练完成后，工程团队面对的第一个难题往往不是模型精度，而是如何把它稳定、高效地跑在生产环境里。GPU显存不足、首Token延迟高、吞吐量上不去——这些问题在AIGC应用落地中反复出现。本文从模型量化、推理引擎选型、服务化部署三个层面，拆解AI模型部署的完整链路。

模型量化：精度损失与推理加速的平衡点

大模型参数量动辄百亿，直接用FP32精度部署，一张A100 80G都装不下70B模型。量化是降低显存占用最直接的手段。

目前主流方案是GPTQ和AWQ两种4bit量化：

# 使用AutoGPTQ进行4bit量化
from transformers import AutoTokenizer, AutoModelForCausalLM
from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig

model_path = "/data/models/qwen2-72b"
quant_output = "/data/models/qwen2-72b-gptq"

tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForCausalLM.from_pretrained(model_path, torch_dtype=torch.float16)

# 量化配置：4bit, group_size=128
quantize_config = BaseQuantizeConfig(
    bits=4,
    group_size=128,
    desc_act=True  # 启用激活值排序，精度更好
)

# 准备校准数据
from datasets import load_dataset
calib_data = load_dataset("wikitext", "wikitext-2-raw-v1", split="train")[:512]
examples = [tokenizer(d["text"]) for d in calib_data if d["text"]]

model_q = AutoGPTQForCausalLM.quantize(
    model,
    quantize_config=quantize_config,
    examples=examples
)
model_q.save_quantized(quant_output)

实测数据（Qwen2-72B，单卡A100 80G）：

• FP16：无法加载，需要2张A100
• GPTQ 4bit：显存占用约38G，推理速度提升1.8倍，MMLU损失0.6%
• AWQ 4bit：显存占用约36G，推理速度提升2.1倍，MMLU损失0.8%

AWQ在推理速度上略优，GPTQ在精度保持上略好。选择取决于场景——对话系统对延迟敏感选AWQ，知识密集型任务对精度敏感选GPTQ。

推理引擎选型：vLLM vs TensorRT-LLM vs Ollama

量化只是第一步，推理引擎决定了实际的吞吐和延迟表现。

vLLM：PagedAttention带来的吞吐革命

vLLM的核心创新是PagedAttention，借鉴操作系统的虚拟内存分页机制管理KV Cache，显存利用率接近100%。

# 启动vLLM OpenAI兼容API服务
python -m vllm.entrypoints.openai.api_server \
    --model /data/models/qwen2-72b-gptq \
    --quantization gptq \
    --tensor-parallel-size 2 \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.92 \
    --port 8000

关键参数说明：

• tensor-parallel-size：多卡并行数，72B模型2卡即可
• max-model-len：最大上下文长度，直接影响KV Cache占用
• gpu-memory-utilization：GPU显存使用上限，0.92留出安全余量

吞吐测试（Qwen2-72B 4bit，2xA100，并发50）：

• vLLM连续批处理：1280 tokens/s
• 传统FIFO调度：420 tokens/s

连续批处理（Continuous Batching）是吞吐提升的关键——新请求不必等待前一批完成，直接插入正在执行的batch。

TensorRT-LLM：NVIDIA的极致优化路径

TensorRT-LLM走的是编译优化路线，将模型计算图编译为NVIDIA GPU高度优化的kernel。

# TensorRT-LLM模型编译
from tensorrt_llm import LLM, ModelConfig

config = ModelConfig(
    model_dir="/data/models/qwen2-72b",
    quantization="int4_awq",
    tp_size=2,
    max_batch_size=64,
    max_input_len=7168,
    max_output_len=1024,
)
llm = LLM(config)
llm.build()  # 编译优化，耗时约15分钟
llm.save("/data/models/qwen2-72b-trtllm")

TensorRT-LLM优势场景：固定硬件、固定模型、高并发在线服务。编译后推理速度比vLLM快15%-20%，但灵活性差——换模型或改参数需要重新编译。

部署架构：从单机到弹性伸缩

生产环境不能只靠一个推理进程。完整的AI模型部署架构需要考虑流量调度、健康检查和弹性伸缩。

# Kubernetes部署清单核心片段
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen2-72b
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        resources:
          limits:
            nvidia.com/gpu: 2
        command: ["python", "-m", "vllm.entrypoints.openai.api_server"]
        args:
          - "--model"
          - "/models/qwen2-72b-gptq"
          - "--quantization"
          - "gptq"
          - "--tensor-parallel-size"
          - "2"
          - "--max-model-len"
          - "8192"
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 120
          periodSeconds: 30
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm-qwen2-72b
  ports:
  - port: 8000
  type: ClusterIP
---
# HPA：基于GPU利用率自动伸缩
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: vllm-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-qwen2-72b
  minReplicas: 2
  maxReplicas: 8
  metrics:
  - type: Pods
    pods:
      metric:
        name: gpu_utilization
      target:
        type: Utilization
        averageUtilization: 70

这套架构在实测中可承载QPS 30+的在线对话请求，P99延迟控制在800ms以内（首Token延迟）。

常见问题诊断与调优

OOM Kill频繁发生：检查gpu-memory-utilization设置，建议不超过0.92；同时确认max-model-len是否过大——8K上下文下KV Cache占显存约4G，32K则占16G。

首Token延迟高：Prefill阶段是计算密集型操作，输入越长延迟越高。解决方案：限制单次输入长度，或启用Chunked Prefill将长输入拆分为多个chunk并行处理。

吞吐量上不去：确认是否开启了Continuous Batching；检查max-num-seqs（默认256）是否合理；排除网络IO瓶颈——使用nvtop确认GPU利用率是否在90%以上。

量化后精度下降明显：尝试group_size=32替代128（牺牲速度换精度）；检查校准数据集是否覆盖了生产分布；考虑混合精度——Embedding层保持FP16，仅Linear层量化。