适用读者：想在自己机器/内网跑模型的人；要把"本地跑"接到业务里的人。
前置：S23-J01（推理指标与显存预算）、S23-J02（量化）、S15-J04（Docker 基础）。
覆盖旧文：4356（如何在本地自托管 AI：Ollama、Open WebUI 完全指南（2026），17,126 字符）。
扩展点：E-S23-013（Ollama 的定位：单机易用 vs 高并发不足）、E-S23-014（显存/内存估算与量化格式取舍）、E-S23-015（Open WebUI 的边界：是控制台不是生产网关）。
下一篇：S23 系列验收（v3）。
1. 一句话结论
Ollama 是"单机推理的开箱即用工具"，不是"生产推理网关"：它把拉模型、跑模型、暴露 HTTP 三件事做成一条命令，但在并发吞吐、批处理、多副本调度上远不如 vLLM/SGLang。判据：个人与内网验证用 Ollama；对外服务、要高并发与批处理，用 vLLM 一类引擎。 Open WebUI 的价值是"图形界面 + 多模型管理 + 权限"，它不能替代网关的鉴权、限流与审计。
出处：
A-4356。
2. 最小可运行（命令 + 预期）
# 环境：Linux / macOS，Docker 24+；或直接安装 ollama（0.3+ 版本口径）
docker run -d --name ollama -p 11434:11434 -v ollama:/root/.ollama ollama/ollama:latest
ollama pull qwen2.5:7b-instruct-q4_K_M # 拉取量化权重（约 4.7 GB）
ollama list # 预期：NAME/ID/SIZE 三列，无报错即成功
ollama run qwen2.5:7b-instruct-q4_K_M "用一句话解释什么是 KV Cache"
# 预期：流式输出一句话答案；首 token 约 0.3~2 s（取决于显存与是否首次加载）
HTTP 接口（OpenAI 兼容路径在 /v1）：
curl -s http://localhost:11434/api/generate -d '{
"model": "qwen2.5:7b-instruct-q4_K_M",
"prompt": "你好，请用三行说明 Ollama 是什么",
"stream": false
}' | head -c 300
# 预期：返回 JSON，含 "response" 与 "eval_count"、"eval_duration" 等统计字段
curl -s http://localhost:11434/v1/chat/completions -H 'Content-Type: application/json' -d '{
"model": "qwen2.5:7b-instruct-q4_K_M",
"messages": [{"role":"user","content":"hi"}]
}' | head -c 200
# 预期：OpenAI 格式响应，可直接被现有 SDK 复用
判据："能跑通"的标志是 /v1/chat/completions 返回 OpenAI 兼容结构——这样上层代码不用改（同 S22-B01 的统一调用层）。
3. 显存与量化：先算再拉（E-S23-014）
权重显存 ≈ 参数量 × 每参字节数
FP16 = 2 B/参数 → 7B ≈ 14 GB
INT8 ≈ 1 B/参数 → 7B ≈ 7 GB
Q4_K_M ≈ 0.55 B/参数 → 7B ≈ 4 GB（质量损失小，最常用）
KV Cache ≈ 2 × 层数 × 头数 × 头维 × 序列长 × 每元素字节 × 并发数
→ 长上下文与高并发时，KV Cache 可能超过权重本身
| 显存 | 可跑（Q4） | 说明 |
|---|---|---|
| 8 GB | 7B（4K 上下文） | 常见笔记本独显 |
| 16 GB | 13B / 7B 长上下文 | 上下文越长，KV 越吃 |
| 24 GB | 32B（Q4）或 13B 高并发 | 单卡 4090 档 |
| 仅 CPU | 7B 可用但慢（数 token/s） | 内存需 ≥ 权重 1.2 倍 |
判据："先按 Q4 算权重，再按上下文算 KV，最后留 20% 余量"——直接拉最大模型，多半 OOM 或疯狂换页。
量化格式取舍（GGUF）：Q4_K_M 是默认平衡点；Q5_K_M 质量更好、显存 +15%；Q8 接近 FP16 但收益递减。判据："Q4 与 Q8 的差别，通常小于换更大模型的差别"。
4. Open WebUI：控制台，不是网关（E-S23-015）
docker run -d --name open-webui -p 3000:8080 \
-e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
-v openwebui:/app/backend/data --add-host=host.docker.internal:host-gateway \
ghcr.io/open-webui/open-webui:main
# 预期：浏览器打开 http://localhost:3000，注册首个账号（即管理员）
| 能力 | 有 | 说明 |
|---|---|---|
| 多模型切换、对话历史 | ✅ | 本地存储（SQLite/Postgres） |
| 用户与角色 | ✅ | 适合小团队 |
| RAG（上传文档） | ✅ | 内置向量库，规模有限 |
| 工具/函数调用 | ✅ | 通过配置接入 |
| 高并发网关、限流、审计 | ❌ | 需前置 nginx/网关（同 S26） |
| 模型副本调度/批处理 | ❌ | 需 vLLM 一类引擎 |
判据："控制台给的是体验，网关给的是治理"——把 Open WebUI 直接暴露公网，等于把管理后台公开（同 S15-X02 §4 的容器三件套判据）。
安全三条：
① 不暴露 11434 到公网（Ollama 默认无鉴权）
② 反向代理加鉴权 + TLS（S26 证书流程）
③ 数据卷定期备份（对话与知识库都在 /app/backend/data）
5. Ollama vs vLLM：选型表（E-S23-013）
| 维度 | Ollama | vLLM / SGLang |
|---|---|---|
| 上手成本 | 一条命令 | 需配置引擎与服务 |
| 并发吞吐 | 低（默认单请求串行化倾向） | 高（PagedAttention + 连续批处理） |
| 批处理/离线任务 | 不适合 | 强项 |
| 多卡/多副本调度 | 弱 | 需 K8s + 编排 |
| 量化格式 | GGUF（CPU/GPU 混合） | AWQ/GPTQ/FP8 |
| 适合 | 个人、内网验证、边缘设备 | 生产 API、规模化服务 |
判据："先用 Ollama 验证 prompt 与数据，再迁到 vLLM 做服务"——两阶段成本最低；反过来（先上 vLLM 调 prompt）会浪费大量工程时间。
6. 反例：八种"本地跑起来就出事"
| 做法 | 后果 |
|---|---|
| 11434 暴露公网 | 无鉴权，任何人都能跑你的卡 |
| 不设并发上限 | 一个批量脚本打满显存，所有人卡住 |
| 用 FP16 拉 7B 到 8 GB 卡 | OOM 或疯狂换页 |
| 上下文设 128K 但显存 8 GB | KV Cache 直接爆 |
| 把 Open WebUI 当生产网关 | 无审计、无限流 |
| 不做卷备份 | 对话与知识库丢失 |
| 用 Ollama 做离线批处理 | 吞吐极低，跑一夜 |
| 量化到 Q2 追省显存 | 质量断崖，答非所问 |
7. 自测
- Ollama 与 vLLM 的定位差别？迁移顺序应该怎样？
- 权重显存与 KV Cache 各怎么估？为什么留 20%？
- Q4_K_M 为什么是默认？何时升 Q5/Q8？
- Open WebUI 能做什么、不能做什么？
- 三条安全底线？
答案
- 单机易用 vs 高并发服务；先用 Ollama 验 prompt，再迁 vLLM。
- 参数量×每参字节；2×层×头×头维×序列×字节×并发；留余量防峰值。
- 质量/显存平衡点；需要更高质量且显存够时升 Q5。
- 体验与多模型管理；无网关级鉴权/限流/审计、无副本调度。
- 不暴露 11434、反代加鉴权与 TLS、数据卷备份。
8. 下一篇
S23 系列验收（v3） —— 教材 12 章 + 自托管补编后的整体验收。