Arquitetura de confiabilidade

Tratamos a "estabilidade" como o recurso número um do produto. Esta página explica como conseguimos isso e o que acontece quando algo dá errado.

Por que a confiabilidade é tão difícil?

Desenvolvedores que se conectam diretamente à API oficial enfrentam coisas como:

• Limitação de taxa / indisponibilidade regional
• Um único canal de pagamento ou conta sendo banido
• Problemas de compatibilidade durante mudanças de versão de modelo
• Filas em horários de pico e picos de latência do primeiro token

Se um serviço de relay for apenas um proxy simples, esses problemas são repassados tal como estão aos usuários, ou até piorados. Nossa abordagem é projetar o sistema com base na premissa de que "os upstreams são instáveis", em vez de tratar isso como uma exceção.

Nossa arquitetura de roteamento multi-origem

Para cada chamada de API, a requisição é tratada seguindo o caminho abaixo:

Mecanismos centrais:

• Pool de múltiplos upstreams: vários canais independentes ficam atrás do mesmo modelo, evitando pontos únicos de falha
• Sondagem de saúde: monitoramos continuamente a taxa de sucesso, a latência do primeiro token e a taxa de limitação de cada upstream, e canais não saudáveis são automaticamente reduzidos de peso ou removidos
• Failover automático: quando o canal primário retorna 5xx / limitação de taxa / timeouts, a requisição muda para um canal de backup em milissegundos, geralmente sem impacto do seu lado
• Reconexão de interrupção de stream: quando uma resposta em streaming cai no meio, tentamos retomá-la em protocolos que oferecem suporte a isso

Nível de serviço (SLA)

Nossos compromissos externos são fundamentados no "que realmente podemos entregar" — não fazemos promessas vazias.

O nível Economy é para desenvolvedores individuais que querem o melhor custo-benefício e podem tolerar flutuações ocasionais; se o seu negócio tem requisitos rígidos de confiabilidade, escolha o nível Enterprise ou entre em contato com nossa equipe de vendas para um plano personalizado.

Como a disponibilidade é medida:

• Contamos apenas a taxa de sucesso das requisições "do lado da LMU AI", excluindo problemas de rede do lado do usuário, erros de parâmetros e recusas de conteúdo do próprio modelo upstream
• Uma falha isolada com duração < 60 segundos não é contabilizada
• O relatório mensal inclui taxas de sucesso e latência P95 detalhadas por modelo e por período de tempo

O que acontece durante um incidente

Oscilação breve (< 5 minutos)

• A camada de roteamento troca de upstreams automaticamente, sem anúncio
• A página de status registra o evento

Interrupção de um único upstream (< 1 hora)

• A camada de roteamento conclui a troca; se for visível para alguns usuários/modelos, publicamos na página de status
• Usuários Standard e Enterprise são notificados por e-mail

Impacto regional ou em múltiplos upstreams simultaneamente

• O evento é fixado na página de status com atualizações periódicas
• Usuários Enterprise recebem atualizações de progresso por e-mail em tempo real
• Um postmortem é publicado dentro de 48 horas após o término do evento

O que não fazemos

Para evitar enganar os usuários, atualmente não prometemos o seguinte:

• Troca contínua e com latência zero: o failover introduz latência extra de milissegundos a segundos, então nunca será completamente contínuo
• Compensação de compatibilidade entre modelos: se um modelo upstream em si for descontinuado (por exemplo, uma versão de modelo é encerrada pelo provedor), anunciamos isso em vez de trocar silenciosamente para um modelo diferente
• Novas tentativas ilimitadas: requisições que falham são repetidas um número limitado de vezes conforme a política, para que você não pague por chamadas repetidas inesperadas

FAQ

Última atualização: 2026-09-10