大模型推理引擎选型实战：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 场景匹配什么需求选什么引擎用一张表可以很清楚地说明问题应用场景首选方案备选方案关键原因个人电脑快速体验、聊天问答Ollamallama.cpp一条命令启动模型管理方便生产环境API服务、高并发RAGvLLMSGLang吞吐量高显存管理成熟多轮对话极多、prompt复用率高SGLangvLLMRadixAttention缓存命中率高只有CPU/低配电脑/嵌入式设备llama.cppOllama原生支持CPU推理量化格式成熟Windows老机器Win7/Win8llama.cpp无编译版对老系统兼容性好Android手机本地部署llama.cpp无官方有Android编译版本全托管私有化平台、团队共享vLLM DockerSGLang Docker生态成熟社区文档多拿我自己的经验举个具体点的例子。如果只是想在笔记本上玩玩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 \ --ipchost \ 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这里每个参数都有讲究。--ipchost是必须加的否则共享内存太小会导致数据传输失败--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-19GB。如果--max-model-len设为32768每个token需要大约40字节的KV Cache7B模型、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/modelsLinux找到blobs目录把整个models目录拷贝到目标机器的相同路径即可。存储路径修改也有两种方法。环境变量方式export OLLAMA_MODELS/new/pathWindows用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_MODELS1。最实用的一条优化建议Ollama运行时会默认读取OLLAMA_KEEP_ALIVE环境变量控制模型驻留时间。如果设成0每次请求后立即卸载模型省显存但慢设成5m则会让模型保持5分钟适合频繁调用的场景。热词里还提到“如何关闭ollama里gemma4的思考过程”这是因为Gemma 3开始支持CoT思维链推理Ollama会默认展示。要关闭可以给模型附加一个定制模板或者在调用API时用options: {stop: [思考结束标记]}来控制输出终止位置。2.4 llama.cppCPU推理和边缘部署的最后防线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_CUDAON -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j编译时要特别注意GGML_CUDA宏。如果你用的是老GPU比如GTX 10系建议关闭它因为新CUDA架构对老卡支持已不太友好。纯CPU用户则开启-DGGML_BLASON能调用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且并发量不大可以直接上Ollamacurl -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约14GBAWQ 4bit降到约4GB速度还能提升20%左右。vLLM和SGLang都原生支持AWQ/GPTQOllama和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 部署报错速查表我自己踩过和替读者排查过的坑整理成一张速查表按关键词对号入座错误/现象可能原因解决方案Ollama 500 internal server error模型版本与内置llama.cpp后端不兼容或显存不足更新/重装Ollama减少同时加载模型数vLLM 启动报CUDA errorout of memorymax-model-len过大或gpu-memory-utilization过高调低max-model-len预留1~2GB显存余量vLLM 加载GGUF模型失败vLLM原生不支持GGUF转HF格式或改用llama.cpp/OllamaSGLang 跑多卡时性能极差卡间无NVLink高通信开销用数据并行--dp替代张量并行--tpllama.cpp CPU推理速度太慢未开启AVX2/AVX512编译优化编译时加-mavx2 -mavx512或下载预编译版本Ollama下载速度极慢默认从官方Registry拉模型配置国内镜像源或离线拷贝blobs目录OpenAI接口timeout并发过高或网络代理限制检查Nginx超时配置调大proxy_read_timeout容器内模型无法加载挂载目录权限或路径错误确认-v目录映射准确容器内路径必须为绝对路径Dify / Cherry Studio 配置不通API地址或模型名错误确认served-model-name与配置页填写的模型名一致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默认设了128KKV 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是专业赛道上的F1SGLang是带智能进站策略的勒芒赛车Ollama是四平八稳的SUVllama.cpp则是能越野能通勤的老皮卡。你开什么车取决于走什么路。再送个实战小技巧如果你不确定该选哪个先在个人电脑上装Ollama用量化模型把业务逻辑跑通等量上来了再平滑迁移到vLLM或SGLang。这种“先易后难”的路径能让你的精力花在真正有价值的业务上而不是一开始就陷入和CUDA、GPU驱动搏斗的泥潭里。最后提一句不管选哪个引擎模型文件的妥善管理都值得从一开始就重视起来。给模型目录做个清晰的命名规范比如Qwen2.5-7B-Instruct-AWQ-INT4这样的格式把日志和配置文件统一放在一起后续排障时真的能省掉大量时间。