Die übliche KI-Erzählung liebt den Monolithen. Ein Modell, ein Endpoint, eine große Antwortmaschine. Für Vorträge ist das attraktiv. Für reale Arbeitslasten oft nicht.

Viele produktive Systeme müssen nicht eine perfekte, universelle Antwort erzeugen. Sie müssen mehrere kleinere Aufgaben gleichzeitig lösen: zwei Übersetzungen, zwei Klassifikationen, ein Routing-Schritt plus ein Review, ein kurzer Tool-Plan parallel zu einer knappen Zusammenfassung. Genau dort wird aus Modellgröße schnell Verschwendung. Denn ein großes Modell arbeitet dann wie ein schwerer Transporter, der täglich nur ein paar Pakete ausfährt.

Die interessantere Frage lautet deshalb nicht nur: Wie stark ist ein Modell? Sondern: Wie gut nutzt ein System seine vorhandene Hardware aus?

Warum ein Modell für alles oft zu viel des Guten ist

Größere Modelle bringen mehr Breite, aber auch mehr Speicherverkehr, mehr Betriebsaufwand und oft höhere Latenz. Für viele Alltagsaufgaben ist das schlicht überdimensioniert. Die Total Cost of Ownership steigt schneller als der praktische Nutzen.

Das sieht man besonders deutlich bei kurzen, wiederholbaren Workloads. Wenn Prompts klein bleiben und Antworten knapp sein dürfen, zählt nicht nur Modellqualität, sondern Durchsatz. Ein System, das zwei Aufgaben in 250 Millisekunden parallel erledigt, ist für den Nutzer oft wertvoller als ein eleganter Alleskönner, der dafür 400 Millisekunden und deutlich mehr Speicher braucht.

Darum wird die Idee kleiner Spezialisten so attraktiv. Nicht aus Romantik für Minimalismus, sondern aus Effizienz.

Vom MoE-Gedanken zur nüchternen Betriebsarchitektur

Das Grundprinzip ist nicht neu. Mixture-of-Experts verteilt Arbeit innerhalb eines großen Modells auf spezialisierte Pfade. Man kann dieselbe Logik aber auch außerhalb des Modells weiterdenken: nicht ein großes Netz mit internen Experten, sondern mehrere kleine Modelle mit klaren Rollen.

Diese Architektur hat einen praktischen Vorteil. Die Modelle bleiben austauschbar, unabhängig versionierbar und in vielen Fällen viel leichter auf Consumer-Hardware oder Edge-Systemen zu betreiben. Wenn ein 1.5B-Modell für Übersetzung reicht, warum sollte dieselbe Aufgabe durch ein viel größeres System geschoben werden, nur weil es theoretisch alles andere auch könnte?

Zwei Arten von Parallelität

Wer mehrere Modelle auf einer GPU oder einem gemeinsam genutzten Beschleuniger laufen lassen will, stößt schnell auf zwei Grundideen. Entweder die Hardware wird zeitlich multiplexed, also in kurzen Scheiben zwischen mehreren Prozessen geteilt, oder sie wird räumlich partitioniert, wie etwa bei NVIDIAs MIG. Das eine ist flexibler, das andere vorhersagbarer.

Auf Apple Silicon gibt es keine harte MIG-artige Aufteilung. Dort entsteht Parallelität eher über Scheduling, gemeinsames Speichersystem und das geschickte Überlappen von Last. Das klingt nach einem Nachteil, muss es aber nicht sein. Gerade bei kleinen, quantisierten Modellen kann dieses weichere Modell schon reichen, um die vorhandene Hardware deutlich besser auszulasten.

Unser Versuch: Zwei kleine Qwen-Modelle auf einem M1 Max

Wir haben das mit einer sehr einfachen, aber aussagekräftigen Aufgabe geprüft. Ein deutscher Text sollte gleichzeitig ins Englische und ins Spanische übersetzt werden. Statt beide Sprachen seriell über ein einziges Modell zu erzeugen, wurden zwei kleine Qwen-Modelle parallel angesprochen.

Die Testumgebung war ein Apple Silicon M1 Max mit 32 GPU-Kernen und 64 GB Unified Memory, bedient über Ollama mit Metal-Backend. Als Modell diente Qwen 2.5 1.5B, einmal in einer Q4KM-Variante und einmal als FP16-Artefakt. Die Idee war bewusst schlicht: zwei kleine Spezialisten statt eines breiten, monolithischen Durchlaufs.

Die relevanten Stellschrauben in Ollama waren:

export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4
ollama serve

Gemessen wurde über mehrere Szenarien mit Warm-up und anschließend 100 Läufen:

ein paralleler Pfad mit zwei Modellen gleichzeitig
ein Einzellauf mit nur einem Modell
ein Einzelpfad, in dem dasselbe Modell beide Sprachen in einer Antwort erzeugt

Was die Zahlen zeigen

Die Messungen sind in ihrer Tendenz deutlicher als in ihrer letzten Nachkommastelle. Das 4-Bit-Modell lag im Einzellauf bei rund 143 ms. Im Parallelbetrieb stieg seine eigene Latenz auf etwa 185 ms. Das ist ein Aufpreis, aber kein dramatischer.

Entscheidend ist etwas anderes: Beide Ergebnisse lagen zusammen trotzdem schneller vor, als wenn ein einzelnes Modell beide Übersetzungen nacheinander oder in einem kombinierten Pfad erzeugen musste. Die schnellste “single-both”-Variante lag bei rund 276 ms. Der Parallelbetrieb brachte die zwei Ausgaben also spürbar früher auf den Tisch.

Gerade das ist die betriebliche Pointe. Die Einzellatenz eines Spezialisten steigt etwas. Die Gesamtzeit bis zum vollständigen Ergebnis sinkt dennoch. Wer nur auf die Latenz einer einzelnen Modellantwort schaut, übersieht den eigentlichen Produktivitätsgewinn.

Warum 4-Bit hier so gut aussieht

Auf dem M1 Max zeigte sich zudem ein Effekt, der gut zu vielen Inferenzsystemen passt: Die 4-Bit-Variante wirkte nicht nur kleiner, sondern auch robuster. FP16 war in diesem Aufbau deutlich langsamer und streute stärker.

Der Grund liegt wahrscheinlich weniger in der rohen Rechenleistung als im Speicherverkehr. LLM-Inferenz ist in vielen Fällen stärker bandbreiten- als arithmetikgebunden. Wenn 4-Bit-Gewichte deutlich weniger Daten bewegen, sinkt der Druck auf das gemeinsame Speichersystem. Die Dequantisierung kostet zwar etwas, aber der Gewinn bei Bandbreite und Cache-Verhalten überwiegt häufig.

Das ist kein allgemeines Naturgesetz, sondern eine Beobachtung für genau diesen Stack. Aber es verweist auf etwas Wichtigeres: Auch auf Apple Silicon ist nicht automatisch der rechnerisch edlere Pfad der produktivere. Für reale Workloads gewinnt oft der Pfad, der mit Speicher sparsamer umgeht.

Was das für Systemdesign bedeutet

Der eigentliche Wert solcher Experimente liegt nicht in der Übersetzung von Deutsch nach Englisch und Spanisch. Er liegt in der Architekturidee dahinter.

Viele Agenten- oder Unternehmenssysteme bestehen aus Teilschritten mit unterschiedlicher Komplexität. Ein kleiner Router entscheidet, wohin eine Anfrage gehört. Ein zweites Modell formuliert knapp. Ein drittes prüft oder extrahiert. Wenn diese Aufgaben getrennt und parallel ausführbar sind, wird Hardwareauslastung plötzlich zu einem echten Hebel.

Das macht kleine Modelle strategisch interessant. Sie sind nicht nur billiger. Sie sind besser komponierbar. Ein großer Monolith verschluckt alle Aufgaben in einem schwarzen Kasten. Kleine Spezialisten machen die Pipeline lesbarer: Wer macht was, wie viel Speicher kostet es, welche Stufe ist der Engpass, wo lohnt Quantisierung, wo nicht?

Gerade für geisten ist das die produktivere Richtung. Nicht noch ein großer Assistent, der alles behauptet zu können, sondern ein Ensemble kleiner, kontrollierbarer Pfade mit klaren Rollen.

Wo die Grenze liegt

Natürlich ist Parallelität kein Gratisgewinn. Sie erhöht Scheduling-Komplexität, kann Speicher stärker fragmentieren und bringt auf hochgradig sequenziellen Aufgaben wenig. Wenn ein einzelnes Ergebnis mit minimalster Latenz im Vordergrund steht, bleibt der direkte Single-Pfad oft überlegen.

Auch muss man sauber unterscheiden zwischen Durchsatzgewinn und Einzellatenzgewinn. Mehr Parallelität macht nicht automatisch jede Antwort schneller. Sie macht das System oft produktiver, wenn mehrere Ergebnisse gleichzeitig gebraucht werden.

Die richtige Frage lautet deshalb nicht: “Ist Parallelität besser?” Sondern: “Für welche Arbeitslast ist Parallelität die bessere Betriebsform?”

Fazit

Unsere Messungen auf dem M1 Max zeigen eine einfache, aber wichtige Wahrheit. Wenn mehrere Ergebnisse gleichzeitig gebraucht werden, schlagen kleine parallele Spezialisten den monolithischen Einzelpfad oft schon auf derselben Hardware.

Der Vorteil entsteht nicht aus Magie, sondern aus besserer Auslastung. Kleine Modelle lassen sich parallel betreiben, quantisierte Artefakte entlasten das Speichersystem, und die Gesamtzeit bis zum Ergebnis sinkt. Für viele reale KI-Workloads ist das wertvoller als die Vorstellung eines einzelnen großen Modells, das alles zugleich erledigen soll.

Die eigentliche Zukunft könnte daher weniger im nächsten Monolithen liegen als in besseren Kompositionen kleiner Modelle.

Abbildungen

Weiterführende Quellen

Wenn Sie kleine Modelle, Quantisierung und parallele Inferenz in robuste Produktpfade übersetzen möchten, sprechen Sie uns gerne an: info@geisten.com