简介这份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 ~/.ollamanvidia-smi输出右上角那个CUDA Version是驱动支持的最高运行时版本不是已安装的版本别拿它去和 CUDA Toolkit 的版本号直接对比。中间的Memory-Usage才是关键它告诉你此刻还剩多少显存可用如果已经有别的程序占着 34GB那你能用的就不是标称值。Windows 上如果提示找不到命令去C:\Windows\System32下确认nvidia-smi.exe是否存在不存在说明驱动没装好先解决驱动再谈后面。磁盘这一项最容易被忽略。Ollama 在 Windows 上默认装在系统盘模型文件也默认落在用户目录下的.ollama\models一个 14B 的量化模型就是 9GB 上下多下几个版本轻松吃掉四五十 G。系统盘紧张的话装完第一件事就是把模型目录迁走具体做法在第 4 章的环境变量那节。可用显存建议起步模型体验预期4GB 左右1.5B短文本问答、分类够用长文会明显变慢68GB7B / 8B日常摘要、抽取、代码补全的主力档位1216GB14B复杂推理和长文档处理速度可接受24GB 及以上32B专业领域文本分析需要控制上下文长度2.2 三平台安装与最小验证安装本身没什么技术含量值钱的是验证顺序先验版本再验端口最后才拉模型。跳过后两步直接拉模型一旦服务没起来你看到的报错会是网络错误很容易误判成下载源的问题。# Linux官方脚本会自动装服务并注册开机自启 curl -fsSL https://ollama.com/install.sh | sh # 验证一客户端版本 ollama -v # 验证二服务端口有没有在监听默认 11434 curl -s http://127.0.0.1:11434 # 验证三看看当前有没有模型被加载进显存 ollama psollama -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。下载卡住是高频场景。判断方法很简单看终端里进度条的字节数还在不在动如果十分钟纹丝不动先CtrlC再重跑同一条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退出而不是CtrlC因为前者会正常释放会话后者在部分版本里会留下一个占着显存的进程表现就是下一次启动提示显存不足。中文验证不要只问一句“你好”那玩意儿怎么都能答对。拿一段两三百字的真实业务文本让它做摘要看输出的标点、术语和断句是否正常乱码问题在这一步就会暴露。长文本验证则直接贴一段接近num_ctx上限的内容观察响应时间和是否报上下文超限——这两项过了这个模型才算真的能用。3. 模型选型与显存换算1.5B/7B/14B/32B 怎么按硬件对号入座选型的核心不是“哪个更强”而是“在我这张卡上它能不能稳定吐字”。同一台机器上7B 跑 4k 上下文很流畅换成 32k 上下文就可能直接 OOM中间的差距全在 KV cache 上。这一章把显存账算清楚再给出把配置固化下来的办法。3.1 参数量不是唯一变量权重、KV cache 与上下文长度显存占用大致可以拆成两块模型权重和 KV cache。权重部分好估参数量乘以每参数字节数4bit 量化下每十亿参数大约 0.550.6GB再加一成左右的运行时开销。KV cache 才是变量它和上下文长度成正比和层数、注意力头维度成正比实际经验值是7B 级别每 1k 上下文约 0.1GB14B 约 0.2GB32B 约 0.4GB。# 粗略估算给定参数量、量化位宽、上下文长度估一下显存底线 def vram_estimate(params_b, bits4, ctx8192, kv_per_1k0.1, kv_scaleNone): 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, ctx8192)) # 约 5.5GB print(vram_estimate(14, ctx8192)) # 约 10.6GB print(vram_estimate(14, ctx32768)) # 约 16.2GB同一模型拉到 32k 就上了另一个台阶这个函数只用来做决策不用来精确规划。它的价值在于让你意识到把num_ctx从 8k 提到 32k显存账单会翻倍而不是你以为的“就多一点点”。真到了显存边缘降num_ctx通常比换小模型更划算因为模型能力掉档是质变上下文变短只是不能一次塞那么长的文档可以靠分段处理绕过去。模型标签参数量权重体积4bit8k 上下文总占用最低可用显存舒适显存deepseek-r1:1.5b1.5B约 1.1GB约 1.4GB4GB6GBdeepseek-r1:7b7B约 4.7GB约 5.5GB8GB12GBdeepseek-r1:14b14B约 9.5GB约 10.6GB12GB1624GBdeepseek-r1:32b32B约 20GB约 23GB24GB32GB 以上表里“最低可用”是指能跑但会吃满显存、稍微开个浏览器就崩的临界值实际部署按“舒适显存”那一列对号入座留出的余量是给系统和其他进程的。如果显存放不下但又想用大模型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.20.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-helperFROM后面可以跟官方标签也可以跟一个本地已有的标签把它当继承来用。PARAMETER的优先级高于模型自带的默认值但低于运行时通过 API 传的options所以固化的是基线临时改还是能改。SYSTEM是这套配置里最值钱的一行很多“模型胡说八道”的问题不是模型不行是没告诉它不许编。ollama create执行完不会重新下载权重只是把这个配置和原有的层组合起来所以秒级完成。改一次参数就重建一次标签比在代码里维护一堆参数字典清爽得多。团队里多人共用一台机器时把 Modelfile 提交到代码库谁要复现就create一下环境就对齐了。3.3 三档硬件配置的实际取舍第一档是只有集显或者 4GB 独显的笔记本。这个档位别硬上 7B1.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] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_KEEP_ALIVE30m EOF sudo systemctl daemon-reload sudo systemctl restart ollama # 验证监听地址和模型目录都生效了 ss -lntp | grep 11434OLLAMA_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}, }, timeout120, # 冷启动可能几十秒超时别设太小 ) print(resp.json()[message][content])from openai import OpenAI # 兼容接口把 base_url 指到本地key 随便填一个非空字符串 client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keylocal) resp client.chat.completions.create( modeldeepseek-r1:7b, messages[{role: user, content: 用一句话解释什么是 KV cache。}], temperature0.3, ) print(resp.choices[0].message.content)timeout这个参数比想象中重要。第一次请求某个模型时Ollama 需要把权重从磁盘读进显存32B 级别能花掉半分钟以上如果客户端设了默认的 5 秒超时你看到的是连接超时但实际上模型还在加载重试一次反而更快成功——这就是典型的“重试一下就好了”的玄学本质是冷启动。批处理场景还要注意并发。默认情况下 Ollama 对同一个模型是串行处理请求的同时发十个请求后面九个在排队客户端看到的是响应时间成倍增长。要么在客户端做限流要么显式调大OLLAMA_NUM_PARALLEL但后者会成倍吃显存因为每个并行请求都要一份独立的 KV cache。我的习惯是客户端限流到 24 并发比调服务端参数可控得多。5. 踩过的坑都在这五个翻车现场的现象、原因与解法下面这几条都是我在不同机器上真撞过的共同点是报错信息指向的地方和真正的病因往往不是一回事。按现象、原因、解决三段来写遇到类似症状直接对号入座。5.1 安装与下载阶段的三个坑坑一终端输出全是方块和问号模型像在说乱码。现象很吓人ollama run之后模型回了一堆(cid:0)(cid:11)之类的东西让人怀疑模型文件坏了。原因不在模型在 Windows 传统命令提示符的代码页是 936GBK而模型输出是 UTF-8编码对不上就会这样。解决办法是换一个能正确处理 UTF-8 的终端Windows Terminal 或者 PowerShell 7实在要用 cmd 就先执行chcp 65001切到 UTF-8 代码页再启动。macOS 和 Linux 基本不会遇到除非 locale 被设成了 C。坑二ollama pull进度条卡死重跑又从头开始。现象是下载到某个百分比之后完全不动等半小时还是那个数字。原因是网络中断后连接没有正确关闭进程还在但数据不再流入。解法是CtrlC中断后重跑同一条pull命令正常情况下会从断点续传不会重新下载已经拿到的层。如果重跑之后进度归零说明临时文件已经被清理那只能重来。预防办法是不要在网络切换频繁的环境下拉大模型以及优先用有线网络。坑三装完提示“安装程序无法创建目录”。Windows 上这个报错直指系统盘空间因为安装路径不可选默认落在用户目录下。原因是 C 盘剩余空间不足或者用户目录的权限被组策略改过。解法是先清理出至少 5GB 空间再装如果空间够还是报权限用管理员身份运行安装包。装完之后不管成功与否都建议立刻把模型目录用OLLAMA_MODELS迁到数据盘避免下一次拉模型又把系统盘塞满。5.2 运行与显存阶段的坑坑四报CUDA out of memory但我明明算过显存够。现象是模型加载到一半崩掉日志里是显存分配失败。原因通常有两个一是算的时候只算了权重没算 KV cachenum_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.10.3top_p给 0.9 左右重复惩罚不要超过 1.15否则中文长句会变得生硬。做创意写作用 0.7 以上但要接受结果不可复现。判断标准很简单如果你的下游代码需要用正则去解析输出就必须压随机性如果输出是给人看的可以放宽。任务类型temperaturetop_pnum_predictnum_ctx分类 / 标签抽取0.10.20.853212820484096结构化信息提取0.20.30.95128192摘要 / 改写0.30.50.951210248192代码生成0.20.40.952048819216384创意文案0.70.90.9510244096第二个动作是写一条能一次跑完的验收脚本把这套参数、这个模型标签、这段样例输入全部固化下来每次改配置或换版本都跑一遍。脚本不需要复杂覆盖三类样例就够一段正常业务文本、一段超长文本、一段模型应该拒答的文本比如问它文本里没写的信息。三类都通过才允许上线。这条脚本还兼任回归测试换了模型版本之后跑一次输出风格变化一眼就能看出来。第三个动作是给每次请求记一条精简日志模型标签、num_ctx、temperature、首 token 延迟、总耗时、输出长度。不需要记全文记元数据就行。我吃过一次亏某天开始响应时间从两秒涨到二十秒翻日志才发现有人把OLLAMA_MAX_LOADED_MODELS调大之后同时加载了三个模型显存被挤爆Ollama 开始往 CPU 上放层而这种降级在终端里没有任何提示只有日志里的耗时曲线能看出来。从那以后我每次给一个新环境部署模型都强制走一遍「nvidia-smi看占用 →ollama ps看 GPU 占比 → 三类样例验收 → 记录基线耗时」这条链路不管机器多闲、不管多赶时间。这套动作加起来五分钟能挡掉后面八成“明明之前好好的”的返工。这份部署手册我按上面六章的顺序整理成了可照着敲的步骤版配置模板、验收脚本和排错清单都在同一份资源里按目录顺序取用即可别跳过第 5 章直接上线那几节是拿真实故障换来的。希望帮到你。本文还有配套的精品资源点击获取
