夜雨聆风今天是2026年7月13日，星期一，北京，天气晴
来回顾文档多模态进展，讲的故事是模型推理加速。HunyuanOCR-1.5，轻量级且面向端到端 OCR 任务的视觉语言模型，将文档解析、文本定位、信息提取、文本图像转换以及多图像文档理解统一在一个单一的端到端视觉语言模型中，这个比较常规：
前代HunyuanOCR-1.0，验证了轻量化端到端统一OCR架构可行性，但存在推理延迟高、长尾任务数据不足、高分辨率/长上下文适配差、文档幻觉突出等短板，因此推出1.5版本做系统性升级。
工作在《HunyuanOCR-1.5: Making Lightweight OCR VLMs Faster and Better》，https://arxiv.org/pdf/2607.04884，https://huggingface.co/tencent/HunyuanOCR，https://github.com/Tencent-Hunyuan/HunyuanOCR。主要关注加速的方案DFlash推理加速，有一些结论，代表继续卷多模态OCR模型的方向，也就是加速。
一、文档多模态大模型进展之HunyuanOCR-1.5
端到端OCR生成表格、公式、长文档时自回归逐Token解码是主要延迟瓶颈，自回归解码的根本瓶颈不是计算量不够，而是计算资源被浪费在等待上。
也就是说，单请求场景下，GPU的算力大量闲置，因为每次只能生成一个token，内存带宽成为瓶颈。与其让GPU闲着，不如用一个轻量级草稿模型并行预测一批候选token，然后目标模型一次性验证；
这种做法，其实就是推测解码，推测解码（speculativedecoding）不是新概念。传统做法是：用一个小模型（draftmodel）自回归地生成几个候选token，然后让大模型（targetmodel）一次性验证。接受最长有效前缀，保证输出分布不变。
但这有一个根本矛盾：草稿模型如果是自回归的，生成k个候选token就需要k次前向传播。候选越多，草稿本身的开销越大，净收益递减。EAGLE、Medusa这些方法要么用多头预测（一次性出多个token但每个头独立），要么用树形草拟来缓解，但本质上都还是在自回归草拟框架内打转。
因此，DFlash换了一个思路：草稿模型不做自回归，做块扩散（blockdiffusion）。一次前向传播，直接出一整块B=16个候选token。
90.7M参数，5层Transformer，相对于0.5B的目标模型来说非常轻，初始化方式：直接从目标模型最后5个解码器层复制参数。这不是随机初始化，而是让草稿模型一开始就站在目标模型的肩膀上，只需要微调就能逼近目标模型的分布。
输入：目标模型在锚点位置的隐状态h（不是token，是隐状态，这很重要，意味着草稿模型可以直接看到目标模型的内部表示，而不只是输出token），输出：一次前向传播出B=16个token的候选块。
问题来了？为什么用隐状态而非token？因为token是离散的、有损的压缩，而隐状态保留了目标模型的完整上下文理解。草稿模型基于隐状态做预测，本质上是在目标模型的思路上做快速续写。
所以，至此，加速可以理解为将闲置的计算资源用于降低解码延迟。在单请求或低并发推理场景中，目标模型的自回归解码通常受内存带宽限制，导致大量计算资源未被充分利用。DFlash利用这些闲置的计算能力，通过轻量级的并行前向传播生成一批草稿 token，使得目标模型能够在一次前向传播中验证多个候选 token。因此，每次目标模型前向传播的有效接受 token 数量增加。
具体实现时，引入块扩散并行推测解码DFlash。草稿模型用块扩散（BlockDiffusion）90.7M参数，而非自回归，单次前向并行一次性生成16个候选Token块->主模型并行验证整块，一次性接受最长有效前缀，保留原始输出分布。
分训练和推理两个点：
1、训练怎么做的？
训练过程是论文里最密的部分，逐步拆：
Step1：目标模型前向，缓存隐状态。目标模型完全冻结，不更新参数。对每个训练序列，跑一次目标模型，把所有位置的隐状态缓存下来。
Step2：随机采样n=16个锚点位置。每个锚点对应一个独立的块草稿任务。也就是说，一条训练序列上，同时训练16个不同位置的续写能力。
Step3：FlexAttention块对角掩码并行训练。这是训练效率的核心。16个块被拼接成一条序列，在单次前向传播中训练。掩码规则：
每个块可以关注自己锚点之前的目标模型隐状态（条件信息）块内的token之间可以做因果注意力（块内自回归，但整体是并行前向）不同块之间完全隔离，块1看不到块2的token，损失函数使用位置加权的交叉熵。
2、推理怎么做的？
推理时是一个循环：
步骤1.目标模型在当前位置产生隐状态h—>步骤2.草稿模型以h为条件，一次前向传播出16个候选token—>步骤3.目标模型并行验证这16个token（一次前向传播）—>步骤4.接受最长有效前缀（从左到右第一个不匹配的位置截断）—>步骤5.接受的token拼入已生成序列，回到步骤1。
需要注意的是，有效接受长度（EffectiveAcceptanceLength）=8.89（Transformers）/8.36（vLLM）。意思是每次草稿-验证迭代平均推进约8-9个token，而不是AR的1个。
但注意：不是每次都推16个。是16个候选里平均接受8-9个。接受率约55%。
二、看提速效果的评估及几个结论
提速效果，来自评估HunyuanOCR-1.5 在 OmniDocBench 上使用标准自回归（AR）解码和 DFlash 加速解码的推理速度。
看几个结论：
1、整体推理速度对比
在批量大小为1的OmniDocBench 下，AR 与 DFlash 解码的对比
DFlash在Transformer和vLLM两种框架下均显著加速了HunyuanOCR-1.5。在vLLM中，DFlash将平均延迟从3.032秒降低至1.408秒，吞吐量从466.9token/s提升至1002.3token/s，并实现了2.14×倍的加速。在Transformer框架下，增益更为显著，因其AR基准更接近朴素的逐token解码，因而能从推测解码中获益更多。
2、横向对比SOTA OCR系统
将HunyuanOCR-1.5与DFlash同若干代表性OCR系统进行对比，包括两阶段流水线方法和端到端OCR视觉语言模型（VLM）。
具体的：该评估在相同的OmniDocBench测试集上、单请求推理模式下进行，每个系统均分配一个计算容量相当的加速器实例。对于两阶段系统GLM-OCR和PaddleOCR-VL-1.6，报告完整的页面级流水线延迟，涵盖版面分析、区域级OCR/VLM推理以及结果合并。由于不同系统采用不同的tokenizer、提示词（prompt）及输出格式，跨模型的token/s指标无法直接比较，因此主要对比平均延迟和页面吞吐量。
结论是：HunyuanOCR-1.5配合DFlash在所有评估系统中实现了最快的端到端推理速度，达到每页1.408秒，即0.706页/秒。其速度比GLM-OCR快约1.17×，比PaddleOCR-VL-1.6快1.24×，与其它OCRVLM相比，包括Unlimited-OCR、DeepSeek-OCR-2以及dots.ocr，HunyuanOCR-1.5配合DFlash分别将平均延迟降低了2.60×、3.88×和5.08×。
3、在不同输出长度范围内的加速效果
随着输出序列变长，加速比持续增加。
在 vLLM 中，DFlash 在 0–256 个 token 输出时的加速比为 1.31×，而在 2048+ 个 token 输出时提升至 2.30×；在 Transformers 中，加速比从 4.56× 增加到 6.67×。这与推测解码的特性相符：输出越长，所需的解码步骤越多，因此每次并行的草稿-验证迭代可以分摊更多的目标模型前向传播计算。而短输出则主要受预填充和固定开销的影响，限制了可达到的加速比。
4、不同内容类型下的推理速度对比
将 OmniDocBench 的页面分为文本、公式和表格三类，并报告各类别上的速度表现。
结论是结构化程度越高（表格>公式>纯文本），加速比越高，表格页获得的加速最大，其次是公式页和文本页。
根本原因：OCR 输出不是自然语言，是结构化文本。结构化文本的 token 预测难度远低于自然语言。
表格页加速 7.81×（Transformers），有效接受长度 10.40；公式页 6.14×，有效接受长度 8.59；纯文本页 5.63×，有效接受长度 7.68；
为什么表格最高？因为 HTML 表格的 token 序列高度规律化：<tr>后面几乎一定是<td>，<td>后面是内容然后</td>。草稿模型在这种位置几乎不会猜错，有效接受前缀自然就长。
而纯文本 OCR 的内容是自然语言，token 的不确定性更高，草稿命中率下降。
这里可以再深入下就是：对于具有强局部规律性的 OCR 输出（如 HTML 表格、公式和结构化 Markdown 解析结果），这种机制尤为有效，因为未来 token 更具可预测性，有效接受长度也更长。
因此，一句话总结就是：DFlash 的核心创新是把草稿模型从自回归换成块扩散，一次前向出 16 个候选 token，草稿成本不随候选数量线性增长。配合隐状态条件化、FlexAttention 并行训练、位置加权损失，在 OCR 这种结构化输出场景下实现了高接受率（~55%）。不改变输出分布，不增加推理时的显存压力，只是在 GPU 空闲的时候多做了一点有用的计算。
参考文献
1、https://arxiv.org/pdf/2607.04884
关于我们
老刘，主页：https://liuhuanyong.github.io。
对知识图谱本体论、Agent记忆及架构、RAG知识库等技术方向感兴趣，欢迎加入社区，社区持续纳新。
加入社区方式：关注公众号，在后台菜单栏中点击会员社区加入。