Laya multilíngue: como o router escolhe o checkpoint certo por idioma e script?

Fala aí, beleza? Decidir uma coisa só em inglês é a parte fácil

O problema aparece quando a mesma fila de decisão recebe alemão curto, tâmil, cirílico e khmer no mesmo minuto, e o modelo devolve tudo com confiança alta como se soubesse exatamente o que tá lendo

O Laya é uma família de modelos de decisão System 1 open source da Convai Innovations, publicada sob licença Apache 2.0, com lançamento em 18 de setembro de 2026. São três checkpoints diferentes e o ponto de entrada recomendado não é nenhum deles chamado na mão: é o Router, que detecta script e idioma por request e despacha pro checkpoint ideal em um único forward pass

Bora entender COMO essa escolha acontece, e onde ela erra 🙂

O que é o Laya e por que ele tem três checkpoints

Primeiro o porquê, que é o que economiza tempo depois

O Laya não gera texto. Ele é um modelo de decisão: você manda o estado e as perguntas com as opções, cada opção é pontuada no próprio token de máscara (o famoso MASK) e passa por softmax entre as opções daquela pergunta

Se você já mexeu com classificador de intenção, é primo disso, com uma diferença boa: o espaço de resposta é definido por request, sem retreino. Mudou as opções da pergunta? Só mandar as novas

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

No checkpoint multilíngue o orçamento é de 1024 tokens por pergunta, dos quais 256 ficam reservados pra pergunta e suas opções. Ou seja, o resto do contexto é pro estado que você empurra

A latência declarada pelo projeto é de 33 ms para uma pergunta e 7,2 ms por pergunta quando roda em lote, medido em GPU T4. Some isso com Apache 2.0, pesos abertos e zero assinatura de API e dá pra entender o barulho em volta do site oficial do Laya

E os três checkpoints existem porque "multilíngue" e "especialista" puxam o modelo pra lados diferentes. Um backbone só não dá conta dos dois sem perder de um lado

Laya, laya-multilingual e laya-typed-decisions: qual faz o quê

Os três vivem no Hugging Face, sob o mesmo dono: convaiinnovations/laya, convaiinnovations/laya-multilingual e convaiinnovations/laya-typed-decisions

Repara numa coisa: o multilíngue é o MENOR dos três em parâmetros, mas é o que tem cobertura ampla de idioma. Tamanho aqui não é sinônimo de "melhor pro seu caso"

E tem o aviso que vem do próprio card do laya-typed-decisions: ele é um especialista, fine-tunado em quatro workflows sintéticos específicos. Fora deles, espere comportamento igual ao checkpoint base laya ou pior

Tome cuidado com isso, porque "typed-decisions" tem nome de bala de prata e não é

Como o router decide, passo a passo, em cada request

Antes do passo a passo, um mapa dos endereços, porque isso confunde: os checkpoints são publicados nas contas convaiinnovations/... no Hugging Face e o código do Router vive no repositório oficial do projeto, o NandhaKishorM/laya. Dois endereços, mesma família Laya

E é lá que o Router aparece como o ponto de entrada recomendado: ele detecta script e idioma em sub-milissegundos e despacha em um único forward pass

O pipeline, destrinchado:

1. Detecção de script, em Python puro, ANTES do forward pass

O script é detectado em menos de 0,5 ms, antes de carregar ou rodar qualquer modelo. Quem faz isso é o módulo laya.lang, com detecção Unicode exata e 22 scripts cobertos: Devanagari, Han CJK, cirílico, árabe, hebraico, tâmil, tailandês, entre outros. A função é a detect_script

O erro comum deste passo: script que não está nas faixas cobertas some do radar. O Router trata script desconhecido como "sem letras" e cai no checkpoint padrão, que é o inglês

2. Palpite best-effort de idioma latino

Quando o texto é latino, script não resolve sozinho: espanhol, italiano, alemão e inglês dividem o mesmo alfabeto. Aí entra a detect_language, que é explicitamente um palpite best-effort, não um detector definitivo

O erro comum deste passo: quando o palpite dá indeciso, o texto vira inglês por padrão. É exatamente isso que a issue aberta #54 relata (volto nela na seção de sintomas)

3. Escolha do checkpoint

Com script e idioma na mão, o Router escolhe entre laya (inglês), laya-multilingual (100+ idiomas) e laya-typed-decisions

4. Carregamento preguiçoso com despejo LRU

Os checkpoints são carregados sob demanda, com LRU eviction. Por padrão o Router mantém apenas UM checkpoint residente em memória (max_loaded=1)

O erro comum deste passo: tráfego que alterna scripts a cada request vira troca de modelo a cada request. O custo disso é brutal e tá documentado em issue (seção de sintomas de novo)

5. Forward pass único

Aí sim roda a decisão, uma vez só, no checkpoint escolhido

O detalhe que eu acho mais massa: os passos 1 e 2 acontecem sem tocar em GPU. Você consegue inspecionar a decisão de roteamento sem pagar o preço de carregar modelo nenhum

Usando o Router na prática: instalação e API

1. Instala o pacote

pip install laya

A versão disponível no PyPI é a 0.3.4

2. Sobe o Router e roda a decisão

from laya import Router

router = Router()
router.predict(state, questions)

O predict() executa a decisão completa: detecta, escolhe, carrega se precisar e roda o forward pass

3. Inspeciona a escolha SEM carregar modelo

router.route(state, questions)

O route() devolve a decisão de roteamento e a justificativa dela, sem carregar nada. Esse é o método que eu rodaria primeiro numa amostra do tráfego real antes de subir qualquer coisa

O erro comum deste passo: pular o route(), só olhar a saída final e depois ficar caçando por que a acurácia despencou em um idioma específico

4. Força o checkpoint quando você JÁ sabe o caso

router.predict(state, questions, model="typed-decisions")

Se a request vem de uma fila que é, sempre, processamento de notas fiscais, não tem por que deixar o roteamento adivinhar

5. Deixa mais de um checkpoint quente

router = Router(max_loaded=2)

Isso mantém dois checkpoints residentes em vez de um

E o custo de memória? Os três checkpoints somam cerca de 1,16B de parâmetros, aproximadamente 4,6 GB em fp32. Não é PC da Nasa, mas também não é de graça: é por isso que o padrão vem em 1 e a decisão de subir pra 2 é sua, olhando o perfil do seu tráfego

Por que isso importa em produto com base de usuários global

Aqui a conversa sai do papel

O laya-typed-decisions foi fine-tunado em quatro workflows sintéticos, e os resultados no benchmark typed-decisions, medidos em 400 casos de teste e 2.000 decisões no split oficial, são:

Traduzindo pro dia a dia:

• Fila de atendimento multilíngue: o mesmo ticket pode chegar em espanhol, alemão ou tâmil. Quem decide "resolve automático ou escala pro humano" é o head act/escalate, e o checkpoint certo pra esse texto é o multilíngue, não o inglês
• Triagem de incidentes de segurança: alerta entra, decisão sai, e 33 ms por pergunta muda o que dá pra colocar no caminho síncrono
• Processamento de notas fiscais: é o workflow com melhor número do especialista, e costuma ser o mais repetitivo, ou seja, o candidato perfeito pra forçar o checkpoint no predict
• Observabilidade de agent-trace: decisão em cima de trace de agente, que é justamente onde chamar um LLM gerador pra cada passo fica caro rápido

E quando NÃO usar o especialista? Quando seu workflow não é um desses quatro. O card avisa na cara: fora deles, espere comportamento igual ao base ou pior. Não adianta chutar model="typed-decisions" porque o nome soa mais sofisticado 😛

Quando o router erra: sintomas conhecidos e como contornar

Agora a parte que ninguém coloca no README bonitinho. Tem coisa documentada em issue aberta, e é bom você saber antes e não depois

O checkpoint inglês colapsa em silêncio fora do alfabeto latino

Sintoma: resposta errada com confiança alta, sem nenhum sinal de incerteza

Causa: no sweep de 51 idiomas, o checkpoint inglês marca 0,000 de acurácia em khmer reportando 0,952 de confiança. E a confiança média dele nunca cai abaixo de 0,885 nos 51 idiomas

Contorno: não dá pra usar confiança como guardrail (limite) nesse checkpoint. O filtro tem que ser o roteamento, não o score

Alemão curto tratado como inglês (Issue #54)

Sintoma: acurácia despenca em textos curtos em alemão

Causa: a issue #54 relata que o Router manda 64% do alemão curto pro checkpoint inglês, custando 20 pontos no MASSIVE de. O lang.py calcula is_english como lang in (None, "en"), ou seja, idioma indeciso vira inglês

Contorno: o relato mostra que passando o idioma explicitamente (visto como lang="de" no teste com laya 0.3.4, n=200) o resultado sobe para 0,535. Se você já sabe o idioma do usuário, informe, não deixe adivinhar

Thrashing de checkpoint com max_loaded=1 (Issues #172 e #137)

Sintoma: latência absurda, na casa dos segundos, em tráfego que deveria ser de milissegundos

Causa: a issue #172 relata que com max_loaded=1 e scripts alternados o Router recarrega checkpoint a cada request: 21.000 ms contra 50 a 136 ms com max_loaded=2 nos mesmos inputs. A issue #137 descreve o mesmo thrashing com requests heterogêneos alternados

Contorno: Router(max_loaded=2) quando o tráfego alterna. Prevenção: se der, agrupa requests do mesmo script em lote, que aí você ainda pega os 7,2 ms por pergunta

A mesma issue #172 traz outro detalhe importante: espanhol e italiano também aparecem roteados pro inglês, e a MESMA reclamação, quando vai pro multilíngue, volta com 0,96 a 0,99 de confiança contra 0,535 quando cai no inglês

Armênio caindo na rota inglesa (Issue #20)

Sintoma: texto em armênio indo pro checkpoint padrão

Causa: a issue #20 mostra que caracteres armênios passam no isalpha(), mas _SCRIPT_RANGES não tinha entrada para armênio. Resultado: detect_script e script_profile descartavam o texto, e script desconhecido é tratado como "sem letras", caindo no inglês

Contorno: o PR #23 propõe adicionar o bloco Unicode armênio às faixas de script compartilhadas. Enquanto isso, forçar o checkpoint ou o idioma resolve na sua ponta

O padrão dos quatro casos é o mesmo, se liga: o erro quase nunca é o modelo decidindo mal, é o ROTEAMENTO mandando o texto pro checkpoint errado. Por isso o route() é tão útil

Vídeo: fundamentos para acompanhar os exemplos

Pra quem quer firmar a base de programação antes de sair mexendo em Router e benchmark, este vídeo do canal apresenta o Curso Completo de JavaScript

Conclusão

O veredito de uso é curtinho:

• Router como entrada padrão, sempre. Chamar checkpoint na mão só quando você JÁ sabe o workflow
• max_loaded=2 quando o tráfego alterna scripts, porque 21.000 ms contra 50 a 136 ms não é detalhe
• lang explícito quando o idioma do usuário já é conhecido no seu produto, pra não depender do palpite best-effort
• Especialista só nos quatro workflows dele, o resto vai de base ou multilíngue

Próximo passo prático: instala com pip install laya, roda route() em cima de uma amostra real do seu tráfego e olha a justificativa de cada decisão ANTES de subir em produção. Vale acompanhar as issues abertas também, que é onde os cantos escuros do roteamento estão aparecendo

E se você tá no Apple Silicon, existe runtime alternativo de terceiro: o laya-mlx, runtime MLX nativo mantido no repositório mizorewww/laya-mlx, fora do repositório oficial NandhaKishorM/laya

Faça o teste com o seu idioma e me conta o que o route() respondeu, tô curioso pra saber se o português curto escapa ou não do checkpoint inglês 😀

Até o próximo post!