Gemini Live API 的预配吞吐量

本部分介绍了预配吞吐量如何与 Gemini Live API 搭配使用,以进行 token 计数和配额强制执行。

Gemini Live API 支持通过会话实现低延迟的多模态互动。它使用会话内存来保留和回忆会话中进行的互动的信息。这使模型可以回忆起之前提供或讨论过的信息。预配吞吐量支持带有 Gemini Live API 的 Gemini 2.5 Flash 模型。如需详细了解 Gemini Live API(包括会话限制和功能),请参阅 Gemini Live API 参考文档

Gemini Live API 要求会话完全专用于预配吞吐量或随用随付流量。它不支持在同一会话中,预配吞吐量和 PayGo 之间的溢出流量。在会话开始时设置的流量类型会在整个会话期间持续有效。如果您在有效会话期间达到预配吞吐量配额,系统不会限制您的使用,也不会显示错误。系统不会立即停止流量,而是允许流量在会话期间暂时突增,以便会话继续进行,但所有后续使用量都会计入您的总配额。这种临时突增可能会导致监控信息中心显示的预配吞吐量用量(专用流量)超出您的限制。为避免在会话期间超出分配的限制,请务必购买足够的 GSU 来支持您的预期用量。

系统支持从一个会话到下一个会话的溢出。如果会话结束后,您超出预配吞吐量限额,则可以使用按用量付费方式启动其他会话。会话是完全按预配吞吐量还是按用量付费方式处理,是在会话开始时决定的。系统会检查用户发送的标头,然后验证会话是否有足够的预配吞吐量配额。如果可用的预配吞吐量配额不足以处理整个会话,则会改用按用量付费配额。

计算 Gemini Live API 的吞吐量

使用 Gemini Live API 时,存储在会话内存中的 token 可用于向模型发出的后续请求。因此,预配吞吐量会在同一请求中同时考虑传入 token 和会话内存 token。这可能会导致每个请求处理的 token 数量大于用户在当前请求中发送的 token 数量。

Gemini Live API 会对可存储在会话内存中的 token 总数施加限制,并且还有一个包含 token 总数的元数据字段。在计算处理请求所需的吞吐量时,您必须考虑会话内存中的 token。如果您将 Gemini Live API 与随用随付 (PayGo) 搭配使用,则可以使用这些流量模式和会话 token 来帮助估算您的预配吞吐量需求。

如何估算 Gemini Live API 的预配吞吐量要求的示例

在会话期间,所有流量都将按预配吞吐量或随用随付方式处理。

只要会话处于有效状态,会话状态(包括会话内存)就可用。

此示例说明了如何通过包含会话内存中的 token 来处理两个连续的请求。

请求 1 详细信息

时长:10 秒

发送的 token 数(音频):10 秒 x 25 个 token/秒 = 250 个 token

发送的 token 数(视频):10 秒 x 258 个 token/帧/秒 = 2580 个 token

为请求 1 处理的 token 总数

  • 发送的 token 数:发送的音频和视频 token 总数 = 2580 + 250 = 2830 个 token
  • 收到的 token 数:100(音频)

请求 2 详细信息

时长:40 秒

发送的 token 数(音频):40 秒 x 25 个 token/秒 = 1000 个 token

为请求 2 处理的 token 总数

  • 发送的 token 数:请求 2 中发送的 token 数 + 来自请求 1 的会话内存 token 数 = 2830 个 token + 1000 个 token = 3830 个 token
  • 收到的 token 数:200(音频)

计算请求中处理的 token 数

这些请求期间处理的 token 数按如下所示进行计算:

  • 请求 1 仅处理来自当前请求的输入和输出 token,因为会话内存中没有其他 token。

  • 请求 2 不但会处理来自当前请求的输入和输出 token,还包含来自会话内存的输入 token,即会话内存中来自前一个请求(请求 1)的输入 token。会话内存中 token 的消耗速率与标准输入 token 的消耗速率相同(1 个输入会话内存 token = 1 个输入 token)。

    如果您发送请求 2 后,系统恰好使用 1 秒来处理该请求,那么您的 token 会按以下方式处理并应用于您的预配吞吐量配额:

    • 将输入乘以消耗速率,即可得出输入 token 总数:

      2830 x(每个会话内存 token 1 个 token)+ 1000 x(每个输入文本 token 1 个 token)= 每次查询 3830 个按消耗调整后的输入 token

    • 将输出乘以消耗速率,即可得出输出 token 总数:

      200 x(每个音频输出 token 24 个 token)= 4,800 个 token

    • 将这两个总数相加,即可得出所处理的 token 总数:

      3,830 个 token + 4,800 个 token = 8,630 个 token

后续步骤