Zwei lokale KI-Modelle auf einem Server: was das für dein Unternehmen bedeutet

Vor einem halben Jahr hat ein einziges gutes KI-Modell meinen Server komplett ausgefüllt. Heute laufen auf derselben Maschine zwei Modelle gleichzeitig, jedes mit einer klaren Rolle.

Kein Cloud-Anbieter, kein API-Vertrag, kein Token verlässt das Haus.

In diesem Beitrag erkläre ich, wie das Setup aussieht, warum es funktioniert und warum das Thema auch dann für dich relevant ist, wenn du selbst nie einen KI-Server betreiben wirst.

Die Ausgangslage

Bei mir steht eine NVIDIA DGX Spark, ein kompakter KI-Rechner mit 128 GB Speicher, den sich Grafikeinheit und Prozessor teilen. Darauf betreibe ich Sprachmodelle mit vLLM, einer Open-Source-Software, die Modelle als Dienst bereitstellt, so wie du es von ChatGPT und Co. über deren Schnittstellen kennst. Nur eben im eigenen Büro.

Lange galt dabei eine einfache Rechnung: ein gutes Modell, ein Server. Die Modelle, die wirklich brauchbaren Code schreiben und zuverlässig Werkzeuge bedienen, waren schlicht zu groß für mehr.

Das hat sich geändert, und zwar durch zwei Entwicklungen gleichzeitig.

Was sich geändert hat

Die erste Entwicklung ist Quantisierung. Die aktuelle Qwen-Generation gibt es offiziell im FP8-Format. Vereinfacht gesagt werden die Zahlen im Modell mit halber Genauigkeit gespeichert. Das halbiert den Speicherbedarf, und die Qualität bleibt in der Praxis nahezu identisch.

Die zweite Entwicklung ist die Architektur. Moderne Modelle wie Qwen3.6-35B-A3B sind Mixture-of-Experts-Modelle. Das Modell hat insgesamt 35 Milliarden Parameter, aktiviert für jedes erzeugte Wort aber nur rund 3 Milliarden davon. Es schlägt also nicht jedes Mal im ganzen Lexikon nach, sondern nur in den Kapiteln, die gerade gebraucht werden.

Beides zusammen bedeutet: Zwei ernstzunehmende Modelle passen jetzt gemeinsam in 128 GB.

Die Arbeitsteilung

Auf meiner Spark laufen jetzt zwei vLLM-Instanzen parallel.

Das erste Modell ist Qwen3.6-35B-A3B-FP8, das Mixture-of-Experts-Modell. Es ist mit rund 50 Token pro Sekunde das schnelle von beiden und übernimmt die tägliche Fleißarbeit: Code schreiben und anpassen im Editor, Autovervollständigung, Zusammenfassungen von Aufnahmen und Notizen.

Das zweite ist Qwen3.6-27B-FP8, ein klassisches dichtes Modell. Hier arbeiten alle 27 Milliarden Parameter an jeder Antwort. Es ist mit etwa 10 Token pro Sekunde deutlich langsamer, liegt in Agenten-Benchmarks aber auf dem Niveau großer Cloud-Modelle. Es bekommt die Aufgaben, bei denen ich gerne warte: Planung, Code-Reviews, Architekturentscheidungen.

Falls du dich wunderst, warum das kleinere Modell das langsamere ist: Bei dieser Art Hardware entscheidet nicht die Gesamtgröße über das Tempo, sondern wie viele Parameter pro Wort aus dem Speicher gelesen werden müssen. 3 Milliarden aktive Parameter gegen 27 Milliarden, das erklärt den Faktor fünf.

Im Entwicklungs-Workflow greifen beide ineinander. Der Planungs-Agent denkt mit dem gründlichen Modell nach, der Umsetzungs-Agent arbeitet mit dem schnellen. Zusätzlich habe ich pro Modell Varianten hinterlegt, etwa eine besonders präzise Einstellung für Refactorings und eine kreativere für Brainstorming. Gleiches Modell im Speicher, je nach Aufgabe anders konfiguriert.

Das ist im Kleinen dasselbe Prinzip, das gute Teams im Großen anwenden: Nicht jede Aufgabe braucht die teuerste Ressource, aber jede Aufgabe braucht die passende.

Warum das für Entscheider relevant ist

Du wirst vermutlich nie selbst eine DGX Spark konfigurieren. Trotzdem lohnt es sich, drei Dinge aus diesem Setup mitzunehmen.

Erstens: Lokale KI ist keine Bastelei mehr. Die Modellqualität, die vor einem Jahr nur bei Cloud-Anbietern verfügbar war, läuft heute auf einem Rechner im Büro. Für Projekte mit Auftragsverarbeitung, DSGVO-Anforderungen oder schlicht sensiblen Geschäftsdaten ist das keine Notlösung, sondern eine vollwertige Option. Die Frage “Cloud oder lokal” ist damit eine echte Abwägung geworden, keine erzwungene Entscheidung.

Zweitens: Die Kostenstruktur ändert sich. Ein lokales Setup hat Anschaffungskosten, aber keine Kosten pro Anfrage. Automatisierungen, die permanent laufen, etwa das Zusammenfassen von Aufnahmen oder das Extrahieren von Aufgaben aus Dokumenten, rechnen sich lokal ganz anders als über eine abgerechnete Schnittstelle.

Drittens, und das ist mir am wichtigsten: Es zeigt, wie eine Agentur mit KI umgehen sollte. Nämlich nicht mit einer Pauschalantwort, sondern mit Rollenverteilung. Das schnelle Modell für Routineaufgaben, das gründliche für Entscheidungen, und für jede Aufgabe die passende Konfiguration. Wer dir erzählt, ein einziges Modell (oder ein einziges Tool) löse alles, hat die Technologie nicht verstanden oder will sie dir zu einfach verkaufen.

Woran du eine passende Agentur erkennst

Wenn du gerade eine Agentur suchst, die KI in deine Prozesse oder deine Software bringen soll, sind das aus meiner Sicht die richtigen Prüffragen:

• Kann sie erklären, welches Modell sie wofür einsetzt, und warum?
• Hat sie eine Antwort auf die Datenschutzfrage, die über “wir haben einen AVV mit dem Anbieter” hinausgeht?
• Betreibt sie selbst, was sie empfiehlt?
• Spricht sie über Grenzen genauso offen wie über Möglichkeiten?

Ich beantworte die letzte Frage gerne zuerst: Nicht alles funktioniert lokal gleich gut. Meine Experimente mit RAG über meine eigenen Notizen waren bisher nur mäßig erfolgreich, und für manche Grundsatzfragen greife ich weiterhin zu großen Cloud-Modellen. Genau diese Ehrlichkeit würde ich von jedem Dienstleister erwarten.

Fazit

Zwei Modelle auf einem Server sind kein Selbstzweck. Sie sind das sichtbare Ergebnis einer Entwicklung, die für Unternehmen gerade sehr konkret wird: KI-Qualität auf Cloud-Niveau, betrieben auf eigener Hardware, mit voller Kontrolle über die Daten.

Wer heute über KI in seinen Projekten nachdenkt, sollte die lokale Option kennen und einen Partner haben, der beide Welten aus der Praxis kennt.

Wenn du wissen willst, wo dein Projekt steht und ob lokale KI für euch eine Option ist, sprich mich an oder starte mit dem Projekt-Check.