Transformer模型在智能驾驶里越来越重要，BEV、端到端、VLA都离不开它。但Transformer里的LayerNorm在征程6上部署是个老大难——算子多、量化敏感、BPU利用率低。最近社区里有人提出用DyT（Dynamic Tanh）替代LayerNorm，号称算子数减半、部署更快。我实际试了试，发现不是简单替换就完事的，精度和性能有 trade-off。这篇把对比实验和踩坑经验记下来

项目初期用YOLOv5x做检测，精度不错（mAP 84.2%），但延迟太高（38ms），帧率只有26fps，不满足产品要求的30fps。单独做量化优化（int8 PTQ）虽然延迟降到了24ms，但精度掉到81.5%。后来尝试把模型剪枝和量化结合起来，先剪枝减少模型参数量，再量化降低精度损失，最终延迟干到18ms（55fps），精度82.7%，只比原始浮点掉1.5%。这篇把联合优化的完整流程和踩坑经

做视觉感知的项目，ISP（Image Signal Processor）的调教质量直接决定了后续AI模型的输入质量。征程6内置了ISP硬件pipeline，支持AE（自动曝光）、AWB（自动白平衡）、LSC（镜头阴影校正）、NR（降噪）等一系列处理。这篇记录我在一个AGV项目上对征程6 ISP做调优的过程，以及图像数据回灌（image data replay）的使用经验。一、征程6 ISP Pip

L2+级智驾系统不能只靠摄像头，毫米波雷达在恶劣天气和测距精度上有不可替代的优势。最近项目里需要在征程6上实现摄像头+毫米波雷达的融合感知，把两个传感器的数据在BPU上统一处理。这篇把融合方案的设计、BPU调度策略、以及踩过的坑完整记下来。一、为什么要做融合？摄像头和毫米波雷达各有优劣：能力 摄像头 毫米波雷达目标分类 强（可以识别行人、车辆、交通标志） 弱（只能区分动静目标）测距精度 中（单目误

最近在一个L2+级智驾项目里负责车道线检测模块的部署，模型选型的时候对比了好几个方案，最后选了GANet。社区里发布的参考算法数据显示GANet在J6M上的延迟只有1.09ms，F1 Score量化后能做到68%，比浮点版本的43.2%还高出一截。实际部署下来发现车道线检测的量化有一些特殊的坑，主要是细长目标对分辨率敏感、以及弯道场景下的拟合精度问题。这篇把GANet在征程6上的完整部署流程和踩坑

做征程6开发，Docker环境是绕不开的。官方提供了带工具链的Docker镜像，但配置过程中踩的坑不少。这篇从镜像拉取、环境配置、常见问题排查到最佳实践，完整记录一下我搭建征程6 Docker开发环境的过程。一、镜像拉取与版本选择地平线官方Docker镜像仓库：```bash# 查看最新可用版本docker pull openexplorer/horizon_j6_open:latest# 或者拉

做智能驾驶，除了视觉感知和路径规划，人机交互也是一个重要方向。这篇记录一下我用征程6开发板 + 手机APP + 语音模块搭建的一个“语音控制小车”多模态交互原型。涉及语音识别、自然语言理解、指令分发、远程通信等多个技术点。一、系统架构手机APP（语音输入） 征程6板端（指令解析）|| CAN/UART↓小车底盘（电机/舵机）手机APP负责语音采集和ASR，把语音转成文本指令后通过WiFi发给征程

上个月和团队参加了“挑战杯”无人清扫车赛题，要求用征程6做视觉感知，实现自动清扫、避障、路径规划。从拿到板子到Demo跑通，前前后后折腾了快一个月。这篇把整个项目的感知链路和控制系统复盘一下。一、硬件配置· 主控：征程6开发板（双核BPU + 4x Cortex-A55）· 相机：USB3.0工业相机，1080p@30fps· 电机驱动：CAN总线连接四路轮毂电机· 超声波：I2C接口，前/后/左

做智能驾驶相关的项目，功能安全是绕不开的门槛。ISO 26262要求ASIL-B级别以上的系统必须做失效模式分析、冗余设计、安全监控。征程6的工具链通过了ASIL-B认证，芯片本身支持双核锁步、ECC内存等安全机制。这篇从一个实际项目出发，讲讲怎么用征程6搭一个满足ASIL-B要求的最小AI应用框架。一、功能安全的风险点对于AI应用，主要的安全风险：1. 模型输出错误：检测框位置偏差太大、分类错误

很多刚接触征程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 约束。正确的处理方式不是立刻大改网络，而是先把“算子约束”翻译成明确的问题，再选择合适的改法。....#