最近在给一套文档智能处理系统做本地化部署，核心模型选了 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.9B
1.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.6GB（9 亿 × 4 字节）；如果切成 FP16，只要 1.8GB。再加上推理过程中的 KV cache 和激活值，16GB 显存绰绰有余。
所以真正的瓶颈从来不是硬件，而是软件生态。PaddlePaddle 官方的 GPU 版本长期只对 CUDA 有完整支持，OpenVINO、oneAPI 这边又是 Intel 自己的体系，两边对接需要额外做一层转换。这也是我在下决定之前就明确的心理预期：跑不起来是正常的，跑起来才是赚到。
1.3 三条部署路线对比，为什么 OpenVINO 是正解
在动手之前，我列了三条可能的路线，避免一头扎进去出不来。这里直接放我当时做的对比表：
| 部署路线 | 原理 | 优点 | 缺点 | 推荐度 |
|---|---|---|---|---|
| Paddle Inference（XPU/SYCL 版） | 用 PaddlePaddle 的 Intel GPU 后端直接推理 | 代码改动最小 | 稳定版算子覆盖参差，编译配置繁琐 | 不推荐 |
| ONNX Runtime + DirectML | Windows 下用 DirectML 执行 ONNX | 本机部署简单 | Linux 不可用，XMX 利用率不稳定 | 备选 |
| ONNX Runtime / OpenVINO GPU Plugin | 先导出 ONNX，再转 OpenVINO IR，走 oneAPI Level Zero 调用 Arc | Intel 官方支持，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 python=3.10 -y conda activate paddleocrv pip install paddlepaddle==3.1.0 pip install paddleocr==3.0.3 paddlex==3.0.3 pip install paddle2onnx==1.5.0 onnx==1.16.2 pip install openvino==2025.2.0 pip install "onnxruntime-openvino>=1.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.2，paddle2onnx 锁到 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 IR
3.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(f"total 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，改用标准 attention |
Unknown 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 并压缩 FP16
ONNX 拿到手之后，下一步是转成 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_fp16=True)compress_to_fp16=True这一步很关键。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_tensors="np").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]], dtype=np.int64) input_ids = np.concatenate([input_ids, next_token], axis=1) attention_mask = np.ones_like(input_ids)贪心解码适合信息抽取这类要求确定性的场景。如果你希望输出更具多样性，比如做文档问答时不想每次都复读同一句话，可以把argmax换成带温度系数的采样，配合top_p=0.9和repetition_penalty=1.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.8s | 4~6 tok/s | 约 8GB 内存 |
| OpenVINO FP16 动态 shape | 1.2s | 18~25 tok/s | 约 6.2GB |
| OpenVINO FP16 静态 shape | 0.6s | 28~35 tok/s | 约 5.8GB |
| OpenVINO INT8（NNCF 量化） | 0.4s | 45~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.8GB，KV 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_penalty=1.1，或改用贪心解码 |
| 显存不足报错 | 动态 shape 导致图编译膨胀 | 固定输入长度，降低max_new_tokens |
| 导出 ONNX 报未知算子 | 模型开了 flash attention | 关闭后重新导出，必要时固定 opset 到 15 |
6. 部署后的几点体会
这次部署下来，我最直观的感受是：Intel Arc A770 跑 0.9B 的文档 VLM 完全可行，瓶颈从来不是卡，而是工具链的适配成本。只要走通"Paddle → ONNX → OpenVINO IR"这条链路，后面换模型、调精度都是水到渠成的事。
两点个人建议。第一，版本组合一定要锁死，我在 2.3 节列的那组版本是实测过的，别在转换阶段追求最新版，稳定比新功能重要。第二，如果你只是做传统的检测加识别，先老老实实用 PP-OCRv5 那套管线，部署成本低一个量级；只有当文档结构复杂到需要语义理解、版面重构时，再上这个 VLM 模型，性价比才是最高的。
另外还有个小技巧：OpenVINO 支持多设备模式，理论上可以把两块 A770 串起来跑更大规模的并发请求。我这次只验证了单卡方案，多卡部分还没有空测，等后面有测试条件了再补一篇实测。总之，Intel 独显跑 Paddle 系模型这条路，现在是走得通的，值得动手试一把。
