FAQ

O que é um modelo de decisão?

Um modelo que lê um estado (texto, um e-mail, um ticket, um objeto JSON) mais perguntas tipadas, e retorna uma resposta tipada com probabilidades calibradas para cada pergunta em um único forward pass. Ele nunca gera texto. Isso o torna rápido, e a sua saída fácil de usar: rotear o ticket, bloquear a mensagem, escalonar quando a probabilidade está acima de um limiar.

Como eu instalo?

O aplicativo de desktop para macOS, Windows e Linux; curl -fsSL https://ollaya.dev/install.sh | sh para a linha de comando no Linux e macOS, irm https://ollaya.dev/install.ps1 | iex no Windows; ou a imagem Docker ghcr.io/ollaya-dev/ollaya. Veja Baixar.

Como o Ollaya se relaciona com o Ollama?

O Ollaya pega a experiência do Ollama (um único binário, pull, run, serve, Modelfiles, uma API REST local com as mesmas convenções) e a aplica a modelos de decisão em vez de modelos de linguagem generativos. É um projeto independente, sem afiliação com o Ollama.

O Ollama agora roda modelos de decisão. Em que o Ollaya é diferente?

O Ollama 0.35 (setembro de 2026) adicionou /v1/systemone para dois modelos decodificadores, o Nimble da Bespoke Labs e o Tev1 da Together AI. Os dois projetos seguem o formato de fio da TypeSafe e, para modelos decodificadores, ambos leem os escores do próximo token dos rótulos de resposta. O Ollaya também roda o Nimble, desde a 0.8.0. Esta comparação é com o Ollama 0.35:

Medido lado a lado. Em uma RTX 5090, sobre o benchmark público da Bespoke Labs (3.880 perguntas rotuladas por humanos de 13 conjuntos de dados, pontuadas com o próprio código da Bespoke): winnow:12b no Ollaya marca 0.773 a 60 ms por pergunta, contra 0.749 a 210 ms do Nimble no Ollama, o melhor do Ollama. Nos mesmos pesos do Nimble a acurácia é a mesma (0.748 e 0.749), o erro de calibração é 5.5 vezes menor no Ollaya (0.022 contra 0.122, porque o Ollaya aplica a temperatura do autor), e o Ollama é mais rápido (210 contra 310 ms: ele roda um GGUF Q8_0 onde o Ollaya calcula em fp32). A página inicial tem o gráfico.

As vantagens do Ollama também são reais. O Tev1 está lá e ainda não aqui (a Together AI não publicou uma licença para os seus pesos), e se você já usa o Ollama para modelos de linguagem, um único daemon cobre os dois. Os dois rodam lado a lado: Ollama na porta 11434, Ollaya na 11435.

Como ele se relaciona com a TypeSafe?

O modelo Jev fechado da TypeSafe criou a categoria dos modelos de decisão. O Ollaya serve modelos abertos atrás de uma API compatível com a TypeSafe: o SDK Python oficial da TypeSafe 0.7.1 funciona sem alterações com TYPESAFE_BASE_URL=http://localhost:11435 e qualquer chave de API. O Ollaya não é afiliado à TypeSafe. Veja Compatibilidade com a TypeSafe.

Quais modelos eu posso rodar?

Modelos de decisão abertos destas famílias. Veja Models, que compara a acurácia e a velocidade deles.

• winnow da EldanRing: Winnow-E4B (winnow:e4b, o modelo recomendado) e Winnow-12B (winnow), ajustes finos do Gemma 4 publicados como arquivos GGUF. O Ollaya roda o arquivo do autor no llama.cpp, em uma GPU NVIDIA, na GPU de um Apple silicon ou na CPU. winnow:e4b marca 0.722 em decisões tipadas, perto do 0.738 do Jev, em cerca de 90 ms em uma RTX 4090.
• laya da Convai Innovations: laya (um roteador), laya:en, laya:multilingual e laya:typed-decisions, cada um também como -fp16 e -fp32. O laya envia texto em inglês para laya:en e outros idiomas, o turco por exemplo, para laya:multilingual. É o mais rápido.
• decider da Mapika: decider:4b, decider:2b e decider:0.8b, construídos sobre o Qwen3.5. decider:4b marca 0.680 em decisões tipadas. decider:2b-vision também lê uma imagem junto com o estado.
• nli do Moritz Laurer: classificadores NLI zero-shot sobre DeBERTa-v3-large e ModernBERT-large. É o codificador mais preciso.
• gliclass da Knowledgator: um classificador zero-shot que segue instruções e pontua cada opção em uma passada.
• kev do Jared Palmer: kev:4b (kev), kev:0.8b e kev:9b, um LoRA e uma cabeça de ponteiro sobre o Qwen3.5 que pontua cada opção no seu próprio span, calibrado. kev:9b marca 0.722 em decisões tipadas, tanto quanto o winnow:e4b, mas precisa de uma GPU de 24 GB e leva cerca de 500 ms.
• decision dos contribuidores do vLLM Semantic Router: decision:eos, Decision 1.0 Eos, um Qwen3.5-0.8B totalmente ajustado com uma cabeça de endpoint que pontua cada opção no seu último token, calibrado, com linhas de até 16.384 tokens.
• qwen3guard do time do Qwen: um guardrail de segurança em 119 idiomas. Ele responde às suas próprias perguntas embutidas (seguro, controverso ou inseguro, e a categoria insegura), então você envia só o texto.
• von do Victor Hugo Panisa: Von 1.1 sobre ModernBERT-large, que pontua cada opção no seu próprio marcador em uma passada e lê estados de até 8.192 tokens.
• clm da Contrastive-LM: CLM-v0.1-8B, que embute o estado e cada opção com o Qwen3-8B e escolhe a opção mais próxima do estado através de duas cabeças treinadas. Perguntas e opções são cacheadas, então as repetidas são quase gratuitas. Ele marca 0.357 em decisões tipadas; os seus autores o construíram para estados de agente, de jogo e de chamada de ferramenta.
• jevk5 do alibiserikbay: JevK5 v0.3, um ajuste fino do Qwen3.5-4B publicado como arquivos GGUF. O Ollaya roda o arquivo 4B Q8_0 do autor no llama.cpp, com até 16 opções por pergunta.

De onde vêm os pesos?

Dos próprios repositórios Hugging Face dos autores dos modelos, fixados em um commit. Cada arquivo é verificado pelo seu sha256 quando é baixado. O Ollaya nunca re-hospeda pesos: o seu registro só serve pequenos manifestos e arquivos derivados, como os grafos ONNX, que referenciam os pesos por URL. Os mesmos arquivos derivados são publicados no Hugging Face sob ollaya-dev.

As respostas são as mesmas do modelo original?

O Ollaya roda o Laya como ONNX. Em 2.383 perguntas por checkpoint (en, multilingual e typed-decisions), a exportação ONNX escolheu a mesma resposta que a referência PyTorch fp32 em 100% das vezes, com uma diferença máxima de probabilidade de 1.1 × 10⁻⁴. Em uma GPU CUDA o grafo fp16 roda por padrão; ele pode diferir do fp32 em empates apertados. Fixe uma tag -fp32 para corresponder à referência.

Como os modelos se comparam com o Jev?

Depende do modelo. Em decisões tipadas (2.000 perguntas), winnow:e4b e kev:9b chegam mais perto, com 0.722 contra 0.738 do Jev, e winnow:e4b responde cinco perguntas em cerca de 90 ms em uma RTX 4090, mais rápido que a API hospedada do Jev. Os codificadores pequenos, como o laya, são os mais rápidos, mas ficam bem abaixo do Jev em perguntas mais difíceis. A página inicial lista a acurácia e a velocidade de cada modelo. Para uma comparação independente de modelos de decisão abertos com o Jev, em acurácia e calibração, veja o Decision Index. Se você tem dados rotulados para uma tarefa fixa, um modelo ajustado neles geralmente supera qualquer um geral.

Quão rápido ele é?

Uma decisão é um único forward pass. Medido de ponta a ponta através da API HTTP em uma RTX 4090, a requisição mediana com cinco perguntas leva 8 ms com laya:multilingual e 10 ms com laya:en (fp16), 15 ms com gliclass, 20 ms com nli e 89 ms com winnow:e4b. Uma única pergunta leva 8–11 ms nos codificadores. Os decodificadores maiores levam mais: kev:4b 354 ms, decider:4b 520 ms.

Preciso de uma GPU?

Não. O Ollaya roda na CPU e, no Linux e Windows x86-64, usa uma GPU NVIDIA com driver R525 ou mais recente quando há uma (bibliotecas CUDA 13 a partir do R580, CUDA 12 antes disso). Os scripts de instalação baixam as bibliotecas CUDA só quando encontram uma GPU. Os aplicativos de desktop do Windows e do Linux não trazem bibliotecas CUDA: sozinhos, eles rodam os modelos na CPU, e quando a linha de comando também está instalada com as suas bibliotecas de GPU (e é tão nova quanto o aplicativo), o aplicativo inicia o servidor a partir dessa instalação, que usa a GPU. Modelos GGUF como o winnow rodam no llama.cpp, que também usa a GPU dos Macs Apple silicon (Metal); a paridade deles foi verificada em CUDA e na CPU x86-64, ainda não no Metal. Eles são grandes modelos de linguagem, então uma GPU faz uma diferença muito maior para eles do que para os modelos codificadores: veja a página de cada modelo para as velocidades medidas. Em uma placa RTX série 30, 40 ou 50, os modelos GGUF não precisam de mais nada. Em placas mais antigas ou de data center (série GTX 10, V100, T4, A100, H100), as bibliotecas CUDA do llama.cpp trazem código que o driver compila no primeiro uso, o que exige um driver mais novo: R570 ou mais recente com as bibliotecas CUDA 12, e um driver para CUDA 13.4 ou mais recente com as bibliotecas CUDA 13. Com um driver mais antigo, o Ollaya roda os modelos GGUF na CPU e registra o motivo; ollaya llama-devices mostra a capacidade de computação de cada GPU e se os kernels rodam nela.

Quais plataformas são suportadas?

• Linux x86-64 e ARM64 com glibc 2.38 ou mais recente: Ubuntu 24.04, Debian 13, Fedora 39, RHEL 10 ou mais recente.
• macOS 14 ou mais recente em Apple silicon. laya e nli:modernbert-large rodam na GPU da Apple via MLX, 2 a 3 vezes mais rápido que na CPU; os outros modelos rodam na CPU.
• Docker: ghcr.io/ollaya-dev/ollaya para linux/amd64 e linux/arm64, e :cuda para GPUs NVIDIA (:cuda12 para drivers do host mais antigos que o R580). Use-o em distribuições Linux mais antigas também.
• Windows 10 e 11 em PCs x86 de 64 bits: o aplicativo de desktop, e irm https://ollaya.dev/install.ps1 | iex para a linha de comando, que também usa uma GPU NVIDIA (instale os dois e o servidor do aplicativo também a usa). WSL 2 com o instalador do Linux também funciona.
• O aplicativo de desktop roda nos três: veja Baixar.

Os meus dados saem da minha máquina?

Não. O servidor escuta em 127.0.0.1:11435 por padrão e roda os modelos localmente. A rede é usada só para baixar modelos. Estados e perguntas nunca são registrados.

Por que a porta 11435?

Ela fica ao lado da porta padrão do Ollama, 11434, para que os dois possam rodar lado a lado.

Como as probabilidades são calibradas?

Com escala de temperatura por tipo de pergunta e número de opções, enviada com cada modelo. Para limiares com que você conta, reajuste as temperaturas nos seus próprios dados rotulados e embuta-as com um Modelfile.

Existe um servidor MCP ou uma skill de agente?

Os dois. ollaya mcp serve os modelos locais para o Claude Code, o Claude Desktop, o Cursor e outros clientes MCP (claude mcp add ollaya -- ollaya mcp), e a skill ollaya-decisions ensina os agentes quando e como usá-los. Veja Agents.

Como eu atualizo?

Rode ollaya update. Ele verifica a versão mais recente e, quando há uma mais nova, roda o script de instalação de novo no mesmo lugar, o que mantém os seus modelos e as configurações do serviço. ollaya update --check só diz se existe uma atualização. O aplicativo de desktop se atualiza por inteiro: instale a nova versão em Baixar. No Docker, baixe a nova imagem.

Como eu desinstalo?

No Linux, depois que o instalador configurou o serviço:

sudo systemctl disable --now ollaya && sudo rm /etc/systemd/system/ollaya.service
sudo rm -rf /usr/local/bin/ollaya /usr/local/lib/ollaya /usr/local/share/doc/ollaya /usr/local/share/ollaya
sudo userdel -r ollaya    # also deletes /usr/share/ollaya, including the models

Para uma instalação sem root (em ~/.local), exclua ~/.local/bin/ollaya, ~/.local/lib/ollaya, ~/.local/share/doc/ollaya e ~/.local/share/ollaya, e os modelos em ~/.ollaya.

Qual é a licença?

O Ollaya é Apache-2.0. Os modelos carregam as suas próprias licenças: laya, decider, kev, decision, qwen3guard, gliclass, von, winnow, jevk5, clm e nli:modernbert-large são Apache-2.0, e nli:deberta-v3-large é MIT.