Python AI 实战（19/20）：Python 模型推理太慢怎么办？量化、批处理、GPU 加速方案

Python AI 实战问答速查手册 · 第 19/20 问

所属板块：部署上线

第一步永远是诊断：慢在哪一段？ 简单计时 time 包住"预处理→模型推理→后处理"，确定瓶颈是模型计算、数据 IO 还是服务端并发设计。

方案一：模型层面（效果最直接）

1. 量化（Quantization）：把权重从 fp32 压到 INT8/INT4，可以降低权重存储，但速度和精度变化取决于模型、硬件及量化方案。选择目标运行时支持的量化工具，用代表性数据比较量化前后的指标；不要把 INT8 CPU 方案直接套到 CUDA 模型上。
2. 模型蒸馏：用大模型教小模型，小模型推理更快（如 7B→1.5B）。
3. 换小模型/剪枝：业务允许就换更小架构。

方案二：推理引擎加速

引擎	适用	验证重点
ONNX Runtime	通用，CPU/GPU 均可	算子支持、执行提供程序及输出一致性
TensorRT	NVIDIA GPU 专属，图优化 + fp16	硬件、精度模式、动态形状及构建开销
vLLM	大模型（LLM）推理	目标模型支持、并发、上下文和 KV 缓存占用

import numpy as np
import onnxruntime as ort

# 对应第 18 问的双特征示例；需先导出并验证 model.onnx
available = ort.get_available_providers()
providers = (["CUDAExecutionProvider"] if "CUDAExecutionProvider" in available else [])
providers += ["CPUExecutionProvider"]
session = ort.InferenceSession("model.onnx", providers=providers)
x = np.asarray([[1.0, 2.0]], dtype=np.float32)
output = session.run(None, {session.get_inputs()[0].name: x})
print(output)

方案三：服务/工程层面（吞吐优化）

1. 批处理（Batching）：把多个请求攒起来一起推理，可能改善 GPU 利用率和吞吐，但会引入排队等待（异步队列 + 定时刷批）。
2. 缓存：相同输入直接返回缓存结果（LRU 缓存，如 functools.lru_cache），重复请求几乎零成本。
3. 预加载 + 常驻：模型在进程启动时加载一次（避免每次请求加载）；推理进程与 Web 进程分离（如 Celery/消息队列）。
4. 避免 GPU-CPU 反复拷贝：数据尽量留在 GPU 上；with torch.no_grad()；合并小张量。
5. 并发：异步适合 I/O 等待，不会自动加速同步模型计算；按负载安排推理工作进程或队列，并实测 CPU 线程数。

指标取舍：延迟（P95）和吞吐（QPS）需要结合排队、资源和批大小权衡——聊天类要低延迟（批大小小），离线批处理要高吞吐（批大小大）。先定业务目标再选方案。

建议顺序：建立基线 → 定位瓶颈 → 每次只改一种优化 → 比较延迟、吞吐、内存和模型质量。GPU 计时时需正确同步或使用设备事件，避免只量到异步提交耗时。