做文档归档和票据录入的团队基本都遇到过同一个坎：识别效果好的模型跑不动量，跑得动量的模型错得离谱。前段时间帮一个做合同归档的团队做技术评估，对方每天要处理两万多页扫描件，早期用大参数量的多模态模型跑，单页响应慢、显存吃紧，一个卡只能挂一个实例，月底算账时电费和算力费比人工还贵；换成轻量OCR方案吧，表格线和手写批注又开始乱。最后把方向定在 0.9B 这个量级的小模型上——GLM-OCR 这类模型的意义不在于"参数小"，而在于它把文档识别这件事从"通用多模态推理"拉回到了"专用任务压缩"的轨道上，让精度、成本和性能三条线第一次有可能在一个可接受的区间里交汇。
这篇内容聊的就是把 0.9B 小模型 OCR 真正推进生产环境这件事。它不是什么跑通 Demo 的教程，而是从选型倒推、显存核算、精度分层验证、成本建模到上线后故障处理的完整链路。适合两类人看：一类是正在做文档解析选型、被大模型账单劝退的工程负责人；另一类是已经把模型跑起来了，但延迟抖动、批量吞吐、结构还原准确率始终不达标的开发者。下面这些数字和结论，一部分来自实际压测，一部分是基于常见工程实践给出的合理推算，具体环境不同，你需要按自己的硬件重新标定。
1. 把识别模型压到0.9B：选型时真正该算的三笔账
1.1 业务约束永远排在模型指标前面
很多团队做 OCR 选型的顺序是反的：先看榜单，再看论文，最后才回过头问业务要什么。这个顺序一旦定下来，后面几乎必然返工。我习惯的做法是先列出三条硬约束，再去筛模型。
第一条是输入形态。是纯打印体票据，还是包含手写批注、印章、表格、公式的混合文档？前者对模型的语言先验要求低，一个纯视觉 OCR 就够；后者必须要有结构化输出能力，否则你拿到一堆散字还得自己拼版面。
第二条是输出消费方。识别结果最终是给人看的，还是给下游系统做结构化入库的？给人看，容忍度高，错几个字不影响；做入库，一个字段错位就可能触发对账失败。这两种场景对"结构还原准确率"的要求差了一个数量级。
第三条是峰值吞吐与成本上限。这一点最容易被忽略。很多方案在离线测试时表现完美，一上生产就崩，原因不是模型不行，而是它压根没为高并发设计。0.9B 这个参数量最大的价值，正是让"单卡多实例 + 批量并发"成为可能，而不是单纯追求榜单上的那零点几个点。
把这三条写清楚之后，你会发现可选范围其实很窄。参数量在 10B 以上的通用多模态模型，基本可以排除在"高吞吐低成本"场景之外；参数量低于 0.3B 的轻量检测识别模型，在复杂版面上又撑不住。0.9B 恰好卡在中间这段真空带里。
1.2 精度、成本、延迟之间不是线性关系
这里要说一个反直觉的结论：从 0.9B 换到 7B，精度提升往往只有几个百分点，但成本会涨五到八倍，延迟涨三到五倍。原因在于文档识别是一个"任务收敛度很高"的问题——字形识别、版面切分、阅读顺序这些子任务，对模型的世界知识依赖其实不深，更多依赖视觉特征提取的充分性和输出格式的约束能力。0.9B 的容量足够把这些模式装进去，再往上加参数，边际收益递减得很厉害。
我用一组粗略的对比说明这个关系（数据为常见实践下的推算区间，仅供理解趋势）：
| 参数量级 | 单页视觉token | 单页解码耗时 | 单卡可挂实例 | 复杂版面结构还原 | 相对单页成本 |
|---|---|---|---|---|---|
| 0.3B 级 | 800–1200 | 0.3–0.8s | 6–10 | 弱，表格易串行 | 1x |
| 0.9B 级 | 1200–2000 | 1.0–2.5s | 2–4 | 中等偏上，常规表格可用 | 3x |
| 7B 级 | 2000–4000 | 4–9s | 1 | 强，复杂版面和公式更稳 | 15x 以上 |
看这张表要抓住一个关键点：成本的增长速度快于精度的增长速度。如果你的业务里 90% 的文档是标准打印件，那 0.3B 级方案加一些规则后处理，性价比反而最高；只有当复杂版面占比超过两三成、且结构错误会直接影响下游业务时，上到 0.9B 才有账可算。而 7B 级方案，我一般只在"离线、低量、高价值"的场景里推荐，比如合同条款抽取，一天就那么几百份，慢一点无所谓。
1.3 0.9B 这个规模适合落在什么位置
把上面两节合起来看，0.9B 小模型 OCR 的最佳落点是：中高吞吐、混合版面、需要结构化输出、成本敏感但不能牺牲太多准确率的在线或准在线业务。典型的如发票批量核验、合同关键页归档、证件信息录入、报告扫描件转 Markdown。
它不适合的场景也很明确：一是超高精度要求且无法容忍任何字符错误的场景，比如某些法律文书的逐字比对，这种还是得上更大模型加人工复核；二是极端低延迟场景，比如要求单页 200ms 内返回的实时交互，那得往纯检测识别的小模型方向走，而不是生成式 OCR。
我个人的判断是，0.9B 这类模型是当前"可自建、可私有化、成本可控"这条线上最有性价比的一档。它让你不必依赖外部接口，也不必为了一次识别去买一张 80GB 的卡。
2. 部署形态：显存账算不明白，后面全是白搭
2.1 单卡到底能放几个实例
这是部署阶段第一个必须算清的账。很多人直接按"参数量乘以数据类型字节数"估权重，然后拍脑袋留 30% 余量，结果一上并发就 OOM。正确的算法要分四块。
第一块是模型权重。0.9B 参数在 fp16 下约 1.8GB。但生成式 OCR 通常是"视觉编码器 + 语言解码器"的组合结构，视觉侧还会额外占几百兆到 1GB。整体权重按 2.0–2.5GB 估比较稳妥。
第二块是激活值与框架开销。推理框架本身、CUDA context、算子 workspace，这部分在 24GB 卡上实测通常吃掉 1.5–2.5GB，跟你开几个实例关系不大，属于固定成本。
第三块是 KV Cache。这是最容易低估的。单页图像编码后视觉 token 大约 1200–2000 个，加上输出序列，单请求的 cache 在几百兆级别。批大小 8 和批大小 1，这部分能差出 3–4 倍。
第四块是预处理缓冲区。图像解码、缩放、归一化，如果放在 GPU 上做，一页 A4 高分辨率扫描件转成张量后能占到 50–100MB，批量时也得算进去。
按这个拆法，一张 24GB 卡的具体账大概是这样：
权重（单实例） 2.4 GB 框架与上下文固定开销 2.0 GB ───────────────────────────── 单实例批1时的动态占用 1.2 GB (激活 + KV + 缓冲) 单实例峰值 5.6 GB 24GB 卡理论上限 4 个实例 留出安全余量（15%） 3 个实例（推荐）所以我的经验值是：24GB 显存卡跑 0.9B 级 OCR，稳态挂 2–3 个实例比较合理，不要追求 4 个。第 4 个实例在平稳期看不出问题，一旦遇到长文档或者突发并发，显存水位迅速顶到 95% 以上，紧接着就是请求排队和超时雪崩。留余量不是浪费，是买保险。
2.2 在线同步与离线批量必须拆成两条链路
把同步请求和批量任务混在一个服务里，是生产环境最常见的设计失误。原因很简单：这两类流量的资源模型完全相反。
在线同步请求的特点是量小、延迟敏感、并发不可预测。它需要常驻实例、低批大小、快速响应，一页就是一到三秒。批量任务的特点是量大、延迟不敏感、可以慢慢攒批。它需要高批大小、高吞吐、允许排队，把一批五十页塞进去跑，单页平均耗时反而能降一半。
我的建议是物理隔离，至少是逻辑上分成两个服务：
| 维度 | 在线同步链路 | 离线批量链路 |
|---|---|---|
| 批大小 | 1–2 | 8–32 |
| 实例数 | 常驻 2 个，弹性扩容 | 按队列深度伸缩，可缩到 0 |
| 超时设置 | 15–30s | 300–600s |
| 队列 | 无队列或极短 | 有持久化消息队列 |
| 失败重试 | 立即重试 1 次 | 指数退避，最多 3 次 |
| 优先级 | 高 | 低，可被抢占 |
拆开之后有个额外好处：批量链路可以放心用更便宜的资源。比如夜间跑批，用低优先级实例把队列清空，白天释放，成本能压掉相当一块。
2.3 预热、常驻与冷启动的取舍
生成式 OCR 的冷启动时间不是闹着玩的。模型加载、权重搬运、首次推理的算子编译（如果用了图优化或编译模式），首请求可能要 20–60 秒。如果没有预热，第一个用户请求必然会超时。
具体做法是三段式：
- 进程启动后立即跑一次空推理，用一张内置的 300×300 小图走完整链路，把所有算子触发一遍，把 cache 建起来。这一步不要省。
- 服务对外暴露健康检查接口时，把"已预热"作为就绪条件之一，而不是进程起来就打到负载均衡上。
- 扩容时采用"先预热后接流"，新实例预热完成才加入流量池，老实例延迟下线。
常驻实例数怎么定？我一般按"日常 P95 并发乘以 1.2"来配，再保留一个最小数量。比如日常并发 6，那就常驻 5 个不缩容，超出部分走弹性。缩容到 0 看着省钱，但每次缩到零再拉起来，光预热就够呛，用户体验断崖式下跌。
提示：如果你的部署环境支持多进程共享显存（部分推理框架支持），可以把权重只加载一份，多个 worker 共享，这样实例数能往上提一档。但这个特性在不同版本上行为不一致，上线前一定要做长时间压测验证，别在白天流量高峰才开始试。
3. 精度验证：别拿一个综合分数糊弄自己
3.1 把文档识别拆成四层来度量
我见过太多团队用一个整体的"准确率"汇报进度，结果上线后问题百出，因为一个数字根本定位不了故障点。文档识别的误差来源至少有四层，必须分层看。
第一层：版面分析。模型输出是不是把区域分对了？页眉页脚有没有被当成正文？双栏文档有没有被读成单栏交错？这一层错了，后面全错，而且错得很隐蔽——每个字都识别对了，但阅读顺序乱了，语义完全变了。
第二层：文字识别。这是传统 OCR 的命题，字符级准确率（CER）和词级准确率（WER）。打印体一般能到 98% 以上，手写和低质量扫描会掉到 85% 甚至更低。
第三层：结构还原。表格的行列关系、合并单元格、公式的 LaTeX 表达、列表层级。这部分最考验模型，也最容易在综合分数里被稀释掉。
第四层：输出格式合法性。输出是不是合法的 Markdown？表格标记有没有闭合？LaTeX 公式有没有语法错误？这一层不影响内容正确性，但直接影响下游能不能解析，属于"不合格就全废"的硬门槛。
分层之后，你会发现问题定位变得非常快。比如整体准确率掉了 5 个点，一看是第三层表格结构掉得厉害，那就去查样本里是不是新增了一批复杂表格，而不是盲目地调参或者换模型。
3.2 字符级指标之外，必须有结构指标
字符级指标有个致命缺陷：它看不见位置关系。一段文字内容全对，但顺序全反，CER 依然是零错误。所以我在做精度评估时，一定会补上两个结构类指标。
阅读顺序一致性：把模型输出的文本块顺序，和人工标注的标准顺序做序列比对，计算编辑距离归一化后的得分。这个指标能直接暴露双栏、多栏、图文混排场景的问题。
表格单元格对齐率：对每一张表格，先按行列解析出二维结构，再和标注表逐格比对。空单元格也算一格，合并单元格展开成多格。这个指标算下来通常比字符准确率低十到二十个点，但它才是真实业务关心的数字。
另外加一个字段级抽取准确率：如果你下游是按字段用的，比如发票的价税合计、合同甲乙方，那就直接按字段比。字段准确率的算法是"完全正确的字段数 / 总字段数"，一个字都不许错。这个数字最残酷，也最贴近业务体感。
3.3 回归集怎么建才不白费功夫
回归集的构建逻辑，不是"样本越多越好"，而是"覆盖度越准越好"。我的做法是按二维矩阵来组织：
| 维度 | 取值 |
|---|---|
| 文档类型 | 发票、合同、报告、证件、手写笔记 |
| 版式复杂度 | 单栏纯文本、双栏、含表格、含公式、图文混排 |
| 质量等级 | 高清电子版、普通扫描、低分辨率、倾斜/褶皱、印章遮挡 |
| 语言 | 中文、英文、中英混排 |
每个格子放 3–5 个样本，总共大概 60–100 份文档就足够做回归了。数量不用多，关键是每个格子的分布要和线上真实流量接近——如果线上 70% 是普通扫描的发票，那回归集里就不能全是高清电子版合同。
还有一点很重要：回归集要留一部分永不参与任何调优。我习惯留出 20% 作为"盲测集"，只在版本上线前的最后一步跑一次。因为一旦你用某个样本调过参数，它就不再具备评估意义了，模型只是在记忆它。
3.4 灰度对比法：新版本怎么证明没退步
每次换模型版本或改预处理，都要回答一个问题：新版本整体上是变好了还是变坏了？只看平均分会骗人，因为可能某几类文档大幅改善，另几类严重退化，平均下来持平。
我用的方法是分类型双向对比表。在灰度期间，让新旧两个版本对同一批文档各跑一遍，按文档类型分别统计：
# 伪代码，核心是分桶统计而不是算总分 results = {} for doc_type in ["invoice", "contract", "report", "id_card"]: old_score = eval_on(subset[doc_type], version="old") new_score = eval_on(subset[doc_type], version="new") delta = new_score - old_score # 只要有一个类型跌幅超过阈值，就阻断上线 if delta < -0.01: block_release(f"{doc_type} 跌幅 {delta:.2%}") results[doc_type] = delta判断标准我一般定的是：任何单一类型的跌幅不能超过 1 个百分点，整体平均分提升至少 0.5 个百分点，才允许全量。这个规则看着严，但能避免掉很多"整体变好、局部崩盘"的翻车事故。
4. 成本核算：单页成本的完整公式
4.1 显存、算力与吞吐的换算链条
很多人算成本只算"每小时多少钱除以每小时处理页数"，这个算法漏了一大截。完整的单页成本公式应该包含四部分：
单页成本 = (实例小时费用 × 实例数 / 每小时实际有效页数) + 预处理成本 + 后处理成本 + 人力运维摊销
先看第一项的核心变量——每小时实际有效页数。它不等于理论吞吐，要打两个折扣。第一个折扣是利用率，即实例真正在计算的时间占比，一般 60%–75%，剩下的时间在处理队列、等待网络 IO、做健康检查。第二个折扣是失败重试损耗，如果重试率是 3%，那有效页数还要再乘 0.97。
举个具体的例子。假设一张卡能跑 3 个实例，单实例批处理下每小时能处理 600 页，那么：
理论吞吐 = 3 × 600 = 1800 页/小时 考虑 70% 利用率 = 1260 页/小时 考虑 3% 重试 = 1222 页/小时如果这张卡的成本是每小时 C 元，那单页算力成本就是C / 1222。这个数字才是能拿去和人工成本、外部接口成本做对比的。
4.2 被严重低估的三块隐性成本
说完显存账，说三块真正烧钱的地方，这三块在方案汇报里通常不会出现，但在月度账单上实实在在。
第一块：图像预处理。扫描件动辄 300 DPI、A4 尺寸，单张 PNG 可能 3–8MB。解码、纠偏、去噪、自适应缩放，这些如果全在 CPU 上做，一台中等配置的机器可能成为瓶颈。如果放到 GPU 上做，又会挤占推理显存。我遇到过一次，推理侧明明只用了 60% 显存，整体吞吐却上不去，最后查出来是 CPU 侧图像预处理排队。解决方案是把预处理做成独立服务，按需扩容，并且对同一批文档做格式归一化，优先转成高质量的 JPEG 而不是保留原始格式。
第二块：后处理与格式修复。模型输出的 Markdown 偶尔会有没闭合的表格、错位的列表层级、LaTeX 语法错误。这些需要一层校验和修复逻辑。这层逻辑如果写得重（比如引入完整 Markdown parser 再重建），CPU 开销不小。建议是轻量正则先过一遍，只对失败样本走重解析，把成本控制在少数样本上。
第三块：存储与审计。生产环境通常要留原始图像、模型原始输出、修复后结果三份。一页 5MB 的原图，一天一万页就是 50GB，一个月 1.5TB。这块要么做冷热分层，热数据存 7 天，冷数据归档压缩；要么干脆只留哈希和结果，原图按需回源。别小看这一块，很多项目的存储费用最后超过了算力费用。
4.3 三种部署形态的账单对比思路
这里不给绝对价格，因为硬件和云厂商差异太大，给个相对比较的框架更有用。
| 部署形态 | 固定成本 | 变动成本 | 适用规模 | 主要风险 |
|---|---|---|---|---|
| 自建单机 | 硬件一次性投入 | 电费、运维人力 | 日处理 5000 页以内 | 峰值扛不住，扩容慢 |
| 云上常驻实例 | 无 | 实例小时费，按 24h 计 | 日常稳定流量 | 低峰期资源闲置浪费 |
| 云上弹性 + 预留 | 少量预留费 | 弹性部分按需计费 | 有明显波峰波谷 | 冷启动延迟，配置复杂 |
关键的判断依据是波峰波谷比。如果你的流量曲线很平（比如内部系统，白天晚上差不多），常驻实例最省心；如果峰谷比超过 3 倍（比如电商大促期间的票据核验），弹性方案能省下可观的一笔；如果日处理量在几千页且长期稳定，自建单机的单位成本最低，但要接受扩容周期长这个现实。
我个人的经验是，先用云上常驻跑一个月，拿到真实的流量曲线和单页成本，再决定要不要转弹性或自建。上来就搞复杂架构，往往是在为一个还不存在的规模做优化。
5. 性能调优：从秒级延迟到可控区间
5.1 分辨率与视觉token预算的取舍
这是调优里收益最大、也最容易调过头的一项。生成式 OCR 的耗时基本正比于视觉 token 数量，而视觉 token 数量又跟输入图像的分辨率强相关。一张 A4 扫描件，如果按长边 2048 送进去，视觉 token 可能是 3000 多；压到长边 1280，token 降到 1200 左右，耗时直接砍掉一半以上。
但分辨率不是越低越好。这里有个临界点：字符高度低于 12–15 像素时，识别准确率会明显下滑。换算一下，A4 纸宽 210mm，如果按长边 1280 缩放，宽度方向大概 900 像素，一行正文 40 个字符的话，每字符宽度约 22 像素，还够用；但如果文档本身是小字号（比如 8pt 的表格注释），那就悬了。
我的做法是按文档类型设不同档位，而不是全局一刀切：
# 按类型给不同长边限制，返回前做一次字符高度估算 RESOLUTION_PROFILE = { "invoice": {"long_side": 1536, "min_char_px": 14}, "contract": {"long_side": 1792, "min_char_px": 16}, "report": {"long_side": 1536, "min_char_px": 14}, "id_card": {"long_side": 1024, "min_char_px": 20}, "handwriting":{"long_side": 2048, "min_char_px": 18}, } def pick_long_side(doc_type, est_char_height_px): cfg = RESOLUTION_PROFILE[doc_type] # 估算缩放后字符高度，低于阈值就抬档 if est_char_height_px < cfg["min_char_px"]: return min(cfg["long_side"] * 1.5, 2560) return cfg["long_side"]这个逻辑的核心思想是：默认用低成本档位，只在检测到字符过小时抬档。大部分文档走快路径，少部分复杂文档走慢路径，整体平均耗时就下来了。实测下来，这套策略能在精度损失小于 0.5 个点的前提下，把 P50 延迟压掉 35% 左右。
5.2 动态分桶：让批处理真正提效
批处理提效的前提是同一批里的样本尺寸接近。如果一批里混了一张 800×600 的小票和一张 3000×4000 的图纸，那么整个批都得 padding 到最大尺寸，小票白白浪费算力，而且显存还不够。
解决办法是动态分桶：按图像的宽高比和面积做聚类，同桶内的样本才拼成一批。实践中的桶划分不用太细，按长边区间分 4–6 档，按宽高比再分 2 档（横向、纵向），一共 8–12 个桶就够了。
配套还要设一个等待窗口。批量链路里，一个桶里攒够 N 个样本或者等够 T 毫秒就发车。这个参数要平衡：等太久吞吐上去了但端到端延迟变长；等太短批不满，提效有限。离线批量的场景，我一般设 N=16、T=2000ms；准在线场景设 N=4、T=300ms。
5.3 推理参数与量化：哪些能省，哪些不能碰
量化是最直接的提速手段，但生成式 OCR 对量化的敏感度比纯文本模型高。原因是视觉编码器输出的特征数值分布比较宽，量化误差容易被放大，最后表现为"个别字符乱码"或者"表格标记错位"。
实测下来的经验：
| 方案 | 显存节省 | 耗时变化 | 精度影响 | 建议 |
|---|---|---|---|---|
| fp16 基线 | — | — | — | 精度优先场景用这个 |
| 权重 int8 量化 | 约 45% | 快 20%–30% | 通常 < 0.5 点，个别字体有抖动 | 推荐，务必跑回归 |
| 权重 + 激活 int8 | 约 55% | 快 30%–40% | 1–2 点，表格结构易出错 | 谨慎，需分类型验证 |
| int4 | 约 70% | 快 40% 以上 | 3 点以上，不推荐用于生产 | 不建议 |
解码参数上，贪心解码（temperature=0）是生产环境的默认选择。OCR 不需要创造性，采样只会引入不确定性。同时把max_new_tokens设成按文档类型估算的上限，比如单页发票 800、合同页 1500，超了就截断并标记为可疑样本。这个限制很重要，没有它，某些异常输入会让模型反复输出直到撞到硬上限，一个请求占着显存好几十秒。
还有个小细节：重复惩罚参数在 OCR 里要慎用。开启之后确实能减少模型"复读"，但也可能让表格里正常的重复内容（比如多行相同的"0.00"）被强行改写。我的做法是默认关闭，只在检测到输出长度异常时临时打开。
6. 上线之后才暴露的六个问题
6.1 长文档的显存抖动怎么稳住
测试阶段都是单页跑，上线后遇到几十页的合并 PDF，问题全出来了。表现是：前几页正常，跑到中途显存持续上涨，最后 OOM 或者请求被框架杀掉。
根因在于长序列的 KV Cache 是线性增长的，而很多服务框架的显存池是预分配的，一旦超过预留水位就直接失败。处理办法有三层：
第一层是前置切分。超过阈值的文档（比如 10 页以上）在入口就按页拆开，每页独立识别，最后按序拼接。这个改动最简单也最有效，缺点是跨页的表格和段落会被打断。
第二层是显存水位监控 + 主动拒绝。服务里加一个后台线程，每 200ms 采一次显存使用率，超过 85% 就把新请求打回队列，而不是硬扛。宁可排队，不要雪崩。
第三层是请求级超时熔断。单页处理超过预设时间就中断，把已生成的部分结果返回并标记为不完整。这个兜底能避免一个卡死的请求拖垮整个实例。
6.2 低质量扫描件与倾斜矫正
真实文档里，倾斜 2–5 度的情况极其常见，尤其是批量扫描和手机拍照。模型对轻微倾斜有一定鲁棒性，但超过 5 度后，阅读顺序和表格结构就开始出错。
我的处理链是这样：先用轻量的文本检测拿到所有文本行的角度中位数，超过 1.5 度就做旋转校正，然后重新送模型。这个检测可以在 CPU 上跑，一张图几十毫秒，成本很低，收益很大。
还有一个反直觉的点：不要让模型自己处理旋转。有些方案会把原图直接送进去，指望模型理解。实测下来，模型对 90 度、180 度这种大角度能应付，对小角度倾斜基本无能为力，而且输出会变得不稳定。手动校正之后再送，准确率提升明显。
6.3 输出结构不稳定的兜底设计
模型输出偶尔会不合法：表格少了分隔线、列表层级乱掉、公式的$没闭合。这类问题占比不高，但一旦发生，下游解析器直接抛异常，整条链路挂掉。
兜底策略要分两级。一级是就地修复：用正则做轻量修补，比如补齐未闭合的表格行、把孤立的分隔符删掉、把不成对的标记补全。这一级不追求语义正确，只保证格式可解析。二级是降级输出：修复失败的样本，退化成纯文本 + 位置坐标的形式返回，虽然丢了结构，但内容还在，下游可以按"低置信度"标记后走人工复核。
这两级兜底一定要做，而且要统计触发率。我一般把一级修复率控制在 3% 以内、二级降级率控制在 0.5% 以内作为健康线，超过就说明模型版本或者预处理有问题，需要回查。
6.4 置信度缺失，得自己造一个
不少生成式 OCR 模型不直接输出置信度分数，这对生产环境很不友好，因为下游没法做分流。我的做法是用一个轻量的代理指标构造置信度。
具体是三个信号加权：输出长度异常度（实际输出 token 数和该类型文档的期望区间偏离多少）、结构完整度（表格闭合、公式成对、列表层级是否合法）、字符集异常度（输出里是否出现大量罕见字符或乱码符号）。三项各自归一化后加权求和，落在一个 0–1 区间。
这个分数不是严格的概率，但用来做排序和分流足够。实践中设两个阈值：低于 0.5 直接进人工复核队列，0.5 到 0.75 之间进抽样复核，高于 0.75 直接入库。这样能把人工复核量控制在一个可承受的比例上。
注意：这个代理置信度必须定期用真实标注数据校准。模型版本一换，分数的分布就变了，阈值不重新标定就会导致复核量暴增或漏检率上升。我的习惯是每次版本升级后，用盲测集跑一遍，画出分数分布，重新定位两个阈值。
6.5 并发突增时的排队策略
生产环境一定会遇到突发流量，比如月底集中报销、审计季批量调档。这时候如果采用 FIFO 队列，短任务会被长任务堵住，整体响应时间急剧恶化。
我的处理是双队列 + 任务大小预判。在入口根据文件大小和页数做一次粗判，页数少的进快队列，页数多的进慢队列。快队列配更多实例、更高优先级，慢队列用剩余容量慢慢消化。这样 90% 的小文档能在可接受时间内返回，少数大文档排队也不会让用户完全无感。
同时要给每个队列设准入上限，队列超过一定长度就直接返回 429，让上游退避重试，而不是无限堆积。堆积到一定程度之后，所有请求都会超时，等于全部失败，还不如早拒绝。
6.6 模型更新带来的格式漂移
这个问题最隐蔽。模型换了个版本，精度指标看着提升了，但输出格式的细节变了——比如原来用|分隔的表格变成了 HTML<table>标签，或者列表的缩进从两个空格变成了四个。下游解析器当场崩溃。
所以每次模型升级，除了跑精度回归，还必须跑一遍格式契约测试。具体做法是把一批标准文档的输出存成快照，新版本输出后做结构化 diff，只要有字段的格式类型发生变化，就视为不兼容，需要同步改下游。
这个测试集不用大，二三十份覆盖各类结构的文档就够，但它必须自动化、每次升级都跑。我吃过这个亏，一次小版本升级后表格全变成了 HTML，上游解析静默失败，结果数据入库了但全是空的，两天后才发现。
7. 我在这类项目里攒下的几条实用判断
7.1 先定降级方案，再谈精度优化
这个顺序很多人不理解。我的理由是：生产环境里，可用性永远优先于准确率。一个准确率 92% 但从不宕机的系统，比一个准确率 96% 但每周挂两小时的系统有价值得多。所以在开始调精度之前，先把降级链路打通：模型超时怎么办、输出非法怎么办、服务不可用怎么办。这些兜底建好之后，你才有底气去做那些可能引入风险的优化。
7.2 精度调优的投入产出比在预处理而不在模型
这是我踩了很多坑才认下来的结论。早期我总想着换更大模型、调更多参数，后来发现收益最大的改动全在预处理：图像纠偏、去噪、对比度归一化、分辨率自适应。这些改动加起来，对最终准确率的提升往往超过换一个大两倍的模型，而成本几乎为零。
具体到操作上，我建议在送模型之前固定做四件事：灰度化并做自适应二值化的判断（不要无脑二值化，彩色文档会被破坏）、检测并校正倾斜、裁掉大面积纯色边框、按内容密度决定缩放档位。这四步做完，低质量文档的识别率能提升好几个点。
7.3 监控要盯的是分布，不是均值
线上监控里，"平均延迟 1.8 秒"这种指标基本没有决策价值。真正要看的是 P95、P99 延迟，以及它们的变化趋势。我一般会在看板上放三条线：P50、P95、P99，再加一条超时率。当 P99 开始抬头而 P50 不动的时候，通常意味着有少量异常输入在拖后腿，这时候去查样本分布，比等到平均延迟涨上去再动手要早好几天。
同样地，精度监控也要看分布。按文档类型、按来源渠道分别统计准确率，只要某一类的准确率出现连续三天的下滑趋势，就该拉告警了，哪怕整体平均分还是稳的。
7.4 别把批大小调到极限
压测的时候容易犯一个错：把批大小一路往上加，看吞吐什么时候到顶，然后在生产里就按那个值配。问题在于，压测环境是理想状态，生产里有长文档、有突发、有各种边界输入。按极限值的 60%–70% 配，才是稳态能扛住的水平。
我一般的做法是：找到吞吐随批大小增长的拐点（再往上加吞吐不再明显提升的那个点），然后取拐点值的 70% 作为生产配置。这样既拿到了大部分吞吐收益，又留出了应对异常输入的缓冲。
7.5 保留一份"最差样本集"
除了前面说的回归集和盲测集，我还会额外维护一份"最差样本集"——就是历史上识别效果最烂的那几十份文档，可能是印章遮挡严重的合同、纸张褶皱的票据、手写体潦草的验收单。这份集合不参与任何指标计算，只在每次大版本上线前跑一遍，看有没有变得更烂。
它的价值在于，正常指标反映的是平均水平，而这份集合反映的是下限。下限一旦崩了，用户投诉往往就集中在这批文档上，虽然数量少，但每一条都是硬伤。维护成本很低，收益很实在。
7.6 关于 0.9B 这个量级的最终判断
用了这么久，我的整体判断是：0.9B 级 OCR 模型是当前自建文档识别方案里性价比最好的一个档位，但它不是万能的。它的甜蜜区是"结构相对规整、质量中等以上、需要结构化输出、日处理量在几千到几万页"的业务。超出这个范围，要么往上走用大模型加人工复核，要么往下走用专用检测识别模型加规则拼装，都不该硬扛。
真正决定项目成败的，往往不是模型选得对不对，而是预处理链路、兜底设计、精度分层验证和成本核算这四件事做得够不够细。模型只是整条链路里的一环，把它放进一个设计良好的系统里，0.9B 能发挥出的效果，比放在一个粗糙系统里的 7B 要好得多。
