最近帮一位做内容的团队优化他们的情感分析服务模型用的是 Transformers 里的 BERT-base服务器是 Ubuntu 20.04GPU 暂时只有一张业务方天天抱怨单条结果要 1 秒多。其实模型本身没什么问题就是裸装裸跑完全没做推理侧的优化。这篇文章就记录一下我是怎么从搭建环境开始一步步把推理延迟降到可用水平的主要是 CPU 和单 GPU 场景下的通用做法适合正在学习或刚准备上线这类服务的开发者参考。整个过程我会拆成几个阶段来讲先聊动手前的选型判断然后是环境搭建、基线测试、瓶颈分析再到具体的优化手段和最终落地到 API 服务。每一步都会给出实际命令、参数和我在实践中踩过的坑希望能帮你少走弯路。1. 动手前先想清楚模型选型、硬件底数、优化目标三位一体很多人拿到任务第一反应是先跑起来再说这个思路在个人实验里没问题但一旦涉及部署上线前面省掉的思考都会在后面加倍还回来。我一般会在敲第一行命令前先把三件事定下来。1.1 模型选型不是越大越好也不是越小越好Transformers 模型指的是一类基于自注意力机制的模型Hugging Face 的 transformers 生态里集合了非常多的预训练权重比如大家熟知的 BERT、RoBERTa、DistilBERT以及生成类的 GPT、T5、BART 等等。选模型时我优先看任务类型和算力预算。以文本分类任务为例三种典型选择是BERT-base通用性强中文和英文都有大量微调好的权重但模型参数量约 1.1 亿推理延迟偏高。DistilBERTBERT 的蒸馏版本参数量大约是 BERT 的 60%速度通常能快 30% 到 40%精度只下降一点点是 CPU 部署的首选目标。ALBERT参数量理论值小但实际推理速度有时反而不如 DistilBERT因为它的 Embedding 分解引入了额外计算。我个人的建议是如果业务对精度要求极其苛刻选 BERT 系列再上量化优化其余大多数场景直接从 DistilBERT 或其蒸馏版本开始后续优化空间更大。1.2 硬件底数CPU 和 GPU 的优化思路完全不一样Ubuntu 20.04 是最常见的服务器操作系统GPU 驱动、CUDA、PyTorch 的环境配置都比较成熟。但我要强调的是CPU 部署不代表不专业反而在成本和推理稳定性上更有优势如果 QPS每秒查询数要求不高延迟容忍在 500 毫秒以内纯 CPU 加量化完全够用。GPU 的优势在于高吞吐并发和超大 batch但显存有限需要合理设置 batch size。没有 GPU 的情况下模型推理计算完全依赖 CPU所以量化、算子融合、线程优化就变得尤其重要。先想清楚你的业务到底是低延迟单条还是高并发批量这直接决定了后面优化手段的优先级。1.3 优化目标延迟、吞吐、成本不可能三角在我接触的绝大多数项目里业务方的需求都可以归纳为三个指标指标含义常用工具延迟Latency单条请求从进到出的耗时time、timeit、CUDA events吞吐Throughput单位时间能处理的请求数QPS、TPS成本Cost硬件投入、电力消耗、运维成本规格对比、TCO 估算如果业务方告诉你都想要那基本意味着需要做组合方案模型压缩 动态批处理 推理引擎优化。2. Ubuntu 20.04 上的环境搭建一套干净、可复现的安装路径环境这块我踩过很多坑尤其是 CUDA 和 PyTorch 的版本不对会出现告警、报错甚至模型推理直接崩掉。这里分享一套我用了很久的安装路径。2.1 Python 环境的隔离别再用系统 Python 裸装包我强烈建议先在 Ubuntu 20.04 上安装 Miniconda原因很简单深度学习库的依赖链非常复杂直接往系统 Python 里装包很容易把环境搞坏而且无法多项目共存。# 安装 Miniconda假设服务器是 x86_64 架构 wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh # 创建独立环境指定 Python 版本 conda create -n deploy python3.9 -y conda activate deployPython 版本的坑transformers 在较新版本中逐步提升最低 Python 版本要求但 3.9 在 Ubuntu 20.04 上兼容性最好各种依赖库的预编译包也很齐全。2.2 CUDA、cuDNN 与 PyTorch 的版本三角PyTorch 是 Transformers 模型推理时最常见的底层框架。版本匹配是最容易出错的地方配错了会直接导致模型推理时出现CUDA error: no kernel image is available for execution on the device。这里有一个可以直接照抄的版本组合适用于 2024 年后安装的稳定版# 先查看 GPU 驱动是否可用 nvidia-smi # 安装 PyTorch以 CUDA 12.1 为例注意 cuda-toolkit 需提前安装 pip install torch2.3.1 torchvision0.18.1 --index-url https://download.pytorch.org/whl/cu121注意点nvidia-smi显示的 Driver Version 是驱动版本它和 CUDA Toolkit 不完全是一回事请务必先确认驱动版本足够新。PyTorch 的 cu121 版本只依赖 CUDA 12.1 runtime不是说你服务器装的是 CUDA 11.8 就一定不能跑实际要看的是 PyTorch 自带的 CUDA 运行时对底层驱动的最低需求。目前常用的稳定组合是Ubuntu 20.04 驱动 535 CUDA 12.1 PyTorch 2.3.1。2.3 transformers 库安装与版本锁定pip install transformers4.41.2 accelerate0.31.0 pip install sentencepiece # 处理 BERT 系列的分词为什么必须加accelerate因为很多较干净的大模型权重格式执行起来需要更多显存或 requires 多卡依赖它的调度加装只有好处没有坏处。另外模型推理前的 tokenizer 也需要单独加载。如果环境无法访问外部网络可以先将模型下载到本地目录再拷贝到服务器下文会讲。3. 从加载模型到跑通第一版基线先让一切跑起来再谈优化很多教程会直接跳到如何用 ONNX 推理但我坚持认为先跑一个最朴素、最不优化的版本并测出基线才是整个推理优化项目的关键第一步。因为不测基线你后面做的任何优化都无法判断到底有没有效。3.1 模型下载与本地缓存管理Hugging Face 的 Hub 提供了非常方便的下载方式from transformers import AutoTokenizer, AutoModelForSequenceClassification model_id distilbert-base-uncased-finetuned-sst-2-english # 这会在 ~/.cache/huggingface/ 下缓存模型文件 tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForSequenceClassification.from_pretrained(model_id)这里有个很实际的问题在多个模型间来回切换时缓存目录会越滚越大。我习惯设置环境变量export HF_HOME/data/huggingface export TRANSFORMERS_CACHE/data/huggingface/transformers把模型缓存放到数据盘避免系统盘被塞满。如果目标机器没有外网就在有网的机器上用snapshot_download将仓库里的文件完整拉到本地然后整个目录打包拷过去from huggingface_hub import snapshot_download snapshot_download(repo_iddistilbert-base-uncased-finetuned-sst-2-english, local_dir./my_model)3.2 最小推理脚本与静态输入长度一个最简单的推理脚本长这样import torch import time from transformers import AutoTokenizer, AutoModelForSequenceClassification model_id ./my_model device torch.device(cuda if torch.cuda.is_available() else cpu) tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForSequenceClassification.from_pretrained(model_id).to(device) model.eval() # 关键静态 pad 到固定长度避免动态 shape 带来的额外计算 texts [ the movie is fantastic, i would not recommend this product, ] inputs tokenizer(texts, paddingmax_length, max_length128, truncationTrue, return_tensorspt) inputs {k: v.to(device) for k, v in inputs.items()} with torch.no_grad(): outputs model(**inputs) predictions torch.softmax(outputs.logits, dim-1) print(predictions)这里我特意加了paddingmax_length, max_length128原因后面优化章节会详细讲简单说就是固定输入长度能够减少动态 shape 判断也为下一步 ONNX 导出和静态量化铺路。3.3 建立基线延迟与吞吐的初始数据用下面的方式测试 1000 条文本的推理耗时会比较准确python benchmark.py我习惯记录三个数据单条延迟P50、P99吞吐每秒处理的样本数显存占用以 DistilBERT-base GPU 为例我的测试结果一般是 batch1 时单条约 8-12ms但如果用 BERT-base同样的单条会涨到 20-30ms。如果连这个数据都慢得离谱说明环境有问题先解决环境而不是盲目堆优化手段。4. 推理慢在哪儿花半小时做一次性能拆解一旦基线数据不理想问题就来了到底慢在 tokenizer 前置处理、模型前向计算还是后处理凭感觉猜是最低效的优化方式我习惯用工具把时间分布拆出来。4.1 用time和CUDA events做阶段计时CPU 端直接嵌套time.time()import time t0 time.time() inputs tokenizer(texts, paddingmax_length, max_length128, truncationTrue, return_tensorspt) t1 time.time() print(ftokenizer: {t1-t0:.4f}s)GPU 端注意PyTorch 的 CUDA 操作是异步的用 Python 的time测不准必须用 CUDA 事件start torch.cuda.Event(enable_timingTrue) end torch.cuda.Event(enable_timingTrue) start.record() with torch.no_grad(): outputs model(**inputs) end.record() torch.cuda.synchronize() print(fmodel forward: {start.elapsed_time(end):.2f}ms)4.2 三个最常见的性能瓶颈在我优化过的项目里推理慢通常不是模型本身多复杂而是下面几个环节出了问题动态 Padding 导致的计算浪费每个 batch 里最长的文本是 500 个 token其余 3 条都只有 30 个 token框架会按 500 去计算 attention 矩阵大量算力在空转。我第一次跑时单条延迟直接翻倍。batch size 过小导致 GPU 利用率低图形处理器有成千上万的运算核心batch1 时根本无法吃满算力。GPU 和 CPU 之间的数据拷贝输入要从内存搬到显存输出要从显存搬回内存频繁小量拷贝代价极高。4.3 不要忽略 tokenizer 本身的耗时你可能觉得分词很快实际在中文长文本场景下tokenizer 带来的 CPU 开销并不低。一个常见的坑是每一条请求都重新初始化分词器或者每次请求都重新加载整个模型。正确的做法是进程启动时加载一次后续复用同一个 tokenizer 和同一个模型实例。用这个思路我把一次请求阶段计时的典型数据列一下CPU 上的 BERT-base单条 60 token阶段耗时占比说明tokenizer15% - 25%python 侧逻辑复杂会让 CPU 短时打满模型 forward70% - 80%大头后处理softmax 等5%占比小但可以合并进模型输出头一次看到这个数据的人通常很惊讶原来 tokenizer 这么慢。所以优化的第一步不一定是量化模型而是先看有没有无谓的计算和重复初始化。5. 优化手段逐个上按性价比从高到低排列这一节是全文的重点我给出手头最常用、实测有效的优化手段按操作成本低、收益高到操作复杂、收益更高排列。5.1 动态量化CPU 场景的第一选择PyTorch 的量化有心酸历程但对 CPU 推理来说动态量化是最简单有效的一个操作。它只对nn.Linear层做量化不需要额外的校准数据一两行代码就能跑from transformers import AutoModelForSequenceClassification import torch model_id ./my_model model AutoModelForSequenceClassification.from_pretrained(model_id) quantized_model torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, dtypetorch.qint8, )这个过程不需要 GPU也不需要真正的数据分布模型大小直接砍到原来的约四分之一。以 BERT-base 在 CPU 上的推理为例动态量化后速度通常提升 20% 到 40%精度几乎无损。注意量化好的模型也要保存下来不能每次加载都重新量化torch.save(quantized_model.state_dict(), ./quantized_distilbert.pt)但要明确一点动态量化只优化了上文说的矩阵乘法部分transformer 里还有大量 LayerNorm、GeLU 等操作依旧是浮点计算所以单模型耗时不会到打对折的程度但已经很可观了。5.2 静态量化需要校准数据但收益更明显静态量化在推理前预先计算好激活值的变化范围推理过程中直接使用整数运算省去了每层激活值的动态量化开销。它的关键是需要一段代表性的校准数据model.eval() # 准备好 fp32_prepared_model 和校准数据 model.qconfig torch.ao.quantization.get_default_qconfig(fbgemm) torch.ao.quantization.prepare(model, inplaceTrue) # 循环若干 batch 校准 for batch in calibration_loader: model(batch) torch.ao.quantization.convert(model, inplaceTrue)在部分模型上静态量化比动态量化再快约 20%但调校过程会复杂一些。CPU 部署 INT8 静态量化 算子融合整体延迟可以比原始模型降低约 50% 以上。5.3 ONNX Runtime 导出模型无关的加速器ONNX Runtime 也是 CPU 推理加速的核心方案。它的原理是将模型转换成计算图并做算子融合、图优化和内存规划。Hugging Face 团队提供了官方的导出支持pip install optimum[onnxruntime]然后在代码里只需要这样from optimum.onnxruntime import ORTModelForSequenceClassification from transformers import AutoTokenizer model_id ./my_model ort_model ORTModelForSequenceClassification.from_pretrained(model_id, exportTrue) tokenizer AutoTokenizer.from_pretrained(model_id)ONNX Runtime 配合动态量化是 CPU 部署中性价比极高的组合。我实测过 DistilBERT 在单核 CPU 上从 150ms 降到 80ms 左右如果这还不够可以考虑OrtModelForSequenceClassification的session_options里增加线程数import onnxruntime as ort sess_options ort.SessionOptions() sess_options.intra_op_num_threads 4 # 根据 vCPU 数调整 ort_model ORTModelForSequenceClassification.from_pretrained( model_id, exportTrue, sess_optionssess_options, )5.4 固定 batch 与 KV 缓存优化对于生成类模型如 GPT 类Transformers 推理时需要通过自回归逐字生成调参use_cacheTrue可以复用历史键值避免重复计算延迟能改善 30% 以上outputs model.generate(**inputs, use_cacheTrue)对于分类模型则优先固定输入长度和 batch size。你会发现大多数推理引擎如 ONNX Runtime更喜欢固定 shape 的计算图这也是我前面强调max_length128的原因。5.5 显存层面的优化半精度推理如果有 GPU最简单的优化是使用torch.float16替代torch.float32model.half().to(cuda)这样做的好处是显存占用减半、计算速度更快代价是精度可能轻微下降。如果模型里有自定义层对半精度不友好在做完.half()之后务必用几组数据复测不能盲信之前的评估指标。5.6 更激进的选择模型蒸馏与剪枝如果上面的优化达到瓶颈就需要从模型结构层面动手了。蒸馏是拿大模型的输出做监督训练一个小模型去逼近它的效果剪枝则是去掉一些贡献不大的 attention head。这类方法通常需要重新训练或微调不在本文部署推理的范围内但是方向要了解。6. 从优化完的模型到稳定的服务API 封装与并发控制模型优化只是第一段路真正上线时还需要解决并发、排队、超时、预热、热更新这些问题。我用 FastAPI 做了一个比较轻量的封装分享给你。6.1 FastAPI 的基础服务实现from fastapi import FastAPI, Request from pydantic import BaseModel import torch from transformers import AutoTokenizer app FastAPI() device torch.device(cuda if torch.cuda.is_available() else cpu) tokenizer AutoTokenizer.from_pretrained(./my_model) # 假设是已经量化或 ONNX 导出后的模型这里以普通模型为例 model torch.load(./quantized_distilbert.pt, map_locationdevice) model.eval() class PredictRequest(BaseModel): text: str max_length: int 128 app.post(/predict) async def predict(req: PredictRequest, request: Request): inputs tokenizer([req.text], paddingmax_length, max_lengthreq.max_length, truncationTrue, return_tensorspt) inputs {k: v.to(device) for k, v in inputs.items()} with torch.no_grad(): logits model(**inputs).logits pred torch.softmax(logits, dim-1)[0].tolist() return {probabilities: pred}这里有几个很容易踩的坑必须使用异步函数与同步推理的正确姿势上面的代码把同步推理放进了 async 函数虽然能跑但在高并发下会阻塞事件循环。更稳妥的方式是用run_in_executor在线程池里执行或者用队列把所有请求攒起来批处理。模型预热服务启动后第一次推理会触发加载和缓存建立冷启动延迟极高。我通常用lifespan在启动时先跑几条假数据app.on_event(startup) def warmup(): _ tokenizer(warmup text, return_tensorspt) with torch.no_grad(): model(input_ids, attention_mask)6.2 批处理合并提升吞吐的大杀器单条请求推理是最高延迟、最低吞吐的方式。FastAPI 自身不带版本队列我习惯引入一个简单的人工队列请求进来后先入队列不立刻推理攒够 8 条请求或等待 20 毫秒集中做一次 batch 推理把结果按顺序回传。这样 GPU 利用率明显提升QPS 往往能提升 2 到 3 倍。实现上可以借助asyncio.Queue和条件变量也可以直接用现成的scheduler库比如nvidia-dali这种但简单场景自己写队列完全够用。6.3 模型热更新与优雅关闭模型迭代是常态直接替换文件后重启服务会丢弃流量。更稳妥的方案是设计两层结构外层是 API 进程内层是模型实例池。将模型版本设置为可配置项更新时预加载新模型到进程内存通过开关平滑切换旧请求继续使用旧模型直到处理完毕class ModelContainer: def __init__(self): self.model None self.version None def load(self, version): # 加载对应版本模型 self.model ... self.version version def predict(self, inputs): return self.model(inputs) container ModelContainer() app.post(/predict) def predict(req): cur container.predict(...) return cur旧进程处理完在队列里的请求后自然退出新进程继续接收。这个方案完全不需要停机。7. 实测数据复盘什么有效、什么无效、优化顺序怎么排光说方法不够我把自己在一台 4 核 CPU 机器上的实测结果整理出来硬件是 Intel 8 vCPU 16GB 内存无 GPU模型选择 DistilBERT-base单条文本长度固定 128。7.1 各方案实测对比方案P50 延迟QPS备注原始 PyTorchFP32125ms8基线动态量化INT888ms11无精度校准ONNX RuntimeFP3272ms14启用图优化ONNX Runtime 动态量化53ms19性价比最高静态量化 ONNX Runtime48ms21需要校准数据批量推理batch8单条约 20ms接近 40服务端延迟有感知差异但吞吐翻倍可以看到光靠一个方案很难彻底解决问题叠加起来才能有质变。7.2 我推荐的优化顺序根据上面的数据和工作量我在项目里一般按这个顺序操作先用脚本跑出原始基线。加载时设置torch.set_num_threads合理线程数默认线程数有时候会炸掉资源。直接用quantize_dynamic做动态量化延迟通常会明显下降。导出 ONNX 并开启图优化这一步往往比量化更有效。如果 CPU 资源多但模型复杂上静态量化校准数据量一般 500 到 1000 条就够。最后再考虑服务化、批处理和缓存。不要一上来就上静态量化因为它的校准流程和精度验证都比较费劲动态量化加 ONNX Runtime 在绝大多数场景已足够。7.3 容易被忽略的配置细节torch.set_num_threads(4)线程数设太高会造成上下文切换反而更慢。export ONNX时需固定sequence_length否则动态 shape 会削弱图优化效果。关闭 PyTorch 的grad推理时务必在torch.no_grad()下进行否则模型会构建计算图内存和耗时都白白增加。缓存之后的数据传输层也要处理模型服务的瓶颈往往不在 GPU而在 CPU 和网络 IO。8. 后续还能往哪个方向走如果你已经把上面这些手段都试完了延迟还是没有达到预期那就已经进入更复杂的优化圈了有几条路可以继续走GPU 专用推理引擎NVIDIA 的 TensorRT 可以对模型进行更细粒度的层融合和内核选择比 ONNX Runtime 在 GPU 上再快 20% 左右但需要花时间处理兼容性和动态 shape 问题。大模型的专用推理框架如果你部署的是 GPT、Llama 这类生成模型直接使用 vLLM 或类似方案它能通过 PagedAttention 极大地提高长文本生成的显存利用率和吞吐。模型再蒸馏如果业务方愿意给出足够的标注数据蒸馏出一个更小的 mini 模型推理延迟可以降到原来的五分之一以下。这个动作需要重新走训练流程但值得做。这些都是在我手头常见场景下摸索出来的未必覆盖所有情况但至少在 Ubuntu 20.04 中搭建 Transformers 模型、然后用各种手段优化推理这一套上你按顺序走完性能大概率已经能上线了。最后再分享一个我自己的习惯每一轮优化都要重新跑一遍完整的评测流程用同一组测试集、同一个长度、同一个线程数数据才有可比性否则很容易被某一次的偶然波动带偏。优化推理从来不是一次性的工作随着业务量和数据分布的变化模型和服务都需要持续调优。
最近帮一位做内容的团队优化他们的情感分析服务模型用的是 Transformers 里的 BERT-base服务器是 Ubuntu 20.04GPU 暂时只有一张业务方天天抱怨单条结果要 1 秒多。其实模型本身没什么问题就是裸装裸跑完全没做推理侧的优化。这篇文章就记录一下我是怎么从搭建环境开始一步步把推理延迟降到可用水平的主要是 CPU 和单 GPU 场景下的通用做法适合正在学习或刚准备上线这类服务的开发者参考。整个过程我会拆成几个阶段来讲先聊动手前的选型判断然后是环境搭建、基线测试、瓶颈分析再到具体的优化手段和最终落地到 API 服务。每一步都会给出实际命令、参数和我在实践中踩过的坑希望能帮你少走弯路。1. 动手前先想清楚模型选型、硬件底数、优化目标三位一体很多人拿到任务第一反应是先跑起来再说这个思路在个人实验里没问题但一旦涉及部署上线前面省掉的思考都会在后面加倍还回来。我一般会在敲第一行命令前先把三件事定下来。1.1 模型选型不是越大越好也不是越小越好Transformers 模型指的是一类基于自注意力机制的模型Hugging Face 的 transformers 生态里集合了非常多的预训练权重比如大家熟知的 BERT、RoBERTa、DistilBERT以及生成类的 GPT、T5、BART 等等。选模型时我优先看任务类型和算力预算。以文本分类任务为例三种典型选择是BERT-base通用性强中文和英文都有大量微调好的权重但模型参数量约 1.1 亿推理延迟偏高。DistilBERTBERT 的蒸馏版本参数量大约是 BERT 的 60%速度通常能快 30% 到 40%精度只下降一点点是 CPU 部署的首选目标。ALBERT参数量理论值小但实际推理速度有时反而不如 DistilBERT因为它的 Embedding 分解引入了额外计算。我个人的建议是如果业务对精度要求极其苛刻选 BERT 系列再上量化优化其余大多数场景直接从 DistilBERT 或其蒸馏版本开始后续优化空间更大。1.2 硬件底数CPU 和 GPU 的优化思路完全不一样Ubuntu 20.04 是最常见的服务器操作系统GPU 驱动、CUDA、PyTorch 的环境配置都比较成熟。但我要强调的是CPU 部署不代表不专业反而在成本和推理稳定性上更有优势如果 QPS每秒查询数要求不高延迟容忍在 500 毫秒以内纯 CPU 加量化完全够用。GPU 的优势在于高吞吐并发和超大 batch但显存有限需要合理设置 batch size。没有 GPU 的情况下模型推理计算完全依赖 CPU所以量化、算子融合、线程优化就变得尤其重要。先想清楚你的业务到底是低延迟单条还是高并发批量这直接决定了后面优化手段的优先级。1.3 优化目标延迟、吞吐、成本不可能三角在我接触的绝大多数项目里业务方的需求都可以归纳为三个指标指标含义常用工具延迟Latency单条请求从进到出的耗时time、timeit、CUDA events吞吐Throughput单位时间能处理的请求数QPS、TPS成本Cost硬件投入、电力消耗、运维成本规格对比、TCO 估算如果业务方告诉你都想要那基本意味着需要做组合方案模型压缩 动态批处理 推理引擎优化。2. Ubuntu 20.04 上的环境搭建一套干净、可复现的安装路径环境这块我踩过很多坑尤其是 CUDA 和 PyTorch 的版本不对会出现告警、报错甚至模型推理直接崩掉。这里分享一套我用了很久的安装路径。2.1 Python 环境的隔离别再用系统 Python 裸装包我强烈建议先在 Ubuntu 20.04 上安装 Miniconda原因很简单深度学习库的依赖链非常复杂直接往系统 Python 里装包很容易把环境搞坏而且无法多项目共存。# 安装 Miniconda假设服务器是 x86_64 架构 wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh # 创建独立环境指定 Python 版本 conda create -n deploy python3.9 -y conda activate deployPython 版本的坑transformers 在较新版本中逐步提升最低 Python 版本要求但 3.9 在 Ubuntu 20.04 上兼容性最好各种依赖库的预编译包也很齐全。2.2 CUDA、cuDNN 与 PyTorch 的版本三角PyTorch 是 Transformers 模型推理时最常见的底层框架。版本匹配是最容易出错的地方配错了会直接导致模型推理时出现CUDA error: no kernel image is available for execution on the device。这里有一个可以直接照抄的版本组合适用于 2024 年后安装的稳定版# 先查看 GPU 驱动是否可用 nvidia-smi # 安装 PyTorch以 CUDA 12.1 为例注意 cuda-toolkit 需提前安装 pip install torch2.3.1 torchvision0.18.1 --index-url https://download.pytorch.org/whl/cu121注意点nvidia-smi显示的 Driver Version 是驱动版本它和 CUDA Toolkit 不完全是一回事请务必先确认驱动版本足够新。PyTorch 的 cu121 版本只依赖 CUDA 12.1 runtime不是说你服务器装的是 CUDA 11.8 就一定不能跑实际要看的是 PyTorch 自带的 CUDA 运行时对底层驱动的最低需求。目前常用的稳定组合是Ubuntu 20.04 驱动 535 CUDA 12.1 PyTorch 2.3.1。2.3 transformers 库安装与版本锁定pip install transformers4.41.2 accelerate0.31.0 pip install sentencepiece # 处理 BERT 系列的分词为什么必须加accelerate因为很多较干净的大模型权重格式执行起来需要更多显存或 requires 多卡依赖它的调度加装只有好处没有坏处。另外模型推理前的 tokenizer 也需要单独加载。如果环境无法访问外部网络可以先将模型下载到本地目录再拷贝到服务器下文会讲。3. 从加载模型到跑通第一版基线先让一切跑起来再谈优化很多教程会直接跳到如何用 ONNX 推理但我坚持认为先跑一个最朴素、最不优化的版本并测出基线才是整个推理优化项目的关键第一步。因为不测基线你后面做的任何优化都无法判断到底有没有效。3.1 模型下载与本地缓存管理Hugging Face 的 Hub 提供了非常方便的下载方式from transformers import AutoTokenizer, AutoModelForSequenceClassification model_id distilbert-base-uncased-finetuned-sst-2-english # 这会在 ~/.cache/huggingface/ 下缓存模型文件 tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForSequenceClassification.from_pretrained(model_id)这里有个很实际的问题在多个模型间来回切换时缓存目录会越滚越大。我习惯设置环境变量export HF_HOME/data/huggingface export TRANSFORMERS_CACHE/data/huggingface/transformers把模型缓存放到数据盘避免系统盘被塞满。如果目标机器没有外网就在有网的机器上用snapshot_download将仓库里的文件完整拉到本地然后整个目录打包拷过去from huggingface_hub import snapshot_download snapshot_download(repo_iddistilbert-base-uncased-finetuned-sst-2-english, local_dir./my_model)3.2 最小推理脚本与静态输入长度一个最简单的推理脚本长这样import torch import time from transformers import AutoTokenizer, AutoModelForSequenceClassification model_id ./my_model device torch.device(cuda if torch.cuda.is_available() else cpu) tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForSequenceClassification.from_pretrained(model_id).to(device) model.eval() # 关键静态 pad 到固定长度避免动态 shape 带来的额外计算 texts [ the movie is fantastic, i would not recommend this product, ] inputs tokenizer(texts, paddingmax_length, max_length128, truncationTrue, return_tensorspt) inputs {k: v.to(device) for k, v in inputs.items()} with torch.no_grad(): outputs model(**inputs) predictions torch.softmax(outputs.logits, dim-1) print(predictions)这里我特意加了paddingmax_length, max_length128原因后面优化章节会详细讲简单说就是固定输入长度能够减少动态 shape 判断也为下一步 ONNX 导出和静态量化铺路。3.3 建立基线延迟与吞吐的初始数据用下面的方式测试 1000 条文本的推理耗时会比较准确python benchmark.py我习惯记录三个数据单条延迟P50、P99吞吐每秒处理的样本数显存占用以 DistilBERT-base GPU 为例我的测试结果一般是 batch1 时单条约 8-12ms但如果用 BERT-base同样的单条会涨到 20-30ms。如果连这个数据都慢得离谱说明环境有问题先解决环境而不是盲目堆优化手段。4. 推理慢在哪儿花半小时做一次性能拆解一旦基线数据不理想问题就来了到底慢在 tokenizer 前置处理、模型前向计算还是后处理凭感觉猜是最低效的优化方式我习惯用工具把时间分布拆出来。4.1 用time和CUDA events做阶段计时CPU 端直接嵌套time.time()import time t0 time.time() inputs tokenizer(texts, paddingmax_length, max_length128, truncationTrue, return_tensorspt) t1 time.time() print(ftokenizer: {t1-t0:.4f}s)GPU 端注意PyTorch 的 CUDA 操作是异步的用 Python 的time测不准必须用 CUDA 事件start torch.cuda.Event(enable_timingTrue) end torch.cuda.Event(enable_timingTrue) start.record() with torch.no_grad(): outputs model(**inputs) end.record() torch.cuda.synchronize() print(fmodel forward: {start.elapsed_time(end):.2f}ms)4.2 三个最常见的性能瓶颈在我优化过的项目里推理慢通常不是模型本身多复杂而是下面几个环节出了问题动态 Padding 导致的计算浪费每个 batch 里最长的文本是 500 个 token其余 3 条都只有 30 个 token框架会按 500 去计算 attention 矩阵大量算力在空转。我第一次跑时单条延迟直接翻倍。batch size 过小导致 GPU 利用率低图形处理器有成千上万的运算核心batch1 时根本无法吃满算力。GPU 和 CPU 之间的数据拷贝输入要从内存搬到显存输出要从显存搬回内存频繁小量拷贝代价极高。4.3 不要忽略 tokenizer 本身的耗时你可能觉得分词很快实际在中文长文本场景下tokenizer 带来的 CPU 开销并不低。一个常见的坑是每一条请求都重新初始化分词器或者每次请求都重新加载整个模型。正确的做法是进程启动时加载一次后续复用同一个 tokenizer 和同一个模型实例。用这个思路我把一次请求阶段计时的典型数据列一下CPU 上的 BERT-base单条 60 token阶段耗时占比说明tokenizer15% - 25%python 侧逻辑复杂会让 CPU 短时打满模型 forward70% - 80%大头后处理softmax 等5%占比小但可以合并进模型输出头一次看到这个数据的人通常很惊讶原来 tokenizer 这么慢。所以优化的第一步不一定是量化模型而是先看有没有无谓的计算和重复初始化。5. 优化手段逐个上按性价比从高到低排列这一节是全文的重点我给出手头最常用、实测有效的优化手段按操作成本低、收益高到操作复杂、收益更高排列。5.1 动态量化CPU 场景的第一选择PyTorch 的量化有心酸历程但对 CPU 推理来说动态量化是最简单有效的一个操作。它只对nn.Linear层做量化不需要额外的校准数据一两行代码就能跑from transformers import AutoModelForSequenceClassification import torch model_id ./my_model model AutoModelForSequenceClassification.from_pretrained(model_id) quantized_model torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, dtypetorch.qint8, )这个过程不需要 GPU也不需要真正的数据分布模型大小直接砍到原来的约四分之一。以 BERT-base 在 CPU 上的推理为例动态量化后速度通常提升 20% 到 40%精度几乎无损。注意量化好的模型也要保存下来不能每次加载都重新量化torch.save(quantized_model.state_dict(), ./quantized_distilbert.pt)但要明确一点动态量化只优化了上文说的矩阵乘法部分transformer 里还有大量 LayerNorm、GeLU 等操作依旧是浮点计算所以单模型耗时不会到打对折的程度但已经很可观了。5.2 静态量化需要校准数据但收益更明显静态量化在推理前预先计算好激活值的变化范围推理过程中直接使用整数运算省去了每层激活值的动态量化开销。它的关键是需要一段代表性的校准数据model.eval() # 准备好 fp32_prepared_model 和校准数据 model.qconfig torch.ao.quantization.get_default_qconfig(fbgemm) torch.ao.quantization.prepare(model, inplaceTrue) # 循环若干 batch 校准 for batch in calibration_loader: model(batch) torch.ao.quantization.convert(model, inplaceTrue)在部分模型上静态量化比动态量化再快约 20%但调校过程会复杂一些。CPU 部署 INT8 静态量化 算子融合整体延迟可以比原始模型降低约 50% 以上。5.3 ONNX Runtime 导出模型无关的加速器ONNX Runtime 也是 CPU 推理加速的核心方案。它的原理是将模型转换成计算图并做算子融合、图优化和内存规划。Hugging Face 团队提供了官方的导出支持pip install optimum[onnxruntime]然后在代码里只需要这样from optimum.onnxruntime import ORTModelForSequenceClassification from transformers import AutoTokenizer model_id ./my_model ort_model ORTModelForSequenceClassification.from_pretrained(model_id, exportTrue) tokenizer AutoTokenizer.from_pretrained(model_id)ONNX Runtime 配合动态量化是 CPU 部署中性价比极高的组合。我实测过 DistilBERT 在单核 CPU 上从 150ms 降到 80ms 左右如果这还不够可以考虑OrtModelForSequenceClassification的session_options里增加线程数import onnxruntime as ort sess_options ort.SessionOptions() sess_options.intra_op_num_threads 4 # 根据 vCPU 数调整 ort_model ORTModelForSequenceClassification.from_pretrained( model_id, exportTrue, sess_optionssess_options, )5.4 固定 batch 与 KV 缓存优化对于生成类模型如 GPT 类Transformers 推理时需要通过自回归逐字生成调参use_cacheTrue可以复用历史键值避免重复计算延迟能改善 30% 以上outputs model.generate(**inputs, use_cacheTrue)对于分类模型则优先固定输入长度和 batch size。你会发现大多数推理引擎如 ONNX Runtime更喜欢固定 shape 的计算图这也是我前面强调max_length128的原因。5.5 显存层面的优化半精度推理如果有 GPU最简单的优化是使用torch.float16替代torch.float32model.half().to(cuda)这样做的好处是显存占用减半、计算速度更快代价是精度可能轻微下降。如果模型里有自定义层对半精度不友好在做完.half()之后务必用几组数据复测不能盲信之前的评估指标。5.6 更激进的选择模型蒸馏与剪枝如果上面的优化达到瓶颈就需要从模型结构层面动手了。蒸馏是拿大模型的输出做监督训练一个小模型去逼近它的效果剪枝则是去掉一些贡献不大的 attention head。这类方法通常需要重新训练或微调不在本文部署推理的范围内但是方向要了解。6. 从优化完的模型到稳定的服务API 封装与并发控制模型优化只是第一段路真正上线时还需要解决并发、排队、超时、预热、热更新这些问题。我用 FastAPI 做了一个比较轻量的封装分享给你。6.1 FastAPI 的基础服务实现from fastapi import FastAPI, Request from pydantic import BaseModel import torch from transformers import AutoTokenizer app FastAPI() device torch.device(cuda if torch.cuda.is_available() else cpu) tokenizer AutoTokenizer.from_pretrained(./my_model) # 假设是已经量化或 ONNX 导出后的模型这里以普通模型为例 model torch.load(./quantized_distilbert.pt, map_locationdevice) model.eval() class PredictRequest(BaseModel): text: str max_length: int 128 app.post(/predict) async def predict(req: PredictRequest, request: Request): inputs tokenizer([req.text], paddingmax_length, max_lengthreq.max_length, truncationTrue, return_tensorspt) inputs {k: v.to(device) for k, v in inputs.items()} with torch.no_grad(): logits model(**inputs).logits pred torch.softmax(logits, dim-1)[0].tolist() return {probabilities: pred}这里有几个很容易踩的坑必须使用异步函数与同步推理的正确姿势上面的代码把同步推理放进了 async 函数虽然能跑但在高并发下会阻塞事件循环。更稳妥的方式是用run_in_executor在线程池里执行或者用队列把所有请求攒起来批处理。模型预热服务启动后第一次推理会触发加载和缓存建立冷启动延迟极高。我通常用lifespan在启动时先跑几条假数据app.on_event(startup) def warmup(): _ tokenizer(warmup text, return_tensorspt) with torch.no_grad(): model(input_ids, attention_mask)6.2 批处理合并提升吞吐的大杀器单条请求推理是最高延迟、最低吞吐的方式。FastAPI 自身不带版本队列我习惯引入一个简单的人工队列请求进来后先入队列不立刻推理攒够 8 条请求或等待 20 毫秒集中做一次 batch 推理把结果按顺序回传。这样 GPU 利用率明显提升QPS 往往能提升 2 到 3 倍。实现上可以借助asyncio.Queue和条件变量也可以直接用现成的scheduler库比如nvidia-dali这种但简单场景自己写队列完全够用。6.3 模型热更新与优雅关闭模型迭代是常态直接替换文件后重启服务会丢弃流量。更稳妥的方案是设计两层结构外层是 API 进程内层是模型实例池。将模型版本设置为可配置项更新时预加载新模型到进程内存通过开关平滑切换旧请求继续使用旧模型直到处理完毕class ModelContainer: def __init__(self): self.model None self.version None def load(self, version): # 加载对应版本模型 self.model ... self.version version def predict(self, inputs): return self.model(inputs) container ModelContainer() app.post(/predict) def predict(req): cur container.predict(...) return cur旧进程处理完在队列里的请求后自然退出新进程继续接收。这个方案完全不需要停机。7. 实测数据复盘什么有效、什么无效、优化顺序怎么排光说方法不够我把自己在一台 4 核 CPU 机器上的实测结果整理出来硬件是 Intel 8 vCPU 16GB 内存无 GPU模型选择 DistilBERT-base单条文本长度固定 128。7.1 各方案实测对比方案P50 延迟QPS备注原始 PyTorchFP32125ms8基线动态量化INT888ms11无精度校准ONNX RuntimeFP3272ms14启用图优化ONNX Runtime 动态量化53ms19性价比最高静态量化 ONNX Runtime48ms21需要校准数据批量推理batch8单条约 20ms接近 40服务端延迟有感知差异但吞吐翻倍可以看到光靠一个方案很难彻底解决问题叠加起来才能有质变。7.2 我推荐的优化顺序根据上面的数据和工作量我在项目里一般按这个顺序操作先用脚本跑出原始基线。加载时设置torch.set_num_threads合理线程数默认线程数有时候会炸掉资源。直接用quantize_dynamic做动态量化延迟通常会明显下降。导出 ONNX 并开启图优化这一步往往比量化更有效。如果 CPU 资源多但模型复杂上静态量化校准数据量一般 500 到 1000 条就够。最后再考虑服务化、批处理和缓存。不要一上来就上静态量化因为它的校准流程和精度验证都比较费劲动态量化加 ONNX Runtime 在绝大多数场景已足够。7.3 容易被忽略的配置细节torch.set_num_threads(4)线程数设太高会造成上下文切换反而更慢。export ONNX时需固定sequence_length否则动态 shape 会削弱图优化效果。关闭 PyTorch 的grad推理时务必在torch.no_grad()下进行否则模型会构建计算图内存和耗时都白白增加。缓存之后的数据传输层也要处理模型服务的瓶颈往往不在 GPU而在 CPU 和网络 IO。8. 后续还能往哪个方向走如果你已经把上面这些手段都试完了延迟还是没有达到预期那就已经进入更复杂的优化圈了有几条路可以继续走GPU 专用推理引擎NVIDIA 的 TensorRT 可以对模型进行更细粒度的层融合和内核选择比 ONNX Runtime 在 GPU 上再快 20% 左右但需要花时间处理兼容性和动态 shape 问题。大模型的专用推理框架如果你部署的是 GPT、Llama 这类生成模型直接使用 vLLM 或类似方案它能通过 PagedAttention 极大地提高长文本生成的显存利用率和吞吐。模型再蒸馏如果业务方愿意给出足够的标注数据蒸馏出一个更小的 mini 模型推理延迟可以降到原来的五分之一以下。这个动作需要重新走训练流程但值得做。这些都是在我手头常见场景下摸索出来的未必覆盖所有情况但至少在 Ubuntu 20.04 中搭建 Transformers 模型、然后用各种手段优化推理这一套上你按顺序走完性能大概率已经能上线了。最后再分享一个我自己的习惯每一轮优化都要重新跑一遍完整的评测流程用同一组测试集、同一个长度、同一个线程数数据才有可比性否则很容易被某一次的偶然波动带偏。优化推理从来不是一次性的工作随着业务量和数据分布的变化模型和服务都需要持续调优。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
