> ## Documentation Index > Fetch the complete documentation index at: https://dragonwingdocs.qualcomm.com/llms.txt > Use this file to discover all available pages before exploring further. # 在 Dragonwing IQ-9075 NPU 上运行 Pi0.5 VLA 模型 > 将拥有 30 亿参数的视觉-语言-动作模型 Pi0.5，从下载到生成机器人动作，完全在 Dragonwing IQ-9075 EVK 的 Hexagon NPU 上完成：1.1 秒动作块，4.3 倍实时速度，无 CPU 回退。
机器人
Rami Mouro · 2026 年 7 月 29 日 · ← 所有文章
在 Qualcomm Dragonwing IQ-9075 EVK 上一步步搭建一个视觉-语言-动作（VLA）模型，直到它在开发板的 Hexagon NPU 上生成机器人动作。本文完全自包含——你需要的每条命令和每行代码都在这一页上，且每一步都以可核对的输出结尾。 我们使用 [Pi0.5](https://aihub.qualcomm.com/models/pi05)，一个 30 亿参数的机器人基础模型：给它相机图像和一条自然英语指令，它就输出关节运动。大约十分钟就能完成第一次 NPU 推理。本页最后三分之一才是有趣的部分——*为什么*这个模型的四个组成部分最终会以那样的方式分布在硬件上。 本页的每个数字都是在运行 Ubuntu 24.04 Server 的真实 IQ-9075 EVK 上实测的。取自 Qualcomm AI Hub 官方公开性能分析的数字会明确标注，绝不与我们的数据混用。 ## 你最终会得到什么 | | 实测值 | | -------------------- | ----------------------------------------------------- | | 动作块（50 个时间步 × 7 自由度） | **1111–1152 ms**，0.87–0.90 块/秒 | | 相对实时的速度 | **4.3–4.5×** — LIBERO 以 10 Hz 运行，因此 50 步即 5 秒的运动 | | 正确性 | **45 个输出张量中 45 个与 Qualcomm 参考运行器逐位一致** | | 闭环任务成功率 | 覆盖全部十个 LIBERO-10 任务的 **100 个回合中成功 86 个**，仿真器同样运行在这块板上 | | CPU 回退 | 无；100% NPU | ## 开始之前 | 要求 | 说明 | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Dragonwing IQ-9075 EVK | 引导 **Ubuntu 24.04 Server** 或更新版本，arm64。无头运行即可——本文没有任何步骤需要显示器 | | 一块已完成启动配置的开发板 | 先完成 Ubuntu 文档中的[通用前提条件](/zh/Ubuntu/ubuntu-supported-hardware#common-prerequisites)，再完成[设置设备](/zh/Ubuntu/devices/iq9075-evk/set-up-the-device)，使开发板已刷写、已联网、可通过 SSH 访问 | | 约 35 GB 空闲磁盘 | 模型 2.9 GB；其余由构建和转储占用 | | 网络 | 约 3 GB 下载量 | 下面每条命令都**在开发板上**运行，通过 SSH 或串口控制台。不需要 Qualcomm AI Hub 账户。没有云端编译任务。不需要浏览器。 设置一个后文都会引用的工作目录： ```bash theme={null} theme={null} export WORK=$HOME/pi05 mkdir -p $WORK && cd $WORK ``` ## 1. 安装 ROS 2 Jazzy 和 Qualcomm AI 运行时 先从 ROS 2 开始。以下命令来自[软件设置](/zh/Ubuntu/robotics-workflows/software-setup)页面： ```bash theme={null} theme={null} sudo apt-get update sudo apt-get install -y curl gnupg2 lsb-release ca-certificates software-properties-common locales sudo locale-gen en_US en_US.UTF-8 sudo add-apt-repository universe -y sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key \ -o /usr/share/keyrings/ros-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] \ http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" \ | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null sudo apt-get update sudo apt-get install -y ros-jazzy-ros-base python3-colcon-common-extensions ros-dev-tools ``` **使用 `http://` 而不是 `https://` 是有意为之。** `packages.ros.org` 是指向 `ftp.osuosl.org` 的 CNAME，后者的 TLS 证书只覆盖 `*.osuosl.org`。在没有 CDN 掩盖这一不匹配的网络中，`https://` 会导致证书校验失败。软件包完整性由 GPG 签名保证，而这正是 `apt` 实际校验的内容——Qualcomm 官方设置页面出于同样的原因使用 `http://`。 接下来是 Qualcomm AI Runtime（QAIRT），它包含与 Hexagon NPU 通信的 QNN 库： ```bash theme={null} theme={null} sudo apt-get install -y qairt-libs qairt-tools qairt-headers ``` `ppa:ubuntu-qcom-iot/qcom-ppa` **在 IQ-9075 出厂镜像中已存在**，因此不需要添加。重复添加会产生致命错误 `E: Conflicting values set for option Trusted`。如果遇到这个问题，请列出 `/etc/apt/sources.list.d/` 并删除重复项。 确认 NPU 可访问且 Hexagon 架构正确。IQ-9075 是 **v73**： ```bash theme={null} theme={null} ls /dev/fastrpc-cdsp /dev/fastrpc-cdsp1 ls /usr/lib/libQnnHtpV73Stub.so ``` **预期输出：** ``` /dev/fastrpc-cdsp /dev/fastrpc-cdsp1 /usr/lib/libQnnHtpV73Stub.so ``` 注意有**两个** CDSP 设备节点。先记住这一点——它稍后会成为整个故事的核心。 推理以普通用户身份即可运行；不需要 root。如果在 `/dev/fastrpc-cdsp` 上遇到权限错误，用 `sudo usermod -aG fastrpc $(id -un)` 把自己加入 `fastrpc` 组，然后注销再登录。 ## 2. 无需 AI Hub 账户获取 Pi0.5 只有当你要把*自己的*模型带上 NPU 时，才需要 AI Hub 中按用户分配的云端编译任务。对于已发布的模型则不需要：**Qualcomm** 为其众多芯片预编译了 **QNN 上下文二进制文件（context binary）**，并通过 [AI Hub Models](https://aihub.qualcomm.com/models) 提供，任何人无需账户即可下载。`qualcomm-qcs9075`——即 IQ-9075 EVK——正是 Pi0.5 的 `default_device`，所以获取模型只是一次普通的 HTTPS 下载： ```bash theme={null} theme={null} pip install --user qai-hub-models cd $WORK qai-hub-models fetch Pi0.5 --runtime qnn_context_binary --precision mixed --chipset qualcomm-qcs9075 export BUNDLE=$WORK/pi05-qnn_context_binary-mixed-qualcomm_qcs9075 ls -l $BUNDLE ``` **预期输出**——四个 `.bin` 文件和一个元数据文件，总计 2.9 GB： ``` action_expert.bin 439205888 backbone.bin 979836928 metadata.json 25536 token_emb.bin 1055449088 vision_encoder.bin 540233728 ``` **Pi0.5 不是一个模型——而是四个。** 这决定了后面的一切： | 组件 | MiB | 作用 | | -------------------- | ---: | -------------------------- | | `vision_encoder.bin` | 515 | 将一张相机图像转换为 256 个嵌入 token | | `token_emb.bin` | 1007 | 嵌入语言 token，构建注意力掩码和 RoPE 表 | | `backbone.bin` | 934 | 语言模型 prefill；输出 18 层 KV 缓存 | | `action_expert.bin` | 419 | 将带噪声的动作块去噪为真实动作块 | 量化是混合的：backbone 为 w4a16，视觉编码器和动作专家为 w8a16。 该模型包记录了 `SDK build=v2.45.0.260326154327`。它可以在 apt 提供的 QAIRT **2.46.0** 上原样运行，因此不需要精确匹配 SDK 版本。 ## 3. 在 NPU 上运行模型的第一个部分 在写任何代码之前，先用 `qairt-tools` 附带的 `qnn-net-run` 证明硬件能正常工作。 视觉编码器接受一张 RGB 图像，224×224，通道优先，float32，归一化到 \[-1, 1]。生成一张： ```bash theme={null} theme={null} mkdir -p $WORK/run && cd $WORK/run python3 -c " import numpy as np np.random.seed(0) np.random.uniform(-1, 1, (1, 3, 224, 224)).astype('float32').tofile('image.raw') open('input_list.txt', 'w').write('image:=image.raw\n') " qnn-net-run --backend /usr/lib/libQnnHtp.so \ --retrieve_context $BUNDLE/vision_encoder.bin \ --input_list input_list.txt --output_dir out ``` **预期输出**以以下内容结尾： ``` Executing Graphs Finished Executing Graphs ``` 你就得到了一个真实的张量： ```bash theme={null} theme={null} ls -l out/Result_0/img_embed.raw ``` **预期输出：** `2097152` 字节——正好是 `1 × 256 × 2048` 个 float32 值。 ## 4. 弄清你实际需要连接什么 现在你有四个模型，却不知道它们如何连接。不要猜，也不要相信 `metadata.json` 的键顺序——直接问二进制文件本身。`qnn-context-binary-utility` 会转储上下文二进制文件声明的输入和输出，**且顺序正是编译后的图所期望的**： ```bash theme={null} theme={null} cd $WORK/run for m in vision_encoder token_emb backbone action_expert; do qnn-context-binary-utility --context_binary=$BUNDLE/$m.bin --json_file=$m.json >/dev/null 2>&1 done ``` 然后打印图的顺序： ```bash theme={null} theme={null} python3 - <<'PY' import json for m in ("vision_encoder", "token_emb", "backbone", "action_expert"): info = json.load(open(f"{m}.json"))["info"]["graphs"][0]["info"] print(f"\n=== {m} ===") for kind in ("graphInputs", "graphOutputs"): names = [t["info"]["name"] for t in info.get(kind) or []] print(f" {kind} ({len(names)}):") print(" ", ", ".join(names)) PY ``` **预期输出**（节选——`action_expert` 有 41 个输入）： ``` === vision_encoder === graphInputs (1): image graphOutputs (1): img_embed === token_emb === graphInputs (5): lang_tokens, img_embed1, img_embed2, img_embed3, lang_mask graphOutputs (7): prefix_emb, prefix_att_2d, prefix_sin, prefix_cos, suffix_sin, suffix_cos, full_att_4d === backbone === graphInputs (4): prefix_att_2d_masks, hidden_state, rope_emb_cos, rope_emb_sin graphOutputs (36): k_cache_l0, k_cache_l1, ... k_cache_l17, v_cache_l0, ... v_cache_l17 === action_expert === graphInputs (41): x_t, time_step, key_cache_l0, key_cache_l1, key_cache_l10, key_cache_l11, ... key_cache_l17, key_cache_l2, ... key_cache_l9, value_cache_l0, ..., rope_emb_cos, rope_emb_sin, full_att_4d graphOutputs (1): action_emb ``` **请再读一遍 `action_expert` 的输入顺序。** 它是 `l0, l1, l10, l11 … l17, l2, l3 … l9`——按字符串排序，而不是数字排序。产出这些缓存的 `backbone` 是按 `l0, l1, l2 … l17` 输出的。如果按生产者顺序连接，你就悄无声息地打乱了 18 层中的 12 层。没有任何报错。模型照常运行。输出的动作是垃圾。 这就是为什么要从二进制文件生成顺序，而不是手动敲出来。 ## 流水线如何组合 ```mermaid theme={null} theme={null} flowchart LR IMG["3 × camera
224×224"] --> VE["vision_encoder
×3"] VE -->|"img_embed1..3"| TE["token_emb"] TOK["lang_tokens
(task + state)"] --> TE TE -->|"prefix_emb"| BB["backbone"] BB -->|"18-layer KV cache"| AE["action_expert
×10 denoise"] TE -->|"full_att_4d,
suffix_sin/cos"| AE AE --> OUT["50 × 32
action chunk"] classDef hero fill:#31017D,stroke:#31017D,color:#fff,stroke-width:1.5px; classDef pkg fill:#F4EFFA,stroke:#31017D,color:#31017D,stroke-width:1.5px; class VE,TE,BB,AE hero; class IMG,TOK,OUT pkg; ``` 一个动作块需要 **15 次 NPU 调用**：三次视觉推理（每个相机槽位一次）、一次 token 嵌入、一次 backbone prefill，然后是经过动作专家的十次去噪步骤。值得记住的常量： | 常量 | 值 | 来源 | | --------- | ------- | ----------------------------------------- | | 相机 | 3 | 2 个真实相机 + 1 个 `empty_cameras` 槽位；未使用的槽位填零 | | 语言 token | 200 | 用 id 0 右侧填充 | | `src_len` | 968 | `256 × 3 个相机 + 200 个 token` | | 动作块 | 50 × 32 | 32 是最大动作维度；真实自由度是前缀（Franka 为 7） | | 去噪步数 | 10 | 策略配置中的 `num_inference_steps` | 除了顺序陷阱外还有两处重命名要注意：`token_emb` 输出 `prefix_emb`，但 `backbone` 称之为 `hidden_state`；`prefix_att_2d` 变成了 `prefix_att_2d_masks`。`suffix_sin`/`suffix_cos` 到达动作专家时叫 `rope_emb_sin`/`rope_emb_cos`。 ## 机器人的状态去了哪里 这四个图中任何地方都没有状态输入张量。Pi0.5 将本体感觉离散化为 256 个桶，并将其拼接进**语言提示词**。以下格式复现自上游 [openpi](https://github.com/Physical-Intelligence/openpi) 实现： ```python theme={null} theme={null} cleaned = prompt.strip().replace("_", " ").replace("\n", " ") discretized = np.digitize(state, np.linspace(-1, 1, 257)[:-1]) - 1 full = f"Task: {cleaned}, State: {' '.join(map(str, discretized))};\nAction: " tokens = tokenizer.encode(full, add_bos=True) # right-pad with 0 to 200 ``` 因此提示词——进而 token id——在**每个控制步**都会变化。你无法预计算一张分词后指令的查找表并在闭环中使用；分词器必须内联运行。 分词器是标准的 PaliGemma SentencePiece 模型。Hugging Face 上的 `google/paligemma-3b-pt-224` 是受限的（未接受许可证时返回 HTTP 401），但完全相同的文件可以从 Google 的 `big_vision` 存储桶免认证获取——openpi 也是从那里获取的： ```bash theme={null} theme={null} cd $WORK curl -fSL -o paligemma_tokenizer.model \ https://storage.googleapis.com/big_vision/paligemma_tokenizer.model sha256sum paligemma_tokenizer.model ``` **预期输出：** `8986bb4f423f07f8c7f70d0dbe3526fb2316056c17bae71b1ea975e77a168fc6`。 为某个任务生成 token id，并把状态向量折叠进去： ```bash theme={null} theme={null} pip install --user sentencepiece cd $WORK/run python3 - <<'PY' import numpy as np, sentencepiece as spm sp = spm.SentencePieceProcessor(model_file="../paligemma_tokenizer.model") state = np.array([0.1, -0.2, 0.3, 0.0, 0.5, -0.9, 0.25, 0.0], dtype=np.float32) bins = np.digitize(state, np.linspace(-1, 1, 257)[:-1]) - 1 prompt = f"Task: pick up the black bowl, State: {' '.join(map(str, bins))};\nAction: " ids = sp.encode(prompt, add_bos=True) print(f"{len(ids)} tokens:", ids[:12], "...") tokens = np.zeros(200, dtype=np.int32); tokens[:len(ids)] = ids mask = np.zeros(200, dtype=np.float32); mask[:len(ids)] = 1.0 tokens.tofile("lang_tokens.raw"); mask.tofile("lang_mask.raw") PY ``` **预期输出：** ``` 47 tokens: [2, 7071, 235292, 4788, 908, 573, 2656, 14581, 235269, 3040, 235292, 235248] ... ``` 如果把这些输入喂给 `qnn-net-run`，你**必须**传入 `--use_native_input_files`。默认情况下它把每个输入文件当作 float32 解析再转换为图的数据类型。对于 int32 的 `lang_tokens`，这会把真实的 token id 变成零——即全是填充——模型随后就在悄无声息地对空内容做条件推理。症状很隐蔽：只有对应真实语言 token 的行的输出不同，其值等于填充嵌入。 ## 5. 从你自己的代码运行模型 `qnn-net-run` 是一个测试工具；它读文件、写文件。要串联四个模型，你需要把它们放进同一个进程。完成这件事的 QRB ROS 软件包是 `qrb_inference_manager`，它的整个 API 只有三个调用。 安装它以及封装它的 ROS 节点： ```bash theme={null} theme={null} sudo add-apt-repository -y ppa:ubuntu-qcom-iot/qirp sudo apt-get update sudo apt-get install -y ros-jazzy-qrb-ros-nn-inference libsentencepiece-dev ``` **apt 版本无法运行这个模型。** apt 中的 `ros-jazzy-qrb-inference-manager` 是 1.1.1；上游是 2.2.0。1.1.1 版本拒绝 **int32** 张量输入，而这恰恰是 `token_emb` 的 `lang_tokens` 所需要的。我们在这里安装它是为了获取头文件并了解 API，然后在第 8 步从源码构建——那一步无论如何都需要。 将以下文件写为 `$WORK/minimal_npu.cpp`。这就是完整的程序： ```cpp theme={null} theme={null} // The entire QRB ROS NPU API: construct, execute, read. #include #include #include #include #include #include "qrb_inference_manager.hpp" int main(int argc, char ** argv) { if (argc < 2) { std::fprintf(stderr, "usage: minimal_npu \n"); return 2; } // vision_encoder wants one RGB image, 224x224, CHW, float32, in [-1, 1]. constexpr int kElems = 3 * 224 * 224; std::vector image(kElems, 0.5F); // flat grey is enough to prove it runs std::vector input(image.size() * sizeof(float)); std::memcpy(input.data(), image.data(), input.size()); // 1. load onto the NPU. "libQnnHtp.so" is what selects the Hexagon. qrb::inference_mgr::QrbInferenceManager mgr(argv[1], "libQnnHtp.so"); // 2. run it. inference_execute() takes ONE flat buffer and slices it across // the graph's inputs in compiled graph order. if (!mgr.inference_execute(input)) { std::fprintf(stderr, "execute failed\n"); return 1; } // 3. read the results back. for (const auto & t : mgr.get_output_tensors()) { std::printf("%s: %zu bytes, shape [", t.output_tensor_name.c_str(), t.output_tensor_data.size()); for (size_t i = 0; i < t.output_tensor_shape.size(); ++i) std::printf("%s%u", i ? ", " : "", t.output_tensor_shape[i]); const auto * v = reinterpret_cast(t.output_tensor_data.data()); std::printf("] first values: %.4f %.4f %.4f\n", v[0], v[1], v[2]); } return 0; } ``` 构建并运行它——一行 `g++`，不需要 CMake： ```bash theme={null} theme={null} cd $WORK g++ -std=c++17 -O2 -I/opt/ros/jazzy/include minimal_npu.cpp \ -L/opt/ros/jazzy/lib -lqrb_inference_manager \ -Wl,-rpath,/opt/ros/jazzy/lib -o minimal_npu QNN_HTP_BURST=1 ./minimal_npu $BUNDLE/vision_encoder.bin ``` **预期输出：** ``` img_embed: 2097152 bytes, shape [1, 256, 2048] first values: 6.9219 -0.7668 -0.6043 ``` 三个 API 调用就把一个 30 亿参数模型的视觉编码器放上了 NPU。没有会话设置，没有 delegate 注册，没有图构建器，也不用写任何设备管理代码。 `QNN_HTP_BURST=1` 将 HTP 锁定在 TURBO 性能级别。没有它，NPU 会以默认的 DCVS 设置运行，每个阶段都会明显变慢。它在上下文创建时读取，所以必须在进程启动前就存在于环境变量中。 ## 6. 串联四个模型 这部分需要你自己编写，而且大多是记账式的工作。它的形态如下： ```cpp theme={null} theme={null} // Per action chunk, in order: // // 1. for cam in 0..2: vision_encoder(image[cam]) -> img_embed[cam] // (zero-fill any camera slot you do not have; the graph arity is fixed at 3) // // 2. token_emb(lang_tokens, img_embed[0..2], lang_mask) // -> prefix_emb, prefix_att_2d, prefix_sin, prefix_cos, // suffix_sin, suffix_cos, full_att_4d // // 3. backbone(prefix_att_2d -> prefix_att_2d_masks, // prefix_emb -> hidden_state, // prefix_cos -> rope_emb_cos, // prefix_sin -> rope_emb_sin) // -> k_cache_l0..17, v_cache_l0..17 (each [1, 968, 1, 256]) // // 4. x_t = gaussian noise, shape [1, 50, 32]; t = 1.0; dt = -1.0 / 10 // repeat 10 times: // action_expert(x_t, t, // k_cache_l* -> key_cache_l* IN LEXICOGRAPHIC ORDER, // v_cache_l* -> value_cache_l* IN LEXICOGRAPHIC ORDER, // suffix_cos -> rope_emb_cos, // suffix_sin -> rope_emb_sin, // full_att_4d -> full_att_4d) // -> action_emb // already the Euler-updated x_{t+dt} // x_t = action_emb; t += dt // // 5. x_t is your action chunk: 50 timesteps x 32 dims. The real degrees of // freedom are the first `action_dof` columns (7 for a Franka Panda); // everything after that is padding and must be ignored. ``` 两条能实实在在省时间的实现笔记： * **在十次去噪步骤中，除 `x_t` 和 `time_step` 外一切都是常量。** 把约 34 MB 的 KV 缓存一次性打包进专家的输入缓冲区，之后每步只重写 6404 字节。 * **专家直接返回 `x_{t+dt}`。** 它在内部完成 Euler 更新，因此主机端不需要 `x += dt * v`。 按第 4 步转储出的图顺序拼接张量，为每个阶段构建扁平输入缓冲区——这是 `inference_execute()` 强制执行的契约，如果总大小不对它会告诉你： ``` Total size of all input tensors should be 35945556 bytes, but receive 35945552 bytes ``` ## 7. 撞上墙：一个 NPU 装不下 Pi0.5 当四个上下文都在一个进程中构建时，你会得到这个： ```text theme={null} theme={null} fastrpc memory map for fd: 39 with length: 434110464 failed with error: 0x1 SharedMemoryMod failed to Map Buffer to SMMU for domain 0 Failed to map weights buffer to device! Failed to initialize graph with id 256 context 4 deviceId 0 ... with err 1002 ``` 四个二进制文件共有 **2875 MiB** 权重。这是 **DSP 地址空间，不是主机内存**——在系统内存还有 34 GB 空闲、以 root 身份运行时它照样失败，而每个二进制文件单独加载都完全正常。在设备 0 上的实测： | 峰值并发映射权重 | 结果 | | -------------: | ---------------------- | | 1523 MiB | 正常 | | 1941 MiB | `Failed to map buffer` | | 2875 MiB（全部四个） | 硬性失败 | 它也不是一个干净的容量上限：反复的 map/unmap 会使地址空间碎片化，因此相同的总量会因进程之前做过什么而时而成功、时而失败。 **权重映射失败的上下文仍然会报告成功。** 日志里能看到 `Initialize Qnn graph from binary file successfully`，而它返回的句柄会产生长度错误的输出向量——这在很久之后才在你自己的代码中以内存错误的形式显现。要防御它：把你得到的输出张量数量与第 4 步中图声明的数量对比，任何不匹配都按硬错误处理。 明显的临时方案是在每次使用前后创建和销毁上下文。它能用，但很慢——权重加载占大头： | 配置 | ms/块 | 其中权重换页 | | ----------------------- | ---: | -----: | | 每个上下文换入换出 | 4421 | \~3245 | | 仅保留 `vision_encoder` 常驻 | 3277 | \~2258 | 你三分之二的时间不是花在计算上。 ## 8. 解锁第二个 NPU 还记得第 1 步的两个设备节点吗。问题是 QNN 是否允许你*指定*它们。直接问它——编写 `$WORK/devices.cpp`： ```cpp theme={null} theme={null} #include #include #include #include "QnnDevice.h" #include "QnnInterface.h" int main() { void * lib = dlopen("libQnnHtp.so", RTLD_NOW); auto get = reinterpret_cast( dlsym(lib, "QnnInterface_getProviders")); const QnnInterface_t ** providers = nullptr; uint32_t n = 0; get(&providers, &n); const auto & api = providers[0]->QNN_INTERFACE_VER_NAME; const QnnDevice_PlatformInfo_t * info = nullptr; api.deviceGetPlatformInfo(nullptr, &info); std::printf("hardware devices: %u\n", info->v1.numHwDevices); for (uint32_t i = 0; i < info->v1.numHwDevices; ++i) std::printf(" device[%u] id=%u numCores=%u\n", i, info->v1.hwDevices[i].v1.deviceId, info->v1.hwDevices[i].v1.numCores); api.deviceFreePlatformInfo(nullptr, info); return 0; } ``` ```bash theme={null} theme={null} cd $WORK g++ -std=c++17 -O2 -I/usr/include/QNN devices.cpp -ldl -o devices && ./devices ``` **预期输出：** ``` hardware devices: 2 device[0] id=0 numCores=1 device[1] id=1 numCores=1 ``` **两个可寻址的 HTP 设备，各自拥有独立的映射预算。** 把四个上下文分布到两个设备上，它们就都能保持常驻——换页问题彻底消失。 有一个障碍：`qrb_inference_manager` 调用的是 `deviceCreate(nullptr, nullptr, …)`，总是落在设备 0 上。选择设备意味着传给它一个单条目的 `QnnDevice_PlatformInfo_t`。从源码构建该库并加入这一功能： ```bash theme={null} theme={null} mkdir -p $WORK/ws/src && cd $WORK/ws/src git clone https://github.com/qualcomm-qrb-ros/qrb_ros_nn_inference.git ``` 无论如何都需要从源码构建——它带来了 int32 支持（`token_emb`）、多输入张量和 HTP burst 模式，这些都不在 apt 的 1.1.1 版本中。 在 `qrb_ros_nn_inference/qrb_inference_manager/src/qnn_inference/qnn_inference.cpp` 中找到 `create_device()`，将 `deviceCreate` 调用替换为： ```cpp theme={null} theme={null} // Scope this device handle -- and therefore every context created from it -- to // one HTP core. device_id_ is a new member, plumbed in from the constructor. QnnDevice_CoreInfo_t core = QNN_DEVICE_CORE_INFO_INIT; QnnDevice_HardwareDeviceInfo_t hw = QNN_DEVICE_HARDWARE_DEVICE_INFO_INIT; QnnDevice_PlatformInfo_t platform = QNN_DEVICE_PLATFORM_INFO_INIT; QnnDevice_Config_t cfg = QNN_DEVICE_CONFIG_INIT; const QnnDevice_Config_t * cfgs[] = { &cfg, nullptr }; const QnnDevice_Config_t ** configs = nullptr; if (device_id_ != 0) { core.v1.coreId = 0; core.v1.coreType = 0; hw.v1.deviceId = device_id_; hw.v1.deviceType = 0; // QNN_HTP_DEVICE_TYPE_ON_CHIP hw.v1.numCores = 1; hw.v1.cores = &core; platform.v1.numHwDevices = 1; platform.v1.hwDevices = &hw; cfg.option = QNN_DEVICE_CONFIG_OPTION_PLATFORM_INFO; cfg.hardwareInfo = &platform; configs = cfgs; // nullptr keeps upstream behaviour: device 0 } auto qnn_status = qnn_interface_->interface_.deviceCreate(nullptr, configs, &(device_handle_)); ``` 在 `QnnInference` 和 `QrbInferenceManager` 上都添加一个 `const uint32_t device_id_ = 0;` 成员和一个 `device_id` 构造函数参数，然后构建： ```bash theme={null} theme={null} cd $WORK/ws source /opt/ros/jazzy/setup.bash colcon build --packages-select qrb_inference_manager --cmake-args -DCMAKE_BUILD_TYPE=Release ``` **`OutputTensor` 在 apt 1.1.1 与上游之间存在 ABI 破坏。** 上游添加了四个 DMA-buf 字段，改变了 `sizeof(OutputTensor)`。任何用 apt 头文件编译却链接到重新构建的库的代码，会以错误的步长读取 `std::vector` 并在 `std::bad_array_new_length` 中崩溃。你的 overlay 的 include 路径必须排在 `/opt/ros/jazzy/include` **之前**，且依赖代码需要完整重新编译而不是仅重新链接。 现在用显式的设备 id 构造四个管理器中的每一个，并让四个都保持常驻。 ## 我们为什么这样拆分 两个 NPU 都可用后，分配四个模型有多种方式。最直观的是按大小平衡——每个设备放约 1.4 GB。这并不是最优答案。