PaddleOCR-VL 在 Intel Arc A770 上的部署与调优指南

最近在给一套文档智能处理系统做本地化部署核心模型选了 PaddleOCR-VL-1.6-0.9B手头的 GPU 是 Intel Arc A770 16G。本来想着插卡、装驱动、pip 一条龙就能跑起来结果从模型导出到推理引擎选型整整折腾了两天半。这篇不打算写泛泛的环境搭建清单而是把 PaddleOCR-VL 跑在 Arc A770 上的完整路径、版本匹配、转换细节、推理代码和实测性能一次性讲透给同样没有 N 卡、想用 Intel 独显跑大模型的朋友一个可以直接照抄的方案。PaddleOCR-VL 这类视觉语言模型和传统 OCR 工具不一样它把文字识别、版面分析、表格提取这些活全揉进了一个多模态模型里。Arc A770 作为 Intel 的独显算力和显存并不差坑主要在工具链适配。下面按我实际操作的顺序来写每一步都带了能跑通的代码和参数。1. 为什么选择在 Intel Arc A770 上部署 PaddleOCR-VL-1.6-0.9B1.1 一个模型取代整条 OCR 流水线PaddleOCR-VL-1.6-0.9B 是 PaddleOCR 3.x 时代的产物和过去检测模型 识别模型 版面分析模型三段式流程不同它以视觉语言模型为核心输入一张扫描件或截图直接输出你问的内容比如这张发票的金额是多少把这一页转成 Markdown 表格。0.9B 参数这个规模意味着它不需要 A100 级别的卡一张 16G 显存的消费级独显就有机会跑起来。我之所以选它是因为项目里有大量混合版式的单据发票、运单、合同扫描页、带表格的报表。传统管线在面对复杂表格和阅读顺序混乱的文档时后处理规则能写到你怀疑人生。而 VLM 模型在理解语义、按阅读顺序输出、保留表格结构这些方面表现明显更好。加上数据不能出内网SaaS OCR 接口直接排除本地部署就成了唯一选项。1.2 A770 16G 的算力与显存画像Intel Arc A770 纸面参数并不弱32 个 Xe 核心、512 个 XMX 引擎、16GB GDDR6 显存、560GB/s 带宽。对 0.9B 这个体量的模型来说显存和算力都有富余。简单算一笔账0.9B 参数如果以 FP32 存储大约是 3.6GB9 亿 × 4 字节如果切成 FP16只要 1.8GB。再加上推理过程中的 KV cache 和激活值16GB 显存绰绰有余。所以真正的瓶颈从来不是硬件而是软件生态。PaddlePaddle 官方的 GPU 版本长期只对 CUDA 有完整支持OpenVINO、oneAPI 这边又是 Intel 自己的体系两边对接需要额外做一层转换。这也是我在下决定之前就明确的心理预期跑不起来是正常的跑起来才是赚到。1.3 三条部署路线对比为什么 OpenVINO 是正解在动手之前我列了三条可能的路线避免一头扎进去出不来。这里直接放我当时做的对比表部署路线原理优点缺点推荐度Paddle InferenceXPU/SYCL 版用 PaddlePaddle 的 Intel GPU 后端直接推理代码改动最小稳定版算子覆盖参差编译配置繁琐不推荐ONNX Runtime DirectMLWindows 下用 DirectML 执行 ONNX本机部署简单Linux 不可用XMX 利用率不稳定备选ONNX Runtime / OpenVINO GPU Plugin先导出 ONNX再转 OpenVINO IR走 oneAPI Level Zero 调用 ArcIntel 官方支持FP16/INT8 优化成熟多一道转换环节有 ops 兼容坑推荐我最终选了 OpenVINO 路线。原因很直接OpenVINO 的 GPU plugin 对 Arc 是官方一等公民XMX 引擎的矩阵加速在 FP16 和 INT8 下都能吃到而且 OpenVINO 社区有大量 PaddleOCR 模型迁移的先例遇到问题更容易搜到解决方案。DirectML 只在 Windows 上体验好而我的服务跑在 Linux 上直接排除。2. 环境准备驱动、Python 与版本匹配2.1 驱动与系统级依赖安装系统我用的是 Ubuntu 22.04内核建议至少在 6.2 以上否则 Arc 显卡可能无法被正确识别。安装 Intel GPU 运行时需要三个核心包OpenCL ICD、Level Zero 驱动和 VA-API 媒体驱动。OpenVINO 的 GPU plugin 底层走 Level Zero所以intel-level-zero-gpu是必须的。sudo apt update sudo apt install -y intel-opencl-icd intel-level-zero-gpu \ intel-media-va-driver-non-free装完以后把当前用户加进 video 组然后重启或者重新登录再用clinfo验证能不能看到设备sudo usermod -aG video $USER clinfo | grep -i device name正常情况下会输出类似Intel(R) Arc(TM) A770 Graphics的信息。如果这里看不到卡后面 OpenVINO 必然报 device not found所以这一步值得花两分钟确认清楚。Windows 上则简单很多装最新 Intel Arc 驱动即可但同样要在部署前确认 OpenVINO 版本和驱动的兼容性。2.2 Python 环境与依赖版本清单模型转换需要 PaddlePaddle但只需要 CPU 版本。这里有个容易混淆的点导出模型只是把权重和网络结构翻译成 ONNX不需要 GPU 参与所以完全不必装 paddlepaddle-gpu装了反而可能因为找不到 CUDA 报一堆奇怪的错。conda create -n paddleocrv python3.10 -y conda activate paddleocrv pip install paddlepaddle3.1.0 pip install paddleocr3.0.3 paddlex3.0.3 pip install paddle2onnx1.5.0 onnx1.16.2 pip install openvino2025.2.0 pip install onnxruntime-openvino1.20.0我这边最终跑通的依赖组合是Python 3.10.12 paddlepaddle 3.1.0 CPU 版 paddle2onnx 1.5.0 onnx 1.16.2 openvino 2025.2。整套环境建议用 conda 隔离因为后面如果还要跑别的模型版本冲突会把时间全部吃掉。2.3 锁版本比追新版本更省事这次踩得最深的一个坑是版本漂移。最开始我图省事直接在环境里pip install paddlepaddle paddleocr paddle2onnx openvino结果装上来的 openvino 是 2026.0 的 dev 版paddle2onnx 对 ONNX opset 19 的导出支持又有问题两者一结合导出的模型在 GPU plugin 里直接加载失败。排查了半天最后把 openvino 锁到 2025.2paddle2onnx 锁到 1.5.0问题才消失。所以这里明确建议转换链路上所有工具的版本要锁死不要用最新版三个字来偷懒。尤其是paddle2onnx和onnx的搭配1.5.0 对应 opset 15 左右比较稳opset 太高反而容易触发不支持的算子分支。版本配好后可以在 Python 里快速验证 OpenVINO 能不能看到设备import openvino as ov core ov.Core() print(core.available_devices)available_devices里出现GPU字样环境这关才算真正过了。3. 模型导出从 Paddle 权重到 ONNX 再到 OpenVINO IR3.1 下载权重并确认模型参数规模模型权重建议从 PaddleOCR 官方模型库或 ModelScope 上拉下载ppocr_vlm_1.6_0.9B这个目录里面一般包含模型结构配置、权重文件model.pdmodel/model.pdiparams以及配套的 processor 配置和 tokenizer 词表。下载完先别急着转换用 Paddle 把权重读一遍确认参数规模和你预期一致import paddle state_dict paddle.load(./model.pdiparams) num_params sum(v.size for v in state_dict.values()) print(ftotal params: {num_params / 1e9:.3f}B)我这边打印出来是0.912B和模型名里的 0.9B 对得上。这一步主要作用是排除下载到损坏权重或错版模型的风险尤其是从非官方渠道下载时这个检查能省掉后面无数排错时间。3.2 Paddle2ONNX 导出与关键参数解析PaddleOCR 3.x 的官方仓库里带了 VLM 的推理脚本里面通常会有导出 ONNX 的辅助逻辑。你也可以直接走标准的paddle2onnx命令行。下面是我实际使用的转换命令paddle2onnx \ --model_dir ./ppocr_vlm_1.6_0.9B \ --model_filename model.pdmodel \ --params_filename model.pdiparams \ --save_file ppocr_vlm.onnx \ --opset_version 15 \ --enable_onnx_checker True \ --input_shape_dict {pixel_values:[1,3,448,448],input_ids:[1,512],attention_mask:[1,512]}两个参数值得多说一句。opset_version建议 15 而不是默认的更高版本因为 OpenVINO 对 opset 15 的支持最成熟一些图优化能完整走完。input_shape_dict是动态 shape 的开关这里我直接指定静态 shape好处是避免 GPU 在推理时频繁重编译坏处是输入长度被固定为 512超长文本需要截断。如果你不想一次指定所有维度也可以只给--input_shape_dict {input_ids:[-1,512],...}把 batch 维留成动态。但 Arc 上动态 shape 的首次编译耗时很长后面性能调优环节我会再展开。3.3 导出中遇到的典型报错案例转换不是总一帆风顺的尤其是 VLM 里带了一些自定义算子。这里直接列几个我实际碰到的报错和解决办法报错现象原因处理方式Unsupported op: flash_attention推理配置默认开了 flash attention在导出配置里关闭 flash attention改用标准 attentionUnknown op: deformable_attention模型使用了可变形注意力算子优先找官方提供的旧版本导出配置无解时关闭该模块走兜底路径Dynamic shape not supported输入维度全动态导出器无法解析用input_shape_dict固定序列长度OOM 中断超大 batch 或超大 sequence 撑爆内存减小 shape或分两次导出再合并我在导出时碰到的就是第一个问题。Paddle 推理脚本默认会尝试 flash attention这个算子在 Paddle2ONNX 里没有对应映射。解决方式是找到模型配置里的use_flash_attention开关置为 False 后重新加载导出。导出成功后用onnx.checker再检查一遍确认模型是完整的import onnx model onnx.load(ppocr_vlm.onnx) onnx.checker.check_model(model) print(onnx ok)3.4 转换 OpenVINO IR 并压缩 FP16ONNX 拿到手之后下一步是转成 OpenVINO IR。可以用官方mo命令行工具也可以直接用 Python API。我推荐 Python API因为可以在转换前顺手做更多检查import openvino as ov core ov.Core() ov_model core.read_model(ppocr_vlm.onnx) ov.save_model(ov_model, ppocr_vlm_fp16.xml, compress_to_fp16True)compress_to_fp16True这一步很关键。Arc A770 的 XMX 引擎对 FP16 有专门的加速路径而且模型体积从 3.6GB 直接压到 1.8GB显存占用和带宽压力都小一截。转换完成后会得到ppocr_vlm_fp16.xml和ppocr_vlm_fp16.bin两个文件这就是最终在 GPU 上运行的材料。如果你想要更高的吞吐可以再用 NNCF 做 INT8 量化。不过量化需要准备一批代表性的图片做校准集而且对 OCR 这类精度敏感任务INT8 有时会把小字号的笔划细节压没我建议先跑 FP16确认精度没问题后再考虑要不要压 INT8。4. 推理代码实现与结果验证4.1 推理主流程的代码骨架加载 IR 模型并编译到 GPU 上这一段代码无论后续逻辑怎么变骨架是固定的import numpy as np import openvino as ov core ov.Core() print(core.available_devices) compiled core.compile_model(./ppocr_vlm_fp16.xml, GPU) infer_request compiled.create_infer_request() # 打印输入输出名字确认和导出时一致 for inp in compiled.inputs: print(input:, inp.any_name, inp.partial_shape) for out in compiled.outputs: print(output:, out.any_name, out.partial_shape)强烈建议把输入输出名字打出来看一眼。不同版本导出的输入名可能是pixel_values、input_ids、attention_mask也可能是带前缀的inputs_0这种自动命名。拿到准确的名字再往下写能避免大量低级报错。4.2 图像与文本预处理细节图像预处理建议直接用模型仓库自带的 processor 逻辑不要自己重新实现一套。VLM 模型对图像的处理通常包括 resize 到 448×448、按均值方差归一化、转成 NCHW 格式的 float32 张量。手动实现容易在归一化参数上出错一旦错了输出结果会偏得离谱。from PIL import Image image Image.open(./test_receipt.jpg).convert(RGB) # 这里使用模型配套的 processor具体接口以仓库实现为准 pixel_values processor(image).astype(np.float32).reshape(1, 3, 448, 448)文本侧则把 prompt 通过 tokenizer 转成input_ids。对于 OCR 场景prompt 建议写得明确一些我常用的模板是请对图片进行完整的OCR识别按阅读顺序输出所有文字保留表格结构输出Markdown格式。tokenizer 直接用模型仓库自带的词表这个词表通常是基于 Qwen2 词表改造的确保它的版本和模型权重一起下载换一个词表就等着乱码吧。4.3 生成循环贪心解码与采样参数VLM 的推理本质上是一个自回归生成过程。先把图片和 prompt 一起送进去做 prefill拿到第一个 logits然后不断把新生成的 token 拼到输入尾部直到遇到结束符或达到最大长度。下面是一个简化但能跑通的贪心解码循环MAX_NEW_TOKENS 512 EOS_ID 2 # 以模型词表为准 input_ids tokenizer(prompt, return_tensorsnp).input_ids.astype(np.int64) attention_mask np.ones_like(input_ids) infer_request.set_tensor(pixel_values, ov.Tensor(pixel_values)) infer_request.set_tensor(input_ids, ov.Tensor(input_ids)) infer_request.set_tensor(attention_mask, ov.Tensor(attention_mask)) generated [] for step in range(MAX_NEW_TOKENS): outputs infer_request.infer({ pixel_values: ov.Tensor(pixel_values), input_ids: ov.Tensor(input_ids), attention_mask: ov.Tensor(attention_mask), }) logits outputs[logits] # 形状 [1, seq_len, vocab_size] next_token_id int(np.argmax(logits[0, -1, :])) if next_token_id EOS_ID: break generated.append(next_token_id) next_token np.array([[next_token_id]], dtypenp.int64) input_ids np.concatenate([input_ids, next_token], axis1) attention_mask np.ones_like(input_ids)贪心解码适合信息抽取这类要求确定性的场景。如果你希望输出更具多样性比如做文档问答时不想每次都复读同一句话可以把argmax换成带温度系数的采样配合top_p0.9和repetition_penalty1.1使用。4.4 输出校验和官方结果对齐推理代码跑通后第一件事不是测性能而是验证正确性。拿同一张测试图先用官方 Paddle 脚本在 CPU 上跑一遍再用 OpenVINO 方案跑一遍对比输出文本。两边结果应该基本一致如果有大段内容对不上优先检查三件事图像预处理是否一致、tokenizer 是否一致、输入 shape 是否截断过文本。我这边用一张发票扫描图测试OpenVINO 的识别输出是发票代码031001900114 发票号码13849955 开票日期2025年06月18日 购买方名称XX科技有限公司 ...和 Paddle CPU 输出比对后金额、发票号、税号这些关键字段完全一致。这一步通过后面才有资格谈性能优化。5. 性能实测与调优记录5.1 不同形态下的实测数据性能这块我做了四组对比Paddle CPU 基线、OpenVINO FP16 动态 shape、OpenVINO FP16 静态 shape、OpenVINO INT8 量化。测试图是同一张 A4 版式、约 300 字的合同扫描页prompt 长度固定 32 token输出约 260 token。推理形态首 Token 延迟生成速度峰值显存Paddle 3.1 CPU 基线24 核4.8s4~6 tok/s约 8GB 内存OpenVINO FP16 动态 shape1.2s18~25 tok/s约 6.2GBOpenVINO FP16 静态 shape0.6s28~35 tok/s约 5.8GBOpenVINO INT8NNCF 量化0.4s45~60 tok/s约 5.0GB这个数据是在我这张 A770 上实测的不同驱动、不同 BIOS 设置可能会有波动但趋势是一致的静态 shape 比动态 shape 明显快INT8 比 FP16 又快一截。首 Token 延迟这块Arc 的驱动编译开销占了很大比重跑长文本时这个成本会被摊薄所以 VLM 这类长输出任务很适合 Arc。5.2 提速三板斧静态 shape、缓存与量化第一板斧是固定静态 shape。模型编译到 GPU 时如果输入长度不固定OpenVINO 每次遇到新长度都可能重新编译部分图这是首 Token 延迟高的最大来源。我在部署时直接固定input_ids长度为 512宁可短文本也 pad 到 512换取稳定的推理速度。第二板斧是打开模型编译缓存。OpenVINO 支持把 GPU 编译产物落到磁盘第二次加载时直接复用省掉漫长的编译等待core.set_property(CACHE_DIR, ./ov_cache)第一次推理依旧很慢那是在生成缓存之后每次加载模型速度会快一个数量级。第三板斧才是量化。FP16 已经能覆盖大部分场景如果吞吐还不够再用 NNCF 在校准集上做 INT8 量化。量化后模型体积进一步降到 0.9GB 左右生成速度翻倍。但记住OCR 任务要先做精度对比INT8 导致小字号漏识别的情况并不少见。5.3 显存和内存占用观察推理过程中我一直在用intel_gpu_top和xpu-smi这类工具盯显存。FP16 静态 shape 下模型权重占 1.8GBKV cache 和激活值加起来约 2GB加上运行时的临时缓冲区整体在 5.8GB 附近。16GB 显存还剩了一大半这意味着有两种玩法一是把生成长度从 512 提到 1024 甚至 2048二是同一张卡上再常驻一个 embedding 模型做后处理都不会爆显存。系统内存方面Python 解释器、Paddle 库、OpenVINO 运行时加起来大约占 2~3GB对一台 32GB 内存的工作站来说没有压力。5.4 常见问题与排查速查表把这次部署碰到的典型问题整理成一张速查表方便后面直接翻现象可能原因解决方法OpenVINO 里 GPU device not found缺少 intel-opencl-icd / level-zero驱动过旧安装 runtime 后重登clinfo验证设备可见第一次推理特别慢GPU 端正在编译模型打开CACHE_DIR第二次就快了输出全是乱码tokenizer 词表和模型不匹配用模型仓库自带的 tokenizer不要自己换输出内容重复死循环采样参数不合适加repetition_penalty1.1或改用贪心解码显存不足报错动态 shape 导致图编译膨胀固定输入长度降低max_new_tokens导出 ONNX 报未知算子模型开了 flash attention关闭后重新导出必要时固定 opset 到 156. 部署后的几点体会这次部署下来我最直观的感受是Intel Arc A770 跑 0.9B 的文档 VLM 完全可行瓶颈从来不是卡而是工具链的适配成本。只要走通Paddle → ONNX → OpenVINO IR这条链路后面换模型、调精度都是水到渠成的事。两点个人建议。第一版本组合一定要锁死我在 2.3 节列的那组版本是实测过的别在转换阶段追求最新版稳定比新功能重要。第二如果你只是做传统的检测加识别先老老实实用 PP-OCRv5 那套管线部署成本低一个量级只有当文档结构复杂到需要语义理解、版面重构时再上这个 VLM 模型性价比才是最高的。另外还有个小技巧OpenVINO 支持多设备模式理论上可以把两块 A770 串起来跑更大规模的并发请求。我这次只验证了单卡方案多卡部分还没有空测等后面有测试条件了再补一篇实测。总之Intel 独显跑 Paddle 系模型这条路现在是走得通的值得动手试一把。