Am 6. Februar 2026 hat Perplexity den Model Council gestartet. Eine eingehende Anfrage geht parallel an drei Frontier-Modelle: Claude Opus 4.6, GPT-5.2 sowie Gemini 3.0. Claude Opus 4.5 fungiert als Chair, aggregiert die Antworten und gibt eine konsolidierte Ausgabe zurück. Das Ergebnis laut CJR-Benchmark im Consumer AI Report Q1 2026: 94 Prozent Answer Accuracy für Perplexity Sonar Pro, dazu die niedrigste Halluzinationsrate der getesteten Systeme.
Das ist nicht Marketing. Das ist die Bestätigung eines Befunds, der seit Sommer 2025 in der Forschung steht und den die meisten KI-Verantwortlichen in deutschen Unternehmen noch nicht gelesen haben.
Kaesberg et al. haben in arXiv 2502.19130 (ACL 2025 Workshop) Multi-Modell-Voting gegen Single-Best-Modelle gemessen. Auf Reasoning-Aufgaben gewinnt Voting um 13,2 Prozentpunkte. Der MATH-Benchmark macht die Größenordnung greifbar: 67,3 Prozent für die Voting-Methode, 54,1 Prozent für das beste Einzelmodell. Auf Knowledge-Recall gewinnt Konsensus, also der Mehrheitsentscheid mit Übereinstimmungspflicht, um 2,8 Prozentpunkte. Beide Effekte sind statistisch signifikant und replizierbar.
Die falsche Grundsatzentscheidung heißt “welches Modell”
Wer 2026 in einem Strategiepapier schreibt “wir standardisieren auf Anbieter X”, optimiert auf eine Frage, die den Performance-Hebel verfehlt. Die richtige Frage lautet nicht “welches Modell”, sondern “welche Architektur”.
Der Unterschied ist nicht akademisch. Eine Single-Model-Architektur baut auf zwei Annahmen. Erstens gibt es ein bestes Modell. Zweitens ist die Lücke zum zweitbesten groß genug, um die Spezialisierungsverluste zu kompensieren. Beide Annahmen tragen im Mai 2026 nicht mehr. Die Frontier-Modelle liegen in aggregierten Rankings drei bis vier Punkte auseinander, in spezialisierten Aufgabenprofilen aber zehn bis dreißig Prozent. Wer auf eines standardisiert, gewinnt eine Achse und verliert mehrere andere.
Der Kaesberg-Befund macht das sichtbar. Voting ist nicht ein bisschen besser als das beste Einzelmodell. Voting ist auf Reasoning-Aufgaben strukturell besser, weil verschiedene Modelle verschiedene Fehlertypen produzieren und ein Voting-Mechanismus die unkorrelierten Fehler herausmittelt. Das ist kein Marketing-Effekt. Das ist Statistik.
Apple zieht 2026 nach, und das ist die wichtigere Nachricht
Apple hat in der iOS-27-Roadmap ein Multi-Provider-Routing für Siri angekündigt. Anfragen werden automatisch an den jeweils spezialisierten Anbieter geroutet: Claude für Schreiben, GPT für Code, Gemini für Suche. Die Nachricht ist nicht, dass Apple endlich KI ernst nimmt. Die Nachricht ist die implizite Aussage hinter dem Architektur-Entscheid.
Apple hätte einen Exklusivvertrag mit einem Anbieter verhandeln können. Das Unternehmen hat es nicht getan. Stattdessen baut der weltweit profitabelste Hardware-Hersteller seine Default-KI als Multi-Provider-Stack. Wenn der Konzern, der für seine Vendor-Lock-Strategien bekannt ist, sich gegen einen Lock entscheidet, hat das einen Grund: Es gibt im Frontier-Bereich kein Modell, das in allen Kategorien führt. Apple ratifiziert damit, was Perplexity bereits operativ macht.
Was Voting von Konsensus unterscheidet, und warum das wichtig ist
Hier liegt der Punkt, den die meisten Unternehmen übersehen, wenn sie den Begriff “Model Council” pauschal in ihre Roadmap kopieren. Der Kaesberg-Befund zeigt zwei Effekte, nicht einen.
Voting, also Mehrheitsentscheid bei Abweichung, schlägt Konsensus auf Reasoning-Aufgaben. Konsensus, also alle drei Modelle müssen übereinstimmen, schlägt Voting auf Knowledge-Recall. Übersetzt für die Praxis: Wer eine mathematische Herleitung sucht oder eine Code-Logik prüft, gewinnt mit dem Mehrheitsvotum. Wer einen Faktabruf macht und Halluzinationen vermeiden will, gewinnt, wenn alle Modelle übereinstimmen müssen.
Das hat eine Konsequenz, die in den Multi-Model-Folien fehlt. Eine pauschale Council-Architektur optimiert auf einen Task-Typ und verliert auf dem anderen. Wer den Council für jede Anfrage gleich verschaltet, hat einen halb fertigen Stack. Die richtige Frage ist nicht “Council ja oder nein”, sondern “welche Aggregationslogik für welchen Task-Typ”.
Das ehrliche Gegenargument: teurer, langsamer, schwerer zu debuggen
Multi-Modell-Architekturen sind teurer als Einzelmodell-Architekturen. Sie sind langsamer. Sie sind schwerer zu debuggen, weil ein Fehler in der Aggregationslogik schwerer zu lokalisieren ist als ein Fehler in einer einzigen API-Antwort. Das stimmt für naive Parallelisierung, bei der jede Anfrage an alle Modelle geht und am Ende ein Voting läuft.
Genau dort setzt Perplexitys Cascade-Architektur an. Schnelle Anfragen mit hoher Konfidenz laufen über ein einziges Modell. Erst wenn die Konfidenz unter einen Schwellenwert fällt, schaltet die Council-Ebene ein. Laut Perplexity Engineering Blog vom März 2026 liegt der Latenz-Overhead in der Praxis bei rund 1,2 Sekunden, der Kosten-Overhead bei etwa 1,8x eines Einzelmodell-Calls, und das nur bei den 22 Prozent der Anfragen, die den Council überhaupt auslösen.
Auf das gesamte Anfragevolumen gerechnet entspricht das einem Cost-Multiplier von rund 1,18x für eine messbare Genauigkeitssteigerung. Das ist nicht “doppelt so teuer”. Das ist 18 Prozent mehr Kosten für 13,2 Prozentpunkte mehr Reasoning-Genauigkeit. Wer diese Rechnung im Pricing-Sheet einer KI-Strategie 2026 nicht macht, lässt Performance auf dem Tisch liegen.
Was das für deine Architekturentscheidung bedeutet
Wenn du gerade eine KI-Strategie verantwortest und die Frage “welches Modell standardisieren wir” auf der Agenda steht, ist der erste richtige Schritt, die Frage umzuformulieren.
Erste Frage: Welche Task-Typen dominieren unser Anfragevolumen? Reasoning-lastige Aufgaben wie Code-Review, juristische Argumentation oder mathematische Modellierung profitieren von Voting. Knowledge-lastige Aufgaben wie Faktenrecherche, Dokumentenextraktion oder regulatorische Compliance profitieren von Konsensus. Wer beide Typen hat, braucht eine Routing-Schicht, die nach Task-Typ unterschiedlich aggregiert.
Zweite Frage: Wo liegt unser Konfidenz-Schwellenwert? Eine reine Cascade-Architektur, bei der das Council nur unterhalb eines bestimmten Confidence-Werts einspringt, hält die Kosten überschaubar. Wer den Schwellenwert sauber kalibriert, holt sich den Kaesberg-Vorteil genau dort, wo er zählt. Der Rest läuft günstig durch.
Dritte Frage: Welche Aggregationslogik passt zur Compliance-Anforderung? In regulierten Branchen ist Konsensus oft die robustere Wahl, weil eine Halluzination im Faktabruf teurer ist als ein verlangsamtes Reasoning. In Entwicklungs- oder Forschungsumgebungen ist Voting oft die richtige Wahl, weil dort der Reasoning-Hebel überwiegt.
Wer regelmäßig Einordnungen zu KI-Architektur und Modellwahl jenseits der Anbieter-Pitches lesen will, findet im KI-Syndikat Newsletter wöchentlich genau das. Wir rechnen Performance-Versprechen gegen Deployment-Realität gegen, mit Quellen statt Behauptungen.
Die Standardisierung auf einen Anbieter war 2023 vernünftig, weil die Modelle zu weit auseinanderlagen, um Voting-Effekte zu erzielen. Im Mai 2026 ist sie es nicht mehr. Perplexity hat den ersten sichtbaren Beweis im Consumer-Produkt geliefert, Apple ratifiziert ihn in der iOS-27-Roadmap, und die Forschung beziffert den Vorteil mit 13,2 Prozentpunkten auf Reasoning. Wer trotzdem einen Anbieter standardisiert, optimiert eine Frage, deren Antwort die Architektur ist.