本地跑大模型选哪个引擎：五款开源方案的边界与代价

同一张显卡、同一个模型，换一个推理引擎，吞吐、显存和运维方式都会变。2026 年下半年可选的方案已经分层：桌面端拼省事，服务器端拼并发。这篇按许可、部署形态、并发模型、资源占用、维护状态五项标准，把五款开源引擎放在一起，逐款写清代价。

先定标准：五个问题决定选哪款

选引擎不是选跑分。先回答五个问题，候选名单通常就能砍掉一半：许可证是否满足商用与再分发、以什么形态部署、要扛多少并发、显存与内存预算多少、项目是否还在活跃维护。

• 许可：MIT 与 Apache-2.0 都允许商用，后者多一条专利授权条款；模型权重另有自己的许可，别和引擎许可混为一谈。
• 部署形态：单机进程、Docker 容器、Python 库，直接决定运维成本与升级方式。
• 并发模型：一次处理一个请求，还是连续批处理；这决定了多用户时是排队还是分摊。
• 资源占用：权重之外还要算 KV Cache，它随上下文长度与并发数一起涨。
• 维护状态：看发布节奏与最近提交时间，而不是 star 数。

五项里，许可与并发模型往往直接淘汰候选，剩下的再谈每秒出多少 token。反过来做，容易被一张跑分图带偏。

还有一层容易混淆：引擎许可宽松，不代表模型可以随便商用。开放权重模型常带自己的使用条款，有的按用户规模划线，有的限制再分发。部署前把引擎许可与模型卡许可分开记录，比事后补救省事。

桌面与单机：Ollama、llama.cpp、MLX

Ollama 是三款里上手门槛较低的一档。MIT 许可，macOS、Windows、Linux 与 Docker 都支持，装完一条命令拉模型，本地 11434 端口直接提供 REST 接口。它把模型下载、版本管理、常驻服务打包在一起，适合先把流程跑通。

代价写在默认值里。官方 FAQ 说明，每个模型的并行请求数由 OLLAMA_NUM_PARALLEL 控制，默认 1；所需内存按并行数乘上下文长度增长，默认上下文只有 4096 token。本地 API 不带鉴权，直接暴露到公网等于开门。

llama.cpp 走另一条路：纯 C/C++ 实现，不依赖外部库，模型用 GGUF 格式，后端覆盖 CPU、Metal、CUDA、HIP、Vulkan、SYCL、昇腾与 RISC-V 等。它支持 CPU 与 GPU 混合推理，模型比显存大也能跑一部分。

2026 年的 llama.cpp 已经不止是玩具。llama serve 提供 OpenAI 兼容接口并自带 Web UI，llama cli 可以直接从 Hugging Face 拉模型开聊，安装脚本与 Docker 镜像都有。它的短板在服务侧：缺多租户与配额，参数要对齐上游模型时得自己改命令。

Mac 用户还有第三个选择。mlx-lm 是 Apple 官方 MLX 框架的推理包，MIT 许可，支持量化、提示缓存与分布式推理，自带 mlx_lm.server，需要 macOS 15 及以上。局限也明确：只能跑在 Apple Silicon 上，模型要转成 MLX 格式，超出内存会明显变慢。

服务器：vLLM 与 SGLang

vLLM 的定位是多用户 GPU 服务。它用 PagedAttention 管理 KV Cache，配合连续批处理、分块预填充、前缀缓存与推测解码，把显存碎片压下去。接口侧提供 OpenAI 兼容服务，另有 Anthropic Messages 与 gRPC。并行方式覆盖张量、流水线、数据与专家并行，硬件以 NVIDIA、AMD 与 CPU 为主，其余后端靠插件。

它的代价是“重”。显存占用相对固定，冷启动要加载权重与编译内核，配置项多，单请求小模型场景不划算。把这些成本摊到几十路并发上才成立。

SGLang 同样面向服务端，Apache-2.0 许可，由 LMSYS 托管。它的核心是 RadixAttention：把请求前缀存进基数树，多轮对话、固定系统提示词、RAG 检索片段这类共享前缀的流量可以复用缓存。结构化输出与 OpenAI 兼容接口是标配，硬件覆盖 NVIDIA、AMD、Intel Xeon、TPU 与昇腾。

局限同样具体。生态与文档体量小于 vLLM，社区案例少一些；前缀复用依赖精确的 token 匹配，改一次聊天模板、或在多副本间随机路由，命中率就会掉下来。项目迭代快，部署时要锁版本。

一张表看清五款推理引擎的边界

表里刻意不写吞吐倍数。同一模型换一种量化、换一档上下文，倍数就会变；跨文章抄来的数字，搬到自己机器上通常对不上。第三方在 2026 年 10 月 27 日按各自文档做过一次逐项对照，结论与上表接近。

量化档位同样是取舍。4 bit 能把权重压到原来的四分之一左右，显存紧张时是可用选项，但复杂推理与长链任务上质量会掉，掉多少取决于模型与任务。生产环境更常见的是 FP8 或 AWQ，牺牲一点显存换稳定输出。

真要比较，做法是固定模型文件与量化、固定上下文与并发数，再测首字延迟、单路解码速度与总吞吐。四项一起看，才知道瓶颈在显存、在调度，还是在网络。

三组常见误配与改法

误配通常不是选错产品，而是把桌面工具推到了服务器位置。下面三组在自建环境里反复出现。

1. 用 Ollama 给团队做共享服务。默认并行 1、接口无鉴权，人一多就排队。改法是把 OLLAMA_NUM_PARALLEL 调到并发数并加反向代理鉴权，或者直接换 vLLM。
2. 在笔记本上用 vLLM 试模型。显存占用与冷启动都不适合单机试用。改法是先用 Ollama 或 llama.cpp 验证效果，确认要上线再迁到 GPU 服务器。
3. 拿 llama.cpp 扛几十路并发。它的强项是硬件覆盖与单机可控，不是队列调度。并发上到双位数，就该评估 vLLM 或 SGLang。

还有一类隐性成本常被忽略：上下文。并发 4 路、上下文 8K，KV Cache 的需求是单路的数倍，权重反而不是大头。先把这块钱算清，再谈引擎。

按场景给的起步顺序

个人先用 Ollama 跑通，需要指定后端、量化或混合卸载再换 llama.cpp；Mac 上追求内存效率可以试 mlx-lm。对外提供服务先上 vLLM，等到多轮对话、长系统提示词或 JSON 输出占主导，再拿 SGLang 做对照测试。

上层搭配可以分开选。图形界面用 Open WebUI 接本地模型，多模型与多供应商统一入口用 LiteLLM，需要把模型接进编码工作流，可参考 开源 AI 编程 Agent 合集 里的工具组合。

迁移成本比想象中低。多数引擎都提供 OpenAI 兼容接口，客户端改一个 base_url 就能切换。真正的差异在采样参数名、聊天模板与工具调用格式，这些要对齐到具体模型版本。

还有一条常被忽略：给引擎指定负责人。这类工具更新很快，没有固定的升级窗口，半年后往往没人说得清线上跑的是哪个版本。

判断方法很简单：先写下并发数与显存预算，能同时满足的候选通常只剩一两个。剩下的差别，用一天的实测就能补上，不必在选型上反复纠结。

相关地址

以下为文中五款引擎的官方入口，版本、许可与部署文档以这些页面为准。

• llama.cpp（GitHub 仓库）：https://github.com/ggml-org/llama.cpp
• Ollama（官网）：https://ollama.com/
• Ollama（常见问题与并发参数说明）：https://docs.ollama.com/faq
• vLLM（官方文档）：https://docs.vllm.ai/
• SGLang（官方文档）：https://docs.sglang.ai/
• MLX LM（GitHub 仓库）：https://github.com/ml-explore/mlx-lm