Bonsai 2 mit llama.cpp-Fork

Bevor wir mit der Installation beginnen, schauen wir uns zunächst an, was Bonsai 2 besonders macht und warum wir dafür einen anderen Weg als bei der normalen llama.cpp-Installation verwenden.

Was ist Bonsai 2?

Bonsai 2 ist ein 27B-Language-Model von Prism ML. Das Modell basiert auf Qwen3.8-27B und verwendet eine ternäre Gewichtsrepräsentation. Dadurch unterscheiden sich die benötigten Modellformate und der Speicherbedarf deutlich von klassischen GGUF-Modellen mit beispielsweise Q4- oder Q8-Quantisierung.

Für Bonsai 2 stehen unter anderem die speziellen Formate PTQ1_0 und PQ2_0 zur Verfügung.

Gerade diese speziellen Formate sind der Grund, warum wir für Bonsai 2 nicht einfach die normale llama.cpp-Installation aus der vorherigen Anleitung verwenden können.

Warum verwenden wir Bonsai 2?

Bonsai 2 ist für unseren Aufbau besonders interessant, weil wir mit einer RTX 3060 mit 12 GB VRAM bewusst eine vergleichsweise kleine GPU verwenden.

Das 27B-Modell lässt sich durch die spezielle ternäre Gewichtsrepräsentation sehr kompakt aufbauen. Dadurch können wir ein Modell dieser Größenordnung auch auf einer GPU betreiben, bei der klassische Quantisierungen eines 27B-Modells deutlich mehr Speicher benötigen würden.

Bonsai 2 verwendet eine spezielle ternäre Darstellung der Modellgewichte. Dabei werden die Gewichte vereinfacht mit drei Zuständen dargestellt: -1, 0 und +1. Dadurch kann das 27B-Modell besonders kompakt gespeichert und ausgeführt werden.

Ein weiterer wichtiger Punkt ist der Kontext.

Für einen späteren KI-Agenten oder andere Anwendungen, die unser lokales Modell über eine API ansprechen, kann ein größerer Kontext sehr interessant sein. Hier stoßen 12 GB VRAM allerdings relativ schnell an Grenzen, da neben den Modellgewichten auch der KV-Cache und weitere Daten Speicher benötigen.

Mit einer 12-GB-GPU ist ein größerer Kontext deshalb zwar möglich, aber man muss die verfügbaren Ressourcen genau im Auge behalten und die Konfiguration entsprechend anpassen.

Genau diese Kombination macht Bonsai 2 für unseren Aufbau interessant:

RTX 3060 12 GB VRAM -> Bonsai 2 27B -> kompakte ternäre Gewichte ->Grundlage für spätere Agenten- und API-Anwendungen

Wir wollen damit also nicht einfach das größtmögliche Modell auf unserer Hardware betreiben. Vielmehr geht es darum, aus begrenztem VRAM möglichst viel Modell und Kontext herauszuholen.

Voraussetzungen

Wir bauen diese Anleitung auf den vorherigen Schritten auf. Die grundlegende Infrastruktur muss daher bereits vorhanden sein:

Proxmox VE mit einem LXC-Container
NVIDIA-GPU mit funktionierendem Zugriff aus dem LXC
CUDA-Unterstützung
die grundlegende NVIDIA- und LXC-Konfiguration aus den vorherigen Anleitungen

Die GPU sollte im LXC bereits mit

nvidia-smi

erreichbar sein.

Docker wird für Bonsai 2 nicht benötigt. Die llama.cpp-Fork wird direkt im Linux-LXC heruntergeladen, kompiliert und anschließend ausgeführt.

Für diese Anleitung beginnen wir nicht mit einem komplett neuen LXC. Stattdessen verwenden wir das Backup unseres CT 101, den wir bereits für die vorherige llama.cpp-Anleitung eingerichtet haben.

Dadurch können wir die bereits getestete NVIDIA- und CUDA-Umgebung übernehmen und uns in dieser Anleitung auf Bonsai 2 und die benötigte llama.cpp-Fork konzentrieren.

⚠️ Wichtig: Eine RTX 3060 hat nur 12 GB VRAM. Läuft in CT 101 noch das Modell aus der vorherigen Anleitung, ist der Speicher belegt, und Bonsai 2 startet in CT 102 nicht. Stoppe es zuerst:

pct enter 101
cd /opt/llamacpp && docker compose down
exit

Prüfe auf dem Host mit nvidia-smi, dass der VRAM wieder frei ist.

LXC-Container aus dem Backup wiederherstellen
Zunächst stellen wir das Backup von CT 101 über die Proxmox-Weboberfläche wieder her.

Wähle dazu:

Datacenter → Storage „local (pve)“ → Backup → Restore

Wähle das entsprechende CT-101-Backup aus und stelle es als neuen Container wieder her.
Für unseren Test verwenden wir beispielsweise:

CT ID: 102
Hostname: bonsai-2

Die genaue CT-ID kann natürlich angepasst werden, wenn sie auf deinem System bereits vergeben ist.
Nach der Wiederherstellung starten wir den neuen Container.

Netzwerk konfigurieren

Da wir einen neuen Container erstellt haben, benötigt dieser eine eigene IP-Adresse.
Wähle dazu:
LXC 102 → Network → Edit → IPv4/CIDR

Ändere die Adresse beispielsweise auf:

192.168.178.136/24

Wichtig: Die eingetragene IP-Adresse darf nicht bereits von einem anderen Gerät im Netzwerk verwendet werden.
Damit ist der Container für die weitere Installation vorbereitet.

NVIDIA-GPU prüfen
Da wir den Container aus unserem bestehenden Backup wiederhergestellt haben, sollte die bereits konfigurierte GPU-Anbindung ebenfalls vorhanden sein.

Zunächst starten wir den neuen LXC-Container CT 102.
Anschließend öffnen wir auf dem Proxmox-Host eine Shell und wechseln mit folgendem Befehl in den Container:

pct enter 102

Wir befinden uns jetzt direkt in der Shell des Containers.
Dort führen wir folgenden Befehl aus:

nvidia-smi

Wenn die RTX 3060 angezeigt wird, funktioniert der GPU-Zugriff im wiederhergestellten Container.

Hinweis: Sollte nvidia-smi nach der Wiederherstellung nicht funktionieren, sollte zunächst die NVIDIA- und LXC-Konfiguration aus der vorherigen Anleitung überprüft werden. An dieser Stelle nehmen wir keine Änderungen an der GPU-Passthrough-Konfiguration vor.

Jetzt richten wir die eigentliche Bonsai-2-Umgebung ein.

Für Bonsai 2 benötigen wir die speziell angepasste llama.cpp-Fork von PrismML. Sie enthält die Unterstützung für die speziellen Bonsai-2-Modelle und deren Modellformate.

Benötigte Pakete installieren

Zunächst aktualisieren wir die Paketlisten und installieren die benötigten Werkzeuge für den Build:

apt update
apt install -y git cmake build-essential curl ca-certificates libcurl4-openssl-dev ninja-build wget

Dabei werden unter anderem folgende Komponenten installiert:

• Git – zum Herunterladen der PrismML-Fork
• CMake – zur Konfiguration des Builds
• build-essential – Compiler und grundlegende Build-Werkzeuge
• Ninja – Build-System für die Kompilierung
• curl / wget – für Downloads
• ca-certificates – für sichere HTTPS-Verbindungen
• libcurl4-openssl-dev – Entwicklungsbibliothek für die Curl-Unterstützung

CUDA Toolkit von NVIDIA installieren

Für die CUDA-Unterstützung benötigen wir zusätzlich das CUDA Toolkit. Es enthält unter anderem nvcc, den CUDA-Compiler, mit dem llama.cpp für die NVIDIA-GPU kompiliert wird.

Wir verwenden dafür direkt das offizielle NVIDIA-Repository.

Zunächst laden wir das Repository-Paket herunter:

wget https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb

Anschließend installieren wir den Repository-Schlüssel:

dpkg -i cuda-keyring_1.1-1_all.deb

Danach aktualisieren wir die Paketlisten:

apt update

Jetzt installieren wir das CUDA Toolkit:

apt install -y cuda-toolkit

Damit der CUDA-Compiler anschließend direkt über die Kommandozeile erreichbar ist, setzen wir den CUDA-Pfad:

echo 'export PATH=/usr/local/cuda/bin:$PATH' >> /root/.bashrc
source /root/.bashrc

Anschließend prüfen wir, ob der CUDA-Compiler verfügbar ist:

nvcc --version

Hier sollte die installierte CUDA-Version angezeigt werden. In unserem Testsystem wurde CUDA 13.4 installiert.

PrismML llama.cpp-Fork herunterladen

Nun laden wir die offizielle llama.cpp-Fork von PrismML herunter. Dabei verwenden wir den dafür vorgesehenen prism-Branch:

cd /opt
git clone https://github.com/PrismML-Eng/llama.cpp.git

Anschließend wechseln wir in das neue Verzeichnis:

cd /opt/llama.cpp

llama.cpp mit CUDA kompilieren

Jetzt wird die PrismML-Fork mit CUDA-Unterstützung kompiliert. Dafür verwenden wir CMake mit Ninja.

Der CUDA-Compiler liegt unter /usr/local/cuda/bin/nvcc. Zusätzlich legen wir die CUDA-Architektur unserer RTX 3060 fest, sie verwendet die Architektur 86. Bei anderen GPUs nimmst du den Wert aus der Tabelle weiter unten.

cmake -B build -G Ninja \
  -DGGML_CUDA=ON \
  -DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc \
  -DCMAKE_CUDA_ARCHITECTURES=86 \
  -DCMAKE_BUILD_TYPE=Release

Anschließend starten wir die Kompilierung:

cmake --build build --config Release -j$(nproc)

Der Build kann je nach CPU einige Zeit dauern.

CUDA-Build überprüfen

Nach erfolgreicher Kompilierung prüfen wir zunächst, welche Geräte die neu erstellte llama-cli erkennt:

/opt/llama.cpp/build/bin/llama-cli --list-devices

Bei einer korrekt eingerichteten RTX 3060 sollte beispielsweise Folgendes angezeigt werden:

Available devices:
CUDA0: NVIDIA GeForce RTX 3060

Damit ist sichergestellt, dass die PrismML-Fork mit aktivem CUDA-Backend kompiliert wurde und auf die NVIDIA-GPU zugreifen kann.

Verzeichnis für das Bonsai-2-Modell erstellen

Zunächst legen wir einen eigenen Speicherort für die Modelldateien an:

mkdir -p /opt/llama.cpp/models
cd /opt/llama.cpp/models

So bleiben die Modelldateien getrennt vom eigentlichen Build der PrismML llama.cpp-Fork.

Hugging Face CLI installieren

Das Bonsai-2-Modell wird über Hugging Face bereitgestellt. Für den Download verwenden wir die offizielle Hugging Face CLI hf.

Da wir Debian 13 verwenden, installieren wir die CLI nicht direkt mit pip3. Debian schützt die systemweite Python-Installation vor solchen Änderungen. Stattdessen verwenden wir pipx, das die Anwendung in einer eigenen Umgebung installiert.

Zunächst installieren wir pipx:

apt install -y pipx

Anschließend installieren wir die Hugging Face CLI:

pipx install "huggingface_hub[cli]"

Die ausführbare Datei hf wird dabei unter /root/.local/bin installiert. Damit sie direkt über die Kommandozeile erreichbar ist, ergänzen wir dieses Verzeichnis dauerhaft im PATH:

echo 'export PATH="/root/.local/bin:$PATH"' >> /root/.bashrc
source /root/.bashrc

Anschließend prüfen wir die Installation:

hf --version

Wenn eine Versionsnummer angezeigt wird, ist die Hugging Face CLI einsatzbereit.

Bonsai 2 von Hugging Face herunterladen

Für diese Anleitung verwenden wir das Modell:

prism-ml/Ternary-Bonsai-2-27B-gguf

Bonsai 2 27B verwendet ternäre Gewichte. Für die GGUF-Version stehen unter anderem die Packings PTQ1_0 und PQ2_0 zur Verfügung.

Für unseren ersten Test verwenden wir PQ2_0. Dieses Modellformat benötigt die PrismML-Version von llama.cpp und wird unter anderem für CUDA unterstützt.

Die Modelldatei laden wir direkt in unser zuvor erstelltes Modellverzeichnis:

hf download prism-ml/Ternary-Bonsai-2-27B-gguf \
  Ternary-Bonsai-2-27B-PQ2_0.gguf \
  Ternary-Bonsai-2-27B-mmproj-BF16.gguf \
  --local-dir /opt/llama.cpp/models

Der Download kann je nach Internetverbindung einige Zeit dauern.

Installation überprüfen

Nach dem Download prüfen wir, ob die Modelldatei vorhanden ist:

ls -lh /opt/llama.cpp/models/Ternary-Bonsai-2-27B-PQ2_0.gguf

Die Datei liegt anschließend unter:

/opt/llama.cpp/models/Ternary-Bonsai-2-27B-PQ2_0.gguf

In unserem Testsystem ist die Datei rund 6,8 GB groß.

Damit ist die PrismML-Fork kompiliert, die CUDA-Unterstützung geprüft und das Bonsai-2-Modell heruntergeladen.

Im nächsten Schritt starten wir Bonsai 2 erstmals mit der kompilierten PrismML-Version von llama.cpp und prüfen die Ausführung auf der NVIDIA-GPU.

Nachdem die PrismML llama.cpp-Fork kompiliert und das Bonsai-2-Modell heruntergeladen wurde, können wir den ersten Start durchführen.

Zunächst verwenden wir bewusst eine einfache Konfiguration. So können wir feststellen, ob die Fork das Modell korrekt lädt und die NVIDIA-GPU verwendet, bevor wir weitere Parameter anpassen.
Bonsai 2 mit llama-cli starten

Wir wechseln zunächst in das llama.cpp-Verzeichnis:

cd /opt/llama.cpp

Anschließend starten wir Bonsai 2 mit llama-cli:

Für den ersten Test verwenden wir eine Kontextgröße von 65.536 Tokens. Dabei verzichten wir zunächst bewusst auf eine Komprimierung des KV-Caches. Bei unserer RTX 3060 mit 12 GB VRAM funktioniert diese Konfiguration zuverlässig.

./build/bin/llama-cli \
-m /opt/llama.cpp/models/Ternary-Bonsai-2-27B-PQ2_0.gguf \
-ngl 99 \
-c 65536 \
-p "Erkläre kurz, was ein Local-AI-Server ist."

Je nach Version bleibt llama-cli nach der Antwort im Chat-Modus. Beende es mit Strg + C.

Was passiert beim Start?

Beim Start lädt llama.cpp zunächst das Modell und bereitet es für die Ausführung vor.

Die Parameter

• m /opt/llama.cpp/models/Ternary-Bonsai-2-27B-PQ2_0.gguf → gibt an, welches Modell verwendet werden soll.
• ngl 99 → weist llama.cpp an, möglichst viele Modell-Layer auf die GPU auszulagern.
• c 65536 → setzt die Kontextgröße auf 65.536 Tokens.
• p → gibt den ersten Prompt vor, mit dem wir das Modell testen.

Wenn das Modell korrekt geladen wurde, sollte llama.cpp Informationen zum Modell und zur verwendeten Hardware anzeigen und anschließend eine Antwort erzeugen.

An diesem Punkt wissen wir, dass die grundlegende Installation funktioniert und Bonsai 2 auf unserer NVIDIA-GPU ausgeführt werden kann.

GPU-Auslastung prüfen

Während das Modell läuft, können wir in einem zweiten Terminal auf dem Proxmox-Host prüfen ob die Modelgewichte in den VRAM geladen werden.

nvtop

Dabei sollte die RTX 3060 als verwendete GPU angezeigt werden.
Damit können wir überprüfen, ob Bonsai 2 tatsächlich auf der NVIDIA-GPU ausgeführt wird.
An diesem Punkt wissen wir, dass die grundlegende Installation funktioniert.

Noch optimieren wir nichts. In den nächsten Schritten können wir die Kontextgröße, GPU-Auslastung und Geschwindigkeit genauer untersuchen und anschließend die Konfiguration an unsere Hardware anpassen.

Vom CLI zum Server

llama-cli eignet sich zunächst sehr gut für unseren Funktionstest, weil wir damit ohne zusätzliche Komponenten überprüfen können, ob das Modell korrekt geladen und ausgeführt wird.

Für den späteren Betrieb möchten wir Bonsai 2 jedoch als Server betreiben. Dafür verwenden wir anschließend llama-server.

Damit können wir Bonsai 2 beispielsweise über eine Weboberfläche oder eine API erreichen und später auch andere Anwendungen damit verbinden.

Der Wechsel vom ersten CLI-Test zum Server erfolgt im weiteren Verlauf der Anleitung.

Nachdem Bonsai 2 erfolgreich gestartet wurde, können wir nun die Einstellungen an unsere RTX 3060 mit 12 GB VRAM anpassen.

Beim ersten Funktionstest haben wir mit 65.536 Tokens Kontext gearbeitet. Für unseren weiteren Betrieb möchten wir den verfügbaren Speicher besser ausnutzen und den Kontext auf 131.072 Tokens erhöhen.

KV-Cache optimieren

Mit zunehmender Kontextgröße steigt auch der Speicherbedarf des KV-Caches. Um hier VRAM einzusparen, quantisieren wir den K- und V-Cache mit q4_0:

-ctk q4_0 \
-ctv q4_0

Damit können wir Bonsai 2 auf unserer RTX 3060 mit 131.072 Tokens Kontext betreiben.

Unsere getestete Konfiguration sieht damit so aus:

./build/bin/llama-cli \
  -m /opt/llama.cpp/models/Ternary-Bonsai-2-27B-PQ2_0.gguf \
  --mmproj /opt/llama.cpp/models/Ternary-Bonsai-2-27B-mmproj-BF16.gguf \
  -ngl 99 \
  -c 131072 \
  -ctk q4_0 \
  -ctv q4_0 \
  -p "Erkläre kurz, was ein Local-AI-Server ist."

Der gemessene VRAM-Verbrauch liegt bei ungefähr 9,6 GB ohne Vision-Modell. Das Vision-Modell benötigt zusätzlich ca. 1 GB. Ich habe es diesmal mitgestartet, da wir damit auch Bilder analysieren können.

Batch-Größe

Zusätzlich können wir mit -b und -ub die Verarbeitung beeinflussen.
-b legt die Batch-Größe fest, während -ub die Größe des tatsächlich gleichzeitig verarbeiteten Teil-Batches bestimmt.

Zum Beispiel:

-b 512 \
-ub 512

Größere Werte können die Verarbeitung beschleunigen, benötigen aber auch zusätzlichen VRAM. Deshalb sollten diese Werte immer passend zur vorhandenen Hardware getestet werden.

GPU-Auslastung und Geschwindigkeit

Während der Tests können wir mit

nvtop

die GPU-Auslastung und den VRAM-Verbrauch beobachten.

llama.cpp zeigt außerdem die Geschwindigkeit der Verarbeitung und Generierung in Tokens pro Sekunde an.

Bei unserem ersten Test mit Bonsai 2 PQ2_0 auf der RTX 3060 lagen wir beim Generieren bei ungefähr 36 Tokens pro Sekunde (kurzer Prompt, Kontext 131.072). Bei langen Eingaben sinkt die Geschwindigkeit meist.

Unsere getestete Konfiguration

Modell:       Bonsai 2 27B PQ2_0
GPU:          NVIDIA RTX 3060 12 GB
GPU-Offload:  -ngl 99
Kontext:      131.072 Tokens
K-Cache:      q4_0
V-Cache:      q4_0

Damit haben wir eine stabile Konfiguration für unsere Hardware gefunden.

Bonsai 2 im Vergleich zu einer klassischen Quantisierung

Um einzuordnen, was Bonsai 2 bringt, habe ich es mit zwei klassisch quantisierten Modellen verglichen. Alle drei liefen auf derselben RTX 3060 mit demselben Prompt. Muse-Glimmer ist dabei kein anderes Format desselben Modells, sondern ein eigenes Modell mit 30B Parametern.

So habe ich gemessen: Alle Modelle bekamen dieselbe Frage („Erkläre kurz, was ein Local-AI-Server ist.") und liefen auf derselben RTX 3060. Die Generierungsgeschwindigkeit zeigt llama.cpp am Ende der Antwort bzw. im Log an. Den VRAM habe ich mit nvtop bei geladenem Modell abgelesen. Die Prompt-Verarbeitung habe ich bewusst nicht verglichen, weil sie bei kurzen Prompts stark von der Prompt-Länge abhängt. Bonsai lief mit 131.072 Tokens Kontext, die beiden anderen mit 32.768. Das sind Einzelmessungen auf meinem System, keine Garantie für andere Konfigurationen.

Im nächsten Schritt wechseln wir von llama-cli zu llama-server und stellen Bonsai 2 als API bereit.

Nachdem wir Bonsai 2 getestet und die für unsere Hardware passende Konfiguration gefunden haben, richten wir nun einen dauerhaften Dienst ein.

Dafür verwenden wir llama-server zusammen mit systemd. Dadurch wird Bonsai 2 automatisch gestartet, sobald der LXC-Container gestartet wird.

llama-server testen

Bevor wir den systemd-Dienst erstellen, testen wir llama-server zunächst manuell.

cd /opt/llama.cpp

Anschließend starten wir den Server mit unserer getesteten Konfiguration:

./build/bin/llama-server \
  -m /opt/llama.cpp/models/Ternary-Bonsai-2-27B-PQ2_0.gguf \
  --mmproj /opt/llama.cpp/models/Ternary-Bonsai-2-27B-mmproj-BF16.gguf \
  -ngl 99 \
  -c 131072 \
  -ctk q4_0 \
  -ctv q4_0 \
  --jinja \
  --chat-template-kwargs '{"reasoning_effort":"medium"}' \
  --host 0.0.0.0 \
  --port 8080

Der Server sollte anschließend auf Port 8080 erreichbar sein.

Die Weboberfläche können wir im Browser über folgende Adresse aufrufen:

http://192.168.178.136:8080

Wenn die Weboberfläche angezeigt wird, beenden wir den Test zunächst mit Ctrl+C.

systemd-Dienst erstellen

Jetzt erstellen wir einen eigenen systemd-Dienst:

nano /etc/systemd/system/bonsai.service

Dort tragen wir Folgendes ein:

[Unit]
Description=Bonsai 2 llama.cpp Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/build/bin/llama-server \
  -m /opt/llama.cpp/models/Ternary-Bonsai-2-27B-PQ2_0.gguf \
  --mmproj /opt/llama.cpp/models/Ternary-Bonsai-2-27B-mmproj-BF16.gguf \
  -ngl 99 \
  -c 131072 \
  -ctk q4_0 \
  -ctv q4_0 \
  --jinja \
  --chat-template-kwargs '{"reasoning_effort":"medium"}' \
  --host 0.0.0.0 \
  --port 8080
Restart=on-failure
RestartSec=5
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

Die Datei speichern und anschließend systemd neu laden:

systemctl daemon-reload

Danach aktivieren und starten wir den Dienst:

systemctl enable --now bonsai.service

Status überprüfen

Mit folgendem Befehl können wir überprüfen, ob Bonsai 2 läuft:

systemctl status bonsai.service

Wenn der Dienst korrekt gestartet wurde, sollte dort active (running) angezeigt werden.

Die laufenden Ausgaben des Servers können wir ebenfalls direkt anzeigen:

journalctl -u bonsai.service -f

Mit Ctrl+C verlassen wir die Anzeige wieder.

Automatischer Start

Durch systemctl enable wird der Dienst automatisch beim Start des Containers aktiviert.

Damit müssen wir Bonsai 2 nach einem Neustart des LXC-Containers nicht mehr manuell starten.

Auch wenn llama-server unerwartet beendet wird, versucht systemd den Dienst nach fünf Sekunden automatisch erneut zu starten.

Weboberfläche und API

Jetzt ist Bonsai 2 dauerhaft als lokaler KI-Server erreichbar.

Die Weboberfläche öffnen wir über:

http://192.168.178.136:8080

Die gleiche Adresse stellt außerdem die API von llama-server bereit.

Damit haben wir jetzt die Grundlage geschaffen, um Bonsai 2 später mit anderen Anwendungen zu verbinden.

🔒 Sicherheit: Mit --host 0.0.0.0 kann jeder in deinem Netzwerk den Server nutzen. Gib Port 8080 nie im Router ins Internet frei. Optional schützt du den Dienst mit einem Schlüssel: Hänge an die letzte Zeile von ExecStart einen Backslash an und ergänze --api-key DEIN_KEY (ein langes, zufälliges Passwort). Danach lädst du mit systemctl daemon-reload und systemctl restart bonsai.service neu. Den Schlüssel brauchst du später auch im Hermes Agent.

Dienst verwalten

Hinweis: Auf der 12-GB-GPU kann immer nur ein Modell laufen. Willst du zwischendurch das Docker-Setup aus der vorherigen Anleitung nutzen, stoppe zuerst Bonsai mit systemctl stop bonsai.service.

Für die tägliche Verwaltung benötigen wir nur wenige Befehle.

Dienst starten:

systemctl start bonsai.service

Dienst stoppen:

systemctl stop bonsai.service

Dienst neu starten:

systemctl restart bonsai.service

Status anzeigen:

systemctl status bonsai.service

Logs anzeigen:

journalctl -u bonsai.service -f

Damit ist Bonsai 2 vollständig als systemd-Dienst eingerichtet und startet automatisch mit dem LXC-Container.

Im nächsten Schritt fassen wir die Ergebnisse zusammen und schauen uns an, wie wir Bonsai 2 anschließend für einen KI-Agenten und weitere Anwendungen verwenden können.

Fazit

Mit Bonsai 2 haben wir ein 27B-Modell auf einer vergleichsweise kleinen NVIDIA RTX 3060 mit 12 GB VRAM zum Laufen gebracht.

Dabei haben wir nicht nur das Modell installiert, sondern die gesamte Konfiguration auf unserer Hardware getestet und angepasst.

Unsere getestete Konfiguration:

• Modell: Bonsai 2 27B PQ2_0
• GPU: NVIDIA RTX 3060 12 GB
• GPU-Offload: -ngl 99
• Kontext: 131.072 Tokens
• K-Cache: q4_0
• V-Cache: q4_0

Durch die Quantisierung des KV-Caches konnten wir den verfügbaren VRAM deutlich effizienter nutzen. Mit dieser Konfiguration läuft Bonsai 2 stabil und stellt gleichzeitig einen sehr großen Kontext zur Verfügung.

Anschließend haben wir das Modell mit llama-server als dauerhaften systemd-Dienst eingerichtet. Dadurch startet Bonsai 2 automatisch mit dem LXC-Container und ist anschließend über die Weboberfläche und die API erreichbar.

Damit ist aus dem zunächst manuell gestarteten Modell ein eigenständiger lokaler KI-Server geworden.

Ausblick

Mit Bonsai 2 haben wir jetzt die Grundlage für den nächsten Schritt geschaffen.

Bisher haben wir das Modell direkt angesprochen und über die API bereitgestellt. Im nächsten Schritt soll die KI jedoch selbstständig Aufgaben ausführen und mit anderen Diensten kommunizieren können.

Dafür schauen wir uns Hermes Agenten an und verbinden den lokalen LLM-Server beispielsweise mit Telegram.

Die bisherige Architektur wird damit erweitert:

Proxmox -> LXC-Container -> NVIDIA GPU -> llama.cpp ->Bonsai 2 -> KI-Agent -> Telegram & weitere Schnittstellen

Damit verlassen wir den reinen Modellbetrieb und gehen den nächsten Schritt in Richtung eines lokalen KI-Agenten.

Dafür schauen wir uns den Hermes Agent an und verbinden den lokalen LLM-Server beispielsweise mit Telegram.

Weiter mit Teil 5: Hermes Agent: vom LLM zum KI-Agenten