1. 先想清楚：为什么要在本地跑大模型

这几年“AI本地部署”被提得越来越频繁，差不多已经到了程序员茶余饭后必聊的程度。很多人一看到 Ollama、LM Studio、Dify 这些名字就跟着下载，结果装完发现要么跑不起来，要么跑起来了不知道自己该拿它做什么。我身边就有同事折腾了一个周末，最后停在“模型能聊天”这一步，然后就没了下文。

如果要给“AI本地部署”下个通俗定义，其实就一句话：把大语言模型（LLM）的推理过程，从云端 API 搬到你自己的电脑或服务器上，让模型的权重文件、上下文数据、生成结果全部只经过你手里的硬件。听起来很酷，但真正动手之前，得先想明白“为什么”。我自己的经验是，适合本地部署的场景大概有三类。

第一类是数据敏感场景。比如企业内部的合同、代码、客户资料，这些内容本身不适合发送到外部 API。本地部署之后，所有请求都在内网完成，至少在数据出域的环节上少了一个风险点。第二类是长期使用比较在意成本的情况。高频调用商业 API 的账单会很难看，尤其是做批量生成、批量总结、跑 Agent 循环时，token 消耗跟流水一样。本地部署虽然要买硬件、花电费，但跑熟了之后，边际成本确实更低。第三类是稳定性和自由度。没有网络依赖、不受 API 限流影响、可以随便换模型、可以改采样参数，这些对做技术研究和做产品原型的人来说，都是实打实的好处。

不过也要泼一盆冷水：本地部署不等于万能。它受显卡显存、内存带宽、供电散热的限制非常明显，7B 级别的模型在消费级显卡上表现尚可，70B 级别就需要多卡或量化方案了。所以这篇文章不是一个“无脑推荐”，而是一份从实际使用出发的横向对比，帮你判断“我这个需求到底该用哪一款”。适合读这篇文章的，是有一定动手能力、想把大模型真正落到本机的开发者、算法工程师、产品原型爱好者，以及所有对数据隐私有要求的人。

2. 7款热门工具大盘点：各自想吃哪碗饭

2.1 一句话定位速览表

先给一张速览表，把7款工具按“它本质上是什么东西”来分个类。很多人选错工具，是因为根本没搞清楚自己需要的是“模型运行器”还是“应用开发平台”。

工具	本质定位	最擅长的事	典型使用人群
Ollama	模型运行器/模型管理 CLI	快速拉起 Llama、Qwen、DeepSeek 等开源模型，提供 OpenAI 兼容 API	开发者、刚入门本地部署的用户
LM Studio	图形化桌面客户端	可视化下载、加载、测试模型，上手零门槛	没有编程经验、想用本地 AI 聊天或做实验的用户
Dify	LLM 应用开发平台	把模型接入知识库、工作流、Agent，快速做应用	产品经理、后端开发者、想做完整应用的人
AnythingLLM	私有知识库问答应用	本地文档导入 + 向量化 + 聊天问答的开箱方案	企业知识管理、个人资料库用户
OpenClaw	多智能体自动化框架	用自然语言指挥多个 AI 工具协作完成复杂任务	AI Agent 玩家、技术探索型用户
MinerU	文档解析/内容提取工具	把 PDF、扫描件转成结构化 Markdown，保障 RAG 质量	做资料库、RAG 管线、内容中台的人
vLLM	高性能推理引擎	高吞吐、高并发的模型推理服务，支持 PagedAttention	把模型做成在线服务、对性能有要求的工程师

这7款工具，不是同一个赛道的竞品，更多是“本地部署生态里的不同环节”。理解这一点，才能看明白后面的横向对比表。

2.2 选型前先搞懂三类“部署工具”

我发现很多人在本地部署时卡住，不是因为电脑不够好，而是脑子里没有分类概念。本地部署工具大致分三层。

最底层是“模型推理引擎”。它负责把模型权重加载进显存，处理输入输出，核心指标是吞吐量、显存占用、并发能力。Ollama 和 vLLM 都属于这一层，但二者取向完全不同：Ollama 追求的是“上手快、资源省”，vLLM 追求的是“性能高、并发强”。

中间层是“应用开发框架”。它在模型之上帮你封装好 API、数据库、知识库、流程编排、对话管理。Dify 属于这一类。使用它的人通常不只是“想聊天”，而是想搭一个具备工具调用、文档问答、工作流处理能力的产品。AnythingLLM 的位置更偏向“即插即用的知识库应用”，你可以不写代码就完成私有文档问答。

最上层是“专项工具”。它们不是通用的 LLM 平台，而是解决某个具体环节。比如 MinerU 解决的是文档解析，OpenClaw 解决的是多智能体编排。这类工具常常和其他部署方案搭配使用：MinerU 解析出干净文本，Dify 做向量化和检索，Ollama 负责模型推理，OpenClaw 调度整个流程。

所以我给所有准备入坑的人一个建议：先确定你要做的是“聊天”“应用”还是“流水线”，再选工具。要是目的都没定，看着哪个工具火就装哪个，大概率会踩坑。

3. 七款工具逐个拆解：我的真实使用感受

3.1 Ollama：轻量、快、省心，入门首选

Ollama 几乎已经成为本地大模型部署的代名词。我第一次接触它时，最大的感受是“没什么存在感”——安装完，几条命令就把模型拉下来跑起来了，整个流程顺到不像本地方案。

# 安装完成后，拉取一个 7B 量级的中文模型试试
ollama pull qwen2.5:7b

# 直接开启交互式对话
ollama run qwen2.5:7b

# 启动 API 服务，默认监听 11434 端口
ollama serve

它的设计思路非常符合“最小可用”原则：模型仓库统一管理、命令行工具极简、自带 OpenAI 兼容接口。你甚至可以用一行 Python 代码接进自己的脚本：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # 本地服务，随便填
)

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[{"role": "user", "content": "用一句话解释什么是 RAG"}]
)
print(resp.choices[0].message.content)

Ollama 在 Mac 和大多数 Linux 机器上表现都不错，尤其是 Apple Silicon 平台，它会自动利用 Metal 加速。我在 M 系列芯片上跑 7B 模型，生成速度能达到 20~30 token/s，体感非常流畅。

但它的短板也很明显。首先，并发能力弱，多个请求同时进来时，默认方案基本是排队处理，不适合高并发的在线服务。其次，参数控制相对有限，想深度调节采样器、做前缀缓存优化，就有点力不从心了。还有一点，Ollama 的模型仓库虽然覆盖广，但一些特殊模型需要用 Modelfile 手工封装，对新手来说又是一个隐藏门槛。

我的建议是：如果你刚开始接触本地部署，或者只是需要一个“能跑模型、能调 API”的轻量方案，直接选 Ollama 不会错。它不解决复杂应用问题，但它是你最容易跑起来的那个起点。

3.2 LM Studio：小白友好的图形化之选

LM Studio 是那种“宣传图看着漂亮，实际用起来也确实漂亮”的工具。它的定位非常清晰：不想打命令行、不想看英文文档、不想自己写代码的人，也可以通过图形界面完成模型下载、加载、对话。

我拿它帮一位做法律翻译的朋友装机，全过程就是“搜索模型 -> 点下载 -> 等进度条 -> 选择量化版本 -> 点加载 -> 开始聊天”。没有出现任何一步需要打开终端的操作，这对非技术用户来说非常友好。它还内置了“本地模型服务器”功能，可以启动一个兼容 OpenAI 的本地 API 服务，给后续接应用留了后路。

不过这种“好用”是有代价的。图形界面本身会占用一部分系统资源，虽然不多，但在低配机器上会放大卡顿感。另外，LM Studio 的模型下载和更新依赖它自己的接口，有些时候你会发现某个版本的模型在官网已经有了，但在 LM Studio 里搜不到，需要你手动下载后放到模型目录里。

它在性能上和 Ollama 没有本质差距，底层都是 llama.cpp 或者类似的原生推理框架，量化格式也基本通用。差别主要在交互方式和工程集成度上。如果你是完全不写代码的用户，或者你只是想在笔记本上跟模型聊聊天、做做实验，LM Studio 会比 Ollama 让你心情愉悦得多。

3.3 Dify：从模型到应用的“工作流工坊”

如果说 Ollama 解决了“模型怎么跑”，Dify 解决的就是“模型怎么用”。

Dify 是一个开源的 LLM 应用开发平台，它把模型接入、提示词编排、知识库管理、Agent、工作流、API 发布这些都做成了可视化操作。你在界面上拖一拖、点一点，就能把一个普通的模型调用变成“带知识库检索的问答机器人”或者“能查数据库、能算数据的 Agent 应用”。

我在实际项目里用 Dify 搭过一个内部文档助手。流程大概是这样：先把几百份 PDF 交给 MinerU 做解析，转成干净的 Markdown；然后通过 Dify 的知识库模块完成文档分段和向量化；最后接上 Ollama 提供的本地模型接口，把对话流程发布给团队使用。整个过程我没有写一行后端代码。

但 Dify 的上手曲线明显比前两款高。它不是一个“点开就能跑模型”的工具，而是一个“需要你理解应用架构”的平台。你要明白什么是 Embedding、什么是向量数据库、什么是上下文窗口、什么是工具调用，才能在 Dify 里做出靠谱的东西。初学者一上来容易把工作流节点拖得乱七八糟，最后调试到心态爆炸。

我的实操心得是：Dify 和 Ollama 是本地部署里非常有性价比的组合。Dify 通过 http://localhost:11434 接入 Ollama，然后在模型供应商里填好模型名称，就能完成对接。注意要提前在 Ollama 里拉好对应模型，因为 Dify 本身不会帮你下载权重。资源占用方面，Dify 推荐用 Docker 部署，默认会启动 Postgres、Redis、Weaviate 等依赖，吃内存比较厉害，至少给它 8G 内存才稳。

3.4 AnythingLLM：私有知识库问答的开箱方案

AnythingLLM 和 Dify 有一部分功能重叠，但它的切入角度更垂直：私有知识库问答。它主打的是“把文档丢进去，就能基于文档聊天”的完整体验。

我拿它做过一次个人资料归档测试，把自己写的几十篇技术笔记（主要是 Markdown 和 TXT 格式）扔进去，向量化完成后，问它“我今年写过哪些关于本地部署的文章”，回答得相当准确，来源引用也能直接定位到具体文档。这种“最小可用”的体验，是 Dify 比不了的——Dify 需要你手动配置知识库和模型，而 AnythingLLM 把默认路径给你铺好了。

AnythingLLM 的默认架构是：前端桌面应用或者 Web 端 + 本地向量库 + 你指定的 LLM 接口。你可以接 Ollama、LM Studio 也可以接 OpenAI 兼容 API。它的 Workspace（工作区）概念很实用，不同工作区可以绑定不同文档集和模型参数，适合一个人管理多个知识库。

但说实话，AnythingLLM 做轻量演示和团队小范围使用可以，真拿到生产环境还是单薄了一点。权限体系比较简单、并发能力有限、定制化空间不大。如果你想深度定制召回策略或者做复杂的多轮 Agent，还是需要回到 Dify 这类平台上去。它的价值在于“快”，从下载到能跑，通常半小时内就搞定。

3.5 OpenClaw：把多智能体跑在本地的探索者

OpenClaw 是这几款里最有“极客味”的一个。它不是一个聊天工具，而是一个能让多个 AI Agent 协作完成任务的自动化框架，强调用自然语言调度本地工具、插件和模型。

我第一次跑 OpenClaw 时有一种“在搭建一个小团队”的感觉：有个 Agent 负责查资料，有个 Agent 负责整理笔记，还有一个 Agent 负责调用代码解释器来算数。它们之间通过任务队列和消息传递来协作，而我做的只是用自然语言给它们下了一个总目标。这和 ChatGPT 里那种单轮对话式 Agent 有本质区别，更像是在本机起了一个异步多角色的自动化系统。

它的部署方式不算复杂，核心依赖是 Docker 和 Node.js 环境。配置文件中可以指定模型提供商，我直接把它接到了本地 Ollama 服务上。实测跑一些简单的“总结文档 + 生成周报”任务，效果还可以，但稳定性确实不如商业产品。多智能体在本地模型上跑，最大的问题是上下文管理，每个 Agent 都会占用上下文窗口，几个 Agent 一协作，7B 模型的小窗口很快就被塞满了。

如果你想追最新的 Agent 玩法，OpenClaw 值得一试，但没必要上来就用它承载核心业务。它的最佳定位是一个“探索工具”，用来理解多智能体协作的机制，以及本地模型在复杂任务链上的能力边界。跑完几个示例任务，你心里就对“本地 Agent 能做什么、不能做什么”有数了。

3.6 MinerU：文档解析，RAG 管线的第一道工序

很多人做 RAG（检索增强生成）时，把精力全放在向量库和模型上，结果效果不好，最后发现是文档解析环节出了问题。PDF 里的表格、多栏排版、扫描图片，如果不经过处理直接切割，喂给模型的知识库就是一团乱麻。这时候就需要 MinerU。

MinerU 是上海人工智能实验室开源的工具，专门做文档内容提取，能把 PDF 转成结构清晰的 Markdown，并识别标题、段落、表格、图片位置。我在搭建知识库时，被各种格式的 PDF 折磨过：有扫描版、有多栏、有加密的、有表格嵌套的，直接丢给向量库的效果惨不忍睹。后来用 MinerU 先统一处理一遍，再进 Dify 做切片和向量化，检索准确率肉眼可见地提升了一个档。

使用 MinerU 最简单的方式是通过命令行：

# 使用 GPU 加速解析
mineru -p input.pdf -o output_dir

# 指定设备类型，没有 GPU 时用 CPU 跑
mineru -p input.pdf -o output_dir --device cpu

需要注意，MinerU 对扫描版 PDF 的识别依赖 OCR 模型，第一次运行会自动下载相关模型权重。在国内网络环境下，模型下载偶尔会慢，可以考虑配置代理或手动下载放置到缓存目录。解析大体积 PDF 时，时间和内存消耗都不小，我处理一本 300 页的扫描版书籍时，耗时接近十几分钟，属于正常的“重活”。

不要低估这个工具在 RAG 生态里的价值。一个知识库系统效果好不好，30% 靠模型，30% 靠向量化策略，40% 靠源文档的解析质量。MinerU 就是那 40% 里的关键答案。

3.7 vLLM：生产级高性能推理引擎

如果前面的工具都偏向“易用”，vLLM 则完全站在另一边——“性能”。它由加州大学伯克利分校团队开源，核心创新是 PagedAttention（分页注意力机制），极大地减少了显存碎片，让高并发推理成为可能。每当有人问我“本地部署能不能支撑几十个人同时用”，我的第一反应就是 vLLM。

使用 vLLM 需要一定的 Python 基础。它不是一个开箱即用的桌面工具，而是让你在代码程序里加载模型、启动推理服务：

# 通过命令行启动一个兼容 OpenAI 的推理服务
vllm serve Qwen/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000

启动后，它会提供一个 http://localhost:8000/v1 接口，行为和 OpenAI API 几乎一样：

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="unused")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "你好"}]
)
print(resp.choices[0].message.content)

vLLM 的并发能力非常强，特别适合给团队内部提供统一的模型服务。在单张 RTX 4090 上，7B 量化模型支持几十路并发是完全可能的，这个量级 Ollama 根本做不到。不过，它的资源占用和部署复杂度也更高。它需要 Python 环境、CUDA 版本匹配、合理的启动参数，不像 Ollama 那样“装完就能跑”。显存不够大的机器，连量化模型加载都可能失败。

我的建议是：自己随便玩，优先 Ollama；要给一个团队或一个产品提供稳定推理服务，再考虑 vLLM。它的学习成本值得花，但没必要每个人都去啃一遍。

4. 横向对比：性能、易用性、资源占用、生态扩展

4.1 维度说明与评分标准

本地部署工具的对比，单纯比“跑得有多快”没有意义。因为工具定位不同，硬比性能反而失真。我更习惯从四个维度来看：

一是易用性，指一个完全没有背景知识的人，从零开始到跑通默认功能需要多久。Ollama 和 LM Studio 在这个维度明显领先。二是性能与并发，指模型推理速度、多请求处理能力，以及做正式服务时的稳定性。vLLM 是这里的天花板。三是资源占用，指工具本身的额外开销和它对显存、内存的利用效率。四是生态扩展，指能不能方便地接入 API、知识库、第三方应用，以及社区活跃度。Dify 和 Ollama 在生态上表现最好。

4.2 横向对比表

这张表里我给了自己用过一段时间后的主观评分，分数基于“我在普通消费级硬件（RTX 4070 / 32G 内存 / Win11 + WSL2）上的体验”，仅供参考。

工具	易用性	并发能力	资源占用	生态扩展	上手成本	推荐度（综合）
Ollama	9	4	低	8	极低	9
LM Studio	9	3	中	5	极低	8
Dify	5	6	高	9	中高	8
AnythingLLM	7	4	中	6	低	7
OpenClaw	4	3	中高	5	高	5
MinerU	6	2	高	6	中	7
vLLM	3	9	高	8	高	7

单看这张表，Ollama 好像无敌，但这完全是因为它把“简单”做到了极致。复杂场景下，它的“生态”主要停留在“能跑很多模型”，而不是“能构建复杂应用”。Dify 的推荐度紧随其后，就因为它解决的是 Ollama 解决不了的应用层问题。

4.3 按场景推荐：什么情况选哪款

根据用途来选的话，我的建议如下。

如果只是想在个人电脑上体验本地大模型，或者写脚本调用模型做自动化，选 Ollama。想在 Mac 或者 Windows 桌面上安安静静聊个天，不折腾命令，选 LM Studio。想做一个团队可用的知识库问答系统，选 AnythingLLM 做快速原型；如果希望这东西能长期迭代、支持更复杂的权限和流程，那直接上 Dify。如果手头有一批 PDF、扫描文档要变成结构化内容，交给 MinerU。如果要做多智能体实验，OpenClaw。如果本地模型将来要当成一个正式服务对外开放，那 vLLM 是绕不开的选项。

这几条路线并不矛盾。我自己的主力方案就是：MinerU 解析文档，Dify 做应用编排，Ollama 提供轻量推理，关键时刻再开 vLLM 顶高并发。工具之间是配合关系，不是替代关系。

5. 实战：用 Ollama 跑一个可用的本地大模型（附参数）

说了这么多对比，还是要落一次地。这一节我用 Ollama 为例，演示一个完整流程：从安装到通过 API 把模型接进自己的代码里。选 Ollama 的理由很简单，它是当前本地部署环境中“边际成本最低”的一环。

5.1 环境准备与安装

Ollama 官方支持 Windows、macOS、Linux。最简单的方式是去官网下载对应的安装包，装完在终端输入 ollama --version 验证。如果使用 Docker，也可以用一行命令起服务：

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

这里重点说一个很多人容易忽略的点： Ollama 的模型默认存储在系统盘的用户目录下 ，模型文件动辄几个 GB，系统盘空间不够时会请求失败。可以在运行 Ollama 之前设置环境变量 OLLAMA_MODELS 来指定模型存储路径。比如在 Linux 的 ~/.bashrc 里加一行：

export OLLAMA_MODELS=/data/ollama/models

这个动作能帮你避免“模型下载到一半空间不足”的尴尬。Windows 用户可以在系统环境变量里直接添加。我踩过这个坑，所以每次装新机器都会先设置模型目录，再去拉模型。

5.2 拉取模型、启动服务、验证调用

选模型时建议新手先从 7B 参数的量化版本开始，比如 qwen2.5:7b 或 llama3.1:8b ，这类模型在 8G 显存或 16G 内存的机器上都能流畅运行。拉取并启动：

# 拉取模型，默认是 q4_K_M 量化版本
ollama pull qwen2.5:7b

# 保持 ollama serve 在后台运行
# 如果之前没启动，可以先执行一次 ollama serve
ollama serve

确认服务正常，可以用 curl 快速验证：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:7b",
  "prompt": "你好，请简单介绍一下自己。"
}'

如果能看到流式返回的 JSON，说明本地服务已经跑通。之后用任何支持 OpenAI 兼容接口的客户端，把 base_url 指向 http://localhost:11434/v1 就能开始调用。

5.3 显存、内存、CPU 取舍的关键原则

本地部署的硬件矛盾，本质上是“模型大小”和“可用内存/显存”之间的矛盾。一个 7B 模型的 FP16 权重约 14GB，量化到 4bit 后约 4GB 左右。显存不足时，Ollama 会自动将部分层放到内存中，由 CPU 参与推理，但这会大幅降低生成速度。

我的经验是：生成速度的瓶颈主要看“内存带宽”，而不是看 CPU 主频。Apple Silicon 统一内存架构在这方面很有优势，所以 Mac 跑中小模型的表现并不输普通 Windows 游戏本。如果是 NVIDIA 显卡，优先保证显存足够装下整个量化模型；显存不够时再考虑 CPU+GPU 混合方案。真要在老机器上跑，就尽量选 3B、1.5B 的小模型，体验反而更好。

顺带再分享一个参数技巧：Ollama 可以通过设置环境变量 OLLAMA_NUM_PARALLEL 调整并行请求数，默认是 1，也就是同一时间只能处理一个请求。如果想多开几个会话，可以设成 4 试一下，但前提是内存足够。

export OLLAMA_NUM_PARALLEL=4

这个值不是越大越好，开多了上下文叠加，显存会快速爆满，对延迟的改善也很有限。自己试几个档位，找到一个“刚好不卡”的平衡点就好。

6. 常见问题与排查技巧实录

6.1 问题速查表

本地部署看起来简单，实操中翻车的地方却非常集中。我把这些年在各类机器上遇到的问题整理成了一张速查表，大部分情况下照着排查都能解决。

现象	可能原因	解决方案
模型下载到一半失败	网络波动或存储空间不足	设置 OLLAMA_MODELS 指向剩余空间大的磁盘，重试下载
加载模型时直接进程崩溃	显存不足，量化精度过高	换更低的量化版本，像 q4 换成 q3；或使用更小模型
生成速度极慢，每秒不到 5 token	CPU 参与推理，或上下文过长	换小模型、减少 num_ctx 、增加内存带宽更好的硬件
API 接口能通，但应用连不上	地址填错，或跨机器访问无监听	检查是否监听 0.0.0.0 ，跨机访问要设置 OLLAMA_HOST
Dify 接入 Ollama 后报模型不存在	Ollama 中没有拉取该模型	先在 Ollama 执行 ollama pull 模型名 ，Dify 里名称保持一致
MinerU 解析 PDF 时卡在 OCR	模型下载不完整或设备配置不对	重新下载 OCR 模型；确认 --device 参数与硬件一致
vLLM 启动提示 CUDA 版本不正确	PyTorch 与本地驱动不匹配	按官方文档安装与 CUDA 版本对应的 PyTorch 轮子
OpenClaw 内 Agent 频繁丢失上下文	模型上下文窗口太小	改用 32K 上下文的模型，或减少单次任务的子步骤数量

6.2 三个值得记住的排查思路

第一个思路：分清“模型问题”还是“工具问题”。当应用没反应时，先用 curl 直接调用模型接口。如果接口本身返回正常，问题就出在应用和模型的对接层，比如地址、模型名、API 格式或时间超时。大多数 Dify 和 AnythingLLM 接入失败都发生在这个环节。

第二个思路：观察资源占用要“看过程，而不是看峰值”。很多人在任务刚开始显存还没达到峰值时就以为跑不动，过早放弃。应该用 nvidia-smi -l 1 连续观察几秒，确认显存曲线和生成速度的关系，再决定要不要调低参数。

第三个思路：多关注日志，而不是凭感觉猜。Ollama 的日志会输出 GPU/CPU 层分配信息，vLLM 的日志会告诉你 KV Cache 占用多少显存，MinerU 的日志会标明当前在解析哪一页。遇到问题先看日志，很多时候答案就在最后几行里。

最后分享一点个人体会

这几款工具我用下来最大的感受是，本地部署真正难的从来不是“把模型跑起来”，而是“把方案选得足够合理”。Ollama 够简单，但它撑不起复杂应用；vLLM 够强，但普通人没必要上来就啃它。懂原理、熟悉每款工具的性格，再按自己的场景做组合，才是性价比最高的路径。

我自己现在的工作流已经固定了：写代码和跑实验用 Ollama，做团队应用用 Dify，处理文档用 MinerU，压力测试和高并发场景交给 vLLM。这个组合不是所有人通用，但它帮我踩过了大多数坑。如果你正准备入坑本地部署，不妨也先花一个下午把这篇文章里提到的工具各试一遍，感受一下它们各自的长短。试完之后，你大概率就知道哪些工具适合留在你的工具箱里了。