0.9B OCR小模型生产级部署：精度、成本与性能平衡实践

文档识别这件事，做 Demo 和上生产完全是两码事。Demo 阶段你随手丢一张清晰的扫描件进去，模型吐出漂亮的 Markdown，你会觉得这事儿成了；真到了生产环境，面对的是歪的、糊的、带水印的、盖了章的、双栏排版的、夹杂手写批注的几十万页历史档案，同时老板还在盯着每页处理成本——这时候你才会意识到，0.9B 小模型做 OCR 生产级部署，真正的难点根本不在模型本身，而在精度、成本、性能这三者之间那条细得几乎看不见的平衡线。我这套东西跑了大半年，从最初被大模型的账单吓退，到后面把 0.9B 量级的 OCR 小模型调到能扛住每天十几万页的稳定吞吐，中间踩的坑够写一篇长文。下面这些内容适合正在做文档解析、票据识别、合同要素抽取、扫描件数字化的同行参考，也适合刚接手 OCR 服务、还没搞清楚该选大模型还是小模型的朋友。全文围绕一个核心问题展开：在真实业务里，怎么把一个 0.9B 的 OCR 小模型部署成既跑得起、又认得准、还付得起钱的生产服务。文中统一用“0.9B OCR 小模型”指代这类不到十亿参数、支持文档/表格/公式解析的视觉语言模型，不绑定任何具体产品。

1. 为什么在文档识别场景里死磕 0.9B 这个量级

1.1 从一笔真实的账单倒推：大模型 OCR 的成本黑洞

我最开始是用一个几十 B 参数的通用多模态大模型做文档解析的，效果确实好，复杂表格、印章遮挡、手写批注都能认个七七八八。但第一份月度成本报表出来的时候，我盯着那个数字看了半分钟没说话。按当时的调用量算下来，单页成本大约是小模型方案的 6 到 10 倍，而且这还是在我们做了大量缓存和去重之后的结果。

成本高的原因不难拆：大模型的单次推理要跑几十亿参数的矩阵乘，即使你的图片只有一页、输出只有几百个 token，它也要把整个模型权重过一遍。更要命的是 token 计费方式——OCR 任务的输出 token 数量是跟着文档内容线性增长的，一页密密麻麻的合同，输出可能有两三千 token，成本直接起飞。而 0.9B 的小模型，权重体积和计算量都小了一个数量级，同样的卡、同样的时间，能处理的页数是前者的好几倍。

这里要说清楚一个容易被忽略的点：OCR 场景的成本结构里，模型推理并不是唯一项。我粗略拆过一笔账，在自建推理集群的情况下，单页成本大致由四块构成：

看这张表就明白了：如果你用大模型，第一项会膨胀到把其他所有优化都白做的地步。这就是为什么我最终决定往小模型方向走——不是因为小模型更先进，而是因为在“每天几十万页、单页毛利只有几分钱”这类业务里，成本结构决定了技术选型。

1.2 小模型的能力边界在哪里：精度、显存、时延的三角关系

0.9B 不是随便挑的数字。往小了走，比如两三百 M 的专用检测识别模型，速度快、成本低，但它只能做“文字在哪、是什么字”，做不了版面理解和结构化输出，遇到跨行合并的表格单元格、跨页续表的表头继承，它就抓瞎了。往大了走，几 B 到几十 B，能力强，但单卡吞吐掉得厉害，而且很多能力对 OCR 任务来说是冗余的。

0.9B 这个量级恰好卡在一个甜点区：它具备一定的版面理解和序列生成能力，可以按你给的 schema 输出结构化 JSON；同时权重在 bf16 下只有 1.8G 左右，加上视觉编码器、KV Cache 和激活值，单请求实际占用在 4 到 6G 之间，一张 24G 显存的卡能同时挂好几个并发实例。

但边界也很清楚，我实测下来这几类任务是它明显的短板：

• 超长文档：单次输出 token 有上限，一份上百页的标书如果整本塞进去，必然截断。解决办法只能是切页 + 跨页表头继承，用工程手段补。
• 极端复杂表格：三层以上嵌套表头、大量合并单元格、单元格内又套小表，这类识别错误率会明显上升。
• 手写体：印刷体和小字号的识别相当稳，但潦草手写、连笔签名的准确率不稳定，得靠人复核兜底。
• 低质量扫描件：歪斜、透背、油墨晕染、传真件噪点，这些必须在预处理阶段解决，指望模型自己扛不现实。

所以我的判断标准很朴素：如果你的业务里印刷体文档占比超过八成、表格结构以两三层为主、对单页时延容忍度在秒级，那 0.9B 完全够用；反过来，如果核心业务是手写票据、古籍、超复杂财务报表，别硬扛，老老实实上大模型或者做模型路由。

1.3 什么样的业务适合上小模型，什么情况必须换回大模型

我把过去接过的几类场景整理了一下，这张对照表基本能覆盖大部分判断：

判断的核心其实就两条：单位页的收益能不能覆盖单位页的成本，以及错误造成的损失能不能被后处理兜住。前者是算账，后者是工程。两条都过了，就放心用小模型；有一条过不了，就别为了省钱硬上，最后返工的成本比省下来的算力费高得多。

提示：不要用“平均精度”这种指标做选型决策。一定要按业务字段拆开看，比如合同场景里“金额”和“条款正文”错一个字的代价完全不同，权重化之后的加权准确率才有参考意义。

2. 部署前的选型与压测：把“能用”和“能扛”区分开

2.1 推理框架怎么挑：别一上来就上最重的

0.9B 这个体量，推理框架的选择其实比大模型宽松很多。我实际试过三种路线，各有适用面：

• vLLM / SGLang 这类面向生成的推理引擎：优势是 PagedAttention、连续批处理（continuous batching）做得好，高并发下的吞吐表现最稳，适合 API 化对外服务的场景。缺点是启动配置项多，图片输入的支持要看具体版本的多模态适配程度。
• ONNX Runtime / TensorRT 导出后推理：极致性能路线，量化之后延迟能压得很低，适合固定输入尺寸、追求单页时延的批处理场景。代价是导出链路麻烦，模型一升级就得重走一遍，工程维护成本高。
• 原生 PyTorch + 手写批处理：最灵活，改模型、加预处理钩子最方便，适合还在调优阶段。但吞吐上限明显，一旦并发上来就顶不住，不建议直接拿去扛生产流量。

我的最终方案是主链路走 vLLM，把服务包在 FastAPI 里做路由和治理，批处理离线任务走 TensorRT 导出的加速版本。这样在线请求优先保时延和稳定性，离线补录任务优先保吞吐，两套并行，互不干扰。

2.2 三张表定生死：精度表、吞吐表、资源占用表

部署之前必须做压测，而且是在自己的真实数据上压，不要用公开 benchmark 的数字代替。我一般会产出三张表：

第一张是精度表，按文档类型分层抽样，每类至少 200 页，人工标注 ground truth，然后计算：

• 字符错误率（CER）= (替换 + 删除 + 插入) / 总字符数
• 字段级准确率：针对业务抽取的字段（金额、日期、编号），完全匹配才算对
• 表格结构相似度：按单元格坐标和内容双维度打分
• JSON 合法率：输出能被 schema 校验通过的比例

第二张是吞吐表，测的是不同 batch size 和并发数下，每秒处理页数（PPS）的变化曲线。这里有个反直觉的点：batch size 从 1 加到 8，吞吐大约涨 3 到 4 倍；从 8 加到 32，可能只再涨 1.2 倍，但尾延迟会翻倍。所以我一般把在线服务的 batch 上限卡在 8 到 16 之间。

第三张是资源占用表，记录每个并发档位下的显存峰值、GPU 利用率、CPU 占用。显存峰值要以实测为准，别信理论值——我第一版按权重 ×1.3 估算，结果实际跑起来撞了 OOM，因为高分辨率图片的视觉 token 数量把激活值顶上去了。

2.3 我踩过的坑：显存预估和实际占用差了一倍

说个具体的。最早我按“0.9B 参数 bf16 ≈ 1.8G 权重，加上各种开销算 4G”来规划，在 24G 卡上开了 6 个实例，觉得绰绰有余。上线第一天晚高峰直接连环 OOM。

排查下来是两个原因叠加：一是图片分辨率的隐式膨胀，我默认把图片长边缩放到 1600 像素，视觉编码器切出来的 patch 数量比预想的多出近一倍；二是KV Cache 没算进峰值，长文档输出的场景下，cache 增长很可观，而且它是随请求动态涨的，压测时短文档跑不出来。

最后的处理方式很土但有效：给每个实例设显存硬上限（gpu_memory_utilization之类参数），把并发卡在压测确认的安全水位上，剩下的显存留给突发；同时在网关层做排队，超过水位就等，不让它冲进 OOM。改完之后连续跑了两个月没再出过这个问题。

注意：压测一定要用最长的那批文档做边界测试，而不是随机抽样。决定显存峰值的是最坏情况，不是平均值。

3. 生产级部署的实操落地

3.1 环境拉起与服务初始化配置

先说环境。我用的是容器化部署，镜像里固定 CUDA 版本、推理引擎版本和模型权重版本，做到“镜像 tag 即版本号”，避免出现“本地能跑线上不能跑”的经典问题。基础依赖大致这样装：

# 基础环境（示例，版本按实际锁死） pip install --no-cache-dir \ torch==2.x.x \ transformers==4.x.x \ fastapi uvicorn[standard] \ pillow opencv-python-headless \ pydantic jsonschema # 生成式推理引擎按官方方式安装 pip install vllm==x.x.x

启动服务的时候，这几个参数是必须显式指定的，我不建议用默认值：

python -m vllm.entrypoints.openai.api_server \ --model /models/ocr-0.9b \ --served-model-name ocr-small \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 16 \ --limit-mm-per-prompt image=1 \ --port 8000

逐个解释一下为什么这么设。--dtype bfloat16是精度和显存的最佳折中，降到 fp16 在这类模型上收益有限但偶发溢出；--max-model-len 8192是输入图片 token 加输出 token 的总上限，设太小长文档会被截断，设太大显存预留会过多；--gpu-memory-utilization 0.85是给显存留 15% 的缓冲，防止碎片和突发把进程打挂；--max-num-seqs 16是并发序列上限，这个值一定要根据压测结果调，不是越大越好。

权重文件在构建镜像时就固化进去，不要运行时下载。运行时下载的坑我踩过——某个凌晨上游仓库抖动，整个服务重启全部失败，那晚的记忆相当深刻。

3.2 推理参数调优：那些“看起来无关紧要”的开关

模型跑起来只是第一步，参数调优才是决定生产可用性的关键。我按影响从大到小排一下：

图片分辨率是第一优先级。长边控制在 1280 到 1600 之间是我实测的甜点区。低于 1024，小字号（比如 6 号字）开始糊，识别错误率明显上升；高于 2048，精度提升不到 1 个百分点，但时延和显存差不多翻倍。这个关系大致是平方级的，因为视觉 patch 数量随边长的平方增长。

输出长度上限要按业务设。合同类文档我设 4096，票据类设 1024。设太大不仅浪费显存预留，还会让模型在生成长度受限前的推理变慢。同时要开stop词控制，在输出完整的 JSON 结束符后立刻截断，避免模型继续生成多余内容。

温度参数直接设 0 或者极低值。OCR 是确定性任务，任何采样带来的随机性都是负收益。我见过有人用默认温度 0.7 跑 OCR，同样的图片两次输出不一样，排查了半天以为是模型 bug。

提示词要极简且固定。小模型的指令跟随能力不如大模型，提示词越复杂越容易跑偏。我的模板基本就三段：任务描述、输出 schema、待识别图片。schema 用 JSON Schema 的形式给出，并在提示里明确“只输出 JSON，不要输出多余解释”。

OCR_PROMPT = """请识别图片中的文档内容，按以下 JSON Schema 输出，不要输出任何额外说明文字。 Schema: { "type": "object", "properties": { "blocks": { "type": "array", "items": { "type": "object", "properties": { "type": {"enum": ["title", "text", "table", "formula", "figure"]}, "content": {"type": "string"}, "bbox": {"type": "array", "items": {"type": "number"}} }, "required": ["type", "content"] } } }, "required": ["blocks"] } """

3.3 后处理与结构化输出校验：最后的防线

模型输出的 JSON 一定会有不合法的，这不是“如果”，是“必然”。我的经验是初次上线阶段 JSON 合法率在 92% 到 96% 之间，经过提示词打磨和 few-shot 优化后能到 98% 以上，但永远到不了 100%。所以后处理是必须的。

后处理链路我分四层：

1. 格式修复层：处理常见的 JSON 破损——缺右括号、多余逗号、中文引号、被 Markdown 代码块包裹、前后有解释性废话。用正则加括号配对修复，能救回六成左右的非法输出。
2. Schema 校验层：用 JSON Schema 校验器严格校验，失败的进重试队列，重试时把校验错误信息回填到提示词里，让模型自我修正一次。
3. 业务规则层：金额字段做数字归一化（去掉千分位、统一小数点、处理“壹万贰仟”这类大写），日期统一成 ISO 格式，编号做正则匹配校验。这一层能抓出很多“格式对但内容错”的问题。
4. 置信度打分层：对关键字段做交叉验证，比如表格里的合计金额要和明细求和比对，对不上就打低分标记人工复核。

import json, re, jsonschema def repair_json(raw: str) -> str: s = raw.strip() # 去掉模型爱加的 markdown 代码块包裹 s = re.sub(r"^```(?:json)?\s*|\s*```$", "", s, flags=re.MULTILINE) # 中文引号转英文 s = s.replace("“", '"').replace("”", '"') # 尝试截取第一个 { 到最后一个 } start, end = s.find("{"), s.rfind("}") if start != -1 and end > start: s = s[start:end + 1] # 去掉对象/数组结尾的多余逗号 s = re.sub(r",\s*([}\]])", r"\1", s) return s def validate(raw: str, schema: dict): fixed = repair_json(raw) try: data = json.loads(fixed) except json.JSONDecodeError as e: return None, f"json_error: {e}" try: jsonschema.validate(data, schema) except jsonschema.ValidationError as e: return None, f"schema_error: {e.message}" return data, None

这段代码看着朴素，但在生产里挡掉了大量无效请求，比调模型参数见效快得多。

3.4 服务治理：限流、超时、降级、灰度一个都不能少

模型服务上线之后，最怕的不是慢，是雪崩。一次上游批量导入几万页文档，如果没有任何保护，请求直接把队列打满，所有在线请求一起超时，整个业务线瘫掉。我这套服务的治理策略是这样的：

• 入口限流：按租户/业务线做令牌桶限流，保障重要业务优先。不同业务给不同配额，别一视同仁。
• 分级超时：单页请求 30 秒超时，超过就返回降级结果。这个值是根据 P99 时延乘 1.5 定的，不是拍脑袋。
• 降级链路：小模型超时或失败时，降级到传统检测识别方案出纯文本结果（不带结构化），虽然信息损失但至少业务能继续跑。进一步失败就返回“处理中”，进异步重试队列。
• 灰度与双跑：模型版本升级时，先切 5% 流量，同时把同一批请求双跑到新旧两个版本，抽检 2% 做人工比对，指标达标再逐步放量。
• 异步任务队列：批量文档一律走异步，前端拿任务 ID 轮询，避免长连接堆积。

提示：降级链路一定要定期演练。我见过太多服务写了降级代码，结果真出事的时候发现降级依赖的那个传统方案早就没人维护，跑起来比主链路还慢。

4. 成本账怎么算：把每千页成本压下来

4.1 单页成本拆解公式与实测数据

我喜欢把成本算到一个很细的单位：每千页多少钱。这个数字比“每 token 多少钱”直观得多，也更容易跟业务方对齐。

计算公式大致是：

单页成本 = (GPU 卡时单价 / 每小时有效处理页数) + 单页 CPU 后处理成本 + 单页存储与传输成本 + 单页运维摊销

我实测的一组数据（24G 显存单卡、0.9B 模型、输入长边 1440、平均输出 600 token）：

看这张表能得出一个很明确的结论：优化收益的大头在批处理，其次是量化，最后是缓存。很多人一上来就折腾量化，其实先把连续批处理跑通，成本就能砍掉七成。

4.2 优化手段按收益排序，从大到小逐个上

下面是我实际的优化顺序，供参考。每一步都建议单独压测，看看实际收益再决定是否保留。

第一步：连续批处理。收益最大，成本最低，只要推理引擎支持，配置一下就能生效。注意要监控排队时延，batch 太大导致首字延迟变高，用户体验会变差。我一般控制在 P95 首字延迟 800ms 以内。

第二步：图片预处理瘦身。这一步收益常被低估。很多原始图片是 4000×3000 的高清扫描件，直接缩放确实会丢信息，但先做自适应裁剪再去边框再缩放，能在几乎不损失精度的前提下把输入 token 数减少三四成。我具体做的是：先用轻量的版面检测把正文区域裁出来，去掉大面积白边和扫描仪黑边，再缩放到目标分辨率。

第三步：量化。INT8 或 FP8 是主流选择，速度提升大概 30% 到 50%，精度损失在 0.5 到 1.5 个百分点之间，具体看数据类型分布。我的做法是只量化视觉编码器和线性层，语言模型部分的关键层保留 bf16，这样精度损失能压到 0.5 个点以内。量化之后一定要重跑精度表，别用旧指标。

第四步：缓存去重。批量补录场景里，重复图片和近似重复图片的比例不低，我做图片内容 hash 之后，命中率大概在 15% 到 25% 之间。这个收益是白捡的。

第五步：模型路由。对简单的单据类型（比如固定版式的发票），派给更轻量的分支；只有复杂文档才走完整模型。这一层收益大但工程复杂度高，建议放到最后做。

4.3 一张对比表：优化前后到底差多少

把上面几步全做完，我做了一次完整的对比压测，用同一批 5000 页的真实文档：

有意思的是精度那一栏：优化之后字段准确率还微涨了 0.4 个点。原因是分辨率调整和裁剪去噪把原本因图片冗余信息导致的干扰去掉了，模型反而更聚焦。这个现象在工程里挺常见的——很多时候不是模型不够强，是喂给它的东西太脏。

5. 精度兜底与常见问题排查

5.1 典型识别失败场景与针对性处理

跑了大半年，失败案例基本能归成几类，我按出现频率排一下：

多栏排版串行。学术论文、报纸这类双栏甚至三栏排版，模型容易把左右栏的文字按水平位置串起来读。解决办法是在预处理阶段做栏切分——用投影法统计垂直方向的黑像素分布，找白谷切分，然后按栏顺序分别送模型，最后按阅读顺序拼接。

表格跨页断开。一张表跨了两页，第二页只有表体没有表头，模型认出来的列就对不上。我的处理是维护一个“表格上下文”状态，把上一页的表头结构作为提示信息带进下一页的请求里，同时在后处理阶段根据列数和对齐关系做校验合并。

印章/水印遮挡。红色印章盖在文字上，模型容易把被遮的字认错或者干脆漏掉。这个纯靠模型很难解决，我在预处理里加了颜色通道分离，把红色通道单独提取出来做掩码，然后把印章区域标记成“遮挡区域”，输出时保留位置信息，交给下游做人工确认。

低质量扫描件。透背、噪点、倾斜、摩尔纹，一套组合拳。我的预处理管线是：灰度化 → 自适应二值化（局部阈值）→ 倾斜校正（霍夫变换估计角度，超过 0.5 度就转正）→ 中值滤波去噪 → 对比度拉伸。这套下来能救回大部分垃圾件。

长文档截断。超过输出 token 上限的部分直接丢失，这是最危险的静默失败。我的处理是在服务层做页数感知：单次请求最多送一页，多页文档在调度层拆开，每个子任务带上页码和上下文，最后合并。绝对不要指望模型自己处理超长输入。

5.2 问题排查速查表

这张表是我贴在工位旁边的，出问题先对照查一遍，能省下大量盲目调试的时间：

5.3 精度提升的工程手段：不换模型也能涨几个点

最后分享几个我觉得性价比很高的手段，都不需要重训模型：

少样本示例（few-shot）。在提示词里放 1 到 2 个同类型的正确输出样例，对固定版式文档的提升非常明显，尤其是表格结构。代价是输入 token 变长，时延略增，但相比精度收益完全值得。

多尺度投票。对关键页面用两个不同分辨率各跑一次，两份结果做字符级对齐，不一致的位置标记低置信度。这个手段能把关键字段的准确率再提 1 到 2 个点，代价是算力翻倍，所以只对高价值文档启用。

分类前置。先用一个轻量分类器（哪怕是规则加图像特征）判断文档类型，再根据类型切换提示词模板和后处理规则。发票和合同的 schema 完全不同，用一套提示词硬扛所有类型，精度必然打折扣。

人工复核采样。按置信度分层抽样，低置信度全量复核，高置信度抽 1% 到 2%。这个机制的价值不只是纠错，更重要的是持续产出标注数据，为后续的模型微调积累素材。

定期回归测试。建一个固定的人工标注测试集，每次模型升级、参数调整、预处理改动之后都跑一遍，指标掉超过 0.5 个点就拦下来。这个习惯救过我一次——有次换了个预处理库的版本，二值化算法默认参数变了，导致浅色文档大面积识别失败，靠回归测试当天就发现了。

6. 我在长期运维这套服务后的几点体会

跑了大半年，最大的感受是：0.9B 小模型的生产价值，八成来自工程而不是模型本身。同样一个权重文件，有人部署出来每千页成本高得离谱、天天 OOM、精度忽高忽低；有人部署出来稳定扛住十几万页日流量，成本压到原来的六分之一。差别全在预处理、批处理、后处理、服务治理这些“不性感”的地方。

第二个体会是，精度指标一定要分桶看，不要看全局平均。我踩过一次坑：整体字符准确率 97.5%，看着挺漂亮，结果财务那边炸了，因为“金额”这一类的字段准确率只有 91%。全局指标会把少数关键字段的错误稀释掉，而业务恰恰只关心那几个字段。

第三个是心态上的：别追求 100% 的自动化。OCR 这件事，模型再强也会有需要人看一眼的边界情况。设计系统的时候就把“人工复核”当成正常链路的一环，而不是异常处理，架构会干净很多，业务方接受度也高得多。我现在的做法是按置信度分流，高置信度直接入库，中置信度异步抽检，低置信度进人工队列——整体自动化率大概 92%，剩下 8% 的人力成本完全在可接受范围内，比死磕那几个点精度划算太多。

最后一个实用小技巧：给你的服务加一个按文档类型和置信度分桶的监控看板，每天扫一眼。真出问题的时候，这个看板能让你在十分钟内定位到是哪一类文档、哪个环节出的问题，而不是从几十万条日志里大海捞针。我这套看板就是被一次深夜告警逼出来的，现在成了日常运维最常用的东西。