X5支持transformer大模型嘛

开发与问题 无人机开发与应用
,
1

X5支持transformer大模型嘛 ？？？

2

要分两种“Transformer”看：

1）Transformer 结构的视觉/感知模型（ViT、Swin、DETR、BEV 等）：支持。 X5 是 Sunrise 5、10 TOPS，官方规格里明确写了支持 Transformer、RWKV、Occupancy 等复杂模型（技术规格）。实际落地路径是把浮点模型用 OE-X5 工具链量化编译成 .hbm，再用 bpu_infer_lib 或 TROS 推理。具体算子能不能上 BPU、有什么 shape 约束，查工具链算子支持约束列表；不满足约束的算子会落到 CPU，速度要按你的模型实测。

2）语言大模型（Qwen、ChatGLM 这类几 B 参数对话模型）：不能按“支持”理解。 官方手册里能查到的端侧 LLM 示例是 Bloom 大语言模型，运行在 CPU 上、1.4B 参数，且只标注支持 X3 4GB；我没有检索到 X5 的板端 LLM 部署示例。X5 是 4GB/8GB 内存，几 B 参数模型在内存和算力上都很难实用，常见做法是语音/文本走云端或局域网 API，板端只做唤醒、ASR、TTS 和业务逻辑。

你具体想跑哪个模型（视觉 Transformer，还是本地对话大模型）？X5 是 4GB 还是 8GB？这两点定了我再给对应的转换或接入步骤。

3

8G qwen3 0.6B CLIP-ViT-B/32

4

8G 跑 Qwen3-0.6B + CLIP-ViT-B/32，两条路子完全不同：语言模型在 CPU 上跑 GGUF，视觉塔走 BPU。

1）Qwen3-0.6B：CPU/GGUF，不经 BPU
官方 LLM 工具链只有 S100/S600 系列，X5 没有 BPU 上的 LLM 流程。但 X5 平台（MagicBox）有板端 LLM 落地示例：语音交互 用的就是 Qwen2.5-1.5B-Instruct 的 GGUF（q5_k_m），默认把模型放 /dev/shm 以缩短启动初始化，功能包见 magicbox_qwen_llm。也就是说 X5 靠 CPU 跑“小参数中文 LLM”是官方验证过的路线，0.6B 比 1.5B 更轻。

  • 内存：0.6B 按 Q4/Q5 量化权重约 0.4–0.6GB 量级（估算，取决于量化档位），8G 放模型 + KV cache + 系统余量够用。
  • 速度：由 CPU 决定，官方没有 X5 上 Qwen3-0.6B 的 TPS 公开数据，别按 S100 的 benchmark 推算，必须实测。0.6B 适合指令解析、结构化输出、短问答；长上下文多轮对话体验会明显下降。

2）CLIP-ViT-B/32：视觉塔上 BPU，文本塔留 CPU
ViT-B/32 图像塔约 88M 参数、输入 224×224，走标准流程：ONNX → hb_mapper 量化编译成 .hbm → hobot_dnn/bpu_infer_lib 推理，参考 OE-X5 模型量化与编译。ViT 的 attention、GELU 等算子要先对 工具链算子支持约束列表，不满足约束的部分会落到 CPU，实际帧率以你的模型实测为准。文本塔很小，建议 CPU 跑或文本特征离线预计算，只做余弦相似度，没必要折腾上板。

3）两个一起跑要注意
Qwen 在 CPU 上生成时会吃满 CPU，CLIP 的前后处理（resize、归一化）也在 CPU，同时跑容易互相拖慢。若做图搜/图文匹配，建议图像特征入库离线做，板端只跑图像塔 + 检索。

一个关键确认：你的板子用的是 MagicBox 那套软件栈，还是普通 X5 系统？前者可以直接复用 qwen_llm 包的 launch 和音频链路；后者需要自己按 GGUF 推理后端搭一个服务。

5

我想自己编译，自己部署

6

X5的话，一般只能把视觉部分放到BPU上。然后有关语言推理的部分还是得用CPU来跑。

7

yaml咋配有教程嘛 ，我看说是能跑小模型的

8

attention 是在bpu嘛

9

可以用下这个

10

@瓜仔 可以提供几个TROS里面X5跑视觉语言大模型的案例。

11

要分开看：视觉塔的 attention 有机会上 BPU，语言模型的 attention 不在 BPU。

CLIP-ViT-B/32 的 attention（MatMul → 缩放 → Softmax → MatMul）

  • MatMul：BPU 加速，约束是最低两维 M、K ∈ [1, 8192]，更高维 ∈ [1, 4096]。ViT 的 QKᵀ 是 [B, heads, N, N]，head 数或 token 数超出这个范围就会退回 CPU。
  • Softmax：默认跑在 CPU。只有 onnx::softmax 输入为四维且 axis=3、或 pytorch::softmax 输入四维且 axis=1/2/3 时，才能用 run_on_bpu 指定到 BPU；不满足就被切出去，模型变成 BPU/CPU 来回跳的子图，耗时主要损失在这里。
  • 这版算子表基于 opset10/11，LayerNormalization 没有单列，实际会被拆成 ReduceMean/Sub/Pow/Sqrt/Div，这些都在 BPU 表内，但 ReduceMean 要求只指定一个 axis 且 keepdims=1。另外 Einsum 标为暂未集成，导出 attention 时不要用 einsum 写法。

以上逐条见 X5 支持的 ONNX 算子列表，更新的约束表在 OE-X5 工具链算子支持约束列表。

Qwen3-0.6B 的 attention：走 GGUF + CPU 后端，整段都在 CPU，X5 没有 BPU 上的 LLM 执行流程。

确认到底哪段在 BPU（别靠猜）

  1. 转换阶段看 hb_mapper makertbin 日志里算子/子图回退到 CPU 的告警，那是第一手依据。
  2. 板上实测节点归属：
hrt_model_exec perf --model_file=xxx.hbm --thread_num=1 --profile_path="."

生成的 profiler.csv 里有 BPU_NodeName、CPUNodeType_NodeName 和 BPU_inference_time_cost / CPU_inference_time_cost，能直接看出 Softmax 是否被留在 CPU。用法见 hrt_model_exec 工具介绍。

12

这对么 ，你给我个skill我咋弄 。。。。

13

对，但别把它当成板子上的工具：oe-skills-x5 是给 AI 编码助手（Claude Code、Cursor 这类）用的“技能包”，内容是流程说明＋脚本，让 agent 按 X5 官方流程去串 hb_mapper 转换、上板验证。它不自带模型，也不替你编译。所以你“拿到一个 skill 不知道咋弄”是正常的——落点在你开发机的项目目录里，跟板子无关。

两条路选一条：

A. 你就想自己编译部署（你之前说的）→ skill 可以完全不用

# 1) 先查模型能否转换
hb_mapper checker --model-type onnx --march bayes-e
# 2) 按 yaml 转换，产物是 X5(bayes-e) 的 .bin
hb_mapper makertbin --config xxx.yaml --model-type onnx

yaml 每个字段（model_parameters/input_parameters/calibration_parameters/compiler_parameters 四组，含必选与默认值）见 6.2.2.2 模型编译命令 hb_mapper makertbin，量化全流程见模型量化与编译。上板跑 .bin 用 hrt_model_exec，用法在工具介绍。

B. 想在 agent 里用这个包 → 必须先装 installer，且要有项目目录和 npx 环境

npx skills add d-robotics/rdk-skills --skill rdk-pack-installer

然后在你的项目根目录让 agent 安装 OE Tool Chain (X5) 包（ref v1.1.1，跑包内 setup.sh）。装完自查这几项存在：.drobotics-x5/VERSION、.drobotics-x5/skill-index.json、.drobotics-x5/skills/x5-router/SKILL.md。装好后它是整包进项目，不能把单个 skill 拷到全局目录。包内分 x5-ptq-deploy（ONNX→.bin）、x5-runtime-deploy（上板 hrt_model_exec）、x5-accuracy-diagnostics（精度掉点）、x5-environment-setup（工具链环境）。

关键一点：B 只是把流程交给 agent 编排，CLIP 图像塔的 ONNX 和校准图还得你自己准备——这块和 A 一样。

确认一下：你走 A 的话，CLIP 图像塔是不是已经单独导出成 ONNX、输入固定 224×224？是的话我按你的实际输入名直接给你一份改好就能跑的 yaml；走 B 的话告诉我你用的是哪个 agent 工具、开发机上有没有 node/npx。

14

不用先装 skill。Qwen3-0.6B 在 X5 上可先走 CPU 的 llama.cpp/GGUF 路线，不用配 hb_mapper YAML；用 b5092 或更新版本编译后，运行 ./build/bin/llama-cli -hf Qwen/Qwen3-0.6B-GGUF:Q8_0 -ngl 0 -c 2048。

CLIP 官方示例是图像编码器走 BPU、文本编码器走 CPU，但当前这份示例没有附自编译的导出脚本和 YAML，不能当成现成转换教程。Attention 是否落到 BPU 要看具体模型的编译报告，不能按“用了 Transformer”一概判断。

Qwen 编译教程：https://qwen.readthedocs.io/en/latest/run_locally/llama.cpp.html

CLIP 示例说明：https://github.com/D-Robotics/rdk_model_zoo/tree/main/samples/vision/clip/conversion

15

你是真人嘛 ？？？

16

是的 论坛侧技术支持主要依据已有资料和情况分析和大模型辅助解答 如果需要更深入的解答 可以联系dgp计划或者向我们更专业的技术人员反馈 论坛侧可以对接更专业的技术人员

17

2026-10-30 09:12:16,014 INFO Start hb_mapper…
2026-10-30 09:12:16,014 INFO hbdk version 3.49.15
2026-10-30 09:12:16,014 INFO horizon_nn version 1.1.0
2026-10-30 09:12:16,014 INFO hb_mapper version 1.24.3
2026-10-30 09:12:16,806 INFO Model type: onnx
2026-10-30 09:12:16,806 INFO input names
2026-10-30 09:12:16,806 INFO input shapes {}
2026-10-30 09:12:16,806 INFO Begin model checking…
2026-10-30 09:12:16,817 INFO Start to Horizon NN Model Convert.
2026-10-30 09:12:17,612 INFO Loading horizon_nn debug methods:set()
2026-10-30 09:12:17,612 INFO The activation calibration parameters:
calibration_type: fixed
2026-10-30 09:12:17,612 INFO The specified model compilation architecture: bayes-e.
2026-10-30 09:12:17,612 INFO The specified model compilation optimization parameters: .
2026-10-30 09:12:17,612 INFO Start to prepare the onnx model.
2026-10-30 09:12:17,685 INFO Input ONNX Model Information:
ONNX IR version: 9
Opset version: [‘ai.onnx v11’, ‘horizon v1’]
Producer: pytorch v2.11.0+cu130
Domain: None
Version: None
Graph input:
input_ids: shape=[1, 7], dtype=INT64
…ion_mask: shape=[1, 7], dtype=INT64
…l_values: shape=[1, 3, 224, 224], dtype=FLOAT32
Graph output:
…er_image: shape=[1, 1], dtype=FLOAT32
…per_text: shape=[1, 1], dtype=FLOAT32
div_1: shape=[1, 512], dtype=FLOAT32
div: shape=[1, 512], dtype=FLOAT32
…_norm_50: shape=[1, 7, 512], dtype=FLOAT32
index: shape=[1, 512], dtype=FLOAT32
add_24: shape=[1, 50, 768], dtype=FLOAT32
…_norm_25: shape=[1, 768], dtype=FLOAT32
2026-10-30 09:12:20,669 INFO End to prepare the onnx model.
2026-10-30 09:12:21,640 INFO Saving model to: ./.hb_check/original_float_model.onnx.
2026-10-30 09:12:21,640 INFO Start to optimize the onnx model.
2026-10-30 09:12:33,040 ERROR *** ERROR-OCCUR-DURING {horizon_nn.build_onnx} ***, error message: variable logits_per_image already exists in graph outputs.
2026-10-30 09:12:33,070 INFO End to optimize the onnx model.
2026-10-30 09:12:33,070 INFO End to Horizon NN Model Convert.

18

同步提供下你这边的模型信息 和 yaml 配置

当前推荐的量化方案是 使用Agent 搭配 Skills ，很很快获取一个不错的效果

19

clip-vit-b-32_opset11_ir9_shape_single_slim.onnx calibration_parameters:

cal_data_type: ‘’

calibration_type: skip

optimization: run_fast

per_channel: false

preprocess_on: false

run_on_bpu: ‘’

run_on_cpu: ‘’

compiler_parameters:

compile_mode: latency

core_num: 1

debug: true

jobs: 0

max_time_per_fc: 0

optimize_level: O3

input_parameters:

input_layout_rt: NCHW;NCHW;NCHW

input_layout_train: NCHW;NCHW;NCHW

input_name: input_ids;attention_mask;pixel_values

input_shape: 1x7;1x7;1x3x224x224

input_space_and_range: ‘’

input_type_rt: featuremap;featuremap;nv12

input_type_train: featuremap;featuremap;bgr

norm_type: no_preprocess;no_preprocess;no_preprocess

model_parameters:

layer_out_dump: false

march: bayes-e

onnx_model: “/workspace/\u8BC4\u6D4B\u6240\u9700\u6A21\u578B/clip-vit-b-32/clip-vit-b-32_opset11_ir9_shape_single_slim.onnx”

output_model_file_prefix: clip-vit-b-32_opset11_ir9_shape_single_slim

remove_node_type: Quantize;Transpose;Dequantize;Cast;Reshape;Softmax;DequantizeFilter

set_node_data_type: {}

working_dir: “/workspace/\u8BC4\u6D4B\u6240\u9700\u6A21\u578B/clip-vit-b-32/model_output”

20

variable logits_per_image already exists in graph outputs

需要从 onnx 上排查 了 工具链优化 ONNX 模型时，试图在计算图输出中加入一个名为 logits_per_image 的变量，但这个名字已经存在，因此优化失败。

@瓜仔