Lendo pesos reais: a aparência de um modelo treinado

1

Conceito

Um modelo treinado não é armazenado como prosa nem como grafo visível de conceitos. Um checkpoint normalmente mapeia nomes de parâmetros a arrays multidimensionais. O código da arquitetura fornece operações; o checkpoint fornece números aprendidos. Ler pesos começa por reconstruir esse contrato com exatidão.

Liste nome, shape, dtype e device de cada tensor. Um token embedding pode ter $V\times d_{model}$. Uma projeção combinada de query–key–value pode ter $3d_{model}\times d_{model}$, embora frameworks discordem sobre qual eixo vem primeiro. A expansão da FFN revela $d_{ff}$; vetores de normalização revelam largura; prefixos numéricos repetidos revelam número de camadas. São pistas estruturais confiáveis.

Nomes são convenções, não padrões. Um repositório armazena attn.c_attn.weight; outro separa q_proj, k_proj e v_proj. Alguns fundem projeções gated. Alguns omitem biases. Alguns ligam o language-model head ao token embedding: dois componentes lógicos apontam para um parâmetro. Contar nomes sem entender compartilhamento duplica ou perde parâmetros.

Tokenizer e configuração também pertencem ao checkpoint. O vocabulário precisa casar com as linhas de embedding. O número de heads determina o reshape. Frequência, pares e scaling de RoPE precisam coincidir. LayerNorm e RMSNorm dão significados distintos aos parâmetros. Um tensor pode caber no shape errado, mas estar transposto ou atribuído a outra convenção, gerando falha fluente e difícil de detectar.

Estatísticas básicas servem como diagnóstico. Procure NaNs e infinitos; calcule mínimo, máximo, média, desvio-padrão e norma. Plote histogramas por tensor e compare camadas. Checkpoints quantizados exigem scales e zero-points; interpretar códigos inteiros compactados como pesos comuns produz absurdo. Outliers podem ser esperados e importantes, então “parece gaussiano” não testa correção.

Linhas de embeddings podem ser comparadas por cosine similarity, mas vizinhos refletem tokenizer e treinamento. Uma linha mistura sintaxe, frequência, morfologia e semântica. Colunas de projeções e neurônios da FFN dependem da base: girar um espaço interno pode preservar comportamento e mudar coordenadas individuais. Peso grande não é automaticamente feature importante.

Para ir de estrutura a função, capture ativações em inputs controlados. Pergunte quais inputs ativam uma feature, que direção o componente escreve e como logits mudam. Depois intervenha: ablate uma head, faça activation patching entre execuções ou remova uma direção. Correlação sugere hipótese; efeito causal reproduzível fortalece a evidência.

Histogramas encontram problemas de treinamento e conversão. Uma camada zerada pode estar ausente. Um vetor de norm em escala inesperada indica cast ruim. Distribuições de Q, K e V muito diferentes de uma conversão conhecida apontam slicing incorreto. A comparação mais forte passa o mesmo input pelas implementações fonte e destino e verifica ativações camada a camada.

Checkpoints reais podem ser sharded. Um índice mapeia parâmetros a arquivos para o loader não abrir tudo junto. Checkpoints de treinamento distribuído podem guardar estados particionados e moments do optimizer, não um modelo consolidado de inference. Eles ficam muito maiores porque incluem gradientes, master weights e buffers.

A conclusão responsável é modesta: metadata revela arquitetura; estatísticas revelam saúde e escala; ativações revelam associações; intervenções revelam contribuição causal. Nenhum gráfico isolado mostra “onde o modelo pensa”.