大模型推理引擎选型实战：vLLM、SGLang、Ollama与llama.cpp对比解析

如果你想本地跑大模型，或者给团队搭一套推理服务，迟早会撞上这四个名字：vLLM、SGLang、Ollama、llama.cpp。网上教程一大堆，但多数只讲“怎么装”，不讲“为什么用它”。更麻烦的是，你搜到的经验往往是几个月前的——这领域迭代太快，照搬很容易踩坑。我最近刚好把四个都深度折腾了一遍，从Windows笔记本到多卡服务器，从聊天界面到高并发API服务，把机制、选型和部署细节捋清楚了，这篇就按我的实战经验来讲透它们。

先说个结论：没有“最好”的推理引擎，只有“最匹配你场景”的那一个。vLLM和SGLang适合做高并发服务端，Ollama适合个人电脑快速体验，llama.cpp则专治各种低配设备和边缘场景。它们不是互相替代的关系，更多是分工不同。下面我从机制层面拆起，再给完整的部署参考，最后列出我踩过的坑和排查记录。

1. 整体选型思路：四个引擎到底在解决什么问题

1.1 先搞清楚它们的技术血缘

这四个项目其实分两大阵营。vLLM和SGLang是服务端推理引擎，它们的目标是在多用户、高并发的场景下，把GPU的利用率压榨到极限。Ollama和llama.cpp则更偏向本地/边缘推理，优先考虑的是部署简单、资源占用低、能在普通硬件上跑起来。

vLLM的前身是UC Berkeley的数值计算团队做的，核心思路是把显存管理做得像操作系统管理内存一样精细，通过PagedAttention（分页注意力）机制，把KV Cache切成小块按需分配，解决了传统方案里显存碎片化导致浪费的问题。SGLang则是斯坦福和MIT的团队搞的，他们在vLLM的思路上进一步优化，核心卖点是RadixAttention（基数树注意力），能在多轮对话和大量prompt复用场景下，缓存命中率高得吓人。

Ollama本质上是给llama.cpp和某些内置后端套了一层“傻瓜化”外壳。它把模型下载、量化、API服务、模型管理全部封装成了几个命令，让你可以像用Docker一样用大模型。llama.cpp则是个纯C/C++实现的推理库，是GGUF量化格式的“发明者”，主打CPU推理和低显存运行，连树莓派都能跑。

所以你看，选型的第一步不是比参数，而是先确认你的场景落在哪个阵营。

1.2 场景匹配：什么需求选什么引擎

用一张表可以很清楚地说明问题：

拿我自己的经验举个具体点的例子。如果只是想在笔记本上玩玩DeepSeek-R1或者Qwen，我根本不会去碰vLLM——因为vLLM的Continuous Batching（连续批处理）机制是为高并发设计的，单用户访问时反而会引入额外的调度开销。而Ollama则是最省心的，装好之后ollama run qwen3就行了。但如果要接到Dify或FastGPT这类知识库系统里，同时有几十个人在用，Ollama的并发处理能力就会捉襟见肘，这时候必须上vLLM或SGLang。

1.3 为什么服务器端更偏重vLLM和SGLang

这跟当前大模型部署的瓶颈有关。单次推理的延迟主要取决于模型计算量，这在单卡场景下各家差别不大。但服务端的核心指标是吞吐量（throughput），也就是单位时间能处理多少请求。传统方案一次只能处理一个请求，GPU利用率极低；vLLM和SGLang通过动态批处理，把多个请求的计算合并成一个大矩阵运算，GPU利用率能飙到90%以上。

这背后还有个显存问题。推理时占显存大头的是KV Cache，也就是已生成token的键值向量。在长对话场景下，KV Cache可能比模型本身还大。vLLM的PagedAttention借鉴了操作系统虚拟内存的思路，把KV Cache拆成固定大小的块，按需分配、用后回收，几乎杜绝了显存浪费。SGLang的RadixAttention则更进一步，它把prompt的公共前缀存在一颗树里，比如多个请求都有一段相同的系统提示词，这段提示词的计算结果可以直接复用，不用每个请求都重新算一遍。

从这个角度看，选vLLM还是SGLang，核心就看一个问题：你的业务里是不是有大量重复的prompt前缀？如果是类似“AI修仙文生成器”这种所有用户共享同一套人设词的场景，SGLang的缓存优势会极其明显。如果是五花八门的自由问答，两者差距不会太大，那就看谁的生态更顺滑——目前vLLM在兼容性和社区答案数量上明显占优。

2. 核心机制与部署细节：逐个拆解四个引擎

2.1 vLLM：服务端吞吐王者的正确打开方式

vLLM当前主要用V1架构（0.6版本之后逐步迁移），底层调度器重构过，支持了更灵活的投机解码和前缀缓存。它的部署方式最常见的是Docker，但我建议你至少理解几个关键参数再上手。

首先是模型格式。vLLM原生支持.safetensors格式的HF模型目录，不直接支持GGUF（虽然有转换脚本，但毕竟是额外步骤）。这意味着你下载模型时要去HuggingFace或ModelScope上找原版格式，而不是图方便下量化版。这里面有个常见误解：很多人以为vLLM和Ollama一样能直接跑GGUF，结果踩坑。如果你手头只有GGUF文件，要么转成HF格式，要么干脆考虑用llama.cpp。

其次是CUDA版本问题。热搜词里有一条“cuda128 vllm”，指的就是CUDA 12.8环境装vLLM时容易出兼容性问题。vLLM的PyPI包名是vllm，从0.8.x开始对CUDA 12.8有原生支持，但如果你用的还是0.6.x或0.7.x的镜像，里面编译的kernel未必适配12.8的驱动。我的建议是：生产环境别追求最新CUDA，用官方镜像自带的CUDA版本最稳。比如docker pull vllm/vllm-openai:v0.6.3.post1这个版本内置CUDA 12.4，实测非常稳定。

部署命令我给一个可直接用的模板：

docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ --ipc=host \ vllm/vllm-openai:v0.6.3.post1 \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --trust-remote-code \ --host 0.0.0.0 \ --port 8000

这里每个参数都有讲究。--ipc=host是必须加的，否则共享内存太小会导致数据传输失败；--gpu-memory-utilization 0.9表示允许vLLM使用90%的显存作为KV Cache缓存池，设太低了吞吐量上不去，设太高容易OOM；--max-model-len要根据你实际业务调整，它直接决定了单请求可处理的最大token数，也决定了KV Cache的块大小计算。--tensor-parallel-size在单卡场景固定为1，多卡则设置卡数。

说到显存规划，这里有个计算细节值得记住。以Qwen2.5-7B为例，模型本身FP16各参数占2字节，所以权重约占14GB，加上CUDA context约0.6~1GB。一张24GB的4090，留给KV Cache的空间大概是24-14-1=9GB。如果--max-model-len设为32768，每个token需要大约40字节的KV Cache（7B模型、GQA结构下），32768个token就需要1.3MB，这还没算上量化缓存。所以同样是24GB卡，7B模型跑32K长度是可行的，但70B模型就别想了，就算用AWQ 4bit量化，权重都要35GB，至少得两块卡。

vLLM还支持一个OpenAI兼容的API端点，启动后直接访问http://localhost:8000/v1/chat/completions就能用，配合vllm serve命令（0.6后新CLI）或者老版--api-key参数都可以做权限控制。对接Dify这类平台时，配置页面填上这个地址，模型名称填--served-model-name里设定的名字就能通。

2.2 SGLang：高缓存命中率与无NVLink场景

SGLang的部署方式有三种：Python包、Docker镜像、源码编译。对多数人来说，Docker是最省心的方式，但有一个特殊的注意点：SGLang的官方镜像体积比vLLM大一截，因为它打包了完整的torch和CUDA工具链。

先说RadixAttention的实用价值。在RAG场景里，每个用户的提问都会拼接上相同的知识库上下文，传统方案下这几十次请求就要算几十次相同的context。SGLang把这部分前缀计算结果缓存起来，后续请求直接读取缓存，实测在长文档问答场景里，吞吐量可以比vLLM高30%到50%。但它的代价是，如果prompt内容高度自由、几乎没有公共前缀，RadixAttention就退化成普通缓存，性能优势就不明显了。

立刻会有人问热搜词里的那个问题：“sglang 无nvlink 影响多大”。NVLink是NVIDIA多卡高速互连技术，带宽通常是PCIe的数倍。SGLang在做张量并行（tensor parallelism）时，每算完一个attention层都要在卡间同步数据，NVLink带宽高，同步就快。实测下来，两台仅靠PCIe 4.0 x16互连的4090机器，跑7B模型时SGLang的吞吐量会比有NVLink的下降20%~30%。如果你的卡没有NVLink，建议尽量用数据并行（--dp）而不是张量并行（--tp），或者干脆单卡部署小模型。数据并行特点是每张卡独立跑完整模型，进程间几乎不通信，对带宽不敏感。

SGLang的部署命令模板：

docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 30000:30000 \ -e NGC_CACHE=/models/.sglang_cache \ lmsysorg/sglang:latest \ python -m sglang.launch_server \ --model-path /models/Qwen2.5-14B-Instruct-AWQ \ --host 0.0.0.0 \ --port 30000 \ --context-length 32768 \ --tp-size 2 \ --quantization awq \ --trust-remote-code

注意--quantization awq必须和模型实际量化类型对应，否则会加载失败或精度异常。SGLang还支持--enable-mixed模式来同时服务多个模型，这在多模型共存的场景里很方便，但显存规划要重新算——每个模型的KV Cache空间需要独立预留。

实际对比中，SGLang在以下两种场景值得投入：一是超长上下文的阅读理解，二是大量共享系统提示词的Agent/工作流编排。如果你的场景是纯自由聊天，用vLLM会发现生态更稳，遇到问题搜到的答案也更多。

2.3 Ollama：本地体验和私有化部署的捷径

Ollama这几年火得不行，原因很简单：它把“下载模型+启动API+管理模型”这三个高频操作压缩到了两条命令里。但它也不是万能钥匙，它的底层推理后端是llama.cpp，所以很多性能指标和llama.cpp是绑定的，并发能力天然不如vLLM这类专门为服务端设计的引擎。

先解决热搜词里出现频率最高的三个问题：下载慢、离线安装、改存储路径。

Ollama下载慢是国内的常态，原因很简单——默认从GitHub和官方Registry拉文件。解决办法有三个层次：一是给命令行设置代理（注意合规使用），二是用环境变量指向国内镜像源，三是在能上网的机器上把模型文件拷贝过来。第三种最靠谱，有人会问Ollama能不能离线部署，答案是完全可以。你只要在一台联网机器上先ollama pull qwen2.5，然后去C:\Users\你的用户名\.ollama\models目录（Windows）或/usr/share/ollama/.ollama/models（Linux）找到blobs目录，把整个models目录拷贝到目标机器的相同路径即可。

存储路径修改也有两种方法。环境变量方式：export OLLAMA_MODELS=/new/path（Windows用setx OLLAMA_MODELS "D:\ollama\models"），设置后重启Ollama服务生效。软链接方式：把原models目录移到新位置，然后在原位置做个symlink。我个人推荐环境变量方式，因为升级时不容易被覆盖。

Ollama的API服务端口是11434，启动服务后它同时监听/api/chat和/v1/chat/completions两个端点。后者是OpenAI兼容格式，所以Cherry Studio、Dify这类工具可以直接配置http://localhost:11434/v1作为API地址，模型名填你pull下来的名字。Nginx反代配置里通常还要加上鉴权头，否则裸暴露到公网很容易被人扫描后盗用GPU资源。

有一个使用频率极高的坑必须单独说：Ollama在Windows上跑qwen或gemma系列时，报500 internal server error。这个错误90%的原因是Ollama内置的llama.cpp后端与当前模型版本不兼容，通常出现在升级Ollama或切换模型版本之后。排查顺序是：先ollama serve看日志，再ollama pull同一模型的另一个量化版本，还不行就彻底卸载重装。还有一种可能是显存不足——Ollama默认只给模型分配可用显存的一部分，如果同时加载了多个模型挤爆了显存，也会报500错误。解决方法是减少同时加载的模型数量或设置OLLAMA_MAX_LOADED_MODELS=1。

最实用的一条优化建议：Ollama运行时会默认读取OLLAMA_KEEP_ALIVE环境变量控制模型驻留时间。如果设成0，每次请求后立即卸载模型，省显存但慢；设成5m则会让模型保持5分钟，适合频繁调用的场景。热词里还提到“如何关闭ollama里gemma4的思考过程”，这是因为Gemma 3开始支持CoT（思维链）推理，Ollama会默认展示。要关闭可以给模型附加一个定制模板，或者在调用API时用"options": {"stop": ["<思考结束标记>"]}来控制输出终止位置。

2.4 llama.cpp：CPU推理和边缘部署的最后防线

llama.cpp的定位是“在所有能跑C++的平台上跑大模型”。它支持CPU推理、AVX2/AVX512指令集优化、GGUF量化模型，甚至有Android版本。Windows 7老机器上还在跑llama.cpp的也大有人在，这是其他三个引擎做不到的。

我自己的经验是，llama.cpp最适合以下几类场景：

一是纯CPU机器。比如公司的办公电脑没有独立GPU，但要本地跑一个1.5B或3B的小模型做文本分类或实体抽取。llama.cpp通过AVX2指令集和量化矩阵乘法，在8核CPU上跑Qwen2.5-3B可以达到每秒8~12个token的生成速度，做异步批处理OCR或关键词提取完全够用。

二是低显存GPU。llama.cpp支持GPU加速，但它的GPU卸载是“逐层”进行的（--n-gpu-layers参数控制），所以你可以把50层模型只卸载40层到GPU，剩下10层留在CPU，这样即便只有4GB显存也能跑14B模型，代价是每层跨设备传输有一定延迟。

三是Android手机。llama.cpp官方提供llama-AndroidAPK，你在手机上选一个Q4_K_M量化的小模型（比如Qwen2.5-1.5B-Instruct-Q4_K_M.gguf），就能在本地跑一个不联网的聊天助手。这个能力在飞行模式下或网络受限环境中特别有用。

llama.cpp的编译也很简单，Linux下就是标准的cmake流程：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j

编译时要特别注意GGML_CUDA宏。如果你用的是老GPU（比如GTX 10系），建议关闭它，因为新CUDA架构对老卡支持已不太友好。纯CPU用户则开启-DGGML_BLAS=ON，能调用OpenBLAS做矩阵加速，性能提升明显。

llama.cpp的server端命令是这样的：

./build/bin/llama-server \ -m /models/qwen2.5-7b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ --n-gpu-layers 40 \ --ctx-size 8192 \ --parallel 4

--parallel 4表示允许4个并发序列，这其实是利用连续批处理的简化版。不过要诚实地说，llama.cpp服务端的并发能力还是没法跟vLLM比，它更适合“少量用户、轻量任务”的场景。

顺带解答一个高频问题：vLLM能不能跑llama.cpp的GGUF模型？答案是vLLM官方支持有限，官方推荐策略是用llama.cpp转模型或者直接从HuggingFace下HF格式模型给vLLM用。除非你确定自己的场景必须在vLLM中用GGUF（比如磁盘空间只有GGUF一个版本），否则不建议折腾转换脚本。

3. 从安装到调优：完整实操记录

3.1 五步走通本地推理部署

我以“在一个干净的Linux服务器上部署一个能跑Qwen2.5-7B的API服务”为例，串联起四个引擎的典型用法。这个流程适用于多数团队内部私有化部署场景。

第一步是环境检测。nvidia-smi查看驱动支持的CUDA版本，再用python -c "import torch; print(torch.cuda.is_available())"确认PyTorch能看到GPU。这两个步骤能筛掉80%的拦路虎——很多人装好引擎后跑不起来，最后发现是驱动太老或PyTorch和CUDA版本不匹配。

第二步是下载模型。服务器上建议先配置HuggingFace镜像或ModelScope。ModelScope对国内环境更友好，很多模型都有直接下载链接。命令示例：

pip install modelscope modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir /data/models/Qwen2.5-7B-Instruct

这里强调一个细节：不要只下载模型权重而遗漏配置文件。HF模型目录里必须有config.json、tokenizer.json、tokenizer_config.json等文件，缺一个都可能让推理引擎加载失败。

第三步是决定用什么引擎。如果你只有一块4090且并发量不大，可以直接上Ollama：

curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:7b ollama run qwen2.5:7b

如果是为了生产服务，直接用Docker部署vLLM，镜像拉取后按前面给的命令启动。此时可以验证一下接口是否正常，用curl发一个请求：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen2.5-7b","messages":[{"role":"user","content":"你好"}],"max_tokens":100}'

第四步是性能测试。我建议至少测两个指标：首token延迟（TTFT，从请求发出到第一个token返回的时间）和生成吞吐（每秒生成token数）。简单的方式是用curl配合time命令测单请求，更规范的可以用Locust或hey压测工具模拟并发。

第五步是把服务接进业务框架。Dify、Cherry Studio、FastGPT都支持OpenAI兼容格式，只需要在配置界面填上API地址和模型名。这里有一个独家建议：千万别在配置里写http://localhost:8000当API地址，应该填服务对外的内网IP或域名，否则容器外部无法访问。

3.2 多引擎并存：各司其职的架构

真正复杂的系统里，这四者通常是共存的，而不是选一个。我最近给某团队搭过一套架构，可以当作参考：

• 前端聊天和轻度RAG查询走Ollama（模型：Qwen2.5-14B-Instruct-Q4_K_M），响应快、部署简单，扛50并发以内没问题；
• 重后端批处理（离线摘要、知识库文档切分向量化）走vLLM（模型：Qwen2.5-32B-Instruct-AWQ），吞吐到200并发也不慌；
• 边缘设备（现场有个Jetson Orin）跑llama.cpp（模型：Qwen2.5-3B-Instruct-Q8_0），部分预分类和提示词修正直接本地完成，不占中心资源；
• 中间偶尔需要做超长文档问答，临时拉一个SGLang容器，用完就关，享受RadixAttention带来的缓存红利。

这套架构的好处是各层独立扩展，显存和计算资源的利用完全按需分配。缺点是维护成本高，所以我加了一层Nginx路由，按路径把/ollama/*、/vllm/*、/sglang/*分别代理到不同后端。配置节选如下：

location /ollama/ { proxy_pass http://127.0.0.1:11434/; proxy_set_header Authorization "Bearer your_api_key"; } location /v1/ { proxy_pass http://127.0.0.1:8000/v1/; }

加了这层之后，客户端只需要记住一个API网关地址，服务端怎么切换引擎不会影响上层业务，以后扩缩容都方便。

3.3 显存与性能调优的路由

部署完之后，大家都会关心怎么把性能榨干。我总结了几个版本好用的调优顺序，按优先级排列：

• 第一优先级：模型量化。7B模型FP16约14GB，AWQ 4bit降到约4GB，速度还能提升20%左右。vLLM和SGLang都原生支持AWQ/GPTQ，Ollama和llama.cpp则通过GGUF的Q4_K_M量化达到类似效果。量化版本对绝大多数业务精度损失可以忽略，但吞吐收益是立竿见影的。
• 第二优先级：批处理参数。vLLM默认动态批处理，--max-num-seqs控制单次批处理最大序列数，设成256能显著提升吞吐，但也会增加首token延迟。SGLang则用--schedule-policy控制调度策略，lpm适合高并发，random适合低延迟场景。
• 第三优先级：KV Cache量化。vLLM 0.6+支持--kv-cache-dtype fp8，实测能把KV Cache显存占用压掉一半，但我们实测fp8精度下长文本生成偶尔会有微小漂移，是否需要开启要看你的任务容错度。
• 第四优先级：投机解码。vLLM用--speculative-config调用小模型做投机解码，SGLang类似。在7B主模型搭配0.5B草稿模型的情况下，实测decode速度能快1.5倍左右，但显存占用也会上升，小卡不建议开。

4. 常见问题与排查技巧实录

4.1 部署报错速查表

我自己踩过和替读者排查过的坑，整理成一张速查表，按关键词对号入座：

4.2 三个容易忽略但影响极大的细节

第一是端口冲突。vLLM默认8000、SGLang默认30000、Ollama默认11434、llama.cpp server默认8080，四个同时部署时端口不冲突，但如果你用过之前的服务没关掉，端口占用就会导致新服务启动失败。我建议统一用Nginx代理，只暴露一个443端口出去。

第二是模型文件的权限问题。在Docker部署时，如果-v挂载的目录是普通用户创建的，容器内进程（通常以root运行）可以读取，但反过来容器内生成的文件（如日志）权限可能变成root，宿主机普通用户删不掉。我习惯在挂载目录加chmod -R 755，并给容器指定--user $(id -u):$(id -g)。

第三是持续运行的稳定性比瞬间性能更重要。很多人在测试环境跑得好好的，一到生产就频繁OOM。我建议在服务端显存规划时，始终保持gpu-memory-utilization不超过0.85，给CUDA context和其他进程留足余量。

4.3 经验复盘：我踩过的坑和绕过的弯

说几个我印象比较深的例子。

第一次用vLLM部署DeepSeek系列模型时，我直接用vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B，结果发现模型加载到一半就OOM。起初以为是显存不够，后来一查才发现是--max-model-len默认设了128K，KV Cache直接爆炸。把--max-model-len改成8192后，7B模型轻松跑在一张3090上。这给我一个教训：大模型推理的精髓不是模型本身，而是KV Cache的预算管理。

第二次是踩了CUDA版本的坑。我在一台CUDA 11.8的环境里直接pip install vllm，结果编译flash-attn的时候各种报错。后来查了官方文档才发现，vLLM 0.8.x最低要求CUDA 12.1，老版本虽然能装上但运行时kernel不匹配。最后我老老实实把环境升级到CUDA 12.4，一分钟搞定。当你的推理引擎跟CUDA版本较劲时，最好相信官方镜像而不是自己编译。

还有个特别典型的场景：把SGLang跑在两张没有NVLink的3090上，做张量并行。测试时发现吞吐量比单卡还低，一开始百思不得其解，后来用nvidia-smi dmon观察GPU利用率，发现两张卡每生成一个token都要通过PCIe同步两次，通信时间直接抵消了并行收益。换成数据并行后，每张卡各跑一个不同请求，吞吐量立刻翻倍。这个案例再回头看“sglang无nvlink影响多大”这个热搜词，答案就很清晰了：影响很大，但你可以用对的方式来规避。

5. 写在最后的个人体会

这四个引擎我折腾了不短的时间，最大的感受是：工具再强，也得看清自己的盘子再下手。vLLM吞吐高但部署门槛也高，SGLang缓存优化好但要求场景匹配，Ollama省心但并发能力有限，llama.cpp万能但性能上限摆在那里。没有哪个引擎是完美的，它们更像是不同赛季的赛车：vLLM是专业赛道上的F1，SGLang是带智能进站策略的勒芒赛车，Ollama是四平八稳的SUV，llama.cpp则是能越野能通勤的老皮卡。你开什么车，取决于走什么路。

再送个实战小技巧：如果你不确定该选哪个，先在个人电脑上装Ollama，用量化模型把业务逻辑跑通，等量上来了再平滑迁移到vLLM或SGLang。这种“先易后难”的路径能让你的精力花在真正有价值的业务上，而不是一开始就陷入和CUDA、GPU驱动搏斗的泥潭里。

最后提一句，不管选哪个引擎，模型文件的妥善管理都值得从一开始就重视起来。给模型目录做个清晰的命名规范（比如Qwen2.5-7B-Instruct-AWQ-INT4这样的格式），把日志和配置文件统一放在一起，后续排障时真的能省掉大量时间。