企业官网建设流程全解析

简介：面向政企单位及内部网络的 IT 运维人员与技术爱好者，这份 DeepSeek 离线部署攻略回答了内网环境搭建 AI 知识库的核心问题：如何在没有互联网接入的情况下备齐模型、安装运行环境并保护数据安全。压缩包内为 1 个 PDF 文档，大小 5.28MB，内容覆盖离线资源准备、Windows/Linux/macOS 多平台部署、模型导入、离线数据投喂、访问控制与安全加固等完整环节，并专门给出国产化操作系统与 CPU 架构适配说明。文中对比了两种 RAG 实现方式，其中借助 Cherry Studio 客户端进行数据馈送的方法步骤直观，对新手尤其友好；还针对 Ollama API 未授权访问、宝塔面板部署等场景提供了加固思路。目前已有 1369 人学习，适合政企内网运维人员及有一定技术基础的用户作为操作手册或排障参考，快速落地安全可控的私有大模型知识库。

1. 内网部署 DeepSeek：从离线安装包到国产化适配的完整落地方案

给政企内网搭 AI 知识库，最大障碍从来不是模型本身，而是「怎么把几百 GB 的模型和依赖搬进隔离网络」。在线教程默认你能pip install、能git clone，但内网环境一切都要靠离线介质传递，数据安全红线又卡死了外网访问。这篇文章要解决的，就是这套完整的离线部署链路：先备齐模型包和安装包，再分别落到 Windows Server 和 Linux（含国产系统）上，最后把 RAG 数据投喂和 Ollama API 安全加固做扎实。适合 IT 运维、政企数字化岗位的工程师，也适合想在内网环境搭私有助手的进阶玩家。

2. 离线资源准备：模型包、安装包与完整性校验

2.1 模型离线包的获取渠道

离线部署的第一步不是装软件，而是先把模型文件搞到手。DeepSeek 系列模型在 Ollama 仓库和 ModelScope 上都有分发，常见做法是找 GGUF 格式——Ollama 能直接识别这种后缀，省去转换步骤。Hugging Face 和 ModelScope 是两条主要下载路径，前者搜索deepseek能看到官方和各社区量化版本，后者对国内网络更友好，速度也稳。

模型版本选择上，我一般建议先看硬件再定大小。7B 级别在 16GB 内存的机器上就能流畅跑，32B 则建议 64GB 内存起步，70B 基本要双卡或者大内存服务器才舒服。Ollama 官方的 deepseek-r1 系列有 1.5b、7b、8b、14b、32b、70b 几个档位，量化版用q4_K_M居多，在显存占用和效果之间取了个平衡。

下载时注意拿ollama run deepseek-r1:7b这种命令格式，在装了 Ollama 的联网机器上执行，就能把模型拉进本地模型目录。如果你走的是 ModelScope，搜到 GGUF 文件直接下了拷贝即可，不需要额外转换。

2.2 Ollama 离线安装包的三种准备方式

Ollama 本体是单一二进制文件，这给内网分发带来了很大便利。

# 有网机器上执行官方脚本，会自动下载 ollama 二进制 curl -fsSL https://ollama.com/install.sh | sh # 安装后找到二进制文件实际位置 which ollama # 通常在 /usr/bin 或 /usr/local/bin

找到二进制后，直接拷贝到 U 盘或者内网共享目录就算准备完成。Windows 端更简单，官网下载安装包，拷进内网双击就能装。macOS 的安装逻辑同 Linux，brew install ollama或者直接下载.zip都行。这个方案的妙处在于：Ollama 没有复杂的依赖树，单文件分发不需要处理动态链接库的兼容问题。

2.3 客户端离线包与 Docker 镜像迁移

Lobe Chat 是常用的 Web 界面客户端，它提供 Docker 镜像，内网部署需要提前在联网机器上拉取再导出。

# 联网机器上拉镜像 docker pull lobehub/lobe-chat # 导出为 tar 包 docker save -o lobe-chat.tar lobehub/lobe-chat # 拷贝到内网后加载 docker load -i lobe-chat.tar

如果还需要 RAG 能力，rag-web-ui 也是同样的操作逻辑：联网机器上docker pull→docker save→ 内网docker load。Docker 镜像迁移是最省心的离线分发方式，因为镜像里已经把运行环境和依赖全部打包好了，内网服务器只要装了 Docker，就能直接跑起来。

2.4 模型文件完整性校验与导入

模型文件动辄几十 GB，传输过程中损坏一个字节，推理结果就可能完全错乱。所以下载完成后，校验 SHA256 哈希是必须走的流程。

# Linux/macOS 计算哈希 sha256sum /path/to/your/model/file # Windows PowerShell 计算哈希 Get-FileHash -Algorithm SHA256 /path/to/your/model/file

拿计算出的哈希值跟官方发布页比对，一致才能进内网。如果模型文件太大，U 盘放不下，Linux 可以用split分割、cat合并，Windows 用 7-Zip 分卷压缩。安全等级高的环境走安全网闸，物理隔离最稳妥。

模型文件进了内网，还需要导入 Ollama 才能使用。先新建一个 Modelfile，内容和模型文件放同级目录：

# Modelfile 内容只需要写模型文件名称和后缀 # 例如模型文件名为 deepseek-r1-7b-q4_K_M.gguf，Modelfile 里就写这一行 deepseek-r1-7b-q4_K_M.gguf # 在模型目录下执行导入 ollama create deepseek-r1-7b -f Modelfile # 查看导入结果 ollama list

ollama create的作用是把 GGUF 文件注册成 Ollama 的模型条目，-f Modelfile指定配置文件。导入完成后ollama list能看到新模型，说明模型已进入 Ollama 管理范围，后面部署服务端时就能直接调用。

3. 内网环境部署：Windows Server、Linux 与 macOS 的差异化配置

3.1 Windows Server 部署与防火墙放行

Windows Server 上安装 Ollama 是图形界面操作，但真正容易翻车的是环境变量和防火墙配置。安装完成后，右键「此电脑」→「属性」→「高级系统设置」→「环境变量」，在系统变量里新建或编辑：

• OLLAMA_HOST：设为0.0.0.0:11434才能让内网其他机器访问；只本机用就填localhost:11434
• OLLAMA_MODELS：模型文件存放路径，如果你把模型放到 D 盘单独目录，这里就填对应绝对路径
• HTTP_PROXY/HTTPS_PROXY：如果需要走代理拉模型才配，纯内网不配

改完环境变量必须重启 Ollama 服务才生效，这是 Windows 上最典型的坑——很多人改了不重启，服务还在用旧配置跑。

防火墙配置用命令或图形界面都行：

# 放行 Ollama 端口 netsh advfirewall firewall add rule name="Ollama API" dir=in action=allow protocol=TCP localport=11434 # 放行 Lobe Chat 端口 netsh advfirewall firewall add rule name="Lobe Chat" dir=in action=allow protocol=TCP localport=3210

Windows Server 2019/2022 上这套流程测试通过，更老版本的 Server 需要考虑 Docker 版本兼容性——老系统装不了新版 Docker Desktop，Lobe Chat 的部署就会卡住。

3.2 Linux Server 部署与 systemd 服务管理

Linux 部署的核心是把 Ollama 二进制放进系统路径，再用 systemd 托管服务，确保重启后能自动拉起。

# 拷贝二进制到系统路径并赋权 sudo cp ollama /usr/local/bin/ sudo chmod +x /usr/local/bin/ollama # 创建 systemd 服务文件 sudo vim /etc/systemd/system/ollama.service

服务文件内容如下：

[Unit] Description=Ollama Service After=network.target [Service] User=youruser WorkingDirectory=/path/to/ollama ExecStart=/usr/local/bin/ollama serve Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/path/to/your/models" Restart=always [Install] WantedBy=multi-user.target

配好后执行：

sudo systemctl daemon-reload sudo systemctl enable ollama sudo systemctl start ollama systemctl status ollama

Restart=always这行很关键——Ollama 进程意外崩溃或 OOM 被系统杀掉时，systemd 会自动拉起，不会出现人不在现场服务就挂了的情况。防火墙层面，CentOS/RHEL 用firewall-cmd --permanent --add-port=11434/tcp && firewall-cmd --reload，Ubuntu/Debian 用ufw allow 11434/tcp。

另外建议把ulimit -n 65535写进服务的环境配置或启动脚本。Ollama 在高并发下要开大量文件描述符，默认 1024 限制会导致连接被拒绝，表现就是客户端偶发连不上、日志里报too many open files。

3.3 macOS 部署与 LaunchAgents 管理

macOS 安装本身不难，curl -fsSL https://ollama.com/install.sh | sh或brew install ollama都行。环境变量写在~/.zshrc或~/.bash_profile：

export OLLAMA_HOST="0.0.0.0:11434" export OLLAMA_MODELS="/path/to/your/models" source ~/.zshrc

macOS 有个容易踩的坑：Gatekeeper 会拦截未签名应用。第一次启动 Ollama 如果提示损坏或无法验证开发者，去「系统设置 → 隐私与安全性」里允许即可。SIP 不建议关闭，跟 Ollama 运行没有冲突。

开机自启动用 LaunchAgent 管理，新建~/Library/LaunchAgents/com.ollama.plist，内容指向 ollama serve 命令，launchctl load加载后就能常驻后台。资源监控方面，活动监视器可以看到 Ollama 进程的 CPU 和内存占用，如果推理性能不理想，可以调OLLAMA_NUM_THREAD环境变量控制线程数——比如 8 核机器设 6，留 2 个核给系统和其他服务。

4. 国产化适配：操作系统、CPU 架构与硬件兼容性边界

4.1 操作系统兼容性：麒麟、统信 UOS 与主流发行版

国产化环境里最常见的操作系统是麒麟（Kylin）和统信 UOS，它们本质上是基于 Linux 的发行版，包管理器和 systemd 体系跟 Ubuntu/CentOS 兼容良好。部署路径跟标准 Linux 一致：拷贝 ollama 二进制到/usr/local/bin，创建 systemd 服务，配置环境变量。需要注意包管理器的差异——麒麟用yum或dnf，UOS 基于 Debian 用apt，这影响的是后续装 Docker 和辅助工具时的命令选择，不影响 Ollama 本身。

写 systemd 服务时，User=字段注意用实际账号。很多国产系统默认禁止 root 直接跑服务，需要先useradd ollama建专用账号再指定。OLLAMA_MODELS 路径也要预先chown给该用户，否则模型写入时权限报错。

4.2 CPU 架构兼容性：x86、ARM 与国产芯片

Ollama 的二进制对架构有严格匹配：x86_64 的二进制不能跑在 ARM 上，ARM 的也不能跑在龙芯的 LoongArch 上。下载安装包时要看清uname -m的输出——x86_64选 amd64 包，aarch64选 arm64 包，龙芯平台需要确认有没有对应构建版本，没有的话只能在兼容层上试跑或换部署方案。

# 查看 CPU 架构 uname -m # x86_64 → amd64 安装包 # aarch64 → arm64 安装包

实操中比较典型的场景是鲲鹏（ARM）服务器跑 DeepSeek 7B 量化版。ARM 平台对 int8 量化支持尚可，FP16 推理效率稍低，选模型时优先考虑 q4_K_M 这类量化版本，显存带宽压力更小。

4.3 硬件兼容性：GPU 显存、内存与量化档位选择

部署前先算清楚自己的硬件能跑动哪个模型，这比安装步骤本身更决定成败。

CPU 推理不是不能跑，但要认清边界。7B 量化版在纯 CPU 环境下一字大约 2~5 token/s，做简单问答和文档摘要没问题，深度的多轮对话或长文生成体验就会明显下降。有 NVIDIA 显卡就设CUDA_VISIBLE_DEVICES指定 GPU，推理速度能提升一个量级。拿了国产 GPU（如昇腾、寒武纪）做适配就要确认 Ollama 有没有对应的后端支持，很多场景下需要走 vLLM 或其他推理框架绕过。

提示：国产化适配最大的坑是「以为照着 Linux 教程就能跑通」，实际上架构和芯片型号决定了一切。部署前先把uname -m和显卡型号记下来，再去对照 Ollama 官方支持列表，比装完再排查省太多时间。

5. 离线数据投喂：RAG 知识库构建的两种路径

5.1 文档解析与文本预处理流程

RAG 知识库的核心流程是「文档 → 文本 → 分块 → 向量化 → 存储 → 检索」。先处理原始文档格式，把 PDF、DOCX、TXT 统一提取成纯文本。

# DOCX 提取文本 from docx import Document document = Document('your_document.docx') text = '\n'.join([paragraph.text for paragraph in document.paragraphs]) # PDF 提取文本（用 pdfminer.six） # 命令行方式：pdf2txt.py your_document.pdf -o output.txt

# 离线安装依赖包 pip install python-docx pdfminer.six jieba

文本提取完做分块。分块尺寸直接影响检索精度——块太大语义混杂，块太小上下文不够。常见做法是每块 500~800 字符，相邻块之间重叠 100 字符左右，保留上下文衔接。

import jieba # 中文分词 text = "这是一段测试文本" seg_list = jieba.cut(text, cut_all=False) print(" / ".join(seg_list))

5.2 向量化与 ChromaDB 向量库写入

文本变成向量才能做相似度检索，这里需要 embedding 模型。推荐bge-large-zh-v1.5或bge-m3，中文效果比通用模型好一截。embedding 模型也要提前下载好，放进内网后通过本地路径加载，全程不碰外网。

from sentence_transformers import SentenceTransformer # 加载本地 embedding 模型路径 model = SentenceTransformer('/path/to/your/embedding/model') # 文本向量化 sentences = ["这是第一段文本", "这是第二段文本"] embeddings = model.encode(sentences)

向量库用 ChromaDB，轻量且支持本地持久化，不需要额外起服务：

import chromadb client = chromadb.Client() # 创建 collection collection = client.create_collection("my_collection") # 写入向量和原文 collection.add( embeddings=embeddings, documents=["这是第一段文本", "这是第二段文本"], metadatas=[{"source": "doc1"}, {"source": "doc2"}], ids=["id1", "id2"] )

这里的metadatas是检索结果过滤的依据，比如按来源文档筛选、按部门标签筛选。ids必须唯一，重复写入同一文档会报错，实操中常用md5(文档路径+块序号)做 ID。

5.3 Cherry Studio 可视化投喂：新手优先推荐的 RAG 路径

上面这套 Python 流程对新手不友好——环境配置、依赖安装、路径问题都能卡半天。实际工作中我更推荐用 Cherry Studio 客户端做数据投喂，把 RAG 链路封装成了图形操作。

操作步骤：

1. 安装 Cherry Studio 并启动，打开「设置」→「模型服务」
2. 先添加 Ollama 服务地址，填http://127.0.0.1:11434（本机）或http://<服务器IP>:11434（内网远程）
3. 导入文本向量模型：设置里点「添加」，选择nomic-embed-text，Ollama 上提前ollama run nomic-embed-text拉好
4. 在知识库页面新建知识库，导入本地 PDF、DOCX、TXT 文件
5. Cherry Studio 会自动完成分块、向量化、写入本地向量库
6. 对话时在输入框上方切换到对应知识库，检索增强自动生效

这条路径把分块参数默认在了合理范围，向量存储也自动管理，新手完全不需要理解 embedding 和向量数据库的细节。等跑通了再回头研究那些参数不迟。

注意：Cherry Studio 的 RAG 默认从本地文件投喂，适合个人知识库；团队共用的知识库还是建议走 rag-web-ui 或自建向量库方案，便于统一维护和多用户共享。

6. 避坑指南：Ollama API 安全加固与常见部署问题排查

6.1 未授权访问：Ollama API 裸奔是最大安全隐患

现象：Ollama 服务启动后，内网任何机器直接访问http://<服务器IP>:11434/api/generate就能调用模型，无需任何认证。如果服务器有外网映射或处于不可信网段，任何人都能白嫖算力，甚至读取、删除模型文件。

原因：Ollama 默认不开启任何鉴权机制，OLLAMA_HOST=0.0.0.0:11434的配置会把 API 完全暴露在网络上。

解决：最直接的措施是把OLLAMA_HOST改成监听内网网卡 IP，而不是0.0.0.0；其次用防火墙限制 11434 端口只允许特定网段访问。如果走了宝塔面板做反向代理，可以在 Nginx 层加 Basic Auth 或 IP 白名单。

6.2 宝塔面板反向代理配置与鉴权保护

现象：用户在宝塔面板里配了 Ollama 反向代理，但没做认证层，访问域名就能直通 API。

原因：反向代理本身不提供认证功能，默认透传所有请求。

解决：在宝塔「网站 → 反向代理」配置里加访问限制。常见做法是在 Nginx 配置里加allow/deny规则控制来源 IP：

location /api/ { allow 192.168.1.0/24; # 允许内网网段 deny all; # 其余全部拒绝 proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

如果是多部门跨网段访问，也可以叠加 Basic Auth。生成 htpasswd 文件，在 Nginx 里加auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd;，这样内网用户访问聊天界面和 API 都要输账号密码。

6.3 环境变量不生效与模型路径错乱

现象：配置了OLLAMA_MODELS指向新路径，但重启后模型还是加载不到，ollama list显示为空。

原因：Windows 上改完环境变量没重启 Ollama 服务，或者在 systemd 服务文件里改了路径却没执行daemon-reload。

解决：Windows 在服务管理器里找到 Ollama 服务右键重启；Linux 改完服务文件务必执行sudo systemctl daemon-reload && sudo systemctl restart ollama。改完用echo $OLLAMA_MODELS或 PowerShell 里Get-ChildItem Env:OLLAMA_MODELS确认环境变量已生效。

6.4 Linux 下 Ollama 起不来：端口占用与依赖缺失

现象：systemctl start ollama报失败，journalctl -u ollama日志里有bind: address already in use或exec format error。

原因：前者是 11434 端口被其他进程占用，后者是二进制架构与系统不匹配——最常见的是把 amd64 的包拷到了 ARM 服务器上。

解决：端口占用用lsof -i :11434查占用进程杀掉，或者改OLLAMA_HOST里的端口号。架构不匹配跑uname -m核对后重新下载对应安装包。这两个问题占了 Linux 部署失败的大半比例。

6.5 CPU 推理 OOM 与加载不稳定

现象：模型加载成功，但对话进行到一半进程被系统杀掉，dmesg里有Out of memory记录。

原因：模型量化档位选择过高，内存耗尽触发 OOM killer。7B 的 FP16 要 14GB 内存，量化 q4_K_M 只要 5GB 左右，选错档位翻车极常见。

解决：32GB 内存的机器不要跑 32B FP16，选 q4_K_M；同时把OLLAMA_NUM_THREAD限制在物理核心数的 60%~75%，避免线程争抢内存。监控用free -h和nvidia-smi，确认还有余量再加大模型档位。

7. 进阶：离线模型统一管理与多模型调度技巧

DecpSeek 部署完成后，日常维护的核心是模型文件管理和多模型调度。这里分享我常用的几个技巧，能让内网 AI 服务稳定度明显提升。

7.1 模型文件目录规范化

把模型文件按「厂商/版本」建目录，是后期维护最省心的做法：

• 主要给OLLAMA_MODELS指定专用磁盘分区或目录，避免模型和系统盘抢空间；实践下来 7B 量化版约 4~5GB，32B 量化版约 20GB，预留 2 倍余量比较稳妥
• 每个模型文件到达后先做 SHA256 校验再导入，导入完ollama list确认显示条目的名称和版本一致
• 模型文件用 U 盘或共享目录进内网时，保持 Modelfile 和模型文件同级目录，ollama create时通过-f参数指定文件路径，就不会出现「导入了但找不到模型」的坑

# 推荐结构 OLLAMA_MODELS=/data/ollama/models # 下面按模型名建子目录 /data/ollama/models/deepseek-r1/ /data/ollama/models/nomic-embed-text/

7.2 多模型按场景切换

Ollama 支持同时管理多个模型，客户端可以在 DeepSeek 对话模型和 embedding 向量模型之间切换。比如 Cherry Studio 里把对话模型指向deepseek-r1:7b，向量模型指向nomic-embed-text，两者各司其职：

# 查看当前所有模型 ollama list # 测试某模型是否正常工作 ollama run deepseek-r1:7b "你好,做个自我介绍" # 模型不在内存中时，首次调用会冷启动加载 # 频繁使用的小模型可改为常驻，通过 OLLAMA_KEEP_ALIVE 控制

关于OLLAMA_KEEP_ALIVE参数的调优是一个通常容易被忽视的关键设置：它表示模型在内存中保持加载的时间，默认是 5 分钟。如果业务场景是多人频繁对话，模型被反复卸载再加载会产生明显延迟，我一般会调大到 30 分钟或-1常驻；但显存紧张的机器不建议设太大，否则小模型长期占着显存，大模型加载时反而容易 OOM。

7.3 日志排查与自启动验证

服务部署完不能一走了之，把日志排查和自启动验证做成固定动作，这比任何监控工具都可靠。

# Linux 查看 Ollama 最近日志 journalctl -u ollama -n 50 --no-pager # 查看服务是否随开机自启 systemctl is-enabled ollama

Windows 上查看事件查看器的「Windows 日志 → 应用程序」，Ollama 启动失败或崩溃会有详细错误记录。首次部署完成后我会强制走一遍：重启机器 → 等服务自动拉起 → 客户端发起一次问答请求 → 看响应时间正常 → 记录基线数据。这套标准化验证流程花不了五分钟，但能确保后续维护时有据可查。

7.4 内网知识库的效果验证

RAG 投喂完数据，要验证检索效果而不是凭感觉判断。我的习惯是准备三组测试问题：一组直接能答的、一组需要知识库外部信息辅助的、一组故意设陷阱的。用 Cherry Studio 对比开启/关闭知识库的答案差异，如果开启后答案包含文档里的细节信息，说明 RAG 链路通了；如果答案还是模型通用知识，优先检查向量模型是否已正确导入、文档分块是否过大、检索 TopK 是否设置过低。

从那以后我每次内网部署完「模型 + RAG + 安全加固」三个环节，都强制走一遍这套验证流程，半小时内能确认交付质量，而不是等用户上线后才发现检索不生效。希望这份攻略能帮你在内网环境少踩坑、少走弯路。

本文还有配套的精品资源，点击获取