★ FEATURED ARTICLE 开头我先说个判断最近后台留言被问得最多的几个问题——我想跑DeepSeek用哪个引擎、Ollama下载模型慢怎么破、llama.cpp能不能在手机上跑——指向的其实是同一个困惑开源推理引擎这么多到底该怎么选。vLLM、SGLang、Ollama、llama.cpp这四个名字几乎出现在所有大模型部署的讨论里但它们的定位、原理、适用场景差异很大。把它们的机制搞清楚比收藏一百份部署教程都管用。这篇文章我尽量用大白话把这些引擎的底细拆开给出一套可落地的选型思路再附上我实测过的部署细节与踩坑记录适合正在纠结「用哪个跑模型」的开发者、以及想本地部署大模型但被各种报错劝退的入门玩家。1. 四个引擎的底层机制先搞清楚它们在干什么选型的前提是理解差异。这四个引擎虽然都能加载模型并提供推理接口但它们的底层设计哲学完全不同从内存管理到调度方式再到硬件支持范围各自都有一套路数。1.1 vLLMPagedAttention 与连续批处理vLLM的核心创新是PagedAttention中文社区一般翻译成分页注意力。这个机制解决的问题很具体大模型推理时KV Cache键值缓存占用的显存极其夸张。跑一个7B模型上下文长度拉到32K的时候KV Cache可能占到20多GB显存比模型权重本身还大。传统方案在推理前就要把整段上下文的KV Cache一次性分配好在这个过程中显存碎片化问题特别严重实际利用率经常不到60%。不同请求的长度不一样有的问一句就完事有的要读一整篇文档预分配的空间要么浪费要么不够用。PagedAttention的思路跟操作系统管理内存一模一样——把连续的逻辑显存拆成固定大小的物理块按需分配、用多少分多少中间还能做块复用。这就是为什么vLLM在长上下文、高并发场景下能把显存利用率和吞吐量都拉上去。另一个关键特性是Continuous Batching连续批处理。以前GPU推理是攒一批请求再一起算迟到的请求必须等下一轮GPU空闲时间不少。vLLM做到了流式调度一个序列的某个token算完立刻释放资源把新请求接进来整个GPU始终处于满载状态。这两个机制加在一起vLLM就成为生产环境中GPU资源利用率的天花板。但这套机制对GPU要求也高。PagedAttention的CUDA kernel实现非常精细只在NVIDIA GPU和部分AMD GPU上跑得顺。如果你的机器只有CPU、或者显卡太老不支持CUDAvLLM基本没有用武之地。1.2 SGLang结构化生成语言与RadixAttentionSGLang全称是Structured Generation Language它跟vLLM解决同一个问题——高并发、高吞吐的在线推理服务。但切入角度不一样。SGLang更在意的是请求和请求之间的共享计算核心利器叫RadixAttention一种带前缀树结构的KV Cache复用机制。举个例子你做一个AI客服100个用户同时提问前30个字都是你好我是你们的会员关于订单问题……传统推理引擎会把这段公共前缀在每张GPU上重复计算100次。SGLang把KV Cache组织成前缀树相同前缀只算一次后面的分支各自生长。遇到系统提示词、少样本示例这种高度复用的场景省下的算力非常可观。SGLang还提供了一套受限解码能力可以在推理时约束输出格式比如强制生成合法的JSON或正则匹配结果。工程上做结构化输出、工具调用这类场景时这个能力很实用。不足之处是它对使用者的工程素养要求更高想充分发挥前缀复用的优势部署层面需要更多的调优经验而且社区的生态、镜像更新速度目前还是比vLLM稍逊一筹。1.3 Ollama以好用为第一原则的本地服务Ollama在我看来是本地优先路线的集大成者它的定位不是生产级推理调优而是把模型部署这件事做到拿到手就能跑。Ollama本身是一个由llama.cpp等后端引擎驱动的封装服务你只需要ollama run qwen3:32b剩下的下载模型、创建服务、暴露API它全都帮你搞定。Ollama屏蔽了工程细节换来的是极度友好的上手体验这也是它在开发者社区和普通用户群体中爆火的原因。它的架构很聪明底层推理使用llama.cpp作为主要后端同时也能适配不同硬件平台然后自己做了一个模型管理仓库和HTTP API层。用户看到的是一个模型商店加一键启动器。这种设计在便利性和可控性之间做了取舍。Ollama的推理参数默认是保守调优过的大多数情况下能跑但你想追求极致吞吐或者用特殊量化策略就会觉得它的封装太厚不如直接操作底层引擎来的顺手。不过对于个人开发、原型验证、以及需要快速把模型集成到应用里的场景这个取舍完全值得。另外提醒一下网上经常有LM Studio和Ollama的对比。LM Studio更像一个图形化桌面工具侧重本地聊天和模型浏览Ollama则带有服务端属性更适合作为应用的后端API。两者不冲突看你需要的是一个本地聊天软件还是一个能接入自己代码的模型服务。1.4 llama.cpp生于边缘的罗塞塔石碑llama.cpp的起点就带着一个非常现实的目标让Meta的Llama模型跑在普通消费级CPU上。它的作者Georgi Gerganov用纯C/C重写了推理核心研究了GGUF量化格式让大模型在没NVIDIA显卡的机器上也能以可接受的速度运行。GGUF量化的核心是把模型权重从16位浮点数压缩到8位、4位甚至更低。Q4_K_M这种量化等级能把70B模型压到40GB以内同时把推理精度控制在合理范围。这就是llama.cpp能成为罗塞塔石碑的原因——它不挑硬件从老旧的x86笔记本到树莓派、再到Android手机只要有一个能跑C语言的环境它就能把模型运行起来。llama.cpp还有一层价值它是Ollama等上层服务的重要底层组件许多个人开发者用自己的C程序直接调用它的库来做端侧推理。最近社区里关于llama.cpp作为本地编程助手的讨论很多其实就是把代码补全模型部署在无GPU的开发机上靠CPU推理实现轻量级的补全服务延迟虽然比GPU高但对日常写代码来说已经足够流畅。Android版llama.cpp则让手机本地跑模型从概念变成了真的可用的东西我身边有朋友在高铁上用手机本地跑一个小模型写摘要体验其实出乎意料地好。2. 选型判断先回答三个问题再做选择很多人的误区是一上来就问哪个引擎最强这个问法本身就是错的。正确答案取决于你手里有什么硬件、跑什么业务、要什么效果。我建议做选型之前先回答下面三个问题。2.1 资源画像你的显卡到底什么段位第一步就是盘点硬件。显存大小直接决定了你能跑多大参数的模型、能不能用vLLM和SGLang这类高性能引擎。以一张24GB显存的RTX 4090为例跑7B模型FP16精度大约需要14GB显存全量的KV Cache留给长上下文会吃力所以vLLM的PagedAttention在这个场景下才有发挥空间。如果手里是8GB显存的RTX 4060那就得走量化路线GGUF Q4格式更适合你。如果机器完全没独显只有16GB内存那llama.cpp就是主力选择靠量化模型和CPU推理实现能跑的目标。这里有一个实用建议用模型权重显存 上下文KV Cache显存 20%余量这个公式去粗算。比如某个13B模型权重FP16大约是26GB你只有24GB显存那必须量化或者换更小的模型后路就是git下个GGUF版本用llama.cpp跑。2.2 业务形态研究实验还是生产接口第二个问题是你的业务场景。做本地聊天、跑通一个demo、给学生演示AI能力Ollama是最省心的答案它的API和OpenAI格式兼容代码链路很短。但如果要把模型服务作为真正的生产接口承载线上请求、提供SLA保障那vLLM或SGLang才是靠谱的选择。它们之间的取舍也看业务形态。请求场景里有大量共享前缀比如重复的系统提示词、大量长文档问答SGLang的前缀复用机制能省下不少计算。如果业务请求五花八门、相互之间没有重叠vLLM的PagedAttention和连续批处理带来的综合吞吐提升更明显。一般团队没有精力做精细调优的话我通常会建议先用vLLM它的默认策略更稳健翻车概率低。2.3 一张表看清四个引擎的边界把几个引擎的边界整理成一张对照表日常选型的时候对着看就清楚多了引擎硬件侧重最强场景主要短板推荐人群vLLMNVIDIA/AMD GPU高并发生产服务、长上下文显存门槛高、只支持GPU有GPU服务器资源的团队SGLangNVIDIA GPU前缀高度复用的服务场景调优复杂、生态较年轻有算法调优能力的团队Ollama跨平台CPU/GPU个人本地部署、快速原型封装厚、高并发性能一般所有想快速跑模型的开发者llama.cppCPU/边缘设备/GPU无GPU机器、智能终端吞吐弱、部署需要手动编译边缘开发者、资源受限场景这张表不是绝对的比如Ollama底层也可以加载量化模型跑得不错llama.cpp同样支持GPU加速层。但大体方向不会错想高性能就上vLLM/SGLang想把模型塞进任何设备里llama.cpp永远是最低保障而Ollama则是从零到一最快的路径。3. 部署实操从零跑通一条生产链路选型定了之后真正的坑才开始出现。这里我挑三个最常被问到的、也是我实际部署过多次的场景把关键步骤和细节写透。3.1 vLLM的Docker化部署细节vLLM官方提供了Docker镜像版本号同步更新。我最近部署新版GLM的时候社区在问该用哪个版本的vLLM镜像这个问题的标准答案其实不难找——VLLM_VERSION这个环境变量会写入模型的requirements文件看模型发布方在文档里标明的适配版本就行。如果没标明优先选最新release版本再对照模型仓库的Issue区确认。比如加载qwen3-embedding-0.6b这类embedding模型官方镜像v0.27.1就有合入支持直接拉对应tag的镜像即可。部署命令我给一个我自己在用的模板# 拉取镜像tag自行替换 docker pull vllm/vllm-openai:v0.27.1 # 启动服务 docker run --runtime nvidia --gpus all \ -p 8000:8000 \ -v /path/to/models:/models \ --ipchost \ vllm/vllm-openai:v0.27.1 \ --model /models/qwen3-embedding-0.6b \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --enforce-eager--max-model-len这个参数我单独说。它控制模型接受的最大输入长度数值越大会占用越多的KV Cache预分配空间。很多人报错CUDA out of memory就是因为这个值设太高了和PagedAttention节省显存的机制互相冲突。经验法则是普通对话场景从8192开始调试长文档场景再逐步加到16384或32768每加一次都观察显存占用是否在安全线内。--gpu-memory-utilization也不是设越大越好。0.9的意思是允许vLLM使用90%的显存做KV Cache剩下的留给模型权重和临时计算。但如果你在同一块GPU上同时还跑着别的服务就必须把这个值调低避免相互挤占导致OOM。--enforce-eager这个参数推荐在首次部署时加上。它关闭了CUDA graph优化但能显著加快启动速度等确认模型能稳定跑通之后再去掉也不迟。我见过太多人第一次启动vLLM就报CUDA相关错误加上这个参数能少走很多弯路。另一个容易忽略的细节是启动线程数。如果设备上CPU核数很多且显存充足可以在启动参数里加上--num-cpu-threads或者让调度器自动配置。不过这个参数普通用户几乎不用动默认值在多数场景下表现已经足够好。3.2 Ollama的安装与模型管理实操Ollama的安装使用本身没什么门槛真正让人头疼的是模型的下载速度。从官方仓库拉取大模型动辄几十个GB如果网络状况一般一个7B模型能下一天。解决思路有两个方向配置国内镜像源、或者离线安装包。配置镜像源的方式是通过环境变量指定模型下载地址。在Linux下执行前先设置OLLAMA_MODELS路径和镜像源地址# 设置模型存储路径避免占用系统盘 export OLLAMA_MODELS/data/ollama/models # 使用镜像源此处用国内镜像 export OLLAMA_HOST0.0.0.0:11434 # 国内镜像加速举例 export OLLAMA_BASE_URLhttps://ollama.example.com # 启动服务 ollama serve不过这只是一个可用方案不同平台的镜像源地址更新频繁而且Windows和macOS下环境变量的设置位置不一样。把环境变量写到系统环境变量文件里比在终端临时导出更稳妥不然每次重启终端都要重新设置。Windows用户还经常被安装到D盘的问题困扰官方安装包默认路径就是C盘。解决方案是安装完毕后在系统设置里改OLLAMA_MODELS指向D盘目录再把原本C盘里的模型文件夹迁移过去。这个流程比卸载重装安全得多。离线安装包的问题更常见。在无外网的生产环境里部署Ollama直接从有网的机器导出模型就行。ollama pull完成后模型文件都躺在OLLAMA_MODELS目录下把整个目录打包带走在目标机器解压到同样的路径然后重启ollama serve模型列表自然就出现了。注意一点不同操作系统之间迁移模型目录要小心跨平台模型文件通常可以复用但路径权限问题会经常冒出来Linux和Windows之间建议用tar打包而不是直接拷贝。我自己的实践是在离线服务器上准备一个固定的/opt/ollama-models挂载盘环境变量固定指向这里团队里谁要加模型就通过U盘拷过来解压非常省事。3.3 llama.cpp的高效构建与边缘场景落地llama.cpp的安装和构建比前两者手动得多但资源受限的机器上它是唯一的答案。构建方式官方文档写得很详细简单总结就是# 克隆代码 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 构建开启GPU加速如果本机有CUDA cmake -B build -DGGML_CUDAON cmake --build build --config Release -j如果目标是CPU推理把GGML_CUDA这项去掉即可。构建时有个小技巧可以用-j参数指定并行度我的8核机器一般用-j 8几十秒就能完成。构建完成后运行模型的方式一般是./build/bin/llama-cli \ -m /path/to/model.Q4_K_M.gguf \ -p 写一段关于推理引擎的代码 \ -n 256 -t 8 --temp 0.7-t参数指定线程数实测下来在CPU密集型机器上设成物理核心数而不是逻辑线程数性能曲线更平滑。--temp控制生成随机性代码补全场景我习惯调低到0.2左右生成内容更稳定不容易出现自由发挥。edge场景下的一个真实案例是llama.cpp作为本地编程助手。我在一台无GPU的旧笔记本上跑了qwen2.5-coder-7B的Q4量化版8线程推理补全一句代码大约需要1到2秒写工具的体感完全可接受。更夸张的是Android版有人用骁龙888在手机上跑0.5B和1.5B的小模型聊天延迟在一秒以内日常记录灵感、离线翻译这些场景绰绰有余。llama.cpp同样可以开启一个HTTP服务端模拟OpenAI接口这样你不需要自己写C调用代码也能对接开源生态的工具链./build/bin/llama-server \ -m /path/to/model.Q4_K_M.gguf \ --host 0.0.0.0 --port 8081 \ -t 8这种方式的好处是部署形态非常轻一个可执行文件加一个模型文件就能跑整个服务对嵌入式设备尤其友好。4. 常见错误排查与避坑实录这部分是我最想写的因为很多问题从报错信息到实际原因之间隔了好几层。4.1 500 Internal Server Errorllama-server进程如果你用Ollama时经常碰到这样的报错ollama run qwen3.5:2b error: 500 internal server error: llama-server process这个报错几乎90%的原因不是Ollama本身坏了而是Ollama尝试启动llama-server进程的时候失败了。导致失败的原因通常是显存不够、模型文件损坏、或者系统没装齐全的依赖库。排查步骤我按顺序排一下验证模型文件完整性ollama rm删除问题模型后重新pull。文件损坏是下载中断留下的后遗症也是概率比较高的原因。检查显存占用用nvidia-smi看显存是否被占满。Ollama默认在显存不够时会切回CPU推理但某些模型的GGUF设置可能有问题导致切换失败报500。看Ollama日志Linux下用journalctl -u ollama -f或者直接前台运行ollama serve看打印输出错误原因会直接出现在日志里比猜有效得多。我还遇到过一次很奇怪的情况只要拉了大参数模型再跑小模型就会报500。原因后来定位到Ollama的模型加载器在显存不足时不能正确释放旧模型把Ollama重启一下就恢复了。这种时候别瞎折腾别的先重启服务。4.2 模型下载太慢与离线安装方案ollama下载太慢是这个话题下出现频率最高的问题。模型仓库的带宽瓶颈客观存在尤其是每次版本更新后会重新拉取整个模型文件。我的建议是两条路并行一条是配国内镜像。Ollama的模型下载可以通过OLLAMA_BASE_URL环境变量指向代理服务这样既解决了速度问题也可以在内网环境里搭建一个模型分发中心方便团队成员共享模型文件。需要注意的是地址写法要精确匹配别漏了协议头。另一条是离线导入。如果你的模型文件已经以GGUF格式存在可以用下面这个命令把它导入Ollamaollama create my-model -f ModelfileModelfile里面写上基础模型路径或者FROM /path/to/model.ggufOllama就会在本地创建一条模型记录不再需要从远程仓库下载。这个方法在封闭开发环境里特别管用也是我处理离线部署最常用的手段。4.3 几个实操中的经典决策这一节记录几个我在实际部署中反复遇到、且网上资料说得不清楚的决策点。第一个是关于Qwen3.5强制不思考的。新版Qwen模型默认开启了思考模式在Ollama里如果不想让模型输出思考过程可以用Modelfile修改提示模板参数比如设置--no-thinking之类的参数或者在调用时通过API参数关闭推理模式。不同版本和量化格式支持的参数名不一样最稳的办法是去模型主页看它支持的chat template参数直接在对话时传进去。第二个是向量模型与embedding模型的加载问题。有朋友问Ollama安装了向量模型后如何使用实际上Ollama支持加载embedding模型调用方式和普通对话模型类似API返回的字段是嵌入向量而不是对话文本。对RAG应用来说Ollama作为向量生成服务完全够用但批量大量文本嵌入时的性能、并发能力不如专门的embedding服务这个需要取舍。第三个是Ollama怎么不支持NPU。这个问题在国产AI芯片讨论里经常出现Ollama目前的生态主要围绕CUDA、ROCm和CPU三大类后端开发对NPU的支持确实缺失。如果你必须在非NVIDIA的国产芯片上跑模型与其执着于Ollama不如直接用llama.cpp这一层适配或者考虑对接各芯片厂商自带的推理框架反而更简单。第四个被问爆的场景是通过Docker部署Ollama和docker vllm加载qwen3-embedding。Docker部署Ollama的关键就一条把模型目录映射出来别让容器删掉后模型跟着消失。docker run -d \ -v /da/ollama:/root/.ollama \ -v /da/ollama-models:/models \ -p 11434:11434 \ ollama/ollama而embedding模型在vLLM里加载本质上就是vLLM在0.27.1之后原生支持了文本嵌入模型的推理只要把权重路径指向embedding模型所在的目录即可。需要注意vLLM默认把第一个维度当作batch引索embedding模型加载时可能要调整--task参数为embedding否则返回内容会不符合预期。5. 我的最终建议与一点经验说了这么多最后给一个我个人的经验总结。很多人把选引擎当成一个技术选型、配置对比的问题但我觉得本质上是一个资源与需求匹配的问题。如果你是一个独立开发者想在自己的电脑上快速跑通一个模型应用直接Ollama别犹豫。它的模型管理、API兼容性、多平台支持能帮你省下一个下午的调参时间。等你的应用有了一定并发再考虑把Ollama换成vLLM。如果你是团队负责人手上有几张24GB以上的GPU业务要支撑真实用户请求那我建议先上vLLM它是生产环境中最不容易翻车的选择。它的默认参数比较稳重遇到性能瓶颈再研究SGLang的前缀复用优化。如果你是嵌入式或者边缘计算方向的人llama.cpp是绕不开的。它不只是能跑而是目前唯一能把大模型塞进各种奇怪硬件里的方案。它值得你花时间学。这些年我部署过的模型、踩过的坑真的不少曾经在一个GPU服务器上为了让vLLM跑稳一个长上下文任务来回调了三天参数最后发现问题只是--max-model-len设太高。很多技术问题一旦理解了底层机制解决起来其实非常简单。希望这篇文章能帮你少走一些弯路。
阅读完成 · 觉得有帮助？
