尧图网页设计 
简介这是一份深度解读DeepSeek大模型技术的PDF专题资料聚焦V3、R1与Janus-Pro系列模型主要面向算法工程师、AI学习者和对大模型技术演进感兴趣的从业者。内容以模型架构与训练效率为主线系统梳理了MoE混合专家架构、MLA潜注意力机制、无辅助损失的负载均衡策略、节点限制路由、MTP多token预测、DualPipe跨节点通信以及FP8混合精度训练等关键创新并结合模型参数、KV缓存压缩、通信开销优化等细节帮助读者理解DeepSeek为何被称为“大模型界的拼多多”以及它是如何以较低成本逼近闭源模型性能的。资源为单个PDF文件大小约8.04MB内文以图文结合方式呈现模块划分清楚便于按章节定位查阅也适合作为技术笔记或面试复习提纲。目前已有183人学习下载对于希望深入掌握开源大模型工程优化方法、提升对前沿架构认知的读者具有不错的参考价值。1. DeepSeek V3、R1、Janus-Pro为什么三份报告要放在一起读2024 年底DeepSeek 连着放了三份技术报告V3 的 671B MoE 模型、R1 的强化学习推理模型、Janus-Pro 的多模态生成模型。把它们分别当成“开源大参数”“会写思考过程的模型”“文生图 demo”来读等于只看了结论。三份报告是同一套工程哲学的三个投影数据质量优先、训练成本可控、推理省显存。V3 用 MLA 和 DeepSeekMoE 压低训练推理成本R1 用规则奖励加 GRPO 验证不靠人工标注也能长出推理Janus-Pro 拆解视觉理解与生成的编码器冲突。下文按主线拆开架构怎么选、训练管线怎么排、部署要什么配置、调 API 时哪些参数会被忽略。2. DeepSeek V3 架构拆解MLA 注意力、256 专家 MoE 与 MTPV3 总参数量 671B但每个 token 只激活 37B这个数字决定了部署时的显存上限也决定了它敢把模型权重开源。要做到“激活少、效果不缩水”V3 在三个点上做了和主流开源模型不一样的选择注意力换成 MLAFFN 换成细粒度 MoE 加共享专家训练目标里加一道多 Token 预测。三个选择互相咬合下面逐个拆。2.1 MLA 把 KV 缓存压到多小多头潜在注意力的设计标准 MHA 在处理长上下文时的痛点是 KV 缓存随层数和头数线性膨胀。一个 70B 级稠密模型在 128K 上下文下KV cache 轻松吃掉几十 GB这还没算中间激活值。vLLM 这类框架花大力气做 PagedAttention、KV 量化本质都是在和这个乘法关系搏斗。MLA 的思路是不要为每个头都存一份完整的 K 和 V而是把所有头共享的信息先压到一个低维潜在向量里用的时候再临时展开。V3 里 kv_lora_rank 是 512q_lora_rank 是 1536解码时真正要缓存的是这个 512 维潜在向量加一份位置相关的 RoPE key。相比按 128 个头分别缓存缓存量可以降一个数量级。代价是权重结构不再是标准的 QKV 三件套decoding kernel 得专门写通用框架支持得晚。省显存和吃框架这是一笔明账推理系统团队要评估的是自己有没有能力维护这类 kernel而不是能不能复刻通用 attention 实现。从报告给出的配置表能直观看到 V3 的形状配置项值说明总参数 / 每 token 激活671B / 37B路由只挑必要专家Transformer 层数61前 3 层为稠密 FFN其余为 MoE注意力头数 / kv_lora_rank128 / 512MLA 潜向量维度 512路由专家 / 共享专家256 1每 token 激活 8 个路由专家专家中间维度2048细粒度小专家单个参数不大MTP 深度1多预测一个未来 token训练数据14.8T tokens中文、英文、代码混合2.2 DeepSeekMoEaux-loss-free 负载均衡与设备受限路由DeepSeekMoE 论文里就在推“细粒度专家”专家切得小、数量多路由组合更灵活。V3 把这条路推到 256 个路由专家加 1 个共享专家每个 token 通过 top-8 路由激活其中 8 个。共享专家保证所有 token 都有一份公共的稠密计算路径避免通用知识完全依赖路由路由专家负责把能力细分到不同领域。负载均衡是 MoE 训练里最烦的问题。传统做法是在 loss 里加一个 auxiliary loss谁的负载不均衡就罚谁。V3 报告明确说这条 aux-loss 路径会伤害模型质量。替代方案是在路由打分里加一个可学习的 bias 项路由得分等于 sigmoid(affinity) 加上 bias每个训练 step 根据专家实际收了多少 token 去调整 bias过载的专家 bias 下调欠载的上调。这样梯度不受负载均衡项污染模型质量保住负载也稳了。另一个容易被忽略的工程点是设备受限路由路由时限制每个 token 最多只能选到少数几台设备上的专家把 all-to-all 通信控制在可接受范围。这个设计在 8 卡、16 卡部署时比算法本身更影响吞吐。社区复现 V3 时踩得最多的坑也在这直接换卡数不重算专家分布通信立刻变成瓶颈。2.3 MTP 多 Token 预测训练时的正则项推理时的投机解码草稿MTP 模块是在主模型之上额外叠的一层 Transformer输入由主模型当前步的隐状态和下一个 token 的 embedding 拼接而成训练 loss 是主 loss 加一个带权重的 MTP loss。这个设计一鱼两吃训练阶段它相当于给模型一个更长的“预测视野”让表征更稳报告里各 benchmark 有稳定提升推理阶段 MTP 模块可以直接当投机解码的草稿模型用额外要加载的参数只有这一层 Transformer 的量级不需要再为 draft 模型单独腾显存。报告给的数据是约 1.8 倍解码加速对 R1 这种动不动输出几千 token 的推理模型尤其值钱。读配置时可以用一个几十行的脚本验证激活参数占比不需要下载完整 checkpointimport json # config.json 在 HF/ModelScope 仓库页直接下载只有几 KB cfg json.load(open(DeepSeek-V3/config.json)) hidden cfg[hidden_size] # 7168 ffn_inter cfg[moe_intermediate_size] # 2048 n_routed cfg[n_routed_experts] # 256 n_act cfg[num_experts_per_tok] # 8 n_shared cfg[n_shared_experts] # 1 mlp_params lambda n: hidden * ffn_inter * 2 * n act mlp_params(n_act n_shared) total mlp_params(n_routed n_shared) print(f每 token MoE 激活参数量: {act/1e9:.1f}B) print(fMoE 总参数量: {total/1e9:.1f}B) print(f路由激活占比: {act/total:.2%})这段脚本只用了 config.json 里 5 个字段。moe_intermediate_size是单个专家 FFN 的中间维度专家间没有共享权重所以一个 token 经过的 MLP 参数量是“激活专家数 × 前后两个投影矩阵”。跑出来的激活占比通常只有 3% 左右配合注意力部分的参数量就能解释为什么 671B 的模型单 token 前向只有 37B 的计算量。部署评估时把n_act改成 16 做敏感性分析能直接看出调大专家激活数对显存和吞吐的影响。提示DeepSeek-V3 和 R1 的开源协议是 MIT商用限制少但“能商用”不等于“能随便部署”671B 的权重体积和推理集群成本才是真正的门槛具体账在第 5 章。3. DeepSeek R1 的训练路线GRPO 强化学习、冷启动与四阶段管线R1 引爆讨论的不是成绩本身而是它证明了“推理能力可以从强化学习里长出来而不是只靠标注数据喂出来”。要理解这一点得从 R1-Zero 的实验说起官方团队故意做了个不加任何 SFT 冷启动的版本直接在 V3-Base 上跑强化学习看模型自己能变成什么样。3.1 R1-Zero 证明了一件事规则奖励能催生出反思行为R1-Zero 的奖励函数只有两条规则数学和代码题答案对了加分输出格式符合要求思考过程包在指定标签里加分。没有训练 reward model没有人类偏好数据。跑出来的结果是 AIME 2024 上 pass1 到 79.8%已经摸到顶尖推理模型的门槛而且训练过程中出现了报告里那个著名的“aha moment”模型在思考过程中用中文写“等等让我重新检查一下这一步”随后自己修正了错误路径。这不是谁设计的提示词是 RL 在“正确率”这个唯一信号下涌现出的自我修正行为。对做强化学习的团队来说这个实验的启示比 R1 本身的成绩更值钱规则奖励加组内对比的优化目标在小规模算力下也能催生大模型的长链推理。代价是 R1-Zero 的输出可读性差、中英混杂、格式不稳定所以 R1 才加了冷启动和两轮 SFT。3.2 GRPO 与 PPO 的差异省掉 Critic 模型的 Group BaselineR1 的强化学习用的是 GRPOGroup Relative Policy Optimization不是传统 RLHF 主流的 PPO。关键差异在 advantage 的计算PPO 需要一条和 policy 同尺寸的 value network 去估计每个 token 的价值训练显存和算力直接翻倍GRPO 对同一道题采样一组输出R1 实验里每个问题采 64 条直接用这一组输出的相对得分当 advantage把每条输出的奖励在组内做归一化减均值除标准差。没有 critic 模型训练显存省下一大块超参也少一组。组内归一化这个细节值得细想它天然把“难题”和“简单题”拉到同一尺度。简单题大家都对相对奖励趋近于零梯度贡献也小难题只有少数几条输出做对正确的那几条会拿到明显更高的 advantage。这比直接拿绝对奖励做优化更稳不容易让模型为了刷分只挑简单样本。实现上要注意GRPO 的奖励是整条输出序列共享的同一个 advantage 要摊到这条序列的每个 token 上这和 PPO 的 per-token advantage 处理方式不一样。R1 系列的开源矩阵如下部署选型基本就是看这张表模型底座训练方式适用场景R1-ZeroV3-Base纯 RL 规则奖励研究用途验证涌现行为R1V3-Base冷启动 SFT → 推理 RL → 拒绝采样 SFT → 全场景 RL满血推理对应 API 的 reasonerR1-Distill-Qwen-1.5B/7B/14B/32BQwen2.5只用 SFT 蒸馏 R1 输出单卡或小显存部署R1-Distill-Llama-8B/70BLlama-3.1只用 SFT 蒸馏 R1 输出单卡或小显存部署3.3 四阶段管线冷启动数据、拒绝采样与二次 RLR1 的四阶段顺序是有讲究的。第一阶段冷启动 SFT只用几千条人工整理过的长思维链样本目标不是教知识是教格式和语气思考过程放指定标签里最终答案放answer标签里语言统一成中文或英文不许自言自语。这一步先把 R1-Zero 的可读性问题压住。第二阶段是纯推理任务的 RL奖励还是规则奖励但加了语言一致性约束思考过程中非目标语言占比过高时扣分解决中英混杂。第三阶段用第二阶段训好的模型做拒绝采样把生成对且格式干净的样本挑出来凑出约 60 万条推理样本再混入 20 万条非推理样本写作、问答、翻译做 SFT防止模型只会在数学题上思考、丢了通用能力。第四阶段再跑一轮全场景 RL推理类继续用规则奖励通用类换成模型奖励——用 V3 当 judge 打分兼顾帮助性和安全性。四阶段的节奏可以概括为先用小数据定格式再用规则奖励猛攻推理然后拒绝采样补通用能力最后全场景对齐收尾。这个管线最大的工程价值是每阶段数据量都不大冷启动几千条、SFT 八十万条比从头攒几千万条人工思维链便宜得多。复现时最容易翻车的是第三阶段拒绝采样的阈值设太紧会丢掉多样性设太松会把错误推理重新灌回去。3.4 API 调用 deepseek-reasoner思维链与上下文缓存的行为差异官方 API 里deepseek-reasoner对应 R1deepseek-chat对应 V3两者走同一套 OpenAI 兼容接口。reasoner 的响应里多一个reasoning_content字段放思维链content放最终答案。调用时最常踩的坑是思维链太长默认 max_tokens 不够用答案被拦腰截断from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://api.deepseek.com, # 官方网关生产环境也可换方舟等兼容网关 ) resp client.chat.completions.create( modeldeepseek-reasoner, messages[{role: user, content: 证明根号2不是有理数并指出证明中用到的关键定理}], max_tokens4096, # 推理题建议给足答案截断时先看这个参数 ) msg resp.choices[0].message print(思维链:, msg.reasoning_content) print(最终答案:, msg.content)deepseek-reasoner的官方建议是不再额外设置 temperature 和 top_p保持默认即可deepseek-chat则通常建议 temperature 0.6、top_p 0.95。reasoner 的reasoning_content在命中上下文缓存时会是空值这是设计行为不是 bug排查时先确认是否命中缓存。高峰期官方网关偶尔返回“服务器繁忙”类错误生产接入要做指数退避重试并准备降级到 chat 模型或本地蒸馏版的兜底链路。API 定价改过几轮以官方计费文档页为准别按旧价格做成本模型。注意reasoning_content是官方文档里明确标注“可能调整”的字段业务代码不要把它当成稳定接口来解析格式。4. Janus-Pro 多模态模型双视觉编码器设计与文生图落地V3 和 R1 的讨论热度太高Janus-Pro 容易被忽略。它其实回答了一个更有普适性的问题多模态大模型里“理解”和“生成”两件事要不要共享同一个视觉编码器。Janus 系列的答案是不共享并为此付两套编码器的代价。4.1 视觉编码器冲突问题理解要语义生成要像素主流统一多模态模型的做法是视觉 encoder 提特征进 LLM理解任务直接在这些特征上接分类或问答头生成任务则把图像量化成离散 token。问题在于理解任务要的是高层语义生成任务要的是能无损重建回图像的细节两套目标对同一个 encoder 的中间表征要求互相打架特征太抽象重建就糊特征太像素级问答就抓不住语义。Janus-Pro 的解法是把两条路彻底拆开理解路径用 SigLIP-L 把 384×384 的图切成 24×24 共 576 个 patch token过 MLP 后拼进文本序列生成路径用独立的 VQ tokenizer下采样率 16和 LlamaGen 系同源把同一张图离散成 576 个码表索引。两套 tokenizer 各配一个投影层进 LLM 前合并。模型底座是同一个 DeepSeek-LLM但视觉侧完全解耦生成训练时梯度只走生成编码器不会反向污染理解路径。Janus 到 Janus-Pro 的升级差异可以看这张表配置JanusJanus-Pro-1BJanus-Pro-7BLLM 底座DeepSeek-LLM-1.5B1.5B 底座7B 底座理解视觉编码器SigLIP-LSigLIP-LSigLIP-L生成视觉编码器VQ 下采样 16VQ 下采样 16VQ 下采样 16图像分辨率384×384384×384384×384每幅图 token 数576 576576 576576 5764.2 三阶段训练预训练、对齐微调与统一微调Janus-Pro 的训练分成三个阶段顺序比数据量更重要。第一阶段预训练用海量图文对把两套投影层和生成侧的 head 训出来LLM 主干基本冻结第二阶段对齐微调用图文指令数据让模型学会“跟着 prompt 画”和“看图回答”第三阶段统一微调混入多模态指令数据做整体调优。前作 Janus 的问题之一是在训练早期就让生成和理解的梯度互相干扰Janus-Pro 把生成训练整体往后放训练数据规模也扩到近亿量级7B 版在手绘指令遵循和图文问答上都明显超过 1B 版。局限也明确输出分辨率锁死在 384×384没有上采样或放大模块生成的图经不起放大看复杂文字渲染、多人物空间关系仍然会翻车。它更适合做“能边看边画”的助手型产品而不是生产级出图管线。产品要出 1024×1024 的图正确姿势是拿 Janus-Pro 做草图或角色一致性参考再接 Stable Diffusion 系的超分模型。4.3 本地跑文生图transformers 的 trust_remote_code 姿势Janus-Pro 的模型代码在 transformers 主线之外加载必须开trust_remote_codeTrue。推理流程和普通 VLM 不一样生成结束拿到的不是文本而是图像 token要交给 processor 的decode_image还原成 PIL 图像from transformers import AutoModelForCausalLM, AutoProcessor import torch model_id deepseek-ai/Janus-Pro-7B model AutoModelForCausalLM.from_pretrained( model_id, trust_remote_codeTrue, torch_dtypetorch.bfloat16 ).cuda() processor AutoProcessor.from_pretrained(model_id, trust_remote_codeTrue) conversation [ {role: user, content: 一只戴红围巾的柴犬站在雪地里写实风格} ] inputs processor(conversationsconversation, imagesNone, return_tensorspt).to(model.device) out model.generate(**inputs, max_new_tokens576, do_sampleFalse) # 576 24×24 图像 token img_tokens out[0, inputs.input_ids.shape[1]:] image processor.decode_image(img_tokens, model) image.save(janus_dog.png)max_new_tokens至少要给 576因为一张 384×384 的图就是 24×24 个 code给少了生成结果会被截成残图。do_sampleFalse保证同一 prompt 输出可复现批量评测时建议固定。想同时输入图片做视觉问答把图片路径列表传给images参数即可processor 会自动走 SigLIP 的理解路径与生成路径分流。bf16 需要 Ampere 架构以上的显卡1B 版 6GB 显存能跑7B 版建议 16GB 以上。模型权重在 HuggingFace 和 ModelScope 都有分发国内下载优先走 ModelScope省掉不少网络问题。5. 本地部署 DeepSeek V3 与 R1 蒸馏版显存估算、vLLM 参数与接入配置满血版 V3/R1 本地部署是集群级工程个人开发者不要轻易尝试蒸馏版则一张消费卡就能跑出可用的推理体验。这一章先把显存账算清楚再给 vLLM 的可抄配置。5.1 先算账671B 参数在不同精度下的显存需求权重大小等于参数量乘以每个参数的字节数这是部署一切大模型的第一步。671B 参数在 BF16 下是 1.34TBFP8 下约 671GBINT4/AWQ 下约 370GB。KV cache 和激活值还要在权重之外另算。8 张 80GB 的卡一共 640GB跑 FP8 的满血版属于压线状态几乎没有余量batch 稍微放大就 OOM。所以社区里“8 卡跑满血 V3”的真实体验是能起服务并发和上下文都得省着用。精度每参数字节671B 权重体积现实部署条件BF162~1.34 TB16×80GB 或更高FP81~671 GB8×80GB 压线KV 余量小INT4/AWQ~0.55~370 GB8×80GB 宽松仍需多卡Q4_K_M14B 蒸馏版~0.6~9 GB单卡 12GB 可跑选型建议分三档有 8 卡 H 系列集群的团队跑 FP8 满血版并接受低并发只有单卡 24GB 的跑 R1-Distill-Qwen-14B 或 32B 量化版完全不想管 GPU 的直接用 API。1.5B 蒸馏版虽然能跑但幻觉和语言质量明显下降做生产前先测一轮再决定。5.2 vLLM 起服务最小参数和 OpenAI 兼容调用vLLM 官方模型列表已经支持 DeepSeek-V3 和 R1但对蒸馏版的支持最成熟。以下配置以两张 24GB 卡跑 R1-Distill-Qwen-14B 为例python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-14B \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --served-model-name r1-14b \ --port 8000起服务后用 curl 发一个聊天补全请求验证连通性。注意model字段要写--served-model-name里定义的别名不是 HuggingFace 仓库名temperature和top_p走 OpenAI 兼容协议的常规语义蒸馏版推理时可以按官方 V3 的推荐值设。curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:r1-14b,messages:[{role:user,content:用动态规划解爬楼梯问题并分析复杂度}],max_tokens:2048,temperature:0.6,top_p:0.95}关键参数的含义和调法参数作用遇到问题怎么改--tensor-parallel-size张量并行卡数需能整除注意力头数显存不够就加卡别盲目加并行度--max-model-len最大上下文直接决定 KV cache 上限思维链长至少 16K 起--gpu-memory-utilization显存占用上限默认 0.9OOM 就降到 0.85--enforce-eager关闭 CUDA graph 预分配小显存爆 OOM 时打开代价是变慢--served-model-name对外暴露的模型名客户端和服务端约定一致即可单卡小显存场景常用 Ollama 和 llama.cpp命令差别不大llama-server -m DeepSeek-R1-Distill-Qwen-14B-Q4_K_M.gguf -ngl 99 --ctx-size 16384 --port 8080llama.cpp 的-ngl 99表示把能放 GPU 的层全放上去--ctx-size控制上下文长度16K 对大多数推理题够用。GGUF 量化版和官方 BF16 的差距主要在低比特下的事实性细节推理链路本身的体验差距不大。5.3 接入 Codex、VSCode 与方舟网关环境变量三板斧DeepSeek 官方提供两种兼容接口OpenAI 兼容的https://api.deepseek.com以及 Anthropic 兼容的https://api.deepseek.com/anthropic后者让 Claude Code 这类原本绑定 Anthropic API 的工具可以直接切换。国内生产环境也常用火山引擎方舟网关base_url 为https://ark.cn-beijing.volces.com/api/v3。# OpenAI 兼容工具Codex CLI、Cline、Continue 都读这套 export OPENAI_API_KEYsk-你的key export OPENAI_BASE_URLhttps://api.deepseek.com # Anthropic 兼容工具Claude Code 官方给出的接入方式 export ANTHROPIC_BASE_URLhttps://api.deepseek.com/anthropic export ANTHROPIC_AUTH_TOKENsk-你的key # 方舟网关需要先在控制台开通对应模型拿到 endpoint id export OPENAI_BASE_URLhttps://ark.cn-beijing.volces.com/api/v3 export OPENAI_API_KEYark-你的key不同工具对环境变量的字段名略有差异有的读baseUrl有的读base_url接入时以工具文档为准社区里 ccswitch 这类配置切换工具本质上也是把 provider 指到这些 base_url 上。方舟要先开通模型并关联 endpointendpoint id 形如ep-20250xxx作为 model 名传给客户端。生产接入要加超时、重试和熔断官方网关高峰期有概率返回 503业务侧必须有降级路径。6. 验证 R1 推理质量的三个技巧思维链观测、超参与评测 harness满血版和蒸馏版都跑起来之后真正花时间的是“怎么判断它是不是真的会”。单次回答的观感会骗人下面三个技巧是验证推理质量时最常用的做法。6.1 用 reasoning_content 判断是不是在假思考API 返回里reasoning_content为空常见原因是命中了上下文缓存这是设计行为但如果 system prompt 写得很长缓存命中率会明显下降排查时可以先在纯 user 消息下做对照。另一个容易混淆的场景是本地 vLLM 部署蒸馏版蒸馏模型的思考过程直接混在content里输出格式不稳定这时要自己解析思维链标签把思考内容单独存日志再分析别拿原始输出直接上评测。6.2 超参的真实作用temperature 与 max_tokens 的边界对deepseek-chatV3temperature 0.6、top_p 0.95 是官方推荐值代码生成可以降到 0.3 以下创意写作再往上拉。对deepseek-reasoner官方明确不建议设置 temperature 和 top_p设置了也不会实质影响推理过程。max_tokens是另一个坑R1 的思维链经常写到几千 token默认值偏小时finish_reason会停在length上看起来像模型不会做其实是输出被截断。凡是推理题答案戛然而止先看usage.completion_tokens再决定要不要扩max_tokens。6.3 写一个 30 行的评测 harness 做 passn 对比要区分“模型不会”和“采样不稳”单次评测不够。自己写一个极简评测 harness对同一组问题采样多个答案统计通过率import openai client openai.OpenAI(api_keysk-xxx, base_urlhttps://api.deepseek.com) def pass_at_n(model, question, answer, n5, max_tokens4096): hit 0 for _ in range(n): r client.chat.completions.create( modelmodel, max_tokensmax_tokens, temperature0.8, messages[{role: user, content: f{question}\n最终答案只写数字。}], ) if r.choices[0].message.content.strip().endswith(answer): hit 1 return hit / n print(pass_at_n(deepseek-chat, 17×23?, 391)) print(pass_at_n(r1-14b, 17×23?, 391))评测时固定 temperature、max_tokens 和 prompt 模板任何一项变了结论都不可比endswith这种解析方式只对“只写数字”的约束有效复杂题要换成正则提取answer标签。用同一批题对比满血 API 和本地蒸馏版的 passn能直接量化蒸馏损失比看几条样例可靠得多。把 temperature 拉到 0.8、max_tokens 扩到 8K再跑一遍刚才被截断的题如果reasoning_content里开始出现自我修正说明问题在采样参数不在模型。本文还有配套的精品资源点击获取 DeepSeek V3/R1/Janus-Pro技术全解析：MoE架构、GRPO与部署实践
简介这是一份深度解读DeepSeek大模型技术的PDF专题资料聚焦V3、R1与Janus-Pro系列模型主要面向算法工程师、AI学习者和对大模型技术演进感兴趣的从业者。内容以模型架构与训练效率为主线系统梳理了MoE混合专家架构、MLA潜注意力机制、无辅助损失的负载均衡策略、节点限制路由、MTP多token预测、DualPipe跨节点通信以及FP8混合精度训练等关键创新并结合模型参数、KV缓存压缩、通信开销优化等细节帮助读者理解DeepSeek为何被称为“大模型界的拼多多”以及它是如何以较低成本逼近闭源模型性能的。资源为单个PDF文件大小约8.04MB内文以图文结合方式呈现模块划分清楚便于按章节定位查阅也适合作为技术笔记或面试复习提纲。目前已有183人学习下载对于希望深入掌握开源大模型工程优化方法、提升对前沿架构认知的读者具有不错的参考价值。1. DeepSeek V3、R1、Janus-Pro为什么三份报告要放在一起读2024 年底DeepSeek 连着放了三份技术报告V3 的 671B MoE 模型、R1 的强化学习推理模型、Janus-Pro 的多模态生成模型。把它们分别当成“开源大参数”“会写思考过程的模型”“文生图 demo”来读等于只看了结论。三份报告是同一套工程哲学的三个投影数据质量优先、训练成本可控、推理省显存。V3 用 MLA 和 DeepSeekMoE 压低训练推理成本R1 用规则奖励加 GRPO 验证不靠人工标注也能长出推理Janus-Pro 拆解视觉理解与生成的编码器冲突。下文按主线拆开架构怎么选、训练管线怎么排、部署要什么配置、调 API 时哪些参数会被忽略。2. DeepSeek V3 架构拆解MLA 注意力、256 专家 MoE 与 MTPV3 总参数量 671B但每个 token 只激活 37B这个数字决定了部署时的显存上限也决定了它敢把模型权重开源。要做到“激活少、效果不缩水”V3 在三个点上做了和主流开源模型不一样的选择注意力换成 MLAFFN 换成细粒度 MoE 加共享专家训练目标里加一道多 Token 预测。三个选择互相咬合下面逐个拆。2.1 MLA 把 KV 缓存压到多小多头潜在注意力的设计标准 MHA 在处理长上下文时的痛点是 KV 缓存随层数和头数线性膨胀。一个 70B 级稠密模型在 128K 上下文下KV cache 轻松吃掉几十 GB这还没算中间激活值。vLLM 这类框架花大力气做 PagedAttention、KV 量化本质都是在和这个乘法关系搏斗。MLA 的思路是不要为每个头都存一份完整的 K 和 V而是把所有头共享的信息先压到一个低维潜在向量里用的时候再临时展开。V3 里 kv_lora_rank 是 512q_lora_rank 是 1536解码时真正要缓存的是这个 512 维潜在向量加一份位置相关的 RoPE key。相比按 128 个头分别缓存缓存量可以降一个数量级。代价是权重结构不再是标准的 QKV 三件套decoding kernel 得专门写通用框架支持得晚。省显存和吃框架这是一笔明账推理系统团队要评估的是自己有没有能力维护这类 kernel而不是能不能复刻通用 attention 实现。从报告给出的配置表能直观看到 V3 的形状配置项值说明总参数 / 每 token 激活671B / 37B路由只挑必要专家Transformer 层数61前 3 层为稠密 FFN其余为 MoE注意力头数 / kv_lora_rank128 / 512MLA 潜向量维度 512路由专家 / 共享专家256 1每 token 激活 8 个路由专家专家中间维度2048细粒度小专家单个参数不大MTP 深度1多预测一个未来 token训练数据14.8T tokens中文、英文、代码混合2.2 DeepSeekMoEaux-loss-free 负载均衡与设备受限路由DeepSeekMoE 论文里就在推“细粒度专家”专家切得小、数量多路由组合更灵活。V3 把这条路推到 256 个路由专家加 1 个共享专家每个 token 通过 top-8 路由激活其中 8 个。共享专家保证所有 token 都有一份公共的稠密计算路径避免通用知识完全依赖路由路由专家负责把能力细分到不同领域。负载均衡是 MoE 训练里最烦的问题。传统做法是在 loss 里加一个 auxiliary loss谁的负载不均衡就罚谁。V3 报告明确说这条 aux-loss 路径会伤害模型质量。替代方案是在路由打分里加一个可学习的 bias 项路由得分等于 sigmoid(affinity) 加上 bias每个训练 step 根据专家实际收了多少 token 去调整 bias过载的专家 bias 下调欠载的上调。这样梯度不受负载均衡项污染模型质量保住负载也稳了。另一个容易被忽略的工程点是设备受限路由路由时限制每个 token 最多只能选到少数几台设备上的专家把 all-to-all 通信控制在可接受范围。这个设计在 8 卡、16 卡部署时比算法本身更影响吞吐。社区复现 V3 时踩得最多的坑也在这直接换卡数不重算专家分布通信立刻变成瓶颈。2.3 MTP 多 Token 预测训练时的正则项推理时的投机解码草稿MTP 模块是在主模型之上额外叠的一层 Transformer输入由主模型当前步的隐状态和下一个 token 的 embedding 拼接而成训练 loss 是主 loss 加一个带权重的 MTP loss。这个设计一鱼两吃训练阶段它相当于给模型一个更长的“预测视野”让表征更稳报告里各 benchmark 有稳定提升推理阶段 MTP 模块可以直接当投机解码的草稿模型用额外要加载的参数只有这一层 Transformer 的量级不需要再为 draft 模型单独腾显存。报告给的数据是约 1.8 倍解码加速对 R1 这种动不动输出几千 token 的推理模型尤其值钱。读配置时可以用一个几十行的脚本验证激活参数占比不需要下载完整 checkpointimport json # config.json 在 HF/ModelScope 仓库页直接下载只有几 KB cfg json.load(open(DeepSeek-V3/config.json)) hidden cfg[hidden_size] # 7168 ffn_inter cfg[moe_intermediate_size] # 2048 n_routed cfg[n_routed_experts] # 256 n_act cfg[num_experts_per_tok] # 8 n_shared cfg[n_shared_experts] # 1 mlp_params lambda n: hidden * ffn_inter * 2 * n act mlp_params(n_act n_shared) total mlp_params(n_routed n_shared) print(f每 token MoE 激活参数量: {act/1e9:.1f}B) print(fMoE 总参数量: {total/1e9:.1f}B) print(f路由激活占比: {act/total:.2%})这段脚本只用了 config.json 里 5 个字段。moe_intermediate_size是单个专家 FFN 的中间维度专家间没有共享权重所以一个 token 经过的 MLP 参数量是“激活专家数 × 前后两个投影矩阵”。跑出来的激活占比通常只有 3% 左右配合注意力部分的参数量就能解释为什么 671B 的模型单 token 前向只有 37B 的计算量。部署评估时把n_act改成 16 做敏感性分析能直接看出调大专家激活数对显存和吞吐的影响。提示DeepSeek-V3 和 R1 的开源协议是 MIT商用限制少但“能商用”不等于“能随便部署”671B 的权重体积和推理集群成本才是真正的门槛具体账在第 5 章。3. DeepSeek R1 的训练路线GRPO 强化学习、冷启动与四阶段管线R1 引爆讨论的不是成绩本身而是它证明了“推理能力可以从强化学习里长出来而不是只靠标注数据喂出来”。要理解这一点得从 R1-Zero 的实验说起官方团队故意做了个不加任何 SFT 冷启动的版本直接在 V3-Base 上跑强化学习看模型自己能变成什么样。3.1 R1-Zero 证明了一件事规则奖励能催生出反思行为R1-Zero 的奖励函数只有两条规则数学和代码题答案对了加分输出格式符合要求思考过程包在指定标签里加分。没有训练 reward model没有人类偏好数据。跑出来的结果是 AIME 2024 上 pass1 到 79.8%已经摸到顶尖推理模型的门槛而且训练过程中出现了报告里那个著名的“aha moment”模型在思考过程中用中文写“等等让我重新检查一下这一步”随后自己修正了错误路径。这不是谁设计的提示词是 RL 在“正确率”这个唯一信号下涌现出的自我修正行为。对做强化学习的团队来说这个实验的启示比 R1 本身的成绩更值钱规则奖励加组内对比的优化目标在小规模算力下也能催生大模型的长链推理。代价是 R1-Zero 的输出可读性差、中英混杂、格式不稳定所以 R1 才加了冷启动和两轮 SFT。3.2 GRPO 与 PPO 的差异省掉 Critic 模型的 Group BaselineR1 的强化学习用的是 GRPOGroup Relative Policy Optimization不是传统 RLHF 主流的 PPO。关键差异在 advantage 的计算PPO 需要一条和 policy 同尺寸的 value network 去估计每个 token 的价值训练显存和算力直接翻倍GRPO 对同一道题采样一组输出R1 实验里每个问题采 64 条直接用这一组输出的相对得分当 advantage把每条输出的奖励在组内做归一化减均值除标准差。没有 critic 模型训练显存省下一大块超参也少一组。组内归一化这个细节值得细想它天然把“难题”和“简单题”拉到同一尺度。简单题大家都对相对奖励趋近于零梯度贡献也小难题只有少数几条输出做对正确的那几条会拿到明显更高的 advantage。这比直接拿绝对奖励做优化更稳不容易让模型为了刷分只挑简单样本。实现上要注意GRPO 的奖励是整条输出序列共享的同一个 advantage 要摊到这条序列的每个 token 上这和 PPO 的 per-token advantage 处理方式不一样。R1 系列的开源矩阵如下部署选型基本就是看这张表模型底座训练方式适用场景R1-ZeroV3-Base纯 RL 规则奖励研究用途验证涌现行为R1V3-Base冷启动 SFT → 推理 RL → 拒绝采样 SFT → 全场景 RL满血推理对应 API 的 reasonerR1-Distill-Qwen-1.5B/7B/14B/32BQwen2.5只用 SFT 蒸馏 R1 输出单卡或小显存部署R1-Distill-Llama-8B/70BLlama-3.1只用 SFT 蒸馏 R1 输出单卡或小显存部署3.3 四阶段管线冷启动数据、拒绝采样与二次 RLR1 的四阶段顺序是有讲究的。第一阶段冷启动 SFT只用几千条人工整理过的长思维链样本目标不是教知识是教格式和语气思考过程放指定标签里最终答案放answer标签里语言统一成中文或英文不许自言自语。这一步先把 R1-Zero 的可读性问题压住。第二阶段是纯推理任务的 RL奖励还是规则奖励但加了语言一致性约束思考过程中非目标语言占比过高时扣分解决中英混杂。第三阶段用第二阶段训好的模型做拒绝采样把生成对且格式干净的样本挑出来凑出约 60 万条推理样本再混入 20 万条非推理样本写作、问答、翻译做 SFT防止模型只会在数学题上思考、丢了通用能力。第四阶段再跑一轮全场景 RL推理类继续用规则奖励通用类换成模型奖励——用 V3 当 judge 打分兼顾帮助性和安全性。四阶段的节奏可以概括为先用小数据定格式再用规则奖励猛攻推理然后拒绝采样补通用能力最后全场景对齐收尾。这个管线最大的工程价值是每阶段数据量都不大冷启动几千条、SFT 八十万条比从头攒几千万条人工思维链便宜得多。复现时最容易翻车的是第三阶段拒绝采样的阈值设太紧会丢掉多样性设太松会把错误推理重新灌回去。3.4 API 调用 deepseek-reasoner思维链与上下文缓存的行为差异官方 API 里deepseek-reasoner对应 R1deepseek-chat对应 V3两者走同一套 OpenAI 兼容接口。reasoner 的响应里多一个reasoning_content字段放思维链content放最终答案。调用时最常踩的坑是思维链太长默认 max_tokens 不够用答案被拦腰截断from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://api.deepseek.com, # 官方网关生产环境也可换方舟等兼容网关 ) resp client.chat.completions.create( modeldeepseek-reasoner, messages[{role: user, content: 证明根号2不是有理数并指出证明中用到的关键定理}], max_tokens4096, # 推理题建议给足答案截断时先看这个参数 ) msg resp.choices[0].message print(思维链:, msg.reasoning_content) print(最终答案:, msg.content)deepseek-reasoner的官方建议是不再额外设置 temperature 和 top_p保持默认即可deepseek-chat则通常建议 temperature 0.6、top_p 0.95。reasoner 的reasoning_content在命中上下文缓存时会是空值这是设计行为不是 bug排查时先确认是否命中缓存。高峰期官方网关偶尔返回“服务器繁忙”类错误生产接入要做指数退避重试并准备降级到 chat 模型或本地蒸馏版的兜底链路。API 定价改过几轮以官方计费文档页为准别按旧价格做成本模型。注意reasoning_content是官方文档里明确标注“可能调整”的字段业务代码不要把它当成稳定接口来解析格式。4. Janus-Pro 多模态模型双视觉编码器设计与文生图落地V3 和 R1 的讨论热度太高Janus-Pro 容易被忽略。它其实回答了一个更有普适性的问题多模态大模型里“理解”和“生成”两件事要不要共享同一个视觉编码器。Janus 系列的答案是不共享并为此付两套编码器的代价。4.1 视觉编码器冲突问题理解要语义生成要像素主流统一多模态模型的做法是视觉 encoder 提特征进 LLM理解任务直接在这些特征上接分类或问答头生成任务则把图像量化成离散 token。问题在于理解任务要的是高层语义生成任务要的是能无损重建回图像的细节两套目标对同一个 encoder 的中间表征要求互相打架特征太抽象重建就糊特征太像素级问答就抓不住语义。Janus-Pro 的解法是把两条路彻底拆开理解路径用 SigLIP-L 把 384×384 的图切成 24×24 共 576 个 patch token过 MLP 后拼进文本序列生成路径用独立的 VQ tokenizer下采样率 16和 LlamaGen 系同源把同一张图离散成 576 个码表索引。两套 tokenizer 各配一个投影层进 LLM 前合并。模型底座是同一个 DeepSeek-LLM但视觉侧完全解耦生成训练时梯度只走生成编码器不会反向污染理解路径。Janus 到 Janus-Pro 的升级差异可以看这张表配置JanusJanus-Pro-1BJanus-Pro-7BLLM 底座DeepSeek-LLM-1.5B1.5B 底座7B 底座理解视觉编码器SigLIP-LSigLIP-LSigLIP-L生成视觉编码器VQ 下采样 16VQ 下采样 16VQ 下采样 16图像分辨率384×384384×384384×384每幅图 token 数576 576576 576576 5764.2 三阶段训练预训练、对齐微调与统一微调Janus-Pro 的训练分成三个阶段顺序比数据量更重要。第一阶段预训练用海量图文对把两套投影层和生成侧的 head 训出来LLM 主干基本冻结第二阶段对齐微调用图文指令数据让模型学会“跟着 prompt 画”和“看图回答”第三阶段统一微调混入多模态指令数据做整体调优。前作 Janus 的问题之一是在训练早期就让生成和理解的梯度互相干扰Janus-Pro 把生成训练整体往后放训练数据规模也扩到近亿量级7B 版在手绘指令遵循和图文问答上都明显超过 1B 版。局限也明确输出分辨率锁死在 384×384没有上采样或放大模块生成的图经不起放大看复杂文字渲染、多人物空间关系仍然会翻车。它更适合做“能边看边画”的助手型产品而不是生产级出图管线。产品要出 1024×1024 的图正确姿势是拿 Janus-Pro 做草图或角色一致性参考再接 Stable Diffusion 系的超分模型。4.3 本地跑文生图transformers 的 trust_remote_code 姿势Janus-Pro 的模型代码在 transformers 主线之外加载必须开trust_remote_codeTrue。推理流程和普通 VLM 不一样生成结束拿到的不是文本而是图像 token要交给 processor 的decode_image还原成 PIL 图像from transformers import AutoModelForCausalLM, AutoProcessor import torch model_id deepseek-ai/Janus-Pro-7B model AutoModelForCausalLM.from_pretrained( model_id, trust_remote_codeTrue, torch_dtypetorch.bfloat16 ).cuda() processor AutoProcessor.from_pretrained(model_id, trust_remote_codeTrue) conversation [ {role: user, content: 一只戴红围巾的柴犬站在雪地里写实风格} ] inputs processor(conversationsconversation, imagesNone, return_tensorspt).to(model.device) out model.generate(**inputs, max_new_tokens576, do_sampleFalse) # 576 24×24 图像 token img_tokens out[0, inputs.input_ids.shape[1]:] image processor.decode_image(img_tokens, model) image.save(janus_dog.png)max_new_tokens至少要给 576因为一张 384×384 的图就是 24×24 个 code给少了生成结果会被截成残图。do_sampleFalse保证同一 prompt 输出可复现批量评测时建议固定。想同时输入图片做视觉问答把图片路径列表传给images参数即可processor 会自动走 SigLIP 的理解路径与生成路径分流。bf16 需要 Ampere 架构以上的显卡1B 版 6GB 显存能跑7B 版建议 16GB 以上。模型权重在 HuggingFace 和 ModelScope 都有分发国内下载优先走 ModelScope省掉不少网络问题。5. 本地部署 DeepSeek V3 与 R1 蒸馏版显存估算、vLLM 参数与接入配置满血版 V3/R1 本地部署是集群级工程个人开发者不要轻易尝试蒸馏版则一张消费卡就能跑出可用的推理体验。这一章先把显存账算清楚再给 vLLM 的可抄配置。5.1 先算账671B 参数在不同精度下的显存需求权重大小等于参数量乘以每个参数的字节数这是部署一切大模型的第一步。671B 参数在 BF16 下是 1.34TBFP8 下约 671GBINT4/AWQ 下约 370GB。KV cache 和激活值还要在权重之外另算。8 张 80GB 的卡一共 640GB跑 FP8 的满血版属于压线状态几乎没有余量batch 稍微放大就 OOM。所以社区里“8 卡跑满血 V3”的真实体验是能起服务并发和上下文都得省着用。精度每参数字节671B 权重体积现实部署条件BF162~1.34 TB16×80GB 或更高FP81~671 GB8×80GB 压线KV 余量小INT4/AWQ~0.55~370 GB8×80GB 宽松仍需多卡Q4_K_M14B 蒸馏版~0.6~9 GB单卡 12GB 可跑选型建议分三档有 8 卡 H 系列集群的团队跑 FP8 满血版并接受低并发只有单卡 24GB 的跑 R1-Distill-Qwen-14B 或 32B 量化版完全不想管 GPU 的直接用 API。1.5B 蒸馏版虽然能跑但幻觉和语言质量明显下降做生产前先测一轮再决定。5.2 vLLM 起服务最小参数和 OpenAI 兼容调用vLLM 官方模型列表已经支持 DeepSeek-V3 和 R1但对蒸馏版的支持最成熟。以下配置以两张 24GB 卡跑 R1-Distill-Qwen-14B 为例python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-14B \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --served-model-name r1-14b \ --port 8000起服务后用 curl 发一个聊天补全请求验证连通性。注意model字段要写--served-model-name里定义的别名不是 HuggingFace 仓库名temperature和top_p走 OpenAI 兼容协议的常规语义蒸馏版推理时可以按官方 V3 的推荐值设。curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:r1-14b,messages:[{role:user,content:用动态规划解爬楼梯问题并分析复杂度}],max_tokens:2048,temperature:0.6,top_p:0.95}关键参数的含义和调法参数作用遇到问题怎么改--tensor-parallel-size张量并行卡数需能整除注意力头数显存不够就加卡别盲目加并行度--max-model-len最大上下文直接决定 KV cache 上限思维链长至少 16K 起--gpu-memory-utilization显存占用上限默认 0.9OOM 就降到 0.85--enforce-eager关闭 CUDA graph 预分配小显存爆 OOM 时打开代价是变慢--served-model-name对外暴露的模型名客户端和服务端约定一致即可单卡小显存场景常用 Ollama 和 llama.cpp命令差别不大llama-server -m DeepSeek-R1-Distill-Qwen-14B-Q4_K_M.gguf -ngl 99 --ctx-size 16384 --port 8080llama.cpp 的-ngl 99表示把能放 GPU 的层全放上去--ctx-size控制上下文长度16K 对大多数推理题够用。GGUF 量化版和官方 BF16 的差距主要在低比特下的事实性细节推理链路本身的体验差距不大。5.3 接入 Codex、VSCode 与方舟网关环境变量三板斧DeepSeek 官方提供两种兼容接口OpenAI 兼容的https://api.deepseek.com以及 Anthropic 兼容的https://api.deepseek.com/anthropic后者让 Claude Code 这类原本绑定 Anthropic API 的工具可以直接切换。国内生产环境也常用火山引擎方舟网关base_url 为https://ark.cn-beijing.volces.com/api/v3。# OpenAI 兼容工具Codex CLI、Cline、Continue 都读这套 export OPENAI_API_KEYsk-你的key export OPENAI_BASE_URLhttps://api.deepseek.com # Anthropic 兼容工具Claude Code 官方给出的接入方式 export ANTHROPIC_BASE_URLhttps://api.deepseek.com/anthropic export ANTHROPIC_AUTH_TOKENsk-你的key # 方舟网关需要先在控制台开通对应模型拿到 endpoint id export OPENAI_BASE_URLhttps://ark.cn-beijing.volces.com/api/v3 export OPENAI_API_KEYark-你的key不同工具对环境变量的字段名略有差异有的读baseUrl有的读base_url接入时以工具文档为准社区里 ccswitch 这类配置切换工具本质上也是把 provider 指到这些 base_url 上。方舟要先开通模型并关联 endpointendpoint id 形如ep-20250xxx作为 model 名传给客户端。生产接入要加超时、重试和熔断官方网关高峰期有概率返回 503业务侧必须有降级路径。6. 验证 R1 推理质量的三个技巧思维链观测、超参与评测 harness满血版和蒸馏版都跑起来之后真正花时间的是“怎么判断它是不是真的会”。单次回答的观感会骗人下面三个技巧是验证推理质量时最常用的做法。6.1 用 reasoning_content 判断是不是在假思考API 返回里reasoning_content为空常见原因是命中了上下文缓存这是设计行为但如果 system prompt 写得很长缓存命中率会明显下降排查时可以先在纯 user 消息下做对照。另一个容易混淆的场景是本地 vLLM 部署蒸馏版蒸馏模型的思考过程直接混在content里输出格式不稳定这时要自己解析思维链标签把思考内容单独存日志再分析别拿原始输出直接上评测。6.2 超参的真实作用temperature 与 max_tokens 的边界对deepseek-chatV3temperature 0.6、top_p 0.95 是官方推荐值代码生成可以降到 0.3 以下创意写作再往上拉。对deepseek-reasoner官方明确不建议设置 temperature 和 top_p设置了也不会实质影响推理过程。max_tokens是另一个坑R1 的思维链经常写到几千 token默认值偏小时finish_reason会停在length上看起来像模型不会做其实是输出被截断。凡是推理题答案戛然而止先看usage.completion_tokens再决定要不要扩max_tokens。6.3 写一个 30 行的评测 harness 做 passn 对比要区分“模型不会”和“采样不稳”单次评测不够。自己写一个极简评测 harness对同一组问题采样多个答案统计通过率import openai client openai.OpenAI(api_keysk-xxx, base_urlhttps://api.deepseek.com) def pass_at_n(model, question, answer, n5, max_tokens4096): hit 0 for _ in range(n): r client.chat.completions.create( modelmodel, max_tokensmax_tokens, temperature0.8, messages[{role: user, content: f{question}\n最终答案只写数字。}], ) if r.choices[0].message.content.strip().endswith(answer): hit 1 return hit / n print(pass_at_n(deepseek-chat, 17×23?, 391)) print(pass_at_n(r1-14b, 17×23?, 391))评测时固定 temperature、max_tokens 和 prompt 模板任何一项变了结论都不可比endswith这种解析方式只对“只写数字”的约束有效复杂题要换成正则提取answer标签。用同一批题对比满血 API 和本地蒸馏版的 passn能直接量化蒸馏损失比看几条样例可靠得多。把 temperature 拉到 0.8、max_tokens 扩到 8K再跑一遍刚才被截断的题如果reasoning_content里开始出现自我修正说明问题在采样参数不在模型。本文还有配套的精品资源点击获取