Modelos abertos e fechados

docs.scrimba.com

Por baixo de tudo, um modelo é uma pilha enorme de pesos treinados (os números que ele aprendeu durante o treinamento) que prevê o próximo token. Este capítulo é sobre as duas formas como esses pesos chegam até você, modelos fechados que você aluga por meio de uma API e modelos de peso aberto que você mesmo pode executar, e sobre onde cada um deles realmente roda. O padrão para o qual todo mundo é direcionado é um modelo fechado hospedado, e os provedores têm pouco motivo para destacar as alternativas, então vale a pena conhecer o cardápio completo e saber quando cada parte dele importa.

Pesos abertos, pesos fechados

Existem duas formas de você ter acesso a um modelo de IA, e a diferença está em onde o modelo realmente vive.

A primeira forma é um modelo fechado, às vezes chamado de proprietário. Você só chega até ele pela API da empresa, que é uma espécie de porta de entrada online: você envia texto, recebe texto de volta, e é só isso. Os pesos do modelo, aquela pilha gigante de números treinados que fazem tudo funcionar, ficam trancados nos servidores da empresa. Você está alugando acesso, não é dono de nada.

A segunda forma é um modelo de peso aberto. Aqui a empresa publica esses pesos, então você pode baixar sua própria cópia e executá-la em hardware que você controla. Pense nisso como alugar um apartamento cuja fiação você nunca vai poder ver, versus ser dono de uma cópia das plantas do prédio.

A maioria das pessoas começa com uma API fechada porque é a porta de entrada mais fácil de atravessar, e esse é um bom ponto de partida. A opção aberta é real e vale a pena conhecer, para que você entenda que alugar é uma escolha, não o único caminho.

JunoPesos abertos, pesos fechados Um modelo fechado vive nos servidores da empresa e você chega até ele pela API dela, então você está alugando acesso. Um modelo de peso aberto tem seus números publicados, então você pode baixar uma cópia e executá-la você mesmo. Começar com uma API fechada é perfeitamente aceitável, mas ajuda saber que a outra porta existe.

Toda a distinção se resume a uma pergunta: quem fica com os pesos? Com um modelo fechado ou proprietário, os pesos nunca saem do provedor e você conversa com o modelo só por meio de uma API. Com um modelo de peso aberto, os pesos são publicados sob uma licença que permite que você baixe e execute onde quiser.

Cuidado aqui, porque "peso aberto" não é a mesma coisa que "código aberto". Quase todo LLM "aberto" libera os pesos treinados, mas não libera os dados de treinamento nem o código de treinamento, então você não consegue reproduzir o modelo do zero por completo. Algumas licenças também trazem restrições de uso, coisas como um limite de tamanho de empresa que pode usá-lo comercialmente, ou restrições sobre usos permitidos. Leia a licença antes de se comprometer; "aberto" é um espectro, não uma coisa binária.

Em termos de capacidade, os modelos fechados de ponta (os modelos mais capazes disponíveis em um dado momento) costumam liderar os benchmarks públicos. Mas modelos de peso aberto fortes já são bons o suficiente para boa parte das tarefas reais, e essa diferença continua diminuindo com o tempo. Na prática, o certo é não presumir que você precisa do modelo mais poderoso que existe. Muitos trabalhos são bem atendidos por um modelo aberto, e você só descobre testando na sua própria tarefa, não em um ranking.

JunoPesos abertos, pesos fechados Fechado significa só via API, com os pesos ficando no provedor; peso aberto significa pesos publicados que você pode baixar e executar. Peso aberto não é código aberto, já que os dados e o código de treinamento geralmente ficam privados e a licença pode restringir o uso, então leia com atenção. Modelos fechados de ponta lideram os benchmarks, mas um modelo de peso aberto forte dá conta de bastante trabalho real, então escolha pensando na tarefa.

O que "aberto" realmente te dá é controle e o fim da dependência de um único fornecedor. Você pode fixar os pesos exatos para que o modelo nunca mude silenciosamente sob seus pés, inspecionar seu comportamento e executá-lo em qualquer lugar onde tenha hardware. Isso é uma vantagem real quando reprodutibilidade ou residência de dados importam.

O que isso não te dá é almoço grátis. Peso aberto quase sempre significa pesos mais licença, e não código aberto de verdade: sem dados de treinamento, muitas vezes com termos de licença nada triviais. Então a revisão de conformidade e de licenciamento vira trabalho de verdade na sua mesa, e um modelo com licença de aparência permissiva ainda pode restringir uso comercial ou redistribuição de formas que só aparecem depois, se você pular a leitura.

A diferença de capacidade dos modelos de ponta também é real para as tarefas mais difíceis, mesmo diminuindo com o tempo. Então escolha pensando na tarefa que você tem à frente, não no rótulo. Para a maior parte do trabalho de rotina, um modelo de peso aberto é mais do que suficiente; na fronteira da dificuldade, o modelo fechado de ponta ainda pode levar vantagem.

A coisa que preciso ficar lembrando a mim mesmo: trate "aberto" como uma propriedade dos pesos e da licença juntos, e leia os dois. "Eu posso baixar" não é a mesma frase que "eu posso fazer qualquer coisa com isso", e a diferença entre essas duas já me pegou antes.

JunoPesos abertos, pesos fechados Pesos abertos te dão controle e uma saída da dependência de fornecedor: versões fixas, comportamento inspecionável, execução em qualquer lugar. Eles não te dão código aberto, então reserve orçamento para a licença e a revisão de conformidade, porque uma licença de aparência amigável ainda pode proibir uso comercial. Escolha pensando na tarefa, não no rótulo, e nunca leia "eu posso baixar" como "eu posso fazer qualquer coisa com isso".

Onde o modelo roda

Existe uma crença por aí de que escolher um modelo aberto significa que você tem que montar seus próprios servidores e rodar tudo sozinho. Isso não é verdade, e vale a pena esclarecer isso logo de início.

Um modelo pode rodar em um de dois lugares. Com um modelo hospedado, alguma empresa o executa nas máquinas dela e você chega até ele pela internet com uma chamada de API, que é uma pequena solicitação que seu código envia e da qual recebe uma resposta de volta. Você nunca toca no computador onde ele roda. Com autohospedagem, você mesmo executa o modelo, no seu próprio computador ou no seu próprio servidor.

Aqui está a parte que as pessoas costumam deixar passar. Um modelo aberto não te obriga a autohospedar. Você pode usar um modelo aberto por meio de uma empresa de hospedagem, do mesmo jeito confortável que usaria um modelo fechado: você envia uma solicitação, recebe uma resposta, e outra pessoa cuida de manter a máquina funcionando. Autohospedar é uma opção que você pode escolher, não uma regra que você precisa seguir.

JunoOnde o modelo roda Um modelo roda ou na máquina de outra pessoa, e você chega até ele pela internet, ou em uma máquina que você mesmo administra. Modelos abertos podem ir de qualquer um dos dois jeitos, então escolher um não significa que você de repente precisa gerenciar servidores. Você pode deixar uma empresa de hospedagem rodar um modelo aberto para você, exatamente como faria com um fechado.

Ajuda deixar de lado o modelo mental de "duas caixinhas", porque onde um modelo roda é, na verdade, um espectro. Em uma ponta, um modelo fechado chamado pela API do seu provedor. No meio, um modelo de peso aberto executado para você por uma hospedagem terceirizada. Na outra ponta, um modelo de peso aberto que você mesmo executa, que é a autohospedagem: você fornece a máquina e roda o programa que serve o modelo.

O motivo de ser barato se mover ao longo desse espectro é que um formato de API de mensagens de chat amplamente adotado se tornou um padrão de fato, e muitos provedores de hospedagem de modelos abertos e servidores autohospedados expõem esse mesmo formato. Então trocar de provedor costuma ser basicamente uma mudança de URL base e nome do modelo, não uma reescrita (veja chamando modelos a partir do código). Nada do que você aprende sobre como chamar um modelo fica preso a um único fornecedor.

De relance, autohospedar significa que você fornece o hardware (uma GPU capaz, ou um servidor de GPU alugado) e roda um programa de serviço na frente do modelo. Trate isso como trabalho de verdade que você está assumindo. Aqui ficamos no nível da decisão e não entramos mais fundo na configuração.

JunoOnde o modelo roda Pense em um espectro: fechado via provedor, aberto via hospedagem terceirizada, ou aberto autohospedado. Como tantos endpoints compartilham um mesmo formato de API de mensagens de chat, pular de um para outro costuma ser uma troca de base_url e nome de modelo, não uma reescrita. Autohospedagem é a ponta extrema, onde você é dono do hardware e do serviço, então recorra a ela de propósito, não por padrão.

Autohospedagem é infraestrutura, não uma missão paralela. No momento em que você executa o modelo sozinho, você assume o planejamento de capacidade, a escalabilidade sob carga, o tempo de atividade, os patches de segurança e as atualizações do modelo. "Roda no meu laptop" é uma demonstração; produção é uma conta bem diferente.

O caminho do meio que a maioria das equipes ignora é uma hospedagem gerenciada de modelo aberto. Você tem as vantagens do modelo aberto (custo menor do que os modelos fechados de ponta, a capacidade de fixar uma versão específica do modelo, opções sobre onde seus dados ficam, sem dependência de um único fornecedor) sem precisar montar as GPUs você mesmo. O formato de API de chat de fato é o seu seguro: mantenha seu código atrelado a essa interface e trocar de hospedagem, ou trazer um modelo para dentro de casa depois, continua sendo uma mudança de configuração, não uma migração.

Já vi um "autohospedagem rapidinha" comer um trimestre inteiro, então reservo a autohospedagem de verdade para quando uma pressão específica realmente exige isso: regras de residência de dados, uma economia de escala que joga a seu favor, ou um modelo que você precisa controlar de ponta a ponta. Na ausência de um desses motivos, a resposta é hospedagem gerenciada aberta ou fechada hospedada.

JunoOnde o modelo roda Rodar seu próprio modelo significa assumir capacidade, tempo de atividade, patches e atualizações, então não entre nisso à toa. O caminho que as equipes costumam ignorar é uma hospedagem gerenciada de modelo aberto: a economia e o controle de um modelo aberto sem precisar cuidar de GPUs. Escreva código para a API de chat padrão e trocas de provedor continuam sendo configuração, não migração. Guarde a autohospedagem de verdade para um motivo concreto, como residência de dados, matemática de escala, ou controle rígido sobre o modelo.

Quando cada opção faz sentido

Aqui está uma forma simples de entender essa escolha toda. Um modelo fechado e hospedado é como alugar: não há nada para configurar, você tem a melhor qualidade disponível, e paga um pouco a cada uso. Um modelo aberto que você mesmo executa está mais para ser dono: você tem mais controle e mais privacidade, e não existe uma conta por uso indo para um provedor, mas você assume o trabalho de manter tudo funcionando.

A maioria das pessoas tem razão em começar alugando por meio de uma API, e a maioria nunca precisa de mais do que isso. Alugar primeiro é o caminho normal e sensato.

O objetivo deste capítulo não era dizer que você deveria trocar para rodar o seu próprio modelo. Era só que você soubesse que a escolha é sua, para que, se um dia suas necessidades mudarem, você reconheça essa opção pelo que ela é.

Com um modelo escolhido, a próxima pergunta é como você conversa com ele. O próximo capítulo, Prompting, é sobre guiar o modelo que você escolher para que ele te dê o que você realmente quer.

JunoQuando cada opção faz sentido Pense nisso como alugar versus ser dono: um modelo fechado hospedado é alugar, um modelo aberto que você mesmo executa está mais para ser dono. Alugar por meio de uma API é o lugar certo para começar, e a maioria das pessoas fica feliz por lá mesmo. Agora você sabe que a outra porta existe, e esse é o ponto principal. A seguir vem Prompting, onde aprendemos a guiar o modelo que você escolheu.

Quando você realmente precisar escolher, pese os fatores mais ou menos nesta ordem. Primeiro, capacidade: um modelo fechado de ponta se justifica para essa tarefa, ou um modelo de peso aberto forte já é bom o suficiente? Segundo, sensibilidade dos dados: esses dados podem sair do seu domínio sob os termos de um provedor, ou a residência de dados (regras sobre onde os dados podem ficar e ser processados fisicamente) descarta isso?

Terceiro, a curva de custo. Uma API por token é barata para começar e continua barata em volume baixo, mas pode ficar cara em volume alto e constante, que é onde a autohospedagem de custo fixo pode vencer. Quarto, controle: você precisa fixar o comportamento exato entre versões, ou evitar ficar preso a um único fornecedor?

Na maioria das vezes, o movimento é o mesmo. Comece com uma API hospedada, porque é o caminho mais rápido para ter algo funcionando. Depois reavalie só quando uma pressão específica realmente aparecer: custo em escala, uma exigência de privacidade ou conformidade, ou uma necessidade real de capacidade ou controle.

Decida com base em evidências, não em padrões ou ideologia. Depois de decidir seu modelo, Prompting é como você consegue tirar dele uma saída confiável.

JunoQuando cada opção faz sentido Pese quatro coisas em ordem: capacidade necessária, sensibilidade dos dados, a curva de custo, e controle. Comece com uma API hospedada porque ela te coloca para funcionar mais rápido, e reavalie só quando uma pressão concreta aparecer, como custo em alto volume ou uma regra de residência de dados. Troque com base em evidência, não em achismo. Depois vá para Prompting para fazer o que você escolheu se comportar direito.

A versão simples. Para a maioria das equipes, uma API fechada hospedada é o padrão correto, e autohospedar um modelo de peso aberto é uma decisão de custo e controle, não uma insígnia de seriedade. Isso compensa depois de uma certa escala, ou sob uma restrição de conformidade ou de residência de dados, e não muito antes disso.

Então saiba mais ou menos onde a curva de custo se cruza para o seu volume, porque esse ponto de cruzamento é todo o argumento financeiro. Saiba o que suas regras de dados realmente exigem, não o que elas vagamente parecem exigir, que é onde entram segurança e limites e a questão do que você envia. E saiba que os pesos abertos também são o que te permite fazer fine-tuning livremente, nos seus próprios termos, sem precisar pedir permissão a um provedor (veja fine-tuning). Evitar a dependência de fornecedor, ficar preso aos preços, termos e ciclo de vida do modelo de um único provedor, faz parte do mesmo cálculo.

O motivo para aprender tudo isso não é para que você vá autohospedar. Já vi gente montar sua própria infraestrutura para provar um ponto e se arrepender já na segunda semana de plantão. É que o caminho padrão é o modelo fechado hospedado, e os provedores têm pouco motivo para te apontar as alternativas, então um engenheiro que conhece o cardápio completo faz uma escolha deliberada, em vez de uma escolha herdada.

Com a questão do modelo resolvida com base em seus méritos, Prompting é onde começa o trabalho do dia a dia de conseguir uma boa saída.

JunoQuando cada opção faz sentido Para a maioria das equipes, a API fechada hospedada é o padrão certo, e autohospedar um modelo de peso aberto é uma decisão de custo e controle que compensa depois de uma certa escala ou sob uma restrição de conformidade, não um traço de personalidade. Saiba onde sua curva de custo se cruza, saiba o que suas regras de dados realmente exigem, e lembre-se de que pesos abertos te dão fine-tuning livre e uma saída da dependência de fornecedor. Já vi a autohospedagem para provar um ponto, e o arrependimento é real. Aprenda o cardápio completo para escolher de propósito, e depois siga para Prompting.