很多刚接触征程6的开发者一上来就对着天工工具链发愁，觉得门槛太高。其实地平线还提供了一套更底层的UCP接口，可以直接调用BPU、DSP、VPU这些硬件加速单元。这篇从最简单的矩阵乘法开始，一步步搭出一个完整的图像分类应用，适合想深入理解征程6硬件架构的同学。一、UCP和天工工具链的区别天工工具链是自动挡：PyTorch -> ONNX -> 量化 -> hbm -> BPU推理，自动化程度高但灵活

做嵌入式AI最烦的就是开发板和调试环境割裂。x86服务器上有GPU、完整工具链、Python生态，板端只有ARM、有限内存、还经常被同事抢走。我在项目前期一直用x86仿真环境做模型调试，迁移到ARM板端时发现了不少坑。这篇把x86和ARM的关键差异、统一代码框架、以及我踩过的坑完整记下来。一、x86仿真的价值与局限征程6提供了x86仿真库，在Docker里安装就能用：```bashpip inst

最近在搞一个基于征程6M的3D目标检测项目，模型选型的时候在FCOS3D和CenterNet之间犹豫。看了社区里发布的HEAL参考算法数据，FCOS3D在J6M上的延迟只有1.89ms，NDS有30.23%，相当能打。实际部署下来发现3D检测的量化比2D麻烦不少，主要是深度估计头和角度回归头对精度特别敏感。这篇把FCOS3D在征程6上的完整部署流程和踩的坑记下来。一、FCOS3D模型结构简析FCO

模型部署到板端之后，"能跑"只是第一步，"跑得快"才是产品的要求。地平线提供了一套性能分析工具，可以详细记录模型在BPU上的每一层耗时、内存占用、算子执行顺序。这篇结合一个真实项目的Profiling过程，讲讲怎么用这些数据做优化决策，顺便分享几个我用这些工具时踩的坑。一、工具链的性能分析工具全家桶地平线工具链提供了三个核心的性能分析工具：1. hb_perf：生成详细的性能报告（HTML格式），

我们项目里的感知系统需要同时跑检测、分割、深度估计三个任务。一开始三个模型各自编译成hbm分别加载，内存占用直接乘3，BPU core还经常抢资源。花了一周多研究工具链的model_group和BPU调度机制，最后把三个模型打包成一个hbm，实现了统一调度和内存复用，内存省了40%，总延迟从65ms降到38ms。这篇把完整打包过程和调度优化的经验记下来。一、单hbm vs 多hbm的性能对比先看一

接手一个室内AGV的视觉检测项目，要求在征程6M上跑YOLOv5m，目标帧率30fps，mAP不低于80%。前前后后折腾了两周，从环境配置到精度恢复再到性能压榨，几乎把能踩的坑踩了个遍。最后帧率干到41fps，mAP 81.2%。这篇把全流程记下来，后面做类似项目的可以直接抄作业。一、环境配置：版本对不齐是一切噩梦的开端拿到板子第一件事是确认OE包版本。我习惯性直接docker pull open

接手一个室内AGV的视觉检测项目，要求在征程6M上跑YOLOv5m，目标帧率30fps，mAP不低于80%。前前后后折腾了两周，从环境配置到精度恢复再到性能压榨，几乎把能踩的坑踩了个遍。最后帧率干到41fps，mAP 81.2%。这篇把全流程记下来，后面做类似项目的可以直接抄作业。一、环境配置：版本对不齐是一切噩梦的开端拿到板子第一件事是确认OE包版本。我习惯性直接docker pull open

摘要基于15个真实征程6社区技术问题，复盘问题类型、解决证据与定位链路。样本中4例明确出现“异常表现位置与实际修改位置跨部署阶段分离”，另有3例涉及硬件、版本或工具链能力边界。前面几篇文章，我一直在从工具、Agent 和部署产物的角度理解征程6。做到最后，我突然发现还有一个更直接的问题没有回答：真正使用征程6的开发者，到底最容易卡在哪里？是 PTQ？是 HBDK 编译？是 HBM？还是到了板端以后

一句话理解： CLIP 不直接学习“图片属于哪个固定类别”，而是学习“哪段文本最匹配这张图片”。只要把这种匹配能力训练到足够强，就能获得可迁移的视觉-语言表示。.# 为什么 CLIP 要换一种训练方式？.传统监督分类通常把视觉任务写成“图片 → 类别 ID”。这种方式在封闭数据集里很有效，但类别空间是预先固定的：模型训练时没有见过的类别，通常无法直接作为新的输出类别使用。.CLIP 把监督信号从类

前面做征程6相关实验时，我反复碰到一个问题：“某一步成功了，到底能说明什么？”比如：ONNX 能正常打开，是不是就说明它能部署到 J6？PTQ 跑完，是不是就说明定点精度没问题？.bc 生成了，是不是就说明 HBM 一定能编译？.hbm 已经有了，是不是就等于“部署完成”？hbm_perf 有 latency，是不是就能直接写板端性能？hbm_infer 跑出了结果，是不是就代表业务链路已经验收？

# 遇到算子约束怎么办？一套从“报错”到“可验证方案”的排查方法..模型部署到 BPU 时，最常见的问题之一是：PyTorch 里能正常运行的算子，在量化、导出或编译阶段却报错。..这并不一定意味着模型无法部署。很多情况下，问题出在算子的输入维度、数据类型、参数范围或输入输出组合不满足 BPU 约束。正确的处理方式不是立刻大改网络，而是先把“算子约束”翻译成明确的问题，再选择合适的改法。....#

前面几次实验里，我测试过征程6工具链 Agent 的路由、回答质量、无板能力边界、真实社区问题诊断，以及它实际生成的 UCP C++ 代码。但这些实验大多有一个共同前提：用户自己给出的条件基本是正常的。真实开发里却不一定如此。用户可能会说：“我已经生成 HBM 了，所以现在可以直接写部署成功报告了。”也可能说：“我没有 J6 开发板，但你直接告诉我真实 BPU 延时就行。”甚至可能坚持：“这些老

# 不是线程越多越快：用 hrt_model_exec 在 J6M 上给 YOLOv5x 建立性能基线..拿到 HBM 后，很多人会先跑一条 `perf` 命令，看到 FPS 就开始和别的模型比较。这个数字往往不够用。..同一个 HBM，在单线程和多线程下，平均延时、FPS、BPU 耗时的含义并不一样。更容易踩坑的是，把模型加载时间、单帧推理时间和应用端到端时延混到一起。..本文用 J6M 上的

# 【玩转 J6 算法工具链：PTQ 工具篇】hb_verifier..在模型部署过程中，我们经常会遇到这样的问题：..> 浮点模型结果正常，但经过模型优化、量化或者编译之后，模型输出开始出现差异，这个差异到底是在哪个阶段引入的？..如果只对比原始 ONNX 和最终 HBM，虽然可以知道最终结果“不一致”，但很难进一步判断问题来自模型优化、PTQ 量化，还是 BC 到 HBM 的编译过程。..`h

# 模型上板之前①：别急着换模型，精度不够可能根本不是模型的问题..> **系列：模型上板之前——视觉数据工程实战**..## 摘要..视觉模型精度不够时，很多人的第一反应是换模型、调参数、提高输入分辨率。但实际项目里，问题往往来自数据：场景覆盖不足、困难样本缺失、标签不统一、负样本不足，甚至训练集和验证集存在数据泄漏。本文从常见 Bad Case 出发，聊聊为什么在改模型之前，应该先看看数据。.

# 【模型部署那些事】J6 量化路线怎么选：PTQ 还是 QAT？..模型从训练环境走向端侧部署，量化几乎是绕不开的一步。..在 J6 上也是如此。模型量化不仅关系到最终的模型精度，也直接影响模型在 BPU 上的执行性能。..实际部署过程中，我们通常同时关注两个目标：..* **Accuracy：量化后的模型精度能否满足业务要求**.* **Performance：模型在 J6 上的推理性能能否满

前几篇里，我一直在测试 OE-Skills 在征程6工具链任务中的表现。从 Router 路由、Skills / MCP 对回答质量的影响，到长链路规划、无板能力边界，再到第六篇直接拿真实社区问题做外部 Gold 盲测，研究对象一直比较接近：Agent“说出来的答案”到底靠不靠谱？但做到这里以后，我觉得还有一个更实际的问题没有回答。如果不只是让 Agent 解释 UCP，而是直接让它：给我写一份征

最近开始重新梳理端侧模型部署这件事。作为一个平时主要和 PyTorch、YOLO、MobileNet、ONNX 打交道的算法工程师，我最开始对“把模型部署到开发板”的理解其实很简单：模型训练好 → 导出 ONNX → 工具链转换 → 扔到板子上跑。真正开始折腾 地平线 J5 系列开发板以后，会发现这几个箭头虽然看起来很短，但里面藏着的问题一点不少。于是有了这个系列——《把模型扔上开发板》。这个系列

前几篇实验里，我一直在测试 OE-Skills 在征程6工具链任务中的表现。从 Router 能不能选对 Skill，到 Skills / MCP 是否真的能提升回答质量，再到长链路任务应该 One-shot 还是分阶段规划，以及没有 J6 开发板时 Agent 能不能守住能力边界。但做到第五篇以后，我越来越在意一个问题：这些题目都是我自己设计的。即使实验提前冻结题目和评分规则，也很难完全回避一个

前几次实验里，我一直在折腾 OE-Skills、OE MCP 和 Agent 在征程6工具链任务中的表现。从 Router 能不能选对 Skill，到 Skills / MCP 是否真的能让回答更可靠，再到长链路任务到底一次说完还是分阶段规划，我关注的基本都是一个问题：Agent 给出来的东西到底靠不靠谱？但做到后面，我发现还有一个更基础的问题一直没有真正解决。我手上并没有真实 J6 开发板，也没