OCR 上云还是本地自建：一张发票背后的成本决策与技术选型

一、一个真实的成本事故

某中型企业的报销系统每月需要处理约 6 万张发票、合同照片和证件扫描件。最初的方案非常”省事”——全部调用某云厂商的通用 OCR 接口，按调用次数计费。在选型阶段，团队算了一笔粗账：单次调用成本只有几分钱，看起来完全在预算之内。然而月末账单出来之后，情况远比预期复杂：OCR 调用费用已经超过了整套应用服务器的整机成本。

更关键的是，费用本身并不是最让他们头疼的问题。真正促使团队重新评估方案的，是三个在选型对比表上永远不会出现的隐性成本。

第一，隐私合规风险。 合同、身份证、银行回单等敏感影像在上传至第三方服务器的那一刻，就已经脱离了企业自身的可控边界。法务部门在合规评审时直接亮出红灯——对于金融、医疗、法务类业务，这不是”愿不愿意”的问题，而是”能不能做”的问题。

第二，失败重试带来的”调用税”。 网络抖动、限流、接口超时是分布式系统的常态。为了保证业务成功率，调用方必须实现重试机制。结果是实际调用次数往往比业务单据数量高出 15%~25%，这部分额外费用完全无法预测，也无法通过优化业务逻辑来消除。

第三，耦合带来的改造税。 最初的实现通常非常直接——在业务 Controller 里直接发起 HTTP 请求，把 OCR 结果塞回业务对象。随着业务迭代，OCR 调用的重试策略、鉴权、限流、字段映射逐渐渗透进核心业务代码。等到有一天接口版本升级或计费方式变更，团队才发现这套逻辑已经无法从业务中剥离出来。

这三个成本在 PoC 阶段往往被忽略，但在生产环境中，它们才是 OCR 这类高频基础能力真正的成本大头。

后来，该团队将整条识别流水线迁移到了本地，使用开源 OCR 方案进行私有化部署，识别质量在印刷体场景下基本持平，综合成本下降超过 85%。这篇文章不复述”如何安装、如何跑 demo”——官方文档已经足够清楚。本文关注的，是更工程化的问题：什么情况下应该自建，什么情况下买商业 API 更划算；自建之后，从三行 demo 到生产可用还差哪些环节。

二、一张决策表：先给结论

在讨论技术细节之前，先给出一个可以直接使用的选型框架。

评估维度	商业 API 方案	本地自建方案
印刷体、版式规整（发票、截图、标准文档）	能力充足，但存在能力过剩	✅ 主战场，主流轻量模型已足够
手写体、复杂艺术字	✅ 大厂模型明显更强	弱项，不建议硬扛
复杂版面还原（表格结构、多栏排版）	✅ 通常配有版面分析能力	需要自行补齐版面分析模块
月调用量 < 1 万张	✅ 成本可忽略	部署与运维成本可能不划算
月调用量 > 5 万张	成本线性上涨，且数据出境	✅ 边际成本 ≈ 电费 + 折旧
数据敏感（合同/证件/病历）	合规风险高	✅ 数据不出内网，一票通过
纯内网 / 离线环境（工控、涉密）	直接排除	✅ 唯一可行选项
弹性突发需求（流量波动 10 倍以上）	✅ 按量付费天然弹性	需要提前规划容量

判断口径其实很简单：OCR 识别的”难度上限”由模型决定，但”成本曲线”由调用量决定。

印刷体文档识别在当下已经是高度成熟的商品化能力。主流轻量级中文 OCR 模型在发票、合同、身份证等规整版式上的准确率已经能满足绝大多数业务要求。这意味着在”质量差距”不再显著的场景下，选型的天平会迅速向”成本结构”和”数据边界”倾斜。

而这两者恰好是本地自建方案的核心优势：边际成本趋近于零，数据全程不出网。

三、成本结构拆解：三种成本，三种命运

要做出理性决策，需要把成本拆开来看。OCR 的总拥有成本大致可以切分为三块：

1. 显性调用成本

商业 API 按次计费，单价从几分到几毛不等。这部分成本最直观，也最容易被纳入选型表。问题在于它是线性增长的——业务量翻倍，账单就翻倍，没有任何规模效应。当月调用量突破 5 万张时，这笔费用通常会超过一台中等配置服务器的月折旧。

2. 隐性调用成本（失败重试税）

为了保证业务成功率，调用方必须实现重试逻辑。加上限流排队、超时重发、幂等去重等机制，实际调用次数往往比业务单据数量高出 20% 左右。这部分成本不可预测，也无法通过业务优化消除。本地部署则不存在这个问题——内网调用的成功率和延迟都由自己掌控。

3. 架构耦合成本

商业 API 的接口协议、鉴权方式、字段定义、版本演进节奏都由供应商决定。一旦发生变更，业务代码必须跟着改。如果最初没有做适配层隔离，改造代价会随时间指数级放大。本地部署虽然也需要维护接口，但版本完全自主可控，可以采用灰度方式逐步演进。

把这三种成本叠加起来，就能理解为什么”每张几分钱”的 API 在规模化之后会变得如此昂贵。

四、自建之后：从 Demo 到生产之间的鸿沟

很多团队在评估本地 OCR 时，会跑一个三行代码的 demo，看到识别结果不错，就认为”方案可行”。但 demo 和生产之间，至少还差以下几个环节。

4.1 模型选型与格式转换

本地部署的第一步是选择模型。中文印刷体场景下，主流方案通常基于检测 + 识别的两阶段结构：检测模型负责定位文字区域，识别模型负责内容转写。为了便于在不同推理引擎上运行，通常会将训练好的模型导出为通用中间格式（如 ONNX），再通过推理运行时加载。

选型时需要重点考察三个指标：

• 准确率：在自有业务样本上的实测表现，而非公开榜单分数；
• 推理速度：单张图片的端到端耗时，尤其是检测阶段的开销；
• 模型体积：影响内存占用和冷启动时间。

4.2 服务化封装

Demo 通常是一个 Python 脚本，生产环境则需要一个稳定的服务。封装时需要考虑：

• 接口设计：建议提供 HTTP 或 gRPC 接口，与业务解耦；
• 并发模型：OCR 推理是 CPU 密集型任务，需要合理设置工作进程数；
• 超时与重试：本地服务同样需要超时控制，避免单张坏图拖垮整个队列；
• 健康检查：提供存活探针和就绪探针，便于容器编排系统调度。

一个简化的服务化示意：

# 伪代码：OCR 服务封装的核心结构
class OcrService:
    def __init__(self, model_path, num_workers=4):
        self.engine = load_onnx_engine(model_path)
        self.pool = ProcessPoolExecutor(max_workers=num_workers)
    def recognize(self, image_bytes):
        # 1. 预处理：解码、缩放、方向校正
        image = preprocess(image_bytes)
        # 2. 检测：定位文字区域
        boxes = self.engine.detect(image)
        # 3. 识别：逐区域转写
        results = self.engine.recognize(image, boxes)
        # 4. 后处理：排序、合并、置信度过滤
        return postprocess(results)

4.3 后处理与业务字段映射

通用 OCR 输出的是”文本块 + 坐标 + 置信度”，而业务需要的是”发票号码、金额、开票日期”等结构化字段。这中间需要一层后处理逻辑：

• 基于坐标的版面还原（判断哪个文本属于哪个字段）；
• 正则匹配与关键字定位；
• 置信度阈值过滤与人工复核兜底。

这层逻辑的复杂度往往被低估，但它直接决定了 OCR 结果能否被业务直接消费。

4.4 监控与容量规划

本地部署意味着容量由自己负责。需要监控的指标包括：

• QPS 与队列深度：判断是否需要扩容；
• P99 延迟：识别慢请求，避免影响用户体验；
• 失败率与重试率：定位模型或预处理问题；
• 资源使用率：CPU、内存、磁盘 IO。

根据历史峰值规划容量，并预留 30% 以上的余量，是本地部署的基本纪律。

五、决策框架：什么时候自建，什么时候上云

将上面的分析整合成一个可操作的判断流程：

优先考虑自建的场景：

• 月调用量稳定超过 5 万张，且业务量可预测；
• 数据涉及合同、证件、病历等敏感信息，合规要求严格；
• 运行环境为内网或离线，不允许外网调用；
• 团队具备基本的容器化部署和运维能力；
• 识别对象以印刷体、规整版式为主。

优先考虑商业 API 的场景：

• 月调用量低于 1 万张，自建的运维成本高于调用费用；
• 识别对象包含大量手写体、艺术字或极度复杂的版面；
• 业务处于早期探索阶段，需要快速验证，且对数据敏感度低；
• 流量波动剧烈，需要极致的弹性伸缩能力；
• 团队没有 GPU/CPU 推理服务的运维经验。

混合方案的可行性：

对于业务形态复杂的团队，可以采用混合策略：核心敏感数据走本地自建，非敏感、低量、高难度的识别请求走商业 API。通过统一的上层接口屏蔽底层差异，既保证了合规底线，又保留了应对复杂场景的灵活性。

六、小结

OCR 的选型决策，本质上不是”哪个模型更强”的问题，而是”成本结构是否匹配业务形态”的问题。

当调用量足够大、数据足够敏感、版式足够规整时，本地自建方案在成本、隐私、可控性三个维度上都会形成压倒性优势。而当调用量小、难度高、流量波动大时，商业 API 依然是更理性的选择。

真正需要警惕的，是那些在选型表上不会出现的隐性成本：失败重试带来的额外调用、接口变更导致的架构耦合、数据出境引发的合规风险。把这些成本算清楚，答案往往会自己浮现出来。