llamaup

Jeder konfiguration ein Alias. Gibt dem LLM Profil.

Für meine lokalen Modelle brauche ich unterschiedliche Einstellungen für Grafikkarte, Kontextgröße und Speicher. llamaup setzt diese aus kleinen TOML-Profilen zusammen. Ich kann die fertige Konfiguration prüfen und den llama.cpp-Server anschließend per SSH in tmux starten.

Ich habe das Python-Werkzeug entwickelt, damit funktionierende Einstellungen wiederverwendbar bleiben — auch wenn ich das Modell wechsle oder einzelne Parameter ausprobiere.

Open Source · Python-Werkzeug

  • Python
  • TOML
  • llama.cpp
  • CUDA
  • tmux

Repository auf GitHub

Mein lokales Setup

Auf meinem Inferenzrechner arbeitet eine NVIDIA RTX 3090 Ti mit 24 GB VRAM. Für Qwen3.8-27B verwende ich die GGUF-Datei Qwen3.8-27B-UD-Q4_K_XL.gguf. Die quantisierten Modellgewichte brauchen weniger Speicher als eine Fassung in voller Präzision. Zusätzlich zu den Gewichten müssen aber auch Kontextzustand und Rechenpuffer Platz finden.

Mein Profil mtp-128k-solo-qwen38 ist auf diese einzelne Karte ausgerichtet: 131.072 Token Kontext, Q8-KV-Cache und MTP mit bis zu zwei vorgeschlagenen Token. Es lädt keinen Vision-Projektor und ist damit für Textbetrieb konfiguriert. Die zusätzliche RTX 3070 Ti mit 8 GB wird von diesem Profil nicht verwendet.

128K bezeichnet hier die eingestellte Kontextkapazität. Wie viel Speicher belegt wird und wie schnell das Modell antwortet, hängt auch vom Build, der Eingabelänge und den übrigen Einstellungen ab. Das Profil hält meine Konfiguration fest; eine Geschwindigkeitsmessung gehört separat dazu.

Aus Profilen wird ein Startbefehl

Modell, GPU, Kontext, Cache und Sampling liegen in getrennten Bausteinen. Ein Alias fasst sie zu einem benannten Setup zusammen. Das ist der Eintrag für meine Qwen-Konfiguration:

[aliases]
mtp-128k-solo-qwen38 = [
  "qwen38-27b",
  "gpu0-3090ti",
  "ctx-128k",
  "kv-q8",
  "no-mmproj",
  "cache-ram-2g",
  "mtp-2",
  "fit-off",
  "batch-mtp",
  "sampling-precise",
]

Prüfen, vergleichen, starten

preview zeigt den aufgelösten Serverbefehl, ohne den Inferenzrechner zu kontaktieren. explain zeigt zusätzlich, aus welchem Profil ein Wert stammt. Mit compare kann ich etwa die 128K-Konfiguration einer Variante mit 64K gegenüberstellen. Der später angegebene Baustein ctx-64k überschreibt dabei nur die Kontextgröße.

Die Namen im Beispiel stammen aus meiner eigenen Konfiguration. Wer llamaup auf einem anderen Rechner verwendet, passt Modellpfade, SSH-Ziel und GPU-Profile an. run startet tatsächlich den Server und ersetzt gegebenenfalls den bisherigen, von llamaup verwalteten Prozess auf dem gewählten Ziel. --wait wartet anschließend auf dessen Health-Endpunkt.

# Startbefehl ansehen, ohne etwas zu starten
llamaup preview mtp-128k-solo-qwen38

# Herkunft der Einstellungen nachvollziehen
llamaup explain mtp-128k-solo-qwen38

# 128K und 64K vergleichen
llamaup compare "mtp-128k-solo-qwen38" \
  "mtp-128k-solo-qwen38 ctx-64k"

# Konfiguration auf dem Inferenzrechner starten
llamaup run mtp-128k-solo-qwen38 --wait

# Prozess und HTTP-Erreichbarkeit abfragen
llamaup status mtp-128k-solo-qwen38

Was die llama.cpp-Flags bedeuten

Dieser gekürzte Ausschnitt zeigt die zentralen Speicher- und GPU-Einstellungen aus dem erzeugten Aufruf. Der Modellpfad ist ein neutraler Beispielpfad; Netzwerk-, Sampling- und weitere Optionen sind hier ausgelassen. CUDA_VISIBLE_DEVICES=0 wählt in meinem Setup die 3090 Ti aus.

CUDA_VISIBLE_DEVICES=0 llama-server \
  -m /srv/models/Qwen3.8-27B-UD-Q4_K_XL.gguf \
  -ngl all -sm none -fa on \
  -c 131072 -np 1 \
  -ctk q8_0 -ctv q8_0 \
  -b 1024 -ub 256 \
  -fit off
  • -ngl all: Alle Modellschichten sollen in den Grafikspeicher geladen werden. Das setzt ausreichend freien VRAM voraus.
  • -sm none: Das Modell wird auf einer GPU betrieben, ohne Aufteilung auf mehrere Karten.
  • -fa on: Aktiviert Flash Attention, eine speichereffiziente Berechnung der Attention.
  • -c 131072 -np 1: Konfiguriert 128K Kontext und einen Server-Slot. Kontext umfasst Eingabe und erzeugte Fortsetzung; Token sind Textbausteine, keine Wörter.
  • -ctk q8_0 -ctv q8_0: Legt die Datentypen des Key-/Value-Caches auf Q8 fest. Dieser Zwischenspeicher hält Attention-Zustand bereits verarbeiteter Token. Seine Quantisierung ist unabhängig von der Quantisierung der Modellgewichte.
  • -b 1024 -ub 256: Begrenzt die logische Batchgröße und die physisch verarbeiteten Teilbatches. Kleinere Teilbatches können den Bedarf an Rechenpuffern reduzieren.
  • -fit off: Schaltet die automatische Anpassung noch nicht gesetzter Parameter an den verfügbaren Gerätespeicher aus. So bleibt die Speicherabstimmung bei meiner gewählten Konfiguration.

MTP und Sampling

Mein Profil ergänzt --spec-type draft-mtp --spec-draft-n-max 2. MTP steht für Multi-Token Prediction: Beim spekulativen Decoding werden Token vorgeschlagen und vom Hauptmodell überprüft. Hier sind es höchstens zwei pro Entwurf. Ob das die Ausgabe beschleunigt, hängt davon ab, wie oft die Vorschläge akzeptiert werden und wie viel Aufwand ihre Berechnung kostet. Modell und llama.cpp-Build müssen diesen Modus unterstützen.

Sampling steuert die Auswahl des nächsten Token. Mein Profil setzt unter anderem --temp 0.6, --top-k 20 und --top-p 0.95: Temperatur verändert die Gewichtung der Wahrscheinlichkeiten, Top-k und Top-p begrenzen die berücksichtigten Kandidaten. Diese Werte sind eine wiederverwendbare Arbeitskonfiguration. Niedrige Temperatur garantiert keine richtigen Antworten.

Für einen einzelnen Vergleich kann ich einen Wert überschreiben, ohne das Profil zu bearbeiten. Dieser Aufruf zeigt nur den geänderten Startbefehl:

llamaup preview mtp-128k-solo-qwen38 --param temp=0.8

Entwicklung und Grenzen

Der Kern läuft mit Python 3.11 oder neuer und der Standardbibliothek. llamaup löst Aliase auf, führt TOML-Bausteine zusammen und prüft Werte vor dem Start. Die Vorschau macht den resultierenden Aufruf kontrollierbar; SSH und tmux übernehmen den Betrieb auf dem Inferenzrechner. Weitere Befehle helfen beim Abgleich von Modellprofilen und vorhandenen GGUF-Dateien.

llamaup ist für meinen Betrieb als einzelne Person ausgelegt. Es benötigt einen vorhandenen llama.cpp-Build und passende Modelldateien. Es richtet keine Authentifizierung, TLS oder Firewall ein. Profile und unterstützte Server-Flags müssen zum verwendeten Build passen. Quellcode, Tests und bereinigte Beispielkonfigurationen sind unter der MIT-Lizenz veröffentlicht.