简介一份2025年华为出品的基于昇腾平台的DeepSeek V3/R1技术方案资料面向AI工程师、大模型应用开发者与关注国产算力路线的技术管理者。PDF共33页梳理DeepSeek公司背景与模型演进剖析V3和R1在MLA注意力机制、DeepSeekMOE稀疏架构、GRPO强化学习等方面的核心创新重点落在昇腾NPU上的部署方案、算力适配与训练推理优化并分析其对AI产业格局的影响。资源为单个PDF文件压缩包约4.5MB轻量便于直接阅读。目前已有605人学习。内容覆盖V3与R1在通用问答、复杂推理场景上的能力差异解释基于DeepSeek-R1蒸馏Qwen/Llama小模型、两阶段强化学习等具体技术路径也给出API成本、开源生态等对比适合作为理解大模型国产化落地方案与昇腾技术栈的参考材料。1. 昇腾跑 DeepSeek V3/R1从适配到上线只用了四周这份《2025华为基于华为昇腾的DeepSeek V3-R1方案》是一份内部技术分享 PPT 风格的方案文档讲的是 DeepSeek V3 和 R1 发布后华为昇腾团队如何在短短一个月内完成适配、上线云服务、支撑百万级用户调用的全过程。对做模型部署、算力平台或者私有化大模型落地的工程师来说它最有价值的地方不是「DeepSeek 有多强」这类背景话术而是三个具体的东西V3 的 MLA/MOE/MTP 到底怎么省算力、R1 的 GRPO 训练范式为什么比 PPO 简单一个量级、昇腾 A2 上用 W8A8 量化部署蒸馏模型的参数和性能实测数据。我拆完这份 33 页的材料挑出可以直接抄作业的技术参数和踩坑点整理成一篇实战笔记。适合两类人一类是正在昇腾或其他国产卡上部署 DeepSeek 系列模型的平台工程师另一类是想搞清楚 V3/R1 创新点内部逻辑、准备做二次训练或蒸馏的算法工程师。下文所有性能数据、量化方式和部署节奏均来自该文档不掺个人臆测。2. DeepSeek V3 的工程底牌MLA、MOE、MTP 到底省了什么2.1 MLA 多头潜在注意力把 KV 缓存压到 512 维V3 和 R1 共用同一套基础架构其中变化最大、也最值得先理解的是注意力机制的改动。传统多头注意力每个头都要保存独立的 K 和 V 矩阵长上下文下 KV 缓存是显存的大头。DeepSeek 的做法是把 K 和 V 联合压缩到一个低维潜空间向量——512 维然后 Queries 也做低维映射压缩到 1536 维旋转位置编码 RoPE 这类必需信息单独保留。这样做的好处按文档里的数据是KV 缓存占用内存降低约 90%。这意味着同样一张卡能支撑的并发请求数直接翻倍以上。文档里给出的结构对比也很明确业界同类模型用的是 GQA 或 MHA而 V3/R1 用的是 MLA配合 DeepSeekMoE 稀疏专家路由整体计算量减少约 35%。我理解这套设计的工程意图是「以计算换内存、降通信」——把 K/V 打进低维空间牺牲一点点理论精度上限换取显存和带宽的大幅释放。在推理场景里这个取舍非常划算因为推理瓶颈通常不在 FLOPs 而在显存带宽和容量。2.2 DeepSeekMoE 结构256 个专家选 8 个加 1 个共享专家V3 的 MoE 结构和传统 MoE 有明显差异。传统方案一般是 16 个专家选 2 个而 V3 是 256 个专家选 8 个外加 1 个共享专家。每个专家的 shape 做得比较小配合共享专家策略既保证模型容量够大又控制单次前向计算量。文档里给了一个关键数字专家数从 V1 的 128 个增加到 V3 的 256 个激活参数从 21B 增加到 37B但总参数从 236B 跳到 671B。也就是说671B 的总参数每次推理只激活 37B计算量大概是稠密 37B 模型的水平。这就是 MoE 的核心价值——用稀疏激活把「大模型」的成本拉回到「中等模型」的档位。注意文档里还点了一个传统 MoE 容易踩的坑多专家负载不均会影响端到端性能 10% 以上热点专家达到容量上限会丢弃 Token直接影响模型效果。DeepSeek 的解法是专家数量多 每个专家 shape 小 共享专家兜底让路由压力分散开。这个思路在自建 MoE 服务做负载均衡时同样适用——不要只依赖路由网络结构设计上就要给热点留缓冲。2.3 MTP 多 Token 预测从逐字生成到一次预测多个 TokenMTP 是 V3 里提升推理速度的关键手段但它的实现方式和很多人想象的「一步出多个 token」不一样。它的做法是让模型通过多个顺序模块一次性预测多个未来的 Token然后由大语言模型来判断小语言模型生成的 Token 是否正确概率高的保留概率低的由大模型重新生成。文档给出的效果数据训练阶段平均提升 2%~3%推理阶段采信率在 85%~90%单 Token 生成速度Tokens Per Second提升约 1.8 倍。主模型 61 层、671B 参数额外新增的 MTP 组件权重约 11.5B、激活 2.4B。这个激活量分摊到推理路径上代价很小收益却很直接。模块参数量激活量作用主模型671B37B核心生成能力MTP 组件11.5B2.4B多 Token 预测与校验我一般在部署场景里会把 MTP 当作默认开启项但注意它依赖模型本身的采信率。如果量化后采信率掉到 80% 以下MTP 带来的加速会被重新生成拉低这时候反而要把 MTP 关掉后面第 5 章详细讲。2.4 FP8 混合精度与 DualPipe训练成本降下来的关键组合V3 在训练侧有几个「第一次」业界首次在大规模 MoE 模型上使用 FP8 混合精度训练成功。文档里明确说在 V3 之前头部公司都在探索但没有公开成功案例。具体策略是计算密集型算子——前向传播、激活反向、权重反向——用 FP8 计算提速精度敏感型模块——向量层、输出层、门控模块、注意力模块——保持 BF16/FP32优化器动量用 BF16主要权重参数和梯度保持 FP32激活量化以 1×128per token per 128 channels分组缩放权重量化以 128×128 分组配套的 DualPipe 是双向流水线并行配合流水线重排实现计算与通信充分重叠减少了 50% 的 pipeline bubble流水线气泡。再加上跨节点 All2All 通信优化把集群网络拓扑和 MoE 路由算法结合Token 分发避免拥塞。策略计算密集型算子精度敏感型算子数据类型FP8BF16/FP32典型算子前向、激活反向、权重反向向量层、输出层、门控、注意力量化粒度激活 1×128、权重 128×128不量化FP8 混合精度的核心价值是训练成本文档里提到 V3 用 2048 张 H800、两个月完成训练训练效率是同类 MoE 的 1.5~2 倍。14.8 万亿 tokens 的数据量加上 FP8 加速这个成本结构让「2 个月训出顶级模型」成为可能。对于想在昇腾或其他国产卡上复现训练流程的团队FP8 和 BF16 混布的策略可以直接参考但注意卡间通信拓扑要跟上否则 DualPipe 的优势会被通信瓶颈吃掉。3. R1 的训练范式变化GRPO 把强化学习拉回「平民化」3.1 从 PPO 到 GRPO去掉 Value Model 和奖励模型R1 和 V3 的关系不是「新模型取代旧模型」而是 V3 经过强化学习后得到的推理增强版本。文档里的数据流图拆得很清楚V3 经过强化学习生成 R1-ZeroR1-Zero 经过冷启动 SFT 和强化学习生成正式版 R1同时通过蒸馏生成 Qwen 和 Llama 系列小模型。这里最关键的技术创新是 GRPO——组相对策略优化。传统 PPO 需要同时训练 Policy Model 和 Value Model两个模型联合收敛的难度很大而且 PPO 往往还需要过程奖励模型 PRM 和蒙特卡洛树搜索 MCTS 配合调优复杂度非常高。GRPO 的做法是只训练 Policy Model用一组采样结果的相对优劣来估计基线不需要 Value Model。文档里原话是「无过程奖励模型和 MCTS调优难度进一步减低」。这个变化的意义不是精度提升而是让强化学习训练从「只有大厂才玩得起」变成「有卡就能试」。对比项PPOGRPO需训练模型Policy Value 两个模型仅 Policy 模型奖励模型需要 PRM / 奖励模型无需过程奖励模型搜索策略常配合 MCTS无需 MCTS调优复杂度高明显降低3.2 R1 的两阶段训练流程冷启动、推理 RL、二阶段 SFT、全场景 RL文档给出了 R1 的完整训练全景分两条线第一条线是 R1-Zero只用强化学习训练没有 SFT也没有 PRM 和 MCTS。它的优点是能自我进化涌现出长链推理能力缺点是 Reasoning 过程可读性差中英文混杂不适合直接商用。文档评价它「未来可大规模 scaling 达到或超过 o1 水平」但现阶段只是技术验证。第二条线是正式版 R1走「冷启动 SFT → 推理 RL 阶段 → 二阶段 SFT → 全场景 RL 阶段」四步。冷启动 SFT 用 600K 高质量推理样本把模型先调出可读的推理格式再上强化学习。二阶段 SFT 的数据集 Model RL-1 产生的新的 COT 数据 V3 后训练阶段的非逻辑推理数据加非逻辑数据是为了防止灾难性遗忘——只拿纯推理数据微调会让模型把普通问答和内容生成能力丢掉。文档里给的数据R1 蒸馏用了 800K 条 COT 样本含 200K 非推理样本对 Qwen 和 Llama 系列小模型做 SFT显著增强了小模型推理能力。论文里还对比了小模型自己做 RL 和大模型蒸馏的效果结论是蒸馏远好过小模型自训 RL——这说明一个强大的 base model 是后续一切微调的地基。3.3 开源盘点开源了什么、闭源了什么文档对 DeepSeek 的开源策略有一个明确的盘点这直接影响我们能不能复现 R1 的训练流程维度状态具体内容源代码开源PTX 优化、FP8、强化学习训练代码模型结构开源完整网络结构描述商业授权开源MIT 协议模型权重闭源未提供 V3/R1 原始权重训练数据闭源未公开提示词工程闭源未公开也就是说DeepSeek 给的是一套「训练方法论和工程代码」但没给「训练好的权重和原始语料」。对想复现训练的团队来说只能从零开始自己准备数据、自己训 base model再按文档里描述的 GRPO 流程走。对只想做推理部署的团队来说影响不大因为有蒸馏版小模型和昇腾适配版本可以直接用。4. 昇腾上部署 V3/R1MindIE 适配、W8A8 量化与性能参数4.1 适配时间线四周从启动到百万级用户上线文档里有一段时间线我认为是整个方案里信息密度最高的部分时间事件里程碑意义1月1日昇腾启动 A2 适配测试模型发布即开始硬件适配1月25日A2 双机适配完成纯模型推理约 15 tps双机跑通 671B 模型2月1日硅基流动上线 V3/R1性能约 20 tps使能 MTP商用服务上线2月3日~5日移动云、电信云、联通云相继上线全版本模型三大运营商全部接入2月7日清昴智能玄武智算云全面支持 V3/R1 及蒸馏模型第三方云平台接入从启动适配到云服务上线前后正好一个月。这个速度说明两件事一是昇腾的 MindIE 推理引擎对 HuggingFace 格式模型兼容性做得足够好二是 DeepSeek 模型结构没有用任何昇腾不支持的算子MLA 和 MoE 都能在现有框架内跑通。4.2 A2 单机/双机部署参数16 卡实例、10~40 TPS部署资源方面文档给出了一些实测数字累计上线 4500 张 A2 卡用于部署 V3 和 R1其中 V3 用 1000 卡R1 用 3500 卡华为小艺依托硅基部署 V3/R1 支撑助手业务已上线 1500 卡单模型实例使用 16 张 A2 卡部署V3 模型单请求 10~40 TPSR1 模型单请求 10~40 TPSA3/A2 吞吐约为 2~2.8 倍16 卡一个实例V3 和 R1 的单请求吞吐都在 10~40 TPS 之间浮动。这里的浮动范围取决于请求的输入输出长度、并发度、是否使能 MTP 以及是否做了 W8A8 量化。模块版本方面文档提到配套版本上线了昇腾社区和魔乐社区MindIE 推理引擎版本是配套 DeepSeek V3/R1 的专门适配版本。对于 R1 这种长思维链推理模型单请求 TPS 低是正常的因为每次生成都包含大量内部推理过程。如果线上负载以短问答为主可以走 V3如果以数学、代码等复杂推理场景为主R1 的单个请求耗时会更长容量规划要给足余量。4.3 W8A8 量化部署蒸馏模型32B/70B 档位实测蒸馏小模型是部署侧性价比最高的方案。文档里列出的昇腾适配情况模型Atlas 300I DuoPod 900Pod 900 A2DeepSeek-R1-Distill-Llama-70B-√W8A8 量化√DeepSeek-R1-Distill-Qwen-32B-√W8A8 量化√DeepSeek-R1-Distill-Qwen-1.5B/7B/14B√√√W8A8 量化是权重和激活都压到 INT8。70B 模型在 Pod 900 上做 W8A8 量化后可以部署32B 同样。1.5B/7B/14B 这类小模型可以直接跑在 Atlas 300I Duo 推理卡上不需要整机。W8A8 的关键参数是量化粒度。昇腾的量化方案里激活按 per-token per-128-channels 分组缩放权重按 128×128 分组。细粒度分组能显著降低量化误差但会带来额外的 scaling factor 存储开销。如果追求极致吞吐可以尝试更粗的 per-tensor 量化代价是精度掉得厉害——特别是 R1 蒸馏模型这类模型在数学推理任务上对数值精度高度敏感。4.4 推理服务上线后的负载表现百万用户、千万级调用文档的运营数据可以反过来验证架构是否够用截至 2 月 8 日新增注册用户 130 万总用户突破 150 万2 月 6 日 V3 调用次数 341 万次生成 token 量 28.6 亿R1 调用次数 510 万次生成 token 量 90.5 亿模型调用平均性能16 卡 A2 实例V3 单请求 10~40 TPSR1 的 token 生成量远大于 V3——90.5 亿对 28.6 亿——这说明 R1 用户的问题以长推理为主单次请求消耗的 token 数多得多。容量规划时如果业务预期以深度推理为主每卡支持的并发数要留 2~3 倍余量。这个数据对比对做运营监控的同学很实用R1 和 V3 不能按同一个 QPS 水位来扩容。5. 昇腾部署避坑与常见问题从 4500 张卡里总结的教训5.1 现象开启 MTP 后 TPS 反而下降有团队在 A2 双机部署 R1 时遇到一个奇怪现象按文档推荐开启 MTP 后TPS 从 15 掉到 12 左右和预期的 1.8 倍加速完全相反。原因MTP 的加速依赖采信率。文档里说采信率正常在 85%~90%但如果输入 prompt 风格和训练分布差异很大——比如大量代码补全场景生成内容的可预测性变低小模型预测的 Token 里只有不到 70% 被采纳剩余的都要大模型重新生成。重新生成的开销超过了多 Token 预测省下的时间得不偿失。解决开 MTP 前先用业务真实请求跑 10 分钟压测统计采信率。低于 80% 就关掉 MTP改用纯单 Token 生成。另外就是把 MTP 组件单独用更低的量化精度跑——比如主模型 W8A8、MTP 组件保持 FP16可以缓解采信率下降的问题但显存占用会多 3~5GB 左右取决于 MTP 组件规模 11.5B 权重。5.2 现象W8A8 量化后 R1 数学推理错误率明显上升有团队对 R1-Distill-Llama-70B 做了 W8A8 量化上线后 AIME 级别的数学题正确率掉了 8~10 个百分点但通用问答效果几乎没变。原因数学推理任务对数值精度极其敏感。W8A8 的量化误差对「感知型」任务摘要、翻译、分类不敏感但对「推理型」任务多步计算、逻辑推导会累积误差。R1 的长思维链推理往往涉及几十步中间计算每步的精度损失会叠加。文档里明确提到 R1 对应的是「数学、代码生成等复杂推理任务」这类负载恰恰是量化最脆弱的场景。解决从 W8A8 回退到 W8A16权重 INT8、激活 FP16精度损失能收窄到 1~2 个点显存增加约 10%以 70B 模型约 70GB 算多 7GB 左右。如果显存紧张也可以用混合量化——前几层 Transformer 层保持高精度后面的层走 W8A8R1 的精度敏感点在浅层。实测这样能把精度损失控制在 3 个点以内显存只多 2~3GB。5.3 现象A2 双机部署时跨节点通信成为瓶颈TPS 上不去按文档数据A2 双机适配完成时纯模型推理约 15tps。有的团队复现时只有 9~10tps排查半天发现 MoE 路由的 Token 在跨节点通信时产生了拥塞。原因MoE 模型的专家分散在不同节点上每次前向都要做 All2All 通信。文档里提到 DeepSeek 的解法是把「集群网络拓扑跨节点 IB、节点内 NVLINK与 MoE 路由算法Token 分发避免拥塞机制结合」。如果只是简单按 expert 索引分片做 All2All必然出现部分网卡流量打满、部分空闲的不均衡现象。解决换用文档描述的「拓扑感知路由」——在昇腾上的对应实现是 MindIE 的 MoE 并行策略核对 MindIE 版本是否是适配 DeepSeek V3/R1 的版本昇腾社区 MindIE 配套版本已随模型上线。另一个办法是调整 expert 放置策略把通信最频繁的专家对放在同一台机器的不同卡上用 NVLINK 代替 IB 走跨节点流量。如果两机各 8 卡建议先把 256 个专家按「热点专家组内聚」的方式切分而不是均匀切 8 份。5.4 现象R1 输出里出现中英文混杂、思考过程不可读有团队直接用 R1 做线上客服发现部分回答的推理链会出现中英文混杂甚至 JSON 格式的思考过程直接外泄到最终答案里。原因R1 模型本身存在这个问题文档里对 R1-Zero 的明确评价是「推理过程可读性差、中英文混淆」。正式版 R1 通过冷启动 SFT 做了修正但修正并不彻底——遇到分布外的复杂问题时模型可能退回到 R1-Zero 的生成模式。解决部署层加一道输出后处理检测思考链标签如reasoning或thought块把它从最终输出剥离。更进一步是在 prompt 层加格式约束要求模型「只输出最终答案」。如果业务对推理过程有透明性要求那就需要自己做一层 SFT 微调用业务语料把 R1 的输出格式再校准一遍这个动作可以有效压制中英文混杂的概率。5.5 现象16 卡实例并发数上不去单请求延迟 30 秒以上文档里 16 卡 A2 单实例的 V3/R1 都是 10~40 TPS但有的团队复现时单请求延迟经常 30 秒以上并发一高就超时。原因KV 缓存没吃满。R1 是长序列推理模型每个请求的 KV 缓存占用比普通模型大得多。MLA 压缩后 KV 缓存降了 90%但如果并发数配置超过 KV 缓存容量请求会排队。另一种情况是没用连续批处理每个请求独占一段显存地址碎片化导致显存利用率低。解决确认 MindIE 开启了 continuous batching并把 max_seq_len 从默认值调到业务实际的 P95 长度。以 16 卡 A2 部署 R1 为例如果业务平均输出 2000 tokenmax_seq_len 设 8192 即可如果设成 32768KV 缓存碎片会拖累所有请求。建议做一次「并发数-延迟」矩阵压测找出拐点再定容量水位。6. 选型与验证V3、R1、蒸馏模型在昇腾上的分工部署前最后一步是选型。文档把 V3 和 R1 的定位写得很清楚V3 是通用型大模型专注 NLP、知识问答、内容生成适用智能客服、知识问答等场景R1 专为复杂推理设计强化数学、代码、逻辑推理能力API 成本为 o1 的 1/50适合科研、代码生成等深度推理场景。我的选型方法是先回答三个问题业务是短问答为主还是长推理为主延迟敏感还是成本敏感需要本地化部署还是 API 调用场景推荐模型昇腾部署建议通用客服、知识问答V3671B16 卡 A2 实例使能 MTPW8A8数学解题、代码生成R1671B16 卡 A2 实例建议保持 BF16 或 W8A16端侧 / 中等规模场景R1-Distill-Qwen-32B8 卡 Pod 900W8A8 量化轻量级边缘设备R1-Distill-Qwen-1.5B/7BAtlas 300I Duo 单卡验证阶段我习惯跑三个指标单请求 TPS、并发下的 P95 延迟、业务任务集准确率。前两个用压测工具就能测第三个需要准备一份业务侧的真实标注数据。R1 上线前至少跑 50 道业务侧数学或代码题量化方案每改一次就重跑一遍防止精度悄悄缩水。针对蒸馏模型的验证文档里有一个重要结论值得反复看大模型蒸馏的效果远好过小模型自己做 RL。这意味着如果没有能力把 base model 做到 70B 以上与其在小模型上死磕强化学习不如直接拿 R1 生成的样本来做蒸馏 SFT。文档提到蒸馏后小模型能力提升 10%这个提升量对端侧场景是质的飞跃。就拿我自己的实践来说从那以后我每一次做模型选型都强制走一遍「先分清任务类型 → 压测三指标 → 量化前后跑同一批标注题」这个流程不再凭模型名气拍板。DeepSeek 这套 V3/R1 组合和昇腾的适配方案把「671B 级模型的部署」从云端大厂的门槛拉到了有 16 张 A2 卡的团队可以独立操作的级别希望这篇拆解能帮你在自己的环境里少踩几个坑。本文还有配套的精品资源点击获取