虚拟里程是指一个海量仿真平台在单位时间内并行仿真节点行驶里程的总和。单位时间内的仿真里程数取决于整个平台算力支持并行运行的节点数和不同仿真场景复杂度下的超实时指数。

简单来讲，一个仿真节点就是一辆车，就是仿真平台能支持同时并行跑多少辆“测试车”。

据智行众维CEO安宏伟解释：简单来讲，假如一个仿真平台有100台GPU服务器的算力，每台部署8个仿真实例，则这个仿真平台就拥有同时并行800个仿真的能力。仿真里程就取决于每个实例每天跑的里程数了。

一台GPU服务器上能跑多少个实例，取决于GPU的性能和仿真求解器能不能在一台服务器上并行仿真。

安宏伟说：“我们云仿真平台的仿真节点，实现了多种部署方式，能够灵活满足客户的各种云资源的状况，都能实现大规模、弹性的节点部署。目前我们在苏州相城建设的云仿真平台已实现过超过400节点的部署。”

结合每个实例每天跑的里程，就可以大致计算出仿真平台上每日的仿真总里程。如果一个实例（虚拟车）平均每小时跑120公里，每天跑24小时，那每日就是将近3000公里，如果有33个实例，那该台服务器上每天就差不多有10万公里。

但据安宏伟的说法，业界平时所说的仿真“每天多少万公里”其实是不太严谨的。“需要结合合理的仿真测试方案和海量的场景作为支撑，在场景的覆盖度和有效性上进行不断地扩展，最后能够跑出来有效的场景才是根本。”

在采访中，笔者反复问到一个问题：仿真平台上跑的车，跟真实世界中的车，是在同一个时间维度上的吗？换个说法：仿真平台上的1小时，等于真实世界中的1小时吗？会有“人间一年，天上十年”的情形出现吗？

答案是：可以等于（实时仿真），也可以不等于（超实时仿真）。超实时仿真又可分为“时间加速”和“时间减速”两者情况——时间加速即仿真平台上的时间比真实世界中的时间快，时间减速即仿真平台上的时间比真实世界慢。

仿真比真实世界的时间快是为了提高效率，那么，比真实世界的时间慢又是为了什么？

安宏伟的解释是：“举个例子，有一些仿真测试对图像渲染的精度要求非常高，为了追求精度，单帧图像的渲染可能无法在实时情况下完成。这种比真实时间慢的仿真，不是做实时的闭环测试，而是做离线测试。”

具体地说，在实时仿真中，图片在生成后直接发给算法去识别，这个过程也许能在100毫秒内完成，但在离线仿真下，图片在生成后先保存，在离线条件下发送给算法处理。

根据安宏伟的解释，在仿真平台上做超实时仿真需要满足如下两个前提条件：服务器的算力资源足够强大；被测算法能接收虚拟时间。

算法能接受虚拟时间，这个怎么理解？安宏伟的解释是，有一些算法在结合硬件运行平台的条件下，可能需要读取硬件上的授时或网络授时，而无法读取仿真系统提供的虚拟时间。

某Tier1的仿真专家说：在仿真系统的工程框架PoseidonOS里做到精确的时间对齐和同步，然后就可以把算法部署在集群服务器上，进而仿真空间的时间可以跟真实物理世界的时间解耦，解开了就能“随意加速”了。

那么，在做时间加速的的时候，能加速2倍还是3倍，这个加速倍数又取决于什么呢？

安宏伟的答案是：服务器的算力资源、测试场景的复杂度、算法的复杂程度、算法的运行效率等。即理论上，在同等场景复杂程度、同样算法的条件下，服务器的算力资源越强大，可实现的加速倍数就可能越多。

时间加速倍数的上限是多少呢？这个问题，我们得结合时间加速的原理来回答。

据某自动驾驶公司仿真负责人解释，由于算法复杂度不一致等原因，训练模块、车辆控制模块等各模块的计算速度是不一样的，而超实时最常规的方法就是通过对各个参与计算的模块做统一调度。 所谓加速，就是计算速度比较快的模块“取消等待时间”——不管你另外一个模块又没有算完，时间到了我就同步。

如果各模块之间计算周期的差异太小，这个被取消的等待时间就很小，因此，加速倍数会很低；另一方面，如果各模块的计算周期差异特别大，比如这个需要1秒，而另外一个需要100秒，那也没法“取消等待”。

因此，时间加速的倍数往往是有限的——能达到2-3倍就算很高了。

甚至，有不少专家说，在实践中，要真正做到时间加速很难。

深信科创创始人杨子江称，如果自动驾驶系统的算法已被编译部署到了域控制器或工控机中（在HIL阶段就是如此），则它在仿真系统中就只能以实时的方式运行——此时，超实时仿真行不通。

安宏伟也说：“硬件在环（HIL，半实物仿真）本身必须是实时仿真，不存在‘超实时’的概念，也不适用‘并行仿真’或者‘时间加速’的提法。”

鲍世强说：“时间加速的前提是，对时间的精确控制，以及时间同步。感知很难加速，因为不同传感器的频率不一样，摄像头可能是30 Hz,然后激光雷达是10Hz，类似于这种，你如何保证不同传感器的信号可以强同步？”

此外，一位在硅谷供职多年的仿真专家认为，现在还没有哪个公司能真正做到超实时仿真，“能做到实时就不错了”。 在这位专家看来，要提高仿真效率，大规模并行仿真是更可取的方案。

而安宏伟认为，时间加速能力取决于每个实例上的超实时水平、总实例数及场景的质量。“实际上，对于云算力仿真而言，单实例上的超实时水平并不很重要，核心还是关注该实例上仿真的质量需要。”

轻舟智航仿真专家甚至认为，“加速倍数”这个说法其实不太成立。因为，仿真中的时间跟真实世界的时间之间，并不是一个简单的倍数关系，它们甚至没有关系。在实践中，更多地是用技术的手段来降低算力的占用，提升时序调度效率，来达到运算时间的提升。

在真实路测中，车辆行驶的连续的，你不会说这是个corner case，我跑一下，那里不是corner case，我就不跑了，而是跑了很长一段路，再在其中筛选出corner case；在仿真平台上，工程师们通常只截取了跟corner case有关的那些片段（即“有效场景”），处理完这个事情后，时钟就会跳到下一个时间段，而不需要在无效场景上浪费时间。

因此，在做仿真时，如何高效地筛选出有效场景，是比时间加速倍数更重要的事。

说到这里，我们便可以发现，尽管时间加速看上去不明觉厉，但要增加在仿真平台上的虚拟行驶里程，其实不能主要依赖时间加速，关键还是得靠“多实例并发”，其实就是要做云算力仿真，增加服务器和仿真实例的数量。

可否支持在云端的高并发、支持多大规模的并发，这个难点到底在哪里？是不是只靠堆服务器就行了？

听起来没错，但问题在于，服务器的规模每增加一个数量级，就会带来新的问题——

（1）服务器的成本挺高的，每台服务器几十万，如果有一百台服务器，直接成本就是几千万，理想的解决方案是上公有云，但国内的主机厂接受公有云还需要一段时间；

（2）大规模并发的情况下，传感器的原始数据极其庞大，这些数据不仅存储成本很高，而且传输也很难——在不同的服务器上做数据的同步会出现延迟，进而影响到智行效率；

（3）每一路跑的并不是连续交通流场景，而是很某个很简短的片段，可能只有30秒，但通常是上千路并行，如果1000路有1000个算法在1000个场景上跑，这对仿真平台的架构设计提出了很严峻的挑战。（某仿真公司CEO）

不过，针对上述最后一条，安宏伟的说法是：这是云算力仿真的基本需求，对我们来说并不算挑战，苏州相城区的云仿真平台早在2019年就已解决了这个问题。此外，云仿真平台跑的场景也会有数公里的连续的复杂/组合场景，相城的Robo-X仿真测评体系里就包括这类（组）场景。基于这类场景可以进行虚拟仿真下“接管”的测试。