选开源推理引擎这件事我最近被问得耳朵起茧。vLLM、SGLang、Ollama、llama.cpp 这四个名字排在一起看着都是“开源推理引擎”实际用起来完全是四个物种。有人用 vLLM 部署 Qwen 当线上 API一天几十万请求稳如老狗有人用 Ollama 想在 Windows 笔记本上跑个 7B 模型做实验结果卡在下载和 500 报错上还有人装着 llama.cpp 在 Android 手机上断断续续生成文本觉得“这也能行”不可思议。这篇文章就围绕这四款引擎从核心机制差异、选型逻辑、实际部署过程到踩坑排查一次性聊透给你一套“看见项目需求就知道该选谁”的判断方法。我尽量按我平时干活的口吻写不整虚的每一步都是可以照着操作的。1. 先搞清楚你手里的牌四个引擎的定位与机制差异1.1 vLLMPagedAttention 与 engine core 的高并发工厂vLLM 在我看来本质是一个“批量请求调度工厂”。它最核心的贡献是 PagedAttention也就是把 KV Cache 切成固定大小的块像操作系统的虚拟内存页一样管理。这样显存里的小碎片能利用起来同样一批请求可以塞进更大的 batch吞吐自然就上去了。这解决的是在线服务场景最痛的问题大量用户同时发请求如何让 GPU 一直在干活而不是空转。如果你去看 vLLM 的源码会看到内部有三个重要角色engine core、scheduler、executor。engine core 负责启动时初始化模型和配置并持有整个推理循环的状态scheduler 在每一轮迭代中检查队列里的请求决定哪些请求能被 prefill、哪些能继续 decode、哪些因为显存不够或 token 数超长要排队executor 则负责把调度器安排好的任务真正丢到 GPU 上执行。三者关系可以理解为scheduler 是排班经理executor 是干活工人engine core 是整个公司的老板。vLLM 1.x 之后把 engine core 抽象出来让这种交互流程更清晰也方便做多模态、结构化输出等扩展。这也是为什么很多团队把它和对话平台、API 网关绑在一起用。vLLM 适合的场景非常明确OpenAI 兼容的 API 服务、高并发场景、需要连续 batching 在线推理。你用它部署一个大模型然后在 8000 端口起一个服务聊天机器人前端来调它能把并发请求压缩成一个一个小 batch吞吐比朴素的 transformers 实现高出数倍。代价是引入的模块多、显存和 CUDA 驱动要求高个人电脑要跑起来并不轻松。1.2 SGLang把前缀缓存做进骨子里SGLang 是 vLLM 的强有力对手最近热度一路走高。它给我的印象是更“聪明”地安排同样输入的复用。SGLang 的招牌是 RadixAttention它在每次请求时把 prompt 拆成前缀树节点缓存下来。多轮对话的 system prompt 完全相同、检索增强生成里一堆文档都带同一个固定模板前缀……这些场景中重复的 KV Cache 不需要重新计算直接复用已有缓存prefill 开销大幅降低。当然SGLang 并不只有前缀缓存。它也实现了自己的 scheduler、executor、continuous batching还引入了“统一内存池”和自动编译前端能把多个请求的执行计划融合起来。简单说vLLM 在“怎么让 GPU 多塞请求”下功夫SGLang 在“怎么让相同内容少算第二遍”下功夫。所以很多长上下文、多轮对话、共享 prefix 的业务会明显感觉到 SGLang 更快。我在对比测试里用同样的 Qwen2.5 7B跑那种带 2000 token 固定 system prompt 的请求SGLang 首个 token 延迟肉眼可见地比 vLLM 低。这件事在 vLLM 开启 prefix caching 后差距缩小但 SGLang 的 RadixAttention 粒度更细细节上更有优势。SGLang 适合的场景是对首 token 延迟敏感、大量重复前缀、多轮会话、长上下文。如果你的业务开发者每天都在调一个知识库 bot强烈建议试试 SGLang。不过它比 vLLM 社区更年轻部分模型、量化格式的支持要留意版本适配。1.3 Ollama个人电脑上的“模型管家”Ollama 跟前面两个完全不是一个路线。它不是为了最大化 GPU 利用率而是为了“让普通人把模型跑起来”。Ollama 相当于一个模型管理工具安装之后ollama pull qwen2.5:7b拉模型ollama run qwen2.5:7b进对话一个命令搞定。它内部把模型包成一层一层真正做推理的底层默认是 llama.cpp 的构建版本。所以 Ollama 和 llama.cpp 有血脉关系。Ollama 的定位是本地开发、个人笔记、桌面端 demo、小团队内部体验。它提供 OpenAI 兼容接口默认 11434 端口所以 AnythingLLM、Dify、LangChain、Goose 这类工具也可以直接接。它吸引人的地方是模型包自带 Modelfile可以配置温度、上下文长度、system prompt 等服务可以单机多模型挂载有 web 或桌面客户端生态。但它不适合极端高并发因为底层 llama.cpp 的连续 batching 和 nvGPU 优化不如 vLLM 激进。你在本地拿 4090 跑 Ollama 做个人助手问题不大要扛十几位并发用户就要小心了。Ollama 最让人头疼的是下载模型太慢官方仓库在海外国内网络经常龟速。解决办法基本都是配置国内镜像源、通过代理下载我这里不提代理工具只说镜像站方式、或者把别人下好的 GGUF 文件手动导入。热词里的“ollama国内镜像源”“ollama 离线安装包”“gguf模型下载后如何导入ollama”都是这个痛点引出来的后面我要讲具体做法。1.4 llama.cppCPU 也能跑的轻量引擎llama.cpp 是 GGUF 格式的娘家。它用 C/C 实现没有厚重的 Python 依赖和 CUDA 生态绑定。它的设计目标很朴素只要有一台电脑CPU 也能推理大模型。通过量化 GGUF 文件比如 Q4_K_M 每参数只占约 4.5 bit7B 模型只要 4~5 GB 内存就能跑。它也对 GPU offload 做了支持你可以指定-ngl 99把全部层扔给显卡也可只用 CPU 跑。llama.cpp 的“轻”体现在很多地方有llama-cli、llama-server、llama-bench等命令行工具能跨平台编译 Windows、Linux、macOS、Android。热词里“llama.cpp android 版”不是新鲜事市面上很多手机端本地模型应用的内核就是 llama.cpp。你想在自己安卓机上跑一个离线小模型把 termux 装上编译个 llama.cpp 或者下载预编译包然后运行 GGUF 文件即可。虽然生成速度只有每秒几个 token但在移动端场景这种灵活性无可替代。llama.cpp 不适合线上高并发服务。它虽然提供llama-server并带 OpenAI 兼容 API但单请求吞吐、调度能力跟 vLLM 不在一个量级。它适合的场景离线推理、边缘设备、CPU 机器、模型实现调优、自定义采样器研究以及那些想要“干净、没依赖、可控”的实现。Ollama 用了它的内核这并不代表 Ollama 的所有能力就是 llama.cpp 的上限真正面向大流量的项目还是要回到 vLLM 或 SGLang。2. 选型逻辑与硬件依赖别只看跑分2.1 场景比拼在线服务、离线批处理、个人尝鲜很多朋友选引擎时习惯去论坛看 “vLLM 和 SGLang 哪个快”然后跟风。我建议先按场景画一个坐标左边是“要不要高并发在线 API”右边是“就一台个人电脑跑跑”。如果是左边直接排除 Ollama 和 llama.cpp 作为主服务端如果是右边vLLM 和 SGLang 可能成了负担。我列一张对比表把几个维度说清楚对比项vLLMSGLangOllamallama.cpp核心优化点PagedAttention、continuous batchingRadixAttention 前缀缓存模型管理与一键部署CPU/GPU 混合轻量推理主要格式FP16/BF16、AWQ、GPTQ、FP8FP16/BF16、量化兼容GGUFGGUF并发能力强强中低低部署复杂度高建议 Docker高建议 Docker低低OpenAI 兼容 API原生原生原生兼容llama-server 提供典型场景线上 API、高并发多轮对话、长上下文、知识库个人本地、小团队 demo离线、移动端、CPU 机器所以如果你做的是“给公司业务提供大模型接口”不用纠结默认 vLLM然后对比 SGLang 是否更快再切换如果你自己是开发者想在笔记本上快速跑个 7B 模型做原型Ollama 最省事如果你在树莓派或手机上跑或者只想在纯 CPU 机器上跑llama.cpp 是唯一正解。2.2 显存、内存的粗算方法附实例推理引擎跑之前最怕的是“模型装不上”。其实显存占用可以提前粗算。以 7B 模型为例FP16 权重约 14GB7B × 2 字节。BF16 一样。如果做 Q4_K_M 量化GGUF 文件通常只有 4.3~4.5GB内存占用接近这个值加一点上下文。而 vLLM 部署时除了权重还要给 KV Cache 预留显存在长上下文场景下这是大头。具体计算假设你用 vLLM 跑 Qwen2.5-7B-InstructFP16 权重 14GB设置--max-model-len 32768KV cache 在 batch 为 1、无 GQA 加持时非常大但因为有 GQA 和跳动 KV cache实际预留可能也要 5~8GB。所以一张 24GB 的 4090 是可以舒服跑 7B 长上下文的想跑 70B 至少要 2~3 张 48GB 或配合量化。用 llama.cpp 的 Q4_K_M 跑 7B 则只需约 5GB 内存CPU 也能跑只是速度感人。量化格式也要注意vLLM 1.x 支持 GPTQ、AWQ、FP8 等但它对 GGUF 支持的体验不如 llama.cpp 好你要是已经有一堆 GGUF 模型用 Ollama 和 llama.cpp 更顺。反过来你从 HuggingFace 拉了原版 weights想快速起个服务vLLM 直接--model 目录就行不需要提前转格式。2.3 CUDA 与 Docker90% 坑从环境来部署 vLLM 或 SGLang 最忌讳的事是裸机安装时版本不搭。vLLM 对 PyTorch、CUDA、GCC、甚至 NVIDIA 驱动都很敏感。一个常见错误是驱动太老报CUDA error: no kernel image is available另一个常见问题是 pip 安装的 PyTorch 是 CPU 版或 CUDA 版本不一致。所以官方推荐 Docker 镜像不是没有道理——镜像里已经把环境隔离好了宿主机只需要有 NVIDIA 驱动和支持 nvidia-container-toolkit 的容器运行时。Docker 拉起 vLLM 的标准套路是先装驱动再装 nvidia-container-toolkit然后docker run --gpus all。镜像地址一般用vllm/vllm-openai标签对应版本。热词里有“vllm/vllm-openai:v0.27.1 加载 qwen3-embedding-0.6b”这个场景就是docker run时传入--model和--task embedding之类的参数vLLM 1.x 对 embedding 模型支持也变好了。此外“glm5.3 使用 vllm 哪个版本的镜像”这类问题说明版本匹配确实困扰人我的建议是看模型官方文档给出的 vLLM 最低版本不要闭眼用最新镜像很多新版本性能反而出现回退社区里有不少反馈。3. 四款引擎的实操部署详解3.1 vLLM 部署 DeepSeek/Qwen 系列服务先说我在 Linux 服务器上部署 Qwen/DeepSeek 系列的标准操作。假设模型已经下载到宿主机/data/models下目录里有config.json和权重文件。我用 Docker因为升级和排障都方便docker run --runtime nvidia --gpus all \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:v0.27.1 \ --model /models/qwen2.5-7b-instruct \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --served-model-name qwen2.5-7b启动后本地就能请求了curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen2.5-7b,messages:[{role:user,content:你好}],max_tokens:256}热词里的“vllm部署deepseek”“docker部署vllm模型教程”都是这条路。有几个参数要解释--gpu-memory-utilization 0.9表示预留 90% 显存给 vLLM不能设太大否则显存溢出就起不来--max-model-len是模型最大上下文长度设得太大KV Cache 预留就多并发时容易 OOM设太小超长 prompt 会被截断。对于 7B 模型在 24GB 卡上32768 是常见安全值。vLLM 新版本 v0.6.x 到 0.8.x 之间变化挺大热词里“vllm新版本性能下降”不是空穴来风。有的版本 scheduler 改动后某些模型的 throughput 和 latency 都变差。我的实践原则是如果模型官方指定了镜像版本就用那个如果没有稳定优先用 vLLM 0.6.x 或 0.7.x 的成熟版本而不是追上最新的 tag。生产环境锁版本是一个好习惯。如果要用 embedding 模型比如 qwen3-embedding-0.6b命令类似但要加参数指定任务类型。vLLM 1.x 支持--task embedding然后请求/v1/embeddings。这个能力对于搭建 RAG 链路很有用不过要注意 vLLM 对 embedding 模型的支持并不是所有版本都完善部署前先去看 release notes。3.2 SGLang 部署与一致性加速SGLang 的部署也很像 vLLM但有一个明显的记忆点是“前缀缓存”。如果你搭一个知识库问答所有用户请求前都附带着同一个固定 system prompt 加一堆候选 chunksvLLM 每次都要重新 prefill 这些公共内容而 SGLang 的 RadixAttention 能直接命中缓存。这是它最大的卖点。在服务器上SGLang 可以用 Docker 也可以 pip 安装。我常用的方式是在 Python 虚拟环境里装pip install --upgrade sglang python -m sglang.launch_server \ --model-path /data/models/qwen2.5-7b-instruct \ --host 0.0.0.0 \ --port 30000 \ --mem-fraction 0.8SGLang 启动后会暴露一个 OpenAI 兼容接口默认端口是 30000。--mem-fraction是显存占用比例可参考 vLLM 的--gpu-memory-utilization。我做压测对比时同样的 7B 模型SGLang 在多轮对话且 system prompt 很长的情况下首 token 延迟比 vLLM 低 20%~40%吞吐在并发中等时也更好。如果你的业务场景没那么“重复前缀”两者相差不算太大更看模型适配度。也有不少模型在发布时官方直接给出 SGLang 参考部署比如长上下文 MoE 模型SGLang 的内存调度策略往往更细腻。SGLang 的坑主要在版本和依赖上它自己会带一套sgl-kernel、flashinfer等加速底层需要和 CUDA 版本匹配如果编译失败建议直接换官方 Docker 镜像或者在干净环境里用pip install sglang[all]而不是手拼依赖。3.3 Ollama 本地部署下载、镜像、导入 GGUFOllama 是我给刚入门的人推得最多的。第一步是安装。Windows 用户官网下载OllamaSetup.exe国内直接下载慢的话可以用一些开源镜像站下载离线安装包。安装包本身不大问题主要在模型下载。设置国内镜像源是最实用的手段。Ollama 支持配置OLLAMA_HOST、OLLAMA_MODELS环境变量而镜像地址通常通过设置OLLAMA_REGISTRY_MIRROR之类的环境变量来指定我把这个写清楚在 Windows 上右键“此电脑” - 属性 - 高级系统设置 - 环境变量新增OLLAMA_MODELS指定模型存放目录比如D:\ollama_models。这样能解决“ollama怎么安装在d盘”的问题因为模型默认集中在C:\Users\me\.ollama\models不改的话 C 盘很容易爆。设置OLLAMA_REGISTRY_MIRROR你的镜像地址拉取模型就会走镜像。不少国内镜像加速服务提供 Ollama 仓库转存填上后ollama pull qwen2.5:7b速度就有明显变化。如果公司内网或离线环境就用离线安装包 手动放入 GGUF 模型文件。手动导入 GGUF 的操作方法ollama create需要一个 Modelfile。比如你下载了一个qwen2.5-7b-instruct-q4_k_m.gguf文件先写一个ModelfileFROM /data/gguf/qwen2.5-7b-instruct-q4_k_m.gguf TEMPLATE {{ if .System }}|im_start|system {{ .System }}|im_end| {{ end }}|im_start|user {{ .Prompt }}|im_end| |im_start|assistant PARAMETER stop |im_end| PARAMETER temperature 0.7然后执行ollama create qwen2.5-7b -f Modelfile ollama run qwen2.5-7b这样本地 GGUF 文件就能变成 Ollama 可管模型。Modelfile 里的模板要跟着模型走Qwen 系列、LLaMA 系列、ChatML 格式各不相同模板写错会导致对话乱套或“不思考”。Ollama 的 500 Internal Server Error 是高频问题热词里“ollama run qwen2.5:7b error: 500 internal server error”就是一个典型抱怨。后面我会专门讲。3.4 llama.cpp服务器与 Android 端的另类玩法先看服务器上的基本用法。编译 llama.cpp 常见两种纯 CPU 版和带 CUDA 版。在 Linux 下git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON cmake --build build --config Release带 CUDA 后运行 GGUF 模型并尽量让 GPU 参与./build/bin/llama-cli -m /models/qwen2.5-7b-q4_k_m.gguf -p 介绍一下开源推理引擎 -n 128 -ngl 99-ngl 99代表把模型层尽量全部加载到 GPU。CPU 跑大型模型时这个参数可为 0。你也可以启动交互式服务./build/bin/llama-server -m /models/qwen2.5-7b-q4_k_m.gguf --host 127.0.0.1 --port 8080llama-server 会提供/v1/chat/completions接口能让 LangChain、Open WebUI 等工具直接连接。Android 端玩法更“折腾”。你可以用 Termux 编译一个 android 版或者在 GitHub 下载别人构建好的二进制。装好后把 GGUF 文件放进手机存储命令行里执行./llama-cli -m /sdcard/Download/qwen2.5-3b-q4_k_m.gguf -p 你好 -n 64手机会很热速度取决于 CPU 和内存带宽。但这个东西的意义不是说一定要体验多流畅而是证明大模型推理不再是只能躲在机房里。你在讨论班、户外、没有网络的场景里也可以用本地模型做演示和简单问答。llama.cpp 的模型文件与 Ollama 可互通这就是为什么“gguf模型下载后如何导入ollama”成为热搜词。4. 踩坑实录与排查速查4.1 为什么 vLLM 最新版不总是最优选很多朋友喜欢追新只要看到 vLLM 出了新版本就立刻升级。但我自己踩过不止一次某个小版本对特定模型支持不好或者新调度逻辑在并发场景下 latency 抖动明显。社区里“vllm新版本性能下降”的讨论就是一个信号。生产环境升级 vLLM 的正确姿势是先在测试环境用量化跑 benchmark对比旧版本再决定是否升级。尤其当你的模型是特殊结构MoE、多模态、embedding时更不能拿“通用指标”代替你的真实流量。我建议锁定一个可复现的 Docker tag记录下来。比如vllm/vllm-openai:v0.27.1对某些 embedding 模型可用你就把它写进 CI 或部署脚本。后续再统一评估升级。同理SGLang 版本更新也很快有时候为了一个 bug fix 就需要换版本所以组件版本驱动要单独管理最好用环境锁文件。4.2 Ollama 下载与 500 报错的真实原因Ollama 下载慢的问题前面已经说了国内直连困难。除了配置镜像源还可以手动下载模型包然后放到models/blobs目录。但更傻瓜的方式是在能正常访问的机器上ollama pull后把.ollama/models整个文件夹拷到目标机器注意目标机器的OLLAMA_MODELS环境变量要指向这个目录。ollama run报 500 Internal Server Error 的原因多样常见的几个GPU 显存不足模型一加载就 OOMOllama 进程返回 500。可以尝试ollama run时限制并发或者换更小量化模型。模型文件损坏拉取中断导致 blob 不完整删掉模型后重新拉取。端口或模式冲突比如同时运行多个模型显存分配冲突。底层 llama-server 进程崩溃查看日志Windows 下在系统托盘 Ollama 图标日志Linux 下journalctl -u ollama或直接前台运行ollama serve看 stdout。报错信息里只要有llama-server process字样基本就是底层推理进程崩了先把模型换成 Q4_K_M 小模型试试如果好了说明是资源或兼容性问题。4.3 CUDA 加速与显存不足怎么破Ollama 在 Windows 上的 CUDA 加速默认是自动的只要 NVIDIA 驱动装好。但很多人装完驱动发现能跑 CPU就是没走 GPU原因可能是模型版本或 ollama 版本不支持当前显卡架构。最简单的验证方法ollama run时看日志里有没有offloaded 20/20 layers to GPU这种输出或者用nvidia-smi看显存占用。vLLM 显存不足时除了调--gpu-memory-utilization还有一个思路是降低--max-model-len因为预留的 KV cache 会随最大 token 数线性增长。如果你跑长文档但实际很少超过 8192就别设置 128K否则 4090 根本扛不住。llama.cpp 显存不足则调低-ngl甚至设 0 全 CPU。4.4 模型文件管理的五个细节模型文件动辄几个 GB管理不好会浪费大量时间。我的习惯是统一目录在服务器上建/data/models按模型名/版本分子目录镜像挂载时不要全盘挂载而是挂这个目录。校验文件下载 GGUF 或 weights 后用cksum、sha256sum和源站比对少一个 shard 文件都可能导致加载异常。区分权重格式config.json里的quantization_config会标明模型是 Gaussian 还是量化部署参数要匹配。定期清理Ollama 的ollama list能看到模型占用删掉不常用大模型能腾出磁盘。备份Modelfile手动导入的模型重新部署时没有 Modelfile 就得从头写模板最好把 Modelfile 放到和 GGUF 同目录提交到 git。5. 决策建议这把刀适合谁5.1 从团队规模与部署形态倒推选型不是选最火的那个而是选“你最可能把它用起来”的那个。如果你所在团队做产品闭环前端聊天、后端 API、多用户访问那主引擎就是 vLLM 或 SGLang。判断依据很简单你的请求是不是有大量重复前缀有优先 SGLang没有用 vLLM 省心安逸。SGLang 目前对较新模型和功能支持速度很快但如果你不想跟随一个年轻项目的节奏vLLM 的文档和案例更多招聘时也好找人。如果你只是一个人在本地做实验、跑知识库、或者给公司内部做 demoOllama 是最低成本的起点。它的生态工具AnythingLLM、Dify、Goose已经很成熟不用自己写推理层。等并发上来了再平滑迁到 vLLM 也不迟——API 兼容可以减少改动量。如果你要在无 GPU 的服务器、嵌入式设备、手机上跑llama.cpp 是唯一可靠的方案。GGUF 格式的便携性加上llama-server的 API 能力让它成为边缘推理的事实标准。Ollama 本身就是建立在其之上。5.2 我个人的项目经验参考我自己的项目一般是这样组合快速原型用 Ollama因为拉模型、改参数、试 prompt 太方便了正式上线用 vLLM 或 SGLang 其中之一看客户请求特征。在部署时我习惯用 Docker 先把环境钉死再用模型层的版本控制管理模型升级。vLLM 我一般选择稳定版镜像SGLang 在小流量 A/B 验证后再切。遇到 “某个模型用哪个镜像”的问题我第一反应是去看对方模型卡上的示例代码那上面写的就是经过验证的版本组合比自己瞎猜可靠得多。踩过几次坑之后我最大的体会是这些引擎没有绝对的优劣只有适不适合你的负载。vLLM 的高并发调度、SGLang 的前缀复用、Ollama 的管理便捷、llama.cpp 的轻量可嵌入分别压中了不同场景。把机制搞明白选型就不会被跑分和热度带着走。 
长河君 · 2026/11/3 8:11:05 · 阅读 1.2k vLLM、SGLang、Ollama、llama.cpp 四款开源推理引擎选型指南
选开源推理引擎这件事我最近被问得耳朵起茧。vLLM、SGLang、Ollama、llama.cpp 这四个名字排在一起看着都是“开源推理引擎”实际用起来完全是四个物种。有人用 vLLM 部署 Qwen 当线上 API一天几十万请求稳如老狗有人用 Ollama 想在 Windows 笔记本上跑个 7B 模型做实验结果卡在下载和 500 报错上还有人装着 llama.cpp 在 Android 手机上断断续续生成文本觉得“这也能行”不可思议。这篇文章就围绕这四款引擎从核心机制差异、选型逻辑、实际部署过程到踩坑排查一次性聊透给你一套“看见项目需求就知道该选谁”的判断方法。我尽量按我平时干活的口吻写不整虚的每一步都是可以照着操作的。1. 先搞清楚你手里的牌四个引擎的定位与机制差异1.1 vLLMPagedAttention 与 engine core 的高并发工厂vLLM 在我看来本质是一个“批量请求调度工厂”。它最核心的贡献是 PagedAttention也就是把 KV Cache 切成固定大小的块像操作系统的虚拟内存页一样管理。这样显存里的小碎片能利用起来同样一批请求可以塞进更大的 batch吞吐自然就上去了。这解决的是在线服务场景最痛的问题大量用户同时发请求如何让 GPU 一直在干活而不是空转。如果你去看 vLLM 的源码会看到内部有三个重要角色engine core、scheduler、executor。engine core 负责启动时初始化模型和配置并持有整个推理循环的状态scheduler 在每一轮迭代中检查队列里的请求决定哪些请求能被 prefill、哪些能继续 decode、哪些因为显存不够或 token 数超长要排队executor 则负责把调度器安排好的任务真正丢到 GPU 上执行。三者关系可以理解为scheduler 是排班经理executor 是干活工人engine core 是整个公司的老板。vLLM 1.x 之后把 engine core 抽象出来让这种交互流程更清晰也方便做多模态、结构化输出等扩展。这也是为什么很多团队把它和对话平台、API 网关绑在一起用。vLLM 适合的场景非常明确OpenAI 兼容的 API 服务、高并发场景、需要连续 batching 在线推理。你用它部署一个大模型然后在 8000 端口起一个服务聊天机器人前端来调它能把并发请求压缩成一个一个小 batch吞吐比朴素的 transformers 实现高出数倍。代价是引入的模块多、显存和 CUDA 驱动要求高个人电脑要跑起来并不轻松。1.2 SGLang把前缀缓存做进骨子里SGLang 是 vLLM 的强有力对手最近热度一路走高。它给我的印象是更“聪明”地安排同样输入的复用。SGLang 的招牌是 RadixAttention它在每次请求时把 prompt 拆成前缀树节点缓存下来。多轮对话的 system prompt 完全相同、检索增强生成里一堆文档都带同一个固定模板前缀……这些场景中重复的 KV Cache 不需要重新计算直接复用已有缓存prefill 开销大幅降低。当然SGLang 并不只有前缀缓存。它也实现了自己的 scheduler、executor、continuous batching还引入了“统一内存池”和自动编译前端能把多个请求的执行计划融合起来。简单说vLLM 在“怎么让 GPU 多塞请求”下功夫SGLang 在“怎么让相同内容少算第二遍”下功夫。所以很多长上下文、多轮对话、共享 prefix 的业务会明显感觉到 SGLang 更快。我在对比测试里用同样的 Qwen2.5 7B跑那种带 2000 token 固定 system prompt 的请求SGLang 首个 token 延迟肉眼可见地比 vLLM 低。这件事在 vLLM 开启 prefix caching 后差距缩小但 SGLang 的 RadixAttention 粒度更细细节上更有优势。SGLang 适合的场景是对首 token 延迟敏感、大量重复前缀、多轮会话、长上下文。如果你的业务开发者每天都在调一个知识库 bot强烈建议试试 SGLang。不过它比 vLLM 社区更年轻部分模型、量化格式的支持要留意版本适配。1.3 Ollama个人电脑上的“模型管家”Ollama 跟前面两个完全不是一个路线。它不是为了最大化 GPU 利用率而是为了“让普通人把模型跑起来”。Ollama 相当于一个模型管理工具安装之后ollama pull qwen2.5:7b拉模型ollama run qwen2.5:7b进对话一个命令搞定。它内部把模型包成一层一层真正做推理的底层默认是 llama.cpp 的构建版本。所以 Ollama 和 llama.cpp 有血脉关系。Ollama 的定位是本地开发、个人笔记、桌面端 demo、小团队内部体验。它提供 OpenAI 兼容接口默认 11434 端口所以 AnythingLLM、Dify、LangChain、Goose 这类工具也可以直接接。它吸引人的地方是模型包自带 Modelfile可以配置温度、上下文长度、system prompt 等服务可以单机多模型挂载有 web 或桌面客户端生态。但它不适合极端高并发因为底层 llama.cpp 的连续 batching 和 nvGPU 优化不如 vLLM 激进。你在本地拿 4090 跑 Ollama 做个人助手问题不大要扛十几位并发用户就要小心了。Ollama 最让人头疼的是下载模型太慢官方仓库在海外国内网络经常龟速。解决办法基本都是配置国内镜像源、通过代理下载我这里不提代理工具只说镜像站方式、或者把别人下好的 GGUF 文件手动导入。热词里的“ollama国内镜像源”“ollama 离线安装包”“gguf模型下载后如何导入ollama”都是这个痛点引出来的后面我要讲具体做法。1.4 llama.cppCPU 也能跑的轻量引擎llama.cpp 是 GGUF 格式的娘家。它用 C/C 实现没有厚重的 Python 依赖和 CUDA 生态绑定。它的设计目标很朴素只要有一台电脑CPU 也能推理大模型。通过量化 GGUF 文件比如 Q4_K_M 每参数只占约 4.5 bit7B 模型只要 4~5 GB 内存就能跑。它也对 GPU offload 做了支持你可以指定-ngl 99把全部层扔给显卡也可只用 CPU 跑。llama.cpp 的“轻”体现在很多地方有llama-cli、llama-server、llama-bench等命令行工具能跨平台编译 Windows、Linux、macOS、Android。热词里“llama.cpp android 版”不是新鲜事市面上很多手机端本地模型应用的内核就是 llama.cpp。你想在自己安卓机上跑一个离线小模型把 termux 装上编译个 llama.cpp 或者下载预编译包然后运行 GGUF 文件即可。虽然生成速度只有每秒几个 token但在移动端场景这种灵活性无可替代。llama.cpp 不适合线上高并发服务。它虽然提供llama-server并带 OpenAI 兼容 API但单请求吞吐、调度能力跟 vLLM 不在一个量级。它适合的场景离线推理、边缘设备、CPU 机器、模型实现调优、自定义采样器研究以及那些想要“干净、没依赖、可控”的实现。Ollama 用了它的内核这并不代表 Ollama 的所有能力就是 llama.cpp 的上限真正面向大流量的项目还是要回到 vLLM 或 SGLang。2. 选型逻辑与硬件依赖别只看跑分2.1 场景比拼在线服务、离线批处理、个人尝鲜很多朋友选引擎时习惯去论坛看 “vLLM 和 SGLang 哪个快”然后跟风。我建议先按场景画一个坐标左边是“要不要高并发在线 API”右边是“就一台个人电脑跑跑”。如果是左边直接排除 Ollama 和 llama.cpp 作为主服务端如果是右边vLLM 和 SGLang 可能成了负担。我列一张对比表把几个维度说清楚对比项vLLMSGLangOllamallama.cpp核心优化点PagedAttention、continuous batchingRadixAttention 前缀缓存模型管理与一键部署CPU/GPU 混合轻量推理主要格式FP16/BF16、AWQ、GPTQ、FP8FP16/BF16、量化兼容GGUFGGUF并发能力强强中低低部署复杂度高建议 Docker高建议 Docker低低OpenAI 兼容 API原生原生原生兼容llama-server 提供典型场景线上 API、高并发多轮对话、长上下文、知识库个人本地、小团队 demo离线、移动端、CPU 机器所以如果你做的是“给公司业务提供大模型接口”不用纠结默认 vLLM然后对比 SGLang 是否更快再切换如果你自己是开发者想在笔记本上快速跑个 7B 模型做原型Ollama 最省事如果你在树莓派或手机上跑或者只想在纯 CPU 机器上跑llama.cpp 是唯一正解。2.2 显存、内存的粗算方法附实例推理引擎跑之前最怕的是“模型装不上”。其实显存占用可以提前粗算。以 7B 模型为例FP16 权重约 14GB7B × 2 字节。BF16 一样。如果做 Q4_K_M 量化GGUF 文件通常只有 4.3~4.5GB内存占用接近这个值加一点上下文。而 vLLM 部署时除了权重还要给 KV Cache 预留显存在长上下文场景下这是大头。具体计算假设你用 vLLM 跑 Qwen2.5-7B-InstructFP16 权重 14GB设置--max-model-len 32768KV cache 在 batch 为 1、无 GQA 加持时非常大但因为有 GQA 和跳动 KV cache实际预留可能也要 5~8GB。所以一张 24GB 的 4090 是可以舒服跑 7B 长上下文的想跑 70B 至少要 2~3 张 48GB 或配合量化。用 llama.cpp 的 Q4_K_M 跑 7B 则只需约 5GB 内存CPU 也能跑只是速度感人。量化格式也要注意vLLM 1.x 支持 GPTQ、AWQ、FP8 等但它对 GGUF 支持的体验不如 llama.cpp 好你要是已经有一堆 GGUF 模型用 Ollama 和 llama.cpp 更顺。反过来你从 HuggingFace 拉了原版 weights想快速起个服务vLLM 直接--model 目录就行不需要提前转格式。2.3 CUDA 与 Docker90% 坑从环境来部署 vLLM 或 SGLang 最忌讳的事是裸机安装时版本不搭。vLLM 对 PyTorch、CUDA、GCC、甚至 NVIDIA 驱动都很敏感。一个常见错误是驱动太老报CUDA error: no kernel image is available另一个常见问题是 pip 安装的 PyTorch 是 CPU 版或 CUDA 版本不一致。所以官方推荐 Docker 镜像不是没有道理——镜像里已经把环境隔离好了宿主机只需要有 NVIDIA 驱动和支持 nvidia-container-toolkit 的容器运行时。Docker 拉起 vLLM 的标准套路是先装驱动再装 nvidia-container-toolkit然后docker run --gpus all。镜像地址一般用vllm/vllm-openai标签对应版本。热词里有“vllm/vllm-openai:v0.27.1 加载 qwen3-embedding-0.6b”这个场景就是docker run时传入--model和--task embedding之类的参数vLLM 1.x 对 embedding 模型支持也变好了。此外“glm5.3 使用 vllm 哪个版本的镜像”这类问题说明版本匹配确实困扰人我的建议是看模型官方文档给出的 vLLM 最低版本不要闭眼用最新镜像很多新版本性能反而出现回退社区里有不少反馈。3. 四款引擎的实操部署详解3.1 vLLM 部署 DeepSeek/Qwen 系列服务先说我在 Linux 服务器上部署 Qwen/DeepSeek 系列的标准操作。假设模型已经下载到宿主机/data/models下目录里有config.json和权重文件。我用 Docker因为升级和排障都方便docker run --runtime nvidia --gpus all \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:v0.27.1 \ --model /models/qwen2.5-7b-instruct \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --served-model-name qwen2.5-7b启动后本地就能请求了curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen2.5-7b,messages:[{role:user,content:你好}],max_tokens:256}热词里的“vllm部署deepseek”“docker部署vllm模型教程”都是这条路。有几个参数要解释--gpu-memory-utilization 0.9表示预留 90% 显存给 vLLM不能设太大否则显存溢出就起不来--max-model-len是模型最大上下文长度设得太大KV Cache 预留就多并发时容易 OOM设太小超长 prompt 会被截断。对于 7B 模型在 24GB 卡上32768 是常见安全值。vLLM 新版本 v0.6.x 到 0.8.x 之间变化挺大热词里“vllm新版本性能下降”不是空穴来风。有的版本 scheduler 改动后某些模型的 throughput 和 latency 都变差。我的实践原则是如果模型官方指定了镜像版本就用那个如果没有稳定优先用 vLLM 0.6.x 或 0.7.x 的成熟版本而不是追上最新的 tag。生产环境锁版本是一个好习惯。如果要用 embedding 模型比如 qwen3-embedding-0.6b命令类似但要加参数指定任务类型。vLLM 1.x 支持--task embedding然后请求/v1/embeddings。这个能力对于搭建 RAG 链路很有用不过要注意 vLLM 对 embedding 模型的支持并不是所有版本都完善部署前先去看 release notes。3.2 SGLang 部署与一致性加速SGLang 的部署也很像 vLLM但有一个明显的记忆点是“前缀缓存”。如果你搭一个知识库问答所有用户请求前都附带着同一个固定 system prompt 加一堆候选 chunksvLLM 每次都要重新 prefill 这些公共内容而 SGLang 的 RadixAttention 能直接命中缓存。这是它最大的卖点。在服务器上SGLang 可以用 Docker 也可以 pip 安装。我常用的方式是在 Python 虚拟环境里装pip install --upgrade sglang python -m sglang.launch_server \ --model-path /data/models/qwen2.5-7b-instruct \ --host 0.0.0.0 \ --port 30000 \ --mem-fraction 0.8SGLang 启动后会暴露一个 OpenAI 兼容接口默认端口是 30000。--mem-fraction是显存占用比例可参考 vLLM 的--gpu-memory-utilization。我做压测对比时同样的 7B 模型SGLang 在多轮对话且 system prompt 很长的情况下首 token 延迟比 vLLM 低 20%~40%吞吐在并发中等时也更好。如果你的业务场景没那么“重复前缀”两者相差不算太大更看模型适配度。也有不少模型在发布时官方直接给出 SGLang 参考部署比如长上下文 MoE 模型SGLang 的内存调度策略往往更细腻。SGLang 的坑主要在版本和依赖上它自己会带一套sgl-kernel、flashinfer等加速底层需要和 CUDA 版本匹配如果编译失败建议直接换官方 Docker 镜像或者在干净环境里用pip install sglang[all]而不是手拼依赖。3.3 Ollama 本地部署下载、镜像、导入 GGUFOllama 是我给刚入门的人推得最多的。第一步是安装。Windows 用户官网下载OllamaSetup.exe国内直接下载慢的话可以用一些开源镜像站下载离线安装包。安装包本身不大问题主要在模型下载。设置国内镜像源是最实用的手段。Ollama 支持配置OLLAMA_HOST、OLLAMA_MODELS环境变量而镜像地址通常通过设置OLLAMA_REGISTRY_MIRROR之类的环境变量来指定我把这个写清楚在 Windows 上右键“此电脑” - 属性 - 高级系统设置 - 环境变量新增OLLAMA_MODELS指定模型存放目录比如D:\ollama_models。这样能解决“ollama怎么安装在d盘”的问题因为模型默认集中在C:\Users\me\.ollama\models不改的话 C 盘很容易爆。设置OLLAMA_REGISTRY_MIRROR你的镜像地址拉取模型就会走镜像。不少国内镜像加速服务提供 Ollama 仓库转存填上后ollama pull qwen2.5:7b速度就有明显变化。如果公司内网或离线环境就用离线安装包 手动放入 GGUF 模型文件。手动导入 GGUF 的操作方法ollama create需要一个 Modelfile。比如你下载了一个qwen2.5-7b-instruct-q4_k_m.gguf文件先写一个ModelfileFROM /data/gguf/qwen2.5-7b-instruct-q4_k_m.gguf TEMPLATE {{ if .System }}|im_start|system {{ .System }}|im_end| {{ end }}|im_start|user {{ .Prompt }}|im_end| |im_start|assistant PARAMETER stop |im_end| PARAMETER temperature 0.7然后执行ollama create qwen2.5-7b -f Modelfile ollama run qwen2.5-7b这样本地 GGUF 文件就能变成 Ollama 可管模型。Modelfile 里的模板要跟着模型走Qwen 系列、LLaMA 系列、ChatML 格式各不相同模板写错会导致对话乱套或“不思考”。Ollama 的 500 Internal Server Error 是高频问题热词里“ollama run qwen2.5:7b error: 500 internal server error”就是一个典型抱怨。后面我会专门讲。3.4 llama.cpp服务器与 Android 端的另类玩法先看服务器上的基本用法。编译 llama.cpp 常见两种纯 CPU 版和带 CUDA 版。在 Linux 下git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON cmake --build build --config Release带 CUDA 后运行 GGUF 模型并尽量让 GPU 参与./build/bin/llama-cli -m /models/qwen2.5-7b-q4_k_m.gguf -p 介绍一下开源推理引擎 -n 128 -ngl 99-ngl 99代表把模型层尽量全部加载到 GPU。CPU 跑大型模型时这个参数可为 0。你也可以启动交互式服务./build/bin/llama-server -m /models/qwen2.5-7b-q4_k_m.gguf --host 127.0.0.1 --port 8080llama-server 会提供/v1/chat/completions接口能让 LangChain、Open WebUI 等工具直接连接。Android 端玩法更“折腾”。你可以用 Termux 编译一个 android 版或者在 GitHub 下载别人构建好的二进制。装好后把 GGUF 文件放进手机存储命令行里执行./llama-cli -m /sdcard/Download/qwen2.5-3b-q4_k_m.gguf -p 你好 -n 64手机会很热速度取决于 CPU 和内存带宽。但这个东西的意义不是说一定要体验多流畅而是证明大模型推理不再是只能躲在机房里。你在讨论班、户外、没有网络的场景里也可以用本地模型做演示和简单问答。llama.cpp 的模型文件与 Ollama 可互通这就是为什么“gguf模型下载后如何导入ollama”成为热搜词。4. 踩坑实录与排查速查4.1 为什么 vLLM 最新版不总是最优选很多朋友喜欢追新只要看到 vLLM 出了新版本就立刻升级。但我自己踩过不止一次某个小版本对特定模型支持不好或者新调度逻辑在并发场景下 latency 抖动明显。社区里“vllm新版本性能下降”的讨论就是一个信号。生产环境升级 vLLM 的正确姿势是先在测试环境用量化跑 benchmark对比旧版本再决定是否升级。尤其当你的模型是特殊结构MoE、多模态、embedding时更不能拿“通用指标”代替你的真实流量。我建议锁定一个可复现的 Docker tag记录下来。比如vllm/vllm-openai:v0.27.1对某些 embedding 模型可用你就把它写进 CI 或部署脚本。后续再统一评估升级。同理SGLang 版本更新也很快有时候为了一个 bug fix 就需要换版本所以组件版本驱动要单独管理最好用环境锁文件。4.2 Ollama 下载与 500 报错的真实原因Ollama 下载慢的问题前面已经说了国内直连困难。除了配置镜像源还可以手动下载模型包然后放到models/blobs目录。但更傻瓜的方式是在能正常访问的机器上ollama pull后把.ollama/models整个文件夹拷到目标机器注意目标机器的OLLAMA_MODELS环境变量要指向这个目录。ollama run报 500 Internal Server Error 的原因多样常见的几个GPU 显存不足模型一加载就 OOMOllama 进程返回 500。可以尝试ollama run时限制并发或者换更小量化模型。模型文件损坏拉取中断导致 blob 不完整删掉模型后重新拉取。端口或模式冲突比如同时运行多个模型显存分配冲突。底层 llama-server 进程崩溃查看日志Windows 下在系统托盘 Ollama 图标日志Linux 下journalctl -u ollama或直接前台运行ollama serve看 stdout。报错信息里只要有llama-server process字样基本就是底层推理进程崩了先把模型换成 Q4_K_M 小模型试试如果好了说明是资源或兼容性问题。4.3 CUDA 加速与显存不足怎么破Ollama 在 Windows 上的 CUDA 加速默认是自动的只要 NVIDIA 驱动装好。但很多人装完驱动发现能跑 CPU就是没走 GPU原因可能是模型版本或 ollama 版本不支持当前显卡架构。最简单的验证方法ollama run时看日志里有没有offloaded 20/20 layers to GPU这种输出或者用nvidia-smi看显存占用。vLLM 显存不足时除了调--gpu-memory-utilization还有一个思路是降低--max-model-len因为预留的 KV cache 会随最大 token 数线性增长。如果你跑长文档但实际很少超过 8192就别设置 128K否则 4090 根本扛不住。llama.cpp 显存不足则调低-ngl甚至设 0 全 CPU。4.4 模型文件管理的五个细节模型文件动辄几个 GB管理不好会浪费大量时间。我的习惯是统一目录在服务器上建/data/models按模型名/版本分子目录镜像挂载时不要全盘挂载而是挂这个目录。校验文件下载 GGUF 或 weights 后用cksum、sha256sum和源站比对少一个 shard 文件都可能导致加载异常。区分权重格式config.json里的quantization_config会标明模型是 Gaussian 还是量化部署参数要匹配。定期清理Ollama 的ollama list能看到模型占用删掉不常用大模型能腾出磁盘。备份Modelfile手动导入的模型重新部署时没有 Modelfile 就得从头写模板最好把 Modelfile 放到和 GGUF 同目录提交到 git。5. 决策建议这把刀适合谁5.1 从团队规模与部署形态倒推选型不是选最火的那个而是选“你最可能把它用起来”的那个。如果你所在团队做产品闭环前端聊天、后端 API、多用户访问那主引擎就是 vLLM 或 SGLang。判断依据很简单你的请求是不是有大量重复前缀有优先 SGLang没有用 vLLM 省心安逸。SGLang 目前对较新模型和功能支持速度很快但如果你不想跟随一个年轻项目的节奏vLLM 的文档和案例更多招聘时也好找人。如果你只是一个人在本地做实验、跑知识库、或者给公司内部做 demoOllama 是最低成本的起点。它的生态工具AnythingLLM、Dify、Goose已经很成熟不用自己写推理层。等并发上来了再平滑迁到 vLLM 也不迟——API 兼容可以减少改动量。如果你要在无 GPU 的服务器、嵌入式设备、手机上跑llama.cpp 是唯一可靠的方案。GGUF 格式的便携性加上llama-server的 API 能力让它成为边缘推理的事实标准。Ollama 本身就是建立在其之上。5.2 我个人的项目经验参考我自己的项目一般是这样组合快速原型用 Ollama因为拉模型、改参数、试 prompt 太方便了正式上线用 vLLM 或 SGLang 其中之一看客户请求特征。在部署时我习惯用 Docker 先把环境钉死再用模型层的版本控制管理模型升级。vLLM 我一般选择稳定版镜像SGLang 在小流量 A/B 验证后再切。遇到 “某个模型用哪个镜像”的问题我第一反应是去看对方模型卡上的示例代码那上面写的就是经过验证的版本组合比自己瞎猜可靠得多。踩过几次坑之后我最大的体会是这些引擎没有绝对的优劣只有适不适合你的负载。vLLM 的高并发调度、SGLang 的前缀复用、Ollama 的管理便捷、llama.cpp 的轻量可嵌入分别压中了不同场景。把机制搞明白选型就不会被跑分和热度带着走。