5.7 KiB
FAQ - Häufig gestellte Fragen
Server-Verwaltung
Wie stoppe und starte ich einen dieser Llama-Server?
⚠️ Wichtig: Da alle Container Port 8000 belegen, kann immer nur einer gleichzeitig laufen.
Server stoppen
# Laufenden Container nach Name stoppen (egal womit er gestartet wurde)
docker rm -f qwen35b-moe-coding
# Oder via docker-compose
cd ~/llama-server
docker compose -f docker-compose_Qwen3.6_Tools_coding.yml down
# Welche Container gerade laufen:
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
Server starten
Via Docker Compose (empfohlen — hat Healthcheck und restart: unless-stopped):
cd ~/llama-server
docker compose -f docker-compose_Qwen3.6_Tools_coding.yml up -d
Via Shell-Script (mit Readiness-Check und Test-Request):
cd ~/llama-server
bash run_qwen35b_server_tools.sh
Wechsel zwischen zwei Servern
cd ~/llama-server
# Aktuellen stoppen
docker rm -f qwen35b-moe-coding
# Anderen starten
docker compose -f docker-compose_Qwen3.6_Uncensored.yml up -d
Übersicht: Container-Namen ↔ Dateien
| Container-Name | Modell | Konfigurationsdatei |
|---|---|---|
qwen35b-moe-coding |
Carnice | docker-compose_Qwen3.6_Tools_coding.yml |
qwen35b-moe-tools |
Carnice | docker-compose_Qwen3.6_Tools.yml |
qwen35b-moe-rag-longctx |
Carnice | docker-compose_Qwen3.6_Tools_RAG_faehig.yml |
qwen35b-moe-uncensored |
Uncensored | docker-compose_Qwen3.6_Uncensored.yml |
qwen35b-moe-uncensored-rag |
Uncensored | docker-compose_Qwen3.6_Uncensored_RAG_faehig.yml |
qwen35b-moe-uncensored-rag-longctx |
Uncensored | run_qwen35b_server_uncensored_rag_longctx.sh |
Wie beende ich einen laufenden Docker-Server und erzeuge und starte ich einen neuen?
Beenden und löschen (Beispiel):
docker compose -f docker-compose_Qwen3.6_Tools_coding.yml rm -s -f qwen35b
Erzeugen und starten (Beispiel):
docker compose -f docker-compose_Qwen3.6_Tools_coding.yml up -d --force-recreate
Integration mit Pi
Wie kann ich diesen Docker-Containern mit Pi Dateien, Prompts, Tools oder MCP-Server übergeben?
Das ist eine Architekturfrage. Die Docker-Container sind reine Inferenz-Backends — sie empfangen API-Requests und liefern Text zurück. Alles andere (Dateien, Prompts, Tools, MCP) wird auf der pi-Ebene verwaltet:
MCP-Server ←──┐
Extensions ←──┤
AGENTS.md ←─┤ Pi ──→ llama-cpp Docker ──→ GPU
Dateien ←──┘ (API-Request mit System-Prompt + Tools)
Die vier Wege im Detail:
1. Dateien → per pi-Kontext
Pi liest Dateien mit dem read-Tool und schickt den Inhalt als Text im Prompt. Für automatisches Laden: AGENTS.md oder projektspezifische Context-Files (die pi beim Session-Start einliest).
2. Prompts → AGENTS.md / SYSTEM.md Bereits eingerichtet. Zusätzlich gibt es:
~/.pi/agent/SYSTEM.md # ersetzt den kompletten System-Prompt
~/.pi/agent/APPEND_SYSTEM.md # wird ans Ende angehängt
3. Tools
Pi hat eingebaute Tools (read, write, edit, bash). Eigene Tools werden als Pi-Extensions im Verzeichnis ~/.pi/agent/extensions/ registriert — du hast dort bereits eine (fact-checker). Das Modell sieht die Tool-Definitionen im System-Prompt und ruft sie über die OpenAI function-calling API auf (deshalb ist --jinja wichtig).
4. MCP-Server → Pi-Packages
Pi unterstützt MCP-Server als Packages. In deiner settings.json ist npm:pi-llama-cpp bereits eingetragen. Weitere MCP-Server werden analog hinzugefügt:
{
"packages": [
"npm:pi-llama-cpp",
"npm:@modelcontextprotocol/server-filesystem",
"npm:irgendein-mcp-server"
]
}
Der MCP-Server läuft dann als Prozess neben pi — nicht im llama-cpp-Container.
Einzige Ausnahme: Statischer System-Prompt direkt im Container llama.cpp hat einen
--system-prompt-Flag, der einen festen Prompt beim Serverstart einbrennt. Das ist aber weniger flexibel als AGENTS.md und kollidiert mit pi's eigenem System-Prompt — daher eher nicht empfehlenswert.
Server-Einstellungen
Kann ich die Server-Einstellungen im laufenden Betrieb ändern?
Größtenteils nein — llama.cpp lädt alle Parameter beim Start und allokiert KV-Cache, GPU-Layer-Verteilung und Kontextfenster fest. Ein Neustart ist für Infrastruktur-Änderungen nötig.
Was sich zur Laufzeit ändern lässt
Sampling-Parameter — pro API-Request überschreibbar:
Pi (und jeder andere API-Client) kann temperature, top_p, top_k, repeat_penalty, max_tokens in jedem einzelnen Request überschreiben — unabhängig vom Server-Default:
POST /v1/chat/completions
{
"temperature": 0.0,
"top_k": 20,
"max_tokens": 512,
...
}
Der Server-Default gilt nur, wenn der Request den Parameter weglässt.
/props-Endpoint — llama.cpp hat eine undokumentierte API zum Ändern weniger Server-Properties zur Laufzeit (z.B. default_generation_settings), aber das ist instabil und von pi nicht genutzt.
Was einen Neustart erfordert
| Parameter | Grund |
|---|---|
-c (Kontext) |
KV-Cache wird beim Start allokiert |
--parallel |
Anzahl KV-Cache-Slots ist fest |
-ngl, --tensor-split |
Modell wird beim Start auf GPU geladen |
--kv-unified, --cache-type-* |
Cache-Struktur ist nach dem Laden unveränderlich |
--batch-size, --ubatch-size |
Interne Buffer-Allokation |
| Modell-Datei | Offensichtlich |
Fazit
Für Experimente mit Sampling-Parametern (temp, top_k etc.) brauchst du keinen Neustart — du kannst sie direkt im pi-Prompt oder per API-Call testen. Für alles andere gilt: stoppen, Datei anpassen, neu starten.