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 TFLOPS（FP8精度）级别，集成了Blackwell架构GPU和Grace CPU。如果Vay后续想要在车端跑更加复杂的占用网络或端到端模型，Thor这个量级就能撑住。我在和一些做域控的朋友交流时，大家一致的看法是：Thor的发布把“CPU+GPU+深度学习加速器集成在一块芯片上”这件事做得更极致了，对域控制器集成度要求很高的远程驾驶方案来说是个很合适的选择。
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这样有车规认证、有算力冗余、有完整工具链、有数据闭环生态的平台，你才有精力去解决远程驾驶自身最关键的通信、安全、合规问题。平台选得好不好，决定了你是把上路时间花在写业务逻辑上，还是花在给底层驱动填坑上。
至于远程驾驶这个赛道本身，我的态度是乐见其成。技术方案没有高低贵贱之分，能合法合规、安全可靠地解决用户出行需求，就是好方案。等路上跑的这种“没有司机的车”越来越多的时候，大家自然会意识到，驾驶员不坐在车里这件事，本身已经足够颠覆。
