DeepSeek-OCR MoE结构梳理(其它LLM原理类似)

本文档参考DeepSeek-OCR LLM部分(DeepSeek-3B-MoE)前向推理流程解读。

网络结构高清大图,请在点击下载获取。

1. 采用64个专家模块(mlp),每个token推理激活6个专家模块。

2. prefill产生首token运行时流程

从流程图中可以明显看出,混合专家模块其实主要针对每个block的transformer模块中的计算量最大的Feed Forward(前馈网络,实际就是全连接+act)做选择,64个混合专家在903个输入token中每个token都被选择6个,即计算903x6次专家计算(Feed Forward),但如果是稠密模型则需要做903x64次FeedForward,计算量巨大。同时,在DeepSeek-3B-MoE中存在一个共享专家(Feed Forward)用于均衡信息。共享专家模块的全连接层维度更大,可以参考下面的ModuleList块,存在1280x6848的权重。而每个混合专家只有1280x896的权重,但64个混合专家权重会更多,所以混合专家模块MoE的主要目的是以空间换时间,更大内存的占用换取推理时更快的速度。

在DeepSeek-OCR中的3B-MoE模型的block为11(从1~11,第0个block为稠密模型),即11次稠密模型与11次混合专家带来的计算量的减少是巨大的。当然在其它模型算法中(比如Qwen 30B A3B模型中采用了128个专家模块,每次激活8个专家模块)。

另外,在prefill阶段,因为一般输入token数量大部分会大于64(本例中为903),所以基本上每个专家模块都会被不同的token所选中,所以大部分混合专家都会被激活。但是也不排除有特例,在prefill阶段存在没有被任何token选中的,那此时concat的输入个数就不固定了,但输出维度是一定的。

3. decode阶段解码时的MoE混合专家模块流程。

与prefill阶段类似,只不过prefill阶段903个token,在decode阶段每次只有一个token输入,即1x1x1280。另外,由于decode阶段每次输入一个token,所以混合专家每次只有6个被选中激活,即concat的输入个数固定为6个。

相关推荐
翔云 OCR API1 天前
API让文档信息“活”起来:通用文档识别接口-开发者文字识别API
前端·数据库·人工智能·mysql·ocr
Chunyyyen2 天前
【第二十六周】OCR学习01
学习·计算机视觉·ocr
恶猫3 天前
STranslate 翻译 工具 v2.0.0 绿色便携版 翻译、OCR工具
ocr·文字识别·自动翻译·翻译·划词翻译·截图翻译
垦***耪3 天前
台达 DVP ES2 与 3 台英威腾 GD 通讯程序(TDES - 12)开发实战
ocr
MonkeyKing_sunyuhua4 天前
使用ARQ做PDF OCR和 图片OCR的任务的方案
pdf·ocr
kevin 14 天前
合同盖章前,如何比对差异,确保纸质版与电子版100%一致?
人工智能·自动化·ocr
AI人工智能+4 天前
授权委托书识别技术:利用深度学习和NLP实现纸质文档的智能解析
ocr·文档抽取·授权委托书识别
大强同学4 天前
ShareX - 错误:英语 language is not available in this system for OCR.
ocr
不惑_5 天前
在 Rokid 眼镜上实现工业巡检与 OCR,识别、理解与指导的现场智能
ocr
翔云 OCR API5 天前
赋能文档的数字化智能处理:通用文字/文档/合同识别接口
开发语言·人工智能·python·计算机视觉·ocr