企业官网建设流程全解析

简介：面向希望摆脱在线服务波动、重视隐私与本地响应速度的 DeepSeek 使用者，这份 docx 教程文档围绕 Ollama 与 ChatBox 搭建本地对话环境展开，适合具备基础电脑操作经验、想深入了解大模型实际应用的爱好者与专业人士。内容覆盖 Ollama 安装、按硬件配置选择 1.5B、7B 或 32B 模型、模型下载与运行、ChatBox 图形界面接入及常见问题说明，并提示当前方案暂不具备联网检索能力，便于读者建立清晰预期。压缩包共 1 个 docx 文件，大小约 1.28MB，轻量易存，适合按章节查阅和随手检索。已有 3698 人学习，说明该主题受到持续关注。读者可借助文档中的工具获取路径、版本选择参考与排错思路，搭建可自主控制的本地 DeepSeek 环境，在平台拥堵或服务中断时保持研究和工作连续性，同时加深对预训练语言模型部署流程的理解。

1. 为什么有人在本地跑一份 DeepSeek：三个绕不开的场景

线上服务排队、限流、忽然返回一句"服务繁忙"，是很多人第一次动 DeepSeek 本地部署念头的原因。我最初也是被逼的：一份带内部字段的日志要交给模型分析，贴到网页端之前手在发送键上停了几秒。本地跑一份的好处很实在，请求不出本机，响应不排队，断网也能用，代价是要自己管模型文件、显存和客户端配置，出问题没人替你兜。

这套 Ollama 加 ChatBox 的组合是当前门槛最低的一条路：Ollama 负责把模型拉到本地并以常驻服务的形式对外提供接口，ChatBox 负责给你一个能存历史、能切模型、能改系统提示的界面。它适合不想再和服务可用性较劲的人，也适合手里只有一台 16GB 内存笔记本、想先摸清量化模型能力边界的人。下面按装运行时、拉模型、接客户端、调参数、排错的顺序走一遍，命令和参数都给到能直接抄的程度。

2. Ollama 装完到模型落地：三条命令、四个路径和一张选型表

2.1 Ollama 装的不是模型，是一个常驻服务

新手最容易误解的一点：Ollama 不是"一个模型"，它是一个本地推理运行时。装完之后它做的事情有两件，一是把各种开源权重按统一格式管理起来，二是在本机起一个 HTTP 服务，默认监听127.0.0.1:11434，开机自启常驻后台。模型权重是另外下载的，所以刚装完就跑ollama list，看到一张空表是正常现象，不是装坏了。

Windows 上双击安装包，一路下一步，装完托盘区会出现一个羊驼形状的图标，点它能看状态和退出；macOS 把应用拖进 Applications；Linux 用官方脚本一行装完。验证方式统一：打开终端或命令行，敲ollama --version，有版本号回显就说明二进制在 PATH 里了。如果提示"不是内部或外部命令"，九成是装完没重开终端，环境变量没刷新。

真正需要提前规划的是模型存放路径。默认位置在 Windows 是C:\Users\<用户名>\.ollama\models，macOS 是~/.ollama/models，Linux 走 systemd 时常见在/usr/share/ollama/.ollama/models。7B 量化权重四五个 GB 起，32B 直接二十 GB 上下，几个模型叠一起，系统盘很快就见底。我一般装完第一件事就是把目录挪走。

# Windows：把模型目录迁到 D 盘，避免系统盘被权重撑爆 [Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\ollama\models", "User") # 设置完必须重启 Ollama 服务才生效：托盘图标右键退出，再从开始菜单启动 # 然后确认变量确实写进去了 [Environment]::GetEnvironmentVariable("OLLAMA_MODELS", "User")

# Linux：用 systemd 覆盖方式改目录，不要直接改 /etc/systemd/system 下的原文件 sudo systemctl edit ollama.service # 在打开的编辑器里写： # [Service] # Environment="OLLAMA_MODELS=/data/ollama/models" sudo systemctl daemon-reload sudo systemctl restart ollama

OLLAMA_MODELS这个变量只影响新下载的模型存放位置，已经下好的文件不会自动搬过去，需要手动剪切整个models目录到新路径，否则服务重启后看到的是两份互不相认的仓库。systemctl edit而不是直接编辑原 unit 文件，是因为包管理器升级时会覆盖原文件，覆盖目录则会被保留。设置完成后可以用ollama list复验，如果模型不见了，先查路径对不对，再去查变量有没有真的被服务进程读到。

2.2 拉取 deepseek-r1：pull、run、list 的差别

原文给的入口是模型库页面，命令行侧其实只有三个动作要分清。pull只下载不启动，run是"没有就先下、有就直接进对话"，list是盘点。很多人习惯直接run，结果在一个大模型下载到一半时误以为卡死，其实只是网速慢，进度条在刷。

# 只下载，不进入交互，适合先挂机拉完再统一验证 ollama pull deepseek-r1:7b # 下载（若本地没有）并直接进入交互式对话，退出用 /bye ollama run deepseek-r1:7b # 盘点本地已有模型及其体积 ollama list # 看当前有哪些模型正驻留在内存/显存里，跑完不用的可以释放 ollama ps

标签语义要拎清楚：deepseek-r1是仓库名，7b是标签，冒号后面不写则默认latest。这意味着ollama run deepseek-r1和ollama run deepseek-r1:7b拉到的可能不是同一份权重，配置客户端时如果模型名和ollama list里的字符串不完全一致，就会报模型不存在。我踩过一次，客户端里手写成deepseek-r1，服务端只有deepseek-r1:7b，报错信息含糊，查了十几分钟。

下载中断是另一个高频场景。Ollama 的拉取是分片续传的，网络抖动后重新执行同一条pull命令，它会从断点继续，不用删掉重来。判断是否真的在动，看进度百分比而不是看是否"卡住"，几十 GB 的模型在网络条件一般的情况下挂半小时很常见。

2.3 版本怎么选：一张硬件账

官方给的档位是参考线，不是硬门槛。下面这张表按原文给的三档整理，补上了权重体积和实际体验的判断：

需要建立一个正确预期：Ollama 支持按层把模型拆到 GPU 和 CPU 上，显存不够不等于跑不起来，只是把一部分层卸载到内存里，速度掉一个量级。所以"我这台机器能不能跑 32B"这个问题，答案通常是"能，但你可能不愿意等"。真正决定体验的是显存能装下多少层，而不是模型总量。

还有一个隐藏参数会显著影响显存占用，就是上下文长度num_ctx。默认值往往比你以为的小，调到 8K 或 16K 之后，KV cache 会额外吃掉一到两个 GB。所以先按 7B 起步，跑顺了再往上加，是最省事的路径。原文推荐 7B 是合理的，绝大多数办公本和游戏本都能撑住。

3. ChatBox 接本地模型：四个字段填错三个就跑不通

3.1 终端能用，为什么还要一个客户端

ollama run的交互界面能出结果，但用起来别扭：不能保存会话历史，不能中途改系统提示，复制一段长回答要滚半天，切模型意味着退出重进。更麻烦的是它把"思考过程"和"最终回答"混在一起刷屏，R1 这类会先输出推理链的模型尤其明显。

ChatBox 这类客户端解决的是交互层的问题：会话管理、多轮上下文、提示词预置、模型快速切换、回答导出。它本身不含模型，只是一个前端，通过 HTTP 把请求打到本机的 Ollama 服务上。理解这个关系很重要，因为一旦出错，你要判断是前端配置问题还是后端服务问题，而这两者的排查路径完全不同。

原文给的是官网下载页，装完首次启动会弹一个引导窗口让你选"使用自己的 API Key 或本地模型"。手快关掉了也不慌，进设置里的"添加自定义提供方"是同一个入口。

3.2 四个字段怎么填

配置项在不同版本里叫法略有差异，但核心就四个：

API Key 这一栏劝退过不少人。本地 Ollama 服务默认不做鉴权，这个字段纯粹是客户端表单的必填校验，填local或者任意字符都能过。反过来，如果哪天你把服务暴露到局域网，这个"随便填"就会变成真实风险，那时要在前面加一层带鉴权的反向代理，别指望 Ollama 自己拦。

域名那一栏的坑在于路径拼接。用 Ollama 原生模式时填http://127.0.0.1:11434即可，客户端会自己拼/api/chat；用 OpenAI 兼容模式时，有些客户端要求填到http://127.0.0.1:11434/v1，有些要求只填根地址由它自己补/v1。填错的表现是 404，而不是连接失败，这个区别很有用：连接被拒说明服务没起或端口不对，404 说明服务通了但路径不对。

3.3 先用 curl 绕开客户端验证

我习惯在配客户端之前，先用命令行确认后端是活的。这一步能省掉大量"到底是前端还是后端"的扯皮。

# 1. 服务是否在监听，能否列出模型 curl http://127.0.0.1:11434/api/tags # 2. 直接发一次生成请求，stream 关掉方便看完整返回 curl http://127.0.0.1:11434/api/generate \ -d '{"model":"deepseek-r1:7b","prompt":"你是谁","stream":false}' # 3. OpenAI 兼容端点也试一下，客户端走兼容模式时用得上 curl http://127.0.0.1:11434/v1/models

第一条返回一段 JSON，models数组里能看到deepseek-r1:7b，说明服务活着且模型就位。第二条请求体里stream: false是关键，默认是流式返回，命令行里会看到一坨一坨的 JSON 分片，不方便判断完整性。第三条能通，说明兼容层可用，客户端选 OpenAI 兼容模式也能接。

后端确认没问题后回到 ChatBox，保存配置，随便发一句"你是谁"。R1 系列会先吐一段推理过程再给结论，看到它自称 DeepSeek-R1 就算通了。此时这套系统是纯离线的，没有联网检索能力，问它今天的新闻它会一本正经地答不上来或者编。这个边界要提前跟用的人讲清楚，否则第一次用就会怀疑是不是部署错了。

4. Modelfile 改参：把 temperature 和 num_ctx 调到能用

4.1 先读出一份模型的默认配置

不要凭感觉调参，先把官方那份 Modelfile 打出来看。ollama show有三个层级的用法，越往下越细：

# 概要：参数量、量化方式、上下文长度、能力标记 ollama show deepseek-r1:7b # 只看参数区，最省事的一屏 ollama show --parameters deepseek-r1:7b # 完整 Modelfile，包含 TEMPLATE、SYSTEM、PARAMETER 三段 ollama show --modelfile deepseek-r1:7b

--modelfile的输出里，TEMPLATE段决定了对话如何被拼成模型认识的格式，R1 这类带思考链的模型，模板里通常有特殊标记区分推理段和回答段。这一块别乱改，改了容易出现"回答到一半开始重复"或者"把思考过程当正文输出"。PARAMETER段才是我们的操作区，常见的有temperature、top_p、num_ctx、stop。

把输出重定向存一份，改参时以它为底稿，比从零手写稳。

4.2 写一个自己的 Modelfile 并构建

假设我要一个"只答技术问题、回答简短、上下文放到 8K"的版本，新建一个纯文本文件，文件名就叫Modelfile，内容如下：

# 基于已下载的 7B 权重派生，不会重复下载模型文件 FROM deepseek-r1:7b # 采样温度：技术问答偏低一点，减少发散 PARAMETER temperature 0.6 PARAMETER top_p 0.9 # 上下文窗口：调到 8192，注意这会额外占用显存 PARAMETER num_ctx 8192 # 单次最多生成多少 token，防止跑飞 PARAMETER num_predict 1024 # 重复惩罚，长回答开始复读时可以往上加一点 PARAMETER repeat_penalty 1.1 # 系统提示：约束角色和输出风格 SYSTEM """你是一名严谨的技术助手。回答用中文，先给结论，再给两到三条理由，不要寒暄。"""

在该文件所在目录执行构建命令：

# 注意最后那个点代表当前目录，缺了会报找不到 Modelfile ollama create r1-tech -f ./Modelfile # 确认新模型出现在列表里，体积应与底座接近而不是翻倍 ollama list # 用新名字跑起来 ollama run r1-tech

FROM指向本地已有模型，构建过程只是重新打包配置层，几秒钟完成，磁盘增量很小。如果构建日志里出现 pulling，说明FROM写错了，Ollama 认为你要重新拉一个不存在的模型。ollama create生成的模型名就是你在客户端里要填的名字，所以起名别用中文和空格，r1-tech这种短横线风格最省事。

派生模型和底座是并列关系，不是覆盖关系。删掉底座，派生的那个会一起失效，所以别急着ollama rm原始模型。要改参数就重新create一次同名模型，Ollama 会覆盖旧的那份。

4.3 参数对照与典型取值

把几个真正影响体验的参数列清楚，剩下的可以默认：

num_ctx是最容易被低估的一个。它不只是"能塞多长的对话"，还直接决定 KV cache 的大小，而 KV cache 是随上下文线性增长的显存开销。7B 模型在 4K 上下文下 4GB 显存勉强够，开到 16K 就可能要往下卸载层。所以调整顺序建议是：先固定num_ctx，再调采样参数，最后才动num_predict。

另外提醒一句，客户端里往往也有自己的上下文设置项，它和服务端的num_ctx是两回事。客户端那个控制"带多少轮历史发给服务端"，服务端那个控制"模型能吃多少 token"。两边不一致时，表现是聊到十几轮之后模型突然"失忆"，其实是客户端把历史裁掉了。

5. 本地部署避坑：5 个翻车现场与一条固定排查顺序

5.1 五个高频翻车现场

现象一：ollama run卡在 pulling，进度长时间不动。原因多数不是死锁，而是分片下载在弱网下超时重试，或者目标磁盘空间不足导致写入失败。先看目标盘剩余空间，OLLAMA_MODELS指到哪个盘就查哪个盘；空间够的话 Ctrl+C 中断再重新执行同一条命令，Ollama 会从断点续传，不需要删缓存。如果反复卡在同一个百分比，换个时间段重试，或者直接用资源包里备好的离线权重导入。

现象二：模型加载时报内存不足，或者加载完机器卡成幻灯片。原因是把模型总量当成了显存需求。7B 量化权重 4～5GB，加上num_ctx带来的 KV cache，实际占用比列表里显示的数字高一截。解决路径有两条：一是换小一号的标签，7B 降到 1.5B；二是显式控制卸载层数，设置OLLAMA_NUM_GPU只让部分层上 GPU，其余走内存，速度慢但能跑完。用ollama ps能看到加载后有多少比例在 GPU 上，那个百分比就是判断依据。

现象三：ChatBox 保存配置后对话报错，要么连接被拒，要么 404。连接被拒说明服务没起或者端口不对，先在浏览器打开http://127.0.0.1:11434看有没有响应，没响应就去托盘重启 Ollama；404 说明服务通了但请求路径不对，检查域名栏是不是多写了/api/chat或者漏了/v1。还有一种情况是模型名对不上，客户端填deepseek-r1、服务端只有deepseek-r1:7b，报错文案通常很含糊，直接复制ollama list里的完整字符串最保险。

现象四：回答说到一半突然停住，或者长文档读到后面就"忘了"前面。前者是num_predict太小，输出被硬截断，调到 1024 以上通常解决；后者是num_ctx不够，超出窗口的部分被直接丢弃，不是模型记性差。这两个参数在自定义 Modelfile 里都能改。另外 R1 会先输出思考链，思考链本身也吃 token 预算，感觉"没说完就结束"时，先确认是不是预算被推理段耗光了。

现象五：系统盘莫名少了几十 GB，ollama list里却只有一两个模型。原因是中途中断的下载会在模型目录里留下未完成的分片，这些分片不计入list但实实在在占空间。清理方式是进模型目录下的blobs子目录按体积排序，把明显对不上任何现存模型的残留删掉，或者干脆ollama rm掉不用的模型再重下。根治办法还是那句话，装完第一件事就是把OLLAMA_MODELS挪到大盘。

5.2 一条固定的排查顺序

出问题别乱试，按"进程 → 端口 → 模型 → 接口 → 客户端"自上而下走，每层只需一条命令：

# Windows：1. 服务进程在不在 Get-Process ollama* # 2. 11434 端口有没有被监听，PID 对不对得上 netstat -ano | findstr 11434

# Linux / macOS 等价操作 ps aux | grep ollama lsof -i :11434

进程在、端口通，问题就一定在模型或客户端侧；进程不在，往上查安装和自启；端口被别的程序占了，改OLLAMA_HOST换端口，客户端跟着改。这个顺序的价值在于每一步都能二分掉一半可能性，比反复重装客户端高效得多。我见过有人为了一个 404 重装了三次 ChatBox，最后发现是域名栏多写了一段路径。

5.3 日志在哪，怎么看

命令行窗口只显示一部分信息，真正的错误在服务日志里。Windows 一般在%LOCALAPPDATA%\Ollama\下，macOS 在~/.ollama/logs/下，Linux 走 journald，用journalctl -u ollama -n 100 --no-pager看最近一百行。日志里最值得关注的是加载阶段那几行，会明确写出分了多少层到 GPU、上下文多大、加载耗时多少，这几个数字直接对应上面的参数问题。

注意：日志里可能带本机路径和用户名，贴给别人求助之前先扫一眼，把路径替换掉。

6. 把本地模型当接口用：一次可复现的吞吐验收

客户端是给人用的，接口是给程序用的。Ollama 默认就暴露了 OpenAI 兼容端点，意味着任何按 OpenAI 协议写的脚本，改个 base_url 就能指向本机：

from openai import OpenAI # 本地服务不需要真 Key，但字段不能为空 client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="local") resp = client.chat.completions.create( model="r1-tech", # 必须与 ollama list 中的名字一致 messages=[{"role": "user", "content": "用三句话说明什么是 KV cache"}], temperature=0.6, max_tokens=512, ) print(resp.choices[0].message.content)

base_url末尾要带/v1，model填派生模型名也可以，只要它在本地存在。这套写法让原来跑在云端的脚本几乎零改动落地，是本地部署最实用的一条延伸。

验收别只看"能不能出字"，要量化。我会固定一段 200 字左右的提示词，跑五次取中位数，记录首字延迟和总耗时，把num_ctx从 4096 调到 8192 再跑一遍，对比两组数字。经验是上下文翻倍后首字延迟涨得比总耗时更明显，这个变化在长文档场景里非常直观。从此以后我每次换模型或者改num_ctx，都会强制走一遍这个小基准，不再凭"感觉快了"下结论。手里有数，才敢把它接到实际流程里。希望帮到你。

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