FAQ

Was ist ein Entscheidungsmodell?

Ein Modell, das einen Zustand (Text, eine E-Mail, ein Ticket, ein JSON-Objekt) plus typisierte Fragen liest und in einem einzigen Vorwärtsdurchlauf eine typisierte Antwort mit kalibrierten Wahrscheinlichkeiten für jede Frage zurückgibt. Es erzeugt nie Text. Das macht es schnell, und seine Ausgabe ist leicht umzusetzen: das Ticket weiterleiten, die Nachricht blockieren, eskalieren, wenn die Wahrscheinlichkeit über einem Schwellenwert liegt.

Wie installiere ich es?

Die Desktop-App für macOS, Windows und Linux; curl -fsSL https://ollaya.dev/install.sh | sh für die Kommandozeile unter Linux und macOS, irm https://ollaya.dev/install.ps1 | iex unter Windows; oder das Docker-Image ghcr.io/ollaya-dev/ollaya. Siehe Download.

Wie hängt Ollaya mit Ollama zusammen?

Ollaya übernimmt Ollamas Erfahrung (ein Binary, pull, run, serve, Modelfiles, eine lokale REST-API mit denselben Konventionen) und wendet sie auf Entscheidungsmodelle statt auf generative Sprachmodelle an. Es ist ein unabhängiges Projekt und nicht mit Ollama verbunden.

Ollama führt jetzt Entscheidungsmodelle aus. Wie unterscheidet sich Ollaya?

Ollama 0.35 (September 2026) fügte /v1/systemone für zwei Decoder-Modelle hinzu, Nimble von Bespoke Labs und Tev1 von Together AI. Beide Projekte folgen dem Wire-Format von TypeSafe, und bei Decoder-Modellen lesen beide die Next-Token-Scores der Antwortlabels. Ollaya führt seit 0.8.0 ebenfalls Nimble aus. Dieser Vergleich bezieht sich auf Ollama 0.35:

Direkt verglichen. Auf einer RTX 5090, über den öffentlichen Benchmark von Bespoke Labs (3.880 von Hand gelabelte Fragen aus 13 Datensätzen, bewertet mit Bespokes eigenem Code): winnow:12b auf Ollaya erreicht 0.773 bei 60 ms pro Frage, gegenüber 0.749 bei 210 ms für Nimble auf Ollama, Ollamas bestem Modell. Auf denselben Nimble-Gewichten ist die Genauigkeit gleich (0.748 und 0.749), der Kalibrierungsfehler ist auf Ollaya 5.5-mal niedriger (0.022 gegenüber 0.122, weil Ollaya die Temperatur des Autors anwendet), und Ollama ist schneller (210 gegenüber 310 ms: Es führt ein Q8_0-GGUF aus, während Ollaya in fp32 rechnet). Die Startseite enthält das Diagramm.

Ollamas Vorteile sind ebenfalls real. Tev1 gibt es dort und hier noch nicht (Together AI hat keine Lizenz für seine Gewichte veröffentlicht), und wenn du Ollama bereits für Sprachmodelle nutzt, deckt ein Daemon beides ab. Beide laufen nebeneinander: Ollama auf Port 11434, Ollaya auf 11435.

Wie hängt es mit TypeSafe zusammen?

TypeSafes geschlossenes Jev-Modell begründete die Kategorie der Entscheidungsmodelle. Ollaya stellt offene Modelle hinter einer TypeSafe-kompatiblen API bereit: Das offizielle TypeSafe Python SDK 0.7.1 funktioniert unverändert mit TYPESAFE_BASE_URL=http://localhost:11435 und einem beliebigen API-Key. Ollaya ist nicht mit TypeSafe verbunden. Siehe TypeSafe-Kompatibilität.

Welche Modelle kann ich ausführen?

Offene Entscheidungsmodelle aus diesen Familien. Siehe Models, das ihre Genauigkeit und Geschwindigkeit vergleicht.

• winnow von EldanRing: Winnow-E4B (winnow:e4b, das empfohlene Modell) und Winnow-12B (winnow), als GGUF-Dateien veröffentlichte Gemma-4-Fine-Tunes. Ollaya führt die Datei des Autors auf llama.cpp aus, auf einer NVIDIA-GPU, der GPU von Apple Silicon oder der CPU. winnow:e4b erreicht 0.722 bei typisierten Entscheidungen, nahe an Jevs 0.738, in etwa 90 ms auf einer RTX 4090.
• laya von Convai Innovations: laya (ein Router), laya:en, laya:multilingual und laya:typed-decisions, jeweils auch als -fp16 und -fp32. laya sendet englischen Text an laya:en und andere Sprachen, etwa Türkisch, an laya:multilingual. Es ist das schnellste.
• decider von Mapika: decider:4b, decider:2b und decider:0.8b, aufgebaut auf Qwen3.5. decider:4b erreicht 0.680 bei typisierten Entscheidungen. decider:2b-vision liest zusätzlich ein Bild zusammen mit dem Zustand.
• nli von Moritz Laurer: Zero-Shot-NLI-Klassifikatoren auf DeBERTa-v3-large und ModernBERT-large. Es ist der genaueste Encoder.
• gliclass von Knowledgator: ein instruktionsbefolgender Zero-Shot-Klassifikator, der jede Option in einem Durchlauf bewertet.
• kev von Jared Palmer: kev:4b (kev), kev:0.8b und kev:9b, ein LoRA und ein Pointer-Head auf Qwen3.5, der jede Option an ihrer eigenen Textspanne bewertet, kalibriert. kev:9b erreicht 0.722 bei typisierten Entscheidungen, genauso viel wie winnow:e4b, braucht aber eine 24-GB-GPU und dauert etwa 500 ms.
• decision von den Mitwirkenden am vLLM Semantic Router: decision:eos, Decision 1.0 Eos, ein Qwen3.5-0.8B, das durchgängig per Fine-Tuning angepasst wurde, mit einem Endpoint-Head, der jede Option an ihrem letzten Token bewertet, kalibriert, mit Zeilen von bis zu 16.384 Token.
• qwen3guard vom Qwen-Team: eine Sicherheits-Leitplanke in 119 Sprachen. Es beantwortet seine eigenen eingebauten Fragen (sicher, umstritten oder unsicher sowie die Kategorie „unsicher”), sodass du ihm nur den Text sendest.
• von von Victor Hugo Panisa: Von 1.1 auf ModernBERT-large, das jede Option in einem Durchlauf an ihrem eigenen Marker bewertet und Zustände von bis zu 8.192 Token liest.
• clm von Contrastive-LM: CLM-v0.1-8B, das den Zustand und jede Option mit Qwen3-8B einbettet und durch zwei trainierte Heads die Option auswählt, die dem Zustand am nächsten liegt. Fragen und Optionen werden zwischengespeichert, sodass wiederholte nahezu kostenlos sind. Es erreicht 0.357 bei typisierten Entscheidungen; seine Autoren haben es für Zustände aus Agenten, Spielen und Tool-Aufrufen gebaut.
• jevk5 von alibiserikbay: JevK5 v0.3, ein per Fine-Tuning angepasstes Qwen3.5-4B, als GGUF-Dateien veröffentlicht. Ollaya führt die 4B-Q8_0-Datei des Autors auf llama.cpp aus, mit bis zu 16 Optionen pro Frage.

Woher kommen die Gewichte?

Aus den eigenen Hugging-Face-Repositories der Modellautoren, an einen Commit gebunden. Jede Datei wird beim Herunterladen gegen ihren sha256 geprüft. Ollaya hostet niemals Gewichte neu: Seine Registry stellt nur kleine Manifeste und abgeleitete Dateien bereit, etwa die ONNX-Graphen, die die Gewichte per URL referenzieren. Dieselben abgeleiteten Dateien sind auf Hugging Face unter ollaya-dev veröffentlicht.

Sind die Antworten dieselben wie die des Originalmodells?

Ollaya führt Laya als ONNX aus. Über 2.383 Fragen pro Checkpoint (en, multilingual und typed-decisions) wählte der ONNX-Export in 100 % der Fälle dieselbe Antwort wie die PyTorch-fp32-Referenz, mit einem maximalen Wahrscheinlichkeitsunterschied von 1.1 × 10⁻⁴. Auf einer CUDA-GPU läuft standardmäßig der fp16-Graph; bei fast gleichen Werten kann er von fp32 abweichen. Lege einen -fp32-Tag fest, um der Referenz zu entsprechen.

Wie schneiden die Modelle im Vergleich zu Jev ab?

Das hängt vom Modell ab. Bei typisierten Entscheidungen (2.000 Fragen) kommen winnow:e4b und kev:9b am nächsten, mit 0.722 gegenüber 0.738 für Jev, und winnow:e4b beantwortet fünf Fragen in etwa 90 ms auf einer RTX 4090, schneller als Jevs gehostete API. Die kleinen Encoder wie laya sind die schnellsten, fallen bei schwierigeren Fragen aber weit hinter Jev zurück. Die Startseite listet die Genauigkeit und Geschwindigkeit jedes Modells auf. Einen unabhängigen Vergleich offener Entscheidungsmodelle mit Jev, bei Genauigkeit und Kalibrierung, bietet der Decision Index. Wenn du gelabelte Daten für eine feste Aufgabe hast, schlägt ein darauf feinabgestimmtes Modell gewöhnlich jedes allgemeine.

Wie schnell ist es?

Eine Entscheidung ist ein einziger Vorwärtsdurchlauf. End-to-End über die HTTP-API auf einer RTX 4090 gemessen dauert die mediane Anfrage mit fünf Fragen 8 ms mit laya:multilingual und 10 ms mit laya:en (fp16), 15 ms mit gliclass, 20 ms mit nli und 89 ms mit winnow:e4b. Eine einzelne Frage dauert bei den Encodern 8–11 ms. Die größeren Decoder brauchen länger: kev:4b 354 ms, decider:4b 520 ms.

Brauche ich eine GPU?

Nein. Ollaya läuft auf der CPU und nutzt unter x86-64-Linux und Windows eine NVIDIA-GPU mit Treiber R525 oder neuer, wenn eine vorhanden ist (CUDA-13-Bibliotheken ab R580, davor CUDA 12). Die Installationsskripte laden die CUDA-Bibliotheken nur herunter, wenn sie eine GPU finden. Die Windows- und Linux-Desktop-Apps enthalten keine CUDA-Bibliotheken: Für sich allein führen sie Modelle auf der CPU aus; wenn zusätzlich die Kommandozeile mit ihren GPU-Bibliotheken installiert ist (und genauso aktuell ist wie die App), startet die App den Server aus dieser Installation, die die GPU nutzt. GGUF-Modelle wie winnow laufen auf llama.cpp, das auch die GPU von Apple-Silicon-Macs nutzt (Metal); ihre Gleichwertigkeit wurde auf CUDA und der x86-64-CPU geprüft, noch nicht auf Metal. Sie sind große Sprachmodelle, daher macht eine GPU bei ihnen viel mehr aus als bei den Encoder-Modellen: Die gemessenen Geschwindigkeiten findest du auf der jeweiligen Modellseite. Auf einer Karte der Serien RTX 30, 40 oder 50 brauchen GGUF-Modelle nichts weiter. Auf älteren oder Data-Center-Karten (GTX-10-Serie, V100, T4, A100, H100) enthalten die CUDA-Bibliotheken von llama.cpp Code, den der Treiber beim ersten Einsatz kompiliert, was einen neueren Treiber erfordert: R570 oder neuer mit den CUDA-12-Bibliotheken und einen Treiber für CUDA 13.4 oder neuer mit den CUDA-13-Bibliotheken. Mit einem älteren Treiber führt Ollaya GGUF-Modelle auf der CPU aus und protokolliert, warum; ollaya llama-devices zeigt die Compute-Capability jeder GPU und ob die Kernel darauf laufen.

Welche Plattformen werden unterstützt?

• Linux x86-64 und ARM64 mit glibc 2.38 oder neuer: Ubuntu 24.04, Debian 13, Fedora 39, RHEL 10 oder neuer.
• macOS 14 oder neuer auf Apple Silicon. laya und nli:modernbert-large laufen über MLX auf der Apple-GPU, 2- bis 3-mal schneller als auf der CPU; die übrigen Modelle laufen auf der CPU.
• Docker: ghcr.io/ollaya-dev/ollaya für linux/amd64 und linux/arm64 sowie :cuda für NVIDIA-GPUs (:cuda12 für Host-Treiber älter als R580). Verwende es auch auf älteren Linux-Distributionen.
• Windows 10 und 11 auf 64-Bit-x86-PCs: die Desktop-App und irm https://ollaya.dev/install.ps1 | iex für die Kommandozeile, die ebenfalls eine NVIDIA-GPU nutzt (installiere beides, dann nutzt der Server der App sie auch). WSL 2 mit dem Linux-Installer funktioniert ebenfalls.
• Die Desktop-App läuft auf allen drei Plattformen: Siehe Download.

Verlassen meine Daten meinen Rechner?

Nein. Der Server hört standardmäßig auf 127.0.0.1:11435 und führt die Modelle lokal aus. Das Netzwerk wird nur zum Herunterladen von Modellen verwendet. Zustände und Fragen werden niemals protokolliert.

Warum Port 11435?

Er liegt neben Ollamas Standardport 11434, sodass beide nebeneinander laufen können.

Wie werden die Wahrscheinlichkeiten kalibriert?

Mit Temperatur-Skalierung pro Fragetyp und Optionsanzahl, die mit jedem Modell ausgeliefert wird. Für Schwellenwerte, auf die du dich verlässt, passe die Temperaturen an deinen eigenen gelabelten Daten neu an und backe sie mit einem Modelfile ein.

Gibt es einen MCP-Server oder einen Agent Skill?

Beides. ollaya mcp stellt die lokalen Modelle Claude Code, Claude Desktop, Cursor und anderen MCP-Clients bereit (claude mcp add ollaya -- ollaya mcp), und das Skill ollaya-decisions bringt Agenten bei, wann und wie sie sie verwenden. Siehe Agents.

Wie aktualisiere ich es?

Führe ollaya update aus. Es sucht die neueste Version und führt, wenn eine neuere existiert, das Installationsskript erneut aus und installiert an denselben Ort, wodurch deine Modelle und die Diensteinstellungen erhalten bleiben. ollaya update --check teilt dir nur mit, ob ein Update existiert. Die Desktop-App wird als Ganzes aktualisiert: Installiere die neue Version von Download. In Docker lädst du das neue Image herunter.

Wie deinstalliere ich es?

Unter Linux, nachdem das Installationsprogramm den Dienst eingerichtet hat:

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

Bei einer Installation ohne root (in ~/.local) lösche ~/.local/bin/ollaya, ~/.local/lib/ollaya, ~/.local/share/doc/ollaya und ~/.local/share/ollaya sowie die Modelle in ~/.ollaya.

Welche Lizenz gilt?

Ollaya ist Apache-2.0. Modelle haben ihre eigenen Lizenzen: laya, decider, kev, decision, qwen3guard, gliclass, von, winnow, jevk5, clm und nli:modernbert-large sind Apache-2.0, und nli:deberta-v3-large ist MIT.