O Imposto do Tokenizador LLM: Como a Linguagem Muda o Custo e o Contexto da IA

O imposto do tokenizador LLM é um custo mensurável e uma penalidade de contexto. Dois prompts podem carregar o mesmo significado, mas consumir contagens de tokens muito diferentes porque usam idiomas diferentes.

Um estudo de julho de 2026 testou 997 frases alinhadas em seis tokenizadores. Com a codificação mais antiga `cl100k_base` da OpenAI, dez idiomas indianos tiveram uma média de imposto de fertilidade de palavras de 8,0 vezes em relação ao inglês. O Malayalam alcançou 13,04 vezes. O novo `o200k_base` reduziu a média para 2,1 vezes. O estudo não prova que a tokenização sozinha causa respostas piores. Ele mostra que o preço e o contexto utilizável podem divergir antes que um modelo comece a raciocinar.

Público: Intermediário

Resposta direta: Não estime um produto de IA multilíngue a partir de contagens de tokens em inglês. Teste o tokenizador exato em texto de produção alinhado, meça toda a solicitação, avalie a qualidade separadamente e repita o teste sempre que o modelo ou tokenizador mudar.

O que o imposto do tokenizador LLM mede

Modelos de linguagem recebem IDs de tokens, não palavras ou caracteres. Um tokenizador divide o texto em unidades de tokens e as mapeia para IDs; alguns tokenizadores normalizam o texto primeiro. Fragmentos comuns podem caber em um token. Escritas ou formas de palavras menos representadas podem se dividir em vários tokens ou bytes.

A métrica principal do artigo é fertilidade de palavras: tokens por palavra delimitada por espaço em branco. Seu imposto de tokenizador é a fertilidade de palavras de um idioma dividida pela fertilidade de palavras em inglês sob o mesmo tokenizador.

Para uma tela de produção, uma razão de contagem de tokens alinhada é frequentemente mais fácil de usar:

text razão de contagem de tokens alinhados para o idioma L = tokens para conteúdo alinhado no idioma L ÷ tokens para a versão em inglês

Essas métricas respondem a perguntas relacionadas, mas não são intercambiáveis. Nomeie a métrica que você reporta. Ambas as comparações precisam de texto semanticamente alinhado. Contar frases não relacionadas ou uma lista de palavras comuns pode produzir um número atraente que diz pouco sobre uma aplicação real.

Os pesquisadores também usam fertilidade, frequentemente definida como tokens por palavra. A fertilidade de palavras é intuitiva, mas os limites das palavras não são igualmente claros entre os idiomas. Adicione a fertilidade de caracteres, bytes por token e a parte de bytes não mesclados quando precisar diagnosticar por que existe uma lacuna.

Essa distinção importa porque a contagem de tokens tem várias consequências diferentes:

A última linha é a mais fácil de exagerar.

O que a pesquisa de 2026 descobriu

O novo estudo do Imposto do Tokenizador usou frases alinhadas do FLORES-200. Ele comparou dez idiomas indianos com inglês, árabe, espanhol e francês em seis tokenizadores. Os autores mediram a fertilidade de palavras e caracteres, bytes por token, tokens de byte único não mesclados e a quantidade de texto fonte que sobreviveu a um orçamento de contexto fixo.

Três resultados são importantes para decisões de engenharia:

Idiomas de alto imposto produziram tokens de byte único não mesclados para 27–43% de seus tokens. Entre os idiomas amostrados com limites de palavras válidos, essa taxa correlacionou-se com o imposto de fertilidade de palavras em `r = 0.89`. Os autores atribuem a lacuna à cobertura de vocabulário insuficiente para esses scripts.

Um artigo de 2023 da NeurIPS encontrou diferenças de comprimento de tokenização de até 15 vezes entre idiomas. Um estudo EMNLP 2023 mediu custo e utilidade em 22 idiomas e descobriu que a precificação de API baseada em tokens pode cobrar algumas comunidades linguísticas mais por conteúdo comparável.

Trabalhos recentes também mostram que a lacuna é uma escolha de design, não uma propriedade inevitável de um script. A codificação de pares de bytes ciente de paridade (BPE) muda o objetivo de mesclagem para ajudar o idioma atualmente menos comprimido. Seus autores relatam uma redução de até 89% na desigualdade de custo de tokens, medida com um coeficiente de Gini entre idiomas, com pouca mudança na compressão global. Um estudo controlado separado em 11 idiomas do Sudeste Asiático colocou o BPE ciente de paridade na fronteira de eficiência–equidade para modelos base comparáveis de 1,5 bilhões de parâmetros. Esse resultado não estabelece a mesma compensação em escala de fronteira ou após o alinhamento.

A reivindicação de precisão precisa de contenção

O estudo de julho encontrou uma correlação bruta de `r = -0.61` entre fertilidade e precisão de compreensão de leitura para 13 pontos de linguagem. Após controlar o nível de recursos linguísticos, a correlação parcial tornou-se `r = 0.25`.

Existem mais razões para evitar um título causal: os números de fertilidade e as pontuações de precisão vieram de diferentes configurações de tokenizador/modelo, a amostra era pequena e as frases de benchmark traduzidas não são uma carga de trabalho de produção. O artigo apoia reivindicações fortes sobre contagens de tokens, contexto e custos precificados por token. Ele não isola a fertilidade do tokenizador como a causa da menor qualidade da resposta.

Meça seu próprio custo de token multilíngue

A pesquisa dá um aviso, não sua razão de produção. Um assistente de suporte, sistema de recuperação ou agente de codificação tem sua própria mistura de idiomas e estrutura de prompt.

Use este fluxo de trabalho antes do lançamento e após cada mudança de modelo.

1. Construa uma amostra alinhada

Para uma tela inicial, colete 100–1.000 exemplos da carga de trabalho que você espera:

Use traduções revisadas do mesmo significado. Mantenha um ID que conecte cada variante de idioma. Não compare texto aleatório retirado de corpora de idiomas separados. Esta faixa de triagem não é um mínimo estatístico: a amostra necessária depende do número de idiomas, da variação da carga de trabalho e de quão precisamente você precisa estimar o comportamento da cauda.

Armazene a amostra como JSON Lines:

{"id":"support-001","language":"en","text":"Texto em inglês revisado"} {"id":"support-001","language":"sv","text":"Tradução em sueco revisada"} {"id":"support-001","language":"tr","text":"Tradução em turco revisada"}

2. Defina o tokenizador

O tokenizador pertence a uma versão do modelo. Registre ambos. O repositório oficial da OpenAI `tiktoken` expõe `cl100k_base` e `o200k_base`; seu mapeamento de modelo também mostra que famílias de modelos podem usar codificações diferentes. Para um modelo fechado, prefira o contador oficial do provedor quando um existir. A API Gemini do Google, por exemplo, expõe um método `countTokens`. Para um modelo aberto, carregue o artefato exato com o pipeline de tokenizador documentado do modelo, como o descrito na API de Tokenizadores da Hugging Face.

Não assuma que dois modelos do mesmo fornecedor compartilham um tokenizador. Não assuma que uma biblioteca local já conhece um modelo lançado ontem.

3. Calcule uma distribuição, não uma razão

Instale e defina o contador:

bash python -m pip install "tiktoken==0.13.0"

Então execute:

python import json from collections import defaultdict from math import ceil from statistics import mean, median

import tiktoken

BASELINE = "en" ENCODINGS = ("cl100k_base", "o200k_base")

groups = defaultdict(dict) with open("aligned-samples.jsonl", encoding="utf-8") as source: for line in source: row = json.loads(line) groups[row["id"]][row["language"]] = row["text"]

def percentile(values, probability): ordered = sorted(values) index = max(0, ceil(len(ordered) * probability) - 1) return ordered[index]

for encoding_name in ENCODINGS: encoding = tiktoken.get_encoding(encoding_name) counts = defaultdict(list) ratios = defaultdict(list)

for sample_id, variants in groups.items(): if BASELINE not in variants: raise ValueError(f"{sample_id} não tem baseline {BASELINE}")

baseline_tokens = len(encoding.encode(variants[BASELINE])) if baseline_tokens == 0: raise ValueError(f"{sample_id} tem um baseline vazio")

for language, text in variants.items(): token_count = len(encoding.encode(text)) counts[language].append(token_count) ratios[language].append(token_count / baseline_tokens)

for language in sorted(counts): print( encoding_name, language, f"mean_tokens={mean(counts[language]):.1f}", f"mean_ratio={mean(ratios[language]):.2f}x", f"median_ratio={median(ratios[language]):.2f}x", f"p95_ratio={percentile(ratios[language], 0.95):.2f}x", f"max_ratio={max(ratios[language]):.2f}x", sep="\t", )

A média pode esconder alguns pedidos longos que transbordam a janela de contexto. Inspecione p50 (a mediana), p95 (o percentil 95) e o máximo antes de usar o resultado em um plano de capacidade.

*Meça o texto de produção alinhado com o tokenizador implantado, depois use a distribuição para definir limites de custo e contexto. A qualidade permanece uma avaliação separada.*

4. Meça a solicitação completa

A mensagem visível do usuário é apenas uma parte de uma chamada de API. Inclua:

Isso é especialmente importante para agentes. Um grande esquema de ferramenta JSON pode dominar uma solicitação curta do usuário. Um trecho RAG localizado pode dominar um prompt de sistema em inglês. Meça a solicitação final serializada sempre que o provedor expuser essa representação.

5. Converta tokens em limites operacionais

Para uma API simples com preço por token:

text custo mensal de entrada = calls mensais × tokens de entrada médios × preço por milhão de tokens ÷ 1.000.000

Suponha que uma API hipotética cobre $1 por milhão de tokens de entrada. Um milhão de solicitações a 1.000 tokens de entrada custam $1.000. Se as solicitações alinhadas em outro idioma tiverem uma média de 2.500 tokens, a parte de entrada se torna $2.500 antes de caching ou descontos.

O contexto precisa de um cálculo separado:

text orçamento de entrada utilizável = janelade contexto

Aplique a razão de idioma observada à parte de conteúdo, não cegamente a toda a solicitação.

O guia de custo de token de raciocínio de IA explica por que orçamentos de tokens precisam de um limite de produto, não apenas um limite de modelo. Para sistemas RAG e de codificação, design de contexto entre repositórios mostra por que enviar mais contexto não é automaticamente útil. Se a escolha da API ainda estiver aberta, o estudo de caso de API de IA gratuita existente fornece uma estrutura de comparação mais ampla.

Defina um portão de aceitação multilíngue

Uma razão de token mais baixa é útil apenas se o modelo ainda atender ao requisito do produto. Use quatro portões separados:

Para um sistema RAG multilíngue, divida pelo tokenizador implantado em vez de uma contagem de caracteres compartilhada. Para um agente, meça rastros de ferramentas e tentativas, bem como a primeira solicitação. Para um produto de suporte, acompanhe o custo por caso resolvido, não o custo por chamada. Essas escolhas impedem que a métrica de tokens se torne um benchmark de vaidade.

Use uma rota específica para o idioma apenas quando melhorar o placar completo. Um tokenizador mais barato emparelhado com um modelo mais fraco pode economizar tokens de entrada e aumentar as tentativas. Uma janela de contexto maior pode ocultar um chunking ruim até que a conta cresça. A unidade correta é a tarefa do usuário concluída.

O que as equipes podem mudar

As equipes de aplicação não podem re-treinar o tokenizador de um modelo comercial, mas ainda têm opções:

Equipes que treinam seus próprios modelos têm uma escolha mais profunda. Os resultados do BPE ciente de paridade sugerem que um objetivo de tokenizador pode reduzir a desigualdade entre idiomas sem sacrificar muito a compressão geral. O estudo do Sudeste Asiático adiciona evidências controladas de que equidade e eficiência não precisam se mover em direções opostas.

Trate o tokenizador como parte do contrato do modelo. Versione-o, faça benchmarks e inclua-o nas revisões de migração.

Limites da evidência

O estudo mais recente é um preprint. Ele usa frases traduzidas do FLORES-200, um conjunto modesto de idiomas e uma métrica de palavras baseada em espaço em branco que não se encaixa igualmente bem em todos os sistemas de escrita. Seu método de detecção de bytes é específico do tokenizador.

A conclusão mais forte é independente do modelo: quando um idioma alinhado produz mais tokens, ele coloca menos texto em uma janela de tokens fixa. A conclusão de custo se mantém quando um provedor cobra esses tokens extras pelo mesmo preço unitário. Políticas de cache e descontos por volume podem mudar a fatura final.

A precisão precisa de seu próprio teste. A cobertura de dados de treinamento, arquitetura do modelo, design de avaliação pós-treinamento e contexto cultural afetam todos os resultados. A fertilidade de tokens pode contribuir para uma lacuna, mas o artigo de julho não isola esse efeito causal.

Checklist do tokenizador multilíngue

Perguntas frequentes

Por que alguns idiomas usam mais tokens LLM?

Vocabulários de subpalavras refletem seus dados de treinamento e regras de mesclagem. Fragmentos comuns em inglês são frequentemente representados de forma eficiente, enquanto scripts menos representados podem ser divididos em pedaços menores ou bytes. O tamanho da lacuna depende do tokenizador exato e do texto.

Uma contagem de tokens mais alta significa uma resposta pior?

Não. Afeta diretamente o custo precificado por token e a quantidade de texto que cabe em uma janela de tokens. Não prova uma qualidade de resposta inferior. Teste a qualidade separadamente em exemplos revisados em cada idioma.

Como posso contar tokens antes de uma chamada de API?

Use o endpoint de contagem oficial do provedor quando disponível. Para codificações da OpenAI, `tiktoken` pode contar localmente. Para modelos abertos, carregue o artefato exato do tokenizador enviado com o modelo. Fixe versões para que uma atualização posterior não mude silenciosamente a medição.

Mudar de modelo pode remover o imposto do tokenizador?

Pode reduzir a lacuna. O estudo de julho encontrou uma grande melhoria entre `cl100k_base` e `o200k_base`. Uma troca de modelo também muda qualidade, custo de saída, caching, latência e comportamento operacional, então compare a carga de trabalho completa em vez de apenas contagens de tokens.

Fontes

Verificações de reivindicações