英田 OCR Windows CPU 加速版压力测试报告：20 万张次长时运行，内存 2.2G 零增长

英田OCR压测报告

TECHNICAL REPORT

压力测试报告

英田 OCR Windows CPU 加速版

20 小时 / 20 万张次 / 内存 2.2G 零增长

在一台 4 核 4 线程 / 8GB 内存 的入门级云主机上，英田 OCR Windows CPU 加速版（商业版，PP-OCRv6 small）完成两轮长时压测。

先看核心数据

连续运行时长

7 小时 / 20 小时

两轮测试，中间未重启

识别总量

6 万张 / 20 万张

图量翻 3.3 倍

内存占用（两次测试完全一致）

2.2 GB

零增长，占 8GB 机器的 27.5%

CPU 利用率

75%

留有 25% 余量，无异常打满

一、三个核心结论

1. 无内存泄漏。图量翻 3.3 倍、时长翻近 3 倍，内存数字一个字节没动——从 2.2G 到 2.2G。

2. 长跑不衰减。平均单张耗时 420ms → 360ms，第二轮反而更快，无碎片化拖累。

3. 资源占用可控。2.2G 仅占 8GB 系统内存的 27.5%，CPU 稳定在 75%。

本次测试的目的不是测「能跑多快」，而是验证三件更基础的事：能不能一直跑、跑久了会不会崩、资源会不会越用越多。

二、为什么特意选一台低配机器

测试机配置：

操作系统：Windows Server 2022

内　存：8 GB

CPU：AMD EPYC 7K62，4 核 4 线程

模　型：PP-OCRv6 small

对　象：英田 OCR Windows CPU 加速版（商业版）

这套配置是刻意压低的，因为低配环境的结论具备向下兼容性：

▪ 4 核 4 线程：没有线程冗余，一旦线程池配置不当、出现忙等或自旋，会立刻在 CPU 曲线上暴露。

▪ 8 GB 内存：这是大量生产容器与入门级云主机的实际上限，最容易触发 OOM。

▪ EPYC 7K62：Zen 2 架构，支持 AVX2 但无 AVX-512，代表云上最常见的基础算力水位。

在一台 4C4T / 8G 的机器上跑得稳，换到更强的机器只会更好；反过来则不成立。因此本次数据可作为容量规划的下限参考。

三、样本：14,713 张，按失效模式分层

样本不是随机堆砌的，而是按 OCR 的典型失效模式分层设计，覆盖五类场景：

PaddleOCR 2024 比赛数据集
旋转、透视、低分辨率、多语言混排——检测鲁棒性

电影选票信息
热敏小字、低对比度、固定版式——小字识别

图书封面
装饰字体、复杂背景、竖排横排混排、任意角度

复杂表格
密集小字、框线、印章叠压——文本框数量极多

工业字符
金属刻印、噪声、光照不均——预处理能力

这五类覆盖了工业界 OCR 的绝大多数典型难点，既有清晰印刷体，也有低对比度、强噪声、任意角度的困难样本，能较为全面地驱动代码路径。

四、循环测试，其实更严格

▪ 第一轮：60,000 张 ≈ 遍历样本 4.1 轮

▪ 第二轮：200,000 张 ≈ 遍历 13.6 轮

循环的意义不在「凑够张数」，而在于放大泄漏信号。同一批代码路径被反复走十几遍，任何一次未释放的缓冲区都会线性累积，最终在内存曲线上现形。

量化一下探测灵敏度：

假设每张图泄漏 1 KB

第一轮累计 59 MB　→　第二轮累计 195 MB

相当于 2.2G 基准的 8.9%，曲线上不可能看不出来

内存纹丝不动，意味着单张泄漏被压制在数百字节量级。

五、结果分析

5.1　内存：2.2G 跨两个数量级不动

两轮测试图量相差 3.3 倍、时长相差近 3 倍，内存却完全一致地停在 2.2G。

这排除了最隐蔽的一种隐患——缓慢泄漏。有些泄漏速率极低，7 小时跑完看着像走平，实际在缓慢爬升，只有跑够 20 小时才现形。现在 20 万张压下去依然是 2.2G，说明这是真正的稳态封顶，而不是「还没漏出来」。

结合样本多样性看，结论更硬：样本覆盖了长尾场景（超大图、极端长宽比、模糊件），能一路平着走，说明异常分支的内存释放同样是干净的。原生推理库的泄漏恰恰最容易藏在「分配了缓冲区、异常提前返回、未执行释放」这类分支里。

5.2　CPU 75%：留白才是健康状态

▪ 说明存在 I/O 轮转：读图、解码、推理、写结果交替进行，是正常的服务形态。

▪ 说明线程池健康：没有忙等、没有自旋、没有线程饥饿。

▪ 若打满 100% 反而要警惕：那通常意味着某处死循环或锁竞争。

75% × 4 线程 ≈ 3 个线程在忙，约 25% 时间在等 I/O。这 25% 余量是可以变现的——低配机上它是吞吐挖潜空间，生产机上它是应对流量尖峰的缓冲。

5.3　吞吐：长跑不衰减

第一轮（6 万张 / 7h）

2.38 张/秒　·　420 ms/张

第二轮（20 万张 / 20h）

2.78 张/秒　·　360 ms/张

第二轮比第一轮快了约 14%，原因是页面缓存与运行时预热——第一轮包含了冷启动成本。

重点在于第二轮没有变慢。长时间运行后，如果内存管理存在缺陷，通常会出现碎片化或句柄累积，导致吞吐逐步下滑。此处反而更快，说明不存在累积性退化。

六、为什么压测数据值得被看重

OCR 组件一旦服务化，就是一个 7×24 常驻的进程。这时决定成败的往往不是峰值速度，而是几个跑分测不出来的问题：

▪ 连续运行三天后，内存还稳不稳？

▪ 遇到损坏文件、超大尺寸、极端长宽比的图，会不会崩？

▪ 线程池配置不当，会不会在高并发下互相拖死？

▪ 长尾样本触发的异常分支，资源有没有正确释放？

这些问题的共同特点是：无法通过单次跑分回答，只能通过长时压力测试回答。

建议在选型阶段就向候选方案索取、或直接自行验证三类数据：

长时内存曲线　→　连续 10 小时以上无增长

真实样本规模　→　万级以上、覆盖多场景

资源占用基线　→　内存占用明确、CPU 留有余量

本次测试中，英田 OCR Windows CPU 加速版在这三项上的表现分别为：20 小时内存 2.2G 无增长、14,713 张五类场景样本、内存占 8G 机器的 27.5%、CPU 稳定 75%。

需要说明的是，这些门槛并非高不可攀——它们是任何准备进入生产环境的 OCR 组件都应当完成的基础验证。区别在于，有些方案把这些数字公开出来供人核对，有些则只能等到上线后才知道答案。

前者的问题你已经知道边界在哪，后者的问题要等到线上才暴露。

七、部署建议

1. 线程数上限设为 4。在 4C4T 机器上开启超过 4 个推理线程只会增加上下文切换开销，不会更快。

2. 8GB 机器可考虑 2 实例并发，但需先验证。每个实例会独立加载一份模型权重，内存非线性叠加，2 实例可能不是 4.4G 而是 5G 以上。

3. 按样本类别分层统计准确率。若发现某一类偏弱，合适的做法不是整体升档拖慢所有图，而是对该类别单独采用更高档位或增加预处理。

4. 容量规划按冷启动值预留。360ms 是热态吞吐，冷启动会更慢，生产配额建议以第一轮的 420ms 为参考。

八、结语

压力测试的价值，不在于证明「它能跑多快」，而在于证明「在最差条件下它会不会崩」。

一台 4 核 8G 的入门云主机，用覆盖五类场景的 14,713 张样本反复循环，连续跑满 20 小时、20 万张次——内存定格在 2.2G，CPU 稳定在 75%，吞吐不降反升。

这三个数字放在一起，回答了 OCR 服务化之后最要命、也最无法靠跑分验证的那一环：长时间、真实数据、资源紧张的三重压力下，不泄漏、不崩溃、不退化。

测试环境：Windows Server 2022 / 8GB / AMD EPYC 7K62 4核4线程

测试对象：英田 OCR Windows CPU 加速版（商业版）· PP-OCRv6 small

测试样本：14,713 张，五类场景，整体多轮循环