本部分介绍了预配吞吐量如何与 Gemini Live API 搭配使用，以进行 token 计数和配额强制执行。
Gemini Live API 支持低延迟的多模态互动，并使用会话内存在多轮对话中保留上下文。如需了解其他功能和会话限制，请参阅 Gemini Live API 参考文档。
每个会话必须完全专用于预配吞吐量或 PayGo；不支持会话中溢出。如果您在有效会话期间超出预配吞吐量配额，系统会允许临时突增，以避免出现错误，并将超额部分计入您的总配额。为避免出现意外的用量高峰，请购买足够的 GSU 来满足您的峰值需求。
支持在各会话之间结转。在开始会话时，系统会评估请求标头并验证预配吞吐量配额是否可用。如果配额不足，则新会话默认采用 PayGo。
由于会话内存会将上一个对话轮次的输出作为后续请求的输入，因此预配吞吐量会根据新的传入 token 和累积的会话 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 要求
我们来举一个潜在工作负载的示例，了解估算工具将如何为此模型提供建议，这也有助于了解请求的处理方式和消耗速率的应用方式。某用户计划将 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 数 = 20 + 200 + 50 + 100 + 200 = 570
然后，计算每个原始令牌数量与总数的比率。在计算上下文窗口时，我们可以忽略视频头像输出令牌。
- 输入文本比率 = 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 个根据燃尽调整后的令牌。
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
将这些值相加，即可得出按消耗调整后的 token 总数为 28,380。