文章目录HunyuanOCR-1.5技术解析腾讯混元端到端OCR大模型的架构原理与部署实践一、引言二、从 HunyuanOCR-1.0 到 1.5为什么不重做主干2.1 从模块级联到统一生成2.2 版本演进背后的决策三、模型架构1B 参数如何处理整页文档3.1 三段式端到端主干3.2 4K 与 128K 解决什么问题3.3 十二类官方任务接口四、DFlash把逐 token 等待改成并行起草与验证4.1 OCR 为什么特别适合投机解码4.2 为什么可以称为“无损加速”4.3 加速效果如何解读五、Agentic Data Flow围绕模型短板造数据5.1 数据工程从“堆数量”转向“修能力缺口”5.2 三类代表性长尾数据六、训练配方预训练、SFT 与任务化强化学习6.1 重新规划预训练 Stage 36.2 SFT 为 RL 建立稳定接口6.3 OCR 奖励不能只看编辑距离七、部署实践vLLM、DFlash 与 llama.cpp 怎么选7.1 服务器端快速启动7.2 PC 与笔记本部署7.3 上线前的最小验收集八、评测结果看清模型强项也看清指标边界8.1 文档解析与长尾能力8.2 幻觉仍是端到端 OCR 的硬问题九、横向对比HunyuanOCR-1.5 处在什么位置9.1 同赛道方案对比9.2 它的生态位与真实取舍十、许可证、局限与选型建议10.1 开源不等于无限制商用10.2 选型建议十一、总结十二、参考资料HunyuanOCR-1.5技术解析腾讯混元端到端OCR大模型的架构原理与部署实践一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.comOCR 正从“把图片里的字抄出来”走向“把一页复杂文档还原成机器可用的结构”。后者不仅要识别字符还要理解阅读顺序区分正文、公式、表格与图表并按 Markdown、HTML、LaTeX 等格式稳定生成结果。传统流水线通常将版面分析、区域裁剪、文字识别和结构恢复拆成多个模块任何一环出错误差都会传到下游。腾讯混元于 2026 年 7 月发布的HunyuanOCR-1.5官方仓库中部分资源也使用“HyOCR-1.5”简称。它延续 1.0 版的 1B 轻量化端到端架构没有为了追逐参数规模重做主干而是回答了两个更接近工程的问题长文档如何更快生成以及模型如何补齐古文字、低资源语言、多图问答等长尾能力。这次升级的四个关键词是DFlash 投机解码、Agentic Data Flow、4K/128K 输入规格以及面向 OCR 任务设计的强化学习。本文将沿版本演进、模型架构、数据与训练、推理部署、评测和竞品格局展开分析。二、从 HunyuanOCR-1.0 到 1.5为什么不重做主干2.1 从模块级联到统一生成传统 OCR 系统的优势是模块边界清晰检测器、识别器和版面模型都可以单独调优弱点则是流程长、规则多跨区域关系与整页阅读顺序容易在切图过程中丢失。OCR 专用 VLM 选择另一条路直接接收整页图像与任务指令生成结构化文本。传统级联图像 - 版面检测 - 区域裁剪 - OCR - 顺序恢复 - 格式拼装 | | | ------ 误差逐级传播 ---- 端到端 VLM图像 指令 - 视觉编码与语言建模 - Markdown / HTML / LaTeX / JSONHunyuanOCR-1.0 于 2025 年 11 月开放权重和推理代码用约 1B 参数统一承载文档解析、文字检测识别、信息抽取、字幕提取和图文翻译。它先证明“小而专”的端到端模型可以成立1.5 版才进一步优化能力边界与部署效率。2.2 版本演进背后的决策时间关键节点技术含义2025 年 11 月HunyuanOCR-1.0 开放权重与推理代码用 1B 端到端 VLM 覆盖多类 OCR 任务2026 年 1 月发布 1.0 在线 Demo降低体验门槛验证真实输入分布2026 年 4—6 月发布文档、翻译、古文字与图表相关论文和基准从通用 OCR 指标转向复杂结构与长尾能力2026 年 7 月 7 日HunyuanOCR-1.5 发布加入 DFlash、Agentic Data Flow提升至 4K/128K2026 年 7 月 13 日开源 CHAOS-Bench用字符篡改检验模型是否忠实于视觉证据2026 年 7 月 24 日开源统一推理环境与 verl RL 配套从“开放权重”推进到可训练、可复现的工程栈1.5 版不重做主干是一个务实选择。1.0 的轻量化架构已验证有效继续扩大主干会重新引入训练成本、推理延迟和回归风险。腾讯混元选择把资源放到数据、输入规格、后训练与解码器上因此它更像一次系统升级而不是换模型名字的架构重启。三、模型架构1B 参数如何处理整页文档3.1 三段式端到端主干HunyuanOCR-1.5 的目标模型保持约 1B 参数核心由三部分构成┌──────────────────────────────────────────────────────────┐ │ 图像 / 多图输入文档、票据、表格、图表、街景、古籍 │ └───────────────────────────┬──────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────┐ │ 原生分辨率 Hunyuan-ViT │ │ 保留原始宽高比与空间布局最大输入分辨率由 2K 提升到 4K │ └───────────────────────────┬──────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────┐ │ Adaptive MLP Connector │ │ 对高分辨率视觉特征做可学习压缩生成紧凑视觉 token │ └───────────────────────────┬──────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────┐ │ Hunyuan-0.5B XD-RoPE最大上下文 128K │ │ 自回归生成 Markdown / HTML / LaTeX / JSON / 翻译结果 │ └──────────────────────────────────────────────────────────┘原生分辨率视觉编码器不会强行把长票据或宽表格拉伸成固定正方形有利于保存字符形状与二维布局。Adaptive MLP 则在信息保真与 token 数量之间做压缩。语言端使用轻量 Hunyuan-0.5B并借助 XD-RoPE 对文本、高度、宽度和时间等维度建模。这里的“端到端”不是完全没有后处理而是指核心识别与结构恢复不依赖独立的检测、切图和区域 OCR 模型。3.2 4K 与 128K 解决什么问题升级直接收益需要注意的成本最大图像分辨率 2K - 4K小字号、密集表格、复杂图表保留更多视觉细节视觉 token、显存和预填充时间增加上下文窗口扩展到 128K支持长结构输出、多页或多图上下文长上下文并不等于每次都应拉满吞吐会下降多图训练数据从单页解析扩展到跨页检索、比较与证据聚合需要可靠的页序与证据标注4K 解决“看不清”128K 解决“装不下”。二者同时升级才使多页文档理解成为可训练的能力而不只是接口允许传多张图片。3.3 十二类官方任务接口官方统一推理代码将提示词收敛为 12 个任务类型避免用户随意改写 prompt 导致性能漂移。能力组任务类型典型输出文档解析doc_parse、layout_parse、layoutMarkdown 正文、HTML 表格、LaTeX 公式、版面信息文字识别structured_parse、spotting_json、spotting_hunyuan纯文本或带归一化坐标的 JSON专项解析table、formula、chart_parseHTML、LaTeX、Markdown 或 Mermaid图文翻译doc_trans_en2zh、trans_other2en、trans_other2zh保留结构的中英文译文这种“固定任务路由”牺牲了一点提示词自由度却换来更稳定的线上行为。对于需要可回归测试的 OCR 服务这通常是更合理的接口设计。四、DFlash把逐 token 等待改成并行起草与验证4.1 OCR 为什么特别适合投机解码端到端文档解析的瓶颈常常不在图像编码而在长文本的自回归生成。标准 AR 解码每次只生成一个 token一页含大量 HTML 表格或 LaTeX 公式时GPU 需要反复读取模型权重而单请求又难以用满计算单元。DFlash 增加一个约90.7M 参数、5 层 Transformer的块扩散草稿模型。它以目标模型的隐藏状态为条件一次并行提出最多 16 个候选 token再由目标模型并行验证并接受最长正确前缀。目标模型已生成 y1 y2 ... yt | v DFlash 草稿模型 [c1 c2 c3 ... c16] 一次并行生成候选块 | v 目标模型验证 [✓ ✓ ✓ ✓ ✗ ...] 接受最长有效前缀 | v 下一轮从 yt4 继续而不是逐个走完 4 次目标模型前向训练 DFlash 时目标模型冻结只优化草稿模型。官方实现设置块大小B16每条序列采样 16 个锚点使用 FlexAttention 的块对角掩码隔离不同草稿任务。5 层草稿网络由目标模型最后 5 个解码层初始化。4.2 为什么可以称为“无损加速”投机解码的候选最终仍由目标模型验证因此理论上保持目标模型的输出分布草稿错了只会少接受几个 token不会把未经验证的内容直接写入结果。官方在 OmniDocBench 速度测试中报告DFlash 与 AR 的总输出 token 差异小于 0.15%。但“无损”不应误读为所有部署配置都会逐字符完全一致。框架版本、浮点精度、采样参数、图像预处理和后处理都可能造成差异因此上线前仍要用自己的文档集做精度回归。4.3 加速效果如何解读官方在单张 NVIDIA H20 80GB、并发 1、max_tokens8000的条件下测试推理框架AR 平均延迟DFlash 平均延迟AR Page/sDFlash Page/s加速比Transformers34.850 秒5.474 秒0.0290.1836.37 倍vLLM3.032 秒1.408 秒0.3300.7062.14 倍vLLM 的基线本来就经过服务优化因此相对加速低于原生 Transformers。输出越长、结构越规则DFlash 越有效官方 vLLM 测试中0—256 token 的加速为 1.31 倍超过 2048 token 后为 2.30 倍表格页达到 2.39 倍高于公式页的 2.06 倍和文本页的 1.81 倍。原因并不神秘HTML 标签和表格结构更容易被草稿模型预测。五、Agentic Data Flow围绕模型短板造数据5.1 数据工程从“堆数量”转向“修能力缺口”Agentic Data Flow 不是让 Agent 独立决定训练目标而是算法工程师提出明确能力缺口Agent 调用搜索、OCR/VLM 服务、文件处理、图像清洗与数据生成工具完成材料收集、质量验证和脚本开发再由工程师检查中间样本并追加约束。模型失败样本 / 能力缺口 | v 工程师定义数据需求 ----------------------------- | | v | Agent 拆解任务 - 搜索语料/字体/PDF/背景 - 工具校验 | | v | 生成与清洗脚本 - 初始样本 - 人工检查与规则修订 -- | v 可复用数据流水线 - 预训练 / SFT / RL - 新一轮评测5.2 三类代表性长尾数据能力缺口Agent 参与的工作训练目标低资源语言搜索多语种语料和 TTF 字体验证字符覆盖组合背景与退化效果论文报告构造覆盖 331 种语言的解析数据古文字搜索“汉字七体”字体与古籍背景多模型过滤干扰文字生成不同书写方向和版式提升甲骨、金文、篆、隶、楷、行、草等字形感知多图问答收集多页 PDF提取页级文本生成跨页检索、比较和证据聚合问题过滤单页可回答或缺少文本证据的样本它的价值不在“Agent”这个名字而在于把一次性的采数脚本沉淀为可复用项目并让模型失败分析与数据生产形成短周期迭代。风险也同样明确网络素材的版权、字体许可证、合成分布偏差以及教师模型错误都不会因为自动化而自动消失。六、训练配方预训练、SFT 与任务化强化学习6.1 重新规划预训练 Stage 3HunyuanOCR-1.5 复用 1.0 的前两个预训练阶段只重做 Stage 3。新阶段混合 Agentic Data Flow 生成的能力数据、多图理解数据与 1.0 历史 OCR 数据。保留旧数据的目的是在扩展古文字、低资源语言和多图能力时减少通用 OCR 与结构化输出退化。6.2 SFT 为 RL 建立稳定接口SFT 阶段清理标注错误、格式不一致、图文错配、任务目标含混和低质量重复样本再加入用户困难样本与新增能力数据。整理后的数据被拆成互不重叠的两部分普通样本用于 SFT高难样本留给 RL。各任务使用固定的专用提示词使奖励函数知道自己在评价哪一种输出结构。开源训练脚本支持视觉编码器、连接器和语言模型的全量端到端 SFT。默认示例将多条 OCR 样本打包到20480token以减少 padding 浪费MODEL_PATH/path/to/HunyuanOCR/base/model\TRAIN_DATA./data/parsing_packed_20480.jsonl\NPROC_PER_NODE8\bashscripts/sft_base.sh6.3 OCR 奖励不能只看编辑距离HunyuanOCR-1.5 使用 IcePop一种 GRPO 风格的策略优化变体通过 token 级校准掩码缓解训练引擎与推理引擎之间的概率偏差。每个候选问题先执行 16 次 on-policy rollout已经稳定答对的简单样本会被过滤使计算集中到有奖励方差的困难样本。奖励组件解决的问题主要方法能力路由、结构感知规则奖励文本、表格、图表不能用同一指标评价文本用归一化编辑距离表格结合内容与结构图表使用结构化语义指标一致性 Judge 奖励VQA、翻译等开放答案难写死规则由 Judge 比较回答与高质量参考的一致性退化抑制奖励长输出容易重复、循环或失控超长输出置零检测尾部重复片段并惩罚这套设计体现了 OCR 强化学习的关键模型不仅要“语言通顺”更要忠实转录视觉证据并满足严格格式。表格结构正确但单元格内容错误和内容正确但合并关系错误是两种不同失败奖励也应分别反馈。七、部署实践vLLM、DFlash 与 llama.cpp 怎么选7.1 服务器端快速启动官方统一环境基于 Python 3.12、CUDA 13 和vLLM0.25.1同一套环境可运行 vLLM AR、DFlash 和原生 Transformers。权重同时包含主模型与dflash/草稿模型。pipinstalluv uv venv--python3.12source.venv/bin/activate uv pipinstallvllm0.25.1uv pipinstall--no-build-isolation --no-cache-dirflash-attn2.8.3huggingface-cli download tencent/HunyuanOCR\--local-dir ./HunyuanOCR--excludev1.0/*MODEL_PATH./HunyuanOCRGPU0PORT8000\bashinference/vLLM/serve.sh调用端不要自己拼一套相似提示词直接使用官方任务类型python inference/vLLM/infer_vllm_client.py\--image/path/to/document.png\--task-type doc_parse\--modeltencent/HunyuanOCR\--port8000\--max-tokens32768启用 DFlash 时将服务脚本换为MODEL_PATH./HunyuanOCRGPU0PORT8000\bashinference/DFlash/serve_DFlash.sh统一环境要求 CUDA 13但官方文档也提供 CUDA 12.x 下仅运行 vLLM AR 的独立方案。生产环境应固定依赖版本并以相同图像预处理、任务 prompt、采样参数和后处理做回归测试。7.2 PC 与笔记本部署HunyuanOCR-1.5 已支持将主模型与视觉投影转换为 GGUF通过社区版llama.cpp的 OpenAI 兼容llama-server运行在 CPU、消费级 GPU 或笔记本上。DFlash 需要腾讯文档指定的适配分支尚未合入上游官方同时提示该分支仍有已知问题。部署路径适用场景优点主要限制vLLM ARGPU 服务、批量 API生态成熟吞吐稳定长输出逐 token 解码仍有延迟vLLM DFlash单请求或低并发长文档官方测试端到端加速明显统一环境需要 CUDA 13增加草稿模型Transformers精度对齐、研发验证路径直接方便调试原生逐 token 推理较慢llama.cpp本地离线、消费级设备GGUF、本地隐私、OpenAI 兼容接口量化精度需实测DFlash 分支尚未上游化7.3 上线前的最小验收集不要只拿清晰论文页测 OCR。一个可用的验收集至少应覆盖无文字图片、小字号密集页、跨栏阅读顺序、合并单元格、长公式、倾斜与拍照畸变、多语言混排、超过 2K token 的长输出以及业务中最常见的票据或卡证。还要分别统计字符正确率、结构正确率、幻觉率、尾部重复率、P50/P95 延迟和失败重试率。八、评测结果看清模型强项也看清指标边界8.1 文档解析与长尾能力以下均为 HunyuanOCR-1.5 技术报告中的结果不应直接外推到不同硬件、量化版本或私有数据集。评测集关注能力HunyuanOCR-1.5 结果官方结论OmniDocBench v1.6整页文档解析Overall 94.74端到端 OCR 专家模型中最高MORE149 种语言的低资源解析Overall 91.90OCR 专家模型中最高Chronicles-OCR汉字七体古文字解析古体平均 0.54成熟字体平均 0.791B 模型取得显著优势TableVerse-5K复杂表格恢复TEDS 78.23TEDS-S 84.84专家 OCR 模型中表现领先ChartArena中英文图表结构化解析英文平均 48.9中文平均 64.1以 1B 规模接近或超过多款更大模型DUDE 验证集多图文档问答54.64接近 Qwen3.5-0.8B 的 56.41CHAOS-Bench视觉证据与语言先验冲突Page-avg Recall 14.15对比模型中最高但绝对值仍低OmniDocBench 的 94.74 很亮眼但技术报告也指出一个评测错位HunyuanOCR 倾向于把多行公式作为完整 LaTeX 块输出而现有匹配协议会把独立多行公式拆成单行后再比对可能低估其公式能力。这提醒我们结构化生成模型的输出语义与基准匹配规则必须一起看。8.2 幻觉仍是端到端 OCR 的硬问题CHAOS-Bench 会把论文图像里的单词替换成无意义字符观察模型是忠实抄录“眼睛看到的错词”还是被语言先验纠正成合理单词。HunyuanOCR-1.5 的 14.15 虽明显高于报告中其他对比模型的 3.02—6.33但绝对召回率仍然很低。这说明 VLM OCR 的结构理解与语言纠错既是优势也是风险。合同编号、药品剂量、序列号、财务数字等字段不能依靠语义“猜对”必须增加规则校验、置信度门控或人工复核。模型还在 1000 张无文字内部测试图上将正确拒识率从 1.0 的 78.1% 提升到 99.8%但内部集结果仍需在业务分布上重新验证。九、横向对比HunyuanOCR-1.5 处在什么位置9.1 同赛道方案对比模型/方案参数规模技术路线OmniDocBench v1.6 Overall官方同硬件延迟更适合谁HunyuanOCR-1.51.0B 90.7M DFlash单模型端到端 投机解码94.741.408 秒/页DFlash需要轻量、整页、多任务和低延迟的团队Unlimited-OCR3B-A0.5B端到端、图像切片93.923.659 秒/页重视复杂文档解析与切片策略的场景DeepSeek-OCR 23B端到端 grounding90.255.460 秒/页需要 grounding 路线与较大模型能力的研究者dots.ocr3B单模型端到端90.777.154 秒/页看重结构化输出与成熟社区实践的用户PaddleOCR-VL-1.60.9B版面分析 区域 VLM 两阶段论文表中未列该 Overall1.744 秒/页接受流水线、希望利用 PaddleOCR 工程生态的团队GLM-OCR论文速度表未给出Layout 区域 OCR 并行流水线论文表中未列该 Overall1.649 秒/页更偏向高吞吐页面流水线的服务场景表中的速度来自 HunyuanOCR 报告在相同 H20 80GB、并发 1 条件下的复现各模型使用各自原生 prompt。由于 tokenizer 和输出格式不同Page/s 比 Token/s 更适合跨模型比较。模型方自报结果仍应被视为选型线索而不是替代第三方测试。9.2 它的生态位与真实取舍HunyuanOCR-1.5 的独特位置不是单项识别指标而是同时满足四件事约 1B 参数、整页端到端、多 OCR 任务统一、长输出投机加速。相比两阶段流水线它减少了版面切分和结果拼装相比 3B 端到端模型它更容易部署相比通用 VLM它把参数与训练预算集中在文字密集场景。代价也很具体。端到端生成的错误不如传统模块容易定位DFlash 在高并发下可利用的空闲算力减少4K/128K 会推高最坏情况资源消耗PC 端 DFlash 仍依赖未上游的分支自定义社区许可证也不能按 MIT 或 Apache 2.0 来理解。十、许可证、局限与选型建议10.1 开源不等于无限制商用HunyuanOCR-1.5 使用Tencent Hunyuan Community License Agreement而非 OSI 常见的 Apache 2.0 或 MIT 许可证。部署前至少要注意以下条款条款工程影响授权地域排除欧盟、英国与韩国在这些地区使用、分发或提供服务不在该协议授权范围内月活超过 1 亿的主体需另行申请许可大型平台不能仅凭社区许可证直接上线分发时需附协议、修改声明与 Notice镜像、模型衍生物和交付包要保留合规材料不得用模型或输出改进其他非混元模型数据回流、蒸馏和教师模型流程需要法律审查高风险决策、军事用途等受可接受使用政策限制业务用途必须逐项核对不应只看模型卡摘要本文是技术解读不构成法律意见。涉及跨区域服务、模型再分发或训练数据回流时应以仓库内最新 LICENSE 原文和专业法务意见为准。10.2 选型建议场景建议本地批量解析论文、合同、表格优先测试 vLLM DFlash并对长页统计 P95 延迟笔记本离线识别、隐私敏感资料评估 llama.cpp GGUF量化后重新测小字号和数字字段已有成熟 PaddleOCR 流水线不必为了“端到端”立即重构先在复杂跨栏和长表格上做 A/B 测试卡证、财务、医疗等高准确字段模型抽取后增加正则、字典、交叉字段校验与人工复核多页文档问答先做页级检索缩小上下文再让模型跨页回答并返回证据页欧盟、英国或韩国业务当前社区许可证存在明确地域排除应先解决授权问题十一、总结维度核心要点架构约 1B 参数由原生分辨率 Hunyuan-ViT、Adaptive MLP 与 Hunyuan-0.5B 组成输入能力最大图像分辨率从 2K 提升至 4K上下文扩展到 128K支持多图文档理解推理90.7M DFlash 草稿模型并行起草 16-token 块官方 vLLM 测试加速 2.14 倍数据Agentic Data Flow 围绕低资源语言、古文字和多图 QA 构造可复用数据流水线训练重做预训练 Stage 3清洗并拆分 SFT/RL 数据使用 IcePop 与结构感知奖励工程开放 SFT、DFlash、verl RL、Transformers、vLLM 与 llama.cpp 相关代码风险幻觉仍未解决DFlash 收益依赖负载社区许可证包含地域和用途限制HunyuanOCR-1.5 代表的不是“用更大模型替代 OCR”而是一条更克制的路线保持主干轻量把高分辨率视觉、长上下文、针对性数据、结构化奖励与解码加速组合成完整系统。它在 1B 规模上把整页解析、长尾文字、多图理解和本地部署放到同一张工程地图中。更值得关注的趋势是OCR 竞争正在从单纯的字符准确率转向三个联合指标结构忠实度、端到端页面延迟以及对视觉证据的服从程度。HunyuanOCR-1.5 在前两项给出了有竞争力的结果也用 CHAOS-Bench 坦率暴露了第三项仍然艰难。对实际使用者而言最合理的态度不是只看 SOTA而是拿业务中的坏图、长表、错词和无文字图片做一轮可复现的精度、速度与合规评估。十二、参考资料HunyuanOCR-1.5 官方 GitHub 仓库 — Tencent HunyuanHunyuanOCR-1.5: Making Lightweight OCR VLMs Faster and Better — arXiv, 2026HunyuanOCR 模型权重与模型卡 — Hugging FaceHunyuanOCR-1.5 推理指南 — Tencent HunyuanHunyuanOCR-1.5 速度基准 — Tencent HunyuanHunyuanOCR-1.5 PC 端 llama.cpp 部署指南 — Tencent HunyuanHunyuanOCR-1.5 强化学习训练配套 — Tencent HunyuanCHAOS-BenchOCR VLM 字符级幻觉评测 — Tencent HunyuanHunyuanOCR Technical Report — arXiv, 2025DFlash: Block Diffusion for Speculative DecodingOmniDocBench 官方仓库 — OpenDataLabTencent Hunyuan Community License Agreement
【HunyuanOCR-1.5技术解析】腾讯混元端到端OCR大模型的架构原理与部署实践
发布时间：2026/7/28 13:46:38
文章目录HunyuanOCR-1.5技术解析腾讯混元端到端OCR大模型的架构原理与部署实践一、引言二、从 HunyuanOCR-1.0 到 1.5为什么不重做主干2.1 从模块级联到统一生成2.2 版本演进背后的决策三、模型架构1B 参数如何处理整页文档3.1 三段式端到端主干3.2 4K 与 128K 解决什么问题3.3 十二类官方任务接口四、DFlash把逐 token 等待改成并行起草与验证4.1 OCR 为什么特别适合投机解码4.2 为什么可以称为“无损加速”4.3 加速效果如何解读五、Agentic Data Flow围绕模型短板造数据5.1 数据工程从“堆数量”转向“修能力缺口”5.2 三类代表性长尾数据六、训练配方预训练、SFT 与任务化强化学习6.1 重新规划预训练 Stage 36.2 SFT 为 RL 建立稳定接口6.3 OCR 奖励不能只看编辑距离七、部署实践vLLM、DFlash 与 llama.cpp 怎么选7.1 服务器端快速启动7.2 PC 与笔记本部署7.3 上线前的最小验收集八、评测结果看清模型强项也看清指标边界8.1 文档解析与长尾能力8.2 幻觉仍是端到端 OCR 的硬问题九、横向对比HunyuanOCR-1.5 处在什么位置9.1 同赛道方案对比9.2 它的生态位与真实取舍十、许可证、局限与选型建议10.1 开源不等于无限制商用10.2 选型建议十一、总结十二、参考资料HunyuanOCR-1.5技术解析腾讯混元端到端OCR大模型的架构原理与部署实践一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.comOCR 正从“把图片里的字抄出来”走向“把一页复杂文档还原成机器可用的结构”。后者不仅要识别字符还要理解阅读顺序区分正文、公式、表格与图表并按 Markdown、HTML、LaTeX 等格式稳定生成结果。传统流水线通常将版面分析、区域裁剪、文字识别和结构恢复拆成多个模块任何一环出错误差都会传到下游。腾讯混元于 2026 年 7 月发布的HunyuanOCR-1.5官方仓库中部分资源也使用“HyOCR-1.5”简称。它延续 1.0 版的 1B 轻量化端到端架构没有为了追逐参数规模重做主干而是回答了两个更接近工程的问题长文档如何更快生成以及模型如何补齐古文字、低资源语言、多图问答等长尾能力。这次升级的四个关键词是DFlash 投机解码、Agentic Data Flow、4K/128K 输入规格以及面向 OCR 任务设计的强化学习。本文将沿版本演进、模型架构、数据与训练、推理部署、评测和竞品格局展开分析。二、从 HunyuanOCR-1.0 到 1.5为什么不重做主干2.1 从模块级联到统一生成传统 OCR 系统的优势是模块边界清晰检测器、识别器和版面模型都可以单独调优弱点则是流程长、规则多跨区域关系与整页阅读顺序容易在切图过程中丢失。OCR 专用 VLM 选择另一条路直接接收整页图像与任务指令生成结构化文本。传统级联图像 - 版面检测 - 区域裁剪 - OCR - 顺序恢复 - 格式拼装 | | | ------ 误差逐级传播 ---- 端到端 VLM图像 指令 - 视觉编码与语言建模 - Markdown / HTML / LaTeX / JSONHunyuanOCR-1.0 于 2025 年 11 月开放权重和推理代码用约 1B 参数统一承载文档解析、文字检测识别、信息抽取、字幕提取和图文翻译。它先证明“小而专”的端到端模型可以成立1.5 版才进一步优化能力边界与部署效率。2.2 版本演进背后的决策时间关键节点技术含义2025 年 11 月HunyuanOCR-1.0 开放权重与推理代码用 1B 端到端 VLM 覆盖多类 OCR 任务2026 年 1 月发布 1.0 在线 Demo降低体验门槛验证真实输入分布2026 年 4—6 月发布文档、翻译、古文字与图表相关论文和基准从通用 OCR 指标转向复杂结构与长尾能力2026 年 7 月 7 日HunyuanOCR-1.5 发布加入 DFlash、Agentic Data Flow提升至 4K/128K2026 年 7 月 13 日开源 CHAOS-Bench用字符篡改检验模型是否忠实于视觉证据2026 年 7 月 24 日开源统一推理环境与 verl RL 配套从“开放权重”推进到可训练、可复现的工程栈1.5 版不重做主干是一个务实选择。1.0 的轻量化架构已验证有效继续扩大主干会重新引入训练成本、推理延迟和回归风险。腾讯混元选择把资源放到数据、输入规格、后训练与解码器上因此它更像一次系统升级而不是换模型名字的架构重启。三、模型架构1B 参数如何处理整页文档3.1 三段式端到端主干HunyuanOCR-1.5 的目标模型保持约 1B 参数核心由三部分构成┌──────────────────────────────────────────────────────────┐ │ 图像 / 多图输入文档、票据、表格、图表、街景、古籍 │ └───────────────────────────┬──────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────┐ │ 原生分辨率 Hunyuan-ViT │ │ 保留原始宽高比与空间布局最大输入分辨率由 2K 提升到 4K │ └───────────────────────────┬──────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────┐ │ Adaptive MLP Connector │ │ 对高分辨率视觉特征做可学习压缩生成紧凑视觉 token │ └───────────────────────────┬──────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────┐ │ Hunyuan-0.5B XD-RoPE最大上下文 128K │ │ 自回归生成 Markdown / HTML / LaTeX / JSON / 翻译结果 │ └──────────────────────────────────────────────────────────┘原生分辨率视觉编码器不会强行把长票据或宽表格拉伸成固定正方形有利于保存字符形状与二维布局。Adaptive MLP 则在信息保真与 token 数量之间做压缩。语言端使用轻量 Hunyuan-0.5B并借助 XD-RoPE 对文本、高度、宽度和时间等维度建模。这里的“端到端”不是完全没有后处理而是指核心识别与结构恢复不依赖独立的检测、切图和区域 OCR 模型。3.2 4K 与 128K 解决什么问题升级直接收益需要注意的成本最大图像分辨率 2K - 4K小字号、密集表格、复杂图表保留更多视觉细节视觉 token、显存和预填充时间增加上下文窗口扩展到 128K支持长结构输出、多页或多图上下文长上下文并不等于每次都应拉满吞吐会下降多图训练数据从单页解析扩展到跨页检索、比较与证据聚合需要可靠的页序与证据标注4K 解决“看不清”128K 解决“装不下”。二者同时升级才使多页文档理解成为可训练的能力而不只是接口允许传多张图片。3.3 十二类官方任务接口官方统一推理代码将提示词收敛为 12 个任务类型避免用户随意改写 prompt 导致性能漂移。能力组任务类型典型输出文档解析doc_parse、layout_parse、layoutMarkdown 正文、HTML 表格、LaTeX 公式、版面信息文字识别structured_parse、spotting_json、spotting_hunyuan纯文本或带归一化坐标的 JSON专项解析table、formula、chart_parseHTML、LaTeX、Markdown 或 Mermaid图文翻译doc_trans_en2zh、trans_other2en、trans_other2zh保留结构的中英文译文这种“固定任务路由”牺牲了一点提示词自由度却换来更稳定的线上行为。对于需要可回归测试的 OCR 服务这通常是更合理的接口设计。四、DFlash把逐 token 等待改成并行起草与验证4.1 OCR 为什么特别适合投机解码端到端文档解析的瓶颈常常不在图像编码而在长文本的自回归生成。标准 AR 解码每次只生成一个 token一页含大量 HTML 表格或 LaTeX 公式时GPU 需要反复读取模型权重而单请求又难以用满计算单元。DFlash 增加一个约90.7M 参数、5 层 Transformer的块扩散草稿模型。它以目标模型的隐藏状态为条件一次并行提出最多 16 个候选 token再由目标模型并行验证并接受最长正确前缀。目标模型已生成 y1 y2 ... yt | v DFlash 草稿模型 [c1 c2 c3 ... c16] 一次并行生成候选块 | v 目标模型验证 [✓ ✓ ✓ ✓ ✗ ...] 接受最长有效前缀 | v 下一轮从 yt4 继续而不是逐个走完 4 次目标模型前向训练 DFlash 时目标模型冻结只优化草稿模型。官方实现设置块大小B16每条序列采样 16 个锚点使用 FlexAttention 的块对角掩码隔离不同草稿任务。5 层草稿网络由目标模型最后 5 个解码层初始化。4.2 为什么可以称为“无损加速”投机解码的候选最终仍由目标模型验证因此理论上保持目标模型的输出分布草稿错了只会少接受几个 token不会把未经验证的内容直接写入结果。官方在 OmniDocBench 速度测试中报告DFlash 与 AR 的总输出 token 差异小于 0.15%。但“无损”不应误读为所有部署配置都会逐字符完全一致。框架版本、浮点精度、采样参数、图像预处理和后处理都可能造成差异因此上线前仍要用自己的文档集做精度回归。4.3 加速效果如何解读官方在单张 NVIDIA H20 80GB、并发 1、max_tokens8000的条件下测试推理框架AR 平均延迟DFlash 平均延迟AR Page/sDFlash Page/s加速比Transformers34.850 秒5.474 秒0.0290.1836.37 倍vLLM3.032 秒1.408 秒0.3300.7062.14 倍vLLM 的基线本来就经过服务优化因此相对加速低于原生 Transformers。输出越长、结构越规则DFlash 越有效官方 vLLM 测试中0—256 token 的加速为 1.31 倍超过 2048 token 后为 2.30 倍表格页达到 2.39 倍高于公式页的 2.06 倍和文本页的 1.81 倍。原因并不神秘HTML 标签和表格结构更容易被草稿模型预测。五、Agentic Data Flow围绕模型短板造数据5.1 数据工程从“堆数量”转向“修能力缺口”Agentic Data Flow 不是让 Agent 独立决定训练目标而是算法工程师提出明确能力缺口Agent 调用搜索、OCR/VLM 服务、文件处理、图像清洗与数据生成工具完成材料收集、质量验证和脚本开发再由工程师检查中间样本并追加约束。模型失败样本 / 能力缺口 | v 工程师定义数据需求 ----------------------------- | | v | Agent 拆解任务 - 搜索语料/字体/PDF/背景 - 工具校验 | | v | 生成与清洗脚本 - 初始样本 - 人工检查与规则修订 -- | v 可复用数据流水线 - 预训练 / SFT / RL - 新一轮评测5.2 三类代表性长尾数据能力缺口Agent 参与的工作训练目标低资源语言搜索多语种语料和 TTF 字体验证字符覆盖组合背景与退化效果论文报告构造覆盖 331 种语言的解析数据古文字搜索“汉字七体”字体与古籍背景多模型过滤干扰文字生成不同书写方向和版式提升甲骨、金文、篆、隶、楷、行、草等字形感知多图问答收集多页 PDF提取页级文本生成跨页检索、比较和证据聚合问题过滤单页可回答或缺少文本证据的样本它的价值不在“Agent”这个名字而在于把一次性的采数脚本沉淀为可复用项目并让模型失败分析与数据生产形成短周期迭代。风险也同样明确网络素材的版权、字体许可证、合成分布偏差以及教师模型错误都不会因为自动化而自动消失。六、训练配方预训练、SFT 与任务化强化学习6.1 重新规划预训练 Stage 3HunyuanOCR-1.5 复用 1.0 的前两个预训练阶段只重做 Stage 3。新阶段混合 Agentic Data Flow 生成的能力数据、多图理解数据与 1.0 历史 OCR 数据。保留旧数据的目的是在扩展古文字、低资源语言和多图能力时减少通用 OCR 与结构化输出退化。6.2 SFT 为 RL 建立稳定接口SFT 阶段清理标注错误、格式不一致、图文错配、任务目标含混和低质量重复样本再加入用户困难样本与新增能力数据。整理后的数据被拆成互不重叠的两部分普通样本用于 SFT高难样本留给 RL。各任务使用固定的专用提示词使奖励函数知道自己在评价哪一种输出结构。开源训练脚本支持视觉编码器、连接器和语言模型的全量端到端 SFT。默认示例将多条 OCR 样本打包到20480token以减少 padding 浪费MODEL_PATH/path/to/HunyuanOCR/base/model\TRAIN_DATA./data/parsing_packed_20480.jsonl\NPROC_PER_NODE8\bashscripts/sft_base.sh6.3 OCR 奖励不能只看编辑距离HunyuanOCR-1.5 使用 IcePop一种 GRPO 风格的策略优化变体通过 token 级校准掩码缓解训练引擎与推理引擎之间的概率偏差。每个候选问题先执行 16 次 on-policy rollout已经稳定答对的简单样本会被过滤使计算集中到有奖励方差的困难样本。奖励组件解决的问题主要方法能力路由、结构感知规则奖励文本、表格、图表不能用同一指标评价文本用归一化编辑距离表格结合内容与结构图表使用结构化语义指标一致性 Judge 奖励VQA、翻译等开放答案难写死规则由 Judge 比较回答与高质量参考的一致性退化抑制奖励长输出容易重复、循环或失控超长输出置零检测尾部重复片段并惩罚这套设计体现了 OCR 强化学习的关键模型不仅要“语言通顺”更要忠实转录视觉证据并满足严格格式。表格结构正确但单元格内容错误和内容正确但合并关系错误是两种不同失败奖励也应分别反馈。七、部署实践vLLM、DFlash 与 llama.cpp 怎么选7.1 服务器端快速启动官方统一环境基于 Python 3.12、CUDA 13 和vLLM0.25.1同一套环境可运行 vLLM AR、DFlash 和原生 Transformers。权重同时包含主模型与dflash/草稿模型。pipinstalluv uv venv--python3.12source.venv/bin/activate uv pipinstallvllm0.25.1uv pipinstall--no-build-isolation --no-cache-dirflash-attn2.8.3huggingface-cli download tencent/HunyuanOCR\--local-dir ./HunyuanOCR--excludev1.0/*MODEL_PATH./HunyuanOCRGPU0PORT8000\bashinference/vLLM/serve.sh调用端不要自己拼一套相似提示词直接使用官方任务类型python inference/vLLM/infer_vllm_client.py\--image/path/to/document.png\--task-type doc_parse\--modeltencent/HunyuanOCR\--port8000\--max-tokens32768启用 DFlash 时将服务脚本换为MODEL_PATH./HunyuanOCRGPU0PORT8000\bashinference/DFlash/serve_DFlash.sh统一环境要求 CUDA 13但官方文档也提供 CUDA 12.x 下仅运行 vLLM AR 的独立方案。生产环境应固定依赖版本并以相同图像预处理、任务 prompt、采样参数和后处理做回归测试。7.2 PC 与笔记本部署HunyuanOCR-1.5 已支持将主模型与视觉投影转换为 GGUF通过社区版llama.cpp的 OpenAI 兼容llama-server运行在 CPU、消费级 GPU 或笔记本上。DFlash 需要腾讯文档指定的适配分支尚未合入上游官方同时提示该分支仍有已知问题。部署路径适用场景优点主要限制vLLM ARGPU 服务、批量 API生态成熟吞吐稳定长输出逐 token 解码仍有延迟vLLM DFlash单请求或低并发长文档官方测试端到端加速明显统一环境需要 CUDA 13增加草稿模型Transformers精度对齐、研发验证路径直接方便调试原生逐 token 推理较慢llama.cpp本地离线、消费级设备GGUF、本地隐私、OpenAI 兼容接口量化精度需实测DFlash 分支尚未上游化7.3 上线前的最小验收集不要只拿清晰论文页测 OCR。一个可用的验收集至少应覆盖无文字图片、小字号密集页、跨栏阅读顺序、合并单元格、长公式、倾斜与拍照畸变、多语言混排、超过 2K token 的长输出以及业务中最常见的票据或卡证。还要分别统计字符正确率、结构正确率、幻觉率、尾部重复率、P50/P95 延迟和失败重试率。八、评测结果看清模型强项也看清指标边界8.1 文档解析与长尾能力以下均为 HunyuanOCR-1.5 技术报告中的结果不应直接外推到不同硬件、量化版本或私有数据集。评测集关注能力HunyuanOCR-1.5 结果官方结论OmniDocBench v1.6整页文档解析Overall 94.74端到端 OCR 专家模型中最高MORE149 种语言的低资源解析Overall 91.90OCR 专家模型中最高Chronicles-OCR汉字七体古文字解析古体平均 0.54成熟字体平均 0.791B 模型取得显著优势TableVerse-5K复杂表格恢复TEDS 78.23TEDS-S 84.84专家 OCR 模型中表现领先ChartArena中英文图表结构化解析英文平均 48.9中文平均 64.1以 1B 规模接近或超过多款更大模型DUDE 验证集多图文档问答54.64接近 Qwen3.5-0.8B 的 56.41CHAOS-Bench视觉证据与语言先验冲突Page-avg Recall 14.15对比模型中最高但绝对值仍低OmniDocBench 的 94.74 很亮眼但技术报告也指出一个评测错位HunyuanOCR 倾向于把多行公式作为完整 LaTeX 块输出而现有匹配协议会把独立多行公式拆成单行后再比对可能低估其公式能力。这提醒我们结构化生成模型的输出语义与基准匹配规则必须一起看。8.2 幻觉仍是端到端 OCR 的硬问题CHAOS-Bench 会把论文图像里的单词替换成无意义字符观察模型是忠实抄录“眼睛看到的错词”还是被语言先验纠正成合理单词。HunyuanOCR-1.5 的 14.15 虽明显高于报告中其他对比模型的 3.02—6.33但绝对召回率仍然很低。这说明 VLM OCR 的结构理解与语言纠错既是优势也是风险。合同编号、药品剂量、序列号、财务数字等字段不能依靠语义“猜对”必须增加规则校验、置信度门控或人工复核。模型还在 1000 张无文字内部测试图上将正确拒识率从 1.0 的 78.1% 提升到 99.8%但内部集结果仍需在业务分布上重新验证。九、横向对比HunyuanOCR-1.5 处在什么位置9.1 同赛道方案对比模型/方案参数规模技术路线OmniDocBench v1.6 Overall官方同硬件延迟更适合谁HunyuanOCR-1.51.0B 90.7M DFlash单模型端到端 投机解码94.741.408 秒/页DFlash需要轻量、整页、多任务和低延迟的团队Unlimited-OCR3B-A0.5B端到端、图像切片93.923.659 秒/页重视复杂文档解析与切片策略的场景DeepSeek-OCR 23B端到端 grounding90.255.460 秒/页需要 grounding 路线与较大模型能力的研究者dots.ocr3B单模型端到端90.777.154 秒/页看重结构化输出与成熟社区实践的用户PaddleOCR-VL-1.60.9B版面分析 区域 VLM 两阶段论文表中未列该 Overall1.744 秒/页接受流水线、希望利用 PaddleOCR 工程生态的团队GLM-OCR论文速度表未给出Layout 区域 OCR 并行流水线论文表中未列该 Overall1.649 秒/页更偏向高吞吐页面流水线的服务场景表中的速度来自 HunyuanOCR 报告在相同 H20 80GB、并发 1 条件下的复现各模型使用各自原生 prompt。由于 tokenizer 和输出格式不同Page/s 比 Token/s 更适合跨模型比较。模型方自报结果仍应被视为选型线索而不是替代第三方测试。9.2 它的生态位与真实取舍HunyuanOCR-1.5 的独特位置不是单项识别指标而是同时满足四件事约 1B 参数、整页端到端、多 OCR 任务统一、长输出投机加速。相比两阶段流水线它减少了版面切分和结果拼装相比 3B 端到端模型它更容易部署相比通用 VLM它把参数与训练预算集中在文字密集场景。代价也很具体。端到端生成的错误不如传统模块容易定位DFlash 在高并发下可利用的空闲算力减少4K/128K 会推高最坏情况资源消耗PC 端 DFlash 仍依赖未上游的分支自定义社区许可证也不能按 MIT 或 Apache 2.0 来理解。十、许可证、局限与选型建议10.1 开源不等于无限制商用HunyuanOCR-1.5 使用Tencent Hunyuan Community License Agreement而非 OSI 常见的 Apache 2.0 或 MIT 许可证。部署前至少要注意以下条款条款工程影响授权地域排除欧盟、英国与韩国在这些地区使用、分发或提供服务不在该协议授权范围内月活超过 1 亿的主体需另行申请许可大型平台不能仅凭社区许可证直接上线分发时需附协议、修改声明与 Notice镜像、模型衍生物和交付包要保留合规材料不得用模型或输出改进其他非混元模型数据回流、蒸馏和教师模型流程需要法律审查高风险决策、军事用途等受可接受使用政策限制业务用途必须逐项核对不应只看模型卡摘要本文是技术解读不构成法律意见。涉及跨区域服务、模型再分发或训练数据回流时应以仓库内最新 LICENSE 原文和专业法务意见为准。10.2 选型建议场景建议本地批量解析论文、合同、表格优先测试 vLLM DFlash并对长页统计 P95 延迟笔记本离线识别、隐私敏感资料评估 llama.cpp GGUF量化后重新测小字号和数字字段已有成熟 PaddleOCR 流水线不必为了“端到端”立即重构先在复杂跨栏和长表格上做 A/B 测试卡证、财务、医疗等高准确字段模型抽取后增加正则、字典、交叉字段校验与人工复核多页文档问答先做页级检索缩小上下文再让模型跨页回答并返回证据页欧盟、英国或韩国业务当前社区许可证存在明确地域排除应先解决授权问题十一、总结维度核心要点架构约 1B 参数由原生分辨率 Hunyuan-ViT、Adaptive MLP 与 Hunyuan-0.5B 组成输入能力最大图像分辨率从 2K 提升至 4K上下文扩展到 128K支持多图文档理解推理90.7M DFlash 草稿模型并行起草 16-token 块官方 vLLM 测试加速 2.14 倍数据Agentic Data Flow 围绕低资源语言、古文字和多图 QA 构造可复用数据流水线训练重做预训练 Stage 3清洗并拆分 SFT/RL 数据使用 IcePop 与结构感知奖励工程开放 SFT、DFlash、verl RL、Transformers、vLLM 与 llama.cpp 相关代码风险幻觉仍未解决DFlash 收益依赖负载社区许可证包含地域和用途限制HunyuanOCR-1.5 代表的不是“用更大模型替代 OCR”而是一条更克制的路线保持主干轻量把高分辨率视觉、长上下文、针对性数据、结构化奖励与解码加速组合成完整系统。它在 1B 规模上把整页解析、长尾文字、多图理解和本地部署放到同一张工程地图中。更值得关注的趋势是OCR 竞争正在从单纯的字符准确率转向三个联合指标结构忠实度、端到端页面延迟以及对视觉证据的服从程度。HunyuanOCR-1.5 在前两项给出了有竞争力的结果也用 CHAOS-Bench 坦率暴露了第三项仍然艰难。对实际使用者而言最合理的态度不是只看 SOTA而是拿业务中的坏图、长表、错词和无文字图片做一轮可复现的精度、速度与合规评估。十二、参考资料HunyuanOCR-1.5 官方 GitHub 仓库 — Tencent HunyuanHunyuanOCR-1.5: Making Lightweight OCR VLMs Faster and Better — arXiv, 2026HunyuanOCR 模型权重与模型卡 — Hugging FaceHunyuanOCR-1.5 推理指南 — Tencent HunyuanHunyuanOCR-1.5 速度基准 — Tencent HunyuanHunyuanOCR-1.5 PC 端 llama.cpp 部署指南 — Tencent HunyuanHunyuanOCR-1.5 强化学习训练配套 — Tencent HunyuanCHAOS-BenchOCR VLM 字符级幻觉评测 — Tencent HunyuanHunyuanOCR Technical Report — arXiv, 2025DFlash: Block Diffusion for Speculative DecodingOmniDocBench 官方仓库 — OpenDataLabTencent Hunyuan Community License Agreement
