0.3B Dolphin 文档解析模型量化部署指南：从 BF16 到 TensorRT-LLM 完整教程-二趣网

0.3B Dolphin 文档解析模型量化部署指南：从 BF16 到 TensorRT-LLM 完整教程

【免费下载链接】DolphinThe official repo for “Dolphin: Document Image Parsing via Heterogeneous Anchor Prompting”, ACL, 2025.项目地址: https://gitcode.com/GitHub_Trending/dolphin33/Dolphin

在单卡 GPU 上批量把扫描版报告转成结构化 Markdown 时，Dolphin 这个 0.3B 文档解析模型是性价比最高的选择：权重 BF16 下仅约 0.6GB，再叠加 vLLM、TensorRT-LLM 等量化加速方案，可进一步压低耗时与显存，低配服务器也能跑批量文档解析。

📦 项目速览：一个模型干完两阶段文档解析

Dolphin（Document Image Parsing via Heterogeneous Anchor Prompting，ACL 2025）是字节跳动开源的轻量文档解析模型：第一阶段按自然阅读顺序生成整页元素序列（布局分析），第二阶段对文本、表格、公式、代码等元素用异构锚点提示做并行解码，直接输出带 bbox 和阅读顺序的 JSON 与 Markdown。当前主线版本为 3B 的 Dolphin-v2，低配场景推荐 0.3B 的 Dolphin-1.5，OmniDocBench (v1.5) 总体得分 85.06。

部署方案怎么选：PyTorch、vLLM、TensorRT-LLM 对比

结论先行：开发调试和小批量用仓库原生 BF16 推理；线上高并发选 vLLM；单卡性能拉满选 TensorRT-LLM。

方案	精度/量化形式	耗时特性	显存特性	适用场景
原生 Transformers（本仓库默认）	BF16（GPU 自动启用）	基准速度	权重约 0.6GB + 激活缓存，随批量线性增长	开发调试、小批量试跑、低显存兜底
vLLM（官方已支持）	FP16/BF16，可开启 vLLM 内置量化	连续批处理，批量吞吐显著提升	略高于原生（预留 KV cache）	在线服务、高并发文档解析流水线
TensorRT-LLM（官方已支持）	INT8/FP8 量化引擎	单卡耗时最低	占用最小	极致单卡性能、大规模生产

各方案的实测耗时与显存数字以仓库官方部署文档为准：deployment/vllm/ReadMe.md与deployment/tensorrt_llm/ReadMe.md（版本记录见 README_CN.md 更新日志）。量化会损失少量精度，选型时以"精度是否满足验收基线"为准，不要只看速度。

🚀 快速上手：4 步跑通 Dolphin 文档解析

环境要求：Linux + NVIDIA GPU（Ampere 及以上，支持 BF16 更佳）、Python 3.9+（匹配 requirements.txt 中 torch 2.6.0 / transformers 4.51.0 环境）、约 6GB 可用显存可跑 0.3B 模型。

克隆仓库并安装依赖：

# 克隆仓库并安装全部依赖 git clone https://gitcode.com/GitHub_Trending/dolphin33/Dolphin cd Dolphin && pip install -r requirements.txt

下载预训练模型（Dolphin-1.5，0.3B）：

# 用 Hugging Face CLI 下载 Dolphin-1.5 模型到本地 huggingface-cli download ByteDance/Dolphin-1.5 --local-dir ./hf_model

单页试跑，确认链路正常：

# 解析一页文档，输出同名 JSON 与 Markdown 到 results python demo_page.py --model_path ./hf_model --input_path ./demo/page_imgs/page_1.png --save_dir ./results

批量解析并开启并行元素解码：

# 批量解析 demo 目录全部样张，8 个元素并行解码 python demo_page.py --model_path ./hf_model --input_path ./demo/page_imgs --save_dir ./results --max_batch_size 8

仓库内置样例可直接验证输入：页面级样例demo/page_imgs/page_1.png，元素级脚本 demo_element.py 支持table/formula/text/code四类。

⚡ 关键参数调优：量化参数怎么选

参数	作用	推荐值	影响
`--max_batch_size`	第二阶段同类型元素的并行解码数，demo_page.py 默认 4	先 4，显存余量足逐步提到 8	越大吞吐越高、显存占用越高；OOM 时第一个调它
推理精度	GPU 下自动走 BF16，CPU 回退 FP32（脚本内已处理）	保持 BF16 为量化起点	量化引擎（INT8/FP8）均从 BF16 基线转换，精度对比也以此为准
模型版本	0.3B（Dolphin-1.5）与 3B（Dolphin-v2）二选一	显存 ≤8GB 选 0.3B；追求精度上限选 3B	0.3B 总体 85.06 / 3B 总体 89.78（OmniDocBench v1.5），3B 显存与耗时成本约为前者数倍

补充一点：--post_process开关会对输出做后处理清洗，接入下游管道前建议开一次对比效果；PDF 输入会按页拆成图片逐页解析，页码多时耗时线性叠加，这是正常行为。

🔍 效果验证：怎样算部署成功

精度基线（官方 OmniDocBench v1.5 实测，量化部署不应显著低于此水平）：

指标	Dolphin 1.0	Dolphin-1.5
总体得分 ↑	74.67	85.06
文本编辑距离 ↓	0.125	0.085
公式 CDM ↑	67.85	79.44
表格 TEDS ↑	68.70	84.25
阅读顺序编辑距离 ↓	0.124	0.071

用元素级脚本抽验结构恢复能力，看输出是否完整：

# 元素级解析表格样例，打印识别结果便于肉眼核对 python demo_element.py --model_path ./hf_model --input_path ./demo/element_imgs/table.jpg --element_type table --print_results

验收标准（满足全部才算部署成功）：

save_dir下生成与输入同名的 JSON 和 Markdown 文件；
Markdown 阅读顺序与原页视觉顺序一致（对照demo/page_imgs/page_1.png人工抽查）；
表格、公式、代码块内容完整无缺行（对照上方样图抽查）；
批量跑demo/page_imgs全程无 OOM，单页耗时稳定；
量化引擎与原生 BF16 对同一页抽样对比，关键内容无丢失。

🛠️ 故障速查：部署报错怎么办

错误现象	可能原因	解决命令
`CUDA out of memory`	`--max_batch_size`过大或页面元素密集	降为`--max_batch_size 2`，或换 TensorRT-LLM 量化引擎
模型全跑在 CPU 上、速度极慢	驱动与 torch 版本不匹配	按 requirements.txt 重装：`pip install -r requirements.txt`（torch 2.6.0）
模型目录文件只有几百字节	git lfs 未启用，下载到的是 LFS 指针文件	`git lfs install`后重新下载，或改用`huggingface-cli download ByteDance/Dolphin-1.5 --local-dir ./hf_model`
`huggingface-cli: command not found`	未安装 huggingface_hub	`pip install huggingface_hub`
PDF 报`Failed to convert PDF`	PDF 加密或页面结构异常	先用 pymupdf（依赖已内置）渲染为 PNG 再输入，bad case 可在 issue 区提交

vLLM 与 TensorRT-LLM 的完整部署命令、引擎构建流程见仓库deployment/vllm/ReadMe.md和deployment/tensorrt_llm/ReadMe.md（官方 README 更新日志中有对应版本记录）。建议先跑通上面的原生 BF16 流程确认输出无误，再切换到量化方案；遇到模型解析 bad case，直接到项目 issue 区提交，官方在持续优化。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析