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 devolve uma resposta tipada com probabilidades calibradas para cada pergunta numa única passagem em frente. Nunca gera texto. Isso torna-o rápido, e a sua saída fácil de usar: encaminhar o ticket, bloquear a mensagem, escalar quando a probabilidade está acima de um limiar.

Como o instalo?

A aplicação 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. Vê Transferir.

Como é que o Ollaya se relaciona com o Ollama?

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

O Ollama já corre modelos de decisão. Em que é que o Ollaya é diferente?

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

Medido lado a lado. Numa 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 exatidão é 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: corre 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 já usas o Ollama para modelos de linguagem, um único daemon cobre os dois. Os dois correm lado a lado: Ollama na porta 11434, Ollaya na 11435.

Como é que 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. Vê Compatibilidade com a TypeSafe.

Que modelos posso correr?

Modelos de decisão abertos destas famílias. Vê Models, que compara a exatidão 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 ficheiros GGUF. O Ollaya corre o ficheiro do autor no llama.cpp, numa 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 numa RTX 4090.
• laya da Convai Innovations: laya (um encaminhador), 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 numa passagem.
• 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 da equipa do Qwen: um guardrail de segurança em 119 idiomas. Responde às suas próprias perguntas embutidas (seguro, controverso ou inseguro, e a categoria insegura), por isso só lhe envias o texto.
• von do Victor Hugo Panisa: Von 1.1 sobre ModernBERT-large, que pontua cada opção no seu próprio marcador numa passagem 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 colocadas em cache, por isso as repetidas são quase gratuitas. Marca 0.357 em decisões tipadas; os seus autores construíram-no 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 ficheiros GGUF. O Ollaya corre o ficheiro 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 num commit. Cada ficheiro é verificado pelo seu sha256 quando é transferido. O Ollaya nunca volta a alojar pesos: o seu registo só serve pequenos manifestos e ficheiros derivados, como os grafos ONNX, que referenciam os pesos por URL. Os mesmos ficheiros derivados são publicados no Hugging Face sob ollaya-dev.

As respostas são as mesmas do modelo original?

O Ollaya corre 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⁻⁴. Numa GPU CUDA o grafo fp16 corre por predefinição; pode diferir do fp32 em empates apertados. Fixa uma tag -fp32 para corresponder à referência.

Como é que 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 a cinco perguntas em cerca de 90 ms numa RTX 4090, mais rápido que a API alojada 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 exatidão e a velocidade de cada modelo. Para uma comparação independente de modelos de decisão abertos com o Jev, em exatidão e calibração, vê o Decision Index. Se tens dados rotulados para uma tarefa fixa, um modelo ajustado neles geralmente supera qualquer um geral.

Quão rápido é?

Uma decisão é uma única passagem em frente. Medido de ponta a ponta através da API HTTP numa RTX 4090, o pedido mediano 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 descodificadores maiores levam mais: kev:4b 354 ms, decider:4b 520 ms.

Preciso de uma GPU?

Não. O Ollaya corre 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 só transferem as bibliotecas CUDA quando encontram uma GPU. As aplicações de desktop do Windows e do Linux não trazem bibliotecas CUDA: sozinhas, correm os modelos na CPU, e quando a linha de comando também está instalada com as suas bibliotecas de GPU (e é tão recente quanto a aplicação), a aplicação inicia o servidor a partir dessa instalação, que usa a GPU. Modelos GGUF como o winnow correm 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. São grandes modelos de linguagem, por isso uma GPU faz uma diferença muito maior para eles do que para os modelos codificadores: vê a página de cada modelo para as velocidades medidas. Numa placa RTX série 30, 40 ou 50, os modelos GGUF não precisam de mais nada. Em placas mais antigas ou de centro de dados (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 recente: 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 corre os modelos GGUF na CPU e regista o motivo; ollaya llama-devices mostra a capacidade de computação de cada GPU e se os kernels correm nela.

Que 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 correm na GPU da Apple via MLX, 2 a 3 vezes mais rápido que na CPU; os outros modelos correm na CPU.
• Docker: ghcr.io/ollaya-dev/ollaya para linux/amd64 e linux/arm64, e :cuda para GPUs NVIDIA (:cuda12 para drivers do anfitrião mais antigos que o R580). Usa-o em distribuições Linux mais antigas também.
• Windows 10 e 11 em PCs x86 de 64 bits: a aplicação de desktop, e irm https://ollaya.dev/install.ps1 | iex para a linha de comando, que também usa uma GPU NVIDIA (instala os dois e o servidor da aplicação também a usa). WSL 2 com o instalador do Linux também funciona.
• A aplicação de desktop corre nos três: vê Transferir.

Os meus dados saem da minha máquina?

Não. O servidor escuta em 127.0.0.1:11435 por predefinição e corre os modelos localmente. A rede é usada só para transferir modelos. Estados e perguntas nunca são registados.

Porquê a porta 11435?

Fica ao lado da porta predefinida do Ollama, 11434, para que os dois possam correr lado a lado.

Como são calibradas as probabilidades?

Com escala de temperatura por tipo de pergunta e número de opções, enviada com cada modelo. Para limiares com que contas, reajusta as temperaturas nos teus próprios dados rotulados e embute-as com um Modelfile.

Existe um servidor MCP ou uma skill de agente?

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

Como o atualizo?

Executa ollaya update. Verifica a versão mais recente e, quando há uma mais nova, executa o script de instalação de novo no mesmo lugar, o que mantém os teus modelos e as configurações do serviço. ollaya update --check só diz se existe uma atualização. A aplicação de desktop atualiza-se por inteiro: instala a nova versão em Transferir. No Docker, transfere a nova imagem.

Como o desinstalo?

No Linux, depois de o instalador ter configurado 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), apaga ~/.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 trazem 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.