Lokale Claude-Code-Einrichtung mit Qwen3.5 27B über llama.cpp

Lokale Claude-Code-Konfiguration

Ein Entwickler dokumentierte seinen Aufbau für den vollständig offline Betrieb von Claude Code mit einem lokalen LLM unter Verwendung von llama.cpp. Das System nutzt Qwen3.5 27B, quantisiert mit unsloth/UD-Q4_K_XL auf Arch Linux mit Strix-Halo-Hardware.

Umgebungskonfiguration

Um Telemetrie zu deaktivieren und Claude Code vollständig offline zu betreiben, wurden folgende Umgebungsvariablen in ~/.bashrc gesetzt:

export ANTHROPIC_BASE_URL="http://127.0.0.1:8001"
export ANTHROPIC_API_KEY="not-set"
export ANTHROPIC_AUTH_TOKEN="not-set"
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
export CLAUDE_CODE_ENABLE_TELEMETRY=0
export DISABLE_AUTOUPDATER=1
export DISABLE_TELEMETRY=1
export CLAUDE_CODE_DISABLE_1M_CONTEXT=1
export CLAUDE_CODE_MAX_OUTPUT_TOKENS=4096
export CLAUDE_CODE_AUTO_COMPACT_WINDOW=32768

Der Entwickler merkte an, dass die Verwendung von claude/settings.json stabiler und besser kontrollierbar ist als Umgebungsvariablen.

llama.cpp-Server-Konfiguration

Der llama.cpp-Server wurde mit diesen Parametern gestartet:

ROCBLAS_USE_HIPBLASLT=1 ./build/bin/llama-server \
--model models/Qwen3.5-27B-Q4_K_M.gguf \
--alias "qwen3.5-27b" \
--port 8001 --ctx-size 65536 --n-gpu-layers 999 \
--flash-attn on --jinja --threads 8 \
--temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.00 \
--cache-type-k q8_0 --cache-type-v q8_0

Das Flag ROCBLAS_USE_HIPBLASLT=1 war für Strix-Halo-Hardware erforderlich, und der Entwickler betonte, dass die spezifische Hardware erforscht werden sollte, um den llama.cpp-Aufbau anzupassen.

Leistungsbenchmarks

Es wurden sieben Durchläufe mit folgenden Ergebnissen durchgeführt:

• Durchlauf 1 (Dateioperationen): 1m44s, 9,71 Token/Sekunde, 23K Kontext, korrekte Ausgabe
• Durchlauf 2 (Git-Klon + Code-Lesen): 2m31s, 9,56 T/s, 32,5K Kontext, ausgezeichnete Qualität
• Durchlauf 3 (7-Tage-Plan + Anleitung): 4m57s, 8,37 T/s, 37,9K Kontext, ausgezeichnete Qualität
• Durchlauf 4 (Fähigkeitsbewertung): 4m36s, 8,46 T/s, 40K Kontext, sehr gute Qualität (Websuche defekt)
• Durchlauf 5 (Python-Skript schreiben): 10m25s, 7,54 T/s, 60,4K Kontext, gute Qualität (7/10)
• Durchlauf 6 (Code-Überprüfung + Fehlerbehebung): 9m29s, 7,42 T/s, 65.535 Kontext (ABSTURZ), sehr gute Qualität (8,5/10)
• Durchlauf 7 (/compact-Befehl): ~10m, ~8,07 T/s, 66.680 Kontext (fehlgeschlagen), N/A Qualität

Wesentliche Erkenntnisse

• Die Generierungsgeschwindigkeit verschlechterte sich um etwa 24 % über den Kontextbereich: von 9,71 T/s bei 23K Kontext auf 7,42 T/s bei 65K Kontext
• Der Claude-Code-System-Prompt verbraucht 22.870 Token (35 % des 65K-Budgets)
• Die automatische Komprimierung war völlig defekt: Claude Code ging von 200K Kontext aus, sodass die 95 %-Schwelle bei 190K lag, aber das 65K-Limit wurde bei 33 % dessen erreicht, was Claude Code für das Fenster hielt
• Der /compact-Befehl benötigt Ausgabepuffer: Bei 4096 maximalen Ausgabetoken passte die Komprimierungszusammenfassung nicht, es werden 16K+ Token benötigt
• Die Websuchfunktion ist ohne Anthropic-Verbindung defekt; mögliche Lösungen umfassen SearXNG über MCP