Warum nicht jede KI-Aufgabe das größte Modell erfordert: ressourcensensibles Design

Eines Betrugspräventions-Systems, vier verschiedene Aufgaben

Betrachten Sie, womit ein einziges System zur Betrugserkennung umgehen muss. Ein Domainname muss möglicherweise mit bekannten Bedrohungsinformationen abgeglichen werden. Eine Rechnung muss mit den festgelegten Zahlungsdetails eines Lieferanten verglichen werden. Ein unklarer E-Mail-Text erfordert eine Interpretation im Kontext, und manipulierte Audio- oder Videodateien können ein weitaus aufwendigeres Analysemodell erfordern. All das zählt zu den Sicherheitsaufgaben, ist aber aus rechnerischer Sicht kein und dasselbe Problem.

Trotzdem bieten moderne KI-Systeme einen verlockenden Kurzweg: Alles an das leistungsstärkste allgemeine Modell weiterleiten und es die Entscheidung treffen lassen. Das ist sicherlich einfach. Es kann jedoch auch unnötig teuer, langsam, eine Einmischung in die Privatsphäre darstellen, schwer zu kontrollieren sein oder einfach nicht für die Aufgabe geeignet sein. Mit „leistungsstärkstes“ ist hier das stärkste oder umfangreichste allgemeine Modell gemeint – und nicht einfach nur das mit den meisten Parametern.

Daher ändert sich die wichtige Designfrage. Anstatt zu fragen, welches das leistungsstärkste verfügbare Modell ist, sollte man fragen, welcher der am wenigsten komplexen Mechanismen dennoch die Anforderungen an Qualität und Risiko der Aufgabe erfüllt. Manchmal handelt es sich dabei um ein leistungsstarkes Allzweckmodell. Manchmal um ein kleineres, spezialisiertes Modell. Und manchmal ist das richtige Modell gar kein Modell.

Benchmarks gegen Produktion

Benchmarks zeigen, was ein Modell leisten kann. Die Produktionsarchitektur muss sich mit einer anderen Frage auseinandersetzen: Was soll das System tatsächlich verwenden? Qualität ist nur eine von mehreren Dimensionen. Reale Systeme müssen zudem mit Latenzzielen, Inferenzbudgets, Datenschutzvorschriften, begrenzten Rechenressourcen, Netzwerkbedingungen, Zuverlässigkeitsanforderungen sowie Betriebskosten umgehen.

Ein Modell, das in einem Benchmark die Bestleistung erzielt, eignet sich daher möglicherweise nicht für eine bestimmte Aufgabe. Wenn eine genaue, deterministische Vergleichsanalyse die Entscheidung trifft, bringt zusätzliche Rechenleistung fast nichts. Wenn Daten lokal verbleiben sollen, ändert ihr Versand an einen entfernten Dienst das Bild hinsichtlich Privatsphäre und Sicherheit. Und wenn ein Geschäftsprozess innerhalb einer strengen Zeitgrenze antworten muss, darf die Wahl nicht allein auf der Modellqualität beruhen.

Eine Möglichkeit, dies zu formulieren: Ein geeigneter Mechanismus vereint ausreichende Qualität, akzeptables Risiko und akzeptable Betriebskosten. Das bedeutet nicht, die günstigste Option auszuwählen, da ein billiger Mechanismus, der die Aufgabe nicht bewältigt, unzureichend ist. Es bedeutet vielmehr, dass zusätzliche Funktionen ihren höheren Preis rechtfertigen müssen.

Was die Routing-Forschung zeigt

Die Idee wird in der Forschung zu Modell-Routing immer deutlicher sichtbar. Anstatt davon auszugehen, dass jede Anfrage an ein Premium-Modell geht, haben Forscher Systeme entwickelt, die je nach Anfrage und benötigter Leistung ein geeignetes Modell auswählen.

Der Artikel „FrugalGPT“ von Chen, Zaharia und Zou (2024) bewertete Kaskaden aus verschiedenen Sprachmodellen. Durch sorgfältige Kombination dieser Modelle konnten die Inferenzkosten erheblich gesenkt werden, ohne dass die Zielleistung beeinträchtigt wurde; in einigen getesteten Szenarien betrugen die erzielten Einsparungen bis zu 98 %. RouteLLM (Ong et al., 2025) ging noch einen Schritt weiter, indem es lernte, wann eine Anfrage an ein stärkeres oder schwächeres Modell gesendet werden sollte. Auf seinen öffentlichen Benchmarks wurden Einsparungen von mehr als dem Doppelten ohne Qualitätsverlust im Vergleich zur Referenzkonfiguration gemeldet.

Diese Zahlen stellen keine Garantien für die Produktivität dar. Sie hängen von den Modellen, Benchmarks, Preisstrukturen sowie den Routierungsmethoden in jedem Experiment ab. Dennoch bleibt der architektonische Grundsatz bestehen: Die maximale Leistungsfähigkeit muss nicht der Standardbetriebspunkt sein.

Spezialisten, Regeln und genaue Vergleiche

Das Mischen von Modellen bedeutet nicht nur das Auswählen zwischen zwei allgemein einsetzbaren LLMs. Wenn eine Aufgabe streng begrenzt ist, kann Spezialisierung manchmal die Rolle der reinen Größe übernehmen. Pecher, Srba und Bielikova (2025) setzten kleine, spezialisierte Modelle gegen große, allgemein einsetzbare Modelle in acht Aufgaben der Textklassifizierung ein, und mit einer recht geringen Menge an gelabelten Datensätzen konnten die kleinen Modelle bei einigen spezifischen Problemen den großen Modellen gleichkommen oder sie sogar übertreffen.

Doch es gibt eine Grenze. Ein kompakter Klassifikator, der für einen bestimmten Zweck trainiert wurde, kann nicht als leistungsstarkes allgemeines Modell dienen, sobald die Aufgabe umfassendes Denken, unbekannte Situationen, Interpretationen über verschiedene Modalitäten oder Wissen jenseits der Trainingsdaten erfordert. Doch eng gefasste, wiederkehrende Probleme ändern die Mathematik: Wenn ein System immer wieder eine gut definierte Operation ausführt, muss es möglicherweise keine umfassenden Fähigkeiten entwickeln, die es nie benötigt. Auch die Forschung im Bereich der Routenplanung bewegt sich in diese Richtung. BEST-Route (Ding et al., 2025) fragt nicht nur nach dem Modell, das eine Anfrage bearbeiten sollte, sondern auch danach, wie viel Rechenzeit für die Prüfung der Anfrage erforderlich ist.

Die zugrundeliegende Idee ist einfach. Verschiedene Arbeitslasten liegen in unterschiedlichen Leistungsbereichen, und eine Architektur lohnt sich, wenn sie diese voneinander unterscheiden kann.

Betrachten wir weiterhin einfachere Operationen:

• die Entscheidung, ob zwei normalisierte Kontoinhaberidentifikatoren übereinstimmen
• Überprüfung, ob eine Transaktion einen festgelegten Schwellenwert überschreitet
• Prüfung, ob eine Domain zu einer im Cache gespeicherten Menge gehören könnte
• Erkennung, ob ein erforderliches Feld in einem strukturierten Datensatz fehlt

Keine dieser Aufgaben ist von Natur aus semantisch. Das Senden eines genauen Vergleichs über ein Sprachmodell verwandelt eine deterministische Aufgabe in eine probabilistische, führt zu zusätzlichem Inferenzaufwand und schafft eine weitere Möglichkeit zum Scheitern. Das ist einer der Gründe, warum Konzepte, die deterministische und gelernte Mechanismen kombinieren, überzeugender wirken als der Einsatz von KI in jedem Komponenten. Neurosymbolische Ansätze in der Cybersicherheit weisen in dieselbe Richtung: Gelernte Komponenten tragen zum Mustererkennen bei, während symbolische oder regelbasierte Komponenten explizites Reasoning und Kontrolle ermöglichen (Bizzarri et al., 2025).

Regeln sind natürlich nicht überall vorteilhaft. Sie werden anfällig, wenn die Sprache unklar ist, sich das Verhalten ändert, Angreifer Paraphrasen verwenden, die niemand erwartet hat, oder das System generalisieren muss, über das hinaus seine Entwickler gedacht haben. Der eigentliche Unterschied liegt nicht in Regeln gegen KI, sondern darin, ob die Aufgabe tatsächlich Schlussfolgerungen erfordert. Wo eine Bedingung genau formuliert werden kann, ist deterministische Logik eine hervorragende Ingenieurslösung. Wo Bedeutung, Unsicherheit oder Generalisierung eine Rolle spielen, finden gelernte Modelle ihren Platz. Eine ausgereifte Architektur kommt mit beidem zurecht.

Dieselbe Disziplin für Multi-Agenten-Systeme

Mehre-Agenten-Systeme verdienen dieselbe sorgfältige Prüfung. Sobald ein Team akzeptiert, dass ein einziges großes Modell nicht alles bewältigen sollte, ist es leicht, zu überkorrigieren und alles in Agenten aufzuteilen, weil das anspruchsvoller erscheint. Die Anzahl der Agenten ist keine Rechtfertigung. Ein Mehr-Agenten-Design macht Sinn, wenn die Verantwortlichkeiten tatsächlich getrennt sind: unterschiedliche Fachkenntnisse, Tools, Berechtigungen oder Datensätze, oder Aufgaben, die wirklich parallel ausgeführt werden können. Shen et al. (2024) untersuchten ein Mehr-LLM-Design für die Tool-Nutzung, bei dem Planung, Tool-Aufruf und Zusammenfassung getrennt wurden, und der Vorteil ergab sich aus dieser funktionalen Trennung.

Ausgehobene Agenten bringen ebenfalls Koordinierungskosten mit sich. Wang et al. (2024) untersuchten mehrere Agenten bei Aufgaben der Argumentation und stellten fest, dass diese nicht immer überlegener sind als starke Baselines mit einem einzigen Agenten, was die Annahme untergräbt, dass das Hinzufügen von Kommunikation zwischen Modellen die Argumentation automatisch verbessert. Auch die Topologie spielt eine Rolle. Li et al. (2024) zeigten, dass die Art und Weise, wie die Agenten miteinander kommunizieren, sowohl die Leistung als auch die Rechenausgaben beeinflusst.

Die daraus resultierende Gestaltungsregel besagt, dass Agenten sich spezialisieren sollten, weil die Arbeitslast dies erfordert. Wenn mehrere Agenten im Wesentlichen denselben Kontext lesen, dieselben Werkzeuge verwenden und sequenzielle Varianten derselben Argumentation durchführen, führt dies in der Architektur vermutlich nur zu erhöhten Overhead-Kosten. Ein einziger Agent mit gut konzipierten Werkzeugen kann die effektivere Lösung sein.

Wo die Berechnungen stattfinden

Die Wahl eines Mechanismus ist nur die halbe Miete, denn er muss auch irgendwo ausgeführt werden. Lokale Geräte, Edge-Infrastrukturen und Cloud-Plattformen haben jeweils ihre Stärken und Grenzen, und Forschungen zum gemeinsamen Inferenzverfahren haben untersucht, wie die Berechnungen auf diese Plattformen verteilt werden können, anstatt davon auszugehen, dass eine Arbeitslast vollständig an einem Ort liegen muss (Zhou et al., 2019; Ren et al., 2023).

Nichts hier funktioniert in jedem Fall. Lokale Ausführung ist nicht automatisch schneller, da die Hardware am Endpunkt schwach sein könnte, während ein optimierter Cloud-Dienst die Aufgabe schneller erledigt. Auch die Ausführung in der Cloud ist nicht automatisch besser, da Netzwerklatenz, Bandbreite, Datensensibilität oder Anforderungen an die Verfügbarkeit das Gleichgewicht verändern können. Datenschutz ist komplizierter als die Annahme „Lokal bedeutet privat“. Die Beibehaltung der Rohdaten auf dem Gerät verringert die Menge an übertragenen Rohdaten, doch die durch geteilte oder gemeinsame Inferenz erzeugten Zwischenrepräsentationen können dennoch sensible Details offenbaren. Higgins et al. (2025) untersuchen die Risiken bei Rekonstruktion und Inferenz in Settings mit geteiltem Lernen.

Die Entscheidung über den Standort ist daher eine systembezogene Entscheidung und keine technologische Präferenz. Es geht nicht darum, ob es sich um Edge- oder Cloud-Lösungen handelt, sondern darum, welche Umgebung die Anforderungen der Arbeitslast angemessen erfüllt.

Eine Fallstudie zum Betrugsschutz

Die Frage wurde konkret, als eine Cybersicherheitsarchitektur entworfen wurde, die darauf abzielte, Schutzmaßnahmen gegen Betrug für kleine und mittelständische Unternehmen zu entwickeln. Die Frage, welches KI-Modell Betrug erkennen sollte, war nie die richtige Herangehensweise. Das Konzept umfasste sehr unterschiedliche Aufgaben: schnelle technische Überprüfungen, strukturierte Vergleiche von Finanzdaten, semantische Interpretation, Anomalieanalyse sowie möglicherweise aufwändigere Medienforensik. Sie als ein einziges Rechenaufgabenpaket zu betrachten, hätte wenig Sinn gemacht.

Das Ergebnis war ein vorgeschlagener dreistufiger hybrider Multi-Agenten-Architekturansatz, der nach zunehmender analytischer Tiefe organisiert ist. Hier ist eine Unterscheidung wichtig: Das dreistufige Design ist eine Zielarchitektur, während das für ein Abschlussprojekt entwickelte, engere Konzept nur einen Teil davon validiert. Es zeigt nicht, dass jedes vorgeschlagene Produktionskomponente tatsächlich existiert oder bereits getestet wurde.

Layer 0: Filtern und Triage

Die erste Schicht ist der kostengünstige, schnelle Teil. Zu den vorgeschlagenen Aufgaben gehören Normalisierung, Überprüfung von Absender und Domain, Authentifizierungssignale, Cache-basierte Prüfungen mit Bloom-Filtern, Einblick in Metadaten von Anhängen sowie deterministische Anhaltspunkte bezüglich finanzieller Risiken. Viele dieser Aufgaben sind aus Gründen der Konzeption keine KI-gestützten Prozesse. Ein Bloom-Filter ist eine schnelle, probabilistische Struktur zur Überprüfung von Elementen und kein Betrugsklassifikator; ein positiver Treffer bedeutet lediglich, dass ein Element möglicherweise in der Menge enthalten ist, weshalb eine Bestätigung weiterhin erforderlich ist. Auch die anderen deterministischen Anhaltspunkte dienen lediglich als Hinweise auf eine Eskalation und stellen keine endgültige Entscheidung dar. Diese Schicht dient dazu, kostspielige Analysen dort zu vermeiden, wo einfachere Hinweise bereits ausreichen, um einen Fall zu klären oder zu eskalieren.

Layer 1: Orchestrierung und Erklärung

Die zweite Schicht stellt den kontrollierten Arbeitsablauf bereit. Im Zieldesign kümmert sich LangGraph um den Zustand, die Knoten, die bedingte Routenplanung sowie den Fluss der Beweise. Ein kleines Sprachmodell kann optional bei der begrenzten semantischen Interpretation oder bei der Formulierung für Benutzer helfen, soll aber nicht für die Entscheidung über Routen, Schweregrade oder hochwirksame Aktionen zuständig sein.

Das ist wichtig, denn das Verwenden eines Sprachmodells innerhalb eines Systems erfordert nicht, dass es die Kontrolle über das System erhält. Die Orchestrierungsschicht kann begrenzen, wo die Modelle arbeiten dürfen, welche Beweise sie sehen und welche nachgelagerten Aktionen ihnen zur Verfügung stehen. Sie kann außerdem Analyse von Erklärung trennen: Zunächst werden strukturierte Beweise erstellt, anschließend werden die unterstützten Erkenntnisse in verständliche Sprache umgewandelt.

Schicht 2: spezialisierte analytische Agenten

Die dritte Schicht enthält die tiefere Analyse. Das Zielkonzept trennt die Analyse von Texten und Rechnungen, die Erkennung von Anomalien sowie die rechenintensive audio- oder videoanalytische Verarbeitung. Für diese Funktionen sind nicht unbedingt dasselbe Modell, derselbe Datenzugriff oder dieselbe Ausführungsumgebung erforderlich. Genau hier wird die Idee der Mehragentensysteme nützlich – nicht als Behauptung, dass mehr Agenten mehr Intelligenz bedeuten, sondern als Möglichkeit, wirklich unterschiedliche analytische Aufgaben darzustellen.

Interessanter ist weniger die Anzahl der drei Schichten als vielmehr die Idee, die sie vermitteln: Die Rechenleistung sollte proportional zum zu lösenden Problem sein.

Was die Konzeptdemonstration zeigte

Das umgesetzte Proof-of-Concept war absichtlich eingeschränkter. Es nutzte synthetische Szenarien zur Kompromittierung von Anbieter-E-Mails sowie zur Umleitung von Rechnungen in Kombination mit einem deterministischen LangGraph StateGraph. Der Workflow behielt den zentralisierten Zustand bei, folgte expliziten Routing-Pfaden, extrahierte strukturierte Risikofaktoren aus Texten und Rechnungen, aggregierte die Schweregrade deterministisch und erzeugte auf Belegen basierende Warnungen. Er umfasste ein verdächtiges Szenario, ein sicheres Basisszenario sowie einen kontrollierten Fehlerrouting-Pfad, wobei automatisierte Tests sowie lokale Ausführung genutzt wurden.

Mehrere Aspekte wurden weggelassen: der vollständige Produktionsworkflow für Layer 0, die Live-Integration mit Microsoft 365 oder Google Workspace, die Produktions-OCR-Funktion, das federierte Lernen, die auf VAE basierende lokale Anomalieerkennung, die vertrauliche Verarbeitung von Medieninhalten sowie die Erkennung von Deepfakes in Audio- oder Videomaterial. Der Umfang ist entscheidend. Der Proof of Concept zeigt, dass der Workflow realisierbar ist. Er beweist jedoch nichts über die Genauigkeit in der Produktion, die Skalierbarkeit oder die Überlegenheit des vollständigen dreistufigen Designs.

Eine engere Erkenntnis wurde dennoch bestätigt: In diesem Workflow musste kein Sprachmodell jede Entscheidung steuern. Zunächst kamen strukturierte Belege, diese wurden von expliziter Logik bewertet, und erst danach wurden sie in eine für Menschen verständliche Warnung umgeschrieben. Die Trennung der Überlegungsfähigkeit von der Entscheidungsbefugnis gehörte zu den nützlichsten architektonischen Erkenntnissen.

Komplexität hat ihren Preis

Eine heterogene Architektur ist nicht kostenlos:

• Jeder Router kann die falsche Route wählen.
• Eine Kaskade kann Verzögerungen verursachen, bevor das teure Modell eingesetzt wird, das die ganze Zeit benötigt wurde.
• Mehrere Modelle bedeuten mehr Evaluierung, Hosting und Versionsverwaltung.
• Mehr-Agenten-Designs führen zu Kosten für Kommunikation und Koordination.
• Komponenten, die in der Nähe des Benutzers laufen, müssen über verschiedene Endpunkte versandt, gepatcht und überwacht werden.
• Das Verteilen von Daten erweitert die Angriffsfläche für Sicherheitslücken, Blindstellen und Ausfälle.

Es gibt einen ernsthaften Gegenargument: Manchmal ist ein einzelnes, leistungsstarkes Modell die einfachste und beste Lösung. Wenn es die erforderlichen Anforderungen hinsichtlich Qualität, Latenz, Datenschutz, Zuverlässigkeit und Kosten erfüllt, kann das Hinzufügen von Routern, spezialisierten Modellen oder zusätzlichen Agenten mehr Betriebskomplexität verursachen, als es wert ist. Das steht im Widerspruch zum ressourcensensiblen Prinzip – im Gegenteil, es gehört dazu, da auch die Komplexität sich rechtfertigen muss.

Das Ziel besteht nicht darin, Modelle zu verkleinern, die Anzahl der Agenten zu maximieren oder Berechnungen an den Edge zu verlagern, nur weil Edge Computing interessant ist. Das Ziel ist vielmehr, nicht mit Geld, Latenz, Datenschutzrisiken oder ingenieurtechnischem Aufwand für Funktionen zu zahlen, die die Arbeitslast nicht benötigt.

Beginnen Sie bei der Arbeitslast

Bevor man ein Modell auswählt, sind eine Reihe einfacherer Fragen sinnvoller:

• Könnte eine genaue Regel, ein Vergleich oder eine Abfrage die Aufgabe erledigen? Wenn ja, ist möglicherweise überhaupt keine Inferenz notwendig.
• Ist die Aufgabe eng gefasst und häufig genug, um einen Spezialisten zu rechtfertigen?
• Braucht sie wirklich semantisches Reasoning oder umfassende Generalisierung?
• Wo können die Daten verarbeitet werden, ohne die Grenzen bezüglich Latenz, Sicherheit oder Privatsphäre zu überschreiten?
• Was passiert, wenn das gewählte Verfahren falsch ist, und kann der Arbeitsablauf sicher eskaliert werden?
• Falls mehrere Agenten in Betracht kommen, haben sie unterschiedliche Verantwortlichkeiten, Tools oder Daten – oder wird eine Aufgabe nur aufgeteilt, weil das anspruchsvoller erscheint?

Nur wenn diese Fragen beantwortet sind, wird die Auswahl eines Modells sinnvoll. Dies kehrt eine gängige Praxis um, bei der zunächst das beeindruckendste Modell ausgewählt wird und anschließend Aufgaben dafür gesucht werden. Beginnen Sie mit der Arbeitslast und lassen Sie deren Einschränkungen das Verfahren bestimmen.

Große Allzweckmodelle sind nach wie vor hervorragende Werkzeuge, und ein ressourcensensibles Design bedeutet nicht, sie zu meiden. Es bedeutet vielmehr, ihre Fähigkeiten dort einzusetzen, wo sie den größten Nutzen bringen. Deterministische Operationen sollten deterministisch bleiben, sofern das ausreicht. Spezialisierte Modelle sollten die Möglichkeit haben, sich weiter zu spezialisieren. Das leistungsstärkere Allzweckmodell sollte nur mit Aufgaben betraut werden, die tatsächlich seine logische Verarbeitungskapazität benötigen. Ein Mehr-Agentensystem sollte nur dann existieren, wenn eine echte Spezialisierung dies erfordert. Kurz gesagt: Verwenden Sie den einfachsten Mechanismus, der die Anforderungen an Qualität und Risiko der Arbeitslast angemessen erfüllt.

Sobald das leistungsstärkste Modell nicht mehr als Ziel angesehen wird, stellt sich unweigerlich die weitere Frage: Wie soll das System entscheiden, wohin jede Arbeitslast geht? Diese Frage nach der Routenwahl, also der Verteilung der Rechenleistung je nach Arbeitslast, ist das nächste logische Problem.

Referenzierte Forschung

• Chen, Zaharia und Zou (2024): FrugalGPT – kaskadierte Sprachmodelle zur Kostensenkung
• Ong et al. (2025): RouteLLM – Lernen des Routenfindens zwischen Modellen anhand von Präferenzdaten
• Ding et al. (2025): BEST-Route – adaptives Routing unter Verwendung von Rechenressourcen zum Testzeitpunkt
• Pecher, Srba und Bielikova (2025): kleine spezialisierte Modelle gegenüber großen allgemeinen Modellen für die Textklassifizierung
• Bizzarri et al. (2025): Übersicht über neurosymbolische KI für die Erkennung von Netzwerkeinbrüchen
• Shen et al. (2024): Ein multi-LLM-Agent für das Lernen von Werkzeugen
• Wang et al. (2024): Ob diskutierende Mehragentensysteme das Schlussfolgern von LLMs verbessern
• Li et al. (2024): Spärige Kommunikationstopologie in Mehragentendebatten
• Zhou et al. (2019) und Ren et al. (2023): Übersichten zu Edge-Intelligenz und kooperativer DNN-Inferenz

Higgins et al. (2025): privacy-preservierendes Split-Learning gegen feindliche Inferenz