私有化部署推理服务上线后性能不达标，通常不是模型权重本身有问题，而是计算资源、推理框架和模型配置没有形成匹配。同一个模型，在公有云 GPU 实例上跑得很快，迁移到内网服务器后吞吐量可能下降数倍，原因集中在硬件利用率低、推理引擎未做图优化、显存策略不合理以及缺少批处理机制。本文从硬件选型、推理引擎配置、模型压缩和部署架构四个层面展开，给出可落地的优化思路。
一、私有化部署推理性能的典型瓶颈
定位推理性能问题时，首先要区分是计算、访存还是调度瓶颈。很多团队只看 GPU 利用率，但 GPU 利用率长期低于 40% 并不一定代表算力充足，更常见的原因是请求到来时没有形成足够的批次，或者算子过于零散，导致计算单元频繁等待数据搬运。此时即便换更高端显卡，延迟也不会明显下降。
另一个容易被忽略的问题是显存带宽。大模型推理不仅是算力密集任务，也是典型的内存带宽敏感任务。权重加载完成后，每次前向计算都要把矩阵从显存中读入计算单元，如果权重过大且没有做低精度处理，显存带宽会成为硬限制。此外，请求队列没有上限控制时，高并发场景下会大量积累排队请求，最终表现为超时和雪崩。
| 瓶颈类型 | 典型现象 | 常用优化方向 |
|---|---|---|
| 计算单元利用率低 | GPU 利用率长期低于 40% | 增大批处理、开启 CUDA Graph |
| 显存带宽不足 | 大批量推理时延迟陡增 | 低精度量化、权重合并 |
| 算子零散 | 小算子开销占比高 | 算子融合、静态图优化 |
| 队列调度不合理 | 请求多时超时严重 | 动态批处理、优先级队列 |
建议在上线前建立一套基础监控，至少覆盖请求延迟分位数、吞吐量、GPU 计算利用率、显存占用和请求排队长度。只有把瓶颈量化到具体指标，后续的硬件选型和引擎优化才有明确方向。
二、硬件选型：CPU、GPU 还是 NPU
硬件选型不能只看显卡算力峰值，还要看实际推理负载的特征。如果模型参数量小于 1B、并发低于 5，纯 CPU 推理配合 AVX-512 或 AMX 指令集也能满足延迟要求；如果模型在 7B 以上或需要高并发，则至少需要 24GB 显存的高端 GPU。NPU 和边缘加速卡适合固定结构模型，但生态兼容性较差，很多自定义算子需要额外适配。
显存容量是硬件选型时最容易算错的一项。估算显存可以使用简单公式：显存需求 ≈ 参数量 × 每参数字节数 + 激活值 + KV Cache。例如 7B 模型采用 FP16 加载，权重约占 14GB，KV Cache 根据序列长度和并发数可能再增加 10GB 以上。以下脚本可快速计算规划值。
def estimate_memory(params_billion, bytes_per_param, kv_cache_gb, activation_gb):
weight_gb = params_billion * 1e9 * bytes_per_param / (1024 ** 3)
total_gb = weight_gb + kv_cache_gb + activation_gb
return total_gb
# 7B FP16 模型，预估 KV Cache 10GB，激活 2GB
mem = estimate_memory(7, 2, 10, 2)
print(f"预计显存占用: {mem:.2f} GB")
在选择 GPU 型号时，除了显存容量，还要关注显存带宽和 PCIe 通道。多卡推理时如果模型采用张量并行，卡间通信依赖 NVLink 或 PCIe，通道带宽不足会导致多卡加速比很差。对于中小规模团队，优先选择显存大、生态好且可支持 TensorRT 或 vLLM 的主流 GPU，通常比购买多张低端卡更划算。
三、推理引擎优化：ONNX Runtime 与 TensorRT
推理引擎的核心作用在于把训练导出的计算图转换成更高效的执行结构。ONNX Runtime 可以通过开启图优化级别来融合相邻算子，减少中间张量的读写次数。配置时优先选择 CUDAExecutionProvider，并设置线程数，避免 CPU 线程争抢影响 GPU 调度。
import onnxruntime as ort
sess_options = ort.SessionOptions()
sess_options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL
sess_options.intra_op_num_threads = 8
session = ort.InferenceSession(
"model.onnx",
sess_options=sess_options,
providers=["CUDAExecutionProvider", "CPUExecutionProvider"],
)
print(session.get_providers())
TensorRT 则更进一步，通过构建阶段对模型进行层融合、精度校准和 kernel 自动调优。尤其是在使用 INT8 量化时，TensorRT 能显著减少显存占用并提升吞吐。构建引擎时需要准备校准集，并显式开启 FP16 或 INT8 模式。下面是一个构建 TensorRT 引擎的简化示例。
import tensorrt as trt
def build_engine(onnx_path, engine_path):
logger = trt.Logger(trt.Logger.WARNING)
builder = trt.Builder(logger)
network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH))
parser = trt.OnnxParser(network, logger)
with open(onnx_path, "rb") as f:
parser.parse(f.read())
config = builder.create_builder_config()
config.set_flag(trt.BuilderFlag.FP16)
config.max_workspace_size = 4 * 1024 * 1024 * 1024
engine = builder.build_serialized_network(network, config)
with open(engine_path, "wb") as f:
f.write(engine)
print("engine saved")
需要注意的是，TensorRT 构建过程比较耗时，但推理阶段收益明显，尤其是固定 batch 和固定输入尺寸的场景。对于动态 shape 模型，需要额外配置 optimization profile，否则可能无法充分利用 GPU 算力。
四、模型层优化：量化、动态批处理与 KV Cache
除了推理引擎自带的优化，模型本身的执行策略也直接影响吞吐。INT8 或 FP8 量化可以把权重和激活的存储字节数降低一半甚至更多，显著缓解显存带宽压力。量化后的模型在部分任务上会有轻微精度损失，因此上线前必须在真实评测集上做精度回归。
动态批处理是提高 GPU 利用率最直接的手段。传统静态批处理要求请求同时到达并组成固定大小批次，私有化场景中请求到达往往稀疏且不均匀。使用动态批处理机制后，引擎可以在等待时间内持续收集请求，达到阈值或超时后统一执行。vLLM 还引入 PagedAttention 思想，将 KV Cache 分成固定大小的页，减少显存碎片，从而允许更多请求同时进入。
python -m vllm.entrypoints.openai.api_server \
--model /data/models/qwen2-7b \
--dtype half \
--max-model-len 4096 \
--gpu-memory-utilization 0.92 \
--max-num-seqs 32
上述参数中，gpu-memory-utilization 控制显存使用比例，max-num-seqs 限制并行请求数。设置过高可能会触发显存溢出，设置过低又会导致排队。建议根据实际并发压测逐步调整，并观察显存峰值和延迟变化。
五、部署架构与压测验证
单实例调优完成后，还需要考虑请求接入层和服务编排。私有化部署通常没有弹性扩缩容条件，因此要在有限实例中做好流量分配。可以为每张 GPU 启动一个推理实例，前面增加负载均衡，按 GPU 的实时队列深度分配请求。对于长文本生成任务，可开启流式输出，降低首字延迟对用户体验的影响。
压测是验证优化效果的关键环节。建议使用异步客户端模拟真实并发，并分别记录成功率和延迟分布。以下是一个简单的异步压测脚本，可快速验证服务在 100 个并发请求下的表现。
import asyncio
import aiohttp
import time
async def request_once(session):
payload = {"messages": [{"role": "user", "content": "你好"}]}
async with session.post("http://127.0.0.1:8000/v1/chat/completions", json=payload) as resp:
return resp.status
async def main():
async with aiohttp.ClientSession() as session:
tasks = [request_once(session) for _ in range(100)]
start = time.time()
results = await asyncio.gather(*tasks)
print("成功请求数:", results.count(200))
print("100 个请求总耗时:", time.time() - start)
asyncio.run(main())
通过压测结果可以进一步反向调整硬件选型和引擎参数。优化过程是一个闭环：先量化瓶颈，再调整配置，最后用压测数据验证。只有把硬件、推理引擎和模型策略结合起来，私有化部署才能在有限资源下获得接近公有云的推理性能。