构建实时应用的人工智能推理引擎的挑战

当人们意识到利用GPU技术训练深度学习模型比用通用CPU完成一个周期的模型训练要快得多时，人工智能(AI)的热潮开始了。(看看这个信息Quora线程更多细节)。

自2016年以来，当NVIDIA、Intel等GPU制造商创造了他们的第一个人工智能优化GPU时，大多数人工智能的发展都与如何训练模型尽可能的精确和预测性有关。2017年底，许多企业和初创公司开始考虑如何将机器学习/深度学习(ML/DL)用于生产。成功的开源项目MLFlow和Kubeflow旨在通过管理整个人工智能生命周期，将人工智能从研究和科学阶段转移到解决现实世界的问题。他们引入了类似的方法来管理机器学习管道的生命周期，正如下面来自Semi Koen的图表所展示的那样不是另一篇关于机器学习的文章!博客):

这幅图是根据Semi Koen的作品改编的不是另一篇关于机器学习的文章!博客文章。

在非常高的层次上，任何ML管道中最关键的步骤之一称为人工智能服务，这一任务通常由人工智能推理引擎执行。AI推理引擎负责上图中的模型部署和性能监控步骤，并代表了一个全新的世界，它将最终决定应用程序是否可以使用AI技术来提高运营效率并解决实际业务问题。

为实时应用构建人工智能推理引擎的挑战

自从引入RedisAI在RedisConf 19，我们一直在与Redis企业客户合作，以更好地了解他们的万博体育彩挑战，将人工智能生产，更具体地说，他们的架构需求从一个人工智能推理引擎。在与许多客户进行多次互动后，我们提出了以下列表:

快速的端到端推论/服务我们的客户已经严重依赖Redis作为他们即时体验应用程序的引擎。他们要求将AI功能添加到他们的堆栈中，对他们的应用程序性能几乎没有影响。
没有停机时间:由于每个事务都可能包括一些人工智能处理，客户需要维护相同级别的SLA，对于关键任务应用程序，最好是5 - 9级以上，使用经过验证的机制，如复制、数据持久性、多可用区/机架、active-active地理分布、定期备份和自动集群恢复。
可伸缩性:在用户行为的驱动下，我们的许多客户的应用程序都是为峰值使用而构建的，它们需要基于预期和实际负载的灵活性来扩展或扩展AI推理引擎。
支持多平台:人工智能推理引擎必须能够为TensorFlow或PyTorch等先进平台训练的深度学习模型提供服务。此外，机器学习模型，如随机森林和线性回归仍然为许多用例提供良好的可预测性，应该包括在内。
易于部署新模型:客户希望根据市场趋势，或为了开发新的机会，经常更新他们的型号。更新模型应该尽可能透明，并且不应该影响应用程序的性能。
绩效监控和再培训每个人都想知道他们训练的模型执行得如何，并能够根据它在现实世界中的表现来调整它。因此，需要AI推理引擎支持A/B测试，将模型与默认模型进行比较。客户还希望该系统能够提供对其应用程序的人工智能执行情况进行排名的工具。
部署无处不在:客户希望在云中构建和培训，并在任何地方提供服务/推断:在特定供应商的云中、跨多个云、本地、混合云或边缘。因此，AI推理引擎应该是平台无关的，基于开源技术和众所周知的部署模型，可以运行在cpu、最先进的gpu、高端计算引擎，甚至微型树莓派设备上。

3种实现快速端到端人工智能推理/服务的方法

我们在Redis的首要任务是帮助我们的客户和用户以一毫秒的速度解决复杂的问题。因此，让我们来看看列表中的第一个挑战——快速端到端推断/服务——并看看如何在将AI添加到生产部署堆栈时实现这个目标。

1.新的人工智能推理芯片组可以提供帮助，但只能解决部分问题

有大量的报道(例如在这里和在这里)，关于芯片组厂商如何努力在2021年前提供高度优化的推断芯片组。这些芯片组旨在通过增加进程的并行性和内存带宽来加速诸如视频、音频和增强现实/虚拟现实等推理处理。但只加速交易链的人工智能处理部分可能只能带来有限的好处，因为在很多情况下，人工智能平台应该通过分散在多个数据源上的参考数据来丰富。用参考数据检索和丰富人工智能的过程可能比人工智能处理本身慢几个数量级，如这个事务评分示例所示:

让我们来看看这里发生了什么:

步骤1:事务评分应用程序从与之合作的商家那里收到了一个信用卡评分请求。
步骤2 - 3:应用服务器对一个或多个数据库服务执行多个数据库查询，以检索该事务的引用数据。在这种情况下，引用数据可以包括用户配置文件、商家配置文件、位置配置文件等。
步骤4:事务评分应用程序将事务数据与参考数据进行矢量化，并将其准备给AI处理引擎。
步骤5:向量化后的数据被发送给AI引擎。
步骤6:通过/失败的响应将被发送回应用服务器。
第七步:通过/失败的响应将被发送回商家。

如上所示，即使我们将人工智能处理提高一个数量级(从30ms提高到3ms)，数据中心内的端到端事务时间仍然保持在500ms左右，因为人工智能处理占总事务时间的不到10%。

所以等用例事务评分,推荐引擎,广告竞价,在线定价、欺诈检测,和许多其他的人工智能推测时间主要与带和准备相关参考数据智能处理引擎,新的推论芯片组只能略微提高端到端事务时间。

2.运行数据所在的人工智能推理平台

由于延迟敏感应用程序的大部分参考数据存储在数据库中，因此在数据所在的数据库中运行AI推理引擎是有意义的。话虽如此，这种方法也存在一些挑战:

1.如果应用程序数据分散在多个数据库中，那么AI推理引擎应该运行在哪个数据库上?即使我们忽略部署的复杂性，决定在每个数据库上运行一个人工智能推理引擎的副本，当一个应用程序事务需要从多个数据库中获取引用数据时，我们如何处理这种情况?最近的一项调查显示Percona很好地演示了多数据库如何代表大多数应用程序的部署架构:

2.为了实现低延迟的AI推断需求，参考数据应该存储在内存中。许多人认为，通过在现有数据库之上添加缓存层，这个问题可以很容易地解决。但是缓存有其自身的局限性。例如，当应用程序没有在缓存中找到数据，被迫从基于磁盘的数据库查询数据，然后用最新的数据更新缓存时，在缓存丢失事件中会发生什么?在这种情况下，破坏端到端响应时间SLA的可能性非常高。如何确保数据库更新与缓存同步并避免一致性问题?最后，如何确保缓存系统具有与数据库相同的弹性级别?否则，应用程序的正常运行时间和SLA将由链中最薄弱的环节——缓存系统来驱动。

为了克服维护独立缓存层的需要，我们认为部署AI推理引擎的正确架构选择是内存数据库。这避免了缓存丢失事件期间的问题，并克服了数据同步问题。内存数据库应该能够支持多个数据模型，允许AI推理引擎尽可能接近每种类型的参考数据，避免在多个数据库和缓存系统之间构建高弹性。

3.使用专门构建的、数据库内的、无服务器的平台

很容易想象，在具有多个数据模型的内存数据库中运行AI推理引擎可以使对延迟敏感的应用程序受益，从而解决这些性能挑战。但有一件事是失踪在这个谜题:即使所有坐在一起在同一个集群与快速访问共享内存,谁负责收集参考来自多个数据源的数据,处理它,并为人工智能推理引擎,同时最小化端到端延时吗?

Serverless平台,如AWSλ，通常用于操作来自多个数据源的数据。用于人工智能推断的通用无服务器平台的问题是，用户无法控制代码实际执行的位置。这就导致了一个关键的设计缺陷:你的人工智能推理引擎被部署在尽可能接近你的数据所在的地方，在数据库中，但为人工智能推断准备数据的无服务器平台运行外部数据库．这打破了让AI更接近您的数据的概念，并导致前面讨论的相同延迟问题，即当AI推理引擎部署在数据库之外时。

只有一种方法可以解决这个问题:一个专门构建的无服务器平台，它是你的数据库架构的一部分，并且运行在你的数据和AI推理引擎所在的共享集群内存上。

回到事务评分的例子，这是如果我们应用这些原则，解决方案看起来有多快(和简单):

人工智能在生产

将人工智能投入生产会带来在培训阶段不存在的新挑战。解决这些问题需要许多架构决策，特别是当一个对延迟敏感的应用程序需要在每个事务流中集成AI功能时。在与已经在生产中运行人工智能的Redis客户的交谈中，我们发现，在很多情况下，交易时间的很大一部分都花在了将参考数据带到和准备到人工智能推理引擎上，而不是人工智能处理本身。

因此,我们提出一个新的人工智能推理引擎架构,旨在解决这个问题通过运行系统在内存中的数据库内置支持多种数据模型,并使用专用,低延迟,数据库内serverless平台查询,做好准备,然后把数据人工智能推理引擎。一旦这些因素就位，对延迟敏感的应用程序就可以从在专用推理芯片组上运行人工智能中受益，因为人工智能处理占用了整个事务时间的更大一部分。

最后，将AI添加到您的生产部署堆栈中应该非常小心。我们认为，依赖于延迟敏感应用程序的企业应该遵循这些建议，以防止用户体验因AI推理引擎的缓慢而降低。在人工智能早期，通用cpu的缓慢性能给开发人员和研究人员在培训阶段带来了阻力。万博最新版本下载苹果ag万博下载当我们期待在生产中部署更多的人工智能应用程序时，构建一个强大的人工智能推理引擎将最终在即将到来的人工智能繁荣中区分出赢家和输家。