256M 参数的文档解析模型，表格结构、 代码块、公式、图表数据的结构化标签序列

256M 参数的文档解析模型, 到底能用到什么程度?

一、模型概况与技术架构

SmolDocling 是 IBM Docling 团队发布的超轻量多模态文档解析模型,参数量仅 256M, 基于 HuggingFace 的 Idefics3 / SmolVLM 架构。它的核心思路与传统 OCR 管线不同: 不先做文字检测再逐块识别,而是直接将整页文档图片输入模型,一步生成包含文本、表格结构、 代码块、公式、图表数据的结构化标签序列(DocTags),再由 docling_core 库 转换为 Markdown 或 HTML。

2025 年 3 月,IBM 发布了继任模型 granite-docling-258M(258M 参数, repo: ibm-granite/granite-docling-258M),同为 Idefics3 架构, 官方标记 SmolDocling 为 deprecated 并推荐迁移。本测评将两个模型在同一套样本上做 1:1 对比。

DocumentImagePNG/JPG/PDF pageas pixel inputSmolDocling / GraniteIdefics3 (256M params)Vision Encoder (SigLIP)+ LLM Decoder (SmolLM)prompt: "Convert this page to docling."output: DocTags structured tagsDocTags<text><otsl> (table)<code><chart><loc_xxx>OutputMarkdownHTMLJSON

SmolDocling / Granite-Docling 技术架构:视觉编码器 + LLM 解码器的端到端多模态方案

训练数据与官方基准

根据论文 arXiv:2503.11576,模型在以下数据集上训练和评估:

注意:以上均为英文数据集。论文未报告任何中文测试结果。 本测评通过自建中文样本补充了这一关键盲区。

推理代码与 DocTags 输出格式

模型使用标准的 transformers API 加载,推理时将文档图片和指令文本一起输入, 生成 DocTags 标签序列。以下是简化后的推理流程:

# 加载模型与处理器
processor = AutoProcessor.from_pretrained("docling-project/SmolDocling-256M-preview")
model = AutoModelForImageTextToText.from_pretrained(
    "docling-project/SmolDocling-256M-preview",
    torch_dtype=torch.bfloat16, _attn_implementation="sdpa"
).to("cuda")
# 构造输入:图片 + 指令
messages = [{"role": "user", "content": [
    {"type": "image"},
    {"type": "text", "text": "Convert this page to docling."}
]}]
prompt = processor.apply_chat_template(messages, add_generation_prompt=True)
inputs = processor(text=prompt, images=[image], return_tensors="pt").to("cuda")
# 生成 DocTags
output = model.generate(**inputs, max_new_tokens=8192)
doctags = processor.batch_decode(output[:, inputs["input_ids"].shape[1]:],
                                  skip_special_tokens=False)[0]
# DocTags -> DoclingDocument -> Markdown/HTML
doc_tags = DocTagsDocument.from_doctags_and_image_pairs([doctags], [image])
doc = DoclingDocument.load_from_doctags(doc_tags, document_name="Doc")
print(doc.export_to_markdown())

DocTags 是 Docling 定义的结构化标记语言,每个元素带有边界框坐标 (<loc_xxx>),核心标签包括:

二、测评设计:8 张样本覆盖 7 个维度

对齐论文 Table 2-5 的基准维度,并补充中文维度。样本来源:

• 1 张官方测试图:page_with_table.png (1326x2014, 学术论文含复杂 8 列表格)
• 7 张自建合成图:用 PIL + 微软雅黑 + Consolas 渲染,ground truth 完全可控

环境:conda env smoldocling (Python 3.11, torch 2.11.0+cu128, transformers 5.14.0, docling_core 2.87.1); 注意力后端 SDPA (PyTorch 内置高效 attention; flash_attn 因 Windows 长路径限制无法编译)。

三、性能实测

SDPA vs Eager 注意力后端对比

在正式对比两个模型前,先测试了注意力后端对性能的影响。结论:

SDPA 通过融合注意力计算的 softmax 和矩阵乘法,在不改变输出质量的前提下 大幅降低显存占用。对 Granite 效果更显著(速度翻倍),但即使优化后,Granite 仍然比 SmolDocling 慢约 8 倍。 这一差距来自模型内部的生成机制差异,而非注意力后端。

SDPA 下两个模型显存均为 0.83 GB,不到 RTX 5060 Ti 16GB 的 5%。 这意味着单张消费级显卡可以同时跑 10+ 个实例并行处理文档,对批量离线场景非常友好。

四、中文能力:本次测评最重要的发现

论文完全没有测试中文,我们用自建中文样本补上了这个关键盲区。 结论非常明确:Granite 的中文识别率从 SmolDocling 的"近乎不可用"提升到了"接近完美", 但代价是推理速度慢 8 倍,且中文表格内容提取出现退步。

4.1 中文纯文本:从"不可用"到"可用"

输入:微软雅黑渲染的中文文档,标题"人工智能发展报告",正文讨论大语言模型

SmolDocling 输出

## 人工看象发展含近年来、大活监掌型在自然语言处理领域取得了量著实施。以 GPT、GLM 分化表的模型最视了現大的理解与生成能力。多模态模型进-步将视角、研究与语言能力融合，能够向时处理图像、视角和文本信息。文献解析是其中的重要应用方向，自标定将析式包实状的双精 ( 法及、按是、翻译)转换为结构化数损。本文评估的 SmolDocling 图力该领域的结论组织方案。

Granite-Docling 输出

## 人工智能发展报告近年来,大语言模型在自然语言处理领域取得了显著突破。以 GPT、GLM 为代表的模型展现了强大的理解与生成能力。多模态模型进一步将视觉、听觉与语言能力融合，能够同时处理图像、视频和文本信息。文档解析是其中的重要应用方向,目标是将版式复杂的文档(论文、报表、票据)转换为结构化数据。本文评估的 SmolDocling 即为该领域的轻量级方案。

逐行对比分析

准确率估算:以 100 个汉字为样本,SmolDocling 正确识别约 20 个(~20%), Granite 正确识别约 98 个(~98%)。差距达 5 倍。

SmolDocling 的错误模式主要是字形相近字混淆:「语→监」「型→掌」「文→图」「档→精」, 这表明模型的中文视觉编码器对 CJK 字形的区分能力不足。Granite 明显改善了这一点。

4.2 中文表格:出乎意料的 Tradeoff

中文表格的结果揭示了一个非直觉的 tradeoff:Granite 的中文文字识别好, 但在表格内容提取上反而退步;SmolDocling 中文字符错误,但表格结构和数值完整。

输入:5 行 x 4 列中文销售统计表格 (含合并表头"第一季度/第二季度")

两个模型输出的 DocTags 结构对比

SmolDocling (3407 chars):

<section_header_level_1>2024 年度費能紛行</section_header_level_1>
<otsl>
  <ched>予告紛別<ched>第-学度<ched>第二学度<ched>同地紛<nl>
  <fcel>智能手机<fcel>1,250 万<fcel>1,480 万<fcel>+18.4%<nl>
  <fcel>等に本車職<fcel>680 万<fcel>720 万<fcel>+5.9%<nl>
  ...
</otsl>

Granite-Docling (289 chars):

<section_header_level_1>2024 年度销售统计</section_header_level_1>
<otsl></otsl>  /* 空标签 -- 表格内容完全丢失 */

Tradeoff 分析

这意味着:如果业务场景是"中文报表数字提取"(提取金额、百分比等数值), SmolDocling 反而比 Granite 更可靠 -- 虽然中文字符有误,但数字和表格结构完整。 而如果需要"中文文档全文识别",则必须用 Granite。

五、英文 / 代码 / 公式:两个模型一致

在英文和非中文维度上,两个模型表现高度一致。以下是逐维度分析。

5.1 英文表格结构 (page_with_table)

英文表格原文

输入:TableFormer 论文页面,含 8 列复杂学术表格 (合并表头,多级嵌套)

表格输出对比

两个模型均完美还原了表格结构:

与论文 Table 4 的 TEDS 基准(SmolDocling FinTabNet 0.52, PubTables 0.65)一致: 对于结构完整的学术表格,两个模型都能准确提取。

5.2 代码块

与论文 SynthCodeNet F1 0.92 的基准一致。两个模型对 Python 代码的还原度极高, 包括 __name__ == '__main__' 这类易错点。Granite 输出中 if __name__ 行有 1 个额外空格缩进,属于微小瑕疵。

5.3 数学公式

值得注意的是,默认 prompt "Convert this page to docling." 下, 公式以 ASCII 文本形式输出而非 LaTeX 源码。论文 Im2LaTeX F1 0.95 是在专用 prompt "Convert formula to LaTeX." 下测的。如需 LaTeX 输出,应使用专用指令。

5.4 双栏排版

5.5 柱状图 (失败案例)

图表识别分析

两个模型均能正确识别图表类型 -- SmolDocling 输出 <chart><vbar_categorical> 标签, 说明它知道这是分类柱状图。但数值读取完全失败,4 个不同的柱子高度被全部识别为 45。

论文 Chart TEDS 0.75 的成绩是在裁剪好的图表区域 + 专用任务下测的。 在整页文档场景中,图表只是页面的一部分,数值提取的可靠性显著下降。 这是一个需要后处理验证的关键边界。

六、SmolDocling vs Granite-Docling 综合对比

七、落地建议与选型指南

场景 1: 中文文档全文识别

推荐: Granite-Docling (速度换准确度)

SmolDocling 中文准确率仅 ~20%,不可直接用于中文 OCR。 Granite ~98% 的准确率使其成为该场景下唯一可用的选择。 如果需要更高准确率,可考虑结合 PaddleOCR / EasyOCR 做后处理纠错。 速度代价:Granite 每页约 50-80 秒(SDPA),适合批量离线处理。

场景 2: 英文学术文档 / 论文解析

推荐: SmolDocling (速度优先)

两个模型在英文维度上表现一致,SmolDocling 速度快 8 倍。 对于批量论文解析(如构建 RAG 知识库),SmolDocling 的吞吐量优势明显: 单张 5060 Ti 可同时处理 10+ 篇论文。

场景 3: 中文报表数字提取

推荐: SmolDocling + PaddleOCR 组合

看似矛盾的结论:中文场景下反而推荐 SmolDocling。原因是 Granite 虽然中文文字准确, 但表格内容提取退步(<otsl> 空标签),无法获取单元格数值。 SmolDocling 中文字符有误但数字和表格结构完整。 更稳妥的方案:用 PaddleOCR 提取文字 + SmolDocling 提取表格结构,两者互补。

场景 4: 代码/公式/英文混合文档

推荐: 两者皆可,SmolDocling 速度更快

代码和公式维度两个模型一致,均达到论文报告的高水准(F1 0.92/0.95)。 SmolDocling 更快,优先选择。如需 LaTeX 源码输出,使用专用 prompt "Convert formula to LaTeX."。

场景 5: 生产环境部署

关键约束:

• 显存: 两个模型均仅需 0.83 GB (SDPA),一张 16GB 显卡可跑 10+ 实例
• flash_attn: 当前 Windows + Blackwell 环境无法编译 flash_attn,用 SDPA 已足够
• vLLM: 模型卡提供 vLLM 推理示例,可大幅提升吞吐(待验证)
• 模型状态: SmolDocling 已 deprecated,生产环境建议评估 granite-docling-258M
• 图表数值: 两个模型的图表数值提取均不可靠,需要后处理验证或专用模型

八、技术踩坑记录

1. AutoModelForVision2Seq 在 transformers 5.x 中不存在

官方模型卡的示例代码使用 AutoModelForVision2Seq,但 transformers 5.13+ 已将其 合并为 AutoModelForImageTextToText。直接 import 会报 ImportError。

2. 缺少 torchvision

SmolDocling 的 image processor (Idefics3) 依赖 torchvision 做图像预处理, 首次加载时报 Missing optional dependencies: torchvision。 需单独安装匹配版本 torchvision 0.26.0+cu128。

3. flash_attn 无法在 Windows + Blackwell 上编译

flash-attn 2.8.3 的源码包含超长路径文件名(如 device_batched_gemm_add_relu_gemm_add_xdl_cshuffle_f16_f16_f16_f16_f16_f16_gmk_gnk_gno_gmo_instance.cpp), 超过 Windows MAX_PATH 260 字符限制。启用长路径需要管理员权限(本环境无权)。 解决方案:使用 PyTorch 内置的 SDPA 后端,效果接近。

4. base 环境 numpy dist-info 损坏

base 环境同时存在 numpy 2.5.0 和 2.5.1 的 dist-info 目录, 导致 importlib.metadata.version('numpy') 返回 None, transformers 启动检查直接抛 ValueError。解法:新建独立 conda 环境。

5. DocTags 元素标签名与直觉不符

DocTags 的标签名并非 <title>/<para>/<table>, 而是 <section_header_level_N>/<text>/<otsl>/<code>/<chart>。 OTSL 表格使用子标签体系: <ched> 列头, <fcel> 数据格, <ecel> 跨列空格, <nl> 换行。统计元素时需用正则提取实际标签名。

6. 公式默认输出非 LaTeX

用默认 prompt "Convert this page to docling." 时,公式以 ASCII 文本形式输出 (e.g. e^(i*pi)+1=0)。论文 Im2LaTeX F1 0.95 是在专用 prompt "Convert formula to LaTeX." 下测的。如需 LaTeX,应切换 prompt。