Treinando seu próprio tokenizer

01 · Conceito

Conceito

Abra o tokenizer fixado e o config do Qwen e aparecem dois números relacionados. O vocabulário do modelo e os added tokens usam IDs de 0 a 248.076, enquanto as matrizes de embedding e saída alocam 248.320 linhas. Isso deixa 243 linhas que o tokenizer fixado nunca emite. Os artefatos estabelecem essas contagens; eles não publicam por que a equipe escolheu a alocação maior. A distinção é útil porque o design do tokenizer é linguístico, enquanto alinhamento de matriz é uma restrição de engenharia, e evidência não deve transformar uma explicação plausível em história.

A metade linguística vem primeiro. Um modelo de linguagem nunca recebe texto bruto; o tokenizer mapeia texto para IDs inteiros e a tabela de embedding mapeia esses IDs para vetores de 5120 dimensões. Treinar esse tokenizer significa escolher uma amostra representativa do corpus governado da lição 5.2, com os limites de mistura já aplicados, e então aprender dela um inventário de tamanho fixo de peças de subword. Esquemas byte-level partem de bytes, de modo que qualquer entrada é representável; BPE funde repetidamente o par adjacente mais frequente, produzindo uma lista ordenada de merges; unigram começa com muitas peças candidatas e poda as que menos contribuem para um objetivo probabilístico. O SentencePiece consegue treinar sobre sentenças brutas e trata o espaço em branco explicitamente. Todos são compromissos entre unidades universais minúsculas e um dicionário impossível de palavras inteiras.

O tamanho é a decisão de verdade, e é uma troca direta. Um vocabulário maior significa menos tokens por sentença, o que significa sequências mais curtas, menos trabalho de attention e — isto importa mais do que parece — tratamento mais justo de idiomas que um vocabulário pequeno e centrado no inglês trituraria em fragmentos. A lição 1.4 mediu esse efeito: o mesmo significado custa mais tokens, e portanto mais dinheiro a USD 0,45 por milhão de tokens de entrada, em português do que em inglês sob um tokenizer mal balanceado.

Mas linhas não são de graça. Neste modelo o embedding e a output head são untied, o que o config declara sem rodeios como tie_word_embeddings: false. Então cada linha é paga duas vezes. Calcule o custo marginal:

Dez mil entradas extras de vocabulário custam cerca de 205 MB de pesos. Escale isso para a tabela inteira: $248{,}320\times 5120\approx 1.271$ bilhão de parâmetros no embedding, outros 1,271 bilhão na head, aproximadamente 2,54 bilhões somados — em torno de 9% de um modelo de 27 bilhões de parâmetros gasto no mapeamento entre texto e vetores, antes que exista uma única camada de transformer.

Agora inspecione a propriedade de engenharia da contagem de linhas alocada sem atribuir intenção. Tensor parallelism só divide uma dimensão de vocabulário igualmente quando a contagem de linhas é divisível pelo grau paralelo. O valor lançado fatora como:

Ele divide limpo por 2, 4, 8, 16, 32, 64, 128, 256 e 512. Qualquer grau de tensor parallel em potência de dois até 512 recebe, portanto, uma fatia igual: no grau 8, cada rank tem 31.040 linhas; no grau 32, 7.760; no grau 64, 3.880. Em contraste, 250.000 só divide até grau 16 entre essas potências de dois. Frameworks podem preencher dimensões incompatíveis, portanto a divisibilidade é um benefício real de implementação. Os artefatos públicos não dizem que esse benefício levou a Qwen a selecionar 248.320; essa explicação causal continua sendo inferência.

que divide por 16 e então para. No grau 32 de tensor parallel você teria 7.812,5 linhas por rank — impossível — e o framework preencheria silenciosamente ou falharia ruidosamente no lançamento. Então o inventário aprendido pelo tokenizer é preenchido até um número altamente composto, e as linhas excedentes simplesmente nunca são emitidas. Elas custam alguns milhões de parâmetros e compram liberdade em todo layout paralelo futuro.

O desvio clássico vem logo em seguida: tratar as linhas não usadas na cauda como removíveis com segurança. Aparar a matriz mudaria os shapes do checkpoint e poderia eliminar divisibilidade útil, economizando apenas 243 × 5120 × 2 matrizes × 2 bytes bf16, cerca de 5 MB. O próprio mapeamento de tokens também precisa permanecer igual. A conclusão segura é contratual: carregue os shapes de matriz e tokenizer publicados pelo checkpoint; não invente nem remova linhas de um artefato treinado.

Todo o resto sobre o treino de um tokenizer decorre do fato de o artefato ser permanente. Reserve tokens especiais — padding, fronteiras de sequência, marcadores de papel de chat, marcadores de modo de pensamento, marcadores de FIM — antes de congelar os IDs, porque acrescentar depois significa redimensionar embeddings e treinar uma linha fria, e inserir no meio corrompe toda associação posterior. Decida a normalização deliberadamente: Unicode pode escrever texto visualmente idêntico de várias formas, e dobrar caixa ou remover acentos encolhe um vocabulário ao custo de distinções que seu produto pode precisar. Avalie em amostras held-out, reportando fertilidade por idioma e domínio em vez de uma média global única, mais correção de ida e volta, expansão máxima adversarial e throughput de codificação. Inspecione exemplos reais na mão, porque a morfologia do português, acentos combinantes, sequências de emoji, texto CJK, escritas da direita para a esquerda, indentação e cadeias longas de dígitos falham cada uma de um jeito.

Então congele e faça hash dos arquivos, guarde a versão do código de treino, as regras de normalização, o manifesto da amostra, o vocabulário, os merges, a tabela de tokens especiais e o relatório de avaliação, e teste que cada worker de dados produz IDs byte a byte idênticos para um conjunto dourado. Uma incompatibilidade silenciosa de versão do tokenizer deixará uma run treinar alegremente sobre entrada sem sentido enquanto a loss permanece finita e plausível — a falha silenciosa mais cara desta track.