DeepSeek 官方修正了 V3 的激活参数量说明

在之前的博客《DeepSeek V3 模型各子模块参数量精算》中,我计算的模型激活参数量跟官方 README_WEIGHT.md 中的说明对不上。之后有读者跟我说,官方更新了激活参数量的数字。我查了一下 commit history,具体修改如下:

DeepSeek V3 README_WEIGHTS.md commit

可以看到,V3 模型激活参数量从 36.7 改成了 36.6,并且去掉了包含 0.9B Embedding 的说明,那基本上跟我的计算完全对上了。MTP 激活参数量从 2.4B 改成了 1.5B,也去掉了 0.9B 的 Embedding,跟我的计算还是有 0.1B 的差异。

Anyway,这种总量统计只是为了揭示计算的大约规模,有点差异也不影响定性结论。真正有用的是你在拆分 TP、EP 等权重矩阵时,矩阵的形状是多大,要拆多少份,每份大概多大。

为了分析像 DeepSeek V3 这样的超大模型具体参数,我写了一个小脚本,可以将 safetensors 文件里面的权重 Shape 提取出来,并且可以按不同的层级做参数量的聚合计算:

https://github.com/solrex/solrex/blob/master/snippets/show_safetensors.py

#!/usr/bin/env python3
import os
import argparse
import torch

from safetensors import safe_open

def print_tensor_tsv(model_dir, depth):
    '''Print tensor info in .safetensors into tsv format'''
    TENSOR_CLASS = {
        'weight': 'weight',
        'e_score_correction_bias': 'weight',
        'weight_scale_inv': 'scale'
    }
    print('SafetensorsFile\tTensorKey\tTensorParams\tTensorType\tTensorShape')
    safetensor_files = sorted([f for f in os.listdir(model_dir) if f.endswith('.safetensors')])
    summary = {}
    for filename in safetensor_files:
        file_path = os.path.join(model_dir, filename)
        with safe_open(file_path, framework='pt') as f:
            for key in f.keys():
                tensor = f.get_tensor(key)
                print(f'{filename}\t{key}\t{tensor.numel()}\t{tensor.dtype}\t{tensor.shape}')
                lst = key.split('.')
                # Get suffix: .weight or .weight_scale_inv
                tclass = TENSOR_CLASS[lst[-1]]
                # Limit prefix to dep
                dep = min(len(lst), depth+1) if depth > 0 else len(lst)
                # Get summary of prefixes
                for prefix in ['.'.join(lst[:i]) for i in range(0, dep)]:
                    summary[f'{tclass}[{prefix}]'] = summary.get(f'{tclass}[{prefix}]', 0) + tensor.numel()
    for key in sorted(summary):
        print(f'Summary\t{key}\t{summary[key]}\t\t')

if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Print tensor shape and dtype of .safetensors file')
    parser.add_argument('model_dir', nargs='?', default='.', help='Model directory (default: $PWD)')
    parser.add_argument('--summary_depth', '-d', type=int, default=3, help='Summary depth of weights')
    args = parser.parse_args()
    print_tensor_tsv(args.model_dir, args.summary_depth)

在 HuggingFace 模型根目录下执行 ./show_safetensors.py ,即可获得当前模型的所有权重 Shape 和前 3 层的聚合权重规模。可以通过 “-d” 参数调整最大聚合的层级。输出的文件是 tsv 格式的,可以导入表格进行再计算。

以下是使用 show_safetensors.py 分析 DeepSeek V3 参数量的示例:

$ ./show_safetensors.py -d 2
SafetensorsFile TensorKey TensorParams TensorType TensorShape
model-00001-of-000163.safetensors model.embed_tokens.weight 926679040 torch.bfloat16 torch.Size([129280, 7168])
model-00001-of-000163.safetensors model.layers.0.input_layernorm.weight 7168 torch.bfloat16 torch.Size([7168])
...
model-00163-of-000163.safetensors model.layers.61.shared_head.head.weight 926679040 torch.bfloat16 torch.Size([129280, 7168])
model-00163-of-000163.safetensors model.layers.61.shared_head.norm.weight 7168 torch.bfloat16 torch.Size([7168])
Summary scale[] 41540496
Summary scale[model.layers] 41540496
Summary scale[model] 41540496
Summary weight[] 684489845504
Summary weight[lm_head] 926679040
Summary weight[model.embed_tokens] 926679040
Summary weight[model.layers] 682636480256
Summary weight[model.norm] 7168
Summary weight[model] 683563166464

可以看到第一列为文件名(像 model-00001-of-000163.safetensors)的行是该文件中的具体权重信息,包含 Shape 信息;第一列为 Summary 的行,是根据模型的 tensor key 名字结构, 例如 “model.layers.0.input_layernorm.weight”,按照 “.” 切成前缀,按照前缀聚合模型参数量的结果,不包含 Shape 信息。

DeepSeek V3 模型各子模块参数量精算

网上很多文章一般只提到 DeepSeek V3 模型的总参数量,很少有人分析各子模块的参数量。我试着让各 AI 根据配置计算一下,没有一个靠谱的,只能自己算了。(也许本文的内容后续会变成 AI 回答本问题的 RAG 养料)

下面是根据 DeepSeek V3 开源仓库 https://huggingface.co/deepseek-ai/DeepSeek-V3,对 DeepSeek V3 各子模块参数量进行的精算,在计算复杂的 TP、DP、EP 拆分时可以用作基数参考。如有错误,烦请评论指出。

嵌入层 Embedding

"vocab_size": 129280, // Token 字典大小
"hidden_size": 7168,

DeepSeek V3 的嵌入层参数量是:

129280 * 7168 = 926,679,040 (~0.9B)

MLA

"hidden_size": 7168,
"num_key_value_heads": 128,
"v_head_dim": 128,
"kv_lora_rank": 512,

"num_attention_heads": 128,
"q_lora_rank": 1536,

"qk_nope_head_dim": 128,
"qk_rope_head_dim": 64,

"num_hidden_layers": 61,

单层 MLA 中 Q 的 LoRA 参数量是:

7168 * 1536 + 1536 + 1536 * 128 * (128 + 64) = 48,760,320

单层 MLA 中 KV 的 LoRA 参数量是:

7168 * (512 + 64) + 512 + 512 * 128 * (128 + 128) = 20,906,496

单层 MLA 中 WO 的参数量是

128 * 128 * 7168 = 117,440,512

pre 和 post attention layernorm 的参数量是:

7168 * 2 = 14336

所以 DeepSeek V3 的 MLA 部分共 61 层的总参数量是:

(48,760,320 + 20,906,496 + 117,440,512 + 14336) * 61 = 11,414,421,504 (~11B)

MoE

"num_hidden_layers": 61,
"hidden_size": 7168,
"moe_intermediate_size": 2048, // 路由专家 MLP 的中间维度
"n_shared_experts": 1, // 共享专家数量
"n_routed_experts": 256, // 路由专家数量
"first_k_dense_replace": 3, // 前几层使用dense替换MoE
"intermediate_size": 18432, // 前3层 (9*moe_intermediate_size)

每个专家的参数量是:

7168 * 2048 * 3 = 44,040,192

路由 Gate 的参数量是:

256 * 7168 + 256 = 1,835,264

前 3 层 dense(固定激活 8 路由专家),前 3 层参数量是:

44,040,192 * 9 * 3 = 1,189,085,184

后 58 层稀疏(动态激活 8 路由专家),后 58 层参数量是:

(44,040,192 * 257 + 1,835,264) * 58 = 656,569,547,264

所以 DeepSeek V3 的 MoE 部分的总参数量是:

1,189,085,184 + 656,569,547,264 = 657,758,632,448 (~657B)

每次计算激活 1 个共享专家,8 个路由专家,所以 DeepSeek V3 MoE 部分的激活参数量是:

44,040,192 * 9 * 61 + 1,835,264 * 58 = 24,284,510,720 (~24B)

Layer 维度

前 3 层是 dense,没有 gate,基于上面的计算,DeepSeek V3 前 3 层每层的参数量是:

(48,760,320 + 20,906,496 + 117,440,512 + 14336) + (44,040,192 * 9) = 583,483,392

后 58 层是 MoE 稀疏激活专家,基于上面的计算,DeepSeek V3 后 58 层每层的参数量是:

(48,760,320 + 20,906,496 + 117,440,512 + 14336) + (44,040,192 * 257 + 1,835,264) = 11,507,286,272

输出层

DeepSeek V3 输出层的 RMSNorm 和 Linear 参数量是:

7168 和 129280 * 7168 = 926,686,208 (~0.9B)

总参数量

核对一下 DeepSeek V3 总参数量是否为 671B:

583,483,392 * 3 + 11,507,286,272 * 58 + 926,679,040 * 2 + 7168 = 671,026,419,200 (~671B)

核对一下 DeepSeek V3 激活参数量是否为 37B:

11,414,421,504 + 24,284,510,720 + 926,679,040 * 2 + 7168 = 37,552,297,472 (~37B)

这个与 README_WEIGHT.md 中提到的 36.7B 不同,我还没找到计算错误的地方。我理解也许是考虑到 embedding 层只是查表,并不是矩阵乘,所以实际激活参数是:

11,414,421,504 + 24,284,510,720 + 926,679,040 + 7168 + 7168 = 36,625,625,600 (~36.6B)

PS (20250208)

DeepSeek 更新了 README_WEIGHT.md ,激活参数量修正成了 36.6B,也去掉了包含 0.9B 输入 embedding 的注释。

MTP

DeepSeek V3 MTP 的 ebedding 和输出 head 与主模型共享,enorm 和 hnorm 的权重是:

7168 + 7168 = 14336

eh_proj 线性变换的权重规模是:

7168 * 14336 = 102,760,448

增加了一层 hidden layer,即第 61 层:

(48,760,320 + 20,906,496 + 117,440,512 + 14336) + (44,040,192 * 257 + 1,835,264) = 11,507,286,272

加起来 DeepSeek V3 MTP 的总参数量是:

11,507,286,272 + 102,760,448 + 14336 = 11,610,061,056 (~11.6B)

DeepSeek V3 MTP 的激活参数量是:

11,610,061,056 - 44,040,192 * (256 - 8) + 926,686,208 * 2 = 2,541,465,856

这个规模比 README_WEIGHT.md 中提到的 11.5B 独立参数,和 2.4B 激活参数都略大一点。

PS (20250208)

DeekSeek 更新了 README_WEIGHT.md ,MTP 的激活参数量由 2.4B 改成了 1.5B,可能跟上面的激活参数一样,都减去了 embedding 层。但在我的计算里,这个应该是 1.6B :),还是略有不同。

11,610,061,056 - 44,040,192 * (256 - 8) + 926,686,208 = 1,614,779,648 (~1.6B)

DeepSeek V3:AI 大模型 infra 基建新高度

AI 工程化

2021 年初,贾扬清在阿里云开始推广 AI 工程化这个概念,我非常认同。我在 21 年中做技术规划的时候,提出“AI 到生产力的转化,需要更高的工程化能力”,并且将 AI 工程化的实施总结为几大方向:

  • 语义索引场景化
  • 算力调度混合化
  • 模型研发标准化
  • 优化技术普惠化
  • 模型超大规模化
  • 架构系统智能化

我的 AI 工程化团队在这些方向上也取得了许多成果。

The AI Model

但 2022 年底 LLM 大流行以后,情况发生了一些变化。原因主要是 LLM 让 AI models 变成了 The AI model,虽然这个 model 很大,也多多少少有一些变种,但从工程实践的角度来看,它并不“复杂”。

很多时候,工程架构解决的是复杂性问题。

比如,TensorFlow、PyTorch、PaddlePaddle 这些训练框架简化了搭建和训练神经网络的复杂度,在一段时间内,各种结构的网络层出不穷,大部分都是依托这些框架来实现的。

而对于 LLM 来说,模型结构相对固定,虽然也使用了框架的一些外围能力,但是模型结构核心部分已经逐渐变成全手写以达成最佳性能,典型的实现包括 FlashAttention、TRT-LLM 等。

而且 LLM 的接口调用是自然语言,因而也变得极其简单,所有的 LLM 模型几乎可以使用同一套 API。

当时看起来 LLM 不需要太多的架构基建工作。

Prefix Caching 和 Kimi

我的这个认知在思考 prefix-caching 作用的时候,有了一些改变。

在《应该把 Prefix Caching 当作一种效果优化技术》这篇博客中,我提到 Prefix Cache Aware Scheduling 是一件非常值得做的事情。而且从 Kimi 发表的论文来看,他们已经在实践了,但其它的技术报告提到这些工程架构工作的不多。

DeepSeek V3

前几天 DeepSeek AI 发布了 DeepSeek V3 版本,我一边在吐槽这 670B 的模型参数太大,下载太慢,一边在阅读它的技术报告。结果发现他们在模型的部署上,玩得更高端,给了我一些新的震撼。

首先,prefilling 和 decoding 分开部署。prefilling 4 机 32 卡,decoding 40 机 320 卡。这样一来,我之前《LLM 推理优化 Continuous Batching 及其实现》这篇博客中提到的 Continuous Batching 就不再需要了。两阶段分开后,prefill 的计算过程(长度)是确定的,其算力利用是充分的,不再需要中间停下来插入新的请求。其实 prefilling 能够分开部署,跟 DeepSeek 以前的研究也是分不开的,DeepSeek V2 引入的 MLA 对 KV Cache 做了大幅度的低秩压缩,可以显著降低 KV Cache 从 prefilling 节点传递到 decoding 节点的带宽和延迟。

其次,MoE 专家分开部署。因为 MoE 专家的激活是 Token 级别的,也就是说每个 Token 会决定走哪个专家进行计算,分开部署就可能会带来负载均衡问题:有些专家太忙,有些专家太闲。DeepSeek V3 为了解决这个问题,还做了复杂的负载均衡策略。例如:快速识别较忙的专家,部署冗余的专家副本以承担压力;重新调整专家在不同节点的布局,尽量利用跨 GPU 带宽而减少跨节点带宽(因为 IB 比 NVLink 要慢);单卡冗余部署多专家,但通过全局的路由计算来优化专家的动态激活数量。

DeepSeek V3 还实现了计算和通信重叠。为了掩盖分布式计算过程中进行集合通信时的开销,将计算任务分为微批。一个微批进行集合通信时,进行下一个微批的计算。

此外,DeepSeek V3 在推理时还将 TP(Tensor)、DP(Data)、SP(Sequence)、EP(Expert)不同维度的并行化融合到了一起。单拿出来一种并行化方法也许现在的框架还是支持的,但这些方法组合在一起,我怀疑目前也没有什么推理加速框架能直接处理。

从技术报告中揭露的这些细节可以看出,为了发挥出模型的极致性能,DeepSeek 在 AI 大模型的分布式部署上花费了很大的心思。这也让 DeepSeek V3 成为目前公开资料可以看到的最复杂、最精巧的大模型 infra 设计

这些 idea 以前也许不是没有人想到,但是 infra 的演进是有很高研发和试错成本的。当 DeepSeek 将这些路走通以后,也许未来的很多大模型公司,大模型框架,都会往沿着这个方向继续演进。

700行代码帮你迈出打造专属Jarvis的第一步

前几天,Mark Zuckerberg 写了一篇博客《Building Jarvis》 ,立即风靡科技圈。智能家庭,Bill Gates 弄了一个,Zuckerberg 也搞了一个,科技圈的大佬们纷纷动手,让小民们看着很眼馋。

在《Building Jarvis》这篇文章中,Zuckerberg 写到:

These challenges always lead me to learn more than I expected, and this one also gave me a better sense of all the internal technology Facebook engineers get to use, as well as a thorough overview of home automation.

注意到这些酷炫的技术,都是 internal technology Facebook engineers get to use。那么到底有没有可能,使用公开领域的服务,构建一个类似于 Jarvis 的系统呢?

正好这段时间,我也在做一个基于人工智能技术的简单 APP:WhatIsWhat。这个 APP 目前很简单,甚至可以称得上简陋,但可能对你构建自己的 Jarvis 会有所帮助或启发。

什么是什么
什么是什么

背景

某天闲聊的时候,有个妈妈同事说,她家宝宝问她很多东西不懂,只好去搜索,发现百度百科的不少词条有个“秒懂百科”,用视频讲解百科词条,宝宝很爱看。只是可惜宝宝不认字,不会自己搜索。然后我就想,要是有个工具,能用语音问问题,语音或者视频回答问题,那挺不错啊,就有了这个 APP。

随着近几年语音识别准确率的大幅度提升,语音交互技术已经步入到非常成熟的阶段了。公开领域也有讯飞、百度等好几家免费服务可用,只是关注和使用这些的一般都是企业,个人开发者并不多。其实从我工作上的背景出发,语音交互背后的技术都是非常熟悉的。下面我就以我使用的百度语音开放平台为例,解释下能有哪些免费的语音交互服务可用。

语音识别

要想宝宝能使用语音问问题,首先需要有一个语音转文字的技术,我们一般称之为“语音识别”。从 20 世纪 70 年代 IBM 把 HMM 应用到语音识别技术上来以后,语音识别准确率一直在稳步提升。但到了 2000 年以后,语音识别的效果改进停滞了,而且一停就是 10 年。直到 2010年,Geoffrey Hinton、邓力和俞栋在微软研究院将深度学习引入语音识别技术后,平地一声惊雷,语音识别的准确率才又开始一次大跃进。

可以这样说,20 年前的语音识别和六七年前的语音识别,没有太大区别。但现在的语音识别技术,和六七年前的语音识别技术,是有革命性改进的。如果你还根据几年前的经验,认为语音识别是个 Tech Toy,识别结果充满了错漏。不妨试试最新的语音识别产品,比如讯飞语音输入法、百度语音搜索,结果会让你很吃惊的。

值得高兴的是,讯飞和百度都将最新的语音识别技术免费开放给所有人使用。比如百度的语音识别服务,单个应用每天可以免费调用 5 万次,而且可以通过申请提升这个免费上限。只需要到它的平台上注册成为开发者(不需要任何费用),申请新建一个应用,下载最新版的 SDK,参考文档集成到 APP 里就行了。

语音合成

如果想让手机使用语音回答问题,还需要一个文字转语音的技术,我们一般称之为“语音合成”或者“TTS”。语音合成在准确率方面的问题上,没有语音识别那么显著,但更大的困难来自于“怎么让机器发出的声音更像人声?”有很多个方面的考量,比如情绪、重音、停顿、语速、清晰度等等。现代的语音合成产品,一般都支持选择发声人(男声、女声、童声)和调整语速的功能。很多小说阅读器都配备的“语音朗读”,就是语音合成技术的典型应用。

讯飞和百度也都免费开放了自家的语音合成技术,也是类似于语音识别的SDK集成即可。值得一说的是,Google 在今年 9 月发表了自家的 WaveNets 语音合成模型,号称将 TTS 发声和人声的差距缩短了 50%(可以到这个页面体验一下),所以我们可以期待公开的语音合成服务效果有更进一步的改进。

WaveNets 效果
WaveNets 效果

语音唤醒

就像两个人交谈时你必须得称呼对方名字,他才知道你是在对他说话,机器也是一样。对着手机屏幕的时候,可以通过点击麦克风按钮来实现唤醒语音输入,但在远处或者不方便点击时(比如开车),需要用特定的指令唤醒它接收并处理你的输入。就像我们熟悉的“Hey,Siri”和“OK,Google”,我们一般称之为“语音唤醒”。

一般情况下,唤醒指令不依赖语音识别,也就是说,它纯粹是使用声学模型匹配你的声音。这样做也有好处,就是不依赖网络,待机功耗也更低。

讯飞的语音唤醒功能是收费的,但是百度的语音唤醒功能是免费的,可以定制自己的唤醒词,然后下载对应唤醒词的声学模型包,集成到语音识别 SDK 中即可。

如果希望打造一个专属的 Jarvis 的话,这个唤醒词声学模型最好是使用自己的语音训练出来的,这样召准率才能更高。但很遗憾,百度的免费语音唤醒还不支持这点,只能用百度语料库训练出来的模型。

自然语言理解

关于自然语言理解,Zuckerberg 的 《Building Jarvis》已经解释得非常充分了,这是一个非常复杂和困难的技术领域。讯飞和百度也都在自身语音识别能力基础上,开放了自然语言理解的能力。用户甚至可以在云端自定义自己的语义,这样识别后不仅能拿到一个纯文本识别结果,还可以获取结构化的分析后结果。

百度语义理解
百度语义理解

我对 WhatIsWhat 这个 APP 的要求很简单,只需要理解“什么是什么?”这个问题即可。我没有用到百度的语义理解能力,而是简单地写了一个正则表达式匹配,主要是希望后续能充分利用语音识别的 Partial Result 对性能进行优化。

问题回答

目前很多搜索引擎(比如谷歌、百度)对语音发起的搜索,在给出搜索结果的同时,往往附带着一句或者几句语音的回答。但搜索引擎针对的往往是开放领域的搜索词,所以语音回答的覆盖比例并不高。限定到“什么是什么”这个特定的领域,百度百科的满足比例就高了。尤其是秒懂百科,使用视频的方式讲解百科词条,样式非常新颖。

在这个最初的版本中,我只采取了秒懂百科的结果。也就是先抓取百科结果页,提取秒懂百科链接,然后打开秒懂百科结果页。为了让播放视频更方便,我用 WebView 执行了一个自动的点击事件,这样第一条视频结果在打开页面后会直接播放,不需要再点击。

演示视频

下面是“WhatIsWhat”这个 APP 的演示视频,请点击查看,因为录音设备的冲突,视频的后半部分没有声音,敬请谅解。

演示视频,点击查看

源代码地址

你可以到 https://github.com/solrex/WhatIsWhat 这个链接查看“WhatIsWhat”的全部源代码。代码总共 700 多行,不多,需要有一点儿 Android 和 Java 基础来理解。

总结

WhatIsWhat 是从一个朴素 idea 出发的非常简单的 APP,这个产品集成了“语音识别、语音合成、语音唤醒、自然语言理解”几类人工智能服务。想要实现 Jarvis,可能还需要人脸识别、智能对话、开放硬件 API 等几项能力,并且需要一定的工程能力将这些功能整合起来。

虽然 WhatIsWhat 与 Jarvis 的复杂度不可比,但它演示了如何使用公共领域已有的人工智能服务,构造一个落地可用的产品。更重要的是,它便宜到不需花一分钱,简单到只有 700 行代码。

就像 Zuckerberg 所说“In a way, AI is both closer and farther off than we imagine. ”虽然很多人并没有意识到语音交互这类 AI 技术能够那么地触手可及,但技术的开放对 AI 应用普及的影响是巨大的。在这一点上,国内的人工智能产业巨头们做得并不差。这篇文章,WhatIsWhat 这个 APP,只能帮你迈出第一步,希望不远的将来,我们能够有更多的开放 AI 服务,使得搭建自己的专属 Jarvis 变成一件轻而易举的事情。