最近有朋友问我能不能在公司内网搭一套离线的大模型问答系统既要让文档不出内网又要能回答内部资料的问题。我给的方案很直接DeepSeek 模型 Ollama 本地部署再套一层知识库RAG顺手把遇到的 3 个高频报错整理成速查笔记。这套组合已经跑通好几次了对个人开发者、小团队、甚至企业私有化探索都有参考价值。这篇文章把选型思路、完整操作、报错排查全部摊开讲尽量让零基础的人也能照着做出来。1. 本地部署方案怎么选为什么是 Ollama1.1 三条主流的本地部署路线先排掉不合适的开源大模型的本地部署工具这半年其实已经收敛成几个流派。第一种是直接用 transformers 库加 PyTorch 加载模型。这种方式最灵活想干什么都能自己写但显存开销很大推理代码、并发请求、参数调优全要自己动手适合做学术研究和模型调试不适合直接拿来当业务后端跑。你想想光是把模型从 Hugging Face 格式加载进来再写一套服务化接口就得折腾一整天后面还要处理请求排队、热加载、模型卸载工程量瞬间膨胀。第二种是 vLLM面向线上推理服务吞吐量高支持动态批处理和 KV Cache 复用是正经做推理集群的选择。但它的配置门槛同样很高光是把调度策略、张量并行、流水线并行这些概念理清楚就需要足够的底层背景。如果你手上有三四张专业显卡想给团队提供一个大模型推理服务vLLM 很合适如果只有一台电脑、一张消费级显卡用它纯属自找麻烦。第三种是 llama.cpp 以及基于它封装的项目。这类方案的优点是资源占用小CPU 上也能跑但模型文件管理、API 暴露、后端集成全部要自己动手对非底层玩家不太友好。所以我的结论很明确单机本地部署首选 Ollama。它把 llama.cpp 的底层推理能力封装成一个类似包管理器的工具一条命令就能把模型下载到本地一条命令就能起服务还直接暴露一个 OpenAI 兼容的 API 端口。模型之间切换也只是改一个名字的事这种“傻瓜化”恰恰是知识库场景最需要的省掉自建推理服务的时间把精力全部留在 RAG 链路调优上。1.2 知识库场景为什么格外吃这套组合知识库项目最怕什么最怕数据出境。企业内部的制度文件、产品手册、售后知识、竞品分析这些内容不该随便发给公有云 API本地化部署的核心目的就是让数据留在自己手里。Ollama 在这个场景里表现得像一座桥本地模型替你做问答知识库系统把私有文档片段检索出来拼成提示词发给模型整个链路不经过任何第三方服务。加上它给的是 OpenAI 兼容接口无论是 Dify、MaxKB、AnythingLLM 还是自己写 Python 脚本都能直接用不用做特殊适配。当然也要说清楚边界。Ollama 毕竟是单机部署做不到多机分布式模型能力上限受硬件约束。我经常跟朋友强调这套方案适合的是“私有数据检索 强约束问答”不适合拿 7B 量化模型去挑战满血版 DeepSeek 的推理能力。想清楚这个预期后面调起来心态会稳很多。2. 动手前先搞清楚硬件底线和模型选型2.1 DeepSeek 各尺寸模型所需的硬件底线DeepSeek 在 Ollama 上最常见的是 deepseek-r1 系列有 1.5b、7b、8b、14b、32b、70b 几个版本其中 7b、14b、32b 是 Qwen 蒸馏版。这里必须先做一个量化概念普及默认拉下来的模型大多是 Q4 量化版意思就是把每个权重压缩到 4bit 精度模型体积和显存要求大幅下降而日常问答的推理质量损失不明显。我整理了一张参考表按“能跑”和“跑得舒服”两级标准给数据模型 Tag量化后体积能跑的最低配置跑得舒服的配置deepseek-r1:1.5b约 1.1GB8GB 内存纯 CPU 可跑集显都能带deepseek-r1:7b约 4.7GB16GB 内存 8GB 显存12GB 显存deepseek-r1:14b约 9.0GB32GB 内存 12GB 显存16GB 显存deepseek-r1:32b约 20GB48GB 内存 24GB 显存32GB 显存deepseek-r1:70b约 42GB64GB 内存 48GB 显存双卡起步这套数据是我实测几个常见配置后得出的经验值不是官方指标。要注意的是纯 CPU 跑 7b 不是不行但生成速度会掉到每秒几个 token体验很像早期拨号上网。所以我的底线建议是有 NVIDIA 显卡优先用显卡显存不够就让 Ollama 自动把部分层卸载到 CPU 跑速度差点但至少能出结果。2.2 模型选型建议不同显存跑不同模型如果你只有 8GB 显存直接用 deepseek-r1:7b这是性价比最高的组合。8GB 显存跑 Q4 量化 7B 模型权重约占 4.7GB剩余空间留给 KV Cache 和对话上下文足够处理知识库问答场景。如果你的显存来到 12GB可以上 deepseek-r1:14b中文理解能力和逻辑推理明显上一档尤其在长文档多跳问答里14b 对关键信息的定位更准。24GB 显存则可以尝试 32b但推理速度会明显变慢需要配合 OLLAMA_NUM_PARALLEL 这类参数控制并发。再往下就是 70b单卡基本带不动除非你有双卡或大显存服务器。我一般不推荐普通用户为了跑 70b 去折腾多卡配置因为在 RAG 场景里14b 已经能覆盖大部分“查文档、做总结、答细节”的需求追大模型不如调好检索链路更实在。3. 知识库的本质RAG 架构与三轮方案选型3.1 RAG 是怎么工作的把“文件柜”藏进提示词知识库的技术底座是 RAGRetrieval-Augmented Generation中文叫检索增强生成。你可以把它理解成给模型配了一个文件柜。传统的问答是直接问模型模型凭“记忆”回答容易编造细节。RAG 则多了一道工序提前把文档切开转成向量存进向量库用户提问时系统先把问题也转成向量在库里做相似度检索找出最相关的几段内容然后把这些内容拼进提示词里再让模型基于这些材料组织回答。模型不再凭空乱说而是“查过资料再答”并且能标注引用来源。这套流程涉及几个关键组件文档解析与分块PDF、Word、Markdown 等格式统一转文本再按固定长度切片切片之间留重叠区域嵌入模型把文本映射成高维向量Ollama 上常用的有 nomic-embed-text 和 bge-m3向量数据库存储向量并支持相似度检索常见的是 Chroma、Milvus 或者平台内置的向量模块重排序第一轮检索结果不够精准时可以用更高成本的模型做第二轮过滤。很多人以为 RAG 难在模型部署其实真正决定体验的是分块策略和检索策略。比如分块长度设置 500 和 1200检索出来的内容颗粒度完全不一样直接决定模型答案是否精准。这块后面实操部分我会细讲。3.2 知识库平台三选一Dify、MaxKB、AnythingLLM通用方案确定后知识库管理平台也要做一轮选型。我实际用下来主流选择是这三个平台部署方式适合谁特点DifyDocker Compose需要生产级链路的人可视化编排、知识库、Agent、API 一站式MaxKBDocker想快速搭一个问答站的人中文界面简洁、权限管理清晰AnythingLLM桌面安装包只想本机体验的人安装即用非常轻量如果是个人学习或做技术验证AnythingLLM 最省事下载客户端选 Ollama 模型创建 Workspace上传文档就能对话。但想要完整的功能比如多用户、知识库分段精细控制、外部 API 集成Dify 是更稳的选择。我在这篇文章里以 Dify 为主线讲实操因为它在国产开源产品里功能成熟度高社区活跃遇到问题的解决方案也容易搜到。当然如果你更喜欢 MaxKB 的界面风格流程大同小异只是配置入口不同。4. 从零到一的完整部署实操4.1 安装 Ollama 与环境变量配置清单第一步当然是装 Ollama。Linux 上用官方脚本命令是curl -fsSL https://ollama.com/install.sh | shWindows 用户直接下载 OllamaSetup.exe 安装包装完后系统托盘会有小图标服务默认开机自启。装完先验证版本ollama --version这里要重点提醒环境变量很多奇怪问题都出在默认配置遗漏上。Ollama 有几个关键变量需要根据自己的情况设置环境变量作用我的建议OLLAMA_HOST监听地址默认 127.0.0.1改成 0.0.0.0:11434 才方便容器或其他机器访问OLLAMA_MODELS模型存储目录默认在 C 盘Windows 上建议改成 D 盘目录防止 C 盘塞满OLLAMA_KEEP_ALIVE模型驻留内存时间知识库高频问答改成 10m减少重复加载OLLAMA_NUM_PARALLEL并行请求数默认够用内存大再尝试 2 或 4Windows 用户设置环境变量的位置在“系统属性 - 高级系统设置 - 环境变量”Linux 用户可以在 systemd service 的 Environment 里配置。改完 OLLAMA_HOST 后一定要重启服务否则不生效。注意环境变量是 Ollama 排查的第一宝典。后面 Dify 连接失败八成因为它默认只监听了本机地址。4.2 拉取 DeepSeek 模型的两种可靠方式第一种方式最简单直接拉官方源ollama pull deepseek-r1:14b如果你在内网测试网络通畅这一步会很快。但很多人在这一步卡住出现下载慢、停留在 0% 的问题我会在第 5 部分专门讲。所以这里直接给第二种稳妥方案从国内模型站下载 GGUF 文件再手动导入 Ollama。步骤很清晰先在魔搭ModelScope找到对应的 GGUF 文件比如 DeepSeek-R1-Distill-Qwen-14B-GGUF选 Q4_K_M 版本下载到本地建议放到一个新目录比如D:\models或~/models。然后在这个目录里写一个 ModelfileFROM ./DeepSeek-R1-Distill-Qwen-14B-Q4_K_M.gguf PARAMETER temperature 0.6 PARAMETER num_ctx 32768接着执行导入cd D:\models ollama create deepseek-r1:14b -f Modelfile导入完成后用ollama list查看模型是否出现。这种方式的好处是下载源稳定模型文件管理也清晰遇到 ollama pull 源挂掉的场景特别好用。验证推理测试ollama run deepseek-r1:14b 你好简单介绍一下你自己看到模型正常输出说明本地推理链路已经通了。4.3 Dify 接入 Ollama 的配置参数Dify 我推荐用 Docker Compose 方式部署官方仓库已经把依赖基本理清了git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d第一次启动会拉不少镜像耐心等一会儿。启动完成后访问http://localhost初始化管理员账号进入主界面。接着在 Dify 里配置 Ollama。路径是“设置 - 模型供应商 - Ollama”需要填几个关键参数参数填什么Base URLhttp://host.docker.internal:11434模型类型LLM模型名称deepseek-r1:14bContext Size按需填 8192 或 32768如果你的 Dify 和 Ollama 都装在宿主机用 host.docker.internal 可以直通如果在同一台机器但用 Docker 网络用宿主机局域网 IP 更保险。Dify 不仅要一个问答模型还需要一个 Embedding 模型来做文档向量化。我的常用组合是 Ollama 里的 nomic-embed-text模型体积很小对中文支持也不错。在同一个 Ollama 供应商配置里添加 Text Embedding 类型的模型ollama pull nomic-embed-text配置好后回到知识库页面创建新知识库上传文档选择分段设置。我的经验值分段长度 500 到 800 字符重叠区 100 字符如果是结构化很强的文档可以启用自定义分段规则按 Markdown 标题切分。4.4 创建知识库与验证问答效果知识库创建完成之后需要做一轮端到端验证。打开对话页面关联刚建的知识库问一个文档里明确提到的问题例如“第三章提到的故障处理流程分几步”。如果回答能准确引用文档内容并给出来源片段说明链路正常。我习惯在系统提示词里强制加一句请严格基于知识库内容回答如果知识库中没有相关信息请直接回答不知道不要编造。这一步很关键它能把模型的“自信幻觉”压住让它老老实实当一个检索问答助手。验证通过后再调整分段长度、检索策略向量检索、全文检索、混合检索直到回答质量和引用命中率都满意为止。5. 三个高频报错与解决实录5.1 报错一ollama pull 永远停在 0%或者反复超时这是我见过最多的问题。现象表现为ollama pull deepseek-r1:14b后进度条一直不动或者显示连接超时有些还会在下载中途断开。原因很直接Ollama 默认模型仓库的下载源在境外而模型文件动辄几个 GB一旦网络不稳定就会出现长时间停滞。解决思路分两条路第一换个网络环境再试。对很多人来说这条不一定可行所以重点看第二条。第二完全绕开官方仓库手动导入。按 4.2 节的方法先用浏览器或下载工具从魔搭等国内站点把 GGUF 文件拉到本地再用ollama create生成本地模型。这个方法等同于自己建一个“局域网模型仓库”不受官方源速度影响我实测下载速度能提升几十倍。这里补充一个小点如果之前 ollama pull 卡住直接CtrlC取消就行不影响后续手动导入但如果强行杀掉进程可能会留下残留文件最好用ollama rm deepseek-r1:14b清理一下。提示手动导入是最可靠的兜底方案尤其适合网络条件有限的生产环境。5.2 报错二运行模型报 500 Internal Server Error: llama-server process 退出这个报错很典型输入ollama run deepseek-r1:14b模型加载没多久就退出Ollama 服务日志里出现一行500 internal server error: llama-server process terminated by signal 4 / 9我在不同机器上排查过几次原因基本集中在三个方向第一Ollama 版本太老。新版框架会不断调整内部推理引擎老版本对部分量化模型或新式模型结构的兼容性差。解决方式是升级到最新版目前只要不是特别老的版本这个问题概率会低很多。第二内存或虚拟内存不够。llama.cpp 在加载模型时要一次性映射大文件如果系统的虚拟内存上限太紧进程会被系统直接杀掉。Windows 上可以打开“高级系统设置 - 性能 - 虚拟内存”改成系统管理大小或者手动指定 16GB 以上Linux 上需要确认 swap 空间充足。第三CPU 不支持所需指令集。部分老 CPU 没有 AVX 指令集而 llama.cpp 默认编译版本依赖 AVX一运行就直接非法指令退出。这种情况没有软件层面的完美解法只能换新一点的机器或者选择更小的模型比如 deepseek-r1:1.5b。我自己的排查顺序是先升级 Ollama不行就看系统日志最后检查硬件指令集基本三分钟内定位问题。5.3 报错三Dify 连不上 Ollama以及 MySQL 1064 语法错误第三个报错发生在系统集成阶段现象是 Dify 的 Ollama 模型配置页点“测试”按钮报连接失败或者对话时返回“模型不可用”。这个问题的根因 90% 是 Ollama 监听地址不对。Ollama 默认绑定 127.0.0.1如果你把 Dify 跑在容器里容器内的 localhost 指向容器自己根本不是宿主机所以必然连不上。正确做法是先把 OLLAMA_HOST 改成0.0.0.0:11434再重启 Ollama 服务。确保宿主机防火墙对 11434 端口放行。测试接口是否正常可以用一条 curlcurl http://127.0.0.1:11434/api/generate -d { model: deepseek-r1:14b, prompt: 你好, stream: false }如果返回 JSON 证明推理接口通了。再测 OpenAI 兼容接口curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:deepseek-r1:14b,messages:[{role:user,content:你好}]}第二个高频集成问题就是热词里常提的“MySQL 1064 报错”。这个报错本质是 SQL 语法错误通常出现在知识库系统自定义外部数据库时。最常见的原因是 MySQL 版本太老比如 5.7 对某些建表语法、字符集定义支持不完整或者建库时没有指定 utf8mb4 字符集导致导入脚本执行到一半就挂掉。解决方式也很直接把 MySQL 升到 8.0 以上建库时显式指定字符集CREATE DATABASE dify DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;同时检查.env里的数据库账号、密码、端口配置是否和实际一致。如果你是按官方 Docker Compose 部署 Dify 或 MaxKB建议直接用默认内置数据库避免手动建库带来的隐性坑。这类排查经历多了之后我的经验是越是奇怪的问题越要往环境差异上想不要盯着业务代码找原因。最后说一个我自己反复踩过的体会知识库的分段策略直接决定回答质量这一点比平台选型更值得花时间。我用 800 字符分段加 100 字符重叠之后引用命中率明显改善了。另外如果文档是 PDF 扫描件务必先做 OCR 再进知识库否则 RAG 检索到的全是乱码任何模型来了都救不回来。