Zubnet AIAprenderWiki › Otimização
Treinamento

Otimização

Também conhecido como: Otimização de modelos, otimização de inferência
O amplo conjunto de técnicas usadas para tornar modelos de IA mais rápidos, menores, baratos ou precisos. Inclui otimizações de treinamento (precisão mista, gradient checkpointing, paralelismo de dados), otimizações de inferência (quantização, pruning, destilação, speculative decoding) e otimizações de serving (batching, caching, balanceamento de carga). Otimização é a razão pela qual você consegue rodar um modelo de 14B parâmetros num laptop.

Por que isso importa

Capacidade bruta não significa nada se você não pode arcar com o custo de rodá-la. Otimização é a diferença entre uma demo de pesquisa e um produto em produção. É a razão pela qual modelos open-weights podem competir com provedores de API, por que IA móvel existe, e por que custos de inferência continuam caindo.

Em profundidade

Otimização em IA é na verdade três disciplinas separadas que compartilham um nome. Otimização de treinamento é sobre tornar o processo de aprendizado mais rápido e barato. Otimização de inferência é sobre fazer o modelo treinado responder mais rápido e usar menos hardware. Otimização de serving é sobre lidar com muitos usuários simultâneos de forma eficiente. A maioria das pessoas confunde esses porque as técnicas às vezes se sobrepõem, mas os objetivos e restrições são diferentes. Uma otimização de treinamento como gradient checkpointing troca tempo de computação por memória — você recomputa ativações durante o backward pass em vez de armazená-las. Faz sentido quando você está limitado por memória de GPU durante um treinamento de vários dias. Não faria sentido durante a inferência, onde não há backward pass. Entender qual fase você está otimizando, e que recurso está trocando por qual, é a base para tomar boas decisões aqui.

Quantização: O Maior Ganho Único

Se você pudesse aprender apenas uma técnica de otimização, quantização seria a escolha. A ideia é simples: modelos são treinados em ponto flutuante de alta precisão (tipicamente bfloat16, que usa 16 bits por parâmetro), mas podem rodar em precisão muito menor sem perda catastrófica de qualidade. Um modelo de 14 bilhões de parâmetros em bfloat16 ocupa cerca de 28 GB de VRAM. Quantize para 4 bits (Q4_K_M na notação do llama.cpp) e ele cabe em menos de 9 GB — de repente roda numa única GPU de consumo. O trade-off de qualidade existe mas é menor do que se esperaria. Métodos modernos de quantização como GPTQ, AWQ e GGUF são calibrados contra dados reais para que os pesos mais importantes mantenham maior precisão. Em testes cegos, a maioria dos usuários não consegue distinguir entre um modelo em precisão total e sua versão quantizada de 4 bits para tarefas cotidianas. A diferença aparece em casos extremos — cadeias complexas de raciocínio, conhecimento factual de nicho, tarefas multilíngues — mas para a maioria dos casos de uso em produção, quantização é performance gratuita.

Velocidade de Inferência: Batching, Caching e Speculative Decoding

Além da quantização, os maiores ganhos de velocidade de inferência vêm de como você gerencia requisições em vez de como você encolhe o modelo. Continuous batching — a abordagem usada pelo vLLM e TensorRT-LLM — permite que o servidor processe múltiplas requisições simultaneamente, preenchendo ciclos ociosos de GPU que de outra forma seriam desperdiçados enquanto uma requisição espera seu próximo token. Otimização de KV-cache (como PagedAttention) evita que o overhead de memória do cache key-value cresça linearmente com o comprimento da sequência, o que é crítico para aplicações de contexto longo. Speculative decoding usa um modelo pequeno e rápido como "rascunho" para gerar vários tokens candidatos, e então o modelo grande os verifica em um único forward pass — se o modelo rascunho acerta (o que frequentemente acontece para texto previsível), você obtém múltiplos tokens pelo custo de uma chamada do modelo grande. Essas técnicas se compõem. Uma stack de serving bem ajustada usando continuous batching, quantização e speculative decoding pode servir o mesmo modelo a cinco a dez vezes o throughput de uma implementação ingênua.

A Equação de Custo na Prática

Para a maioria das equipes, otimização é em última análise sobre custo por consulta. Rodar um modelo 70B em um cluster de A100s custa dinheiro sério — aproximadamente US$ 8–15 por GPU por hora a preços de nuvem. Otimização determina se esse cluster lida com 50 requisições por segundo ou 500. Destilação é outra alavanca: você treina um modelo "aluno" menor para imitar as saídas de um modelo "professor" maior na sua tarefa específica. Um modelo destilado de 8B que iguala 90% da qualidade do modelo 70B no seu caso de uso particular custa uma fração para rodar. O workflow prático que muitas equipes seguem é: prototipar com o maior modelo disponível via API, medir qual nível de qualidade você realmente precisa, e então trabalhar de trás para frente — quantizar, destilar ou trocar para um modelo menor até acertar o ponto onde qualidade é aceitável e custo é sustentável. As equipes que pulam esse processo e vão direto para o maior modelo em produção estão quase sempre gastando demais.

Conceitos relacionados

← Todos os termos
← OpenAI Sobreajuste →
ESC