持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第27天，点击查看活动详情
不久前，我们的产品负责人 Juha Kiili 在A I Infrastructure Alliance 组织的模型服务活动上谈到了批量推理与在线推理的比较，以及哪个更适合项目。在这篇文章中，我们总结了他演讲中的关键要点，希望尽可能让大家更多地了解延迟推理的好处。
重温术语
对于不同类型的推理，有一个既定的命名约定，这些约定非常简单。批量推断用于批量交付值，例如：每天一次。在线推断适用于按需配送，就像在食品配送服务中根据您的订单配送比萨饼一样。
但是，我们建议以不同的方式命名。 你所知道的批量推理，我们称之为延迟推理。 在线推理和边缘推理都是实时推理。
为什么呢？ 好吧，它更有意义，因为它更好地描述了实施过程中发生的事情。 从这一点开始，您将阅读的所有内容都将证明这一点。
灰色区域
大多数常见的机器学习场景落在延迟推理和实时推理这两个极性之间。
在光谱的一端，我们可以找到只能作为延迟推理完成的场景。 例如，天气预报。 这些模型非常慢。 因此，期望它们是实时的是不现实的，因为，模拟需要数小时。
另一方面是实时推理，例如：聊天机器人。 它们总是需要成为实时模型。 在几秒钟内没有响应的聊天机器人是没有用的。
但是很多情况都停留在中间的灰色区域，延迟和实时选项都是可能的。如果您发现您的案例属于该领域，您需要问问自己您选择了哪个选项。这里有一些关于他们的事情需要知道。
不同推理选项的实现
边缘推理与在线推理
在边缘设备，即一些物联网设备或移动应用程序中，部署机制很复杂，但实际推理非常简单。那是因为应用程序和模型是本地的，它们在同一个设备中，所以，一旦你部署它就很容易进行推理。
对于在线它是一个不同的故事。模型和应用程序之间存在分离。所以基本上，你有互联网介于两者之间。这意味着您经常需要某种特定于模型的 API。然后使用某种 Web 服务器或 Web 服务为模型提供服务。尽管如此，它仍然非常简单：它是一个无状态的 Web 服务器，简单的请求和响应。
计划在线推理与延迟在线推理
对于延迟资产，有两种方法可以进行推理。
第一种方式，有一个计划调度的模型，比如说每天运行一次或每周运行一次。它会填充缓存并且应用程序正在使用缓存。它不直接与模型交互。
但是还有另一种方式，延迟在线方式，它甚至还不是一个传统的技术术语。尽管如此，Valohai 的客户还是经常使用这种方法，这是它的工作原理。
如果模型很慢或很大，那么实时进行推理是不现实的。但是，如果您仍然想拥有这种类型的在线 API 怎么办？您所做的是使用 MLOps 平台 API 并利用它进行推理。
一个很好的例子是 CT 扫描，因为医学图像的尺寸很大。只是上传可能需要太多时间才能实现实时。实际的管道可能非常复杂。该应用程序实际上调用了 MLOps 平台 API 并触发了推理。它可以挖掘中间结果或最终结果。它有点像实时和批处理之间的混合体。
这种情况很常见，但实际上并没有太多讨论。也许这就是它仍然没有名字的原因。
实时总是更好吗？
如果你看看实时推理的好处，你得到的是最新的数据，即刻的某种预测，而且它是无状态的。 请求和响应非常简单。 由于所有这些好处，这种设置通常会诱使人们认为实时总是更好。
然而！ 在 Valohai，我们相信它并不总是更好，如果你有这样的选择，默认应该是延迟推理。 让我们看看为什么它比实时推理更受欢迎。
延迟推理的好处
解决生产问题
特别是在线推理，这是最常见的实时方式，你总是会在生产环境和开发环境之间分离。 在训练和进行推理时，这对于特征来说尤其棘手。 您能否在生产环境中使用与训练模型时相同的代码进行数据转换？ 它会满足延迟标准吗？ 您最终可能会在开发和生产中使用略有不同的特征。
从 Juha 20 年的经验来看，开发环境和生产环境分离的设置会带来很多痛苦：如果一个人不能相信开发环境与生产环境匹配，那有什么办法呢？ 真的值得信任吗？ 这是一个巨大的问题，也是一个巨大的危险信号。
最新的解决方案是特征存储。它们可以非常有效地解决这个问题，但需要付出代价。因此，实际问题应该是“我们甚至需要实时推断吗？”如果不需要实时推理，则不需要特征存储。少了一个需要设置和管理的系统，这将会更简单。
在延迟推理中，您的生产和开发环境是相同的。 在 Valohai，我们将其称为“在生产中构建”---相同基础架构和相同平台可用于您的训练和推理。 这真的很强大。
避免模型大小和延迟问题
如果您正在进行延迟推理，您的模型可以是任何东西，您不需要针对您的生产对其进行优化。另一方面，如果您希望您的模型是实时模型，那么您必须满足所有延迟要求。您总是需要为生产构建不同的镜像，注意内存要求等。
立即可用的最小可行产品
我们认为，即使有可能，也不应该在笔记本电脑上进行推理生产。如果您正在进行延迟推理，您也可以使用您用于生产训练的任何基础设施。然而，为了实现实时性，您总是需要设置某种web服务或服务器。
简单的部署机制
实时的部署机制大多是复杂的。您需要构建某种镜像，并且需要将其部署到集群中。然后你需要有影子部署、金丝雀部署或所有那些花哨的东西。
但是对于延迟推理，它可以像将您的模型标记为您当前的生产模型一样简单。下次运行批处理管道时，您将使用新的标记模型而不是以前的模型。
易于监控并有容错率
简而言之，在延迟推理中，火灾被延迟了。但对于实时而言，火灾也会实时点燃，您需要立即做出反应。
监控实时模型是一个完全不同的故事：它是 7 x 24 全天候待命的警报。你会很快得到警觉疲劳。但是，如果您的管道已安排好，比如说每周一次，您就不会太担心它了。它运行，你得到日志。如果有错误，你有时间修复它，所以没有压力。
同样，如果你搞砸了批处理管道，在某种程度上它仍然没问题。你可以修复它，没有人会知道。但如果你搞砸了你的实时推理，问题就会立竿见影，痛苦也会立竿见影。
结论
假设您发现您的项目处于延迟和实时推理这两个极端之间的灰色区域，您可以选择其中任何一个，问问自己是否可以延迟推理。
如果可以的话，你应该！仍然有错误和痛苦需要处理，但是你有更多的回旋余地和安心作为奖励。
