企业官网建设流程全解析

前阵子有个朋友问我，能不能在不把公司合同、技术文档传到任何云端的情况下，做一个能"翻着文档回答问题"的内部助手。我说，那就把整套东西都放在自己电脑上跑。于是就有了这篇完整的实战记录——在 Windows 10 上，用 ollama 跑 DeepSeek 模型，再用 oneApi 做接口网关，最后用 fastGPT 搭建知识库，实现真正意义上的"本地数据、本地知识、本地问答"。

这篇文章适合准备给自己或团队搭私有知识库的人看，尤其是想绕开云端 API 费用、又对数据隐私特别敏感的 Windows 用户。整个方案不需要昂贵的专用服务器，普通台式机或性能好一点的笔记本就能跑，但步骤确实不少，中间坑也多。我会把从硬件评估、环境规划、模型拉取，到网关配置、知识库初始化、全链路联调的完整过程都写出来，包括我实际踩过的坑和调整方法。

1. 这套组合到底解决了什么问题

1.1 知识库不是把文档堆在一起

很多人一听到"知识库"，第一反应是找一个目录，把几百个 Word 和 PDF 往里面一扔，然后觉得这就是知识库了。这是误区。知识库的核心价值在于"检索增强生成"：用户问一个问题，系统先从文档里找出相关内容片段，再把这些片段连同问题一起交给大模型，由大模型组织成通顺、可追溯的回答。所以它的本质不是"存储文档"，而是"让文档变成能被模型理解并调用的知识资产"。

我见过很多团队用云端知识库产品，文档一传，回答倒是快，但隐患也有：数据出了内网，敏感信息在别人服务器上过了一趟；免费额度用完之后，按 token 计费，几个人天天问，费用肉眼可见地涨。这些痛点在我实际了解需求时几乎都会被提到。于是本地部署成了自然而然的选项：数据不出本机，模型跑在本地，问题再敏感也只在内存里转一圈。

1.2 四个组件的分工与协作逻辑

这套组合里每个组件都不是多余的，它们的协作关系更像一条流水线：

• ollama 是"模型载体"，负责把深度学习模型跑起来，对外提供 OpenAI 风格的接口。它解决了"模型怎么在本地运行"的问题。
• DeepSeek 是"大脑"，是真正理解问题、生成回答的模型。你选什么规格，直接决定回答质量和硬件消耗。
• oneApi 是"网关"，所有下游（比如 fastGPT）不需要知道模型到底部署在哪里，只要对着 oneApi 这一个地址发请求。它解决的是"接口统一、渠道管理"的问题。
• fastGPT 是"应用层"，负责用户界面、知识库管理、文档切分向量化、对话流程编排。它解决的是"用户怎么用"的问题。

换句话说，如果只装 ollama，你只能在一个简陋的命令行里跟模型聊天，没法导入文档；如果只用 fastGPT 而不接 ollama，它连一个能回答问题的模型都没有。中间的 oneApi 表面上多了一层转发，实际极大降低了后续切换模型、分配令牌、控制配额的成本。

1.3 想跑在这套方案上，先看看硬件门槛

跑本地模型的硬门槛就是内存和显存。以 DeepSeek 在 ollama 上的热门规格为例：

• deepseek-r1:1.5b，量化后不到 2GB，8GB 内存的机器就能跑，但回答水平有限，适合演示链路。
• deepseek-r1:7b，约 5GB，16GB 内存可以跑得比较从容，属于"性价比之选"。
• deepseek-r1:14b，约 9GB，建议 32GB 内存起步，有 8GB 以上显存体验更佳。
• deepseek-r1:32b，约 20GB，建议 64GB 内存或 24GB 显存，已经是正经生产力配置。

我自己用的是 32GB 内存加 8GB 显存的机器，平时跑 14b 模型。要注意，这里说的"内存需求"是把模型权重载入内存的基础开销，实际运行还要叠加上下文窗口、fastGPT 本体、数据库的开销，所以不建议顶着最低配置去跑，留 30% 余量比较踏实。

这套方案最适合三类人：一是企业内部需要私有知识库的 IT 负责人；二是有敏感资料又不想用云服务的个人研究者；三是想学习 RAG 技术栈、把每条链路都摸清楚的开发者。反过来，如果你的文档量极大、团队并发很高、对回答速度要求到"秒回"，那本地单机方案不是最优解，建议直接考虑正规的云端服务。

2. Windows 10 上的部署路线选择：原装还是容器化

2.1 硬件配置预期：没有4090也能跑

在讲具体安装前，先把花销说清楚。这套方案的优点就是"不挑卡"。纯 CPU 推断也能跑，只是速度慢一些。我实际测试过：deepseek-r1:7b 在纯 CPU 下，生成一个 200 字左右的回答大约需要 10 到 20 秒，作为知识库问答场景其实是可以接受的，毕竟用户读回答也需要时间。如果有 NVIDIA 显卡，记得提前装好新版驱动，ollama 会自动检测到 GPU 并优先使用，速度会有几倍提升。

另外，磁盘空间要留足。模型本体占了主要空间，但 fastGPT 的日志、MongoDB 的数据、文档向量化的索引都会持续增长。我建议 D 盘预留至少 50GB 给整套系统，后面处理大批量 PDF 时不会捉襟见肘。

2.2 ollama 走原生安装的理由

在 Windows 上，ollama 有两种装法：原生安装包和 Docker 容器。我首推原生安装，理由有三点：第一，原生版对 NVIDIA GPU 的支持最直接，不需要在容器里做额外映射；第二，ollama 会自动注册成 Windows 服务，开机自启，省心；第三，原生版命令行交互体验好，排查问题的时候直接 ollama list、ollama ps 这些命令顺手。Docker 版适合本来就在容器环境里统一管理的场景，个人部署没必要绕弯。

2.3 oneApi 和 fastGPT 用 Docker 承载

oneApi 和 fastGPT 则反过来，我建议用 Docker。oneApi 的 Windows 原生部署需要 Go 编译环境，跑起来还有一堆依赖环境变量要配；fastGPT 原生部署更是要自己装 MongoDB、PostgreSQL，每一步都是坑。Docker Compose 把这些依赖都打包好了，一台机器上只要装一个 Docker Desktop，后续升级、回滚都方便。

所以最终路线就是"混合部署"：ollama 在宿主机，占着 11434 端口；oneApi 和 fastGPT 跑在 Docker 里，分别映射 3000 和 3001 端口。三者在网络层面通过 localhost 互通，Windows 防火墙记得放行对应端口。

装 Docker Desktop 时有个容易被忽略的点：如果开启了 WSL 2 后端，要注意 WSL 的整体内存上限。默认情况下 WSL 会吃掉一半物理内存，这会让本地模型的内存本就不宽裕，建议在用户目录下的 .wslconfig 文件里限制内存，比如设置 memory=16GB，或者干脆给 Docker Desktop 单独设置资源限制。

3. ollama 安装与 DeepSeek 模型拉取实录

3.1 安装时的目录规划和两个环境变量

ollama 的安装包不大，一路点下一步就行，但它默认把模型放到 C 盘用户目录下，这有两个问题：C 盘空间紧张，而且重装系统时模型会全部丢失。我的习惯是在安装前先加两个系统环境变量：

• OLLAMA_MODELS=D:\ollama\models，把模型仓库挪到大分区。
• OLLAMA_HOST=127.0.0.1:11434，明确绑定地址。如果后续要让局域网内其他机器访问，可以改成 0.0.0.0:11434，但要注意暴露到网段里的风险，建议配合防火墙白名单。

设置完环境变量再安装，模型就会落在 D 盘。如果已经装好了，改环境变量后重启 ollama 服务也生效。

3.2 模型下载慢或超时的处理

拉模型是新手碰壁最多的地方。直接 ollama pull deepseek-r1:7b 时，经常会因为网络问题断流、超时。这里有几个我实测有效的办法：

第一，不要反复重新拉取。ollama 的拉取支持断点续传，中断后再次执行 pull 会从上次进度继续，耐心等即可。第二，配置镜像加速。在 ollama 的配置层面，目前社区常用的做法是通过环境变量或配置文件指定加速镜像地址。我建议从正规渠道获取配置信息，不要轻信来路不明的第三方脚本。第三，如果网络情况实在不理想，可以用另一台网络状况较好的电脑把模型文件准备好，通过移动硬盘拷贝过来。ollama 模型本质上是一个带 manifest 的目录结构，拷贝到 OLLAMA_MODELS 对应的路径下，再执行 ollama list 就能识别。

3.3 选 DeepSeek 哪个规格的模型

选模型规格，我建议先明确自己的"体验目标"。如果只是打通链路，验证 fastGPT 能回复，那 1.5b 就够了，速度快，模型小，全链路调通后想换大模型只是 pull 一条命令的事。如果要真正拿去给业务用，至少要 14b 起步，7b 在长文档归纳、复杂问答场景下明显会答得比较浅。32b 以上是追求质量的用户会选的，但在没有 24GB 显存的情况下基本吃 CPU，速度就别抱太高期待。

还要注意模型的中文能力。DeepSeek R1 系列在中文理解上表现不错，而且 R1 本身带有思维链，会在回答前输出一段内部推理，这在知识库问答里是好事，能显著提升对文档内容的归纳质量，但也意味着 token 消耗会变大，回答速度会稍微慢一点，这是正常的，不用慌。

3.4 先让模型在命令行里跑通

正式接入 oneApi 之前，我强烈建议先把模型在 ollama 命令行里跑通，这一步能帮你把"模型本身的问题"和"上层应用的问题"提前隔离开。

安装完 ollama 后，打开 PowerShell，执行：

ollama list

如果能看到刚拉取的模型，说明模型仓库正常。然后执行：

ollama run deepseek-r1:7b

在交互界面里问一句"你好，用一句话介绍你自己"。如果它能正常回复，说明模型推断链路没问题。接下来按 Ctrl+D 退出，再验证一下 API 接口：

curl http://127.0.0.1:11434/api/tags

能看到返回模型列表，说明 API 服务也正常。到这一步，底层模型已经准备好了，可以进入网关配置。

4. oneApi 网关配置：把本地模型包装成标准接口

4.1 这一层到底值不值得加

很多人在读架构图时会产生一个疑问：fastGPT 不是可以直接填一个 API 地址吗？为什么非要中间塞一个 oneApi？

我最初也觉得多余，直到踩了几次坑才明白它的价值。第一，如果你以后想同时接入本地模型和云上模型做对比，或是想给不同团队分配不同 key，oneApi 的统一入口能让上层应用完全不用改配置。第二，fastGPT 里要配置对话模型、向量模型至少两个接口，如果渠道多了，每个都要维护一套鉴权和地址，oneApi 能把它们收敛成一套。第三，oneApi 自带可观测面板，能看到每次请求的耗时、token 消耗、成功率，排查问题的时候非常有用。

4.2 启动 oneApi 并完成初始化

用 Docker 跑 oneApi 很简单，在 Docker Desktop 的终端里执行：

docker run --name one-api -d --restart always -p 3000:3000 -e TZ=Asia/Shanghai -v D:\docker\one-api:/data justsong/one-api

其中 D:\docker\one-api 是宿主机上的数据目录，用来保存渠道、令牌等配置。启动后访问 http://127.0.0.1:3000，初始账号是 root，密码是 123456，首次登录后系统会要求改密码。顺手把登录会话过期时间调大一点，避免隔一会儿就被踢下线。

4.3 把 ollama 添加为渠道

登录 oneApi 后台，进入"渠道"页面，点击新建渠道。渠道类型选择 OpenAI 兼容（不同版本里名称可能叫 OpenAI 或自定义 OpenAI），重点是下面几个字段：

• Base URL 填 http://127.0.0.1:11434/v1
• 密钥随便填一个占位符，比如 local
• 模型列表填 deepseek-r1:7b，多个模型用英文逗号分隔
• 代理留空即可

保存后，点一下"测试"按钮，oneApi 会向 ollama 发一个模型列表请求，返回 200 就说明渠道通了。

这里有个细节：ollama 的 OpenAI 兼容接口路径是 /v1，不带 v1 的话 oneApi 转发时路径会对不上。

4.4 令牌与转发规则的心得

渠道建好之后，还要创建令牌。令牌相当于是 fastGPT 拿到的"钥匙"，推荐为不同应用建不同令牌，方便后续按令牌统计用量。在令牌页面创建时，额度可以先不填，等确认链路稳定了再根据实际消耗设置。

关于转发规则，我建议在渠道设置里把"模型重定向"功能用上。比如 ollama 拉的是 deepseek-r1:7b，但 fastGPT 端习惯填 deepseek-chat，你可以在 oneApi 里配置一个别名映射，把模型名翻译成 ollama 认识的名称。这样上层应用不用感知底层模型变化，以后换了一个 14b 模型，只需要改 oneApi 的映射，fastGPT 一点不用动。

5. fastGPT 的 Docker化部署与知识库初始化

5.1 从官方编排文件说起

fastGPT 官方提供了一个 Docker Compose 编排文件，里面包含 fastgpt 主程序、MongoDB、PostgreSQL、沙盒服务等。Windows 用户先确保 Docker Desktop 正常运行，然后在 D 盘建一个工作目录，比如 D:\fastgpt，把 docker-compose.yml 放进去。

注意不要把编排文件里所有服务一股脑启动，fastGPT 有些模块是可选的，比如沙盒服务只在执行高级编排时才需要。我一般只保留必须的核心服务，这样拉取的镜像更少，启动更快，资源占用也更低。镜像拉取需要一些时间，配置好 Docker 的镜像加速能省下不少等待。

5.2 配置文件里的几个关键项

fastGPT 启动前要改的地方主要是两个：一个是 fastgpt 主服务的环境变量，里面有两个关键的 URL 要填对外访问地址，如果是纯本机使用，直接填 http://127.0.0.1:3001 即可；另一个是数据库的连接串，需要配合自己的 MongoDB 容器账号密码。这些配置在初次启动前必须确认，否则会出现前端页面起来了、但知识库报数据库连接错误的问题。

还有一处容易被忽略：fastGPT 默认会把请求超时时间设得比较短，而本地小模型推断慢，可能超过默认超时导致前端报错。建议把超时时间调到 120 秒以上，给模型留足思考时间。我一开始就是没注意这个参数，第一次对话经常转圈到一半就断了，后来调大超时时间才稳定。

5.3 创建知识库：文档切分与向量化

fastGPT 启动后，先别急着配模型，我的建议是先把知识库建立了。进入知识库页面，新建一个数据集，然后上传若干 PDF 或 Markdown 文档。fastGPT 会把文档切分成片段，再调用向量模型把每个片段转成向量。

这里就引出了向量模型的问题。我常用的做法是在 ollama 里拉一个 bge-m3 模型，它是一个中英文效果都不错且体量可控的向量模型，然后通过 oneApi 把它也暴露成一个 embedding 接口。这样在 fastGPT 配置向量模型的环节，只需要填 oneApi 的地址和令牌，选择 bge-m3 即可。如果没有向量模型，知识库的训练任务会一直失败，很多新手会以为是自己上传的文件有问题，实际是模型没配好。

5.4 配置模型与应用，跑通第一次对话

在 fastGPT 的模型管理里，分别配置对话模型和向量模型。对话模型的 API 地址指向 oneApi：http://127.0.0.1:3000/v1，API Key 填刚才创建的令牌，模型名填 deepseek-r1:7b（如果配了重定向，填别名也可以）。向量模型类似，不过模型名填 bge-m3。

配置完成后，创建一个新的应用，在应用设置里勾选上刚建的知识库，保存后就可以在对话窗口里发问了。第一次提问建议问一个能从文档里直接找到答案的问题，比如"这份文档里的联系电话是多少"，这样能快速判断文档切分、向量检索、模型回答整条链路是否正常。

6. 全链路联调、提速与坑位盘点

6.1 一次完整请求的追踪过程

链路调通后的某次请求，我会按这个顺序检查：fastGPT 收到用户问题后，先从知识库检索相关片段，再把问题和片段一起发给对话模型。这个请求到 oneApi 后，oneApi 先校验令牌，然后转发给 ollama，ollama 把 deepseek-r1:7b 加载到内存（如果还没加载），模型推理完成后逐字节返回，oneApi 再组装成 OpenAI 格式响应回给 fastGPT。第一次请求往往会比较慢，因为模型要冷加载，后续如果模型一直驻留内存，速度会快很多。

6.2 我实际踩过的几个报错

• ollama 模型加载失败：通常提示 "llama runner process has terminated"，多半是内存不足或者模型文件损坏。前者好解决，换个更小的模型或加大虚拟内存；后者重新 pull 一次。
• oneApi 提示 "invalid api key"：令牌复制错了，或者渠道里的密钥被当成真实 AK 去校验。确认一下 Header 里的 Authorization 格式。
• fastGPT 知识库训练停止：多半是向量模型没有正确配置，或者嵌入接口超时。注意 bge-m3 这类模型在 CPU 上单次向量化也要几百毫秒，文档多的时候整体训练耗时较长，不要误判为卡住。
• 前端打开白屏：fastGPT 主服务和数据库没起来，或者端口映射有问题。逐个容器看日志，重点看 Mongo 是否已经 ready。

6.3 上下文长度、并发和磁盘空间的调优建议

全套跑通之后，我一般在三处做调优。第一处是 ollama 的 OLLAMA_KEEP_ALIVE 环境变量，默认模型在内存中驻留 5 分钟，频繁问答时会反复加载，建议改为 30m 或 1h，体验会更顺。代价是内存一直被占着，得结合自己的硬件权衡。

第二处是上下文长度，在 fastGPT 的模型参数里可以设置 max_tokens，对 R1 这种带思维链的模型，建议给足 2000 以上，否则回答容易中途截断。另外 ollama 也可以设置 OLLAMA_NUM_PARALLEL 来控制并发请求数，默认是 1，意思是同一时刻只能处理一个请求。如果你有好几个人同时用知识库，可以适当调大到 2 或 4，但要注意并发越高，内存占用和卡顿风险也越大。

第三处是磁盘，知识库文档越多、向量索引越涨，定期清理 fastGPT 的历史对话记录和不再需要的旧文档，能延缓磁盘压力。

最后再分享一个小技巧：给 Windows 任务计划程序加一个自启动脚本，把 ollama serve、Docker 容器一并在开机后拉起。因为本地知识库这东西，最大的价值在于"随时可用"，别让人每次开机还要手动开一堆东西。我自己的脚本就几行命令，扔在启动目录里，基本做到了无感运行。整个部署过程坑不少，但跑通之后的体验确实是"数据全在自己手里"的踏实感，这种掌控感用云端产品是换不来的。