Ivan Nikitin, CEO und Mitgründer von Fortytwo – Interviewreihe

Ivan Nikitin ist CEO und Mitgründer von Fortytwo. Dort entwickelt er eine Technologie für Schwarm-Inferenz, bei der mehrere KI-Modelle gemeinsam Schlussfolgerungen ziehen und die Arbeit der jeweils anderen bewerten. Sein beruflicher Hintergrund umfasst Spiele, konversationelle KI, generative KI und interaktive Systeme bei Temporal und Sensorium. 2011 gründete er gemeinsam mit Vlad Larin Temporal. Mit ihm sammelte er Erfahrung mit sich weiterentwickelnden Agentenpopulationen und Systemen, die spezialisierte Modelle kombinieren. Larin ist heute Mitgründer und CTO von Fortytwo.

Fortytwo entwickelt KI-Infrastruktur, die es Modellen ermöglicht, während der Inferenz zusammenzuarbeiten. Die Fortytwo Engine nutzt einen Swarm Decoder, um den gemeinsamen Schlussfolgerungsprozess während seiner Ausführung zu lenken. Ziel ist es, die Genauigkeit zu verbessern und bei langwierigen Aufgaben die Erzeugung unnötiger Tokens zu reduzieren. Das Unternehmen bietet Entwicklerinnen und Entwicklern über die Fortytwo Engine eine API sowie mit Fortytwo Harbor eine Bereitstellung vor Ort an.

Bevor Sie Fortytwo mitgründeten, verbrachten Sie Jahre damit, bei Sensorium und Temporal Produkte rund um konversationelle KI, generative KI und interaktive Systeme zu entwickeln. Wie haben diese Erfahrungen Ihre Sicht darauf geprägt, wo einzelne große Sprachmodelle an ihre Grenzen stoßen, und Sie schließlich zu dem schwarmbasierten Ansatz geführt, auf dem Fortytwo beruht?

Ein großer Teil unseres Teams, mich eingeschlossen, kam über Spiele zur KI. Spiele waren die Wiege des Personal Computing und der modernen KI: Ihnen verdanken wir die Existenz der GPU, und Spiele waren das erste ernsthafte Testfeld für bestärkendes Lernen. Spielwelten boten uns eine praktische Umgebung, um Agenten zu entwickeln, die lernen, sich anpassen und miteinander konkurrieren konnten. Bei Temporal, das ich 2011 gemeinsam mit Vlad Larin gründete, der heute Mitgründer und CTO von Fortytwo ist, beschäftigten wir uns zunächst mit sich weiterentwickelnder Intelligenz: Populationen von Agenten, die unter Selektionsdruck miteinander konkurrieren. Uns interessierte, wie eine Population mehr erreichen könnte als ein einzelner Agent – vorausgesetzt, es gab einen guten Mechanismus, um ihre stärksten Beiträge zu erkennen und darauf aufzubauen. Selektion und Bewertung wurden zu zentralen Bestandteilen unseres Verständnisses von Intelligenz.

Als Transformer-Modelle aufkamen, erweiterten wir unsere Arbeit auf konversationelle KI und entwickelten eine Plattform für KI-gesteuerte Figuren, die offene, nicht vorgegebene Gespräche mit Gedächtnis und Persönlichkeit führen konnten. Das war einige Jahre vor ChatGPT; die Modelle, mit denen wir arbeiteten, hatten Kontextfenster von gerade einmal 512 bis 1.024 Tokens. Es kam nicht infrage, von einem einzelnen frühen Sprachmodell zu erwarten, all die unterschiedlichen Anforderungen dieser Erfahrung zuverlässig zu erfüllen. Wir mussten eine maßgeschneiderte Pipeline aus spezialisierten Modellen entwickeln, von denen jedes einen enger gefassten Aufgabenbereich hatte, sowie eine Logik, um ihre Beiträge zusammenzuführen. Antworten zu bewerten und auszuwählen, war entscheidend dafür, dass das gesamte Erlebnis funktionierte. Dabei lernten wir, wie viel Leistungsfähigkeit sich erzielen lässt, wenn man begrenzte Modelle zu einem gut durchdachten System kombiniert.

Die andere wichtige Erkenntnis betraf die Effizienz. Wir stellten fest, dass sich spezialisierte Modelle für klar definierte Aufgaben effizienter trainieren und bereitstellen ließen, sodass wir mit begrenzter Rechenleistung mehr erreichen konnten. Die Skalierung der Inferenz blieb jedoch eine Herausforderung: Auf der einen Seite standen Nutzungsbeschränkungen für APIs, auf der anderen die Kosten für das Hosting eigener Modelle im großen Maßstab. Da uns keine Spitzenkapazitäten für Berechnungen zur Verfügung standen, mussten wir sorgfältig überlegen, wie wir die verfügbaren Ressourcen möglichst effektiv einsetzen konnten. Bei Fortytwo flossen diese Erkenntnisse in die Vision der Schwarm-Inferenz ein: Mehrere Modelle oder mehrere Instanzen desselben Modells tragen zur Schlussfolgerung bei und bewerten zugleich die Arbeit ihrer Mitstreiter. Das Ergebnis: Das Kollektiv ist genauer als jedes seiner Mitglieder.

Die Fortytwo Engine nutzt mehrere Modelle mit offenen Gewichten, um einen einzigen Schlussfolgerungsprozess zu lenken und die Beiträge der einzelnen Modelle während der Antwortgenerierung gegenseitig zu überprüfen. Worin unterscheidet sich dieser Ansatz von herkömmlichen Multi-Agenten-Systemen, Modell-Ensembles oder dem bloßen Ausführen mehrerer Modelle mit anschließender Auswahl der besten Antwort?

Der entscheidende Unterschied besteht darin, dass die Schwarm-Inferenz direkt in die von uns entwickelte Inferenz-Engine integriert ist. Wir nennen sie Swarm Decoder: Mehrere Modellteilnehmer beeinflussen kontinuierlich einen einzigen Schlussfolgerungspfad, während dieser entsteht. Bewertung und Steuerung finden innerhalb dieses Prozesses statt. So können die Modelle seine Richtung beeinflussen, bevor eine Antwort fertig ist.

Die Alternativen funktionieren anders. Bei einem Ensemble auf Antwortebene erzeugen die Modelle separate Antworten, die anschließend bewertet, ausgewählt oder zusammengeführt werden. In der ursprünglichen Architektur von Fortytwo, die 2025 umgesetzt wurde, bewerteten die Modelle einander anhand fertiggestellter Antworten. Das verbesserte die Antwortgenauigkeit erheblich, ging jedoch mit höherer Latenz und zusätzlichem Rechenaufwand einher. Viele herkömmliche Multi-Agenten-Systeme teilen die Arbeit unter Agenten auf und nutzen eine Orchestrierung sowie Nachrichten in natürlicher Sprache, um deren Beiträge zu koordinieren. Solche Übergaben können zusätzliche Inferenzaufrufe und wiederholte Kontextinformationen erfordern sowie Entscheidungen darüber, welche Informationen von einem Agenten an den nächsten weitergegeben werden sollen. Im Swarm Decoder gibt es keine Übergaben: Die Teilnehmer arbeiten an einem einzigen Schlussfolgerungspfad und tauschen lediglich ihre Einschätzung darüber aus, welche Richtung besser ist.

Der Swarm Decoder soll schwache Annahmen bereits während der Generierung erkennen, bevor erheblicher Aufwand in deren Weiterentwicklung fließt. Ziel ist es, Fehler, Umwege und unnötige Generierung zu reduzieren. Ein Effizienzgewinn entsteht dann, wenn die Prüfung mehr Arbeit verhindert, als sie selbst verursacht. Deshalb gibt es auch keinen Latenzaufschlag: Der Ablauf nimmt einen direkteren Weg, sodass die Engine Aufgaben schneller abschließt als dasselbe Modell allein und dabei insgesamt weniger Tokens verwendet – wobei alle beteiligten Modelle mitgezählt werden.

Sie haben das Abdriften von Modellen bei lang andauernden Aufgaben als großes Problem hervorgehoben. Was verursacht dieses Abdriften genau, und wie zeigt es sich in der Praxis, etwa in der Softwareentwicklung, der Forschung oder bei autonomen KI-Agenten?

Abdriften tritt auf, wenn sich der Kontext eines Modells nach und nach immer weiter von der eigentlichen Aufgabe entfernt. Bei einem langen Durchlauf füllt sich der Kontext mit den eigenen Ausgaben des Modells, Tool-Ergebnissen, Dateiinhalten und erneuten Versuchen. Die ursprüngliche Anweisung nimmt einen immer kleineren Anteil dessen ein, worauf das Modell seine Aufmerksamkeit richtet. Zugleich fließen seine früheren Fehler in die Eingabe ein, auf deren Grundlage es weiterarbeitet. Dadurch summieren sich Fehler, statt sich gegenseitig aufzuheben. Hinzu kommt, dass heutige Reasoning-Modelle mit bestärkendem Lernen darauf trainiert werden, Aufgaben abzuschließen. Dabei lernen sie Abkürzungen, die wie ein Abschluss wirken: den Tool-Aufruf überspringen, den Erfolg verkünden oder zusammenfassen, statt etwas zu überprüfen. Wir nennen das Faulheit, und Spitzenmodelle zeigen dieses Verhalten ebenso wie Modelle mit offenen Gewichten. Die Ursache liegt darin, dass ein einzelnes Modell keine externe Kontrolle hat. Es bewertet seine eigene Arbeit, doch Modelle können sich selbst nur schlecht zuverlässig einschätzen.

In der Softwareentwicklung zeigt sich das etwa daran, dass ein Agent den beschriebenen Fehler behebt, dabei aber die Einschränkung missachtet, die Sie in der ersten Nachricht genannt haben, einen Test schreibt, der ohne Weiteres besteht, oder dieselbe Datei viermal liest, weil er den Überblick darüber verloren hat, was er bereits herausgefunden hat. In der Forschung ist es ein langer Durchlauf, bei dem sich das Modell von der gestellten Frage zu der Frage vorarbeitet, die sich am einfachsten beantworten lässt, und mit einer allgemeinen Zusammenfassung zurückkommt. Bei autonomen Agenten zeigt sich die kostspielige Variante: Abschweifungen, wiederholte Tool-Aufrufe, Umwege und eine Token-Rechnung, die um ein Mehrfaches höher ausfällt, als für die Aufgabe nötig wäre.

Das lässt sich beziffern. Wir haben Qwen 3.8 27B mit 450 DeepSWE-Aufgaben getestet – realen Aufgaben aus der Softwareentwicklung, bei denen Tools über lange Kontexte hinweg eingesetzt werden –, einmal eigenständig und einmal mit der Fortytwo Engine. Im eigenständigen Betrieb verbrauchte das Modell durchschnittlich 16,3 Millionen Tokens pro Durchlauf und insgesamt 7,4 Milliarden. Mit der Engine waren es beim selben Modell durchschnittlich 12,3 Millionen Tokens pro Durchlauf und insgesamt 5,6 Milliarden – 24,7 % weniger. Zugleich löste es mehr Aufgaben: 47,8 % gegenüber 42,2 %. Am Modell selbst wurde nichts geändert. Die vier Millionen Tokens pro Durchlauf, die eingespart wurden, entfielen auf das Abdriften: das erneute Lesen, die weiteren Versuche und die Umwege, die ein einzelnes Modell in Kauf nehmen muss, weil niemand seine Fehlentscheidungen erkennt, während es sie trifft. Der Schwarm erkennt sie, sodass diese Kosten gar nicht erst anfallen.

Früher ließ Fortytwo Modelle die fertigen Antworten der jeweils anderen bewerten, während sie in der aktuellen Architektur den Denkprozess beeinflussen können, solange er noch abläuft. Was haben Sie aus dem früheren Ansatz gelernt, und warum ist eine Steuerung in Echtzeit wirksamer?

Die Architektur von 2025 hat gezeigt, dass wir durch horizontale Skalierung Leistungen auf dem Niveau der Spitzenmodelle erreichen können – indem wir mehr Modelle einbeziehen, statt dem größten Modell hinterherzujagen. Ein Schwarm von Modellen mit offenen Gewichten, die die vollständigen Antworten der anderen bewerteten, übertraf das beste Einzelmodell im Schwarm um bis zu 17 Prozentpunkte. Außerdem erwies er sich in Situationen als robust, in denen ein einzelnes Modell es nicht ist: bei verrauschten Prompts, eingeschleusten Anweisungen und einer Mehrheit falscher Antworten.

Was diese Architektur nicht leisten konnte, war einzugreifen. Fertige Antworten zu bewerten funktioniert bei einer einzelnen Frage. Agentenläufe umfassen jedoch Hunderte von Schritten mit Tool-Aufrufen dazwischen, und die entscheidenden Fehler passieren früh und wirken sich immer weiter aus. Wird erst am Ende bewertet, hat jedes Modell bereits die vollen Tokenkosten verursacht, und die Bewertung kann nur noch zwischen Verläufen wählen, die bereits auseinanderdriften. Außerdem stiegen die Kosten des Schwarms mit der Zahl der Modelle – bei einer einzelnen schwierigen Frage ist das in Ordnung, für einen Programmieragenten jedoch ungeeignet.

Die Steuerung in Echtzeit löst beide Probleme. Durchgängige Ranglistenbewertung erzeugt während des gesamten Durchlaufs Selektionsdruck, sodass ein falscher Schritt korrigiert wird, sobald er auftritt – bevor er sich weiter auswirkt. Der Schwarm gibt sich nie mit einem nachlässigen Versuch zufrieden, denn ein weniger sorgfältiger Versuch schneidet in der Rangliste schlechter ab als ein sorgfältigerer. Deshalb sorgt derselbe Mechanismus inzwischen zugleich für höhere Genauigkeit und einen geringeren Tokenverbrauch.

In Ihren Tests mit Qwen 3.8 27B gibt Fortytwo an, bei 450 DeepSWE-Durchläufen 24,7 % weniger Tokens zu verbrauchen und zugleich die Ergebnisse über sechs Benchmarks hinweg zu verbessern. Was geschieht im Schwarm, sodass er die Leistung steigern und gleichzeitig den Tokenverbrauch senken kann?

Die Überprüfung durch den Schwarm verursacht geringe, feste Kosten. Die dadurch vermiedene Nacharbeit nimmt mit der Länge der Aufgabe zu, denn jeder nicht korrigierte Fehltritt verteuert alles, was darauf aufbaut. Je länger also die Aufgabe, desto größer die Einsparungen. DeepSWE liegt am langen Ende dieses Spektrums. Deshalb belaufen sich die Einsparungen auf fast ein Viertel aller Tokens.

Bei der Genauigkeit geht es um ungleichmäßig ausgeprägte Intelligenz. Verbesserungen an Modellen fallen typischerweise unterschiedlich aus: In einem Bereich erreicht das Modell die Schlussfolgerungskompetenz eines Doktoranden, in einem anderen liefert es völligen Unsinn. Denn durch Fine-Tuning, RL und andere Verfahren des nachgelagerten Trainings verbessert sich ein Modell bei den Daten, mit denen es trainiert wurde. Je weiter reale Aufgaben von diesen Daten entfernt sind, desto geringer fallen die Zugewinne aus. Der Swarm Decoder verändert das Modell nicht. Er verbessert vielmehr das Schlussfolgern selbst – und zwar durchgängig. Bei den sechs Benchmarks handelt es sich daher nicht um sechs Bereiche, für die wir das Modell optimiert haben, sondern um sechs Anwendungsfälle, in denen wir dasselbe gemessen haben. Insgesamt ist das Modell leistungsfähiger und aufmerksamer. Wenn Gleichgesinnte jeden Schritt überprüfen, wirkt es, als würde es sich deutlich mehr Mühe mit Ihrer Aufgabe geben. Deshalb können wir die Engine zum Tokenpreis des Basismodells anbieten: Kundinnen und Kunden zahlen nicht für ein größeres Budget, sondern für einen kürzeren Weg zur richtigen Antwort.

KI-Entwickler machen sich zunehmend Gedanken über die Inferenzkosten, da Reasoning-Modelle immer längere Tokenfolgen erzeugen. Glauben Sie, dass eine effizientere Gestaltung des Reasoning-Prozesses selbst letztlich ebenso wichtig sein könnte wie kleinere, schnellere oder günstigere Einzelmodelle?

Ja, und ich würde sagen, dass dies bereits der größere Hebel ist. Kleinere, schnellere und günstigere Modelle senken den Preis pro Token. Aber niemand kauft Tokens. Gekauft wird die Erledigung einer Aufgabe. Im Zeitalter der Agenten ist die Zahl der Tokens pro Aufgabe geradezu explodiert: Bei einer realen Programmieraufgabe verbraucht ein Reasoning-Modell Millionen von Tokens, von denen ein großer Teil auf wiederholte Schritte entfällt. Eine Verringerung der Tokens pro Aufgabe um 25 % ist genauso viel wert wie eine Preissenkung um 25 % – mit dem Unterschied, dass sie sich mit jeder Verbesserung bei Hardware, Quantisierung und Kernels summiert. Außerdem können wir dieses Verfahren auf jedes Open-Weight-Modell auf dem Markt anwenden.

Die Branche hat drei Hebel. Bessere Modelle durch Training, das teuer ist. Günstigere Tokens durch Hardware und Bereitstellung; hier gleichen sich die Bedingungen an, weil alle dieselben GPUs verwenden. Und weniger Tokens pro Aufgabe, abhängig davon, wie die Inferenz ausgeführt wird – ein Bereich, der kaum erforscht ist. Bei der Skalierung ging es bislang um größere Modelle und längere Gedankengänge. Beides setzt voraus, dass ein Modell alles in einem einzigen Ablauf erledigt. Wir glauben, dass die nächste Dimension kollektiv ist: Mehrere Modelle denken gemeinsam nach, wobei das Urteilsvermögen auf sie verteilt ist. Dadurch wird der Ablauf selbst kürzer und zuverlässiger. Das ist eine andere Art der Skalierung als die über Parameter oder Rechenleistung zur Testzeit – und auf sie setzen wir. Wir nennen das: Peers statt Parameter.

Fortytwo Engine ist mit der OpenAI API kompatibel und führt gleichzeitig Open-Weight-Modelle aus. Wie wichtig war die Kompatibilität mit bestehenden KI-Entwicklungsumgebungen, und wie einfach können Entwickler eine Anwendung von einer herkömmlichen API mit einem einzelnen Modell auf eine Schwarmarchitektur umstellen?

Kompatibilität ist unverzichtbar. Das Agenten-Ökosystem – mit Programmieragenten, Steuerungsumgebungen, Frameworks und Evaluierungstools – basiert auf dem OpenAI-API-Format. Für Entwickler, die Fortytwo Engine nutzen, ist der Wechsel daher wie der Wechsel zu einem anderen Inferenzanbieter: Bei einer kompatiblen App, einem Agenten, einer Steuerungsumgebung oder einem Dienst ist in der Regel nur eine Konfigurationsänderung nötig: Endpunkt, API-Schlüssel und Modellauswahl.

Was sich ändert, ist das Verhalten, nicht die Integration. Der Unterschied zeigt sich bei längeren agentischen Abläufen, bei denen Tokenverbrauch und Trefferquote im ersten Durchlauf die Kosten bestimmen: Dasselbe Modell erledigt Aufgaben über die Engine schneller, mit weniger Tokens und löst mehr davon korrekt. Mein Rat: Behandeln Sie es wie jeden Modellwechsel. Führen Sie die Evaluierung durch, die Sie bereits für Ihren Agenten verwenden, vergleichen Sie die Tokens pro Aufgabe und die Erfolgsquote und behalten Sie die Variante bei, die besser abschneidet.

Vielen Dank für das großartige Interview. Leserinnen und Leser, die mehr über Schwarm-Inferenz und darüber erfahren möchten, wie Peer-Evaluierung die Effizienz des Reasoning verbessern kann, sollten Fortytwo besuchen.