去 NIO Space 摸了两天 ES6 的 Banyan 2.0，确实有明显可感知的响应速度提升，而蔚来今天官宣的 Banyan 2.0 更新也提到了系统构架发生了变化，蔚来给出的说明是：“算力聚合、性能提升，业内首个聚合车辆不同算力共同协作。”
“算力聚合”可能只是宣发用词
众所周知，“算力聚合”这件事在分布式计算领域是很常见并且有一套完善的方法论的，但是在图形渲染领域，实际上是不切实际的，通过聚合两个独立系统的算力来提升一个显示设备的流畅度是很难做到的，系统间通信的延迟和带宽限制会直接反映到界面的卡顿上，例如同一台电脑上两张显卡的算力聚合用于做 CUDA 计算就很容易，而用于游戏图形输出就需要额外的一条 SLI 总线来增加带宽降低延迟。
蔚来是一家很诚实地企业，在宣发材料标题的后面解释了实际的实现方式“在8155芯片专注保障系统高性能运行的同时使用 Orin X 承担更多模型计算的工作”，所以其实本质上是调整了工作负载的分配，而并不是两套系统的算力融合。
那么蔚来到底调整了什么？这要从 Banyan 1.x 系统使用的骁龙 8155 SoC 的常规方案说起。
虚拟化方案看起来很美
安卓是车机多媒体系统的首选，但是因为安卓主要用于手机平板和电视盒等多媒体系统，所以 360 影像、主动安全、车上硬件控制这些需要高可用性、稳定性和实时性地应用在安卓上实现就没那么便利。
QNX 或者实时 Linux 都可以提供更可靠、更实时的应用支持，但是本身对多媒体的支持并不是很好。
做开发的都知道，尽量少造轮子，而是用好现有的轮子，8155 SoC 发布的时候就是提到了硬件虚拟化的特性，而在面向传统车企的方案提供商也都选择了一颗 8155 通过 Baremetal Hypervisor 来实现运行多台虚拟机多个操作系统的方式。安卓、QNX、Linux 可以同时运行在一台车机上，各司其职，安卓负责导航和多媒体、QNX 负责仪表盘和摄像头、Linux 和底层的 CAN 通讯来控制，看起来是一个完美的方案。
智能化被虚拟化拖了后腿
蔚来 Banyan 1.x 采用的就是这类方案，安卓和 QNX 分别运行在各自的虚拟机内然后，因为 QNX 和 Android 都需要调用 GPU 来处理视频和进行画面渲染，所以虚拟机除了做 CPU 虚拟化以外，GPU 需要虚拟化分配给不同的系统，而不能做到直通给某一个系统来使用，这就造成了额外的延迟，所以 UI 用起来总觉得卡卡的。
蔚来 NT2 构架的车辆，4颗环视摄像头，1颗行车记录仪主摄像头，1颗车乘员环境摄像头（自拍摄像头）接入了 8155 的 QNX 虚拟机；激光雷达、前后三个瞭望塔摄像头、双目摄像头、翼子板摄像头和驾驶员 DMS 摄像头接入了 Orin 系统。这就是为什么行车记录仪的视频会3分钟一个跳动生成在车机系统的相册，而不是一边录一边出现的，因为QNX每录制3分钟切分一个文件再通过 NFS 拷贝到安卓的系统中去。
这个构架可以看作蔚来基于 8155 SoC 的行业通用方案做了个性化的定制逐步生长出来的缝合怪，蔚来整车软件的构架本就是一件破旧立新的事情，用传统的构架搭建很快就遇到了瓶颈，为了解决问题会创造出新的问题，这也许就是 1.x 系统在升级过程中不断地出现旧问题反复的原因，实现很多功能也变得相当困难。例如流媒体后视镜，例如转向摄像头辅助，实现一个行车记录仪都已经非常不容易了，守卫模式串流也非常有挑战，系统的流畅性也因为虚拟化 GPU 非常苦难，是时候构建一套自己的构架来解决问题了。
猜猜 Banyan 2.0 的构架是什么样的
从蔚来的文字表述，我猜测一下，首先就是 GPU 的虚拟化应该不存在了，可能 GPU 直通了安卓的虚拟机，而 QNX 不再处理需要GPU的任何工作，Orin 承担了所有需要 GPU 计算的任务。
安卓完全接管了 8155 的 GPU，所有 8155 GPU 的算力都用于用户界面的显示渲染，环视摄像头的视频通过总线转发给 Orin 进行运算，这也更加符合 BEV 和占用网络的需求，在低速的泊车辅助等需要用到环视摄像头的场景转发导致的延迟应该不会造成太大的问题。QNX 只负责 8155 上接驳的几颗摄像头的数据存储和转发，不再参与计算。
我再大胆一点猜测，QNX 可能已经完全被干掉了，8155 上的虚拟机已经不存在了，安卓直接在 8155 上本地运行，接驳在8155上的摄像头完全由安卓接管
大统一大融合，流媒体后视镜、专项摄像头辅助视角、行车记录仪视频实时上传都变得非常易于实现，而车辆的唤醒速度也将进一步得到提升。
全文都基于作者的猜想，并没有任何代码和实验佐证，如有雷同纯属巧合。
