本地大模型实践（一）：在内网搭建你的 AI 基础设施

当你所在的公司因为数据合规、安全策略或网络隔离而无法使用公网大模型时，AI 能力是不是就此止步了？答案是否定的。通过 Ollama、vLLM 和 Open WebUI 这三个开源工具的组合，你可以在内网搭建一套完整的本地 AI 基础设施——让团队在不联网的环境下，拥有不输公网体验的大模型推理能力。

一、先想清楚：为什么要自己跑大模型？

调用公网大模型的 API（OpenAI、Claude、通义千问等）确实方便，但很多场景下这条路走不通。不是技术问题，是现实约束：

第一，数据不出门。 金融、政务、医疗等行业有硬性的数据合规要求。你的代码、你的内部文档、你的业务数据不允许通过公网传输——哪怕只是作为 Prompt 发给 AI 也不行。这不是”觉得不安全”，是”法规不允许”。

第二，网络都没有。 涉密网、研发内网、军工环境——这些网络本身就是物理隔离的。别说 API 了，连 DNS 都解析不了。在这种环境里，AI 能力只能自建。

第三，成本可控。 公网 API 按 Token 计费，高频使用场景下月账单可能很吓人。而本地部署的边际成本接近于零——电费和显卡折旧而已。团队越大，这个差异越明显。

第四，能力可控。 你用的模型不会被服务商悄悄升级，不会突然改变行为，不会被限流。你自己决定什么时候换模型、什么时候微调、什么时候调整参数。

但自己跑大模型，不是装一个软件就完了的事。你需要搞清楚三个层次的问题：模型怎么跑起来（推理运行时）、性能怎么保障（生产级推理引擎）、以及怎么让别人也能用（交互界面）。这三件事，恰好对应了我们今天要聊的三个工具。

二、三件套各司其职

先给一个速览表，方便你对号入座：

工具	角色	核心价值	适用场景
Ollama	模型运行时	一条命令拉起一个模型，零配置	个人开发、快速体验、轻量部署
vLLM	生产级推理引擎	高吞吐、低延迟、显存高效	团队共享、API 服务化、高并发
Open WebUI	交互界面	ChatGPT 式的 Web 界面	让非技术人员也能用上大模型

这三个工具不是竞品，它们是互补的。Ollama 让你几分钟跑起来，vLLM 让你在团队场景下跑得好，Open WebUI 让所有人都能跑。

实际工作中，大多数团队的路径是这样的：先用 Ollama 把模型跑通、验证可用性，然后上 vLLM 做生产部署、对外提供 API 服务，最后挂上 Open WebUI 给团队日常使用。下面我们逐个来看。

三、Ollama：一键起跑的模型运行时

如果你只记住一句话，记住这句：Ollama 让跑大模型变得和 docker run 一样简单。

# 安装 Ollama（macOS / Linux）
curl -fsSL https://ollama.com/install.sh | sh

# 跑一个模型
ollama run llama3.2

就两步。不需要配 CUDA 版本，不需要手动下载模型权重，不需要写 Python 脚本。Ollama 帮你做了所有脏活。

第一次运行 ollama run 时，它会自动从模型仓库拉取模型文件（通常在 4GB 到几十 GB 之间）。下载完成后进入交互式对话，你就可以直接在终端里和模型聊天了。体验和 ChatGPT 的命令行版差不多。

Ollama 几个实用的操作：

# 查看本地已有的模型
ollama list

# 拉取特定模型（不进入对话）
ollama pull qwen2.5:14b

# 以 API 模式启动（暴露 HTTP 接口）
ollama serve

# 用 API 调用
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:14b",
  "prompt": "解释一下什么是 DevOps",
  "stream": false
}'

ollama serve 启动后暴露的 /api/generate 端点是兼容 OpenAI API 格式的。这意味着任何支持 OpenAI 兼容接口的工具，都可以无缝切换到 Ollama——只需要把 base_url 从 https://api.openai.com 改成 http://localhost:11434。

Ollama 的模型管理也很直观。官方的模型仓库里有上百个预量化模型，从 Llama、Qwen、Mistral 到 CodeGemma、DeepSeek-Coder，覆盖了通用对话和代码生成两大主流场景。模型标签里可以看到不同参数规模和量化等级的版本，比如 qwen2.5:7b、qwen2.5:14b 和 qwen2.5:32b。

但 Ollama 有一个明显的局限：并发能力弱。 它默认是单线程处理请求，当多个人同时调用时，后来的请求要排队。这就是为什么团队场景需要 vLLM。

四、vLLM：当”能用”不够，你需要”好用”

Ollama 适合你一个人玩。但当你的目标是让整个团队都通过 API 接入大模型时，你需要的是一个生产级的推理引擎。vLLM 就是干这个的。

vLLM 的核心能力用几个数字就能说明白：相比 HuggingFace Transformers 的默认推理，它的吞吐量可以提升 10 到 20 倍。这不是营销话术，是它做了一件关键的事情——PagedAttention。

传统的 Transformer 推理中，KV Cache（注意力机制的中间结果）是按请求分配的，每个请求独占一块显存。当一个请求生成的文本很长时，会预留一大块显存，即使大部分时间用不到。这导致显存碎片化，并发上不去。

vLLM 的 PagedAttention 借鉴了操作系统里的虚拟内存分页思想——把 KV Cache 切分成固定大小的块，按需分配、动态映射。这个改进让显存利用率大幅提升，同等硬件上并发数从个位数跃升到几十甚至上百。

# 安装 vLLM
pip install vllm

# 启动一个兼容 OpenAI API 的推理服务
vllm serve Qwen/Qwen2.5-14B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.9

启动后，vLLM 暴露的也是 OpenAI 兼容的 /v1/chat/completions 端点。你的应用程序不需要任何改动——把 OPENAI_API_BASE 指向 vLLM 的地址就行了。

vLLM 还有一些实用的生产特性：

连续批处理（Continuous Batching）：不等到一个 batch 里的所有请求都完成才处理下一个，而是动态插入新请求。推理过程不空转。
量化支持：支持 GPTQ、AWQ、FP8 等多种量化格式，降低显存占用。
多 GPU 推理：一块显卡装不下的大模型，自动拆分到多块显卡上跑。

什么时候该从 Ollama 换到 vLLM？一个简单的判断标准：当你发现 Ollama 的请求要排队等 5 秒以上，就该上 vLLM 了。 这个时间点通常对应团队人数超过 3 到 5 人，或者你打算把大模型作为某个应用的底层服务来调用。

五、Open WebUI：让大模型有一个好看的”门面”

命令行里和大模型聊天，你 OK，你的同事不一定 OK。一个产品经理、一个设计师、一个管理者——他们需要的是一个浏览器里打开的、像 ChatGPT 一样的界面。

Open WebUI 就是做这件事的。它可以对接 Ollama 的 API，也可以直接对接 OpenAI 兼容的 API（包括 vLLM）。部署方式也简单：

# Docker 部署，一行搞定
docker run -d -p 3000:8080 \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

打开浏览器访问 http://localhost:3000，你会看到一个几乎和 ChatGPT 一模一样的界面。对话记录自动保存，支持多轮对话，支持文件上传作为上下文，支持 Markdown 渲染和代码高亮。

但 Open WebUI 不只是个”皮肤”。它有几个团队场景下非常实用的功能：

多模型切换：在对话界面里可以随时切换底层模型。你可以同时接入一个通用对话模型（如 Qwen）和一个代码模型（如 DeepSeek-Coder），聊天时用前者，写代码时用后者。

多用户管理：支持注册和登录，管理员可以控制谁能使用哪些模型。不是所有人都需要最强的模型——给日常问答分配 7B 的模型，给代码生成分配 32B 的模型，合理调配资源。

文档 RAG：你可以上传团队的内部文档（技术方案、API 文档、运维手册），Open WebUI 会自动做向量化和检索。之后在对话中，模型就能引用这些文档来回答。这在”内网没有搜索引擎，文档散落各处”的场景下特别有用。

六、拼起来：一个团队的内网 AI 基础设施长什么样

三个工具单独看都很简单，拼在一起就不一样了。来看一个典型的团队部署拓扑：

┌──────────────────────────────────────────┐
│  用户浏览器 (Open WebUI :3000)             │
│  ┌─────────────────────────────────────┐ │
│  │ 对话界面 / 文档上传 / 多模型切换      │ │
│  └──────────────┬──────────────────────┘ │
└─────────────────┼────────────────────────┘
                  │ API 调用
┌─────────────────▼────────────────────────┐
│  vLLM 推理服务 (:8000)                     │
│  ┌─────────────────────────────────────┐ │
│  │ 模型: Qwen2.5-14B (通用)             │ │
│  │ 模型: DeepSeek-Coder-V2 (代码)       │ │
│  │ → 高并发 / 连续批处理 / 显存优化      │ │
│  └─────────────────────────────────────┘ │
└─────────────────┬────────────────────────┘
                  │ 运行在
┌─────────────────▼────────────────────────┐
│  GPU 服务器                               │
│  2× A100 或 4× RTX 4090                  │
└──────────────────────────────────────────┘

这个拓扑下，开发人员可以在 IDE 里通过 API 调用大模型做代码补全，产品经理可以在 Open WebUI 里让模型帮忙润色 PRD，运维同学可以让模型读着运维手册帮忙排障。所有人共享同一套底层推理服务，但各取所需。

部署顺序也很清晰：

先在 GPU 服务器上装 Ollama。用它快速拉模型、测试效果，确认”这个模型能用”。
再上 vLLM。把模型从 Ollama 迁到 vLLM，配置并发参数，开放 API 给团队。
最后挂 Open WebUI。对接 vLLM 的 API，开启多用户，上传内部文档。

七、先跑起来，但别抱太高期望

最后说一个务实建议。

很多团队在”要不要自建大模型”这个问题上犹豫很久。担心硬件不够好，担心模型不够强，担心维护成本高。于是迟迟不动手，AI 能力一直缺位。

我的建议是：先用一台闲置的 GPU 机器 + Ollama + Open WebUI 跑起来。 一块 RTX 3090 就能跑 7B 到 14B 参数的模型。

但要先说清楚能做什么、对硬件的要求是什么。

本地小模型在文档问答、文本摘要、格式转换、简单脚本生成这些任务上表现还不错，一块 RTX 3090 跑 7B 到 14B 的模型就能胜任。

但代码生成对模型能力的要求就高多了。就算顶尖的云端大模型写出来的代码也需要人工审查和修改，本地如果要达到接近公网大模型的代码生成水平，需要部署更大参数规模的模型（比如 70B 以上的 DeepSeek-V3 或 Qwen），这意味着需要多卡甚至多机部署，硬件投入和运维成本都会显著上升。大公司如果有充足的 GPU 预算，这个方向是可以走的——我们前面聊的 vLLM 本身就支持多 GPU 推理，在硬件到位的情况下，本地代码辅助的体验可以逼近公网水平。但对一般团队来说，需要仔细权衡投入产出比。

换句话说，跑起来之后你会发现两件事：一是轻量任务确实能用、有产出；二是重任务需要重投入，不是一块消费级显卡就能搞定的。这两件事提前知道了，比一直犹豫着不跑要好。

AI 能力不会从天而降，你得自己把它接进来。 而 Ollama、vLLM 和 Open WebUI 这三件套，就是目前成本最低、路径最短的接引方式。但接进来之后能发挥多大作用，取决于你有没有清楚认识到它的边界。

每天前进一小步，就是一个新的高度！