企业官网建设流程全解析

把一台高端移动工作站抱回家，我第一件想干的事，不是跑分，不是剪视频，而是看看它能不能扛起本地大模型这摊活。这台戴尔Precision 5690到我手上之后，我直接在它上面部署了一套 DeepSeek 本地服务，又配了 LobeChat 做前端聊天界面，整套下来基本不依赖公网大模型 API，数据全在机器里跑。折腾了几天，踩了不少坑，也把这块 RTX 系专业显卡在本地推理场景下的真实水平摸了个透。这篇就给同样想在移动工作站或高性能笔记本上自建 AI 助手的同学一个完整的参考，从模型选择、环境配置到实际生成速度和散热表现，我都会写清楚。

1. 硬件底子与选型思路

1.1 为什么拿移动工作站来跑本地大模型

先说个很多人会问的问题：跑本地大模型，买台游戏本不就行了，为什么非得是 Precision 5690 这种移动工作站？

游戏本和移动工作站的核心区别，不在于跑分高低，而在于两个词：稳定性和验证。

游戏本的显卡驱动、散热策略是围绕“短时间高分”调校的，跑个三分钟 benchmark 能飙到满功耗，但你要是让它连续推理一两个小时，很多机器会撞温度墙降频，生成速度直接从 40 token/s 掉到 15 token/s。而移动工作站整机功耗墙、散热模组、风扇策略都是为长时间满负载设计的，Precision 5690 这类机器里甚至有独立的散热管理固件，可以针对不同负载场景动态调整风扇曲线。做本地模型推理，尤其是跑 14B 以上参数的模型，一跑就是几十分钟起步，这类长时间负载恰恰是游戏本的弱项。

另一个是专业显卡的生态。Precision 5690 可选配的 RTX 专业卡，虽然游戏帧率不一定打得过同价位游戏本，但它有完整的 ISV 认证、更稳的驱动分支、更大的显存位宽和 ECC 显存支持（部分型号），这些对 CUDA 推理、长时间高精度浮点运算都是实打实的加成。跑模型的人都知道，显存容量直接决定你能跑多大的模型，而显存稳定性和驱动兼容性决定你跑模型的时候会不会动不动崩。

1.2 我这台的配置和第一感受

我这台 Precision 5690，具体配置是：Intel Core Ultra 9 处理器，64GB DDR5 内存，1TB 固态硬盘，显卡是 16GB 显存的 RTX 3500 Ada Generation（那是同一个核心）。这套组合放在 2025 年的移动工作站里算中高配了，当时选它也是冲着 16GB 显存去的，因为 7B 和 14B 量级的量化模型，16GB 刚好能整体塞进显存，不至于到 CPU 和显卡之间来回搬数据。

第一印象是这机器比我预想的沉一点，全金属机身加上大电池，单手拿着有点分量。不过键盘手感和屏幕素质确实好，尤其是那块高分辨率屏，长时间看代码、看对话日志，眼睛疲劳度比普通笔记本低不少。开机之后我先干了两件事：一是更新显卡驱动到专业分支最新版，二是装好 CUDA 工具链。这俩没搞干净，后面部署模型会出一堆莫名其妙的报错。

2. 部署前的环境准备

2.1 系统与驱动：先把地基打牢

我最后确定在 Windows 11 上直接部署，不套 WSL2。原因很简单：Ollama 对 Windows 有原生支持，LobeChat 我用 Docker Desktop 跑，也不依赖 Linux 子系统，没必要为了“看起来专业”白白多一层虚拟化开销，尤其是显存透传那一层，Windows 原生跑 CUDA 是最省心的。

驱动方面踩过一个坑：一开始用的是显卡厂商自动更新拉下来的驱动，版本很新，但 nvidia-smi 里显示的 CUDA 版本和 Ollama 运行时要求的对不上，导致推理时 CUDA error。后面我直接去 NVIDIA 官网按“RTX 3500 Ada + Windows 11”筛选，下载了对应分支的 Studio 驱动，装完重启再跑 nvidia-smi，CUDA 版本显示 12.x，问题就消失了。

驱动装好之后，建议顺手装一下 CUDA Toolkit，虽然 Ollama 自带了 runtime，但装一份完整的本地 CUDA 工具链，后续想用其他框架调试模型会方便很多。

2.2 推理框架选型：为什么是 Ollama 而不是 llama.cpp

现在本地跑模型的工具很多，我最后选了 Ollama，主要看中三点：模型管理省心、显存策略合理、周边生态成熟。

llama.cpp 我也用过，它的控制力最强，什么--gpu-layers、-t线程数都能手动调，但代价是模型文件得自己找 GGUF 格式、自己写命令、自己管上下文窗口，配置成本高。LM Studio 则是图形界面友好，但脚本化和远程接入方面不够方便，给 LobeChat 当后端时多少有点别扭。

Ollama 把模型下载、量化格式选择、显存 offload 策略都自动处理了，而且它把模型抽象成“一条ollama run命令就能跑”的服务，默认暴露一个 HTTP API（端口 11434），这对接 LobeChat 简直是无缝的。另外 Ollama 可以设置OLLAMA_MAX_LOADED_MODELS、OLLAMA_NUM_PARALLEL这些环境变量来控制显存占用，实际调参空间也够用。

三个框架的取舍我做了个对比表，方便你根据自己的情况选：

2.3 显存和内存：跑之前先算一笔账

这一步很多人会忽略，但我觉得是整套部署里最值得花时间的地方。

大模型推理的显存占用大约是：模型权重文件大小 + KV Cache + CUDA context 开销。以 14B 模型 Q4_K_M 量化为例，权重文件约 9GB，KV Cache 在 4096 上下文下大概 1GB 左右，加上 CUDA 本身占的几百 MB，16GB 显存刚好能放下，而且还能留出 3GB 左右给其他应用。

但你要是上 32B 模型，Q4 量化权重就 20GB 左右了，16GB 显存无论如何塞不下，只能让 Ollama 把大部分层放到内存里用 CPU 计算，速度会断崖式下降。这也是我做模型选型时的核心判断依据，详见下一节。内存方面，Windows 本身占 8GB 左右，加上 Ollama 进程开销和浏览器，建议至少 32GB 起步，64GB 比较舒服。

3. DeepSeek 本地模型部署实操

3.1 模型规格怎么挑：7B、14B 还是 32B

DeepSeek 官方开源了很多版本，但本地部署的时候，我们要分清一个概念：原版稠密模型和蒸馏小模型。

原版模型参数量太大（动辄几百B），不是移动设备能碰的。适合本地部署的是 R1 系列蒸馏版，比如基于 Qwen 蒸馏的 7B、14B、32B 版本，它们保留了推理链路中的核心能力，但参数量压缩到了个人设备能承载的范围。

模型规格的选择，直接由显存决定，我的建议是：

• 7B：任何 8GB 以上显存的显卡都能跑，Q4 量化权重约 4.4GB，速度最快，适合尝鲜和泛化问答。
• 14B：16GB 显存跑得舒服，Q4 量化权重约 9GB，推理质量和速度的平衡点最好，是目前移动工作站的甜点区间。
• 32B：24GB 显存以上才建议认真跑，16GB 强行跑只能部分 offload，速度会比较难受。

我最后主力用的是 14B 版本，偶尔切到 7B 做对比测试。

3.2 用 Ollama 拉取 DeepSeek 模型

Ollama 的模型仓库里有现成的 DeepSeek R1 蒸馏版本，拉取命令很简单。

# 拉取 7B 版本 ollama pull deepseek-r1:7b # 拉取 14B 版本（我主力用的这个） ollama pull deepseek-r1:14b # 查看本地已安装的模型 ollama list

第一次拉取会把整个量化模型文件下载下来，14B 的 Q4_K_M 大概是 9GB 左右，网络好也要等一阵。Ollama 支持断点续传，中途断了重新拉就行，不用从头下。

模型拉下来之后，简单测试可以这样：

ollama run deepseek-r1:14b "用三句话解释什么是大模型推理"

看到正常的文字流式输出，说明模型已经成功加载并能稳定推理了。

这里有个细节要提：Ollama 默认会用 Q4_K_M 量化格式，这个量化级别在质量和体积之间比较均衡。如果显存比较紧，可以在拉取命令后面加:q3_K_M之类的标记指定更低精度的量化版本，但会牺牲一点生成质量。我实测下来，Q4 和 Q8 在 14B 上的中文生成质量差异，普通对话场景基本感觉不出来，但 Q3 在某些专业术语上就开始出现语义偏差了，所以不建议为了省 1GB 显存去用 Q3。

3.3 调整并发与上下文参数

Ollama 默认的并发参数比较保守，在 16GB 显存的机器上，如果不调整，它一次只能跑一个请求，而且上下文窗口默认只有 2048 token。我在实际使用中做了两个调整：

第一个是增大上下文窗口。在 LobeChat 里提问时经常要贴很长一段代码或者文档，2048 token 不够用，所以我通过环境变量把上下文调到了 8192。修改方式是在 Windows 系统环境变量里新建：

OLLAMA_CONTEXT_LENGTH=8192

第二个是并发数。LobeChat 本身可能开多个会话，或者你一边在网页上用一边在终端里调，Ollama 默认的并发上限太低，会导致后发的请求排队等待甚至超时。我设了：

OLLAMA_MAX_LOADED_MODELS=2 OLLAMA_NUM_PARALLEL=2

注意，这两个参数不是设得越大越好。并发数越高，显存的 KV Cache 占用就越大，如果同时跑两个 14B 模型，16GB 显存瞬间就会被吃满，甚至触发 OOM。我自己实测，OLLAMA_NUM_PARALLEL=2配合 14B 已经够了，再往上性能反而下降，因为显存带宽被多路请求争抢。

4. LobeChat 前端搭建与接线

4.1 前端选型：为什么是 LobeChat

模型后端跑起来了，但纯命令行交互总归不直观，日常用还是得有个聊天界面。市面上接 Ollama 的前端不少，我选 LobeChat，主要是三点：界面设计现代、插件生态完整、模型管理灵活。

LobeChat 默认界面就跟 ChatGPT 类似，左右栏结构、会话历史、消息流式显示都做得很完整，而且它可以在同一套界面里同时配置多个本地模型和多个云端模型，自由切换。也就是说，公网 API 没断的情况下，你甚至可以在同一个对话里先让本地 14B 回答，再切到云端大模型做结果对比，这种组合在调模型、做评测的时候就非常方便。

另外 LobeChat 支持插件机制、联网搜索（通过工具调用），虽然本地模型对工具调用的支持参差不齐，但前端层面它已经把这些功能都预留好了，后期想扩展不用换前端。

4.2 Docker 部署 LobeChat

LobeChat 官方推荐用 Docker 部署，我也是这么干的。Windows 上先装好 Docker Desktop，然后把镜像拉下来：

docker pull lobehub/lobe-chat

启动命令最简版是这样：

docker run -d -p 3210:3210 \ --name lobe-chat \ --restart=always \ lobehub/lobe-chat

端口我用了默认的 3210，启动完成后直接浏览器访问http://localhost:3210就能打开界面。

但有一个很关键的坑：LobeChat 容器要访问宿主机上的 Ollama，不能直接用localhost:11434，因为在 Docker 容器里，localhost指向的是容器自己，而不是宿主机。需要把 Ollama 的地址映射成宿主机网关地址，在启动容器时加一行：

docker run -d -p 3210:3210 \ --name lobe-chat \ --add-host=host.docker.internal:host-gateway \ --restart=always \ lobehub/lobe-chat

如果忘记加这一行，后面在 LobeChat 里配置 Ollama 连接时，无论填http://localhost:11434还是http://127.0.0.1:11434，都会一直报连接失败。这个我一开始踩了个结实，排查了好久。

另外镜像拉取速度的问题也顺带说一句：国内网络环境下，直接从 Docker Hub 拉大镜像经常速率感人，建议给 Docker Desktop 配置一个镜像加速器，具体地址每家服务商不一样，配置完重启 Docker Desktop 再拉，速度快不少。

4.3 在 LobeChat 里配置 Ollama 提供商

LobeChat 界面跑起来之后，进入左下角设置，找到“模型提供商”或者“AI 服务商”一栏，选择 Ollama，然后填两样东西：

• 服务地址：http://host.docker.internal:11434
• 模型标识符：deepseek-r1:14b

模型标识符一定要跟ollama list里显示的 tag 完全一致，比如deepseek-r1:14b，大小写、冒号都不能错。填完之后点检测连接，显示成功，然后把该模型勾选启用到对话列表中。

前端也顺手设置一下参数。LobeChat 里每个模型可以单独调 temperature（温度）、top_p 这些采样参数。我实测下来，DeepSeek R1 14B 在 temperature 设 0.7 左右时，回答质量最好，既有逻辑性又不会太死板；设到 1.0 以上，创造性内容多一些，但容易开始胡编。日常问答我直接保持在 0.7。

4.4 页面配置与对话实测

首次进 LobeChat，它会有一个默认助手，我是直接改成了自己的“本地知识助手”，把系统提示词设为“你是部署在本地的工作助手，回答要简洁、准确，必要时分点”。

连接好之后，我做了几轮实际对话验证。第一轮是文本理解类的：“把下面这段项目需求拆成五个可执行任务，用列表输出”，14B 的回答质量很不错，条理清楚，没有明显漏项。第二轮是代码生成类的：“用 Python 写一个读取 CSV 文件并统计每列缺失值的函数”，生成的代码基本可以直接用，只有一处边界情况需要手动补。第三轮是文档总结类的，粘了一段长文档，模型也能准确提炼出要点。

这基本上验证了整套链路是通的：用户在浏览器输入 → LobeChat 前端 → Docker 容器 → host.docker.internal → Ollama API → GPU 推理 → 流式返回前端。

5. 性能实测：速度、显存、功耗与散热

5.1 生成速度实测：不同模型的 token/s

跑本地模型，大家最关心的就是速度。我实际测了三档模型在 16GB RTX 3500 Ada 上的生成速度，数据是在模型完全加载到显存之后、连续对话第二三轮时取得的，取稳定值：

14B 在 38 token/s 的生成速度下，体验和云端的正常速度基本接近了，你打一句话进去，它开始流式输出的时候几乎没延迟，这也是为什么我说 16GB 显存跑 14B 是这台机器的甜点区间。

32B 的成绩有点尴尬，7 token/s 意味着写一段 200 字的回复要等将近一分钟，网页上体验很吃力。我试过把上下文从 8192 降到 4096，速度能稍微提到 9 token/s 左右，但依然比不上 14B 的畅快感。所以我的结论是：如果你只有 16GB 显存，老老实实用 14B，别硬上 32B。

5.2 显存和内存占用细节

推理过程中我开着任务管理器观察过显存曲线：14B 模型加载完成瞬间显存占用跳到 11GB 左右，之后对话过程中有小幅波动，主要是 KV Cache 随上下文长度变化。如果连续对话超过 3000 token，显存占用会涨到 12GB 上下，这时候如果同时开着 Chrome 硬解视频，显存就逼近 13GB，离 16GB 上限还有一点余量，但已经不能再开大模型并发了。

内存方面，Ollama 进程在 14B 推理时大约占用 1.5GB 系统内存，加上模型的 CUDA context，整套系统在 Windows 下内存占用稳定在 20GB 左右，64GB 内存完全不会有压力。

5.3 功耗与散热表现

长时间推理和短时间跑分不一样,它对散热的要求更高。我分别测了插电和电池两种场景。

插电状态下，14B 模型连续推理 30 分钟，CPU 封装功耗稳定在 35W 左右，GPU 功耗在 65W 到 75W 之间波动，整机峰值功耗能摸到 170W 附近。此时 CPU 温度在 82 到 88 度之间浮动，GPU 温度压在 72 度左右。键盘中心区域有一点温热，但不烫手，风扇声音是明显的“工作声”，大概 50 分贝出头，戴耳机无感，不戴耳机在安静房间里有点明显。

电池状态下就完全不一样了。同一模型跑起来，整机功耗被压到 90W 以内，GPU 频率明显下降，生成速度直接降到 22 token/s 左右，而且电池模式下风扇策略更激进，温度倒是更低，但速度损失是切切实实的。所以如果你要长时间跑模型，强烈建议插电用，不要在电池模式下期待满血性能。

5.4 长时间负载下的稳定性

为了验证移动工作站的“长时间稳定”卖点，我特意做了一次 90 分钟的连续压力测试：脚本里循环调 Ollama 接口，模拟真实对话场景，跑满 90 分钟。结果是没有一次进程崩溃、没有一次 CUDA error，速度在前 60 分钟几乎是一条直线，最后 30 分钟因为上下文填充和历史消息累积，单次请求速度略有下降，但属于正常的 KV Cache 开销，不是降频导致的。

这个结果让我挺满意的，游戏本在这个时长下大概率会撞一次功耗墙或者温度墙，但这台机器扛下来了。移动工作站贵出来的那一截，买的就是这种“长时间稳定输出”的底气和各种认证带来的可靠性。

6. 常见问题与排查实录

这几天的部署过程中，我遇到并且解决了不少问题，挑几个典型的整理成速查表，能帮你少走弯路：

其中最烦的一个问题是 CUDA error，我最开始以为是模型文件损坏，把模型删了重新拉一遍，依然报错，后来才想到是驱动版本的问题。换驱动之后错误彻底消失。所以提醒各位：部署大模型之前，先把驱动环境弄干净，这一步省下来的时间比什么都值。

另外一个小技巧：Ollama 的日志能解决很多诡异问题。Windows 上 Ollama 日志默认在C:\Users\<用户名>\.ollama\logs\下，遇到问题时先看最后几十行日志，比瞎猜原因高效得多。我排查 docker 连接失败那一次，就是看 Ollama 日志发现它根本没有收到任何来自 LobeChat 的请求，从而断定问题出在容器网络而不是模型服务。

7. 一些更接地气的使用建议

整套环境跑通之后，机器在我这里的角色从“高性能笔记本”转变成了“随时在线的本地 AI 助手”。但有几个使用习惯和场景上的建议，我觉得值得单独写一写。

第一是数据安全场景。我用 LobeChat 接本地 DeepSeek 这套组合，最大的价值是不用把对话内容传到任何外部服务。我自己处理一些敏感文档时，会直接复制内容到前端让本地模型提炼要点，心里踏实。这个优势是云端 API 给不了的，也是本地部署最大的意义所在。

第二是移动场景。Precision 5690 虽然重，但它是真的能装进包里带走的。我带它出过两次差，在高铁上、在酒店里，不需要网络也能跑模型，这解决了很多“离线环境下也需要智能助手”的问题。虽然电池模式下速度会折半，但 7B 模型在电池下还能跑到 35 token/s 左右，简单问答完全够用。

第三是模型切换的习惯。我一开始图新鲜，什么模型都想跑一遍，后来发现日常使用根本不需要那么多。我现在的固定搭配是：14B 做主力，7B 做快速草稿和意图理解，32B 留给需要长思考链的复杂问题时偶尔切过去用。切换方式就是在 LobeChat 左上角选择不同模型，底层 Ollama 会自动加载对应模型，不需要重启服务。

最后分享一个小技巧：如果你发现自己常用的本地模型有些回答质量不稳，可以先检查一下是不是上下文窗口被长轮对话塞满了。我的习惯是每个会话的主题尽量单一，聊偏了就新开会话，这样既保证速度，也减少模型被无关上下文干扰的概率。

这套本地 AI 组合，目前已经是我日常办公流的一部分。在移动工作站上部署本地大模型的整个过程中，个人体感最深刻的一点是：硬件选型决定上限，模型调度决定体验，而前端的价值是把这套东西变得真正可用。希望这篇踩坑记录对你也有用。