Zhuang's Diary

部署要占用多少显存

以运行精度为 INT8 的大模型为例，这种精度的参数，一个参数需要占用一个字节。
$1B参数模型 = 10亿参数 * 每个参数占用1Byte$
$1G显存 = 102410241024Byte$
也就是说
INT8 精度类型：1B 参数需要约 1G 显存。

训练要占用多少显存

这里还有另外一个在线的网页工具：https://huggingface.co/spaces/hf-accelerate/model-memory-usage

模型包括： DeepSeek R1 (671B)，DeepSeek R1 Distill Qwen 7B， 14B， 32B， 以及 DeepSeek R1 Distill Llama 8B， 70B 这些模型，

1. 假设在并发 3 个用户的情况下运行这些模型所需的资源？
2. 关于 DeepSeek R1 系列模型在不同数据量下进行微调（并非全量训练），并在一天内完成微调所需的硬件资源。分别在 1K，1M，1GB，1T 数据量下训练这些模型所需的资源和训练时长。

根据您提供的信息，以及之前的分析，以下是关于 DeepSeek R1 系列模型微调硬件资源需求的全面分析，并以表格形式呈现：

DeepSeek R1 模型微调硬件资源需求总表 (单日内完成)

采用BF16（2字节/参数）的情况下，考虑到 Unsloth 主要优化 LoRA 微调，并且更适用于单 GPU 或少量 GPU 场景，基于 Unsloth 优化 LoRA 微调的假设，重新评估 DeepSeek R1 系列模型在中小数据量 (1K, 1M, 1G, 10G) 下的硬件资源需求。 对于超大数据量 (100G) 和超大模型 (DeepSeek-R1-671B)，我仍然保留 ZeRO-3 优化。

GPU 配置 (显存需求): 指完成微调任务所需的 GPU 型号和数量，以及总显存需求。例如 “16×A100 80G” 表示需要 16 张 80GB 显存的 A100 GPU。
CPU 核心数: 训练任务所需的 CPU 核心数量，主要用于数据预处理和模型管理。
内存: 系统内存需求，用于数据缓存、模型加载和训练过程中的临时数据存储。
存储 (SSD/NVMe): 高速固态硬盘容量需求，用于存储训练数据、模型参数和中间结果。NVMe SSD 提供更快的读写速度，适用于大数据量训练。
网络带宽: 多 GPU 训练时所需的网络带宽，用于 GPU 之间的数据通信。RDMA (Remote Direct Memory Access) 网络提供更低的延迟和更高的带宽，适用于大规模分布式训练。
关键配置说明: 简要描述了针对不同模型和数据量所采用的关键并行策略和优化技术，例如模型并行 (TP)、数据并行 (DP)、ZeRO-3 优化和梯度累积等。
预估并发 3 用户显存需求: 粗略估计为模型参数显存占用的 3 倍或更高。因为并发用户需要模型的多份副本或共享模型但需要额外的上下文缓存等。实际情况可能更复杂。

1. Unsloth 对资源需求的影响:
   • 中小模型 (Distill-Qwen-7B/14B/32B, Distill-Llama-8B) 和中小数据量 (1K - 100G): 使用 Unsloth 库进行 LoRA 微调，可以显著降低 GPU 资源需求。例如，Distill-Qwen-7B 在 1K 数据量下，单张 A10G 24G 即可完成微调；即使在 100G 数据量下，也仅需 8 张 A10G 24G GPU。
   • 超大模型 (DeepSeek-R1-671B) 和大数据量 (100G): 对于这些极端情况，Unsloth 的优化可能不足以完全解决显存瓶颈。因此，表格中仍然保留了 ZeRO-3 优化，并结合 Unsloth 的 FlashAttention-2 优化，以期达到最佳的性能和资源效率。
2. LoRA 微调的优势:
   • 表格中所有基于 Unsloth 的配置方案都假设使用 LoRA 微调。LoRA 本身就是一种参数高效微调方法，可以显著减少需要训练的参数量，从而降低显存需求和加速训练。
   • Unsloth 进一步优化了 LoRA 的实现，使其在速度和显存效率方面更具优势。
3. FlashAttention-2 的加速作用:
   • Unsloth 集成的 FlashAttention-2 可以显著加速训练过程，这有助于在 “日内完成微调” 的目标下，使用更少的 GPU 资源。

关键分析逻辑

1. 模型参数量 vs. GPU 显存:
   • 参数高效微调 (如 LoRA) 显著降低了显存需求，公式估算如下： $$ \text{显存} \approx \text{模型参数} \times (2\ \text{bytes} \times \text{激活系数}) + \text{优化器状态} $$ 其中，激活系数在 LoRA 场景下约为 0.1-0.3，优化器状态通过 ZeRO-3 等技术可以大幅减少。
2. 数据量 vs. 训练并行度:
   • 小数据量 (1K, 1M): 资源需求主要由模型大小决定。较小的 Distill 模型甚至可以在单张消费级 GPU 上完成微调。
   • 大数据量 (1G, 1T): 数据并行成为关键。需要增加 GPU 数量以提高数据吞吐量，并配合高速网络 (如 RDMA) 保证并行效率。
3. 训练时长与硬件资源:
   • 表格中的配置旨在将微调时间压缩到 一天以内。更快的训练速度通常需要更多的 GPU 资源并行计算。
   • 实际训练时间还会受到 模型结构、超参数设置、优化算法 等多种因素影响。上述表格提供的是一个 硬件配置参考，实际部署时可能需要根据具体情况进行调整。
4. 优化技术:
   • 混合精度训练 (BF16/FP16): 降低显存占用和计算复杂度，加速训练过程。
   • 梯度检查点: 通过计算换取显存，进一步降低显存峰值。
   • ZeRO-3: 将优化器状态、梯度和模型参数分片到多张 GPU 上，极大地减少单卡显存需求，尤其适用于超大模型 (如 671B)。
   • 模型并行 (Tensor Parallelism, TP): 将模型按层或张量切分到多张 GPU 上，降低单卡显存压力，适用于超大模型。
   • 数据并行 (Data Parallelism, DP): 将数据分片到多张 GPU 上，每张 GPU 训练模型完整副本的一部分数据，提高数据吞吐量，适用于大数据量训练。
   • 梯度累积: 在显存受限时，通过多次小批量梯度计算累积梯度，模拟大批量训练的效果。
5. 网络与存储:
   • RDMA 网络: 对于大规模分布式训练 (尤其是模型并行和数据并行结合)，RDMA 网络可以显著降低 GPU 间通信延迟，提高并行效率。
   • 高速 SSD/NVMe 存储: 大数据量训练时，高速存储可以加速数据加载，避免 I/O 瓶颈。

请注意:

• 上述表格提供的是 估算和建议，实际资源需求可能因具体任务和实现细节有所不同。
• 在实际部署时，建议 从小规模配置开始测试，并根据训练速度和资源利用率逐步调整硬件配置。
• 云服务平台通常提供多种 GPU 实例和高速网络配置，可以根据表格中的建议选择合适的云资源进行模型微调。

DeepSeek-R1的实施步骤

DeepSeek-R1本身就是开源的，HuggingFace Open R1 项目 ， 李飞飞团队s1项目 ， simpleRL-reason 在部分复现DeepSeek R1，还有 TinyZero 项目在复现DeepSeek R1-Zero，又是为何？
根据 DeepSeek-R1 的技术报告，分3个步骤完成这个项目：

• 第1步：用 DeepSeek-R1 蒸馏高质量语料库，来复制R1-Distill模型。
• 第2步：复制 DeepSeek (V3) 用来构建R1-Zero的纯强化学习（RL）pipeline。这可能涉及为数学、推理和代码整理新的大规模数据集。
• 第3步：通过多阶段训练，从基础模型过渡到RL版本。

结合DeepSeek的官方技术报告来看，也就是说，Open R1项目首先要实现的，是用R1数据蒸馏小模型，看看效果是不是像DeepSeek说的那么好：

DeepSeek-R1的实施效果

DeepSeek开源了6个用R1蒸馏的小模型，其中蒸馏版Qwen-1.5甚至能在部分任务上超过GPT-4o。

接下来，就是按照DeepSeek所说，不用SFT，单纯依靠RL调教出R1-Zero，在R1-Zero的基础上复刻出性能逼近o1的R1模型。

其中R1技术报告讲到，DeepSeek-R1训练过程中引入了一个多阶段训练流程，具体包括以下4个阶段：

1. 冷启动
   用数千个长思维链（CoT）样本对基础模型进行监督微调（SFT），为模型提供初始的推理能力。
2. 面向推理的强化学习
   在第一个SFT阶段的基础之上，用和训练R1-Zero相同的大规模强化学习方法，进一步提升模型的推理能力，特别是应对编程、数学、科学和逻辑推理任务的能力。
3. 拒绝采样的监督微调
   再次使用监督微调（SFT），提升模型的非推理能力，如事实知识、对话能力等。
4. 针对所有场景的强化学习
   这次强化学习的重点是让模型行为与人类偏好保持一致，提升模型的可用性和安全性。

Open R1做了什么？

目前，在open-r1 GitHub仓库中，已经可以看到这几个文件：

• GRPO（Grouped Relative Policy Optimization）实现，grpo.py: trains a model with GRPO on a given dataset.
  在 Open R1 发布后，GRPO已整合至TRL最新版本（v0.14，Jan 30, 2025）。该整合方案支持使用单个或多个奖励函数模型进行模型训练。GRPO 实现方案深度集成了 DeepSpeed ZeRO 1/2/3 分布式训练框架以实现多 GPU 扩展，并采用 vLLM 加速生成过程——这正是在线训练方法的主要性能瓶颈。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

from datasets import load_dataset
from trl import GRPOConfig, GRPOTrainer

dataset = load_dataset("trl-lib/tldr", split="train")

# Dummy reward: rewards completions that are close to 20 characters
def reward_len(completions, **kwargs):
    return [-abs(20 - len(completion)) for completion in completions]

training_args = GRPOConfig(output_dir="Qwen2-0.5B-GRPO", logging_steps=10)
trainer = GRPOTrainer(
    model="Qwen/Qwen2-0.5B-Instruct",
    reward_funcs=reward_len,
    args=training_args,
    train_dataset=dataset,
)
trainer.train()
# (Feb 2nd)仍存在显存占用过高的问题，我们正在通过性能剖析进行优化改进。

• 合成数据生成器，generate.py: generates synthetic data from a model using Distilabel.
  R1 技术报告中最引人注目的发现之一是：主模型可用于生成合成推理轨迹，而基于该数据集微调的较小模型可获得与主模型相近的性能提升。因此Open R1自然希望复现该合成推理数据集，使社区能够在其他模型上进行微调实验。
  面对 R1 这类超大模型，核心挑战在于高效扩展生成规模。Open R1花费一周时间尝试了多种配置方案：该模型可部署在 2 个 8xH100 节点（16 块 H100 GPU）上，我们最初基于此配置使用 vLLM 作为推理服务器。但很快发现该方案存在性能瓶颈：由于 GPU 的 KV 缓存快速耗尽，吞吐量未达最优且仅支持 8 路并行请求。当缓存耗尽时，占用大量缓存资源的请求会被抢占；若配置为PreemptionMode.RECOMPUTE模式，这些请求将在显存释放后重新调度。为此我们切换至 4x8xH100 节点配置（共 32 块 H100 GPU）。该方案为 32 路并行请求提供了充足的显存余量，基本避免了因 100% 缓存占用导致的请求重新调度问题。初始阶段我们采用批量请求查询 vLLM 服务器，但很快发现批次中的长尾样本会导致GPU利用率波动——新批次需等待前一批次最后一个样本完成后才能开始处理。将批量推理切换为流式处理后，GPU利用率显著稳定。

该优化仅需修改vLLM服务器的请求发送代码。批量推理代码如下：

1
2
3
4
5
6
7
8

# send requests in batches of 500
for batch in batch_generator(dataset, bs=500):
    active_tasks = []
    for row in batch:
        task = asyncio.create_task(send_requests(row))
        active_tasks.add(task)
    if active_tasks:
        await asyncio.gather(*active_tasks)

流式请求的新版代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

active_tasks = []
for row in dataset:
    # keep the total active requests under 500
    while len(active_tasks) >= 500:
        done, active_tasks = await asyncio.wait(
            active_tasks,
            return_when=asyncio.FIRST_COMPLETED
        )

    task = asyncio.create_task(send_requests(row))
    active_tasks.add(task)

# wait for all remaining tasks to complete
if active_tasks:
    await asyncio.gather(*active_tasks)
    # Open R1当前的生成速率已趋于稳定，但对于长查询被抢占时是否采用CPU 缓存策略仍需进一步探索。

• 实施监督微调训练代码，sft.py: performs a simple SFT of a model on a dataset.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# Train via command line
accelerate launch --config_file=recipes/accelerate_configs/zero3.yaml src/open_r1/sft.py \
    --model_name_or_path Qwen/Qwen2.5-1.5B-Instruct \
    --dataset_name HuggingFaceH4/Bespoke-Stratos-17k \
    --learning_rate 2.0e-5 \
    --num_train_epochs 1 \
    --packing \
    --max_seq_length 4096 \
    --per_device_train_batch_size 2 \
    --gradient_accumulation_steps 8 \
    --gradient_checkpointing \
    --bf16 \
    --output_dir data/Qwen2.5-1.5B-Open-R1-Distill

# Train via YAML config
accelerate launch --config_file recipes/accelerate_configs/zero3.yaml src/openr1/sft.py \
    recipes/Qwen/Qwen2.5-1.5B-Instruct/sft/config_demo.yaml

• 训练和评估代码，evaluate.py: evaluates a model on the R1 benchmarks.

数据集

社区在多个与R1相关的数据集项目上非常活跃，以下是一些亮点：

• bespokelabs/Bespoke-Stratos-17k：这是对 Berkeley Sky-T1 数据管线的复制，使用 DeepSeek-R1 创建一个包含问题、推理轨迹和答案的数据集。随后，这些数据被用于通过类似于 R1 论文中的蒸馏方法，微调 7B 和 32B 的 Qwen 模型。
• open-thoughts/OpenThoughts-114k：一个“开放的合成推理数据集，包含 114k 个高质量样本，涵盖数学、科学、代码和谜题”。这是 Open Thoughts 项目的一部分。
• cognitivecomputations/dolphin-r1：一个包含 80 万样本的数据集，样本来自 DeepSeek-R1、Gemini flash 以及来自 DolphinChat 的 20 万样本，目的是帮助训练 R1 风格的模型。
• ServiceNow-AI/R1-Distill-SFT：目前有 17,000 个样本，这是 ServiceNow 语言模型实验室为支持 Open-R1 工作而创建的数据集。
• NovaSky-AI/Sky-T1_data_17k：用于训练 Sky-T1-32B-Preview 的 17k 训练数据。最终数据包含来自 APPs 和 TACO 的 5k 编码数据，以及来自 NuminaMATH 数据集的 AIME、MATH 和 Olympiads 子集的 10k 数学数据。此外，我们还维护了来自 STILL-2 的 1k 科学和拼图数据。使用该数据集训练的模型成本不到 450 美元。
• Magpie-Align/Magpie-Reasoning-V2-250K-CoT-Deepseek-R1-Llama-70B：这个数据集扩展了 Magpie 和方法，通过生成没有起始提示的指令数据来包括推理过程。指令由 Llama 3.1 70B Instruct 和 Llama 3.3 70B Instruct 生成，响应则由 DeepSeek-R1-Distill-Llama-70B 生成。

总结

1. SFT后，进步显著，怎么做到的？
   一是微调用的训练数据起到了一定作用；二是强制让模型延长思考时间（test time scaling），具体做法叫做（Budget Forcing）预算强制，也就是强制限制模型使用最大或最小 tokens 进行推理，以此控制模型的思考长度。
   为了尽可能延长模型的思考，他们将模型的思考放在标签内，当结束后，以 final answer 给出答案，同时，当 LLM 即将停止思考时，会强制输出 Wait 来迫使模型继续思考，通过这样的方式，模型会进入反思，并可能会发现自己的错误。
   推理时插入的“Wait”，也许会像当初的 Step by Step 一样，成为一个魔法 token。“这或许就是古人‘三思而后行’的哲学吧！”
2. R1 训练的步骤总结：
   1）精心选择若干条（如 8000 条）高质量的数据，
   2）通过让 Gemini/DeepSeek V3 补充完善思维链COT之后作为数据集，
   3）以开源的大模型（如 Qwen2.5-32B，Llama 3.1）为基座微调出结果(如 R1)。
   4）最后，在模型输出时，用（Budget Forcing）预算强制方法强行拉长模型的思考时长和输出 token，结果发现其在特定测试集上进步显著。

一、关于DeepSeek公司及其大模型

1.1 公司概况

DeepSeek 2023年7月成立于杭州，是幻方量化旗下的子公司，全称是杭州深度求索人工智能基础技术研究有限公司。”成立时间才一年多”、”最近推出的V3已经能和OpenAI的4o媲美”、”训练成本不到600W美元”、”API定价仅是国内其他头部厂商几十分之一”、”APP已经在中美APP store登上免费应用榜首”；

以上是最近关于DeepSeek的一些新闻热点信息，下面我们从官网看下：
DeepSeek近半年相继推出了3个主要的大模型版本，分别是DeepSeek V2.5、DeepSeek V3、DeepSeek-R1（无一例外的都是用了MOE架构）。在这之前还推出了DeepSeek-VL、DeepSeek Coder、DeepSeek Math。

1.2 模型能力

DeepSeek模型已经对标国内Qwen、海外Llama、GPT 4o，从公布的榜单评测上看：DeepSeek-V3 在开源模型中位列榜首，与世界上最先进的闭源模型不分伯仲。

1.3训推成本

推理成本(API报价)：百万Token输入价格能达到1元。

训练成本：从技术报告中看DeepSeek用的是H800的GPU做的训练，而且只有2千张左右的H800，整个V3的正式训练成本不超过600W美元。

1、预训练阶段，每万亿的Token 训练V3使用 2048 个H800GPU集群，只需要 180K 个H800 GPU小时，大概 3.7 天(180000/2048/24)
2、整个预训练总耗时 2664K GPU小时（不到2个月），加上 上下文扩展和后训练，总耗时大概2788KGPU耗时。
3、按照 H800 每小时2美元租赁，总的训练成本不超过600W美元

这么低的推理和训练成本不由引出以下的问题：

• 模型采用了什么样的网络架构？
• 训练的精度、框架和并行策略是怎样的？
• 模型的部署和优化方案是怎样的？
• 在硬件层的计算和通信上做了什么优化？

二、DeepSeek训推核心技术

2.1 DeepSeek-V3模型网络架构

1) DeepSeekV3 整体预训练用了14.8万亿的高质量Token，2) 并且在后期做了SFT和RL，模型参数量达到 671B，但是每个Token仅激活37B参数。为了做到高效的推理和训练，3) DeepSeekV3自研了MLA注意力机制和无辅助损失负载均衡策略的MoE架构。

从技术报告中看出，是经典的Transformer架构，比较亮眼的就是前馈网络使用的DeepSeekMoE架构、Attention机制使用MLA架构，其实这两个在DeepSeekV2模型已经被验证使用过。
与DeepSeek-V2相比，V3额外引入了一种无辅助损失的负载均衡策略，用于DeepSeekMoE，以减轻因需要保证Expert负载均衡而导致的性能下降。

2.1.1 DeepSeekMoE

第一个将MoE架构引入Transformer网络的就是GShard架构了，与传统大模型架构相比，MoE架构在数据流转过程中集成了一个专家网络层。
可以看出传统的MoE基本两部分组成：Gating门控网络、稀疏MoE层；

• 稀疏 MoE 层: 这些层代替了传统 Transformer 模型中的前馈网络 (FFN) 层。MoE 层包含若干“专家”(例如 8 个)，每个专家本身是一个独立的神经网络。在实际应用中，这些专家通常是前馈网络 (FFN)，但它们也可以是更复杂的网络结构，甚至可以是 MoE 层本身，从而形成层级式的 MoE 结构。
• 门控网络或路由: 这个部分用于决定哪些Token被发送到哪个专家。Token的路由方式是 MoE 使用中的一个关键点，因为路由器由学习的参数组成，并且与网络的其他部分一同进行预训练。

和传统的MoE架构相比，DeepSeekMoE使用更细粒度的专家，并将一些专家隔离为共享专家，减少专家间的知识冗余。


门控网络路由策略：TopK表示第t个Token和所有路由专家计算出的亲和力分数中K个最高分数的集合，在DeepSeekV3中，使用sigmoid函数计算亲和力分数，然后在所有选择的亲和力分数中应用归一化来生成门控值。
通常在MoE模型的训练过程中，不同专家因为路由策略的因素会导致接收的训练数据分布不均，比如所有的Token都被发送到只有少数几个受欢迎的专家，那么有些专家就可能没有被训练到。
业界通用的解决方案就是引入辅助损失，但是，有时候过大的辅助损失会损害模型性能。
为了在负载均衡和模型性能之间取得更好的平衡，DeepSeek开创了一种无辅助损失的负载均衡策略：为每个专家引入一个偏差项 bi，并将其添加到相应的亲和力分数 Si,t 中以确定top-K路由，具体来说：如果其对应的专家过载，我们将偏差项减少γ；如果其对应的专家负载不足，我们将偏差项增加γ，其中γ是一个称为偏差更新速度的超参数。

门控网络本质上就是一个softmax叠加一个分类网络，那么辅助loss往往就是添加一个惩罚项，对输出过大的 logits 进行惩罚，鼓励模型生成更加适度的 logits 值，防止模型生成过于极端的输出。

2.1.2 MLA 多头潜在注意力

大模型推理过程KV Cache机制一般是限制推理效率的一大瓶颈，而标准的Transformer 架构里面的MHA架构会产出非常多的KV Cache，为了减少对应的KV Cache业界实践过很多方案，例如PagedAttention、多查询注意力（MQA）和分组查询注意力（GQA），但是性能相比原生的MHA有一定差距。

DeepSeek-V2，提出一种创新的注意力机制：多头潜在注意力（MLA）。
相比MQA的KV共用和GQA的KV分组，MLA的核心是注意力键和值的低秩联合压缩，以减少推理过程中的键值(KV)缓存。相比MHA具有更好的性能，但需要的 KV 缓存量要少得多。

低秩矩阵是指其秩（rank）远小于其行数和列数的矩阵。
假设我们有一个矩阵，其实际结构允许它被分解为两个较小的矩阵的乘积。这种情况通常意味着原矩阵是低秩的。
假设我们有一个4×5的矩阵A，这个矩阵可以通过两个更小的矩阵的乘积来表示，比如一个4×2的矩阵B和一个2×5的矩阵C。这意味着原始矩阵A的信息可以通过这两个较小的矩阵来捕捉，表明A是一个低秩矩阵。

低秩压缩计算核心过程：

这里的 ht 表示第 t 个Token的输入，WDKV 表示KV的向下投影矩阵，将 ht 做降维压缩表示，实际得到 cKVt 就是要缓存的KV压缩隐向量；WUK和WUV是向上做升维的投影矩阵，将Token的压缩隐向量cKVt复原为原始KV矩阵；
MLA 模块架构图如下：

2.2 训练推理核心技术

2.2.1 训练框架HAI-LLM

DeepSeek-V3在一个配备了2048个NVIDIA H800 GPU的集群上进行训练，使用的是自研的HAI-LLM框架，框架实现了四种并行训练方式：ZeRO 支持的数据并行、流水线并行、张量切片模型并行和序列并行。  
这种并行能力支持不同工作负载的需求，可以支持数万亿规模的超大模型并扩展到数千个 GPU，同时还自研了一些配套的高性能算子haiscale，可以帮助 HAI-LLM 极大优化大模型训练的显存效率和计算效率。

2.2.2 核心算法DualPipe-创新流水线并行算法

i.通信计算重叠优化
DeepSeek-V3应用了16路流水线并行（PP），跨越8个节点的64路专家并行（EP），以及ZeRO-1数据并行（DP）。
与现有的流水线并行方法相比，DualPipe的流水线气泡更少。同时重叠了前向和后向过程中的计算和通信阶段，解决了跨节点专家并行引入的沉重通信开销的挑战。
DualPipe的关键思想是重叠一对单独的前向和后向块中的计算和通信：将每个块划分为四个组件：注意力、all-all调度、MLP和all-all组合

例如，假设我们有两个计算块，A和B：
1.在块A进行前向传播计算时，可以同时进行块B的后向传播通信过程。
2.当块A完成前向传播计算后，开始它的通信过程；而块B则开始它的前向传播计算。

通过优化排列这些功能模块，并精确调控用于通信和计算的 GPU SM资源分配比例，系统能够在运行过程中有效隐藏全节点通信和 PP 通信开销。
可以看出DeepSeek在PP这块，做了大量的通信计算重叠优化，从技术报告中看出，即使是细粒度的all-all专家通信，all-all的通信开销几乎为0。



• 计算通信重叠
  在深度学习大规模分布式训练过程中，通信的速度往往落后于计算的速度，如何在通信的gap期间内并行做一些计算就是高性能计算和通信重叠，是实现高效训练的关键因素。
• 流水线并行气泡问题
  一些大的模型会采用流水线并行策略，将模型的不同层放在不同的GPU上，但是不同层之间有依赖关系，后面层需要等前面的计算完才能开始计算，会导致GPU在一段时间是闲置的，如下图所示：

ii.跨节点全对全通信
DeepSeek还专门定制了高效的跨节点all-all通信内核(包括调度和组合)。
具体来说：跨节点 GPU 通过 IB 完全互连，节点内通信通过 NVLink 处理，每个Token最多调度到 4个节点，从而减少 IB 通信量。同时使用warp专业化技术做调度和组合的优化。

在调度过程中，(1) IB 发送，(2) IB 到 NVLink 转发，以及 (3) NVLink 接收分别由各自的 warp 处理。分配给每个通信任务的 warp 数会根据所有 SM 上的实际工作负载动态调整。
在合并过程中，(1) NVLink 发送，(2) NVLink 到 IB 的转发和累积，以及 (3) IB 接收和累积也由动态调整的 warp 处理。

通过这种方式，IB 和 NVLink 的通信实现完全重叠，每个 token 能够在不产生 NVLink 额外开销的情况下，在每个节点上平均高效选择 3.2 个专家。这意味着，虽然 DeepSeek-V3 实际只选择 8 个路由专家，但它可以将这个数字扩展到最多 13 个专家（4 个节点 × 3.2 个专家/节点），同时保持相同的通信成本。

DSV3采用了1个共享专家和256个路由专家的MoE架构，每个token会激活8个路由专家。

2.2.3 用于FP8训练的混合精度框架

这里并没有将全量参数FP8量化训练，大多数计算密集型操作都在FP8中进行，而一些关键操作则战略性地保留其原始数据格式，以平衡训练效率和数值稳定性。

哪些算子启用FP8量化去计算？取舍逻辑是什么？

• 大多数核心计算过程，即 GEMM 运算，都以 FP8 精度实现
• 涉及对低精度计算的敏感性的算子，仍然需要更高的精度
• 一些低成本算子也可以使用更高的精度
  以下组件保留了原始精度（例如，BF16 或 FP32）：Embedding模块、输出头、MoE 门控模块、Normalization 算子以及 Attention 算子。

如何提高低精度训练精度？

• 细粒度量化

  对激活，在token维度采用group-wise的量化(1128)；对权重，采用128 128的block-wise量化

• 提高累加精度

  在 TensorCore 上执行矩阵 MMA（矩阵乘法累加）操作时，每当累加达到一个间隔时，这些部分结果会被传输到 CUDA Cores 上的 FP32 寄存器中，并在那里进行FP32 精度的累加计算。

2.2.4 MTP的训练目标

DeepSeekV3训练过程设置了多Token预测的目标，从技术报告的消融实验看出，确实提高了模型在大多数评估基准上的性能，而且MTP模块还可以用于推理加速。

2.2.5 推理部署方案

DeepSeek-V3 整体参数量达到了671B，如此多的参数量，我们看下他的一个部署方案：
推理部署采用了预填充(Prefilling)和解码(Decoding)分离的策略，确保了在线服务的高吞吐量和低延迟。通过冗余专家部署和动态路由策略，模型在推理时保持了高效的负载均衡。
整套部署方案下来基本是跨机分布式推理。

2.2.5.1 Prefill 阶段
这个阶段简单说就是并行处理用户的Prompt，将其转为KV Cache。

预填充阶段的最小部署单元由4个节点组成，每个节点配备32个GPU。注意力部分采用4路张量并行（TP4）和序列并行（SP），并结合8路数据并行（DP8）。其较小的TP规模（4路）限制了TP通信的开销。对于MoE部分，我们使用32路专家并行（EP32）

2.2.5.2 Decoder 阶段
这个阶段就是做自回归的每个Token的输出。

解码阶段的最小部署单元由40个节点和320个GPU组成。注意力部分采用TP4和SP，结合DP80，而MoE部分使用EP320。对于MoE部分，每个GPU只承载一个专家，64个GPU负责承载冗余专家和共享专家

总结：为什么DeepSeekV3训练成本这么低？

训练成本主要由模型架构以及训练架构所决定，而且两者一定是相辅相成。从报告中可以看出以下几个原因：
I.MLA 机制：通过对KV做联合低秩压缩大幅减少KV Cache，相比业界从KV数量角度做KV Cache的减少，MLA 的压缩实现很考验研究团队的基本功。
II.FP8 训练：通过低精度计算减少了 GPU 内存使用和计算开销，技术报告中也提到FP8混合精度训练框架是首次在一个极大规模的模型上验证了其有效性，这一点也看出DeepSeek的Infra工程团队的底蕴。
III.MoE 架构：通过MoE稀疏激活机制大幅减少了计算量，相比Qwen和Llama的Dense架构有很大的训推先天优势，不过难题(专家的负载、通信、路由)也给到了Infra工程团队。

三、为什么是DeepSeek？

在硅谷，类似DeepSeek这样的AI创新并不少有，只是这次是一家中国公司做出了这个动作，相比传统的‘美国创新、中国应用’的模式显得格外的让人兴奋。

从最近的一些访谈以及DeepSeek的技术报告中也能看出以下几点：
1、大模型是一个知识密集型产业，如何组织高密度人才？显然DeepSeek做到了。
2、大模型技术没有魔法，更多时候就是考验基本功和驱动力。
3、不以商业化为第一要义，很多时候能轻装上阵。

四、个人思考

1、长远来看，后续可能会有专门的适配Transformer架构的芯片，就像为卷积设计了ASIC芯片。
2、多Token预测、MoE架构可能很长一段时间都是大模型训推架构热门研究方向。
3、在国内做AI，应用始终会比基础研究有市场，更有话语权，但是基础创新和海外的代际差距会越来越小。
4、大模型训练和推理，软硬件是一个协同的生态，DeepSeek的出现将会促进AI全行业的更加快速且低成本的迭代。

参考资料

1、Better & Faster Large Language Models via Multi-token Prediction
4、DeepSeek-V3 Technical Report
5、DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model
6、deepseek v3的成本这么低的根本原因是什么？
7、GPipe: Easy Scaling with Micro-Batch Pipeline Parallelism 

CBDC商业需求的框架：

1. 货币属性与分层（Monetary Hierarchy）
   • 明确性增强：
   建议进一步明确CBDC与现有货币（如现钞、存款货币）在法律地位和功能上的边界，特别是CBDC与稳定币的关系，以防止市场混淆。
   • 计息机制补充：
   动态利率调控应细化适用场景，如是否适用于长期零利率环境或应对通缩危机。增加对“负利率”选项的讨论（如欧盟报告提及），并评估其可能对现金的替代效应和公众接受度的影响。

2. 合规与监管（Compliance & Regulation）
   • 隐私与监管平衡细化：
   • 对于“小额匿名交易”的标准可结合具体国情调整，比如中国试点采用的「可控匿名」方案，可以在技术上设置交易金额、频率的动态监控上限，而非固定金额阈值。
   • 增加数据最小化（Data Minimization）原则，以减少不必要的信息收集，从而增强用户隐私保护。
   • 制裁合规优化：
   建议进一步细化跨境交易黑名单机制的实现方式，是否支持智能合约自动筛查，同时预防潜在的技术误判和冤假错案。

3. 技术架构（Technical Infrastructure）
   • 混合账本的弹性：
   明确不同机构的技术分工，例如央行核心账本是采用传统集中式数据库，还是许可链。对于子账本的具体功能，可以进一步说明其扩展范围（如钱包、支付场景）以及与核心账本的交互机制。
   • 隐私保护技术：
   除零知识证明（ZKP）和同态加密外，可增加多方安全计算（MPC）的讨论，特别是对于跨境支付中的敏感数据分割与安全计算的适用性分析。
   • 可扩展性补充：
   万级TPS的标准可细化到压力测试指标，如峰值负载下的系统响应时间、区块生成时间和网络延迟等。

4. 支付系统互操作性（Interoperability）
   • 增强描述：
   增加CBDC在跨境支付场景中的“桥接角色”功能说明，例如mBridge、ICE项目的架构特点；明确自动外汇兑换的具体技术实现（是否基于去中心化市场或官方清算系统）。
   • 与商业银行系统的协同：
   明确CBDC是否会与商业银行账户体系直接交互，以及在支付链条中，如何避免资源争夺（如存款转移至CBDC后对商业银行的影响）。

5. 用户体验与普惠性（User-Centric Design）
   • 普惠性增强：
   • 硬件钱包的支持范围可进一步说明，如是否采用低成本芯片（例如安全芯片SE），以应对农村或偏远地区普及难题。
   • 对无智能手机用户的支持还可以讨论二维码与短信支付结合方案。
   • 双离线能力补充：
   增加离线交易后同步验证机制的技术细节（如通过时间戳或单次签名以防双花攻击）。

6. 货币政策传导（Monetary Policy Implementation）
   • 定向发放机制优化：
   明确技术实现，例如智能合约中的补贴精确传导机制，并讨论此类功能对社会福利政策的潜在影响（如精准扶贫）。
   • 数据采集分析透明性：
   增加对数据使用的透明化要求，例如统计数据是否匿名化处理以及其公开程度，以增强公众信任。

7. 法律与治理框架（Legal & Governance）
   • 治理多元化：
   增加外部监督机制，例如是否允许第三方审计机构对央行CBDC系统进行独立评估。
   • 国际合作机制：
   考虑到跨境支付需求，建议增加CBDC在国际治理框架中的角色说明，例如是否支持与IMF、BIS等国际组织协同制定技术标准。

8. CBDC参与方-央行，商业银行和金融中介等金融机构的权利，责任和义务。

9. 补充建议
   • 动态演进需求的细化：
   对智能合约的可编程性增加限制性条款，以避免复杂合约逻辑引发系统性风险。同时可支持模块化智能合约，便于后期升级或维护。
   • 技术中立性再明确：
   技术中立性框架下，可列举具体的“避免绑定特定技术”的实现方法，例如通过开放API接口或支持多种基础设施并行部署。

CBDC继续需求的框架：

核心目标：为公众和企业提供安全、可靠、高效、可普惠的数字支付手段，同时支持央行在货币政策、支付监管和金融创新中的核心职能。

1. 货币核心功能

1.1 法定地位与可兑换性
• 法定货币属性：确保CBDC具有与纸币等值的货币权威性（M0级别），直接体现央行负债。
• 兑换机制：支持与现钞、商业银行存款的无缝兑换，保障CBDC与现有货币体系平稳共存。
• 多面额与精确支付：允许最低单位交易（如0.01元），满足日常交易需求。

1.2 利息与价值管理
• 默认无息设计：CBDC保持与纸币一致的零利率，避免对银行存款造成挤压。
• 动态调节选项：在特殊经济场景下（如通缩或危机）允许设计利息方案，支持货币政策工具创新。

2. 用户与场景需求

2.1 便捷性与普惠性
• 广泛的终端支持：兼容智能手机、非智能手机（如USSD短信支付），以及硬件钱包（适用于无银行账户用户）。
• 离线支付能力：在网络中断时支持小额支付（如公交、零售场景），同步额度可灵活设置（如3天内最高500元）。
• 普适设计：提供多语言界面、语音辅助功能，并支持残障人士友好的交互方式（如盲文触觉反馈）。

2.2 交易隐私保护
• 分层隐私：
• 小额匿名交易：单笔<100美元时，避免用户身份被记录；
• 大额追溯交易：交易>1000美元时，需绑定实名身份以满足合规要求。
• 用户数据保护：限制不必要的用户数据采集，确保数据在监管无需要的情况下可在设定时间后销毁（如90天）。

3. 支付与互操作性

3.1 国内支付整合
• 支付系统对接：支持CBDC与现有实时全额结算系统（RTGS）和其他支付网络的互联互通，保障T+0清算能力。
• 银行与钱包融合：允许用户将CBDC钱包与银行账户快速绑定，实现账户资金的灵活转移与管理。

3.2 跨境支付功能
• 跨境支付便捷性：通过多边央行合作（如mBridge项目）实现跨境支付无缝结算，并提供实时汇率支持。
• 合规性保障：在跨境支付中，实时筛查国际制裁名单，确保不涉及高风险交易。

4. 监管与合规支持

4.1 反洗钱（AML）与反恐融资（CFT）
• 实时监控：提供可疑交易的实时预警和链上追踪功能，确保资金来源与用途透明。
• 自动报告：支持生成符合国际标准的资金流动报告（如FATF旅行规则），减少金融机构合规负担。

4.2 账户管理与司法协助
• 账户冻结功能：在司法授权情况下，允许央行冻结特定用户的CBDC账户。
• 资金追回：支持误转账资金的快速追踪和人工审批返还流程。

5. 货币政策与数据支持

5.1 流动性与脱媒管理
• 余额上限：允许设置用户钱包的持币上限，避免商业银行存款大规模流失。
• 定向发放能力：支持政府专项资金（如灾害补贴）精准下发到用户钱包，提高政策执行效率。

5.2 数据驱动的经济监测
• 实时监测：通过交易数据流动情况（如频率、金额、地域分布）支持央行货币政策分析与调整。
• 宏观经济评估：基于CBDC的实时数据反馈，优化货币流通结构，替代传统滞后的M0统计方法。

6. 安全与稳定性

6.1 抗风险能力
• 高安全性：采用先进加密算法保护交易信息，确保CBDC对网络攻击（如量子计算攻击）具有抗风险能力。
• 离线交易风控：离线支付额度和时间窗可动态调整，防止双花攻击及恶意使用。

6.2 系统容灾
• 多活备份：在不同地区部署容灾节点，确保系统在灾难情况下的持续运行。
• 快速恢复：所有用户交易记录可在网络恢复后10分钟内同步，保障支付体验连续性。

7. 智能合约与可编程货币

7.1 可编程场景
• 政府补贴发放：支持通过智能合约精确发放专项资金，确保资金流向符合政策目标。
• 绿色金融：支持碳积分兑换等创新应用，鼓励低碳消费行为。

7.2 合约管理与更新
• 部署权限：仅允许央行授权的机构发布智能合约，确保安全性与规范性。
• 动态升级：智能合约需支持紧急修复能力，避免代码漏洞引发系统性风险。

8. 附加说明

• 动态调整需求：针对不同试点国家的具体需求（如普惠金融优先级或隐私保护程度），设计需灵活调整。
• 技术中立性：选择适配性广的基础架构，避免过度依赖单一技术，保障未来系统升级的灵活性。

Below are the characteristics of different types of Bitcoin addresses:

1. P2PKH Address (Pay-to-PubKey-Hash):
   • Starts with the letter “1”.
   • Length is 26 to 35 characters.
2. P2SH Address (Pay-to-Script-Hash):
   • Starts with the letter “3”.
   • Length is 26 to 35 characters.
3. Bech32 Address (SegWit Address):
   • Starts with “bc1”.
   • Length is 42 to 62 characters.

另外，Thief on Solana

• CEzN7mqP9xoxn2HdyW6fjEJ73t7qaX9Rp2zyS6hb3iEu
• 5WwBYgQG6BdErM2nNNyUmQXfcUnB68b6kesxBywh1J3n

Scam on ETH

• 0x84eb60e6732848f837f48402dcfff25e3d3d9304