A tese desta página: um modelo grande não cabe numa placa pequena por compressão, e sim por divisão de trabalho. Todo parâmetro ocupa disco, mas só uma parte precisa estar perto da GPU: a que roda em todo token. O resto pode ser consultado, sorteado ou lido sob demanda. Quando essa divisão é explícita, a pergunta de hardware muda de "cabe na minha VRAM?" para "qual pedaço precisa mesmo estar lá?", e essa é uma pergunta com resposta numérica. As oito etapas seguintes calculam essa resposta, peça por peça.
Explore cada etapa →
As contas, num só lugar
As 4 contas desta página. Clique em qualquer uma para pular direto para a etapa que a explica.
O modelo de referência desta página
No arquivo
177 B
Tabela de consulta
51 B
Especialistas · ativos
512 · 10
Um modelo de mistura de especialistas com tabela de consulta acoplada. Dos 177 bilhões de parâmetros do arquivo, 51 bilhões não são rede neural: são uma tabela que o modelo lê, e por isso o cartão do modelo anuncia só os 126 bilhões que calculam. Os números desta página usam esse formato porque ele é o caso extremo que torna a divisão visível; a mecânica vale para qualquer modelo com especialistas.
Honestidade, antes de começar: esta página não roda modelo nenhum. O que roda de verdade: a aritmética de bytes por precisão e a alocação em VRAM, RAM e disco; a tabela de n-gramas construída a partir do corpus impresso na etapa 2; o roteamento de especialistas, conferido contra a fórmula fechada na própria tela; a simulação de cache com as duas políticas; e as contas de custo da etapa 7. O que é modelo declarado e não medição: o tempo por token da etapa 5 e a curva de threads da etapa 6, com todos os parâmetros abertos porque dependem da máquina. O que é citado: a tabela de medições de referência da etapa 5, obtida numa máquina real e usada só para comparar a forma da curva.
Parâmetro é peso, peso é byte, e byte precisa de um endereço. Antes de qualquer discussão sobre velocidade existe uma pergunta puramente geográfica: o que vai para a VRAM, o que fica na RAM e o que continua no SSD. A regra que decide é simples: perto da GPU fica o que roda em todo token; longe fica o que roda de vez em quando.
Fórmula · o tamanho do arquivo
bytes = P × bits ÷ 8
Leia assim: P é o número de parâmetros e bits é quantos bits cada um ocupa depois da quantização. Em 16 bits, cada bilhão de parâmetros pesa 2 GB; em 4 bits, 500 MB. A conta é linear e não tem surpresa, mas repare no número mostrado como precisão efetiva: um formato chamado "3 bits" quase nunca ocupa 3 bits por peso, porque cada bloco de pesos carrega junto a escala e o ponto zero que permitem reconstruí-lo. O excedente é pequeno por peso e enorme no total.
A fronteira que importa não é a do arquivo, é a da parte quente. O corpo denso mais a área de trabalho precisam estar na placa, porque participam de todo token. Os especialistas participam por sorteio e a tabela por consulta, então os dois toleram morar longe. É por isso que um arquivo sete vezes maior que a VRAM pode carregar: o que precisa de VRAM não é o arquivo, é a fatia quente dele. Se você aumentar a área de trabalho até estourar a placa, a página avisa: aí não existe alocação possível, e a saída é reduzir contexto ou precisão.
Parte do que um modelo faz é redescobrir, a cada token, algo que é sempre igual: que Belo seguido de Horizonte é uma cidade, e não um elogio a uma vista. Isso pode ser calculado camada por camada ou pode ser consultado numa tabela. A tabela custa memória e zero multiplicação, e por isso pode ficar longe da GPU.
O corpus do livro, impresso inteiro
três palavras no livropar no livroprecisa calcular
Por que a tabela pode morar longe
A consulta depende só das palavras que já foram escritas, nunca do que a rede está calculando agora. Isso muda tudo do ponto de vista de hardware: dá para começar a buscar a linha da tabela enquanto a primeira camada ainda trabalha, e a busca termina antes de alguém precisar do resultado. Uma leitura que acontece em paralelo com cálculo e chega a tempo custa, para efeito prático, zero. É por isso que a tabela pode ficar na RAM, ou no SSD, sem virar gargalo.
Num modelo de mistura de especialistas, cada camada tem centenas de sub-redes e um roteador que escolhe umas poucas por token. O arquivo inteiro existe, mas em cada passo quase nada dele roda. O número que decide a velocidade não é o total: é o parâmetro ativo por token.
Cobertura conforme os tokens entram
Fórmula · quantos especialistas um prompt toca
tocados = E × (1 − (1 − k/E)ⁿ)
Leia assim: a chance de um especialista específico não ser escolhido em um token é (1 − k/E); em n tokens independentes, isso vira a potência n. O que sobra é a fração que foi tocada ao menos uma vez. A simulação acima roda o roteamento token a token e imprime as duas coisas lado a lado, para você conferir que a fórmula não é decorativa. A consequência prática é toda a etapa 5: um token puxa quase nada, um prompt puxa quase tudo.
O roteador de verdade não sorteia: ele é uma camada treinada que escolhe especialistas por afinidade com o conteúdo, e por isso o uso real é desigual, com uns poucos especialistas disparando muito mais que os outros. Aqui a escolha é um hash determinístico, o que dá uma distribuição uniforme e é o pior caso para a etapa seguinte. Guarde essa diferença: ela é exatamente o que decide se guardar especialistas na VRAM adianta alguma coisa.
Se os especialistas não cabem todos na placa, a VRAM que sobra vira prateleira e a pergunta passa a ser qual subconjunto guardar. Existem duas políticas óbvias: guardar o que acabou de ser usado, ou medir antes quais são os mais usados e fixar esses. Qual das duas ganha depende de um único número.
Zero significa uso uniforme: todo especialista dispara na mesma frequência. Valores altos concentram os disparos em poucos.
O teto teórico da tabela é a soma das probabilidades dos especialistas que cabem: nenhuma política pode acertar mais que isso sem adivinhar o futuro. Comparar as duas políticas com esse teto é o que separa "meu cache funciona" de "meu cache está perto do máximo que existe". Repare no caso de uso uniforme: as três linhas colapsam no mesmo número, que é a fração da tabela que coube. Cache sem desnível não é cache, é uma cópia menor.
Perfil contra LRU, na prática: o perfil precisa de uma passada de medição antes e envelhece mal quando o assunto muda, porque ele fixa o que era popular ontem. O LRU não precisa de medição nenhuma e se adapta sozinho, mas paga uma falta toda vez que a conversa vira. Em carga estável o perfil ganha; em carga variada, o LRU. E as duas são inúteis se o roteador espalhar os disparos por igual.
Todo peso que não está na memória certa é lido de novo a cada uso. Esse tráfego não aparece como erro em lugar nenhum: aparece como lentidão. E as duas fases do modelo sofrem de formas diferentes, porque uma processa um token por vez e a outra processa o prompt inteiro de uma vez.
O modelo, declarado
t_token = t_calc + bytes_fora ÷ banda
Este é o ponto da página em que a conta deixa de ser exata e passa a ser modelo. Ela ignora sobreposição entre leitura e cálculo, cache de página do sistema operacional e leitura antecipada, então o número absoluto é otimista. O que ela reproduz é a forma: platô enquanto os pesos cabem, degrau quando não cabem, e uma queda muito mais violenta na leitura de prompt do que na geração. Se você quiser o número da sua máquina, meça a sua; se quiser entender por que a curva tem esse formato, ela está aí. Um teste que vale fazer: volte à etapa 4, aumente o desnível de uso e veja a geração virar um platô, porque um roteador bem treinado concentra os disparos e faz caber na memória justamente o que é mais pedido.
Medições de referência, para comparar a forma
Medições obtidas numa máquina real com placa de 12 GB, memória DDR4 em canal duplo e SSD NVMe, rodando o modelo de referência num quant de pouco menos de 4 bits por peso. Não foram medidas nesta página, e estão aqui só para comparar o formato da curva: platô na geração, desabamento na leitura de prompt.
A parte que roda na CPU não escala com o número de threads que o sistema anuncia. Cada thread nova traz trabalho, mas também traz espera: barreiras entre camadas, sincronização de resultado parcial, disputa por memória. Passado certo ponto, a espera cresce mais rápido que o trabalho e o total cai.
Modelo declarado, não medição. Os três parâmetros são editáveis justamente porque dependem da máquina, da implementação e até do tamanho do lote. O que a curva mostra é qualitativo e reprodutível em quase todo hardware: existe um pico, e ele costuma ficar no número de núcleos físicos, não no de threads anunciadas. Rodar com todas as threads disponíveis é a configuração mais comum e uma das piores.
As armadilhas, na ordem em que aparecem
Local não é grátis: é capital adiantado mais energia, em troca de uma fatura que não cresce com o uso e de um dado que não sai da máquina. As duas primeiras coisas cabem numa conta; a terceira é a que costuma decidir, e não tem número.
O arranjo que costuma render mais numa máquina só não é escolher um modelo, é dividir papéis. O modelo grande e lento lê o problema, decide o que está errado e escreve um plano em passos exatos; o modelo pequeno e rápido executa os passos; o grande volta no fim para revisar. Quem decide é o que erra menos, quem repete é o que corre mais, e instrução exata elimina a decisão do caminho do rápido. O custo desse arranjo é o tempo de trocar os pesos na memória a cada passagem de bastão, que é irrelevante numa tarefa de uma hora e insuportável numa conversa.
E a parte sem número: rodar local significa que o prompt, o anexo e o log ficam na sua máquina, que a versão do modelo não muda sem você mandar, e que nada disso depende de um contrato continuar existindo. Para uso pessoal isso é conforto; para dado de cliente, costuma ser requisito. Nenhuma dessas três coisas aparece na tabela acima, e as três já decidiram mais projetos do que a conta de energia.
As oito, de um relance
No fim: a pergunta que essa página troca é a de sempre em engenharia. Em vez de "esse modelo cabe na minha placa?", que só admite sim ou não, você passa a perguntar "qual parte dele precisa estar na minha placa, e o que acontece com o resto?". A resposta é uma alocação, e alocação se calcula. Foi essa mudança de pergunta que colocou modelos de centenas de bilhões de parâmetros em máquinas domésticas, e ela continua valendo quando a próxima geração de placas chegar: o que muda é o tamanho da fatia quente, não a natureza da conta.
Continue na série
Anatomia de um modelo, a conta de parâmetros e de VRAM que esta página usa como ponto de partida