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

相关推荐
求真学习8 小时前
最新百度PaddleOCR开源HPD-Parsing,提出层级并行文档解析,1B模型解码步数最高压缩18倍,文档解析效率提升3倍!
百度·ocr·pdf解析·paddleocr·文档解析
Damon小智9 小时前
眼见不一定为实:WAIC 2026 探展合合信息,实测 AI 去反光 + AI 跨模态鉴伪两项黑科技
人工智能·ocr
山石满棠10 小时前
基于python313环境构建paddle-ocr镜像
ocr·paddle
AI人工智能+11 小时前
药品经营许可证识别技术,融合计算机视觉、自然语言处理和知识图谱,保障药品供应链安全,助力构建智慧药监体系。
深度学习·ocr·药品经营许可证识别
蓝创工坊Blue Foundry12 小时前
多个同模板 PDF,怎样批量提取同一类字段到 Excel
运维·数据库·pdf·自动化·ocr·excel
AI人工智能+1 天前
智能文档抽取系统采用“解析底座+大模型“双引擎架构,突破传统OCR局限
深度学习·ocr·文档抽取
蓝创工坊Blue Foundry1 天前
图片文字提取到 Excel:批量任务如何先定义要交付的字段
运维·服务器·开发语言·数据库·自动化·ocr·excel
求真学习1 天前
智谱联合清华开源GLM-OCR,0.9B参数配MTP多Token预测,文档解析吞吐量1.86页/秒,印章识别90.5分,第二名才42.2分
ocr·pdf解析·glm·文档解析·智谱
胡琦博客2 天前
HarmonyOS 智能工具箱(二):OCR 文字识别工具
华为·ocr·harmonyos
云间月13142 天前
搭一套截图识别通知机器人:OCR、飞书Webhook与远程触发实战
机器人·ocr·飞书