导读｜腾讯云OCR团队在产品性能的长期优化实践中，结合客户运用场景及产品架构对服务耗时问题进行了深入剖析和优化。本文作者——腾讯研制工程师彭碧发具体介绍了OCR团队在耗时优化中的思路和办法(如工程优化、模型优化、TIACC加快等)，通过引进TSA算法运用TI-ACC削减模型的辨认耗时，结合客户运用场景优化编解码逻辑、对关键节点的日志分流以及与客户所在地就近布置继续下降传输耗时，克服OCR耗时优化面对的环节多、时间短乃至本钱有限的问题，终究完结了OCR产品均匀耗时从1815ms下降到824ms。希望咱们在阅读中能收成一些新的思路。

布景介绍

腾讯云OCR(文字辨认)团队收到客户反馈称，腾讯云OCR在服务可用性和准确率方面都表现出色，但服务耗时还有可观的进步空间。因而，我所在的团队决定优化腾讯云OCR服务耗时，为用户供给更快的文字辨认服务。

可是耗时优化是一个系统性工程，需求多方的支撑和协作。文字辨认服务进行耗时优化，首要有以下应战：

• 环节多：耗时优化触及多个环节，包括模型算法、TI-ACC、工程等。各环节都需求剖析各自阶段耗时，制定完整的耗时优化方针。

• 时间短：客户耗时优化诉求强烈，可是给到的优化的时间很短。

• 本钱考量：降本增效大布景下，单纯依靠机器的状况一去不复返。耗时优化计划也需求考虑本钱优化。

咱们成立了专项团队进行攻坚。事务团队从工程优化、模型优化、TI-ACC优化等方面发力，逐渐下降服务耗时。优化前均匀耗时1815ms，优化后均匀耗时824ms，耗时性能进步2.2倍，并终究得到重要客户的肯定。接下来将介绍咱们在耗时优化方面的具体实践，希望能给遭受类似问题的你带来创意。

剖析问题

1）结构和链路剖析

OCR服务通过云API接入，内部多个微服务间通过TRPC进行调用。根本架构图如下：

从客户建议恳求到OCR服务处理完结首要链路为：

• 云API层：恳求首先会传输到离客户最近的云API接入点，云API接入点会进行相应的鉴权、寻址、转发等操作。

• 事务逻辑层：文字辨认逻辑层服务会对数据做处理、下载、计费、上报等操作。

• 引擎层：算法引擎服务对图片进行处理，辨认出文字。

2）首要阶段耗时

首要触及到下面几个阶段的耗时：

• 客户传输耗时：客户恳求到云API和云API呼应到客户链路的传输耗时在测验进程中发现动摇很大。文字辨认事务场景下恳求传输的都是图片数据，这受客户网络带宽和质量的影响大。此外，因客户恳求的文字辨认服务在广州，所以恳求需求跨地域。这进一步增加了传输耗时。

• 事务逻辑耗时：事务逻辑中有许多杂乱的工程处理，首要耗时点包括数据处理、编解码、图片下载、路由、上报等。

• 算法引擎耗时：想达到更好的辨认作用和泛化性，通用OCR模型会比较杂乱。检测和辨认都会触及到杂乱的浮点核算，耗时长。

因而，要优化文字辨认服务的全体耗时，就需求从各个阶段进行具体剖析和优化。

3）测验办法和结论

因为客户生产环境的机器在云服务器上，所以为了保持和客户测验条件一致，咱们购买了和客户相同环境的云服务器(含北京、上海、广州)进行模拟测验，具体剖析文字辨认服务各个阶段耗时。

端到端耗时为客户恳求建议直到收到呼应的总耗时、客户到腾讯云API接入点以及云API呼应给客户存在着公网传输的耗时、从云API接入后就是腾讯云内网链路服务的耗时。端到端耗时首要由客户传输耗时、云API耗时、事务逻辑层耗时、引擎耗时组成，通过屡次恳求通用OCR后核算各个阶段的均匀耗时，具体状况为：

• 客户的传输耗时占比很大。首要是因为客户在北京建议恳求，需求跨地域到广州的服务，存在很大的传输耗时，这部分需求咱们通过优化布置来减低耗时。

• 在服务链路中，事务逻辑处理的耗时也较多。这部分耗时需求咱们精益求精，优化工程逻辑和架构，然后下降耗时。

• 文字辨认服务的引擎耗时占比最高。所以咱们需求对算法引擎的耗时进行重点优化。

通过具体的各阶段耗时测验能够发现：引擎耗时占首要部分。所以咱们会重点优化引擎耗时，这儿的首要手法是模型优化和TI-ACC加快。为了做到极致优化，咱们还通过日志分流和编解码优化下降了事务逻辑层耗时，同时服务就近多地布置，优化了客户传输耗时。

解决问题

1 ）模型优化—引进TSA算法削减模型耗时

优化之前耗时长度会跟着文字字数增加显着变大。引进TSA算法能够显着改进这种状况，然后削减模型耗时。

• OCR特色与算法进程剖析

依据OCR的特色与难点，OCR问题学术界算法能够划分成两大类：依据CTC (Connectionist Temporal Classification)的流式文本辨认计划；依据Attention的机器翻译的结构计划。

在依据深度学习的OCR辨认算法中，整个流程能够归纳成了四个进程如下图: 几何改换；特征提取；序列建模；对齐与输出。CTC计划与Attention计划区别首要是在最后一个进程。它作为衔接视觉特征与语义特征的关键桥梁，能够依据上下文图画特征和语义特征做准确输入、输出的对齐，是OCR模型关键的进程。

针对上述特色与耗时问题，咱们提出了TSA文本辨认模型。

• TSA研制布景

研讨表明，图画对 CNN 的依靠对错必需的。当直接应用于图画块序列时，transformer 也能很好地履行图画分类使命。63%耗时在(BiLSTM+Global Attn，或attention方式)序列建模。

• 辨认模型特色

特色1：引进self-attention算法对输入图画进行像素级别建模，并代替RNN完结序列建模。比较CNN与RNN，self-attention不受感触野和信息传递的限制，能够更好地处理长距离信息。

特色2：规划self-attention核算进程中的掩码mask。self-attention天然能够“无视”距离带来的影响，因而需求对输入像素间自注意力进行约束 。其进程如下图所示。

总结：通过multi-head self-attention对序列建模，能够将两个任意时间片的建模杂乱度由lstm的O (N)下降到 O(1)，猜测速度大幅进步。优化后的算法和文本长度无关，对大文本得到成倍的加快进步。

2 ）TIACC加快优化—继续削减模型耗时

为了进一步下降模型的耗时，咱们运用了 TI-ACC进行加快，TI-ACC支撑多种结构和杂乱场景，面向算法和事务工程师供给一键式推理加快功用。

• 支撑杂乱结构模型

OCR使命能够分为两大类：检测使命和辨认使命。检测使命和辨认使命一般会保存成两个独立的TorchScript模型，每个使命又分为了多个阶段。通用OCR检测使命包括了backbone(RepVGG等)、neck(FPN等）、head（Hourglass等）等部分。

辨认使命包括特征提取部分和序列建模部分。其间特征提取部分既有传统CNN网络，也有最新ResT等依据Transformer的网络。序列建模部分既有传统RNN网络，也有依据Attention的网络。

加快OCR事务模型是对推理加快引擎兼容性的检测。下表分别对比了TIACC和Torch-TensorRT（22.08-py3-patch-v1）对本文模型加快能力：

• 下降恳求推迟并进步系统吞吐

OCR事务不只模型结构杂乱，模型输入也很有特色。下图显示了本文其间一个模型的输入：

上述输入包括以下特色：输入类型多；输入shape改变规模大；有些最小shape维度是0；输入不只包括Tensor也包括Tuple。仅仅上述模型输入格局，就会导致一些推理引擎不可用或加快作用不显着。举个比如，TensorRT不支撑int64输入、Torch-TensorRT不支撑Tuple输入。输入改变规模大会导致推理引擎显存消耗过高，导致某些推理引擎加快失败或无法单卡多路并行推理，然后导致无法有用进步TPS。关于OCR这种大调用量事务，TPS进步能够有用下降GPU卡规模然后带来可观本钱下降。

针对OCR模型shape规模过大显存占用量高问题，TIACC能通过显存同享机制有用下降了显存占用。关于动态shape模型，推理加快引擎在部分shape加快显着，部分shape反而会性能下降的问题。TIACC通过重写关键算子、依据模型结构，挑选事务全流程最优的算子完结，有用解决了实际事务中部分shape加快显着但全体加快不理想的问题。

通过打磨OCR事务模型，能进步模型的推理推迟。即使多路布置也能够有用进步模型的吞吐。下表显示了TIACC FP16比较libtorch FP16的加快倍数，数字越高越好。

TIACC底层运用了TNN作为基础结构，性能强大。其间TNN是优图试验室结合自身在AI场景多年的落地经历，也是向行业开源的布置结构。TIACC依据TNN最新研制的子图切分功用基础上做产品化封装，为企业供给 AI 模型训练、推理加快服务。它显着进步模型训练推理功率，下降本钱。

3）工程优化——优化逻辑和传输耗时

• 编解码优化

文字辨认采用微服务架构规划，全体服务链路长。其间触及到TRPC、HTTP、Nginx-PB协议的转化和调用，所以恳求和呼应需求有许多的编解码操作。文字辨认场景下，恳求和呼应包体都非常大，RPC协议之间的转化和编解码增加了核算耗时。为了进一步下降服务耗时，咱们对这些编解码操作进行了全体的优化，削减了协议转化和编解码次数。

• 日志分流处理

在事务中有许多关键节点需求记录日志，便于问题定位。在文字辨认事务场景下，日志需求脱敏处理大量辨认出的文本数据，写入速度慢。为了防止日志操作影响服务呼应耗时，咱们规划了日志分流上报服务，将日志操作全部通过异步流程上签到其他微服务完结，削减主逻辑耗时。

• 就近布置—下降传输耗时

通过屡次具体测验文字辨认事务在北京、上海、广州区域机器建议恳求的耗时差异，咱们对跨地域传输耗时有了比较明确的认识。服务跨地域恳求时（比如在北京建议恳求，实际服务布置在广州），会存在很大的传输耗时动摇，客户的运用体会会下降。因而咱们针对通用OCR接口进行了就近多地布置，在服务布置的架构上对耗时进行了优化。

在文字辨认跨地域恳求时，咱们进行多地布置。通用OCR接口线上多地布置发布今后，咱们对线上云API记录的总耗时监控进行了观察和对比，耗时有了很显着的下降——某段时间内耗时从均匀1100ms下降到800ms，下降了300ms。

• GPU显存优化-进步系统吞吐

跟着OCR事务功用点越来越多，事务中运用的AI模型越来越多且更杂乱，所以对显存的要求也越来越大。显卡显存巨细影响服务能开启并发数，而并发数影响服务的吞吐——所以显存往往成为事务吞吐量的瓶颈。

显存办理首要就是解决上述问题。其首要思想是解耦合显存占用巨细跟服务并发路数之间的关系，进步并发路数不再导致显存增大，然后进步服务全体吞吐量；由服务路数完结并行方式转化为不同模型之间并行方式，进步了GPU核算的并行度，更好的充分利用GPU资源。以通用OCR为例，下图能够看运用前后GPU利用率改变和显存占用改变。

终究作用

1）通用OCR均匀耗时优化54.6%

通用OCR三地的均匀耗时从优化前1815ms调整到优化后824ms，优化份额54.6%。

2、图片文字越多，耗时优化越显着

跟着图片中的字数的增多，耗时优化作用更显着。其耗时优化份额从23%到69%。在耗时优化之前，服务耗时和图片文字正相关，相关性强；优化后，相关性下降。

3、召回率进步1.1%

作用：优化后的版别精度有所进步。召回率进步1.1%，准确率进步2.3%。

本钱下降

TI-ACC、工程优化等手法，不只满意了客户的耗时要求，还也进步了每个接口的tps——均匀tps进步51.4%。由于tps的进步，每月能够节约等份额的机器本钱。

结语

通用全链路优化，全体耗时下降54.6%，GPU利用率也从均匀35%优化到85%。

本次优化取得了阶段性的效果，但值得注意的是，耗时优化是一个继续不断的进程。咱们的项目会继续盯梢通用OCR pipleline等环节进行继续优化。希望这篇经历分享文章能给遭受类似问题的你带来创意！

注：本文所述数据均为试验测验数据。

腾讯工程师技能干货直达：

1、算法工程师深度解构ChatGPT技能

2、10分钟！从架构视角读懂K8s

3、探秘微信事务优化：DDD从入门到实践

4、祖传代码重构：从25万行到5万行的血泪史

‍‍

阅读原文