Links importantes
Painel de estado do serviço (atualmente disponível apenas para clientes Enterprise da API)
Começar com as predefinições certas
Ao abrir o painel Estado do serviço, a predefinição é:
Todos os projetos
Últimos 30 dias
Resolução horária
Esta vista é útil apenas para orientação. Uma resolução de problemas significativa requer sempre filtragem.
Filtrar antes de investigar
A filtragem correta é o passo mais importante. A maioria das interpretações erradas resulta da mistura de modelos, camadas ou projetos.
Filtrar por modelo (um de cada vez)
Filtre sempre para um único modelo.
Porquê:
Problemas em modelos com pouco tráfego podem ficar ocultos por tráfego de maior volume
Modelos de grande volume podem fazer com que problemas localizados pareçam globais
Modelos diferentes têm objetivos de desempenho diferentes
Nota: selecionar vários modelos agrega-os — não alterna entre eles.
Filtrar por camada de serviço
Se utilizar mais do que uma camada (standard, prioridade, escala), filtre sempre para a camada que está a investigar.
Porquê:
As camadas têm características de desempenho diferentes
As camadas de prioridade e escala têm SLAs definidos
Misturar camadas oculta o desempenho da camada paga
Isto é especialmente importante para a análise de latência.
Filtrar por projeto
Por predefinição, o Estado do serviço mostra todos os projetos.
Para resolução de problemas, filtre para o(s) projeto(s) onde o problema foi observado.
Porquê:
Um único projeto de grande volume pode dominar as métricas.
Projetos afetados mais pequenos podem ser mascarados por tráfego não relacionado.
Deixe «Todos os projetos» selecionado apenas se acreditar que o problema é verdadeiramente transversal à organização.
Resolução de erros
Utilizar a vista Pedidos HTTP
Para investigar erros:
Filtre por modelo e camada de serviço.
Abra o separador Pedidos HTTP em vez do separador Disponibilidade.
Esta vista mostra o total de pedidos e as contagens de erros por código de estado HTTP. Amplie para uma resolução ao nível do minuto para identificar picos ou alterações granulares.
Interpretar taxas de erro, não contagens
Alguns erros são esperados em qualquer sistema de produção. Concentre-se na percentagem de erros, não nos totais brutos.
Quanto maior for o volume total, maior será o número potencial de erros, mesmo com uma taxa de erro extremamente baixa.
Quando faltam erros no Estado do serviço
Se vir erros do lado do cliente, mas não houver dados correspondentes no Estado do serviço:
É provável que os pedidos não tenham chegado à OpenAI.
O problema é, normalmente, a montante (tempos limite, proxies, rede).
Isto é comum com tempos limite agressivos do lado do cliente.
Resolução de problemas de latência
A análise de latência é mais significativa nas camadas de prioridade e de escala, que têm SLAs definidos. A camada standard pode apresentar maior variação de latência e não tem latência garantida.
Métricas principais
Para ver cada métrica, clique no separador relevante:
Velocidade de tokens: tokens gerados por segundo; independente do tamanho do prompt.
Tempo do pedido: duração total do pedido; muito afetada pelo tamanho da saída e pelo raciocínio.
Tempo até ao primeiro token (TTFT): tempo até o primeiro token ser gerado; muito afetado pelo tamanho do prompt de entrada não colocado em cache e pelo raciocínio.
Reveja sempre os percentis P50 / P75 / P95. As médias podem ocultar o impacto nos utilizadores reais.
6. Correlacionar a latência com a utilização de tokens
O Estado do serviço mostra quando o comportamento mudou. Os dados de utilização ajudam a explicar porquê.
No painel Utilização, faça o seguinte para garantir que está a ver os dados relevantes para a sua vista no painel Estado do serviço:
Filtre para o mesmo projeto e modelo.
Agrupe por camada de serviço, se aplicável.
Concentre-se nos tokens de saída, que são os que mais afetam a latência.
Para uma análise mais aprofundada, exporte os dados de atividade e examine os tokens por pedido ao longo do tempo.
7. O que partilhar com o suporte (se necessário)
Se contactar o suporte, inclua:
IDs de organização afetados (importante)
Endpoints afetados, como Chat Completions ou Responses (importante)
Modelos afetados (importante)
Se isto ocorre na Camada de escala ou de prioridade (importante)
Intervalos de tempo com fuso horário para latência ou erros (importante)
x-request-id ou X-Client-Request-Id relevante, se disponível
Carimbos de data/hora com fuso horário, ou pelo menos a data, para os pedidos que fornecer
Se disponível, inclua também:
ID do projeto relacionado com os pedidos
Se os pedidos de residência de dados são afetados e quais
Descrições das tendências que está a observar
Para o tipo de problema, inclua:
Erros: percentagem aproximada de pedidos com falha ou erro, códigos de resposta, mensagens de erro e quanto tempo demorou a receber a resposta de erro.
Latência: quais os percentis afetados (P50 / P90 / P95 / P99), quão elevados estão em comparação com a referência do cliente e exemplos de pedidos lentos com carimbos de data/hora de envio e receção.
Ambos: capturas de ecrã ou uma tabela de dados de erros ou latência, mais a forma como determinou que as taxas de erro ou a latência eram superiores ao esperado.
Cenários comuns de resolução de problemas
Ocorrem tempos limite, mas o Estado do serviço parece normal
Causa possível: os pedidos estão a atingir o tempo limite antes de chegarem à OpenAI.
Verifique:
Definições de tempo limite do cliente ou proxy
Alterações na rede local ou no balanceador de carga
Presença de erros 499 no painel Estado do serviço (estes podem aparecer como erros 5xx nos seus próprios sistemas).
A latência aumentou sem uma implementação
Causa possível: o tamanho dos tokens de saída ou a utilização de raciocínio aumentou e/ou o tráfego mudou entre camadas de serviço.
Verifique:
Média de tokens de saída por pedido no painel Utilização (requer transferir os dados e dividir os tokens de saída pelo total de pedidos).
Percentis de Tempo do pedido e TTFT no painel Estado do serviço.
A camada Prioridade ou a Camada de escala parece lenta
Causa possível: as métricas estão misturadas entre camadas, o que significa que o tráfego da camada standard está a mascarar o desempenho da camada paga.
Verifique:
Os filtros estão restringidos a uma única camada e modelo.
Comparação da velocidade de tokens entre camadas.
Aumento de erros 5XX
Causa provável: falhas transitórias que afetam uma pequena percentagem do tráfego.
Verifique:
Percentagem da taxa de erros
Se o volume de tráfego mudou ao mesmo tempo
O problema afeta apenas um projeto
Causa provável: configuração ou padrão de utilização específico do projeto.
Verifique:
Filtragem ao nível do projeto
Comparação com projetos não afetados
Principais conclusões
Filtre por modelo, camada e projeto, quando relevante, antes de interpretar métricas.
Utilize percentis, não médias, para a análise de latência.
São esperadas pequenas taxas de erro.
A ausência de dados indica, normalmente, problemas a montante.
Os dados de utilização podem ajudar a explicar por que motivo a latência mudou; o Estado do serviço mostra quando o comportamento mudou.