vLLM vs TensorRT-LLM vs Ollama vs llama.cpp：RTX 5090 最佳推理引擎选择指南

作者
  • avatar
    姓名
    Nino
    职业
    Senior Tech Editor

随着 NVIDIA RTX 5090 的正式发布，本地大语言模型 (LLM) 推理的格局发生了翻天覆地的变化。凭借 32GB 的 GDDR7 显存和高达 1.79 TB/s 的内存带宽，这款消费级 Blackwell 架构显卡在特定任务上的表现已经能够媲美数据中心级硬件。然而，硬件只是基础，如何选择合适的推理引擎——vLLM、TensorRT-LLM、Ollama 或 llama.cpp——决定了你是否能真正发挥出这块 5090 的全部潜力。虽然在 RTX 5090 上进行本地推理非常强大，但许多开发者在处理需要 99.9% 可用性的生产负载时，仍然倾向于选择 n1n.ai 提供的稳定、统一的 API 服务。

四大引擎概览：定位与差异

在评估推理后端时，我们必须区分“服务 (Serving)”与“运行 (Running)”的概念。某些引擎旨在为数百个并发用户提供高吞吐量的 API，而另一些则专注于在个人电脑上以最快速度运行模型。

  1. vLLM：高吞吐量服务的行业标准。它首创了 PagedAttention (分页注意力) 技术，是 Python 生产环境的首选。
  2. TensorRT-LLM：NVIDIA 官方出品的高性能库。它通过将模型编译为专门的推理引擎来实现极限吞吐量，但学习曲线极为陡峭。
  3. Ollama：基于 llama.cpp 的易用包装器。它专为希望获得“一键式”本地测试体验的开发者设计。
  4. llama.cpp：本地 LLM 运动的基石。采用 C++ 编写，具有极高的可移植性，几乎支持所有硬件平台。

技术特性深度对比

特性vLLMTensorRT-LLMOllamallama.cpp
核心目标生产级服务极致吞吐量开发者易用性可移植性与效率
量化支持AWQ, GPTQ, FP8FP8, FP4, INT8GGUFGGUF (Q4_K_M 等)
内存管理PagedAttentionIn-flight Batching静态分配静态/统一内存
API 兼容性兼容 OpenAI自定义 / Triton兼容 OpenAI兼容 OpenAI
RTX 5090 支持已支持 (v0.15.1+)部分支持 (SM120 算子缺失)已支持已支持
Mamba 架构支持原生支持有限支持通过 GGUF通过 GGUF

vLLM：生产环境的务实之选

vLLM 的核心创新在于 PagedAttention。它效仿了操作系统中虚拟内存的分页管理方式来处理 KV 缓存。在传统的推理引擎中，KV 缓存需要分配连续的显存空间，这会导致严重的显存碎片化。vLLM 彻底消除了这种浪费，使得在同一显存容量下可以处理更大的批次 (Batch Size)。如果你觉得配置 vLLM 或 TensorRT-LLM 太过繁琐，n1n.ai 提供了一个统一的接口，让你无需折腾硬件即可访问这些高性能模型。

在 RTX 5090 上运行 Nemotron Nano 9B v2 Japanese 模型 (BF16 精度) 时，vLLM 在批处理场景下的优势非常明显：

  • 单次请求速度：约 83 tokens/秒
  • 10 个并发请求：总吞吐量约 630 tokens/秒
  • 首字延迟 (TTFT)：45–60 毫秒

对于使用 LangChain 或 LlamaIndex 构建 RAG (检索增强生成) 流水的开发者来说，vLLM 是最逻辑的选择，因为它与 Python 生态系统结合得非常紧密。它对 Mamba 混合架构 (如 Nemotron) 的支持目前也是同类中最好的，能够利用 Blackwell SM120 算力核心的特定优化。

TensorRT-LLM：极致性能与复杂度的博弈

TensorRT-LLM 是为数据中心而生的。在 H100 或 B200 集群上，它是无可争议的王者，其原始吞吐量通常比 vLLM 高出 30% 到 50%。它在 FP8 和 FP4 量化方面表现卓越，这对于大规模部署 DeepSeek-V3 等超大规模模型至关重要。

但在 RTX 5090 上，体验并不完美。消费级 Blackwell 显卡的 SM120 架构有时会缺少企业级显卡中的某些“融合算子 (Fused Kernels)”。在测试中，用户经常会遇到类似 Fall back to unfused MHA 的警告信息，这会显著降低性能。此外，其安装过程通常依赖 NVIDIA NGC 的 Docker 镜像，对于个人开发者来说，维护成本较高。

Ollama 与 llama.cpp：本地开发的利器

Ollama 就像是 AI 界的 apt-get。它屏蔽了 CUDA 版本和 Python 环境的复杂性。如果你想在 60 秒内测试 Llama 3.1 或 Mistral 模型，Ollama 是不二之选。然而，它的致命伤是缺乏 连续批处理 (Continuous Batching)。如果你同时发送 5 个请求，Ollama 会排队一个一个处理，而 vLLM 则会利用 PagedAttention 同时处理它们。

llama.cpp 则依然是功能最全的工具。其 GGUF 格式 是量化领域的金标准。在 RTX 5090 上，1.79 TB/s 的带宽让 llama.cpp 在单用户聊天场景下快如闪电。它还支持“混合推理”，即将部分模型层放入显存，部分留在大容量的系统内存中——如果你想在 32GB 显存的 5090 上跑 70B 甚至 405B 的大模型，这是唯一的办法。

实践指南：在 RTX 5090 上部署 vLLM

要在 5090 上运行高性能服务器，你可能需要最新的 CUDA 13 开发版本。以下是一个调用示例：

# 启动 vLLM 服务
# vllm serve nvidia/NVIDIA-Nemotron-Nano-9B-v2-Japanese \
#    --trust-remote-code \
#    --max-num-seqs 64 \
#    --mamba_ssm_cache_dtype float32

from openai import OpenAI

# vLLM 提供兼容 OpenAI 的 API 接口
client = OpenAI(base_url="http://localhost:8000/v1", api_key="n1n-dummy-key")

response = client.chat.completions.create(
    model="nvidia/NVIDIA-Nemotron-Nano-9B-v2-Japanese",
    messages=[
        {"role": "system", "content": "你是一个专业的技术顾问。"},
        {"role": "user", "content": "请解释 GDDR7 显存对大模型推理的意义。"}
    ],
    temperature=0.7
)

print(response.choices[0].message.content)

为什么 vLLM 是 5090 开发者的最佳选择？

对于使用 RTX 5090 的独立开发者或小团队，vLLM 提供了最佳的平衡点。它提供了生产级的特性（如连续批处理和前缀缓存），但又没有 TensorRT-LLM 那样繁琐的运维负担。虽然 llama.cpp 适合个人使用，但 vLLM 允许你从一个显卡实例中为一整套项目提供服务——从法律文档摘要到复杂的代码分析。对于那些追求生产级性能但不想自建硬件环境的用户，n1n.ai 提供了无缝的替代方案，通过高速 API 即可调用顶尖模型。

总结建议

  • 选择 vLLM 的场景：构建 API 服务、开发 RAG 应用、或需要在单块 5090 上支持多用户并发。
  • 选择 TensorRT-LLM 的场景：在拥有 H100 的企业环境中工作，且需要压榨 FP8 量化的每一分性能。
  • 选择 Ollama 的场景：本地快速实验新模型，不想写任何配置代码。
  • 选择 llama.cpp 的场景：运行显存放不下的超大模型，或在非 NVIDIA 硬件上运行。

随着 Blackwell 生态的成熟，我们预期 TensorRT-LLM 对消费级显卡的支持会进一步提升，但就目前而言，vLLM 依然是高性能本地推理的最务实选择。

在 n1n.ai 获取免费 API 密钥。

参考来源：https://dev.to/soytuber/vllm-vs-tensorrt-llm-vs-ollama-vs-llamacpp-choosing-the-right-inference-engine-on-rtx-5090-2aap