模型选好了，下一个问题就是：用什么框架来跑？
同一个 Hermes 模型，在不同的推理框架上跑出来的速度、资源占用、并发能力可能差好几倍。选错框架等于白白浪费硬件投入。
今天拿四个最主流的本地推理框架——Ollama、vLLM、llama.cpp、TGI（Text Generation Inference）——分别跑 Hermes 模型，用实际数据说话。
四个框架的定位
先搞清楚它们各自的设计目标，这很重要。
Ollama：面向个人用户的”一键式”本地推理方案。安装简单、操作直观，目标用户是那些想在自己电脑上玩大模型的普通人和入门开发者。它在底层实际调用的是 llama.cpp，但包装了一层友好的接口。
vLLM：面向线上服务的高性能推理引擎。它最大的创新是 PagedAttention 技术，大幅提升了 GPU 显存利用率和并发吞吐量。目标用户是需要部署模型 API 服务的团队。
llama.cpp：Georgi Gerganov 开发的纯 C/C++ 推理框架。最初是为了让 LLaMA 模型能在 CPU 上跑而设计的，后来扩展到支持 GPU 加速。特点是极度轻量、跨平台（Windows/Linux/macOS/Android都能跑）、支持各种量化格式。
TGI（Text Generation Inference）：HuggingFace 开发的推理框架，面向生产部署。基于 Rust 和 Python 混合实现，内置了 Continuous Batching、Tensor Parallelism 等生产级特性。和 HuggingFace 生态深度集成。
测试环境和方法
测试分两套环境：
环境A（消费级）：RTX 4090 24GB，用 Hermes 3 8B Q4_K_M 量化版
环境B（服务器级）：4x A100 80GB，用 Hermes 3 70B FP16
每个框架在两套环境下分别测试以下指标：
- 首 Token 延迟（Time to First Token, TTFT）
- 生成速度（Tokens per Second, TPS）
- 最大并发数
- 显存占用
- 吞吐量（在最大并发下的总 TPS）
消费级硬件测试结果
RTX 4090 + Hermes 3 8B Q4_K_M：
| 指标 | Ollama | vLLM | llama.cpp | TGI |
|---|---|---|---|---|
| 首Token延迟 | 180ms | 220ms | 150ms | 240ms |
| 单路生成速度 | 40 t/s | 52 t/s | 45 t/s | 48 t/s |
| 显存占用 | 6.2GB | 7.8GB | 5.8GB | 7.5GB |
| 最大并发 | 1-2路 | 4-5路 | 1-2路 | 3-4路 |
| 最大吞吐量 | ~40 t/s | ~180 t/s | ~45 t/s | ~140 t/s |
几个关键发现：
单路速度：vLLM 最快，得益于其高效的 CUDA kernel 实现。llama.cpp 紧随其后，考虑到它还支持 CPU 卸载和各种量化方案，这个成绩相当不错。Ollama 因为多了一层包装，速度比 llama.cpp 稍慢。
显存效率：llama.cpp 最省显存，它对量化模型的显存管理做得非常精细。vLLM 和 TGI 因为要预分配 KV Cache 用于并发支持，显存占用偏高。
并发能力：消费级显卡上跑并发是 vLLM 的主场。它的 PagedAttention 技术在这种显存受限的环境下优势巨大——同样的24GB显存，vLLM 能开4-5路并发而 Ollama 只能跑1-2路。
首Token延迟：llama.cpp 最快，因为它的启动开销最小。TGI 最慢，它在处理第一个请求时需要做一些初始化工作。
服务器级硬件测试结果
4x A100 80GB + Hermes 3 70B FP16：
| 指标 | Ollama | vLLM | llama.cpp | TGI |
|---|---|---|---|---|
| 首Token延迟 | 850ms | 320ms | 680ms | 350ms |
| 单路生成速度 | 18 t/s | 35 t/s | 22 t/s | 32 t/s |
| 显存占用 | 148GB | 165GB | 142GB | 160GB |
| 最大并发 | 2-3路 | 25-30路 | 3-4路 | 20-25路 |
| 最大吞吐量 | ~36 t/s | ~650 t/s | ~70 t/s | ~520 t/s |
服务器环境下的差距就非常夸张了。
vLLM 吞吐量碾压：650 t/s vs Ollama 的 36 t/s，差了18倍。这就是 PagedAttention + Continuous Batching + Tensor Parallelism 的威力。如果你要部署线上服务，vLLM 和 TGI 是唯一的选择。
Tensor Parallelism 支持：多卡推理时，vLLM 和 TGI 支持自动的张量并行——把模型切分到多张卡上同时计算。Ollama 和原生 llama.cpp 在多卡支持上弱得多，基本就是把数据分到不同卡上分别算，效率差距明显。
llama.cpp 的尴尬：在消费级硬件上 llama.cpp 表现不错，但到了多卡服务器环境，它的分布式推理能力就暴露了短板。不过 llama.cpp 的优势在于它的跨平台能力和极致的量化支持，这在其他框架上很难找到替代。
易用性对比
性能之外，实际使用中的”爽感”也很重要。
Ollama：最简单
1 | ollama pull hermes3:8b |
两行命令，模型就跑起来了。不需要管什么 CUDA 版本、Python 环境、依赖冲突。Ollama 把所有复杂的东西都藏在了后面。
对于想在本地快速体验 Hermes 模型 的用户来说，Ollama 是门槛最低的方案。
缺点：配置灵活性差。想调整一些底层参数（比如 KV Cache 大小、Batch Size）？抱歉，Ollama 不太支持。
llama.cpp：灵活但需要编译
llama.cpp 需要从源码编译（虽然也有预编译版本）。对于大部分开发者来说不算难，但对新手确实有门槛。
好处是什么都能调。量化格式、线程数、GPU层数、上下文长度——每个参数都暴露给你。如果你想榨干硬件的每一分性能，llama.cpp 给你最大的操作空间。
1 | ./main -m hermes-3-8b-q4_k_m.gguf -n 512 -ngl 35 --ctx-size 4096 |
vLLM：生产级但有门槛
vLLM 的安装不算难（pip install vllm），但配置一个高性能的服务需要理解不少概念：Tensor Parallelism 的设置、KV Cache 的分配策略、Continuous Batching 的参数等。
1 | python -m vllm.entrypoints.openai.api_server \ |
启动一个 OpenAI 兼容的 API 服务只需要一条命令，但要调到最优性能需要花时间。
TGI：Docker 一把梭
TGI 推荐用 Docker 部署，这对于有容器化经验的团队来说反而是优点——环境隔离、部署标准化。
1 | docker run --gpus all -p 8080:80 \ |
和 HuggingFace 生态的深度集成是 TGI 的加分项。如果你已经在用 HuggingFace 的模型库和工具链，TGI 的对接成本最低。
功能特性对比
| 功能 | Ollama | vLLM | llama.cpp | TGI |
|---|---|---|---|---|
| OpenAI API 兼容 | 是 | 是 | 有限 | 是 |
| 流式输出 | 是 | 是 | 是 | 是 |
| GGUF 量化 | 是 | 否 | 是 | 否 |
| AWQ/GPTQ 量化 | 否 | 是 | 否 | 是 |
| Speculative Decoding | 否 | 是 | 有限 | 是 |
| Continuous Batching | 否 | 是 | 否 | 是 |
| Tensor Parallelism | 否 | 是 | 有限 | 是 |
| CPU 推理 | 是 | 否 | 是 | 否 |
| macOS Metal 支持 | 是 | 否 | 是 | 否 |
| Windows 原生 | 是 | 否 | 是 | 否 |
| Function Calling | 有限 | 是 | 有限 | 是 |
几个值得注意的点：
量化路线分化：llama.cpp 阵营用 GGUF 格式，vLLM/TGI 阵营用 AWQ/GPTQ。两套量化格式不兼容。如果你的模型是 GGUF 格式的，只能用 Ollama 或 llama.cpp 跑。
Speculative Decoding：这是一个能把推理速度提升20-40%的技术。vLLM 和 TGI 支持得比较好，llama.cpp 的实现还在早期阶段，Ollama 不支持。
跨平台能力：想在 Mac 上跑模型？只有 Ollama 和 llama.cpp 支持 macOS 的 Metal 加速。想在没有 GPU 的机器上跑？也只有这两个支持纯 CPU 推理。
Function Calling 支持：对于 Hermes 的工具调用场景，vLLM 和 TGI 的支持最完善。它们能正确处理 Hermes 的 ChatML 格式下的 Function Calling 流程。Ollama 和 llama.cpp 对 Function Calling 的支持比较基础，复杂的多步骤工具链可能有问题。
不同场景的最佳选择
个人学习和实验 → Ollama
想在自己电脑上快速体验 Hermes？Ollama 两分钟搞定。不需要任何技术背景，装好就能用。对于想入门大模型但不想和环境配置较劲的人，这是最友好的选择。cocoloop 社区里有不少用 Ollama 跑 Hermes 的经验帖。
极客玩家和硬件优化 → llama.cpp
手里有各种奇奇怪怪的硬件（老显卡、Mac、ARM 设备），想把性能榨到极致？llama.cpp 给你最大的自由度。它也是量化模型的最佳平台——支持的量化格式最多，量化效果也最好。
线上 API 服务 → vLLM
要部署一个能承接真实流量的模型服务？vLLM 的高并发能力是其他框架没法比的。PagedAttention 技术在高并发场景下的优势太大了。对于 B 端客户或者有一定用户量的应用，vLLM 是性价比最高的方案。
HuggingFace 生态用户 → TGI
如果你的技术栈已经深度绑定 HuggingFace（模型用 Hub 上的、训练用 Transformers、部署用 Inference Endpoints），TGI 是最自然的推理引擎选择。它和 HuggingFace 生态的无缝集成省了大量的对接工作。
混合方案也可以：开发阶段用 Ollama 快速测试，生产部署用 vLLM。两个框架支持的模型格式不同（GGUF vs 原生格式），但核心模型能力是一样的。
一个容易忽略的因素
最后提一个很多人不太关注但实际影响很大的因素：框架的更新速度。
vLLM 的更新频率非常高，几乎每周都有新版本。新模型发布后，vLLM 通常在一周内就能支持。llama.cpp 的更新也很快，而且 Georgi Gerganov 一个人的开发效率惊人。
TGI 的更新频率中等，作为 HuggingFace 的产品，它的稳定性优先于新功能。Ollama 更新最慢，有时候新模型发布后要等好几周才能用。
如果你想第一时间用上最新的 Hermes 版本，vLLM 和 llama.cpp 会是更好的选择。
延伸阅读：OpenClaw 社区资源
本文由 CocoLoop 中文社区出品。如果你在研究 AI Agent 与主流模型的工程化落地，姊妹站 OpenClaw 中文社区 也许会有帮助：