最近，lw.PPOCR.C 发布了新的预览版本 v0.1.0-preview.5。
这是一个专门面向 PP-OCRv6 Tiny 的轻量级纯 C 推理运行时，目标一直很明确：尽可能减少部署依赖，让 OCR 可以更方便地运行在 Windows、Linux、ARM64、浏览器以及 Node.js 等不同环境中。
项目地址：
这次 preview.5 不只是一次常规更新，而是把项目在 跨平台、Web、Node.js 和国产架构支持几个方向上又往前推进了一步。
这次更新了什么？
1. 正式增加 Node.js / WASM 发行包
之前，浏览器版本已经可以把 WASM Runtime、OCR 模型、字典等资源全部打包进一个 HTML 文件，实现真正的：
下载一个 HTML，打开即可离线 OCR。
不过，如果 Node.js 项目想复用这套 WASM Runtime，就需要自己从 HTML 中解析并提取相关资源。
preview.5 正式增加了：
python
lw.PPOCR.C-0.1.0-node-wasm.zip其中直接包含：
runtime.cjs
det.lwm
cls.lwm
rec.lwm
ppocr_keys.txt以及 manifest、SHA256 校验和授权说明等文件。
这意味着以后 Node.js 项目可以直接加载官方 Runtime，不再需要"拆 HTML"。
同时，这个 Node/WASM 包仍然保持了项目一贯的轻量定位：
不依赖 Python、不依赖 OpenCV、不依赖 ONNX Runtime，也没有额外的 npm Runtime 依赖。
图片解码、HTTP 服务、PDF 处理、Worker Pool 等功能仍然交给上层应用自由选择。
2. 单文件 HTML 现在可以直接做 PDF OCR
这一版的离线 HTML Demo 也继续增强。
现在不仅可以识别普通图片，还可以直接打开本地 PDF：
javascript
PDF
↓
页面渲染
↓
OCR
↓
文字结果
↓
TXT / JSON 导出支持识别当前页，也支持按顺序识别整个 PDF。
同时针对手机浏览器和部分 WebView 环境，对 PDF Worker、Blob、FileReader 等兼容问题做了进一步处理。
所以现在这个单 HTML 已经不只是一个"技术演示页"，而开始具备一个轻量离线 OCR 工具的基本形态。
不用安装软件，也不用上传文件到服务器。
3. Native OCR 进一步优化，多线程调度更合理
Native 版本这一轮增加了一个比较重要的优化：
DET 检测阶段和 CLS/REC 识别阶段，不再共用同一个线程数量配置。
现在运行时会根据：
逻辑处理器数量
物理核心数量
进程 CPU Affinity
Linux cgroup CPU quota自动给 DET 分配合适的 CPU 预算。
而文字行识别则继续使用独立的 worker。
这样可以避免简单粗暴地"所有阶段都使用同样线程数"，让 CPU 使用更加合理。
在项目自带的 500×500、16 行测试图片上，当前 Windows x64 Release 完整 OCR 已经进入 约 100 ms 级别。
当然，不同 CPU、图片内容和系统负载下结果会有所不同，但这个阶段已经说明：
纯 C + FP32 + CPU 这条路线仍然有很大的优化空间。
4. ARM64 NEON 与 LoongArch LSX 开始进入优化阶段
除了传统的 x86 SSE2 / AVX2，这一版也开始正式扩展其他 CPU 架构。
目前已经加入：
- ARM64 NEON
- LoongArch LSX
- Scalar fallback
- x86 SSE2 / AVX2
其中 ARM64 已经对部分高价值卷积算子进行了 NEON 优化，例如 Packed Conv1x1、3×3 Conv 和 ConvTranspose。
LoongArch64 也开始加入 LSX 优化路径。
这意味着项目正在逐渐从：
"Windows / Linux x86 OCR Runtime"
走向：
"真正跨 CPU 架构的轻量 OCR Runtime"。
对于 ARM 边缘设备、国产 CPU 等场景，这也是后续比较值得继续推进的方向。
5. 现在已经有四种主要使用方式
随着 preview.5 发布，目前 lw.PPOCR.C 已经形成了比较清晰的使用方式：
- Windows / Linux Native：适合 C、C++、C#、服务端以及嵌入式集成；
- 单文件 HTML：下载即用，图片和 PDF 都可以完全离线识别；
- Browser JavaScript SDK：适合开发自己的 Web OCR 应用；
- Node.js / WASM：适合 Node.js、Electron 以及 JavaScript 服务端项目。
虽然使用方式越来越多，但底层仍然是同一个纯 C Runtime。
模型也仍然统一使用自定义的 .lwm 格式，并不会因为 AVX2、NEON 或 WASM 而产生不同模型文件。
为什么要做这样一个项目？
现在 OCR 部署方案其实很多。
Python、Paddle Inference、ONNX Runtime、OpenVINO、TensorRT 都非常成熟。
lw.PPOCR.C 并不是想替代这些通用推理框架。
它更关注的是另一类需求：
如果只需要运行 PP-OCR，能不能把 Runtime 做得更小、更简单、更容易嵌入？
因此项目从一开始就没有打算做成一个通用 ONNX Runtime。
它只服务于 PP-OCR，并围绕固定模型结构做针对性优化。
这样做的好处就是：
模型范围更小
↓
支持算子更少
↓
Runtime 更简单
↓
更容易做专用 SIMD 优化
↓
更容易跨平台部署目前仍然坚持：
纯 C11、FP32 CPU、无部署期第三方推理依赖。
接下来还会做什么？
后续比较值得继续推进的方向，是 WASM SIMD128 的性能优化。
目前浏览器、单文件 HTML 和 Node.js/WASM 已经共用同一套 Runtime，因此底层增加一个高价值 WASM128 kernel，就可以同时惠及三个使用场景。
例如：
Packed MatMul
Softmax
ConvTranspose都是下一阶段比较值得继续优化的算子。
另外 ARM64 NEON 也还有不少可以继续迁移的高价值 kernel。
写在最后
从最开始只是想验证：
"能不能不用 ONNX Runtime，自己写一个纯 C 的 PP-OCR 推理 Runtime？"
到现在已经逐渐具备：
Native
Browser
Node.js
ARM64
LoongArch
PDF OCR
多线程调度
SIMD 优化lw.PPOCR.C 依然还是一个很小众的项目，但方向越来越清晰：
专注做好一个轻量、纯 C、低依赖、跨平台的 PP-OCR 专用 Runtime。
如果你也对 OCR、纯 C 推理、WebAssembly、ARM64、国产 CPU 或轻量化部署感兴趣，欢迎体验和交流。
GitHub：
当前版本：
v0.1.0-preview.5