企业官网建设流程全解析

简介：《DeepSeek应用手册》是一份面向深度学习爱好者、微调技术研究者及AI应用开发者的操作型资料，聚焦DeepSeek大模型在日常使用与私有化部署中的实际落地。手册内容覆盖多模型协同（R1与V3分工）、文件上传与联网搜索技巧、万能提问模板，并详解通过Cherry Studio、Ollama与Chatbox接入API或本地私有数据集的流程，同时对max_batch_size、max_seq_len、hidden_size等关键参数给出通俗解释，并说明蒸馏技术如何将大模型能力迁移至轻量模型，既适合零基础用户快速掌握使用技巧，也能帮助进阶用户优化本地部署参数与性能。资源包内为1个docx文档，压缩包大小207KB，文件体量轻量，便于下载后直接阅读或按章节检索。目前已有285人学习，内容由作者从实战角度提炼整理，尤其适合希望将DeepSeek融入写作、任务拆解、私有知识库构建等场景的读者参考。

1. 装一套能跑的 DeepSeek 环境：先分清三条路再动手

第一次部署 DeepSeek 时我栽得挺结实：照着教程装好 Ollama，兴致勃勃敲下ollama run deepseek-r1:32b，然后屏幕上一行红字——显存不足。整份 deepseek 应用手册翻完才发现，问题不在命令，而在参数量和显存需求的关系被我搞混了。1.5B 是 15 亿参数，32B 直接翻到 320 亿，这还没算推理时 KV Cache 占掉的那块显存。对多数人来说，本地跑 DeepSeek 不是“装个软件”就完事，而是路径选择：想轻量跑，走 Ollama 全家桶，改配置就能玩；想带私有数据，走 Cherry Studio 或 API 做知识库；想到微调和满血部署，就得碰 LoRA 和 KTransformers 这类重装备。这篇按我的实操顺序拆开讲，适合正卡在“装什么、怎么配、坏了怎么救”的开发者。

2. 本地跑起来：Ollama 部署与 Chatbox 接入

2.1 先选模型尺寸：1.5B 到 32B 怎么定

Ollama 是本地跑 DeepSeek 最省事的入口，装上之后一条ollama run就能把模型拉下来。但我见过太多人栽在第一步：不看显存，直接拉最大的模型，然后看着 OOM 报错发呆。DeepSeek-R1 后面跟的参数 XX B，意思就是 XX 乘上 10 亿个参数，1.5B 是 15 亿参数，32B 是 320 亿参数。参数越大，能力越强，显存和内存占用也直线上升。

我一般这样选：手头只有 8 GB 显存的卡，老老实实用 1.5B，适合跑通流程；有 24 GB 的 4090，可以上 32B，流畅度和智能程度平衡得比较好。满血 671B 单卡 24 GB 能跑？能，但要走 KTransformers 这类 CPU 卸载方案，后面第五章专门讲。选尺寸这件事，本质是“先定硬件预算，再挑模型”，反过来选必然翻车。

2.2 安装 Ollama 并下载 DeepSeek-R1

Linux 服务器上我习惯用官方安装脚本，一步到位：

# Linux / macOS 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 下载并运行 DeepSeek-R1 32B 模型 ollama run deepseek-r1:32b

Windows 用户直接去官网下载OllamaSetup.exe，双击安装完，CMD 里同样能跑ollama run deepseek-r1:32b。这条命令的逻辑是：先检查本地有没有 deepseek-r1:32b 这个模型，没有就自动从模型库拉取，拉完直接进入交互式对话界面。我第一次跑的时候没注意终端里那一大串下载进度，还以为是卡住了，其实是 32B 模型十几个 GB 在慢慢下。

模型默认存在用户目录下，Linux 是/root/.ollama/models，Windows 是C:\Users\用户名\.ollama\models。这个路径后面配知识库、做微调经常要手动指定，建议提前记住。下载速度一般取决于网络，国内环境偶尔会断，断了重跑ollama run会接着断点续传，不用清缓存重来。

2.3 用 Chatbox 接入本地模型

Ollama 自带的终端交互够用，但很多人想要个能保存会话、有界面的工具，我用的搭配是 Ollama 当推理引擎，Chatbox 当前端。安装 Chatbox 之后，进入设置界面，模型提供方选“Ollama API”，API 地址填http://127.0.0.1:11434，模型选deepseek-r1:32b，保存就能聊天。

关键点是不要填错地址。本地 Ollama 服务默认监听 11434 端口，地址写成http://localhost:11434或http://127.0.0.1:11434都行，但不要随手填成https，本地服务走的是明文 HTTP。Chatbox 里填完地址，可以先点一下“检查连接”，能读到模型列表说明通了。连不上时先回终端确认 Ollama 服务活着，再查端口有没有被占用。

Chatbox 的设置页里还能调一组参数，第一次接触的人容易懵。核心几个是：max_batch_size控制模型一次能处理的最大样本数，默认就行；max_seq_len定义最长输入序列长度，填太小长文档会被截断，填太大爆内存；temperature控制随机性，写代码我习惯调到 0.2 以下，做头脑风暴调到 0.8 以上。这些参数属于“调坏了大不了重置”的类型，别怕，大胆试。

3. 私有数据集接入：Cherry Studio 与 API 两条路

3.1 Cherry Studio 安装与 API Key 导入

本地跑模型解决的是“模型能力”问题，但如果想让它回答你手里的 Excel、Word、TXT 这些私有资料，就得走知识库路线。我用的工具是 Cherry Studio，它对非技术用户比较友好，不用写代码，界面操作就能建知识库。

安装 Cherry Studio 后，第一步是导入 API Key。官方 Key 和第三方中转 Key 都能用，区别在于官方稳定但额度有限，第三方便宜但得挑口碑好的。导入位置在设置里的“模型服务”一栏，把 Key 粘进去，再选择你要用的模型，DeepSeek 的 API 网关会自动识别模型名。这里有个容易踩的坑：有些第三方服务商把模型名改成别名，比如deepseek-r1-pro这种，导入后选不到，得去服务商的文档里查真实的模型标识。

3.2 用本地文件构建知识库：为什么尽量别用 PDF

知识库支持文本文档、PDF、Excel 表格和图片。但我自己的经验是：能用 Word 和 Excel，就别用 PDF。

PDF 在知识库场景里是个坑货。扫描版 PDF 本质是图片，没有文字层，解析出来全是乱码；文字版 PDF 也常因为分栏、页眉页脚被切得七零八落。我踩过一次：把一份 PDF 合同丢进知识库，问“违约金比例是多少”，模型答了个风马牛不相及的条款，后来排查发现是 PDF 解析时把两页内容拼在了一起。Excel 和 Word 是结构化文本，切分干净，检索准确率高得多。如果手头只有 PDF，建议先用工具转成 Word 或 TXT 再进知识库。

知识库的构建逻辑不算复杂：文件上传后，Cherry Studio 会做文本切分和向量化，生成一个个“片段”存起来。使用时勾选“知识库”开关，模型先检索相关片段，再结合片段内容回答。这里要提醒一句：知识库不是万能的，它做的是检索增强生成，如果文档本身就没写清楚，模型也编不出来。所以提问时尽量带上上下文语境：“根据《XX合同》第 3 条，违约金怎么计算”，而不是干巴巴问“违约金多少”。

3.3 远程接入：把 Ollama 服务地址改到服务器

如果你有一台远程服务器在跑模型，想在本地 Chatbox 里用，操作也不复杂。核心思路就一句话：让 Ollama 监听所有网卡，然后把本地 Chatbox 的服务地址指向服务器 IP。

# 在远程服务器上设置监听地址 OLLAMA_HOST=0.0.0.0:11434 ollama serve # 如果重启后失效，写入服务配置： # Linux systemd 服务编辑 /etc/systemd/system/ollama.service # 在 [Service] 段加入 Environment="OLLAMA_HOST=0.0.0.0:11434" sudo systemctl daemon-reload sudo systemctl restart ollama

远程服务器上跑完这两步，本地 Chatbox 里把 API 地址从127.0.0.1:11434改成http://服务器IP:11434，模型选同一个名字，就能远程调用了。注意这不是什么代理，纯粹是把 Ollama 的监听范围从只允许本机访问，改成允许局域网访问。有两件事必须做：一是确认服务器防火墙放行了 11434 端口，二是如果服务器有安全组策略，也需要去控制台放行。否则本地会一直卡在“连接超时”，我当初排查了两个小时，最后才发现是安全组没放行。

4. 避坑指南：部署过程中最常见的五个坑

4.1 模型秒退或启动即失败

现象：运行ollama run deepseek-r1:32b，模型加载到一半直接退出，或者刚进入对话界面就崩溃。 原因：显存不足是主因，其次是模型文件损坏。 解决：先看报错有没有OOM或CUDA out of memory。有就换小模型，比如ollama run deepseek-r1:1.5b。如果报错是“文件不完整”，删掉模型重新拉一遍，ollama rm deepseek-r1:32b后再ollama run。还有个常见情况是 Windows 上显存充足但共享内存不够，去核显设置里多分点共享显存。

4.2 显存占用比预期高很多

现象：32B 模型官方说 20 GB 显存能跑，实际一启动直接吃满 24 GB，还报了 OOM。 原因：上下文长度默认值太大。Ollama 默认给 2048 tokens 的上下文，但很多前端会把它改到 4096 或 8192，KV Cache 随上下文长度线性增长，显存自然水涨船高。 解决：在 Ollama 里设置OLLAMA_CONTEXT_LENGTH=2048，同时把前端设置里的max_seq_len调小。跑长文档时再临时调大，不跑就调回来。从那以后我跑 32B 都会先设 2048 验证能通，再逐步加大。

4.3 Chatbox 提示连接失败

现象：设置填了http://127.0.0.1:11434，点保存后提示“连接失败”或“无法获取模型列表”。 原因：八成是端口写错或 Ollama 没在运行，少数情况是系统代理把本地流量劫持走了。 解决：先ollama list确认服务活着，再netstat -ano | grep 11434看端口监听状态。如果开了代理，检查代理设置里有没有把127.0.0.1排除在外，很多代理工具会默认拦截本地请求，导致连接失败。

4.4 知识库问答答非所问

现象：勾选了知识库，问文档相关内容，模型给的答案和文档对不上。 原因：要么是 PDF 解析质量太差导致切分碎片化，要么是提问时没指定文档范围。 解决：把 PDF 优先转成文本再导入知识库。提问时把范围说清楚，比如“根据《产品需求文档》中关于登录模块的描述，列出主要功能点”，让检索阶段能精准命中片段。还有一个细节：知识库多个文件混合时，问题和答案之间容易被模型“二次加工”带偏，遇到答非所问先确认勾选的是不是目标知识库。

4.5 Windows 下模型路径和环境变量设置后不生效

现象：设置了OLLAMA_MODELS指向 D 盘，重启后发现模型还是下载到 C 盘。 原因：Windows 的 Ollama 以服务方式运行，只改用户环境变量没用，服务读取的是系统环境变量或服务配置。 解决：在系统环境变量里新增OLLAMA_MODELS，设置完到“服务”里重启 Ollama 服务，不是简单关掉终端窗口。验证方式：ollama list确认路径已变更。这个坑我反复踩过，后来总结出一句话：Windows 上凡是 Ollama 配置不生效，先去重启服务，别怀疑配置语法。

5. 进阶操作：LoRA 微调与低成本部署满血 R1

5.1 在 Linux 上准备 LoRA 微调环境

到了进阶这一步，部署目标从“能跑”变成“会适应你的业务”。微调不是训练大模型，它是在预训练模型基础上做少量参数适配。LoRA 的核心思路是只更新低秩矩阵，不碰原始权重，好处是显存占用低、训练快、存储占用小。我在 Linux 服务器上做 LoRA 微调，参考的是某开源微调指南项目里的 Qlora 方案，整体流程不复杂，但对环境整洁度要求高。

先准备一个干净环境：

# 创建独立 conda 环境，避免污染系统 Python conda create -n llama-factory python=3.10 -y conda activate llama-factory pip install llama-factory transformers datasets accelerate # 准备数据集（JSON 格式，alpaca 风格）

数据集格式是关键。LoRA 微调的数据集一般是 JSON，每条包含instruction、input、output三个字段。instruction是任务描述，input是输入材料，output是期望输出。我从业务里抽了 200 条真实问答做数据集，微调出来的效果比通用模型贴近业务得多。注意数据质量和多样性要兼顾，全是同一模板的数据，模型会学成复读机。数据集准备这一块，网上的教程很细，但多数默认你已经懂 JSON 格式规范，我见过不少初学者栽在少一个逗号导致解析失败上，建议写完数据先python -m json.tool验证一遍。

5.2 用 KTransformers 跑满血 DeepSeek-R1

如果目标是跑满血版 DeepSeek-R1，也就是 671B 参数那版，常规思路得一堆 A100，显存算下来天价。但有了 KTransformers 框架，单张 4090 24 GB 也能跑，核心原理是“混合推理”：把计算量最大的 FFN 层放到 CPU 上跑，只有 attention 层留在显卡。这样显存压力大减，代价是 CPU 和内存要够强。

参考配置是双路 Xeon 64 核 + 480 GB DDR5 内存 + 4090 24 GB。这个配置的合理之处在于，FFN 卸载到 CPU 后，CPU 核心数和内存带宽直接决定推理速度。我用过 32 核的机器跑，速度慢到没法用；换 64 核后基本能稳定在可接受范围。部署步骤大致是：拉取 KTransformers 源码，下载量化好的模型权重，然后启动服务。

# 以 4bits 量化权重为例，启动推理服务 python -m ktransformers.local_chat --model_path ./DeepSeek-R1-Q4_K_M --gguf_path ./DeepSeek-R1-Q4_K_M.gguf

启动参数里--model_path指向解压后的模型目录，--gguf_path指向量化后的权重文件。启动日志里会显示“放置到 CPU 的层数”和“放置到 GPU 的层数”，这个信息很重要，如果 FFN 层没有识别到 CPU，实际上还是在 GPU 上跑，24 GB 会瞬间打满然后崩溃。第一次启动时间会比较长，因为需要做权重转换和缓存预热，不是卡死。

5.3 微调后的 LoRA 权重和部署怎么衔接

微调完的 LoRA 权重一般是一个几百 MB 的小文件，使用时要加载回基座模型。Chatbox 这类前端工具默认不直接加载 LoRA 权重，我一般有两种处理方式：一是用ollama create把基座模型和 LoRA 合并生成一个新模型，二是通过后端推理脚本加载 LoRA 权重再暴露 API。前者适合快速验证，后者适合正式接入应用。

# 方式一：用 Modelfile 合并 LoRA 权重（ollama create） FROM deepseek-r1:7b ADAPTER ./lora-output/adapter_model.bin

合并后新模型会出现在ollama list里，和普通模型一样用。方式一的好处是简单，坏处是每次微调迭代都要重新合并；方式二更灵活，但需要写 Python 加载逻辑，适合本身就有后端服务的场景。微调这一步没有捷径，核心可靠建议只有一个：每次微调前备份基座权重，LoRA 合并前验证数据集质量，否则调出来的模型会比原版还难用。

6. 验证跑通：模型是不是真能用，几项检查一做便知

装完一套环境，最怕的就是界面能聊天，但真正用起来全是问题。我给自己定了一套验证清单，每次部署完强制走一遍，几十秒就能确认环境是不是真的健康。

第一项是冷启动时间。模型加载完第一次输入文字，到开始吐出第一个字的时间，我一般记录这个值。Ollama 加载 32B 模型在 24 GB 显存的机器上，冷启动通常在 10 秒左右；如果超过 30 秒，多半是磁盘读取慢或者显存被别的进程占了。验证命令先跑一次ollama run deepseek-r1:32b "你好"，数一下从回车到出字的秒数。

第二项是推理质量。随便找一道需要推理的数学题丢进去，比如“一根绳子剪成两段，第一段比第二段长 20%，两段一共长 90 米，每段各长多少米”，然后观察模型的思维链输出。DeepSeek-R1 系列会把完整的推理过程展示出来，如果看到它先定义变量再逐步解方程，说明模型工作正常；如果思维链乱跳或直接给结论，就要检查量化参数是不是压太狠了。

第三项是私有知识库实测。在 Cherry Studio 里勾选知识库，问一个文档里有明确答案的问题，比如“售价在 100 元以上的商品有哪些”。如果回答能准确引用文档里的字段名和数值，流程就算通。第四项是微调效果对比。同一个问题问微调前和微调后的模型，看答案是不是更贴近业务口径。如果差异不明显，先检查 LoRA 权重有没有正确加载，再检查数据集有没有在学习阶段跑进模型。

最后别忘了看一眼日志。Ollama 的终端日志里会有显存占用、token 生成速度等指标，速度稳定在每秒钟 10 到 20 个 token 属于合理范围，太低就要排查 CPU 过载或内存带宽瓶颈。我从那以后每次部署完，都强制自己把这一套流程完整走一遍，哪怕只是换了一个模型版本也会重跑，因为上线后才发现模型在糊弄你，那才是真的血亏。希望帮到你。

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