本部分介绍了预配吞吐量如何与 Live API 搭配使用，以进行 token 计数和配额强制执行。
Live API 支持通过会话实现低延迟的多模态互动。它使用会话内存来保留和回忆会话中进行的互动的信息。这使模型可以回忆起之前提供或讨论过的信息。预配吞吐量支持带有 Live API 的 Gemini 2.5 Flash 模型。如需详细了解 Live API（包括会话限制和功能），请参阅 Live API 参考文档。
计算 Live API 的吞吐量
使用 Live API 时，存储在会话内存中的 token 可用于向模型发出的后续请求。因此，预配吞吐量会在同一请求中同时考虑传入 token 和会话内存 token。这可能会导致每个请求处理的 token 数量大于用户在当前请求中发送的 token 数量。
Live API 会对可存储在会话内存中的 token 总数施加限制，并且还有一个包含 token 总数的元数据字段。在计算处理请求所需的吞吐量时，您必须考虑会话内存中的 token。如果您将 Live API 与随用随付 (PayGo) 搭配使用，则可以使用这些流量模式和会话 token 来帮助估算您的预配吞吐量需求。
如何估算 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 6 个 token）= 1,200 个 token
将这两个总数相加，即可得出所处理的 token 总数：
3,830 个 token + 1,200 个 token = 5,030 个 token
如果您的预配吞吐量配额大于每秒 5,030 个 token，则可以立即处理此请求。如果小于该数量，则系统会按照您为配额设置的速率随时间推移处理这些 token。