Ein 27-Milliarden-Parameter-Modell mit 262.144 Token Kontext auf einer einzelnen Consumer-Grafikkarte, mit 5,4 GB VRAM übrig
Stand: 24.09.2026. Alle Zahlen sind auf dem unten genannten System gemessen, nicht aus Datenblättern übernommen.
Worum es geht
Goose ist ein quelloffener KI-Agent (Desktop-App plus CLI): Er bearbeitet Dateien, führt Shell-Befehle aus und nutzt MCP-Werkzeuge. Normalerweise hängt so etwas an einer Cloud-API. Hier läuft alles lokal.
Ternary Bonsai 2 27B ist ein ternär quantisiertes Modell von Prism ML: nahezu alle Gewichte sind auf drei Werte reduziert (−1, 0, +1), rund 1,585 Bit statt 16. Basis ist Qwen3.8-27B. Das Ergebnis: ein 27B-Modell in einer 7,2-GB-Datei.
Gemessene Werte
| Kennzahl | Wert |
|---|---|
| VRAM belegt | 18.644 MiB von 24.564 MiB |
| VRAM frei | 5.495 MiB |
| Kontext | 262.144 Token (natives Maximum) |
| Ausgabe | 79–81 Token/s |
| Prompt-Verarbeitung | 220–620 Token/s |
| Ladezeit | 3,5 Sekunden |
Testsystem: RTX 4090 24 GB, Ryzen 9 7950X3D, 128 GB DDR5, Windows 11 Pro.
Die Herstellerangabe zur Qualität lautet 98,2 % der FP16-Leistung. Das ist deren Zahl. Was ich selbst geprüft habe: flüssiges, fachlich sauberes Deutsch und mehrstufige Werkzeugketten, die zuverlässig durchlaufen. Was ich nicht geprüft habe: Programmierqualität und ob das Modell bei 200.000 Token noch zuverlässig auf frühe Informationen zugreift.
Voraussetzungen
- NVIDIA-Grafikkarte mit mindestens 12 GB VRAM (24 GB für den vollen Kontext), aktueller Treiber
- Windows 10/11, rund 20 GB freier Speicherplatz
- Keine Admin-Rechte nötig
Mit 12 GB VRAM funktioniert es ebenfalls, dann mit kleinerem Kontext, siehe die VRAM-Tabelle am Ende.
Schritt 1: Goose in der CUDA-Variante installieren
Hier liegt die erste Falle. Das Goose-Release enthält zwei Windows-Pakete:
| Datei | Bedeutung |
|---|---|
| `Goose-win32-x64.zip` | Standard, das eingebaute llama.cpp läuft nur auf der CPU |
| `Goose-win32-x64-cuda.zip` | GPU-Variante |
Für dieses HowTo brauchst du die CUDA-Variante nicht zwingend, der Agent läuft über einen externen Server. Wenn du aber Gooses eingebaute Modellverwaltung mit GPU nutzen willst, nimm sie.
Achtung bei eigenen Installationsskripten: Ein Suchmuster wie `Goose-win32-x64.*\.zip$` passt auf beide Dateien. Welche gewinnt, entscheidet die Sortierung der GitHub-Antwort. Vergleiche exakt auf den Dateinamen.
Download: [https://github.com/aaif-goose/goose/releases](https://github.com/aaif-goose/goose/releases)
Entpacken nach `%LOCALAPPDATA%\Programs\Goose`.
Wenn Goose nicht startet
Meldung: *„The backend server failed to start … Process exited with code 3221225781“*
`3221225781` ist hexadezimal `0xC0000135`, STATUS_DLL_NOT_FOUND. Der CUDA-Build verlangt die CUDA-12-Laufzeit, die ein normaler Treiber nicht mitbringt. Vier DLLs müssen neben `resources\bin\goose.exe` liegen:
```
cudart64_12.dll
cublas64_12.dll
cublasLt64_12.dll (wird von cublas64_12.dll nachgezogen)
curand64_10.dll
```
`nvcuda.dll` kommt mit dem Treiber und ist bereits da.
Bezugsquelle, die ich getestet habe: Wer Ollama installiert hat, findet drei davon unter
```
%LOCALAPPDATA%\Programs\Ollama\lib\ollama\cuda_v12\
```
`curand64_10.dll` fehlt dort. Die gibt es als offizielles NVIDIA-Paket:
```
https://developer.download.nvidia.com/compute/cuda/r….19-archive.zip
```
Entpacken, `bin\curand64_10.dll` herauskopieren. Alternativ liefert derselbe Redist-Server auch `libcublas` und `cuda_cudart`, diesen Weg habe ich nicht getestet, er sollte aber sauberer sein, weil alles aus einer CUDA-Version stammt.
Prüfen mit:
```
"%LOCALAPPDATA%\Programs\Goose\resources\bin\goose.exe" --version
```
Kommt eine Versionsnummer, ist es in Ordnung. Kommt gar nichts, fehlt noch eine DLL.
Schritt 2: llama.cpp in der PrismML-Fassung
Wichtig: Bonsai läuft nicht mit normalem llama.cpp, LM Studio oder Ollama. Die Quantisierungsformate `PTQ1_0` und `PQ2_0` (GGML-Typ 143 und 142) sind bis heute nicht im Hauptprojekt. Ein entsprechender Pull Request wurde am 22.09.2026 ohne Übernahme geschlossen; Prism MLs eigener Entwickler schrieb dort, die Typen blieben womöglich dauerhaft im Fork.
Besonders tückisch: Eine `Q2_0`-Datei lädt auf einem Standard-Build ohne Fehlermeldung und liefert dann Kauderwelsch, weil die Hadamard-Transformation fehlt. Ein stiller Fehlschlag.
Download der fertigen Windows-Binaries: [https://github.com/PrismML-Eng/llama.cpp/releases](https://github.com/PrismML-Eng/llama.cpp/releases)
Getestete Fassung: `prism-b10709-9a9394a`. Zwei Archive:
```
llama-prism-b10709-9a9394a-bin-win-cuda-13.3-x64.zip 145 MB
cudart-llama-bin-win-cuda-13.3-x64.zip 391 MB
```
Beide in denselben Ordner entpacken, zum Beispiel `C:\KI\llama-prism\`. Für ältere Treiber gibt es dieselben Archive in der Fassung `cuda-12.4`.
Schritt 3: Das Modell
Von [https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf](https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf)
| Datei | Größe | Anmerkung |
|---|---|---|
| `Ternary-Bonsai-2-27B-PQ2_0.gguf` | 7,21 GB | Empfehlung, schnelleres Prefill |
| `Ternary-Bonsai-2-27B-PTQ1_0.gguf` | 5,95 GB | kleiner, gleiche Decode-Geschwindigkeit |
| `Ternary-Bonsai-2-27B-mmproj-*.gguf` | ~0,9 GB | nur für Bildverarbeitung nötig |
Für Agentenarbeit mit großen Systemprompts ist das Prefill der Engpass, deshalb `PQ2_0`. Ablegen zum Beispiel unter `C:\KI\models\`.
Schritt 4: Server starten
Eine `.bat` im übergeordneten Ordner, damit man nicht jedes Mal tippt:
```bat
@echo off
title Bonsai 2 27B - llama-server
set "HIER=%~dp0"
set "SERVER=%HIER%llama-prism\llama-server.exe"
set "MODELL=%HIER%models\Ternary-Bonsai-2-27B-PQ2_0.gguf"
netstat -ano -p tcp | findstr /C:"127.0.0.1:8080" | findstr /C:"LISTENING" >nul
if not errorlevel 1 (
echo Auf Port 8080 laeuft bereits etwas.
pause
exit /b 0
)
"%SERVER%" -m "%MODELL%" -a bonsai -c 262144 --host 127.0.0.1 --port 8080 ^
-ngl 99 -fa on --reasoning off -ctk q8_0 -ctv q8_0 ^
--temp 0.5 --top-p 0.85 --top-k 20 --min-p 0
pause
```
Die Optionen im Einzelnen:
| Option | Wirkung |
|---|---|
| `-a bonsai` | Modellname für die API. Muss zum Namen in Gooses Konfiguration passen, sonst findet Goose es nicht |
| `-c 262144` | Kontextgröße, hier das native Maximum |
| `-ngl 99` | Alle Layer auf die GPU |
| `-fa on` | Flash Attention |
| `-ctk q8_0 -ctv q8_0` | KV-Cache quantisiert, spart rund 6 GB |
| `--reasoning off` | Denkblock aus. Für Agenten wichtig, sonst grübelt das Modell vor jedem Werkzeugaufruf |
| Sampling-Werte | Aus der PrismML-Dokumentation |
Ohne `-ctk q8_0 -ctv q8_0` belegt derselbe Kontext 24.107 MiB statt 18.644, die Karte wäre randvoll. Tempo und Textqualität leiden nach meinen Messungen nicht darunter.
Fenster offen lassen, solange Goose das Modell nutzt. Prüfen im Browser: [http://127.0.0.1:8080/health](http://127.0.0.1:8080/health) muss `{"status":"ok"}` liefern.
Schritt 5: Goose anbinden
Goose spricht das OpenAI-Format. Die Konfigurationsdatei liegt unter
```
%APPDATA%\Block\goose\config\config.yaml
```
Goose vorher schließen, es schreibt die Datei beim Beenden zurück und überschreibt Änderungen sonst.
```yaml
providers:
openai:
enabled: true
model: bonsai
configured: true
active_provider: openai
OPENAI_HOST: http://127.0.0.1:8080
OPENAI_BASE_PATH: v1/chat/completions
OPENAI_API_KEY: local-no-auth
```
Der Schlüssel ist ein Platzhalter, llama-server prüft nichts, aber Goose will das Feld gefüllt sehen. Der Wert bei `model:` muss mit dem `-a`-Alias des Servers übereinstimmen.
Alternativ über die Oberfläche: Einstellungen → Anbieter → OpenAI konfigurieren, dort den Host auf `http://127.0.0.1:8080` umbiegen.
Schritt 6: Das Kontextlimit, die zweite Falle
Nach dem Start zeigt Goose 128k an, obwohl der Server 262k bereitstellt.
Der Grund: Goose fragt beim Provider `/v1/models` ab, um das Kontextfenster zu ermitteln. llama-server meldet dort aber keine Kontextlänge. Goose fällt daher auf seinen eingebauten Wert von 131.072 zurück.
`GOOSE_CONTEXT_LIMIT` hilft nicht, die Variable wird bei diesem Aufbau ignoriert, weder in der `config.yaml` noch als Umgebungsvariable. Nachweis: Mit `GOOSE_CONTEXT_LIMIT=2000` lief Goose völlig normal durch, obwohl allein der Systemprompt ein Vielfaches davon umfasst.
Das ist kein Fehler, der etwas kaputt macht, Goose bleibt schlicht unter dem, was der Server könnte. Wer die Kapazität nutzen will, trägt sie direkt in Gooses Datenbank ein:
```
%APPDATA%\Block\goose\data\sessions\sessions.db
```
Goose schließen, Datenbank sichern, dann:
```sql
-- Vorher den vorhandenen Schlüssel auslesen:
SELECT inventory_key FROM provider_inventory_entries WHERE provider_id='openai';
INSERT OR REPLACE INTO provider_inventory_models
(inventory_key, ordinal, model_id, name, family, context_limit, reasoning, recommended)
VALUES ('<key>', 0, 'bonsai', 'bonsai', NULL, 262144, 0, 1);
```
Existiert noch kein Eintrag für `openai`, muss zuerst eine Zeile in `provider_inventory_entries` angelegt werden (Spalten: `inventory_key`, `provider_id`, `provider_family`, `last_updated_at`).
Danach zeigt Goose `0 / 262k` und verdichtet automatisch bei 80 %, also rund 209.700 Token, mit über 52.000 Token Abstand zur Servergrenze. Ein Überlauf ist damit ausgeschlossen.
Dass dieser Eintrag dauerhaft hält, ist über einen Neustart samt Inventar-Aktualisierung bestätigt. Goose überschreibt ein vorhandenes `context_limit` offenbar nicht, wenn der Provider keines meldet. Auf Dauer würde ich es trotzdem gelegentlich kontrollieren, es ist ein Eingriff an der Anwendung vorbei.
## VRAM je nach Kontextgröße
Gemessen auf 24.564 MiB. Mit `q8_0`-KV kostet Kontext rund 37 MiB je 1.000 Token.
| Kontext | KV-Typ | belegt | frei |
|---|---|---|---|
| 32.768 | f16 | 11.454 MiB | 12.685 MiB |
| 131.072 | q8_0 | 13.129 MiB | 11.010 MiB |
| 262.144 | q8_0 | 18.644 MiB | 5.495 MiB |
| 262.144 | f16 | 24.107 MiB | 32 MiB |
Die letzte Zeile zeigt, warum die KV-Quantisierung nicht optional ist: Ohne sie bleiben 32 MiB übrig, und jede andere GPU-Anwendung bringt das Ganze zum Absturz.
Wer auf 12-GB-Karten unterwegs ist, fährt mit 32.768 oder 65.536 Kontext und `q8_0`.
## Häufige Fehler
„null result from llama cpp“ in Gooses eingebautem Modell-Provider
Das trifft Qwen3.8-GGUFs von Unsloth. Diese Dateien deklarieren einen MTP-Kopf (`nextn_predict_layers`), dessen Gewichte in einer separaten Datei liegen, die Goose nicht mitlädt. Die genaue Meldung lautet `missing tensor 'blk.64.ssm_conv1d.weight'`. Ausweichen auf Qwen3.5, oder über Ollama gehen, dessen Paket enthält den Zusatzteil.
Exit-Code 3221225781 beim Goose-Start
Fehlende CUDA-DLLs, siehe Schritt 1.
„request (N tokens) exceeds the available context size“
Der Serverkontext liegt unter dem, was Goose verwendet. Server hochsetzen oder Gooses Verdichtungsschwelle senken.
Modell antwortet mit Kauderwelsch
Kein PrismML-Build. Ein Standard-llama.cpp lädt manche dieser Dateien kommentarlos und rechnet falsch.
Goose findet das Modell nicht
`-a`-Alias und `model:` in der `config.yaml` stimmen nicht übereinstimmen.
Einordnung
Was für diesen Aufbau spricht: ein 27B-Modell mit vollem Kontext auf einer einzelnen Consumer-Karte, rund 80 Token/s, alles lokal, keine laufenden Kosten, keine Daten außer Haus.
Was man wissen sollte: Man hängt an einem Fork. Prism ML hat angekündigt, die Formate möglicherweise nicht ins Hauptprojekt zu bringen. Schläft das Projekt ein, fehlt die Laufzeit für die Modelldateien. Ein Ausweichmodell über Ollama daneben zu haben, ist keine schlechte Idee.
Offen bleibt bei mir die Programmierqualität, Bonsai basiert auf einem Allround-Modell, nicht auf einem Coder. Für deutsche Texte und Werkzeugketten hat es mich überzeugt; für PHP oder Python habe ich es noch nicht ernsthaft getestet. Wer darauf abzielt, sollte gegen ein Coder-Modell gegentesten.
_Rückfragen gern im Thread. Fehler bitte melden, ich pflege den Beitrag nach._
