乐于分享
好东西不私藏

多模态文档解析开源新进展:HunyuanOCR-1.5引入DFlash实现推理加速技术方案

多模态文档解析开源新进展:HunyuanOCR-1.5引入DFlash实现推理加速技术方案

HunyuanOCR-1.5 在 HunyuanOCR-1.0【多模态文档解析模型新进展:腾讯开源HunyuanOCR-1B模型架构、训练配方】 的验证过架构基础上,不重新设计 backbone,只围绕两个目标做升级:

  • 引入 DFlash 推测解码:Transformers 推理 6.37× 加速;vLLM 上推理 2.14× 加速。
  • Agentic Data Flow + 训练配方升级,长尾能力扩展。

覆盖任务:文档解析、text spotting、信息抽取、图文翻译、多图文档理解,在单一端到端 VLM 中完成。

模型架构

沿用 HunyuanOCR-1.0 的三段式结构【Hunyuan-ViT(4K 原生分辨率) + Adaptive MLP Connector + Hunyuan-0.5B LLM】:

HunyuanOCR-1.5 模型架构
  • 视觉编码器最大分辨率从 2K → 4K:保留原生长宽比与空间布局,用于处理超密文档、超大表格、复杂图表。
  • MLP Connector:对高分辨率视觉 patch 做可学习池化与投影,压缩成紧凑的 visual tokens。
  • 语言模型:Hunyuan-0.5B,使用 XD-RoPE 编码 text / height / width / time 四个维度,天然支持多图 / 时序输入。
  • 端到端:图片 + 指令 → 直接输出 Markdown / HTML 表 / LaTeX 公式 / chart 描述,无任何 layout / detection / recognition 级联模块

DFlash 推理加速

为什么需要 DFlash

端到端 OCR 的痛点是长自回归解码

  • 密集文档、表格、公式、多列文档 → 输出序列很长;
  • AR decoding 在单请求 / 低并发场景下 memory-bandwidth-bound,算力大量闲置;
  • 传统推测解码(EAGLE 系列)虽然减少目标模型步数,但草稿模型本身仍是自回归的,草稿成本随候选数量线性增长,加速上限约 2–3×。
DFlash vs EAGLE-3 vs AR 解码的加速对比(Qwen3-8B,Transformers 后端)。DFlash 相比 EAGLE-3 平均高 2.5× 加速。
DFlash 的核心思想

DFlash 用一个轻量 block-diffusion 草稿模型,通过一次并行前向生成一整块候选 tokens,再交给目标模型并行验证。

推测解码 per-token latency:

其中  是每轮期望接受 token 数。DFlash 双管齐下:

  • 降低 :block diffusion 一次并行出  个候选,摆脱 AR 草稿的串行开销;
  • 提高 (接受长度):不像 EAGLE 只把 target hidden 作为输入嵌入,DFlash 把 target 的多层 hidden 特征融合后作为 K/V 直接注入草稿模型每一层(KV Injection)——"the target knows best"。
DFlash 推理设计

DFlash 推理流程。Target 抽出多层 hidden 特征 → 融合 → 注入到 draft 每一层的 KV cache,实现条件化并行 speculation。

三条设计要点:

  1. Context features from target model:prefill 阶段抽取多层 hidden,融合成 target context feature。
  2. KV Injection:这些特征投影后写入草稿模型 KV cache,跨迭代复用;草稿越深收益越大(EAGLE 加深反而增益递减)。
  3. Parallel diffusion drafting:block 内所有 mask 位置并行去噪,一次 forward 出块。
草稿延迟对比:1/3/5 层 DFlash 与 1 层 EAGLE-3 的草稿开销对比。得益于并行 forward,DFlash 即使更深也保持极低草稿延迟。

DFlash 在 HunyuanOCR-1.5 中的应用

(1)草稿模型规格
参数
参数量
约 90.7M
层数
5-layer Transformer
初始化
用 target 模型最后 5 层 decoder 权重初始化
Block size 
16
(一次并行出 16 个 token)
每序列 anchor 数 
16
损失衰减率 
7.0
(2)训练机制(target 冻结,只训 DFlash)

训练流程:

  • Step 1: 用 target model 跑一次完整序列,缓存 hidden states 作为条件表征
  • Step 2: 在序列上随机采 n=16 个 anchor 位置
  • Step 3: 每个 anchor 起一个独立的 block-drafting 任务, 用 mask tokens 填充 block 内其余位置
  • Step 4: 把 n 个 block 拼成一个 batch,一次 forward 训练

FlexAttention block-diagonal 掩码:每个 block 只能:

  • 看到 anchor 之前的 target hidden state;
  • 看到同一 block 内的 mask token 查询;
  • 跨 block 完全隔离,避免信息泄漏。
DFlash 训练注意力掩码

DFlash 训练时的稀疏注意力设计。Target 提供 context features(蓝色);每个 masked block 内,从 clean response 采样出 anchor(黄色)作为起点,其余 mask token(绿色)位置由 draft 并行预测;不同 block 之间通过 attention mask(白色)严格隔离。

HunyuanOCR-1.5 中的 block 掩码具体形式

HunyuanOCR-1.5 中 DFlash 的 block-diagonal 掩码可视化。n=16 个 anchor 位置各自领起一个 block,独立训练。

(3)损失函数(position-weighted next-token CE)

对第  个 anchor 内位置  的权重:

  • 排除 anchor 位置本身和无效位置;
  • 指数衰减:越靠后的位置权重越低(越难预测),越靠前的位置权重越高(早期错误会让整个 block 后续全部作废)。

损失:

其中  是 anchor 前的 target hidden, 是 block 内 mask token 查询。

不同 loss 权重对接受长度的影响:加位置衰减权重后收敛更快、最终接受长度更高
(4)推理阶段:draft-and-verify
[Prefill]     Target 跑一次 → 缓存 hidden features              ↓ 融合投影              注入到 draft 每层的 K/V cache[Loop]:   Draft:     draft 模型一次并行前向 → 输出 B=16 个候选 tokens   Verify:    target 模型一次并行前向验证整个 block              → 接受最长有效前缀(保持 target 分布不变)              → 未接受部分丢弃,下一轮以最新 accepted token 为新 anchor

关键性质:无损。target 分布保持不变,加速完全来自"用闲置算力换更少的 AR 步数"。

为什么 DFlash 对 OCR 特别有效

OCR 输出具有强局部规律性——HTML 表格 <td><tr>、LaTeX 公式、结构化 Markdown 都是高度可预测的:

  • 未来 token 更容易被草稿模型猜对 → 接受长度  更长
  • 输出越长,AR 步数越多,每一步都摊薄到"一次 verify 前进多 token"的收益 → 速度提升越明显

实验

整体速度对比:

指标
AR (vLLM)
DFlash (vLLM)
加速
Latency
3.032s
1.408s
2.14×
Throughput
466.9 token/s
1002.3 token/s

按输出长度看加速比(越长越明显):

输出长度
Transformers
vLLM
0–256
4.56×
1.31×
2048+
6.67×2.30×

按内容类型看加速比(结构越强越明显):

Table > Formula > Text(表格因为 HTML 结构最规整,接受长度最长)

与 SOTA OCR 系统对比:

单页 1.408s / 0.706 page/s,比 GLM-OCR 快 1.17×,比 PaddleOCR-VL-1.6 快 1.24×,比 dots.ocr 快 5.08×。

并发场景:

vLLM 并发 1–32 下始终 >1.8× 加速,并发=4 时最高 2.26×;并发再高时 GPU 饱和,闲置算力减少,加速比自然下降(这是推测解码的本质规律)。

部署支持:

除了 vLLM 服务端部署,还通过 llama.cpp 支持 PC 端(CPU / 消费级 GPU / 笔记本)部署。

Better:Agentic Data Flow + 训练配方升级

1 Agentic Data Flow:以模型弱点为导向的数据生产pipeline

不是"堆数据量",而是把模型能力缺口翻译成可执行的数据需求。Agent 被赋予工具调用能力(Web search / OCR / VLM / 脚本 / 图像清洗 / 数据生成),承担三类操作:

Agentic Data Flow 的闭环流水线。以模型弱点为起点 → agent 自动做素材搜集/清洗验证/pipeline 开发 → 算法工程师多轮迭代 → 数据回注训练。
操作
具体做的事
素材搜集与组织
低资源语言:找语料 + TTF 字体 + 背景;古文字:找 7 种历史汉字字体和古籍风格背景;多图 QA:搜集多页 PDF 并抽取 page-level 文本
工具辅助清洗与验证
用 HunyuanOCR-1.0 + Qwen3.5 双模型交叉验证背景图,过滤含干扰文本的背景;测试字体的语言渲染兼容性;批量跑 HunyuanOCR-1.0 挖 hard case(漏识别、结构混乱、表格解析失败、多列阅读顺序错)
弱点导向的 pipeline 开发迭代
自主写渲染 / QA 生成脚本,定义任务格式,接入布局、背景、退化增强、输出 schema,并与算法工程师多轮交互(demo → 反馈 → 修正)

2 三个具体落地场景

  • 低资源 OCR:合成覆盖 331 种语言的解析数据(灵感来自 SynthText / SynthDoG);
  • 古文字 OCR:聚焦 7 种历史汉字,覆盖不同书写方向、版式、退化;
  • 多图 QA:从多页 PDF 生成 cross-page 检索 / 对比 / 证据聚合 / 文档级推理问题,并过滤掉单页就能答的、答案与 PDF 上下文不一致的、无显式文本证据的样本。

3 训练配方升级(三阶段)

(1)Pretraining:重规划 Stage3
  • 数据:Agentic Data Flow 新数据 + 多图理解数据 + 1.0 的历史 OCR 数据混合训练(既扩边界又不掉旧能力);
  • 输入规格最大分辨率 → 4Kcontext window → 128K
(2)SFT:为 RL 打基础
  • 数据精炼:从 1.0 的 post-training 数据出发,剔除标注错误、格式不一致、图文不匹配、目标模糊、低质重复;补充 Agentic 新数据 + 用户 hard case + 新能力关键样本;
  • SFT / RL 数据分裂:难度高的样本留给 RL;
  • 统一 prompt 设计:每个任务能力对应专门 prompt,为 RL 阶段提供清晰的任务边界。
(3)RL:capability ceiling improvement

使用 IcePop(GRPO 变体,带 token 级 train–inference 校准比过滤),token-mean loss,包含三重奖励系统:

HunyuanOCR-1.5 的 RL 奖励系统。三条互补路径 —— Factuality-Oriented Reward(文档解析)+ Consistency-Based Judging Reward(通用 QA)+ Degeneration Suppression Reward(生成稳定性)

a. Factuality-Oriented Reward(文档解析)

  • Table,用 1D-probe 结构奖替代 TEDS-S,用 anchor-guided destylization 改进 TEDS 内容奖;
  • Chart:转 CSV 后用 SCRM 算 mAP,对行列顺序无关。

b. Consistency-Based Judging Reward(通用 QA)

  • VQA:LLM-as-judge 给 0/1;
  • Translation:辅助元数据(源语言文本 + 目标语言标签),soft score [0,5] 经 debiased 映射归一到 [0,1]。

c. Degeneration Suppression Reward(生成稳定性)

  • Overlong penalty:超长度上限直接给 0;
  • 重复片段检测:末尾单元长度 ≤ max_unit、连续重复 ≥ min_repeats 次的 rollout 给 0。

实验

参考文献

  • HunyuanOCR-1.5: Making Lightweight OCR VLMs Faster and Better,https://arxiv.org/abs/2607.04884
  • DFlash: Block Diffusion for Flash Speculative Decoding,https://arxiv.org/abs/2602.06036
  • HuggingFace: https://huggingface.co/tencent/HunyuanOCR
  • GitHub: https://github.com/Tencent-Hunyuan/HunyuanOCR

往期相关

多模态文档解析的开源项目模型技术方案都在《文档智能专栏》,如:

...