企业官网建设流程全解析

简介：大模型私有化部署是当前AI应用落地的重要方向，尤其适合对数据隐私和调用成本敏感的个人与中小企业。本地部署的核心在于推理引擎的选型与配置，Ollama凭借轻量级封装和API兼容性成为入门首选。完成模型加载后，通过Open WebUI等可视化工具能够极大降低交互门槛，而RAG知识库的挂载则让模型快速理解私有文档，避免高昂的微调成本。针对上下文参数、显存管理和故障排查的细节优化，决定了大模型实际应用的稳定性。本文以DeepSeek为例，从Ollama安装到WebUI部署，覆盖模型参数调优、知识库投喂与API封装，为AI技术选型和私有化部署提供了一份可落地的工程实践参考。

1. 本地部署 DeepSeek：先想清楚这条路值不值得走

如果你正在用 DeepSeek 的在线 API，大概率已经体会过两件事：一是按 token 计费，聊得多了钱包肉眼可见地变薄；二是某些内部数据不方便往外送，哪怕只是粘贴一段业务日志都觉得心里没底。DeepSeek 本地部署这件事，说白了就是在这两个痛点之间开一条缝——把模型拉到自己的机器上跑，把数据留在自己的硬盘里。这份《DeepSeek本地部署+WebUI可视化+数据投喂训练AI之新手保姆级教程.pdf》我拆完后的感受是：它不跟你讲大模型原理，而是直接带你走一条能落地的路，从装 Ollama 到跑起 WebUI，再到把手里的文档投喂给模型，全流程覆盖。

我按这份教程的路线在自己的工作站上完整跑了一遍，硬件是 RTX 3090 24G + 64G 内存，模型选的 deepseek-r1 7B 量化版。整个链路跑通后，我想把几个关键节点的操作、参数和踩坑记录整理出来，因为本地部署这件事，卡壳的地方从来不是你理解不了概念，而是命令层面的一两个细节没对上。这篇文章适合两类人：一是从来没部署过大模型的纯新手，照步骤走能少走弯路；二是已经跑起来但想搞清楚参数边界和排查思路的熟手，可以直接跳到中间几章看细节。

2. 先把推理引擎跑起来：Ollama 部署 DeepSeek 与模型参数一次说清

2.1 为什么选 Ollama 而不是直接裸跑模型

DeepSeek 的模型权重拿到手之后，本质上是一堆参数文件，你需要一个推理引擎把它加载起来才能对话。常见的选择有 Ollama、vLLM、llama.cpp 这几个，很多新手一上来就纠结到底用哪个。我的建议很简单：个人电脑本地部署，第一选择就是 Ollama，理由有三个。

第一，Ollama 把模型下载、量化、推理、API 服务全部封装好了，你不需要自己处理 CUDA 环境、不用手工编译源码，这对没有深度 Linux 经验的人是决定性的优势。第二，Ollama 自带模型管理机制，一条命令就能拉取不同尺寸的 DeepSeek 模型，切换模型就像切换 Python 虚拟环境一样方便。第三，它默认暴露了一个 HTTP API，端口 11434，后面接 WebUI 或者你自己的业务程序都走这个口子，生态兼容性非常好。

vLLM 的优势在高并发和吞吐量，那是生产环境做的事情；llama.cpp 的优势在极致轻量和 CPU 推理，但配置门槛高一些。对于「一台电脑、一个人用、想要可视化对话」这个场景，Ollama 是最省事的路径，这也是这份教程选择它的原因。你装完之后跑ollama list就能看到本地所有模型，跑ollama ps能看到当前加载在显存里的模型，这种直观感是裸跑模型给不了的。

2.2 安装与拉取模型：从零到能对话

Ollama 的安装本身没什么玄机，Windows 和 macOS 直接下载安装包双击，Linux 用官方脚本一行搞定。真正需要认真看的是模型选择这一步，因为 DeepSeek 在 Ollama 上的模型标签非常多，选错了尺寸可能跑不动，选错了量化方式可能效果打折。

# Linux 安装 Ollama（macOS/Windows 用户直接下载安装包即可） curl -fsSL https://ollama.com/install.sh | sh # 拉取 DeepSeek-R1 7B 模型（q4_K_M 量化，约 4.7GB） ollama pull deepseek-r1:7b # 跑起来试试对话 ollama run deepseek-r1:7b

我来说下模型标签的含义。deepseek-r1:7b后面的7b表示 70 亿参数的模型，这是显存 8G 以上就能流畅跑的规格；如果你的显存只有 6G 左右，可以考虑deepseek-r1:1.5b这个更小的版本，虽然智商明显降档，但至少能跑；显存 16G 以上可以直接上deepseek-r1:14b，推理质量会好一个档次。量化格式q4_K_M是 Ollama 默认的，本质是把模型权重从 16 位浮点数压到 4 位，换来的是显存占用大幅下降，代价是效果有轻微折损——但这个折损在对话场景里几乎感知不到，我个人建议新手不要碰q8_0或fp16这类高精度版本，回报很低但显存压力陡增。

跑起来之后，Ollama 会默认在后台起一个服务监听 11434 端口。你可以用ollama serve单独启动服务，也可以直接ollama run边跑边聊。初次对话时模型会从磁盘加载到显存，这个加载时间取决于你的硬盘速度和模型大小，冷启动 10 到 30 秒都是正常的，别以为卡死了。

# 确认 API 服务是否正常响应 curl http://localhost:11434/api/generate -d '{"model": "deepseek-r1:7b", "prompt": "你好，简单介绍一下你自己", "stream": false}'

这条命令是验证部署是否成功的关键一步。/api/generate是 Ollama 的生成接口，model参数指定模型名，prompt是输入内容，stream设为false表示等完整结果返回再打印。看到 JSON 返回里"response"字段有内容，说明推理引擎已经通了这个接口就是后面所有上层应用的入口，WebUI 也是靠它工作的。

2.3 模型推理参数：temperature 与上下文长度到底怎么设

很多人把模型拉下来直接聊，遇到回答质量不对就怪模型不行，其实是推理参数没调对。Ollama 的对话支持temperature、top_p、num_ctx这几个关键参数，它们直接在模型加载时生效。

# 指定参数运行模型 ollama run deepseek-r1:7b --temperature 0.7 --top_p 0.9 --num_ctx 8192

temperature控制随机性，0 到 1 之间，我一般写代码或做分析时用 0.5 左右，让输出更稳定；创意写作可以拉到 0.8 以上。num_ctx是上下文窗口长度，默认值是 4096，意味着模型只能记住最近 4096 个 token 的对话，超过的部分会直接丢掉。如果你喂给模型的长文档比较多，建议调到 8192 或更高，但注意上下文越长显存占用越大，7B 模型在 24G 显存下开到 8192 是安全的，再多就要观察显存余量了。

这里有个容易被忽略的坑：num_ctx不是你在 WebUI 聊天框里输入多少字就自动生效的，它是在模型加载层面就要分配好显存资源的。如果你在 WebUI 里发现了「聊着聊着模型突然忘了前面说的内容」，十有八九就是num_ctx没调够。后续接 WebUI 的时候，这个参数也要在界面里对应设置，否则你在命令行改了 WebUI 不认。

3. 给模型装一个看得见的脸：Open WebUI 的安装与配置拆解

3.1 Open WebUI 是什么，以及它和 Ollama 的分工

模型跑起来只是一个命令行黑匣子，你输入文字它回文字，没有任何界面。Open WebUI 是社区里最流行的可视化前端，它像浏览器一样运行在本地，你在网页里和模型对话，它负责把请求转发给 Ollama 的 API。你可以把它理解成：Ollama 是发动机，Open WebUI 是方向盘和仪表盘——发动机决定了马力，仪表盘决定了你开得顺不顺手。

Open WebUI 支持的玩法不只是聊天窗口，它自带多会话管理、提示词模板、文档上传（就是把文档喂给模型的关键入口）、模型切换下拉框。这些功能对于日常使用足够了，而且它是纯本地运行的，所有数据都存在你自己机器上的数据库里，不存在数据上传第三方的问题。部署方式我建议用 Docker，避免把 Python 依赖装得满系统都是，以后想卸载也干净。

3.2 Docker 部署 Open WebUI：命令逐行拆解

新手最怕的就是 Docker 命令一长串看不懂每个参数什么意思，我先把完整命令给你，然后逐行解释。

docker run -d \ --name open-webui \ -p 3000:8080 \ -v open-webui-data:/app/backend/data \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ --add-host=host.docker.internal:host-gateway \ --restart always \ ghcr.io/open-webui/open-webui:main

先看-d，表示后台运行容器，不占用当前终端。--name open-webui给容器起名，后续docker logs open-webui查看日志、docker stop open-webui停止服务都用这个名字。-p 3000:8080是端口映射，宿主机的 3000 端口映射到容器内部的 8080 端口，之后浏览器访问http://localhost:3000就是 Open WebUI 的页面。-v open-webui-data:/app/backend/data是数据卷挂载，你上传的文档、聊天记录、账号信息都存在这个数据卷里，容器删了数据还在，这是后悔药。

-e OLLAMA_BASE_URL=http://host.docker.internal:11434是整条命令的命门，它告诉容器去哪里找 Ollama 服务。host.docker.internal是 Docker 提供的一个特殊域名，指向宿主机本身。为什么不能直接写localhost？因为容器是一个隔离的环境，容器里的localhost指向容器自己，不是你的宿主机——这个细节是大多数人第一次部署翻车的重灾区，后面避坑章节我会专门讲。--add-host=host.docker.internal:host-gateway是 Linux 下让上面那个特殊域名生效的配置，Windows 和 macOS 的 Docker Desktop 不需要这一行，但加上也没坏处。--restart always表示机器重启后容器自动拉起，省得你手动docker start。

启动完成后，浏览器打开http://localhost:3000，第一次访问会让你注册管理员账号。注意这个账号是本地的，不是 DeepSeek 的账号，它只用来管理 Open WebUI 本身。

3.3 在 WebUI 里把模型接上并做一次完整对话

打开页面后在左上角或顶部应该能看到模型选择的下拉框。如果你确认 Ollama 已经跑起来了但下拉框是空的，先不要慌，大概率是OLLAMA_BASE_URL配错了或者容器内访问不到宿主机。验证方法是在宿主机上执行：

curl http://localhost:11434/api/tags

这个接口会返回本地所有模型列表。如果在宿主机上能返回 JSON 但 WebUI 里看不到模型，问题就在容器和宿主机的网络连通性上。此时进入容器内部检查：

docker exec -it open-webui sh # 进入容器后执行 wget -q -O- http://host.docker.internal:11434/api/tags | head

能看到 JSON 说明容器访问宿主机的链路通，看不到就检查--add-host参数是否正常。链路通了之后，在模型下拉框里选中deepseek-r1:7b，输入任意问题即可对话。如果对话时报错提示 connection refused，优先检查 Ollama 服务是否真的在宿主机上运行，ollama serve有没有执行。

WebUI 里还有一个重要的细节：聊天气氛参数在界面右侧的「设置」里可以调整，对应 Ollama 命令行的temperature、top_p等参数。如果你在命令行里设置了 8192 上下文，但 WebUI 这边的num_ctx还是默认 4096，那么命令行设置会被 WebUI 覆盖掉。所以统一在一个地方设置比较省心，我习惯直接在 WebUI 里调，因为命令行参数在容器化的部署方式下本来就不太好透传。

4. 数据投喂才是重头戏：知识库挂载与模型训练的两条路径

4.1 先分清投喂的两层含义：RAG 与微调

「数据投喂」这个词在网上被用得很模糊，很多人以为就是把文档丢给模型然后它就能学会里面的知识。实际上要分两种情况来理解。第一种是 RAG（检索增强生成），做法是把文档切块、向量化后存进数据库，每次提问时先检索相关片段拼到提示词里再让模型回答。这个方案的好处是改文档即时生效、不需要重新训练模型、对硬件要求低。第二种是真正的微调（Fine-tuning），用一批结构和答案都标注好的数据去更新模型权重，让模型从根上改变行为模式或掌握特定领域的表达风格。这个方案的效果更持久，但需要构造高质量数据集，训练过程也吃显存。

这份教程主推的是第一种路径，因为对绝大多数个人用户来说，RAG 已经能解决「让模型知道我的内部文档」这个核心问题。微调是进阶玩法，适合你发现 RAG 回答的措辞始终不自然、或者模型总是用不对你行业内的专业术语时再考虑。

4.2 用 Open WebUI 做知识库：文档上传与向量化

Open WebUI 内置了 RAG 功能，操作路径是页面上方的「文档」或「知识库」入口。点击上传按钮，把 PDF、TXT、Markdown 格式的文件拖进去，系统会自动完成文本提取和向量化。这个步骤背后需要一套嵌入模型（Embedding Model），Open WebUI 默认会去拉一个轻量级的嵌入模型到 Ollama 里。

第一次上传文档时页面可能会卡住几十秒，这是因为正在下载嵌入模型。你可以先在 Ollama 里手动确认：

ollama list

正常情况下会自动多出一个类似nomic-embed-text或bge-m3的模型。如果没有自动下载，说明 WebUI 的嵌入模型配置有问题，需要到管理员设置里手动指定。嵌入模型的作用是把文字变成一串数字向量，让计算机能从语义上判断相似度——为什么用「向量」而不是「关键词」？因为关键词匹配只能找到字面一样的句子，向量匹配能找到「意思相近但表述完全不同」的内容，这在文档问答里是决定体验上限的。

文档完成向量化之后，在聊天的模型选择下方会有一个「附加文档」的区域，勾选对应的知识库再提问，模型就会优先基于文档内容回答。这里有三个实用细节：一是提问用「根据文档内容，总结……」这类引导句式，可以明显降低模型自由发挥的概率；二是文档更新后需要删掉旧版本重新上传，因为 RAG 的向量库不会自动感知文件变化；三是知识库文件太多时，回答的检索质量会下降，保守做法是每个知识库控制在几百个文件以内。

4.3 真正的训练：用 LLaMA-Factory 微调 DeepSeek 的最小流程

如果你确实需要走到微调这一步，这份教程里给了基于 LLaMA-Factory 的实践路径。LLaMA-Factory 是目前社区里最友好的微调框架，支持 LoRA 这类参数高效微调方法，普通消费级显卡也能跑。准备工作需要 Python 3.10 以上环境、CUDA 版 PyTorch 以及一张显存至少 8G 的显卡。

数据格式最关键也最容易翻车。LLaMA-Factory 支持多种格式，新手最不容易出错的是 ShareGPT 格式，每条数据由对话轮次组成，结构如下：

[ { "conversations": [ { "from": "human", "value": "公司新员工的入职流程是什么？" }, { "from": "gpt", "value": "新员工入职第一天先到 HR 部门领取工牌和电脑，然后在 OA 系统完成账号激活……" } ] } ]

from字段只能是human或gpt，分别代表用户和管理员角色的发言。value是具体的对话内容。整个文件是一个 JSON 数组，每个元素是一段完整的多轮对话。新手最常犯的错误是格式对不上，比如在字段名后面多加逗号、中文引号写成了全角，微调框架解析不了就会直接报错。

数据准备好后，训练命令如下：

# 在 LLaMA-Factory 目录下执行 LoRA 微调 CUDA_VISIBLE_DEVICES=0 python src/train_bash.py \ --model_name_or_path deepseek-r1:7b \ --dataset alpaca_data \ --dataset_dir ./data \ --finetuning_type lora \ --output_dir ./output_lora \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 4 \ --learning_rate 2e-4 \ --num_train_epochs 3.0 \ --max_length 2048

model_name_or_path是基础模型的路径，可以是 HuggingFace 上的 DeepSeek 权重路径，也可以是本地下载好的权重目录。finetuning_type lora是参数高效微调的核心，它只训练一小部分新插入的参数而不是全部权重，显存占用和训练时间都大幅降低。per_device_train_batch_size 2表示每张卡一次处理 2 条数据，显存不够就调成 1。gradient_accumulation_steps 4是梯度累积步数，相当于每 4 步做一次参数更新，等效 batch size 就是 2 乘 4 等于 8——这个换算关系很实用，调参时你改的是这两个数的乘积，而不只是其中某一个。learning_rate 2e-4是 LoRA 微调最常用的学习率，一般不需要动。

训练完成后会得到一个 LoRA 适配器权重目录，这个目录体积很小，通常几十到几百 MB。使用的时候需要把基础模型和适配器合并，或者用 LLaMA-Factory 的 ChatBot 界面动态加载。直接改原模型不行，这是新手容易理解错的地方：LoRA 不是给模型打补丁改原文件，而是一个单独的小参数包，推理时必须配合基础模型一起加载。

5. 部署与训练避坑指南：五个高频故障的排查实录

5.1 WebUI 里看不到模型

现象：Open WebUI 页面能正常打开，图片样式都加载了，但模型下拉框是空的，一个选项都没有。

原因：容器内的 Open WebUI 无法访问到宿主机上的 Ollama API。最常见的情况是OLLAMA_BASE_URL写成了http://localhost:11434，而容器的 localhost 指向容器自身，容器里面根本没有 Ollama 服务。第二个常见原因是 Linux 系统下--add-host=host.docker.internal:host-gateway没加，导致host.docker.internal这个域名在容器内解析不了。

解决：先改容器环境变量，删除旧容器重新创建一个，把OLLAMA_BASE_URL设为http://host.docker.internal:11434，Linux 加上--add-host参数。创建完成后用docker exec -it open-webui sh进入容器，执行curl http://host.docker.internal:11434/api/tags验证连通性。这个排查顺序很重要，先确认宿主机 Ollama 本身是通的，再排查容器到宿主机的链路，不要一上来就重装 Docker。

5.2 对话时提示 connection refused

现象：WebUI 里能看到模型列表，但发一句话出去立刻报错，错误信息里出现 connection refused 或 connection reset。

原因：Ollama 服务没有在宿主机上运行，或者 Ollama 服务崩了。很多人在命令行窗口里跑过ollama run之后关了窗口，服务也随之停了。Win 系统下 Ollama 应该是常驻后台服务的，如果没装成功，会表现为 API 端口完全不通。

解决：到宿主机上执行ollama serve单独启动服务，保持终端开着；或者检查系统服务里 Ollama 的启动类型是否设成了自启。启动后立刻重新执行curl http://localhost:11434/api/tags看是否恢复。如果确认服务在跑但还是 refused，再检查系统防火墙是否拦截了 11434 端口。

5.3 长文档问答时模型「失忆」

现象：刚上传的几十页 PDF，文档内容也能检索到，但问几个问题之后模型开始回答得含糊，甚至直接说文档里没有相关内容。

原因：上下文窗口num_ctx设置太小。默认 4096 的窗口大约只能容纳 3000 个汉字左右的上下文，RAG 检索到的文档片段加上历史对话很快就把窗口塞满了，后面的内容直接被截断丢弃。

解决：在 Open WebUI 的管理员设置里把上下文长度调到 8192 或更高。同时注意，这个设置是按模型生效的，切换模型后需要重新确认。显存足够的条件下，7B 模型开到 8192 是安全的，14B 模型建议先看显存余量再往上加。

5.4 微调训练时 loss 不降反升

现象：LLaMA-Factory 训练跑起来了，loss 在低位震荡或者越来越差，生成的回答明显不像训练数据的风格。

原因：数据集里混入了大量噪声，比如问答不对应、多轮对话角色颠倒、或者指令和数据重合度太低。也有人会把测试集和训练集混在一起，模型学到的全是「正确答案」的重复记忆，真正的泛化能力反而掉下来了。

解决：随机抽 10% 的训练数据人工过一遍，检查对话是否通顺、答案是否准确。用脚本统计一下数据里的重复样本，重复超过三次的删掉。另外把num_train_epochs从 3.0 降到 1.0 试一下，epoch 过多在小数据集上很容易过拟合，loss 反而会上翘。

5.5 显存看着够用却 OOM 报错

现象：显卡驱动显示显存占用只有 50%，但模型加载或推理时报 CUDA out of memory。

原因：OOM 很多时候不是当前这一刻显存不够，而是显存碎片化。之前加载过其他模型退出了，但显存没完全释放干净；或者num_ctx调过大，给推理预留的 KV cache 空间超出了剩余显存。Windows 下还有个元凶是其他应用占用了显存，比如显卡驱动为桌面窗口管理分配的那部分。

解决：ollama ps查看当前加载模型占用的显存，ollama stop停掉不用的大模型。确认其他显存应用（浏览器硬件加速、游戏录制）关闭。把num_ctx先降到 4096 跑通再往上调。最后的手段是在服务环境变量里设置OLLAMA_MAX_LOADED_MODELS=1，限制同时加载的模型数量，这个参数防止 Ollama 自动把多个模型都塞显存里。

6. 进阶：从 API 封装到业务接入，一个可复用的调用链

前面几章解决的是「自己能聊起来」的问题，这一步解决的是「让本地模型变成你程序里的一个服务」。Ollama 的 API 遵循 OpenAI 兼容格式，这意味着很多原本对接 OpenAI 的代码，改一个 base URL 就能切到本地 DeepSeek。先看最基础的调用方式：

import requests response = requests.post( "http://localhost:11434/api/chat", json={ "model": "deepseek-r1:7b", "messages": [ {"role": "system", "content": "你是公司的技术支持助手，回答风格简洁专业。"}, {"role": "user", "content": "Nginx 502 报错一般怎么排查？"} ], "stream": False, "options": { "temperature": 0.5, "num_ctx": 8192 } } ) print(response.json()["message"]["content"])

这段代码的关键点是messages数组里除了用户消息之外还有一条system消息，它定义模型的角色。很多人写程序对接时忽略system消息，导致模型回答风格不可控。options字段里传的temperature和num_ctx和命令行一致，这样每次请求都能独立控制参数，而不是依赖服务启动时的默认值。注意stream设为False时接口会等完整结果返回，对于长回答可能要等十几秒，适合后端处理；如果要做打字机效果的流式输出，就改为True，用 SSE 协议逐 token 接收。

我常用这套 API 做自动化脚本，让模型批量处理之前人工标好的工单数据，输出结果存成 JSON 文件再回灌到知识库，这就完成了一个简单的数据闭环。

# 流式调用示例 curl -N http://localhost:11434/api/chat \ -d '{"model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "写一段 Python 快速排序代码"}], "stream": true}'

-N参数是禁用 curl 的缓冲，让内容边生成边打印出来。Open WebUI 前端打字机效果背后的请求就是这种形式，你理解了这个原理，就能自己写一个极简的聊天页面了。如果你有代码编辑器里的 Codex 类工具，也可以在配置里把模型 API 指向http://localhost:11434/v1，这个路径是 Ollama 的 OpenAI 兼容端点，原理和上面的api/chat一致，只是协议字段更接近 OpenAI 官方格式。

关于验证方法，我有一个习惯：每次部署完成后，不急着进 WebUI 聊天，先跑一轮自动化脚本。脚本里固定三个测试用例——一个事实性问答、一个代码生成任务、一个长文本总结任务，分别验证模型的应答稳定性、输出格式正确性和上下文处理能力。输出结果记录时间戳，这样下次换模型或改参数时能直接对比效果。这套验证流程的成本不到十分钟，但能避免在 WebUI 里聊半天才发现模型压根没正常工作。

最后说一个我吃过的亏：第一次部署时我把num_ctx调到了 16384，跑了不到十分钟 OOM，我当时以为是模型有问题，折腾着换了别的模型，结果问题反而更严重。后来才意识到上下文不是越大越好，它和显存是线性关系。从那以后，我每次调参都先在命令行里用ollama ps看显存占用，再进 WebUI 做长文本测试，两步走完才会继续下一步。部署大模型这事，翻车点多在细处，希望这篇实操记录能帮你绕开我踩过的坑。

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