1B 干翻 7B，94 分霸榜：腾讯混元 OCR 全栈开源，老李的 A100 可以卖了

工欲善其事，必先利其器。

老李的团队刚经历了一场"降本增笑"的魔幻操作：花 200 万采购的 A100 集群，跑通用 7B VLM 做合同 OCR，GPU 利用率 60% 的时间耗在文字解码上，实际每天处理不到 5000 页。财务部投诉："一张发票识别 8 秒，月底对账等两小时。"

就在老李准备再加两台机器"加速"的时候，看到了 HunyuanOCR-1.5 的 benchmark——1B 参数，OmniDocBench v1.6 上 94.74 分，端到端第一。比他的 7B 通用模型高了将近 10 个百分点。

更让他血压升高的是——这玩意能跑在 CPU 上。

一笔账

老李算了一下：

• 之前：2 × A100-80G，月成本约 3 万，日处理 5000 页
• 迁移后：1 × L40S 单卡，月成本约 3000，DFlash 加速后日处理 3 万+页

投入降到 1/10，产出翻了 6 倍。这不是优化，是降维。

到底是什么

不畏浮云遮望眼，只缘身在最高层。

HunyuanOCR-1.5 是腾讯混元团队开源的端到端 OCR 专家模型。关键在"专家"两个字——它不是通用大模型的 OCR 插件，是专门为文字相关任务设计的小而精 VLM。

差别在于：

通用 7B 的 OCR 能力只是"附带"的，而 HunyuanOCR 把 1B 参数全部花在文字任务上。结果就是：参数少 7 倍，OCR 精度反而高。

它是第一个完整端到端的开源 OCR 专家模型。 训练脚本、推理代码、权重全开，连数据构造方法论（Agentic Data Flow）都写在论文里。

为什么你的团队应该用它

老李说，三个理由：

1. 省钱。 1B 参数，一张消费级 GPU 甚至 CPU 就能跑。原来 3 万/月的 GPU 账单可以砍掉，迁移到内部服务器。llama.cpp 支持 CPU 推理，普通笔记本也能做开发测试——这在端到端 VLM 圈子里是头一次。

2. 省时间。 DFlash 推测解码让推理最高提速 6.37 倍。合同解析从 8 秒/页降到约 1.3 秒/页，日处理量从 5000 页跃升到 3 万+。同样的硬件，吞吐量翻了好几倍。

3. 可控。 全栈开源意味着你可以用自己的数据微调——古籍、医疗报告、手写笔记，有什么数据就训什么。Agentic Data Flow 这套数据构造方法也公开了，照着做就行。

架构一图看透

大鹏一日同风起，扶摇直上九万里。

两个看点：

DFlash 推测解码。 训练一个小草稿模型，一次并行预测多个候选 token，由主模型一次性验证。无损加速——输出分布和原始模型完全一样，推理速度最高提 6.37 倍。这对 OCR 来说就是换了个发动机——OCR 输出经常有几千个 token，解码时间是主要瓶颈。

Agentic Data Flow。 不是人工标注数据，而是让 Agent 根据模型弱点自动搜索、清洗、验证训练数据。这解决了 OCR 最头疼的事：长尾场景（古籍、手写、低资源语言）标注成本极高，没有自动化数据管线根本做不了。

安装部署

纸上得来终觉浅，绝知此事要躬行。

三行命令部署（vLLM）

# 1. 下载权重（约 4GB）
huggingface-cli download tencent/HunyuanOCR --local-dir ./HunyuanOCR

# 2. 安装环境
pip install -r inference/vllm_0_18_1/requirements.txt

# 3. 启动服务
MODEL_PATH=./HunyuanOCR GPU=0 PORT=8000 bash inference/vllm_0_18_1/serve.sh

笔记本也能跑（llama.cpp）

git clone https://github.com/ggml-org/llama.cpp.git && cd llama.cpp
cmake -B build -DLLAMA_BUILD_EXAMPLES=ON
cmake --build ./build --config Release -j

python3 convert_hf_to_gguf.py --outfile hyocr-f16.gguf ./HunyuanOCR
python3 convert_hf_to_gguf.py --outfile mmproj-f16.gguf --mmproj ./HunyuanOCR

build/bin/llama-server --model hyocr-f16.gguf \
    --mmproj mmproj-f16.gguf --port 8080

注意：vLLM（AR 版本）和 Transformers 不能共用同一个虚拟环境，transformers 版本互不兼容。readme 里专门提醒了这一点，别踩坑。

实战演示

5 行 Python 解析合同

import requests
resp = requests.post("http://127.0.0.1:8000/v1/chat/completions", json={
    "model": "tencent/HunyuanOCR",
    "messages": [{"role": "user", "content": [
        {"type": "image_url", "image_url": {"url": "file:///contract.jpg"}}
    ]}],
    "max_tokens": 32768, "temperature": 0.0
})
print(resp.json()["choices"][0]["message"]["content"])

批量处理

python batch_infer.py --image-dir ./invoices --out-dir ./results \
    --ports 8000 --task-type doc_parse --concurrency 16

实测数据：一张混合表格+印章的 A4 合同，vLLM 约 2.3 秒，DFlash 加速后约 0.8 秒。精度？OmniDocBench 94.74，端到端排名第一。

三条洞见

洞见一：参数量的军备竞赛该停了

1B 专家模型在 OCR 榜上压着 7B 通用模型打——参数多 7 倍，分数反而低 10 分。这说明两件事：第一，通用模型的 OCR 能力是"烫剩饭"（训练数据里的 OCR 样本不够密集）；第二，小模型只要够专，完全可以做到顶尖水平。

对企业来说这个信号很清楚：应该用"每参数效能"选模型，而不是看参数量。 你不需要一个能写诗能编程的模型来做 OCR——你只需要一个 OCR 专家。

洞见二：开源从"给模型"进化到"给工厂"

HunyuanOCR 开源的不只是模型，而是完整生产线：数据构造管线 → 训练脚本 → 推理栈 → 部署方案。换句话说，你不是"试用腾讯的模型"，而是"用腾讯的工具造自己的 OCR 系统"。

古籍、医疗报告、工地手写单、东南亚小语种——以前这些长尾场景根本没人做，因为标注成本太高。Agentic Data Flow 把这个成本打下来了。社区微调的效率会远超单一团队一年的研发产出。

洞见三：推理效率决定了 OCR 能不能普及

以前的端到端 OCR 是这样的：需要 7B+ GPU 集群 → 推理慢且贵 → 只能用 API → 数据要出网 → 合规过不了 → 放弃。

HunyuanOCR 把这个链条打断了：1B 模型 → CPU 能跑 → 笔记本开发 → GPU 加速可选 → 数据内网处理 → 全链路可控。

这就把一个原来只有大厂能碰的技术，变成了中小团队也能上的基础设施。 如果说大模型是"核武器"，那 OCR 专家模型就是"手枪"——精度够用，人人配得起。

行动建议

老李已经把他的 A100 集群砍了一半，省下来的预算买了更多数据标注工具。他的一句话总结：

"OCR 不是造火箭，不需要 7B 的发动机。一把手术刀就够了。"

方法论速查表

项目地址：github.com/Tencent-Hunyuan/HunyuanOCR

在线体验：hunyuan.tencent.com/chat