当前位置：首页 > news >正文

推理引擎选型对比：TensorRT、ONNX Runtime、vLLM、llama.cpp 实测

news 2026/7/29 17:31:03

推理引擎选型对比：TensorRT、ONNX Runtime、vLLM、llama.cpp 实测

一、个性化深度引言

模型训练完了，部署才是真正的开始。在实验室的 A100 上跑得飞起的模型，到了线上的 T4 上延迟翻了三倍。不是模型的问题，是推理引擎没选对。

推理引擎是把训练好的模型转化为可部署服务的关键环节。2026 年的选择比以往任何时候都多：NVIDIA 官方的 TensorRT、跨平台的 ONNX Runtime、专为大模型设计的 vLLM、以及 CPU 混合推理的 llama.cpp。每个引擎针对不同的硬件和场景做了深度优化，选错引擎的损失不是百分之几，是几倍的吞吐差距。

见证奇迹的时刻，不是你用 Triton Server 跑通了 TensorRT 模型，而是你把同一个模型用 vLLM 跑了一遍，QPS 从 12 跳到了 89。

二、个性化原理剖析

推理引擎的优化可以按层次来理解。

TensorRT 的计算图优化最强，vLLM 的调度策略最优，llama.cpp 的量化最丰富，ONNX Runtime 的硬件覆盖最广。

三、个性化代码实践

import time import numpy as np from typing import Dict, List, Optional, Tuple from dataclasses import dataclass @dataclass class InferenceResult: """设计原因：统一的推理结果数据结构，方便不同引擎的对比""" engine: str model_name: str input_tokens: int output_tokens: int latency_ms: float tokens_per_second: float gpu_memory_gb: float quantization: str = 'none' # ============================== # 方案一：TensorRT —— NVIDIA 官方，延迟最低 # ============================== class TensorRTInference: """ 设计原因：TensorRT 的核心是计算图级别的深度优化。 包括层融合、kernel auto-tuning、精度校准（INT8/FP8）。 注：以下为配置说明和接口设计，实际需要 TensorRT Python API。 """ @staticmethod def build_engine_config() -> Dict: return { 'optimization_level': 3, # 设计原因：Level 3 最大优化 'precision': 'fp16', # 设计原因：FP16 适合 V100/A100，INT8 适合 T4 'max_batch_size': 32, 'workspace_size_gb': 2, # 设计原因：给 TensorRT 的构建空间 'dynamic_shapes': True, # 设计原因：支持可变输入长度 'profile_shapes': { 'min': (1, 32), 'opt': (1, 512), 'max': (1, 2048) } } @staticmethod def benchmark_scenario() -> Dict: """设计原因：TensorRT 在不同场景下的性能特征""" return { 'best_for': [ 'BERT/T5 等编码器模型（延迟敏感）', '固定 batch 的在线推理', '需要 INT8/FP8 精度优化的场景', 'NVIDIA Triton Inference Server 部署' ], 'not_for': [ '大语言模型的生成式推理（vLLM 更好）', '非 NVIDIA GPU（无法使用）', '频繁切换模型的场景（构建时间长）' ], 'build_time': '大型模型（>10B）构建需要 30分钟到数小时', 'inference_latency': '通常是同精度下最低延迟', 'ecosystem': 'NVIDIA 全栈（Triton Server, CUDA, cuDNN）' } # ============================== # 方案二：ONNX Runtime —— 跨平台，硬件覆盖最广 # ============================== class ONNXRuntimeInference: """ 设计原因：ONNX Runtime 的优势是跨平台和跨硬件。 同一份 ONNX 模型可以在 GPU、CPU、EdgeTPU、移动端上运行。 注：实际需要 onnxruntime 和 onnx 库。 """ @staticmethod def get_execution_providers() -> Dict: """设计原因：ONNX Runtime 的执行提供者是其核心差异化能力""" return { 'cuda': { 'provider': 'CUDAExecutionProvider', 'best_for': 'NVIDIA GPU', 'configuration': {'device_id': 0, 'gpu_mem_limit': 4 * 1024 * 1024 * 1024} }, 'tensorrt': { 'provider': 'TensorrtExecutionProvider', 'best_for': 'NVIDIA GPU（最高性能）', 'note': '需要额外安装 onnxruntime-gpu-tensorrt' }, 'cpu': { 'provider': 'CPUExecutionProvider', 'best_for': '无 GPU 环境、开发调试', 'configuration': {'intra_op_num_threads': 8} }, 'openvino': { 'provider': 'OpenVINOExecutionProvider', 'best_for': 'Intel CPU/GPU', 'note': 'Intel 硬件上的推理优化' }, 'coreml': { 'provider': 'CoreMLExecutionProvider', 'best_for': 'Apple Silicon / iOS', 'note': 'Mac 和 iOS 设备上的推理' } } @staticmethod def benchmark_scenario() -> Dict: return { 'best_for': [ '跨平台部署（GPU → CPU → Edge）', '非 NVIDIA 硬件（Intel、Apple、ARM）', '需要模型格式标准化的团队', '不需要极致性能的中等吞吐场景' ], 'not_for': [ '大模型生成式推理（不如 vLLM/llama.cpp）', '需要极致 GPU 利用率的场景（不如 TensorRT）' ], 'conversion_cost': 'PyTorch → ONNX 转换可能需要处理不兼容算子', 'portability': '最佳（ONNX 是行业标准）' } # ============================== # 方案三：vLLM —— 大语言模型推理王者 # ============================== class vLLMInference: """ 设计原因：vLLM 是为 LLM 推理从头设计的引擎。 核心创新：PagedAttention（分页显存管理）+ Continuous Batching。 注：实际需要 pip install vllm """ @staticmethod def get_optimization_features() -> Dict: return { 'paged_attention': { 'description': '将 KV Cache 分页管理，类似操作系统的虚拟内存', 'benefit': '消除显存碎片，显存利用率从 30-50% 提升到 90%+', 'impact': '相比 HuggingFace Transformers，吞吐量提升 5-24 倍' }, 'continuous_batching': { 'description': '不等整个 batch 完成，新请求即时加入', 'benefit': '消除"憋 batch"的延迟，P99 延迟显著降低', 'impact': '高并发下延迟提升 2-3 倍' }, 'prefix_caching': { 'description': '共享系统提示词只在第一个请求时计算', 'benefit': '多轮对话场景的首 token 延迟降低 50%+', 'impact': '系统提示词越长收益越大' }, 'tensor_parallelism': { 'description': '张量并行拆分到多 GPU', 'benefit': '支持 70B+ 模型的多卡推理', 'impact': '线性扩展（4 卡吞吐约 4 倍）' } } @staticmethod def startup_config() -> Dict: """设计原因：vLLM 的核心启动参数及设计考量""" return { 'model': 'meta-llama/Llama-3-70B', 'dtype': 'auto', # 设计原因：auto 自动选择最佳精度 'max_model_len': 8192, # 设计原因：限制最大长度以管理显存 'gpu_memory_utilization': 0.9, # 设计原因：留 10% buffer 'max_num_seqs': 256, # 设计原因：最大并发序列数 'max_num_batched_tokens': 8192, # 设计原因：单 batch 最大 token 数 'tensor_parallel_size': 4, # 设计原因：4 卡并行 'enable_prefix_caching': True, 'enable_chunked_prefill': True # 设计原因：分块预填充减少首 token 延迟 } @staticmethod def benchmark_scenario() -> Dict: return { 'best_for': [ '大语言模型的在线推理（GPT/Llama/Qwen 等）', '高并发、需低延迟的在线服务', '多卡推理大模型（70B+）', '多轮对话（受益于前缀缓存）' ], 'not_for': [ '非 LLM 模型（BERT、ResNet 等——vLLM 不支持）', '单次硬实时推理（首 token 延迟优化有限）', 'CPU 环境（vLLM 需要 GPU）' ] } # ============================== # 方案四：llama.cpp —— CPU/GPU 混合，量化之王 # ============================== class LlamaCppInference: """ 设计原因：llama.cpp 是轻量级的 LLM 推理引擎。 核心优势：量化方案最丰富 + CPU 推理 + 低硬件门槛。 注：实际需要 pip install llama-cpp-python """ @staticmethod def get_quantization_options() -> Dict: """ 设计原因：llama.cpp 支持最多的量化格式。 从 2-bit 到 8-bit，覆盖了精度的整个谱系。 """ return { 'Q4_K_M': { 'bits': 4, 'size_vs_fp16': '25%', 'quality': '推荐默认值，质量损失极小', 'use_case': '一般推理' }, 'Q5_K_M': { 'bits': 5, 'size_vs_fp16': '31%', 'quality': '高质量，略优于 Q4_K_M', 'use_case': '质量敏感场景' }, 'Q2_K': { 'bits': 2, 'size_vs_fp16': '13%', 'quality': '有显著质量损失，仅用于极度资源受限', 'use_case': '边缘设备、移动端' }, 'Q8_0': { 'bits': 8, 'size_vs_fp16': '50%', 'quality': '质量无损（近似）', 'use_case': '需要高质量但显存受限' }, 'IQ4_NL': { 'bits': 4, 'size_vs_fp16': '25%', 'quality': 'Importance-aware 量化，K-quant 的改进版', 'use_case': '追求量化质量最佳' } } @staticmethod def cpu_gpu_hybrid_config() -> Dict: """ 设计原因：llama.cpp 支持 CPU+GPU 混合推理。 部分层在 GPU，部分在 CPU，灵活分配显存。 """ return { 'ngl': { 'description': '加载到 GPU 的层数', 'recommendation': { 'no_gpu': 'ngl=0（纯 CPU）', 'partial_gpu': 'ngl=20（约一半层在 GPU）', 'full_gpu': 'ngl=99（全部层在 GPU）' } }, 'n_threads': { 'description': 'CPU 推理的线程数', 'recommendation': '物理核心数（不推荐超线程）' }, 'context_size': { 'description': 'Context 窗口大小', 'note': '越大的 context 消耗越多 RAM/VRAM' } } @staticmethod def benchmark_scenario() -> Dict: return { 'best_for': [ '边缘设备和本地推理（MacBook、树莓派、手机）', '没有 GPU 的环境', '需要灵活量化的场景', '本地私有推理（数据不离开设备）' ], 'not_for': [ '高并发在线服务（延迟和吞吐不如 vLLM）', '非 LLM 的模型（不支持）', '需要 FP16/BF16 全精度推理' ] } # ============================== # 综合对比与决策辅助 # ============================== class InferenceEngineSelector: """ 设计原因：基于四个维度的决策矩阵。 注：以下为设计示意，实际数值需要在自己的硬件上实测。 """ @staticmethod def compare_throughput(engine: str, model_size: str) -> Dict: """设计原因：吞吐量比较（仅示意，需实测）""" reference = { 'tensorrt': { '7B': {'tokens_per_second': 4500, 'note': '构建耗时长'}, '70B': {'tokens_per_second': 800, 'note': '需多GPU'} }, 'vllm': { '7B': {'tokens_per_second': 3800, 'note': '最佳LLM引擎'}, '70B': {'tokens_per_second': 750, 'note': 'PagedAttention显存高效'} }, 'onnx_runtime': { '7B': {'tokens_per_second': 1200, 'note': '中等性能'}, '70B': {'tokens_per_second': 'Not recommended'} }, 'llama_cpp': { '7B': {'tokens_per_second': 120, 'note': 'CPU推理'}, '70B': {'tokens_per_second': 15, 'note': 'CPU推理较慢'} } } return reference.get(engine, {}) @staticmethod def decide(hardware: str, model_type: str, requirements: Dict) -> str: """ 设计原因：基于硬件、模型类型和需求的三维决策。 """ if model_type == 'llm' and hardware.startswith('NVIDIA') and requirements.get('throughput') == 'high': return 'vLLM # LLM + NVIDIA GPU + 高吞吐' if model_type == 'encoder' and hardware.startswith('NVIDIA') and requirements.get('latency') == 'low': return 'TensorRT # 编码器 + NVIDIA GPU + 低延迟' if hardware in ['CPU', 'Apple Silicon', 'Mobile']: return 'llama.cpp # CPU/Edge + 任何 LLM' if requirements.get('cross_platform'): return 'ONNX Runtime # 需要跨平台部署' return 'ONNX Runtime # 默认推荐，跨平台兼容性最好' # ============================== # 基准测试框架 # ============================== class BenchmarkRunner: """ 设计原因：在自己的硬件上实测是选型的最终依据。 这个框架提供了一个最小化的基准测试模式。 """ @staticmethod def run_benchmark(engine_name: str, model_path: str, prompts: List[str], warmup: int = 3) -> List[InferenceResult]: results = [] # Warmup（设计原因：消除冷启动影响） for _ in range(warmup): pass # 实际调用引擎 for prompt in prompts: start = time.time() # 实际推理调用 time.sleep(0.05) # 模拟 latency = (time.time() - start) * 1000 results.append(InferenceResult( engine=engine_name, model_name=model_path.split('/')[-1], input_tokens=len(prompt), output_tokens=128, latency_ms=latency, tokens_per_second=128 / latency * 1000, gpu_memory_gb=8.0 )) return results @staticmethod def analyze(results: List[InferenceResult]) -> Dict: latencies = [r.latency_ms for r in results] tps = [r.tokens_per_second for r in results] return { 'engine': results[0].engine if results else 'unknown', 'total_requests': len(results), 'latency': { 'mean': np.mean(latencies), 'p50': np.percentile(latencies, 50), 'p95': np.percentile(latencies, 95), 'p99': np.percentile(latencies, 99), }, 'throughput': { 'mean_tps': np.mean(tps), 'total_tps': sum(r.output_tokens for r in results) / max(sum(latencies)/1000, 0.001) } }

四、个性化边界权衡

吞吐 vs 延迟：

vLLM 追求高吞吐（tokens/second），通过 Continuous Batching 最大化 GPU 利用率。代价是单个请求的尾延迟较高。
TensorRT 追求低延迟（milliseconds/request），通过 kernel 级别优化和 CUDA Graph 减少开销。代价是构建复杂度和 batch 吞吐。
选择：在线聊天 Agent 追求低延迟（TensorRT/TensorRT-LLM），离线批量任务追求高吞吐（vLLM）。

GPU 专用 vs 跨平台：

TensorRT/vLLM 锁定 NVIDIA GPU，但在其上性能最优。
llama.cpp/ONNX Runtime 可在 CPU/GPU/Edge 上运行，但性能不及专用方案。
选择：数据中心部署选 GPU 专用方案，边缘部署/私有本地部署选跨平台方案。

量化激进 vs 保守：

llama.cpp 的 Q2/Q3 量化大幅压缩模型体积，但质量损失不可忽略。
vLLM 的 AWQ/GPTQ 量化精度损失小，但需要校准数据。
选择：资源极度受限用低 bit 量化，服务质量要求高保留 FP16/BF16。

结论

推理引擎的选择由三个因素决定：模型类型、硬件环境和性能要求。对于大语言模型的在线推理服务，vLLM 凭借 PagedAttention 的显存管理和 Continuous Batching 的调度策略，在 NVIDIA GPU 上提供了最高吞吐，是当前 LLM 服务化的首选方案。对于延迟敏感的编码器模型（BERT/T5 及类似架构），TensorRT 的 kernel 级别优化可最大化推理速度，适用于分类、匹配等低延迟要求场景。对于跨平台和硬件多样性需求，ONNX Runtime 提供了最广泛的执行后端支持，是标准化部署的最佳选择。对于资源受限的边缘设备和本地推理，llama.cpp 的丰富量化方案和 CPU 推理能力使其成为唯一可行的轻量级引擎。没有全能的引擎，只有匹配场景的引擎。

查看全文

http://www.jsqmd.com/news/1288496/