Como planejar o failover entre provedores de modelos da OpenAI

Quando uma empresa depende de um fluxo de trabalho com IA, mesmo uma breve indisponibilidade do provedor pode atrasar decisões ou interromper serviços. Temos trabalhado com clientes do setor financeiro que usam modelos da OpenAI para desenvolver aplicativos com agentes de IA e fluxos de trabalho de cibersegurança. Neste artigo, explicamos como planejamos o roteamento em produção e a recuperação de cargas de trabalho críticas. Ao longo do texto, usamos como exemplo uma avaliação de fraude somente leitura em um fluxo de pagamentos.

Neste artigo, o acesso direto (1P) é feito pela API da OpenAI. No acesso por terceiros (3P), o aplicativo usa modelos da OpenAI por meio de um provedor de nuvem, independentemente de onde é executado. Veremos como o acesso direto permite avaliar modelos e recursos em prévia, como os requisitos da carga de trabalho e a conectividade privada influenciam a escolha da rota e quais operações podem mudar de provedor com segurança em caso de falha. Em seguida, apresentaremos um prompt para implementar a política em um gateway existente com o Codex e explicaremos o que validar antes de habilitar o failover.

Por que usar as duas rotas?

O acesso direto à OpenAI tem valor mesmo quando o ambiente de produção usa um provedor de nuvem. Um dos principais motivos é o acesso a modelos e recursos em prévia. Quando estão disponíveis pela API direta, as equipes elegíveis podem avaliá-los em seus próprios fluxos de trabalho antes que o provedor de nuvem escolhido passe a oferecê-los.

O ambiente em que o fluxo de trabalho é executado costuma influenciar a escolha da rota de produção. Um serviço de nuvem de terceiros pode se adequar à infraestrutura e aos controles operacionais que o aplicativo já usa, enquanto o acesso direto à OpenAI pode atender melhor aos requisitos de outro fluxo. Valide os modelos, os recursos e o comportamento necessários na rota escolhida e use o acesso direto à OpenAI para continuar os experimentos. A disponibilidade depende do provedor, do endpoint, da região e da sua conta.

Para cargas de trabalho críticas, também consideramos o failover entre 1P e 3P, desde que validado. O failover entre provedores consiste em repetir uma solicitação por meio de outro provedor aprovado quando o principal não consegue atendê-la. Isso só ajuda quando é seguro repetir a solicitação e a alternativa atende aos requisitos do fluxo de trabalho.

Um provedor global de pagamentos pode usar a Responses API para uma avaliação de fraude independente e somente leitura. Se a chamada atingir o tempo limite antes que o resultado seja usado, o aplicativo poderá repeti-la por uma rota secundária validada, dentro do prazo da transação.

Uma sessão em andamento da Agents API exige outra estratégia de recuperação. Por si só, a troca de provedor não retoma a conversa nem o trabalho salvo, tampouco reconcilia as ações anteriores. Recuperar essa sessão é bem mais difícil e está fora do escopo deste artigo.

Por essa razão, tratamos o suporte a vários provedores como um recurso da plataforma e decidimos se cabe usar failover em cada fluxo de trabalho.

Roteamento planejado e failover

Escolher a rota de produção e aprovar o failover são decisões distintas. O roteamento planejado pode distribuir o tráfego entre provedores ou direcionar o excesso de demanda a outra rota. Cada estratégia exige testes próprios de capacidade, custo, qualidade e recuperação.

Alguns clientes têm usado a Decisions API como fonte opcional de informação para decisões de roteamento. Para preservar a resiliência do fluxo de trabalho, defina como o roteamento deve funcionar se esse serviço ficar indisponível.

Nos diagramas, a rota 1P é a principal, e uma rota 3P aprovada é a secundária. Qualquer uma delas pode ser a principal, dependendo da carga de trabalho.

O papel do roteador

Figura 1. A API da OpenAI é a rota principal, e um provedor terceirizado aprovado é a rota secundária. A plataforma opera o roteador, e o aplicativo define a política. Os modelos, os recursos, a capacidade, os controles e a disponibilidade podem variar entre as rotas.

Você pode usar o roteador de modelos ou o gateway de LLM existente se ele puder aplicar regras distintas a cada rota. Direcione o tráfego normal à rota principal. Use a rota secundária testada apenas quando as condições de failover forem atendidas.

Defina quem pode usar cada rota, em quais regiões e com quais modelos e APIs. Registre as pessoas jurídicas, as equipes, as contas ou os projetos nos provedores e as regras de tratamento de dados que receberam aprovação. A aprovação se aplica apenas às cargas de trabalho e regiões acordadas.

Conectividade privada e escolha da rota

Muitos clientes de setores regulamentados exigem conectividade privada como parte de seus controles de segurança. Para esses clientes, escolher uma rota também envolve verificar como a nuvem em que o aplicativo é executado pode se conectar de forma privada a cada provedor. O diagrama mostra um aplicativo e um gateway na rede privada do cliente, com caminhos privados distintos para cada provedor.

Figura 2. A rota principal usa a API da OpenAI (1P), e a secundária usa um provedor aprovado (3P), como Amazon Bedrock ou Azure OpenAI. Apenas o tráfego de recuperação elegível passa pela rota secundária.

Na data de publicação, as opções de conectividade privada diferem entre 1P e 3P. Para o acesso direto à OpenAI (1P), o OpenAI Private Link usa um Azure Private Endpoint. Para acessar a API da OpenAI por esse caminho privado a partir da AWS ou do Google Cloud, as cargas de trabalho precisam de uma conexão com o Azure gerenciada pelo cliente.

Para o acesso por terceiros (3P), o Amazon Bedrock usa endpoints de interface de VPC específicos de cada API por meio do AWS PrivateLink, enquanto o Azure OpenAI usa endpoints privados do Azure. Antes de habilitar o failover, verifique o DNS, o acesso e o suporte regional aos modelos e às APIs nas duas rotas. O OpenAI Private Link não alterna automaticamente entre endpoints regionais. Por isso, a recuperação regional exige configuração e testes próprios. Qualquer recuperação que recorra ao HTTPS público também exige aprovação explícita.

O suporte oferecido pelos provedores pode mudar. Consulte a documentação oficial antes de escolher ou habilitar uma rota.

Quais operações podem usar failover?

Nem toda operação conta com uma rota secundária adequada. Alguns exemplos:

• Recursos indisponíveis: Um fluxo de trabalho pode usar a pesquisa na Web pela API direta da OpenAI para consultar informações atuais. Se a rota secundária não oferecer esse recurso, não pule a pesquisa sem aviso. Valide uma implementação alternativa ou mantenha o failover desabilitado para essa operação.
• Comportamento não validado: Ter um modelo com o mesmo nome ou uma API compatível não basta. Antes de habilitar a rota secundária, execute nela o harness e as avaliações que o fluxo de trabalho já usa.
• Restrições de residência de dados ou de estado: Não mude para um destino que viole os requisitos aprovados de localização dos dados ou que não tenha acesso ao estado necessário para concluir a operação com segurança.

Quando nenhuma rota secundária atender aos requisitos, coloque o trabalho em uma fila respeitando o prazo acordado, use uma alternativa aprovada com funcionalidade reduzida ou atendimento manual, ou interrompa a execução com segurança. Uma etapa de inferência que admite nova tentativa pode ser elegível para failover mesmo que o fluxo completo não seja.

Uma avaliação de fraude somente leitura que atingiu o tempo limite pode admitir nova tentativa se o resultado ainda não tiver sido usado e houver tempo suficiente. Depois que a saída chega a outro sistema, a recuperação exige um procedimento de reinício já testado. Se houver possibilidade de uma ação já ter sido concluída, confirme o resultado e impeça a duplicação de ações antes de reiniciar.

Quando e como acionar o failover

No exemplo de pagamentos, um modelo ocupado ou indisponível pode ser substituído por outro modelo aprovado. Isso é fallback de modelo. Repetir a avaliação por meio de outro provedor é failover entre provedores. Às vezes, tanto o modelo quanto o provedor mudam.

Primeiro, verificamos se trocar de provedor ajudaria. Um gateway, um serviço de recuperação de informações ou um sistema de identidade compartilhado pode afetar ambas as rotas. Teste a conectividade, o acesso e a capacidade da rota secundária. Verifique também se a recuperação regional é compatível com seus modelos, suas ferramentas hospedadas e seus requisitos de localização dos dados.

Se as falhas ou a lentidão nas respostas persistirem, um circuit breaker pode suspender o envio de novas solicitações à rota afetada. Defina limites de erros e de tempo de resposta por provedor, modelo, região e fluxo de trabalho. Cada solicitação ainda precisa atender aos critérios de failover.

Antes de repetir uma solicitação, verifique se é seguro fazê-lo e se ela pode ser concluída dentro do prazo do fluxo de trabalho. A rota secundária precisa estar aprovada, habilitada, em boas condições de operação e testada para a carga adicional. Também deve haver orçamento disponível. Consulte a documentação da OpenAI sobre códigos de erro e limites de taxa. Confira também as regras dos demais provedores para erros, novas tentativas, cotas e cobrança.

A tabela abaixo oferece um ponto de partida conservador para o failover automático. Além do código de status HTTP, leve em conta os detalhes do erro informados por cada provedor.

Uma única camada deve controlar as novas tentativas no aplicativo, no SDK e no gateway para evitar que elas se multipliquem. Use um limite compartilhado de novas tentativas e siga as orientações de Retry-After quando o valor for válido. Caso contrário, use recuo exponencial limitado com variação aleatória. Aumente o intervalo entre as tentativas, introduza uma variação aleatória e limite o número de tentativas. Repita apenas chamadas de inferência seguras, respeitando os prazos tanto da solicitação quanto do fluxo de trabalho.

Limite o tráfego de failover para evitar sobrecarga na rota secundária. Retome o tráfego pela rota principal gradualmente depois que solicitações representativas permanecerem dentro dos limites de erros e de tempo de resposta por um período definido. Interrompa o aumento do tráfego se esses limites forem excedidos. Se ambas as rotas estiverem com restrições, siga a política de recuperação acordada para o fluxo de trabalho.

Implemente a política de failover com o Codex

Agora podemos usar o Codex para aplicar essas regras de recuperação a um gateway de LLM existente. No exemplo de pagamentos, limitamos as mudanças à etapa independente de avaliação de fraude somente leitura. A rota principal continua em uso, e o failover permanece desabilitado até que a rota secundária seja aprovada e validada.

No Codex, abra o repositório responsável pela configuração do gateway ou pelo roteamento do aplicativo. Em seguida, adapte o prompt abaixo ao seu fluxo de trabalho e às rotas que pretende usar.

Implemente o failover entre provedores para [workflow’s self-contained, read-only inference step] em [repository/gateway] e deixe-o desabilitado por padrão. Preserve a rota principal e reutilize o gateway existente, as rotas aprovadas da plataforma e a política do fluxo de trabalho.

Verifique as versões do gateway, do SDK e dos adaptadores, a configuração de implantação, as APIs e a documentação oficial atual. Separe as alterações do aplicativo e as do gateway de acordo com os respectivos responsáveis e as revisões necessárias. Forneça a configuração e os testes de integração para as dependências sob responsabilidade de outras equipes. Indique quais controles não têm suporte. Não presuma aprovações nem limites. Mantenha desabilitadas as rotas de failover que dependem deles até confirmar as aprovações e os limites aplicáveis.

Use mapeamentos de erros específicos de cada provedor que já tenham sido testados. Permita o failover em caso de falha transitória de serviço ou de rede, ou de limitação de taxa comprovadamente temporária, somente se for seguro repetir a solicitação. A rota secundária deve estar aprovada, habilitada e operacional, oferecer os recursos e os controles de dados necessários, ter capacidade testada e dispor de orçamento e tempo suficientes para concluir a solicitação. Bloqueie o failover em caso de solicitação inválida, falha de acesso, recusa, esgotamento de cota, créditos ou orçamento, erro desconhecido ou erro 429 de causa incerta.

Use um único controlador de novas tentativas para o cliente, o gateway e o SDK. Desabilite as cadeias de novas tentativas ou de failover que entrem em conflito. Aplique um único limite para o total de tentativas e respeite tanto o prazo da solicitação quanto o do fluxo de trabalho. Use os tempos limite configurados para cada tentativa sem ultrapassar o prazo total. Aceite apenas um resultado por solicitação lógica e ignore respostas tardias de tentativas anteriores. Respeite o valor de Retry-After quando for válido. Caso contrário, use recuo exponencial limitado com variação aleatória. Se a saída for parcial ou o resultado de uma ação for incerto, nunca repita a operação sem verificar o que ocorreu. Não presuma que o estado seja transferido entre provedores. Aplique a política aprovada para colocar a solicitação em fila, retornar um resultado reduzido ou interromper a execução. Inclua a opção de desabilitar o failover manualmente, um circuit breaker e o retorno gradual à rota principal.

Teste o caminho real das solicitações com stubs HTTP locais e com o acesso à rede externa bloqueado. Use asserções para verificar a ordem das rotas, o número de chamadas e o tempo decorrido nos seguintes casos: sucesso, falhas elegíveis para failover, cada classe de erro bloqueada, critérios de elegibilidade não atendidos, saída parcial, ações de resultado incerto, orçamentos esgotados, falha nas duas rotas e acionamento dos controles de recuperação. Nos casos bloqueados, verifique se o número de chamadas à rota secundária é zero. Mantenha os limites sintéticos nas fixtures de teste e proteja os segredos. Não faça chamadas a serviços reais nem implantações sem autorização.

Entregue patches mínimos, os testes com indicação dos requisitos que cobrem, os resultados, as instruções de reversão e a lista das verificações pendentes no ambiente real. Mantenha desabilitadas todas as rotas de failover que ainda não foram verificadas.

O prompt pede ao Codex uma alteração pontual no gateway, testes que mostrem quando a rota secundária deve ser acionada e quando deve ser bloqueada, além de uma lista de verificações pendentes nas rotas reais. Revise primeiro o patch e os resultados dos testes locais. Em seguida, valide o comportamento do modelo, os controles de dados, a capacidade e a recuperação sob carga antes de habilitar o failover.

Valide as rotas e a recuperação

O exemplo de pagamentos ilustra verificações que também se aplicam a outras cargas de trabalho críticas. Teste as duas rotas com base nos critérios de aceitação do fluxo de trabalho para qualidade, segurança, formato da saída, uso de ferramentas e limites de contexto. Registre a configuração testada, a disponibilidade e os requisitos de acesso, incluindo os níveis de processamento e os recursos hospedados. Defina quando repetir os testes.

As restrições de dados da avaliação, incluindo os limites para registrar prompts e saídas em logs, se aplicam tanto à operação normal quanto à recuperação. Antes de habilitar qualquer uma das rotas, revise as credenciais, os caminhos de rede, a recuperação de informações, as ferramentas, o estado armazenado e os logs com os responsáveis pelas áreas jurídica, de privacidade, de segurança e de governança de dados.

Essa revisão exige consultar a documentação dos serviços e os contratos para confirmar onde os dados são processados e armazenados, por quanto tempo são retidos, como são criptografados e quem controla as chaves e o acesso. A localização do endpoint ou a existência de uma conexão privada, por si só, não basta. Os controles, os critérios de elegibilidade e as responsabilidades variam conforme o endpoint. Consulte os controles de dados da OpenAI.

Mesmo uma rota adequada precisa de capacidade disponível para o tráfego de recuperação. Um painel com dados agregados do provedor pode ocultar uma limitação de taxa no modelo de avaliação de fraude. Para cada rota, monitore as taxas de solicitações e de tokens, as solicitações simultâneas, as ocorrências de limitação de taxa, os tempos de resposta e o saldo do orçamento aprovado, discriminados por modelo, conta ou projeto e região.

Para verificar se a rota secundária suporta a demanda, faça um teste de carga que combine o trabalho que ela já atende com o tráfego esperado das avaliações de fraude e das novas tentativas. Use os resultados para definir o limite de tráfego de failover e decidir quais solicitações podem aguardar, prosseguir com funcionalidade reduzida ou ser interrompidas. A cota, por si só, não garante a conclusão dentro do prazo.

Mudar a rota da avaliação também pode alterar o custo e o tempo de resposta. Compare o custo por avaliação bem-sucedida, considerando os casos em que os dados não estão no cache, as tarifas de transferência de dados e os custos de conectividade. Meça também os atrasos adicionais quando os dados não estão no cache ou quando as solicitações passam de uma nuvem a outra.

Por fim, teste sob carga os cenários de falha da tabela, além dos casos em que faltam recursos ou a rota secundária está ocupada ou indisponível. Verifique se a política de recuperação funciona como previsto, incluindo os limites de tráfego, a interrupção manual e o retorno gradual à rota principal.

Para avaliar a recuperação, considere quanto tempo leva para restabelecer o serviço, quantas avaliações terminam dentro do prazo, a qualidade dos resultados, o custo e a ocorrência de ações duplicadas. Exercícios periódicos mantêm essas verificações em dia à medida que as credenciais expiram, as configurações mudam ou a capacidade varia.

Quem responde pela recuperação?

Uma forma prática de distribuir as responsabilidades é separar a gestão do serviço de roteamento da gestão do aplicativo. Uma equipe de plataforma pode operar as integrações com os provedores, o roteador, o monitoramento e os logs de auditoria. Caberia a essa equipe garantir que o serviço de roteamento esteja pronto para produção e aplicar os controles de destino, identidade, dados, tráfego e gastos. A equipe também designaria responsáveis de plantão para desabilitar rotas e gerenciar o retorno à rota principal.

Nesse modelo, os responsáveis pelo aplicativo definem quais operações podem usar failover, quais são as metas de serviço e qualidade e quais reduções de funcionalidade são aceitáveis. Eles também respondem pelos resultados de negócio, pelo contexto salvo para recuperação, pelas permissões das ferramentas, pela verificação das respostas e pela prevenção de ações duplicadas, inclusive quando há compartilhamento de estado ou de ferramentas.

Sua equipe pode combinar essas funções ou distribuí-las de outra forma. Antes de habilitar o failover, definam em conjunto quem aprova os controles, quem responde pelos testes das rotas e pelos procedimentos operacionais e quem tem autoridade para agir durante um incidente.

Conclusão

Considere o acesso direto à OpenAI entre as opções disponíveis, mesmo quando o ambiente de produção usa um provedor de nuvem. Ele permite que equipes elegíveis avaliem modelos e recursos em prévia e oferece uma possível rota de recuperação para cargas de trabalho críticas. Escolha entre 1P e 3P para produção com base nos recursos do fluxo de trabalho, no ambiente de hospedagem e nos controles, incluindo a conectividade privada quando exigida.

Para cargas de trabalho críticas, comece com uma única etapa de inferência independente e somente leitura. O Codex pode ajudar a implementar a política dessa etapa no gateway e a criar os testes locais. A validação nas rotas reais determina se a rota secundária atende aos requisitos do fluxo de trabalho. Assim, a equipe tem um plano de recuperação que define quando trocar de rota, quando interromper a operação e quem responde pela decisão.