onisin OS
2026-05-27

Mehrstufige LLM-Architektur: Warum Onisin OS für die kommende Welt gebaut ist

Teil 6 der Serie LLM-Systeme in der Praxis. 1. Event-basierte Daten — wie landen Daten im System? 2. Embeddings und RAG — wie werden sie durchsuchbar? 3. Eino vs. LangGraph — wie nutzt ein Agent das alles? 4. Kein Entscheidungsbaum mehr — Absichten verstehen ohne Regeln 5. LLM für Unternehmen — was wirklich zählt 6. Mehrstufige LLM-Architektur (dieser Post)

Wenn man heute mit Entscheidern in größeren Firmen über KI-Infrastruktur spricht, ist die Annahme im Hintergrund meistens dieselbe: Modelle laufen in einer Cloud, Anwendungen rufen sie über eine API auf, Daten reisen hin und zurück. Das ist die Architektur, die OpenAI und die großen Cloud-Anbieter seit 2023 etabliert haben, und sie hat ihre Berechtigung.

Ich glaube allerdings, dass sie ein Übergangszustand ist. In fünf Jahren wird die Frage “wo läuft das LLM” nicht mehr binär beantwortet, sondern in Ebenen — vom Schreibtisch des einzelnen Mitarbeiters über die Abteilung bis zum zentralen Rechenzentrum. Die Firmen, die heute schon so bauen, dass ihre Software diese Topologie unterstützt, werden in fünf Jahren bessere Kostenkurven, bessere Datenschutz-Stories und bessere Resilienz haben.

Dieser Post ist der Versuch, drei Entwicklungen zusammenzubringen, die gerade gleichzeitig laufen, und zu beschreiben, warum ich Onisin OS für die Welt danach für besonders gut vorbereitet halte. Nicht weil wir die Zukunft vorhergesagt hätten. Sondern weil ein paar frühe Architektur-Entscheidungen sich rückblickend als Vorteil herausstellen.

Drei Entwicklungen, die zusammenwirken

Kleine Modelle werden überraschend gut. Ein Gemma 4 4B im Jahr 2026 ist besser als GPT-3.5 vor zwei Jahren. Ein Llama 3 8B kann viele Klassifikations- und Extraktions-Aufgaben so gut wie das große Modell vor einem Jahr. Die Schere zwischen kleinem lokalem Modell und großem Cloud-Modell schließt sich für siebzig bis achtzig Prozent der Business-Aufgaben. Es wird nicht alles lokal lösbar, aber sehr viel mehr als noch vor einem Jahr.

Hardware für lokale Inferenz wird ernsthaft. Ein Mac Studio mit M5 Ultra wird vermutlich 256 GB und mehr Unified Memory haben. Das reicht für ein 70B-Modell in 4-bit oder mehrere mittlere Modelle parallel. NVIDIA hat mit DGX Spark eine Desktop-Box angekündigt, AMD mit Strix Halo eine vergleichbare Klasse. Die Vorstellung “ein LLM-fähiger Rechner am Arbeitsplatz” ist nicht mehr akademisch, sondern wird in den nächsten Jahren Mainstream.

Klassische strukturierte Filter holen sich Aufmerksamkeit zurück. Die Welle der reinen Vektor-Suche von 2023 und 2024 ebbt ab. Firmen merken, dass eine realistische Anfrage selten “finde alle Dokumente die semantisch ähnlich sind” lautet. Sie lautet “finde alle Dokumente von Gerd Müller aus Köln im Zeitraum Januar bis Dezember 2024 mit fraud-relevanten Mustern”. Die ersten drei Filter sind klassisches SQL-Territorium und filtern Millionen Dokumente in Millisekunden auf ein paar Hundert runter. Erst dann kommt der LLM ins Spiel.

Diese drei Entwicklungen zusammen ergeben ein neues Bild: viele Anfragen kommen mit kleinen Datenmengen (nach SQL-Filterung), brauchen schnelle Antworten (interaktive Workflows) und können von mittelgroßen Modellen bedient werden. Das ist genau das Profil, für das Edge-Compute gut ist.

Compute auf mehreren Ebenen

Ich denke seit einer Weile in folgender Hierarchie:

Jede Ebene macht das, was sie am besten kann. Und das Schöne: jede Ebene ist optional. Ein kleiner Standort hat nur Workstations plus zentrale Farm. Ein großer Standort kann die Department-Ebene ausbauen. Man wächst in die Tiefe rein, wo es sich lohnt.

Das ist kein neues Muster. Wir hatten das schon vor der Cloud: Workstations am Arbeitsplatz, Abteilungs-Server, Konzern-Rechenzentrum. Cloud hat das für fünfzehn Jahre eingedampft auf “alles in der Cloud, Endgerät ist nur Anzeige”. Jetzt schwingt es zurück — nicht weil die Cloud schlecht wäre, sondern weil die Rechenleistung an der Edge plötzlich verfügbar ist. Compute pendelt zwischen zentral und Edge, je nachdem ob die Daten oder die Hardware-Knappheit dominiert. Wir hatten zehn Jahre “Daten sind groß, GPUs sind selten, also zentral”. Jetzt: “vorgefilterte Daten sind klein, GPUs werden Commodity am Arbeitsplatz, also Edge”.

Was die Verschiebung von Software fordert

Die meisten heutigen LLM-Anwendungen sind für eine andere Welt gebaut. Sie kodieren einen Cloud-Endpoint hart: https://api.openai.com/v1. Sie nehmen an, dass es genau einen LLM-Provider gibt. Sie behandeln den LLM-Aufruf als monolithischen externen Service-Call.

Für eine mehrstufige Welt funktioniert das nicht. Was eine Anwendung braucht, ist anders:

Modell-Endpoint-Discovery. Die Anwendung sagt “ich brauche ein Klassifikations-Modell”, nicht “ich rufe gpt-4 auf api.openai.com auf”. Welcher physische Endpunkt dahinter steht, entscheidet die Runtime basierend auf der aktuellen Topologie. Im Hauptquartier mit lokaler GPU-Farm geht es dorthin; in einer Zweigstelle mit eigenem Mac Studio geht es lokal; bei Ausfall eskaliert es zur Cloud.

Modell-Capability-Awareness. Die Anwendung beschreibt, was sie braucht — Mindest-Context-Window, Vision-Fähigkeit, Function-Calling. Die Runtime matcht das gegen verfügbare Modelle und wählt das nächstgelegene, das die Anforderungen erfüllt.

Daten-Lokalitäts-Constraints. Die Anwendung kann sagen “diese Daten dürfen das Department nicht verlassen”. Die Runtime respektiert das, indem sie keinen LLM auf einer höheren Ebene aufruft — selbst wenn dort schneller wäre. Das ist Compliance, die im Code lebt, nicht im PDF.

Wo Onisin OS ansetzt

Das Pipeline-DSL in Onisin OS war ursprünglich nicht für mehrstufige LLM-Topologien gedacht. Es entstand aus dem pragmatischen Bedürfnis, deklarativ zu beschreiben, wie eine Folge von Daten-Operationen und LLM-Aufrufen abläuft. Eine Pipeline sieht etwa so aus:

pipeline "Fall-Analyse" {
  source db schaeden from pipeline_documents
  llm    "gemma4:e4b-mlx"

  step where vorauswahl {
    from schaeden
    where { ort: "Köln", zeitraum: "2024" }
    limit 300
  }

  step llm analyse {
    from   vorauswahl
    mode   per-row
    prompt "Prüfe diesen Schadensfall auf Ungereimtheiten."
  }

  step llm zusammenfassung {
    from   analyse
    mode   aggregate
    prompt "Erstelle eine Risiko-Zusammenfassung."
  }
}

Die Pipeline sagt, was geschehen soll, nicht wo. Modell-Auswahl und Modell-Ausführung sind getrennt. Das war ursprünglich eine Entscheidung für Lesbarkeit und Re-Use — derselbe Pipeline-Code soll auf verschiedenen Modellen laufen können, weil sich Modelle schneller ändern als Geschäftslogik.

Im Rückblick stellt sich diese Trennung als Vorbereitung auf die mehrstufige Welt heraus. Was die Pipeline als llm "gemma4:e4b-mlx" bezeichnet, kann der Runner heute auf einen lokalen Ollama-Endpunkt auflösen. In einer mehrstufigen Welt löst er es auf das nächstgelegene verfügbare Modell auf, das den Capabilities entspricht — Mac Studio in der Abteilung, GPU-Server im Standort, zentrale Farm im Konzern. Die Pipeline-Definition bleibt identisch. Der Bearbeiter, der die Pipeline startet, sieht keine Topologie. Der Pipeline-Autor weiß im Regelfall nicht einmal, dass es eine Topologie gibt.

In der Praxis lassen sich darauf weitere Eigenschaften aufsatteln, die für mehrstufige Compute relevant werden:

pipeline "Fall-Analyse" {
  llm           "fraud-analyzer"     // logischer Name
  data_locality "department"         // verlässt Abteilung nicht
  fallback      "central-llama-70b"  // bei Eskalation
  ...
}

Die Pipeline trägt ihre Anforderungen explizit. Der Runner verhandelt sie mit der verfügbaren Topologie zur Laufzeit. Bei Capability-Mismatch fällt der Runner auf das Fallback zurück; bei Locality-Verletzung schlägt die Pipeline lieber fehl, als die Daten zu exportieren.

Coarse-to-Fine als Architekturprinzip

Es gibt einen zweiten Vorteil, der mit dem ersten verwandt ist. Onisin filtert klassisch-strukturiert, bevor es LLM-Compute aufruft. Aus hundert Millionen Dokumenten werden per SQL-Filter ein paar Hundert. Aus den paar Hundert macht der LLM die fachliche Analyse. Billige Filter zuerst, teure Analyse zuletzt.

Dieses Muster ist in der mehrstufigen Welt besonders wertvoll. Wenn nach dem SQL-Filter nur 300 Dokumente übrig sind, ist die Compute-Menge so klein, dass sie überall hinpasst — der lokale Mac Studio kann sie in 5-15 Minuten verarbeiten, ohne dass die zentrale GPU-Farm involviert sein muss. Hätte die Pipeline alle hundert Millionen Dokumente erst durch den LLM jagen wollen, wäre das zwingend ein Batch-Job auf zentraler Hardware.

Das heißt: strukturierte Vorfilterung ist nicht nur eine Kosten-Optimierung, sondern auch eine Topologie-Befähigung. Sie verwandelt einen Workload, der zentral laufen muss, in einen Workload, der lokal laufen kann.

Department-Compute als organisatorische Möglichkeit

Wenn man die Hierarchie ernst nimmt, wird die Department-Ebene interessant — die in der heutigen Cloud-Welt gar nicht vorgesehen ist. Vor zwei Jahren hätte “ein LLM-Server pro Abteilung” geheißen: 8x A100-Server, hundertfünfzigtausend Euro, sechs Kilowatt Stromverbrauch, eigener Serverraum nötig. Das ergab pro Abteilung keinen Sinn — also zentral.

Heute: ein Mac Studio steht unter dem Schreibtisch, zieht hundert Watt, kostet wie ein guter Business-Laptop. Die physische Hürde ist weg. Damit wird die Frage “wo platziere ich Compute” plötzlich eine organisatorische Frage, nicht eine technische.

Was das strukturell ermöglicht:

Fachspezifische Modelle pro Abteilung. Die Rechtsabteilung hat andere Anforderungen als Vertrieb hat andere Anforderungen als Schadensregulierung. Heute kriegen alle dasselbe Modell, weil eine zentrale GPU-Farm nicht zwanzig verschiedene Modelle gleichzeitig hosten will. Mit Department-Compute kann jede Abteilung ihr eigenes Fine-Tune fahren, das mit den Daten der Abteilung über die Jahre besser wird.

Datensouveränität wird Architektur, nicht Policy. Heute schreibt man in eine Policy, dass personenbezogene Daten nicht zu externen LLM-Providern dürfen. Dann hofft man, dass sich alle dran halten. Mit Department-Compute macht man es strukturell unmöglich: die Daten der Schadensregulierung können das Schadensregulierungs-Netzsegment nicht verlassen, weil der LLM dort steht. Es gibt keinen Pfad raus, der nicht durch eine bewusst geöffnete Tür geht. Das ist der Unterschied zwischen “wir vertrauen darauf, dass unsere Daten in der richtigen Jurisdiktion bleiben” und “unsere Daten können gar nicht woanders hin”. Für Branchen, in denen Datensouveränität eine harte Anforderung ist — Versicherung, Gesundheit, öffentlicher Sektor, Verteidigung — ist das nicht ein nettes Extra, sondern die Grundbedingung dafür, überhaupt LLMs einsetzen zu dürfen.

Abteilungs-Verantwortung wird sichtbar. Die Schadensabteilung hat ihren eigenen LLM, ihre eigenen Pipelines, ihre eigene Kostenstelle. Wenn die LLM-Nutzung explodiert, sehen sie das in ihrer Stromrechnung und ihrem Hardware-Budget. Heute ist die zentrale GPU-Farm eine Black-Box-Cost-Center, in der niemand sieht, wer wofür wie viel verbraucht.

Resilienz. Zentrale GPU-Farm fällt aus, tausend Mitarbeiter haben kein LLM. Department-Compute fällt aus, dreißig Mitarbeiter sind betroffen, der Rest arbeitet weiter.

Was zentral bleibt

Ich will nicht den Eindruck erwecken, dass alles an die Edge wandert. Eine ehrliche Architektur sieht weiterhin zentrale Komponenten vor:

Der Unterschied ist: in der heutigen Welt geht jede LLM-Anfrage durch die zentrale Farm. In der mehrstufigen Welt geht nur das durch sie, was wirklich dort hingehört. Der Rest wird lokal beantwortet. Das ist nicht Ablehnung der Cloud — das ist arbeitsteilige Architektur.

Die These

Wenn ich die These dieses Posts in einem Satz fassen müsste: die LLM-Anwendungs-Architekturen der nächsten Jahre werden nicht durch das Modell der Wahl entschieden, sondern durch die Frage, wie gut die Anwendung mit einer mehrstufigen Compute-Welt umgeht.

Onisin OS ist dafür gut positioniert. Nicht weil wir besonders weitsichtig waren, sondern weil drei frühe Entscheidungen zusammenwirken:

  1. Pipeline-DSL trennt Modell von Daten. Was die Pipeline tut, ist unabhängig davon, welches Modell die Aufgabe übernimmt.
  2. Strukturierte Filterung vor LLM-Compute. SQL und Indexe machen die meiste Arbeit; der LLM ist die teure Spitze, nicht der Standard-Pfad.
  3. NATS als Transport-Schicht. Anfragen sind keine HTTP-Punkt-zu-Punkt-Verbindungen, sondern Subject-basierte Nachrichten. Wer auf ein Subject antwortet, ist nicht in der Anfrage festgeschrieben. Das ermöglicht Topologie-Wechsel, ohne dass die Anwendung etwas merkt.

Die nächste Stufe der Onisin-Entwicklung wird sich darum drehen, diese latenten Vorteile explizit nutzbar zu machen — Modell-Routing mit Topologie-Awareness, Daten-Lokalitäts-Constraints im DSL, Fallback-Ketten für Eskalation. Das ist keine grundlegende Architektur-Änderung. Es ist die natürliche nächste Schicht auf einer Architektur, die schon die richtigen Trennungen vorgenommen hat.

Die Firmen, die heute LLM-Anwendungen bauen und dabei jeden Aufruf hart gegen ein einziges Cloud-API-Endpoint verdrahten, werden in fünf Jahren eine teure Migration vor sich haben. Wer früh deklarativ arbeitet und Modell von Ort entkoppelt, hat diese Migration nicht.

Das ist der Vorteil, den ich mit “für die Zukunft gebaut” meine. Nicht dass wir wüssten, wie die Zukunft aussieht. Sondern dass die Entscheidungen, die wir getroffen haben, mit mehreren plausiblen Zukünften kompatibel sind. In einer Branche, die sich monatlich neu erfindet, ist das vielleicht der robusteste Vorteil, den eine Architektur haben kann.

← Zurück zur Übersicht © 2026 Frank & Tristan von Schrenk