LLMs produktiv betreiben: Ein praktischer Blick auf den Stack
Stand: April 2026
In den letzten Monaten habe ich viel damit gearbeitet, lokale LLMs von „läuft auf meinem Rechner“ auf „läuft stabil im Alltag“ zu bringen. Der Unterschied ist größer, als es auf Benchmarks aussieht. In der Praxis scheitert es selten am Modellnamen – meistens scheitert es an Speicher, Laufzeit oder schlechteren Antworten nach zu aggressiver Quantisierung.
1) Warum der Stack wichtiger ist als der Modellname
Wenn man ehrlich ist, fragt man anfangs oft nur: „Welches Modell ist das beste?“ Die bessere Frage lautet: Welches Modell passt zu meiner Hardware und meinem Use Case?
- Passt es sauber in den Speicher?
- Sind Antwortzeiten für echte Nutzer okay?
- Bleibt die Qualität bei längeren Prompts stabil?
Ein „Top“-Modell, das ständig an VRAM-Grenzen kratzt, ist am Ende schlechter als ein kleineres Modell, das zuverlässig läuft.
2) Modellgröße realistisch wählen
Der Sprung von 8B auf 70B klingt in Diskussionen oft linear – ist er aber nicht. Infrastrukturseitig ist das fast eine andere Liga. Größer heißt:
- mehr Speicherbedarf,
- mehr Wärme/Leistungsaufnahme,
- mehr Komplexität im Betrieb.
Meine Faustregel: Erst mit der kleinsten Größe starten, die den Job verlässlich schafft. Danach hochskalieren – nicht umgekehrt.
3) Quantisierung: Spart Speicher, kostet manchmal Qualität
Quantisierung ist kein „an/aus“-Schalter, sondern ein Trade-off.
- FP16/BF16: solide Qualität, hoher Speicherbedarf
- INT8: oft sehr guter Kompromiss
- INT4/NF4: stark platzsparend, aber bei komplexen Aufgaben fehleranfälliger
Bei 4-bit sehe ich regelmäßig den gleichen Effekt: kurze Antworten sehen gut aus, aber bei mehrstufigen Aufgaben kippt die Qualität. Darum immer mit realen Prompts testen – nicht nur mit Demo-Fragen.
4) Apple Silicon vs. NVIDIA im Alltag
NVIDIA bleibt meist die erste Wahl, wenn viele Nutzer parallel bedient werden müssen. Das CUDA-Ökosystem ist reif, Tools wie vLLM laufen dort sehr stark.
Apple Silicon ist dagegen super für lokale Entwicklung und kleine bis mittlere Last. Gerade mit viel Unified Memory kann man überraschend große Modelle lokal fahren, solange die Parallelität moderat bleibt.
Wichtig: „Fühlt sich schnell an“ und „hat hohen Durchsatz“ sind zwei verschiedene Dinge. Für Chat-UX zählt oft die Zeit bis zum ersten Token mehr als reine Tokens/Sekunde.
5) Tooling, das sich bewährt hat
- Ollama für schnelle lokale Starts
- llama.cpp für GGUF-Workflows
- vLLM für ernsthaften GPU-Server-Betrieb
- TGI wenn man stärker im Hugging-Face-Stack unterwegs ist
Ich starte meist klein und simpel. Erst wenn die Use Cases stabil sind, wird aufwändiger skaliert.
6) Was man wirklich messen sollte
Benchmarks sind ein guter Start, aber kein Betriebsersatz. Ich messe vor allem:
- Time to First Token (TTFT)
- stabile Antwortqualität bei echten Inputs
- Speicherverhalten über längere Sessions
- Ausreißer statt nur Durchschnitt
Gerade die Ausreißer entscheiden, ob sich ein Setup „produktiv“ anfühlt oder nur in Demos gut aussieht.
Fazit
LLM-Betrieb ist weniger Magie und mehr sauberes Engineering. Das beste Setup ist nicht das mit der größten Zahl im Modellnamen, sondern das, das unter Last zuverlässig arbeitet und nachvollziehbar bleibt.
Wenn du gerade aufbaust: klein starten, mit echten Daten testen, dann schrittweise hochziehen. Das spart Zeit, Geld und Nerven.