LiteLLM e OpenRouter: como criar um gateway de IA
Quando uma empresa usa vários modelos, espalhar chaves e nomes de fornecedores pelo código torna cada mudança mais arriscada. Um gateway de IA cria uma fronteira comum para routing, autenticação, custos e observabilidade, sem esconder as diferenças entre os modelos.
O que deve ficar atrás do gateway
A aplicação deve conhecer um alias estável — por exemplo maker-text ou support-vision — e não depender de dezenas de nomes específicos. O gateway resolve o alias para um provider e modelo configurados no servidor.
Assim, uma troca de fornecedor ou uma mudança de versão não exige uma alteração espalhada por todas as aplicações.
LiteLLM e OpenRouter têm papéis diferentes
OpenRouter é uma camada de acesso a vários modelos e providers. LiteLLM pode ser usado como proxy de aplicação, com aliases, chaves virtuais, logging, routing e políticas.
Podem coexistir: a aplicação fala com LiteLLM e o gateway encaminha algumas tarefas para OpenRouter ou para APIs directas.
Uma modalidade não é outra
Texto, visão, imagem, áudio e vídeo têm capacidades, parâmetros, tempos e preços diferentes. O alias maker-image não deve ser tratado como maker-video.
Antes de chamar um provider, o sistema deve confirmar se o modelo suporta a operação, a entrada, a resolução, a duração e as imagens de referência necessárias.
Fallback com critério
Um fallback só é seguro quando o modelo alternativo consegue cumprir o contrato da tarefa. Um modelo de texto não substitui automaticamente um gerador de vídeo.
Também não se deve fazer fallback em erros causados por credenciais inválidas, payload incorrecto ou falta de quota sem registar a decisão e limitar a repetição.
Segredos, equipas e custos
As chaves dos providers ficam exclusivamente no servidor. O gateway pode separar aplicações, equipas e ambientes, aplicar limites e associar utilização a um projecto.
O frontend recebe apenas o resultado necessário; nunca recebe OPENROUTER_API_KEY, LITELLM_MASTER_KEY ou credenciais de fornecedores.
A leitura da PontoTi
A PontoTi deve começar com aliases pequenos, modo mock, limites por tarefa e uma página de health/custos. Depois pode acrescentar routing por qualidade, latência e preço.
A abstração só vale a pena se tornar a operação mais segura e substituível; não deve ser uma camada que ninguém consegue diagnosticar.