深度技术评估报告：Dots.OCR 架构机制、微调可行性与生态系统全景分析

1. 执行摘要与引言

在过去三十年中，光学字符识别（OCR）技术经历了几次根本性的范式转移。从早期的基于规则的匹配算法，到卷积神经网络（CNN）与循环神经网络（RNN）结合的CRNN架构，再到目前基于Transformer的视觉语言模型（VLM）时代，文档智能处理的边界不断被拓展。2025年中期，由小红书（Rednote）技术团队 Rednote HiLab 发布的 Dots.OCR 模型，标志着这一领域的一个重要里程碑。该模型并未沿用传统的“检测-识别-组装”的流水线式架构，而是采用了一种端到端的统一视觉语言生成范式，在一个紧凑的1.7B参数规模下实现了对复杂文档布局、多语言文本及表格公式的统一解析。

本报告旨在对 Dots.OCR 生态系统进行详尽的法医学式分析。基于对技术文档、GitHub 开发者讨论、模型卡片及第三方基准测试的深入研究，我们将重点回应当前社区最为关注的三个核心问题：该模型是否可以被有效微调（Fine-tuning）及其具体流程；社区衍生版本 prithivMLmods/Dots.OCR-Latest-BF16 的技术特性与必要性；以及当前 Dots.OCR 生态中所有衍生模型的完整图谱与性能现状。

分析显示，尽管 Dots.OCR 在 OmniDocBench 等基准测试中展现了“小而美”的 SOTA（State-of-the-Art）性能，但在实际的下游微调任务中，该模型表现出了显著的工程脆弱性。由于其独特的 NaViT（Native Resolution Vision Transformer）视觉编码器采用了非标准的动态分辨率处理机制，导致其与 LLaMA-Factory、Unsloth 等主流微调框架存在严重的兼容性断层。目前，社区中成功的微调案例极少，绝大多数尝试均因预处理器（Preprocessor）缺失或张量形状不匹配而告终。与此同时，prithivMLmods 发布的 BF16 版本实际上是一个关键的工程修复补丁，解决了原版模型在 transformers 库版本更新后的崩溃问题，并引入了 Flash Attention 2 加速，是目前生产环境部署的首选版本。

本报告将分为七个核心章节，从底层架构原理、微调失败的根因分析、衍生模型的技术审计、以及与 GOT-OCR 2.0、MinerU 等竞品的深度对比等方面，全面解构 Dots.OCR 的技术全貌。

2. Dots.OCR 的架构基础：统一视觉语言范式的机遇与挑战

要理解为何 Dots.OCR 在微调过程中频频遭遇技术壁垒，首先必须深入解剖其设计哲学与架构细节。Dots.OCR 并非简单的“视觉编码器 + 语言解码器”的堆叠，而是在数据处理与特征交互层面进行了深度定制。

2.1 统一端到端架构的演进

在 Dots.OCR 出现之前，工业界的标准文档处理方案通常是流水线式的（Pipeline-based）。例如，使用 YOLO 或 Mask R-CNN 进行版面分析（Layout Analysis），使用 DBNet 进行文本检测（Text Detection），再使用 CRNN 或 SVTR 进行文本识别（Text Recognition），最后通过复杂的规则脚本将这些结果拼凑在一起。这种方法的缺陷显而易见：误差会逐级累积，且难以处理文本与布局高度耦合的场景（如复杂的报表或图文混排）。

Dots.OCR 激进地抛弃了这一范式，转向了 Unified Vision-Language Model（统一视觉语言模型）架构 1。其核心思想是将文档解析任务重构为“看图说话”的序列生成任务。模型直接接收原始文档图像，并输出包含结构化信息（如 Markdown、JSON 或 LaTeX）的文本序列。

该模型主要由两部分组成：

1. 视觉编码器（Vision Encoder）： 一个拥有 12 亿参数（1.2B）的视觉塔，基于 NaViT 架构从头训练 1。
2. 语言基座（Language Backbone）： 采用了 Qwen2.5-1.5B 模型 1。选择 Qwen2.5 而非 Llama 或 Mistral 的原因在于 Qwen 系列在多语言（尤其是中文）及数学逻辑推理方面的先天优势，这对于处理包含中文文档及复杂表格公式的 OCR 任务至关重要。

2.2 NaViT：原生分辨率的“双刃剑”

Dots.OCR 架构中最具决定性的设计选择是使用了 NaViT（Native Resolution Vision Transformer）架构 1。理解 NaViT 是理解 Dots.OCR 微调困境的关键。

2.2.1 传统 ViT 的局限性

标准的 Vision Transformer（如 CLIP-ViT 或 SigLIP）通常要求输入图像具有固定的分辨率，例如 224x224 或 336x336 像素。如果输入一张长条形的购物小票（例如 200x1000 像素）或一张横向的全景报表，传统的预处理方法通常是：

• 强制缩放（Resizing）： 将图像压扁或拉伸到正方形。这会导致文字严重变形，甚至变得不可读。
• 填充（Padding）： 保持比例缩放，然后用黑色像素填充空白区域。这引入了大量的无效计算，浪费了显存与算力。

2.2.2 NaViT 的 Patch n' Pack 机制

NaViT 旨在解决上述问题。它允许模型处理任意分辨率和纵横比的输入图像，而无需将其强制转换为固定的正方形网格。

• 动态切片（Patching）： NaViT 将图像直接切分为多个 Patch，无论图像的长宽比如何，Patch 的总数量是动态变化的。
• 序列打包（Packing）： 为了进行批量训练，NaViT 采用了一种称为 "Patch n' Pack" 的技术，将来自不同图像的 Patch 序列打包到同一个长的序列中，并通过精心设计的注意力掩码（Attention Mask）来防止不同图像的 Patch 之间发生交互 4。

这一机制对 OCR 的意义： 这种设计使得 Dots.OCR 能够“原汁原味”地看到文档细节。对于包含细微脚注、密集表格或长图截屏的文档，NaViT 能够保留高频的视觉特征，从而极大地提升了 OCR 的识别精度，尤其是在 OmniDocBench 等包含极端纵横比样本的基准测试中 5。

这一机制对微调的代价： 然而，正是这种非标准的张量处理方式，构成了微调的噩梦。现有的主流微调框架（如 LLaMA-Factory、Swift、Unsloth）通常假设视觉输入是一个形状固定的张量 (Batch_Size, Channels, Height, Width)。当 Dots.OCR 传入一个变长的、打包后的序列时，标准的数据整理器（Data Collator）无法处理这种动态形状，导致张量堆叠失败或注意力计算错误。这解释了为何社区用户在尝试微调时普遍遭遇 pixel_values 形状不匹配的问题 6。

2.3 基于提示词的任务控制接口

Dots.OCR 的另一个架构特点是其高度依赖提示词（Prompt）的任务控制机制。模型并没有针对检测、识别或表格解析训练不同的“头”（Heads），而是通过在输入文本中加入特定的控制符来切换模式 7：

• prompt_ocr：指示模型执行全文 OCR，输出无格式文本或简单的 Markdown。
• prompt_layout_only_en：指示模型仅输出布局信息（Bounding Boxes）和类别标签，不识别具体文本内容。
• prompt_table：专门触发表格解析能力，输出 HTML 格式的表格代码。
• 自定义 Prompt：用户可以构建特定的指令，例如“提取发票中的总金额”，利用 Qwen2.5 的语言理解能力进行信息抽取（VIE）。

这种设计意味着模型在预训练阶段经历了大量的多任务指令微调（Multitask Instruction Tuning）。因此，在对其进行微调时，如果用户的数据集没有包含类似的指令结构，或者破坏了原有的指令分布，极易导致“灾难性遗忘”（Catastrophic Forgetting）。例如，仅使用纯文本数据微调后，模型可能会丧失输出 Bounding Box 的能力，或者无法再响应 prompt_table 指令。

3. Dots.OCR 微调深度调查：现状、阻碍与个案分析

针对用户关于“是否有人微调过”以及“微调过程”的询问，通过对 GitHub Issue、Hugging Face Discussions 以及 Reddit 社区的全面排查，我们的结论是：目前社区中尚未出现广泛公认的、成功的 Dots.OCR 微调案例，且官方仓库并未提供开箱即用的微调脚本。

微调 Dots.OCR 是一项具有极高技术门槛的任务，绝大多数尝试者都在环境配置或数据加载阶段遭遇了挫折。

3.1 社区微调尝试的法医学分析

我们对 GitHub 上相关的 Issue（特别是 #12, #39, #91）进行了详细的梳理，识别出了导致微调失败的三大核心病灶。

3.1.1 第一类阻碍：“幽灵”预处理器（The Missing Preprocessor）

这是最常见的错误模式，通常发生在用户尝试将 Dots.OCR 加载到 LLaMA-Factory 或其他基于 Hugging Face Trainer 的框架时。

• 症状描述： 训练脚本在启动初期崩溃，报错信息为 ValueError: Processor was not found, please check and update your model file 或 AttributeError: 'NoneType' object has no attribute 'image_processor' 6。
• 技术根因：
  • Hugging Face 的 AutoProcessor 依赖于 config.json 中的配置来动态加载对应的 Python 类。
  • Dots.OCR 的模型权重中包含自定义代码（modeling_dots_vision.py 等）。由于安全策略或路径配置问题，标准库往往无法正确解析这些远程代码中的 Processor 类。
  • 更关键的是，Qwen2-VL 的官方 Processor 并不完全兼容 Dots.OCR 修改后的 NaViT 逻辑。Dots.OCR 的配置文件在某些版本中缺失了 image_processor 的显式定义，导致框架加载了一个空的 Processor 对象。
• 用户挣扎： 在 Issue #12 中，用户尝试手动指定 AutoProcessor 并从本地路径加载，但随后又遇到了 image_processor 属性为 None 的连环错误。这表明模型的代码结构与 transformers 库所期望的标准接口存在脱节。

3.1.2 第二类阻碍：数据整理器的张量冲突（Tensor Mismatch）

即使解决了 Processor 的加载问题，用户往往会在数据加载阶段（Data Loading）遇到第二道墙。

• 症状描述： 报错提示 RuntimeError: stack expects each tensor to be equal size 或与 Flash Attention 相关的维度错误。
• 技术根因： 如前所述，NaViT 输出的是变长的 Patch 序列。
  • 标准的 DataCollator（如 LLaMA-Factory 中的默认实现）试图将一个 Batch 内的所有图像张量堆叠（Stack）成一个规整的张量。
  • 由于 Dots.OCR 对每张图像生成的 Patch 数量不同（取决于原始分辨率），直接堆叠在数学上是不可能的。
  • 解决方案需求： 必须编写一个自定义的 DataCollator，该整理器需要能够处理“嵌套张量”（Nested Tensors）或执行特殊的 Padding 逻辑，将所有序列填充到该 Batch 中的最大长度。然而，Rednote 官方并未开源这一关键的训练代码组件。

3.1.3 第三类阻碍：灾难性过拟合与“胡言乱语”

极少数拥有高深工程能力的用户（如 Issue #39 中的 @JamesGs）声称跑通了训练流程，但结果令人沮丧。

• 症状描述： “After training the model on several private datasets, I observed only minimal improvements in accuracy... it seems more effective to use the base model directly.”（在私有数据集上训练后，精度几乎没有提升，甚至更差）9。模型开始输出重复的字符循环，或者完全丧失了对复杂表格的解析能力。
• 原因推测： 这是一个典型的“小模型过拟合”现象。1.7B 的参数量相对较小，且 Dots.OCR 在预训练阶段使用了极其庞大且多样化的数据混合（Data Mixture）。用户微调时通常只使用几千条特定数据（如特定格式的单据），这种数据分布的剧烈偏移（Distribution Shift）迅速破坏了模型原有的参数平衡。由于缺乏官方提供的“重放数据”（Replay Data）来维持通用能力，微调变成了破坏性的遗忘过程。

3.2 针对 LLaMA-Factory 的具体微调现状

LLaMA-Factory 是目前最流行的微调工具之一。关于 Dots.OCR 在该框架下的支持情况：

• 官方支持状态： 不支持。LLaMA-Factory 的模型列表中并未包含 dots-ocr。
• 社区 Hack 方案： 有用户尝试通过修改 mm_plugin.py 文件，仿照 Qwen2-VL 的插件结构注册一个 dots_ocr 模板 6。具体操作包括定义特定的 image_token 和 video_token，并强制指定模型类型。
• 结果： 这种 Hack 方案极其脆弱。由于 Dots.OCR 的 modeling_*.py 代码与 Qwen2-VL 的官方实现有细微但致命的差异（特别是在 Vision Embedding 的输出维度对齐上），这种强制适配通常以失败告终。

3.3 针对 Unsloth 的微调现状

Unsloth 以其显存优化和训练加速闻名，是许多显存受限用户的首选。

• 支持状态： 不支持 10。
• 技术壁垒： Unsloth 的加速原理是重写了特定模型架构（如 Llama、Mistral、Qwen）的底层 Triton 内核。虽然 Dots.OCR 的语言部分是 Qwen2.5，但其视觉部分是自定义的 NaViT。Unsloth 目前没有针对 NaViT 编写专门的梯度计算内核。
• 替代建议： Unsloth 官方和社区均强烈建议用户转向 Qwen2.5-VL-7B。Qwen2.5-VL 同样具备处理动态分辨率的能力，且得到了 Unsloth 的官方原生支持（包括 4-bit 量化微调），是目前微调多模态模型的最佳平替方案 10。

3.4 微调结论

综上所述，微调 Dots.OCR 目前属于“高投入、低回报”的科研级工程任务，而非工程级应用任务。 对于绝大多数希望提升特定领域 OCR 效果的用户，我们强烈建议：

1. 放弃微调 Dots.OCR，转而使用其强大的 In-Context Learning（上下文学习）能力，通过构建更好的 Prompt 来引导输出。
2. 若必须微调，请转向 Qwen2.5-VL 或 Llama-3.2-Vision。这两个模型拥有完善的微调生态支持，且架构原理与 Dots.OCR 相似。

4. 详解 prithivMLmods/Dots.OCR-Latest-BF16：不仅仅是搬运

用户特别询问了 prithivMLmods/Dots.OCR-Latest-BF16 的情况。这并非一个普通的模型搬运（Re-upload），它是目前 Dots.OCR 生态中最重要、最推荐使用的版本。

4.1 诞生的背景：Transformers 版本的断裂

在 2024 年末至 2025 年初，Hugging Face 的 transformers 库进行了一次重大更新（版本跨越 v4.37 到 v4.40+），其中对多模态模型的处理器基类 Qwen2VLProcessor 进行了严格的参数校验升级。

• 原版的问题： Rednote HiLab 发布的原始权重配置（config.json）是基于旧版库生成的。在新版 transformers 中加载原版模型时，代码会抛出 TypeError，抱怨缺少 video_processor 参数 11。这是因为新版库默认 Qwen2 架构必须包含视频处理配置，而 Dots.OCR 是纯图像模型，配置文件中缺少这一项。
• 导致的后果： 任何试图在最新环境（如 Colab 默认环境、新配置的 Docker 容器）中运行原版 Dots.OCR 的用户都会遭遇“开箱即崩”。

4.2 PrithivMLmods 版本的关键改进

用户 prithivMLmods（以及早期的 strangervisionhf）针对上述问题发布了这个修复版本。它主要包含三个层面的改进，使其成为事实上的“标准版”：

4.2.1 配置文件热修复（Hotfix）

该版本手动修补了 preprocessor_config.json，显式添加了 video_processor: null 或与之兼容的配置项。这使得模型可以被 transformers >= 4.40（甚至最新的 4.57.1）正确加载，消除了 NoneType 错误 12。

4.2.2 BF16 精度转换（Crucial for Modern GPUs）

原版模型可能以 FP32 或混合精度发布。prithivMLmods 版本明确将权重转换为 Bfloat16 (BF16) 格式 12。

• 数值稳定性： BF16 拥有与 FP32 相同的指数位宽（8位），这意味着它能表示的数值范围极广，不容易在训练或推理过程中出现溢出（Infinity）或下溢（Zero）。这对于基于 Transformer 的大模型在 Ampere（RTX 3090/4090, A100）及 Hopper（H100）架构 GPU 上的稳定运行至关重要。相比之下，FP16 经常因数值范围不够而导致 Loss NaN。
• 显存优势： 相比 FP32，BF16 节省了一半的显存。这使得 3B 级别的模型（视觉+语言）可以轻松塞入 8GB 甚至 6GB 显存的消费级显卡中。

4.2.3 Flash Attention 2 集成

该版本的模型卡片明确标注了 attn_implementation="flash_attention_2" 12。

• 原理： Flash Attention 2 是一种通过优化 GPU 显存读写（IO-aware）来加速注意力计算的算法。它将标准 Attention 的 $O(N^2)$ 复杂度带来的显存瓶颈大大缓解。
• 收益： 对于 OCR 任务，尤其是处理高分辨率文档时，序列长度（Sequence Length）往往极长（超过 4096 tokens）。启用 Flash Attention 2 可以显著提升推理速度（通常提升 20%-50%），并大幅降低长序列推理时的显存占用。

结论： 如果你打算使用 Dots.OCR，请务必下载 prithivMLmods/Dots.OCR-Latest-BF16，而不是官方的 rednote-hilab/dots.ocr。前者是后者的现代化、工程化修复版，且在精度上没有损失。

5. Dots.OCR 衍生模型全谱系调查

用户希望“完整知道到底有多少个衍生模型”。这是一个不断变化的目标，但基于截至 2025 年 11 月的数据，我们整理出了目前现存的 9 个主要衍生版本/项目。这些模型并非都是独立的微调版，更多是针对不同硬件环境的适配版。

表 1：Dots.OCR 模型家族与衍生版本一览

关键缺失：GGUF 版本的缺席

在衍生模型生态中，有一个显眼的空白：目前不存在可用的 GGUF 版本 16。

• GGUF 是 llama.cpp 和 Ollama 使用的模型格式，是本地 CPU/Mac 推理的标准。
• 原因： llama.cpp 需要用 C++ 重写模型的所有算子。虽然它支持 Qwen2.5，但它不支持 NaViT 的 Patch n' Pack 视觉编码器。除非 llama.cpp 团队针对 NaViT 进行底层开发（这是一项巨大的工程），否则 Dots.OCR 将无法在 Ollama 上运行。
• 影响： 这限制了 Dots.OCR 在边缘设备（如 MacBook Air、树莓派）上的普及，相比之下，Qwen2-VL 和 Llama-3.2-Vision 都有成熟的 GGUF 支持。

6. 性能评估与竞品全维对比

Dots.OCR 在发布时宣称 SOTA，但现在的真实性能如何？我们将从精度、速度、鲁棒性三个维度，将其与 GOT-OCR 2.0、MinerU、LightOnOCR 等竞品进行对比。

6.1 性能基准数据（基于 OmniDocBench 及社区实测）

下表汇总了不同模型在关键指标上的表现：

6.2 深度洞察：Dots.OCR 的强项与弱点

6.2.1 强项：阅读顺序的“理解者”

Dots.OCR 最大的优势在于**阅读顺序（Reading Order）**的恢复。在 OmniDocBench 的测试中，其阅读顺序编辑距离仅为 0.193，优于 GOT-OCR 2.0 的 0.287 8。

• 场景： 多栏排版的报纸、复杂的学术论文、图文穿插的杂志。
• 原因： 得益于 Qwen2.5 强大的语言建模能力，Dots.OCR 能够像人类阅读一样，根据语义逻辑连接断开的文本块，而不是简单地按几何坐标排序。

6.2.2 弱点：幻觉与多语言缺陷

社区反馈揭示了基准测试之外的严重问题：

• 重复生成的幻觉： 当遇到长串的特殊符号（如表单中的下划线 ________ 或省略号 ......）时，Dots.OCR 容易陷入生成循环，无限输出这些符号，直到达到 Token 上限。这是 Autoregressive（自回归）模型的典型病灶。
• 印地语/小语种崩溃： 尽管宣称多语言，但在 Reddit 用户的实测中，Dots.OCR 在处理印地语（Hindi）文档时输出了“Garbage output”（乱码或毫无意义的字符），而同期的 Gemini Pro 表现完美 18。这暗示其训练数据中非中英文的语料权重较低。

6.2.3 竞品对比：MinerU 的表格统治力

虽然 Dots.OCR 声称表格 SOTA，但在处理跨行/跨列合并单元格（Merged Cells）的复杂表格时，用户普遍反映 MinerU (MinerU 2.5) 的表现更为稳健 19。MinerU 采用了一种专门优化的 Pipeline 来处理表格结构，其 TEDS 指标虽然在某些论文数据上略低，但在真实世界的复杂 PDF 解析中更具实用性。

6.2.4 竞品对比：LightOnOCR 的速度碾压

LightOnOCR 是最新的强力竞争者。根据 LightOn 团队的报告，LightOnOCR 在保持与 Dots.OCR 相当精度的情况下，推理速度快了 6.5 倍 20。

• 原因： LightOnOCR 使用了更轻量级的视觉编码器和更高效的训练策略，避免了 NaViT 带来的沉重计算负担。
• 结论： 对于需要处理数百万页文档的企业级应用，LightOnOCR 或 GOT-OCR 2.0 是比 Dots.OCR 更具性价比的选择。

7. 结论与建议

Dots.OCR 是一款技术理念先进（NaViT + LLM 统一架构）但在工程落地层面略显生涩的模型。它证明了端到端 VLM 在解决复杂版面分析问题上的潜力，但也暴露了非标准架构在开源社区生态中的孤立无援。

针对您的需求，我们的最终建议如下：

1. 关于微调： 请勿尝试微调 Dots.OCR，除非您具备修改 Hugging Face 源码级别的工程能力。其兼容性陷阱（Preprocessor 缺失、DataCollator 冲突）是巨大的时间黑洞。若需微调，请直接选择 Qwen2.5-VL-7B，它拥有几乎相同的能力上限且生态支持完美。
2. 关于模型选择： 只有当您的核心需求是复杂版面的阅读顺序恢复（如将报纸转为 Markdown）时，Dots.OCR 才是首选。此时，请务必使用 prithivMLmods/Dots.OCR-Latest-BF16 版本。
3. 关于生产部署： 如果您的场景是海量单据识别，LightOnOCR 或 GOT-OCR 2.0 的速度优势将为您节省数倍的算力成本。如果您的场景主要是表格提取，请优先评估 MinerU。

Dots.OCR 是一个优秀的“特种兵”，但不是一个万能的“瑞士军刀”。在当前 VLM 极速迭代的背景下，它更像是一个过渡性的技术展示，其生态位的长期价值正逐渐被 Qwen2-VL 等通用多模态大模型所稀释。

引用的著作

1. SOTA OCR with Core ML and dots.ocr - Hugging Face, 访问时间为 十一月 24, 2025， https://huggingface.co/blog/dots-ocr-ne
2. helizac/dots.ocr-4bit - Hugging Face, 访问时间为 十一月 24, 2025， https://huggingface.co/helizac/dots.ocr-4bit
3. LightOnOCR-1B: The Case for End-to-End and Efficient Domain-Specific Vision-Language Models for OCR - Hugging Face, 访问时间为 十一月 24, 2025， https://huggingface.co/blog/lightonai/lightonocr
4. Qwen2-VL: Enhancing Vision-Language Model's Perception of the World at Any Resolution - arXiv, 访问时间为 十一月 24, 2025， https://arxiv.org/html/2409.12191v1
5. 访问时间为 十一月 24, 2025， https://jimmysong.io/en/ai/dots-ocr/#:\~:text=Introduction-,dots.,on%20benchmarks%20such%20as%20OmniDocBench.
6. 微调模型· Issue #12 · rednote-hilab/dots.ocr - GitHub, 访问时间为 十一月 24, 2025， https://github.com/rednote-hilab/dots.ocr/issues/12
7. Small but Mighty: How dots.ocr is Revolutionizing Document AI - Evnek Quest, 访问时间为 十一月 24, 2025， https://www.evnekquest.com/post/small-but-mighty-how-dots-ocr-is-revolutionizing-document-ai
8. rednote-hilab/dots.ocr - Hugging Face, 访问时间为 十一月 24, 2025， https://huggingface.co/rednote-hilab/dots.ocr
9. rednote-hilab/dots.ocr · Challenges and Limitations in Fine-Tuning the Dots.OCR Model, 访问时间为 十一月 24, 2025， https://huggingface.co/rednote-hilab/dots.ocr/discussions/39
10. Qwen2.5 VL for OCR : r/LocalLLaMA - Reddit, 访问时间为 十一月 24, 2025， https://www.reddit.com/r/LocalLLaMA/comments/1nwuslg/qwen25_vl_for_ocr/
11. strangervisionhf/dots.ocr-base-fix - Hugging Face, 访问时间为 十一月 24, 2025， https://huggingface.co/strangervisionhf/dots.ocr-base-fix
12. prithivMLmods/Dots.OCR-Latest-BF16 - Hugging Face, 访问时间为 十一月 24, 2025， https://huggingface.co/prithivMLmods/Dots.OCR-Latest-BF16
13. rednote-hilab/dots.ocr: Multilingual Document Layout Parsing in a Single Vision-Language Model - GitHub, 访问时间为 十一月 24, 2025， https://github.com/rednote-hilab/dots.ocr
14. Python client for dots.ocr with vLLM and Replicate backend support. Minimal deps, no file I/O. - GitHub, 访问时间为 十一月 24, 2025， https://github.com/sljeff/dots-ocr-client
15. Dots OCR - a Hugging Face Space by MohamedRashad, 访问时间为 十一月 24, 2025， https://huggingface.co/spaces/MohamedRashad/Dots-OCR
16. Feature Request: Support dots.ocr · Issue #16161 · ggml-org/llama.cpp - GitHub, 访问时间为 十一月 24, 2025， https://github.com/ggml-org/llama.cpp/issues/16161
17. Quantized version (GGUF) #36 - rednote-hilab/dots.ocr - GitHub, 访问时间为 十一月 24, 2025， https://github.com/rednote-hilab/dots.ocr/issues/36
18. I benchmarked 7 OCR solutions on a complex academic document (with images, tables, footnotes...) : r/LocalLLaMA - Reddit, 访问时间为 十一月 24, 2025， https://www.reddit.com/r/LocalLLaMA/comments/1jz80f1/i_benchmarked_7_ocr_solutions_on_a_complex/
19. rednote-hilab/dots.ocr - Multilingual document layout parsing in a single vision-language model achieving SOTA performance despite compact 1.7B LLM foundation : r/LocalLLaMA - Reddit, 访问时间为 十一月 24, 2025， https://www.reddit.com/r/LocalLLaMA/comments/1mdwngf/rednotehilabdotsocr_multilingual_document_layout/
20. LightOnOCR-1B: Making Knowledge Machine-Readable - LightOn's AI, 访问时间为 十一月 24, 2025， https://www.lighton.ai/lighton-blogs/making-knowledge-machine-readable
21. LightonOCR : Fastest OCR AI, beats DeepSeek OCR, PaddleOCR | by Mehul Gupta | Data Science in Your Pocket - Medium, 访问时间为 十一月 24, 2025， https://medium.com/data-science-in-your-pocket/lightonocr-fastest-ocr-ai-beats-deepseek-ocr-paddleocr-1fe2f0a2f1ad