01
Eine private KI für ein Büroteam, auf vorhandenen GPUs
- Problem
- Das Team wollte einen KI-Assistenten für Chat und Programmierung, aber Firmencode und Dokumente sollten nicht zu einem öffentlichen Dienst gehen. Keine einzelne Workstation hatte genug GPU-Speicher für ein 27B-Modell mit langem Kontext.
- Was wir gemacht haben
- Wir haben ein Modell mit 27 Milliarden Parametern mit llama.cpp RPC auf vier vorhandene GPU-Workstations verteilt, drei mit NVIDIA und eine mit AMD, und llama.cpp dafür selbst für CUDA, ROCm/HIP und Vulkan gebaut. Genutzt wird es über Open WebUI zum Chatten und über eine OpenAI-kompatible API direkt in den Entwicklungswerkzeugen. Das Deployment läuft über Bash und systemd, mit Health-Checks und Rollback. Der RPC-Port ist per Firewall abgeschottet, der Dienst hat ein eigenes Konto und die API verlangt einen Schlüssel.
- Ergebnis
- Lasttest mit 10–16 Personen gleichzeitig: 0 Fehler, etwa 22 Tokens pro Sekunde für jeden, 262K Tokens Kontext.
- Technik
llama.cpp RPC · CUDA · ROCm/HIP · Vulkan · Open WebUI · Linux · systemd · Bash
Diagramm: Nutzer verbinden sich mit Open WebUI oder der API, die Anfragen an llama-server senden. llama-server verteilt das Modell über llama.cpp RPC auf vier GPU-Worker: drei mit NVIDIA, einer mit AMD. Die Antworten werden zurückgestreamt.
↑ Antworten zurückgestreamt
llama-server
llama-server lädt das 27B-Modell und legt jeweils einen Teil davon in den GPU-Speicher jedes Workers. Für jedes Token koordiniert er die Worker über das Netzwerk. Er läuft unter einem eigenen Dienstkonto.
Hier wird ein Modell auf vier Rechner aufgeteilt; das ist kein Load Balancing. Jede Anfrage nutzt alle vier GPUs, weil jede einen Teil desselben Modells hält.
Wofür es genutzt wird
Die meisten Fragen drehen sich um Code. Weil das Modell im Haus läuft, kann internes Material eingefügt werden, ohne dass es das Netzwerk verlässt.
Entwickler
Dieses Deploy-Skript startet den Inferenzserver neu, prüft aber nie, ob er wieder läuft. Wie warte ich mit einem Timeout darauf, dass er bereit ist?
systemctl restart llama-server
echo "deploy finished"Lokales Modell · 27B
Fragen Sie nach dem Neustart den /health-Endpunkt von llama-server ab. Beenden Sie das Skript, sobald er antwortet, und brechen Sie mit einem Fehlercode ab, wenn er nach 60 Sekunden noch nicht erreichbar ist, damit das Deployment zurückrollen kann:
systemctl restart llama-server
for attempt in $(seq 1 30); do
if curl -fsS http://127.0.0.1:8080/health > /dev/null; then
echo "llama-server is healthy"
exit 0
fi
sleep 2
done
echo "llama-server not healthy after 60 s" >&2
exit 1Gemessen im Lasttest
- 4
- 27B
- 262K
- 10–16
- 0
- ≈22