FAQ

Qu’est-ce qu’un modèle de décision ?

Un modèle qui lit un état (du texte, un e-mail, un ticket, un objet JSON) plus des questions typées, et renvoie une réponse typée avec des probabilités calibrées pour chaque question en une seule passe avant. Il ne génère jamais de texte. Cela le rend rapide, et sa sortie facile à exploiter : router le ticket, bloquer le message, escalader quand la probabilité dépasse un seuil.

Comment l’installer ?

L’application de bureau pour macOS, Windows et Linux ; curl -fsSL https://ollaya.dev/install.sh | sh pour la ligne de commande sous Linux et macOS, irm https://ollaya.dev/install.ps1 | iex sous Windows ; ou l’image Docker ghcr.io/ollaya-dev/ollaya. Voir Télécharger.

Quel est le lien entre Ollaya et Ollama ?

Ollaya reprend l’expérience d’Ollama (un binaire unique, pull, run, serve, les Modelfiles, une API REST locale avec les mêmes conventions) et l’applique aux modèles de décision plutôt qu’aux modèles de langage génératifs. C’est un projet indépendant, sans affiliation avec Ollama.

Ollama exécute désormais des modèles de décision. En quoi Ollaya diffère-t-il ?

Ollama 0.35 (septembre 2026) a ajouté /v1/systemone pour deux modèles décodeurs, Nimble de Bespoke Labs et Tev1 de Together AI. Les deux projets suivent le format filaire de TypeSafe, et pour les modèles décodeurs, les deux lisent les scores du token suivant des étiquettes de réponse. Ollaya exécute aussi Nimble, depuis 0.8.0. Cette comparaison porte sur Ollama 0.35 :

Mesuré côte à côte. Sur une RTX 5090, sur le benchmark public de Bespoke Labs (3,880 questions étiquetées par des humains issues de 13 jeux de données, notées avec le propre code de Bespoke) : winnow:12b sur Ollaya obtient 0.773 à 60 ms par question, contre 0.749 à 210 ms pour Nimble sur Ollama, le meilleur d’Ollama. Sur les mêmes poids Nimble, la précision est la même (0.748 et 0.749), l’erreur de calibration est 5.5 fois plus faible sur Ollaya (0.022 contre 0.122, parce qu’Ollaya applique la température de l’auteur), et Ollama est plus rapide (210 contre 310 ms : il exécute un GGUF Q8_0 là où Ollaya calcule en fp32). La page d’accueil contient le graphique.

Les avantages d’Ollama sont réels eux aussi. Tev1 y est et pas encore ici (Together AI n’a pas publié de licence pour ses poids), et si tu utilises déjà Ollama pour des modèles de langage, un seul démon couvre les deux. Les deux tournent côte à côte : Ollama sur le port 11434, Ollaya sur 11435.

Quel est le lien avec TypeSafe ?

Le modèle Jev fermé de TypeSafe a créé la catégorie des modèles de décision. Ollaya sert des modèles ouverts derrière une API compatible TypeSafe : le SDK Python officiel de TypeSafe 0.7.1 fonctionne sans modification avec TYPESAFE_BASE_URL=http://localhost:11435 et n’importe quelle clé d’API. Ollaya n’est pas affilié à TypeSafe. Voir Compatibilité TypeSafe.

Quels modèles puis-je exécuter ?

Des modèles de décision ouverts de ces familles. Voir Models, qui compare leur précision et leur vitesse.

• winnow d’EldanRing : Winnow-E4B (winnow:e4b, le modèle recommandé) et Winnow-12B (winnow), des ajustements fins de Gemma 4 publiés en fichiers GGUF. Ollaya exécute le fichier de l’auteur sur llama.cpp, sur un GPU NVIDIA, le GPU d’un Apple silicon ou le CPU. winnow:e4b obtient 0.722 sur les décisions typées, proche du 0.738 de Jev, en environ 90 ms sur une RTX 4090.
• laya de Convai Innovations : laya (un routeur), laya:en, laya:multilingual et laya:typed-decisions, chacun aussi en -fp16 et -fp32. laya envoie le texte anglais à laya:en et les autres langues, le turc par exemple, à laya:multilingual. C’est le plus rapide.
• decider de Mapika : decider:4b, decider:2b et decider:0.8b, construits sur Qwen3.5. decider:4b obtient 0.680 sur les décisions typées. decider:2b-vision lit aussi une image avec l’état.
• nli de Moritz Laurer : des classifieurs NLI zero-shot sur DeBERTa-v3-large et ModernBERT-large. C’est l’encodeur le plus précis.
• gliclass de Knowledgator : un classifieur zero-shot qui suit les instructions et note chaque option en une passe.
• kev de Jared Palmer : kev:4b (kev), kev:0.8b et kev:9b, un LoRA et une tête pointeur sur Qwen3.5 qui note chaque option à son propre span, calibré. kev:9b obtient 0.722 sur les décisions typées, autant que winnow:e4b, mais nécessite un GPU de 24 Go et prend environ 500 ms.
• decision des contributeurs de vLLM Semantic Router : decision:eos, Decision 1.0 Eos, un Qwen3.5-0.8B entièrement ajusté avec une tête d’endpoint qui note chaque option à son dernier token, calibré, avec des lignes allant jusqu’à 16,384 tokens.
• qwen3guard de l’équipe Qwen : un garde-fou de sécurité en 119 langues. Il répond à ses propres questions intégrées (sûr, controversé ou non sûr, et la catégorie non sûre), donc tu ne lui envoies que le texte.
• von de Victor Hugo Panisa : Von 1.1 sur ModernBERT-large, qui note chaque option à son propre marqueur en une passe et lit des états allant jusqu’à 8,192 tokens.
• clm de Contrastive-LM : CLM-v0.1-8B, qui encode l’état et chaque option avec Qwen3-8B et choisit l’option la plus proche de l’état via deux têtes entraînées. Les questions et les options sont mises en cache, donc les répétitions sont presque gratuites. Il obtient 0.357 sur les décisions typées ; ses auteurs l’ont conçu pour les états d’agents, de jeux et d’appels d’outils.
• jevk5 d’alibiserikbay : JevK5 v0.3, un ajustement fin de Qwen3.5-4B publié en fichiers GGUF. Ollaya exécute le fichier 4B Q8_0 de l’auteur sur llama.cpp, avec jusqu’à 16 options par question.

D’où viennent les poids ?

Des dépôts Hugging Face des auteurs des modèles eux-mêmes, épinglés à un commit. Chaque fichier est vérifié par son sha256 au moment du pull. Ollaya ne réhéberge jamais les poids : son registre ne sert que de petits manifestes et des fichiers dérivés, comme les graphes ONNX, qui référencent les poids par URL. Les mêmes fichiers dérivés sont publiés sur Hugging Face sous ollaya-dev.

Les réponses sont-elles les mêmes que celles du modèle d’origine ?

Ollaya exécute Laya en ONNX. Sur 2,383 questions par checkpoint (en, multilingual et typed-decisions), l’export ONNX a choisi la même réponse que la référence PyTorch fp32 dans 100 % des cas, avec un écart de probabilité maximal de 1.1 × 10⁻⁴. Sur un GPU CUDA, le graphe fp16 s’exécute par défaut ; il peut différer du fp32 sur des quasi-égalités. Fixe un tag -fp32 pour correspondre à la référence.

Comment les modèles se comparent-ils à Jev ?

Cela dépend du modèle. Sur les décisions typées (2,000 questions), winnow:e4b et kev:9b s’en approchent le plus, avec 0.722 contre 0.738 pour Jev, et winnow:e4b répond à cinq questions en environ 90 ms sur une RTX 4090, plus vite que l’API hébergée de Jev. Les petits encodeurs, comme laya, sont les plus rapides mais restent bien en dessous de Jev sur les questions difficiles. La page d’accueil liste la précision et la vitesse de chaque modèle. Pour une comparaison indépendante des modèles de décision ouverts avec Jev, sur la précision et la calibration, voir le Decision Index. Si tu as des données étiquetées pour une tâche fixe, un modèle ajusté dessus bat généralement n’importe quel modèle généraliste.

Quelle est sa vitesse ?

Une décision est une seule passe avant. Mesuré de bout en bout via l’API HTTP sur une RTX 4090, la requête médiane avec cinq questions prend 8 ms avec laya:multilingual et 10 ms avec laya:en (fp16), 15 ms avec gliclass, 20 ms avec nli et 89 ms avec winnow:e4b. Une seule question prend 8–11 ms sur les encodeurs. Les décodeurs plus grands prennent plus longtemps : kev:4b 354 ms, decider:4b 520 ms.

Ai-je besoin d’un GPU ?

Non. Ollaya tourne sur le CPU et, sous Linux et Windows x86-64, utilise un GPU NVIDIA avec un pilote R525 ou plus récent quand il y en a un (bibliothèques CUDA 13 à partir de R580, CUDA 12 avant). Les scripts d’installation ne téléchargent les bibliothèques CUDA que lorsqu’ils trouvent un GPU. Les applications de bureau Windows et Linux n’embarquent aucune bibliothèque CUDA : seules, elles exécutent les modèles sur le CPU, et quand la ligne de commande est aussi installée avec ses bibliothèques GPU (et est aussi récente que l’application), l’application démarre le serveur depuis cette installation, qui utilise le GPU. Les modèles GGUF comme winnow tournent sur llama.cpp, qui utilise aussi le GPU des Mac Apple silicon (Metal) ; leur parité a été vérifiée sur CUDA et le CPU x86-64, pas encore sur Metal. Ce sont de grands modèles de langage, donc un GPU fait une bien plus grande différence pour eux que pour les modèles encodeurs : voir la page de chaque modèle pour les vitesses mesurées. Sur une carte RTX série 30, 40 ou 50, les modèles GGUF n’ont besoin de rien de plus. Sur des cartes plus anciennes ou de centre de données (série GTX 10, V100, T4, A100, H100), les bibliothèques CUDA de llama.cpp embarquent du code que le pilote compile au premier usage, ce qui exige un pilote plus récent : R570 ou plus récent avec les bibliothèques CUDA 12, et un pilote pour CUDA 13.4 ou plus récent avec les bibliothèques CUDA 13. Avec un pilote plus ancien, Ollaya exécute les modèles GGUF sur le CPU et en journalise la raison ; ollaya llama-devices affiche la capacité de calcul de chaque GPU et si les noyaux y tournent.

Quelles plateformes sont prises en charge ?

• Linux x86-64 et ARM64 avec glibc 2.38 ou plus récent : Ubuntu 24.04, Debian 13, Fedora 39, RHEL 10 ou plus récent.
• macOS 14 ou plus récent sur Apple silicon. laya et nli:modernbert-large tournent sur le GPU Apple via MLX, 2 à 3 fois plus vite que sur le CPU ; les autres modèles tournent sur le CPU.
• Docker : ghcr.io/ollaya-dev/ollaya pour linux/amd64 et linux/arm64, et :cuda pour les GPU NVIDIA (:cuda12 pour les pilotes hôtes antérieurs à R580). Utilise-le aussi sur des distributions Linux plus anciennes.
• Windows 10 et 11 sur des PC x86 64 bits : l’application de bureau, et irm https://ollaya.dev/install.ps1 | iex pour la ligne de commande, qui utilise aussi un GPU NVIDIA (installe les deux et le serveur de l’application l’utilise aussi). WSL 2 avec l’installateur Linux fonctionne aussi.
• L’application de bureau tourne sur les trois : voir Télécharger.

Mes données quittent-elles ma machine ?

Non. Le serveur écoute sur 127.0.0.1:11435 par défaut et exécute les modèles localement. Le réseau n’est utilisé que pour tirer les modèles. Les états et les questions ne sont jamais journalisés.

Pourquoi le port 11435 ?

Il se trouve juste à côté du port par défaut d’Ollama, 11434, pour que les deux puissent tourner côte à côte.

Comment les probabilités sont-elles calibrées ?

Par une mise à l’échelle par température selon le type de question et le nombre d’options, livrée avec chaque modèle. Pour les seuils sur lesquels tu t’appuies, réajuste les températures sur tes propres données étiquetées et intègre-les avec un Modelfile.

Y a-t-il un serveur MCP ou une compétence d’agent ?

Les deux. ollaya mcp sert les modèles locaux à Claude Code, Claude Desktop, Cursor et d’autres clients MCP (claude mcp add ollaya -- ollaya mcp), et la compétence ollaya-decisions apprend aux agents quand et comment les utiliser. Voir Agents.

Comment le mettre à jour ?

Lance ollaya update. Il vérifie la dernière version et, s’il y en a une plus récente, relance le script d’installation au même endroit, ce qui conserve tes modèles et les réglages du service. ollaya update --check te dit seulement si une mise à jour existe. L’application de bureau se met à jour en bloc : installe la nouvelle version depuis Télécharger. Dans Docker, tire la nouvelle image.

Comment le désinstaller ?

Sous Linux, après que l’installateur a mis en place le service :

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

Pour une installation sans root (dans ~/.local), supprime ~/.local/bin/ollaya, ~/.local/lib/ollaya, ~/.local/share/doc/ollaya et ~/.local/share/ollaya, ainsi que les modèles dans ~/.ollaya.

Quelle est la licence ?

Ollaya est sous Apache-2.0. Les modèles portent leurs propres licences : laya, decider, kev, decision, qwen3guard, gliclass, von, winnow, jevk5, clm et nli:modernbert-large sont sous Apache-2.0, et nli:deberta-v3-large sous MIT.