企业官网建设流程全解析

把 PaddleOCR-VL-1.6-0.9B 跑在 Intel Arc A770 上这件事，我前后折腾了一个多星期才完全调顺。这篇文章就把整个过程整理出来，包括环境搭建、模型部署、参数调优，以及踩过的几个硬坑。如果你手头正好有 A770 或者其他 Intel 独显，想跑 PaddleOCR 的多模态模型，这篇应该能帮你省下不少时间。

PaddleOCR-VL-1.6-0.9B 是 PaddleOCR 推出的文档智能模型，主打的是“版面理解+OCR识别+结构化输出”一条龙。相比传统 OCR 方案需要串联多个模型（检测、方向分类、识别、表格结构解析），它用一个视觉语言模型直接搞定，对复杂版面、表格、公式、甚至手写内容都有不错的适应性。0.9B 参数量属于轻量级，理论上消费级显卡就能跑，但 Intel 显卡的部署和 N 卡差别不小，网上能查到的完整案例又少，所以我把自己的实践记录整理出来，给同样在 Intel GPU 上折腾的朋友做个参考。

1. 项目背景与目标解析

1.1 为什么选这个模型

先说说我为什么挑 PaddleOCR-VL-1.6-0.9B 而不是其他 OCR 方案。

我手头有一批混合了印刷体、手写批注、表格、盖章的扫描文档，数量大概几万页，需要批量转成结构化的 Markdown 文件。传统方案一般是 PaddleOCR 的检测+识别串起来，再加表格结构解析模型，流程长、中间环节多，遇到复杂的嵌套表格或者手写覆盖印刷体的情况，效果很难保证。PaddleOCR-VL 这种 VLM 路线的模型直接输入整页图像，输出带格式的 Markdown，一步到位，省去了串联多个模型的麻烦。

0.9B 这个参数量放在 VLM 里算轻量级，显存要求不高，推理速度也快。A770 有 16GB 显存，跑这个模型绰绰有余。另外一个重要原因是 PaddleOCR-VL 是百度开源的项目，中文文档场景的适配做得比同类开源模型好，许可证也相对宽松，商用没问题。

1.2 Intel Arc A770 这块卡的定位

选择 A770 可能有人觉得冷门，但从性价比角度看，这张卡在 AI 推理场景确实有吸引力。

Intel Arc A770 有两个版本，8GB 和 16GB，我用的 16GB 版本。它基于 Xe-HPG 架构，内置 XMX（Xe Matrix eXtension）AI 加速单元，理论上有不错的 AI 算力。关键的第二点是显存容量，16GB 在 2000 元价位段的独显里几乎无敌，可以轻松容纳大多数轻量级模型。但 Intel 显卡的软件生态不如 NVIDIA 成熟，很多框架默认只支持 CUDA，需要额外配置才能调用 Intel GPU，这也是很多人买了 A770 之后吃灰的原因。

把它和 NVIDIA 的卡做个简单对比：

价格相近的情况下，A770 显存更大、纯计算性能不差，代价是部署门槛高一些。这篇文章的核心就是把这块最短的短板补上。

1.3 一条明确的部署路径

最终目标很明确：在 Linux 系统下，用 PaddlePaddle 框架调用 Intel Arc A770 的算力，成功运行 PaddleOCR-VL-1.6-0.9B，并且把推理速度、显存占用优化到一个可接受的水平。

这里需要说明，我不是第一次接触 PaddleOCR，之前的检测+识别方案在 CPU 和 N 卡上都跑过，对框架的使用有一定基础。即便如此，这次跨 Intel GPU 的部署还是遇到了不少意料之外的坑，主要集中在驱动识别、库版本匹配、以及 IPEX 模式配置三个方面。下面按照部署顺序逐一讲。

2. 部署环境准备与软件栈选型

2.1 硬件平台与系统基础

我的服务器配置：

建议内存至少 16GB，因为 PaddleOCR-VL 加载模型权重后，还需要额外的临时空间做图像预处理。32GB 跑起来比较从容，如果要开多个并发任务，建议 64GB。

系统层面，Ubuntu 22.04 是目前兼容性最好的选择。Windows 下 PaddlePaddle 对 Intel 显卡的支持也有，但在 Linux 下使用 Docker 和命令行工具更顺手，而且长时间批量处理任务稳定性更好，所以我首选了 Linux。

2.2 Intel GPU 驱动与 oneAPI 安装

Intel 显卡在 Linux 下需要安装两个层面的驱动：内核级驱动（i915）和用户态运行时（Intel Graphics Compute Runtime）。

新版本 Ubuntu 自带的内核驱动已经包含 i915，但版本可能偏旧，建议更新内核到 6.2 以上对 Arc 系列的支持才完整。可以用 ubuntu-mainline-kernel 工具升级，也可以直接用官方提供的 Intel 驱动安装脚本：

# 安装 Intel 官方 GPU 驱动仓库 sudo apt update sudo apt install -y gpg-agent wget wget -qO - https://repositories.intel.com/gpu/intel-gpu-keys.gpg | sudo gpg --dearmor -o /usr/share/keyrings/intel-gpu-archive-keyring.gpg echo "deb [arch=amd64 signed-by=/usr/share/keyrings/intel-gpu-archive-keyring.gpg] https://repositories.intel.com/gpu/ubuntu jammy unified" | sudo tee /etc/apt/sources.list.d/intel-gpu-jammy.list sudo apt update sudo apt install -y intel-opencl-icd intel-level-zero-gpu level-zero

接着安装 Intel oneAPI Base Toolkit 里的 DPC++ 编译器和相关运行时，这是 PaddlePaddle 调用 Intel GPU 的前提。我用的版本是 2024.0，装完后需要设置环境变量：

source /opt/intel/oneapi/setvars.sh

验证驱动和运行时是否正常，用下面这个命令：

# 检查显卡是否被系统识别 lspci | grep VGA # 检查 Level-Zero 运行时是否可用 sycl-ls

正常情况下sycl-ls会输出类似[platform:GPU:0] Intel(R) Arc(TM) A770 Graphics的信息，到这里驱动的准备就完成了。

2.3 Python 环境与 PaddlePaddle 安装

Python 环境推荐用 conda 管理，版本选 3.10。PaddlePaddle 官方对 3.10 的支持最好，3.11 以上在 Intel GPU 的某些算子上有兼容问题。

安装 PaddlePaddle GPU 版本时，默认的paddlepaddle-gpu包是针对 CUDA 的，在 Intel 显卡上根本运行不了。需要安装的是支持 oneDNN 和 oneAPI 的版本，可以通过官方给出的 Intel 分支安装：

# 创建 conda 环境 conda create -n paddle python=3.10 conda activate paddle # 安装 PaddlePaddle（Intel GPU 版） python -m pip install paddlepaddle-gpu==2.6.1.post112 -f https://www.paddlepaddle.org.cn/whl/linux/mkl/avx/stable.html

需要注意的是，这里安装的是带 MKL（Math Kernel Library）的 CPU/GPU 混合版。PaddlePaddle 目前对 Intel GPU 的支持走的是 IPEX（Intel Extension for PyTorch）兼容模式，也支持 oneDNN 的 GPU 后端。2.6.1 这个版本是我实测下来对 Arc A770 识别最稳定的版本，更早的 2.5.x 在算子层面明显缺支持，更晚的开发版又存在库冲突。

验证 PaddlePaddle 是否能调用 GPU：

import paddle # 检查是否为 GPU 版本 print(paddle.is_compiled_with_cuda()) # 这里是 False print(paddle.device.get_device()) # 如果配置成功，会显示 GPU 设备名

get_device()如果返回gpu:0相关的内容，说明 Paddle 已经识别到了 Intel GPU。如果报错，大概率是 oneAPI 环境变量没设置对，回到上一步重新 source 一下 setvars.sh。

2.4 PaddleOCR 套件安装

PaddleOCR-VL 模型发布在 PaddleOCR 仓库下，需要安装最新的 develop 分支或 2.7 以上版本。我直接用的源码安装：

git clone https://github.com/PaddlePaddle/PaddleOCR.git cd PaddleOCR pip install -r requirements.txt python setup.py install

依赖里有几个重要的库：paddlex（模型管理）、diffusers（生成式模型推理支持）、transformers、einops。如果安装过程中某些包版本冲突，建议不要强解，看报错信息手动指定版本。我踩过的最大的坑是 transformers 版本过高导致模型配置文件读取失败，后来固定到 4.38.2 才正常。

到这里基础环境就绪，下面进入核心部署环节。

3. 模型部署的核心流程

3.1 模型下载与权重管理

PaddleOCR-VL-1.6-0.9B 的权重可以直接用 paddlex 自动下载，也可以手动下载后在代码里指定路径。我用的是手动下载，方便后续离线部署。

from paddlex import create_model model = create_model("PaddleOCR-VL-1.6-0.9B", device="gpu:0")

首次执行这段代码，paddlex 会自动下载权重到~/.paddlex/official_models目录，下载约 2GB（FP16 精度）。如果网络不好，可以去 PaddleOCR 官方 GitHub Release 页面下载inference格式的权重包，手动解压到指定目录。权重目录结构大概是：

~/.paddlex/official_models/ └── PaddleOCR-VL-1.6-0.9B/ ├── inference.pdmodel ├── inference.pdiparams ├── inference.pdiparams.info └── config.yaml

确认权重文件都在后，后续代码里可以直接加载，不会触发下载。

3.2 首次推理测试

先用官方示例图跑一次最简单的推理，确认模型能在 A770 上正常输出：

import paddle from paddlex import create_model # 指定使用 GPU（这里就是 Intel Arc A770） model = create_model("PaddleOCR-VL-1.6-0.9B", device="gpu:0") # 输入图像路径 result = model.predict("demo.jpg") # 输出结果 for res in result: print(res["res"]["markdown"])

第一次跑的时候我遇到了报错，提示某个算子无法在 GPU 上执行，后来在配置里加了一行环境变量才解决：

export FLAGS_use_mkldnn=1

这行设置的作用是让 Paddle 在遇到不支持的 GPU 算子时自动回退到 CPU 的 MKL-DNN（oneDNN）路径。Intel GPU 天然的 oneDNN 亲和性，让这种回退策略在 A770 上的表现相当不错，大部分算子还是跑在 GPU 上，回退到 CPU 的只是极少数。

3.3 核心参数配置解析

create_model时可以传入几个关键参数，直接影响推理效果和速度：

我实际跑的时候把max_tokens调到了 1024，因为测试文档中有大量长段落，默认 512 会导致内容被截断。precision选 fp16 时显存占用大约 4.5GB，速度比 fp32 快一倍，精度损失在 OCR 场景下基本无感。

一个值得注意的点：run_mode参数不要选trt，因为 TensorRT 不支持 Intel GPU，选了会报错。保持默认的paddle模式即可。

3.4 批量文档处理脚本

部署稳定后，我写了一个批量处理脚本，把整个目录的扫描件统一转换。脚本会做图像预处理（矫正、缩放），调用模型推理，最后把 Markdown 输出到指定目录：

import os import argparse from tqdm import tqdm from paddlex import create_model from PIL import Image def preprocess_image(image_path, max_size=2048): """图像预处理：限制最大边，保证模型输入不过大""" img = Image.open(image_path).convert("RGB") width, height = img.size max_dim = max(width, height) if max_dim > max_size: scale_ratio = max_size / max_dim new_width = int(width * scale_ratio) new_height = int(height * scale_ratio) img = img.resize((new_width, new_height), Image.LANCZOS) return img def process_folder(input_dir, output_dir, model): os.makedirs(output_dir, exist_ok=True) image_files = [f for f in os.listdir(input_dir) if f.lower().endswith((".jpg", ".jpeg", ".png"))] for filename in tqdm(image_files, desc="Processing"): img_path = os.path.join(input_dir, filename) img = preprocess_image(img_path) temp_path = os.path.join("/tmp", filename) img.save(temp_path) result = model.predict(temp_path) for res in result: markdown_content = res["res"]["markdown"] output_path = os.path.join(output_dir, os.path.splitext(filename)[0] + ".md") with open(output_path, "w", encoding="utf-8") as f: f.write(markdown_content) os.remove(temp_path) if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument("--input", type=str, required=True, help="输入图片目录") parser.add_argument("--output", type=str, required=True, help="输出 Markdown 目录") args = parser.parse_args() model = create_model("PaddleOCR-VL-1.6-0.9B", device="gpu:0", precision="fp16") process_folder(args.input, args.output, model)

这个脚本有三个细节比较重要：

第一，图像预处理要限制最大边长。A770 的算子对大尺寸输入支持有限，超过 2048 像素会显著拖慢推理速度，甚至爆显存。第二，输出文件按原文件名命名，保留关联关系，方便后续回查。第三，临时文件尽量写到/tmp，避免大量图片直接占用工作目录的磁盘空间。

4. A770 上的性能实测与调优记录

4.1 推理速度实测

跑了 200 张不同复杂度文档，统计了速度分布：

作为参考，同样模型在 RTX 3060 上纯文本页大约是 2.2 秒，A770 到 2.8 秒左右，差距可以接受。考虑到 A770 的价格和显存，这个表现符合预期。

4.2 耗时构成分析

进一步用cProfile做了耗时统计，发现单页推理时间主要拆成三块：

• 图像预处理：约 0.3 秒，主要是缩放和归一化，A770 的 CPU 回退路径在这里。
• VLM 推理前向计算：约 2.1 秒，这是 GPU 的主体计算部分，剪枝空间不大。
• 文本生成解码：约 0.4 秒，受限于推理策略的束搜索宽度。

整体来看，A770 的 XMX 引擎确实在矩阵运算上发挥了作用，前向计算速度接近 N 卡水平，真正拉差距的主要是框架对 Intel GPU 的算子覆盖度和驱动层面的额外开销。

4.3 显存占用优化技巧

A770 有 16GB 显存，虽然跑 0.9B 模型压力不大，但如果同时处理大量任务，还是要关注显存释放。

模型推理默认会缓存部分激活值，如果开启paddlex的use_trt或 batch 调试模式，显存峰值会明显上升。一个实用技巧是在推理后手动清理显存缓存：

import paddle # 推理完成后 paddle.device.cuda.empty_cache()

此外，A770 的显存是由驱动统一管理的，如果系统内存紧张，会缓冲到共享显存空间，这种情况下性能会有轻微下降，但不会 OOM。这个设计在跑大批量任务时反而是一种保护。

4.4 推理精度与格式输出测试

PaddleOCR-VL 输出的是带格式的 Markdown，这一点实际上相当于集合了版面分析、OCR 识别、表格结构解析三合一。

我拿了几组典型测试页做了字段级别的准确性评估。纯文本页面的汉字识别准确率大约在 98%，数字和英文字符几乎无错；表格页面的行列结构还原度不错，但遇到多级表头或者合并单元格时，偶尔会丢失层级结构；公式识别用的是 LaTeX 格式输出，基础公式的准确率尚可，复杂分式和矩阵还是会出错。如果要投入生产，建议对生成结果做一轮自动校验，比如用 PaddleOCR 的旧版检测模型做交叉验证，把置信度低的区域重点标记出来。

4.5 多进程并发注意事项

一开始我尝试用multiprocessing同时跑多个推理进程，想提高吞吐量，结果 A770 的驱动不允许多个进程同时访问同一个 GPU 上下文，直接报错。后来改成单进程内批量循环处理，虽然吞吐量不如并发，但稳定性和显存管理要好得多。

如果你的部署环境是 Docker，记得在启动容器时加--device=/dev/dri参数，否则容器内访问不到 Intel GPU。

5. 常见问题与排查技巧实录

5.1 问题速查表

部署和运行过程中我遇到了不少报错，把最有代表性的整理出来：

每条问题我都实际遇到过，其中transformers 版本问题最容易忽略，因为报错信息不会直接提示是 transformers 的锅，只会告诉你模型加载失败。

5.2 算子回退机制的理解

刚才提到FLAGS_use_mkldnn=1这个设置，这里详细解释一下它的作用。

PaddlePaddle 在 GPU 上执行算子时，如果遇到没有对应 GPU 版本实现的算子，默认会直接抛异常终止。设置FLAGS_use_mkldnn=1后，框架会走 oneDNN 库，自动将 CPU 算子转成 oneDNN 的 GPU 实现。对 Intel GPU 来说，oneDNN 的 GPU 后端就是为 Xe 架构优化的，所以执行效率并不低。

这也是 PaddlePaddle 在 Intel GPU 上的一个设计巧思：它不是在 GPU 上执行每个算子，而是优先用 oneDNN GPU 后端，不支持的再回退到 CPU 路径。因为是同一个库（oneDNN），CPU 和 GPU 之间的切换开销很小。这也是为什么 A770 上跑 Paddle 模型的速度比很多人预期的好。

如果没有这个设置，模型在首个不支持的算子处就会崩溃，表现为“模型加载成功，但推理报错”，很多新人在这里卡住。

5.3 Linux 下 A770 驱动的升级与排查

如果sycl-ls没有识别到 GPU，大概率是驱动问题。排查路径按以下顺序：

# 1. 确认内核模块加载 lsmod | grep i915 # 2. 确认固件更新（Arc 系列的 GuC/HuC 固件） sudo dpkg -l | grep intel # 3. 查看内核日志中的 GPU 相关错误 dmesg | grep -i "i915\|xe"

如果 i915 模块没有加载，可以在/etc/modules里加上i915，然后重启。注意 Arc A770 完整支持需要 GuC/HuC 固件，旧内核可能缺少对应的固件文件，导致 GPU 计算单元初始化失败。

另一种情况是系统里同时装了 NVIDIA 和 Intel 两张卡，默认显示设备是 N 卡，但计算设备要指定到 Intel 上。可以用ZE_AFFINITY_MASK环境变量指定：

export ZE_AFFINITY_MASK=0.0

5.4 性能不达标的排查清单

如果模型能跑但速度不理想，按优先级排查：

1. 确认设备选择正确：检查paddle.device.get_device()，确认返回的是 GPU 而不是 CPU。
2. 检查精度设置：fp16 比 fp32 在 A770 上快约 60%-80%，确认实际生效。
3. 看任务管理器：用intel_gpu_top监控 GPU 利用率，如果利用率低于 50%，可能算子回退太多。
4. 确认推理输入图片尺寸：太大的图不会让识别更准，反而让速度成倍下降。
5. 切换 run_mode：paddle模式下 oneDNN 优化效果最佳，不要试图改成trt或onnx。

5.5 离线部署与容器化建议

实际生产环境通常不能连接公网下载权重，提前准备好离线部署包很重要。

权重文件可以提前下载好，通过 scp 传到目标机器，放到~/.paddlex/official_models/。Python 依赖用 pip download 缓存到本地目录，然后在目标机器上离线安装。

如果要用 Docker，参考 Dockerfile 的关键部分：

FROM nvidia/cuda:12.2.0-base-ubuntu22.04 # 注意：Intel GPU 不需要 CUDA，这里只用来作为基础镜像 RUN apt-get update && apt-get install -y intel-opencl-icd intel-level-zero-gpu ENV LD_LIBRARY_PATH=/opt/intel/oneapi/compiler/latest/lib:$LD_LIBRARY_PATH COPY ./requirements.txt /app/requirements.txt RUN pip install -r /app/requirements.txt CMD ["python", "/app/infer.py", "--input", "/data/input", "--output", "/data/output"]

启动容器时：

docker run -d \ --device=/dev/dri \ -v /data/input:/data/input \ -v /data/output:/data/output \ -v /opt/intel:/opt/intel \ ocr-a770:latest

容器的关键点是挂载/dev/dri设备和 oneAPI 安装目录，后者是为了让容器内的库能正常链接。

6. 个人经验与后续扩展建议

最后再分享一些我在实际使用中的体会。

部署过程最大的压力不是模型本身，而是框架与硬件的适配。PaddlePaddle 对 Intel GPU 的支持比 PyTorch 的 IPEX 路径更顺滑，这是当初选择 Paddle 的重要原因。A770 的性能释放很大程度上取决于驱动和 oneAPI 的版本组合，不要盲目追求最新版，稳定性优先。我在测试中发现 2024 年版 oneAPI 配合 2.6.1 的 Paddle 是最稳的组合，升到 2024.2 之后某些算子反而出现了兼容问题。

关于硬件选择也有一个实际观察：如果你的核心需求是 OCR 文档解析，而不是训练模型，那么 A770 的性价比优势相当明显。16GB 显存意味着未来切换到更大的 7B 参数模型也不必换卡，这给后续升级留了空间。真要挑毛病的话，驱动安装和版本管理的复杂度比 N 卡高，排查问题的成本是有的，但一次性配置好后并不会有太大负担。

对于后续可以扩展的方向，我建议几个：一是尝试用ONNX Runtime的 Intel GPU EP（Execution Provider）作为备选推理后端，某些算子上可能比 Paddle 原生路径更快；二是通过OpenVINO做模型转换和量化，理论上能把 INT8 推理速度再提升一截，但需要验证精度损失；三是用 Paddle Serving 把模型封装成微服务，接入现有业务系统。

这些扩展我还没全部完成验证，但方向是可靠的。整体来说，PaddleOCR-VL-1.6-0.9B 在 Intel Arc A770 上已经可以稳定支撑中小规模的文档数字化任务，值得花时间去调通它。