DeepSeek本地部署：Ollama选型、显存调参与验收排错

发布时间：2026/10/28 14:54:17

简介：这份PDF面向希望把DeepSeek模型落地到本地环境的开发者、初学者及具备一定硬件基础的专业人士，围绕低、中、高三档硬件配置给出选型建议，并讲解Ollama、Python、CUDA等工具的获取、安装与验证方法，帮助读者解决本地部署中的环境准备、模型选择、运行测试和故障排查问题。压缩包内共1个PDF文件，大小约559KB，以图文操作指南和命令行示例呈现，便于按流程查阅。已有1153人学习下载。内容覆盖DeepSeek-R1-1.5B、7B、32B三款模型的功能特点与适用场景，说明模型下载时的磁盘空间预留和网络连接注意事项，并引导完成交互界面对话测试，介绍Chatbox AI、LM Studio等个性化界面的选择与使用，最后汇总常见问题与排障技巧，可作为从硬件评估到应用拓展的实操参考。

1. 从一台 8GB 内存的办公本说起：DeepSeek 本地部署先别急着敲 run

上周有台办公本，8GB 内存、核显、C 盘还剩 40GB，开机第一件事就是ollama run deepseek-r1:32b。风扇转了一刻钟，终端光标闪了半天没吐出一个字，最后抛出一句内存不足。DeepSeek 本地部署和模型安装这件事，卡人的从来不是敲哪条命令，而是装之前的三个判断：这台机器该拉哪个版本、模型文件会落到哪个盘、跑起来到底是 GPU 在算还是 CPU 在硬扛。

本地跑大模型在自然语言处理和代码生成上的吸引力很直接——对话内容、项目源码、内部文档都不出本机。但换个版本号，体验就是天壤之别：同一个模型，1.5B 在核显本上能流畅问答，32B 在 16GB 内存的机器上连加载都过不去。这篇记录按「量硬件 → 装 Ollama → 拉模型调参 → 接界面 → 排错 → 验收」的顺序走一遍，硬件中等、想在自己机器上把 AI 模型部署跑通的开发者，照着抄就行。

2. 装前量硬件：1.5B / 7B / 32B 三档版本与显存账单

2.1 三个版本各自吃什么资源

同一个 DeepSeek-R1 系列，参数量差一个数量级，硬件门槛差的不止一个数量级。下面这张表是我自己装机时对着填的，磁盘占用按量化后的文件大小估，显存按「整份权重能全放进显存」算，放不进去就会有一部分卸载到内存里跑，速度会掉一个档。

模型版本	磁盘占用（约）	全 GPU 运行建议显存	建议内存	能干什么
deepseek-r1:1.5b	1～2GB	核显可跑，独显 2GB 起	8GB	日常问答、短文本摘要、简单改写
deepseek-r1:7b	5GB 上下	6～8GB	16GB	文章润色、中等长度代码生成、多轮对话
deepseek-r1:32b	20GB 以上	16GB 以上，或接受部分卸载	32GB	长文深度分析、复杂代码调试

显存这一栏不是拍脑袋定的。模型权重之外还要留出 KV Cache，上下文长度num_ctx开得越大，这部分吃得越多。7B 的量化文件 5GB，num_ctx给到 8192，实际占用会摸到 6GB 往上；同一张 6GB 显存的卡，num_ctx设 2048 能跑满 GPU，设 16384 就会被迫往内存里丢层，出字速度肉眼可见地掉。

所以选版本的正确顺序是反的：先看显存和内存能给多少，再倒推能拉到多大的模型。手里是 8GB 内存的老笔记本，别犹豫，1.5B 就是对的选择；16GB 内存加一张 8GB 显存的卡，7B 是甜点；只有 32GB 内存起步、显存 16GB 以上，32B 才值得折腾。

提示：显存刚好卡在门槛上时，优先降num_ctx而不是降模型版本。上下文从 8192 降到 4096，省下来的显存往往够让整份权重留在 GPU 里，比换小模型划算。

2.2 三分钟摸清自己机器的底牌

装之前先花三分钟把家底摸清，比装完再返工省事得多。Windows 上最省事的办法是直接看任务管理器「性能 → GPU」，那里显示的「专用 GPU 内存」就是显存，不要信 PowerShell 里Win32_VideoController的AdapterRAM，那个字段是 32 位整数，4GB 以上的卡会溢出一个离谱的数字。

有独显的机器，一条命令看全：

# Windows / Linux 通用，前提是装了显卡驱动 nvidia-smi

这条命令输出三样关键信息：显存总量（MiB那一列）、当前驱动版本、以及右上角CUDA Version显示的驱动支持上限。这个上限不是让你照着去装 CUDA Toolkit，后面第 4 章会讲清楚为什么。

macOS 和 Linux 各有各的看法：

# macOS：看显卡型号与显存 system_profiler SPDisplaysDataType | grep -i -E "chipset|vram" # Linux：看显卡、内存、磁盘剩余 lspci | grep -i vga free -h df -h

free -h看的是物理内存，注意别把 swap 算进去，模型加载时吃的是实打实的内存。df -h看的是挂载点剩余空间，这一步经常被跳过，结果拉到 60% 提示磁盘不足。

2.3 磁盘预留与默认模型目录的位置

Ollama 默认把模型放在用户目录下，三个系统各不一样：

Windows：%USERPROFILE%\.ollama\models
macOS：~/.ollama/models
Linux：/usr/share/ollama/.ollama/models

这意味着一台 256GB 固态、C 盘只剩 30GB 的笔记本，拉 32B 一定会失败。我的习惯是装完 Ollama 第一件事就改模型目录，改到 D 盘或者一块独立的数据盘，预留空间按「当前要拉的模型 + 以后可能再拉两个」算，32B 起步就留 60GB。

这个目录里装的是两类文件：blobs放模型权重分片，manifests放版本索引。迁移已有模型的时候，两个目录都要拷，只拷blobs会出现ollama list里有名字、run的时候报找不到层的情况。

3. 安装 Ollama：Windows、macOS、Linux 三条路径与目录迁移

3.1 Windows 与 macOS 的图形化安装

Ollama 在 Windows 上的安装包是个常规 exe，双击、下一步、可选安装路径，全程不需要管理员权限，因为它默认装在当前用户目录下。装完托盘区会出现一个羊驼图标，这就是服务在后台跑起来的标志。

macOS 拿到的是 dmg，打开后把图标拖进「应用程序」文件夹。首次启动系统会弹一次「是否允许打开」，允许之后托盘出现图标即算装好。

两个系统都有一个共同的坑：装完之后不要在有图标的终端里直接敲命令。Windows 上装完会新开一个终端窗口，如果是在装之前就开着的 PowerShell 里敲ollama -v，很可能提示「不是内部或外部命令」，因为那个进程的 PATH 还是旧的。解决办法简单，关掉重开一个窗口。

3.2 Linux 脚本安装与 systemd 服务管理

Linux 上官方给的是一条脚本：

# 下载并执行安装脚本，脚本内部会完成用户创建、二进制放置、服务注册 curl -fsSL https://ollama.com/install.sh | sh

这条脚本做的事比看上去多：创建ollama系统用户、把二进制放到/usr/local/bin、注册一个 systemd 服务并立即启动、顺带检测显卡并装上对应的运行库。所以装完之后不需要手动ollama serve，服务已经在后台跑了。

想确认服务状态：

# 查看服务是否 active (running) systemctl status ollama # 查看服务日志，排查启动失败时最有用 journalctl -u ollama -n 50 --no-pager

journalctl这条在排查「装完了但端口没起来」的时候特别有用，日志里通常会直接写明是权限问题还是显存初始化失败。

注意：Linux 下用脚本安装的 Ollama 是系统服务，用sudo手动跑ollama serve会和已有服务抢 11434 端口，报address already in use。要么停服务，要么别手动起。

3.3 装完必须过的三道验证

安装完成的判定标准有三层，一层层过：

# 第一层：命令能调起来，能看到版本号 ollama -v # 第二层：HTTP 服务在监听，返回 Ollama is running curl http://localhost:11434 # 第三层：确认端口确实被占用（Windows） netstat -ano | findstr 11434 # 第三层（Linux / macOS） ss -lntp | grep 11434

第一层过不了，说明 PATH 没生效，回去看安装路径有没有进环境变量。第二层过不了但第一层过了，说明后台服务没起来，Windows 上看托盘图标，Linux 上看systemctl status ollama。第三层能看到监听地址，默认应该是127.0.0.1:11434，如果是0.0.0.0:11434说明有人改过OLLAMA_HOST，这时候同网段的其他机器也能访问到，公网机器上要留意这一点。

3.4 把模型目录从系统盘挪走

这一步放在拉模型之前做，顺序反了就得把几十 GB 的文件再搬一次。

Windows 的做法是加系统环境变量：Win + R输入sysdm.cpl→ 高级 → 环境变量 → 新建用户变量OLLAMA_MODELS，值填D:\ollama\models。建完必须做一件事——在托盘图标上右键退出 Ollama，再重新打开。只关窗口不退出进程，新变量不会生效，ollama list里还是旧目录的内容。

Linux 用 systemd 的 override 机制，不要直接改/etc/systemd/system/ollama.service，升级的时候会被覆盖：

# 生成 override 文件，编辑器里填内容 sudo systemctl edit ollama.service

在弹出的编辑器里写入：

[Service] # 模型存储目录，换成你自己的数据盘路径 Environment="OLLAMA_MODELS=/data/ollama/models" # 只监听本机，避免同网段其他机器直连 Environment="OLLAMA_HOST=127.0.0.1:11434" # 模型在显存里驻留时长，默认 5 分钟，调大可以减少反复加载 Environment="OLLAMA_KEEP_ALIVE=30m"

保存后重载并重启：

# 重载 unit 配置并重启服务 sudo systemctl daemon-reload sudo systemctl restart ollama # 确认环境变量已注入进程 sudo systemctl show ollama | grep -i environment

macOS 稍微绕一点，图形界面启动的 App 读不到 shell 里的环境变量，常见做法是用launchctl：

# 设置当前登录会话的环境变量，之后从启动台打开 Ollama 才会生效 launchctl setenv OLLAMA_MODELS /Users/yourname/ollama-models # 确认写入成功 launchctl getenv OLLAMA_MODELS

这条命令的局限是重启电脑后失效。要长期生效，得写一个 LaunchAgent 的 plist，或者干脆把模型目录做成软链接，指向数据盘上的实际位置。

4. 拉模型与调参：ollama run 之后的 Modelfile 与接口

4.1 pull、run、list、ps 四个命令的分工

很多人第一次装完只知道ollama run，其实四个命令各有各的位置：

# 只下载不启动，适合提前把模型备好 ollama pull deepseek-r1:7b # 下载并进入交互式对话，没下过会自动先下 ollama run deepseek-r1:7b # 列出本地已有的模型及大小 ollama list # 查看当前加载在内存/显存里的模型，以及卸载状态 ollama ps

ollama list的输出里有个SIZE列，这个数值和磁盘上实际占用对得上，可以拿来核对磁盘预留够不够。ollama ps是最容易被忽略但最该常用的一个，它会告诉你模型是不是还在显存里、什么时候会被卸载、以及最关键的那一列PROCESSOR：

NAME ID SIZE PROCESSOR UNTIL deepseek-r1:7b e3f9a1c2b7d4 5.2 GB 100% GPU 29 minutes from now

100% GPU说明整份权重都在显卡上，速度最快；100% CPU说明完全靠 CPU 硬算；出现35%/65% CPU/GPU这种百分比，说明显存装不下，卸载了一部分到内存。看到第三种，先别急着换卡，按 4.3 的思路调。

提示：模型默认在闲置 5 分钟后从显存卸载，下一次提问又要重新加载，7B 大约要十几秒。频繁用的话把OLLAMA_KEEP_ALIVE调到30m甚至-1（常驻），体验差别很明显。

4.2 用 Modelfile 固化 temperature 与 top_p

命令行里每次都要手动调参数很烦，Modelfile 就是把这套配置固化成一个新模型标签的办法。它的语法和 Dockerfile 很像：

# 基于已下载的 7B 模型派生 FROM deepseek-r1:7b # 温度：0.2 偏严谨，适合问答和代码；0.8 偏发散，适合创意文本 PARAMETER temperature 0.3 # 核采样：越小越保守，越大越发散，一般和 temperature 二选一重点调 PARAMETER top_p 0.9 # 上下文窗口：越大越能装长文档，但 KV Cache 吃显存 PARAMETER num_ctx 8192 # 重复惩罚：大于 1 抑制复读，写长文时给 1.1 比较稳 PARAMETER repeat_penalty 1.1 # 系统提示词，固定角色和输出格式 SYSTEM """你是一名严谨的技术助理，回答代码问题时先给可运行的最小示例，再解释关键参数。"""

写好后创建并运行：

# 在 Modelfile 所在目录执行，-f 指向文件名 ollama create deepseek-r1-7b-dev -f ./Modelfile # 用新标签启动，参数已固化 ollama run deepseek-r1-7b-dev

temperature和top_p这两个参数的取舍，我的经验是：代码补全和日志分析这类要确定性的任务，temperature给 0.2～0.3，top_p给 0.9，输出几乎不会跑偏；写文案、想标题这类要发散的任务，temperature提到 0.8，top_p放宽到 0.95，能出一些意想不到的表述。两个参数同时开很高会让输出变得难以控制，一般只重点调其中一个。

num_ctx是显存杀手，也是最值得单独设的一项。7B 模型把num_ctx从 2048 提到 8192，显存多占一到两个 GB，但只要还装得下，处理长文档的能力就差了一大截。判断依据还是ollama ps：改完跑一次，看PROCESSOR列有没有掉出100% GPU。

4.3 GPU 到底吃上了没有

这一步是本地部署里玄学最多的地方。先明确一个常见误解：用 Ollama 跑模型，不需要单独安装 CUDA Toolkit。Ollama 的安装包里已经带了推理所需的运行库，只要显卡驱动正常、nvidia-smi能认到卡，它就会自动走 GPU。装 CUDA Toolkit 是为了自己写 Python 脚本、跑 PyTorch 这类场景，和 Ollama 本身是两回事。我见过有人为了跑 7B，花两小时装了一个版本对不上的 Toolkit，最后把驱动搞崩了。

真有需要装 Toolkit 的情况（比如要做二次开发），版本对位关系看nvidia-smi右上角那个数字，装的 Toolkit 版本不能高于它，然后用nvcc -V验证：

# 查看已安装的 CUDA Toolkit 版本 nvcc -V # 查看驱动版本与驱动支持的最高 CUDA 版本 nvidia-smi

如果ollama ps显示的全是 CPU，按这个顺序排查：nvidia-smi能不能正常输出（驱动没装好，输出会报错）→ 显存是不是真不够（看SIZE列和显存总量的对比）→ 是不是装过多个版本的 Ollama 冲突。前两条占九成。

还有一种情况是笔记本双显卡，独显被系统电源策略挂起了。插上电源、在系统设置里把 Ollama 指定为「高性能 GPU」运行，很多时候问题就没了。

4.4 把模型挂成 HTTP 接口

Ollama 起来之后本身就是个 HTTP 服务，11434端口上暴露了几个接口，把本地模型当 API 用是最实用的拓展方式。

# 单轮生成：prompt 进，response 出 curl http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "用一句话解释什么是 KV Cache", "stream": false }' # 多轮对话：messages 数组，带角色 curl http://127.0.0.1:11434/api/chat -d '{ "model": "deepseek-r1:7b", "messages": [ {"role": "system", "content": "你是一名运维工程师"}, {"role": "user", "content": "给出查看 11434 端口占用的命令"} ], "stream": false }' # 列出本地模型，等价于 ollama list curl http://127.0.0.1:11434/api/tags

三个接口的差别在入参结构：/api/generate只接受单个prompt，适合一次性任务；/api/chat接受消息数组，能保留上下文，是接界面和写脚本时用得最多的；/api/tags用来做健康检查。stream设成false会等生成完一次性返回，脚本里好处理；设成true是逐 token 流式返回，界面上的打字机效果靠它。

Python 里调用：

import requests # 本地服务不需要鉴权，地址固定为 127.0.0.1:11434 URL = "http://127.0.0.1:11434/api/chat" payload = { "model": "deepseek-r1-7b-dev", "messages": [ {"role": "user", "content": "把这段循环改成列表推导式：result = []\nfor i in data:\n result.append(i * 2)"} ], "stream": False, # options 里的参数会覆盖 Modelfile 中的同名设置 "options": {"temperature": 0.2, "num_ctx": 4096} } # 7B 首次加载要几十秒，超时别设太小，否则连接断在模型加载阶段 resp = requests.post(URL, json=payload, timeout=180) resp.raise_for_status() print(resp.json()["message"]["content"])

options字段的优先级高于 Modelfile，调试参数时不用反复ollama create，直接在请求里改更快。定位到合适的值之后再写回 Modelfile 固化。

4.5 接上 Chatbox 与 LM Studio 两类界面

命令行交互适合测试，日常用还是图形界面顺手。Chatbox 的配置只有三项关键项：

打开「设置」→ 切到「模型」选项卡 → 「AI 模型提供方」下拉里选Ollama→ 「API 域名」填http://localhost:11434→ 「模型」下拉里会出现ollama list里的所有模型，选中deepseek-r1-7b-dev→ 保存。保存之后新建对话就能用。

三个地方容易配错：一是API 域名后面多加了/api或者结尾斜杠，正确写法就是http://localhost:11434，不带任何路径；二是localhost在某些系统上解析到 IPv6 的::1，而 Ollama 只监听了127.0.0.1，改成http://127.0.0.1:11434就通了；三是配置完没点保存，直接关窗口。

LM Studio 走的是另一条路，它本身也能直接加载模型文件，适合完全离线、不想让服务常驻后台的场景。它的界面里同样可以挂到本地的 OpenAI 兼容端点，把地址填成本机的11434，模型名填ollama list里的标签即可。

编辑器里也能接。VS Code 扩展市场里支持 Ollama 的插件不止一个，常见做法是装 Continue 这类助手插件，在配置文件里把 provider 指到 ollama，模型名填本地标签：

# Continue 的 config.yaml 片段 models: - name: deepseek-r1-7b-dev provider: ollama # 指向本地服务，不要带 /api 后缀 apiBase: http://127.0.0.1:11434 model: deepseek-r1-7b-dev roles: [chat, edit]

写代码时选中片段右键问模型，或者在侧边栏提问，回答都来自本机，源码不出内网。这是本地部署相比云端服务最实在的价值。

5. 排查与避坑：本地跑 DeepSeek 最常见的五种翻车

5.1 装完命令找不到、端口连不上

现象：新开的终端里敲ollama -v提示「不是内部或外部命令」或者command not found；或者命令能用但curl http://localhost:11434返回连接被拒绝。

原因：前一种情况是 PATH 没刷新——安装程序改了系统环境变量，但已经开着的终端进程读的还是旧值。后一种情况是后台服务没起来，Windows 上是托盘进程没运行，Linux 上是 systemd 服务启动失败。

解决：命令找不到就先关掉所有终端窗口重开，还不行就去安装目录手动确认——Windows 装在%LOCALAPPDATA%\Programs\Ollama，macOS 装在/Applications/Ollama.app，Linux 是/usr/local/bin/ollama，把所在目录手动加进 PATH。端口连不上就分系统看：Windows 点托盘图标重启，Linux 用systemctl status ollama加journalctl -u ollama -n 50看失败原因，日志里最常见的两条是显存初始化失败和模型目录权限不足（服务以ollama用户跑，自定义目录要chown -R ollama:ollama）。

5.2 模型跑起来了，但慢得不像话

现象：模型能回答问题，但每个字都像挤出来的，任务管理器里 CPU 跑满、GPU 闲着；ollama ps的PROCESSOR列显示百分比混合，比如35%/65% CPU/GPU。

原因：显存装不下整份权重加 KV Cache，Ollama 自动把一部分层卸载到内存里，每生成一个 token 都要在内存和显存之间搬数据，速度会掉到原来的几分之一。常见的触发条件是num_ctx设得太大，或者后台还开着浏览器、剪辑软件这类吃显存的程序。

解决：先降num_ctx，从 8192 降到 4096 甚至 2048，再跑ollama ps看有没有回到100% GPU。降完还是不行就换更小的量化版本或者更小的参数量。另外确认笔记本是不是在用电池——很多机器的电源策略会在拔掉电源后限制独显功耗，插上电再测。

5.3 模型拉一半断了、盘写满了

现象：ollama pull跑到某个百分比卡住不动，或者直接报磁盘空间不足；重跑一次看着像从头开始。

原因：模型文件按层分片下载，网络波动会让某一层超时；磁盘空间不足则是在写 blob 的时候写失败。这两个问题经常一起出现，因为很多人根本没检查过目标盘还剩多少空间。

解决：先df -h或用资源管理器确认OLLAMA_MODELS指向的盘剩余空间，32B 起步留 60GB。空间没问题就重跑同一条ollama pull，已经下完的分片会被复用，不会从零开始。网络一直不稳的话换个时间段再试，或者分批拉——先把 7B 拉下来用着，等有整块时间再拉 32B。

5.4 目录一改，模型列表空了

现象：设了OLLAMA_MODELS指向新盘之后，ollama list输出为空，但旧目录里明明有模型文件。

原因：三种可能。一是环境变量只对当前终端会话生效，服务进程读不到；二是改完之后没重启服务；三是迁移的时候只拷了blobs没拷manifests，文件在但索引没了。

解决：Windows 上必须用系统环境变量面板设置，设完在托盘图标上右键退出再重开，光关窗口不够。Linux 上必须用systemctl edit写 override，然后daemon-reload加restart，直接export在当前 shell 里是没用的。迁移已有模型时，blobs和manifests两个目录要一起拷，拷完权限也要跟着改，Linux 下漏了chown会表现为服务起来了但加载模型报权限错误。

5.5 第三方界面接不上 11434

现象：Chatbox 或网页版界面里填了http://localhost:11434，点保存后提示连接失败，或者对话时报跨域错误。

原因：localhost在部分系统上优先解析成 IPv6 地址，而 Ollama 默认只监听 IPv4 的127.0.0.1；网页版界面还会受浏览器同源策略限制，需要服务端明确允许来源。

解决：地址栏里的localhost一律换成127.0.0.1再试，这一条能解决大部分连接失败。网页端接入的话，要给 Ollama 加OLLAMA_ORIGIN环境变量，值填界面的来源地址，改完同样要重启服务。这里有个安全提醒：不要为了图省事把OLLAMA_HOST改成0.0.0.0又不做任何访问控制，那等于把本机的模型能力开放给整个网段，公网机器上尤其不能这么干。

6. 装完怎么验证跑通：一份五分钟验收清单

装完不等于跑通，跑通不等于好用。我习惯在交付给自己或别人的时候走一遍固定验收，五分钟能过完，能提前暴露八成问题。

验收项	执行方式	期望结果
服务在线	`curl http://127.0.0.1:11434`	返回`Ollama is running`
模型就位	`ollama list`	目标标签在列，`SIZE`与磁盘占用吻合
算力落点	提问后立即`ollama ps`	`PROCESSOR`显示`100% GPU`，或可接受的混合比
短问答	问一句「1+1 等于几，只回答数字」	两秒内返回，内容正确
长上下文	贴 3000 字文档让它总结	不报错、不截断、不答非所问
接口可用	`/api/chat`的 curl 请求	返回 JSON，`message.content`非空
界面连通	Chatbox 里发一句话	正常回显，无连接错误

短问答这一项别嫌简单，它能一次性验证服务、模型、显存三条链路都通。长上下文那一项是专门用来打num_ctx的——如果贴进去的长文档被截断，或者模型开始答非所问，说明上下文窗口设小了，回第 4 章改 Modelfile 里的num_ctx。

最后再补一个我自己的习惯动作：把这次装的版本、模型标签、关键环境变量记在一个deploy.md里，跟模型目录放一起。

# 一条命令把关键信息落到文件，换机器时直接照着复现 { echo "## $(date +%F) 部署快照" ollama -v ollama list systemctl show ollama | grep -i environment # Linux nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv } > deploy.md

这几行输出记下来，下次换机器或者系统重装，照着抄一遍就能复现同样的环境，不用再回忆当时到底设了哪些变量。

从那以后我每次装完本地模型，都强制走一遍这套验收流程，哪怕只是换了个模型标签。因为「能启动」和「跑得对」之间隔着的坑，往往要等到真正拿它干活那天才暴露出来，那时候再回头查是最难受的。希望这套流程能帮到你。

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