做AI服务部署的同学大概都遇到过这样的场景：同一个模型，在测试环境跑得好好的，一到线上并发一上来，响应时间直接从几百毫秒飙升到好几秒。排查了一圈代码没发现问题，最后才发现瓶颈出在服务器负载分配和模型版本上。这两个因素对推理速度的影响经常被低估，但恰恰是性价比最高的优化切入点。
先搞清楚你的瓶颈到底在哪一层
推理速度慢的原因可以粗略分成三层：模型层、服务层、硬件层。模型层包括参数规模、是否量化、计算图优化程度；服务层包括批处理策略、并发调度、内存管理；硬件层则是GPU利用率、显存带宽、PCIe吞吐。很多人的第一反应是换更强的显卡，但实际项目里，大量服务的GPU利用率长期徘徊在百分之三四十，硬件根本没吃满，问题出在调度和配置上。
动手优化之前，建议先用工具做一次基线测量。NVIDIA的nvidia-smi可以看整体利用率，但粒度太粗，推荐配合DCGM或者PyTorch Profiler分析具体算子耗时。服务层可以用Prometheus加Grafana监控每个请求的排队时间、批处理等待时间、纯计算时间。把这三段时间拆开看，问题就很清楚了：如果排队时间占比高，是负载调度问题；如果纯计算时间长，才需要动模型本身。
一个常见的误区是把延迟问题全部归咎于模型太大。实际上在中等并发场景下，动态批处理等待窗口设置不合理导致的排队延迟，往往比模型计算本身还耗时。先测量再动手，能避免大量无效优化。
服务器负载优化：让硬件真正跑满
负载优化的核心思路是提高请求的批处理效率。现代推理引擎如TensorRT-LLM、vLLM、TGI都支持动态批处理（Dynamic Batching），也就是把一小段时间内到达的多个请求合并成一个batch一起计算。GPU的并行特性决定了batch从1提到8的吞吐提升可能是数倍级别的，而延迟只增加一点点。配置时要注意两个参数的平衡：最大批大小（max_batch_size）和等待窗口（max_queue_delay）。
# 以Triton Inference Server的配置为例
dynamic_batching {
preferred_batch_size: [4, 8, 16] # 优先凑成的批大小
max_queue_delay_microseconds: 100 # 最多等待100微秒凑批
}等待窗口设得太小，批凑不满，吞吐上不去；设得太大，单请求延迟又被拖长。一般线上服务建议从100微秒到1毫秒之间起步测试，根据延迟SLA反推上限。如果你的服务对首字延迟敏感（比如流式对话），还要考虑用连续批处理（Continuous Batching），让新请求随时插进正在进行的batch，避免整批等待。
多实例部署也是常用手段。单卡显存装得下两份模型副本时，跑两个实例往往比单实例吞吐更高，因为两个实例可以交错调度，减少GPU空闲间隙。另外注意CPU预处理别成为隐形瓶颈，tokenizer、图片解码这类工作建议放到独立进程或多线程里，避免和主推理循环抢锁。对于多卡机器，还要检查是否启用了NCCL通信优化，卡间数据拷贝走NVLink和走PCIe的差距相当明显。
模型版本选择：不是越大越好，也不是越小越快
选模型版本时要建立“够用就好”的意识。同一个模型家族通常提供多个参数规模的版本，比如7B、13B、32B。参数翻倍并不意味着效果翻倍，但推理计算量确实是接近线性增长的。正确做法是先用你自己的评测集测试各版本的效果分数，找到满足业务准确率下限的最小版本，往往这个小版本在优化后的速度能比大版本快两到三倍。
量化版本是另一个重要选项。FP16转INT8一般能带来1.5到2倍的速度提升，INT4则更激进，显存占用降到四分之一左右，适合显存紧张的场景。但要注意量化对不同任务的精度损失差异很大：分类、抽取类任务通常损失可忽略，而数学推理、代码生成这类对精度敏感的任务，INT4可能出现明显的质量下滑，必须实测。AWQ和GPTQ是目前主流的训练后量化方案，vLLM和TensorRT-LLM都有良好支持。
# 使用vLLM加载AWQ量化版本并限制GPU显存占用比例 python -m vllm.entrypoints.openai.api_server \ --model Qwen2-7B-Instruct-AWQ \ --quantization awq \ --gpu-memory-utilization 0.85 \ --max-num-seqs 128
推理框架的版本也值得关注。框架本身的更新经常带来可观的性能改进，比如vLLM引入PagedAttention后，长上下文场景的吞吐提升非常显著；TensorRT-LLM每个版本也会针对新架构显卡做算子优化。升级框架版本属于低成本高收益的优化，但要注意API兼容性，升级前先在灰度环境完整回归一遍。
把优化效果验证清楚再上线
所有优化都应该建立在一个可复现的压测流程上。推荐固定一批真实业务请求作为测试集，用locust或者wrk模拟不同并发梯度，记录P50、P95、P99延迟和整体吞吐。只看平均延迟容易被长尾欺骗，线上体验差往往就是那百分之五的长尾请求造成的。
每次只改一个变量，跑一轮压测记录数据，这样能明确知道每个优化项的实际收益。建议维护一张优化记录表，把配置参数、测试环境、结果数据都留档，方便后续回溯。优化到位的服务，通常GPU利用率能从百分之三十提到七十以上，同等硬件下吞吐提升一到三倍是完全可以实现的目标。最后提醒一句，负载优化和模型选型不是一次性工作，业务流量变化后记得定期回顾配置，保持性能和成本的动态平衡。