Google cloud platform “怎么做？”；“实时请求批处理”；在gcloud中

以下是我的情况：

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

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

• 接收请求时，请稍等其他请求
• 一段时间后，或者当请求数量达到设定数量时，将请求以单个“批”转发到另一个服务
• 如果流量低，延迟将在批处理满之前过期，但由于流量低，这不是问题
• 如果流量很大，则在延迟之前批处理将已满，客户端将不得不等待更少的时间

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

我很感激能够使用AppEngine的东西，但现在我愿意接受任何建议（只要它适用于谷歌云）

谢谢！

最好（但不是最便宜）使用数据流

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

---

你可以想象其他更简单/更便宜的设计

• 仍在PubSub中发布预测请求

您可以计划云功能，或者每X分钟运行一次云，以拉取pubsub订阅，然后触发批处理作业。但是，这是一个固定的时间

在PubSub中发布消息时，您还可以在firestore中存储消息，例如，增加计数器和在PubSub中发布的第一条消息的日期。

• 如果消息数量超过阈值，请向拉取PubSub订阅并运行批处理的其他进程执行请求（如前所述#1）。重置计数器值和消息日期值
• 设置一个云计划程序，每分钟检查Firestore中第一个消息日期的值。如果它超出了您的时间限制，请向其他进程执行请求，以拉取PubSub订阅并运行批处理（如前所述#1）。重置计数器值和消息日期值

---

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

谢谢！…但如果我理解正确，所有这些解决方案的最小延迟约为一分钟。我也有使用cron jobs的类似想法，但我担心等待一整分钟的结果对用户来说太长了（谁会期待等待5到10秒）你有几种解决方案。一种是每分钟触发一个进程（云功能或云运行）流程每5秒执行一次检查。原则是1分钟内的所有检查都需要在请求上下文中执行。另一种解决方案是让流程在任务中创建带有触发时间戳的云任务。每分钟生成12个任务，每个任务间隔5秒。任务将调用另一个端点that执行检查和批触发。我不知道云任务“scheduleTime”。这听起来像是一个解决方案（虽然有点“黑客”）。我会尝试一下。谢谢！