Unitary 使用 HAQM EKS 将人工智能审核范围扩大到每天 2,600 万个视频

Unitary 成立于 2019 年，专门研究多模态机器学习模型，用于识别海量数字内容中的有害文本、图片和视频。Unitary 首席架构师 Matt Camp 表示：“单靠人工审核或人工智能审核都无法完成全部工作，平台必须将两者相结合。”“我们提供混合解决方案，能以更短的时间、更高的准确性和更低的成本捕获有害内容。”

Unitary 产品的第一个版本基于 HAQM Elastic Compute Cloud（HAQM EC2）构建，可提供安全且可调整大小的计算容量，支持几乎所有工作负载。但是，要扩展到每天处理数百万个视频，就需要自我管理 1200 多个实例。对于三人组成的平台团队而言，这是巨大的挑战，因为大量的自我管理会增加运营开销和复杂性。

随着 Unitary 的人工智能模型不断改进，该公司需要处理的内容量很快超过了其初始基础设施所能处理的范围。2021 年，Unitary 决定在 HAQM EKS 上构建基于微服务、事件驱动的新架构。为实现有效的节点管理，AWS 团队建议采用开源 Kubernetes 节点生命周期管理器 Karpenter 和 HAQM EKS，以便按需扩展基础设施。

Unitary 使用 API 每天摄取多达 2600 万个视频，这些视频代表数十亿帧的内容和数千万小时的音频。当 Unitary 接收到要分析的视频时，在 HAQM EKS 上运行的多个微服务会将视频拆分为多个帧，提取音频，然后使用机器学习对视频内容进行分类。之后，会将提取到的视频部分存储起来。然后，Unitary 运行一系列人工智能和机器学习模型（其中一些模型可使用客户的安全策略进行训练），以检测视觉、音频和文本的多模态组合环境中有无有毒或不安全的内容。最后，这些模型会生成一份包含安全评分在内的摘要，Unitary 会将这份摘要提供给客户，以便客户制定明智的审核决定。

使用 HAQM EKS 和 Karpenter 进行扩展，Unitary 可以解锁所需的灵活性和速度，以适应不可预测的流量，同时保持正常运行时间。借助 Karpenter，该公司使用单一工具即可实现多项优化。例如，Karpenter 可在不中断系统吞吐量和稳定性的情况下，优雅地处理必要的 Kubernetes 节点中断，以进行安全更新和容器组调度。使用多个 Karpenter NodePool，Unitary 可根据客户不同的延迟要求为其提供不同的产品。此外，该公司正在开发亚秒级延迟解决方案，以便在有害图片上线前对其进行分类。由于 Karpenter 能够快速配置新的 Kubernetes 节点，Unitary 现已具备实现这些结果所需的响应能力。

这种灵活性可提高工作效率；在其他公司可能需要几个团队才能完成的工作，Unitary 只需几个人就能完成。由于 Unitary 不需要持续管理集群，因此其小型团队可以关注更重要的工作，如提升用户体验和开发新功能。Camp 表示：“即使在流量高峰期运行，每天使用 1,000 多个节点处理 2,000 多万个视频，整个团队也可以在国外待上 5 天，无需管理集群或与集群交互。”系统会自动替换运行状况不佳的节点，重新安排容器组，以确保没有未经审核的文本、图片或视频。此外，Unitary 还将其机器学习推理工作负载的容器启动时间缩短多达 80%。这意味着大型容器可以快速启动，以应对不断变化的客户流量模式。

使用 Karpenter，Unitary 已解锁跨区域的 HAQM EC2 实例智能选择的好处。该公司搭配使用 HAQM EC2 竞价型实例（让用户可以利用 AWS 上未使用的 HAQM EC2 容量）和 HAQM EC2 按需型实例（让用户可按小时或按秒支付计算容量，无需长期承诺）。除该工具的速度以外，Karpenter 的整合功能还使 Unitary 能够快速重新分配工作负载，并适应更具成本效益的资源的动态可用性。事实上，Unitary 估计，使用竞价型实例作为 GPU 推理基础设施，已在 18 个月内将成本降低 50-70%。

随着 Unitary 扩展其基础设施以满足日益增长的需求，对稳健可观测性的需求变得愈发重要。每个 Kubernetes 集群的节点数量可在几分钟内从 30 个波动到 1000 个以上。这种可变性意味着要使用开源监控和警报解决方案 Prometheus 处理日益增长的时间序列数据，以及收集更多样本。尝试多种可观测性工具后，Unitary 决定使用 HAQM Managed Service for Prometheus，该服务可为容器化系统提供高度可用、安全和托管的监控。因此，该公司无需管理 Prometheus 资源的扩展，即可收集到所需的指标水平。

Unitary 的客户通过生成 API 请求以提交内容进行评估，该请求由 HAQM EKS 上运行的微服务接收，并由负载均衡器进行管理。微服务会为内容分配作业 ID，并向客户确认将以异步方式处理请求。然后，将作业发布到 HAQM SNS 主题，该主题将消息发送到已订阅的 SQS 队列。此队列包含所有等待分类的内容的详细信息。这种架构支持错误处理，队列深度可作为 EKS 上运行的服务自动扩展的基础。媒体处理微服务从队列中检索作业，并评估已提交的内容类型。如果需要，还能将视频分解成帧并提取音频流。之后，在内容的不同模式上调用运行 Unitary 机器学习模型相关推理微服务：图片/视频帧（Triton 推理服务器）、从视觉效果（OCR 服务器）中提取的任何文本以及视频音频流（音频推理服务器），具体视情况而定。然后，媒体处理微服务汇总推理微服务的输出结果，根据客户内容审核策略对内容进行分类，并汇总结果。此摘要包括每个策略类别的安全评分或风险等级。结果摘要将通过 SNS 主题添加至其他 SQS 队列，并通过 webhook 发回给客户。结果写入器微服务会充当内容分类结果的记录系统，将结果保存至 Postgres 数据库。