乐道Coconut 3.1.0推送之后，单Orin X版辅助驾驶体验确实上了一个台阶。

暴雨零接管、人车混行博弈、高架自主变道，都还不错，说是目前 orin x 最强有点绝对，但接近。

昨天 大雨说了蒸馏的话题，借这个话题展开一下。

254 TOPS对神玑的1000 TOPS，差了将近4倍，这个数字大家都知道。但还有一个老生常谈的话题 内存带宽。

Orin X的内存带宽是204.8 GB/s，神玑是546 GB/s，差了2.7倍。

为什么带宽重要？

现在的智驾模型越来越多用Transformer架构，而Transformer的attention机制有个特点：它需要频繁地在内存和计算单元之间搬运数据。

你的计算单元再快，如果数据供不上，算力就空转。

就像厨房灶台再大，上菜的通道就那么宽，出餐速度照样卡在走廊上。

不过得诚实说：是不是所有智驾模型都受限于内存带宽，这取决于具体架构。

传统CNN感知网络往往是算力受限的，只有当Transformer占比较大、尤其是做跨帧时序推理的时候，带宽瓶颈才会凸显。

乐道Orin版具体用的模型架构没公开，这一点我没法100%确定，但从行业趋势看，端到端模型里Transformer比重越来越大，带宽成为瓶颈只是时间问题。

第二个，Orin版跑的到底是什么模型？

公开信息说得很清楚：神玑版跑的是完整NWM世界模型，100ms内推演216种行车轨迹，直接输出方向盘转角和踏板控制。

而Orin版拿到的是 统一架构下的分级版本。

说白了就是蒸馏。

大模型蒸馏角度聊过这个话题，蒸馏让小模型继承大模型的高频能力，但低频长尾场景会丢。

我今天想接着往深了聊：蒸馏之后，天花板到底卡在哪。

蒸馏的原理决定了一个特性：高频场景（直行、跟车、常规变道），学生模型学得很好，因为训练样本多、特征分布密集；但低频长尾场景（施工区域临时改道、异形障碍物、极端天气下的罕见路况），老师自己见得就少，教给学生的更少。

这不是整体差一点，而是大部分场景差不多，某些特定场景突然断崖。

这种断崖式差异比均匀的"差一点"危险得多，因为你不知道它会在哪个路口突然失效。

第三个，蒸馏之上，可能还叠了一层量化。

先说实话：乐道Orin版到底用没用INT8量化，公开渠道没有明确信息。可能FP16，可能INT8，也可能混合精度。

这个我不确定，不能乱说。

但如果用了INT8量化，这在车载部署中非常常见，因为能把推理速度提升2到4倍，就有一个值得关注的叠加效应。

量化的本质是把32位浮点数压成8位整数。

TensorRT的官方技术文档明确提到一个问题叫小数值信息淹没：模型中那些微弱但有效的信号，比如低置信度的特征、稀疏的边缘场景激活值，在压缩过程中可能被噪声直接淹没。

你想，蒸馏已经让长尾场景的能力变弱了，量化又把这些变弱的信号进一步压缩。

两次压缩不是简单相加，更像是乘法，蒸馏让某个场景的置信度从0.9降到0.5，量化再从0.5压到0.1以下，这个场景可能就直接识别不了了。

当然，这是基于量化原理的推测，没有乐道的实测数据来证明。但从工程逻辑上说，这个叠加风险是真实存在的。

纯视觉方案在时序推理上还面临一个额外的算力困境。Transformer的attention机制复杂度是处理帧数越多，计算量是平方级增长的。

你想看更长的历史帧来提升深度估计精度，算力代价就指数级上升。

低算力平台上，要么缩短时序窗口牺牲精度，要么减小模型规模牺牲能力，两头都被锁住。

不过说清楚，具体乐道用了什么时序方案、窗口设了多长，这个没公开，我是在讲架构层面的物理约束，不是说乐道一定撞上了这个墙。

第五个，热降频。

Orin X满载功耗大约50W，8nm工艺，神玑是5nm。

8nm对5nm不只是 先进一代 的事。制程越先进，同等算力下功耗越低、发热越少。

车载环境散热空间有限，你不可能在车里装一个跟台式机显卡一样大的散热模组。

持续高负载下（比如长时间城区领航），Orin温度上来会触发降频，实际可用算力低于标称值。

254 TOPS是峰值，不是持续值。

神玑5nm能效比更好，同等散热条件下能维持更长时间的高性能输出。

跑高速时这个差距可能不明显，但走走停停的城区复杂路况，持续计算压力更大，差异就出来了。

最后说一个更根本的：以上这些因素不是独立存在的，它们是叠加的。

蒸馏损失长尾能力，量化可能进一步压缩稀疏特征，纯视觉需要更多算力弥补感知不足，算力受限于芯片规格，持续算力又被热降频打折，内存带宽限制了能跑的模型规模。

每一层都在给下一层加压，不是某一个环节不行，而是这些物理约束层层叠加，形成了一堵硬墙。

Coconut 3.1.0把这颗Orin X榨得很干了，这一点应该你不得不说，嚣张至极。