Laya no meio do request ou em fila: qual arquitetura escolher no seu app?
O Laya decide rápido o bastante pra ficar no meio do request, mas a fila costuma ser o padrão mais seguro. Os números oficiais (só em GPU T4) são cerca de 33 ms por pergunta e 7,2 ms por pergunta em lote. Em CPU, a comunidade mediu 307 ms por pergunta, com ganho de lote de 20 a 30% que some depois de 10 perguntas. Vá de síncrono quando a decisão precisa bloquear a ação e você tem GPU. Vá de fila para volume alto sem usuário esperando, já que os pesos abertos não têm custo por chamada
Fala aí, beleza? O Laya é rápido o bastante pra ficar no caminho do usuário, mas isso não quer dizer que ele DEVA ficar lá 😀
Antes de tudo, vale situar: o Laya não gera texto
Ele responde perguntas tipadas sobre um estado (um texto, um email, um ticket ou um documento JSON) numa única passada e devolve probabilidades calibradas
São três tipos de pergunta: choice (escolhe uma opção entre critérios), score (posiciona o estado numa rubrica ordinal 0, 1, 2…) e noul (pergunta booleana que devolve P(true) de 0.0 a 1.0)
Formação Claude Code
Domine Claude Code do absoluto zero até o avançado
- 120 aulas
- 4 projetos
- 9h 48min
Como o resultado é uma decisão curta, e não uma resposta longa, a pergunta de arquitetura faz todo sentido: tu decide enquanto o usuário espera ou joga tudo numa fila e processa depois?
Segundo a página do Laya na wiki, ele é open source, da Convai Innovations, e foi lançado em 18/09/2026 sob licença Apache 2.0
Os pesos ficam no Hugging Face e o pacote Python é instalado via pip (pip install laya, conforme a página do pacote no PyPI), então ele roda na sua própria GPU ou CPU
Ou seja, onde ele fica no seu app é decisão 100% sua haha
Quanto tempo o Laya leva pra decidir: os números de latência
Toda a escolha entre síncrono e fila começa aqui, no tempo que cada pergunta custa
Então bora olhar só o que foi medido de verdade, beleza?
O número oficial do Laya (só em GPU T4)
O site oficial do Laya divulga cerca de 33 ms para uma pergunta e 7,2 ms por pergunta quando em lote, medidos numa GPU Tesla T4
Se liga num detalhe: o card do modelo no Hugging Face só traz números de latência em T4
Não tem número oficial pra CPU nem pra outras GPUs
E em CPU, quanto o Laya leva?
Aqui entra uma medição da comunidade, feita numa discussão aberta no Hugging Face, num Intel i9-14900HX com um estado de 227 tokens:
- 307 ms por pergunta com n=1
- 182 ms por pergunta com n=50
- o lote rende cerca de 20 a 30% de 1 a 10 perguntas e nada depois disso
Tome cuidado: isso é medição de uma pessoa, num processador específico, com um tamanho de estado específico
Não dá pra pegar esses números e assumir que valem pra sua máquina, pro seu texto ou pra outra GPU 🙂
Por que o Laya é rápido assim?
Que "passada única" é essa?
O Laya não é autorregressivo, então ele não fica gerando token por token igual um LLM de chat
Ele lê o estado uma vez e devolve a distribuição de probabilidade calibrada, e é isso que deixa a decisão curta o bastante pra sequer cogitar colocar ele no meio do request
Laya síncrono x Laya em fila: comparação lado a lado
Os dois desenhos resolvem problemas diferentes, e o que decide é o seu cenário, não o modelo
| Sinal | Laya no meio do request (síncrono) | Laya em fila (lote depois) |
|---|---|---|
| Tolerância a latência | Baixa: o usuário está esperando a decisão | Alta: ninguém está esperando na tela |
| Volume de texto | Um estado por request, poucas perguntas | Muitos estados acumulados de uma vez |
| Necessidade de bloquear a ação | Sim: a decisão libera ou barra algo agora | Não: a decisão não trava o fluxo do usuário |
| Custo de reprocessar | Irrelevante: decidiu, seguiu | Baixo: os pesos rodam na sua máquina, sem custo por chamada |
| Aproveitamento do lote | Quase nenhum, é uma pergunta por vez (cerca de 33 ms em T4) | Forte em T4 (7,2 ms por pergunta em lote), limitado em CPU segundo a medição da comunidade |
| Se o modelo errar | A decisão já afetou o usuário | Ainda dá pra revisar ou corrigir antes do efeito |
VPS Hostinger para seu sistema
10% OFF extraVPS com SSD NVMe e backups semanais. O cupom MATHEUSHORADECODAR é aplicado automaticamente pelo link.
Ver planos com 10% OFF →A última linha é a que mais pesa, na real
No síncrono o erro vira experiência do usuário na hora, na fila o erro ainda é só um registro que tu pode reprocessar
Quando colocar o Laya no meio do request
O desenho síncrono faz sentido quando a decisão muda o que acontece AGORA
A ação precisa ser bloqueada ou liberada na hora
Moderação e checagens de segurança são o caso clássico
Se o conteúdo passar e só depois alguém descobrir que não devia, a fila chegou tarde demais
Aqui o Laya fica no caminho: recebe o estado, responde e o app decide se segue ou barra
Roteamento e detecção de intenção
Quando a resposta do Laya define a próxima tela ou a próxima resposta, não tem como deixar pra depois
Pensa num atendimento no WhatsApp com n8n: saber se a mensagem é dúvida de produto, reclamação ou pedido de humano muda o fluxo que vai rodar em seguida
Roteamento e detecção de intenção estão justamente entre os casos de uso indicados no card do Laya no Hugging Face
Decidir se um modelo maior ou um humano assume
Outro uso indicado no mesmo card do Hugging Face é o escalonamento: decidir quando um modelo maior ou uma pessoa deve pegar o caso
Isso precisa acontecer ANTES de responder, então é síncrono por natureza
A condição: isso pede GPU
Se liga nisso, porque é aqui que muita gente vai se ferrar
O número oficial de cerca de 33 ms é numa T4
Em CPU, a comunidade mediu cerca de 307 ms por pergunta, e isso muda bastante a conta de quem está esperando uma resposta
E lembra: várias perguntas no mesmo request somam latência
Se tu faz uma pergunta de moderação, outra de intenção e mais uma de escalonamento, o usuário espera todas elas…
Quando mandar o Laya para uma fila
Aqui o jogo vira: ninguém está olhando pra tela esperando o resultado
Volume alto de texto sem usuário esperando
Triagem de email e pontuação de relevância de um acervo são o exemplo perfeito
Tu junta os estados, manda pro Laya em lote e grava o resultado, sem ninguém sofrendo com a espera
Decisões que não bloqueiam nada
Se a decisão só organiza, etiqueta ou prioriza, não tem motivo pra ela travar o request
Melhor deixar o usuário seguir e decidir com calma depois
Reprocessar sai barato
Como os pesos rodam na sua própria máquina, não tem custo por chamada
Mudou a pergunta, ajustou o critério, quer rodar tudo de novo? Roda de novo 😛
A fila é onde o lote rende (em GPU)
Na T4, o número oficial em lote é de 7,2 ms por pergunta, contra cerca de 33 ms de uma pergunta isolada
É aí que a fila brilha: tu acumula e processa junto
E se a fila rodar em CPU?
Aqui o ganho é menor
Segundo a medição da comunidade, o lote rende cerca de 20 a 30% de 1 a 10 perguntas e para de crescer depois disso
Crie sistemas com IA para vender
Prompts, modelos e checklists para criar e publicar seu sistema com IA e preparar a oferta para o primeiro cliente.
Quero o e-book gratuito Receba o livro e os bônus no seu e-mail.Então, em fila na CPU, o que ajuda é paralelizar o trabalho, e não ficar inflando o tamanho do lote esperando milagre
O desenho híbrido: decisão rápida agora, refinamento depois
E se tu quiser os dois? Dá, e é bem massa
Uma pergunta noul barata no request
No caminho síncrono vai só uma pergunta booleana (noul) pra barrar o que é claramente problemático
O resto, as perguntas score e choice mais detalhadas, vai pra fila
Assim o usuário espera o mínimo e a análise completa acontece depois
Usando as probabilidades calibradas como gatilho
Como o Laya devolve probabilidade calibrada, dá pra usar o próprio P(true) pra decidir o caminho:
- P(true) bem alta ou bem baixa: decide na hora
- faixa intermediária: manda pra fila ou pra um humano revisar
Onde fica o corte entre "certeza" e "dúvida" depende do seu caso e dos seus dados, então não existe número mágico aqui
Por que a pergunta booleana vai pro caminho síncrono?
Pela acurácia divulgada por primitiva:
- noul: 0.857
- choice: 0.733
- score: 0.723
A noul é a mais confiável das três, então faz sentido reservar ela pra decisão que acontece na frente do usuário e deixar as outras onde ainda dá pra corrigir
Veredito: qual arquitetura escolher para o Laya
Sem enrolação: fila por padrão
Síncrono só em duas situações:
- A decisão precisa bloquear a ação e você tem GPU
- A latência de CPU cabe no seu orçamento pra uma única pergunta
Fora disso, a fila ganha, principalmente porque o erro ainda pode ser corrigido antes de afetar alguém
Os pesos abertos favorecem a fila
O Laya tem pesos Apache 2.0 que rodam localmente, podem passar por fine-tuning e ser implantados sem custo por chamada
Isso é bem diferente do Jev, que é uma API hospedada fechada (se tu já viu como usar o Jev para detectar jailbreak, sabe que ali o modelo não fica na sua máquina)
Sem custo por chamada, reprocessar vira algo trivial, e isso puxa muiiito a balança pro lado da fila
Meça no seu próprio hardware
O card só traz números de T4, e a medição em CPU é de uma pessoa, num i9, com um estado de 227 tokens
O seu texto, o seu servidor e a sua quantidade de perguntas são outros, então o único número que vale de verdade pro seu app é o que tu medir aí
E para textos em português?
O checkpoint em inglês é baseado em ModernBERT-large, com cerca de 421 milhões de parâmetros
Pra português, o caminho é a variante multilíngue, baseada em mmBERT-base, com 322 milhões de parâmetros e suporte a mais de 100 idiomas
Não tem número oficial de latência separado pra ela, então mais um motivo pra medir antes de decidir 🙂
Conclusão
O Laya é rápido, mas o "onde" importa tanto quanto o "quanto"
Recapitulando os quatro sinais: tolerância a latência, volume de texto, necessidade de bloquear a ação e custo de reprocessar
Se a decisão precisa travar algo agora e tu tem GPU, vai de síncrono, e se não, fila (ou o híbrido, com uma noul na frente e o resto depois)
O próximo passo é instalar o pacote:
pip install layaPegar os pesos em huggingface.co/convaiinnovations/laya, medir a latência com os seus próprios estados e aí sim decidir com base nesses quatro sinais
Bora testar aí e me conta onde o Laya ficou no seu app, até o próximo post! 😀
Perguntas frequentes
O Laya roda 100% local, sem depender de internet?
Sim. Os pesos ficam no Hugging Face e o pacote Python é instalado via pip install laya, rodando na sua própria GPU ou CPU. Não é uma API hospedada, então a decisão acontece na sua máquina.
Dá pra usar o Laya em CPU em produção ou só faz sentido em GPU?
Dá, mas a conta muda bastante. A comunidade mediu cerca de 307 ms por pergunta em CPU (n=1) contra os 33 ms oficiais em GPU T4, então em CPU o desenho síncrono tende a pesar mais na experiência do usuário.
Qual a diferença prática entre escolher Laya ou Jev na arquitetura?
O Jev é uma API fechada, então a decisão sempre passa por uma chamada externa. O Laya usa pesos Apache 2.0 que rodam localmente, podem ser ajustados por fine-tuning e não têm custo por chamada, o que muda o cálculo de colocar ele no meio do request ou numa fila que reprocessa bastante.
A acurácia do Laya é boa o bastante pra decisão automática sem revisão humana?
Depende do tipo de pergunta. O projeto divulga 0.857 pra noul, 0.733 pra choice e 0.723 pra score, então perguntas booleanas tendem a ser mais confiáveis que as de rubrica ordinal ou múltipla escolha.
Fazer várias perguntas do Laya no mesmo request é uma boa ideia?
Cada pergunta soma latência, já que o modelo não é autorregressivo mas processa uma pergunta por passada. Se o request precisa de moderação, intenção e escalonamento juntos, o usuário espera as três, o que pesa mais contra o desenho síncrono.
O ganho de processar o Laya em lote vale a pena em qualquer cenário?
Em GPU T4 sim, o lote cai pra 7,2 ms por pergunta contra 33 ms isolado. Em CPU o ganho é bem mais limitado: cerca de 20 a 30% até 10 perguntas por lote, e some depois disso segundo a medição da comunidade.
Matheus Battisti
Formações
Formação Vibe Coding
Do Prompt ao Produto: Crie Software Real com IA
- 474 aulas
- 20 projetos
- 39h 30min
Blog | Mais populares
Choice, score e noul: quais são os tipos de pergunta do Laya e quando usar cada um?
Entenda os tipos de pergunta do Laya: choice, score e noul. Como cada um funciona, a acurácia de cada primitiva e quando usar em cada situação.
Como usar o laya para detectar phishing, spam e risco de churn em texto, email e ticket?
Veja como o laya detecta phishing, spam e risco de churn em texto, email e ticket com scores calibrados, rodando local via pip install.
Quando não usar o laya? Os limites de um motor de decisões que não gera texto
Quando não usar laya? Veja os limites do motor de decisões: sem texto, sem zero-shot eficaz, sem raciocínio em várias etapas. Descubra onde ele falha.
