Um modelo é três coisas fundidas juntas: uma arquitetura, um conjunto de parâmetros e o fantasma de seus dados de treinamento. A arquitetura é o projeto — ela define como a informação flui pelo sistema. Um Transformer processa texto por meio de camadas de mecanismos de atenção. Um modelo de difusão denoisa iterativamente ruído aleatório em imagens. Um modelo Mamba usa espaços de estado seletivos para processar sequências sem atenção alguma. A arquitetura determina que tipo de entrada o modelo pode lidar e que tipo de saída pode produzir, mas por si só não faz nada. É uma estrutura vazia sem conhecimento.
Parâmetros são o conhecimento. Durante o treinamento, o modelo ajusta milhões ou bilhões de pesos numéricos até que possa prever bem seus dados de treinamento. Esses pesos codificam tudo o que o modelo "sabe" — gramática, fatos, padrões de raciocínio, estilo, vieses. Quando as pessoas dizem que um modelo tem 70 bilhões de parâmetros, querem dizer 70 bilhões de números aprendidos que coletivamente representam quaisquer padrões que o modelo extraiu de seu corpus de treinamento. Os parâmetros são o modelo no sentido mais concreto: são o arquivo que você baixa, a coisa que é carregada na memória da GPU, o artefato que transforma a arquitetura em capacidade.
Quando você baixa um modelo, está baixando esses parâmetros serializados em um arquivo. O formato importa mais do que você talvez imagine. Arquivos .pt ou .bin do PyTorch são o formato nativo para modelos treinados no PyTorch — eles usam a serialização do pickle do Python, o que significa que, tecnicamente, podem conter código arbitrário. Isso é uma preocupação real de segurança se você baixar modelos de fontes não confiáveis. O safetensors, desenvolvido pela Hugging Face, resolve isso armazenando apenas os dados brutos de tensores em um formato que não pode executar código. Também é mais rápido de carregar porque suporta acesso mapeado na memória. A maioria dos repositórios de modelos já迁移ou para safetensors como padrão.
GGUF é uma criatura totalmente diferente. Desenvolvido pela comunidade llama.cpp, o GGUF é projetado para inferência em CPU e em hardware de consumo com CPU/GPU mista. Ele empacota os pesos do modelo junto com metadados sobre quantização, configuração do tokenizador e detalhes da arquitetura em um único arquivo autocontido. Se você viu alguém rodando um modelo de 70B em um MacBook, eles provavelmente estão usando um arquivo GGUF que foi quantizado para precisão de 4 bits ou 5 bits. ONNX (Open Neural Network Exchange) toma outra abordagem — é um formato de interoperabilidade projetado para permitir que você treine um modelo em um framework e o execute em outro, frequentemente com otimizações específicas de hardware aplicadas pelo runtime.
Modelos passam por um ciclo de vida que a maioria dos usuários nunca vê. O pré-treinamento é a parte cara: um modelo base é treinado em grandes volumes de dados (muitas vezes trilhões de tokens para modelos de linguagem grandes) com custos que variam de centenas de milhares a centenas de milhões de dólares. Isso produz um modelo base que pode prever texto, mas não é particularmente útil para conversas. A finaçao adapta o modelo base para tarefas específicas — seguir instruções, geração de código, diagnóstico médico — usando conjuntos de dados muito menores e curados. Técnicas de alinhamento como RLHF ou similares tornam as saídas do modelo mais úteis e menos prejudiciais. A quantização comprime a precisão do modelo de ponto flutuante de 16 bits ou 32 bits para 8 bits, 4 bits ou até menos, trocando uma pequena quantidade de qualidade por reduções drásticas nas exigências de memória e computação. A implantação coloca o modelo atrás de uma API ou carrega-o em um dispositivo. O atendimento lida com as solicitações reais de inferência em larga escala.
A distinção entre modelos abertos e fechados é mais ambígua do que parece. Quando a Meta "libera" o Llama, eles publicam os pesos do modelo — você pode baixar os parâmetros e rodar o modelo em seu próprio hardware. Mas eles não liberam os dados de treinamento ou o código completo de treinamento. A Mistral faz algo semelhante. Esses são mais corretamente chamados de "modelos de peso aberto". Modelos verdadeiramente de código-fonte aberto incluiriam pesos, dados de treinamento, código de treinamento e pipelines de avaliação — um padrão que quase ninguém atende. Do outro lado, modelos fechados como GPT-4 e Claude estão disponíveis apenas por meio de APIs. Você nunca vê os pesos, não pode modificar o modelo e está sujeito aos termos de serviço do provedor. A diferença prática é enorme: modelos de peso aberto lhe dão controle, privacidade e a capacidade de finaçao, mas você paga pela computação e assume complexidade operacional. Modelos fechados lhe dão conveniência e frequentemente melhor desempenho, mas você está alugando acesso a um sistema de outra pessoa.
Benchmarks são o método padrão para comparar modelos, e são profundamente imprecisos. Um modelo que obtém a pontuação mais alta no MMLU (um teste de conhecimento com múltipla escolha) pode ter dificuldades com sua tarefa específica. A contaminação de benchmarks — onde os dados de teste vazam para os dados de treinamento — é comum e difícil de detectar. O Chatbot Arena, que classifica modelos com base em votos de preferência humana cega, é mais confiável, mas ainda reflete a qualidade geral de conversação em vez do desempenho específico de domínio. A única maneira confiável de escolher um modelo é testar candidatos no seu trabalho real. Escreva dez prompts representativos, execute-os em três ou quatro modelos e compare as saídas. Esse investimento de uma hora lhe dirá mais do que qualquer lista de classificação.