Fiabilidade, novas tentativas e tempos limite

Cada pedido é monitorizado desde o início até ao primeiro token. Se uma via de acesso ao modelo bloquear ou falhar, o pedido passa para outra antes de lhe chegar qualquer conteúdo.

Recuperação automática

• A maioria dos modelos está disponível através de várias vias. Cada pedido começa pela que está a funcionar melhor.
• Uma via que devolva um erro ou esteja inacessível é descartada para esse pedido, que é repetido noutra. Se a via estiver a funcionar, aguardamos, por muito que um pedido grande demore; se ficar sem enviar nada durante 3 minutos (5 com esforço de raciocínio elevado), é considerada falhada.
• As vias que falham repetidamente passam para o fim da fila para todos. Uma via que deixe de enviar dados num quinto ou mais dos seus pedidos fica atrás de uma que esteja a responder sem problemas. Cada uma volta a ser usada assim que recuperar.
• Nada lhe é enviado até chegar um token real, pelo que tudo isto é invisível: recebe uma resposta um pouco mais lenta, não um erro.

A página de modelos mostra o estado de cada modelo em tempo real (operacional, com desempenho degradado ou indisponível), com base em pedidos reais e nas nossas verificações: cada modelo de chat é testado pelo menos a cada 10 minutos.

Tempos limite

Um stream não envia nada nos primeiros 20 segundos de espera pelo primeiro token; depois, abre com comentários keep-alive até a resposta começar. Um pedido sem streaming não envia nada até estar concluído, pelo que o streaming é adequado para clientes que desistem quando os cabeçalhos demoram a chegar (o fetch do Node espera 5 minutos por eles). Defina o tempo limite do seu cliente para pelo menos 10 minutos para raciocínios demorados, respostas longas e imagemns. Os SDKs da OpenAI usam 10 minutos por predefinição; alguns clientes HTTP usam 30 ou 60 segundos.

Limites de pedidos

Não existe um limite global de pedidos na sua conta: as chaves só têm limites se os definir. Um espaço de trabalho pode processar 32 pedidos em simultâneo; um pedido adicional recebe 429 concurrency_limit_exceeded com retry-after. Se um modelo estiver sobrecarregado, o pedido é repetido nas outras vias; se nenhuma responder, recebe 503 model_unavailable com retry-after. Aguarde antes de tentar novamente ou ative o encaminhamento inteligente.

Quando um modelo está indisponível

Em casos raros, todas as vias de acesso a um modelo falham. Sem encaminhamento inteligente, o pedido termina com 503 model_unavailable e retry-after. Quando as vias devolvem erros mas o modelo continua a responder a outros pedidos, trata-se de uma falha pontual que costuma passar em segundos, pelo que continuamos a tentar durante até 2 minutos antes de devolver o erro. Quando o modelo está indisponível para todos, o erro é imediato; quando as vias não enviam nada, chega num prazo de 10 minutos. Com o encaminhamento inteligente, responde uma alternativa semelhante.