1. 什么是 Prefix Caching在大语言模型（LLM）推理过程中，用户输入的 Prompt 通常需要经过 Prefill 阶段计算，生成对应的 KV Cache，随后模型进入 Decode 阶段逐 Token 生成输出。在实际业务中，不同请求之间往往存在大量相同的 Prompt 前缀，例如：相同的 System Prompt相同的角色设定相同的工具定义多轮对话中已经产生的历史上下文简而言

# 从 40% 到 0.92%：一次征程6 OTA 下载的硬件加速优化全记录..> 副标题：为什么 HTTPS 下载会烧 CPU，以及一条 `objdump` 命令如何成为跨团队验收的判据。..## 摘要..在征程 6（J6）平台的车载 OTA 下载场景中，`admsysiApp` 下载模块长期占用约 **15% CPU**，在单核环境下挤占其他业务。我们通过火焰图定位、台架实测与软件包二进制比对

摘要： 模型在 GPU 上精度正常，到了 J6 做 INT8 量化却开始掉点，很多人的第一反应是换校准数据、调量化参数，甚至直接上 QAT。但实际工程中，问题可能早在 ONNX、图优化、量化转换或编译部署阶段就已经出现。本文结合 J6 工具链，把 PyTorch 模型到 J6 HBM 的精度变化明确拆成 4 段，通过逐阶段验证定位第一处误差，再决定到底该修模型、调 PTQ，还是进入 QAT。关键词

具身智能（Embodied AI）是今年的热门方向，机器人不仅要感知环境，还要理解环境语义、规划路径、执行动作。我在一个室内服务机器人项目里，把视觉SLAM和语义理解部署到征程6M上，让机器人能"看懂"房间布局并自主导航。这篇把方案设计和踩坑经验记下来。一、系统架构服务机器人的感知-决策-控制闭环：1. 视觉SLAM：单目/双目摄像头+IMU，实时建图和定位2. 语义理解：BPU跑分割模型，识别"

自动泊车是智能驾驶的重要场景，感知需求和高频高速场景不一样：速度低、环境复杂（柱子、路沿、其他车辆）、需要厘米级精度。我在一个自动泊车项目里把环视拼接、BEV分割、车位检测三个模块部署到征程6M上，踩了不少坑。这篇把完整经验记下来。一、Parking感知Pipeline自动泊车的感知pipeline分三个阶段：1. 环视图像拼接：4路鱼眼摄像头→去畸变→透视变换→拼接成鸟瞰图2. BEV分割：对拼

检测做得再好，没有跟踪也做不成自动驾驶。多目标跟踪（MOT）负责把每帧的检测框关联成连续的轨迹，输出"这辆车从哪来、到哪去"。我在一个城市NOA项目里把DeepSORT+JDE部署到征程6M上，BPU跑检测，CPU跑跟踪，两者协同调度有不少门道。这篇把完整部署经验记下来。一、DeepSORT+JDE架构我们的跟踪方案：1. 检测器：YOLOv5m（BPU运行），每帧输出检测框2. 外观特征提取：J

自动驾驶感知不是单帧的事，时序信息对运动目标预测、遮挡恢复、假阳性过滤都至关重要。我在一个高速NOA项目里做了基于征程6M的时序BEV融合，把多帧BEV特征对齐、时序注意力、轨迹预测三个模块跑通。这篇把设计思路和踩坑经验记下来。一、时序BEV融合架构时序融合的核心问题：如何把历史帧的BEV特征和当前帧对齐？我们的方案：1. ego-motion补偿：根据车辆自身的运动（速度、yaw rate），把

地平线官方最近推出了OE Agent"天工"，一个基于大模型的AI助手，能辅助写代码、查文档、排错。我试用了一段时间，发现对新手很友好，老手也能省不少查文档的时间。这篇把天工的安装、使用场景和实际体验记下来，后面想用的同学可以参考。一、天工是什么天工是地平线基于大模型开发的AI Agent，专门面向征程系列芯片的开发者。主要功能：1. 代码生成：根据自然语言描述生成征程6相关的代码（如UCP调用、

Occupancy Grid（占据栅格）预测是自动驾驶感知的新方向，比传统的3D目标检测更细粒度，能描述不规则障碍物（如倾倒的锥桶、悬挂的树枝）。我在一个园区无人车项目里把Occupancy Network部署到征程6M上，踩了不少坑。这篇把模型结构、量化策略和部署经验记下来。一、Occupancy Network架构典型的Occupancy Network包含：1. 图像编码器：ResNet/V

做算法部署的同学通常只关心模型推理，但摄像头图像能不能稳定进BPU、推理结果能不能正确输出，全看VIN（Video Input）和VOUT（Video Output）模块配置对不对。我在一个量产项目里被VIN的图像花屏问题卡了一周，后来发现是几个寄存器配置错了。这篇把VIN/VOUT的配置流程和调试经验记下来，适合想深入理解征程6底层驱动的同学。一、VIN模块架构征程6的VIN模块负责从MIPI

RT-DETR是百度提出的实时检测Transformer，精度比YOLOv5x高，延迟更低。但Transformer的量化比CNN麻烦，attention层的动态范围大、LayerNorm对精度敏感、decoder的交叉注意力有复杂索引操作。这篇把RT-DETR在征程6M上的完整QAT调优流程和踩的坑记下来。一、RT-DETR模型结构简析RT-DETR主要分三部分：1. Backbone：ResN

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. 模型输出错误：检测框位置偏差太大、分类错误