Saltar para o conteúdo
EuroVPSEuroVPS

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.

Por EuroVPS EngineeringA casa das máquinas

6 min de leitura
Neste artigo 3 secções
Em resumo
  • 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.

THE MIGRATION, IN ITS ENTIRETY
- 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 you

Prompts, 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 keyCorrer as suas evals no novo modelo
Formatos de pedido e resposta, streamingAjustes de prompts onde o comportamento mudou
O seu código de retry e de ferramentasDecidir a quantização e o dimensionamento (isto fica connosco)
Extras da API específicos do vendor, se os usouUma 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 engenheiro

Chegou 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
XIn

Faltam 6 min