Parâmetros de LLM: entenda os pesos e os ajustes de geração

Os parâmetros de LLM dizem respeito a duas decisões diferentes: qual modelo usar e como solicitar suas respostas. Um grande modelo de linguagem (LLM) de 70B tem cerca de 70 bilhões de parâmetros aprendidos; definir a temperatura como 0.2 muda a forma como uma API compatível seleciona a resposta, não a quantidade de pesos do modelo. Escolha o modelo adequado à tarefa e configure apenas os controles disponíveis naquela API e versão específicas.

Verificado na documentação oficial dos provedores em 25 de outubro de 2026. Essa distinção ficou ainda mais importante: algumas APIs atuais rejeitam controles de amostragem, enquanto outras os aceitam, mas os ignoram. Copiar uma configuração pronta pode, portanto, causar uma falha na requisição ou simplesmente não fazer diferença.

Parâmetros de LLM: duas funções diferentes

Os parâmetros do modelo pertencem ao modelo treinado. Os parâmetros de geração pertencem à requisição enviada a ele. Alterar os segundos não retreina os primeiros.

Pense em um edifício. A estrutura determina o que ele consegue sustentar; as aletas ajustáveis de um brise mudam a forma de usar o espaço. Girar uma aleta não acrescenta um andar. Da mesma forma, mudar a temperatura não transforma um modelo menor em um maior.

O que são os parâmetros de um LLM?

Quando o assunto é o tamanho do modelo, parâmetros são valores numéricos aprendidos, principalmente pesos, que influenciam seus cálculos. O treinamento ajusta esses valores a partir de dados. Já nas conversas sobre APIs, o termo “parâmetros” também designa configurações que influenciam a geração das respostas. A explicação da IBM diferencia os valores aprendidos da configuração externa.

Quando um fornecedor diz “nosso modelo tem mais parâmetros”, está falando do modelo. Quando um desenvolvedor diz “mude os parâmetros para extrair dados de faturas”, provavelmente está falando das configurações da requisição. Esclareça o sentido antes de interpretar qualquer uma dessas frases como uma afirmação sobre desempenho.

O que é um parâmetro individual em um LLM?

Um parâmetro aprendido é um número usado dentro da rede, como um peso que altera a intensidade com que um sinal interno contribui para outro. Ele não é um fato devidamente etiquetado, um documento ou uma palavra guardada em uma gaveta própria.

Existe ainda uma categoria separada: os hiperparâmetros de treinamento, configurações como a taxa de aprendizado que determinam como o treinamento ocorre. Uma aplicação empresarial que chama um modelo existente normalmente não controla essas configurações de treinamento nem os pesos aprendidos.

Tokens são outra coisa. São as unidades em que a entrada e a saída são divididas, muitas vezes pedaços de palavras. Colocar mais tokens em um prompt não aumenta a quantidade de parâmetros do modelo. O guia sobre tokens em IA explica essa unidade; o guia sobre system prompts mostra como as instruções orientam o comportamento sem alterar os pesos treinados.

Parte um: o que os parâmetros revelam sobre a escala do modelo

A quantidade de parâmetros ajuda a estimar armazenamento e processamento, mas não basta para escolher o melhor modelo para uma tarefa da empresa. Use esse número como ponto de partida para planejar a infraestrutura. A decisão final depende de uma avaliação específica da tarefa.

O que significam os bilhões de parâmetros de um LLM?

O “B” indica bilhões de valores aprendidos. Um modelo descrito como 70B tem aproximadamente 70 bilhões de parâmetros; “T” indica trilhões. Os nomes divulgados podem usar números arredondados, por isso uma estimativa precisa de implantação deve considerar o checkpoint real e seu formato de armazenamento.

Dois modelos com a mesma quantidade de parâmetros podem ter arquiteturas, dados de treinamento, métodos de treinamento e especializações diferentes. Até o mesmo modelo pode ocupar quantidades muito diferentes de memória, dependendo da precisão usada para armazenar cada peso.

Para quem contrata uma solução para a empresa, a pergunta útil é se o modelo atende aos critérios de aceitação: ele extrai o total correto da fatura, preserva o identificador do cliente ou produz um patch que passa nas verificações exigidas? O número maior não responde a essas perguntas.

Como calcular a memória dos pesos de um modelo de 70B

O armazenamento bruto dos pesos é a quantidade de parâmetros multiplicada pelos bytes por parâmetro. Para um modelo hipotético com exatamente 70 bilhões de pesos, o cálculo é o seguinte. Trata-se de uma conta, não de um resultado medido em uma implantação.

Esses valores estão em gigabytes decimais. Os 140 GB correspondem a cerca de 130.4 GiB, a unidade binária exibida por algumas ferramentas de memória. A conversão muda a unidade, não o modelo.

A documentação da Hugging Face explica como a quantização, que armazena os pesos com menor precisão, reduz a memória necessária enquanto busca preservar a acurácia. Nosso guia de quantização de LLMs aborda os formatos e suas vantagens e limitações.

Prompts mais longos e requisições simultâneas também alteram a carga de execução. A documentação do estimador de memória de modelos da Hugging Face separa explicitamente o carregamento do modelo da execução da inferência, o processo de gerar respostas.

O que a quantidade de parâmetros diz sobre custo e qualidade

Mais pesos geralmente exigem mais recursos de armazenamento e operação, mantidas as demais condições. Mas essa ressalva faz muita diferença. Precisão, arquitetura, hardware, processamento em lotes e quantidade de texto processado afetam o resultado.

Na hospedagem própria, a quantidade de parâmetros ajuda a selecionar opções de hardware. Em uma API hospedada, ela não determina a conta: isso depende das regras de cobrança do provedor e da sua carga de trabalho. Um modelo que exige várias tentativas ou muita correção humana também pode ser uma escolha operacional ruim, mesmo que pareça eficiente.

Quanto à qualidade, trate o tamanho como um indício de capacidade, não como uma nota. Um documento de contratação deve pedir resultados com entradas representativas do seu uso, os casos de falha e as condições da avaliação. Não deve aceitar uma estimativa não publicada da quantidade de parâmetros de um modelo fechado como evidência.

Parâmetros totais e ativos nos modelos MoE

Os parâmetros totais descrevem o modelo inteiro; os ativos descrevem o caminho de processamento informado para um token. Os dois números importam em um modelo de mistura de especialistas, normalmente chamado de MoE, de mixture-of-experts.

Um MoE reúne sub-redes especialistas e um roteador que escolhe quais delas processam cada token. Esses “especialistas” são componentes matemáticos, não profissionais identificados que você possa designar para tarefas contábeis ou jurídicas. Ativar apenas uma parte pode reduzir o processamento em comparação com ativar o modelo inteiro, mas os demais pesos ainda precisam existir em algum lugar. A explicação da PyTorch sobre MoE aborda o roteamento e a comunicação envolvidos.

A expressão “104B ativos” aparece em um exemplo concreto publicado pelo próprio fabricante: o anúncio do Kimi K3.1 Pro, da Moonshot AI, informa 2.8T de parâmetros totais e 104B ativos. Convertendo o total para 2,800B, temos 104 ÷ 2,800, ou cerca de 3.7% ativos. Essa porcentagem é um cálculo nosso a partir dos números anunciados, não uma medição de ganho de velocidade nem uma classificação de qualidade.

Outro exemplo, o model card do Qwen3-235B-A22B, da Qwen, informa 235B de parâmetros totais e 22B ativados. A ilustração mantém visíveis as salas inativas porque a necessidade de armazenamento não desaparece quando um token percorre outro caminho.

Na implantação, pergunte como o modelo inteiro é armazenado e distribuído, como os especialistas são alocados no hardware e qual é o desempenho com o seu volume real de requisições simultâneas. A quantidade de parâmetros ativos não é uma especificação de memória da unidade de processamento gráfico (GPU). O artigo sobre mistura de especialistas aprofunda essa questão de infraestrutura.

Parte dois: os parâmetros de geração orientam a resposta

As configurações de geração mudam a seleção dos tokens e as condições de encerramento dentro das capacidades do modelo. Uma API é a interface que sua aplicação chama para solicitar uma resposta. Suas configurações não fornecem material de referência ausente, não corrigem uma instrução ambígua e não garantem uma resposta correta.

Temperatura: quanto as escolhas se concentram

A temperatura altera a distribuição de probabilidades usada para escolher o próximo token. Valores menores favorecem mais as opções prováveis; valores maiores permitem mais variação. Isso ajuda a escolher entre uma redação mais consistente e uma variedade maior de rascunhos.

Em um fluxo de processamento de faturas, a variação raramente é o objetivo. Para criar alternativas de títulos de campanha, pode ser útil. Mas uma temperatura baixa não torna verdadeiro um número de fatura inventado, e uma temperatura alta não acrescenta conhecimento.

Nem mesmo uma requisição com temperatura zero é uma garantia universal de reprodutibilidade. O glossário da Anthropic alerta explicitamente que entradas idênticas ainda podem produzir resultados diferentes com temperatura zero. A reprodutibilidade precisa ser avaliada no sistema inteiro que executa o modelo.

Top-p: quanto do conjunto de candidatos continua disponível

Top-p, também chamado de amostragem por núcleo, limita o conjunto de candidatos pela probabilidade acumulada. É um limiar de probabilidade, não uma quantidade de candidatos nem uma porcentagem do vocabulário.

Em uma distribuição ilustrativa para o próximo token de 0.60, 0.25, 0.10 e 0.05, um limiar de top-p de 0.9 precisa dos três primeiros candidatos: os dois primeiros somam 0.85, enquanto os três primeiros chegam a 0.95. Esses números são um exemplo didático, não uma saída observada de um modelo.

A temperatura redistribui as probabilidades; o top-p restringe o conjunto elegível. Ao configurar uma aplicação empresarial pela primeira vez, altere um controle de amostragem por vez. Essa também é a recomendação da OpenAI na referência de Chat Completions.

Limite de tokens do LLM: um teto, não um tamanho solicitado

O limite de tokens de geração define o teto da resposta. Ele não pede que o modelo use exatamente aquela quantidade de tokens nem amplia a janela de contexto, que é sua capacidade de lidar com a conversa.

Um limite baixo demais pode interromper um objeto JSON, uma frase ou um patch de código. Um teto alto não torna a resposta útil automaticamente. Indique o tamanho desejado no prompt e deixe uma margem suficiente até o limite para que o resultado venha completo.

O raciocínio exige mais uma distinção. A referência de Responses da OpenAI informa que o teto de saída inclui tanto os tokens visíveis quanto os de raciocínio. A referência de Messages da Anthropic também contabiliza os tokens de pensamento em max_tokens. Não dimensione uma requisição com raciocínio como se todos os tokens permitidos fossem aparecer na resposta final.

Sequências de parada: encerrar em um ponto definido

Uma sequência de parada encerra a geração quando uma string designada aparece. Use esse recurso apenas quando a aplicação tiver um delimitador confiável, como um marcador explícito de fim que não possa aparecer legitimamente no conteúdo.

Uma quebra de linha é uma má escolha de parada genérica para um relatório com várias linhas. Uma chave de fechamento é uma má escolha para JSON aninhado: a primeira ocorrência pode encerrar a resposta cedo demais. Para extração estruturada, prefira o mecanismo de esquema compatível com o provedor e valide os campos retornados.

Em geral, faz sentido começar sem sequências de parada personalizadas. O teto de tokens de saída e a validação continuam necessários.

Penalidades: reduza a repetição com cuidado

A penalidade de presença considera se um token já apareceu. A penalidade de frequência considera quantas vezes ele apareceu. Penalidades positivas desestimulam a reutilização; negativas podem incentivá-la, quando o endpoint aceita esses valores.

Texto repetido nem sempre é um defeito. Um código de produto, nome de cliente, chave JSON ou identificador de programação pode precisar reaparecer exatamente da mesma forma. Penalizar essa repetição pode atrapalhar a tarefa.

Para extração e código, comece sem penalidades de repetição. Na redação de textos, primeiro corrija instruções que induzam a estruturas repetitivas. Só depois considere uma pequena penalidade compatível com a API e confira se ela melhora o texto sem alterar a terminologia obrigatória. A referência de geração do Google também alerta que penalidades de frequência negativas podem causar ciclos de repetição de tokens.

Faixas e valores padrão nas APIs da OpenAI, Anthropic e Google

O endpoint, o modelo e a versão da API determinam quais configurações você pode enviar. Um mesmo nome de campo em SDKs não prova que todos os provedores implementam o mesmo controle.

A tabela considera Chat Completions para a OpenAI, Messages API na versão 2026-10-21 para a Anthropic e generateContent da Gemini Developer API para o Google. Ela não incorpora configurações do Vertex AI nem da Interactions API do Google.

NI significa que a documentação atual citada para o campo não informa uma faixa numérica ou um valor padrão. Não significa zero, ilimitado ou não compatível. A orientação de omitir um campo é uma recomendação para a aplicação, não um valor padrão inventado para o provedor.

Fontes: esquema de requisição da OpenAI, esquema de requisição da Anthropic, migração de versão da Anthropic, esquema de geração do Google, metadados de modelos do Google e faixa de top-p do Google.

A tabela geral de solução de problemas do Google informa uma faixa de temperatura mais estreita que a referência do campo de geração. Use a referência do campo em conjunto com maxTemperature do modelo escolhido; consulte Model.temperature, Model.topP e Model.outputTokenLimit para os valores específicos de cada modelo. Não trate uma requisição de exemplo como um padrão documentado.

OpenAI: verifique primeiro a compatibilidade com raciocínio

O guia atual do GPT-6 da OpenAI orienta a remover temperature e top_p quando o esforço de raciocínio for diferente de none. GPT-6 Astra e GPT-6.1 Sol não aceitam none; GPT-6 Sol e GPT-6 Luna aceitam. Essa é uma restrição de compatibilidade, não a documentação de uma temperatura numérica fixa.

O endpoint também importa. Responses usa max_output_tokens, cujo mínimo no esquema atual é 16; ali não são informados um padrão numérico nem um máximo universal. Seu esquema de criação não disponibiliza os campos stop, presence_penalty ou frequency_penalty de Chat Completions. Em Chat Completions, a referência marca explicitamente stop como incompatível com o3 e o4-mini e descontinua max_tokens em favor de max_completion_tokens.

A regra prática é montar a requisição para o endpoint escolhido e depois aplicar as regras de compatibilidade do modelo. Não copie a tabela inteira para uma única requisição.

Anthropic: a versão da API pode eliminar o controle

O guia de migração de 21 de outubro da Anthropic informa que enviar temperature, top_p ou top_k com a versão 2026-10-21 da API resulta em erro 400, mesmo que o valor enviado seja o padrão. Quando os campos são omitidos, o comportamento inclui temperatura 1.0.

Versões anteriores da API não devolvem automaticamente essa flexibilidade a todos os modelos. A documentação de pensamento da Anthropic informa que modelos como Claude Sonnet 5.5 rejeitam valores de amostragem diferentes dos padrões, independentemente de o pensamento estar ativado. Ela informa um top-p padrão de 0.99 para esses modelos e diz explicitamente que 1 é rejeitado. Uma faixa genérica de uma versão anterior não se sobrepõe a essa regra do modelo.

Para gerar conteúdo de fato, forneça um orçamento positivo de max_tokens dentro do limite do modelo. O mínimo documentado de zero serve para pré-aquecer o cache sem produzir uma resposta; não é uma configuração útil para extração.

Google: uma configuração aceita pode não ter efeito

O guia de migração do Gemini 3.6 Flash e do 3.5 Flash-Lite, do Google, informa que esses modelos ignoram as configurações descontinuadas de temperatura, top-p e top-k. O documento orienta os desenvolvedores a removê-las e diz que futuras gerações de modelos vão rejeitá-las com erro 400.

Isso cria um tipo de falha diferente de uma requisição rejeitada: a aplicação pode parecer aceitar uma mudança de temperatura enquanto o modelo continua se comportando exatamente como antes. Consulte a documentação do modelo selecionado antes de interpretar uma resposta bem-sucedida como prova de que o controle funcionou.

Configurações iniciais para tarefas da empresa

Comece pelo comportamento compatível com o provedor e por uma definição mensurável de sucesso. Os números abaixo são nossas sugestões iniciais para endpoints que permitem ajustes, não valores padrão dos provedores, configurações ótimas medidas ou combinações prontas que funcionam em qualquer API. As regras de compatibilidade acima têm prioridade.

Extração: preserve os valores exatos

Para campos de faturas, classificação de chamados de suporte ou metadados de contratos, experimente temperatura 0 ou 0.2 apenas onde houver suporte. Deixe o top-p como está. Omita paradas personalizadas e penalidades de repetição; em um modelo compatível com esses controles em OpenAI Chat Completions, definir explicitamente as duas penalidades como 0 é outra forma de estabelecer uma configuração de referência sem penalidades.

Nas requisições atuais da Anthropic e nos modelos Gemini Flash citados, omita os controles de amostragem. Use definições explícitas dos campos, categorias permitidas, exemplos de dados ausentes e o recurso de saída estruturada compatível com o provedor. Valide o resultado independentemente da formatação.

Para um registro curto extraído, um teto inicial de 1,000 tokens de saída pode servir como primeiro experimento em uma requisição compatível sem raciocínio. Não é um limite universal: verifique cortes na resposta e o uso real, e reserve separadamente os tokens de raciocínio quando necessário. Peça um marcador de valor ausente em vez de um número de fatura inventado.

Critério de aceitação: todos os campos obrigatórios estão presentes, os valores correspondem à fonte e as informações ausentes continuam ausentes. Passar na validação de JSON, por si só, não basta.

Redação: varie as palavras e preserve os fatos

Para um e-mail de prospecção ou uma descrição de produto, comece pelo comportamento padrão compatível com o modelo. Em um endpoint ajustável, compare esse resultado com temperatura 0.7, sem mudar o top-p. Especifique no prompt o público, o tamanho, o tom, os fatos obrigatórios e as afirmações proibidas.

Comece sem penalidades. Se um modelo compatível de OpenAI Chat Completions reutilizar repetidamente expressões indesejadas, uma penalidade de frequência de 0.2 é um experimento moderado dentro da faixa documentada. Mantenha o ajuste apenas se a revisão mostrar uma melhora; os nomes obrigatórios de produtos precisam permanecer intactos.

Em modelos que eliminam os controles de amostragem, peça explicitamente abordagens diferentes, como um rascunho factual e conciso e outro narrativo. Avalie as diferenças no trabalho produzido.

Critério de aceitação: variação útil sem novas afirmações factuais. “Mais surpreendente” não é sinônimo de “melhor texto para a empresa”.

Código: reserve espaço para concluir e confira o comportamento

Para um patch pontual em um endpoint ajustável, temperatura 0 ou 0.2 é um ponto de comparação razoável. Para um modelo de raciocínio, siga a configuração compatível e omita campos de amostragem não aceitos. Deixe de fora as penalidades de repetição e as paradas personalizadas, a menos que um protocolo testado as exija.

Forneça o código relevante, as restrições e o comportamento esperado. Reserve espaço de saída suficiente para um patch completo. Se a resposta atingir o teto, trate o resultado como incompleto em vez de presumir que a parte visível pode ser aplicada com segurança.

Critério de aceitação: o patch atende à especificação e passa nas verificações adequadas. Identificadores repetidos são normais em código, e uma resposta que parece plausível não comprova que ele funciona.

O que a quantidade de parâmetros e os controles não garantem

A promessa exagerada é que um único número pode substituir uma avaliação. Não pode, seja esse número uma quantidade de pesos ou uma temperatura.

Um modelo maior não é automaticamente melhor para o seu fluxo de trabalho específico. Uma quantidade menor de parâmetros ativos em um MoE não significa que o modelo inteiro caiba nessa quantidade de memória. Uma temperatura baixa não garante veracidade. Um teto alto de saída não garante um argumento completo, e uma chamada de API bem-sucedida não prova que todas as configurações enviadas foram aplicadas.

A evidência útil é uma entrada representativa, uma condição de sucesso definida e um resultado inspecionado. Para uma compra, peça ao fornecedor que demonstre o fluxo de trabalho na configuração que você realmente usará. Para o desenvolvimento, registre modelo, endpoint, versão da API, prompt e configurações, para entender o que mudou quando o comportamento mudar.

Próximos passos para quem compra, opera e desenvolve

Quem compra deve comparar resultados; quem opera deve definir o que é falha; quem desenvolve deve remover configurações incompatíveis. Essas responsabilidades convergem no mesmo pequeno conjunto de avaliação.

Quem escolhe um serviço hospedado pode seguir adiante sem saber a quantidade de parâmetros, desde que o serviço demonstre os resultados exigidos. Adie a compra de hardware para hospedagem própria até dimensionar o checkpoint completo, a precisão e a carga de trabalho. Quem já opera um fluxo que funciona não precisa substituí-lo porque outro modelo anuncia um número maior.

Desenvolvedores que trocam de modelo ou versão da API devem verificar a compatibilidade agora. Para quem usa uma interface gerenciada sem acesso aos controles de geração, a sintaxe dos campos da requisição costuma ter pouco impacto, mas a validação da saída continua necessária.

1. 1

   Reúna exemplos das tarefas que precisam dar certo

   Na próxima segunda-feira, reúna 20 exemplos representativos de um fluxo de trabalho, incluindo entradas incompletas, ambíguas e excepcionalmente longas. Escreva o resultado esperado ou os critérios de revisão antes de comparar os modelos.

2. 2

   Deixe explícita a configuração da requisição

   Registre o endpoint, o modelo e a versão da API. Confira quais controles são compatíveis, remova os demais e escolha um orçamento de saída que permita um resultado completo. Mantenha no prompt a terminologia obrigatória e o comportamento esperado quando faltarem dados.

3. 3

   Mude uma coisa por vez e avalie o resultado

   Compare a configuração de referência com um único ajuste compatível. Na extração, confira a correspondência com a fonte; nos textos, a exatidão dos fatos e a utilidade; no código, o comportamento e as verificações. Mantenha a configuração mais simples, a menos que a mudança justifique sua adoção.

Perguntas frequentes

Como funciona o parâmetro de temperatura em um LLM?

Ele altera o quanto a distribuição de probabilidades do próximo token se concentra. Valores menores favorecem as escolhas mais prováveis; valores maiores permitem mais variedade. A temperatura muda a amostragem, não os pesos aprendidos, e algumas APIs atuais rejeitam ou ignoram essa configuração.

Qual é o tamanho aproximado de um modelo de 70B?

Para exatamente 70 bilhões de pesos, o armazenamento bruto é de cerca de 140 GB em 16-bit, 70 GB em 8-bit ou, no caso ideal, 35 GB em 4-bit. Esses valores decimais não incluem a memória usada durante a execução nem o espaço adicional exigido pela quantização. O checkpoint real e a carga de trabalho determinam os requisitos de implantação.

Quais são os quatro tipos de parâmetros?

Não existe uma classificação universal de quatro tipos para LLMs. Uma distinção útil separa parâmetros aprendidos do modelo, configurações de arquitetura, configurações de treinamento e configurações de geração. São categorias para entender o sistema, não uma afirmação de que toda API tem quatro controles.

Qual é a diferença entre GPT e LLM?

LLM significa grande modelo de linguagem, a categoria mais ampla. GPT significa transformador generativo pré-treinado e dá nome a uma família de modelos e a uma abordagem específicas dentro dessa categoria. Outras famílias de modelos de linguagem também são LLMs.

Quais são os quatro tipos de LLM?

Não existe uma lista única e padronizada de quatro tipos. A distinção entre modelos densos e de mistura de especialistas descreve a arquitetura; a distinção entre pesos abertos e fechados descreve a disponibilidade. Elas respondem a perguntas diferentes e não devem ser combinadas em uma suposta classificação de qualidade.

ChatGPT é um LLM ou uma IA?

ChatGPT é uma aplicação de IA que usa modelos. É preciso distinguir a aplicação, o modelo selecionado nela e as configurações de API disponíveis aos desenvolvedores; são camadas diferentes.

Que tipos de IA não são LLMs?

A IA vai além dos modelos de linguagem. Um classificador de fraudes ou um sistema de visão computacional pode usar métodos de aprendizado de máquina sem usar um LLM. A quantidade de parâmetros também não é uma característica exclusiva dos modelos de linguagem.

Qual é o LLM mais inteligente?

A quantidade de parâmetros não permite dar uma resposta que valha para qualquer tarefa. Compare os modelos com exemplos representativos do trabalho, usando os mesmos critérios de aceitação e uma configuração documentada. O resultado de um benchmark não resolve todas as tarefas de uma empresa.

A que área da IA os LLMs pertencem?

LLMs são modelos de aprendizado profundo usados para processar e gerar linguagem. Seus parâmetros aprendidos pertencem ao modelo; a temperatura e outros controles da requisição dizem respeito à forma como a aplicação o utiliza.

Para receber explicações práticas sobre sistemas de IA e as decisões por trás deles, assine a newsletter.