简介：面向希望将大语言模型落地到私有环境的技术爱好者、企业IT管理者与开发者，这份PDF指南围绕DeepSeek的本地化部署展开，重点解决敏感数据不出内网、模型权限自主可控以及垂直场景定制等问题。内容结合自然语言处理与深度学习应用背景，梳理模型特点、硬件与软件准备、Ollama与CUDA环境配置、部署流程、常见问题及进阶用法，并延伸到医疗辅助诊断、金融风控、教育资源推荐等场景，兼顾GPU加速与不同硬件条件下的运行优化。资源包仅含1个PDF文件，大小约586KB，篇幅紧凑，便于按章节查阅部署思路与配置要点。已有701人学习，适合需要了解私有化AI服务搭建、模型微调与场景适配的读者作为实践参考，也可为后续定制开发和性能调优提供索引。

1. 从一块 8GB 显存的旧卡说起：先定档位再动手

前阵子帮人收拾一台机器，显卡 8GB 显存、内存 32GB。Ollama 装完，ollama -v正常返回版本号，看着一切顺利；接着ollama run deepseek-r1:14b，风扇起飞，屏幕上文字一个字一个字往外挤，实测不到 2 token/s。查了半天才发现模型压根没上 GPU，而是全在 CPU 上运行。本地部署 DeepSeek 大语言模型如今门槛确实低，一条命令就能拉模型，但“能跑”和“跑得对”完全是两回事：档位选大了显存爆，驱动版本对不上就自动回落到 CPU，模型目录默认塞系统盘，几十 GB 下去 C 盘直接见红。这套环境适合手上有独立显卡、想把自然语言处理能力留在自己机器里的开发者，也适合对数据外发有顾虑、要一套自主可控推理环境的技术负责人。下面按我实际装机的顺序走一遍，装什么版本、参数怎么配、坏了怎么救，都写清楚。

2. 装之前先把账算清：Ollama 与 CUDA 的版本对齐

动手下载安装包之前，先花十分钟把机器的底细摸清楚，比装到一半再回头删要省事得多。本地跑大语言模型这件事，瓶颈九成出在显存和磁盘上，而版本对不齐又是“装成功了但没加速”的头号原因。这一章的两个动作——查 GPU 现状、配环境变量——决定了后面所有命令是有用功还是白忙。

2.1 先确认三件事：显卡、驱动、可用磁盘

第一件事是打开命令行跑一次显卡状态查询，把型号、显存总量、驱动版本一次性看全。

# Windows / Linux 通用，需已安装显卡驱动 nvidia-smi

输出右上角那行CUDA Version: 12.x经常被误读，它是当前驱动能够支持的最高 CUDA 版本，不是你机器上已经装了什么。左下角MiB / MiB才是显存总量。如果这条命令直接报“不是内部或外部命令”，说明驱动没装或没进 PATH，这时候先去补驱动，别急着装 Ollama。

第二件事是算磁盘。模型权重按 4bit 量化后大致是这个量级，下载时还要额外占一份临时空间，所以实际可用空间建议按表里数字的两倍留：

第三件事，把ollama list的语义搞清楚。它列的是本机已经下载过的模型，不是模型仓库里有什么。想看仓库有哪些档位，直接ollama run deepseek-r1:7b触发拉取即可，拉不到会明确报错。我见过有人拿ollama list | grep deepseek当搜索命令用，结果输出空行，误判成“没有这个模型”。

2.2 CUDA Toolkit 装不装，看你要不要 nvcc

这里有个流传很广的误解：以为不装 CUDA Toolkit，Ollama 就用不上 GPU。实际上 Ollama 的安装包里已经带了跑推理所需的运行库，纯粹为了跑模型，不装 Toolkit 也能吃到 GPU 加速。装它的真实价值在于拿到nvcc这个编译器入口——排查“到底是驱动旧了还是运行库不匹配”的时候，nvcc -V和nvidia-smi两个版本号一对照，问题基本就定位了。

要装的话，去 CUDA Toolkit 的归档页面，按上一节nvidia-smi右上角显示的版本号往下选一到两个小版本，别直接选最新版。安装向导里保持默认路径，唯一需要注意的是“自定义安装”那一步：如果显卡驱动已经是最新，把 Driver 组件取消勾选，只留 Toolkit，避免装完驱动被降级。

# 安装完成后新开一个终端验证，注意是大写 V nvcc -V

大写-V输出编译器版本，小写-v在部分版本里是 verbose 模式，输出一大堆编译细节，第一次装的人容易被吓到。这条命令能返回版本号，说明 Toolkit 本体和 PATH 都通了。

2.3 环境变量：两条 Path 和三个 OLLAMA_ 前缀

CUDA 装完必须手工进 PATH，否则命令行永远找不到nvcc。需要加的是两条：...\CUDA\vXX.X\bin和...\CUDA\vXX.X\libnvvp。图形界面里改最稳，用命令行的话长这样：

:: 管理员权限的 cmd 中执行，路径按实际版本号替换 :: 注意 setx 有 1024 字符截断风险，PATH 很长时改用图形界面 setx /M PATH "%PATH%;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4\bin" setx /M PATH "%PATH%;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4\libnvvp"

比 CUDA 更值得提前配的是 Ollama 的三个环境变量，其中OLLAMA_MODELS是我每台机器都第一个设的：

:: Windows 下设置，设置完必须重启 Ollama 服务才生效 setx OLLAMA_MODELS "D:\ollama\models" setx OLLAMA_HOST "127.0.0.1:11434" setx OLLAMA_KEEP_ALIVE "30m"

OLLAMA_MODELS改模型存放目录，绕开“默认装 C 盘”这个最大的空间隐患；OLLAMA_HOST决定服务监听在哪个地址端口，本机自用绑127.0.0.1就够，要让局域网里另一台机器访问才改成0.0.0.0:11434；OLLAMA_KEEP_ALIVE控制模型在显存里驻留多久，默认 5 分钟，频繁问答的场景调到 30 分钟能省掉反复加载的十几秒等待。

注意：Windows 上用setx设置完，当前已打开的命令行窗口读不到新值，必须关掉重开；托盘里的 Ollama 也要右键退出再启动，否则它仍按旧配置跑。

Linux 下改法不一样，装完 Ollama 后它是个 systemd 服务，得用 override 的方式写：

sudo systemctl edit ollama.service # 在打开的编辑器里加入下面两行 # [Service] # Environment="OLLAMA_MODELS=/data/ollama/models" sudo systemctl daemon-reload && sudo systemctl restart ollama

改完用systemctl show ollama | grep Environment确认值确实进去了，这比“改完直接重启碰运气”可靠得多。

3. 三个平台装 Ollama：Windows 的坑最多

Ollama 本身的安装过程没什么技术含量，真正的差异全在“装完之后它怎么跑起来”。Windows 是托盘程序，macOS 是应用包，Linux 是 systemd 服务，三种形态决定了你改配置、看日志、重启服务的方式完全不同，混着用命令就会各种不生效。

3.1 Windows：默认装 C 盘，先腾地方再点安装

去 Ollama 官网首页点 Download，选 Windows 版，拿到的是一个.exe。双击运行，向导里同意协议、保持默认路径、点 Install，等进度条走完点 Finish。整个过程唯一需要留意的是安装包本身不接受自定义安装目录，所以 C 盘至少要留 5GB 余量；但这只是程序本体，模型该放哪由OLLAMA_MODELS说了算，装完立刻按上一节把它指到大盘上去。

装完托盘区会出现 Ollama 图标，说明服务已在后台常驻。验证分两步，先看版本再看服务：

:: 第一步：确认可执行文件在 PATH 里 ollama -v :: 第二步：确认后台服务真的起来了，返回 Ollama is running 才算通 curl http://localhost:11434

如果ollama -v有输出但curl没反应，八成是托盘程序被关掉了，或者 11434 端口被别的程序占了。Windows 下查端口占用：

netstat -ano | findstr :11434

拿到最后一列的 PID，去任务管理器里对照，确认是 Ollama 自己还是别的服务。如果是冲突，把OLLAMA_HOST改成127.0.0.1:11435再重启服务即可，后面所有调用地址同步改。

3.2 macOS 与 Linux：拖拽与一行脚本的差别

macOS 拿到的是.dmg，双击挂载后把 Ollama 图标拖进 Applications 文件夹，就这一步。首次启动时系统会弹安全提示，去“系统设置 → 隐私与安全性”里点“仍要打开”，之后就不会再拦。终端里跑ollama -v验证，服务和菜单栏图标是绑定的，退出图标等于停服务。

Linux 用官方脚本，一条命令把二进制、用户、systemd 单元全给你配好：

# 需要 sudo 权限，脚本会自动创建 ollama 用户并注册 systemd 服务 curl -fsSL https://ollama.com/install.sh | sh

这个脚本做了三件事：下载对应架构的二进制放到/usr/local/bin、创建系统用户ollama、注册并启动ollama.service。装完用systemctl status ollama看状态，绿色的 active (running) 才是正常。有一点要注意，服务是以ollama这个系统用户身份跑的，所以OLLAMA_MODELS指向的目录必须给这个用户读写权限，否则模型拉下来会报权限错误：

sudo mkdir -p /data/ollama/models sudo chown -R ollama:ollama /data/ollama

这一步漏掉的话，现象是ollama pull跑到一半突然 permission denied，很容易被误判成网络问题。

3.3 验证服务活着：11434 端口和 ollama -v

三个平台装完，验收动作是同一套。ollama -v证明命令行工具就绪，访问 11434 端口证明服务就绪，两者都过才算装完。Linux 和 macOS 上再补一条端口检查，比 Windows 的 netstat 干净：

# 看谁在监听 11434，正常应输出 ollama 进程 lsof -i :11434

还有一个容易忽略的点：如果你改了OLLAMA_HOST又想让浏览器访问，注意浏览器里填的地址要和配置一致。绑了127.0.0.1就只有本机能开，同事的机器打不开是预期行为，不是配置错了。

4. 拉模型与第一次对话：deepseek-r1 各档位怎么选

到这一步环境已经就绪，剩下的是把模型搬下来、跑通第一句话。这部分翻车最多的地方不是命令写错，而是档位和硬件不匹配——模型能加载、能出字，但慢到没法用，或者加载到一半直接 OOM。选档位的原则很简单：先按显存卡上限，再按内存留余量，宁可小一号也别硬上。

4.1 档位对照与选择逻辑

上一章那张表是静态参考，实际选的时候还要看你的任务类型。1.5b 这类小模型响应快、占用低，做短文本改写、格式转换、简单问答完全够用，缺点是长链条推理容易断片；7b 是平衡点，一般办公和研发场景我默认从这里起步；14b 在长文档摘要、代码补全上明显更强，但显存低于 16GB 会开始往内存里溢出，速度断崖式下跌；32b 往上就是专业用途了，单卡消费级显卡基本吃力，除非你能接受每分钟出几十个字。

一个实操判断法：模型加载完成后跑ollama ps，看 PROCESSOR 那一列。写着100% GPU就是全量上卡，写着100% CPU说明加速完全没生效，写着类似70%/30% CPU/GPU的混合比例，就是显存不够、部分层被挤到内存里了，这时候要么降档，要么调小上下文长度。

4.2 ollama pull 与 run 的区别，以及断点续传

run和pull都会下载模型，区别在于run下完直接进交互界面，pull只下载。批量准备环境时我习惯先用pull单独拉，失败了不影响后面脚本继续跑：

# 只下载不入交互，适合提前把模型备好 ollama pull deepseek-r1:7b # 下载并进入对话，出现 >>> 提示符即可提问 ollama run deepseek-r1:7b

进入交互后输入问题回车，模型开始流式输出。退出用/bye，别直接 Ctrl+C，某些终端下强退会留下未清理的会话上下文。Ollama 的模型文件是按 blob 分片存的，下载中断后重新执行同一条pull，已经下完的分片不会重来，会从断点继续——这一点比很多人以为的“每次从头开始”要好，所以断了别删目录，直接重跑命令。

# 确认模型完整落盘，以及它占了多少空间 ollama list

ollama list输出的 SIZE 列要是明显小于上表里的量级，说明下载不完整，重新pull一次补齐。

4.3 三个真正影响体感的参数：num_ctx、num_gpu、temperature

默认参数下模型能用，但谈不上好用。三个参数调完，体验差距很明显：num_ctx控制上下文窗口，默认 4096，处理长文档时不够用，但每往上翻一倍显存占用也跟着涨；num_gpu控制多少层放到 GPU 上，99 表示尽量全放；temperature控制输出随机性，0.6 左右适合问答和代码，往 0.9 走适合创意文本。

交互模式里可以临时改：

# 进入对话后输入，只对当前会话生效 >>> /set parameter num_ctx 8192 >>> /set parameter temperature 0.6

要通过 HTTP 接口调用或者写进脚本，用 API 的 options 字段：

curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "用三句话解释什么是梯度下降", "stream": false, "options": { "temperature": 0.6, "num_ctx": 8192, "num_gpu": 99, "num_batch": 512 } }'

stream: false让接口一次性返回完整结果，适合脚本里取；num_batch是批处理大小，调大能提升吞吐但显存峰值同步上涨，显存吃紧的卡上把它降到 256 甚至 128，往往就能把 OOM 压下去。

经常用同一套参数的话，别每次都手敲，写个 Modelfile 固化下来：

# 保存为 Modelfile，然后 ollama create 生成一个自定义模型 FROM deepseek-r1:7b # 上下文扩到 8K，温度固定 0.6 PARAMETER num_ctx 8192 PARAMETER temperature 0.6 # 系统提示词也一并固化，省得每次重复交代 SYSTEM "你是一个严谨的技术助手，回答尽量给可执行结论。"

ollama create ds-tech -f Modelfile ollama run ds-tech

这样以后换机器、换项目，把 Modelfile 拷过去重建一遍就行，参数不会漂。

5. 避坑记录：五条在本地部署 DeepSeek 时真踩过的坑

这一节全是血泪经验，按“现象 → 原因 → 解决”的顺序写，遇到相似症状可以直接对号入座。有些坑表面看是模型问题，实际是系统层面的事，不熟悉的话能查一整天。

5.1 C 盘一夜少 20GB

现象：装完 Ollama 一切正常，用了一周后发现 C 盘可用空间从 40GB 掉到个位数，系统开始弹低空间警告。

原因：模型默认落在用户目录下的.ollama/models，Windows 上就是C:\Users\<用户名>\.ollama\models。一条pull命令下 14b 就是 9GB，再下个 32b 直接 20GB 起步，加上 Ollama 保留的旧 blob 不会自动清理，几个版本迭代下来很容易吃穿系统盘。

解决：先设OLLAMA_MODELS指到数据盘，重启服务，再把旧目录整体搬过去，别用复制粘贴——用移动或软链接更稳妥。

:: 先停掉托盘里的 Ollama，再执行下面的移动 move C:\Users\%USERNAME%\.ollama\models D:\ollama\models

# Linux 下如果不想改环境变量，软链接也是可行方案 sudo systemctl stop ollama sudo mv /usr/share/ollama/.ollama/models /data/ollama/models sudo ln -s /data/ollama/models /usr/share/ollama/.ollama/models sudo chown -R ollama:ollama /data/ollama sudo systemctl start ollama

搬完用ollama list确认模型还在，能列出来就说明路径生效了。

5.2 明明有独显，ollama ps 显示 100% CPU

现象：机器上有独立显卡，nvidia-smi也正常，但跑模型时显卡占用接近零，ollama ps的 PROCESSOR 列写着 100% CPU，出字速度只有个位数 token/s。

原因：最常见的是显卡驱动版本过老，低于 Ollama 内置运行库要求的最低版本，程序检测到不兼容就静默回落到 CPU，不报任何错。第二种是笔记本双显卡切换，进程实际跑在核显上。第三种是显存被别的程序（浏览器硬件加速、其他推理进程）占着，Ollama 加载时判定不够用，直接放弃 GPU。

解决：第一步先升驱动到官网当前稳定版，重启后再试。第二步在 NVIDIA 控制面板里把ollama.exe的 OpenGL 渲染 GPU 指定为独显。第三步跑之前先清场：

# 看当前显存被谁占了 nvidia-smi # 看 Ollama 自己加载后的分层情况 ollama ps

如果ollama ps显示的是70%/30% CPU/GPU这种混合比例，说明是显存不够，降到 7b 档或者把num_ctx压回 4096，通常就能回到 100% GPU。

5.3 命令行输出全是一堆方块和乱码

现象：模型明明在正常生成，终端里却是一屏问号和方块，复制出来也是乱码，完全没法用。

原因：Windows 老版本 cmd 默认代码页是 GBK，模型输出的是 UTF-8，编码对不上就变成乱码；另一种是终端字体不含中文字形，字符能正确解码但渲染成方块。原文里那种满屏诡异符号，就是编码和字体两个问题叠加的结果。

解决：换 PowerShell 或 Windows Terminal，先切代码页再启动：

:: 切到 UTF-8 代码页，再启动模型 chcp 65001 ollama run deepseek-r1:7b

如果还不行，就是字体问题，在终端设置里把字体换成等宽中文字体（比如各种 Mono 结尾的中文字体）。Linux 和 macOS 上出现乱码的概率低得多，真遇到了先查echo $LANG是不是 UTF-8。

5.4 模型拉到 87% 断了，重来又从零开始

现象：下载进度条走到一大半突然中断，网络恢复后重跑ollama run，进度显示又从 0% 开始，让人以为前功尽弃。

原因：两个可能。一是确实在续传，但进度条是从“已完成的 blob 总数”重新算的，显示上像从零开始，实际不用重下；二是磁盘写满或权限不足，blob 写不进去，每次都在同一个位置失败，看起来就像永远下不完。

解决：先看磁盘剩余空间和目录权限，再判断是不是显示问题。

# 查看模型目录已落盘的分片，以及剩余空间 du -sh ~/.ollama/models 2>/dev/null; df -h

如果空间和权限都正常，就别删目录，直接重跑ollama pull deepseek-r1:7b，让它自己续。反过来，如果ollama list里出现了这个模型但 SIZE 明显偏小，那才是真损坏，需要先ollama rm deepseek-r1:7b再重新拉。这条命令是我每次下载失败后的第一反应，比盲目删整个 models 目录安全得多。

5.5 CUDA out of memory 与端口被占

现象：模型能加载，一提问就抛显存不足；或者装完curl一直连不上，报连接被拒绝。

原因：显存不足多半是上下文开太大或者并发请求太多，num_ctx8192 配合 14b 模型，光 KV 缓存就要吃掉好几 GB；端口问题通常是上一次的 Ollama 进程没退干净，或者别的服务占了 11434。

解决：显存这边从三个方向压——降档、缩上下文、限制并发。

# 限制同时处理的请求数，默认值在显存紧张时偏大 export OLLAMA_NUM_PARALLEL=1 export OLLAMA_MAX_LOADED_MODELS=1

端口这边先定位再处理，找到占用进程杀掉，或者干脆换端口：

# 换个端口，重启服务后所有调用地址同步改 export OLLAMA_HOST=127.0.0.1:11435 ollama serve

有个细节值得记一下：ollama serve手动前台启动时，如果后台服务已经在跑，会直接报端口被占——这不是故障，是它不让你起第二个实例。先ollama ps和systemctl status ollama确认有没有在跑的，再决定是重启还是换端口。

6. 装完怎么验证跑通：把 OpenWebUI 接上 11434

命令行能对话只证明模型活着，要确认整套环境真的可用，我会再接一层 Web 界面做端到端验收——它同时踩到了模型服务、HTTP 接口、跨进程通信三个环节，任何一环没配好都会在这里暴露。OpenWebUI 满足这个需求，本机自托管、完全离线，装上就能用。

它需要 Python 3.11 以上，先建虚拟环境隔离依赖，别直接往系统 Python 里装：

python -m venv openwebui_env # Windows openwebui_env\Scripts\activate # macOS / Linux source openwebui_env/bin/activate pip install open-webui open-webui serve

启动后浏览器打开http://localhost:8080，第一次进要注册一个本地管理员账号，数据都存在本机。进设置里找连接配置，把 Ollama 的服务地址填成http://localhost:11434，保存后模型列表里应该能直接看到已经拉下来的deepseek-r1:7b。这里有个高频坑：如果 OpenWebUI 是跑在容器里的，localhost指的是容器自己，得改成宿主机的内网地址才能连上，这是新手最容易卡住的一步。

验收我固定看三项，都过才算这套环境可用：

第三项最容易被跳过，但它恰恰是判断“有没有真正用上 GPU 加速”的唯一可靠依据——界面能出字不代表跑在显卡上，很多人就这么在 CPU 上慢悠悠用了半个月才发现。

从那以后我每次装完这套环境，都会强制走一遍ollama ps看 PROCESSOR 列的流程，哪怕界面已经能正常对话。这一步只花三秒钟，却能挡住“装成功了但加速没生效”这类最隐蔽的问题。希望这套流程能帮到你，少在同样的地方卡第二次。

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