快速的未来即将登陆你所在城市内的活动。
加入我们参加 Redis 发布活动
分享
随着关键任务型现代应用加入越来越多机器学习技术，他们将会遇到一些令人惊讶的复杂挑战。这些挑战主要围绕处理实时模型服务需求并监控这些新特性对最终用户造成的影响。
我们很高兴宣布 Redis 的 AI 服务引擎 RedisAI 已正式推出。RedisAI 的构建以两个核心目标为基础：
RedisAI 旨在运行在数据所在的地方，从而减少了延迟并提升简洁度，其用例包括事务评分和欺诈检测、推荐引擎个性化等等。要详细了解常见用例以及何时应用它们，请参阅RedisAI 产品页面。
此篇博文旨在帮助开发者和架构师了解 RedisAI 的底层情况，并了解它是如何解决上述目标的。我们 将会深入了解架构，并分享一个突出的实际 AI 问题——实时检测金融交易中的欺诈所创建的基准。这些基准表明与其他模型服务平台相比，如果整体端到端时间并未因推理本身而增加，则 RedisAI 可将速度提升至 81 倍。
大多数人工智能 (AI) 框架都随附了用于执行使用它开发的模型的运行时，而针对它们提供服务的常见做法是围绕它们构建一个简单服务器。由于 RedisAI 实化为Redis 模块，因此它将自动受益于服务器的能力，包括 Redis 的原生数据类型和健壮的客户端生态系统，以及其持久的稳定性和集群，更不用说 Redis 模块提供的灵活性以及 Redis Enterprise 支持提供的安心。当然，这里还有 Redis 的高可用性(99.999%) 和无限线性可扩展性。
因为 Redis 是一款可扩展内存内数据结构服务器，RedisAI 使用它来存储其机器学习 (ML) 本地数据类型。RedisAI 支持的主要数据类型是张量，它是 ML 数据的通用表示方式。
此外，RedisAI 还添加了两个数据结构（模型和脚本）用于模型运行时功能。模型通过一个支持的深度学习 (DL) 或机器学习框架后端表示一个计算图，并设置有关它们应在哪个设备（CPU 或 GPU）上运行以及后端特定参数的信息。RedisAI 具有几个集成后端，包括 TensorFlow、Pytorch 和 ONNXRuntime。
脚本可以在 CPU 和 GPU 上运行，让你可以通过TorchScript（一种用于张量操作的类似 Python 的特定领域语言 (DSL)）来操作张量。这让你可以在执行模型之前预处理你的输入数据，并在执行之后处理结果，例如用于集成不同的模型以提高性能。
由于张量存储在 Redis 服务器的内存空间中，因此 DL/ML 后端库和脚本可以快速访问它们，而延迟极小。这种数据局部性让 RedisAI 在提供模型时能够提供最佳性能。这也使其成为在生产环境中部署 DL/ML 模型并允许任何应用程序使用它们的理想选择。
重要的是，此架构并不绑定到单个后端，让你可以将你的后端选择（通常由数据科学家做出决策）与使用这些模型提供功能的应用程序服务分离开来。切换模型（即使模型是在不同后端中创建的）就像在 Redis 中设置一个新键一样简单。
其他重要的 RedisAI 功能包括其自动批处理支持和DAG（就像有向无环图）命令。使用自动批处理，来自多个客户端的请求可以自动透明地批量处理成单个请求，以在提供服务期间提高 CPU/GPU 效率。新的AI.DAGRUN命令支持在单次执行传递中规定其他 RedisAI 命令的组合，其中中间键永远不会实际化到 Redis。
为了对 RedisAI 进行基准测试，我们创建了一个 基准测试套件，其中包含一个 基于 Kaggle 数据集的欺诈检测用例，并扩展了参考数据。此用例旨在根据匿名化信用卡交易和参考数据来检测欺诈交易。
我们使用此基准测试来比较四种不同的 AI 服务解决方案
我们希望以一种公正的方式涵盖所有解决方案，帮助准用户就最适合其案例的解决方案（无论是否具有数据局部性）做出明智的决定。
在附录中阅读有关优化的更多信息。
查看附录
最重要的是，我们希望减少此基准测试中参考数据的影响，以便它设置RedisAI 可能实现的下限，具体方法为：
比较不同解决方案的基准延迟
第一个测试比较没有参考数据的解决方案，以测试单客户端性能。此基准测试中的所有服务解决方案实际上都是围绕其核心库的提供服务的包装器。安装和数据流在此处显示
下表显示了在基准测试客户端上测得的端到端推理时间。此测试设置了基准。它显示出与其他服务解决方案相比，RedisAI 不会对运行型号造成任何开销。在某些情况下，它经过了更好的优化，这在很大程度上归功于选择的编程语言（RedisAI 使用 C/C++ 编写，TensorFlow Serving 使用 C++ 编写，TorchServe 使用 Java 编写，而常见的 REST API 服务器使用 Python 编写）。
带有参考数据的延迟影响
既然我们已经设定了基准，让我们看看当模型需要 1KB 参考数据时延迟会如何受到影响。对于 TensorFlow Serving、TorchServe 和 Gunicorn，参考数据将存储在不同的主机中。
如上所述，对于 RedisAI，参考数据位于 Redis 内，已经作为张量。这就是安装更简单的原因
下表记录了第二次测试的结果，表明 RedisAI 将端到端推理延迟降低了至多 8 倍，与其他模型服务解决方案在单个客户端的使用性能上使用参考数据时相比。与此同时，q99 数值显示，RedisAI 提供的解决方案比其他任何解决方案都稳定得多：
这些解决方案如何处理规模？
在分析了单个客户端使用性能之后，下一个问题是这些解决方案如何在高并发场景中扩展？我们设计了第三项测试，在测试中将客户端数量从 16 增加到 160，一次增加 16 个客户端。
对于包含 100 万个不同的信用卡交易的数据集，常见的 HTTP 服务器解决方案的限制约为每秒 2.1 万次完整推理循环，TensorFlow Serving 的限制约为每秒 4 万次完整推理循环，TorchServe 的限制约为每秒 5 万次完整推理循环，RedisAI 的限制约为每秒 19.2 万次完整推理循环。
在相同硬件上并基于相同模型进行服务时，RedisAI 处理的推理比 TensorFlow Serving 多 4.8 倍，比 TorchServe 多 4 倍，比常见 Web API 多 9 倍，如下所示：
考虑每个不同的模型服务解决方案的最佳结果，注意虽然其他模型服务器在每秒大约 5 万次推理时过载，但 RedisAI 以稳定的亚毫秒延迟执行，并且不需要将更多的虚拟机添加到集群中，每秒可进行高达 19 万次推理，如下面的图表所示
如果你将吞吐量和推理延迟的加速因子联系起来，RedisAI 相比于 TorchServe 快了 16 倍，相比于 TensorFlow Serving 快了 25 倍，相比于常见的 HTTP 服务器快了 81 倍。这意味着在相同的底层硬件上，RedisAI 在提供总共 100 万次推理时可以高效 81 倍，如下所示
基准分析
这个最初的基准表明，数据局部性对基准以及任何现实生活中的 AI 解决方案都有巨大的影响。
注意，在这个基准中参考数据的影响已被大大降低，而且如前所述，该基准只设定了可能性的下限。
我们计划增强我们的基准并创建更多与许多现代部署和传统部署相一致的设置，以便你能轻松了解你的应用程序架构的潜在加速。
最后，正如在之前的图表中看到的那样，对于高负载/高并发用例，没有比 RedisAI 更好的选择了，因为 Redis 是唯一在并发增加时仍能保持亚毫秒延迟和稳定且稳定的结果的模型服务器。
RedisAI 能够取得如此惊人的结果，主要是因为它是从头开始构建，以实现高性能。它无缝插入 Redis，利用 Redis 的核心特征进行扩展，同时避免 Redis 已解决的通常高负载/高并发工作负载瓶颈。
RedisAI 快速，稳定，且支持多个后端 - 我们一直在不断努力增强其功能。（在即将发布的博客中，我们计划重点介绍如何使用 ML-flow 的支持部署模型，以及如何监视生产环境中的模型。）RedisAI 表明，我们可以在 Redis 之上创建功能丰富且高性能的模型服务器。我们期待听到您的反馈，因此请联系我们或在 GitHub 或 新的 RedisAI 社区论坛 中发表评论。
