Drei Sprachmodelle auf einer Maschine

Ein lokaler KI-Server, drei Modelle für drei Aufgaben: warum ein kleines MoE ein größeres Dense-Modell schlägt — und Bandbreite mehr zählt als Parameter.

Wer lokale KI ernst nimmt, landet schnell bei einer unbequemen Frage: Welches Modell eigentlich? Die Antwort in unserem Labor lautet: nicht eines, sondern drei — je nach Aufgabe. Auf einem einzigen lokalen KI-Server (einem NVIDIA DGX Spark mit 128 GB gemeinsamem Speicher) laufen bei uns drei Sprachmodelle nebeneinander, jedes für einen anderen Job. Was wir dabei über Modellwahl gelernt haben, widerspricht dem verbreiteten „mehr Parameter = besser".

Ein Gerät, drei Rollen

Wir teilen die Arbeit nach Charakter der Aufgabe auf:

  • Das Arbeitspferd — ein schnelles Mixture-of-Experts-Modell (MoE) für alles, was zügig kommen muss: Assistenz, Zusammenfassungen, Werkzeug-Aufrufe. Es liefert 60 bis 90 Tokens pro Sekunde und fühlt sich dadurch flüssig an.
  • Das Reasoning-Modell — ein kleineres, dichtes Modell für Aufgaben, bei denen Sorgfalt vor Tempo geht: Code, mehrstufige Analysen. Es ist mit rund 9 Tokens pro Sekunde deutlich langsamer, dafür gründlicher.
  • Ein Eskalations-Modell — ein großes Modell, das nur für die wenigen wirklich harten Fälle bei Bedarf dazugeschaltet wird.

Alle drei liegen gleichzeitig im Speicher. Genau das macht ein Gerät mit viel gemeinsamem Arbeitsspeicher möglich.

Die überraschende Lehre: Bandbreite schlägt Parameter

Tempo je Rolle — Tokens pro Sekunde
MoE-Arbeitspferd 60–90 Reasoning (dicht) ~9
Das MoE aktiviert pro Token nur einen Bruchteil seiner Gewichte — darum ein Vielfaches schneller als ein dichtes Modell. Werte in Tokens/Sekunde.

Der eigentliche Aha-Moment kam bei der Modellwahl fürs Arbeitspferd. Intuition sagt: nimm das größte Modell, das reinpasst. Gemessen war das falsch.

Auf dieser Hardware ist Speicher billig, aber Speicher-Bandbreite teuer. Bei jedem erzeugten Token muss das Modell durch seine aktiven Gewichte gelesen werden — und dieses Lesen, nicht das Rechnen, ist der Flaschenhals. Ein MoE-Modell aktiviert pro Token nur einen Bruchteil seiner Gesamtgewichte. Ein gleich großes dichtes Modell muss durch alle. Das Ergebnis: Unser MoE-Arbeitspferd ist bei vergleichbarer Antwortqualität um ein Vielfaches schneller als ein dichtes Modell ähnlicher Größe.

Kurz: Es zählen die aktiven Parameter, nicht die auf dem Papier. „Größer" heißt auf dieser Klasse Hardware oft nur „langsamer".

Die Falle mit dem Nachdenken

Eine zweite Lehre, die uns Zeit gekostet hat: Manche Modelle haben einen „Thinking"-Modus standardmäßig an — sie erzeugen vor der eigentlichen Antwort eine interne Denk-Kette. Für Reasoning ist das Gold wert, für einen schnellen Assistenten ist es Gift: Die Antwort kommt Sekunden später, ohne dass der Nutzer etwas davon hat. Wer das nicht bewusst abschaltet, wundert sich über einen „lahmen" Assistenten, der eigentlich nur die ganze Zeit nachdenkt. Welches Modell in welcher Rolle mit oder ohne Nachdenken laufen soll, ist eine der wichtigsten Konfigurationsentscheidungen — und keine, die man dem Zufall überlassen sollte.

Was das praktisch bedeutet

Für einen Betrieb, der lokale KI einsetzen will, steckt darin eine handfeste Kostenlehre: Man braucht nicht zwingend die teuerste, größte Hardware für das größte Modell. Man braucht das richtige Modell für die jeweilige Aufgabe — und misst, statt zu raten. Ein schnelles MoE für den Alltag, ein gründliches Modell für die Denkarbeit, und für die seltenen harten Fälle eine Eskalation. Drei Rollen, eine Maschine, klare Zuständigkeiten.

Wie weit man mit dem kleinen Modell kommt, wenn man ihm die richtigen Fakten danebenlegt, statt zum großen zu greifen, haben wir in einem eigenen Experiment gemessen: Grounding schlägt Gewichte.

Zurück zur Übersicht