开源推理引擎怎么选vLLM、SGLang、Ollama、llama.cpp 的机制与部署部署大模型第一个要做的选择不是用哪个模型是用哪个推理引擎。同一张卡、同一个模型换个引擎能扛的并发可能差好几倍——因为引擎决定了 KV Cache 怎么管、请求怎么排队。这篇讲清主流开源引擎的技术机制差异和选型逻辑每个都给出部署命令。看完你就能对着一张卡、一个场景直接定下来用哪个。一、推理引擎到底在优化什么大模型推理有两个绕不开的开销引擎的功夫全花在这两件事上一是 KV Cache 怎么管。生成过程中每个 token 的历史 Key/Value 都要存着。存得散、碎片多显存就浪费存得死板长上下文就爆。二是请求怎么排队。一个请求生成到一半GPU 在等它如果非要等它生成完才处理下一个GPU 大量时间在空转。怎么把多个请求插空塞进 GPU是吞吐量的关键。各家引擎的差别本质就是这两件事的解法不同。记住这一点后面的机制就都好理解了。二、四大主流引擎的技术机制先看全景对比维度vLLMSGLangOllamallama.cpp核心机制PagedAttentionRadixAttention封装 llama.cpp纯 C 推理批处理连续批处理连续批处理 零开销调度单队列为主单队列为主权重格式HF safetensorsHF safetensorsGGUFGGUF典型硬件NVIDIA GPUNVIDIA GPUCPU / Apple / GPUCPU / 边缘设备定位生产级 API 服务Agent / 复杂工作流本地便捷、多模型管理极致轻量、可移植vLLM把操作系统的分页思想搬进显存核心是 PagedAttention。它借鉴操作系统的虚拟内存分页把 KV Cache 切成固定大小的页存在非连续的显存空间里用一张表记录映射关系。解决的问题传统做法要求每个请求的 KV Cache 在显存里连续存放长度不一就会产生大量显存碎片利用率常常只有 60% 左右。分页之后碎片问题被消掉显存利用率能上到 95% 以上——同一张卡能塞下更多并发。再叠加连续批处理Continuous Batching请求不用等整批做完生成完的立刻退出、新的立刻插入GPU 持续保持忙碌。适合企业级高并发 API 服务、线上客服、需要吞吐的场景。pipinstallvllm python-mvllm.entrypoints.openai.api_server\--modelQwen/Qwen2.5-7B-Instruct\--tensor-parallel-size2\--gpu-memory-utilization0.9启动后就是一个OpenAI 兼容接口原来的 OpenAI SDK 直接改 base_url 就能用。SGLang用前缀树复用 KV Cache核心是 RadixAttention。它用基数树前缀树管理 KV Cache把多个请求相同的前缀共享起来。为什么这个设计重要在多轮对话、Agent 多步任务里大量请求的前缀是重复的比如同一个 system prompt、同一段对话历史。传统做法每个请求都重算一遍前缀浪费巨大RadixAttention 让它们复用同一份缓存。另一大特色是结构化输出的 DSL可以用领域特定语言强约束模型输出 JSON、函数调用或自定义格式在多步协调上是最强的。适合Agent 应用、工具协作、多步骤任务、高吞吐多轮对话。pipinstallsglang[all]python-msglang.launch_server\--model-path Qwen/Qwen2.5-7B-Instruct\--port30000Ollama易用性优先的本地管理器它的定位不是最快的引擎是最好用的本地入口。底层封装 llama.cpp / ggml / gguf 生态用 Go 重新包了一层做到一键部署、开箱即用。核心价值在模型管理Modelfile可以自定义模型、系统提示与参数多模型一键切换。完全离线运行数据不出本机。适合个人开发、快速原型、隐私敏感场景、Apple Silicon 上跑。ollama run qwen2.5:7b# 一条命令拉起ollama serve# 起本地 API 服务默认 11434注意它的边界Ollama 面向的是单人/小规模多并发需要显式配置OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS默认配置下并发能力远不如 vLLM。别拿它扛生产级并发。llama.cpp纯 C 的极致轻量纯 C/C 实现依赖极低能编译成单个二进制文件可移植性极高。深度支持GGUF 的 4/5/8-bit 量化把内存占用压到最低。独有的 GBNF 语法约束可以在生成时严格约束输出格式边缘端生成结构化数据很实用。还支持 CPU、CUDA、Apple Metal甚至WASM。适合硬件资源受限、边缘设备、需要极致可移植或离线的场景。./llama-server-mqwen2.5-7b-q4_k_m.gguf-c8192-ngl99--port8080三、还有哪些值得知道主流之外这几个在特定场景下是更优解引擎独特之处适合TensorRT-LLMNVIDIA 官方核心级优化FP8/FP4 原生延迟要求最苛刻的场景XInferencePrefill / Decode 分离部署K8s 扩展大规模分布式LMDeploy国产硬件昇腾深度优化多模态国产算力部署LightLLM三进程异步 TokenAttention手机 / IoT 边缘Prefill / Decode 分离是这两年一个明确的方向把处理输入和生成输出拆到不同 GPU 上因为两者的瓶颈不同一个吃算力、一个吃带宽。XInference 是这方面的代表。国产硬件这条线要注意LMDeploy它对昇腾等国产算力做了深度优化如果你的部署环境是国产卡这是绕不开的选项。四、怎么选一张决策表你的场景选它理由企业级高并发 APIvLLMPagedAttention 连续批处理吞吐最优延迟要求极致TensorRT-LLMNVIDIA 核心级优化Agent / 多步任务 / 多轮对话SGLang前缀复用 结构化 DSL个人本地、快速上手Ollama一键部署、多模型管理边缘设备、纯 CPU、极致轻量llama.cpp单二进制、GGUF、GBNF国产算力昇腾LMDeploy针对国产卡深度优化大规模分布式XInferencePrefill/Decode 分离 K8s三条选型原则先看硬件。有 NVIDIA 卡走 vLLM/SGLang纯 CPU 或边缘走 llama.cpp国产卡走 LMDeployApple Silicon 走 Ollama 或 llama.cpp再看并发量。单人到几个人用Ollama 够了要扛并发必须上 vLLM/SGLang——别用 Ollama 硬扛生产最后看任务形态。大量重复前缀Agent、多轮优先 SGLang纯问答 API 用 vLLM。五、部署要点几个容易踩的坑一是gpu-memory-utilization别拉满。vLLM 里这个参数控制显存占用比例设成 0.95 以上容易 OOM还要留显存给框架本身和临时张量。0.85~0.9 更稳。二是--max-model-len要显式设。不设的话引擎按模型的最大上下文预留 KV Cache长上下文模型会直接把显存吃光。按你实际需要的长度设。三是 GGUF 量化等级别一味求小。Q4 比 Q8 省显存但精度损失在某些任务上很明显尤其代码、数学。先测再定别默认越小越好。四是并行度要跟卡数匹配。--tensor-parallel-size设成卡数设错了要么跑不起来要么显存不均。五是接口兼容不等于行为一致。各家都提供 OpenAI 兼容接口但采样参数、工具调用、流式细节的实现有差异。迁移时要用自己的用例回归别假设换个 base_url 就完全一样。六、卡住时的排查顺序起不来 / OOM→ 先降gpu-memory-utilization再显式设max-model-len吞吐上不去→ 确认开了连续批处理检查并发请求数是不是太低多轮对话越来越慢→ 看引擎是否支持前缀复用SGLang 的强项输出格式不稳→ 用结构化输出能力SGLang DSL / llama.cpp GBNF别靠提示词硬求精度掉了→ 回退量化等级先确认是不是量化导致的国产卡跑不起来→ 换 LMDeploy别在 vLLM 上死磕。最后一句推理引擎的选择本质是在吞吐、延迟、易用、硬件四个约束里找平衡。没有最好的引擎只有最适合你当前硬件和场景的那个。先确定硬件和并发量再选引擎——这个顺序反了后面全是返工。说明文中引擎机制PagedAttention、RadixAttention、连续批处理、GBNF 等为各项目官方文档与公开技术资料的通行描述显存利用率、量化等级等数值为常见经验范围实际表现与模型、硬件、框架版本强相关请以官方文档和自身回归为准。部署命令为通用示例参数名以所用版本为准。本文不做跨引擎的性能排名。
开源推理引擎怎么选：vLLM、SGLang、Ollama、llama.cpp 的机制与部署
开源推理引擎怎么选vLLM、SGLang、Ollama、llama.cpp 的机制与部署部署大模型第一个要做的选择不是用哪个模型是用哪个推理引擎。同一张卡、同一个模型换个引擎能扛的并发可能差好几倍——因为引擎决定了 KV Cache 怎么管、请求怎么排队。这篇讲清主流开源引擎的技术机制差异和选型逻辑每个都给出部署命令。看完你就能对着一张卡、一个场景直接定下来用哪个。一、推理引擎到底在优化什么大模型推理有两个绕不开的开销引擎的功夫全花在这两件事上一是 KV Cache 怎么管。生成过程中每个 token 的历史 Key/Value 都要存着。存得散、碎片多显存就浪费存得死板长上下文就爆。二是请求怎么排队。一个请求生成到一半GPU 在等它如果非要等它生成完才处理下一个GPU 大量时间在空转。怎么把多个请求插空塞进 GPU是吞吐量的关键。各家引擎的差别本质就是这两件事的解法不同。记住这一点后面的机制就都好理解了。二、四大主流引擎的技术机制先看全景对比维度vLLMSGLangOllamallama.cpp核心机制PagedAttentionRadixAttention封装 llama.cpp纯 C 推理批处理连续批处理连续批处理 零开销调度单队列为主单队列为主权重格式HF safetensorsHF safetensorsGGUFGGUF典型硬件NVIDIA GPUNVIDIA GPUCPU / Apple / GPUCPU / 边缘设备定位生产级 API 服务Agent / 复杂工作流本地便捷、多模型管理极致轻量、可移植vLLM把操作系统的分页思想搬进显存核心是 PagedAttention。它借鉴操作系统的虚拟内存分页把 KV Cache 切成固定大小的页存在非连续的显存空间里用一张表记录映射关系。解决的问题传统做法要求每个请求的 KV Cache 在显存里连续存放长度不一就会产生大量显存碎片利用率常常只有 60% 左右。分页之后碎片问题被消掉显存利用率能上到 95% 以上——同一张卡能塞下更多并发。再叠加连续批处理Continuous Batching请求不用等整批做完生成完的立刻退出、新的立刻插入GPU 持续保持忙碌。适合企业级高并发 API 服务、线上客服、需要吞吐的场景。pipinstallvllm python-mvllm.entrypoints.openai.api_server\--modelQwen/Qwen2.5-7B-Instruct\--tensor-parallel-size2\--gpu-memory-utilization0.9启动后就是一个OpenAI 兼容接口原来的 OpenAI SDK 直接改 base_url 就能用。SGLang用前缀树复用 KV Cache核心是 RadixAttention。它用基数树前缀树管理 KV Cache把多个请求相同的前缀共享起来。为什么这个设计重要在多轮对话、Agent 多步任务里大量请求的前缀是重复的比如同一个 system prompt、同一段对话历史。传统做法每个请求都重算一遍前缀浪费巨大RadixAttention 让它们复用同一份缓存。另一大特色是结构化输出的 DSL可以用领域特定语言强约束模型输出 JSON、函数调用或自定义格式在多步协调上是最强的。适合Agent 应用、工具协作、多步骤任务、高吞吐多轮对话。pipinstallsglang[all]python-msglang.launch_server\--model-path Qwen/Qwen2.5-7B-Instruct\--port30000Ollama易用性优先的本地管理器它的定位不是最快的引擎是最好用的本地入口。底层封装 llama.cpp / ggml / gguf 生态用 Go 重新包了一层做到一键部署、开箱即用。核心价值在模型管理Modelfile可以自定义模型、系统提示与参数多模型一键切换。完全离线运行数据不出本机。适合个人开发、快速原型、隐私敏感场景、Apple Silicon 上跑。ollama run qwen2.5:7b# 一条命令拉起ollama serve# 起本地 API 服务默认 11434注意它的边界Ollama 面向的是单人/小规模多并发需要显式配置OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS默认配置下并发能力远不如 vLLM。别拿它扛生产级并发。llama.cpp纯 C 的极致轻量纯 C/C 实现依赖极低能编译成单个二进制文件可移植性极高。深度支持GGUF 的 4/5/8-bit 量化把内存占用压到最低。独有的 GBNF 语法约束可以在生成时严格约束输出格式边缘端生成结构化数据很实用。还支持 CPU、CUDA、Apple Metal甚至WASM。适合硬件资源受限、边缘设备、需要极致可移植或离线的场景。./llama-server-mqwen2.5-7b-q4_k_m.gguf-c8192-ngl99--port8080三、还有哪些值得知道主流之外这几个在特定场景下是更优解引擎独特之处适合TensorRT-LLMNVIDIA 官方核心级优化FP8/FP4 原生延迟要求最苛刻的场景XInferencePrefill / Decode 分离部署K8s 扩展大规模分布式LMDeploy国产硬件昇腾深度优化多模态国产算力部署LightLLM三进程异步 TokenAttention手机 / IoT 边缘Prefill / Decode 分离是这两年一个明确的方向把处理输入和生成输出拆到不同 GPU 上因为两者的瓶颈不同一个吃算力、一个吃带宽。XInference 是这方面的代表。国产硬件这条线要注意LMDeploy它对昇腾等国产算力做了深度优化如果你的部署环境是国产卡这是绕不开的选项。四、怎么选一张决策表你的场景选它理由企业级高并发 APIvLLMPagedAttention 连续批处理吞吐最优延迟要求极致TensorRT-LLMNVIDIA 核心级优化Agent / 多步任务 / 多轮对话SGLang前缀复用 结构化 DSL个人本地、快速上手Ollama一键部署、多模型管理边缘设备、纯 CPU、极致轻量llama.cpp单二进制、GGUF、GBNF国产算力昇腾LMDeploy针对国产卡深度优化大规模分布式XInferencePrefill/Decode 分离 K8s三条选型原则先看硬件。有 NVIDIA 卡走 vLLM/SGLang纯 CPU 或边缘走 llama.cpp国产卡走 LMDeployApple Silicon 走 Ollama 或 llama.cpp再看并发量。单人到几个人用Ollama 够了要扛并发必须上 vLLM/SGLang——别用 Ollama 硬扛生产最后看任务形态。大量重复前缀Agent、多轮优先 SGLang纯问答 API 用 vLLM。五、部署要点几个容易踩的坑一是gpu-memory-utilization别拉满。vLLM 里这个参数控制显存占用比例设成 0.95 以上容易 OOM还要留显存给框架本身和临时张量。0.85~0.9 更稳。二是--max-model-len要显式设。不设的话引擎按模型的最大上下文预留 KV Cache长上下文模型会直接把显存吃光。按你实际需要的长度设。三是 GGUF 量化等级别一味求小。Q4 比 Q8 省显存但精度损失在某些任务上很明显尤其代码、数学。先测再定别默认越小越好。四是并行度要跟卡数匹配。--tensor-parallel-size设成卡数设错了要么跑不起来要么显存不均。五是接口兼容不等于行为一致。各家都提供 OpenAI 兼容接口但采样参数、工具调用、流式细节的实现有差异。迁移时要用自己的用例回归别假设换个 base_url 就完全一样。六、卡住时的排查顺序起不来 / OOM→ 先降gpu-memory-utilization再显式设max-model-len吞吐上不去→ 确认开了连续批处理检查并发请求数是不是太低多轮对话越来越慢→ 看引擎是否支持前缀复用SGLang 的强项输出格式不稳→ 用结构化输出能力SGLang DSL / llama.cpp GBNF别靠提示词硬求精度掉了→ 回退量化等级先确认是不是量化导致的国产卡跑不起来→ 换 LMDeploy别在 vLLM 上死磕。最后一句推理引擎的选择本质是在吞吐、延迟、易用、硬件四个约束里找平衡。没有最好的引擎只有最适合你当前硬件和场景的那个。先确定硬件和并发量再选引擎——这个顺序反了后面全是返工。说明文中引擎机制PagedAttention、RadixAttention、连续批处理、GBNF 等为各项目官方文档与公开技术资料的通行描述显存利用率、量化等级等数值为常见经验范围实际表现与模型、硬件、框架版本强相关请以官方文档和自身回归为准。部署命令为通用示例参数名以所用版本为准。本文不做跨引擎的性能排名。
