最近，上汽大众ID. ERA 5S上市，带城区NOA的Pro领航版，限时权益价只要11.49万元。我们刚试了一汽-大众ID. AURA T6，同样也忍不住问：大众辅助驾驶怎么这么强了？
两款车背后，都有大众与地平线的合资公司酷睿程：基于征程芯片和HSD模型等底层能力，继续研发、适配。这套方案计划从今年第三季度起，陆续搭载大众在华三家合资企业的七款新车。
这些体验怎么做出来的？
我想起了前段时间，我们在上海试用了HSD V2.0，发现它有个很突出的特点：反应特别快。
看下面这个场景。
斑马线上有人横穿，它先减速让行；人刚过去，几辆非机动车又接连插到车前，它继续低速等待。等前面的空间让出来，车马上又走起来了。
短短几秒钟，前面的情况一直在变，它的动作也跟着变。遇到情况能及时让，情况解除后也能及时走——要做到这一点，低时延、快反应很重要。同样的动作，哪怕慢上半拍，看起来都会有点呆。
手头恰好有一张标注数据来源为睿思齐的测试榜单：HSD的绿灯启动延迟为505毫秒，跟车急刹制动间隔为640毫秒，两项都排在这张表的第一位。
注意，这份榜单测的还是HSD V1.6。到了V2.0，系统响应时延进一步缩短了20%。这也与我们测试中感受到的敏捷反应对上了。
这就让我想仔细研究一下：反应快这几十、几百毫秒，在实际驾驶中究竟有什么价值？地平线又是怎么把这些时间省下来的？
一、低时延的价值
几十、几百毫秒，听起来很短。但要注意，车不会停下来：
时速60公里时，多等100毫秒，就又走了1.67米；
时速120公里时，同样的100毫秒，就是3.33米。
在城区辅助驾驶中，慢半拍可能只是让人觉得车有点呆；放到AEB紧急制动中，就可能影响能不能及时停住。
我们平时关注制动性能，百公里刹停33米还是35米，差两米就很值得研究。为了争取这两米，卡钳上六活塞、换布雷博，轮胎换高抓地力的，制动盘再做大一些……
全做完这些，还不如把时延降低个100ms的效果强！
那么，时延时间究竟耗在哪里？是因为算得慢吗？是不是芯片算力越大，车就能反应越快？
二、降低时延的方法
为什么我们很容易觉得，算力越大，反应就越快？
因为我们习惯把计算想得很简单：信息进来，芯片算出结果。按这个最简单的模型：
计算时间 ≈ 计算量 ÷ 算力。
计算量不变，算力翻倍，时间自然就减半了。
但实际运行时，芯片未必能一直满负荷计算。数据没送到，它要等；前面的任务没完成，它也要等。机器转得再快，也架不住材料在路上、任务在排队。
所以，要讲清楚低时延，我们得拆开四层来看：
1. 计算单元：用什么机器算？
2. 存储与数据流：数据怎样送到机器手里？
3. 编译器与运行时：这些工作怎样安排？
4. 模型结构：得到一个结果，究竟要完成哪些工作？
接下来，就看看征程6P和HSD在这四层分别做了什么。
1. 计算单元
算力当然也重要：征程6P是征程6系列的旗舰，算力达到560 TOPS。但评价算力时，必须要稍加了解一下芯片架构！
我们以前用三张动图解释过CPU、GPU和TPU的区别。
CPU像一位多面手，擅长处理复杂、变化多的任务：
GPU把大量相似的计算铺开，让许多计算单元同时干活；
TPU则进一步针对神经网络里的矩阵乘加，把计算单元连接成阵列，让数据边传递、边计算，减少中间结果反复存取。
同样是做乘法、加法，工作的组织方式不同，效率就可能差很多。
那地平线用的是什么？它把自己研发的AI计算架构叫作BPU，全称Brain Processing Unit，中文可以叫“脑处理单元”。
从设计思路看，BPU与前面介绍的TPU更接近，都针对神经网络计算设计专用硬件。地平线进一步围绕智能驾驶的需求做优化，征程6P搭载的就是采用Nash（纳什）架构的BPU。
它具体优化了什么？我们拿Transformer里的注意力计算来看，它要解决的是：面对一组信息，应该重点关注哪些，又该怎样把它们组合起来？主要过程可以拆成三步。
第一步，算相关程度。通过矩阵乘法，得到不同信息之间的相关分数。
第二步，分配权重。用Softmax把分数转换成一组总和为1的权重。比如分数是1、2、3，转换后约为9%、24.5%、66.5%：分数越高，获得的关注越多。
第三步，按权重汇总信息。这一步也是矩阵乘法，权重大的信息，对结果的贡献就更大。
第一步、第三步，都是TPU这类计算架构擅长的大块矩阵乘法。但中间的Softmax，需要找最大值、做减法、求指数、求和，再做除法。这些操作还有先后依赖：总和没算出来，最后一步就完成不了。
所以，中间这一段如果跟不上，光把前后的矩阵乘法做快，整个过程也快不了多少。
征程5部署Swin Transformer时，就通过软件调整算子映射、优化执行方式。
征程6P采用的Nash架构，除了矩阵计算引擎，还配置了可编程的向量处理单元，并明确支持Softmax等算子的硬件加速。前后两步的大块矩阵乘法有专门的计算资源，中间这串计算也得到了针对性优化。
效果呢？据地平线BPU算法负责人介绍，Nash针对Transformer进行专用优化，在Softmax、LayerNorm等关键计算环节，实现了数量级的性能提升。
2. 存储与数据搬运。
注意力计算的三步之间，也需要传递数据。如果数据传得慢，整个过程也会被拖住。
针对这个问题，地平线从硬件和软件两个方向下功夫：一是把存储设计好，让数据留在近处；二是优化计算安排，让数据少搬几趟。
先看硬件。
分层存储就像办公桌、文件柜和档案室：常用资料放在手边，更多资料分层存放，兼顾取用速度和存放空间。
征程6P采用的Nash架构，设计了L0M、L1M、L2M三级存储，用于数据缓冲和交换，配合计算核之间的协同，缓解大参数模型的带宽瓶颈。
再看软件。
地平线介绍过分块与融合的方法，我们换一个连续两层卷积计算的例子来看。
如果先算完整个第一层，再开始第二层，中间结果可能太大，芯片内部放不下，就得写到外部内存，之后再读回来。
另一种安排是把任务拆小：第一层算出一部分，只要满足第二层对应部分的输入需求，就接着算。中间结果便有机会留在芯片内部直接使用，用完再腾出空间处理下一块。
硬件让数据存得更合适，软件让数据少搬几趟，共同减少外部内存读写，让计算单元少等数据。
3. 让紧急任务少排队。
地平线的J6工具链，可以在编译时把一个长模型任务拆成多个较短的执行段。
运行过程中，高优先级任务到来，不必等整个模型全部算完，而是在当前执行段结束后，优先获得计算资源；处理完，再继续原来的任务。这就省下了高优先级任务等前面的大模型算完的时间。
4. 一段式端到端，减少中间环节。
以往的端到端也可能分成两段实现的。两段不仅要完成各自的计算，还要整理、传递结果，衔接不同步时，就可能产生额外等待。
记得去年第一次试驾HSD时，地平线强调“真正的一段式端到端”，横向、纵向控制都纳入端到端方案。我试下来，确实感觉很丝滑。
当时主要觉得是驾驶效果更好了，现在从低时延的角度再看，把这些任务放进统一模型，还能减少中间交接带来的潜在等待，为降低系统时延创造条件。
总结
这四层拆下来，就能看出，低时延需要整条链路一起配合。模型、工具链和芯片得围着同一个目标调整：让判断及时变成车上的动作。
地平线从征程5时代就在讲软硬结合，也一直在做。前段时间群里有人感叹，原来地平线不只是软件强，芯片也很强啊。听着好笑，也说明HSD确实做出了存在感。
HSD像是征程芯片的一份“参考答案”：让车企和用户看见，这套硬件配上合适的软件，能做出什么样的驾驶体验。从这个角度看，低时延就是软硬能力得到发挥的一个具体例证。
而大众、比亚迪这样的客户，会进一步带动规模。
比亚迪天神之眼C的部分车型已经采用征程6，带来芯片的量产需求。大众则通过酷睿程，把芯片、模型等底层能力做成自己的方案，按计划从今年第三季度起，陆续搭载于在华三家合资企业的七款新车。随着这些合作车型上量，地平线的能力也会进入更多人的日常驾驶。
现在，征程芯片累计量产出货已经突破1500万。芯片有规模，软件有体验，大众和比亚迪的合作又在继续扩大应用。这样的软硬双强，已经经过了市场检验。
回到开头，低时延省下的那一点等待，到了车上，就是该让时及时让、能走时顺畅走。把这种体验做出来，再让它具备走向大规模量产的条件——地平线今天取得的成绩，已经很大了
