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 de uma camada (padrão, modo Fast (anteriormente, processamento prioritário), Camada de escala), filtre sempre pela camada que está a investigar.
Porquê:
As camadas têm diferentes características de desempenho
O modo Fast e a Camada de escala têm SLAs definidos
Combinar camadas oculta o desempenho das camadas pagas
Isto é especialmente importante para a análise da latência.
Nos modelos existentes, o tráfego do modo Fast continua a ser apresentado como prioritário no painel Utilização.
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 da latência é mais relevante nas camadas modo Fast e Camada de escala, que têm SLAs definidos. A camada padrão pode apresentar uma maior variação da latência e não oferece garantia de latência.
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 fornecer ao suporte (se necessário)
Se contactar o suporte, inclua:
IDs das organizações afetadas (importante)
Endpoints afetados, como Chat Completions ou Responses (importante)
Modelos afetados (importante)
Se o problema ocorre no modo Fast ou na Camada de escala (importante)
Intervalos de tempo com fuso horário relativos à latência ou aos erros (importante)
x-request-id ou X-Client-Request-Id relevantes, se disponíveis
Datas e horas com fuso horário ou, pelo menos, a data dos pedidos que fornecer
Se possível, inclua também:
ID do projeto associado aos pedidos
Se os pedidos sujeitos a residência de dados são afetados e quais
Descrições das tendências que está a observar
Consoante o tipo de problema, inclua:
Erros: percentagem aproximada de pedidos que falham ou devolvem erros, códigos de resposta, mensagens de erro e tempo decorrido até à receção da resposta de erro.
Latência: percentis afetados (P50 / P90 / P95 / P99), diferença em relação ao valor de referência do cliente e exemplos de pedidos lentos com data e hora de envio e de receção.
Ambos: capturas de ecrã ou uma tabela com dados de erros ou latência, além da forma como determinou que as taxas de erro ou a latência estavam acima do 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.
Lentidão no modo Fast ou na Camada de escala
Possível causa: as métricas estão combinadas entre camadas, pelo que o tráfego da camada padrão mascara o desempenho das camadas pagas.
Verifique:
Os filtros estão limitados a uma única camada e a um único modelo.
Comparação da velocidade dos 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.