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个。

相关推荐
AI人工智能+12 小时前
文档抽取技术:通过OCR、NLP和机器学习技术,将非结构化的合同、发票等文档转化为结构化数据
人工智能·计算机视觉·nlp·ocr·文档抽取
ASKED_20191 天前
大模型 + 字形理解:Glyph-OCR 带来的 OCR 新范式
人工智能·深度学习·ocr
翔云 OCR API2 天前
表格识别接口技术解析:从传统OCR到智能识别的跃迁
ocr
EkihzniY2 天前
身份三要素认证:筑牢线上医疗人脸识别的安全根基
ocr
DARLING Zero two♡3 天前
用Rust构建一个OCR命令行工具
数据库·rust·ocr
余俊晖3 天前
文档图像旋转对VLM OCR的影响及基于Phi-3.5-Vision+分类头的文档方向分类器、及数据构建思路
人工智能·分类·ocr
翔云 OCR API3 天前
NFC护照鉴伪查验流程解析-ICAO9303护照真伪查验接口技术方案
开发语言·人工智能·python·计算机视觉·ocr
大模型实验室Lab4AI3 天前
【Github热门项目】DeepSeek-OCR项目上线即突破7k+星!突破10倍无损压缩,重新定义文本-视觉信息处理
人工智能·ocr·deepseek-ocr
AI人工智能+6 天前
从“海量文书”到“精准数据”:文档智能抽取重塑车险核心竞争力
nlp·ocr·文档抽取
Stara05116 天前
DeepSeek-OCR私有化部署—从零构建OCR服务环境
计算机视觉·docker·ocr·transformers·vllm·deepseek·光学符号识别