Qual LLM é mais barato no seu idioma? Custo dos tokenizers

Não existe um único LLM mais barato para texto multilíngue. No mesmo trecho, GPT-5.5 cobra menos tokens em idiomas europeus, hindi e coreano; Kimi K2.5 é o mais eficiente em chinês; DeepSeek, em japonês. Claude Fable 5, Opus 4.8 e Sonnet 5 compartilham um tokenizer, as contagens foram idênticas em todas as amostras enviadas, e nunca são os mais eficientes: o mesmo parágrafo em inglês gera uma cobrança de 90 tokens brutos no Claude, contra 55 no DeepSeek, e o acréscimo líquido varia de 1.3x em japonês a 2.2x em chinês. Como o token é a unidade de cobrança, dois fatores que quase nunca aparecem nas páginas de preços determinam o custo de entrada: a densidade de significado por caractere de cada idioma e a eficiência com que o tokenizer de cada modelo comprime aquela escrita. Esses fatores se multiplicam, e o resultado não é o que uma análise por caractere sugere.

TL;DR

• Claude Fable 5, Opus 4.8 e Sonnet 5 compartilham um tokenizer e nunca são os mais eficientes: usam de 1.2 a 2.3x a menor contagem 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. Por significado, porém, o chinês fica próximo da paridade, enquanto japonês e coreano custam de 1.5 a 2.4x.
• O custo é a densidade da escrita multiplicada pela cobertura do tokenizer. Cobertura insuficiente amplifica o custo: GLM cobra 4.9x mais tokens em hindi do que em inglês.
• Localizar raramente economiza dinheiro; escolha o modelo por idioma com base na contagem de tokens.

As contagens foram medidas pelo gateway da Synthorai em 2026-07-08. Sempre usamos a contagem do próprio provedor, nunca um tokenizer local. Todas as repetições retornaram contagens idênticas.

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

A cobrança é feita por token, mas token não é caractere nem palavra. Cada modelo traz seu próprio tokenizer e vocabulário, e a mesma frase resulta em uma quantidade diferente de tokens em cada um. Essa contagem é multiplicada pelo preço por token. Portanto, duas variáveis mudam ao mesmo tempo: quantos tokens o texto gera e quanto custa cada token.

A maioria das páginas de preços mostra apenas o segundo número. Este artigo mede o primeiro. Enviamos três trechos semanticamente equivalentes a 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 registramos o que cada um cobrou como entrada.

Uma narrativa casual, sobre uma feira de sábado, foi preparada em nove idiomas. Uma explicação técnica sobre retry com exponential backoff e uma nota jornalística sobre a votação do orçamento municipal foram preparadas em inglês, chinês, japonês, coreano, alemão e hindi. O conjunto também inclui uma função Python e um blob JSON de tool call. As versões em outros idiomas foram geradas por tradução automática, com instruções para preservar o conteúdo sem comprimi-lo, e revisadas manualmente por amostragem. A prolixidade da tradução é uma variável real; a seção sobre registro abaixo estima seu efeito em cerca de 20%.

A contagem vem sempre do próprio provedor. Na linha Claude, fizemos uma chamada real à Messages API e lemos usage.input_tokens, pois o gateway ainda não faz proxy de count_tokens. Nos modelos compatíveis com OpenAI, fizemos uma chamada pequena e lemos usage.prompt_tokens. Assim evitamos exatamente o problema de um tokenizer local discordar da fatura. Há ainda um controle importante: toda requisição inclui uma estrutura fixa, chat template e marcadores de papel, que consome alguns tokens. Por isso, medimos uma amostra de referência com dois caracteres e subtraímos esse valor. Todas as proporções deste artigo descontam esse envelope e comparam apenas o texto, não a estrutura da chamada.

O mesmo texto, cinco tokenizers

A tabela mostra a contagem bruta de tokens de entrada do trecho narrativo, por idioma e tokenizer. Os três modelos Claude aparecem na mesma coluna porque retornaram contagens idênticas em todas as amostras, como detalharemos abaixo. Os outros dois trechos repetem o mesmo padrão e entram nos cálculos apresentados mais adiante. A coluna de caracteres contém o tamanho da versão em cada idioma. Como diferentes sistemas de escrita compactam o significado de formas distintas, o chinês expressa em 77 caracteres o mesmo conteúdo que exige 254 em inglês.

Dois pontos chamam atenção. A coluna Claude contém um único valor para três modelos porque Claude Fable 5, Opus 4.8 e Sonnet 5 retornaram contagens idênticas em todas as amostras, tanto em idiomas naturais quanto em código e JSON. Os três usam o tokenizer lançado com o Opus 4.7, portanto uma contagem feita em um deles vale para os demais. Essa coluna também contém o maior valor em todas as linhas, exceto em hindi, no qual os 192 tokens do GLM são ainda piores. Normalizando as contagens líquidas para que o modelo mais eficiente de cada idioma seja 1.00, o envelope é subtraído antes, então as proporções não correspondem à divisão direta dos valores brutos acima, temos:

O empate quádruplo na linha do inglês não é efeito de arredondamento: DeepSeek, GLM, GPT-5.5 e Kimi geram exatamente 50 tokens líquidos nesse trecho. No trecho narrativo, Claude usa de 1.3x a 2.2x os tokens do tokenizer mais eficiente; nos três trechos, a faixa vai de 1.2x a 2.3x. Essa é uma característica do vocabulário e se aplica a todas as chamadas durante a vida útil do modelo. Os trechos técnico e jornalístico repetem a classificação: somados, Claude cobra 212 tokens líquidos em chinês, contra 114 do Kimi (1.9x), e 477 em hindi, contra 210 do GPT-5.5 (2.3x). Ainda assim, não existe um único vencedor. O modelo mais eficiente muda conforme o idioma:

• GPT-5.5 é o mais eficiente em alemão, francês, espanhol, italiano, hindi e coreano, além de empatar em inglês. O empate e os resultados de francês, espanhol e italiano valem para o trecho narrativo. Seu vocabulário favorece escritas latinas e também funciona bem com devanágari e hangul.
• Kimi K2.5 é o mais eficiente em chinês e mantém boa competitividade em CJK.
• DeepSeek-v4 é o mais eficiente em japonês e fica pouco atrás em chinês.
• GLM 5.2 fica no meio do grupo na maioria dos idiomas, mas apresenta os piores resultados da matriz em hindi: 2.59x a menor contagem no trecho narrativo, 179 tokens líquidos contra 69 do GPT-5.5, com resultados ainda piores nos trechos formais. É a única coluna que supera até o Claude.

A diferença não se limita à prosa. Na função Python, Claude usa 1.61x a menor contagem; no tool call em JSON, 1.29x. A distância no JSON é menor porque texto estruturado consiste principalmente em pontuação e chaves ASCII curtas, que todos os tokenizers processam de forma parecida. Em um agente de longa duração que reenvia um schema de ferramentas grande a cada turno, esse custo adicional se acumula. É nesse ponto que o cache compensa. A série sobre prompt caching explica esse funcionamento.

A armadilha do custo por caractere: CJK parece pior do que realmente custa

As tabelas acima comparam modelos. Mantendo o modelo fixo, o idioma também altera a contagem, mas não da forma sugerida pelos valores brutos por caractere. A métrica de tokenizer mais citada é a quantidade de tokens por caractere, na qual CJK se destaca: no Claude, o chinês usa cerca de 114 tokens líquidos por 100 caracteres; coreano, 106; japonês, 94; inglês, 32. Considerada isoladamente, essa coluna faz CJK parecer 3x mais caro. Mas ela mede a dimensão errada: a cobrança é pelo significado, não pelos caracteres, e todos os trechos alinhados transmitem o mesmo conteúdo. A tabela mostra as duas perspectivas no Claude para o trecho narrativo:

As duas colunas à direita contam histórias diferentes. O chinês é o caso mais marcante: tem a maior densidade de tokens por caractere do conjunto, mas custa apenas 1.07x o inglês por significado nesse trecho. Seus 77 caracteres transmitem o que exige 254 em inglês. A taxa elevada por caractere é multiplicada por uma quantidade muito menor de caracteres, e os efeitos quase se anulam. Esse cancelamento também aparece nos três trechos, embora não seja perfeito: no Claude, o chinês custa em média 1.17x o inglês; dependendo do modelo, varia de 0.95x a 1.32x. Isso fica perto da paridade, não dos 3x sugeridos pela coluna por caractere.

Japonês e coreano mostram o limite desse efeito. Os dois também têm alta densidade de tokens por caractere, pois hangul e kana representam sons usando aproximadamente um glifo por sílaba, em vez de compactar uma palavra inteira em cada caractere como os hanzi chineses. Por isso, o trecho exige 143 caracteres em coreano e 136 em japonês, contra 77 em chinês. Multiplicar mais caracteres por uma taxa alta por caractere não anula o custo; amplifica-o. No Claude, o coreano custa em média 1.96x o inglês por significado nos três trechos, enquanto o japonês custa 1.56x. Ambos são de fato mais caros, apesar de suas colunas por caractere se parecerem muito com a do chinês.

O alemão é o reflexo inverso do chinês: tem uma taxa baixa por caractere, 48, próxima da do inglês, mas a maior quantidade de caracteres entre os idiomas analisados, 289, devido às palavras compostas. O total ainda chega a 1.68x. O custo é o produto dos dois eixos; qualquer um deles, isoladamente, leva a conclusões erradas.

Por que os números mudam: dois fatores multiplicados

Todas as tabelas acima seguem uma única equação:

tokens de um trecho = (caracteres necessários para expressar o significado) x (tokens por caractere)

O primeiro fator é a densidade do sistema de escrita, uma propriedade do idioma, não do modelo. Trata-se de um espectro, e não de uma exceção exclusiva do chinês. O chinês logográfico compacta um morfema em cada caractere e ocupa o extremo de maior densidade. Kana japonês e hangul coreano representam sons, portanto têm menor densidade e exigem mais caracteres. Devanágari e os alfabetos latinos são ainda menos densos. A quantidade de significado por caractere diminui progressivamente do chinês ao inglês.

O segundo fator é quantos tokens o vocabulário do modelo usa por caractere daquela escrita, algo específico de cada modelo. Um tokenizer BPE aprende merges de vários caracteres com base no corpus de treinamento. Escritas frequentes no corpus recebem tokens compactos; as raras tendem a cair em codificação por caractere ou até por byte, na qual um único caractere pode virar dois ou três tokens. Para os mesmos três idiomas, em tokens líquidos por caractere:

A tabela explica três pontos. O chinês se destaca nos totais porque ocupa um extremo do primeiro fator. Mesmo a compressão fraca do chinês no Claude, 1.14 tokens por caractere, ainda dividindo alguns hanzi em dois, não produz um total elevado quando há apenas 77 caracteres. Nos modelos treinados na China, a compressão é boa o bastante, de 0.52 a 0.58, para chegar perto do próprio custo em inglês. Em hindi, o acréscimo vem do segundo fator, não da densidade: GLM usa 0.91 tokens por caractere devanágari, quase um token por caractere, porque seu vocabulário praticamente não inclui merges devanágari de vários caracteres. GPT-5.5 usa 0.35 ao cobrir grupos silábicos inteiros, uma diferença de cobertura na mesma escrita. Claude tem valores altos em todos os casos porque sua taxa por caractere já é elevada em inglês, 0.32 contra 0.20 do DeepSeek, uma base do próprio modelo somada ao efeito de cada idioma.

Isso não é uma peculiaridade dos sete modelos avaliados. A literatura acadêmica chama o fenômeno de token premium. Petrov et al. (NeurIPS 2023) mediram centenas de pares de idiomas e encontraram as mesmas duas causas: a quantidade de caracteres necessária para expressar o mesmo significado varia, assim como a cobertura do tokenizer para cada escrita. O estudo encontrou acréscimos de até 15x em idiomas com poucos recursos, com as mesmas consequências: custo e latência maiores, além de uma context window efetivamente menor, pois um idioma com acréscimo elevado preenche o mesmo orçamento de contexto com menos significado. A diferença também diminui conforme os fornecedores investem. Medições independentes apontam +182% de tokens para chinês em relação ao inglês nos vocabulários da era GPT-3, contra +24% no GPT-4o. Esse valor se aproxima dos +32% medidos no GPT-5.5 e da paridade observada nos modelos treinados na China. Cobertura consome posições no vocabulário, e os fornecedores continuam ampliando esse investimento.

Localizar alguma vez reduz o custo?

A seção anterior pode levar a duas conclusões erradas: “Claude tem custo estável entre idiomas, então a localização é irrelevante” e “modelos chineses são baratos em chinês, então localizar economiza dinheiro”. A tabela mostra cada idioma em relação ao inglês do próprio modelo, na média dos três trechos e para os cinco idiomas disponíveis em todos eles:

Claude não tem custo estável: coreano custa 1.96x seu inglês; hindi, 2.40x. O chinês ficar perto de 1.17x é uma coincidência específica desse idioma, não uma propriedade do modelo. Os modelos chineses também não ficam muito abaixo da paridade em chinês; apenas chegam até ela. O melhor valor de toda a tabela é 0.95x no Kimi, cinco por cento abaixo de seu próprio inglês. Todos os demais valores são iguais ou maiores. Em hindi, japonês e coreano, esses mesmos modelos têm um acréscimo maior que o Claude, não menor, pois essas escritas estão mais distantes do foco de treinamento. O padrão não é “o fornecedor X é barato”. Em relação ao próprio inglês, cada modelo é mais eficiente nos idiomas mais próximos de seus dados de treinamento.

O registro do texto também altera esses números. A narrativa casual é o caso mais favorável. Os trechos técnico e jornalístico aumentam quase todos os multiplicadores, pois terminologia e empréstimos linguísticos são justamente os elementos para os quais vocabulários não latinos têm menos merges. No Claude, o alemão passa de 1.68x no texto casual para 2.29x no técnico; no trecho jornalístico, o hindi do GLM chega a 5.98x seu inglês. Um benchmark com apenas um trecho favorece o idioma que recebeu a tradução mais concisa. Por isso, o trecho narrativo isolado colocou o chinês em 0.80x no Kimi, enquanto a média dos três o coloca em 0.95x.

Comparar cada modelo com seu próprio inglês também não é a perspectiva correta. O custo real depende da quantidade absoluta de tokens. Nessa comparação, Claude é o mais caro em oito dos nove idiomas; o hindi do GLM é a única exceção ainda pior. Conteúdo em chinês “barato em relação ao inglês do Claude” ainda gera 88 tokens líquidos no Claude, contra 40 no Kimi para o trecho narrativo. A estratégia não é localizar para economizar, mas escolher o modelo pelo idioma: Kimi ou DeepSeek para chinês, GPT-5.5 para hindi e coreano, DeepSeek para japonês. Claude nunca vence em custo de tokens em nenhum idioma, embora ainda possa vencer em qualidade.

A contagem é apenas metade da fatura

O multiplicador de tokens só importa quando combinado com o preço por token, e ambos se multiplicam. Claude Fable 5 custa $10 por milhão de tokens de entrada, Opus 4.8 custa $5 e Sonnet 5 custará $3 quando o preço promocional terminar. Em chinês, o tokenizer compartilhado também conta 2.2x mais tokens que o modelo mais eficiente. Esse acréscimo de contagem multiplica qualquer diferença de tarifa que já exista em relação à alternativa escolhida para o roteamento. O inverso também ocorre: um modelo pode contar poucos tokens e ainda assim custar mais por chamada devido à sua tarifa elevada. Nenhum dos números, isoladamente, determina a fatura. Não incluímos aqui as tarifas dos outros fornecedores porque elas mudam mais rápido que os tokenizers. As contagens acima são a parte mais duradoura do cálculo.

Na prática, pare de comparar preços de tabela e calcule o custo efetivo de entrada: conte o mix real de tráfego em cada modelo candidato e multiplique o resultado pela tarifa de entrada correspondente. Em um produto com muito conteúdo em chinês ou coreano, esse cálculo pode mudar a ordem dos modelos mais baratos. A diferença persistente fica entre 1.5x e 2x, longe de ser um erro de arredondamento. Pelo mesmo motivo, ao usar cache, a métrica relevante é o custo efetivo ponderado pela taxa de acerto, não o preço anunciado. A comparação entre provedores detalha esse cálculo. A análise entre versões, por que Sonnet 5 conta 41% mais tokens que Sonnet 4.6 no mesmo texto em inglês, está no artigo sobre o tokenizer do Sonnet 5.

Conclusão

• O custo em tokens é a densidade da escrita multiplicada pela cobertura do tokenizer. O idioma determina o primeiro fator; o modelo, o segundo. Analisar qualquer um deles isoladamente leva a conclusões erradas.
• Claude Fable 5, Opus 4.8 e Sonnet 5 usam de 1.2x a 2.3x a contagem do modelo mais eficiente em todos os idiomas, pois sua taxa por caractere é alta até em inglês.
• O modelo mais eficiente depende do idioma: GPT-5.5 para idiomas europeus, hindi e coreano; Kimi para chinês; DeepSeek para japonês. GLM tem o pior desempenho em hindi, com quase um token por caractere.
• Registros formais e técnicos aumentam o multiplicador em quase todos os idiomas. Faça benchmarks com o mesmo registro usado em produção.
• Não localize para economizar. Escolha o modelo pelo idioma com base na contagem absoluta de tokens e multiplique pelo preço de cada modelo para comparar o custo efetivo.

Perguntas frequentes

Qual tokenizer de LLM é mais barato? Depende do idioma. Entre sete modelos testados com os mesmos trechos alinhados, GPT-5.5 foi o mais eficiente em idiomas europeus, hindi e coreano, além de empatar em inglês. Kimi K2.5 venceu em chinês; DeepSeek-v4, em japonês. A família Claude, Fable 5, Opus 4.8 e Sonnet 5, nunca foi a mais eficiente, usando de 1.2x a 2.3x a menor contagem em todos os idiomas e registros.

Claude Fable 5, Opus 4.8 e Sonnet 5 usam o mesmo tokenizer? Sim. Os três produziram contagens idênticas em todas as amostras, em todos os idiomas, além de código e JSON. Eles usam o tokenizer lançado com o Opus 4.7. Portanto, a contagem de um vale para os demais, e a fatura maior do Fable 5 vem exclusivamente do preço por token.

Chinês custa mais que inglês no Claude? Um pouco: 1.17x por significado, na média de três trechos, e aproximadamente o mesmo nos modelos treinados na China. Por caractere, a diferença parece muito maior: cerca de 114 tokens líquidos por 100 caracteres chineses, contra 32 em inglês. Como o chinês transmite o mesmo significado usando aproximadamente um terço dos caracteres, os totais quase se anulam.

Japonês e coreano se comportam como chinês? Apenas em parte. Ambos têm uma taxa por caractere alta como o chinês, mas hangul e kana representam sons e exigem muito mais caracteres para o mesmo trecho: 136 em japonês e 143 em coreano, contra 77 em chinês. A taxa alta por caractere deixa de ser compensada. Por significado, o japonês custa cerca de 1.6x o inglês no Claude e o coreano, cerca de 2x. Nos sete modelos, a faixa vai de 1.5x a 2.4x.

Como medir isso nos meus próprios prompts? Envie alguns prompts reais, com o mesmo registro usado em produção, para cada modelo candidato. Leia a contagem de tokens de entrada nos campos de uso do próprio provedor, em vez de confiar em um tokenizer local. Um único trecho favorável pode beneficiar um idioma em cerca de 20%, então use vários. Depois, multiplique cada contagem pelo preço de entrada do modelo para obter o custo efetivo no seu tráfego.

← Voltar ao blog