提供实时机器学习预测服务简介

实时机器学习越来越受到用例的关注，例如使用编码为特征的近期会话活动的实时推荐模型、音乐会门票预订/拼车应用程序中使用的激增价格预测算法等。在大多数实时用例中，一个人类用户等待您的预测结果或效果在移动应用程序中可用或显示在网页上。 因此，在提供实时预测时，对响应时间的重视至关重要。

保持低响应时间的问题因迫切需要添加诸如可观察性、A/B 测试、深度学习模型推理、流式高维特征集等功能层而变得更加复杂。

机器学习管道示例

下面是实时推理设置中机器学习管道的简化图示。

A real-time machine learning inference template

吨 推理管道是上述模块的同步部署，分布在多个微服务中。由于每个模块都花费了总响应时间的一小部分，让我们仔细研究一下为什么每个模块都应该存在于推理管道中的情况。

API网关： 需要 API 网关将传入请求路由到一个或多个下游服务。 API 网关服务从“路由实现”中抽象出“路由执行”。 “路线执法” 当您的推理管道包含诸如生产中多个模型的 A/B 测试、实施金丝雀测试、跨模型的流量拆分等功能时，它变得重要/非平凡。

数据整理： 传入推理请求的有效负载通常必须被解析和转换以生成 请求时间特征 .要优化此模块，请使用矢量化转换将您的代码与部署环境的底层硬件架构相匹配，并利用 GPU 优化库。

模型推断： 即使托管在最新的 GPU 上，深度学习模型也可能需要几十毫秒才能提供对高维特征的预测。需要尽量减少神经网络中的层数，看看我们是否能够维持模型性能。还有诸如量化之类的技术可以调整特征精度的容差并提高推理性能

结构化流媒体： 在请求处理时生成所有特征可能是不可行和/或不必要的。复制转换逻辑的复杂性、对广泛聚合的需求以及特征的时间敏感性都可能在要求使用异步低延迟管道将结构化数据流式传输到高可用性存储系统（例如雷迪斯

查询/查找功能： 存储在缓存或其他可用存储中的流式特征预计将在亚毫秒时间内被查询。这在实际设置中会变得很棘手，因为在读取缓存的同时填充缓存。因此可用性可能是高度不稳定的并且依赖于有效地更新缓存。需要监视查询查找失败和延迟，即使它们是几毫秒的数量级。

可观察性和日志收集： 响应时间开销几乎总是不均匀地分布在推理管道的各个部分。无论您是继承现有模型进行优化还是从头开始，推荐的方法是在开始优化之前先让模型在端到端生产模拟设置中服务。部署后，我们开始观察推理管道各个部分的记录性能。这种方法使我们能够将注意力集中在对提高绩效进行投资最重要的管道部分。因此，需要以下内容：

1. 推理和路由过程发出半结构化的日志数据 异步 到本地存储。记住不要因为 Flask 在服务架构中的流行而认为异步是理所当然的。

2. 将标准化的日志收集器进程独立部署到托管推理和路由服务的 pod 中，而不会花费大量的请求处理性能。

实时机器学习管道汇集了不断发展的多学科复杂性层，使得精确设计数十毫秒的响应时间变得更加困难。这需要全面的设计工作来优化管道的速度，就像优化模型的准确性一样。

[

Mlearning.ai 提交建议

如何成为 Mlearning.ai 上的作家

媒体网

](/mlearning-ai/mlearning-ai-submission-suggestions-b51e2b130bfb)

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/15424/46360508