简介《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 显存的卡系统盘只剩 90Gollama 的模型列表里躺着一个拉了一半的 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:32bollama 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 估模型 tag参数量Q4 权重大致体积建议显存建议内存适用场景deepseek-r1:1.5b15 亿1.1GB 左右4GB8GB边缘设备、流程验证deepseek-r1:7b / 8b70 至 80 亿4.7 至 5.2GB8GB16GB日常问答、文本处理deepseek-r1:14b140 亿9GB 左右12GB24GB写代码、中等推理deepseek-r1:32b320 亿19 至 20GB24GB32GB复杂推理、长文档deepseek-r1:70b700 亿40 至 43GB48GB 起64GB高质量生成deepseek-r1:671b6710 亿约 380 至 400GB24GB 加异构480GB 级满血推理需专门方案表里「建议显存」是能跑起来的下限不是跑得舒服的下限。权重之外还有 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_ctxvLLM 之类是启动参数别把名字记混。2.4 环境清单Windows 和 Linux 各一套手册里的操作在两种系统上都能走通差别在安装方式和路径管理。装之前对照下面这张表把环境备齐项目Linux 侧Windows 侧说明操作系统主流发行版内核别太老Win10 及以上需要 WSL2 的场景另算推理服务Ollama装当前稳定发布版Ollama 安装包不用锁小版本装新不装旧显卡驱动与卡匹配的官方驱动官方驱动驱动版本要支持所选 CUDA数据盘单独挂载别放根分区非系统盘模型动辄几十 GPython3.10 及以上3.10 及以上只在微调、API 脚本时需要Markdown 阅读器Typora 或同类Typora 或同类手册里的 md 文件要读客户端Chatbox、Cherry Studio同左图形化对话与知识库内存这一栏容易被忽略。跑 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] # 模型权重落到数据盘避免撑爆根分区 EnvironmentOLLAMA_MODELS/data/ollama/models # 允许局域网内其他机器访问本机自用可保持 127.0.0.1 EnvironmentOLLAMA_HOST0.0.0.0:11434 # 模型常驻显存的时间默认 5 分钟反复加载很浪费时间 EnvironmentOLLAMA_KEEP_ALIVE30m # 并发请求数单卡建议 1 到 2调高只会互相抢显存 EnvironmentOLLAMA_NUM_PARALLEL2 # 同时驻留的模型数量显存紧张时锁成 1 EnvironmentOLLAMA_MAX_LOADED_MODELS1写完保存执行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 psollama 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 层的计算交给 CPUGPU 只负责注意力再配合 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_HOST0.0.0.0:11434没改的话外部一律连不上这是最常见的「Connection refused」。防火墙要放行对应端口# 开放 11434 端口按发行版选 firewalld 或 ufw sudo firewall-cmd --add-port11434/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 之类的文件构建知识库然后在对话时勾选这个知识库。具体操作是新建知识库、选嵌入模型、把文件拖进去、等切片和向量化跑完回到对话界面在输入框上方勾上对应知识库。整个过程有几个参数直接影响效果配置项建议值影响切片大小500 至 800 字太小语义不完整太大检索命中率下降切片重叠50 至 100 字防止句子被切断导致语义丢失返回条数3 至 5 条太多会挤占上下文太少容易答不全相似度阈值中等偏上调低会把无关内容塞进提示词第一次建完库别急着问业务问题先问一个「只在某份文档里出现过的词」看它能不能准确引出来。答不出来多半是切片或嵌入模型选得不对不是模型笨。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 processollama ps里什么都看不到。原因显存不够时框架会把层卸载到内存内存也不够就触发系统的内存回收直接杀掉进程。另一种情况是拉错了 tag本想拉 32B命令里写成了deepseek-r1:671b权重下载量级完全不同。解决先核对 tagollama 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. 验证跑通五步验收和一条我每次都走的习惯装完不算完能证明它跑通才算。我验收一套本地模型环境固定走五步每步都有明确的期望结果任何一步不对就往回退一层查。验收项操作期望结果服务存活curl -s http://127.0.0.1:11434/api/tags返回 JSON模型列表里有目标 tag模型可推理/api/generate带stream:false问一个常识问题返回完整回答total_duration在正常量级显存占用合理ollama ps查看 SIZE 列不超过显存总量未出现明显卸载迹象客户端连通Chatbox 里新建对话发一句话正常流式输出模型名显示为自己派生的 tag知识库命中问一个只在私有文档里出现的词回答里引用该词并给出上下文前两步用命令行就能验完第三步是判断「能跑」和「跑得好」的分界。第四步容易漏掉的是模型名——如果下拉框里还是默认 tag说明你在 Modelfile 里固化的参数根本没生效还在用默认上下文。第五步是唯一能验证私有数据集这条链路是否打通的很多人跳过这一步等到真正用的时候才发现知识库是空的。最后留一条习惯每次改完环境变量或者换模型我都会先跑一遍最小验证脚本而不是直接开客户端聊天。脚本很简单就是一句curl加一句ollama ps输出贴到当天的记录里包含时间、模型 tag、上下文长度和占用。这个习惯是从一次事故里留下来的——某次换模型之后忘了确认OLLAMA_MODELS是否还指向数据盘权重又落回系统盘第二天整台机器因为根分区写满连日志都写不进去查了两小时才定位到原因。从那以后我每次装完、每次改完配置都强制走一遍这五步验收宁可多花五分钟也不要在半夜被一个磁盘满的电话叫起来。这套流程配着 DeepSeek 应用手册里的命令一条条走基本不会偏。需要的话把手册存一份在本地边装边对照希望帮到你。本文还有配套的精品资源点击获取
技术深度解析)
