有人把 DeepSeek 当成“又一个 ChatGPT 平替”，也有人把它当作大模型学习的入口。我的态度很明确：它是我 2025 年至今最值得花时间研究的开源大模型，没有之一。这篇文章是我从零开始学习 DeepSeek 的完整笔记，涵盖选型逻辑、本地部署、API 调用、上下文管理、微调实战、工具链接入和问题排查，全程用实际操作说话。适合三种人：第一次接触大模型、想搞清楚“怎么跑起来”的入门者；已经在用 API、想进一步掌握部署和微调的中阶玩家；以及需要评估大模型落地成本的技术负责人。

我自己踩过的坑，比如显存估算错误导致推理服务反复 OOM、上下文窗口被无意义内容塞满、LoRA 微调后模型“记性变差”，都会写在后面。你照着做，至少能少走我一半的弯路。

1. 为什么偏偏选 DeepSeek：不只是“开源”两个字

1.1 你要的不是最强模型，而是最能让你学到东西的模型

如果你只是想“用一下 AI”，直接开网页版或买 API 就行，不需要看这篇笔记。但如果你的目标是理解大模型到底怎么工作、怎么部署、怎么调优，那么选择一个权重开放、技术文档齐全、社区活跃且推理成本可控的模型，比追求榜单第一重要得多。

DeepSeek 在这几个维度的匹配度非常高。它开源了模型权重，意味着你可以在自己的服务器上加载、量化、微调、部署，而不是只能通过别人封装好的接口调用。你能够真正观测到一个模型从加载到推理的完整过程，这是“能用”与“懂它”的分水岭。

DeepSeek 的模型其实包含多个成员：对话模型 DeepSeek-V3、推理模型 DeepSeek-R1 系列，以及后来迭代的蒸馏版本。每个版本定位不同，V3 擅长通用对话和指令跟随，R1 以推理能力见长，蒸馏版则适合资源有限的场景。学习的时候不要笼统说“我在学 DeepSeek”，要清楚自己在操作的是哪个版本、什么规格。

1.2 架构关键词：MoE 与 MLA 背后的工程智慧

DeepSeek 在技术架构上有两个值得写进笔记的关键点。

第一是 MoE（Mixture of Experts，混合专家）架构。简单理解，MoE 把一个大模型拆成多个“专家”子网络，每次推理时不是所有参数都被激活，而是由路由机制挑选出与当前任务最相关的少数专家来参与计算。举一个生活化的类比：就像一家大公司，全公司有几百名员工，但处理一个合同只需要法务和财务的几个人参与，不需要让前台和保洁也到场。这样既保留了大模型的知识广度，又控制了单次推理的计算量。DeepSeek 在 MoE 上做了不少优化，比如共享专家与路由专家的配合、负载均衡的损失项设计，这些细节是读论文时值得深挖的地方。

第二是 MLA（Multi-head Latent Attention，多头潜在注意力）。注意力机制是大模型处理序列关系的核心，它需要在推理时缓存历史 token 的 Key 和 Value 信息，这些缓存叫 KV Cache。序列越长，KV Cache 占用的显存就越大，这是长上下文场景的主要成本来源。MLA 的思路是把 Key 和 Value 压缩到一个低维潜在空间，减少缓存体积。效应很直接：同样显存条件下，能支持的上下文长度明显增加，或者同样上下文长度下批量处理能力更强。这解释了为什么 DeepSeek 系列模型在做长文本任务时性价比表现突出。

把这两个架构特点记下来，你再看后面的显存估算、上下文管理、推理性能调优，就能理解很多决策背后的原因了。

2. 跑起来再说：三种方式打通 DeepSeek 的“第一次对话”

2.1 新手优先走 API：五分钟验证一个想法

我第一次接触 DeepSeek 时选择的是官方 API，理由是它足够快、足够便宜，可以把精力集中在理解模型行为上，而不是先被部署过程劝退。

申请注册后，创建一个 API Key，然后通过接口发送对话请求。调用起来非常直接，一个兼容风格的 HTTP 请求就能完成。注意几个新手上路时的细节：模型名称要写对，不同版本对应不同 model 参数；temperature 控制回复的随机性，偏低适合代码生成和检索提取，偏高适合头脑风暴；max_tokens 限制回复长度，不是你想让它说多少就说多少，它同时受限于模型的上下文上限。

我当时测试一个简单的问答，用 Python 写了个脚本：

import requests url = "https://api.deepseek.com/chat/completions" payload = { "model": "deepseek-chat", "messages": [ {"role": "system", "content": "你是一个擅长解释复杂概念的老师。"}, {"role": "user", "content": "用一句话解释什么是注意力机制。"} ], "temperature": 0.7, "max_tokens": 200 } headers = { "Authorization": "Bearer 你的API密钥", "Content-Type": "application/json" } resp = requests.post(url, json=payload, headers=headers) print(resp.json()["choices"][0]["message"]["content"])

这段代码会把一个完整的大模型调用链路跑通：构造请求、身份认证、携带对话历史、接收回复。这是理解更复杂应用（比如 Agent、多轮记忆）的最小起点。API 默认不会自动管理历史对话，每次调用的 messages 需要你自己拼装，这其实是在逼你理解“上下文”是怎么构造的——后面讲上下文管理时我会详细展开。

2.2 本地部署：用 Ollama 垒起第一块砖

走完 API 之后，下一步一定是本地部署。原因很朴素：API 是别人的机器，本地部署才是你自己的机器；数据不出服务器这个诉求，在很多场景下是硬性的。

本地部署不必一开始就上大集群，我推荐用 Ollama 作为起点。Ollama 把模型下载、量化、推理服务封装成了几条命令，是我用过的本地大模型方案中对新手最友好的一个。

安装完成后，拉取模型并启动：

ollama pull deepseek-r1:7b ollama run deepseek-r1:7b

第一条命令把模型下载到本地，第二条命令启动一个交互式对话界面。注意模型命名中的后缀，7b 代表 7B 参数量版本，此外还有 1.5b、8b、14b、32b 等不同规格。参数量越大，能力越强，但对硬件要求也越高。对于只想跑通流程的用户，我建议先从最小的 1.5b 或 7b 开始，而不是一上来就挑战最大的版本。

Ollama 启动后不仅仅是一个聊天窗口，它的底层会启动一个本地 HTTP 服务，默认监听 11434 端口。这意味着你完全可以在自己的代码里通过 localhost 访问这个模型，也可以用其他工具链（比如 Dify）把本地模型作为后端接入。我在跑通交互界面之后，做的第一件事就是写一个脚本通过本地 API 发请求，确认模型确实作为一个独立服务在运行。

2.3 高端局：vLLM 部署的关键认知

如果你进一步追求高吞吐、更规范的服务化部署，可以研究 vLLM。它与 Ollama 的定位不同，Ollama 追求开箱即用，vLLM 追求高性能推理，尤其是批量并发场景下的吞吐优化。

vLLM 的核心技术是 PagedAttention，原理参考了操作系统虚拟内存的分页思想。传统 KV Cache 需要一整块连续显存，很容易碎片化；PagedAttention 把 KV Cache 切分成固定大小的块，像内存分页一样按需分配，显存利用率显著提升。这意味着同一块显卡可以服务更高的并发请求。

部署 DeepSeek 系列模型用 vLLM 时，命令大致要指定模型路径、设备数量、GPU 内存利用率上限、服务端口这些参数。显存占用不能只看模型权重大小，还要加上 KV Cache 开销、激活值内存、CUDA 上下文占用。实践经验告诉我，7B 的 bf16 全精度权重约占 14GB 显存，量化到 4bit 后只要约 5-6GB；70B 级别模型至少要准备 80GB 以上的显存才能玩得舒服。

本地部署的意义不只是“省钱”。它给了你检查模型真实行为、调整推理参数、记录性能指标的自由。有些模型行为在 API 上观察不到，只有落到自己的服务器上，你才能看到日志里每一次推理的耗时和显存变化。

3. 能对话不代表会干活：上下文、Token 与 Prompt 的工程化

3.1 Token 是第一层现实：为什么同样的请求贵一倍

很多人第一次用大模型时，对 Token 完全没有概念，直到看账单才傻眼。Token 是模型处理文本的基本单位，你可以大致理解为“片段”。英文里一个 Token 通常对应一个子词，中文则比较复杂，每个汉字大约可能是 0.6 到 2 个 Token 不等，具体要看分词策略。

Token 要计数的包括输入和输出两部分。特别容易忽略的是，历史对话记录也会被反复拼接进输入。所以多轮对话不是每轮独立计费，而是每轮都在增长输入长度，这是 Agent 类应用成本失控的常见原因。

我做的第一个管理 Token 的增删记谱是：请前先估算需求，不要动不动就“帮我分析这段 5000 字的文章”，你自己先要清楚它会产生多少 Token。模型上下文窗口只是一个上限，不是建议你用满。比如 DeepSeek 支持长上下文，看起来很美，但送进去的内容越多，单次请求耗时越长，出错率也可能越高。能用 2000 Token 解决的，就不要塞进 6000 Token。

3.2 上下文窗口：理解“记忆”的边界

上下文窗口（Context Window）是模型单次能接收的最大 Token 数。它决定了一棵树能长多高——树根是输入历史，树冠是回复。

DeepSeek 系列模型的上下文长度做到了相当大的尺寸，但实际应用中“能支持”和“用得好”是两回事。上下文窗口就像一个临时桌面，你收到的所有对话历史、参考文档、系统指令都会堆在上面，窗口满了之后，最早的内容会被挤下去。注意这不是简单“忘记”，而是根本不会参与后续计算。

我在做长文档问答时遇到的典型情况是：把一本手册全文丢给模型，开头部分的内容还能答对，读到中后段时，模型开始混淆早期关键细节。原因就是早期内容可能已经超出了有效注意范围，或者被大量无关文本稀释了注意力。解决方案不是继续加长上下文，而是对输入做分块、检索、摘要。这也就是 RAG（Retrieval-Augmented Generation，检索增强生成）思路的价值：不是把所有信息一次性给模型，而是每次只给与问题最相关的片段。

3.3 让模型的输出“听话”

学习 DeepSeek 过程中收获最大的一部分，是理解 Prompt 不是“聊天技巧”，而是一种对概率分布的控制手段。模型生成一个词，本质是从词汇表里按概率采样，Prompt 的作用就是通过上下文把概率分布引导到正确的区域。

要让输出可控，核心做法是把你的要求拆成“可检查”的指令，而不是寄希望于模型“心领神会”。比如：

• 明确格式：要求“输出 JSON，包含 title 和 content 两个字段”，而不是笼统说“整理成结构化数据”。
• 给出示例：Few-shot 示例比抽象描述更有效。你想让它按某种风格写摘要，就给它一个符合要求的样本。
• 限制自由发挥：把“你可以发挥”改成“不要编造，不知道就明确说不知道”。
• 用角色约束范围：一个系统角色设定，比每次对话时重复强调一百句“你是一个严谨的助手”更有效。

我还测试了结构化输出能力。让模型按 JSON Schema 返回结果，同时把可能出现的边界情况都规定清楚。实测下来，对于中等复杂度的信息抽取任务，规范化的提示词可以把格式错误的概率从三成降到一两成以内。如果还想继续压，那就要靠输出解析层做校验和重试——这是工程问题，不是单纯提示词能解决的。

3.4 “破甲”之类说法，其实都是在讨论引导词边界

热门搜索里经常能看到各种“破解”“无限制对话”的字眼，作为学习者没必要把精力消耗在这些旁门左道上，也不要指望通过奇技淫巧让模型变得“百无禁忌”。大模型的安全对齐是产品化的基本底线。你更应该关注的是怎么合法合规地把模型能力发挥在正经场景里：知识库问答、代码生成、文本结构化、内容摘要。这些是真正能产生业务价值的方向，也是社区里质量最高的教程集中的领域。

4. 从通用到专用：微调实战与私有化部署决策

4.1 先别急着微调：把提示工程和 RAG 榨干再说

很多人学会调用 API 之后，马上就想微调一个专属于自己的模型。我的忠告是：一段时间内，先不要。

微调，是对模型参数做进一步训练，让模型适应特定领域的数据分布。它是成本最高、风险最大、收益路径最长的手段。尤其是风险，其中最大的一个我很早踩过：我尝试用一小批客服对话数据微调一个模型，结果因为数据量太少而出现严重的过拟合现象——模型对训练集中的固定句式倒背如流，一遇到真实场景的新颖提问就答非所问。

先用提示工程。你给模型写清楚业务规则、输出格式、行为边界，成本为零。再上 RAG。你把公司文档和常见问题录成知识库，检索相关片段再交给模型回答，大部分“私域知识”问题都能解决。微调的价值主要在两个场景：风格和行为对齐，比如你必须让模型的回答口吻严格符合品牌调性；特定任务效果提升，比如让模型稳定输出某种复杂格式，而提示工程怎么都调不动。只有这些场景出现时，才需要认真考虑微调。

4.2 用 LoRA 做一次真正的小成本微调

如果判断下来确实要微调，用 LoRA 而不是全参微调，这是目前开源社区的主流做法。

LoRA 的原理相当于冻结原有模型的全部权重，然后在每一层旁边加一个小型的低秩矩阵，只训练这些新增参数。用人体类比：原模型像你的固有肌肉，LoRA 像是给肌肉加了一对轻量外骨骼，它不改变肌肉本身，只改变发力方式。训练参数量极少，内存占用比全参微调低一个数量级，并且实验效果在很多任务上与全参微调相当接近。

实操层面，我用的是 LLaMA-Factory 这套框架。数据准备成 JSON 格式，每条样本包含 instruction、input、output 字段。训练时关键参数有：learning rate，LoRA 任务常用 1e-4 到 2e-4；训练轮数，小数据集 3 到 5 轮足够，再多就容易过拟合；LoRA rank，通常 8 到 16 起步，更大并不一定更好；目标模块，一般对 attention 层的 query、value 矩阵做适配，不同基座模型略有差异。

训练完成后得到的是一个适配器（adapter）文件，不是完整模型。使用时要把它与基座模型叠加加载。这个设计很优雅，意味着你可以准备好几个适配器对应不同业务，推理时按需切换，不用重复保存完整模型。

训练过程中记录 loss 曲线是一个好习惯。loss 下降而不稳就适当减小学习率或调大 batch，loss 降到平台期还继续训练就提防过拟合。微调之后务必拿一份“干净”的验证集来测，数据里不能包含训练样本，否则你看不到真实泛化能力。

4.3 企业场景下的私有化部署要点

搜“企业大模型私有化部署”的人很多，这里有几个我实际做过的关键判断。

私有化部署的第一驱动力是数据主权。客户数据、代码资产、内部文档不能出网，这是很多行业不可逾越的红线。其次是可控性和成本，长期持有内部模型可以消除按量计费的不确定性，同时也方便与内部系统深度集成。

部署方案通常要考虑：基础模型选型，7B 到 14B 级别，量化后一块主流专业显卡就能跑，适合一般业务；如果追求更强的综合能力，72B 以上级别需要多卡部署，成本和运维复杂度大幅上升。推理引擎选型，支持国产芯片推理的不在少数，但生态成熟度差异明显。外围设施同样不可忽视，模型网关、密钥管理、日志审计、监控告警。很多私有化项目模型本身跑得好好的，死在运维环节上。

部署之后还要做评测。不要只看一两个演示效果，要建立业务侧甘特图式的评测集，持续记录每次迭代前后的评分变化。评测跑分不完全等同于业务满意度，但至少提供了一条可追踪的基线。

5. 让模型进入业务流：Function Calling、Agent 与工具链接入

5.1 代码与数据接入：DeepSeek 的工程接口能力

学习到这一步，一个重要的认知转折点出现了：大模型的价值不在“聊天聊得好”，而在能成为系统中的一个组件，执行可编程的决策。

DeepSeek 的 API 支持函数调用，即 Function Calling。你可以先告诉模型有哪些工具可用，比如“查询天气”“创建订单”，并描述每个工具的参数格式，模型在需要时会输出一个结构化的调用指令，而不是一段自然语言。由此，你的程序收到调用指令后执行真实函数，再把函数结果返回给模型继续对话，从而完成一次“模型发号施令、系统执行任务”的闭环。

我用这个能力做了一个简单的内部知识库问答机器人，效果出乎意料地好。核心链路是：用户提问，在向量数据库中检索候选文档，把候选文档片段与用户问题拼接成 Prompt，发给 DeepSeek 生成答案，同时在 Prompt 中明确要求“只依据提供的文档回答，文档中没有信息就明确说不知道”。这样构造的系统既有模型的语言理解能力，又有文档库的精确信息源，还规避了模型凭空编造知识的风险。

5.2 用 Dify 编排一套零代码智能体

如果你不想从零手写编排逻辑，Dify 这类开源 LLMOps 平台是很好的中间层。它可以连接向量数据库、编排 Prompt 流程、配置工具，然后把 DeepSeek API 或本地模型接进去。

我在 Dify 里创建了一个知识库应用，把若干份 FAQ 文档灌入，选择嵌入模型做向量化，再选择 DeepSeek 作为生成模型。界面操作本身不难，难的是理解每一步背后在干什么。比如设置“检索召回条数”时，你要明白召回太多会稀释关联性，召回太少可能找不到答案；设置“相似度阈值”时，你是在判断“文档片段到底跟问题够不够相关”。

Dify 的另一个作用是可视化调试。你可以在中间步骤看到模型输入的完整 Prompt、检索召回的片段以及最终回复，这样定位出错点就变得很直接。这在纯代码方案里反而要多花不少时间。之前遇到“模型答案引用了知识库不存在的内容”这类问题，我在 Dify 里一眼就能看出那是因为检索阈值设置过低，把不相关文档也塞给了模型。

5.3 AI Agent 不只是聊天：计划拆解与工具调用

Agent（智能体）是当前最热的话题之一。实际落地中，我看过的 Agent 多半是两个东西的组合：第一步，把复杂任务拆解成多个子步骤；第二步，每个子步骤调用合适的工具执行。模型本身不是执行者，它更像一个调度中枢。

比如一个“合同风险摘要助手”，它需要先读合同全文，拆分成条款，检查其中有没有自定义的敏感词汇，再把风险点汇总输出。这背后就是多次模型调用和工具调用的组合。你要做的工程是清晰定义每一步的输入输出格式、错误处理策略以及步骤之间的衔接。

核心难点不在“让模型变聪明”，而在“让系统在你需要的时候及时刹车”。模型可能编出根本不存在的工具返回结果，你要在代码层校验函数返回值；模型可能陷入循环调用同一个工具，你要设置最大调用次数；模型可能返回你不能解析的内容，你要设计好重试和兜底逻辑。这些才是 Agent 工程化的核心。

6. 避坑实录：我在 DeepSeek 学习中最常见的八个问题

6.1 部署与调用类问题速查表

OOM 是我在本地部署时最常遇到的问题。7B 模型听起来不大，但你以为“7B 就是 7GB”就错了。权重文件是一个因素，推理时还要加载全部层间状态和注意力缓存。跑一个大数据量的上下文请求，显存峰值可能比静态加载模型时高出好几 GB。

6.2 模型行为类问题

模型“一本正经地胡说八道”是所有人都绕不开的问题。原因在于语言模型本身不是事实数据库，它的训练目标是在给定上下文后预测最合理的下一个词，推理过程也不验证事实真伪。你问一个它没见过的冷门问题，它更可能生成一个“听起来合理”的编造答案，这是概率分布的自然结果，并非它故意说谎。

温度参数是操控随机性的核心旋钮。写作创意场景可以调高到 0.9 以上，事实问答和代码生成直接调到 0.1 以下，甚至接近 0，让采样策略趋向确定性输出。这一个小改动，往往比换一个大模型对准确率的影响更明显。

上下文被“越界内容”污染的另一个常见情况是：你不小心在参考资料里混入了和问题无关的营销文案，模型也照单全收，并把其中的话术当作事实。所以，给模型喂什么内容，要完全由你控制，不然它输出会学得很奇怪。

另外我建议给每一个消费模型的上层应用增加日志记录。模型返回的内容原样落盘，Prompt 原样落盘，检索结果也原样落盘。这能让你在模型行为不符合预期时回溯问题，找到是哪一段 Prompt 在起作用，而不是靠猜。

7. 沿着这条路继续走：后续学习再往里挖四个方向

如果你想继续深入，我认为可以从四个方向里选一个：

一是 RAG 的工程优化。这包括切分粒度的选择：按标题层级切分、按固定字数切分、按语义切分，各有优劣；向量维度与检索算法的选择；重排序模型的引入；混合检索（关键词加向量）的实战。最终目标是让检索出来的片段总是与问题高度相关。

二是模型量化的数学原理。你不需要自己发明量化算法，但当你看到 q4_K_M、q8_0、AWQ 这些命名时，至少要明白它们分别对应什么精度和性能损失。课程资料方面，可以搜索“大模型量化原理”，跟着做一遍量化再评估效果差异。

三是 Agent 多工具调度的设计模式。怎么写工具描述，模型更容易调用正确；遇到多个工具可选时怎么让模型优先选择最优解；循环任务里设置什么样的终止条件。这些经验需要大量实操，社区仓库的智能体项目代码就是非常好的学习素材，但一定要亲手改一遍，理解它每一步为什么这么设计。

四是模型评测体系的搭建。给自己要用的模型做一个带准确率分数的评测集，覆盖业务中的典型问题，每次修改 Prompt 或微调参数后都跑一遍评测，用数据指导决策，而不是靠“感觉”。

个人建议，不要同时学所有方向。我在这些方向上，每次只深挖一个，因为每个方向都是负担不小的工程实践。一次只霸占一个坑，反而进展更快。

8. 几点最想对刚开始接触大模型的人说的话

整个学习过程走下来，我发现一个残酷的规律：二十个看教程的人里，可能只有一个把模型真正落地到了一个能用的小项目里。差距不是天赋，也不是硬件条件，而是能不能忍住“一直看、一直收藏、从来不写代码”的冲动。

从最小的闭环开始。先调通 API，再部署本地模型，再做一个 RAG 机器人，再跑一次 LoRA 微调。每完成一个闭环，你对大模型的认知模型就自己升级一层。哪怕最终的产物只是把一个小模型部署在家中电脑上，用得很糙，也远比收藏一百份教程更有价值。

学习大模型不一定要买多贵的算力。DeepSeek 有多个规模的蒸馏小模型，我用 7B 级别的模型已经完成了不少有意思的实践。小模型适合学原理、做原型、验流程，等真需要高性能表现再考虑更大模型和更多预算。之前我分享过一篇“从零构建大模型”的阅读笔记，核心观点是：原理书上那些矩阵运算和反向传播如果你暂时没耐心啃，也强烈建议至少把 Transformer 的模块结构和训练阶段读明白。这些知识在未来调试模型时，会是最值得依靠的背景知识。

最后，在硬件的选择上，有两句实在话：NVIDIA 的 CUDA 生态在兼容性上确实省心，社区支持和工具链配合都是现成的；如果没有专业显卡，先用 CPU 跑 1.5B 或者 7B 的小模型体验全过程，也比什么都不做强。我最初跑 7B 模型就是靠 CPU 硬跑的，虽然生成速度慢得让人容易失去耐心，但它确保了我把部署链路的所有环节都走通了。后来的显卡，只是把速度提上去了而已。