虽然推理加速器最初用于数据中心，但它们已经迅速发展到应用程序的边缘推理，如自动驾驶和医学成像。通过这种转变，客户发现，同样的加速器，在数据中心处理图像很顺利，但移到边缘推断方面却显得糟糕。其实原因很简单：一个处理数据池，而另一个处理的是数据流。
当你在batch ＝ 1时进行批处理时，池子里待处理的batch就会很多。在数据中心，客户通常是数据的处理池，比如被标记的照片。其目标是用最少的资源和功耗以及最佳的延迟来处理尽可能多的照片。
另一方面，边缘推断应用程序需要处理数据流。我们通常的相机每秒拍摄30帧，每帧通常是200万像素。通常情况下，每幅图像需要33毫秒，每秒大约30帧。当你有一个图像从一个流进来，它如何被处理取决于它需要做什么。
例如，使用推理进行零售分析的商店可能会计算给定时间排队的人数。在这个例子中，他们真的不需要几个小时甚至几天的结果。然而，如果你驾驶一辆使用自动驾驶功能的汽车，你只有毫秒来处理图像，否则你可能会撞到人。虽然在这两个例子中，相机每3毫秒生成1帧图像，但使用的推理加速器非常不同。
让我们看看数据流发生了什么。
首先，您需要清理图像以去除诸如光线条纹之类的东西，然后应用推理。当推理完成后，您需要采取一个行动，根据你正在处理的活动，所有这些都需要在特定的时间内发生。如果你不需要几个小时的结果，你可以对图像进行批处理。在这种情况下，延迟就无关紧要了。重要的是用最少的成本和能量处理最多的图像。
最常犯的一个错误就是在选择边缘推断解决方案时没有考虑延迟和流媒体吞吐量。比方说，你有一台每秒能处理30帧的推理加速器，另一台每秒能处理15帧。
大多数人自然而然地认为每秒30帧的解决方案更好——其实你错了。
每秒30帧的加速器可能会获得比较可观的吞吐量，原因是它有三个引擎，每个引擎都有不同的延迟。最典型的是英伟达Xavier推理加速器。Xavier的深度学习引擎处理图像大约需要300毫秒，GPU大约需要90毫秒。如果客户有两个深度学习引擎＋GPU都在运行，他们可能会在数据池中获得显著的吞吐量。
但是，如果它需要从数据流一次处理一个图像，它就不能有效地使用深度学习引擎，吞吐量会显著下降。在这种情况下，你需要观察哪个执行单元的延迟最短，即GPU的延迟为90毫秒。分割成1000毫秒就是每秒的帧数，这意味着这个吞吐量实际上只有每秒10帧（而不是宣传的每秒30帧）。
x Logix购买了一台Xavier AGX，并将其配置为NX模式（该软件测量芯片的功率，当功率超过15W时，会调低芯片的时钟，以防止芯片过热）。
然后，我们通过Nvidia Xavier NX软件流运行三个模型（YOLOv3加上我们客户的两个模型），并在芯片上运行，测量每张图像的延迟。我们还通过自己的InferX X1性能评估器运行了相同的模型。
显然，Nvidia不能为我们自己客户的机型发布基准测试，但YOLOv3的数据是在Xavier AGX上发布的，而不是在NX上发布的——而且他们发布的数据是使用GPU和两个DL加速器的综合吞吐量。对于Batch＝ 1，GPU有可接受的延迟。
