专栏算法工具链从零接触征程6：我用 Codex + OE-Skills 理清了一条模型部署链

从零接触征程6：我用 Codex + OE-Skills 理清了一条模型部署链

361922026-08-23
34
0

第一次接触征程6开发资料时，我遇到的第一个问题不是代码，而是一堆看起来都很重要、但一开始完全串不起来的名词：

OpenExplorer、HMCT、HBDK、HBM、UCP、PTQ、QAT……它们到底分别负责什么？

单独查一个概念并不难，真正麻烦的是：它们放进一条模型部署链以后，谁在前、谁在后？普通 ONNX 和 PyTorch 又是不是走同一套流程？

正好看到 HorizonRobotics 官方的 OE-Skills 支持 Codex 等 Agent，我就搭了一个项目环境，想先做一件比较基础的事情：

不假装自己已经有征程6开发板，也不假装完整工具链已经跑通，只看看一个第一次接触 J6 的人，能不能借助 OE-Skills 和官方资料把这条部署链真正理清楚。

一、先说实验环境和边界

这次使用的环境是：

  • Windows 11

  • Ubuntu 24.04 WSL2

  • Codex Desktop + Codex CLI

  • HorizonRobotics 官方 OE-Skills 0.2.0

  • 安装 Skills：37 个

  • OE MCP：项目级配置

但目前有两个很重要的限制：

第一，我没有验证可用的完整 OE 安装包；第二，我手上没有 J6/J6E/J6M 开发板。

因此这篇记录的实际内容是：

OE-Skills 安装、Router 路由、OE MCP 官方资料检索，以及征程6模型部署流程的梳理。

后面涉及 PTQ、QAT、HBDK 编译、HBM、UCP 和板端运行时，我会明确区分“官方流程说明”和“本机已经执行”。

不会把“理论上可以做”写成“已经做成功”。

图片预览

图1：Phase 0 环境检查结果。当前环境已经可以开展 OE-Skills / Router / MCP 文档实验，但完整 OE 工具链和 J6 硬件仍未验证。

二、安装 OE-Skills 时先踩了一个 Windows + WSL 的坑

我先按照官方 agent-setup.md 检查安装流程，然后在项目里执行 OE-Skills 提供的 setup.sh。

第一次没有成功。

报错和：

有关。

最后检查下来，原因是仓库在 Windows 环境 checkout 后，setup.sh 使用了 CRLF 行尾。放到 WSL Bash 中执行时，实际读到的参数带上了 \r，于是出现：

一开始我还以为脚本本身出了问题。

确认原因后，我没有修改官方仓库，也没有改全局 Git 设置，只是在执行时临时把脚本从 CRLF 转成 LF，再把同一份脚本交给 Bash 执行，之后安装正常完成。

安装后项目中出现了：

这一版一共安装了 37 个 Skills，同时按照当前官方说明配置了 Router 规则。

这个问题本身不复杂，但对 Windows + WSL 用户还挺典型：shell 脚本突然出现一些奇怪的语法错误时，除了怀疑脚本逻辑，也可以顺手检查一下行尾格式。

三、为什么 OE MCP 没有直接配成全局？

这里我额外做了一件事。

后面我还准备测试：

普通 Codex

和

Codex + OE-Skills + OE MCP

在征程6工具链问题上的差别。

所以如果一开始就把 OE MCP 配进 Codex 用户级全局配置，后面的普通 Codex 对照组也可能偷偷获得地平线资料能力。

于是这次 OE MCP 只放在当前项目的：

实际检查结果是：

  • 当前实验项目可以看到 oe-mcp
  • 另一个空白 baseline 工作区看不到 oe-mcp

  • 用户级 Codex 配置文件前后的 SHA-256 保持不变

这样后面的对照实验至少有一个比较干净的环境基础。

四、装好以后，我先问了五个最基础的问题

我没有一上来就问：

“帮我把这个模型部署到 J6。”

因为这个时候连完整流程都没理解，直接让 Agent 干一条长链路，我自己也很难判断它到底说得对不对。

所以先固定了五个问题：

  1. OpenExplorer 是做什么的？

  2. HMCT、HBDK、UCP 分别负责什么？

  3. 一个普通 ONNX 模型最终如何变成可以在征程6上运行的模型？

  4. PTQ 和 QAT 分别适合什么情况？

  5. 如果没有 J6 开发板，目前究竟可以完成什么？

五个问题都通过 OE-Skills Router 处理，并且实际调用了项目级 OE MCP 检索地平线官方资料。

这一轮最大的收获，就是终于把原来混在一起的几个概念拆开了。

五、普通 ONNX：PTQ 这条链到底怎么走？

如果手里是一个普通浮点 ONNX，并且准备走 PTQ，那么主链路可以先简化成：

这里面三块东西的职责差别其实很明显。

HMCT

HMCT 主要负责普通 ONNX 的模型解析、图优化、校准、PTQ 量化以及相关精度分析。

所以如果已有一个普通 ONNX，需要做 PTQ，前面首先会接触 HMCT。

HBDK

HBDK 位于更后面的编译阶段。

它会继续做定点转换、HBIR 图处理和模型编译等工作，最终可以生成 HBM。

UCP

到了 UCP，已经进入运行时。

它负责真实板端的模型加载、Tensor 和内存管理、cache 同步、推理任务提交、结果获取和资源释放等。

所以这里有一个非常容易混淆的点：

生成 HBM，并不等于“模型已经完成征程6部署”。

HBM 是一个可以继续用于上板的模型产物。

真正的部署闭环还包括 UCP 应用、板端运行、输出验证，以及最终的精度和性能测试。

六、QAT 又是另一条入口

我原来还有一个误解：

HMCT 是不是所有模型量化流程的统一入口？

实际不是。

如果手里有的是 PyTorch 模型、权重以及完整训练链路，并且准备做 QAT，前面的路线主要是 Horizon Plugin：

所以可以把两条路线先记成：

以及：

图片预览

图2：征程6模型部署概念链路。ONNX/PTQ 与 PyTorch/QAT 从不同入口进入工具链，后续汇合到 HBDK、HBM 与 UCP。

对于 PTQ 和 QAT 怎么选，目前我比较认同的理解是：

  • 已经有普通 ONNX，希望快速做评测、选型和原型验证，可以优先考虑 PTQ；

  • PTQ 精度如果已经满足需求，没有必要仅仅因为“QAT 看起来更高级”就强行切换；

  • 如果拥有完整 PyTorch 训练链路、精度要求高，或者是长期量产迭代项目，那么 QAT 更值得投入；

  • 最终还是应该由真实精度、工程周期和训练资源来决定。

在没有真实模型结果以前，也不能简单写成“QAT 一定比 PTQ 好”。

七、普通 ONNX 真正走到 J6，还缺哪些东西？

如果把 PTQ 这条链再展开一点，大概会变成：

这里又有两个比较值得注意的地方。

首先，PTQ 并不是“不需要数据”。

正式 PTQ 仍然需要有代表性的校准数据，而且输入名称、shape、dtype、颜色空间、mean/scale 等预处理最好和原来的浮点模型保持一致。

随机数据可以用于某些转换流程检查，但不能直接拿来证明正式量化精度。

其次，“J6”也不是一个足够具体的配置。

J6E/J6M、J6P、J6B 等目标不同，march 以及其他编译、量化参数也需要跟着具体平台确认。

所以在真实项目里，第一步应该先把目标平台、模型输入输出和数据条件问清楚，而不是拿到一个 ONNX 就直接开始猜参数。

八、没有 J6 开发板，到底还能做到哪一步？

这是我这一轮最关心的问题之一。

整理完官方资料以后，我觉得可以把能力分成三层。

第一层：现在就可以做

不需要 OE 包，也不需要 J6 板卡，例如：

  • 查询官方资料

  • 判断 PTQ / QAT 路线

  • 梳理部署流程

  • 静态审阅 ONNX、PyTorch 和预处理代码

  • 设计校准数据规范

  • 草拟量化、编译和 UCP 方案

  • 制定精度与性能测试计划

本文真正执行的，基本就是这一层。

第二层：需要 OE 包，但原则上不一定需要板卡

如果后面取得匹配版本的 OE 环境，并且具备模型和数据，那么在 x86 开发机侧还可以继续做一些事情：

  • ONNX 模型检查与算子支持分析

  • HMCT PTQ

  • QAT 相关适配和训练

  • HBDK convert / compile

  • quantized.bc 相关验证

  • HBM x86 指令仿真

  • 静态性能分析

  • UCP 源码生成及部分构建准备

但是由于当前我没有验证 OE 包和对应下载权限，所以这些都不能写成“本机已经完成”。

第三层：必须有真实 J6 板卡

例如：

  • 在 BPU 上真正执行 HBM

  • 跑 UCP 板端程序

  • 获取真实板端输出

  • 测量真实 latency / FPS

  • 测 BPU、DDR、内存等资源

  • 验证 CPU fallback 的实际影响

  • 做板端精度闭环

到了这一层以后，才真正开始接触“模型在征程6上跑起来”的结果。

九、一个很容易搞错的细节：hbm_infer 并不是纯 x86 推理

我一开始看到 hbm_infer 这个名字时，很自然地理解成：

拿到一个 HBM 文件以后，可以直接在普通 x86 电脑上执行。

查了官方资料以后才发现不是这样。

hbm_infer 的实际模式更接近：

也就是说，x86 侧负责前后处理、任务发起等工作，真正的 HBM 推理还是由 J6 板端完成。

图片预览

图3：无板环境下的 hbm_infer 与验证边界。hbm_infer 依赖 J6 板端 Server，不能把 x86 指令仿真或静态性能评估当成真实板端推理。

这还要和另外两类能力区分开：

  • HBM 的 x86 指令仿真

  • 开发机侧的静态性能评估

前者可以用于一些数值一致性检查，后者可以做性能预估。

但它们都不能被写成：

“我已经得到了真实征程6板端延时。”

所以：

本地 HBM 仿真成功 ≠ hbm_infer 无板运行成功。

静态性能预估 ≠ J6 实板延时。

这个是这一轮五问里我觉得最有价值的一个小纠偏。

十、OE-Skills 对我真正有用的地方是什么？

做完这一轮以后，我并不觉得 OE-Skills 的价值是：

“装上以后 Codex 就可以自动帮我完成征程6部署。”

至少目前真正体验到的价值，更像是在 Agent 和 OE 工具链之间增加了一层导航。

大概是：

比如：

  • 普通 ONNX PTQ → HMCT

  • PyTorch QAT → Plugin

  • 编译 → HBDK

  • 推理应用 → UCP

对于一个第一次接触 J6 工具链的人来说，这其实已经解决了一个很实际的问题：

我遇到的这个问题，到底应该去哪一套工具、哪一份资料里找答案？

以前面对：

HMCT / Plugin / HBDK / HBM / UCP

首先要做的是把这些缩写一个个搜明白。

现在可以先根据任务把问题路由到对应模块，再去读真正相关的官方资料。

十一、目前做到哪里？

这一轮实际完成了：

  • OE-Skills 0.2.0 项目级安装

  • 37 个 Skills 加载

  • Router 路由验证

  • OE MCP 官方文档检索

  • 5 个基础问题测试

  • PTQ / QAT 两条基本路径梳理

  • HMCT、HBDK、HBM、UCP 职责区分

  • 无 OE、无 J6 板卡条件下的能力边界确认

还没有完成：

  • 真实模型 PTQ / QAT

  • HBDK 编译

  • HBM 生成

  • x86 仿真

  • UCP 构建

  • J6 板端运行

  • 真实精度和性能数据

下一步我准备继续拿一组固定的征程6开发任务测试 OE-Skills Router。

题目会覆盖 PTQ、QAT、HBDK、UCP、静态性能分析、真实板端性能请求，以及一些故意缺少硬件条件的任务。

看看 Router 到底能不能稳定选到正确的 Skill，同时在条件不满足的时候及时停下来，而不是顺着问题继续编一个“已经运行成功”的答案。

如果这部分数据有意思，再继续记录。

参考资料

算法工具链
社区征文征程6
评论0
0/600