24G显存部署DeepSeek-R1：Ollama安装、量化选型与知识库排错

简介：《deepseek应用手册》是一份面向深度学习、自然语言处理与API集成学习者的实操型文档，适合希望系统掌握DeepSeek多模型协作、私有知识库搭建及参数调优的初中级用户。压缩包内仅含1个docx文件，体积约207KB，便于轻量下载与随时查阅。内容围绕使用技巧与场景展开，涵盖R1与V3协同写作、文件上传与联网搜索、续写/简化/举例/步骤/检查等指令集，以及万能提问模板和分步指导案例；同时讲解通过Cherry Studio、ollama与chatbox接入私有数据集的API、本地和远程方式。文档还梳理了模型参数规模、max_seq_len、hidden_size等配置项，思维链差异、蒸馏技术及Qwen与Llama架构区别，并附大模型应用方向示意。已有287人学习，适合边查边用、快速建立DeepSeek应用知识框架。

1. 一台 24G 显存的机器，把 DeepSeek 应用手册里的东西装到能跑

我碰到过不止一次这种现场：24G 显存的卡，系统盘只剩 90G，ollama 的模型列表里躺着一个拉了一半的 deepseek-r1:671b，删不掉也跑不起来。机主说他是照着 DeepSeek 应用手册里的命令原样敲的，结果下载跑了四十分钟，磁盘先满，重启后模型条目变成 0 字节。这不是手生，是装之前没把版本、量化、目录这三件事算清楚。DeepSeek 应用手册这份资料覆盖使用技巧、私有数据集、参数与架构、LoRA 微调、低成本部署几块，真到落地那天，最容易卡住的偏偏是安装环节：拉哪个 tag、显存放不放得下、客户端往哪指、知识库为什么答非所问。下面按我实际装过一遍的顺序写，从一台空机器装到能对话、能查私有文档、能验证微调结果。

2. 版本与硬件先算清：DeepSeek-R1 从 1.5B 到 671B 怎么选

装之前先花十分钟算账，比装完再删模型省事得多。这一步不涉及任何命令，纯粹是把「我有什么机器」和「我要什么模型」对齐。算错的地方通常只有两处：把满血版和蒸馏版混为一谈，以及只算了权重显存、忘了上下文缓存。前者会让你下载一个根本装不下的东西，后者会让你在跑得好好的时候突然掉速。

2.1 满血 671B 和蒸馏小模型不是同一类东西

DeepSeek-R1 这个名字底下挂着两类模型。一类是原生的 671B 混合专家模型，社区里叫满血版，单机没有几百 G 内存想都别想；另一类是蒸馏出来的小尺寸版本，用大模型的输出教一个更小的学生模型，常见档位是 1.5B、7B、8B、14B、32B、70B，在 ollama 里就是deepseek-r1:1.5b到deepseek-r1:70b这一串 tag。蒸馏的意义在手册里写得很清楚：把大模型的特征和推理能力压到轻量模型上，部署成本和推理成本都降下来，代价是复杂推理任务的准确率会掉一些。

选档位有个朴素标准：日常问答、写文档、改代码片段，7B 到 14B 够用；要做多步推理、读长文档、写完整模块，32B 是性价比拐点；70B 及以上已经超出单张消费卡的舒适区，除非走量化加异构方案。中文任务我一般优先选基于 Qwen 蒸馏的那几档，训练语料对中文做过优化，输出比基于 Llama 蒸馏的同尺寸版本更贴中文表达习惯；如果任务本身是多语种混杂，再考虑 Llama 系。

# 列出本地已经拉下来的模型、体积和量化格式 ollama list # 看某个 tag 的底细：参数量、量化方式、上下文长度、模板 ollama show deepseek-r1:32b

ollama show这条命令值得养成习惯。它输出的 Modelfile 段会告诉你这个 tag 的默认上下文窗口有多大，而上下文窗口直接决定后面显存够不够。很多「装完能跑、聊两句就卡死」的情况，答案就在这段输出里。

2.2 参数 B 是什么意思，以及量化怎么换算显存

模型名后面那个 B 是 Billion 的缩写，指的是参数量级。手册里那句解释很直白：deepseek-r1:32b里的 32B 就是 320 亿个参数，1.5B 就是 15 亿个参数。参数量决定了模型能力上限，也决定了它要吃多少内存。

真正落地要看的是量化后的体积。Q4 系列量化大致按「每 10 亿参数 0.6 到 0.7GB」估算，Q8 翻倍，fp16 再翻倍。按这个口径算出来的对照表如下，磁盘占用按 Q4_K_M 估：

表里「建议显存」是能跑起来的下限，不是跑得舒服的下限。权重之外还有 KV cache、CUDA 上下文、框架开销，实际占用普遍比权重多一两 G。24G 的卡塞 32B 的 Q4，权重占掉 20G，留给上下文的余量已经很薄，这也是后面第 5 章那条掉速问题的根子。

2.3 第二个吃显存的东西是上下文长度

很多人算完权重视为完事，结果把num_ctx从默认的 4096 调到 32768，模型直接报显存不足。原因在于 KV cache 随上下文线性增长，序列越长，缓存的键值对越多。粗略估算，32B 模型在 fp16 下每 1000 token 的 KV cache 大约占几百 MB 量级，具体取决于层数、注意力头数和头维度；跑到 32K 上下文，几个 G 就没了。

我的做法是先用默认上下文把模型跑通，确认能对话，再按单次任务的真实需要往上加。读一篇几千字的文档，8192 足够；要整篇长文摘要，再试 16384；每加一档都用ollama ps看一次显存。手册里列出的max_seq_len就是控制这条上限的参数，但它在不同框架里位置不一样，ollama 是num_ctx，vLLM 之类是启动参数，别把名字记混。

2.4 环境清单：Windows 和 Linux 各一套

手册里的操作在两种系统上都能走通，差别在安装方式和路径管理。装之前对照下面这张表把环境备齐：

内存这一栏容易被忽略。跑 32B 的时候，如果显存不够，框架会自动把部分层卸载到内存里，内存只有 16G 的机器会直接卡死或者被系统杀掉进程。我一般按「模型体积的两倍」备内存，代价不大，能省掉一堆莫名其妙的退出。

环境就绪之后，剩下的就是装。整个链路是「推理服务 → 模型 → 客户端 → 知识库」，顺序不能反，反了会在排查时分不清是服务没起来还是客户端填错了。

3. 装 Ollama 拉模型：从默认目录到 Modelfile 固化参数

这一章是整条链路的底座。Ollama 负责把模型权重拉下来、加载进显存、对外提供一个本地 HTTP 接口，后面 Chatbox 也好、Cherry Studio 也好、自己写的脚本也好，都是往这个接口上打。装坏的地方集中在三处：模型目录默认落在系统盘、监听地址只有本机、以及把模型的架构参数当成运行参数去调。

3.1 Linux 装 Ollama，先把模型目录挪出根分区

Linux 上的安装一条脚本就够，装完会自动注册成 systemd 服务并开机自启：

# 官方安装脚本，会创建 ollama 用户并注册服务 curl -fsSL https://ollama.com/install.sh | sh # 确认服务状态和端口监听情况，默认只听 127.0.0.1:11434 systemctl status ollama --no-pager ss -lntp | grep 11434

跑完先别急着拉模型。默认的模型目录在系统盘上，32B 加 70B 拉下来能吃掉七八十 G，根分区小一点的机器当场就满。正确顺序是先建数据目录、改归属、再用 systemd 的覆盖配置写环境变量：

# 建独立目录，挂在大容量数据盘上 sudo mkdir -p /data/ollama/models sudo chown -R ollama:ollama /data/ollama # 用 systemctl edit 生成覆盖配置，比改 /etc/profile 可靠 sudo systemctl edit ollama

在打开的编辑器里写入下面这段。systemctl edit会生成一个 drop-in 文件，重启服务后依然生效：

[Service] # 模型权重落到数据盘，避免撑爆根分区 Environment="OLLAMA_MODELS=/data/ollama/models" # 允许局域网内其他机器访问，本机自用可保持 127.0.0.1 Environment="OLLAMA_HOST=0.0.0.0:11434" # 模型常驻显存的时间，默认 5 分钟，反复加载很浪费时间 Environment="OLLAMA_KEEP_ALIVE=30m" # 并发请求数，单卡建议 1 到 2，调高只会互相抢显存 Environment="OLLAMA_NUM_PARALLEL=2" # 同时驻留的模型数量，显存紧张时锁成 1 Environment="OLLAMA_MAX_LOADED_MODELS=1"

写完保存，执行sudo systemctl daemon-reload && sudo systemctl restart ollama，再用systemctl show ollama | grep OLLAMA_MODELS确认变量真的注进去了。这一步的取舍在于：OLLAMA_HOST改成0.0.0.0是为了让第 4 章的远程连接能被外部访问，如果你只在本机用，保持默认更省事；OLLAMA_KEEP_ALIVE调大能减少冷启动等待，代价是显存一直被占着，多模型切换的场景反而应该调小。OLLAMA_NUM_PARALLEL是需要说清楚的一项——它增加的是并发处理能力，模型本身仍在同一张卡上，并发上来后每条请求的生成速度会摊薄，两个人同时用 32B 的体感未必比一个人用好。

3.2 Windows 装 Ollama 与两个必改环境变量

Windows 侧直接下安装包，双击装完托盘里会有一个常驻进程，命令行同样能用ollama命令。安装路径和模型目录默认都在系统盘的用户目录下，同样建议改：

打开「系统属性 → 环境变量」，在用户变量里新增两项，然后从托盘退出 Ollama 再重新启动，变量才会被读到：

# 在 PowerShell 里验证变量是否生效 echo $env:OLLAMA_MODELS echo $env:OLLAMA_HOST # 服务起来后确认端口 netstat -ano | findstr 11434

如果你不想动图形界面，也可以用setx写入，但要注意setx只影响之后新开的进程，当前这个终端读不到。

注意：Windows 上装完先确认显卡驱动是最新的，并且nvidia-smi能看到显存占用。Ollama 在检测不到可用 GPU 时会静默回落到 CPU 推理，界面上没有明显提示，表现就是「模型能跑但慢得离谱」。

3.3 拉模型并做第一次健康检查

环境和目录都定好之后，拉模型就是一条命令的事。tag 一定要写全，只写deepseek-r1会拉到默认档位：

# 拉取 32B 蒸馏版，体积约 20G，看网速决定等多久 ollama pull deepseek-r1:32b # 一次性提问，不进交互界面，方便脚本化验证 ollama run deepseek-r1:32b "用三句话说清楚思维链是什么" # 看模型是否已经加载进显存，以及占用了多少 ollama ps

ollama run带上引号里的提示词就是单轮模式，回答完自动退出，这一点在写批处理脚本时很实用。ollama ps那一列SIZE是包含了上下文缓存的真实占用，比权重体积更能反映显存压力，调参时就盯这个数。

除了命令行，还要确认 HTTP 接口活着，因为后面所有客户端都是走接口的：

# 列出模型清单，返回 JSON 说明服务正常 curl -s http://127.0.0.1:11434/api/tags # 走一次生成接口，stream 关掉方便看完整返回和耗时 curl -s http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-r1:32b", "prompt": "解释一下什么是模型蒸馏", "stream": false }'

/api/tags返回空列表说明服务起来了但没拉到模型；连接被拒说明服务没起来或者端口不对；/api/generate里把stream设为false是为了拿到一个完整 JSON，便于看total_duration这类字段判断生成速度，日常对话用流式体感更好，但排查时非流式更好读。

3.4 用 Modelfile 固化参数：哪些能调，哪些是权重里写死的

默认 tag 的上下文窗口偏小，系统提示词也是通用的。想固定一套自己常用的配置，最省事的做法是写一个 Modelfile，派生出一个新模型：

FROM deepseek-r1:32b # 上下文窗口，直接决定 KV cache 占用，24G 卡上别超过 8192 PARAMETER num_ctx 8192 # 卸载到 GPU 的层数，99 表示能放多少放多少 PARAMETER num_gpu 99 # 采样温度，推理和写代码压到 0.5 至 0.6 更少胡说 PARAMETER temperature 0.6 PARAMETER top_p 0.95 # 重复惩罚，长文生成时略微调高能减少车轱辘话 PARAMETER repeat_penalty 1.05 SYSTEM "你是严谨的技术助理，回答先给结论，再给依据，不确定的地方直接说不确定。"

保存成Modelfile后执行ollama create ds-r1-32b-ctx8k -f ./Modelfile，之后ollama run ds-r1-32b-ctx8k用的就是这套配置。num_gpu那一项值得多说一句：设成 99 是「尽量全放 GPU」，显存不够时框架会自动往 CPU 卸层，速度断崖式下跌，所以它不是越大越好，而是要在显存允许范围内尽量大，靠ollama ps观察实际占用来找平衡点。

手册里还列了一长串参数：max_batch_size、max_seq_len、hidden_size、n_layers、n_heads、inter_dim、dropout、qk_rope_head_dim、v_head_dim、rope_theta、rope_factor、world_size、rank、dtype、gemm_impl。这串东西要分类看，不然容易白折腾：

• 结构类：hidden_size、n_layers、n_heads、inter_dim、qk_rope_head_dim、v_head_dim是模型结构参数，权重文件里已经定死。改它们不会让模型变快，只会让加载直接失败。
• 位置编码类：rope_theta、rope_factor与旋转位置嵌入相关，缩放位置编码可以扩展上下文，但需要和训练时的设置匹配，强行改会让长文输出质量明显下降。
• 精度类：dtype决定用 fp16、bf16 还是 int4 加载，直接换显存占用和速度，是少数值得动手的一项。
• 分布式类：world_size和rank是多机多卡训练/推理时的节点数与当前编号，单机单卡没有意义。
• 训练类：dropout是训练时的正则手段，推理阶段不起作用。
• 框架类：max_batch_size、max_seq_len、gemm_impl属于推理或微调框架的启动参数，出现在 vLLM、微调脚本里，不在 ollama 的 Modelfile 里。

顺带把一个常见误解说清：Chatbox 里能设的是采样参数和上下文长度，改不了模型结构。有人以为改个hidden_size能让 7B 变 32B，这在物理上就不成立。

3.5 24G 显卡跑满血：KTransformers 把 FFN 交给 CPU

如果非要在一张 24G 卡上跑 671B 的满血版，就得换思路。MoE 架构的模型推理时并不是所有专家都激活，激活的专家稀疏，真正吃显存的是被反复调用的注意力部分。KTransformers 这类框架的做法是把 FFN 层的计算交给 CPU，GPU 只负责注意力，再配合 Q4 量化，把显存需求压到 24G 以内。代价是内存要管够——那台机器配到 480GB DDR5、双路 64 核才跑得顺，内存不足会频繁换页，速度比小模型还慢。

部署流程大致是：装 Python 环境、装框架、下载 Q4 量化权重、起一个兼容 OpenAI 接口的服务，然后第 4 章的客户端把地址指过去就行。具体命令参数以对应项目的说明为准，不要照抄网上的旧参数，量化和硬件后端一变，参数就跟着变。

提示：这条路适合「必须用满血版、但只有一张卡」的场景。日常任务老老实实上 32B，投入产出比高得多，异构方案的内存成本往往比多买一张卡还贵。

4. 接客户端与私有数据集：Chatbox、Cherry Studio 的接口与知识库配置

推理服务跑通之后，纯命令行用起来还是别扭：翻历史记录费劲、系统提示词每次要重打、私有文档也没法直接问。这一章解决两件事，一是给模型配一个顺手的前端，二是让它能读到自己的资料。手册里给了三条路：API 方式、本地方式、远程方式，三条路的区别只在模型跑在哪、客户端连到哪。

4.1 Chatbox 接本地 Ollama：三处地址别填错

Chatbox 装完第一次打开会让你选模型提供方。选 Ollama API，接口地址填http://127.0.0.1:11434，模型下拉框里能刷出第 3 章拉的 tag 就说明通了；刷不出来基本是服务没起、端口被占，或者地址末尾多写了/v1。

选完之后在设置里还有几项值得调：

# Chatbox 设置里与 Ollama 相关的关键项 api_host: http://127.0.0.1:11434 # 本机服务地址，远程连接时换成服务器 IP model: ds-r1-32b-ctx8k # 选自己在 Modelfile 里派生的模型，参数已固化 context_message_count: 10 # 携带的历史轮数，调太高会把上下文撑满 temperature: 0.6 # 客户端侧采样温度，与 Modelfile 里冲突时以客户端为准

context_message_count是容易被忽略的一项。多轮对话时客户端会把历史消息一起发给模型，轮数设得太大，上下文很快吃满，表现是聊到十几轮之后模型开始忘事、或者报上下文超限。做长文档分析时我一般设成 4 到 6，需要连贯推理的调试类对话才往上加。

4.2 远程连 Ollama：先改监听地址再放行端口

模型跑在公司的机器上、人在自己笔记本上操作，就用到远程方式。做法不复杂，顺序别反：先在服务器上改监听地址，再放行端口，最后在本地客户端填服务器地址。

服务器侧在第 3 章已经写了OLLAMA_HOST=0.0.0.0:11434，没改的话外部一律连不上，这是最常见的「Connection refused」。防火墙要放行对应端口：

# 开放 11434 端口，按发行版选 firewalld 或 ufw sudo firewall-cmd --add-port=11434/tcp --permanent sudo firewall-cmd --reload # 从另一台机器验证连通性，能看到 JSON 就说明通了 curl -s http://服务器IP:11434/api/tags

本地 Chatbox 里把接口地址从127.0.0.1换成服务器IP:11434，其余不变。这里有个安全层面的取舍要自己拿主意：把 11434 直接暴露在网络上，等于任何人拿到地址就能调用你的模型，我一般限制为内网访问，或者在前面加一层反向代理做鉴权。

4.3 Cherry Studio 走 API 方式：导入 key 再建知识库

如果不想在本地跑模型，直接用官方或第三方提供的接口，Cherry Studio 这条路更轻。装完之后在设置里添加模型提供方，把申请到的 API key 填进去，模型列表刷新出来就能对话。

知识库是它比命令行强的地方。手册里给的步骤是：用自己的 Excel、Word 之类的文件构建知识库，然后在对话时勾选这个知识库。具体操作是新建知识库、选嵌入模型、把文件拖进去、等切片和向量化跑完，回到对话界面在输入框上方勾上对应知识库。整个过程有几个参数直接影响效果：

第一次建完库，别急着问业务问题，先问一个「只在某份文档里出现过的词」，看它能不能准确引出来。答不出来多半是切片或嵌入模型选得不对，不是模型笨。

4.4 文件类型与切片：为什么 PDF 是最后选项

手册里那句「尽量不要使用 pdf 格式」是血泪经验，不是随口一说。文本文档、Markdown、Word、Excel 这些格式的结构是显式的，段落、标题、表格都能被解析器正确识别，切片切在段与段之间，语义完整。PDF 恰恰相反，它描述的是「字画在页面的哪个坐标」，双栏排版、页眉页脚、跨页表格、扫描件水印全混在一起，解析出来的文字顺序经常是乱的，切片自然也就断了。

我的处理顺序是：有原始 Word 或 Markdown 就用原件；只有 PDF 的话，能拿到文字版就别用扫描版；实在只有扫描件，先用工具做一遍文字识别再入库，并且人工抽查几页解析结果。Excel 这类结构化数据更适合单独处理，把关键列拼成自然语言段落再入库，比整表塞进去效果好得多。

注意：知识库的答案质量取决于检索到的片段，不取决于模型多大。同一份资料，切片切对了，7B 也能答得准；切片切乱了，70B 一样答非所问。

4.5 把指令集和提问模板存成预设

手册里的常用指令集在客户端里同样可用：/续写处理回答中断、/简化把复杂内容转成白话、/举例要求给出实际代码案例、/步骤让模型分步指导操作流程、/检查帮你找文档里的错误。这些都是纯文本指令，任何客户端都认。

真正提升效率的是把它们和万能提问模板一起做成预设。模板结构是「背景 + 需求 + 约束条件」，约束条件可省。举个实际用过的组合：背景写清环境（Linux、单卡 24G、已经装好 Ollama），需求写清要做什么（把 32B 模型的上下文从 4096 调到 8192 并保持速度），约束写清边界（不能加显存、不能换成更小的模型）。三段齐了，模型给出来的往往是能直接执行的步骤，而不是泛泛而谈。

在 Chatbox 和 Cherry Studio 里都能把这套模板存成会话预设或系统提示词，下次新建对话直接选，不用每次重打。我自己存了四套：排错、写代码、读文档、写文案，覆盖了八成场景。

5. 避坑与排查：装完才发现的五类报错

装的过程里，真正让人卡住半天的不是命令敲错，而是报错信息指向的位置和根因差着好几层。下面五条是我在不同机器上反复遇到的，按「现象 → 原因 → 解决」记下来，遇到同类问题时能少绕几圈。

5.1 现象：拉到一半磁盘满，模型条目删不掉

现象：ollama pull跑到一半卡住，随后报磁盘空间不足，ollama list里出现一个体积异常小或者显示为 0 的条目，ollama rm删了还在。

原因：模型目录默认在系统盘，几十 G 的权重直接把根分区写满。中断的下载会留下不完整的 blob 文件，清单里已经登记但内容不全，删除时因为元数据和实际文件对不上而失败。

解决：先df -h确认哪个分区满了，用du -sh /usr/share/ollama之类定位到实际目录，手动清掉不完整的 blob，再按 3.1 的方式把OLLAMA_MODELS指到数据盘，重启服务后重新拉。装任何模型之前，我都先看一眼目标分区的剩余空间够不够模型体积的三倍。

5.2 现象：进程被系统杀掉，日志里只有 killed

现象：模型加载到一半终端断开，dmesg或系统日志里出现Out of memory: Killed process，ollama ps里什么都看不到。

原因：显存不够时框架会把层卸载到内存，内存也不够就触发系统的内存回收，直接杀掉进程。另一种情况是拉错了 tag，本想拉 32B，命令里写成了deepseek-r1:671b，权重下载量级完全不同。

解决：先核对 tag，ollama show看参数量对不对；再看内存总量，按「模型体积两倍」备内存；确实要在小机器上跑，就降档到 14B 或 7B，或者改用 KTransformers 这类异构方案。被 OOM 杀掉时不会有友好提示，这是排查里最容易误判成「软件坏了」的一类。

5.3 现象：远程连不上，客户端一直转圈

现象：本地 Chatbox 填了服务器 IP 和 11434 端口，点测试一直转圈，或者直接报连接被拒绝；服务器上curl 127.0.0.1:11434却是通的。

原因：Ollama 默认只监听127.0.0.1，本机访问通、外部访问不通。改完环境变量没重启服务，或者防火墙没放行端口，都会表现成同一个现象。

解决：ss -lntp | grep 11434看监听地址是127.0.0.1:11434还是0.0.0.0:11434，前者说明变量没生效，回到 3.1 检查 drop-in 文件有没有写对段名、有没有执行daemon-reload；后者说明是端口没放行，去查防火墙。另外别忘了云主机的安全组是独立于本机防火墙的另一层。

5.4 现象：调大上下文后速度断崖式下跌

现象：num_ctx从 4096 调到 32768，第一句话还正常，第二句开始每秒只吐一两个字，ollama ps里显示的占用远超模型体积。

原因：KV cache 随上下文线性增长，24G 卡的余量本来就被 32B 权重吃掉大半，上下文一放大，部分层被挤到 CPU，每次生成都要在显存和内存之间搬运。

解决：把num_ctx退回到 8192 或 16384，用ollama ps对比两次的占用；确实需要长上下文，就换成参数量更小的模型配更长的窗口，或者上第 3.5 节那套异构方案。参数不是越大越好，长上下文和小显存之间必须二选一。

5.5 现象：知识库答非所问，检索出来的片段驴唇不对马嘴

现象：私有知识库建好了，问一个文档里明确写着的流程，模型给出来的答案似是而非，或者干脆说「资料中没有提到」。

原因：九成是入库文件的问题。PDF 双栏排版解析后段落顺序错乱，扫描件没有做文字识别，切片切在句子中间导致语义断裂，嵌入模型选了个不适配中文的。剩下那一成是检索返回条数太少，命中的片段不完整。

解决：换成原始 Word 或 Markdown 重新入库，切片大小调到 500 至 800 字、重叠 50 至 100 字，返回条数从 3 提到 5 再试一次。验证方法是问一个只在那份文档里出现过的专有名词，看检索结果里有没有它，有就是生成环节的问题，没有就是切片或嵌入的问题。

6. 验证跑通：五步验收和一条我每次都走的习惯

装完不算完，能证明它跑通才算。我验收一套本地模型环境，固定走五步，每步都有明确的期望结果，任何一步不对就往回退一层查。

前两步用命令行就能验完，第三步是判断「能跑」和「跑得好」的分界。第四步容易漏掉的是模型名——如果下拉框里还是默认 tag，说明你在 Modelfile 里固化的参数根本没生效，还在用默认上下文。第五步是唯一能验证私有数据集这条链路是否打通的，很多人跳过这一步，等到真正用的时候才发现知识库是空的。

最后留一条习惯：每次改完环境变量或者换模型，我都会先跑一遍最小验证脚本，而不是直接开客户端聊天。脚本很简单，就是一句curl加一句ollama ps，输出贴到当天的记录里，包含时间、模型 tag、上下文长度和占用。这个习惯是从一次事故里留下来的——某次换模型之后忘了确认OLLAMA_MODELS是否还指向数据盘，权重又落回系统盘，第二天整台机器因为根分区写满连日志都写不进去，查了两小时才定位到原因。从那以后我每次装完、每次改完配置，都强制走一遍这五步验收，宁可多花五分钟，也不要在半夜被一个磁盘满的电话叫起来。这套流程配着 DeepSeek 应用手册里的命令一条条走，基本不会偏。需要的话把手册存一份在本地，边装边对照，希望帮到你。

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