企业官网建设流程全解析

简介：这份PDF资料聚焦2025年华为基于昇腾平台部署DeepSeek V3/R1的完整技术方案，面向大模型算法工程师、AI基础设施开发者及关注国产算力适配的技术决策者，帮助读者理解DeepSeek系列模型的演进脉络与昇腾NPU上的落地路径。资源为单文件PDF，共33页，压缩包约4.5MB，内容涵盖DeepSeek背景介绍、V3/R1创新点、基于昇腾的部署方案以及其对产业的影响四大模块。读者可从中获取DeepSeek从V1到V3的参数迭代对比、MoE架构与MLA注意力机制的设计思路、R1通过强化学习与冷启动SFT生成推理能力的训练流程，以及昇腾平台在计算通信优化、后训练与推理加速方面的工程实践。方案还对比了V3与R1在模型定位、训练方法、应用场景和API成本上的差异，并给出蒸馏版本适配Qwen与Llama的路径。目前已有605人学习，适合需要快速掌握国产算力与大模型结合要点的技术人员参考。

1. 昇腾上跑 DeepSeek V3/R1：这份 33 页方案到底解决了谁的燃眉之急

过去两个月，我身边做政企 AI 交付的同行几乎都在问同一个问题：客户点名要 DeepSeek V3 或 R1，但机房里的卡不是 A100/H800，而是华为昇腾 Atlas 800 A2 和 A3，能不能跑、怎么跑、跑出来多少 TPS？这份《2025华为：基于华为昇腾的DeepSeek V3-R1方案》就是冲着这个问题来的，33 页，四个部分：DeepSeek 背景、V3/R1 创新点、昇腾适配方案、产业影响。它不是一篇论文，而是一份交付视角的落地材料——告诉你哪些模型已经在昇腾上开箱即用、单机双机怎么摆、MTP 打开后性能从 15tps 提到 20tps 是怎么来的。适合两类人：一是手里有昇腾算力、要接 DeepSeek 私有化项目的交付工程师；二是想搞清楚 V3 和 R1 到底差在哪、该选哪个版本上线的技术决策者。下面我按自己拆这份材料的顺序，把能抄的参数、能复现的步骤和踩过的坑一条条摊开。

2. 先分清 V3 和 R1：选错版本，后面所有部署参数都是白调

2.1 从权重关系看 R1 不是 V3 的简单升级

很多人第一反应是"R1 比 V3 新，那就上 R1"。这个判断在通用问答场景下会翻车。材料里那张权重关系图讲得很清楚：R1 是从 V3-base 出发，经过冷启动 SFT、推理 RL、再 SFT、全场景 RL 四个阶段训出来的，中间还产出了 R1-Zero 和 800K CoT 蒸馏数据。也就是说 V3 和 R1 是同一底座上的两条分支，不是版本迭代关系。

具体差异落到选型上：

价格差接近 4 倍（输入）到 8 倍（输出），这个差距在私有化部署里体现为推理卡占用和单请求延迟。我一般会建议客户：客服、文档问答这类高频低复杂度请求走 V3；代码助手、数据分析、需要多步推理的走 R1。如果预算只够一套，优先 R1，因为 R1 在通用任务上也能用，只是贵。

2.2 蒸馏版才是大多数中小项目的实际选择

材料里提到 R1 开源了基于 Qwen 和 Llama 的蒸馏版本，覆盖 1.5B、7B、14B、32B、70B。这一条对交付工程师的价值远大于 671B 全量版。原因很直接：671B 的 V3 在昇腾上要 Atlas 300I Duo 900 Pod 或 900 A2 Pod 级别，而蒸馏版 32B 在单台 A2 上就能跑起来。

材料里那张适配表我抄下来对照过：

• DeepSeek R1-Distill-Qwen-1.5B/7B/14B：Atlas 300I Duo 和 900 A2 Pod 都支持，已上线
• DeepSeek R1-Distill-Qwen-32B：900 A2 Pod 支持，W8A8 量化，已上线
• DeepSeek R1-Distill-Llama-8B：测试中
• DeepSeek R1-Distill-Llama-70B：900 A2 Pod 支持，W8A8 量化，已上线

注意 W8A8 量化这个标注。32B 和 70B 蒸馏版在 A2 上是靠 W8A8 才塞进去的，这意味着精度有损。如果你的场景对数值敏感（比如金融报表解析），要么上更大显存不量化，要么在评测集上先验证量化后的掉点是否可接受。材料里没给量化掉点数据，这一步得自己补。

2.3 蒸馏效果为什么比小模型直接 RL 好

材料里有一句结论值得单独拎出来：论文对比了小模型 RL 训练和大模型蒸馏的效果，大模型蒸馏远远好过小模型 RL。这解释了一个常见误区——有人觉得既然 R1 靠 RL 训出来的，那我拿个 7B 模型也跑一遍 RL 不就行了。实际不行，因为 RL 需要模型自身有足够的推理能力底子去探索，小模型探索空间太窄，训出来不稳定。蒸馏是把大模型的推理轨迹直接灌给小模型，相当于抄答案，效率高得多。

所以选型顺序我一般这么排：有 A2 双机以上资源，直接上 R1 671B 或 V3 671B；单机 A2，上 R1-Distill-Qwen-32B（W8A8）；只有 Atlas 300I Duo，上 14B 或 7B 蒸馏版。这个顺序和材料里的适配表是对得上的。

3. 昇腾适配的四个关键动作：从 15tps 到 20tps 是怎么抠出来的

3.1 时间线里藏着适配的真实工作量

材料给了一条很具体的时间线，我按它还原一下适配节奏：

• 1 月 1 日，启动 A2 上的适配测试
• 1 月 25 日，A2 双机适配完成，纯模型推理性能约 15tps
• 2 月 1 日，硅基流动和华为攻坚后，V3、R1 上线昇腾云服务，性能约 20tps（使能 MTP）
• 2 月 3 日到 5 日，移动云、电信云、联通云相继上线全版本模型
• 2 月 7 日，清昴智能玄武智算云平台支持 V3/R1 及蒸馏模型

从 1 月 1 日到 2 月 1 日，整整一个月，从 15tps 到 20tps，提升 33%。这个提升的来源材料写明了是 MTP（Multi-Token Prediction）。所以如果你现在拿到昇腾环境要复现，第一件事不是调 batch size，而是确认 MTP 有没有打开。

3.2 MTP 打开前后的差异与配置要点

MTP 的原理材料讲得比较清楚：主模型 61 层 671B，额外加 1 层 MTP 组件，权重 11.5B，激活 2.4B。推理时一次预测多个 token，采信率 85%~90%，性能提升 1.8 倍（tokens per second）。训练阶段平均提升 2%~3%。

落到配置上，我一般会检查这几个点：

# 查看当前推理服务是否启用 MTP # 以 MindIE 为例，检查模型配置中的 speculative 相关字段 grep -r "mtp\|speculative\|multi_token" /usr/local/Ascend/mindie/config/ # 确认 MTP 组件权重是否加载 ls -lh /path/to/deepseek-r1/mtp_layer/ # 正常应看到约 11.5B 参数的权重文件

逻辑说明：MTP 是一个独立的预测头，需要单独加载权重。如果只加载了主模型没加载 MTP 层，服务能起来但性能停在 15tps 档位。参数上，MTP 的采信率阈值一般设在 0.85 左右，设太高会退化成单 token 预测，设太低会引入错误 token 影响输出质量。材料给的 85%~90% 是实测区间，我建议从 0.85 起步，在业务评测集上验证输出质量后再往上调。

提示：MTP 对显存有额外占用，11.5B 权重即使量化后也不是小数目。如果显存已经吃紧，打开 MTP 可能导致 OOM，这时候要么降 batch，要么放弃 MTP 保稳定。

3.3 FP8 混合精度在昇腾上的对应策略

材料里 V3 的一个核心创新是首次在大规模训练上用 FP8 混合精度，策略是：计算密集型算子（前向、激活反向、权重反向）用 FP8，精度敏感型（向量层、输出层、门控、注意力）保持 BF16/FP32，优化器动量 BF16，主权重和梯度 FP32。激活按 1x128 分组缩放，权重按 128x128 分组缩放。

这套策略在昇腾上落地时，对应的是 CANN 的混合精度配置。我一般会这样检查：

# 昇腾混合精度配置检查（以 PyTorch + torch_npu 为例） import torch import torch_npu # 查看当前 NPU 是否支持 FP8 print(torch_npu.npu.get_device_properties(0)) # 混合精度策略通常通过环境变量或框架配置控制 # 常见做法是在模型转换阶段指定精度白名单 # 将 attention、layernorm、output 层排除在 FP8 之外

逻辑说明：FP8 在昇腾上的支持程度取决于 CANN 版本和具体芯片型号。A2 和 A3 对 FP8 的支持不一样，材料里没细说，这是需要跟华为侧确认的点。参数上，分组缩放的粒度（1x128、128x128）是 DeepSeek 论文里的设定，昇腾适配时是否完全对齐，材料没给，我建议在模型转换日志里搜 "fp8" 和 "scale" 关键字确认。

3.4 DualPipe 与 All2All 通信优化的落地观察

DualPipe 是 DeepSeek 自研的双向流水线并行策略，核心是让计算和通信重叠，减少 PP 气泡。材料说减少 50% PP 气泡。All2All 优化则是把集群网络拓扑（跨节点 IB、节点内 NVLink）和 MoE 路由算法结合，避免 Token 分发拥塞。

这两项在昇腾上的落地，普通交付工程师能干预的不多，因为属于框架层优化。但有一个点可以观察：MoE 的专家负载均衡。材料提到多专家负载不均影响端到端性能 10% 以上，热点专家达到容量上限会丢弃 Token 影响模型效果。DeepSeek 的策略是专家数量多（256 选 8+1 共享专家）+ 每个专家 shape 小。

实际运维时，我会盯这个指标：

# 查看 MoE 各专家的 Token 分发统计（以 MindIE 日志为例） grep "expert_load\|token_dispatch" /var/log/mindie/inference.log | tail -100 # 如果发现某个专家承接的 token 数远超均值，说明路由不均 # 需要检查路由网络的温度参数或负载均衡损失配置

逻辑说明：专家负载不均是 MoE 推理的典型问题，表现为部分请求延迟突然拉高。原因通常是路由网络对某些输入模式有偏好。解决手段有限，一般是调路由温度或加负载均衡辅助损失，但推理阶段能调的参数比训练阶段少。如果负载不均严重，可能需要在服务层做请求分流，把不同类型的请求打到不同实例。

4. 避坑与排查：昇腾部署 DeepSeek 最容易翻车的五个点

4.1 现象：服务起来了但 TPS 只有个位数

原因：最常见的是没开 MTP，或者 MTP 权重加载失败但服务没报错。其次是 batch size 设成了 1，昇腾在 batch 较小时吞吐上不去。

解决：先确认 MTP 状态，再看 batch 配置。材料里 15tps 是双机 A2 的纯模型推理性能，20tps 是使能 MTP 后。如果你的环境是单机，TPS 会更低，这是正常的。单模型实例用 16 卡 A2 部署时，V3 和 R1 单请求都是 10~40TPS，这个区间跨度大是因为输入输出长度不同。

4.2 现象：模型加载到一半 OOM

原因：671B 模型即使量化后对显存要求仍然很高，加上 MTP 的 11.5B 额外权重，以及 KV Cache 的预留空间，容易在加载阶段就撑爆。

解决：材料里 MLA 的核心价值就是 KV Cache 压缩——KV 联合低维映射到 512 维潜空间，降低内存 90%。确认 MLA 是否生效是关键。如果 MLA 没生效，KV Cache 会按标准 MHA 的大小占用，直接翻几倍。检查模型配置里 attention 类型是否为 MLA。

4.3 现象：输出中英文混杂、推理过程可读性差

原因：材料里明确说了 R1-Zero 的问题就是"Reasoning 过程可读性差，中英文混淆"。如果你部署的是 R1-Zero 而不是正式 R1，这个问题必然出现。

解决：确认部署的是 DeepSeek-R1 正式版而非 R1-Zero。R1-Zero 是纯 RL 训练的中间产物，没有经过冷启动 SFT，不适合直接面向用户。材料里 R1 的训练流程是冷启动 SFT -> 推理 RL -> SFT -> 全场景 RL，正式版才有好的可读性。

4.4 现象：蒸馏版小模型效果远不如预期

原因：蒸馏版的能力上限受限于学生模型的容量。材料里蒸馏版覆盖 1.5B 到 70B，1.5B 和 70B 的能力差距是数量级的。另外 W8A8 量化会进一步掉点。

解决：先确认选的蒸馏版尺寸是否匹配任务复杂度。7B 以下适合简单分类和抽取，14B/32B 适合中等复杂度问答，70B 才接近可用推理。如果已经选了 32B 以上还是效果差，检查量化配置，尝试在关键层保留 FP16。

4.5 现象：多卡推理时延迟波动大

原因：MoE 的 All2All 通信在跨节点时受网络拓扑影响大。材料提到跨节点 IB 和节点内 NVLink 的差异，如果 Token 分发跨了 IB，延迟会明显高于节点内。

解决：检查部署拓扑，尽量让同一个请求的专家计算落在同一节点内。材料里提到集群网络拓扑与 MoE 路由算法结合来避免拥塞，这部分需要和华为侧确认是否有针对性的配置。运维层面能做的，是监控跨节点通信量，如果发现大量 All2All 走 IB，考虑调整专家分布策略。

5. 从 130 万用户数据反推：上线后该盯哪些指标

材料里给了一组硅基流动上线后的真实数据，我觉得比任何 benchmark 都有参考价值。截至 2 月 8 日晚 8 点，当日新增注册用户 23.6 万，累计新增 130 万+，总用户突破 150 万，7 天增长 8 倍。调用量方面，2 月 6 日 V3 调用 341 万次、生成 28.6 亿 token，R1 调用 510 万次、生成 90.5 亿 token。资源部署上，累计 4500+ A2 卡，V3 用 1000+ 卡，R1 用 3500+ 卡。

这组数据里藏着一个关键比例：R1 的卡数是 V3 的 3.5 倍，调用次数是 1.5 倍，但生成 token 量是 3.2 倍。说明 R1 的单次请求生成 token 数远高于 V3——这符合 R1 做推理任务时输出长 CoT 的特征。对你的容量规划意味着：如果业务以 R1 为主，显存和带宽预算要按 token 生成量来算，不能按请求数算。

我现在的习惯是，每次昇腾上部署完 DeepSeek，先跑一轮自己的评测集，记录三个数：首 token 延迟、单请求 TPS、并发 10 路时的 P99 延迟。然后对照材料里的 10~40TPS 区间，看自己落在哪。如果低于 10，先查 MTP 和 batch；如果在区间内但 P99 抖动大，查 MoE 负载均衡和跨节点通信。这套流程走下来，基本能定位到是配置问题还是资源问题。从那以后我每次上线前都强制走一遍这个三步检查，再也没出现过上线后才发现性能不达标的情况。希望帮到你。

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