原理概述
TPS（Transaction Per Second）是衡量系统处理能力的核心指标，定义为每秒钟系统能够处理的交易或事务数量。在文档识别（OCR）、数据库操作、在线交易等场景中，TPS直接反映了系统在高并发下的响应效率与资源利用率。本文以OCR领域为例，探讨TPS的底层运行机制、长序列处理中的优化策略，以及如何通过技术手段突破性能瓶颈。
背景问题：长序列处理的性能挑战
在OCR任务中，长文档（如合同、论文、书籍）的识别需处理数千至数万字符的序列。传统模型在长序列输出时面临两大挑战：
- 推理开销激增：注意力机制的计算复杂度随序列长度平方增长，导致单次推理耗时显著增加；
- 资源竞争加剧：长序列占用更多显存与计算资源，限制并发处理能力，直接拉低TPS。
例如，某开源模型在处理10页文档时，TPS可能从短文档的50骤降至5，无法满足实时性要求。
核心概念：TPS的构成要素
理解TPS需掌握以下基础概念：
- 事务（Transaction）：系统完成一次完整操作的最小单元，如OCR中识别一页文档、数据库中执行一条SQL；
- 并发度（Concurrency）：系统同时处理的事务数量，与硬件资源（CPU/GPU核心数、显存）强相关；
- 延迟（Latency）：单个事务从发起至完成的耗时，延迟越低，单位时间内可处理的事务越多。
TPS的计算公式为：
[
TPS = \frac{\text{并发事务数} \times \text{每事务处理速度}}{\text{单位时间}}
]
其中，处理速度受模型架构、硬件性能、数据分布共同影响。
系统组成：TPS优化的关键模块
以OCR系统为例，提升TPS需优化以下模块：
- 输入层：负责文档分页、图像预处理（去噪、二值化），将原始数据转换为模型可处理的张量；
- 模型层：包含特征提取（CNN）、序列建模（RNN/Transformer）、解码（CTC/Attention）等子模块，需通过架构优化降低计算复杂度；
- 推理引擎：管理模型加载、内存分配、批处理（Batching）策略，直接决定硬件利用率；
- 输出层：合并分页结果、后处理（纠错、格式化），最终返回结构化文本。
工作流程：从输入到输出的完整链路
以长文档OCR为例，TPS优化的工作流程如下：
- 动态分页：将长文档按显存容量分割为固定长度的片段（如每页512字符），避免单次推理超限；
- 并行批处理：将多个片段组成批次（Batch），通过矩阵运算并行处理，提升GPU利用率；
- 注意力机制优化：采用稀疏注意力（如局部窗口、全局向量）替代全注意力，将计算复杂度从 (O(n^2)) 降至 (O(n))；
- 异步流水线：将模型拆分为特征提取、序列建模、解码三阶段，各阶段重叠执行，隐藏I/O延迟。
例如，某模型通过流水线优化后，单卡TPS从15提升至40，延迟降低60%。
关键机制：性能优化的核心技术
1. 批处理（Batching）
批处理通过合并多个请求共享计算资源，减少内存访问次数与CUDA内核启动开销。
- 静态批处理：固定批次大小，适合同构请求（如相同长度的文档）；
- 动态批处理：动态填充短请求至最大长度，平衡负载与延迟，常见于异构场景。
伪代码示例： def dynamic_batching(requests, max_batch_size, max_delay_ms): batch = [] start_time = current_time() for req in requests: batch.append(req) if len(batch) == max_batch_size or (current_time() - start_time) > max_delay_ms: process_batch(batch) # 并行处理 batch = [] start_time = current_time()
2. 注意力机制优化
长序列场景下，传统Transformer的注意力计算成为瓶颈。常见优化方案包括：
- 局部注意力：仅计算相邻token的注意力，如每512个token为一个窗口；
- 线性注意力：通过核方法近似注意力矩阵，将复杂度降至 (O(n))；
- 记忆压缩：用低维向量总结历史信息，减少K/V缓存大小。
例如，某模型采用局部注意力后，推理速度提升3倍，显存占用降低75%。
3. 异步推理与流水线
异步推理将模型拆分为多个阶段，通过重叠执行隐藏延迟。例如：
- 阶段1：特征提取（GPU）；
- 阶段2：序列建模（GPU）；
- 阶段3：解码（CPU）。
当阶段1处理第N个请求时，阶段2可同时处理第N-1个请求，阶段3处理第N-2个请求，实现资源最大化利用。
示例说明：OCR模型的长序列优化
以某开源OCR模型为例，其原始架构在长文档处理中TPS较低，优化步骤如下：
- 问题诊断：通过Profiler发现注意力计算占推理时间的60%，显存占用随序列长度指数增长；
- 方案选择：采用局部注意力（窗口大小=256）与动态批处理（批次大小=8）；
- 效果验证：在10页文档测试中，TPS从5提升至22，延迟从2.1s降至0.8s。
优化前后的资源占用对比：
| 指标 | 原始方案 | 优化方案 | 提升幅度 |
|———————|—————|—————|—————|
| 单请求显存 | 4.2GB | 1.8GB | -57% |
| 批处理TPS | 5 | 22 | +340% |
| 平均延迟 | 2.1s | 0.8s | -62% |
技术优势与限制
优势
- 量化评估：TPS提供可对比的性能基准，便于横向评估不同系统或算法；
- 资源导向：通过TPS与延迟的权衡，指导硬件选型（如GPU型号、集群规模）；
- 可扩展性：结合批处理与流水线，可线性扩展至多卡/多机场景。
限制
- 序列长度敏感：超长序列（如>10K字符）仍需分片处理，可能引入上下文丢失；
- 硬件依赖：TPS受GPU显存、CPU核心数限制，优化需匹配硬件规格；
- 动态负载：请求长度波动时，动态批处理可能引入额外延迟。
常见误区
- TPS越高越好：忽略延迟与资源成本，盲目追求高TPS可能导致系统过载；
- 仅优化模型：忽视输入分页、输出合并等周边逻辑，整体性能提升有限；
- 静态批处理万能：在请求长度差异大的场景中，静态批处理可能降低吞吐量。
总结
TPS作为系统性能的核心指标，其优化需从架构设计、算法选择、资源调度多维度协同。在长序列处理场景中，通过批处理、注意力机制优化、异步流水线等技术，可显著提升TPS并降低延迟。实际应用中，需结合硬件规格、数据分布动态调整策略，避免陷入“唯TPS论”的误区，最终实现效率与成本的平衡。