KI-Server auswählen, ohne sich zu verrennen: ein pragmatischer Blick auf Modelle, Nutzerzahlen und Workflows
Wer „lokale KI“ hört, denkt oft zuerst an ein Modell und eine Grafikkarte. In der Praxis ist es eher ein kleines System aus Bausteinen: ein LLM, das Texte erzeugt, eine Oberfläche, über die Menschen damit arbeiten, und oft eine Automationsschicht, die das Modell in Prozesse einbindet. Genau da passieren die meisten Fehlkäufe. Nicht weil jemand zu wenig Technik versteht, sondern weil die falschen Fragen gestellt werden.
Dieser Beitrag erklärt die Grundlagen so, dass du eine Hardwareentscheidung vorbereiten kannst, ohne dich in Datenblättern zu verlieren. Du brauchst kein Vorwissen. Und du musst dich nicht auf ein bestimmtes Tool-Setup festlegen, denn die Logik bleibt gleich, ob du mit Ollama/OpenWebUI/n8n arbeitest oder mit einer anderen Kombination.
Was ist ein „lokaler KI-Stack“ überhaupt?
1) VRAM: der Speicher der GPU
Der wichtigste Begriff am Anfang ist VRAM. Das ist der Speicher auf der Grafikkarte. Ein LLM muss zu großen Teilen in diesen Speicher passen, sonst wird es langsam oder läuft gar nicht sinnvoll. VRAM ist daher weniger „nice to have“, sondern dein Budget.
Mehr VRAM bedeutet nicht nur „größeres Modell“. Es bedeutet auch mehr Luft für längere Kontexte, mehrere gleichzeitige Anfragen und Zusatzkomponenten wie Vision oder Reranking.
2) GPU-Rechenleistung: fühlt sich das schnell an?
Selbst wenn ein Modell in den VRAM passt, kann es träge sein. Nutzer merken das sofort. Entscheidend ist die Zeit bis zur ersten Ausgabe und wie schnell der Text dann fließt. Das wird im Alltag wichtiger als theoretische Maximalwerte.
3) CPU und RAM: die Realität drumherum
Viele Aufgaben rund ums Modell laufen nicht auf der GPU: Daten holen, JSON verarbeiten, Dokumente zerlegen, PDFs vorbereiten, Embeddings berechnen, Dateien bewegen, Workflows koordinieren. Dafür brauchst du CPU-Kerne und RAM. Gerade bei Automationen ist das der Bereich, der aus „läuft im Test“ schnell „wird zäh im Alltag“ macht.
4) Storage: NVMe ist nicht Luxus, sondern Stabilität
Sobald Dokumente im Spiel sind, brauchst du schnelle Datenträger. Nicht nur für Geschwindigkeit, auch für sauberes Verhalten unter Last. NVMe reduziert Wartezeiten bei Indexzugriffen, Logs, Cache und Dateiverarbeitung.
Modellgrößen verstehen, ohne in Zahlen zu ertrinken
Modellgrößen werden meist in „B“ angegeben, also Milliarden Parameter: 7B, 14B, 27B, 70B. Mehr Parameter heißt oft bessere Qualität, aber der Zusammenhang ist nicht linear. Ein gut trainiertes 27B kann in vielen Business-Aufgaben sehr überzeugend sein, während ein schlecht passendes 70B unnötig teuer und langsam wirkt.
Neben der Größe gibt es einen zweiten Hebel, der für lokale Setups entscheidend ist: Quantisierung.
Quantisierung komprimiert Modellgewichte, damit sie weniger VRAM brauchen. Das ist der Grund, warum viele Modelle lokal überhaupt praktikabel sind. Du siehst dann Varianten wie Q4, Q5, Q8. Grob gilt:
- stärker quantisiert: spart VRAM, kann bei Präzision oder Stil leiden
- weniger quantisiert: bessere Qualität, braucht mehr VRAM
QAT (Quantization Aware Training) ist dabei besonders interessant: Das Modell wurde so trainiert, dass es in quantisierter Form besser funktioniert. „gemma3 27B IT QAT“ ist ein gutes Beispiel für diese Kategorie: eine Modellgröße, die in der Praxis oft spürbar besser ist als typische 7B/14B, aber durch QAT in Reichweite von lokalen Deployments bleibt.
Kontextlänge: der versteckte VRAM-Fresser
Kontext ist das, was das Modell „im Kopf behalten“ soll: Chatverlauf, Anweisungen, Dokumentauszüge. Mehr Kontext ist bequem, kostet aber VRAM. Wer also viel mit Dokumenten arbeitet, steht schnell vor einer Wahl: mehr Kontext direkt ins Modell kippen oder eine Retrieval-Strategie nutzen.
RAG in einem Satz: Dokumente nutzen, ohne alles in den Kontext zu stopfen
RAG steht für Retrieval Augmented Generation. Statt dem Modell ganze Dokumente zu geben, suchst du die relevanten Passagen heraus und gibst nur diese weiter. Das spart Kontext und steigert oft die Trefferqualität.
RAG verschiebt Last: weniger VRAM-Druck durch riesige Kontexte, dafür mehr CPU/RAM/Storage für Embeddings, Index und Suche. Genau deshalb ist ein lokaler KI-Server kein reines GPU-Thema.
Fazit
Wenn du lokale KI für den Alltag planst, reicht es nicht, dass es irgendwie startet und im Test ein paar Antworten ausspuckt. Entscheidend ist, dass es unter realer Nutzung stabil bleibt: mehrere parallele Chats, Dokumente im Hintergrund, Workflows, die nebenbei laufen.
VRAM entscheidet, welche Modellklasse und welche Kontexte realistisch sind. GPU-Leistung entscheidet, ob es sich schnell anfühlt. CPU, RAM und NVMe entscheiden, ob Workflows, Dokumente und Nebenlast das Ganze dauerhaft tragen.
Unsere scope7-Familie bildet genau diese typischen Wachstumsschritte ab: vom soliden Einstieg über Team-Betrieb bis zur Plattform für mehrere Teams und parallele Modelle. Der Punkt ist nicht, möglichst groß einzukaufen, sondern die passende Stufe zu wählen, damit Nutzer es gerne verwenden.
👉 Willst du sehen, wie das in deiner Umgebung aussieht? Buche eine Demo und erlebe meloki.
