Esta seção explica como a capacidade de processamento provisionada funciona com a API Gemini Live para contagem de tokens e aplicação de cotas.
A API Gemini Live permite interações multimodais de baixa latência usando a memória da sessão para manter o contexto entre os turnos. Para mais recursos e limites de sessão, consulte a referência da API Gemini Live.
Cada sessão precisa ser dedicada inteiramente ao Provisioned Throughput ou ao PayGo. O transbordamento no meio da sessão não é compatível. Se você exceder a cota de Capacidade de Processamento Provisionada durante uma sessão ativa, o sistema permitirá um aumento temporário para evitar erros, registrando o excesso na sua cota geral. Para evitar picos inesperados de uso, compre GSUs suficientes para atender à demanda máxima.
O transbordamento é compatível entre as sessões. Ao iniciar uma sessão, o sistema avalia o cabeçalho da solicitação e verifica a disponibilidade da cota de Capacidade de Processamento Provisionada. Se a cota for insuficiente, a nova sessão vai usar o PayGo por padrão.
Como a memória da sessão transfere as saídas da conversa anterior como entradas para solicitações subsequentes, a Capacidade de Processamento Provisionada calcula a cota com base em tokens novos e acumulados da sessão. Como resultado, o total de tokens processados por solicitação vai aumentar à medida que a sessão avança até atingir o limite predefinido. O estado da sessão, incluindo a memória da sessão, fica disponível enquanto a sessão está ativa.
Não se esqueça de considerar os tokens de memória da sessão ao estimar a capacidade de processamento provisionada necessária. Os tokens de avatar de vídeo de saída não são incluídos na memória da sessão. Os padrões históricos de tráfego do PayAsYouGo podem servir como um valor de referência útil para calcular suas necessidades de GSU.
As janelas de aplicação de cota variam de acordo com o número de GSUs compradas para o modelo e estão sujeitas a mudanças.
API Gemini 3.8 Live
Janelas de aplicação de cota
Confira a seguir os períodos de aplicação de cota para diferentes tamanhos de GSU do modelo de API Gemini 3.8 Live:
- 1 a 9 GSUs: 45 segundos
- 10 ou mais GSUs: 5 segundos
Os valores listados são independentes da latência da solicitação. O tempo para processar sua solicitação não é o mesmo que a janela de aplicação de cota. É necessário comprar pelo menos 10 GSUs para que a taxa de transferência provisionada possa processar as solicitações relacionadas ao avatar de vídeo desse modelo. Se menos de 10 GSUs forem compradas, toda a sessão baseada em avatar de vídeo será transferida para o PayGo.
As janelas de aplicação são maiores em quantidades menores de GSU para garantir que solicitações menores sejam processadas com sucesso dentro da janela. À medida que o número de GSUs de um modelo aumenta, não é necessário ter períodos mais longos para processar uma solicitação. Se você precisar processar saídas com mais frequência usando a capacidade provisionada, recomendamos aumentar a quantidade de GSUs compradas e verificar a janela de aplicação correspondente. Os períodos de aplicação dependem de algoritmos de back-end e estão sujeitos a mudanças.
Como estimar os requisitos de GSU
Vamos analisar um exemplo de uma possível carga de trabalho e entender como a ferramenta de estimativa forneceria uma recomendação para esse modelo, que também informa como as solicitações são processadas e as taxas de redução são aplicadas. Um usuário planeja usar a API Live para um chatbot em que são esperadas 10 sessões simultâneas, e a duração é de 5 minutos (300 segundos). São esperados 30 turnos de conversa por sessão, e o usuário especifica uma janela de contexto máxima de 6.000 tokens de acionamento. O formato das solicitações é capturado abaixo:
| Campo | Valor de exemplo |
|---|---|
| Número esperado de sessões simultâneas | 10 |
| Duração esperada (segundos) | 300 |
| Número médio de turnos por sessão | 30 |
| Tamanho máximo do contexto (tokens de acionamento) | 6.000 |
| Média de tokens de texto de entrada por turno | 20 |
| Média de tokens de áudio de entrada por turno | 200 |
| Média de tokens de imagem/vídeo de entrada por turno | 50 |
| Média de tokens de texto de saída por turno | 100 |
| Média de tokens de áudio de saída por turno | 200 |
| O avatar de vídeo de saída está ativado? | Sim |
Tokens de entrada por vez:
Calcule o produto escalar das modalidades de entrada e das respectivas taxas de redução:
Tokens de texto de entrada médios por turno * taxa de redução do texto de entrada = 20 * 1 = 20
Tokens de áudio de entrada médios por turno * taxa de redução do áudio de entrada = 200 * 4 = 800
Média de tokens de imagem/vídeo de entrada por rodada * taxa de redução de imagens de entrada = 50 * 1,4 = 70
Total de tokens de entrada ajustados por burndown por turno = 20 + 800 + 70 = 890
Tokens de saída por turno:
Calcule o produto escalar das modalidades de saída e das respectivas taxas de redução. Os tokens de avatar de vídeo de saída representam um valor fixo de 6.192 tokens por 25 tokens de áudio:
Média de tokens de texto de saída por turno * taxa de redução do texto de saída = 100 * 6 = 600
Tokens de áudio médios por turno * taxa de redução de áudio de saída = 200 * 16 = 3.200
O avatar de vídeo de saída está ativado? Sim, então multiplique a saída de token de áudio por (6.192/25) e aplique a taxa de redução de token de avatar de vídeo de saída: 200 * (6.192/25) * 1,4 = 69.350
Total de tokens de saída ajustados por burndown por turno = 600 + 3.200 + 69.350 = 73.150
Tokens da janela de contexto por interação:
A janela de contexto acumula tokens de entrada e saída brutos (exceto tokens de avatar de vídeo de saída) em cada turno até atingir o tamanho máximo e parar de aumentar. Os tokens são contabilizados no limite da janela de contexto como tokens brutos (sem aplicar taxas de redução). No entanto, quando a janela de contexto é inserida nas solicitações de entrada da próxima vez como memória de sessão, os tokens na janela de contexto precisam aplicar as taxas de redução de entrada correspondentes com base na modalidade deles.
Adicione o total de tokens brutos em cada sessão sem considerar as taxas de redução.
- Média de tokens de texto de entrada por turno + média de tokens de áudio de entrada por turno + média de tokens de imagem/vídeo de entrada por turno + média de tokens de texto de saída por turno + média de tokens de áudio de saída por turno = 20 + 200 + 50 + 100 + 200 = 570
Em seguida, calcule a proporção de cada contagem de token bruta em relação ao total. Podemos ignorar os tokens de saída do avatar de vídeo como parte do cálculo da janela de contexto.
- Proporção de texto de entrada = 20/570 = 0,035
- Proporção de áudio de entrada = 200/570 = 0,351
- Proporção de imagem/vídeo de entrada = 50/570 = 0,088
- Proporção de texto de saída = 100/570 = 0,175
- Proporção de áudio de saída = 200/570 = 0,351
Em seguida, calcule o produto da soma das proporções, o tamanho máximo do contexto e as taxas de redução como se fossem todas as modalidades de entrada.
Taxa de texto de entrada * tamanho máximo do contexto * redução do texto de entrada = 0,035 * 6.000 * 1 = 210
Proporção de áudio de entrada * comprimento máximo do contexto * redução do áudio de entrada = 0,351 * 6.000 * 4 = 8.424
Redução da proporção imagem/vídeo de entrada * duração máxima do contexto * imagem/vídeo de entrada = 0,088 * 6.000 * 1,4 = 739
Proporção de texto de saída * tamanho máximo do contexto * redução do texto de entrada = 0,175 * 6.000 * 1 = 1.050
Proporção de áudio de saída * tamanho máximo do contexto * redução do áudio de entrada = 0,351 * 6.000 * 4 = 8.424
No limite máximo de 6.000 tokens brutos, o total de tokens de janela de contexto ajustados por burndown processados por turno é 210 + 8.424 + 739 + 1.050 + 8.424 = 18.847.
Cálculo de GSU:
(tokens de entrada por turno + tokens de saída por turno + tokens de janela de contexto por turno) * número médio de turnos por sessão * número esperado de sessões simultâneas * (1/duração esperada) * (1 GSU / 1.350 TPS) = (890 + 73.150 + 18.847) * 30 * 10 * (1/300) * (1/1.350) = 68,8, arredondado para cima, resulta em 69 GSUs.
Processamento de solicitações
Vamos conferir um exemplo de como as solicitações são processadas em relação ao Provisioned Throughput para esse modelo. Vamos supor que há três solicitações.
Detalhes da solicitação 1: entrada de áudio e vídeo, saída de áudio
- Duração: 10 segundos
- Tokens enviados (áudio): 10 segundos x 25 tokens/segundo = 250 tokens
- Tokens enviados (vídeo): 10 segundos x 258 tokens/frame por segundo = 2.580 tokens
- Tokens de áudio de saída recebidos com base na natureza da solicitação: 100 tokens
- Memória de sessão atualizada = 250 + 2.580 + 100 = 2.930 tokens
Detalhes da solicitação 2: áudio de entrada com memória de sessão, áudio de saída
- Duração: 40 segundos
- Tokens enviados (áudio): 40 segundos x 25 tokens/segundo = 1.000 tokens
- Memória da sessão após a solicitação 1 = 2.930 tokens
- Total de tokens de entrada enviados: tokens enviados nesta solicitação + memória da sessão da solicitação nº 1 = 1.000 + 2.930 = 3.930 tokens
- Tokens de áudio de saída recebidos com base na natureza da solicitação: 200 tokens
- Memória de sessão atualizada = 3.930 + 200 = 4.130 tokens
Detalhes da solicitação nº 3: entrada de áudio e vídeo com memória de sessão, saída de vídeo e áudio do avatar
- Duração: 10 segundos
- Tokens enviados (áudio): 10 segundos x 25 tokens/segundo = 250 tokens
- Tokens enviados (vídeo): 10 segundos x 258 tokens/frame por segundo = 2.580 tokens
- Memória da sessão após a solicitação nº 2 = 4.130 tokens
- Total de tokens de entrada enviados: tokens enviados nesta solicitação + memória da sessão da solicitação nº 2 = 250 + 2.580 + 4.130 = 6.960 tokens
- Saída de tokens de avatar de vídeo recebidos com base na natureza da solicitação: 61.920 tokens
- Tokens de áudio de saída recebidos com base na natureza da solicitação: 250 tokens
- Memória da sessão atualizada = 6.960 + 250 = 7.210 tokens
Como entender os tokens processados
A solicitação 1 processa apenas os tokens de entrada e saída da solicitação em andamento, já que não há outros tokens na memória da sessão. Todos os tokens processados agora compõem a memória da sessão.
A solicitação 2 processa os tokens de entrada e saída da solicitação em andamento e inclui a memória da sessão da solicitação 1. Todos os tokens de memória da sessão aplicam a taxa de redução de um token de entrada correspondente.
A solicitação nº 3 processa os tokens de entrada e saída da solicitação em andamento e inclui a memória da sessão da solicitação nº 2. Todos os tokens de memória da sessão aplicam a taxa de redução de um token de entrada correspondente.
Se a solicitação nº 3 levasse exatamente 1 segundo para ser processada após o envio, os tokens ajustados de burndown aplicados à cota de capacidade de processamento provisionada para esse modelo seriam os seguintes:
Tokens de áudio de entrada * taxa de redução do áudio de entrada = 250 * 4 = 1.000
Tokens de vídeo de entrada * taxa de redução do vídeo de entrada = 2.580 * 1,4 = 3.612
Memória de áudio da sessão * taxa de redução de áudio de entrada = (250 + 100 + 1.000 + 200) * 4 = 6.200
Vídeo de memória de sessão * taxa de redução de vídeo de entrada = 2.580 * 1,4 = 3.612
Tokens de avatar de vídeo de saída * taxa de redução de avatar de vídeo de saída = 61.920 * 1,4 = 86.688
Tokens de áudio de saída * taxa de redução de áudio de saída = 250 * 16 = 4.000
A adição do total fornece 105.112 tokens ajustados por redução.
Áudio nativo da API Gemini 2.5 Flash Live
Processamento de solicitações
Detalhes da solicitação 1: entrada de áudio e vídeo, saída de áudio
- Duração: 10 segundos
- Tokens enviados (áudio): 10 segundos x 25 tokens/segundo = 250 tokens
- Tokens enviados (vídeo): 10 segundos x 258 tokens/frame por segundo = 2.580 tokens
- Tokens de áudio de saída recebidos com base na natureza da solicitação: 100 tokens
- Memória de sessão atualizada = 250 + 2.580 + 100 = 2.930 tokens
Detalhes da solicitação 2: áudio de entrada com memória de sessão, áudio de saída
Duração: 40 segundos
Tokens enviados (áudio): 40 segundos x 25 tokens/segundo = 1.000 tokens
Memória da sessão após a solicitação 1 = 2.930 tokens
Total de tokens de entrada enviados: tokens enviados nesta solicitação + memória da sessão da solicitação nº 1 = 1.000 + 2.930 = 3.930 tokens
Tokens de áudio de saída recebidos com base na natureza da solicitação: 200 tokens
Memória de sessão atualizada = 3.930 + 200 = 4.130 tokens
Como entender os tokens processados
A solicitação 1 processa apenas os tokens de entrada e saída da solicitação em andamento, já que não há outros tokens na memória da sessão. Todos os tokens processados agora compõem a memória da sessão.
A solicitação nº 2 processa os tokens de entrada e saída da solicitação em andamento e inclui a memória da sessão da solicitação nº 1. Todos os tokens de memória da sessão aplicam a taxa de redução de um token de entrada correspondente.
Se a solicitação nº 2 levasse exatamente 1 segundo para ser processada após o envio, os tokens ajustados por burndown aplicados à cota de capacidade de processamento provisionada para esse modelo seriam os seguintes:
- Tokens de áudio de entrada * taxa de redução do áudio de entrada = 1.000 * 6 = 6.000
- Memória de áudio da sessão * taxa de redução de áudio de entrada = (250 + 100) * 6 = 2.100
- Vídeo de memória da sessão * taxa de redução do vídeo de entrada = 2.580 * 6 = 15.480
- Tokens de áudio de saída * taxa de redução de áudio de saída = 200 * 24 = 4.800
Adicionar o total fornece 28.380 tokens ajustados de redução.