企业官网建设流程全解析

前天一位做企业内部知识库的朋友问我，能不能把 DeepSeek 这类开源模型部署到他们只有内网的测试环境里。他自己的笔记本是 16G 内存的 Windows，手头还有一台 32G 内存的旧服务器，想跑一个能给团队用的“私有问答机器人”。我给他的方案就是 Ollama 跑 DeepSeek 模型，再通过知识库系统把部门文档接进去。整条链路跑下来，效果比我预想的稳，但中间也踩了几个很典型的坑。这篇就把我的完整做法、选型思考，以及三个报错的排查过程全部写出来，给准备做 DeepSeek 本地部署 + 知识库的同学一个可以直接参考的路线。

1. 为什么选Ollama而不是vLLM：先把路线定明白

1.1 本地部署的真正适用场景

大家要明白一点：本地部署不是什么情况都值得做。我见过不少人折腾半天，最后发现直接调 API 更划算。根据我的经验，真正适合本地部署 DeepSeek 的场景就这几类：

• 数据敏感：业务数据、合同、内部文档不能出内网，第三方 API 传过去就有合规风险。
• 长期高频调用，成本算得过来：如果只是偶尔问几句，买 GPU 服务器自己跑可能比按量付费更贵。
• 网络受限环境：办公网对外部服务不稳定，或者干脆就是内网隔离环境，这时候唯一的办法就是本地跑。
• 学习和研究目的：想了解大模型推理原理、RAG 流程、prompt 工程，本地部署是最可控的实验环境。

我这位朋友属于典型的数据敏感加内网场景，所以本地部署是合理选择。

1.2 Ollama / vLLM / llama.cpp 三条路线的取舍

模型跑起来的引擎选择，目前主流就三个：Ollama、vLLM、llama.cpp。各有各的适用面，我直接给个对比表：

我自己做知识库和私有化问答这类应用，优先推荐 Ollama。原因很直接：

1. 开箱即用：Ollama 安装完就是一个系统服务，API 自动跑在 11434 端口，OpenAI 兼容格式，Dify、MaxKB 这些知识库系统直接填地址就能连上。
2. 模型管理简单：拉模型、删模型、跑对话都是几个命令，不需要写 Python 代码。
3. 社区生态成熟：DeepSeek R1 系列在 Ollama 官方模型库里有现成标签，不需要自己转换权重。

vLLM 的优势在高并发和吞吐量，如果你的知识库系统会给几十个人同时提供服务，Ollama 的并发处理会吃力，这时候 vLLM 更合适。但 vLLM 的安装和调优成本高很多，不是新手能快速搞定的。llama.cpp 则是极客向的选择，适合 CPU 推理和树莓派之类的小设备，日常使用体验不如 Ollama 顺滑。

1.3 硬件要求与模型档位选择

DeepSeek 官方发布的 R1 系列包括 671B 的完整模型，但本地个人和小团队能跑的是蒸馏版——也就是用更大的教师模型蒸馏出来的小参数模型。在 Ollama 上，你能拉到的 DeepSeek 主要标签是deepseek-r1:7b、deepseek-r1:8b、deepseek-r1:14b、deepseek-r1:32b、deepseek-r1:70b这几档。

根据我实测的经验，硬件选型大概是这个档位：

朋友那台 32G 内存的老服务器，我建议他直接跑deepseek-r1:14b的 Q4_K_M 量化版，纯 CPU 模式下速度大概每秒 5-8 个 token，虽然不快，但作为内部知识库问答是能等的。如果是 16G 内存笔记本，就老老实实用deepseek-r1:7b。

注意：这里说的deepseek-r1:7b是 R1 蒸馏出的 7B 版本，底层架构类似 Qwen 或 Llama 系列，和 DeepSeek-V3 那种 MoE 架构不是一个东西。它牺牲了一部分复杂推理能力，但换来的是消费级硬件能跑的成本优势。

2. 先把模型跑起来：Ollama安装、模型拉取与API验证

2.1 安装Ollama时最容易忽略的三个点

Ollama 的安装过程本身很简单，Linux 上执行官方安装脚本就能装好：

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

Windows 和 macOS 直接下载安装包双击安装即可。但我在实际部署中发现了三个容易被忽略的细节，这里专门说一下。

第一，模型存储路径一定要提前指定。Ollama 默认把模型文件放在用户目录下，Linux 是~/.ollama/models，Windows 是C:\Users\你的用户名\.ollama。一个 7B 的 Q4 模型文件约 4.7GB，14B 约 9GB，时间一长很容易把系统盘占满。如果你有独立的磁盘或数据盘，建议在安装前就设置好环境变量：

export OLLAMA_MODELS=/data/ollama/models

然后重启 Ollama 服务，之后再拉模型，模型文件就会落到你指定的目录。

第二，做完环境配置后要重启服务。很多人改了OLLAMA_HOST、OLLAMA_MODELS这些环境变量后发现不生效，多半是因为没有重启 Ollama 进程。Linux 上执行：

sudo systemctl restart ollama

第三，Windows 下记得把 Ollama 加入防火墙白名单。如果后续要让局域网里其他机器访问你的 Ollama 服务，防火墙默认会拦截 11434 端口的访问，需要在防火墙规则里放行。

2.2 下载慢或拉取超时的两条务实解法

拉取模型这一步，我这里要重点说，因为这是很多人卡住的第一关。执行：

ollama pull deepseek-r1:14b

经常会出现速度极慢、卡在pulling manifest或者直接中断的情况。这里的根因是模型文件托管在海外对象存储上，网络链路长、不稳定，纯网络问题。

我用的第一条解法是配置国内可访问的镜像加速地址。Ollama 支持通过环境变量指定镜像源，安装好之后，在启动服务前加一个环境变量指向你找到的可用镜像地址，把模型下载流量走内网或国内节点。配置好后重新拉取，速度可能有几十倍的提升。

第二条更稳妥的解法是离线导入 GGUF 文件。这个方法完全脱离网络依赖，也是内网环境部署的必经之路：

1. 在能上网的机器上，从公开的模型文件镜像站下载 DeepSeek R1 14B 的 GGUF 量化文件（推荐 Q4_K_M 格式）。
2. 把文件拷贝到目标机器，放在一个固定目录下，比如/data/models/。
3. 写一个Modelfile文件：

FROM ./deepseek-r1-14b-q4_k_m.gguf PARAMETER temperature 0.7 PARAMETER num_ctx 4096

4. 执行创建命令：

ollama create deepseek-r1:14b -f Modelfile

5. 验证模型已存在：

ollama list

这个办法本质上是绕过模型拉取，直接从 GGUF 文件构建 Ollama 模型，完全绕开了网络问题。我强烈建议任何做内网部署的人都掌握这条技能，因为你不可能每次部署都指望外网通畅。

2.3 通过API验证模型是否真正就绪

模型拉起来之后，先别急着接知识库，验证一下 API 是否就绪。Ollama 默认监听http://localhost:11434，有两个接口可以测：

原生生成接口：

curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:14b", "prompt": "你好，简单介绍下你自己", "stream": false }'

OpenAI 兼容接口，这个对后面接知识库系统非常关键：

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "deepseek-r1:14b", "messages": [{"role": "user", "content": "你好"}] }'

能正常返回 JSON 就说明模型服务没问题。这里有几个判断模型档位是否合适的技巧：响应太慢说明模型偏大或内存不足；响应很快但答非所问，说明量化等级太低或模型太大被截断。正常情况下deepseek-r1:14b纯 CPU 推理、每次回答几百字，等待时间在十几秒到半分钟，可以接受。

2.4 让服务常驻并支持局域网访问

Ollama 安装后在 Linux 上默认是 systemd 服务，开机自启。但它默认只监听本机回环地址127.0.0.1，如果知识库系统部署在同一台机器，这没问题；如果知识库系统在另一台机器，就需要把它暴露到局域网。修改方式：

sudo systemctl edit ollama.service

在配置里写入：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

保存后重启：

sudo systemctl restart ollama

这样局域网内其他机器就能通过http://这台机器的IP:11434访问模型服务了。注意，如果知识库系统和 Ollama 在同一台机器上用 Docker 部署，容器内访问宿主机不能用localhost，要用host.docker.internal或宿主机的局域网 IP，这个细节后面还会用到。

3. 知识库系统选型与接入：Dify和MaxKB怎么选、怎么接

3.1 知识库不等于文件夹：先理解RAG的完整链路

很多第一次做知识库的人有个误解，以为把 PDF、Word 扔进一个系统里，模型就能像人一样“读”这些文件。真实情况完全不是这样。大模型只能理解文本 token，它没有任何能力直接阅读一份多页 PDF。你要做的，是把文档拆成片段、转成向量、存进向量数据库，用户提问时从库里检索最相关的几个片段，再把这些片段拼进 prompt 一起交给模型回答。这就是 RAG（检索增强生成）的基本链路。

RAG 链条上有四个角色：

理解了这条链路，再去看知识库产品，你就能一眼看出它们做的事其实高度同质化——差别主要在切片策略、检索方式、界面易用性和开源生态上。

3.2 Dify还是MaxKB：按团队情况选

现在主流的开源知识库系统里，我实际部署过并且长期用的是 Dify 和 MaxKB 这两个。

Dify是功能最全的 LLMOps 平台，除了知识库，还支持工作流编排、Agent、插件、模型管理。部署方式是 Docker Compose 多容器，依赖 PostgreSQL，概念相对多。适合有容器基础、想把知识库和各类工具串起来做复杂应用的团队。

MaxKB是 1Panel 团队出的知识库问答系统，设计简洁得多，一个容器就能启动，界面是中文的，创建知识库、上传文档、绑定模型三步就能用。适合追求快速见效、不想折腾基础设施的团队。

我用这个对比表帮助选择：

我那位朋友的情况是团队只有他一个人懂技术，我建议他用 MaxKB 先跑通；如果你是做长期项目、需要复杂流程编排，直接上 Dify。下面我以 Dify 为例详细写接入过程，因为它在接 Ollama 时配置项最多，你能看到完整逻辑。

3.3 在Dify里配置Ollama的LLM与Embedding

Dify 的本地部署在docker compose里一条命令就能完成：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

启动后访问http://服务器IP/install完成初始化。接下来要做的核心操作，是在 Dify 后台把 Ollama 接入为模型提供方。

进入设置 → 模型供应商 → Ollama，需要填几项关键配置：

• API 地址：填http://host.docker.internal:11434（Dify 容器内访问宿主机的 Ollama）。如果你 Ollama 装在另一台机器，就填http://那台机器的IP:11434。
• 模型类型：分别添加两类模型。一类是LLM，填deepseek-r1:14b，用于最终的问答生成；另一类是Embedding，填 Ollama 上拉取的嵌入模型，推荐bge-m3，用于把文档切片转成向量。

Embedding 模型也需要先在 Ollama 里拉取：

ollama pull bge-m3

这里有个很关键的点：DeepSeek 官方 API 不提供 embedding 接口，所以做知识库时必须单独准备一个嵌入模型。很多教程只讲接大模型，不讲接嵌入模型，导致用户上传文档后知识库一直处理不了。BGE-M3 是一个中英双语都支持的很合适的嵌入模型，6G 左右的内存占用也能接受。

3.4 文档分段与检索参数：首轮就能提升匹配度的细节

配置好模型之后，创建知识库应用时还有一组参数直接影响问答质量，这里分享我反复调教后总结出的经验值。

• 分段长度（Chunk Size）：建议 400-800 字符。太短会导致语义碎片化，检索结果没上下文；太长会导致向量检索不精确，且浪费 prompt 上下文长度。
• 分段重叠（Overlap）：建议 50-100 字符。分段重叠可以避免一句话被从中间切开，尤其是技术文档里经常出现的“如果…那么…”这种关联结构。
• 召回数量（Top K）：建议 3-5 条。默认值经常是 10，但对超长文档来说，Top K 太大会把不相关内容塞进 prompt，反而干扰回答。
• 相关性阈值（Score）：建议 0.5 左右。低于阈值的片段说明和问题关联度太低，不应进入 prompt。

我实际测试过一个场景：知识库里存了一篇 30 页的产品操作手册，默认参数下我问“如何修改密码”，模型回答里混入了账号权限相关的内容；把 Top K 调整为 4、阈值调到 0.5 后，回答明显聚焦了，引用也准确对应到了具体段落。这些参数在 Dify 的知识库设置里都能直接改，改完立刻生效，不需要重启。

4. 三个真实报错：现象、排查链路、修复验证

这个部分是我这篇的核心，三个报错分别来自模型拉取、模型推理、知识库数据库初始化三个阶段，覆盖了本地部署最常见的三类问题。

4.1 报错一：模型拉取卡在“pulling manifest”或反复超时

现象： 执行ollama pull deepseek-r1:14b后，长时间停留在pulling manifest，进度条不动，或者下载到一半中断，再次执行又是从零开始。偶尔还会报pull access denied或connection error。

排查链路：

第一步，确认 Ollama 服务本身正常：

systemctl status ollama

第二步，看 Ollama 日志，确认是网络问题还是服务问题：

journalctl -u ollama -n 50

或者查看日志文件：

cat ~/.ollama/logs/server.log

如果是网络请求超时、dial tcp ... i/o timeout这类字样，可以确定是模型源的网络不可达或链路不稳定。

第三步，测试网络连通性。注意这里的判断标准不能是“能 ping 通”，而是 HTTPS 请求能否正常完成，因为模型下载走的是 HTTPS 对象存储。

修复方案：

方案一，配置镜像加速地址。找到可用的镜像地址后，在启动 Ollama 前设置：

export OLLAMA_BASE_URL="https://你的镜像加速地址"

再重启服务，重新拉取。

方案二，也是我最终推荐的内网解法——离线 GGUF 导入，方法在本文 2.2 已经写过了。总结下来就是：从公共模型文件镜像站下载 GGUF 文件，写 Modelfile，用ollama create创建模型。

验证：

ollama list

能列出deepseek-r1:14b且大小和本地 GGUF 文件对得上，说明修复成功。

注意：不要反复多次重试拉模型。Ollama 的下载是分块进行的，反复中断后容易造成分块文件错乱，反而更慢。遇到速度长期低于几百 KB/s 或者连续中断两次，果断切换到镜像或离线方案。

4.2 报错二：请求对话时返回500 Internal Server Error: llama-server process

现象：

Ollama 服务启动正常，模型列表也正常。但调用对话接口时，返回错误：

Error: 500 Internal Server Error: llama-server process terminated with error

这是 Ollama 在实际运行中高频出现的错误，英文提示里的llama-server process是 Ollama 内部启动的推理进程。

排查链路：

第一步，立刻看资源占用。用nvidia-smi看显存（有 GPU 时），用free -h看内存。这个错误的常见根因就是OOM（内存/显存耗尽）。7B 模型 Q4 量化需要大约 5GB 显存，14B 大约 10-12GB；纯 CPU 跑 14B 需要约 16-20GB 可用内存。如果机器内存只剩两三个 G，模型加载不进去，llama-server 进程就会被系统杀掉。

第二步，看 Ollama 日志中的具体崩溃原因：

journalctl -u ollama -n 100

日志里如果出现killed process、out of memory之类的关键词，基本可以锁定是资源不足。

第三步，查看当前加载的模型状态：

ollama ps

如果同时加载了多个模型，每个模型都要占据独立的内存/显存，加起来很容易爆。

修复方案：

1. 释放资源——卸载暂时不用的模型：

ollama stop deepseek-r1:7b

甚至直接删掉不用的模型：

ollama rm deepseek-r1:7b

2. 如果并发请求多，限制 Ollama 同时处理的任务数和加载模型数。编辑服务配置：

Environment="OLLAMA_NUM_PARALLEL=1" Environment="OLLAMA_MAX_LOADED_MODELS=1"

OLLAMA_NUM_PARALLEL=1表示每次只处理一个请求，避免多个请求同时加载上下文导致内存暴涨；OLLAMA_MAX_LOADED_MODELS=1表示同一时间只保留一个模型在内存里。

3. 如果仍然不稳定，换更小的量化模型，比如deepseek-r1:7b，或者降低上下文长度，在 Modelfile 里设小num_ctx：

PARAMETER num_ctx 2048

验证：

重启 Ollama 服务，再一次调用对话接口：

curl http://localhost:11434/api/generate -d '{"model":"deepseek-r1:14b","prompt":"测试","stream":false}'

能正常返回内容即可确认修复。

这个报错还有一个隐蔽诱因：模型文件不完整。如果你是通过不稳定的网络拉取的模型，表面看ollama list里存在，但实际文件有损坏。排查方法是先ollama rm删掉模型，再重新拉取或用 GGUF 重建，通常能解决。

4.3 报错三：知识库数据库初始化时报MySQL 1064语法错误

现象：

在做知识库系统初始化时，我用现有的 MySQL 作为元数据库，导入 SQL 初始化脚本时报错：

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ...

我看到这个报错的第一反应是“是不是我复制漏了？”反复核对后发现不是，后来才定位到根因。

排查链路：

第一步，用 MySQL 客户端直接定位报错的行号。不要只看命令行里那一句，用--show-warnings或者把 SQL 文件拆分执行：

mysql -u root -p yourdb --force < init.sql

加--force可以让 MySQL 跳过出错行继续执行，最后你就能看到完整出错列表，从而定位出问题的具体 SQL 语句。

第二步，比对 MySQL 版本。很多 1064 报错的根源不在 SQL 本身写错，而是初始化脚本是用更高版本的 MySQL 生成的，语句里用了旧版本不认识的默认值或字符集写法。

第三步，检查 SQL 文件编码。如果 SQL 文件是带 BOM 的 UTF-8，或者混入了 Windows 换行符，某些情况下 MySQL 解析器会把特殊字符误认为语法错误。用编辑器把编码转成 UTF-8 without BOM、换行符统一成 LF 再导入。

修复方案：

• 确认 MySQL 版本：

SELECT VERSION();

• 查看当前sql_mode，这经常是隐性元凶：

SHOW VARIABLES LIKE 'sql_mode';

高版本 MySQL 的STRICT_TRANS_TABLES会把不合法数据直接报错，而低版本只是给个警告。如果初始化脚本里某些字段的默认值在当前模式下不合法，也会表现为 1064 语法错误。

• 如果是脚本不兼容，最快捷的修复是直接改用知识库系统当前支持的数据库。比如 Dify 官方默认使用 PostgreSQL，MaxKB 自带数据库，不是所有系统都能随意切换数据库后端。为了省事稳定，我后来直接按官方默认配置跑通，不去折腾“换到自己熟悉但不受支持的 MySQL 上”这条路。

验证：

SQL 导入成功后，知识库系统页面能正常登录，创建知识库、上传文档、解析切片一路顺畅，就说明数据库层修复完成。

这次排查给我最大的教训是：报错文本虽然写在“语法”上，但你实际要查的往往是版本、编码、服务端配置。遇到 1064 第一反应不应该去逐字检查 SQL，而是先确认数据库版本和脚本版本的匹配关系。

5. 部署完成之后，我踩过的细节与建议

5.1 磁盘与内存的隐形增长

整套系统跑起来之后，有几个东西会被很多人忽略。第一是 Ollama 的模型缓存，你反复拉取不同量化版本，磁盘空间会悄悄吃满。第二是知识库系统上传解析后的文档副本。第三是日志文件，Dify 的容器日志如果一直不清理，几个月能攒下好几个 G。

我目前的惯例是：模型文件指定到独立数据盘，日志做定期清理，知识库文档源文件单独存一份，避免系统盘空间告急。这些“脏活”看起来不起眼，但真到服务器挂掉那天就来不及了。

5.2 给同一模型起多个别名，适配不同场景

Ollama 提供ollama create的时候，你可以用同一个 GGUF 文件创建两个不同名字的模型，比如一个叫deepseek-r1:14b-fast（num_ctx小一点），一个叫deepseek-r1:14b-long（num_ctx大一点）。知识库问答用长上下文版，日常闲聊用快速版。这比每次改参数重启服务快得多。这也是“一个模型拆成多个配置”的思路，在 Dify 或 MaxKB 里配置模型时非常灵活。

5.3 适合用本地知识库的几种真实场景

我把这套方案跑稳定之后，陆续帮朋友和同事落地了三个场景，都验证过效果：

1. 产品手册问答：把几十页的 FAQ 和操作手册放进去，客服人员可以直接问“退货流程是什么”，模型会引用手册里的原话回答，不用再手动翻文档。
2. 代码库检索：把内部项目的 README、接口文档、设计文档放进去，开发同事问“登录接口的鉴权方式”，模型能综合多份文档给出答案。
3. 制度文件问答：把公司制度、报销流程等文件放进去，员工问“出差住宿标准”，模型返回结果附带文件出处，方便核查。

这几个场景的共同特点是：问题答案高度依赖特定文档，而不是靠模型的自带知识。这说明 RAG 知识库和本地模型是互补关系——模型负责理解与生成，知识库负责提供准确出处。

5.4 关于模型底座与知识库配合的体会

最后说点我自己的实际体会。本地部署 DeepSeek R1 蒸馏版 + Ollama + 知识库这套组合，适合大多数非极端场景。它的上限主要受硬件和模型档位限制：你想要更高质量的回答，就得加内存、上 GPU、换更大的模型。但在预算有限的条件下，14B 的蒸馏模型配上优质的 RAG 检索链路，实际可用性真的不低——比起把文档直接扔给一个在线大模型干聊，知识库的引用能力往往更有价值。

如果你正在规划类似的本地知识库项目，我的建议是先定清楚“谁来用、用多久、问题集中在哪几类”，然后照着这篇的路线先跑一个最小原型，别一上来就追求 70B 大模型和全套高配。把小模型、小知识库跑稳了，再逐步升级，这个节奏远比一步到位扎实。