别再瞎装了！大模型本地部署，Ollama / vLLM / SGLang 到底该选谁？

本文来源： 反神经全栈（公众号：反神经全栈）
原文链接： https://mp.weixin.qq.com/s/OIOHG9f0XOPW8ZnfMKQ2VA
发布时间： 2026-09-01 12:09

作者： 反神经全栈　　发布时间： 2026-09-01 12:09

先问你一个问题。

你有没有过这种经历：兴致冲冲下载了一个大模型，环境装了半天，好不容易 run 起来，结果——

• 自己问一句话要等 5 秒，多开两个对话窗口直接卡死；
• 想做个小服务给同学用，并发一上来显存就爆，进程原地去世；
• 看网上教程说"用 vLLM 快十倍"，照着装完发现命令看不懂、报错看不明白。

我见过太多人，把"模型没跑好"归结为"我的显卡太菜""这个模型不行"。

真相往往是：你不是模型选错了，你是"部署框架"选错了。

模型只是发动机，部署框架才是整车底盘。底盘选不对，再好的发动机也跑不起来。今天这篇文章，我把当前最主流的四个本地部署框架——Ollama、vLLM、SGLang、vLLM-Omni——一次讲透。读完你会明白：什么场景该用哪个，你的显卡到底能跑多大，以及那些"高手"不会主动告诉你的坑。

一、先想清楚：你为什么要"本地部署"？

在选工具之前，先确认你是不是真的需要本地部署。本地部署不是银弹，它解决的是下面这几件事：

1. 数据隐私。 你让云端模型处理公司代码、个人简历、客户资料，数据就出了你的边界。本地部署，数据不出机。

2. 成本可控。 云端 API 按 token 计费，量一大就是无底洞。本地一次性投入显卡，后续推理边际成本趋近零。

3. 离线可用、随时改。 没网也能跑，想换量化、换提示词、接自己的 RAG，完全自己说了算。

4. 但它不便宜、也不简单。 显卡是硬成本，框架是软门槛。所以——

关键认知："本地部署" ≠ 直接 python model.py 跑模型。 框架决定了你能跑多快、跑多大、多少人能同时用。选错框架，体验差十倍。

这四个框架，本质是在"易用性、性能、并发、多模态"四个维度上做了不同取舍。下面我们一张图先看定位。

二、四个框架，一张图看懂定位

记住这张表，后面每一个框架的拆解，都是在解释它为什么站在这个位置。

三、Ollama：新手的第一台"本地模型发动机"

Ollama 的本质，是把 llama.cpp 这个底层推理库，套了一层极简的命令行外壳。它干的最关键的一件事是：把"下载模型、量化、加载、起服务"全部封装成一个命令。

# 安装后，跑起一个 7B 模型只需要一行
ollama run qwen2.5:7b

你甚至可以用 Modelfile 像写 Dockerfile 一样定义自己的模型：

FROM qwen2.5:7b
SYSTEM "你是一个严谨的求职顾问，回答必须给出可执行的步骤。"

它好在哪：

• 真·一键：Mac、Windows、Linux 全平台，装完即用，没有依赖地狱。
• 模型丰富：官方库 + 社区模型，Qwen、Llama、DeepSeek、Gemma 随便拉。
• 自动量化：GGUF 格式自动帮你压显存，一张 8G 显卡也能跑 7B。
• 本地 API：默认起在 11434 端口，直接被你的 Agent、脚本调用。

它的天花板在哪（很多人栽在这里）：

• 并发弱：本质是单用户友好的设计，多个请求同时来，吞吐掉得厉害。
• 吞吐一般：相比专用推理引擎，单位显存产出的 token 数偏少。
• 生产化弱：缺监控、缺批处理优化，拿它硬扛服务会后悔。

一句话总结： Ollama 是让你"先跑起来"的工具，不是让你"扛住流量"的工具。想学原理、做本地 Agent、单机玩，它是首选。

四、vLLM：把一块显卡榨干的"并发王者"

如果说 Ollama 是代步买菜车，vLLM 就是赛道版性能怪兽。它的核心武器叫 PagedAttention——把 Transformer 推理中最占显存的 KV Cache，像操作系统管理内存一样"分页"管理，显存利用率直接拉满。

另一个杀手锏是连续批处理（Continuous Batching）：不再等一个批次凑齐再算，而是来一个请求就塞进空闲算力，GPU 几乎不闲着。

起一个兼容 OpenAI 接口的服务，也是一行：

vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000

然后你就能用和 OpenAI 完全一样的姿势调用：

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "本地部署怎么选？"}]
)

它好在哪：

• 吞吐和并发顶级：同等显卡下，吞吐通常是 Ollama/原生推理的数倍。
• OpenAI 兼容：你原来调 GPT 的代码，改个 base_url 就能切到本地。
• 生产首选：国内绝大多数"私有化推理服务"落地，底层都是 vLLM。

它的代价：

• 显存占用大：为了性能，它更吃显存，小显卡要选好量化。
• 上手成本：要懂端口、批大小、张量并行这些概念。
• 偏单模型服务：多模态、复杂编排不是它的主战场。

一句话总结： 你要做的是"给别人用的服务"，要扛并发、要低延迟、要 API 化——闭眼选 vLLM。

五、SGLang：不止会推理，更懂"怎么把任务编排好"

SGLang 和 vLLM 常被拿来比，但它们解决的是不同层面的问题。vLLM 回答"怎么快地把一个请求算完"，SGLang 回答"怎么把一串复杂请求编排好、还不浪费算力"。

它的核心创新是 RadixAttention（前缀缓存）：多个请求如果共享同一段提示词前缀（比如同一个系统提示、同一段知识库上下文），这部分计算只算一次，后续全部复用。在 Agent 场景里，这个优化是降维打击。

更妙的是它内置了结构化输出约束——你直接要求"返回合法 JSON"，它保证吐出来的就是能解析的 JSON，不用你事后正则兜底。

import sglang as sgl

@sgl.function
def extract_job(prompt):
    sgl.gen("info", max_tokens=512,
            regex=r'\{"公司":.*,"岗位":.*,"技能":.*\}')
    return sgl.gen_text()

它好在哪：

• 复杂多步任务强：Agent 那种"调工具→看结果→再决定下一步"的链路，编排得最顺。
• 前缀复用省钱：同样上下文反复问，算力只花一次。
• 结构化输出稳：做信息抽取、表单填充、RAG 后处理，体验极佳。

它适合谁： 你在做 Agent、做需要稳定 JSON 输出的后端、做多轮复杂流水线——SGLang 比 vLLM 更对味。

六、vLLM-Omni：当大模型"长了眼睛和耳朵"

前面三个，主角都是文本大模型。但今天的应用早就不止文本了——你要让模型看图片、听语音、看视频。

vLLM-Omni 就是在 vLLM 基础上扩展出的多模态推理服务框架。它解决的核心难题是：文本、图像、音频的推理路径完全不同，怎么用一个服务统一调度？

它的两个关键设计：

• Omni-Router（多模态路由器）：根据输入里含哪些模态，把任务分发给对应的编码器/解码器，不浪费算力。
• Omni-Inferencer（多模态推理器）：统一管理不同模态模型的加载、批处理和显存。

它适合谁： 你要做语音对话助手、图文问答、视觉理解这类"多模态应用"，vLLM-Omni 是当前最省心的本地方案之一。

注意：多模态对显存的要求是文本的数倍。别指望一张 8G 卡能流畅跑"看图说话+语音"，后面显存表会给你泼冷水。

七、一张表横评：六个维度直接拉满

把上面四个拉到同一张表，差异一目了然：

怎么读这张表：

• 要"最省事先跑起来"→ Ollama
• 要"扛并发的纯文本服务"→ vLLM
• 要"Agent/JSON/复杂流水线"→ SGLang
• 要"图文音多模态"→ vLLM-Omni

八、显存对照表：你的卡到底能跑多大的模型？

这是全网收藏率最高的那种表，建议直接存图。以下为消费级显卡的经验参考（7B/13B/34B/70B，量化等级 Q4/Q8/fp16）：

两个关键提醒：

1. Ollama 的 Q4 量化是真香，但精度有损。 写代码、做推理，Q4 通常够用；但涉及精确计算、长上下文，建议至少 Q8。
2. vLLM 比 Ollama 更吃"峰值显存"。 同样 7B，vLLM 为了吞吐会预留更多 KV Cache，小显卡要显式控制 --gpu-memory-utilization。

一句话：显存不够，先降量化、再换框架，别硬上 fp16，否则不是爆显存就是慢到怀疑人生。

九、选型决策树：对号入座

不想看长篇，直接照这个来：

• 我是学生/新手，想本地跑模型玩、接 Agent → Ollama，ollama run 五分钟上手。
• 我要做个 API 给 App/网站用，怕人多崩 → vLLM，并发和吞吐给你兜底。
• 我在做 Agent / 要稳定 JSON / 多步推理 → SGLang，前缀缓存和结构约束省大钱。
• 我要做看图、语音、多模态应用 → vLLM-Omni，一套服务管所有模态。

进阶组合：Ollama 做开发调试 + vLLM/SGLang 做生产部署，是很多团队的真实链路——本地用 Ollama 快速验证，上线换 vLLM 扛量。

十、三个最容易踩的坑（看完能省三天调试）

坑一：拿 Ollama 硬扛并发。 现象：本地自己用挺丝滑，一开放给同学就卡死。Ollama 不是为并发设计的，正确做法是开发用 Ollama，上线换 vLLM。

坑二：忽视量化对精度的影响。 为了省显存无脑上 Q2/Q3，结果模型"变傻"。一般建议 Q4 起步、关键任务 Q8。精度换显存，要在测试结果上权衡，别拍脑袋。

坑三：生产环境不压测、不监控。 很多人本地 run 通了就直接上线，结果真实流量下延迟飙升、显存泄漏。上线前用真实并发压一轮，配上显存和延迟监控，是基本功。

十一、写在最后：为什么这件事和"找工作"有关

看到这你可能想：我就是个准备求职的学生，搞这么深干嘛？

恰恰相反——"本地部署怎么选型"几乎是 AI 应用岗面试的高频题。

面试官问这个，不是在考你背名字，而是在看三件事：

1. 你有没有工程思维：知道性能、成本、场景之间的权衡，而不是"哪个火用哪个"；
2. 你有没有真动手：Ollama 跑过、vLLM 起过服务、SGLang 写过结构化输出，和只看过文章，回答质感天差地别；
3. 你能不能把技术讲清楚：能把四个框架讲明白的人，沟通成本最低。

所以我的建议很直接：别只收藏，动手装一遍。 用 Ollama 跑通一个本地 Agent，再用 vLLM 把它变成能并发的 API，最后用 SGLang 给它加一个稳定的 JSON 输出——这一套走完，你的简历项目里"大模型工程化能力"就立住了。

最后划重点：

• 本地学习 / 单机 Agent → Ollama
• 高并发文本服务 → vLLM
• Agent / 结构化输出 → SGLang
• 多模态应用 → vLLM-Omni

别再瞎装了。选对框架，你的显卡和你的时间，都值得被好好对待。

觉得有用？点个赞+在看，转发给那个还在用 Ollama 硬扛并发的冤种同学。关注不迷路。

本文转载自微信公众号「反神经全栈」，仅供学习交流使用。