Ollaya deixa modelos de decisão do tipo Jev rodarem 100% locais

O Ollaya (ollaya.dev) é um projeto open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →, licenciado em Apache-2.0, que roda modelos de decisão na máquina do desenvolvedor em vez de depender de uma API paga na nuvem. A proposta é clara pelo próprio nome, que ecoa o Ollama (o gerenciador de LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → locais que virou padrão de fato para rodar modelos generativos na própria máquina): assim como o Ollama popularizou baixar e servir um LLM com um comando, o Ollaya faz o mesmo para uma categoria diferente de modelo, os chamados decision models, e se posiciona como substituto direto de serviços proprietários como o Jev, da empresa TypeSafe.

O que é um "modelo de decisão" (e por que não é um chatbot)

Um modelo de decisão não gera texto token a token. Ele responde perguntas tipadas (escolha entre opções, nota numérica, sim ou não) sobre um texto ou JSON, em uma única passada pela rede, e devolve uma probabilidade calibrada para cada resposta. Isso importa porque é justamente o tipo de tarefa que times de produto e engenharia resolvem hoje com prompt de LLM e parsing manual de JSON: triagem de ticket, detecção de urgência, classificação de intenção, risco de churn.

O exemplo que a própria página do Ollaya usa é uma mensagem de suporte:

ollaya run laya --preset triage \
 "I was charged twice this month and want a refund."

O preset triage dispara várias perguntas de uma vez contra o texto e devolve, cada uma com sua probabilidade: intenção é reembolso (1.00), não é urgente (0.87), frustração 1.59 em uma escala de 3 (0.36), pedido de reembolso confirmado (0.88), risco de churn baixo (0.89). Segundo a página do projeto, essa chamada específica foi roteada para o modelo laya:en e respondida em 8,9 ms rodando em uma RTX 4090.

Compatível com a API da TypeSafe Jev

A parte mais relevante para quem já usa Jev em produção é a compatibilidade de API: o Ollaya expõe os endpoints /v1/systemone e /v1/models reproduzindo o formato de requisição e resposta da TypeSafe, e o SDK Python oficial da TypeSafe (versão 0.7.1) funciona sem alteração de código apontando para um servidor local:

export TYPESAFE_BASE_URL=http://localhost:11435
export TYPESAFE_API_KEY=local # qualquer valor funciona
export TYPESAFE_DEFAULT_MODEL=laya

Ou chamando o endpoint compatível diretamente:

curl http://localhost:11435/v1/systemone -d '{
 "model": "laya",
 "state": "Can I get an invoice for last month?",
 "questions": {
 "intent": {
 "type": "choice",
 "instructions": "What does the customer want?",
 "criteria": {
 "invoice": "Needs an invoice or receipt",
 "refund": "Wants money back",
 "other": "Anything else"
 }
 }
 }
}'

A resposta vem no mesmo formato que a TypeSafe usa, com probabilidade por opção (invoice: 0.9698, refund: 0.0172, other: 0.013 no exemplo da documentação). Na prática, isso significa migrar um serviço que hoje chama a API hospedada da Jev trocando só a URL base, sem reescrever a camada de integração.

Velocidade: milissegundos contra frações de segundo

O próprio site do Ollaya publica uma comparação de latência: uma requisição de cinco perguntas ao modelo Laya, rodando local numa RTX 4090 e passando pela API HTTP completa, tem mediana de 8 a 10 ms. A API hospedada da TypeSafe Jev, segundo benchmarks de terceiros citados na página (os repositórios AbdelStark/jev-benchmarks e nibzard/decision-model-benchmark), tem mediana entre 236 e 276 ms, já contando o tempo de rede.

A própria Ollaya faz a ressalva de que os setups não são idênticos (Laya roda em fp16, os demais modelos em fp32, e a comparação inclui ou não rede de formas diferentes), então o número deve ser lido como ordem de grandeza, não benchmark controlado. Ainda assim, a diferença de dezenas de vezes é grande o suficiente para importar em qualquer pipeline que classifique volume alto de mensagens em tempo real. A tabela de latência mediana por modelo, publicada na página:

• laya:multilingual: 8,1 ms
• laya:en: 9,6 ms
• gliclass: 14,7 ms
• nli: 20,4 ms
• decider:0.8b: 155 ms
• decider:2b: 190 ms
• TypeSafe Jev (API hospedada): 236 a 276 ms

Modelos disponíveis e origem dos pesos

O Ollaya não treina modelo próprio: ele empacota e serve pesos abertos de terceiros, baixados dos repositórios dos próprios autores no Hugging Face, fixados a um commit específico e verificados por hash sha256 antes de rodar. Os modelos disponíveis hoje:

• laya, da Convai Innovations: modelo em inglês e um multilíngue (mais de 100 idiomas), com 322 milhões e 421 milhões de parâmetros, respectivamente, ajustado especificamente para responder perguntas tipadas.
• decider, criado por Mapika sobre o Qwen3.5 (0,75 bilhão e 1,9 bilhão de parâmetros): um decoder que lê a resposta direto dos logits da letra da opção, descrito pela Ollaya como o modelo mais preciso do catálogo, ao custo de latência maior.
• nli, de Moritz Laurer: classificadores zero-shot baseados em encoder (396 milhões e 435 milhões de parâmetros), que transformam cada opção em uma hipótese de entailment.
• gliclass, da Knowledgator: classificador zero-shot que segue instruções e pontua todas as opções de uma pergunta em uma única passada, com 439 milhões de parâmetros, o que faz o custo crescer pouco mesmo com muitas opções.

O projeto lista mais dois itens no roadmap sem data definida: von e modelos de decisão baseados em LLM via GGUF, rodando com llama.cpp.

Onde roda e por que isso pesa para quem lida com dado sensível

O runtime é o ONNX Runtime, com o servidor escutando em 127.0.0.1 por padrão, ou seja, sem exposição externa a menos que o desenvolvedor configure isso explicitamente. Roda em CPU em qualquer plataforma; para acelerar em GPU NVIDIA, é preciso driver R580 ou mais recente. A matriz de suporte cobre macOS (Apple Silicon), Windows 10/11 x64, Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → x86-64 e ARM64, WSL 2 e Docker (amd64/arm64), com imagem no GHCR e serviço systemd para Linux. Em GPU AMD, Intel ou Apple, os modelos caem para CPU.

Para quem está pensando em usar IA para triagem de ticket, moderação ou scoring de risco sobre dado de cliente, rodar o classificador na própria infraestrutura, sem token cobrado por chamada e sem o texto sair da rede da empresa, muda o cálculo de custo e de exposição de dado, especialmente em times que já evitam mandar mensagem de usuário para APIs de terceiros por questão de conformidade. Outro ponto que a página destaca é a calibração: o erro de calibração esperado (ECE) do Laya, depois de ajuste de temperatura, é 0,081, contra 0,246 do Jev. Isso importa na prática porque é o que permite definir threshold de decisão (por exemplo, "só sinalizar como urgente acima de 0,8 de confiança") e confiar que aquele número reflete a probabilidade real, e não um score arbitrário do modelo.

O que fica em aberto

A comparação de latência publicada pelo próprio Ollaya já vem com a ressalva de que os ambientes não são equivalentes, e não há benchmark independente reproduzindo os dois lados nas mesmas condições até o momento. O catálogo de modelos também é bem mais restrito do que o universo de LLMs generativos disponíveis para tarefas abertas: quem precisa de algo fora do escopo de classificação, score ou sim/não tipados não encontra solução aqui. E a página do projeto não traz changelog nem data de lançamento das versões atuais dos binários, então quem for adotar em produção precisa validar a estabilidade da API e o suporte de longo prazo antes de trocar uma dependência paga por outra que ainda está construindo histórico.

Fonte: Hacker News