Ollama+open-webui+AnythingLLM 本地大模型私有化部署实战指南

本地跑大模型这件事，这两年已经不是极客专属了。只要有一台配置还过得去的电脑，就能把 Qwen、Llama、DeepSeek 这类开源大模型完整装进本机，数据不出机器、断网也能聊，还能把私人文档变成可问答的知识库。我平时折腾最多的就是 Ollama + open-webui + AnythingLLM 这套组合，Windows 和 Linux 两个系统都反复装过好几遍，中间踩的坑不少。这篇文章就把我的实际部署流程、选型思路、以及各种报错的排查方法一次性讲清楚，想在自己电脑上搭一套私有大模型环境的朋友，可以直接照着抄。

这套方案我最看重的点，是它把“跑模型”“聊天界面”“知识库问答”三件事彻底拆开了，各管一段，坏了好修，换也好换。下面我会从整体架构开始讲，再分别拆 Ollama、open-webui、AnythingLLM 的安装与配置，最后是高频问题的排查记录。

1. 选型思路：这套组合拳的定位与分工

很多第一次接触本地大模型的人，容易被一堆名词搞晕：Ollama 是啥，open-webui 是啥，AnythingLLM 又是啥？其实它们解决的是完全不同的问题，组合在一起才是完整方案。

先说我为什么不用“全家桶”式的一体化工具。市面上确实有一些一键整合包，下载下来什么都有，但升级难、出问题难排查、换模型也麻烦。而 Ollama + open-webui + AnythingLLM 每个工具只做一件事，做得足够深，而且都是目前社区里维护最活跃的开源项目，出了问题能搜到大量现成答案，这才是它最值钱的地方。

1.1 Ollama：负责把模型真正跑起来

Ollama 是整个链条的地基，本质是一个本地模型运行时。它解决的核心问题是“一个开源大模型从下载到能对话，到底要经历什么”。如果没有 Ollama，你得自己处理模型格式转换、显存调度、批量推理接口、上下文管理这些琐碎事情，光是让一个 7B 模型跑起来，就能耗掉一个晚上。

Ollama 把这些全部封装成了几条命令。你只需要ollama run qwen2.5:7b，它就会自动下载模型、加载进内存、给你一个命令行对话界面。它还提供一个默认跑在 11434 端口的 HTTP API，接口风格和 OpenAI 的 chat/completions 高度兼容，这意味着任何写好的 OpenAI API 客户端，只要改一下 base_url 就能接到本地 Ollama 上。

更关键的是，Ollama 内部做了很多性能优化。它支持 GPU 和 CPU 混合推理，显存不够的时候会自动把一部分层放到内存跑，虽然速度会下降，但至少不会直接崩溃。它还支持并发请求排队，多个人同时访问也不会把进程打崩。这些特性对后面的 open-webui 和 AnythingLLM 都至关重要，因为它们都是通过 API 来调模型的，底层必须有一个稳定可靠的运行时。

1.2 open-webui：补上图形化聊天界面

Ollama 自带的是终端对话，对普通用户来说太劝退了。open-webui 是一个纯前端的 Web 聊天界面，可以理解成“本地版的 ChatGPT 外壳”。它通过 API 连接 Ollama，提供一个在浏览器里访问的、带气泡对话框、支持多轮对话、能切换模型的界面。

open-webui 解决的痛点很明显。第一，它支持多模型管理，装了好几个模型之后，可以在界面上直接下拉切换，不用记命令。第二，它天然支持多用户注册，虽然本地自用一般不需要，但如果你想让整个办公室都在内网访问一套大模型服务，open-webui 的开箱即用注册登录功能就很省事。第三，它自带对话历史、收藏、附件上传、代码高亮这些细节，用起来真的和商业产品差不多。

很多人在问“有 Ollama 了为什么还要 open-webui”，答案就在体验上。命令行只能服务你自己，Web 界面才能服务一个团队，而且 open-webui 的 API 接口还能被其他程序调用，等于把交互层标准化了。

1.3 AnythingLLM：面向文档的知识库专用工具

AnythingLLM 和 open-webui 有明显分工。open-webui 强在“聊天”，AnythingLLM 强在“知识库问答”。它的核心功能是把 PDF、Word、TXT、Markdown 等文档切碎、向量化、存进本地向量数据库，然后在聊天时先检索相关内容，再把这些内容拼进提示词交给大模型，让模型基于你的私有文档回答问题。

这就是 RAG（检索增强生成）的落地实现。为什么需要单独一个工具来做？因为在纯聊天界面里，模型只能依靠它训练时学到的知识回答问题，这叫“参数记忆”。而 AnythingLLM 的文档问答，本质是“外部记忆”——先把你的资料库变成可搜索的向量索引，再在回答的瞬间把最相关的片段喂给模型。这样模型回答的不是它背过的东西，而是你的文档里写了什么。

AnythingLLM 还有一个优势是它对非技术用户友好。向量数据库、嵌入模型这些概念，在它界面里都被简化成了选项，你不需要懂原理，选一个模型、拖几个文件进去，点一下处理，就能开始问了。

1.4 三者配合逻辑与适用人群

这套组合的数据流是：AnythingLLM 或 open-webui 接收用户输入 → 调用 Ollama 的 API 让大模型生成回复 → 返回界面展示。如果用了知识库，AnythingLLM 会先检索相关文档片段，再在请求里附带给模型。

适合这套方案的人群非常明确：一是对数据隐私敏感的从业者，不愿意把公司文档或对话记录发给云端；二是开发者和运维，需要在本地验证开源模型效果，或者做二次开发的前期测试；三是学生和研究者，想在本地反复跑实验，又不想为每一次 API 调用付费。如果你只是偶尔跟 AI 聊两句，那确实用不着这么复杂，但如果你想要的是“一台电脑 = 私有 AI 工作台”，这套组合就是目前最稳的路。

2. 部署前的硬件评估与环境准备

先说一个残酷的现实：本地大模型对硬件的要求是真实存在的，但也没有想象中那么夸张。很多人被“大模型”三个字吓住，觉得没有几万块的显卡跑不了。实际上，模型能不能跑、跑得快不快，取决于模型参数量和量化精度，你可以选很小很轻的模型，也可以选大而全的模型，完全取决于你的机器。

2.1 显存和内存到底要多大

模型文件的实际大小，决定了下限。有个非常粗略的估算公式：模型文件大小约等于 参数量（B）× 每参数字节数。Q4 量化（4bit）大约每参数 0.55 字节，Q8 量化（8bit）大约每参数 1.06 字节。

举例来说，7B 模型用 Q4_K_M 量化，最终文件大约是 4.7GB；13B 的 Q4 大约 8.1GB；32B 的 Q4 大约 20GB。理论上，你的显存要能装下这个文件，才能把模型整体塞进显卡。显存不够时，Ollama 会退而求其次，把一部分层放到内存（RAM）里跑，这会导致速度大幅下降，但至少能跑。

我建议的最低配置门槛是这样的：

我的经验是：如果你只想要一个能日常聊天的模型，至少准备 16GB 内存+8GB 显存，跑 7B 或 8B 的量化模型体验是能接受的。如果你的内存只有 8GB，那就只适合跑 3B/4B 或者 1.5B 的小模型。另外提醒一句，浏览器、Docker 容器、AnythingLLM 这些都要占内存，别把内存卡得刚刚好。

2.2 Windows 与 Linux 的路径差异

两个系统我都深度用过，优缺点非常清楚。

Windows 的优势是安装门槛低。Ollama 有官方 exe 安装包，AnythingLLM 有桌面版安装包，点几下鼠标就能装好。open-webui 虽然推荐 Docker，但 Windows 上有 Docker Desktop，界面化配置也比命令行友好。对于刚入门的人来说，Windows 是更平滑的起点。

Linux 的优势是稳定和资源占用低。没有桌面环境吃资源，同样的硬件跑模型往往更快一点。Docker 在 Linux 上是原生支持的，不用像 Windows 那样通过 WSL2 中转一层，出问题的概率低很多。还有一个现实因素：很多人的主力开发机是 Linux，模型推理最终要部署到服务器上的话，直接在 Linux 上调试能少踩很多环境不一致的坑。

我的建议是：日常自用、学习体验，选 Windows；要做服务、长期跑任务、当测试环境，选 Linux。两个系统对应的部署步骤我会分别写，细节上有差别，但大体思路一致。

2.3 Docker 环境准备

open-webui 和 AnythingLLM 的 Docker 部署是主流方式，所以先把 Docker 准备好。

Windows 上，安装 Docker Desktop 前要先确认两件事：一是 CPU 虚拟化已经在 BIOS 里开启（Intel VT-x 或 AMD-V），二是 Windows 功能里启用了“适用于 Linux 的 Windows 子系统”（WSL2）。装好后在 PowerShell 里执行wsl --update把 WSL 内核更新到最新，否则 Docker Desktop 很容易在启动时卡在 WSL 更新这一步。

Linux 上，不同发行版安装命令不同。Debian/Ubuntu 可以用官方脚本安装：

curl -fsSL https://get.docker.com | sh sudo systemctl enable --now docker

CentOS/RHEL 系可以用 yum 安装 docker-ce，或者直接用发行版自带的 podman 代替 Docker，命令基本通用。装完验证一下：

sudo docker run hello-world

能正常打印提示信息，说明 Docker 环境没问题了。如果在国内网络环境下拉取 hello-world 也失败，那你后面大概率会遇到 open-webui 镜像拉不下来的问题，建议先解决镜像源的问题，具体方法我放到第 4 节细说。

3. Ollama 安装与模型管理全流程

Ollama 是整个方案的起点，我必须认真讲。我见过太多人在这一层就卡住了，而且卡住的点五花八门。

3.1 Windows 安装步骤与安装到 D 盘

Windows 安装相对无脑，去 ollama.com 官网下载安装包，文件名类似 OllamaSetup.exe，双击运行，一路 Next 就行。默认安装目录是 C 盘的用户目录下，模型默认也放在 C 盘。如果你 C 盘空间紧张，就需要手动迁移。

Ollama 在 Windows 上默认的模型存储路径是C:\Users\你的用户名\.ollama\models。想改到其他盘，要在系统环境变量里加一个OLLAMA_MODELS。操作路径是：右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 新建系统变量，变量名填OLLAMA_MODELS，变量值填你要存放的目录，比如D:\ollama\models。设置完之后，重启终端，重新执行拉模型命令。

有几个环境变量对后面特别重要：

改 OLLAMA_HOST 时需要特别注意：如果设成0.0.0.0:11434，局域网内任何机器都能访问你的模型服务，相当于把 API 裸奔在网上了。我建议只在可信内网里这样干，并且最好配上访问控制，否则任何人连上你的 11434 端口都能自由调用模型，这个隐患很多人一开始没意识到。

安装完成后，打开一个新的命令提示符或 PowerShell，执行：

ollama --version

能输出版本号说明安装成功。然后拉一个模型试试：

ollama run qwen2.5:7b

这条命令会自动从模型仓库下载 qwen2.5 的 7B 版（大约 4.7GB），下载完成后会进入交互式对话，输入问题回车就能得到回答。第一次跑可能等几秒到十几秒不等，因为要加载模型进内存，后面再对话就快了。

3.2 Linux 安装步骤与后台运行

Linux 安装 Ollama 的方式非常粗暴，官方提供了自动安装脚本：

curl -fsSL https://ollama.com/install.sh | sh

脚本会自动检测系统架构，下载对应版本，装到 /usr/local 下，还会创建一个 systemd 服务来自动管理进程。装完执行：

ollama --version systemctl status ollama

如果 systemd 服务已经在运行，说明后台服务已经起来了。这个和 Windows 有个重要区别：Linux 上你不需要手动ollama serve，服务是常驻后台的，开机自启。我用 systemd 管理最省心，日志查看也方便：

sudo journalctl -u ollama -f

如果网络环境导致安装脚本拉不下来，就需要手动装。去 GitHub Releases 里找ollama-linux-amd64.tgz或对应架构的包下载，然后解压到 /usr/local 并建立软链：

sudo mkdir -p /usr/local/lib/ollama sudo tar -C /usr/local/lib/ollama -xzf ollama-linux-amd64.tgz sudo ln -s /usr/local/lib/ollama/ollama /usr/local/bin/ollama ollama --version

手动装的没有 systemd 服务，要长期跑可以自己写一个 service 文件，把ollama serve交给 systemd 管理，或者干脆用一个 tmux/screen 会话挂在后台。稳妥起见，还是建议优先用官方脚本，省事。

Linux 下同样要注意模型存储路径，默认在~/.ollama/models，也就是 /root/.ollama/models（root 用户）或 /home/用户名/.ollama/models。如果你把系统盘和数据盘分开了，同样通过环境变量OLLAMA_MODELS指向大容量盘符。

3.3 模型下载太慢的几条出路

“ollama 下载太慢”是这个方案里出现频率最高的抱怨。我理解那种看着进度条半天不动的心情，但这里其实有几条务实的解决路径。

首先，Ollama 的 pull 命令内置断点续传，网络波动导致中断后，重新执行ollama pull 模型名会从断点继续，不会从头再来。所以遇到卡住，可以 Ctrl+C 中断，然后再 pull 一次，多数情况能续上。有人觉得这不靠谱，但我实测过多次，只要网络不是彻底断掉，断点续传的效率远高于反复重试。

其次，可以避开官方源，从第三方镜像站或 Hugging Face 下载 GGUF 格式的模型文件，然后用ollama create注册成本地模型。具体做法是：到一个能正常访问 Hugging Face 或有国内镜像服务的环境，找到你想要的模型的 GGUF 文件，比如qwen2.5-7b-instruct-q4_k_m.gguf，下载下来。然后在本地写一个 Modelfile：

FROM ./qwen2.5-7b-instruct-q4_k_m.gguf

把这个 Modelfile 和 GGUF 文件放在同一目录，执行：

ollama create qwen2.5-local -f Modelfile

之后你就能用qwen2.5-local这个名字来运行了。这个办法的好处是，你对模型来源完全可控，而且下载方式更加灵活，不局限于 Ollama 官方仓库。缺点是需要自己动手找合适的 GGUF 文件，对新手稍有一点门槛，但掌握了之后灵活性很高。

还有一个办法比较朴素：找一台网络条件好的机器，把模型拉好，然后把整个模型目录打包拷贝到目标机器。模型目录就是前面说的OLLAMA_MODELS指向的文件夹，里面按models/manifests和models/blobs分好了层级。把整个 models 目录拷到目标机的对应位置后，执行ollama list就能看到已经存在的模型。这个方法适合离线内网环境，或者多台机器复用同一套模型文件，省去每台机器各自下载的重复流量。

3.4 常用命令与模型目录结构

Ollama 的命令不多，但每个都很实用。我列一份我日常使用频率最高的命令清单：

ollama list # 查看本地已安装的模型列表 ollama pull 模型名 # 从仓库下载模型 ollama rm 模型名 # 删除本地模型 ollama show 模型名 # 查看模型详情（参数量、量化等级、上下文长度） ollama ps # 查看当前加载在内存里的模型 ollama serve # 手动启动服务（一般不需要，服务常驻）

模型目录结构也需要了解，尤其是你要做迁移或者清理磁盘的时候。以 Linux 为例，默认模型目录是~/.ollama/models，里面有两个核心子目录：manifests存放模型的元数据（名称、标签、对应的 blob 列表），blobs存放真正的模型权重文件，以哈希命名，没有扩展名。平时在界面里看到的模型列表，其实是 Ollama 根据 manifests 信息展示出来的；而占用磁盘空间的大头，全在 blobs 里。手动清理时不要乱删 blobs，通过ollama rm删除模型才能把 blob 正确回收。

我第一次看这个结构时也困惑过，后来明白了：这和 Git 的对象存储思路一样，blob 是内容寻址的，多个模型如果共享某些层，磁盘上也只存一份。理解了这点之后，迁移模型目录、手动备份、清理空间就都不慌了。

4. open-webui 部署实操

open-webui 是这套方案里最“漂亮”的一层。它跑起来之后，你就不需要面对黑漆漆的终端了。

4.1 Docker 方式安装与镜像拉取失败解析

open-webui 官方推荐的部署方式是 Docker，一条命令就能起服务：

docker run -d -p 3000:8080 \ -v open-webui:/app/backend/data \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main

这条命令里几个参数分开解释：-p 3000:8080把容器的 8080 端口映射到宿主机的 3000 端口，这样浏览器访问http://localhost:3000就能打开界面；-v open-webui:/app/backend/data是数据持久化，聊天记录和用户信息存在 Docker 卷里，容器删了重建数据也不丢；-e OLLAMA_BASE_URL告诉 open-webui 去哪个地址找 Ollama 服务。这里有个坑：容器内部看到的localhost是容器自己，不是宿主机，所以要用host.docker.internal这个特殊域名来指代宿主机。Windows 和 macOS 的 Docker Desktop 默认支持这个域名，Linux 上如果不支持，可以在运行命令里加一个参数手动映射：

--add-host=host.docker.internal:host-gateway

然后再执行 docker run。

在拉取镜像时，很多人会碰到这个经典报错：

unable to find image 'ghcr.io/open-webui/open-webui:main' locally

这个报错信息其实有两层意思：第一层，Docker 在本地镜像仓库里没找到这个镜像，这很正常，首次使用必然找不到；第二层是隐含的，Docker 尝试去远程拉取，但拉取失败了，所以最终只把“本地找不到”这句话抛出来了，真正的网络错误信息往往在更靠后的日志里。所以看到这行提示，先别慌，问题不是镜像名写错了，十有八九是网络连通性问题。

解决办法从易到难有几种。最简单的，给 Docker 配置 registry mirror。Docker 支持在 daemon.json 里配置镜像加速地址：

{ "registry-mirrors": ["https://你的可用加速地址"] }

Linux 上配置文件在/etc/docker/daemon.json，改完后执行sudo systemctl restart docker。Windows 上在 Docker Desktop 的 Settings → Docker Engine 里改同样的 JSON 配置，点 Apply & Restart 生效。需要注意，这类公共加速地址有失效的可能，不同地区的网络状况也不同，如果你所在网络环境连接 ghcr.io 不稳定，加速可能也不起作用，这时候就要用下面的办法。

更稳的办法是离线迁移。找一台网络环境好、能拉取到镜像的机器，执行：

docker pull ghcr.io/open-webui/open-webui:main docker save ghcr.io/open-webui/open-webui:main -o open-webui.tar

把 open-webui.tar 拷贝到目标机器上，然后：

docker load -i open-webui.tar

镜像进到本地后，再执行之前那段 docker run 命令就不会触发远程拉取了。这个方法也适用于其他任何 Docker 镜像，内网离线部署常用的就是这套思路。

4.2 非 Docker 方式（pip 安装）

如果你不想折腾 Docker，或者 Docker 本身在你的机器上就装不起来，open-webui 还提供 Python 包安装方式。前提是机器上有 Python 3.11 以上版本，并且有 pip。执行：

pip install open-webui open-webui serve

默认监听 8080 端口，浏览器访问http://localhost:8080。这种方式没有 Docker 隔离，依赖直接装在系统 Python 环境里，好处是简单直接，坏处是如果 Python 环境本身比较乱，容易出现依赖冲突。我建议做法是先建一个干净的虚拟环境：

python -m venv openwebui-env source openwebui-env/bin/activate # Windows 用 openwebui-env\Scripts\activate pip install open-webui open-webui serve

pip 方式同样需要让 open-webui 能找到 Ollama。如果 Ollama 跑在默认地址，open-webui 的配置里会自动探测本机的http://localhost:11434；如果 Ollama 不在本机，就需要在 open-webui 的设置里手动修改 Ollama 的 Base URL。

4.3 首次登录与基本配置

open-webui 启动完成后，第一次打开网页，需要注册一个账号。第一个注册的账号会自动成为管理员，这个身份很重要，后面的连接 Ollama、管理用户都在管理员设置里。

注册登录后，进入设置页面，找到“外部连接”或“Ollama”相关配置，填上 Ollama 的 Base URL。本机部署的话是http://localhost:11434，如果你是用 Docker 部署的 open-webui，并且容器和 Ollama 不在同一台机器，就填宿主机或那台机器的 IP。保存后，模型列表会自动刷新，Ollama 里已有的模型都会出现在界面上，点击就能开始对话。

open-webui 的界面里值得注意的功能有：顶部可以切换模型，左侧可以管理多会话，输入框支持上传文件做简单的上下文引用。它其实也内置了一个简易的 RAG 能力，可以把文件内容拼进对话，但说实话，专业的文档知识库问答还是交给 AnythingLLM 更合适，open-webui 更适合做纯粹的聊天入口。

5. AnythingLLM 部署与知识库搭建

AnythingLLM 在这套组合里负责的是“让大模型读你的文档”，这一步配置细节比前两个多，而且涉及嵌入模型和向量库的概念，我单独展开讲。

5.1 安装方式与离线包获取

AnythingLLM 有两个主流的形态：桌面版和 Docker 版。桌面版适合单机使用，Windows 用户直接下载 exe 安装包，Linux 用户下载 AppImage 或 deb 包。Docker 版适合服务器部署，但在 Windows 上我反而更建议桌面版，因为 AnythingLLM 的 Docker 部署涉及多个容器的编排，桌面版把这些复杂度全部藏起来了。

如果你是在内网环境，或者 GitHub 下载速度不理想，就需要提前拿到离线安装包。操作思路是：找一台能够正常访问 GitHub 的机器，打开 AnythingLLM 的 GitHub Releases 页面，在最新版本的 Assets 里找到对应系统的安装文件。Windows 一般是AnythingLLMDesktop.exe，Linux 是.AppImage或.deb。下完之后通过 U 盘、内网共享或其他文件传输方式拷贝到目标机器安装。

这里特别提醒一句：下载离线包时一定要选对架构。绝大多数 PC 是 x64 架构，选x64或通用版；如果是 ARM 设备（比如部分 Nas 或树莓派），就要选对应的arm64版本。选错了装不上或者运行直接闪退，这是很常见的新手问题。

5.2 接入 Ollama 模型

AnythingLLM 装好后，第一步是把大模型接进来。打开主界面，进入设置（Settings），找到“LLM 偏好设置”（LLM Preference），提供商选择 Ollama。

这里需要填两个关键信息：一是 Ollama 的 API 地址，默认是http://localhost:11434，如果你用的 Docker 版 AnythingLLM，这里的 localhost 也要改成host.docker.internal或宿主机实际 IP；二是选择模型，下拉列表里会显示 Ollama 里已有的模型，比如qwen2.5:7b。

填完只管保存，然后随便问一个问题，能正常回复就算接通了。我个人的建议是，如果只是测试链路，先用一个 1.5B 的小模型，回复速度快、门槛低，链路跑通之后再切换到 7B 或更大模型，避免一上来就等很久的模型加载时间，效果不好还容易误判为配置错误。

5.3 嵌入器选择：为什么推荐 bge-m3

很多人第一次接触 AnythingLLM 时，对“嵌入器”这个设置很困惑，不明白大模型之外为什么还要再选一个模型。这里我用一个类比解释：大模型负责“听懂问题并组织语言回答”，嵌入器负责“把文档里的文字变成一串数字向量”。文档被切成句子后，每一句都会被嵌入器转成一个向量，提问的时候，系统也把问题转成向量，然后去找最相近的文档片段。这个过程里，嵌入器的质量决定了“能不能搜索到最相关的内容”。

如果你的资料是纯中文或者中英混合，我很推荐选用 bge-m3 作为嵌入器。bge-m3 是 BAAI 开源的多语言嵌入模型，对中文的支持要明显好于 nomic-embed-text 这类英文为主的模型。它支持 100 种语言，上下文长度最长 8192 token，并且同时具备稠密检索、稀疏检索和多向量检索三种能力，在中文文档检索场景下效果稳定。

配置方式很简单：在 AnythingLLM 的设置里找到“Embedding Preference”（嵌入偏好设置），提供商选 Ollama，模型选bge-m3。首次使用时，AnythingLLM 会通过 Ollama 自动拉取这个嵌入模型，所以第一次处理文档时会等一小会，这是正常的。

如果你用 Ollama 单独拉一次，可以看到这个模型确实存在：

ollama pull bge-m3

这个模型文件相对较小，几百 MB 到一两个 GB 不等，比对话模型小很多，拉取速度也快。需要注意的是，嵌入模型和对话模型是两个独立的模型，不要试图把同一个 7B 对话模型既当对话模型又当嵌入器，硬件负担会大很多，效果也不好。

5.4 构建第一个本地知识库

在 AnythingLLM 里，文档问答是通过“工作区”（Workspace）来实现的。工作区可以理解为一个独立的“知识空间”，每个工作区可以绑定不同的文档集和不同的模型。

创建新工作区后，右侧会有一个上传文档的区域，支持 PDF、TXT、Markdown、DOCX、CSV 等常见格式。把文档拖进去，选择“移动到工作区”或“复制到工作区”，文档就会进入处理队列。AnythingLLM 会先把文档切成小的文本块，然后用你配置的嵌入器把这些文本块向量化，存进内置的向量数据库。

处理完成之后，在聊天时确保当前选中的是刚才的工作区，输入问题时，系统会自动搜索该工作区里最相关的文档片段，并把片段连同问题一起发给大模型。你会发现回答里引用了文档里的具体内容，而不只是干巴巴的泛泛而谈。

这里有一个使用上的小技巧：AnythingLLM 的聊天输入框旁边有个切换按钮，可以切换“Chat”和“Query”两种模式。Chat 模式会结合多轮对话的上下文来检索，适合连续追问；Query 模式每次只根据当前这个问题去检索，适合反复测试检索准确度。两种模式下效果差异挺明显，实际使用时可以按需切换。

文档处理还有一个隐藏的坑：如果你上传的文档本身是扫描件或图片型 PDF，AnythingLLM 默认没有 OCR 能力，向量化进去的全是空白文本，问答结果自然一塌糊涂。遇到这种情况，要么先把 PDF 转成可复制的文字版，要么给 AnythingLLM 配一个 OCR 工具，后者配置要复杂一些，新手先用前者就行。

6. 高频问题排查与经验总结

最后这部分是我最想写给新手看的。前面讲的是流程，这里是血泪。我把折腾过程中遇到的典型问题整理成了一张速查表，按“现象 → 可能原因 → 解决办法”的格式，你可以直接当手册用。

6.1 常见问题速查表

这张表不能覆盖所有问题，但覆盖了我遇到过的 90% 的常见故障。排查的顺序建议从底层向上：先确认 Ollama 能否正常运行、能否响应 API 请求，再排查 open-webui 和 AnythingLLM 到 Ollama 的连接，最后才看界面和文档的配置。按这个顺序排查，很少会走弯路。

6.2 几个我踩过的坑

第一个坑是环境变量改了没重启。我在 Windows 上设置好OLLAMA_MODELS后，直接在原来的终端窗口执行命令，发现模型还是下载到了 C 盘，折腾了半天才反应过来，环境变量要新开终端窗口才生效。这类问题不伤人，但极其消磨耐心。

第二个坑是 Docker 容器删除导致数据丢失。有一次我调试 open-webui 时，嫌容器名字不好看，直接docker rm -f open-webui然后把容器删了重建，结果聊天记录全丢了。后来查了文档才明白，数据在名为open-webui的卷里，容器删了卷还在，但那一次我用的是没有命名的匿名卷，容器一删，匿名卷也被清理了。从那以后，所有部署我都有意识地给卷起名字，删除容器前也养成了先备份的习惯。

第三个坑是模型加载的影响。我一开始用 7B 模型，每次对话都要等十几秒，还以为是部署坏了，后来发现这是模型第一次加载的正常时间，模型加载进内存后，后续响应就快了。了解了ollama ps的机制后，我习惯在批量对话前先手动触发一次模型加载，或者用一条最简单的问候语“热身”，之后体验会流畅很多。这个细节很小，但对日常使用的感知提升非常明显。

6.3 后续还能怎么玩

这套组合跑通之后，能做的事情远远不止聊天和文档问答。我目前在玩的方向有三个，你可以参考。

一是把 Ollama 接入更多工具。因为 Ollama 提供了 OpenAI 兼容 API，很多支持自定义 API 地址的应用（比如一些笔记软件、开发辅助插件、自动化脚本）都可以把模型指向本地 Ollama，实现完全本地化的 AI 功能，不再依赖云端。这个改造的成本极低，改一个 base_url 就能用。

二是配置局域网共享。把 Ollama 和 open-webui 的监听地址改成0.0.0.0，同一局域网内的电脑就能通过 IP 访问你的模型服务。办公室搭一套，全组人共用，显卡利用率高很多。但一定要记住前面强调的：内网裸奔有风险，建议只开在可信环境。

三是扩展知识库的规模。AnythingLLM 支持同时管理多个工作区，可以给不同项目建独立的知识库。我目前的一个项目做法是：把团队的技术文档、产品手册、历史决策记录分别做成不同的工作区，各自绑定对应模型和嵌入器，干活时按需切换，效率比在聊天软件里翻聊天记录高太多了。

最后再分享一个经验：别一上来就追求大模型。先把整条链路用最小配置跑通，再一步步升级模型和扩充知识库，这个顺序能帮你省掉大量排查问题的时间。本地大模型的乐趣就在于一切都可控，慢慢调、慢慢玩，你很快就会发现这套组合能做的事情比想象中多得多。