模式 1：无服务器 ML 推理管道 - AWS 规范性指导
无服务器机器学习推理模式：轻量级、事件驱动、可扩展用例：客户反馈的情绪分类无服务器 ML 推理管道的商业价值

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

模式 1：无服务器 ML 推理管道

在许多企业环境中，团队需要将 AI 注入运营工作流程，例如，对用户反馈进行分类、检测传入遥测中的异常情况或对风险进行实时评分。这些由机器学习 (ML) 驱动的功能通常嵌入在面向客户的应用程序、移动应用程序或内部自动化系统中。

但是，传统的 ML 推理工作负载通常需要以下内容：

  • 预配置的计算，例如亚马逊弹性计算云 (Amazon EC2) 实例和容器

  • 手动扩展策略

  • 即使处于闲置状态也能保持基础架构

  • 复杂的部署和监控管道

这些要求会产生以下结果：

  • 用于零星推理的资源未得到充分利用

  • 模型版本控制、故障转移和自动缩放的操作复杂性

  • 成本增加，特别是对于低频或突发性工作负载

此外，工程团队通常缺乏专业的机器学习基础架构技能来维持这种复杂性，人工智能的采用在原型阶段停滞不前。

无服务器机器学习推理模式：轻量级、事件驱动、可扩展

无服务器机器学习推理管道模式使用完全托管的事件驱动 AWS 服务 来消除基础架构负担。这种方法使推理工作流程能够仅在需要时触发和运行，并根据需求自动扩展。

这种模式非常适合执行以下任务：

  • 运行在 Amazon SageMaker 或本地训练的轻量级机器学习模型。

  • 近乎实时地执行分类、评分或转换。

  • 在微服务或数据摄取管道中嵌入机器学习逻辑。 APIs

参考架构按如下方式实现每个层：

  • 事件触发器 — 使用 Amazon API Gateway 处理用户请求，使用亚马逊 EventBridge处理商业活动，使用 Amazon S3 处理数据上传。

  • 处理层-AWS Lambda用于标准化输入、验证架构和丰富元数据的工具。

  • 推理层-部署SageMaker 无服务器推理端点以执行分类、回归或评分。

  • 后处理-使用 Lambda 格式化响应、存储日志和发出新事件。

  • 输出-实现 API Gateway 以将结果返回给用户或将事件发布到以 EventBridge 进行下游处理。

注意

通过使用 AWS Cloud Development Kit (AWS CDK) 或 ()、版本化和可观察，整个管道可以部署为基础设施即代码 AWS Serverless Application Model (IaC AWS SAM)。

用例：客户反馈的情绪分类

一家全球电子商务公司希望对产品评论或支持票证上留下的客户反馈进行分类，以尽早发现批评者并确定后续行动的优先顺序。分类系统必须满足以下要求：

  • 流量变化很大，活动期间会出现峰值。

  • 推理必须实时进行，才能与支持分类系统集成。

  • 该模型是轻量级的（推理延迟 100 毫秒），并且经过了训练。 SageMaker

对于此用例，无服务器推理管道解决方案包括以下步骤：

  1. 用户反馈将提交给 API Gateway，然后由后者将其发送到 EventBridge。

  2. Lambda 对文本负载进行预处理和格式化。

  3. SageMaker 无服务器推理端点运行情感分类模型。

  4. Lambda 将 “负面” 结果路由到支持升级队列。

  5. 结果记录在 Amazon DynamoDB 中，用于分析和再训练。

无服务器 ML 推理管道的商业价值

无服务器 ML 推理管道在以下领域提供了价值：

  • 可扩展性 — 无需手动调整即可自动扩展到每分钟数千个推论

  • 成本效益 — 仅为空闲期间的执行时间付费，成本为零

  • 开发人员速度 — 使团队无需管理基础设施即可部署 end-to-end AI 推理工作流程

  • 弹性-提供内置重试、日志记录和无状态执行，以确保稳健性

  • 可观察性 — 使用 Amazon CloudWatch 监控模型使用情况、输入和输出量以及延迟 AWS X-Ray

无服务器机器学习推理管道是许多希望以渐进和务实的方式采用 AI 的组织的切入点。这是实现以下目标的理想模式：

  • 实时、低延迟 AI

  • 经济高效地部署传统 ML 模型

  • 与现代无服务器和事件驱动系统无缝集成

通过抽象化基础架构，团队可以专注于业务逻辑、模型准确性和提供真正的价值，而不会牺牲运营控制或可扩展性。