在 CentOS 7 上跑通离线大模型问答，最绕不开的问题就是“模型服务”和“知识库”这两件事怎么串起来。MaxKB 负责把文档喂给模型做检索增强问答，Ollama 负责在本地跑模型，两者一配，就变成了一套完全内网的智能小助手。这篇文章不聊概念，只讲我在某公司内网环境里从零部署的完整过程，包括踩过的坑和最后稳定运行的配置。
这套方案适合谁？适合企业内网、数据不能出域的私有化场景，也适合个人想在本地弄一个知识库问答机器人。需要说明的是，我这里的“离线”是指模型推理和知识库检索都不依赖外部 API，整个服务跑在局域网内。如果你只有一台 4 核 8G 的旧服务器，也能跑，只要模型选得合适。
1. 为什么是 MaxKB 加 Ollama：离线问答场景的选型逻辑
1.1 离线环境到底缺什么
很多人以为离线部署难在模型本身，其实真正麻烦的是生态。模型文件再大，拷进去一次就完了，但推理服务、向量检索、知识库管理、Web 界面这几层都要自己搭。单把模型跑起来只需要 Ollama 或者 llama.cpp，可要让业务人员直接在网页上提问、让回答能引用公司内部文档，就必须有一个上层应用。
MaxKB 解决的就是上层应用。它自带知识库管理、文档解析、向量检索、对话应用编排，还可以直接对接本地模型服务，不需要外网。Ollama 解决的是底层推理，它把模型下载、加载、量化、API 暴露都封装好了，省得自己写推理脚本。
1.2 这套组合怎么分工
我习惯用一句话概括：Ollama 是发动机，MaxKB 是整车。发动机决定能跑多快，整车决定司机和乘客怎么用。
具体到数据流上，用户先打开 MaxKB 的对话页面提问，MaxKB 会先做两件事：第一，去知识库里做向量检索，把相关的文档片段捞出来；第二，把问题和文档片段拼成一段上下文，发给 Ollama 的接口，让大模型根据这段上下文生成回答。整个过程中模型参数、温度、上下文长度都可以在 MaxKB 里配置，不需要写代码。
1.3 适合的场景和硬性前提
我这次部署是给某部门搭建内部运维知识问答，文档大概 200 份，以操作手册和故障记录为主。如果你也是类似的场景——企业内部知识库问答、离线环境下的文档助手、不想把数据交给云端 API——这套组合很合适。
硬性前提有两个：一是服务器能装 Docker，二是模型文件能拷进服务器。只要这两个满足，后面基本是水到渠成。至于 CUDA 显卡，有当然好，没有也能跑，只是模型要选小一点的量化版本。
2. CentOS 7 环境准备：一次把坑填平的步骤
2.1 系统检查与基础依赖
CentOS 7 系统本身很老，但作为服务器它足够稳。首先确认系统版本、内核和架构：
cat /etc/redhat-release uname -r uname -m我这边输出是 3.10.0 的内核，x86_64 架构，没问题。接着安装基础工具和编译依赖，虽然大部分组件走 Docker，但宿主机上还是需要一些工具来做网络排查和文件操作：
yum install -y net-tools vim wget curl tar lrzsz如果你发现 yum 安装软件报错，或者命令找不到，多半是镜像源的问题，接着看 2.2。
2.2 YUM 源失效的坑
这是 CentOS 7 部署最大的坑。CentOS 7 停止维护后，官方源默认指向的 mirrorlist 已经失效，直接 yum 装东西会报 404。需要把源切到 vault 归档源或者可用的国内镜像源。
操作核心就是把/etc/yum.repos.d/CentOS-Base.repo里的 mirrorlist 注释掉，baseurl 改为可用源。以 vault 源为例：
sed -i 's/mirrorlist=/#mirrorlist=/g' /etc/yum.repos.d/CentOS-Base.repo sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-Base.repo改完执行：
yum clean all yum makecache这一步做完，yum 就恢复正常了。我见过很多人在部署到一半卡在装 Docker 上，根因就是这个。
2.3 安装 Docker
MaxKB 官方推荐用 Docker 部署，Ollama 可以装成系统服务，也可以容器化。我建议宿主机直接装 Docker，后面两个组件都用容器管理，统一一些。
CentOS 7 装 Docker 建议使用 Docker CE 的稳定版本，注意 20.10.x 对 CentOS 7 兼容性最好，太新的版本反而可能因为内核太旧出现奇怪问题。安装方式：
yum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce docker-ce-cli containerd.io systemctl start docker systemctl enable docker如果仓库地址拉不动，可以换成国内镜像源，具体地址以你实际网络环境为准。装完验证：
docker version docker ps还需要确认 Docker 数据目录的空间，模型文件动辄几个 G，知识库索引也会越来越大。建议把 Docker 数据目录迁到数据盘，方法是在/etc/docker/daemon.json里写：
{ "data-root": "/data/docker", "registry-mirrors": ["https://你的镜像加速地址"] }然后重启 Docker。这一步是经验之谈，很多系统盘只有 20G 的服务器，跑一个 7B 模型加知识库索引就能把盘撑爆。
2.4 防火墙与端口规划
部署前先把要用的端口想好。Ollama 默认监听 11434，MaxKB 的 Web 服务我习惯用 8080。放行端口：
firewall-cmd --permanent --add-port=8080/tcp firewall-cmd --permanent --add-port=11434/tcp firewall-cmd --reload如果服务器前面还有安全组策略，也要记得把这两个端口放通。另外，内网环境下不要直接把 11434 暴露到公网，Ollama 本身没有太强的鉴权，一旦暴露，别人可以直接调用你的模型接口，成本会失控。这一点后面会细说。
3. 部署 Ollama 并准备离线模型
3.1 安装 Ollama
Ollama 支持直接以系统服务方式安装，一条命令：
curl -fsSL https://ollama.com/install.sh | sh如果服务器不能访问外网，就找一台能联网的机器下载安装脚本和 rpm 包，拷进去离线安装。不过更稳妥的方式是直接用 Docker 跑 Ollama 容器，镜像可以提前导入到内网。
我用的是 Docker 方式，便于统一管理，命令：
docker run -d \ --name ollama \ --restart=always \ -p 11434:11434 \ -v /data/ollama:/root/.ollama \ ollama/ollama:latest这里挂载/data/ollama作为模型存储目录，模型都存这里，以后重装容器不会丢。启动后验证：
curl http://127.0.0.1:11434正常会返回Ollama is running。
3.2 选择模型并按需拉取
模型选择是这次部署的关键决策。离线环境里模型不可能通过网络频繁调整，所以一开始就要选好。
我的建议是：有 N 卡且显存 ≥ 8G，选 7B~8B 级别的量化模型，比如 Qwen3 的 8B 量化版或 Llama3.1 8B；纯 CPU 机器，选 3B~4B 模型，推理速度能接受，回答质量也够用；如果显存有 24G+，可以上 14B 模型，效果会有明显提升。
我在这台服务器上用的是 7B 模型，首次在联网机器上执行拉取：
ollama pull qwen2.5:7b拉取完成后可以通过ollama list查看本地已有的模型。
3.3 离线迁移模型的完整操作
这是本次部署里最实用的一段。Ollama 的模型文件都存放在模型目录下，以容器方式运行的话，就是挂载的/data/ollama目录。
在联网机器上确认模型位置，然后打包：
# 找到模型目录，默认是 ~/.ollama/models tar -czf ollama-models.tar.gz ~/.ollama/models把打包文件传到离线服务器的/data/ollama下，解压：
mkdir -p /data/ollama/models tar -xzf ollama-models.tar.gz -C /data/ollama/models --strip-components=3这里的--strip-components参数要根据打包路径的层级调整。解压完重启 Ollama 容器：
docker restart ollama再用ollama list（进容器执行）确认模型是否被识别。这一步我当初折腾了两轮才搞清楚路径层级，建议解压前先用tar -tzf看一眼结构，避免解压到错误层级。
3.4 验证模型接口
模型就绪后，用最直接的 API 测试验证：
curl http://127.0.0.1:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "你好，请简单介绍一下你自己", "stream": false }'返回里能看到response字段和total_duration之类的统计，说明服务正常。这里有个疏漏提醒：如果 Ollama 跑在容器里，127.0.0.1在容器内和宿主机上是不同的概念；宿主机的 11434 端口映射到容器后，用127.0.0.1:11434访问是可以的，但如果 MaxKB 也容器化，它访问 Ollama 时就不能用127.0.0.1，而要用宿主机内网 IP 或 Docker 网络别名。这个坑后面还会遇到。
4. 部署 MaxKB
4.1 镜像获取与导入
MaxKB 官方提供 Docker 镜像，联网环境下直接拉取：
docker pull registry.cn-hangzhou.aliyuncs.com/maxkb/maxkb:latest这里用的是阿里云镜像仓库地址，如果你在海外或拉取慢，可以自行查找可用的镜像源。离线环境则需要先在一台联网机器上拉下来，然后导出 tar 包：
docker save -o maxkb.tar registry.cn-hangzhou.aliyuncs.com/maxkb/maxkb:latest把 tar 包拷到离线服务器上导入：
docker load -i maxkb.tar4.2 启动容器
我用的是单容器模式，默认自带 PostgreSQL 数据库和向量库，适合中小规模知识库。启动命令：
docker run -d \ --name maxkb \ --restart=always \ -p 8080:8080 \ -v /data/maxkb:/var/lib/postgresql/data \ -v /data/maxkb/upload:/opt/maxkb/upload \ registry.cn-hangzhou.aliyuncs.com/maxkb/maxkb:latest等待几十秒，容器初始化完成后访问http://服务器IP:8080，首次进入会让你创建管理员账号。这里我提醒一句：管理员密码一定要记牢，MaxKB 目前没有简单的密码找回机制，忘了会比较麻烦。
4.3 基础配置检查
登录后先别急着建知识库，打开“系统管理”检查一下基础设置。主要看三点：
- 模型供应商是否为空（这一步在下一章配置）
- 系统语言和时区是否正确
- 如果有 HTTPS 证书要挂，提前把域名和证书准备好
MaxKB 的管理界面比较清爽，左侧菜单有“模型供应商”“知识库”“应用”“系统管理”几个模块，逻辑很清楚。
5. 配置模型接入并建立第一个知识库助手
5.1 添加 Ollama 模型供应商
进入“模型供应商”页面，选择 Ollama。填两个关键信息：
- API 地址：填写
http://服务器内网IP:11434，注意不要写成127.0.0.1，因为 MaxKB 也跑在容器里，容器内访问宿主机的 127.0.0.1 是不通的。 - 模型名称：填写 Ollama 里已有的模型名，比如
qwen2.5:7b。
填完后点“校验”，如果提示连接成功，就能在模型列表里看到该模型了。校验失败最常见的原因就是地址写错或者防火墙没放行 11434 端口。
5.2 创建知识库并上传文档
知识库是 MaxKB 的核心。进入“知识库”页面，新建一个，比如“内部运维知识库”，然后上传文档。格式支持 PDF、Word、Markdown、TXT 等，我这次主要是 PDF。
MaxKB 会自动做文档切片、向量化。向量模型方面，MaxKB 内置了本地向量模型，不需要额外接 Ollama 的 embedding 模型，这一点对离线部署非常友好。切片参数我用的是默认值，如果你的文档段落很长，可以适当调大切片重叠，保证检索召回率。
上传完成后，在文档列表能看到切片状态，全部完成后可以点“测试”按钮输入一个问题，看检索效果。这一步很重要，能提前发现切片和向量化的问题，而不是等到应用建完才发现回答质量差。
5.3 创建应用并实现问答
进入“应用”页面，新建一个“对话型应用”。核心配置就是两步：
- 绑定模型：选刚才添加的 Ollama 模型
- 关联知识库：选刚建的运维知识库
在应用的高级设置里，有几个参数值得关注：
- 检索模式：建议选“向量检索”，如果文档量大还可以开“混合检索”提高召回率
- 引用标注：开启后，回答下方会显示引用了哪些文档片段，方便溯源
- 系统提示词：可以写“请基于知识库内容回答，不要编造”
配置保存后，点“预览”就能进入对话界面测试了。我第一天部署完，测试问题是“如何排查服务超时问题”，回答直接引用了知识库里的故障处理手册原文，效果比预期好。
5.4 打通知明一个容易被忽略的点
如果回答里没有引用知识库内容，或者明显在胡编，先检查应用是否真的关联了知识库，以及知识库是否正确启用。MaxKB 的应用在未启用“问题优化”功能时，模型会基于知识库内容回答；启用后，模型还会先对用户的问题进行改写，效果更好但推理开销更大。内网环境如果机器性能一般，建议先用默认不优化的模式。
6. 部署中的常见问题与排查链路
6.1 容器启动报错或初始化失败
最常见的是端口冲突或数据目录权限问题。先用docker logs看日志：
docker logs maxkb --tail 200如果有 PostgreSQL 初始化失败的报错，大概率是挂载目录权限有问题，执行chmod -R 755 /data/maxkb后重启容器即可。
6.2 模型生成速度极慢
纯 CPU 跑 7B 模型，生成速度可能只有每秒几个 token，这是正常的，不代表部署有问题。对策是换更小的模型，比如 3B 或 1.5B；或者开启 Ollama 的并发参数，但多请求同时进来会互相抢资源，体验反而更差。我最终在这台 CPU 机器上换成了 4B 模型，速度明显改善，回答质量损失不大。
6.3 知识库检索不到内容
如果你的问题明明在文档里有，但回答却说“未找到相关资料”，依次排查：
- 确认知识库文档切片已完成，没有处于“解析中”状态
- 在知识库里用同一个问题做检索测试，如果返回为空，说明切片方式有问题，调整切片长度后重新导入
- 确认应用关联的是对的知识库
还有一个很隐蔽的坑：上传的 PDF 如果是纯图片扫描件，没有 OCR 层，MaxKB 解析出来可能是空的。这时候需要先对 PDF 做文字识别，或者在文档里附带文本版本。
6.4 Ollama 模型在 MaxKB 里校验失败
这个问题几乎都是网络地址问题。重申一遍：MaxKB 容器里不能直接访问宿主机的127.0.0.1:11434，应该填http://宿主机内网IP:11434。如果还是不通，进 MaxKB 容器内测试网络：
docker exec -it maxkb curl http://宿主机内网IP:11434如果容器里没有 curl，可以先apt-get update && apt-get install -y curl，Debian 系的 MaxKB 容器一般能装上。这步排查能快速定位是网络不通还是 Ollama 服务本身有问题。
6.5 系统盘空间不足
模型文件加 Docker 镜像加知识库索引，随便都是 10G 以上。部署前一定要把/data等数据目录放到有足够空间的挂载盘上，否则跑几个月后容器会异常退出。检查空间：
df -h /data我见过最惨的情况就是系统盘 30G，部署完没问题，跑了半个月知识库索引涨到 20G，容器直接挂掉，排查了一下午才发现是磁盘满了。
7. 收尾：把这套小助手真正用起来的经验
7.1 资源规划建议
根据这次部署的经验，我给一个配置参考：
- 纯 CPU、追求可用的最低配置：4 核 8G，跑 3B~4B 量化模型，单用户使用没问题
- 推荐配置：8 核 16G + 8G 显存 N 卡，跑 7B~8B 模型，3~5 人同时使用体验较好
- 团队使用：16 核 32G + 24G 显存，跑 14B 模型，知识库达到数千份文档无压力
如果多人并发使用，模型本身是串行推理的瓶颈。Ollama 默认会串行处理请求，想支持并发需要调整OLLAMA_NUM_PARALLEL环境变量，但如果显存不够，强行并发会导致缓存溢出，回答质量下降。
7.2 维护技巧：定期备份与安全
知识库是这套系统里最值钱的东西。备份只需要备份两个目录：Ollama 模型目录和 MaxKB 数据目录。
tar -czf maxkb-backup-$(date +%F).tar.gz /data/maxkb /data/ollama建议每周做一次。另外，Ollama 的 11434 端口一定不要暴露到公网，MaxKB 的 8080 端口如果允许，也建议只对办公网开放，或者套一层简单的登录认证。
7.3 我实际使用中的一点体会
这套系统跑起来之后，最大的价值不是那几句智能问答，而是把散落在各种文档里的知识变成了可检索、可追问、可溯源的统一入口。团队里新来的同事遇到问题，第一反应不是翻聊天记录，而是上小助手问一句，效率提升非常明显。
如果后续文档量涨到几千份，可以考虑把 MaxKB 的默认 PostgreSQL 数据卷迁移到外部数据库，同时升级内存和显存。扩展方向还可以接企业微信或钉钉的机器人，把问答能力直接变成内部通讯工具里的一个入口，那又是另一套玩法了。
