google-cloud-platform - 如何在 gcloud 中进行“实时请求批处理”

Question

这是我的情况：

• 我有一个在 GPU 上运行的相当慢的张量流模型（每次预测需要 2 到 3 秒）
• 对单个“实体”的预测与对 8 个“实体”的预测大约需要相同的时间
• 这意味着只需在同一个请求中组合多个预测，我的效率就可以提高 8 倍
• 我在 AI 平台上有一项服务，为该模型提供请求
• 该服务适用于缓慢的请求率，但难以扩展（超过 4 QPS 的任何事情都无法处理）

那么我的问题是：是否有批处理实时客户端请求的标准方法/最佳实践：

• 收到请求时，稍等一下其他请求
• 一段时间后，或者当请求数量达到设定数量时，将请求以单个“批次”的形式转发到另一个服务。
• 如果流量低，延迟将在批次满之前到期，但由于流量低，这不是问题
• 如果流量高，延迟前批次就满了，客户端等待的时间会更少

我有一个几乎可以使用 app-engine + firebase 的解决方案（用于托管共享的“队列”），但是实现延迟给我带来了麻烦（应用引擎似乎不喜欢 python 的 threading.Timer

我很感激可以与应用程序引擎一起使用的东西，但在这一点上，我愿意接受任何建议（只要它适用于谷歌云）。

谢谢！

标签： google-cloud-platformroutes

Answer 1

完美的（但不是最便宜的）是使用 Dataflow。

• 当预测请求进来时，在 PubSub 中发布
• 以流模式部署数据流，固定窗口为 X 分钟，并在窗口中的 Y 事件之后触发另一个未累积的触发器。
• 当执行窗口触发时（在消息数或计时器上）执行批处理

---

您可以想象其他设计，更简单/更便宜。

• 仍然在 PubSub 中发布预测请求

1. 您可以每 X 分钟安排一次 Cloud Functions 或 Cloud Run 来拉取 pubsub 订阅，然后触发批处理作业。但是，这是一个固定的时间。
2. 当您在 PubSub 中发布消息时，您还可以存储，例如在 firestore 中，并增加一个计数器和在 PubSub 中发布的第一条消息的日期。
   • 如果消息数量超过您的阈值，请向您的其他进程执行请求，以提取 PubSub 订阅并运行批处理（如 #1 之前）。重置计数器值和消息日期值
   • 设置一个云调度程序，每分钟检查一次 Firestore 中第一条消息日期的值。如果超过您的时间限制，请向您的其他进程执行请求，以提取 PubSub 订阅并运行批处理（如 #1 之前）。重置计数器值和消息日期值

#2 会产生大量的 Firestore 读/写，但会比数据流便宜。