资讯动态

Win11上Ollama本地部署DeepSeek-R1:硬件配置与避坑指南

发布时间:2026/10/6 1:32:22 来源:尧图企业网站定制
简介面向需要在 Windows 11 上本地运行大语言模型的开发者与人工智能爱好者这份 PDF 指南以 Ollama 为工具系统讲解 DeepSeek-R1 的本地部署方案帮助用户摆脱对云端服务的依赖从而增强数据隐私保护并减少网络延迟带来的影响。资源为单个 PDF 文件压缩包大小约 264KB篇幅紧凑却覆盖了从处理器、显卡、内存、存储空间等硬件要求到 Ollama 安装与启动、模型拉取和验证、命令行交互等关键步骤并给出了多核 CPU、NVIDIA GPU、16GB 以上内存以及固态硬盘等实际配置建议。指南还介绍了通过 REST API 使用 Python 调用本地模型的方法以及借助 Modelfile 自定义温度、top_p 等参数并构建专属模型配置的进阶用法同时针对模型下载失败、运行缓慢、服务端口被占用等常见问题提供了具体排查思路。目前已有 4333 人学习下载适合希望快速上手本地大模型部署、进行离线实验或关注隐私敏感场景的开发者和技术爱好者。1. 在 Win11 上用 Ollama 本地部署 DeepSeek-R1一台普通电脑能跑到什么程度所谓“Win11 使用 Ollama 本地部署 DeepSeek-R1”就是跳过云端 API把 DeepSeek-R1 的蒸馏版本装进自己机器里通过 Ollama 这个运行时去加载和推理。它的实际价值不在于跑出接近 DeepSeek 官方满血版的效果而在于请求不出本机、断网可用、数据不进别人日志同时还能按自己需求调上下文、换量化、接 Web 界面。适合三类人想给本地知识库配一个能连续对话的模型的人手里有多余显卡或大内存想榨干性能的人以及被云端 API 限流和计费折腾过、想彻底把对话能力收编到内网的人。这篇指南按能直接复现的方式写先算配置账再给安装命令最后是参数设置和五个必踩的坑。2. 环境准备先说硬件显存、内存与量化版本的匹配再装 Ollama 并改模型存储路径2.1 12GB 内存能跑什么DeepSeek-R1 各参数版本的真实占用Ollama 仓库里的 DeepSeek-R1 是蒸馏系列常见标签有 1.5b、7b、8b、14b、32b、70b。这里的 7b 不是满血 671B而是基于 Qwen 或 Llama 蒸馏出来的小模型推理质量不能和满血版比但胜在桌面机带得动。我第一次部署时犯过一个错以为 7b 就是 7GB结果直接把 C 盘撑爆了。实际占用要先看量化格式Ollama 默认拉取的通常是 Q4_K_M 量化模型文件大小如下模型标签磁盘占用约推理时内存/显存需求约适合配置1.5b1.1 GB2 GB 内存任何能跑 Win11 的机器7b4.7 GB8 GB 内存最好 16 GB16GB 内存的日常本8b4.9 GB8 GB 内存最好 16 GB同上14b9.0 GB16 GB 内存起步32GB 内存或 8G 显存32b20 GB32 GB 内存起步24G 显存或 64GB 内存70b43 GB48 GB 内存起步纯 CPU 很吃力双卡或多卡工作站注意区分“模型文件大小”和“运行时占用”。推理时除了权重本身还有 KV Cache 和临时计算图上下文长度设得越长额外内存涨得越快。我自己在 16GB 内存的笔记本上跑 7b把 num_ctx 默认的 2048 调到 8192 后内存占用冲到 14GB多开两个浏览器就明显卡顿。所以硬件的账不是只看模型大小还要看你打算给多长的上下文。另一个容易忽略的点是显卡。Win11 下 Ollama 优先用 NVIDIA 显卡的 CUDA 加速AMD 显卡虽然 Ollama 有 ROCm 分支支持但在 Windows 上兼容性不如 Linux很多人最终用 CPU 跑。CPU 跑 7b 不是不行生成速度大概每秒 5 到 10 个 token回答一段代码要等十来秒能忍就能用。结论是内存决定能不能跑显卡决定跑得快不快。2.2 winget 一步安装 Ollama再把模型目录从 C 盘搬走安装 Ollama 在 Win11 上最省事的路径是用 winget这是 Windows 自带的包管理命令不需要手动去官网找安装包。以管理员身份打开 PowerShell 或 Windows Terminal执行winget install --id Ollama.Ollama -e逻辑说明-e 参数要求精确匹配 Ollama.Ollama 这个包 ID避免装到同名第三方程序。winget 会把 Ollama 安装到用户级目录同时注册一个后台服务装完后在系统托盘会出现一个带羊驼图标的进程这就是 Ollama 的常驻服务。如果 winget 拉取仓库慢也可以直接从官网下载安装包效果一样只是后续升级要自己盯。装完后先别急着拉模型第一件事是把模型存储目录改到非系统盘。Ollama 默认把模型 blob 放在C:\Users\用户名\.ollama\models下一旦拉了几个 7b、14b 模型C 盘很快会被吃掉二三十 GB。改路径用环境变量 OLLAMA_MODELSsetx OLLAMA_MODELS D:\ollama\models逻辑说明setx 会把变量写入用户环境变量但当前已经打开的终端窗口读不到新值必须新开一个 PowerShell 窗口才生效。我在这上面翻过车执行完 setx 后直接在旧窗口里 ollama pull模型照样下到 C 盘还以为是命令没生效。改完后确认一眼echo $env:OLLAMA_MODELS如果输出D:\ollama\models说明新窗口已经带上变量。还要做一件事把旧目录里的文件复制过去或者直接删掉避免 C 盘里残留之前下到一半的模型片段。注意让D:\ollama\models目录本身先建好Ollama 不会自动帮你创建整条目录路径。2.3 第一道验证ollama serve 与 ollama list安装完成、环境变量改好后先用三条命令确认服务端是活的。Ollama 的架构分客户端和服务端ollama run是客户端命令它要连到本地服务端才能工作服务端就是常驻在托盘里的那个进程底层监听 11434 端口。ollama --version ollama serve ollama list逻辑说明ollama --version确认命令行工具可用ollama serve是手动启动服务端如果提示端口已被占用说明托盘里的后台进程已经在跑这是正常现象不需要再起一个ollama list列出本机已拉取的模型刚装完应该是空列表。如果ollama list报错连接失败大概率是托盘进程没起来去开始菜单手动启动 Ollama或者在任务管理器里看一眼后台进程。另外建议顺手测一下服务端口是否在监听Test-NetConnection -ComputerName localhost -Port 11434输出里 TcpTestSucceeded 为 True说明服务端就绪。这一步很多人跳过结果后面 API 调不通时分不清是模型问题还是服务问题。到这里环境就绪了下一步才真正进入模型拉取。3. 拉取 DeepSeek-R1 模型两种落地路径与 Modelfile 的参数写法3.1 ollama run deepseek-r1:7b 起步首次拉取的完整链路环境就绪后最直接的方式是用ollama run一条命令把模型拉下来并进入交互。以 7b 版为例ollama run deepseek-r1:7b逻辑说明这个命令拆成两步如果本地没有 deepseek-r1:7b 这个标签Ollama 会先从官方仓库下载对应 blob 文件下载完成后加载模型并进入一个交互式对话窗口。之后你再输入的问题都会走本地推理。首次下载的模型文件约 4.7GB具体耗时取决于带宽这个阶段最容易卡住后面第 5 章专门讲。进入交互后可以先从一句简单的请求开始请用一句中文介绍你自己第一次提问时你可能看到终端停住几秒到几十秒这是模型在加载权重不是死机。之后每句话的等待时间就是生成耗时。想退出交互按/bye回车模型不会立即从内存卸载Ollama 会保留一段时间以便下次快速响应。如果你不想进入交互只想先把模型下好用ollama pull deepseek-r1:7b逻辑说明pull 只下载不加载适合在晚上挂机把模型先拉到位。需要哪个版本就把标签换成deepseek-r1:14b、deepseek-r1:32b等。我一般建议先拉 7b 跑通全流程再按内存余量决定要不要换更大的版本一上来就拉 70b 很容易把机器拖死。3.2 官方仓库拉不动就换一条路从 ModelScope 拿 GGUF 再导入Ollama 官方仓库在国内时常处于龟速状态一个 4.7GB 的文件可能拉到半夜。常见做法是换一条路径从 ModelScope 下载 GGUF 格式的模型文件再通过 Ollama 的导入机制创建本地模型。这套流程不依赖镜像配置只需要一台能正常访问 ModelScope 的机器。先在合适目录建好模型文件夹用 ModelScope 的 Python 包下载 DeepSeek-R1 蒸馏版的 GGUF 文件pip install modelscope python -m modelscope download --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B-GGUF --local_dir D:\ollama-download\deepseek-r1-7b逻辑说明这条命令把模型仓库下载到D:\ollama-download\deepseek-r1-7b目录。仓库里通常有多个量化文件例如 Q4_K_M、Q5_K_M、Q8_0 等Ollama 能直接加载的是带 gguf 后缀的文件优先选名字里含 Q4_K_M 的版本体积和质量的平衡点最接近官方默认。如果你不想装 Python 包也可以直接在 ModelScope 网页端找到对应文件手动下载一个 gguf 文件即可注意别下错成 safetensors。拿到 gguf 后在同目录写一个 Modelfile这是 Ollama 用来描述“怎么组装这个模型”的配置文件FROM D:\ollama-download\deepseek-r1-7b\deepseek-r1-distill-qwen-7b-Q4_K_M.gguf PARAMETER temperature 0.7 PARAMETER top_p 0.8 SYSTEM 你是部署在本机的 DeepSeek-R1 助手回答要简洁直接。然后执行创建命令ollama create deepseek-r1-local -f Modelfile逻辑说明deepseek-r1-local是给这个本地模型起的标签可以按自己的喜好命名-f Modelfile指定配置文件路径。创建过程会做一次校验并把 gguf 复制到 Ollama 的模型存储目录之后ollama list里就能看到这个标签。这条路的本质是绕开官方仓库的下载瓶颈模型文件来源从 ModelScope 走剩下的加载和推理逻辑完全和官方拉取一样。3.3 用 Modelfile 固定推理参数FROM、PARAMETER 与 SYSTEMModelfile 里最值得花时间调的是 PARAMETER 和 SYSTEM 两段。PARAMETER 控制采样行为SYSTEM 决定模型的人格和回答风格。我常用的模板FROM deepseek-r1:7b PARAMETER temperature 0.6 PARAMETER top_p 0.9 PARAMETER repeat_penalty 1.1 SYSTEM 你是 R1 助手。代码问题先给结论再给示例普通问题控制在 300 字以内。逻辑说明temperature 控制随机性。DeepSeek-R1 系列本身带有推理倾向temperature 调到 0.7 以上时回答会啰嗦且偶尔跑偏0.5 到 0.6 更适合编程和逻辑问答。top_p 是核采样阈值0.8 到 0.9 之间比较稳妥越小回答越发散度低。repeat_penalty 用来压制重复1.1 是个常用经验值如果输出出现循环复读把它升到 1.15。在ollama run的交互会话里也可以不改 Modelfile 临时调参/set parameter temperature 0.6 /set parameter num_ctx 8192逻辑说明这种改法只对当前会话生效退出后恢复默认。Modelfile 的改动是永久的。我个人的习惯是如果只是聊天调试用/set parameter快速试确认好一组参数后再写进 Modelfile 固定住。SYSTEM 提示词里也能塞一些“包装”比如让模型在代码回答开头标注语言类型、在末尾给复杂度提示这对实际使用体验的提升比调温度更明显。4. 把部署参数调到能用上下文长度、并发数与 API 计时验证4.1 聊两句就忘干净num_ctx 与 OLLAMA_NUM_PARALLEL 怎么设本地部署里最容易暴露体验短板的是上下文长度。Ollama 默认的 num_ctx 是 2048翻译成大白话就是模型最多记住约 2048 个 token 的对话内容折合中文大概一千多字。聊几轮后它就“失忆”了这不是模型问题是上下文窗口被截断了。把它调大的方式有两种。交互模式下直接设/set parameter num_ctx 8192逻辑说明8192 是日常够用的档位能覆盖大约五千字的中文对话或一个中等函数文件的上下文。如果你要让它分析长文档可以调到 16384但内存占用会明显上升。原因在于上下文越长KV Cache 占用的内存呈近似线性增长8GB 内存的老机器调到 16384 极可能加载到一半直接退出。API 调用时通过 options 字段传参这比交互模式更可控curl http://localhost:11434/api/generate -d {\model\:\deepseek-r1:7b\,\prompt\:\写一个快速排序\,\stream\:false,\options\:{\num_ctx\:8192,\temperature\:0.6}}逻辑说明options 里的 num_ctx 只对这一次请求生效不会污染模型默认参数。适合程序化调用时按任务类型切换上下文长短比如代码生成用 8192普通问答用 4096。并发方面Ollama 在 Windows 上通过环境变量 OLLAMA_NUM_PARALLEL 控制同时处理的请求数默认值是 1。如果只是自己用保持默认即可如果多人同时访问你部署的模型把这个值调到 2 或 4。但要注意并发和上下文是互相挤占资源的四个并发每个 8192 上下文16GB 内存基本撑不住Ollama 会退化为排队而不是真正并行。我一般会在 16GB 内存的机器上设置 OLLAMA_NUM_PARALLEL1在 32GB 以上才考虑 2 以上。设置方式还是 setx 加新开终端setx OLLAMA_NUM_PARALLEL 24.2 用 curl 调 /api/generate验证模型是不是真的能用交互式对话能跑通不代表 API 可用。很多场景下你要的不是一个终端窗口而是能被 Python、Web 后端或自动化脚本调用的接口。Ollama 在本地暴露了 HTTP API端口 11434核心是 /api/generate 和 /api/chat 两个端点。验证思路很简单发一个带计时信息的最小请求。curl http://localhost:11434/api/generate -d {\model\:\deepseek-r1:7b\,\prompt\:\11\,\stream\:false}逻辑说明stream 设为 false 表示等待完整生成后一次性返回便于看结果和耗时字段。第一次请求的响应里会包含模型加载时间和推理时长。这个验证步骤不能省因为很多图形界面工具或封装库最终都是走这两个 API端口或参数不对时UI 上只会看到“无法连接”之类的模糊提示而 curl 能直接把问题暴露出来。如果嫌 JSON 转义麻烦可以换成--data-binary file.json的方式先写一个文件{ model: deepseek-r1:7b, prompt: 用一句话解释什么是局部变量, stream: false, options: { temperature: 0.5, num_ctx: 4096 } }然后执行curl http://localhost:11434/api/generate --data-binary request.json逻辑说明这种方式看起来多了一步但文件里能写多行 JSON可读性和可维护性都比长串转义字符好。返回 JSON 中重点看 response 字段是否包含有效答案其他暂时不用关心。4.3 用计时脚本判断算力load_duration 与 eval_count 怎么看API 返回的 JSON 里有几个字段是判断部署质量的关键load_duration 表示模型加载耗时eval_count 表示生成的 token 数量eval_count 除以 eval_duration 能算出每秒生成速度。写个 Python 脚本把这些字段整理成可读指标import json import time import requests url http://localhost:11434/api/generate payload { model: deepseek-r1:7b, prompt: 写一个判断闰年的 Python 函数, stream: False } start time.time() r requests.post(url, jsonpayload) data r.json() cost time.time() - start tokens_per_sec data[eval_count] / (data[eval_duration] / 1e9) print(f总耗时(含网络): {cost:.2f}s) print(f模型加载耗时: {data[load_duration] / 1e9:.2f}s) print(f生成 token 数: {data[eval_count]}) print(f生成速度: {tokens_per_sec:.2f} tokens/s)逻辑说明脚本先把请求耗时和模型内部耗时分开统计。请求总耗时包含网络和 HTTP 序列化开销load_duration 是变量加载进内存的时间eval_duration 才是纯推理时间。如果你用 CPU 跑 7b速度在 5 到 15 tokens/s 属于正常如果低于 3 tokens/s先看任务管理器里是不是有别的程序吃满了 CPU。NVIDIA 显卡跑 7b 通常能到 30 tokens/s 以上差距非常明显。这个脚本也适合换模型后做对比同一个 prompt分别测 7b 和 14b你能直观感受到质量提升和速度下降之间的权衡。部署完成后我建议把这脚本留作巡检工具平时怀疑模型变慢时跑一次能快速判断是模型问题还是系统负载问题。5. DeepSeek-R1 部署避坑清单下载卡住、空间报错、响应慢的排查顺序5.1 模型拉到 99% 就断重跑 ollama pull 有用吗现象ollama run deepseek-r1:7b下载到 90% 左右进度停止等很久也不动偶尔直接报 connection error。原因Ollama 的拉取过程是把模型文件切成分片写入本地网络波动或磁盘写入慢都会导致下载中断。最常见的是下载源连接超时尤其模型文件较大的 14b、32b。解决先重跑一次ollama pull deepseek-r1:7b。Ollama 会重新校验已下载的分片已完成的块不会重新下多数情况能从中断点继续。如果连续两次都在同一个百分比断开改用第 3.2 节的 ModelScope 导入方案不要在官方仓库这一个问题上死磕。另外把下载目标盘的剩余空间留足模型文件的两倍以上分片临时文件会占用额外空间。5.2 报错 no space left on device但磁盘明明有空位现象ollama run或ollama pull时报 no space left on device但检查 D 盘还剩几十 GB。原因Ollama 仍然在往 C 盘写。OLLAMA_MODELS 环境变量没有生效常见于两种情况setx 之后没有新开终端或者你在旧终端里执行了报告中的命令。解决确认环境变量值echo $env:OLLAMA_MODELS如果输出为空或还是默认路径新开终端重设setx OLLAMA_MODELS D:\ollama\models然后重启 Ollama 进程托盘图标右键退出再重新打开。注意以前已经拉下来的模型文件还留在 C 盘旧目录不会自动搬走需要手动把C:\Users\用户名\.ollama\models里的内容移动到 D 盘或者删掉重新拉。5.3 中文输出乱码、回答半天下不来先查温度与上下文再查 CPU现象模型回答里出现大量重复的繁体字或“嗯嗯嗯”这类循环一句话要等一分钟又或者输出全是无意义的特殊符号。原因两类问题常常同时出现。温度设置过高会导致采样发散DeepSeek-R1 系列尤其明显temperature 超过 0.8 时回答容易开始“说胡话”。另一类是上下文长度过大导致内存不足系统开始用虚拟内存交换生成速度断崖式下跌。解决先用/set parameter temperature 0.6把采样压低再设置/set parameter num_ctx 4096缩小时空窗。如果症状集中在长对话后期优先降 num_ctx如果第一句话就乱优先降 temperature。还有一类特殊情况是模型本身没下完整用ollama list对比模型大小和官方标注是否一致不一致就删除重拉。5.4 localhost:11434 连不上端口被占时换个监听位置现象curl 访问 http://localhost:11434 报 connection refused但托盘里的 Ollama 看起来在运行。原因Ollama 的 11434 端口被其他程序占用或者 Ollama 服务进程异常退出只留下了客户端壳。解决先看端口是谁占的netstat -ano | findstr 11434逻辑说明如果有 PID 且不是 Ollama 的进程说明端口冲突。可以通过环境变量改监听位置setx OLLAMA_HOST 127.0.0.1:11435新开终端重启 Ollama 后再用 11435 访问。如果 netstat 没有任何输出说明服务端没起来去开始菜单手动启动 Ollama。这里提示一下OLLAMA_HOST 设置为 0.0.0.0 可以允许局域网内其他设备访问方便手机或另一台电脑调用但 Win11 防火墙会拦截入站请求需要在防火墙里放行对应端口第一次设置时通常会弹出授权窗口。5.5 切模型时电脑卡成黑匣子给 Ollama 限制同时加载的模型数现象刚跑完 7b接着ollama run deepseek-r1:14b电脑直接卡死鼠标都移不动切回 7b 也要等很久。原因Ollama 默认会保留加载过的模型一段时间如果 7b 还没卸载14b 又要加载两个模型同时驻留内存内存瞬间打满系统开始疯狂交换内存。解决限制同时加载的模型数量setx OLLAMA_MAX_LOADED_MODELS 1逻辑说明设为 1 表示同一时间只保留一个模型在内存中。这样切模型时 Ollama 会先把旧模型卸载再加载新的首次响应变慢一些但至少不会把机器卡死。另外Ollama 的卸载有延迟如果只想立即释放内存可以在交互界面里用/clear清空上下文或者重启 Ollama 进程。这属于最容易忽略的“玄学”问题很多人以为是 14b 模型把内存吃爆了实际是两个模型叠加。6. 把本地 R1 接进日常工具Web 对话、Python 封装与开机自启6.1 用 Docker 起一个 Open WebUI浏览器里聊本地模型命令行的交互方式对非技术用户太不友好。常见做法是用 Docker 跑 Open WebUI它是开源的本地模型 Web 界面默认会去找本机的 11434 端口。安装好 Docker Desktop 后执行docker run -d -p 3000:8080 --add-hosthost.docker.internal:host-gateway -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 --name open-webui ghcr.io/open-webui/open-webui:main逻辑说明Open WebUI 跑在容器里容器内部的 localhost 和 Windows 本机不是同一个所以要加上--add-host参数把 Windows 主机地址映射为 host.docker.internal再通过 OLLAMA_BASE_URL 指向它。这是 Windows 上跑 Web 界面最常踩的坑不加这个参数界面里会一直提示连接不到 Ollama。启动后打开 http://localhost:3000注册一个本地账号在设置里选择 deepseek-r1 标签就能获得一个接近 ChatGPT 界面的对话环境而且支持多会话、历史记录和文档上传。6.2 Python 封装一个本地 R1 接口二十行代码接入自己的脚本比起 Web 界面Python 封装更能体现本地部署的价值。写一个简单的函数把 DeepSeek-R1 变成自己脚本里可调用的“工具”import requests def r1_chat(prompt, modeldeepseek-r1:7b, historyNone): messages history or [] messages.append({role: user, content: prompt}) r requests.post(http://localhost:11434/api/chat, json{ model: model, messages: messages, stream: False }) return r.json()[message][content]逻辑说明这个封装维护一个 messages 列表每次调用把新问题追加进去Ollama 会自己处理上下文的拼装。你可以用它做代码审查助手、日志摘要工具或者把它接到企业微信机器人的回调里。本地接口没有配额限制没有按 token 计费唯一限制就是内存和速度。6.3 把 Ollama 当 Windows 服务管理并看日志Ollama 在 Windows 上安装后默认随开机启动但偶尔会被安全软件或手动优化脚本关掉。把它纳入 Windows 服务管理是一个更可控的做法sc query ollama sc config ollama startauto逻辑说明sc query 查看服务状态和启动类型sc config 把启动类型改为自动。如果服务被误禁用用sc config ollama startauto恢复后重启即可。排错时用ollama serve在前台启动一次能看到日志输出和错误信息比服务模式下的黑盒状态直观得多。最后说一个我养成的习惯每次部署完新模型先跑一遍第 4 节的计时脚本确认加载耗时和生成速度在预期区间再把它交给别人用。本地部署最大的好处是可以反复折腾不受平台限制但前提是你对这套环境的手感足够熟。希望这篇指南能帮你少走几趟弯路把自己机器上的 DeepSeek-R1 真正跑起来。本文还有配套的精品资源点击获取

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑