简介这份指南面向在 Windows 11 上通过 Ollama 本地部署 DeepSeek-R1 的开发者与 AI 爱好者适合希望摆脱云端依赖、敏感数据不外传的个人开发者和企业用户解决大模型使用中的隐私与网络延迟问题。内容涵盖硬件与系统配置要求、Ollama 安装与启动、模型拉取与验证、命令行交互并详细介绍基于 REST API 的 Python 调用和 Modelfile 自定义参数同时针对模型拉取失败、运行缓慢、端口占用、服务无法连接等常见故障给出具体排查方法与解决建议。资源仅含 1 个 PDF 文件体积 264KB便于随时查阅已有 4328 人学习下载。借助这份指南读者可快速完成私有化部署在断网环境下也能享受 DeepSeek-R1 的智能对话与文本生成能力且无需深厚的 AI 基础按步骤操作即可上手是入门本地大模型运行的极其实用手册。1. 为什么要在Win11上本地部署DeepSeek-R1在Windows 11上直接拉取并运行大语言模型Ollama是我见过最顺手的方案。它把模型仓库、权重管理、服务进程和命令行交互打包成一个可执行体装完后默认监听11434端口不需要手工组装Python环境、CUDA库和推理框架。DeepSeek-R1的推理表现足够应对代码生成、日志分析和内部知识库问答数据全程留在本机不用把文本提交到外部服务。这套部署方式特别适合两种人一是想快速验证本地大模型实际效果的产品原型开发者二是对数据出境比较敏感、需要在内网离线环境运行模型的运维工程师。下面从安装检查开始逐步给出可复现的命令。2. Ollama安装检查与模型文件管理2.1 Ollama在Windows 11下的运行机制Ollama在Windows 11上并不是一个传统意义上的安装即走的前台软件。它的核心是一个后台服务默认绑定127.0.0.1:11434。Windows版以原生进程方式运行不依赖WSL2和早期社区里流传的“必须装WSL”的做法不同。安装包会注册自启动服务所以大多数情况下直接执行ollama run就能工作。但有一个常见陷阱如果服务没起来命令行会返回类似failed to connect的错误。这时需要手动执行ollama serve让进程在前台运行观察启动日志和模型加载信息。这也是排查问题的第一入口。日志中会明确打印监听地址以及每次请求时的模型加载耗时。模型文件的位置也值得提前知道。Ollama的模型默认存放在%USERPROFILE%\.ollama\models目录里是以哈希命名的blob文件和描述模型信息的manifest。这种结构带来的好处是修改模型参数时不需要重新下载全部权重只需要生成新的manifest指向已有blob就能得到一个自定义模型。2.2 安装前需要确认的软硬件条件DeepSeek-R1在Ollama仓库里有多个量化规格的标签体积随精度不同而有明显差异。部署前先按下面的表核对硬件能避免后续频繁出现的OOM和“生成到一半卡死”。检查项建议底线推荐配置具体影响CPU8核16线程英特尔酷睿i7或AMD Ryzen 7影响prompt进入模型前的预填充速度内存16GB32GB同时容纳权重和KV CacheGPU可选NVIDIA RTX 30系列及以上CUDA加速后解码速度提升明显存储20GB可用SSD剩余50GB以上模型blob写入和加载依赖磁盘随机读内存这块容易被低估。推理时不仅要加载权重还要为上下文窗口分配KV Cache上下文越长额外占用越大。Windows 11系统本身通常占用3~4GB内存16GB机器在跑中等规模量化模型时可能勉强够用但一旦把上下文拉到8k以上物理内存耗尽后系统会把数据换到页面文件回答速度会突然掉到数十秒。所以如果预算有限优先加内存效果通常比升级GPU更直观。2.3 安装与验证Ollama服务从官网下载安装包后按向导完成安装。装好后打开PowerShell先做两个基础检查ollama --version ollama serveollama --version确认CLI已经进入PATHollama serve手动拉起服务。如果终端持续输出日志而不是立刻退回到提示符说明服务在正常工作。启动日志里通常有一行listening on [::]:11434这就是本地服务地址。在另一个窗口验证端口状态Get-NetTCPConnection -LocalPort 11434 | Select-Object State, LocalAddress, LocalPort, OwningProcess返回结果里State为ListenOwningProcess是对应的pid。后续如果端口被其他程序占用可以用这个pid反查进程。安装到这里先不用急着拉模型建议顺手把OLLAMA_MODELS环境变量改到大容量磁盘。具体设置方法在下一章故障排查部分给出这里先了解目录机制就够了。3. 命令行部署DeepSeek-R1模型与常见坑3.1 拉取DeepSeek-R1的正确姿势确认服务正常后拉取模型ollama pull deepseek-r1这条命令不带tag默认拉取该模型在仓库中标记为latest的版本。Ollama会先解析镜像索引然后按blob分块下载终端里显示进度条和下载速度。拉下来的文件会按哈希写入第2章提到的models目录不会散落在当前工作目录。如果下载进度停在某个百分比不动网络闪断是最常见的原因。Ollama支持断点续传直接再次执行相同的ollama pull它会跳过已完成的blob继续剩余部分。不要因为进度条不动就反复删除重拉那样更容易让磁盘空间碎片化。需要注意的是Windows Defender可能在首次拉取时扫描模型目录导致剩余进度长时间不更新。这不是失败只是文件防病毒扫描在后台占用磁盘IO。可以在任务管理器里确认Ollama进程是否还在产生网络流量。3.2 确认模型列表与命令行交互拉取完成后先确认模型已经进入本地仓库ollama list输出里会显示NAME、ID、SIZE和MODIFIED。如果能看到deepseek-r1说明模型清单已经生效。要注意ollama list读取的是manifest而不是直接扫盘所以即使blob不完整只要manifest存在也可能显示记录。判断完整性的可靠方式是接着运行一下。ollama run deepseek-r1 用Python写一个快速排序运行命令会自动加载模型到内存。首次加载时间取决于磁盘速度和模型大小加载完成后提示符会进入问答模式输入问题得到回答输入/exit退出交互。在交互模式下模型保持常驻连续提问不需要重新加载这是与一次性调用ollama run deepseek-r1 -p 问题最大的区别。常驻模式对多轮对话更友好但内存占用也会持续存在。命令作用使用场景ollama list查看本地模型清单确认拉取结果ollama run deepseek-r1进入交互式问答多轮对话、调试验证ollama run deepseek-r1 -p 提问单次提问并退出脚本集成、快速测试/exit退出交互模式结束对话释放内存3.3 下载慢与离线导入的通用处理搜索“ollama下载慢”时最常见的建议是换镜像源或加参数重试。我的经验是先区分瓶颈在哪。如果拉取速度始终在几十KB/s大概率是连接模型仓库的网络不稳定。此时可以断点续传或者在一台网络条件更好的机器上先拉取完整模型然后把整个.ollama\models目录同步到目标机。具体做法是源机器执行ollama list记录模型名退出Ollama服务后复制%USERPROFILE%\.ollama\models整个目录。目标机也先退出服务把目录替换到相同路径。重新启动服务后执行ollama list模型就会出现在本机。这种方式不依赖模型仓库适合内网离线环境。复制过程中建议保持SSD到SSD避免机械硬盘长时间拷贝导致hash校验失败。另外如果你的模型文件已经以GGUF格式存在本地也可以通过Ollama的Modelfile导入后面第4章会讲到Modelfile的具体写法。这个技巧我常用在从Hugging Face下载权重的场景先把GGUF转成Ollama可识别的格式再创建一个本地模型tag。4. 通过REST API与自定义Modelfile扩展DeepSeek-R14.1 REST API请求格式与关键参数Ollama启动后等于自带了一个HTTP服务。最常见的接口是/api/generatePOST请求体包含model、prompt和可选参数。下面是一个最小请求样例{ model: deepseek-r1, prompt: 解释一下什么是大模型量化, stream: false }model对应ollama list里的名称prompt是输入文本stream设为false表示等待完整回答后一次性返回。如果设为true服务端会以NDJSON格式逐行推送结果适合做流式对话界面。Ollama也支持/api/chat接口专门处理多轮对话。请求体里传的不再是prompt而是messages数组结构与OpenAI Chat API类似。用聊天接口时历史消息需要自己维护Ollama不会自动做持久化服务重启后上下文就丢了。参数默认情况说明streamfalse是否流式返回temperature由模型Modelfile决定控制随机性top_p由模型Modelfile决定核采样裁剪范围num_ctx2048左右上下文窗口长度具体默认值可以通过ollama show deepseek-r1查看不同tag之间的参数预设会有差异。建议在接入业务前先跑一次ollama show把关键参数记录下来后面调优时有基准。4.2 Python调用示例可以把REST API封装成Python工具这样不需要依赖Ollama内置的交互命令行。保存下面代码为ask_deepseek.pyimport requests data { model: deepseek-r1, prompt: 把这段日志中的ERROR级别信息提取出来, stream: False } response requests.post(http://localhost:11434/api/generate, jsondata, timeout300) result response.json() print(result[response])这段代码通过requests把JSON发给Ollama服务timeout300是因为大模型的生成时间可能超过默认的10秒过短的超时会导致客户端提前断开连接。打印的response字段就是模型生成的纯文本。如果请求失败先检查response.status_codeOllama在模型不存在或参数错误时会返回4xx并在error字段给出原因。调用时的数据格式直接影响生成质量。temperature默认值一般够用回答偏向确定性任务时可以调低到0.3以下减少随机采样。4.3 用Modelfile自定义模型参数Modelfile是Ollama自定义模型的入口。新建一个文本文件ModelfileFROM deepseek-r1 PARAMETER temperature 0.7 PARAMETER top_p 0.8FROM指定基础模型这里引用的是之前拉取的deepseek-r1。PARAMETER行用来覆盖生成参数。temperature控制随机性值越大越发散top_p控制核采样范围值越小候选词越少。这两个参数配合使用当temperature较高时调低top_p能减少乱回答的概率。然后构建并运行ollama create my-deepseek-r1 -f Modelfile ollama run my-deepseek-r1 写一段生产环境可用的Nginx配置ollama create会生成一个新的模型名但并不会重新下载权重而是基于已有blob创建新的manifest。所以整个过程几乎瞬间完成。通过这种方式同一个基础模型可以派生出“高确定性版”“创意写作版”等多个配置按场景分别调用。5. 性能观测与故障排查清单5.1 用系统工具定位资源瓶颈模型回答变慢时第一步不是改参数而是确认瓶颈在CPU、内存还是磁盘。在任务管理器的“性能”标签页按内存占用排序找到ollama进程。如果GPU的CUDA利用率一直为0说明模型并没有加载到GPU上。常见原因是Ollama默认只做一次GPU离线检查驱动过老或显存不足时会自动回退到CPU推理。更精确的观测可以通过nvidia-smi命令完成nvidia-smi在输出中查看ollama进程是否出现在GPU进程列表里。如果没有可以检查Ollama日志看是否输出了no compatible GPU之类信息。驱动更新后重启服务再试。如果是显存容量不够Ollama会自动将部分层放到CPU侧这种情况不算失败但性能会比纯GPU差不少。5.2 端口占用与连接失败的快速判断ollama serve已经启动但ollama run仍提示连接失败优先怀疑端口被抢。执行netstat -ano | findstr :11434这条命令返回监听进程的PID。如果返回多个条目说明有进程同时绑定了端口。在任务管理器里找到对应PID确认是Ollama还是其他服务。如果确实被其他程序占用可以结束该进程或者给Ollama换端口。换端口的方式是设置OLLAMA_HOST环境变量。设置环境变量前需要先退出运行中的Ollama服务否则新配置不会生效setx OLLAMA_HOST 127.0.0.1:11435setx是Windows的持久化配置命令。执行后重新打开终端启动ollama serve服务会监听新端口。对应的API请求地址也要同步改成http://localhost:11435。5.3 模型目录迁移与上下文窗口调整默认模型目录在C盘长期拉模型容易爆盘。迁移目录的通用做法是设置OLLAMA_MODELSsetx OLLAMA_MODELS D:\ollama\models设置完成后重新启动Ollama服务之后拉取的模型会写入新目录。注意已有模型不会自动迁移需要手动移动.ollama\models下的内容到新路径或者直接重新拉取。迁移时关闭Ollama进程避免文件占用导致复制失败。如果回答内容重复或无逻辑问题往往出在上下文窗口和参数。可以通过Modelfile调整num_ctxFROM deepseek-r1 PARAMETER num_ctx 8192 PARAMETER temperature 0.5num_ctx控制上下文窗口大小默认值可能只有2048。当输入内容较长时超出部分会被截断模型只看到局部内容回答自然不准确。把它提高到8192会显著增加KV Cache的内存占用所以要根据内存容量谨慎设置。现象可能原因排查顺序连接失败服务未启动或端口被占ollama serve观察日志生成速度慢CPU推理或内存吃紧看任务管理器GPU占用下载进度停滞网络闪断或杀毒扫描重新ollama pull断点续传回答截断num_ctx太小调大num_ctx并重启服务6. 进阶把DeepSeek-R1接入本地应用6.1 包装成OpenAI兼容接口很多现有AI应用只认OpenAI的/v1/chat/completions格式。Ollama不直接提供这个路径但可以在Ollama前加一层轻量代理。常见做法是用一个Python FastAPI服务将请求转发到Ollama的/api/chat。我一般会在本地启动一个5001端口的服务业务代码只改一个base_url就能切换模型。from fastapi import FastAPI, Request import requests app FastAPI() app.post(/v1/chat/completions) async def chat_completions(request: Request): body await request.json() ollama_payload { model: body.get(model, deepseek-r1), messages: body.get(messages, []), stream: body.get(stream, False) } response requests.post( http://localhost:11434/api/chat, jsonollama_payload, timeout300 ) return {choices: [{message: {role: assistant, content: response.json()[message][content]}}]}这个代理的核心是把OpenAI请求中的messages原样传给Ollama然后把Ollama返回的message.content重新包装成OpenAI响应结构。body.get做了参数兼容处理即使客户端没有传model也会使用默认的deepseek-r1。这样服务的路由逻辑可以先行验证之后再决定是否将模型固定为本地的这个tag。6.2 流式输出时的处理细节如果你在前端页面里使用流式输出Ollama的/api/chat在streamtrue时会返回多行JSON。代理层不能简单返回response.json()需要逐行读取原始响应并按SSE格式转发from fastapi.responses import StreamingResponse def generate(): ollama_resp requests.post( http://localhost:11434/api/chat, json{model: deepseek-r1, messages: messages, stream: True}, streamTrue, timeout300 ) for line in ollama_resp.iter_lines(decode_unicodeTrue): if line: yield fdata: {line}\n\n return StreamingResponse(generate(), media_typetext/event-stream)这里iter_lines按行读取data:前缀是SSE协议的固定格式。前端用EventSource或fetch的流式解析都能识别。要注意的是Ollama在流式模式下每行都是一个完整的JSON对象最后一行是done:true前端可以根据这个字段结束解析。接入时把模型名、端口和超时时间抽成配置项。这样整个Win11本地部署链路就变成一个可维护的本地服务后续替换模型或调整参数不需要改业务代码。本文还有配套的精品资源点击获取 Win11本地部署DeepSeek-R1：Ollama安装、配置与API调用指南
简介这份指南面向在 Windows 11 上通过 Ollama 本地部署 DeepSeek-R1 的开发者与 AI 爱好者适合希望摆脱云端依赖、敏感数据不外传的个人开发者和企业用户解决大模型使用中的隐私与网络延迟问题。内容涵盖硬件与系统配置要求、Ollama 安装与启动、模型拉取与验证、命令行交互并详细介绍基于 REST API 的 Python 调用和 Modelfile 自定义参数同时针对模型拉取失败、运行缓慢、端口占用、服务无法连接等常见故障给出具体排查方法与解决建议。资源仅含 1 个 PDF 文件体积 264KB便于随时查阅已有 4328 人学习下载。借助这份指南读者可快速完成私有化部署在断网环境下也能享受 DeepSeek-R1 的智能对话与文本生成能力且无需深厚的 AI 基础按步骤操作即可上手是入门本地大模型运行的极其实用手册。1. 为什么要在Win11上本地部署DeepSeek-R1在Windows 11上直接拉取并运行大语言模型Ollama是我见过最顺手的方案。它把模型仓库、权重管理、服务进程和命令行交互打包成一个可执行体装完后默认监听11434端口不需要手工组装Python环境、CUDA库和推理框架。DeepSeek-R1的推理表现足够应对代码生成、日志分析和内部知识库问答数据全程留在本机不用把文本提交到外部服务。这套部署方式特别适合两种人一是想快速验证本地大模型实际效果的产品原型开发者二是对数据出境比较敏感、需要在内网离线环境运行模型的运维工程师。下面从安装检查开始逐步给出可复现的命令。2. Ollama安装检查与模型文件管理2.1 Ollama在Windows 11下的运行机制Ollama在Windows 11上并不是一个传统意义上的安装即走的前台软件。它的核心是一个后台服务默认绑定127.0.0.1:11434。Windows版以原生进程方式运行不依赖WSL2和早期社区里流传的“必须装WSL”的做法不同。安装包会注册自启动服务所以大多数情况下直接执行ollama run就能工作。但有一个常见陷阱如果服务没起来命令行会返回类似failed to connect的错误。这时需要手动执行ollama serve让进程在前台运行观察启动日志和模型加载信息。这也是排查问题的第一入口。日志中会明确打印监听地址以及每次请求时的模型加载耗时。模型文件的位置也值得提前知道。Ollama的模型默认存放在%USERPROFILE%\.ollama\models目录里是以哈希命名的blob文件和描述模型信息的manifest。这种结构带来的好处是修改模型参数时不需要重新下载全部权重只需要生成新的manifest指向已有blob就能得到一个自定义模型。2.2 安装前需要确认的软硬件条件DeepSeek-R1在Ollama仓库里有多个量化规格的标签体积随精度不同而有明显差异。部署前先按下面的表核对硬件能避免后续频繁出现的OOM和“生成到一半卡死”。检查项建议底线推荐配置具体影响CPU8核16线程英特尔酷睿i7或AMD Ryzen 7影响prompt进入模型前的预填充速度内存16GB32GB同时容纳权重和KV CacheGPU可选NVIDIA RTX 30系列及以上CUDA加速后解码速度提升明显存储20GB可用SSD剩余50GB以上模型blob写入和加载依赖磁盘随机读内存这块容易被低估。推理时不仅要加载权重还要为上下文窗口分配KV Cache上下文越长额外占用越大。Windows 11系统本身通常占用3~4GB内存16GB机器在跑中等规模量化模型时可能勉强够用但一旦把上下文拉到8k以上物理内存耗尽后系统会把数据换到页面文件回答速度会突然掉到数十秒。所以如果预算有限优先加内存效果通常比升级GPU更直观。2.3 安装与验证Ollama服务从官网下载安装包后按向导完成安装。装好后打开PowerShell先做两个基础检查ollama --version ollama serveollama --version确认CLI已经进入PATHollama serve手动拉起服务。如果终端持续输出日志而不是立刻退回到提示符说明服务在正常工作。启动日志里通常有一行listening on [::]:11434这就是本地服务地址。在另一个窗口验证端口状态Get-NetTCPConnection -LocalPort 11434 | Select-Object State, LocalAddress, LocalPort, OwningProcess返回结果里State为ListenOwningProcess是对应的pid。后续如果端口被其他程序占用可以用这个pid反查进程。安装到这里先不用急着拉模型建议顺手把OLLAMA_MODELS环境变量改到大容量磁盘。具体设置方法在下一章故障排查部分给出这里先了解目录机制就够了。3. 命令行部署DeepSeek-R1模型与常见坑3.1 拉取DeepSeek-R1的正确姿势确认服务正常后拉取模型ollama pull deepseek-r1这条命令不带tag默认拉取该模型在仓库中标记为latest的版本。Ollama会先解析镜像索引然后按blob分块下载终端里显示进度条和下载速度。拉下来的文件会按哈希写入第2章提到的models目录不会散落在当前工作目录。如果下载进度停在某个百分比不动网络闪断是最常见的原因。Ollama支持断点续传直接再次执行相同的ollama pull它会跳过已完成的blob继续剩余部分。不要因为进度条不动就反复删除重拉那样更容易让磁盘空间碎片化。需要注意的是Windows Defender可能在首次拉取时扫描模型目录导致剩余进度长时间不更新。这不是失败只是文件防病毒扫描在后台占用磁盘IO。可以在任务管理器里确认Ollama进程是否还在产生网络流量。3.2 确认模型列表与命令行交互拉取完成后先确认模型已经进入本地仓库ollama list输出里会显示NAME、ID、SIZE和MODIFIED。如果能看到deepseek-r1说明模型清单已经生效。要注意ollama list读取的是manifest而不是直接扫盘所以即使blob不完整只要manifest存在也可能显示记录。判断完整性的可靠方式是接着运行一下。ollama run deepseek-r1 用Python写一个快速排序运行命令会自动加载模型到内存。首次加载时间取决于磁盘速度和模型大小加载完成后提示符会进入问答模式输入问题得到回答输入/exit退出交互。在交互模式下模型保持常驻连续提问不需要重新加载这是与一次性调用ollama run deepseek-r1 -p 问题最大的区别。常驻模式对多轮对话更友好但内存占用也会持续存在。命令作用使用场景ollama list查看本地模型清单确认拉取结果ollama run deepseek-r1进入交互式问答多轮对话、调试验证ollama run deepseek-r1 -p 提问单次提问并退出脚本集成、快速测试/exit退出交互模式结束对话释放内存3.3 下载慢与离线导入的通用处理搜索“ollama下载慢”时最常见的建议是换镜像源或加参数重试。我的经验是先区分瓶颈在哪。如果拉取速度始终在几十KB/s大概率是连接模型仓库的网络不稳定。此时可以断点续传或者在一台网络条件更好的机器上先拉取完整模型然后把整个.ollama\models目录同步到目标机。具体做法是源机器执行ollama list记录模型名退出Ollama服务后复制%USERPROFILE%\.ollama\models整个目录。目标机也先退出服务把目录替换到相同路径。重新启动服务后执行ollama list模型就会出现在本机。这种方式不依赖模型仓库适合内网离线环境。复制过程中建议保持SSD到SSD避免机械硬盘长时间拷贝导致hash校验失败。另外如果你的模型文件已经以GGUF格式存在本地也可以通过Ollama的Modelfile导入后面第4章会讲到Modelfile的具体写法。这个技巧我常用在从Hugging Face下载权重的场景先把GGUF转成Ollama可识别的格式再创建一个本地模型tag。4. 通过REST API与自定义Modelfile扩展DeepSeek-R14.1 REST API请求格式与关键参数Ollama启动后等于自带了一个HTTP服务。最常见的接口是/api/generatePOST请求体包含model、prompt和可选参数。下面是一个最小请求样例{ model: deepseek-r1, prompt: 解释一下什么是大模型量化, stream: false }model对应ollama list里的名称prompt是输入文本stream设为false表示等待完整回答后一次性返回。如果设为true服务端会以NDJSON格式逐行推送结果适合做流式对话界面。Ollama也支持/api/chat接口专门处理多轮对话。请求体里传的不再是prompt而是messages数组结构与OpenAI Chat API类似。用聊天接口时历史消息需要自己维护Ollama不会自动做持久化服务重启后上下文就丢了。参数默认情况说明streamfalse是否流式返回temperature由模型Modelfile决定控制随机性top_p由模型Modelfile决定核采样裁剪范围num_ctx2048左右上下文窗口长度具体默认值可以通过ollama show deepseek-r1查看不同tag之间的参数预设会有差异。建议在接入业务前先跑一次ollama show把关键参数记录下来后面调优时有基准。4.2 Python调用示例可以把REST API封装成Python工具这样不需要依赖Ollama内置的交互命令行。保存下面代码为ask_deepseek.pyimport requests data { model: deepseek-r1, prompt: 把这段日志中的ERROR级别信息提取出来, stream: False } response requests.post(http://localhost:11434/api/generate, jsondata, timeout300) result response.json() print(result[response])这段代码通过requests把JSON发给Ollama服务timeout300是因为大模型的生成时间可能超过默认的10秒过短的超时会导致客户端提前断开连接。打印的response字段就是模型生成的纯文本。如果请求失败先检查response.status_codeOllama在模型不存在或参数错误时会返回4xx并在error字段给出原因。调用时的数据格式直接影响生成质量。temperature默认值一般够用回答偏向确定性任务时可以调低到0.3以下减少随机采样。4.3 用Modelfile自定义模型参数Modelfile是Ollama自定义模型的入口。新建一个文本文件ModelfileFROM deepseek-r1 PARAMETER temperature 0.7 PARAMETER top_p 0.8FROM指定基础模型这里引用的是之前拉取的deepseek-r1。PARAMETER行用来覆盖生成参数。temperature控制随机性值越大越发散top_p控制核采样范围值越小候选词越少。这两个参数配合使用当temperature较高时调低top_p能减少乱回答的概率。然后构建并运行ollama create my-deepseek-r1 -f Modelfile ollama run my-deepseek-r1 写一段生产环境可用的Nginx配置ollama create会生成一个新的模型名但并不会重新下载权重而是基于已有blob创建新的manifest。所以整个过程几乎瞬间完成。通过这种方式同一个基础模型可以派生出“高确定性版”“创意写作版”等多个配置按场景分别调用。5. 性能观测与故障排查清单5.1 用系统工具定位资源瓶颈模型回答变慢时第一步不是改参数而是确认瓶颈在CPU、内存还是磁盘。在任务管理器的“性能”标签页按内存占用排序找到ollama进程。如果GPU的CUDA利用率一直为0说明模型并没有加载到GPU上。常见原因是Ollama默认只做一次GPU离线检查驱动过老或显存不足时会自动回退到CPU推理。更精确的观测可以通过nvidia-smi命令完成nvidia-smi在输出中查看ollama进程是否出现在GPU进程列表里。如果没有可以检查Ollama日志看是否输出了no compatible GPU之类信息。驱动更新后重启服务再试。如果是显存容量不够Ollama会自动将部分层放到CPU侧这种情况不算失败但性能会比纯GPU差不少。5.2 端口占用与连接失败的快速判断ollama serve已经启动但ollama run仍提示连接失败优先怀疑端口被抢。执行netstat -ano | findstr :11434这条命令返回监听进程的PID。如果返回多个条目说明有进程同时绑定了端口。在任务管理器里找到对应PID确认是Ollama还是其他服务。如果确实被其他程序占用可以结束该进程或者给Ollama换端口。换端口的方式是设置OLLAMA_HOST环境变量。设置环境变量前需要先退出运行中的Ollama服务否则新配置不会生效setx OLLAMA_HOST 127.0.0.1:11435setx是Windows的持久化配置命令。执行后重新打开终端启动ollama serve服务会监听新端口。对应的API请求地址也要同步改成http://localhost:11435。5.3 模型目录迁移与上下文窗口调整默认模型目录在C盘长期拉模型容易爆盘。迁移目录的通用做法是设置OLLAMA_MODELSsetx OLLAMA_MODELS D:\ollama\models设置完成后重新启动Ollama服务之后拉取的模型会写入新目录。注意已有模型不会自动迁移需要手动移动.ollama\models下的内容到新路径或者直接重新拉取。迁移时关闭Ollama进程避免文件占用导致复制失败。如果回答内容重复或无逻辑问题往往出在上下文窗口和参数。可以通过Modelfile调整num_ctxFROM deepseek-r1 PARAMETER num_ctx 8192 PARAMETER temperature 0.5num_ctx控制上下文窗口大小默认值可能只有2048。当输入内容较长时超出部分会被截断模型只看到局部内容回答自然不准确。把它提高到8192会显著增加KV Cache的内存占用所以要根据内存容量谨慎设置。现象可能原因排查顺序连接失败服务未启动或端口被占ollama serve观察日志生成速度慢CPU推理或内存吃紧看任务管理器GPU占用下载进度停滞网络闪断或杀毒扫描重新ollama pull断点续传回答截断num_ctx太小调大num_ctx并重启服务6. 进阶把DeepSeek-R1接入本地应用6.1 包装成OpenAI兼容接口很多现有AI应用只认OpenAI的/v1/chat/completions格式。Ollama不直接提供这个路径但可以在Ollama前加一层轻量代理。常见做法是用一个Python FastAPI服务将请求转发到Ollama的/api/chat。我一般会在本地启动一个5001端口的服务业务代码只改一个base_url就能切换模型。from fastapi import FastAPI, Request import requests app FastAPI() app.post(/v1/chat/completions) async def chat_completions(request: Request): body await request.json() ollama_payload { model: body.get(model, deepseek-r1), messages: body.get(messages, []), stream: body.get(stream, False) } response requests.post( http://localhost:11434/api/chat, jsonollama_payload, timeout300 ) return {choices: [{message: {role: assistant, content: response.json()[message][content]}}]}这个代理的核心是把OpenAI请求中的messages原样传给Ollama然后把Ollama返回的message.content重新包装成OpenAI响应结构。body.get做了参数兼容处理即使客户端没有传model也会使用默认的deepseek-r1。这样服务的路由逻辑可以先行验证之后再决定是否将模型固定为本地的这个tag。6.2 流式输出时的处理细节如果你在前端页面里使用流式输出Ollama的/api/chat在streamtrue时会返回多行JSON。代理层不能简单返回response.json()需要逐行读取原始响应并按SSE格式转发from fastapi.responses import StreamingResponse def generate(): ollama_resp requests.post( http://localhost:11434/api/chat, json{model: deepseek-r1, messages: messages, stream: True}, streamTrue, timeout300 ) for line in ollama_resp.iter_lines(decode_unicodeTrue): if line: yield fdata: {line}\n\n return StreamingResponse(generate(), media_typetext/event-stream)这里iter_lines按行读取data:前缀是SSE协议的固定格式。前端用EventSource或fetch的流式解析都能识别。要注意的是Ollama在流式模式下每行都是一个完整的JSON对象最后一行是done:true前端可以根据这个字段结束解析。接入时把模型名、端口和超时时间抽成配置项。这样整个Win11本地部署链路就变成一个可维护的本地服务后续替换模型或调整参数不需要改业务代码。本文还有配套的精品资源点击获取