简介：这份PDF文档面向AI技术爱好者、企业IT管理员与开发者，聚焦在本地环境部署DeepSeek大语言模型的完整流程与安全可控价值，帮助需要处理敏感信息、构建私有化AI服务的读者规避数据上云风险，并掌握模型定制与垂直场景优化的方法。内容从DeepSeek的功能特点与技术背景切入，依次说明硬件显存、内存与CPU的选型建议，Ollama运行框架和CUDA Toolkit的安装配置，部署步骤及常见问题，并延伸至医疗辅助诊断、金融风控、教育资源推荐等应用场景与进阶工具组合。包内共1个PDF文件，约586KB，篇幅紧凑、结构清晰，便于按章节检索。已有701人学习。读者可据此理解不同规模模型的硬件门槛，获得从环境准备到部署落地的操作参考、排错思路与优化配置方式，并为后续结合业务微调、提升私有AI服务效率提供可复用的实践框架。

1. 为什么把模型拉回本地：一次显存账算清 1.5B 与 14B 的真实取舍

去年有个团队找我，说想把合同摘要和工单归类这两件事交给模型处理，但数据出不了机房，走在线接口的方案在内审那关就被打回来了。这类诉求最后基本都指向同一个动作：把 DeepSeek 大语言模型在本地跑起来，让自然语言处理和文本生成留在自己的机器上，用不用 GPU 加速、上多大参数的版本，全由自己权衡。这份资源就是围绕本地部署 DeepSeek 展开的完整流程，从硬件核对、Ollama 安装、模型标签怎么读，到 OpenWebUI 界面、接口调用，最后落到参数调优和故障排查。它不负责训练模型，目标是让一台普通工作站或者一台带独显的笔记本，稳定跑起一个能对内交付的私有推理服务。适合需要处理敏感文本的开发者、要把模型嵌进内部系统的运维，以及想先摸清显存账再决定要不要买卡的人。

2. Ollama 装好只是起点：从零到跑通第一个 token 的完整链路

真正拖慢新人的从来不是点安装包，而是装完之后的那半小时：不知道服务有没有起来，不知道模型下到哪一步，不知道命令敲进去没反应是卡死了还是在加载权重。这一章把这段路拆成可验证的小步，每一步都有明确的成功判据，任何一步不对，立刻就能定位问题出在驱动、服务还是模型文件上。

2.1 装之前先查三件事：显卡、显存、磁盘余量

很多人拿到包就双击，装到一半发现模型目录塞不下，或者模型跑起来风扇狂转速度还不如打字。前置检查花两分钟，后面能省两小时。

# Linux / Windows PowerShell 下都能用，看显卡型号、驱动版本、当前显存占用 nvidia-smi # macOS 看芯片型号和统一内存大小（Apple Silicon 走 Metal，不看独立显存） system_profiler SPDisplaysDataType | head -20 # 看模型默认目录所在分区还剩多少空间（Linux / macOS） df -h ~/.ollama

nvidia-smi输出右上角那个CUDA Version是驱动支持的最高运行时版本，不是已安装的版本，别拿它去和 CUDA Toolkit 的版本号直接对比。中间的Memory-Usage才是关键，它告诉你此刻还剩多少显存可用；如果已经有别的程序占着 3～4GB，那你能用的就不是标称值。Windows 上如果提示找不到命令，去C:\Windows\System32下确认nvidia-smi.exe是否存在，不存在说明驱动没装好，先解决驱动再谈后面。

磁盘这一项最容易被忽略。Ollama 在 Windows 上默认装在系统盘，模型文件也默认落在用户目录下的.ollama\models，一个 14B 的量化模型就是 9GB 上下，多下几个版本轻松吃掉四五十 G。系统盘紧张的话，装完第一件事就是把模型目录迁走，具体做法在第 4 章的环境变量那节。

2.2 三平台安装与最小验证

安装本身没什么技术含量，值钱的是验证顺序：先验版本，再验端口，最后才拉模型。跳过后两步直接拉模型，一旦服务没起来，你看到的报错会是网络错误，很容易误判成下载源的问题。

# Linux：官方脚本会自动装服务并注册开机自启 curl -fsSL https://ollama.com/install.sh | sh # 验证一：客户端版本 ollama -v # 验证二：服务端口有没有在监听（默认 11434） curl -s http://127.0.0.1:11434 # 验证三：看看当前有没有模型被加载进显存 ollama ps

ollama -v只说明客户端二进制装好了，不代表后台服务在跑。真正判断服务活着的是第二条curl，返回一句Ollama is running才算通过。第三条ollama ps在刚装完时应该是空表，如果它直接报连接被拒绝，问题就在服务进程，而不在模型。

Windows 和 macOS 走图形安装包，双击一路下一步即可，装完服务会常驻。Windows 用户注意两点：一是安装目录不可选，默认在用户目录下的AppData\Local\Programs\Ollama，空间不够只能事后迁模型目录；二是验证时别用老的 cmd 窗口，用 Windows Terminal 或 PowerShell，否则中文输出会变成一堆问号和方块，这个坑在第 5 章单独讲。macOS 把图标拖进 Applications 就行，装完在终端里跑一遍上面三条验证命令。

Linux 上如果curl那条装完但systemctl status ollama显示失败，八成是 systemd 单元没有权限访问显卡设备，先确认当前用户属于video组，再重启服务。这一步在企业内网的服务器上出问题概率最高，因为很多镜像默认裁掉了相关用户组。

2.3 拉模型：pull 和 run 是两件事

ollama run在模型不存在时会自动触发下载，看起来很方便，实际上把两件事混在了一起：下载失败和加载失败在终端里长得几乎一样。我一般习惯先pull再run，把下载和推理彻底分开。

# 只下载，不进对话。中断后重跑同一条命令会续传，不用删残留 ollama pull deepseek-r1:7b # 看本地已经有哪些模型、各自多大、什么时候拉的 ollama list # 看某个模型的量化类型、参数量、模板和默认参数 ollama show deepseek-r1:7b # 模型就位后再进交互 ollama run deepseek-r1:7b

标签里冒号后面那一段决定了你拿到的是什么。deepseek-r1:1.5b、:7b、:14b、:32b是蒸馏后的不同规模版本，同一个规模下还有基于不同底座蒸馏出来的分支，硬件适配性差别不大，选主流的那个就行。ollama show输出的parameters段落会告诉你默认上下文长度和量化方式，默认量化通常是 4bit 一档，这也是为什么 7B 模型的体积只有 4.7GB 左右而不是 28GB。

下载卡住是高频场景。判断方法很简单：看终端里进度条的字节数还在不在动，如果十分钟纹丝不动，先Ctrl+C再重跑同一条pull，它会从断点继续，不需要清空目录。真正需要清空的是模型文件损坏的情况，特征是ollama list里能看到条目，但run的时候报加载失败，这时候删掉对应目录重新拉。

2.4 第一次对话就该做完的三项验证

模型跑起来不等于能交付。第一次对话我固定做三件事：确认中文正常、确认长文本不崩、确认参数能改。少做一样，后面接进业务系统时都得返工。

# 进入交互后，这几条是斜杠命令，不是 shell 命令 >>> /set parameter temperature 0.6 >>> /set parameter num_ctx 8192 >>> /show parameters >>> /bye

/set parameter只对当前这个会话生效，退出即失效，适合临时试参数；要长期固化得写进 Modelfile，那是第 3 章的内容。num_ctx是上下文窗口，调大直接吃显存，8k 是大多数 8GB 显卡的舒适区。/bye退出而不是Ctrl+C，因为前者会正常释放会话，后者在部分版本里会留下一个占着显存的进程，表现就是下一次启动提示显存不足。

中文验证不要只问一句“你好”，那玩意儿怎么都能答对。拿一段两三百字的真实业务文本让它做摘要，看输出的标点、术语和断句是否正常，乱码问题在这一步就会暴露。长文本验证则直接贴一段接近num_ctx上限的内容，观察响应时间和是否报上下文超限——这两项过了，这个模型才算真的能用。

3. 模型选型与显存换算：1.5B/7B/14B/32B 怎么按硬件对号入座

选型的核心不是“哪个更强”，而是“在我这张卡上，它能不能稳定吐字”。同一台机器上，7B 跑 4k 上下文很流畅，换成 32k 上下文就可能直接 OOM，中间的差距全在 KV cache 上。这一章把显存账算清楚，再给出把配置固化下来的办法。

3.1 参数量不是唯一变量：权重、KV cache 与上下文长度

显存占用大致可以拆成两块：模型权重和 KV cache。权重部分好估，参数量乘以每参数字节数，4bit 量化下每十亿参数大约 0.55～0.6GB，再加一成左右的运行时开销。KV cache 才是变量，它和上下文长度成正比，和层数、注意力头维度成正比，实际经验值是：7B 级别每 1k 上下文约 0.1GB，14B 约 0.2GB，32B 约 0.4GB。

# 粗略估算：给定参数量、量化位宽、上下文长度，估一下显存底线 def vram_estimate(params_b, bits=4, ctx=8192, kv_per_1k=0.1, kv_scale=None): weights = params_b * bits / 8 * 1.1 # 权重 + 运行时开销 scale = kv_scale if kv_scale else params_b / 7.0 # 以 7B 为基准缩放 KV 开销 kv = ctx / 1000 * kv_per_1k * scale # KV cache return round(weights + kv, 1) print(vram_estimate(7, ctx=8192)) # 约 5.5GB print(vram_estimate(14, ctx=8192)) # 约 10.6GB print(vram_estimate(14, ctx=32768)) # 约 16.2GB，同一模型拉到 32k 就上了另一个台阶

这个函数只用来做决策，不用来精确规划。它的价值在于让你意识到：把num_ctx从 8k 提到 32k，显存账单会翻倍，而不是你以为的“就多一点点”。真到了显存边缘，降num_ctx通常比换小模型更划算，因为模型能力掉档是质变，上下文变短只是不能一次塞那么长的文档，可以靠分段处理绕过去。

表里“最低可用”是指能跑但会吃满显存、稍微开个浏览器就崩的临界值，实际部署按“舒适显存”那一列对号入座，留出的余量是给系统和其他进程的。如果显存放不下但又想用大模型，Ollama 会自动把一部分层放到 CPU，表现为能跑但速度掉一个数量级，ollama ps里那一列100% GPU变成70%/30% CPU/GPU就是这个信号。

3.2 用 Modelfile 固化一套配置

命令行调参是一次性的，业务系统要的是一致性。Modelfile 的作用就是把模型、参数、系统提示词打包成一个新标签，之后所有人run的都是同一份配置。

# 基于官方 7B 模型派生一个专用标签 FROM deepseek-r1:7b # 上下文窗口：按显存余量给，8k 是 8GB 卡的稳妥值 PARAMETER num_ctx 8192 # 单次最多生成多少 token，防止模型自说自话停不下来 PARAMETER num_predict 1024 # 温度：做抽取和分类用 0.2～0.3，做创意写作用 0.7 以上 PARAMETER temperature 0.3 # 核采样，配合温度一起控随机性 PARAMETER top_p 0.9 # 重复惩罚，中文长文本里这个值过高会让句子变得生硬 PARAMETER repeat_penalty 1.1 # 系统提示词写死业务边界 SYSTEM """你是内网文档助手。只根据用户提供的文本作答，文本中没有的信息直接说不知道，不要补充推测。"""

# 用上面的文件创建一个本地标签，名字自己定 ollama create contract-helper -f ./Modelfile # 确认新标签存在，并检查参数是否生效 ollama show contract-helper

FROM后面可以跟官方标签，也可以跟一个本地已有的标签，把它当继承来用。PARAMETER的优先级高于模型自带的默认值，但低于运行时通过 API 传的options，所以固化的是基线，临时改还是能改。SYSTEM是这套配置里最值钱的一行，很多“模型胡说八道”的问题不是模型不行，是没告诉它不许编。

ollama create执行完不会重新下载权重，只是把这个配置和原有的层组合起来，所以秒级完成。改一次参数就重建一次标签，比在代码里维护一堆参数字典清爽得多。团队里多人共用一台机器时，把 Modelfile 提交到代码库，谁要复现就create一下，环境就对齐了。

3.3 三档硬件配置的实际取舍

第一档是只有集显或者 4GB 独显的笔记本。这个档位别硬上 7B，1.5B 在短文本分类、字段抽取这类任务上够用，响应在一两秒内，反而体验更顺。要把期望调低：它做不了多步推理，问它“分析一下这份合同的三个风险点”会给你一堆正确的废话。

第二档是 8GB 显存的消费级独显，这是性价比最高的一档。7B 模型跑 8k 上下文，输出速度通常每秒十几到几十个 token，日常的文档摘要、工单归类、代码补全都能覆盖。这一档我的建议是把num_ctx卡死在 8192，不要贪心往 16k 拉，代价是响应速度腰斩、还得关掉其他吃显存的程序。

第三档是 24GB 及以上的工作站卡。上 14B 是甜点，32B 在 4k 上下文下也能跑。这一档真正的瓶颈会从显存转移到加载时间上：32B 模型从磁盘读进显存要几十秒，如果业务是低频调用，建议把OLLAMA_KEEP_ALIVE调大，让模型常驻，别让它每次冷启动。

4. 从命令行到可用界面：OpenWebUI 与接口的两种接法

命令行只适合自己用，一旦要给不写代码的同事用，就得有界面。同时，业务系统要接进来，走的是 HTTP 接口而不是终端。这一章把两条路都铺通：一条是给人看的 Web UI，一条是给程序调用的 API，两者共用同一个 11434 端口。

4.1 先把服务暴露到正确的地址

Ollama 默认只监听127.0.0.1，也就是只有本机能访问。本机自用没问题，一旦要在局域网里给同事用，或者跑在容器里，就必须改监听地址和模型目录。

# Linux systemd 方式：写一个 drop-in 覆盖文件，不要直接改主单元 sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf <<'EOF' [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models" Environment="OLLAMA_KEEP_ALIVE=30m" EOF sudo systemctl daemon-reload sudo systemctl restart ollama # 验证监听地址和模型目录都生效了 ss -lntp | grep 11434

OLLAMA_HOST改成0.0.0.0:11434之后，同网段的机器就能访问了。OLLAMA_MODELS是模型存放目录，前面提到的系统盘空间问题就靠它解决，改完要把原有模型目录里的内容整体搬过去，否则已经下好的模型会“消失”。OLLAMA_KEEP_ALIVE控制模型在显存里闲置多久后卸载，默认 5 分钟，改成 30 分钟能显著减少冷启动，代价是这段时间显存一直被占着。

Windows 上改环境变量用setx，改完必须重启 Ollama 服务或者重启系统才生效：

# Windows：把模型目录迁到 D 盘，同时允许局域网访问 setx OLLAMA_MODELS "D:\ollama\models" setx OLLAMA_HOST "0.0.0.0:11434"

注意：暴露到0.0.0.0意味着同网段任何人都能调用你的模型，Ollama 本身没有鉴权机制。只在可信内网这么干，公网环境务必在前面挡一层带认证的反向代理。

4.2 装 OpenWebUI 并对接本地模型

OpenWebUI 是自托管的 Web 界面，装完之后用起来和常见的在线对话产品差不多，但所有请求都落在你自己的 11434 上。

# 建独立虚拟环境，避免和系统 Python 的依赖打架 python -m venv ~/openwebui_env # Linux / macOS 激活；Windows 用 openwebui_env\Scripts\activate source ~/openwebui_env/bin/activate # 升级 pip 再装，老版本 pip 解析依赖容易失败 pip install --upgrade pip pip install open-webui # 启动，默认监听 8080 open-webui serve

环境要求里最关键的是 Python 版本，低于 3.11 会在安装阶段就报依赖不兼容。装的过程中会拉不少包，几分钟属于正常，不要以为卡死就中断。启动成功的标志是终端里出现监听 8080 的日志，浏览器访问http://localhost:8080能看到注册页，第一个注册的账号自动成为管理员。

进界面后第一次要做的配置是模型来源：在设置里找到连接配置，把 Ollama 的地址填成http://127.0.0.1:11434（如果 OpenWebUI 跑在容器里，这里要填宿主机的内网 IP 或者容器网络里的服务名，不能写 127.0.0.1）。保存后刷新，模型下拉框里应该能看到你在第 3 章create出来的那个标签。看不到就回终端跑一次ollama list，确认标签拼写和界面里显示的一致。

4.3 写一个最小调用脚本：原生接口与兼容接口

业务系统集成时，HTTP 接口比界面重要得多。Ollama 提供两套入口：原生的/api/chat，和模仿通用协议的/v1/chat/completions。前者参数更贴近 Ollama 自己的实现，后者能直接复用现成的客户端库。

import requests # 原生接口：options 里的参数优先级高于 Modelfile，适合按请求动态调 resp = requests.post( "http://127.0.0.1:11434/api/chat", json={ "model": "contract-helper", # 用第 3 章 create 出来的标签 "messages": [ {"role": "user", "content": "把这条工单归到网络/账号/硬件三类之一，只输出类别名：会议室投影连不上笔记本。"} ], "stream": False, # 批处理场景关掉流式，方便一次性取结果 "options": {"temperature": 0.2, "num_ctx": 4096, "num_predict": 32}, }, timeout=120, # 冷启动可能几十秒，超时别设太小 ) print(resp.json()["message"]["content"])

from openai import OpenAI # 兼容接口：把 base_url 指到本地，key 随便填一个非空字符串 client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="local") resp = client.chat.completions.create( model="deepseek-r1:7b", messages=[{"role": "user", "content": "用一句话解释什么是 KV cache。"}], temperature=0.3, ) print(resp.choices[0].message.content)

timeout这个参数比想象中重要。第一次请求某个模型时，Ollama 需要把权重从磁盘读进显存，32B 级别能花掉半分钟以上，如果客户端设了默认的 5 秒超时，你看到的是连接超时，但实际上模型还在加载，重试一次反而更快成功——这就是典型的“重试一下就好了”的玄学，本质是冷启动。

批处理场景还要注意并发。默认情况下 Ollama 对同一个模型是串行处理请求的，同时发十个请求，后面九个在排队，客户端看到的是响应时间成倍增长。要么在客户端做限流，要么显式调大OLLAMA_NUM_PARALLEL，但后者会成倍吃显存，因为每个并行请求都要一份独立的 KV cache。我的习惯是客户端限流到 2～4 并发，比调服务端参数可控得多。

5. 踩过的坑都在这：五个翻车现场的现象、原因与解法

下面这几条都是我在不同机器上真撞过的，共同点是：报错信息指向的地方，和真正的病因往往不是一回事。按现象、原因、解决三段来写，遇到类似症状直接对号入座。

5.1 安装与下载阶段的三个坑

坑一：终端输出全是方块和问号，模型像在说乱码。

现象很吓人，ollama run之后模型回了一堆(cid:0)(cid:11)之类的东西，让人怀疑模型文件坏了。原因不在模型，在 Windows 传统命令提示符的代码页是 936（GBK），而模型输出是 UTF-8，编码对不上就会这样。解决办法是换一个能正确处理 UTF-8 的终端：Windows Terminal 或者 PowerShell 7，实在要用 cmd 就先执行chcp 65001切到 UTF-8 代码页再启动。macOS 和 Linux 基本不会遇到，除非 locale 被设成了 C。

坑二：ollama pull进度条卡死，重跑又从头开始。

现象是下载到某个百分比之后完全不动，等半小时还是那个数字。原因是网络中断后连接没有正确关闭，进程还在但数据不再流入。解法是Ctrl+C中断后重跑同一条pull命令，正常情况下会从断点续传，不会重新下载已经拿到的层。如果重跑之后进度归零，说明临时文件已经被清理，那只能重来。预防办法是不要在网络切换频繁的环境下拉大模型，以及优先用有线网络。

坑三：装完提示“安装程序无法创建目录”。

Windows 上这个报错直指系统盘空间，因为安装路径不可选，默认落在用户目录下。原因是 C 盘剩余空间不足，或者用户目录的权限被组策略改过。解法是先清理出至少 5GB 空间再装；如果空间够还是报权限，用管理员身份运行安装包。装完之后不管成功与否，都建议立刻把模型目录用OLLAMA_MODELS迁到数据盘，避免下一次拉模型又把系统盘塞满。

5.2 运行与显存阶段的坑

坑四：报CUDA out of memory，但我明明算过显存够。

现象是模型加载到一半崩掉，日志里是显存分配失败。原因通常有两个：一是算的时候只算了权重没算 KV cache，num_ctx一开大就爆；二是别的进程占着显存没释放，最常见的是上一次没正常退出的 Ollama 进程，或者浏览器开着硬件加速。解法是先用nvidia-smi看当前占用，把残留进程清掉；再检查ollama ps里有没有僵尸模型；最后把num_ctx降一半重试，能跑起来就说明是上下文吃太多，而不是模型选错了。

坑五：能跑，但慢得离谱，一个短问答要等两分钟。

现象是响应时间远超预期，风扇也不怎么转。原因是模型没完全上 GPU，一部分层被放到了 CPU 上跑，ollama ps里那一列会显示类似60%/40% CPU/GPU的分布。解法分三步：先确认驱动和 CUDA 运行时正常，nvidia-smi里能看到进程占用；再降模型规模或者降num_ctx，让整模型塞进显存；如果显存实在不够又必须用大模型，那就接受这个速度，或者把OLLAMA_KEEP_ALIVE调大减少重复加载。

5.3 接入阶段的坑

坑六：容器里的 OpenWebUI 连不上宿主机的 Ollama。

现象是界面上模型列表永远为空，日志里是连接被拒绝。原因是容器有独立的网络命名空间，容器里的127.0.0.1指的是容器自己，不是宿主机。解法是把 Ollama 的地址改成宿主机的内网 IP，或者在容器启动时用--network host共享网络栈；同时确认宿主机的 Ollama 已经按 4.1 节改成监听0.0.0.0，否则即使地址填对了也连不上。防火墙和端口映射是这一环里第二常见的拦路虎，先curl一下宿主机 IP 的 11434 端口，能通再回头看界面配置。

6. 让输出稳定可复现：一套调参与验收的自检习惯

模型能跑起来只是及格线，能不能稳定复现才是能不能交付的分水岭。同一段提示词，今天给的结果和明天不一样，业务方第一次问“为什么变了”你就得解释半天；更麻烦的是同一批任务跑两次结果不同，后处理脚本直接错乱。这一章说三个我每次都强制走的动作。

第一个动作是把随机性压到业务能接受的范围。做分类、抽取、结构化输出这类任务，温度给 0.1～0.3，top_p给 0.9 左右，重复惩罚不要超过 1.15，否则中文长句会变得生硬。做创意写作用 0.7 以上，但要接受结果不可复现。判断标准很简单：如果你的下游代码需要用正则去解析输出，就必须压随机性；如果输出是给人看的，可以放宽。

第二个动作是写一条能一次跑完的验收脚本，把这套参数、这个模型标签、这段样例输入全部固化下来，每次改配置或换版本都跑一遍。脚本不需要复杂，覆盖三类样例就够：一段正常业务文本、一段超长文本、一段模型应该拒答的文本（比如问它文本里没写的信息）。三类都通过，才允许上线。这条脚本还兼任回归测试，换了模型版本之后跑一次，输出风格变化一眼就能看出来。

第三个动作是给每次请求记一条精简日志：模型标签、num_ctx、temperature、首 token 延迟、总耗时、输出长度。不需要记全文，记元数据就行。我吃过一次亏，某天开始响应时间从两秒涨到二十秒，翻日志才发现有人把OLLAMA_MAX_LOADED_MODELS调大之后同时加载了三个模型，显存被挤爆，Ollama 开始往 CPU 上放层，而这种降级在终端里没有任何提示，只有日志里的耗时曲线能看出来。

从那以后我每次给一个新环境部署模型，都强制走一遍「nvidia-smi看占用 →ollama ps看 GPU 占比 → 三类样例验收 → 记录基线耗时」这条链路，不管机器多闲、不管多赶时间。这套动作加起来五分钟，能挡掉后面八成“明明之前好好的”的返工。这份部署手册我按上面六章的顺序整理成了可照着敲的步骤版，配置模板、验收脚本和排错清单都在同一份资源里，按目录顺序取用即可，别跳过第 5 章直接上线，那几节是拿真实故障换来的。希望帮到你。

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