Qual LLM é o mais barato para o seu idioma? Custos de tokenizer medidos

Não existe um único LLM mais barato para texto multilíngue: medido no mesmo trecho, o GPT-5.5 cobra menos tokens em idiomas europeus, hindi e coreano, o Kimi K2.5 é o mais enxuto em chinês e o DeepSeek em japonês. Claude Fable 5, Opus 4.8 e Sonnet 5 compartilham um mesmo tokenizer (contagens idênticas em toda amostra que enviamos) e nunca são os mais enxutos: o mesmo parágrafo em inglês cobra 90 tokens brutos no Claude contra 55 no DeepSeek, e o prêmio líquido vai de 1,3x em japonês a 2,2x em chinês. O token é a unidade de cobrança, então duas coisas que você raramente vê numa página de preços decidem o seu custo de entrada: o quão densamente um idioma empacota significado em caracteres, e o quão bem o tokenizer de cada modelo comprimiu aquele script. Os dois se multiplicam, e o resultado não é o que a visão por caractere sugere.

TL;DR

• Claude Fable 5, Opus 4.8 e Sonnet 5 compartilham um mesmo tokenizer e nunca são os mais enxutos: 1,2 a 2,3x da contagem mais barata em todos os casos.
• O tokenizer mais barato muda conforme o idioma: GPT-5.5 em idiomas europeus, hindi e coreano; Kimi em chinês; DeepSeek em japonês.
• Por caractere, CJK parece 3x pior, mas por significado o chinês fica perto da paridade, enquanto japonês e coreano ficam entre 1,5 e 2,4x.
• O custo é a densidade do script vezes a cobertura do tokenizer; cobertura ausente multiplica isso (o GLM cobra hindi a 4,9x do seu inglês).
• Localizar raramente economiza dinheiro; case o modelo com o idioma pelos tokens.

As contagens foram medidas através do gateway Synthorai em 2026-07-08, sempre usando a contagem do próprio provedor, nunca um tokenizer local. Toda contagem foi idêntica entre repetições.

O token é a unidade de cobrança, não o texto

Você é cobrado por token, mas um token não é um caractere nem uma palavra. Cada modelo traz seu próprio tokenizer com seu próprio vocabulário, e a mesma frase resulta em uma contagem de tokens diferente em cada um. Essa contagem então multiplica o preço por token, então duas coisas variam ao mesmo tempo: quantos tokens o seu texto vira, e quanto custa cada token.

A maioria das páginas de preços só mostra o segundo número. Este post mede o primeiro. Enviamos três trechos semanticamente alinhados para sete modelos (claude-fable-5, claude-opus-4-8, claude-sonnet-5, deepseek-v4-flash, glm-5.2, gpt-5.5, kimi-k2.5) e lemos de volta o que cada um cobrou como entrada.

Uma narrativa casual (uma história de feira de sábado) existe em nove idiomas; uma explicação técnica (retry com exponential backoff) e uma nota de notícia (uma votação de orçamento municipal) existem em inglês, chinês, japonês, coreano, alemão e hindi. Uma função Python e um blob de tool-call em JSON completam o conjunto. As versões não inglesas são traduções automáticas produzidas com uma instrução fiel, sem compressão, e conferidas manualmente por amostragem; a verbosidade da tradução é um fator de confusão real, e a seção sobre registro mais abaixo a limita a cerca de 20%.

A contagem é sempre a do próprio provedor: a linha Claude via uma chamada Messages real lendo usage.input_tokens (o gateway atualmente não faz proxy de count_tokens), e os modelos compatíveis com OpenAI via uma pequena chamada lendo usage.prompt_tokens. Um tokenizer local que discorda da fatura é exatamente a falha que isso evita. Um controle importa: toda requisição carrega um enquadramento fixo (chat template, role markers) que vale um punhado de tokens, então medimos uma amostra base de dois caracteres e a subtraímos. Toda razão neste post é líquida desse envelope e compara o texto, não o enquadramento.

O mesmo texto, cinco tokenizadores

Segue a contagem bruta de input tokens para o trecho narrativo, por idioma e por tokenizador. Os três modelos Claude compartilham uma coluna porque devolveram contagens idênticas em todas as amostras (detalhes mais adiante). Os outros dois trechos repetem o mesmo padrão e aparecem mais abaixo. A coluna de caracteres é o tamanho da versão em cada idioma; cada sistema de escrita empacota significado de forma diferente, e o chinês diz em 77 caracteres o mesmo que o inglês precisa de 254 para dizer.

Dois fatos saltam à vista. A coluna do Claude é um único número para três modelos porque Claude Fable 5, Opus 4.8 e Sonnet 5 devolveram contagens idênticas em todas as amostras — idiomas, código e JSON. Os três usam o tokenizador introduzido com o Opus 4.7, então uma contagem em um vale para todos. E essa coluna é a maior em todas as linhas exceto no hindi, onde os 192 do GLM ficam piores. Normalizando pelas contagens líquidas, com o modelo mais enxuto de cada idioma lendo 1,00 (o envelope é subtraído primeiro, então essas razões não batem com uma divisão das células brutas acima):

O empate quádruplo na linha do inglês não é arredondamento: DeepSeek, GLM, GPT-5.5 e Kimi caem todos em exatamente 50 tokens líquidos nesse trecho. O Claude consome de 1,3x a 2,2x o tokenizador mais enxuto nesse trecho, e de 1,2x a 2,3x nos três trechos somados — uma propriedade do vocabulário que se aplica a toda chamada durante toda a vida do modelo. Os trechos técnico e jornalístico reproduzem o mesmo ranking: somando os dois, o Claude cobra o chinês a 212 tokens líquidos contra os 114 do Kimi (1,9x) e o hindi a 477 contra os 210 do GPT-5.5 (2,3x). Mas não há um vencedor único por baixo disso. A coluna mais enxuta muda conforme o idioma:

• GPT-5.5 é o mais enxuto em alemão, francês, espanhol, italiano, hindi e coreano, e empata na liderança em inglês (o empate e o fr/es/it valem apenas na narrativa). Seu vocabulário é ajustado para escritas latinas e se sai bem em devanágari e hangul.
• Kimi K2.5 é o mais enxuto em chinês e competitivo em todo o CJK.
• DeepSeek-v4 é o mais enxuto em japonês e fica logo atrás em chinês.
• GLM 5.2 fica no meio do pelotão na maioria dos idiomas, mas registra as piores células da matriz em hindi: 2,59x o mais enxuto na narrativa (179 tokens líquidos onde o GPT-5.5 precisa de 69), pior ainda nos trechos formais, e a única coluna que supera até o Claude.

A penalidade não se limita à prosa. Na função em Python o Claude consome 1,61x o mais enxuto, e na tool-call em JSON, 1,29x. A diferença no JSON é menor porque texto estruturado é quase todo pontuação e chaves ASCII curtas, que todos os tokenizadores tratam de forma parecida. Para um agente de longa duração que reenvia um grande schema de ferramentas a cada turno, esse imposto por turno se acumula, e é aí que o caching se paga. A série sobre prompt caching cobre esses mecanismos.

A armadilha do por caractere: CJK parece pior do que cobra

As tabelas acima comparavam modelos. Fixe o modelo e o idioma ainda mexe na contagem, mas não do jeito que a visão bruta por caractere sugere. O número de tokenizer mais citado é o de tokens por caractere, e CJK domina esse critério: no Claude, o chinês fica em torno de 114 tokens líquidos por 100 caracteres, o coreano 106, o japonês 94, contra 32 para o inglês. Olhe só essa coluna e CJK parece um imposto de 3x, mas é a coluna errada: você paga por significado, não por caractere, e a mesma passagem carrega o mesmo significado em todos os idiomas. Aqui estão as duas visões no Claude, para a passagem narrativa:

As duas colunas da direita discordam, e o chinês é o caso mais gritante: a maior densidade por caractere do conjunto, mas um prêmio por significado de apenas 1.07x o inglês nesta passagem. 77 caracteres carregam o que o inglês gasta em 254, então uma taxa alta por caractere multiplica uma contagem minúscula de caracteres e quase se anula. Nas três passagens a anulação se mantém, mas não é mágica: o chinês fica em média 1.17x o próprio inglês do Claude, e de 0.95x a 1.32x dependendo do modelo, próximo da paridade em vez dos 3x que a coluna por caractere ameaça.

Japonês e coreano respondem à pergunta óbvia seguinte: mesma ilusão, anulação mais fraca. Ambos compartilham a alta densidade por caractere, porque o Hangul e o kana japonês soletram sons a mais ou menos um glifo por sílaba, em vez de empacotar uma palavra inteira em cada caractere como fazem os hanzi chineses. Por isso o coreano precisa de 143 caracteres e o japonês de 136 para a passagem que o chinês diz em 77. Mais caracteres vezes uma taxa alta por caractere não se anula, se acumula: no Claude, o coreano fica em média 1.96x o inglês por significado nas três passagens e o japonês 1.56x, ambos realmente caros, mesmo com uma coluna por caractere bem parecida com a do chinês.

O alemão é o espelho do chinês: taxa baixa por caractere (48, perto do inglês), mas o maior número de caracteres de todos os idiomas aqui (289, por suas palavras compostas), o que ainda soma 1.68x. O custo é o produto dos dois eixos, e qualquer um deles lido isoladamente engana.

Por que os números mudam: dois fatores, multiplicados

A regra por trás de todas as tabelas acima é uma equação:

tokens de um texto = (caracteres para expressar o significado) x (tokens por caractere)

O primeiro fator é a densidade do sistema de escrita, uma propriedade da língua, não do modelo. É um espectro, não uma exceção chinesa. O chinês logográfico compacta um morfema em cada caractere e fica no extremo denso. O kana japonês e o Hangul coreano soletram sons, então são menos densos e precisam de mais caracteres. O devanágari e os alfabetos latinos são ainda menos densos. O significado por caractere cai de forma constante do chinês ao inglês.

O segundo fator é quantos tokens o vocabulário do modelo gasta por caractere daquele script, e isso é totalmente específico de cada modelo. Um tokenizador BPE aprende junções de vários caracteres a partir do corpus de treino: scripts que ele viu com frequência ganham tokens compactos; scripts que viu raramente caem para uma codificação caractere a caractere ou até em nível de byte, onde um caractere pode virar dois ou três tokens. As mesmas três línguas, tokens líquidos por caractere:

A tabela explica três coisas. O chinês parece especial nos totais porque é extremo no primeiro fator: mesmo a compressão fraca do chinês pelo Claude (1.14 tokens por caractere, ainda dividindo alguns hanzi em dois) não consegue tornar o total grande quando há apenas 77 caracteres, e os modelos treinados na China o comprimem bem o bastante (0.52 a 0.58) para chegar perto da paridade com o próprio inglês deles. O prêmio do híndi vem do segundo fator, não da densidade: o GLM gasta 0.91 tokens por caractere devanágari, quase um token por caractere, porque seu vocabulário quase não tem junções devanágari de vários caracteres, enquanto o GPT-5.5 gasta 0.35 ao cobrir grupos silábicos inteiros — uma diferença de cobertura no mesmo script. E o Claude é alto em tudo porque sua taxa por caractere é alta até no inglês (0.32 contra 0.20 do DeepSeek), uma linha de base no nível do modelo que se soma ao que quer que a língua faça.

Nada disso é uma peculiaridade dos nossos sete modelos. A literatura de pesquisa chama o fenômeno de token premium, e Petrov et al. (NeurIPS 2023) o mediram em centenas de pares de línguas. Encontraram as mesmas duas causas de raiz (a contagem de caracteres varia por significado, e a cobertura do tokenizador varia por script) e prêmios de até 15x para línguas de poucos recursos, com as mesmas consequências: mais custo, mais latência e menos janela de contexto útil, já que uma língua de prêmio alto preenche o mesmo orçamento de contexto com menos significado. A diferença também diminui à medida que os fornecedores investem: medições independentes colocam o chinês em +182% de tokens frente ao inglês nos vocabulários da era GPT-3 e +24% no do GPT-4o, perto dos +32% que medimos no GPT-5.5 e da paridade que medimos nos modelos treinados na China. A cobertura se compra com slots de vocabulário, e os fornecedores continuam comprando.

Localizar chega a economizar dinheiro?

É tentador ler a seção sobre a armadilha como “o Claude é uniforme entre idiomas, então esqueça a localização” e “os modelos chineses são baratos em chinês, logo localizar economiza dinheiro”. Os dois estão errados. Segue cada idioma comparado com o inglês do próprio modelo, com média sobre as três passagens, para os cinco idiomas que têm as três:

O Claude não é uniforme: o coreano custa 1.96x o inglês dele, o hindi 2.40x. O chinês perto de 1.17x é uma coincidência de um único idioma, não uma propriedade do modelo. E os modelos chineses não ficam abaixo da paridade em chinês, apenas a alcançam: a melhor célula da tabela inteira é o 0.95x do Kimi, cinco por cento abaixo do próprio inglês, e todas as outras células custam o mesmo ou mais. Em hindi, japonês e coreano esses mesmos modelos carregam uma penalidade maior que o Claude, não menor, porque essas escritas estão mais distantes do foco de treinamento deles. O padrão não é “o fornecedor X é barato”; é que todo modelo é mais econômico, em relação ao próprio inglês, nos idiomas mais próximos dos seus dados de treino.

O registro também mexe nesses números. A narrativa casual é o caso mais favorável; as passagens técnica e jornalística elevam quase todos os multiplicadores, porque terminologia e estrangeirismos são justamente o que os vocabulários não latinos não têm como fundir em tokens. O alemão vai de 1.68x (casual) a 2.29x (técnico) no Claude, e o hindi do GLM chega a 5.98x o inglês dele na passagem jornalística. Um benchmark de uma única passagem favorece o idioma que recebeu a tradução mais fácil, e por isso a narrativa isolada colocava o chinês em 0.80x no Kimi enquanto as três passagens o colocam em 0.95x.

De qualquer forma, comparar com o próprio inglês é a lente errada. O que você paga são tokens absolutos, e nesse quesito o Claude é o mais caro em oito dos nove idiomas, com o hindi do GLM sendo a única coluna pior. Conteúdo em chinês que é “barato em relação ao inglês do Claude” ainda são 88 tokens líquidos no Claude contra 40 no Kimi para a narrativa. A jogada não é localizar para economizar, e sim casar o modelo com o idioma: chinês no Kimi ou DeepSeek, hindi e coreano no GPT-5.5, japonês no DeepSeek. O Claude nunca vence em custo de tokens em nenhum idioma, embora ainda possa vencer em qualidade.

Contagem é só metade da conta

Um multiplicador de tokens só faz sentido junto do preço por token, e os dois se somam. O Claude Fable 5 custa $10 por milhão de tokens de entrada, o Opus 4.8 custa $5, e o Sonnet 5 fica em $3 quando o preço promocional acabar. Em chinês, o tokenizer que eles compartilham conta o texto com 2,2x o do modelo mais enxuto, então o sobrepreço de contagem multiplica a diferença de tarifa que o modelo já carrega em relação à alternativa para a qual você faria o roteamento. O contrário também acontece: um modelo pode contar de forma enxuta e ainda assim custar mais por chamada porque a tarifa dele é alta. Nenhum dos dois números sozinho diz quanto vai ser a conta. Não colocamos aqui as tarifas dos outros fornecedores porque elas mudam mais rápido que os tokenizers; as contagens acima são a metade duradoura do cálculo.

Na prática, pare de comparar preço de tabela e compare o custo de entrada efetivo: sua mistura real de tráfego, contada em cada modelo candidato, multiplicada pela tarifa de entrada daquele modelo. Num produto com muito chinês ou muito coreano, essa reordenação pode inverter qual modelo é o mais barato, e a diferença é de 1,5x a 2x de forma consistente, não um erro de arredondamento. É pela mesma razão que o número que importa quando você usa cache é o custo efetivo ponderado pela taxa de acerto, não a tarifa de tabela — algo que a comparação de fornecedores detalha. O recorte versão a versão dessa história, por que o Sonnet 5 conta 41% mais que o Sonnet 4.6 no mesmo inglês, está no post sobre o tokenizer do Sonnet 5.

Conclusão

• O custo em tokens é a densidade do script vezes a cobertura do tokenizer. O idioma define o primeiro fator, o modelo define o segundo, e ler só um deles engana.
• Claude Fable 5, Opus 4.8 e Sonnet 5 ficam entre 1,2x e 2,3x acima do mais enxuto em todos os idiomas, porque a tarifa por caractere é alta até em inglês.
• O modelo mais enxuto depende do idioma: GPT-5.5 para línguas europeias, hindi e coreano; Kimi para chinês; DeepSeek para japonês. O GLM é o pior em hindi, com quase um token por caractere.
• Registro formal e técnico eleva o multiplicador em quase todos os idiomas; faça seu benchmark no registro que você realmente coloca em produção.
• Não localize para economizar; escolha o modelo pelo idioma com base em tokens absolutos e depois multiplique pela tarifa de cada modelo para comparar o custo efetivo.

FAQ

Qual tokenizer de LLM é o mais barato? Depende do idioma. Testando sete modelos sobre os mesmos trechos alinhados, o GPT-5.5 foi o mais enxuto nas línguas europeias, no hindi e no coreano (empatado no inglês), o Kimi K2.5 no chinês e o DeepSeek-v4 no japonês. A família Claude (Fable 5, Opus 4.8, Sonnet 5) nunca foi a mais enxuta, ficando entre 1,2x e 2,3x acima da menor contagem em todos os idiomas e registros.

O Claude Fable 5, o Opus 4.8 e o Sonnet 5 usam o mesmo tokenizer? Sim. Os três produziram contagens de token idênticas em todas as amostras, em todos os idiomas, código e JSON. Eles usam o tokenizer que estreou com o Opus 4.7, então uma contagem feita em um vale para os outros, e a conta mais alta do Fable 5 vem inteiramente do preço por token dele.

O chinês é mais caro que o inglês no Claude? Um pouco: 1,17x por significado, na média de três trechos (e praticamente empatado nos modelos treinados na China). Por caractere fica bem pior (cerca de 114 tokens líquidos por 100 caracteres chineses contra 32 no inglês), mas o chinês transmite o mesmo significado em cerca de um terço dos caracteres, então os totais quase se cancelam.

O japonês e o coreano se comportam como o chinês? Só até certo ponto. Compartilham a alta densidade por caractere do chinês, mas o hangul e o kana soletram os sons, então precisam de muito mais caracteres para o mesmo trecho (japonês 136, coreano 143, contra 77 do chinês). A alta taxa por caractere já não se cancela, então, por significado, o japonês fica em torno de 1,6x o inglês no Claude e o coreano em cerca de 2x, variando de 1,5x a 2,4x entre os sete modelos.

Como faço para medir isso nos meus próprios prompts? Envie alguns prompts reais, no registro que você de fato usa em produção, para cada modelo candidato e leia a contagem de tokens de entrada do próprio provedor nos campos de usage, em vez de confiar num tokenizer local. Um único trecho favorável pode inflar um idioma em cerca de 20%, então use vários. Depois multiplique cada contagem pelo preço de entrada daquele modelo para chegar ao custo efetivo no seu tráfego.

← Voltar ao blog