OvisOCR2 (0.8B): 首个登顶OmniDocBench的端到端模型——我用827份真实医学扫描文档测试了它，以下是我学到的所有内容

它是什么：ATH-MaaS/OvisOCR2 —— 一个由Qwen3.5-0.8B（SFT + RL + OPD）后训练得到的0.8B文档解析视觉语言模型，采用Apache 2.0协议，运行于vLLM 0.22.1。每个页面图像输入一个提示，输出完整的Markdown格式（包括HTML表格、LaTeX公式、图片的边界框占位符）。它在OmniDocBench v1.6上获得了96.58分，是首个登顶该排行榜的端到端模型——此前排名靠前的都是流水线方法。 为什么这很重要：流水线OCR（布局检测器 -> 裁剪区域 -> 对每个区域进行OCR -> 重新组装）在布局阶段就会失败：如果检测器漏掉一个区域，该区域的文本就会悄无声息地丢失。端到端模型没有布局阶段，因此不会出现这种失败。这也意味着：一个模型、一个服务栈、无需胶水配置。 我的测试：用827份真实扫描文档与一个流水线OCR进行对比。我将它与一个GLM-OCR（0.9B流水线）部署在827份真实扫描的医学信件（密集印刷、表格、传真、质量极差的扫描件）上进行了比较，并以Gemini 3.5 Flash的转录结果作为伪真值（词级F1分数，约780份文档有参考）：指标 流水线 (GLM-OCR) OvisOCR2 平均F1 0.908 0.947 中位F1 0.942 0.971 p10 F1 (尾部!) 0.810 0.898 直接对决胜场 41 503 (236 平局) 尾部就是故事：Ovis的第10百分位接近流水线的中位数。所有流水线表现极差的文档都是由于布局检测器遗漏所致。 单张RTX 5090（vLLM 0.22.1）上的吞吐量，150 DPI渲染，温度0，max_tokens 4096：并发数 页/分钟 p50延迟 8 304 1.6秒 16 427 2.2秒 32 590 3.0秒 64 550 5.7秒 96 535 8.7秒 拐点在cc=32（约0.10 GPU秒/页）。超过后吞吐量下降，延迟随队列深度增加。 限制在哪里：单请求延迟受解码限制（约占页面时间的76%；单流约570 tok/s——经典的小模型权重读取瓶颈），但饱和吞吐量受预填充限制：一个页面约2.3k图像token对比约600个输出token，因此GPU处理的每5个token中约有4个是预填充。KV缓存从未超过约11%——VRAM对这个模型完全无关紧要；16 GB的显卡完全够用，只会按比例变慢（受计算和带宽限制，而非内存限制）。 DPI发现：从200降到150 DPI = 吞吐量提升50%，F1分数无变化（150 DPI相当于免费性能）。100 DPI = 再提升30%，但质量尾部会以糟糕的方式崩溃：表格单元格融合（日期与地址合并，行合并混乱）。如果你的文档中有重要的表格，不要低于150 DPI。 注意事项（血泪教训）重复循环（约0.5%的页面）：贪婪解码偶尔会崩溃成1111111... / O O O O / 表情符号刷屏，直到达到token上限。该问题具有确定性和可重现性。在失败的页面上测试了缓解措施：frequency_penalty 0.3 修复了5/5，presence_penalty 1.0 修复了4/5，repetition_penalty 1.05-1.1 仅修复了2/5 (!)，temp 0.2 无效。解决方案：第一次贪婪解码，检测（finish_reason=length 或退化尾部），然后用frequency_penalty 0.3重试一次。不要在第一次解码时使用惩罚——它会扭曲合法的重复内容（如表格列）。限制max_tokens。一个循环页面在批次末尾单独解码16k token，会产生约30秒的拖尾延迟。我的基准测试数字仅因拖尾放置位置不同就从383页/分钟变到了895页/分钟，直到我将max_tokens限制在4096（正常页面最多约800个输出token；仅当尾部是干净文本时才无限制重试，即真正的长页面）。 在OCR工作负载中将--mm-processor-cache-gb设置为0。真实页面是唯一的（0%命中率），如果你用重复图像进行基准测试，缓存会预热并给你华丽的数据（我在发现100% MM缓存命中之前"测量"到了1000+页/分钟）。 **必须安装ninja**，否则--gdn-prefill-backend triton路径会在启动时报FileNotFoundError（GDN线性注意力核需要JIT编译）。 经过上述所有调整后可行的启动命令： vllm serve ATH-MaaS/OvisOCR2 --gpu-memory-utilization 0.9 \ --max-model-len 32768 --gdn-prefill-backend triton \ --mm-processor-cache-gb 0 --disable-uvicorn-access-log 总而言之：在我的语料库上，这个0.8B的端到端模型在准确性（尤其是最坏情况）上击败了调优后的流水线，每GPU效率提高约2-4倍，且堆栈简单得多。重复循环是它唯一的真正缺点，而检测并重试的防护措施完全控制了它。现在，流水线OCR需要一个非常好的理由才能被采用。