企业官网建设流程全解析

TurboOCR 是一款极速的 GPU 文档解析引擎：基于 C++/CUDA + TensorRT FP16 + PP-OCRv6，单张显卡上最高可达559 张/秒，完整结构化解析（版面 + 表格 + 公式）约20 页/秒，并且完全本地运行、无需外部 API。它同时提供 HTTP 与 gRPC 双接口，一张图进来，文本、版面、表格（HTML）、公式（LaTeX）和 Markdown 全都能出。

一、TurboOCR 是什么：一张 GPU 上的完整文档解析流水线 🧠

TurboOCR 不只是传统意义上的 OCR。它的定位是"文档解析器"，一次请求可以同时拿到：

技术上它是一次"工程极限"的实践：C++20 编写核心流水线，CUDA 多流并行调度，TensorRT FP16 推理引擎，内置 Wuffs（PNG 解码）与 PDFium（PDF 渲染），甚至公式识别都是纯 C++ 进程内运行，整条链路没有任何 Python 环节。

二、200+张/秒是怎么炼成的：架构全景拆解 ⚙️

1. 五条命名 CUDA 流：让各阶段互不排队

普通 OCR 框架里，检测、识别、版面等阶段往往串行执行，GPU 大量时间在"等"。TurboOCR 为每类任务分配独立的 CUDA 流（如rec_stream_、layout_stream_、table_stream_、formula_stream_），用事件（event）做异步接力，多个页面、多个阶段在 GPU 上"同时"推进。完整的流与事件图见 docs/architecture/cuda-streams.md。

2. TensorRT FP16：为 GPU 架构量身定制的引擎

为什么不用更通用的 ONNX Runtime？因为极限吞吐需要吃满新架构 GPU（如 RTX 50 系）的 Tensor Core。TensorRT 10.15+ 在构建引擎时会自动选择对应架构的最优 kernel；识别引擎还预置了 5 个宽度桶（320/480/800/1600/4000）并做启动预热，避免请求时触发 JIT 卡顿。设计动机详见 docs/architecture/overview.md。

3. 惰性加载 + CPU 路由：不用的阶段零开销

这是"全景概览"里最值得学习的一点：

• 版面、表格、公式都是按需加载的，启动时用环境变量开关；
• 纯文本页面走"热路径"时，路由器（纯 CPU 逻辑）会提前短路返回，GPU 指令序列与不开启任何高级功能时位级一致；
• 只有版面模型真的检出了table/formula区域，表格/公式引擎才会被唤起。

效果就是：默认配置下它是极速 OCR 引擎，加几个参数它就升级为完整版面/表格/公式解析器，且升级不拖累纯文本速度。流水线节点级拆解见 docs/architecture/pipeline.md，核心实现位于 src/pipeline/ocr/ocr_pipeline_run.cpp。

三、实测性能：比其他 OCR 引擎快 15–90 倍 🚀

在单张 RTX 5090 上，TurboOCR 与主流引擎同台竞技（同为整页 OCR 任务，英文表单 FUNSD / 小票 CORD 数据集）：

关键数字（完整测试方法见 docs/benchmarks/comparison.md）：

• 小票场景：tiny 档最高559 张/秒，medium 档仍达 193 张/秒；
• 表单场景：520 张/秒（tiny），词级 F1 达 91.9%（medium），全面领先；
• 对比对象：PaddleOCR-VL 约 1 页/秒、PaddleOCR-Python 约 6 张/秒、EasyOCR 约 3 张/秒——TurboOCR 快15–90 倍；
• 完整文档解析（OmniDocBench 125 篇子集）：Overall 得分0.90，速度20 页/秒，与 VLM 方案（0.95，约 1 页/秒）仅差约 5 分，详见 docs/benchmarks/omnidocbench.md。

四、不止 OCR：版面、表格、公式一次搞定 📄

版面分析与阅读顺序

PP-DocLayoutV3 将页面切分为 25 类区域（标题、正文段落、图、表、页眉页脚等），再通过类别感知的 XY-cut 算法还原正确的阅读顺序，多栏版面也不会串行。下面的版面检测示例中，页面被精确标注为header、text、paragraph_title、chart、footer等区域：

表格 → HTML，公式 → LaTeX

• 表格走 SLANet-Plus（TensorRT FP16 编码器 + 手写 C++ 解码器），输出标准 HTML 表格与单元格坐标；
• 公式走 PP-FormulaNet-S，进程内纯 C++ 解码为 LaTeX，无需 Python 运行时。

这两者都严格按请求开启（?tables=1/?formulas=1），未开启时零开销；/ocr/markdown与/ocr/pdf?markdown=1可直接产出忠实的 Markdown 文档。

五、速度与精度的权衡：3 个开关自由切换 🎛️

默认配置为吞吐量优先，但有 3 个"精度杠杆"可以按需求换回精度：

各档位组合的实测吞吐量代价（含表格+公式的完整解析）如下图所示，可以直接照着选配置：

此外，版面框的合并策略（LAYOUT_MERGE_MODE的 all/outer/inner 三种模式）也可调节区域粒度的疏密：

模型选型详解见 docs/models/selection.md。

六、3 分钟快速上手：一行 Docker 启动 ✅

环境要求：Linux + NVIDIA GPU（Turing 及以上），纯文本约 4 GB 显存，完整流水线约 8 GB。

docker run --gpus all -p 8000:8000 -p 50051:50051 \ -v trt-cache:/home/ocr/.cache/turbo-ocr \ ghcr.io/aiptimizer/turboocr:latest

首次启动会自动从 ONNX 构建 TensorRT 引擎（5090 上约 90 秒），引擎缓存进命名卷后启动秒开。然后一条 curl 即可拿到结果：

curl -X POST "http://localhost:8000/ocr/raw?layout=1" \ --data-binary @document.png -H "Content-Type: image/png"

常用运维端点：

• GET /capabilities—— 查看服务器当前加载了哪些阶段；
• GET /metrics—— Prometheus 指标，便于监控部署；
• gRPC 服务监听 50051 端口，接口定义见 proto/ocr.proto，核心 RPC 实现位于 src/grpc/recognize_rpc.cpp。

HTTP 端点与全部参数（layout、tables、formulas、words等）详见 docs/api/http.md，监控部署参考 docs/api/monitoring.md。Docker 镜像定义在 docker/Dockerfile.gpu，源码构建入口为 CMakeLists.txt。

七、它适合谁？🎯

• 海量票据/表单数字化：500+ 张/秒的吞吐意味着一晚上处理百万级单据；
• PDF 批量转 Markdown：科研论文、书籍、合同的结构化入库；
• 本地私有化部署：无外部 API 依赖、数据不出内网，且 MIT 协议可商用；
• 边缘/低成本 GPU 服务：tiny 档小显存即可运行，需要更高精度时平滑切到 medium。

一句话总结：TurboOCR 把"文档解析"做成了一个可以单卡跑满的极速 GPU 服务——精度接近 VLM，速度快 20 倍，而且每一层设计（多流 CUDA、TensorRT FP16、惰性加载路由）都指向同一个目标：让每一张图尽快、尽可能准地被解析完。