Sair da API é uma linha de código.
A reescrita que todos orçamentam não existe. Os serving stacks self-hosted falam a mesma API compatível com OpenAI que o seu código já chama, por isso a migração da infraestrutura por baixo é o base URL. O resto honesto são evals, não engenharia, e corta nos dois sentidos: a mesma linha que permite sair deles permite sair de nós.
Neste artigo 3 secções
- As equipas ficam em APIs de IA alojadas muito depois de quererem sair, porque orçamentaram uma reescrita. Para a infraestrutura por baixo, essa reescrita não existe: os serving stacks self-hosted expõem a mesma API compatível com OpenAI que o seu código já fala.
- A migração do lado da aplicação é o base URL e a chave. Os seus prompts, os seus streaming handlers, as suas ferramentas: inalterados.
- O resto honesto é o comportamento do modelo: um modelo diferente responde de forma diferente, por isso o verdadeiro trabalho de migração é correr as suas evals nas suas tarefas. Mais pequeno do que uma reescrita, e testável antes de se comprometer.
- A mesma propriedade protege-o à saída: open weights mais uma API standard significam que sair de nós também é uma linha. Vendemos a clientes que podem sair.
A reunião acontece em todo o lado. Toda a gente na sala quer sair da API alojada, escolha a razão: os dados que não deviam sair, o escalão de rate limit que não vai sobreviver ao roadmap, a fatura que escala com o sucesso. E então alguém diz a frase que a encerra: estamos demasiado integrados, seria uma reescrita. Seis meses depois, a mesma reunião, a mesma frase, mais um sprint de retry logic pelo meio.
A frase merece uma auditoria, porque a integração que descreve tem a profundidade de um valor de configuração.
h2 (#the-standard): O mundo normalizou-se enquanto ninguém estava a olhar
Algo útil aconteceu no mundo do serving nos últimos anos: o formato da API da OpenAI tornou-se o wire standard de facto para falar com modelos de linguagem, e os serving stacks open-source adotaram-no de propósito. As mesmas rotas, o mesmo formato de pedido, o mesmo protocolo de streaming, para o núcleo mais usado da superfície: chat completions, streaming, embeddings. Quando entregamos um endpoint privado, ele fala esse dialeto nativamente. O seu SDK não sabe que mudou de sítio. Se a sua aplicação se apoiou nos extras proprietários de um vendor, isso é uma auditoria curta, não uma reescrita, e percorremo-la consigo: a maioria dos extras tem equivalentes diretos ou shims finos.
- OPENAI_BASE_URL=https://api.vendor.example/v1
+ OPENAI_BASE_URL=https://inference.yourcompany.internal/v1
OPENAI_API_KEY=**** # your key, issued by you, revoked by youPrompts, streaming handlers, retry logic, ferramentas: intocados. Esse diff é toda a migração da infraestrutura por baixo. É exatamente por isso que o orçamento da reescrita merece desconfiança: foi calculado para um mundo em que cada fornecedor tinha o seu próprio wire format, e esse mundo acabou.
h2 (#the-honest-remainder): O que muda realmente: o modelo
Agora a metade honesta, porque a afirmação da linha única só é verdadeira para a infraestrutura por baixo. Um modelo diferente é um colega diferente. Faça-lhe a mesma pergunta e a resposta volta redigida e estruturada de outra forma. Prompts afinados para um modelo podem precisar de ajustes. Os casos limite mudam de lugar. Isto é trabalho real. É também delimitado, testável e barato em comparação com o que orçamentou: corra o seu conjunto de evals existente (ou construa o pequeno conjunto que devia ter de qualquer forma) contra o modelo candidato nas suas tarefas reais, compare, decida. Acontece antes de se comprometer, num endpoint que pode experimentar, não depois de uma reescrita que não pode desfazer.
| UMA LINHA (A INFRAESTRUTURA POR BAIXO) | TRABALHO REAL (O MODELO) |
|---|---|
| A PARTE QUE TODOS SOBRESTIMAMO base URL e a API key | Correr as suas evals no novo modelo |
| Formatos de pedido e resposta, streaming | Ajustes de prompts onde o comportamento mudou |
| O seu código de retry e de ferramentas | Decidir a quantização e o dimensionamento (isto fica connosco) |
| Extras da API específicos do vendor, se os usou | Uma auditoria curta: substituir ou criar um shim para cada um |
Repare no que não apareceu nesta tabela: nenhuma afirmação de que o modelo aberto é igualmente bom. Não fazemos essa afirmação, porque envelhece mal e porque, de qualquer forma, não a devia aceitar de um vendor. A execução das evals substitui a afirmação. As suas tarefas, os dois modelos, lado a lado, e a decisão é sua com as evidências à frente. Essa passagem de evals faz parte do nosso deployment, juntamente com o dimensionamento e o trade-off da quantização (mostrado, não escondido), que é onde um managed host ganha o que cobra.
h2 (#both-ways): A linha corta nos dois sentidos, de propósito
Tudo o que está acima descreve também a saída de nós. Open weights são ficheiros portáteis. O endpoint fala o dialeto standard. Os seus dados vivem na sua máquina e partem consigo. Se deixarmos de merecer o que executa, a migração para longe de nós é a mesma linha única, e construímo-la assim deliberadamente, pela mesma razão que o resto desta empresa eliminou os contadores e recusa impostos de saída (o argumento sobre as taxas de egress é a mesma postura um nível abaixo). Um anti-lock-in que não se pode exercer é uma palavra de brochura. Os clientes que podem sair, e ficam mesmo assim, são a única referência que vale a pena ter.
Mais uma liberdade viaja junto: assim que o modelo é seu, ninguém o retira debaixo dos seus prompts, e a versão que passou nas suas evals continua a ser a versão que responde até decidir o contrário. Numa API alojada, esse calendário pertence a outra pessoa.
“A mesma linha que permite sair deles permite sair de nós. É esse o ponto.”
Respostas diretas
A API compatível com OpenAI é mesmo compatível?+
O núcleo mais usado (chat completions, streaming, embeddings) é o standard de facto que o mundo do serving implementa. Se se apoiou nos extras proprietários de um vendor, esses recebem uma auditoria curta: a maioria tem equivalentes diretos ou shims finos, e percorremos essa lista consigo.
O que acontece ao meu prompt engineering?+
A maior parte transfere-se. Alguma precisa de ajustes onde o comportamento do novo modelo difere, e as suas evals mostram exatamente onde. Orçamente horas de afinação de prompts, não uma reescrita.
A uma linha de distância do seu próprio endpoint.
Traga-nos o modelo que quer executar. Dimensionamo-lo, instalamo-lo atrás da API que o seu código já fala e corremos as evals consigo antes de mudar o que quer que seja.
Fale com um engenheiroChegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro
