本地跑大模型选哪个推理引擎？Tiny-vLLM/vLLM/Ollama/llama.cpp 实测对比

最近想在本地跑几个开源大模型做实验，发现现在的推理引擎选择多到让人眼花。前两天看 HN 又冒出个 Tiny-vLLM，号称用纯 C++/CUDA 写的高性能引擎，干脆把目前主流的几个推理框架拉出来一起跑了下，把数据整理出来供参考。

直接给结论：如果是单机批量推理生产部署，vLLM 还是性能王者；本地玩票图省事用 Ollama；想榨干显卡每一分性能且不在乎折腾用 Tiny-vLLM；只有 CPU 或者 Mac 用 llama.cpp。下面是详细测试。

为什么要做这个对比

我手里有台 4090 的工作站，平时跑跑 7B-14B 的开源模型做 RAG 测试。之前一直用 Ollama，省事但感觉性能没榨干。看到 Tiny-vLLM 上 HN 热榜后突然好奇，到底现在这几个引擎差距有多大？于是花了一个周末把同样的模型在不同引擎上跑了一遍，结果挺出乎意料。

测试环境

• CPU：Intel i9-13900K
• GPU：RTX 4090 24G
• 内存：64G DDR5
• 系统：Ubuntu 22.04 + CUDA 12.4
• 测试模型：Qwen2.5-7B-Instruct（GGUF Q4_K_M 给 Ollama/llama.cpp，FP16 safetensors 给 vLLM 系）
• 测试集：自己写的 200 条 prompt，平均输入长度 512 token，要求输出 256 token
• 每个引擎跑 3 轮取平均

横向对比结果

维度	Tiny-vLLM	vLLM	Ollama	llama.cpp
单请求吞吐 (tok/s)	142	138	96	78
32并发吞吐 (tok/s)	2810	2950	480	320
显存占用	14.8G	15.2G	6.4G	5.8G
首 token 延迟	38ms	42ms	65ms	88ms
模型加载时间	2s	8s	4s	3s
安装难度	高（需编译）	中	低（一行命令）	中
兼容 OpenAI API	是	是	是	需开 server 模式
模型格式	safetensors	safetensors/AWQ/GPTQ	GGUF	GGUF
量化支持	INT4/INT8/FP8	全面	仅 GGUF	仅 GGUF
适合场景	极致性能调优	生产部署	本地玩票	CPU/Mac/边缘

Tiny-vLLM 实测

仓库刚上 HN 热榜，号称重新实现了 PagedAttention 和 Continuous Batching，纯 C++/CUDA 没有 Python 依赖，启动快得离谱。

安装就是第一个坑。README 写得过于简洁，我编译时缺了 cutlass 子模块，又踩到 nvcc 版本和 gcc 不匹配的问题，折腾了俩小时才跑起来：

git clone https://github.com/xxx/tiny-vllm
cd tiny-vllm
git submodule update --init --recursive
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release \-DCUDA_ARCHITECTURES=89 \-DENABLE_FP8=ON
make -j$(nproc)

跑起来后单请求吞吐 142 tok/s，比 vLLM 略高一点。但 32 并发下反而被 vLLM 反超了，作者在 issues 里也承认调度器还在优化。最大优点是启动速度快，模型加载只要 2 秒，vLLM 要 8 秒。

踩坑：默认编译没开 FP8，性能数据不好看。CMake 里加上 -DENABLE_FP8=ON 重新编译才正常。另外 4090 一定要指定 CUDA_ARCHITECTURES=89，不然跑得贼慢。

vLLM 实测

老牌选手了，pip install vllm 就完事，但要装对 CUDA 版本：

from vllm import LLM, SamplingParamsllm = LLM(model="Qwen/Qwen2.5-7B-Instruct",gpu_memory_utilization=0.85,max_model_len=4096
)
params = SamplingParams(temperature=0.7, max_tokens=256)
outputs = llm.generate(prompts, params)

32 并发下吞吐 2950 tok/s 是真的猛，PagedAttention 加 Continuous Batching 这套组合拳目前还是天花板。生产环境闭眼选这个。

踩坑：gpu_memory_utilization 别设太高，0.9 以上我直接 OOM 了两次，0.85 是经验值。

Ollama 实测

最省心的方案，curl 一行就装好了：

ollama pull qwen2.5:7b
ollama serve

调用 API 直接兼容 OpenAI 格式：

import openaiclient = openai.OpenAI(base_url="http://localhost:11434/v1",api_key="ollama"
)
resp = client.chat.completions.create(model="qwen2.5:7b",messages=[{"role": "user", "content": "讲个冷笑话"}]
)

单请求 96 tok/s，并发拉跨。但日常本地测试 prompt、调 agent 这些场景足够用，从安装到能调用 30 秒搞定。

踩坑：改 context 长度别直接编辑 modelfile，要 ollama create 重新打包，不然不生效，我被这个坑了一晚上。

不想本地折腾？云端聚合 API 更省事

说实话，本地跑大模型这套对显卡要求不低，4090 也只能勉强跑 14B 以下的模型。我平时做项目联调，70% 时间是直接调云端 API，本地推理只在隐私敏感场景才用。

如果是日常开发需要切换不同模型对比效果，我现在用的是 ofox.io 这个聚合平台。一个 API Key 能调 GPT-4o、Claude Opus 4.6、Gemini、DeepSeek 等 50+ 模型，兼容 OpenAI SDK 协议，低延迟直连，支付宝按量计费。

import openaiclient = openai.OpenAI(base_url="https://api.ofox.io/v1",  # 我用的这个，低延迟直连api_key="sk-xxx"
)# 切模型只改一个字段，对比方便
for model in ["gpt-4o", "claude-opus-4-6", "deepseek-chat"]:resp = client.chat.completions.create(model=model,messages=[{"role": "user", "content": "解释下 PagedAttention"}])print(model, resp.choices[0].message.content[:100])

多供应商冗余备份，某一路挂了自动切换，成功率 99.2%。本地推理引擎调参的时候我也会拿它做基线对比，省得自己同时维护好几个云厂商 key。

llama.cpp 实测

老牌 GGUF 推理引擎，社区生态最广。Mac 用户基本都用这个：

./llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf \-c 4096 --port 8080 --n-gpu-layers 999

4090 跑 GGUF 量化模型 78 tok/s，慢的原因是 GGUF 量化格式本身对 GPU 不太友好，但显存占用最低，只要 5.8G。

唯一选 llama.cpp 的理由：你只有 CPU、或者你是 Mac M 系列、或者你要部署到边缘设备。其他场景没必要。

选型建议

按场景给个总结：

1. 生产部署、高并发推理：vLLM 没有争议，社区成熟、文档全、性能强
2. 极客折腾、追求极限性能：Tiny-vLLM 值得一试，作者还在迭代，启动快是亮点
3. 本地开发测试、随手起服务：Ollama，一行命令的省事程度无人能敌
4. Mac 用户、CPU only、嵌入式：llama.cpp 是唯一答案
5. 日常开发联调多模型对比：建议用聚合 API 平台，省去自己维护多个 key 的痛苦

几个踩过的坑

1. 同样是 Qwen2.5-7B，GGUF Q4 量化版精度损失肉眼可见，做严肃任务不要用量化版本
2. vLLM 的 gpu_memory_utilization 别设太高，0.9 以上容易 OOM，0.85 是黄金值
3. Tiny-vLLM 编译时如果显卡是 4090 一定要加 -DCUDA_ARCHITECTURES=89，否则跑得贼慢
4. Ollama 改 context 长度要重新 create 模型才生效
5. 跑 benchmark 一定要预热，第一次请求会被 CUDA kernel 编译拖累

总结

跑了一圈下来，我的最终选择是：开发测试用 Ollama 配合云端聚合 API（对比模型用），生产部署上 vLLM，Tiny-vLLM 保持关注但暂时不上生产。如果你的场景不一样，参考上面的表格按需选型就行，没有银弹。

这套测试脚本我整理一下后续放 GitHub，有兴趣的可以拿去自己跑一遍，毕竟硬件不一样数据会有差异，自己实测的数据最可信。