简介：《DeepSeek本地部署保姆级教程（Ollama、ChatBox）》是一份面向关注在线服务稳定性、隐私保护与响应延迟的DeepSeek使用者的课程资源，适合具备基本电脑操作经验、希望在本机运行大模型并完成图形化交互配置的读者。压缩包内为1个docx文档，大小约1.28MB，内容集中，便于按章节查阅和留存参考。已有3698人学习或下载，具备一定参考热度。文档围绕Ollama应用安装、按硬件条件选择1.5B、7B或32B等模型规格、模型获取与运行，以及ChatBox客户端连接本地AI系统的配置展开，并附常见问题说明；同时明确当前部署方式暂不具备联网检索能力，便于读者建立合理预期。整体可作为本地大模型入门与实操配置的参考材料，帮助读者理解工具链组成、模型选型依据、本地交互环境搭建思路及常见问题排查方向。

1. 装完才发现选错版本：本地跑 DeepSeek 前必须先算的一笔账

第一次在这台笔记本上做 DeepSeek 本地部署，我照着某篇教程直接敲了ollama run deepseek-r1:32b，进度条走得挺顺，走完一问问题，屏幕上几秒钟蹦一个字，风扇声盖过键盘声。这不是玄学，32B 对显存的要求远超家用机器，模型层加载不进显存就退回 CPU 计算，速度直接掉一个数量级。后来换成 7B，同一台机器立刻能正常对话。这次装的是一套 Windows 上最省事的组合：Ollama 负责把模型拉下来并在本机跑起来，DeepSeek-R1 是模型本身，ChatBox 给这套东西套一个能正常聊天、能翻历史的界面。装完的效果是断网也能问、不排队、对话内容不出本机，适合天天被在线服务劝退、又不想把资料传出去的人。

2. 环境盘点与版本选择：1.5B、7B、32B 到底该拉哪个

跳过环境盘点直接拉模型，是本地部署里最常见的一次性浪费。一个 32B 的量化包要占掉二十来个 GB 的磁盘，下载时间从十几分钟到一小时不等，拉完发现跑不动，删掉重来又是一轮。更麻烦的是模型默认落在系统盘的用户目录里，很多人拉到一半 C 盘飘红，才发现问题不在模型而在路径。所以这一章不急着装任何软件，先把机器的底摸清楚，再决定拉哪个规格，最后把存放位置提前挪好。顺序错了，后面每一步都得返工。

2.1 三条命令摸清内存、显存和剩余磁盘

Windows 上不需要装额外的检测工具，PowerShell 自带的几条命令就够。开一个 PowerShell 窗口（不是 cmd），依次执行下面的命令，把输出记下来。

# 内存总量，返回的是字节数，除以 1GB 才是我们熟悉的数字 Get-CimInstance Win32_ComputerSystem | Select-Object TotalPhysicalMemory # 独立显卡的型号、显存总量和驱动版本，只有 NVIDIA 卡能这么查 nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv # 各磁盘分区的剩余空间，单位换算成 GB 方便看 Get-PSDrive -PSProvider FileSystem | Select-Object Name,@{n='FreeGB';e={[math]::Round($_.Free/1GB,1)}}

第一条命令返回的TotalPhysicalMemory是个十位数，除以 1073741824 得到 GB 数，比如 17179869184 就是 16GB。第二条只有装了 NVIDIA 独显的机器才有输出，memory.total那一列就是专用显存，这个数字决定了模型能不能整块塞进显卡。核显机器没有nvidia-smi，直接打开任务管理器，切到「性能 → GPU」，看「专用 GPU 内存」和「共享 GPU 内存」两行，前者通常是 0 或者很小，后者是从内存里划出来给核显用的，核显跑模型吃的就是这部分。

第三条命令看的是目标盘的剩余空间。模型默认放在用户目录，也就是 C 盘，如果你的 C 盘只剩二三十个 G，先别急着拉 32B，把 2.3 节的环境变量设好再说。这里有个容易忽略的点：Ollama 拉模型时是分片下载再合并的，下载过程中占用的空间会比最终体积略大一点，留出 1.5 倍余量比较稳妥。

2.2 模型规格对照：显存决定速度，内存决定能不能跑

把硬件数字对上模型规格，选择其实只有三档。下面这张表是按官方给出的硬件门槛整理的，磁盘占用是量化后的实际下载体积，可以作为下载前的参考。

需要说清楚的是「内存门槛」和「显存门槛」分工不同。显存决定的是模型有多少层能放进显卡，放得越多，每个 token 的生成速度越快；内存决定的是模型放不进显存时，剩下那些层有没有地方待。7B 这个规格之所以被大多数人推荐，是因为它量化之后的总量在 4 到 5GB 之间，一张 4GB 显存的入门独显就能整块装下，装不下也有足够的内存兜底，不会出现跑不动的情况。

32B 的问题不在于「跑不了」，而在于「跑起来难受」。12GB 显存是官方给的舒适线，低于这条线，Ollama 会自动把一部分层留在内存里，每次生成都要在内存和显存之间搬数据，速度断崖式下跌。我在 8GB 显存的机器上试过一次，首字延迟十几秒，后面稳定在每秒一两个字，问一个稍微长点的问题要等好几分钟，这种体验还不如直接用 1.5B。

还有一层是量化格式。Ollama 模型库里同名 tag 默认给的是 4 位量化的版本，体积和精度做了折中，这也是为什么 7B 的包只有 4.7GB 而不是原始权重的十几 GB。这个折中对日常问答几乎无感，但如果你要拿它做严格的代码生成或者数学推导，可以留意模型页面上有没有标注其他量化等级的 tag，换 tag 的方式和换版本一样，把:7b换成对应的标签即可。

2.3 先改模型目录再拉模型：OLLAMA_MODELS 的设定顺序

这一步的顺序错了，后面全是白工。Ollama 默认把模型存在当前用户目录下的隐藏文件夹里，路径大致是C:\Users\你的用户名\.ollama\models。这个位置在装完之后改也不是不行，但已经下载的模型不会自动搬家，你得手动移过去，还得保证目录结构一模一样，否则 Ollama 认不出来，等于重下。

正确做法是在装完 Ollama、还没拉任何模型之前，先把环境变量设好。

# 先在 D 盘建好目标目录，路径里不要有中文和空格 New-Item -ItemType Directory -Path "D:\ollama\models" -Force # 写入用户级环境变量，只对之后新开的进程生效 setx OLLAMA_MODELS "D:\ollama\models"

setx写的是用户级变量，不需要管理员权限，但有个必须知道的特性：它只影响之后启动的新进程，当前这个 PowerShell 窗口读不到。所以执行完之后要把右下角托盘里的 Ollama 图标右键退出，再重新启动一次，让服务用新变量重新读一遍配置。判断有没有生效，最简单的办法是拉完一个小模型之后去看D:\ollama\models下面有没有出现blobs和manifests两个文件夹，有就说明路径切换成功。

如果你的机器只有一块盘，或者 C 盘空间本来就充裕，这一步可以跳过，但要清楚代价：一个 7B 模型 4.7GB，再拉一个 32B 就是 20GB，几个模型叠起来，系统盘很快就不够用了。我一般会在装完之后立刻做这个切换，哪怕当前只打算拉一个模型，也算是给以后留个后悔药。

注意：目录路径不要带中文、空格和特殊符号，Ollama 在某些版本下对这类路径处理不干净，表现是模型列表里能看到，但加载时报文件找不到，排查起来很费时间。

3. Ollama 安装与首个模型：从安装包到 11434 端口

环境盘完，进入真正的安装环节。Ollama 在 Windows 上的安装体验算是同类工具里最省心的，一个安装包双击到底，不需要单独装运行时，也不需要配 Python 环境。但省心不等于没有细节，安装位置、服务自启方式、端口占用这几件事如果不清楚，后面接客户端的时候会卡住。

3.1 Windows 安装包安装与安装位置确认

打开 Ollama 官网，首页上有一个 Download 按钮，点进去选 Windows 版本，下载下来是一个几十 MB 的安装包。双击运行，没有下一步下一步的向导，它会自己装完并在托盘区留下一个羊驼图标，整个过程不需要管理员权限，因为它装的是当前用户目录而不是 Program Files。

装完之后先别急着拉模型，验证一下命令行能不能用。按 Win+R 输入cmd开一个命令行窗口，执行下面两条。

# 确认版本号，能打印出来说明命令已进 PATH ollama -v # 列出本机已有模型，全新安装时是一张空表，表头有 NAME ID SIZE MODIFIED 四列 ollama list

ollama -v正常会输出一行版本信息，如果提示「不是内部或外部命令」，说明 PATH 没刷新，关掉这个窗口重新开一个就好，因为安装程序写 PATH 的动作对已经打开的终端不生效。这一点在 5.2 节还会细说，因为它是新手最容易误判成安装失败的一个现象。

安装位置值得记一下，默认在%LOCALAPPDATA%\Programs\Ollama，也就是C:\Users\用户名\AppData\Local\Programs\Ollama。这个目录里有主程序ollama.exe和一个app.exe，后者是托盘界面。知道位置的好处是，当你想彻底重装或者排查服务有没有起来的时候，可以直接去这个目录下手动执行命令，绕开 PATH 的问题。

托盘图标还有一个实际作用：它代表后台服务正在运行。Ollama 装完之后会注册开机自启，每次登录系统就自动把服务拉起来，监听本机的 11434 端口。如果你把托盘图标右键退出了，命令行里的ollama run会自己再拉起一个临时服务，但这个时候如果端口被别的进程占着，就会报错。所以装完先确认托盘图标在，再去敲命令。

3.2 ollama run deepseek-r1:7b：下载、加载与交互

这一步是整个流程里唯一需要等的地方。打开命令行，执行下面这条命令。

# 首次执行会先拉取模型，拉完自动进入交互式对话 ollama run deepseek-r1:7b

命令敲下去之后，终端会显示一个下载进度条，格式是「pulling manifest」加一串分片下载的百分比。7B 的包在 4.7GB 左右，网速正常的话十几分钟能下完。这里有个细节：Ollama 的下载是分片进行的，每个分片下完就落盘，中途断网或者按了 Ctrl+C，重新执行同一条命令会接着下，不会从头开始。所以下到一半卡住了不用慌，重跑一遍就行。

下载完成后会自动加载模型并进入对话提示符>>>，这个时候直接输入问题就能看到回答。DeepSeek-R1 的输出有个特点，它会先输出一段被think标签包起来的思考过程，再给正式回答。第一次看到大段英文推理别以为是出错，那是模型的思维链，本地跑的时候这段过程是完整可见的，反倒是比在线版多了一点可观察性。

交互界面里还有几个命令值得记住，敲/开头的都算元命令。

# 退出对话，回到普通命令行，模型会从显存里卸载 /bye # 清空当前会话的上下文，重新开始一轮对话 /clear # 查看当前模型的参数、模板和量化信息 /show info

/clear这个命令在实际使用中比想象中重要。Ollama 的交互会话是带上下文的，你连着问十个问题，前面九轮的问答都会作为上下文带进去，token 数越积越多，速度越来越慢，显存占用也会上涨。问完一个话题想换方向的时候，先/clear一下，速度立刻回到初始水平。

模型加载到显存需要一个过程，7B 在普通独显上大概两三秒，之后每次提问的响应就是实时的了。判断模型有没有真的进了显存，另开一个窗口执行ollama ps，看输出里 PROCESSOR 那一列，显示 100% GPU 说明全在显卡上，显示一部分 CPU 一部分 GPU 说明显存不够发生了分层卸载，速度会明显变慢。这一列是排查性能问题的第一手依据。

3.3 服务端口与常用环境变量

Ollama 装完之后干的事其实很简单：在后台跑一个 HTTP 服务，默认监听127.0.0.1:11434，所有命令行操作和客户端调用最后都变成对这个端口的请求。理解了这一点，后面接 ChatBox 就只是填一个地址的事。

先验证服务是通的。

# 查询本机已安装的模型列表，返回一段 JSON curl http://127.0.0.1:11434/api/tags

正常情况下会返回一个 JSON 对象，models数组里每一项对应一个模型，包含名称、大小、修改时间和摘要信息。这条命令的价值在于把「服务通不通」和「模型有没有」两个问题一次查清：返回 JSON 但数组为空，说明服务正常只是没拉模型；返回连接被拒绝，说明服务压根没起来，去托盘看图标。

如果想绕开交互界面直接调一次生成接口，Windows 的 cmd 里引号转义比较麻烦，建议用 PowerShell。

# 组装请求体，stream 设为 false 表示等完整回答一次性返回 $body = @{ model = "deepseek-r1:7b" prompt = "用一句话解释什么是本地推理" stream = $false } | ConvertTo-Json # 调用生成接口 Invoke-RestMethod -Uri "http://127.0.0.1:11434/api/generate" -Method Post -Body $body -ContentType "application/json"

stream这个参数决定返回方式，设成false是一次性返回完整结果，适合脚本调用；设成true是流式返回，一个字一个字往外吐，ChatBox 这类客户端用的就是流式，所以你能看到回答逐字出现。这个接口是后面排查客户端问题的重要工具：客户端连不上时，先用这条命令确认服务本身没问题，能把问题范围缩小一半。

有两个环境变量建议装完就设，都属于「设了之后少很多麻烦」的类型。

# 模型在显存里多留 30 分钟，避免每次提问都重新加载 setx OLLAMA_KEEP_ALIVE "30m" # 默认端口被占用时换一个，改完客户端地址要同步改 setx OLLAMA_HOST "127.0.0.1:11500"

OLLAMA_KEEP_ALIVE的默认值是 5 分钟，意思是模型闲置 5 分钟后从显存卸载，下次提问再重新加载。对于 7B 这种加载要两三秒的模型，频繁卸载重载很影响体验，设成 30 分钟比较合适；对于 32B 这种一加载就吃掉大半显存的模型，反而建议调小或者保持默认，把显存让给别的程序。

OLLAMA_HOST改的是监听地址和端口，只有在 11434 被别的开发服务占用时才需要动。改完之后记得把托盘程序重启一次，并且所有客户端的地址都要跟着改成新端口，否则会出现「服务明明在跑但客户端连不上」的情况。

4. ChatBox 接入本地模型：自定义提供方、API 域名与上下文长度

命令行里能对话，但翻历史、复制长回答、切换模型这些事在终端里做起来别扭。ChatBox 的作用就是给这套本地服务加一层图形界面，它本身不跑模型，只负责把你说的话发到 11434 端口，再把返回的内容渲染出来。理解了这层关系，配置的时候就不会被「API Key」「提供方」这些词吓到。

4.1 安装与首次配置入口

从 ChatBox 官网的下载页拿 Windows 安装包，双击装完打开。首次启动会弹一个引导窗口，里面有几个选项，要选的是「使用自己的 API Key 或本地模型」这一项，不要选登录账号或者云端模型那些。

如果不小心把这个窗口关了，也不用重装，主界面左下角进「设置」，找到「添加自定义提供方」，效果一样。这个入口是后面所有配置的起点，记住它的位置比记住怎么填更重要，因为换模型、加第二个模型都要回到这里。

添加提供方的时候，类型选择上有两种走法：一种是直接选 Ollama，另一种是选「OpenAI API 兼容」然后手填地址。两种都能通，区别在于前者会自动去拉模型列表，后者需要你手填模型名。我一般用后者，因为字段含义更明确，出问题的时候容易定位是哪一项填错了。

4.2 参数怎么填：一张表对着抄

配置界面里字段不多，但每一项都有踩坑点，下面这张表按实际填写顺序整理，照抄即可。

表里最容易被填错的是 API 域名和模型名这两项。域名这一栏，有人习惯性写成https，结果握手直接失败；也有人把127.0.0.1写成0.0.0.0，这个地址是服务端的监听地址，客户端拿它去连接是连不上的。模型名这一栏，必须和ollama list输出的 NAME 列一字不差，deepseek-r1:7b少一个冒号、多一个空格都会报模型不存在，而这个报错在界面上往往只显示成一句笼统的「请求失败」。

保存之后不要急着开始聊，先点界面上的测试或者直接发一句「你是谁」。正常情况会看到模型先吐一段思考过程，然后回答自己是 DeepSeek-R1。这一步通了，说明从界面到模型整条链路都通了，剩下的都是调优。

如果测试失败，按这个顺序排查：先在命令行执行curl http://127.0.0.1:11434/api/tags确认服务活着，再执行ollama list确认模型名没写错，最后检查 API 路径那一栏是不是多填或者少填了斜杠。这三步能把绝大多数连接问题定位到具体某一项。

4.3 会话设置：温度、系统提示词与局域网访问

界面通了之后，有几个参数值得调一下，调完之后使用体验差别挺明显。

温度控制的是输出的随机性，值越低回答越保守越确定，值越高越发散。DeepSeek-R1 这类推理模型，官方给的通用建议区间在 0.5 到 0.7 之间，我一般设 0.6。做代码补全或者需要稳定复现的场景，可以压到 0.3；做头脑风暴类的用途，拉到 0.8 也无妨。这个值在 ChatBox 的模型设置里能改，改完对新建会话生效。

上下文长度决定模型能记住多少轮对话。Ollama 默认给 7B 的上下文窗口是 2048 个 token，连续聊十几个回合就会开始遗忘前面的内容。可以在 ChatBox 里把这个值调到 8192，代价是显存占用会上涨，8GB 显存的机器要留意ollama ps的输出有没有从 100% GPU 掉下来。如果掉了，说明上下文开太大挤占了模型层的空间，往回退到 4096 更稳。

系统提示词那一栏可以写一句「请始终用简体中文回答」，能减少模型在思考过程结束后切换成英文回答的情况。这不是必须的，但对中文使用者来说省心不少。

还有一种用法是把服务开放给局域网内的其他设备，比如手机或者另一台电脑访问这台机器上的模型。

# 监听所有网卡，让局域网内其他设备能连进来 setx OLLAMA_HOST "0.0.0.0:11434" # 允许浏览器跨域访问，网页版客户端需要 setx OLLAMA_ORIGINS "*"

改完重启托盘程序，然后在防火墙里放行 11434 端口，其他设备把 API 域名换成这台机器的内网 IP 就能用了。

注意：0.0.0.0监听意味着同一网络下的任何设备都能访问你的模型服务，只适合在可信的家庭或办公内网使用，不要把这个端口映射到公网。

5. 踩坑记录：五个把 Ollama 折腾到重装的现场

前面三章按顺序走下来，多数机器能顺利跑通。但实际动手的时候，出问题的往往不是主流程，而是几个边界情况：硬件刚好卡在门槛上、环境变量没刷新、端口被占、磁盘满了、输出被截断。这一章按现象、原因、解决三段式记录五条真实遇到过的坑，遇到对应症状可以直接对号入座。

5.1 显存这条线：拉了大模型之后一秒一个字

现象：模型能加载，也能出字，但速度慢到没法用，一个问题等好几分钟，任务管理器里 GPU 占用很低，CPU 反而跑满。执行ollama ps看到 PROCESSOR 列显示的是一个百分比，比如30%/70% CPU/GPU。

原因：模型的层数超过显存容量，Ollama 自动做了分层卸载，一部分层放在显存，剩下的放在内存由 CPU 计算。CPU 算这些层的速度比 GPU 慢一个数量级，整体速度就被拖垮了。这不是故障，是设计上的降级策略，只是降级之后的体验落差很大。

解决：先确认显存真实容量，再看当前模型的体积，两者对不上就换小一号的规格，32B 换 7B、7B 换 1.5B。如果一定要跑大模型，另一条路是降低上下文长度，把num_ctx从默认值压到 2048，能省出一部分显存给模型层，速度会有改善但幅度有限。判断标准很简单：ollama ps里 GPU 占到 100% 才算正常，低于这个数就说明显存不够。

5.2 环境这条线：命令找不到、服务没起来、端口被占

现象一：装完 Ollama，在命令行敲ollama提示「不是内部或外部命令，也不是可运行的程序」。

原因：安装程序把 Ollama 的目录写进了用户级 PATH，但这个改动只对之后新开的进程生效。当前这个 cmd 窗口是在安装之前打开的，读的还是旧的环境变量。

解决：关掉窗口重新开一个，或者重启一次资源管理器。如果重开之后还是不行，去%LOCALAPPDATA%\Programs\Ollama看主程序在不在，在的话说明只是 PATH 的问题，手动把这个目录加进环境变量即可；不在的话是安装没完成，重装一遍。

现象二：ChatBox 里发消息一直转圈，最后提示连接超时，但命令行里ollama run是正常的。

原因：命令行能跑不代表服务在监听端口。ollama run在服务没起来时会自己拉起一个临时进程，用完就退出，而 ChatBox 需要的是一个常驻服务。另一种可能是 11434 端口被别的开发工具占了，比如某些本地调试服务默认也用这个段位的端口。

解决：先看托盘图标在不在，不在就手动启动一次。然后用curl http://127.0.0.1:11434/api/tags确认端口通不通，报连接拒绝说明服务没起，报其他错误说明端口被占。查端口占用的命令是netstat -ano | findstr 11434，最后一列是进程 PID，拿去任务管理器里对一下就知道是谁占的，要么关掉它，要么用OLLAMA_HOST换个端口。

5.3 磁盘与输出这条线：C 盘爆满、回答截断

现象一：拉了两三个模型之后 C 盘突然飘红，系统开始卡。

原因：模型默认存在C:\Users\用户名\.ollama\models，每个模型都是几个 GB 起，1.5B、7B、32B 各来一个就是二十多个 GB。这个目录还是隐藏的，在资源管理器里默认看不到，所以很多人是等到磁盘告警才发现。

解决：先设OLLAMA_MODELS把目录指到大盘，再重启服务，然后把旧的 models 目录整个移到新位置。Ollama 是按内容哈希找文件的，只要blobs和manifests两个子目录结构不变，移过去就能直接识别，不用重新下载。移完执行ollama list验证，模型都在就说明迁移成功，可以删掉旧目录了。

现象二：聊了十几轮之后，模型的回答开始变得莫名其妙，要么答非所问，要么直接重复上一句，长回答还会中途断掉。

原因：上下文窗口满了。Ollama 默认的上下文长度是 2048 token，超出之后最早的对话被挤掉，模型就丢失了前面聊过的信息。回答中途断掉则是输出长度达到上限被截断。

解决：在 ChatBox 的模型设置里把上下文长度调到 8192，同时养成换话题时新建会话的习惯，而不是在一个会话里从头聊到尾。如果调整之后显存占用明显上涨、速度变慢，说明上下文开太大挤了模型的空间，退回 4096。另外温度设得太高也会让回答发散跑偏，回到 0.6 左右通常就正常了。

6. 装完怎么验证：四个检查点和一次断网测试

一套本地环境装完，最怕的是「看起来能用」但其实是走了云端。判断标准不能只看能不能出字，得逐层验证。我一般按下面四个检查点走一遍，全部通过才算装好。

第一步查模型清单。命令行执行ollama list，输出里必须有一行 NAME 是deepseek-r1:7b，SIZE 在 4.7GB 上下。列表为空说明模型没拉下来，或者OLLAMA_MODELS指向了一个空目录。

第二步查加载位置。执行ollama ps，看 PROCESSOR 那一列。显示100% GPU是最理想的状态，说明整个模型都在显卡上；显示带 CPU 百分比说明发生了分层卸载，能用但会慢，参考 5.1 节处理。

第三步查服务接口。用 PowerShell 执行下面这条，看返回的 JSON 里 models 数组有没有内容。

# 服务层面确认模型已注册，返回的 JSON 里应能看到 deepseek-r1:7b (Invoke-RestMethod -Uri "http://127.0.0.1:11434/api/tags").models | Select-Object name, size

第四步查客户端链路。打开 ChatBox，新建一个会话，问一句「你是谁，你运行在哪里」。回答里应该出现 DeepSeek-R1，并且能正常吐出思考过程。

四个检查点都过了，再做一次断网测试，这是最能说明问题的一步：把 Wi-Fi 关掉或者拔掉网线，等几秒让网络状态稳定下来，回到 ChatBox 再问一个问题。如果回答照常出现，说明整条链路确实跑在本机，没有任何请求发到外部；如果这时候报错或者卡住，说明配置里还有某个地址指向了线上服务，回 4.2 节把 API 域名重新核对一遍。

断网测试这个习惯是被坑出来的。早些年配环境，有一次界面一切正常，回答也很流畅，直到某天网络断了才发现根本没用上本地模型，客户端一直在连一个默认的云端地址，只是因为网速好所以没察觉。从那以后我每次装完本地模型，都强制走一遍断网验证，不管前面几步看起来多正常。这一步花不了一分钟，能省掉后面几个小时的困惑。

这套安装包和离线模型文件都在资源里备了一份，官网下载慢的时候可以直接拿，按照从环境盘点、装 Ollama、拉模型到接 ChatBox 的顺序走一遍，基本不会卡住。希望帮到你。

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