1. “没有司机的车”背后其实是远程司机在开车最近两年自动驾驶行业里出现了一种和“全无人Robotaxi”并行的路线——远程驾驶Teledriving。Vay这家公司主推的就是这个方向车辆本身具备一定感知和计算能力但并不是完全自主决策而是由远程驾驶员通过网络实时操控。听起来有点像“遥控车放大版”但真正落地起来牵扯到的东西比想象中多得多。先说说这种模式定位在哪。传统自动驾驶想解决的问题是“机器替人开车”Vay想解决的问题是“人不必坐在车里开车”。这两者听起来很像但商业逻辑和技术栈是有明显差异的。远程驾驶模式下车端依然要有摄像头、雷达、计算平台用来采集环境数据并回传给远程驾驶员同时车端也要具备执行转向、加速、刹车的线控能力。决策环节不在车上而是发生在远程工作站里那个驾驶员的大脑里。也正因为如此远程驾驶不需要像全无人驾驶那样把算法置信度推到极高它面对的工程挑战更多在通信延迟、安全冗余、数据带宽和法规认证上。我曾经和搞自动驾驶的朋友聊过大家都认可一个判断全无人驾驶的落地节奏受限于长尾场景而远程驾驶受限于“网络靠不靠谱、车坏了怎么办”。两边的瓶颈完全不同所以技术选型逻辑也不一样。那为什么Vay偏偏要选择NVIDIA DRIVE AGX平台来承载这套方案这是我看到这个标题时最想展开聊的问题。DRIVE AGX本质上是一套为L2到L4级自动驾驶设计的计算平台它不只是一个芯片而是一整套硬件软件栈。Vay用这个平台等于是把最难的部分——车规级计算、传感器接入、功能安全认证、OTA升级链路——交给了一个已经验证过的底座而自己集中精力解决远程驾驶特有的问题。这篇文章我就以自己的理解把“Vay DRIVE AGX”这条技术路线的关键点拆开讲讲。内容主要面向三类人一是做自动驾驶/辅助驾驶方案选型的工程师二是研究出行商业模式的产品经理三是关心“自动驾驶到底怎么落地”的从业者。看完你至少能搞明白三件事远程驾驶和自动驾驶在技术架构上差在哪DRIVE AGX这个平台到底解决了哪些部署难题以及一套远程驾驶方案从demo到量产车队的完整链路长什么样。2. DRIVE AGX算力底座为什么选现成平台而不是自研很多团队在做远程驾驶方案时第一反应是“反正决策在远程端车上不需要太强的算力”。这个想法大方向没错但实际做下去就会发现问题即使决策不在车上车端的感知、编码、传输、执行、安全监控每一步都需要算力支撑而且这些任务不能挤在一起。2.1 车端算力到底用在哪儿远程驾驶的车端计算主要分四块负载。第一块是传感器数据采集与预处理摄像头原始数据要经过ISP图像信号处理、去畸变、时间同步等多个步骤才能变成可传输的干净画面。第二块是视频编码与推流这活儿对算力要求相当高尤其是多路摄像头同时编码的情况下通用CPU几乎扛不住。第三块是主动安全监控虽然决策在驾驶员但车端必须有一套独立的障碍物检测逻辑用来在网络断开或驾驶员误操作时兜底。第四块是车辆状态协议处理线控指令下发、底盘状态上报、IMU数据融合这些需要实时性很强的计算资源。这四块负载如果能合理分摊到专用单元上整个系统的稳定性和实时性都会好很多。DRIVE AGX的优势就在这里这块平台通常包含GPU、CPU、深度学习加速器、图像处理单元等多个异构核心可以把感知、编码、推理、控制分配到不同单元上并行处理。而不是像某些自研方案那样所有东西挤在一颗SoC上哪一路数据量一大整体延迟就上去了。2.2 DRIVE AGX平台的核心硬件组成当前DRIVE AGX系列里大家听得比较多的主要是基于Orin芯片的方案以及面向下一代车型的Thor平台。Orin家族的AI算力最高可以到254 TOPS对于远程驾驶这种“不需要端上跑大模型”的场景来说其实是把性能冗余给足了。冗余不是浪费而是给主动安全模块和未来功能升级留的空间。Thor则是Orin的下一代产品算力水平提升到2000 TFLOPSFP8精度级别集成了Blackwell架构GPU和Grace CPU。如果Vay后续想要在车端跑更加复杂的占用网络或端到端模型Thor这个量级就能撑住。我在和一些做域控的朋友交流时大家一致的看法是Thor的发布把“CPUGPU深度学习加速器集成在一块芯片上”这件事做得更极致了对域控制器集成度要求很高的远程驾驶方案来说是个很合适的选择。DRIVE AGX还配套一个很关键的东西——DRIVE OS操作系统。这是一套基于实时操作系统的软件平台支持功能安全隔离。简单说它允许你把“运行视频编码的应用”和“运行安全监控的应用”放在同一个平台的不同分区里两者互不干扰。这在远程驾驶里极其重要如果视频编码突然占满资源安全监控不能跟着卡顿这属于功能安全设计的基本要求。2.3 自研和选型的时间成本账有些团队觉得买个GPU开发板编解码自己做不就行了正经去走量产流程就会发现问题远不是“算力够不够”这么简单。车规级认证、功能安全证书、长供货周期承诺、工具链成熟度每一样都是钱和时间。DRIVE AGX的优势在于它是已经验证过的量产平台从硬件到软件栈再到工具链有大批量产经验垫底。对Vay这种模式相对轻的公司来说自研域控要养一个几十人的底层软件团队还要自己处理芯片bring-up、BSP适配、功能安全认证光时间账就不划算。做产品的人都懂关键的竞争要素除了性能还有上市时间。与其把精力花在重复造轮子上不如借助成熟平台把核心业务跑通。3. 从传感器到远程驾驶座舱整套部署链路的完整拆解选完算力底座下一步就是搭建端到端系统。远程驾驶方案的整体链路可以分成三段车端感知与计算、通信传输、远程驾驶座舱。下面我按部署顺序展开讲。3.1 车端传感器配置方案Vay的车辆传感器套件目前以摄像头为主、毫米波雷达和超声波雷达辅助没有搭载激光雷达。这个选型逻辑很清晰远程驾驶员靠视觉判断路况所以高分辨率摄像头的数量和质量是第一位的激光雷达产生的点云数据带宽大、编码复杂对传输链路压力很大而且在远程驾驶里用处不大——你总不能把点云画面直接推给驾驶员看。摄像头布局方面一般会做8到12路的环视配置前向双目为主视觉四角鱼眼负责近距盲区两侧盲区摄像头覆盖变道场景后向摄像头负责倒车。每路摄像头的分辨率目前主流是800万像素级别帧率要求30fps左右。这堆原始数据加起来带宽需求是非常夸张的——如果直接传原始视频流单路摄像头就要接近1Gbps以上。所以车端必须有一套智能Region of Interest感兴趣区域编码策略。比如高速行驶时前景区域分配较高码率天空和远处静态背景可以降低码率低速转弯时重点保障车辆侧向区域的画质。NVIDIA的编码单元支持多路并行硬件编码可以把整体传输码率压到比较合理的范围。实测下来8路摄像头叠加编码后单车上行带宽控制在20-40Mbps左右是可行的这个数值对于5G网络来说完全可承受。3.2 远程驾驶座的硬件与人机交互设计远程驾驶座舱不是单纯放一套方向盘和踏板就完事。它涉及的关键问题在于驾驶员无法感知车辆的横向加速度和颠簸只能用视觉信息来补足。因此Vay的远程座舱在设计时做了几件事多屏拼接显示前向主场景用大屏左右两侧用辅助屏模拟真实驾驶视野。虚拟化后视镜通过车侧摄像头画面合成电子后视镜视图弥补物理后视镜的缺失。方向盘力反馈模拟真实路感让驾驶员知道前轮大概处在什么角度。声音回传车端麦克风采集环境音回传帮助驾驶员感知周围环境。这一套交互设计做下来核心目标是让远程驾驶员在几百公里之外能够做到足够自然的驾驶操作。说实话方向盘力反馈这一点是很多远程驾驶团队忽略的细节。没有力反馈的情况下驾驶员很难感知车辆的转向状态一旦遇到障碍物变道就容易出现过度转向。Vay在这块的打磨看得出是花了时间去实测的。3.3 车端与远程端的通信链路设计通信是远程驾驶方案里最重要也最脆弱的一环。当前主要依赖5G公网有线专网混合链路车辆通过双运营商SIM卡做链路冗余远程端通过专线接入运营商核心网从而降低公网抖动。通信参数上有几个硬性指标端到端视频延迟控制在100毫秒以内控制指令下发在50毫秒以内上行丢包率低于0.5%。这套指标在5G网络覆盖良好的城区是可以达到的但前提是编码和传输策略要优化到位。比如视频链路用UDP传输并配合前向纠错控制链路走TCP但要做超时重发的快速判断——如果上一次转向指令超过80毫秒没到达车端车端主动安全模块就应介入并制动。DRIVE AGX在这一环节的价值体现为它自带高精度的时间同步和网络协议栈适配能力摄像头曝光时间戳、视频帧时间戳、控制指令时间戳能够统一对齐。这一点对排查网络延迟问题很有用。我们之前在做延迟排查时发现很多“看起来延迟高”的问题根源其实是车端采集时间戳和远端显示时间戳差了半秒钟导致测出来的延迟数据虚高。用好平台自带的时间同步机制能省去大量调试成本。4. 安全冗余设计网络断开、算法误判、驾驶员失能怎么办远程驾驶最容易被质疑的问题就一个网络断了怎么办这个问题处理得好不好决定了方案能不能过法规审核也决定了普通用户敢不敢坐。Vay在整个系统里设计了多级安全兜底机制下面按优先级从高到低拆解。4.1 车端主动安全模块独立于远程控制的“安全岛”DRIVE AGX支持**安全岛Safety Island**功能也就是在计算平台内部划分出一块独立的、运行在功能安全认证环境里的计算区域。这块区域只运行车辆安全相关的算法比如紧急制动判断、车道偏离预警、障碍物距离监测。安全岛最核心的特征是独立性即使主系统崩了、视频编码卡了、通信断了安全岛依然能独立工作。一旦检测到异常它可以在200毫秒内让车辆执行紧急停车策略——打开双闪、缓踩刹车、靠边停车。这个安全岛的设计思路和航空业的“自动驾驶远程飞行员”很像主飞行系统失效时有独立的备用系统接管。4.2 多层降级策略整个系统的降级策略一般分四级正常远程驾驶模式远程驾驶员操控车辆主动安全模块实时监控不干预。软降级模式网络延迟超过阈值但未完全断开系统限制车速例如限制到30km/h以内并提醒驾驶员准备接管或选择安全停车点停车。硬降级模式网络完全断开或远程驾驶员失能主动安全模块执行最小风险停车策略。驾驶员失能兜底如果远程驾驶员长时间无操作且系统判定其失能强制切换到自动紧急停车流程。这种分级降级的策略核心逻辑是让系统的每一步失效都有更底层的机制兜住而不是赌“网络不会断”。Vay目前在一些城市开展商业运营能够拿到运营许可很大程度上是因为这套多级降级设计经过了监管方的安全论证。4.3 远程驾驶与自动驾驶的安全边界还有一个常被搞混的点远程驾驶系统的车端主动安全模块到底算不算“自动驾驶”这也是法规上非常敏感的地带。我的理解是Vay的车辆在远程驾驶模式下严格意义上属于“L2级辅助驾驶远程驾驶员监管”的组合远程驾驶员承担主要安全责任。但在硬降级模式下车端执行的是L4级最小风险策略——这一段自动化的边界非常窄只覆盖“安全停车”这个动作。把安全策略收窄到一个高度可控的范围内是远程驾驶方案更容易过法规审查的关键。这个设计思路值得其他做出行方案的朋友参考在AV法规还不成熟的情况下与其做全场景自动驾驶不如先把“自动安全停车”这一件事做到极致让它成为一个独立的、可认证的子系统然后再围绕它搭建商业模式。边界清晰了审批和用户信任的门槛都会降低。5. 部署与量产从单台Demo到车队运营的支撑体系最后聊一下方案从Demo走向量产车队时DRIVE AGX这个底座在工程落地层面带来的具体价值。很多人小看了这一步觉得技术Demo跑通了离量产就不远了实际上中间隔着一条巨大的工程化鸿沟。5.1 数据回传与训练闭环DRIVE AGX平台天然支持大规模数据采集和回传。车辆在运营过程中采集到的视频数据、驾驶员操作行为数据、接管事件数据都会被自动打标签并回传到云端。这些数据一方面用于优化主动安全算法另一方面也可以训练“驾驶行为预测模型”帮助系统预判远程驾驶员的操作意图提前给予辅助。举个例子远程驾驶员在接近十字路口时系统可以通过历史数据预判其减速意图提前调整视频编码码率分配保证潜在危险区域的画质不丢帧。这种优化无法在实验室里完成必须在真实运营车队里拿数据调优。这也是为什么DRIVE AGX的生态能力——数据平台、云端工具链、仿真测试环境——对Vay的价值不亚于芯片本身。5.2 仿真测试在远程驾驶里的特殊用法传统自动驾驶的仿真测试主要是验证决策算法远程驾驶的仿真测试重点完全不同。它的核心价值在于验证异常场景下的降级策略是否可靠——比如模拟5G基站突然故障、模拟隧道内信号丢失、模拟远程驾驶座舱断线、模拟驾驶员突然失能等。DRIVE AGX生态里配套的DRIVE Sim仿真平台可以按需构建这类网络异常场景并在虚拟环境里测试车端安全岛的响应逻辑。我在和一些做仿真平台的朋友聊天时大家普遍认为远程驾驶的仿真需求其实是“软硬结合”——不仅要仿真车辆动力学还要仿真通信链路质量。Vay的做法是先用仿真大批量跑降级策略的边界条件再在封闭场地做小规模实车验证最后才进入公开道路试运营。这套验证节奏大大压缩了从代码到运营的时间成本。5.3 车队的OTA迭代能力再一个不能忽略的点是OTA升级。远程驾驶方案迭代非常频繁摄像头标定参数、编码策略、安全模块灵敏度、通信协议栈都需要持续优化。DRIVE AGX的软件生态对OTA的支持很完善支持分区升级——也就是说升级视频编码模块时安全岛模块可以保持运行不影响车队正常运营。远程驾驶车队如果没有OTA能力每次升级都要召回车辆回厂刷软件那个成本是无法接受的。而借助DRIVE AGX的软件架构整个升级过程能做到类似换手机系统一样便捷这对一个运行上百辆车甚至上千辆车的出行服务商来说是决定生死的基础设施能力。远程驾驶和自动驾驶不是二选一写了这么多最后聊几句我自己的判断。远程驾驶长期被不少人看作是“自动驾驶的过渡形态”好像等技术成熟了就会被全无人驾驶替代。但在实际工程角度看这两种模式未来很可能会长期并行全无人驾驶负责它擅长的高确定性场景远程驾驶负责接驳最后一公里、夜间低需求时段、复杂城区等场景。甚至在全无人驾驶系统遇到无法处理的边缘情况时远程驾驶员介入会成为整个系统的“安全网”层级而不是一个可有可无的补充。对于想切入这个方向的团队我在实际接触项目后的建议是别一上来就想着全自研先把车上这个计算底座选对。选一个像DRIVE AGX这样有车规认证、有算力冗余、有完整工具链、有数据闭环生态的平台你才有精力去解决远程驾驶自身最关键的通信、安全、合规问题。平台选得好不好决定了你是把上路时间花在写业务逻辑上还是花在给底层驱动填坑上。至于远程驾驶这个赛道本身我的态度是乐见其成。技术方案没有高低贵贱之分能合法合规、安全可靠地解决用户出行需求就是好方案。等路上跑的这种“没有司机的车”越来越多的时候大家自然会意识到驾驶员不坐在车里这件事本身已经足够颠覆。