本部分介绍了预配吞吐量如何与 Gemini Live API 搭配使用，以进行 token 计数和配额强制执行。
Gemini Live API 支持低延迟的多模态互动，并使用会话记忆来保留多轮对话中的上下文。如需了解其他功能和会话限制，请参阅 Gemini Live API 参考文档。
每个会话必须完全专用于预配吞吐量或 PayGo；不支持会话中溢出。如果您在活跃会话期间超出预配吞吐量配额，系统会允许临时突发，以避免出现错误，并将超额部分计入您的总配额。为避免用量意外激增，请购买足够的 GSU，以满足高峰需求。
支持在会话之间溢出。启动会话时，系统会评估请求标头并验证预配吞吐量配额可用性。如果配额不足，新会话将默认采用 PayGo。
由于会话内存会将前一轮输出作为后续请求的输入，因此预配吞吐量会根据新的传入 token 和累积的会话令牌计算配额。因此，随着会话的进行，每个请求处理的总 token 数量会增加，直到达到预定义的会话限制。只要会话处于有效状态，会话状态（包括会话内存）就可用。
在估算所需的预配吞吐量时，请务必考虑会话内存 token。请注意，输出视频头像 token 不包含在会话内存中。历史 PayGo 流量模式可以作为计算 GSU 需求的有用基准。
配额强制执行期因您为该模型购买的 GSU 数量而异，并且可能会发生变化。
Gemini 3.8 Live API
配额强制执行窗口
以下是 Gemini 3.8 Live API 模型不同 GSU 规模的配额强制执行窗口：
- 1-9 个 GSU：45 秒
- 10+ GSU：5 秒
列出的值与请求延迟时间无关。处理您的请求所用的时间与配额强制执行期不同。请注意，必须至少购买 10 个 GSU，预配吞吐量才能处理此模型的视频头像相关请求。如果购买的 GSU 少于 10 个，则整个基于视频头像的会话将溢出到 PayGo。
GSU 数量较小时，强制执行时间窗口会较长，以确保较小的请求在时间窗口内成功处理。随着模型 GSU 数量的增加，处理请求所需的时间窗口不会变长。如果您需要使用预配吞吐量更频繁地处理输出，建议您增加购买的 GSU 数量，并查看相应的强制执行时间窗口。违规处置窗口取决于后端算法，并且可能会发生变化。
估算 GSU 需求
我们来看一个潜在工作负载的示例，了解估算工具如何为此模型提供建议，以及如何处理请求和应用消耗率。用户计划将 Gemini Live API 用于聊天机器人，预计会有 10 个并发会话，时长为 5 分钟（300 秒）。预计每个会话有 30 个对话轮次，用户指定的最大会话上下文窗口为 6,000 个触发 token。请求的形式如下所示：
| 字段 | 示例值 |
|---|---|
| 预期的并发会话数 | 10 |
| 预计时长（秒） | 300 |
| 每次会话的平均交互轮次 | 30 |
| 上下文长度上限（触发器 token 数） | 6000 |
| 每轮平均输入文本 token 数 | 20 |
| 每轮平均输入音频 token 数 | 200 |
| 每轮平均输入图片/视频 token 数 | 50 |
| 每轮平均输出文本 token 数 | 100 |
| 每轮平均输出音频 token 数 | 200 |
| 是否已启用输出视频头像？ | 是 |
每轮输入 token 数：
计算输入模态及其各自消耗率的乘积和：
每轮平均输入文本 token 数 * 输入文本消耗率 = 20 * 1 = 20
每轮平均输入音频 token 数 * 输入音频消耗率 = 200 * 4 = 800
每轮平均输入图片/视频 token 数 * 输入图片消耗率 = 50 * 1.4 = 70
每轮按消耗调整后的输入 token 总数 = 20 + 800 + 70 = 890
每轮输出 token 数：
计算输出模态及其各自消耗率的乘积之和。请注意，输出视频虚拟形象 token 表示每 25 个音频 token 对应固定的 6,192 个 token：
每轮平均输出文本 token 数 * 输出文本消耗率 = 100 * 6 = 600
每轮平均音频 token 数 * 输出音频消耗率 = 200 * 16 = 3,200
是否已启用输出视频头像？是，因此将音频 token 输出乘以 (6,192/25)，并应用输出视频虚拟形象 token 消耗率：200 * (6,192/25) * 1.4 = 69,350
每轮按消耗调整后的输出 token 总数 = 600 + 3,200 + 69,350 = 73,150
每轮对话的上下文窗口 token 数：
上下文窗口会在每轮对话中累积原始输入和输出 token（不包括输出视频虚拟形象 token），直到达到最大上下文窗口长度并停止增加。系统会将 token 作为原始 token（不应用消耗率）计入上下文窗口限制。不过，当上下文窗口作为会话记忆馈送到下一轮的输入请求时，上下文窗口中的 token 必须根据其模态应用相应的输入消耗率。
将每个会话中的原始 token 总数相加，不考虑消耗率。
- 每轮平均输入文本 token 数 + 每轮平均输入音频 token 数 + 每轮平均输入图片/视频 token 数 + 每轮平均输出文本 token 数 + 每轮平均输出音频 token 数 = 20 + 200 + 50 + 100 + 200 = 570
然后，计算每个原始 token 数量与总数量的比率。在计算上下文窗口时，我们可以忽略视频头像输出词元。
- 输入文本比率 = 20/570 = 0.035
- 输入音频比率 = 200/570 = 0.351
- 输入图片/视频比率 = 50/570 = 0.088
- 输出文本比率 = 100/570 = 0.175
- 输出音频比率 = 200/570 = 0.351
然后，计算比率、最大上下文长度和消耗率的乘积和，就好像它们都是输入模态一样。
输入文本比率 * 上下文长度上限 * 输入文本消耗量 = 0.035 * 6,000 * 1 = 210
输入音频比率 * 上下文长度上限 * 输入音频消耗量 = 0.351 * 6,000 * 4 = 8,424
输入图片/视频比率 * 上下文长度上限 * 输入图片/视频消耗量 = 0.088 * 6,000 * 1.4 = 739
输出文本比率 * 上下文长度上限 * 输入文本燃尽率 = 0.175 * 6,000 * 1 = 1,050
输出音频比率 * 上下文长度上限 * 输入音频消耗 = 0.351 * 6,000 * 4 = 8,424
在 6,000 个原始 token 的最大上下文窗口限制下，每轮处理的经消耗率调整后的上下文窗口 token 总数为 210 + 8,424 + 739 + 1,050 + 8,424 = 18,847。
GSU 计算：
（每轮输入 token 数 + 每轮输出 token 数 + 每轮上下文窗口 token 数）* 每个会话的平均轮数 * 预期并发会话数 * (1/预期时长) * (1 GSU / 1,350 TPS) = (890 + 73,150 + 18,847) * 30 * 10 * (1/300) * (1/1,350) = 68.8，向上取整后为 69 GSU。
正在处理请求
我们来看一个示例，了解如何根据此模型的预配吞吐量处理请求。假设有 3 个请求。
请求 1 详细信息 - 输入音频和视频，输出音频
- 时长：10 秒
- 发送的 token 数（音频）：10 秒 x 25 个 token/秒 = 250 个 token
- 发送的 token 数（视频）：10 秒 x 258 个 token/每秒帧数 = 2,580 个 token
- 根据请求性质收到的输出音频 token 数：100 个 token
- 更新后的会话内存 = 250 + 2,580 + 100 = 2,930 个 token
请求 2 详细信息 - 输入音频（带会话记忆）、输出音频
- 时长：40 秒
- 发送的 token 数（音频）：40 秒 x 25 个 token/秒 = 1,000 个 token
- 请求 1 之后的会话内存 = 2,930 个 token
- 发送的输入 token 总数：此请求中发送的 token 数 + 来自请求 1 的会话内存 = 1,000 + 2,930 = 3,930 个 token
- 根据请求性质收到的输出音频 token 数：200 个 token
- 更新后的会话内存 = 3,930 + 200 = 4,130 个 token
请求 #3 详细信息 - 输入音频和视频（带会话记忆），输出虚拟形象视频和音频
- 时长：10 秒
- 发送的 token 数（音频）：10 秒 x 25 个 token/秒 = 250 个 token
- 发送的 token 数（视频）：10 秒 x 258 个 token/每秒帧数 = 2,580 个 token
- 请求 2 之后的会话记忆 = 4,130 个 token
- 发送的输入 token 总数：此请求中发送的 token 数 + 来自请求 2 的会话记忆 = 250 + 2,580 + 4,130 = 6,960 个 token
- 根据请求性质收到的输出视频虚拟形象 token 数：61,920 个 token
- 根据请求性质收到的输出音频 token 数：250 个 token
- 更新后的会话内存 = 6,960 + 250 = 7,210 个 token
了解处理的 token 数量
请求 1 仅处理来自当前请求的输入和输出 token，因为会话内存中没有其他 token。所有已处理的 token 现在都构成了会话记忆。
请求 2 会处理来自当前请求的输入和输出 token，同时还会包含来自请求 1 的会话记忆。所有会话内存 token 均采用相应输入 token 的消耗速率。
请求 3 会处理来自当前请求的输入和输出 token，同时还会包含来自请求 2 的会话内存。所有会话内存 token 均采用相应输入 token 的消耗速率。
如果您发送请求 3 后，系统恰好使用 1 秒来处理该请求，那么应用于此模型的预配吞吐量配额的、经过消耗调整的 token 数量如下：
输入音频 token 数 * 输入音频消耗率 = 250 * 4 = 1,000
输入视频 token 数 * 输入视频消耗率 = 2,580 * 1.4 = 3,612
会话记忆音频 * 输入音频消耗速率 = (250 + 100 + 1,000 + 200) * 4 = 6,200
会话记忆视频 * 输入视频消耗速率 = 2,580 * 1.4 = 3,612
输出视频头像 token 数 * 输出视频头像消耗率 = 61,920 * 1.4 = 86,688
输出音频 token 数 * 输出音频消耗率 = 250 * 16 = 4,000
加上总数后，可获得 105,112 个经过消耗调整的 token。
Gemini 2.5 Flash Live API 原生音频
正在处理请求
请求 1 详细信息 - 输入音频和视频，输出音频
- 时长：10 秒
- 发送的 token 数（音频）：10 秒 x 25 个 token/秒 = 250 个 token
- 发送的 token 数（视频）：10 秒 x 258 个 token/每秒帧数 = 2,580 个 token
- 根据请求性质收到的输出音频 token 数：100 个 token
- 更新后的会话内存 = 250 + 2,580 + 100 = 2,930 个 token
请求 2 详细信息 - 输入音频（带会话记忆）、输出音频
时长：40 秒
发送的 token 数（音频）：40 秒 x 25 个 token/秒 = 1,000 个 token
请求 1 之后的会话内存 = 2,930 个 token
发送的输入 token 总数：此请求中发送的 token 数 + 来自请求 1 的会话内存 = 1,000 + 2,930 = 3,930 个 token
根据请求性质收到的输出音频 token 数：200 个 token
更新后的会话内存 = 3,930 + 200 = 4,130 个 token
了解处理的 token 数量
请求 1 仅处理来自当前请求的输入和输出 token，因为会话内存中没有其他 token。所有已处理的 token 现在都构成了会话记忆。
请求 2 会处理来自当前请求的输入和输出 token，同时还会包含来自请求 1 的会话记忆。所有会话内存 token 均采用相应输入 token 的消耗速率。
如果请求 2 在发送后恰好用了 1 秒来处理，那么应用于此模型的预配吞吐量配额的、经过消耗调整的 token 如下所示：
- 输入音频 token 数 * 输入音频消耗率 = 1,000 * 6 = 6,000
- 会话记忆音频 * 输入音频消耗速率 = (250 + 100) * 6 = 2,100
- 会话记忆视频 * 输入视频消耗速率 = 2,580 * 6 = 15,480
- 输出音频 token 数 * 输出音频消耗率 = 200 * 24 = 4,800
将总数相加，得出 28,380 个按消耗调整后的 token。