先看性能跑分，机器是我自己的主力开发机 Ryzen 7 5800X（16 逻辑核，AVX2），Windows 11，PP-OCRv6，4 个行级 worker，仓库里会生成 100 张合成图，去掉第一张预热，统计 99 张，长这个样子：
耗时是每张图的平均毫秒。C 引擎换成了较新的 lw.PPOCR.C 20d0de6，不是8月底那份旧 DLL。OpenVINO.NET 是我此前的开源项目 OpenVINO.NET 0.8.1 + runtime 2026.2.0。
| 模型 | 引擎 | 平均耗时 | 相对本库 | 对上的行 | CER错误率 | 内存占用 |
|---|---|---|---|---|---|---|
| tiny | 本库 1.3 | 87.8 | 1.00 | 734/1026 | 2.71% | 803 MB |
| tiny | OpenVINO.NET | 132 | 1.51 | 644/1026 | 3.55% | 2785 MB |
| tiny | lw.PPOCR.C | 186 | 2.12 | 744/1026 | 4.01% | 539 MB |
| medium | 本库 1.3 | 641 | 1.00 | 992/1026 | 0.68% | 2430 MB |
| medium | OpenVINO.NET | 1077 | 1.68 | 810/1026 | 1.74% | 4516 MB |
| medium | lw.PPOCR.C | 2193 | 3.42 | 1004/1026 | 0.24% | 1481 MB |
tiny 上最新 C 大约慢 2.1 倍，medium 上是 3.4 倍。OpenVINO.NET 同机也慢一截，内存还胖一圈：tiny 都快 2.8 GB 了，medium 直接 4.5 GB。
对还不熟的朋友先补一句：SimdPaddleOCR 是纯 C# 的 PP-OCRv6 推理库。不绑 Paddle Inference，不绑 ONNX Runtime，也不依赖于 OpenCV 原生库，靠的是 C# 自己的 SIMD。周一发过介绍：SimdPaddleOCR发布——一个纯 C# 的完整 OCR 推理库。
1.1 在 win-x64 上已经不错了。1.2 又把 ARM64 端到端抠了大约 40%，别的平台没被拖下水：ARM64端到端再提速40%：SimdPaddleOCR 1.2 发布！。写完 1.2 的时候我心里是有数的——再往上凹，大概就是 C# 的天花板了。比 OpenVINO.NET 慢一点，听着也正常。纯托管，怎么可能还更快？
最近有位客户用的是 medium。他那边一测，发现 SimdPaddleOCR 比我自己以前那个 OpenVINO.NET 慢一截。tiny 上大家看 CI 还行，medium 一上量，差距就藏不住了。
我拿标签 1.2.0 在同一台 5800X 上复测：medium 4 worker，本库 1507 ms，OpenVINO.NET 大约 1 秒出头。客户说得没错。于是又得上大模型忙起来了。
改的是 AVX2 上那几段连续卷积：以前按 NCHW 一张张转通道，热路径上转来转去；1.3 对能连着走的卷积段改成图级 NHWC，通道不用来回倒。netstandard2.0、ARM、以及环境变量 PPOCR_NHWC=0 还是老的 NCHW，没强行一刀切。正确率没动，medium 还是 CER 0.68%、992/1026。
同机 medium 4w：1507 ms 掉到 641 ms，吞吐 2.35 倍，也就是标题那句 暴涨 135%。OpenVINO.NET 还在 1077 ms。这就是「吊打」的那一档——速度赢了，内存也瘦一截。
本机是 16 核桌面机。云上的 GitHub-hosted runner 是 4 核，只能看 tiny，但同一颗 CPU 对比仍然成立（34818949921 vs 1.2 的 34303303418）：
| 场景 | 1.2 | 1.3 | 相对耗时 |
|---|---|---|---|
| win-x64 EPYC 7763 AVX2，tiny 4w | 232 ms | 160 ms | 0.69 |
| win-x64 ns2（没有 NHWC） | 361 ms | 343 ms | 0.95 |
| linux-arm64 N2，tiny 4w（没有 NHWC） | 273 ms | 241 ms | 0.88 |
| 同 replica OpenVINO / 本库 | 0.96 | 1.38 | 本库反超 |
tiny 在 7763 上大约快 31%。没吃到 NHWC 的 ns2 和 ARM，几乎就在原地。1.2 的时候同 replica 上 OpenVINO.NET 还略快（0.96）；1.3 翻成 1.38。small 的完整表、ISA 阶梯和怎么读这些数，在仓库的 docs/perf.md。
不过有一点也需要指明：medium 上最新 C 更准（CER错误率 0.24% vs 0.68%），内存也更省。
大家可以直接拿同一套图、同一个 harness 来比，--engine sharp|c|openvino 都在测试项目里。
慢在哪，我的助手 AI 早就一眼就能看出来了。medium 的账主要记在卷积上，尤其是检测和识别里铺天盖地的 1×1 卷积。1.2 的内核已经是 AVX2 手写了，单算子已经非常强了，但张量在层与层之间一直是 NCHW：通道在最外，空间在里面。AVX 一次吃 8 个相邻 float，最想看到的是同一像素旁边的通道排在一起。于是每个 Conv1x1 进门先把 NCHW 转成 NHWC，算完再转回去。tiny 还能忍；medium 通道多、特征图大，这来回两趟就把内存带宽吃满了。OpenVINO 那边图是 blocked 布局一路走下去，就没有这道税。
人话讲：不是乘法不够快，是数还没乘，先搬了一遍家。
思路不新鲜。我日常用的 AI 秘书很早就嘀咕过「别每层都转，让连续卷积段在图上直接走 NHWC」。但说起来容易，真让它落地，它却搞不定——Pooling、残差、激活、哪些边能连、哪些边必须转回 NCHW，一碰图就散。
后来请 gpt-6-astra（体感有点降智）连着改了好几轮，算子融了一点，分块也动了，medium 从 1507 ms 凹到 ~1200 出头，对照 OpenVINO.NET 还是慢一截。账还在「每层进门搬家」上。
最后把 Claude Fable 5.1 请出山，一次性花了 48 美元，终于把图级 NHWC 真正铺进去——不仅把事情做好了，甚至比预想的还要好：能连着走的卷积段，中间结果不再倒回 NCHW；段首转一次，段尾再转回来。AVX2+FMA 才走这条路；netstandard2.0、ARM、以及 PPOCR_NHWC=0 仍是老布局，没为了数字把别的平台砸了。正确率没动。
这一下 medium 才从「慢于 OpenVINO.NET」变成上面那张表。CI 里没吃到 NHWC 的 ns2 / ARM 几乎不动，也从侧面说明：快的就是这趟搬家钱。
有兴趣可以对着源码和记录看：SimdPaddleOCR 性能优化记录。
写到这里有点高处不胜寒。纯 C#，没挂原生推理库，medium 还能把 OpenVINO.NET 和今天的 C 甩在后面——我自己做 OpenVINO.NET 那些年，从没想过有一天我能写出这种标题。
1.3.0 已经在 GitHub 发了 Release，NuGet 大家可以搜 Sdcb.SimdPaddleOCR。
如果你还在用 1.2 的，可以直接升核心包就行。协议还是 Apache-2.0：纯C#，免费使用，内网和离线环境跑都没问题。
开源仓库： https://github.com/sdcb/SimdPaddleOCR 喜欢的朋友欢迎点个 Star~
欢迎关注微信公众号 .NET骚操作，或者加入 SimdPaddleOCR 微信交流群：
(如果微信群二维码过期，请加入 C# / .NET 计算机视觉交流 QQ 群：579060605)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。