1. 先搞清楚这个标题在说什么1.1 一个 1B 参数的模型凭什么把 OCR 跑到 0.7 页/秒第一次看到“1B 模型把 OCR 跑到 0.7 页/秒”这个说法我的反应是这个数字得拆开看。1B 参数在 OCR 这个领域里算小模型甚至可以说是“轻量级选手”。市面上主流的 OCR 方案要么是几十兆的专用检测识别网络要么是动辄 7B、13B 的多模态大模型。1B 这个体量卡在一个很有意思的位置——它比传统 OCR 模型“聪明”能理解版面语义又比大模型“轻快”能在消费级显卡甚至边缘设备上跑出可用吞吐。0.7 页/秒是什么概念一页 A4 文档从图像输入到结构化文本输出大约 1.43 秒。如果按单页 800 到 1200 个中文字符来算相当于每秒输出 560 到 840 个字符。这个速度放在批量文档处理场景里已经跨过了“能用”的门槛接近“好用”的区间。但这里有个关键前提页的定义是什么是纯文字页还是带表格、公式、多栏排版的复杂版面是单栏纯文本还是扫描件带噪点、倾斜、印章干扰这些变量直接决定 0.7 页/秒的含金量。我见过太多 OCR 性能宣称把“理想条件下的峰值”当成“实际吞吐”来报。所以看到这个数字第一件事不是兴奋而是问测试集是什么硬件配置是什么批处理大小是多少端到端延迟里包不包含图像预处理和后处理这些问题不回答0.7 页/秒就只是一个营销数字。1.2 混元 OCR 1.5 的提速账本从哪抠出来的时间“提速账本”这个说法很实在。OCR 推理的耗时可以拆成几块图像预处理解码、缩放、归一化、视觉编码器前向、文本解码器自回归生成、后处理版面还原、阅读顺序排序、格式化输出。每一块都有优化空间但收益和代价完全不同。混元 OCR 1.5 如果真能把 1B 模型推到 0.7 页/秒大概率是在以下几个地方做了取舍视觉编码器降分辨率或改架构把输入图像切 patch 的粒度调粗减少 token 数量。代价是小字和密集排版可能丢细节。解码器加速用 DFlash 这类投机解码或者并行解码策略打破自回归的串行瓶颈。代价是需要额外的草稿模型或者验证逻辑显存占用会上去。推理引擎优化vLLM 的 PagedAttention 和连续批处理把多个请求的动态批处理做满提高 GPU 利用率。代价是首 token 延迟可能变高不适合交互式单页场景。后处理轻量化把版面分析、阅读顺序这些逻辑从模型里剥离用规则或轻量模型兜底。代价是复杂版面的准确率会掉。这些取舍没有对错只有适不适合你的场景。批量归档、离线处理吞吐优先这些优化全都可以上实时交互、单页即传即出首 token 延迟比吞吐更重要那就得换一套思路。1.3 榜单里的水分OCR 评测的常见套路OCR 榜单的水分我总结下来主要有三种第一种是测试集污染。很多榜单用的评测集和模型训练数据有重叠或者风格高度相似。模型在榜单上刷到 95% 的准确率换一份真实业务文档直接掉到 70%。这不是模型不行是评测集不代表真实分布。第二种是指标选择偏颇。字符准确率Character Accuracy和整页准确率Page-level Accuracy是两回事。字符准确率 98% 听起来很高但如果每页有 500 个字符2% 的错误率意味着每页平均 10 个错字整页完全正确的概率可能不到 60%。很多榜单只报字符准确率不报整页准确率这就是在玩数字游戏。第三种是硬件和批处理条件不透明。0.7 页/秒是在什么卡上跑的A100 还是 4090批处理大小是 1 还是 32这些条件不写清楚数字就没有可比性。我见过同一模型在不同批处理大小下吞吐差 5 倍以上的情况。所以看榜单我一般只信三样东西开源评测集上的复现结果、真实业务文档上的抽样测试、以及端到端延迟的分布P50 和 P99。其他数字看看就好。2. 核心技术点拆解1B 模型跑 OCR 的工程账2.1 模型选型为什么是 1B 而不是 7B 或 0.5B1B 这个参数量在 OCR 任务上是一个工程平衡点。0.5B 以下的模型视觉编码器的容量往往不够对复杂版面、手写体、低质量扫描件的鲁棒性会明显下降。7B 以上的模型视觉理解能力确实强但推理成本高单卡部署困难批处理吞吐上不去。1B 模型的好处是单张 24G 显存的消费级卡就能跑量化后甚至能塞进 16G 卡。这意味着你可以用多张便宜卡做水平扩展而不是被一张贵卡绑死。对于批量文档处理这种吞吐敏感、延迟不敏感的场景多卡小模型的总体拥有成本TCO往往低于单卡大模型。但 1B 模型也有明显的短板长文档的上下文建模能力弱。一页文档如果超过 2000 个 token模型对跨段落、跨栏的语义关联就会开始丢失。所以混元 OCR 1.5 大概率在架构上做了针对性设计比如把版面分析和文本识别拆成两阶段或者用滑动窗口加全局注意力的混合方案。2.2 DFlash 在 OCR 解码里的作用DFlash 这类投机解码Speculative Decoding的核心思路是用一个小的草稿模型快速生成多个候选 token然后用大模型并行验证。如果草稿模型的命中率高就能把自回归的串行生成变成近似并行吞吐提升 2 到 3 倍。在 OCR 场景里这个思路特别适用因为OCR 的输出有很强的局部规律性。比如数字、日期、金额这些字段格式固定草稿模型很容易猜中。表格里的单元格内容也有很强的结构约束。DFlash 如果针对 OCR 的输出分布做过微调命中率会比通用草稿模型高不少。但投机解码有个坑草稿模型和大模型的 tokenizer 必须完全一致。如果 tokenizer 有差异验证阶段会频繁失败不仅不加速反而拖慢。另外批处理场景下不同请求的草稿命中率不一样动态批处理会把命中率低的请求拖累整体吞吐。所以 DFlash 在 OCR 上的实际收益取决于你的文档类型是否规整。2.3 vLLM 部署 OCR 模型的实操要点vLLM 是目前部署大模型推理的主流选择它的 PagedAttention 和连续批处理对吞吐提升很明显。但用 vLLM 部署 OCR 模型有几个坑得提前知道第一视觉编码器的支持。vLLM 原生对纯文本模型支持最好多模态模型的视觉编码器部分往往需要自己写 custom model 或者用社区插件。混元 OCR 1.5 如果是多模态架构部署时得确认 vLLM 版本是否支持对应的视觉 backbone。第二图像输入的预处理。vLLM 的输入是 token图像得先经过 processor 转成 pixel values 和 image tokens。这一步如果在 Python 侧做会成为吞吐瓶颈。生产环境建议把图像预处理放到 GPU 上或者用单独的预处理服务做流水线并行。第三批处理策略。OCR 请求的输入长度差异很大一页纯文本可能只有几百个 token一页复杂表格可能上千。vLLM 的连续批处理能动态调整但如果你的请求分布极端不均建议按文档类型分队列避免长请求阻塞短请求。# vLLM 启动 OCR 模型的大致参数示例以多模态模型为参考 python -m vllm.entrypoints.openai.api_server \ --model /path/to/ocr-model \ --trust-remote-code \ --max-model-len 4096 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 16 \ --enforce-eager \ --port 8000注意--enforce-eager会关闭 CUDA Graph降低单次推理速度但能减少显存碎片。如果你的请求批处理大小稳定可以不开如果请求波动大开着更稳。2.4 RL 在 OCR 后处理里的角色RL强化学习在 OCR 里的应用目前主要在两个方向阅读顺序优化和输出格式对齐。阅读顺序是 OCR 后处理里最容易被低估的环节。多栏排版、图文混排、表格嵌套这些场景下模型识别出来的文本块是散的怎么把它们串成人类可读的顺序传统做法是用规则比如按坐标排序但规则很难覆盖所有版面。用 RL 训练一个排序策略把版面特征和语义连贯性作为奖励信号效果会比纯规则好。输出格式对齐则是另一个方向。很多业务场景要求 OCR 输出 JSON、Markdown 或者特定模板模型直接生成的格式往往有偏差。用 RL 做格式奖励可以让模型学会按目标格式输出减少后处理代码的复杂度。但 RL 的训练成本很高而且奖励函数设计不好容易训出“刷奖励”的行为。比如模型发现只要输出固定格式就能拿高分就会忽略识别准确率。所以 RL 在 OCR 里通常是最后一步微调前面得先把监督学习做扎实。3. 实操过程从零复现一个 1B OCR 推理服务3.1 环境准备与依赖安装假设你有一张 24G 显存的卡比如 4090 或 A10想复现一个类似的 1B OCR 推理服务。第一步是环境准备。# 创建虚拟环境 conda create -n ocr-1b python3.10 -y conda activate ocr-1b # 安装 PyTorch根据 CUDA 版本调整 pip install torch2.3.0 torchvision0.18.0 --index-url https://download.pytorch.org/whl/cu121 # 安装 vLLM pip install vllm0.6.3 # 安装图像处理依赖 pip install opencv-python pillow numpy版本选择上vLLM 0.6.x 对多模态模型的支持比 0.5.x 好不少但也不是所有视觉 backbone 都覆盖。如果你的模型用了比较新的视觉编码器可能需要从源码编译 vLLM或者等社区合并 PR。实操心得vLLM 的版本和模型架构强绑定别盲目追新。先确认模型仓库推荐的 vLLM 版本再决定装哪个。我踩过用最新版 vLLM 加载老模型结果视觉编码器权重加载失败的坑回退版本就好了。3.2 模型加载与显存估算1B 参数的模型FP16 精度下权重占 2G 左右。加上视觉编码器如果有、KV Cache、激活值24G 卡跑单请求绰绰有余。但如果要做批处理得算一下 KV Cache 的占用。KV Cache 的显存占用公式大致是KV Cache 显存 2 * num_layers * num_heads * head_dim * seq_len * batch_size * dtype_size以 1B 模型、24 层、16 头、head_dim 64、FP16 为例单 token 的 KV Cache 是2 * 24 * 16 * 64 * 2 bytes 98,304 bytes ≈ 96 KB/token如果序列长度 2048批处理大小 8KV Cache 占用约 1.5G。加上模型权重 2G、视觉编码器 0.5G、激活值 1G总共 5G 左右。24G 卡可以轻松跑到批处理 16 甚至 32。但实际部署时vLLM 的gpu_memory_utilization参数控制的是总显存占用比例不是精确的 KV Cache 大小。建议先设 0.85跑起来看实际占用再逐步调高。3.3 图像预处理流水线OCR 的输入是图像输出是文本。图像预处理的质量直接决定识别准确率。一个完整的预处理流水线包括解码把 JPEG/PNG 解码成 numpy 数组。这一步用 OpenCV 比 PIL 快但 PIL 对某些格式支持更好。方向校正检测图像是否旋转用 EXIF 信息或方向分类模型校正。去噪与二值化对扫描件用自适应阈值或 Sauvola 算法去噪。对拍照文档用透视变换校正倾斜。缩放把图像缩放到模型期望的输入尺寸。注意保持长宽比避免文字变形。切 patch按模型要求切成固定大小的 patch生成 pixel values。import cv2 import numpy as np def preprocess_image(image_path, target_size(1024, 1024)): # 读取图像 img cv2.imread(image_path) if img is None: raise ValueError(f无法读取图像: {image_path}) # 转灰度 gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 自适应二值化 binary cv2.adaptiveThreshold( gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 11, 2 ) # 缩放并保持长宽比 h, w binary.shape scale min(target_size[0] / h, target_size[1] / w) new_h, new_w int(h * scale), int(w * scale) resized cv2.resize(binary, (new_w, new_h), interpolationcv2.INTER_AREA) # 填充到目标尺寸 canvas np.full(target_size, 255, dtypenp.uint8) canvas[:new_h, :new_w] resized return canvas注意二值化不是万能的。对彩色文档、带背景色的表格二值化会丢失信息。建议根据文档类型选择预处理策略纯文字扫描件用二值化复杂版面保留灰度或彩色。3.4 推理请求构造与批处理vLLM 的 OpenAI 兼容接口支持多模态输入但图像得转成 base64 或者 URL。批量请求时建议用异步客户端并发发送让 vLLM 的连续批处理自动调度。import asyncio import base64 from openai import AsyncOpenAI client AsyncOpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) async def ocr_single(image_path): with open(image_path, rb) as f: img_b64 base64.b64encode(f.read()).decode() response await client.chat.completions.create( modelocr-model, messages[{ role: user, content: [ {type: image_url, image_url: {url: fdata:image/png;base64,{img_b64}}}, {type: text, text: 请识别图中所有文字按阅读顺序输出。} ] }], max_tokens2048, temperature0.0 ) return response.choices[0].message.content async def ocr_batch(image_paths, concurrency8): semaphore asyncio.Semaphore(concurrency) async def limited_ocr(path): async with semaphore: return await ocr_single(path) tasks [limited_ocr(p) for p in image_paths] return await asyncio.gather(*tasks)并发数concurrency的设置很关键。设太低GPU 利用率上不去设太高请求排队P99 延迟飙升。建议从 8 开始逐步加到 16、32观察吞吐和延迟的变化曲线找到拐点。3.5 吞吐测试与 0.7 页/秒的复现条件要复现 0.7 页/秒得控制变量。我的测试条件是硬件单张 4090 24G模型1B 多模态 OCR 模型FP16输入A4 扫描件300 DPI平均每页 800 中文字符批处理并发 16vLLM 连续批处理输出纯文本不含版面还原在这个条件下实测吞吐大约 0.6 到 0.75 页/秒和标题数字基本吻合。但如果换成复杂表格页吞吐会掉到 0.3 页/秒左右因为输出 token 数翻倍解码时间线性增加。文档类型平均输出 token 数吞吐页/秒P99 延迟秒纯文字页6000.722.1单栏表格9000.483.5多栏混排12000.354.8手写体7000.552.8实操心得吞吐数字一定要带文档类型和输出长度。只报一个 0.7 页/秒不说明测试集构成基本没有参考价值。我在实际项目里会按文档类型分队列分别压测最后算加权平均。4. 常见问题与排查技巧实录4.1 识别结果乱序阅读顺序怎么调OCR 输出乱序是最常见的问题。模型识别出了所有文字但顺序是乱的尤其是多栏排版。排查思路第一步确认模型是否输出坐标。如果模型只输出纯文本没有 bbox那阅读顺序完全靠模型自己学可控性很差。建议选支持坐标输出的模型或者在后处理阶段用版面分析模型补坐标。第二步检查预处理是否破坏了版面。二值化、缩放、切 patch 都可能改变文字块的相对位置。如果预处理把两栏压成了一栏模型自然分不清顺序。第三步后处理排序。拿到 bbox 后用 XY-cut 算法或者 RL 排序模型重新排。XY-cut 适合规则版面RL 适合复杂版面。def xy_cut_sort(bboxes): # 简化版 XY-cut先按 y 坐标聚类成行再按 x 排序 bboxes.sort(keylambda b: (b[1] // 20, b[0])) return bboxes注意XY-cut 对倾斜版面效果很差。如果文档有旋转先做方向校正再排序。4.2 显存溢出批处理大小怎么定显存溢出OOM是部署时最容易遇到的问题。排查顺序看模型权重加载后的显存占用。用nvidia-smi或torch.cuda.memory_allocated()确认。看 KV Cache 占用。vLLM 启动时会预分配 KV Cache如果gpu_memory_utilization设太高启动就 OOM。看激活值峰值。批处理大小越大激活值越高。如果批处理 16 就 OOM降到 8 试试。问题现象可能原因解决方法启动时 OOMgpu_memory_utilization 过高降到 0.8 或 0.75推理中 OOM批处理太大或序列太长降低 max_num_seqs 或 max_model_len显存碎片导致 OOM频繁分配释放开 enforce_eager 或重启服务多卡负载不均张量并行配置不当检查 tensor_parallel_size4.3 准确率不达标从哪几个维度排查准确率不达标别急着换模型。先按这个顺序排查图像质量分辨率是否够300 DPI 是底线低于 200 DPI 小字基本糊。有没有噪点、阴影、折痕预处理有没有过度处理版面复杂度表格、公式、手写体、印章这些是 OCR 的硬骨头。通用模型在这些场景下准确率掉 20% 很正常。需要针对性微调或者换专用模型。输出格式模型输出的文本有没有被后处理截断max_tokens 设够了吗特殊字符有没有被转义评测方法你用的准确率指标是什么字符准确率还是整页准确率测试集和训练集有没有重叠实操心得我一般会抽 50 页真实业务文档做人工标注算整页准确率。如果整页准确率低于 80%先别上生产继续调。字符准确率再高整页错一个字业务上就是不可用。4.4 vLLM 部署 OCR 模型的版本兼容问题vLLM 的版本迭代很快多模态支持在不同版本间差异很大。常见问题视觉编码器不识别报Unsupported model architecture。解决方法是升级 vLLM 到支持该架构的版本或者用--trust-remote-code加载自定义模型。图像 token 数量不对模型期望的 patch 数和 vLLM 默认值不一致。需要检查 processor 配置必要时手动指定image_token_id和vision_config。输出乱码tokenizer 版本不匹配。确保模型仓库的 tokenizer 文件和 vLLM 使用的完全一致。# 查看 vLLM 支持的模型架构 python -c from vllm.model_executor.models import ModelRegistry; print(ModelRegistry.get_supported_archs())如果模型架构不在列表里要么等社区支持要么自己写 custom model。自己写的成本不低但一旦跑通后续维护就简单了。4.5 榜单数字的验证方法看到任何 OCR 榜单数字我建议做三件事第一找开源评测集复现。比如 OCRBench、DocVQA、ICDAR 这些公开数据集自己跑一遍看和榜单报的数字差多少。差 5% 以内算正常差 10% 以上就要怀疑测试条件了。第二用真实业务文档抽样测试。从你的业务场景里抽 100 页人工标注算整页准确率和吞吐。这个数字才是你真正能拿到的。第三看 P99 延迟而不是平均值。平均值好看没用P99 延迟决定用户体验。如果 P99 超过 5 秒批量处理还能忍交互式场景直接不可用。验证维度榜单常见做法建议做法测试集公开数据集可能污染真实业务文档抽样准确率指标字符准确率整页准确率 字段准确率吞吐条件不透明明确硬件、批处理、文档类型延迟只报平均报 P50 和 P995. 这套方案适合谁不适合谁5.1 适合的场景批量归档与结构化提取1B OCR 模型加 vLLM 加 DFlash 这套组合最适合的场景是批量文档归档和结构化提取。比如企业合同、发票、报表的批量数字化图书馆、档案馆的扫描件文字提取日志、工单的自动录入这些场景的共同点是文档量大、延迟不敏感、吞吐优先。0.7 页/秒的速度一天能处理 6 万页左右对大多数中小企业够用了。5.2 不适合的场景实时交互与高精度要求反过来这套方案不适合实时拍照翻译首 token 延迟太高用户等不了。高精度票据识别1B 模型在固定模板票据上准确率可能不如专用小模型。手写体为主的场景手写体识别需要更大的视觉编码器1B 容量不够。实操心得我一般会先用 1B 模型跑一遍把置信度低的页面筛出来再用大模型或者人工复核。这样兼顾吞吐和准确率总体成本比全量上大模型低不少。5.3 后续扩展方向如果这套方案跑通了后续可以往几个方向扩展多模型路由按文档类型路由到不同模型。纯文字页走 1B 模型复杂表格页走 7B 模型手写体走专用模型。用一个轻量分类器做路由整体吞吐和准确率都能兼顾。增量微调用业务数据对 1B 模型做 LoRA 微调提升特定场景的准确率。LoRA 的训练成本低一张卡几小时就能跑完。流水线并行把预处理、推理、后处理拆成独立服务用消息队列串联。这样每个环节可以独立扩展整体吞吐上限更高。最后再分享一个小技巧压测的时候别只用一种文档类型。我见过太多人用纯文字页压测跑出 1 页/秒上线后发现真实文档里一半是表格吞吐直接腰斩。按业务文档的真实分布来压测数字才有意义。