PaddleOCR 3.5 接入 Transformers：模型没换代，接入少绕路

PaddleOCR 3.5 这次最值得看的，不是“又强了多少”，而是多了一个很小的开关：engine="transformers"。

这意味着，受支持的 PaddleOCR 模型现在可以用 Hugging Face Transformers 作为推理后端跑起来。PaddleOCR 仍负责 OCR 和文档解析 pipeline。Transformers 只是新增后端，不是全面迁移。

我更愿意把它看成一次让路：向 PyTorch、Transformers、Hugging Face 这套主流开发者习惯让路。模型能力有没有跃迁，目前不能这么说。但集成摩擦，确实被压低了。

发生了什么：多了一个后端，不是换了一套系统

PaddleOCR 3.5 引入了更灵活的推理引擎接口。开发者可以通过 engine 选择推理后端，通过 engine_config 配置后端参数。

可配置项包括 dtype、设备、attention 实现等。受支持模型包括 PP-OCRv5、PaddleOCR-VL 1.5 等 OCR 与文档解析模型。

这个边界很重要。

不要把它读成“PaddleOCR 放弃 Paddle 后端”。没有。原有后端还在，PaddleOCR 的 pipeline 也还在。新增 Transformers 后端，解决的是另一件事：让已经在 HF / PyTorch 栈里的团队少绕一圈。

谁受影响：RAG 和 Agent 团队少写胶水代码

真正会关心这件事的，不是普通用户，而是两类开发者。

一类是做 RAG、搜索、知识库、Document AI 的团队。另一类是做文档 Agent、分析自动化、内部工具链的工程团队。

这些团队的麻烦通常不在 LLM 回答阶段，而在入口。

PDF、扫描件、截图、表格、页眉页脚、公式、复杂版面，先要被抽出来。抽错一行，后面的向量检索、摘要、问答都会跟着歪。

“差之毫厘，谬以千里。”这句话放在文档入口上很贴切。LLM 看起来站在终点，命门常常在最前面的 OCR 和版面解析。

PaddleOCR 接入 Transformers 的现实价值，就是把这段前处理更顺地塞进已有工作流里。

已经使用 PyTorch、Transformers、Hugging Face Hub 的团队，可以更自然地做模型加载、实验和服务衔接。动作也很具体：原来需要在 Paddle 生态和 HF 生态之间搭桥的团队，可以先评估 engine="transformers" 是否足够覆盖现有模型和部署需求；新项目则可以把 OCR / 文档解析直接纳入现有 HF 栈做原型。

但我不建议所有团队立刻迁移。

如果你的系统已经用 Paddle 后端稳定跑批，吞吐是第一目标，那就没必要为了“生态统一”折腾。官方仍建议高吞吐优先用默认 paddle_static。这句话比宣传语更有用。

我的判断：这次做对了，但别把适配当升级

我喜欢这次更新的地方，是它没有强行把故事讲成“大一统”。

很多模型项目的尴尬，不是能力完全不行，而是接入太费劲。开发者不是没有耐心，是没有预算把时间花在框架缝合上。

技术扩散有时很像铁路换轨距。不完全一样，但逻辑相通：车跑得再快，轨道不兼容，货也运不远。今天的“轨道”，就是开发者工具链。

PaddleOCR 3.5 这步，至少承认了一个现实：大量 AI 应用团队已经围着 PyTorch / Transformers / Hugging Face 工作。既然如此，就别让他们为了接 OCR 和文档解析再绕一套复杂路径。

但限制也要摆在桌面上。

Transformers 后端解决的是生态适配，不是承诺更高精度，也不是承诺更高速度。Hugging Face 集成也不等于完整 Document AI 方案。权限、索引、召回、切分、重排、Agent 调工具，仍要开发者自己搭。

接下来最该观察的变量只有两个。

一是支持模型范围会不会继续扩大。现在能跑受支持模型，但团队真正迁移时，关心的是自己要用的 OCR、版面解析、多模态文档模型是否覆盖。

二是 Transformers 后端在真实部署里的稳定性和成本。包括显存占用、延迟、批处理能力、服务化复杂度。没有这些实际约束，生态适配只能停在“更容易试用”。

所以这次更新的位置很清楚：不是模型秀肌肉，而是产品降摩擦。

好工具的价值，很多时候不在发布会上喊得多响，而在开发者少改一层环境、少写一段胶水、少踩一个框架坑。文档进入 RAG 和 Agent 之前，总要有人干脏活。PaddleOCR 3.5 做的，是让这件事更容易接进主流流水线。

不华丽，但很工程。