Kategorie: KI-News

256.000 Beschleunigerkarten soll ein einzelner Atlas-950-SuperCluster von Huawei verbinden können. Diese Zahl beschreibt besser als jede Produktfolie, worum es dem Konzern gerade geht: nicht um den besten einzelnen Chip, sondern um einen Verbund, der als ein einziger Computer rechnet. Den nächsten Baustein dafür will Huawei früher liefern als geplant. Der chinesische Technikkonzern hat den Start seines KI-Chips Ascend 960DT vom dritten Quartal 2027 auf das erste Quartal 2027 vorgezogen, wie er auf seiner Konferenz Huawei Connect mitteilte.

Wer die Ankündigung einordnen will, muss zwei Dinge auseinanderhalten: den Chip und das System, in dem er steckt. Während Huawei beim Zeitplan nach vorne prescht, sind bei den umgebenden Großsystemen Zweifel aufgekommen. Beide Bewegungen zusammen sagen mehr über Huaweis Lage aus als jede einzelne Zahl. Der folgende Text sortiert, was auf der Konferenz gesagt wurde, was eine Analystin darauf erwidert hat und was das für den Wettbewerb mit Nvidia bedeutet.

Q1 2027 statt Q3 2027: Was Huawei beim Ascend 960DT vorzieht

Zwei Quartale früher ist in der Halbleiterbranche keine Feinjustierung. Ein Sprecher des Unternehmens bestätigte gegenüber TechCrunch den neuen Termin: Der Ascend 960DT soll im ersten Quartal 2027 bereit sein, ursprünglich war das dritte Quartal desselben Jahres vorgesehen. Angekündigt wurde die Änderung laut dem Sprecher von David Wang, einem der rotierenden und amtierenden Vorsitzenden von Huawei, auf der Hausmesse Huawei Connect. In der Mitteilung heißt es, die Ascend-960-Chips kämen früher als geplant, verdoppelten die Leistung und entwickelten sich Jahr für Jahr weiter.

Solche Verdopplungsangaben solltest du als Unternehmensaussage lesen, nicht als unabhängig geprüften Messwert. Rechenleistung lässt sich auf viele Arten definieren: mit unterschiedlicher Präzision, mit oder ohne Speicherbandbreite, für das Training oder nur für die Inferenz. Wer zwei solcher Zahlen vergleicht, vergleicht oft zwei verschiedene Definitionen. Bemerkenswert ist deshalb weniger das Tempo der Leistungssteigerung als die Tatsache, dass Huawei überhaupt einen so konkreten Termin nennt und ihn dann nach vorne zieht. Worin sich die Variante 960DT vom Basis-960 unterscheidet, ließ das Unternehmen in den öffentlichen Angaben offen.

Peerium Computing Architecture von Huawei: viele Chips, ein Takt

Ein Chip ist noch kein Computer, und ein paar Hunderttausend Chips sind noch lange kein großer Computer. Man kann sich das wie ein Orchester vorstellen: Es nützt wenig, 256.000 Musiker auf eine Bühne zu stellen, wenn sie nicht im selben Takt spielen. Der Engpass liegt dann nicht mehr in der Geschwindigkeit des Einzelnen, sondern darin, wie schnell Informationen zwischen allen Beteiligten hin- und herwandern. Genau an dieser Stelle setzt an, was Huawei seine Peerium Computing Architecture nennt.

Diese Architektur stützt sich auf UnifiedBus, eine Huawei-Technik, die Prozessoren mit Speicher, Storage und Netzwerk-Hardware verbindet. Eric Xu, ebenfalls rotierender Vorsitzender des Konzerns, erklärt in der Unternehmensmitteilung, man baue mit Peerium größere KI-Rechensysteme, die sowohl für das Training als auch für die Inferenz ausgelegt sind – also für das Lernen der Modelle und für ihren späteren Betrieb. Die ersten Systeme auf dieser Basis sind den Angaben zufolge der Atlas 950 SuperPoD und der Atlas 950 SuperCluster. Die Stoßrichtung ist erkennbar: Huawei tritt nicht zum Duell um den schnellsten einzelnen KI-Beschleuniger an, sondern versucht, das Kräfteverhältnis über die Größe des Verbunds zu verschieben. Ein langsamerer Chip in einem gut verschalteten Netz aus vielen Chips kann auf der Systemebene einen Teil des Rückstands wettmachen.

Atlas 950 SuperPoD und SuperCluster: die Dimensionen

Die Zahlen, die Huawei nennt, sind für europäische Maßstäbe schwer greifbar. Ein Atlas 950 SuperCluster soll bis zu 256.000 Beschleunigerkarten verbinden können; das ist kein Rechenzentrum mehr im üblichen Sinn, sondern ein Cluster, der über mehrere Gebäude verteilt gedacht werden muss. Leistung entsteht dabei nicht durch einen besonders schnellen Kern, sondern durch schiere Menge und kurze Wege. In der Analogie des Orchesters ist UnifiedBus der Taktstock: Ohne ihn spielt jeder für sich, und die Summe klingt schlechter als der beste Einzelne.

Für Nutzer solcher Systeme zählt am Ende weniger die Kartenzahl als die Frage, wie effizient sie zusammenarbeiten. Jede Verzögerung im Netzwerk kostet Rechenzeit, und je größer der Verbund, desto teurer wird jede Umleitung. Eine Architektur, die Chips, Speicher und Netzwerk zusammen denkt, ist deshalb mindestens so wichtig wie der Chip selbst. Wer in Europa KI-Modelle trainiert, kennt das Problem in kleinerem Maßstab: Die Wahl der Verbindungstechnik entscheidet oft mehr über die Trainingsdauer als die Wahl der Beschleuniger. Huawei setzt hier auf eine Disziplin, die in dieser Branche am schwersten zu kopieren ist.

15.488 gegen 4.096: der Widerspruch bei den SuperPoD-Zahlen

Genau an dieser Stelle wird die Ankündigung angreifbar. Die China-Technik-Analystin Rui Ma wies auf X darauf hin, dass Huawei zuvor angekündigt habe, der Atlas 960 SuperPoD werde auf 15.488 Ascend-960-Chips skalieren, während die dieswöchige Mitteilung von einem System mit 4.096 Chips sprach. Ihre Einschätzung: Der Chip selbst komme deutlich früher, doch das angekündigte SuperPoD sei erheblich kleiner als ursprünglich dargestellt. Das ist keine Nebensache, denn die ganze Strategie ruht auf dem Verbund – schrumpft der Verbund, schrumpft der Vorteil.

Man kann das auf zwei Weisen lesen. Die erste: Huawei hat die frühere Zahl überzogen und korrigiert sie jetzt stillschweigend nach unten. Die zweite: Es handelt sich um unterschiedliche Ausbaustufen oder Generationen desselben Systems, und die Kommunikation hat sie nicht sauber getrennt. Nachprüfen lässt sich beides von außen kaum, weil Huawei weder Spezifikationen noch Preis- und Verfügbarkeitsangaben in dem Detail veröffentlicht, das Konkurrenten üblicherweise liefern. Für dich als Leser heißt das: Nicht die größte jemals genannte Zahl ist der Maßstab, sondern die Zahl, die zum genannten Termin tatsächlich geliefert wird.

KI-Chips trotz US-Beschränkungen: der politische Rahmen

Die Ankündigung fiel in ein politisch aufgeladenes Zeitfenster. Sie kam eine Woche vor einem geplanten Treffen von US-Präsident Trump und Chinas Präsident Xi Jinping am 24. September in Washington. Huawei entwickelt seine KI-Chips trotz US-Beschränkungen weiter, die Chinas Zugang zu fortgeschrittener Halbleitertechnik begrenzen sollen. Rui Ma hält es für wenig aussichtsreich, Chinas Halbleiterentwicklung aufhalten zu wollen, weil das Interesse an Selbstversorgung zu groß sei. Man muss dieser Einschätzung nicht folgen, um zu sehen, dass sie einen Kern trifft: Sanktionen verlangsamen eine Entwicklungslinie, beenden sie aber selten, wenn ein Staat ein strategisches Interesse daran hat.

Auf der anderen Seite steht eine Regierung, die ihren Vorsprung gegenüber China halten will. Trump hat sich gegen Forderungen aus der KI-Industrie gestellt, die Entwicklung der Technologie aus Sicherheitsgründen zu bremsen, und argumentiert, die USA müssten ihre Führung behaupten. Eric Xu wiederum sagte laut Financial Times, China müsse die KI-Entwicklung beschleunigen, um zum US-Stand aufzuschließen; chinesische Unternehmen müssten weiter vorankommen, bevor sie die Risiken leistungsfähigerer Systeme vollständig verstehen und adressieren könnten. Zwei Regierungen und ein Konzernchef argumentieren mit derselben Logik – schneller entwickeln – und ziehen daraus gegensätzliche Schlüsse.

Was der Ascend 960DT für Nvidia und für den Markt bedeutet

Für Nvidia ändert der vorgezogene Termin kurzfristig wenig. Die Stellung des Unternehmens beruht nicht allein auf Chips, sondern auf einer Softwareumgebung, die seit Jahren gewachsen ist und von Entwicklern beherrscht wird. Wer heute Modelle trainiert, wechselt nicht wegen eines Datenblatts die Plattform, sondern wegen Werkzeugen, Bibliotheken und Erfahrung. Huawei baut parallel an eigenen Ökosystemen, aber dieser Teil der Arbeit ist langsamer als jede Chip-Ankündigung und öffentlich schwer zu messen.

Mittelfristig ist die Bewegung trotzdem relevant, und zwar aus einem Grund, der oft übersehen wird. Solange es nur einen glaubwürdigen Anbieter für große KI-Beschleuniger gibt, bestimmt dieser Anbieter Preis, Lieferzeit und Roadmap. Jede Alternative, die tatsächlich liefert statt nur angekündigt zu werden, verändert die Verhandlungsposition der Käufer. Ob diese Alternative aus Shenzhen, aus Europa oder aus Südkorea kommt, ist für den Effekt zweitrangig. Der Ascend 960DT ist in diesem Sinn weniger ein Produktversprechen als ein Datum, an dem sich überprüfen lässt, wie ernst die Ankündigung gemeint war.

Was bleibt, ist eine nüchterne Einordnung. Huawei nennt einen Termin, zieht ihn vor und liefert gleichzeitig widersprüchliche Größenangaben für das System, das den Chip tragen soll. Das ist kein Beweis für Schwäche und keiner für Stärke, sondern der normale Zustand einer Branche, in der Ankündigungen Teil der Verhandlung sind. Für dich heißt das: Behalte das erste Quartal 2027 im Kalender, bewerte das Ergebnis aber an den Systemen, die dann wirklich laufen – und an den Zahlen, die dann noch gelten.

Quelle: techcrunch.com

Wie viel Modellintelligenz passt in 5,9 Gigabyte? Das Unternehmen Prism ML hat mit Ternary Bonsai 2 27B eine ziemlich konkrete Antwort gegeben. Das Team entstand aus einer Gruppe von Caltech-Forschern und wird von Khosla Ventures, Cerberus, Google und Samsung unterstützt. Es beschreibt ein 27B-Modell mit ternären Gewichten, das auf Qwen3.8 27B aufbaut. Wer sich mit lokalen KI-Modellen beschäftigt, kennt das Grundproblem: Qualität wächst mit der Parameterzahl, der Speicherbedarf wächst genauso. Hier setzt die Veröffentlichung an. Die Zahlen, die das Team nennt, lohnen einen genauen Blick.

Was Ternary Bonsai 2 27B technisch ausmacht

Entscheidend ist, wie ein einzelnes Gewicht im Speicher steht. In einem konventionellen Modell ist jedes Gewicht eine 16-Bit-Zahl mit vielen Nachkommastellen. Ternary Bonsai 2 27B kennt dagegen nur noch drei Zustände: minus eins, null und plus eins. Rechnet man die Skalierungsfaktoren mit, kommt das Team auf 1,76 effektive Bits pro Gewicht. Drei Zustände allein wären zu grob, deshalb speichert das Modell zusätzlich pro Gruppe von Gewichten einen gemeinsamen Maßstab im FP16-Format. Man kann sich das vorstellen wie eine Landkarte, auf der jede Region ihren eigenen Maßstab mitbringt: Die Zeichnung bleibt grob, die Position stimmt trotzdem. Diese niedrige Bitzahl wird nach Angaben der Entwickler durchgängig über das gesamte Sprachmodell angewendet, nicht nur auf ausgewählte Schichten. Insgesamt ergibt das 5,9 GB für 27 Milliarden Parameter, also mehr als neunmal weniger als die Vollpräzisionsvariante, dazu ein Kontextfenster von 262.000 Token, multimodale Eingaben aus Text und Bild und eine Veröffentlichung unter der Apache-2.0-Lizenz.

Was sich gegenüber dem ersten Bonsai 27B geändert hat

Der Vorgänger erschien nach Angaben des Unternehmens rund zwei Monate vorher und zeigte, dass ein multimodales Modell der 27B-Klasse klein genug komprimiert werden kann, um auf einem lokalen Gerät effizient zu laufen. Bonsai 2 27B verfolgt nun einen anderen Schwerpunkt: nicht mehr der Machbarkeitsnachweis, sondern die Modellqualität und Laufzeitperformance, die für echte lokale Anwendungen gebraucht werden. Konkret nennt das Team drei Änderungen. Erstens ein stärkeres Basismodell, nämlich Qwen3.8 27B. Zweitens eine höhere Beibehaltung der Fähigkeiten gegenüber dem Vollpräzisionsmodell, gestiegen von etwa 95 auf 98,2 Prozent. Drittens bessere Leistungen bei Reasoning, Coding, Vision und langen agentischen Aufgabenketten. Das Deployment-Profil bleibt gleich: kleiner Speicherbedarf, hoher lokaler Durchsatz, bessere Energieeffizienz. Die Verbesserung kommt nicht durch ein größeres Modell zustande, sondern innerhalb desselben Speicherrahmens.

Benchmarkzahlen: wo Fähigkeiten erhalten bleiben

Über Reasoning-, Mathematik-, Coding-, Instruktionsfolge-, Vision- und Tool-Benchmarks hinweg erreicht Ternary Bonsai 2 27B einen Gesamtwert von 83,9 Punkten. Der Vergleichswert für Qwen3.8 27B in voller Präzision liegt bei 85,4, der ältere Qwen3.6 27B kommt auf 83,6 Punkte. Daraus ergibt sich die vom Team genannte Beibehaltung von 98,2 Prozent. In einzelnen Disziplinen sieht das anders aus: Mathematik kommt auf 96,57 gegenüber 97,06, Coding auf 81,58 gegenüber 82,17, agentische Tool-Nutzung auf 77,57 gegenüber 79,74, Vision auf 78,59 gegenüber 81,64 und Wissen plus Reasoning auf 83,95 gegenüber 86,66. Bei der Instruktionsfolge liegt das komprimierte Modell mit 82,66 sogar über dem Vollpräzisionsmodell, das 81,25 erreicht. Aussagekräftiger als der Durchschnitt ist die Verteilung. Coding-Agenten, Tool-Systeme und multimodale Abläufe gelten als besonders empfindlich gegenüber Modellverschlechterung, weil sich kleine Fehler über viele Schritte aufsummieren. Dort bleibt der Verlust nach den vorliegenden Zahlen klein, während er bei Vision und breitem Faktenwissen deutlicher ausfällt.

Durchsatz, Energiebedarf und der Alltag von Coding-Agenten

Auf einer NVIDIA GeForce RTX 5090 erreicht das Modell laut Whitepaper bis zu 143 Token pro Sekunde, auf einem M5 Max sind es 46,8 Token pro Sekunde. Auf einer RTX 4090 verbraucht Ternary Bonsai 2 27B nach diesen Angaben 0,714 Milliwattstunden pro Token und arbeitet damit rund 40 Prozent energieeffizienter als ein 8B-Modell in voller Präzision. Für Coding-Assistenten bedeutet höherer Durchsatz kürzere Schleifen aus Ändern und Testen, also weniger Wartezeit zwischen zwei Gedanken. Für multimodale Agenten zählt, wie schnell Screenshots, Dokumente und Tool-Aufrufe durchlaufen. Und für private, lokale Abläufe entscheidet die Energie pro Token darüber, ob ein Assistent dauerhaft im Hintergrund verfügbar sein kann, ohne ständig die Cloud zu rufen. Der Vergleich mit einem 8B-Modell in voller Präzision ist bemerkenswert: Ein 27B-Modell, das weniger Strom pro Anfrage braucht als ein kleineres, verschiebt die übliche Abwägung zwischen Fähigkeit und Kosten.

Intelligenzdichte und warum Kompression die Architekturdebatte verschiebt

Das Team fasst sein Ergebnis in einer Kennzahl zusammen, die es Intelligenzdichte nennt: nutzbare Fähigkeit pro Gigabyte Speicher. Viele Alternativen mit niedriger Bitzahl werden erst nutzbar, weil sie bei Coding, Vision oder Tool-Nutzung spürbar Fähigkeit aufgeben. Bonsai 2 27B setzt sich nach oben ab: weniger Speicher und trotzdem konkurrenzfähige Werte. Daraus folgt eine Argumentation, die über den lokalen Rechner hinausgeht. Wenn sich ein größeres Modell in dasselbe Speicherbudget quetschen lässt, passen mehr Nutzer auf dieselbe Hardware, sinkt die Energie pro Inferenz und werden hybride Systeme realistischer, in denen lokal läuft, was sensibel oder häufig ist, während seltenere oder schwerere Anfragen gezielt an die Cloud gehen. Die Frage lautet dann nicht mehr nur, wie fähig ein Modell ist, sondern wie viel nützliche Intelligenz sich innerhalb eines vorgegebenen Speicher-, Rechen- und Energiebudgets ausliefern lässt. Das gilt für Rechenzentren wie für den Laptop auf dem Schreibtisch.

Plattformen, Lizenz und die offenen Punkte

Ausgeliefert wird das Modell auf NVIDIA-GPUs über CUDA und auf Apple-Geräten – Mac, iPhone und iPad – über MLX, jeweils mit eigenen Kernen für niedrige Bitzahlen. Die Gewichte stehen ab sofort unter der Apache-2.0-Lizenz bereit, die technischen Details zu Kompression, Evaluation und Benchmarking finden sich im Whitepaper. Das Unternehmen bietet zusätzlich an, Modelle für konkrete Anwendungen anzupassen, vom Nachtraining auf Domänendaten bis zur Optimierung der Inferenz für bestimmte Hardware, und sucht Mitarbeitende für die nächste Modellgeneration. Zwei Einschränkungen gehören dazu. Die Zahlen stammen aus der eigenen Evaluation des Herstellers und ersetzen keinen unabhängigen Nachbau auf der eigenen Hardware. Außerdem bleibt offen, wie sich das Modell über lange Sitzungen verhält, wenn Kontext wächst, Speicher fragmentiert und reale Tool-Ketten mehr Fehler produzieren als ein Benchmark-Skript. Wer heute ein lokales Modell für Coding-Agenten oder dokumentenbasierte Arbeit sucht, hat mit Ternary Bonsai 2 27B einen ernstzunehmenden Kandidaten mit sehr niedriger Einstiegshürde beim Speicher. Der nächste Schritt ist ohnehin einfach: herunterladen, auf dem vorhandenen Gerät laufen lassen und die eigenen Aufgaben damit messen, nicht die Benchmark-Tabelle.

Quelle: prismml.com

Viele gehen davon aus: Automatisierte Code-Übersetzung ist vor allem eine Frage der Modellgröße. Ein stärkeres Sprachmodell liefert saubereren Code. Der arXiv-Preprint 2609.12464 zeigt das Gegenteil. Nicht das Modell bremst, sondern die Frage, welchen Ausschnitt eines Systems es überhaupt zu sehen bekommt.

Die Arbeit vergleicht zwei Arten des Kontextabrufs bei der Migration von Legacy-Monolithen zu Microservices. Da ist zum einen das bekannte Standard RAG, das Code in Chunks zerlegt und per Vektorähnlichkeit wieder einsammelt. Zum anderen eine Methodik namens Hierarchical Context-Resident Graph, kurz HCRG, die den Code als Graph mit echten architektonischen Kanten abbildet. Der Unterschied klingt trocken. Er entscheidet aber mit darüber, ob der übersetzte Code am Ende kompiliert.

Retrieval-Augmented Generation heißt heute fast immer Vektorähnlichkeit: Text wird in Häppchen geschnitten, in Zahlenvektoren übersetzt und über die Nähe im Vektorraum wieder eingesammelt. Für Dokumentation, Tickets oder Chatverläufe reicht das. Für Quellcode ist es das falsche Kriterium. Ähnlichkeit sagt nichts über Zugehörigkeit – und Zugehörigkeit ist in einem Softwaresystem die Größe, auf die es ankommt.

Warum Standard RAG beim Übersetzen von Legacy-Code scheitert

Ein Monolith ist kein Haufen unabhängiger Dateien, sondern ein Geflecht aus Vererbungsketten, Interface-Verträgen, Aufrufhierarchien und geteilten Datenstrukturen. Wer das in gleich große Textblöcke zerlegt, zerschneidet genau die Fäden, die das System zusammenhalten. Die Vektorsuche findet dann die Textstellen, die einer Anfrage semantisch am nächsten liegen – nicht die, die fachlich dazugehören. Das Modell bekommt eine Auswahl, die plausibel aussieht und strukturell falsch ist.

Man kann sich das wie die Renovierung eines alten Gebäudes vorstellen. Standard RAG liefert Innenaufnahmen: schöne Bilder einzelner Zimmer, sauber beschriftet, thematisch sortiert. Der Bauplan mit dem Tragwerk fehlt. Wer nur die Fotos kennt, reißt irgendwann eine Wand heraus, die das Dach trägt, und wundert sich, warum danach etwas einstürzt. Genau das passiert, wenn ein Sprachmodell eine Methode aufruft, die es in der Zielarchitektur nicht gibt.

Der Preprint gibt dem Phänomen eine Kennzahl: API-Halluzination. Gemeint ist der Anteil erfundener oder falsch verdrahteter Schnittstellen. Im Standard-RAG-Aufbau liegt der Wert bei 56,4 Prozent. Mehr als die Hälfte der erzeugten Aufrufe zeigt also auf etwas, das es nicht gibt. Oberflächlich sieht der Code dabei gut aus – genau das ist die Gefahr.

Wie ein hierarchischer Graph-Kontext den Code zusammenhält

Die Pipeline arbeitet in drei Schritten. Zuerst zieht das Parsing-Werkzeug tree-sitter einen Abstract Syntax Tree aus dem Quellcode – eine formale Struktur aus Klassen, Methoden, Parametern und Blöcken. Dann werden die architektonischen Beziehungen zwischen diesen Knoten als Kanten in einen Property Graph geschrieben, konkret in Google Cloud Spanner. Zum Schluss wird die Struktur serialisiert und in einen Gemini Context Cache gelegt, aus dem das Modell seinen Kontext bezieht.

Entscheidend ist die Reihenfolge. Das System arbeitet parent-first: erst die übergeordneten Einheiten, dann die abhängigen. Wer eine Klasse migriert, kennt bereits die Basisklasse, das Interface und die aufrufenden Stellen. Zurück zum Gebäude: Das Modell bekommt nicht mehr einzelne Zimmerfotos, sondern den vollständigen Bauplan, und arbeitet sich vom Fundament nach oben vor.

Der Unterschied liegt in der Art des Abrufs. Standard RAG fragt: Welcher Textblock ähnelt meiner Suchanfrage am meisten? Graph RAG fragt: Welche Knoten sind mit diesem Knoten über welche Kanten verbunden? Die zweite Frage lässt sich nicht per Vektorähnlichkeit beantworten. Strukturelle Nachbarschaft und inhaltliche Ähnlichkeit sind zwei verschiedene Dinge. Ein Interface kann semantisch völlig anders klingen als seine Implementierung und trotzdem dazugehören.

CodeBLEU lügt: Warum Textähnlichkeit die falsche Messlatte ist

Der zweite Beitrag der Arbeit liegt im Messen. Übliche Metriken für Code-Übersetzung vergleichen erzeugten mit vorhandenem Code auf Textüberlappung, etwa CodeBLEU und ähnliche Varianten. Hier erreichten Standard RAG und Graph RAG beide rund 91 Prozent. Auf dem Papier sind die Verfahren damit gleichwertig – solche Zahlen stehen deshalb gern in Evaluationsberichten.

Der Wert kaschiert das Problem. Code, der syntaktisch plausibel ist und auf nicht existierende APIs zeigt, sieht textlich fast aus wie korrekter Code. Die 91 Prozent sind kein Qualitätsnachweis, sondern ein Beleg dafür, dass die Metrik die falsche Frage stellt. Die Autoren ersetzen sie durch ein eigenes Framework mit sieben Kennzahlen, die softwaretechnische Eigenschaften abbilden statt Zeichenähnlichkeit.

Dazu gehören die bereits erwähnte API-Halluzinationsrate, die Dependency Resolution Quality für korrekt aufgelöste Abhängigkeiten, die Parent-Child Consistency für die Konsistenz zwischen Basis- und abgeleiteten Einheiten, die Cyclomatic Complexity Consistency für die erhaltene Verzweigungsstruktur und die Docstring Preservation für den Erhalt von Dokumentationskommentaren. Das ist der methodische Fortschritt: eine Messlatte, die strukturelle Fehler nicht hinter glatter Oberfläche versteckt.

Was die Zahlen zeigen – und wo Graph RAG teuer bezahlt

Bei den strukturellen Kennzahlen ist das Ergebnis deutlich. Die API-Halluzinationsrate sinkt von 56,4 auf 16,2 Prozent, also auf weniger als ein Drittel. Die Dependency Resolution Quality steigt von 34,8 auf 65,9 Prozent, die Parent-Child Consistency von 26,7 auf 45,5 Prozent. Wer schon einmal übersetzten Code manuell nachgebessert hat, kennt den Unterschied: Es geht nicht mehr darum, fehlende Schnittstellen zu erraten.

Der Gewinn kommt nicht umsonst. Weil das Modell den gesamten strukturellen Zusammenhang sieht, reagiert es mit defensivem Überbau. Es fügt Prüfungen, Fallunterscheidungen und Absicherungen ein, die im Original nicht stehen. Die Cyclomatic Complexity Consistency fällt deshalb von 71,6 auf 46,7 Prozent. Der übersetzte Code ist weniger halluzinationsanfällig, aber spürbar komplexer als die Vorlage.

Auch bei der Dokumentation geht es leicht zurück: Die Docstring Preservation sinkt von 67,0 auf 61,0 Prozent. Das passt ins Bild. Wenn ein Modell mehr Kontext verarbeitet und mehr Absicherung einbaut, verschiebt sich seine Aufmerksamkeit weg von Kommentaren und hin zur Logik. Vereinfacht: weniger erfundene Schnittstellen gegen mehr Verzweigungen und etwas weniger Dokumentation.

Was das für die Praxis der Legacy-Modernisierung bedeutet

Die Konsequenz ist unbequem für alle, die auf das nächste Modell gehofft haben. Der größte Hebel bei der Migration von Unternehmenscode mit LLM liegt nicht im Modell, sondern im Retriever – in der Frage, welcher Kontext zusammengestellt wird. Bessere Abhängigkeitsauflösung entsteht nicht dadurch, dass man mehr Kontext in das Modell schüttet, sondern dadurch, dass man den richtigen Kontext aus einer Struktur zieht.

Daraus folgt: Man braucht eine eigene Messlatte. Wer CodeBLEU oder reine Textähnlichkeit als Abnahmekriterium verwendet, erklärt Projekte für gelungen, die beim ersten Build scheitern. Sinnvoll sind Kennzahlen, die den Kompilierungsvorgang, die Auflösung von Abhängigkeiten und die Konsistenz zwischen Basis- und abgeleiteten Einheiten abbilden. Erst dann wird sichtbar, was Standard RAG und Graph RAG wirklich unterscheidet.

Die Sache bleibt aufwendig. Eine Graph-Pipeline mit AST-Extraktion, Property-Graph-Speicherung und serialisiertem Kontext-Cache ist Infrastruktur, keine Konfigurationszeile. Sie kostet Engineering-Zeit, Speicher und Betrieb. Für ein einzelnes Skript lohnt das nicht; bei einem gewachsenen Monolithen mit tausenden Dateien sieht die Rechnung anders aus, weil dort jeder vermiedene Halluzinationsfehler direkt Review-Zeit spart.

Und auch der beste Graph RAG ersetzt keine menschliche Abnahme. Die verbleibenden 16,2 Prozent API-Halluzinationen sind keine Restfehler, die man ignorieren kann, sondern genau die Stellen, an denen ein Review hinschauen muss. Graph RAG macht automatisierte Code-Übersetzung also nicht fehlerfrei. Es verschiebt den Fehlercharakter: Statt falscher Schnittstellen bekommt man konservativen, etwas zu komplexen Code – für jede Migration die angenehmere Ausgangslage.

Quelle: arxiv.org

Zuerst wird ein Ledger angelegt: jede untersuchbare Einheit der Codebasis bekommt eine Kennung und einen Prüfstatus. Erst danach beginnt die Suche. Isolierte Agenten arbeiten die Einheiten ab, eine zweite Gruppe sucht Lücken im Prüfplan, und jeder vorläufige Befund geht an einen Prüfer, dessen Auftrag das Widerlegen ist.

Cloudflare hat diesen Ablauf als offenes Skill für Coding-Agenten auf GitHub veröffentlicht. security-audit-skill ist eine Sammlung von Anweisungen, Schemata und Prüfskripten, die einen Agenten durch sechs Phasen führt: Aufnahme, Abdeckung, Kandidatenprüfung, strukturierte Ausgabe, unabhängige Nachprüfung und Bericht. Nach Angaben des Projekts ist es das Skill, aus dem Cloudflares Vulnerability-Discovery-Harness hervorgegangen ist. Der Harness wurde daraus zu einem mehrstufigen, flottenweiten System ausgebaut; dieses Repository ist der Ausgangspunkt für ein einzelnes Projekt.

Das Vorgehen erinnert an die Trennung von Bauausführung und Prüfstatik. Wer die Wand gemauert hat, nimmt sie nicht selbst ab. Diese Trennung ist hier nicht als Empfehlung formuliert, sondern in den Ablauf eingebaut. Das unterscheidet den Ablauf von einem Scanner, den man einmal über ein Repository laufen lässt.

Einen Agenten nach einem Sicherheitsaudit zu fragen und den ersten Bericht als Ergebnis zu nehmen, ist verständlich, aber meistens zu optimistisch. Ein Sprachmodell produziert plausiblen Text. Plausibilität ist das Gegenteil von Beweis. Der folgende Durchgang zeigt, wie das Skill dagegen arbeitet.

Ein Ledger statt Bauchgefühl: wie die Aufnahme den Prüfumfang festlegt

Die erste Phase heißt Reconnaissance und hat wenig mit Suchen zu tun, sondern viel mit Kartieren. Der Agent erfasst Architektur, Vertrauensgrenzen und Eingabeoberflächen, dazu frühere Befunde und die deterministisch bekannte Abdeckung. Zwei Dateien entstehen dabei: architecture.md für das Bild des Systems und coverage-ledger.json für das Verzeichnis aller Einheiten, die geprüft werden müssen oder bereits geprüft wurden. Das Ledger ist kein Protokoll im Nachhinein, sondern der Prüfplan, gegen den später abgerechnet wird.

Phase zwei folgt diesem Plan. Aus den Einheiten des Ledgers werden isolierte Hunter zugewiesen, jeder mit einem begrenzten Auftrag, und jeder Hunter trägt seine durchgeführten Checks zurück ins Ledger ein. Danach kommen Coverage-Critics zum Einsatz, deren einzige Aufgabe es ist, Lücken zu finden: Stellen, die im Ledger fehlen oder nur scheinbar abgedeckt sind. Damit unterscheidet sich der Ablauf von der freien Suche. Nicht der Fund steuert den Fortgang, sondern die Frage, was noch nicht angesehen wurde.

Damit das Ledger nicht selbst zur Behauptung verkommt, läuft nach dem Anlegen und nach jeder späteren Aktualisierung ein Prüfskript darüber. validate-coverage-ledger.cjs arbeitet ohne Abhängigkeiten und prüft die Struktur der Datei in den Phasen eins bis fünf. Ein Eintrag, der formal nicht stimmt, fällt auf, bevor er die weiteren Phasen verzerrt.

Falsifikation statt Bestätigung: der Finder prüft sich nicht selbst

In Phase drei bekommt jeder eindeutige Kandidat einen frischen Prüfer. Dessen Auftrag ist nicht, den Befund zu bestätigen, sondern ihn zu widerlegen. Doppelte Kandidaten werden vorher zusammengeführt, damit nicht fünf Prüfer dieselbe Beobachtung fünfmal abnicken. Der Prüfer ist ein separater Agent, ohne den Fundweg des ersten. Er sieht das Ergebnis und die Quelle, nicht die Überlegung, die dazu geführt hat.

Das Projekt formuliert es als Designprinzip: Der Agent, der einen Befund prüft, ist nie der Agent, der ihn gefunden hat. In der Praxis entscheidet das darüber, ob ein automatischer Audit brauchbar ist. Ein Modell, das seinen eigenen Fund nachbewertet, bestätigt ihn fast immer, weil die Begründung schon im Kontext liegt. Ein zweiter Durchlauf ohne diesen Kontext hat diese Bequemlichkeit nicht.

Dazu kommen Regeln, die den Begriff der Schwachstelle schärfen. Bestätigt wird nur ein etablierter Grenzübertritt, also ein nachvollziehbarer Bruch einer Vertrauensgrenze mit beobachtbarer Wirkung. Eine Lücke in der Defense-in-Depth ist keine Schwachstelle: Wenn Schutzschicht A den Angriff verhindert, ist das Fehlen von Schutzschicht B ein Härtungshinweis und wandert nicht in die Befundliste. Die Schwere eines Befunds verlangt einen Impact, berechnet aus Wahrscheinlichkeit mal Auswirkung, nicht aus der Abweichung von einer Checkliste.

Ein blockierter, aber quellenbelegter Hinweis wird nicht weggelassen und nicht hochgestuft. Er bleibt als needs_validation stehen, mit dem exakten ungelösten Fakt, der zu seiner Klärung fehlt. Solche Einträge bleiben offen, das ist unbequem. Ein glatter Befund ohne Belege wäre schlechter.

Drei Urteile, ein Schema und zwei Validatoren

Phase vier übersetzt die Prüfergebnisse in eine maschinenlesbare Datei namens findings.json. Jeder Eintrag trägt eines von drei Urteilen. confirmed bedeutet: vollständiger Quellennachweis und ein begrenztes, tatsächlich beobachtetes Ergebnis. needs_validation bedeutet: ein exakter, ungelöster Fakt und ausdrücklich keine Schweregradeinschätzung. rejected dokumentiert einen widerlegten Kandidaten. Auch das ist ein Ergebnis, weil es verhindert, dass dieselbe Spur beim nächsten Lauf wieder aufgemacht wird.

Gegen das Schema report-schema.json prüft validate-findings.cjs, wieder ohne Abhängigkeiten. Das Skript läuft in Phase vier und erneut nach jeder Ersetzung in Phase fünf, damit kein nachträglich geänderter Datensatz ungeprüft stehen bleibt. Zu beiden Validatoren gehören Testdateien, die unter anderem prüfen, ob erzeugte Datensätze zum Schema passen.

Die Befunde sind keine Prosa, die man von Hand aus einem Langtext zieht. Sie sind Datensätze mit Quelle, Urteil und Begrenzung, die sich in ein Ticketsystem, eine Pipeline oder ein Prüfprotokoll übernehmen lassen. Einen zehnseitigen Scan-Bericht in Arbeitsschritte zu zerlegen, ist mühsam. Ob ein Audit weiterverarbeitet oder nur abgeheftet wird, hängt davon ab, ob die Befunde maschinenlesbar sind.

Unabhängige Nachprüfung und der additive Lauf über mehrere Durchgänge

Phase fünf setzt eine weitere Schicht darauf. Dort verifizieren frische Agenten die endgültigen Quellenaussagen, also die Behauptung, dass eine bestimmte Stelle im Code tatsächlich das tut, was der Befund ihr zuschreibt. Wird ein Eintrag inhaltlich ersetzt, bekommt er einen weiteren unabhängigen Prüfer. Erst danach entstehen in Phase sechs die Berichte: REPORT.md, FINDINGS-DETAIL.md und NEEDS-VALIDATION.md, abgeleitet aus den verifizierten Datensätzen und dem Coverage-Ledger. Die Berichte leiten sich aus den Datensätzen ab, sie sind nicht die Quelle der Wahrheit.

Mehrere Durchläufe gegen dasselbe Repository addieren sich. Frühere Ledger und Befunde werden genutzt, um gezielt Lücken anzugehen, geänderten Quellcode neu zu prüfen und belegte Aussagen zum aktuellen Code mitzunehmen. Veraltete oder ungelöste Arbeit wird dabei ausdrücklich nicht als erledigt behandelt. Ein Audit ist hier kein einmaliger Termin.

Cloudflare nennt für die eigenen Testläufe eine Zahl: Ein einzelner Durchlauf fand ungefähr die Hälfte der Schwachstellen, die wiederholte Läufe zusammen fanden. Ein mehrphasiger Sicherheitsaudit mit KI-Agent ist also nicht deshalb gründlich, weil er schlau ist, sondern weil er mehrfach und mit Gedächtnis läuft. Ein einmaliger Scan erreicht das nicht.

Angriffsklassen als Nachschlagewerk für verschiedene Zieltypen

Das Skill besteht nicht nur aus Ablauflogik, sondern aus einer Reihe von Wissensdateien. SKILL.md beschreibt Einrichtung, Grundprinzipien und Anti-Muster eines Audits, RECONNAISSANCE.md die Aufnahme, HUNTING.md die Orchestrierung der Suche, VALIDATION-AND-REPORTING.md die Phasen drei bis sechs. Dazu kommen Angriffsklassen als eigene Dateien.

Für native Ziele gibt es MEMORY-SAFETY-AND-BINARY.md mit Speichersicherheit, Binär- und Kernel-Klassen. Für Systeme mit Sprachmodellen liegt AI-AND-LLM.md bereit, mit Prompt-Injection, Agenten- und Werkzeuggrenzen sowie der Behandlung von Modellausgaben. Weitere Dateien decken HTTP-Protokoll und Authentifizierung, clientseitige Themen von DOM-Injection bis Prototype-Pollution, Supply Chain und Release, Cloud und Deployment, RPC und Messaging, Ressourcenerschöpfung, Mandantentrennung und Datenlebenszyklus sowie Desktop-, Mobile- und lokale IPC-Flächen ab. Die Reihenfolge ist keine Rangfolge, sondern eine Auswahlhilfe je nach Ziel.

Solche Prüfungen scheitern üblicherweise an einem Muster: Ein Agent, der „finde Schwachstellen“ liest, greift auf das Offensichtliche zu und verteilt seine Aufmerksamkeit dünn über alles. Ein Katalog verschiebt die Arbeit von allgemeinem Verdacht zu konkreten Klassen mit bekannten Mustern. Ein Sprachmodell prüft hier ein System, das selbst Sprachmodelle enthält. Prompt-Injection betrifft beide Seiten.

Installation, Sandbox-Pflicht und was das im Alltag bedeutet

Die Installation läuft über die Skills-CLI. Ein Aufruf wie npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit bindet das Skill ein, mit dem Zusatz --global gilt es benutzerweit statt nur im aktuellen Projekt. Für Auswahl des Agenten und nicht-interaktive Varianten gibt die Hilfe der CLI Auskunft. Danach startet man den Coding-Agenten im zu prüfenden Repository und bittet um ein Security Audit; das Skill aktiviert sich, wenn die Anfrage zu seinen Auslösern passt.

Zwei Betriebsarten sind vorgesehen. Eine gezielte Frage oder eine einzelne Schwachstellenanalyse läuft im Guidance-Modus, ein vollständiger Audit- oder Pen-Test-Auftrag im Full-Audit-Modus. In diesem Modus landen die Ergebnisse ohne Angabe eines Verzeichnisses unter einem Benutzerpfad mit Repo-Namen und laufender Nummer; in das Repository selbst wird nur geschrieben, wenn ausdrücklich ein ignoriertes Verzeichnis gewählt wurde. So liegen Audit-Artefakte nicht ungewollt im Versionskontrollsystem.

Die Anforderungen sind nüchtern, mit einer harten Kante: Gebraucht wird ein Coding-Agent, dessen Modell Werkzeugnutzung und parallele Unteragenten beherrscht, dazu Node.js für die Validatoren. Vor allem aber braucht es eine vom Betriebssystem erzwungene Sandbox für alles, was vom Ziel gesteuert wird: Builds, Tests, Prozesse, Browser, Emulatoren und Fuzzer. Diese Sandbox muss externes Netzwerk abschalten, eine bereinigte Umgebung mit Erlaubnisliste verwenden, Ressourcengrenzen durchsetzen und Schreibzugriffe auf zugewiesene Pfade begrenzen. Fehlen diese Kontrollen, führt der Ablauf den Code des Ziels nicht aus, sondern belässt den Hinweis als needs_validation.

Ein automatisiertes Audit, das fremden Build-Code ohne Netzwerksperre und ohne Ressourcengrenzen ausführt, verschiebt das Risiko vom Prüfling zum Prüfer. Der Workflow nimmt dafür lieber einen offenen Eintrag in Kauf, als diese Grenze zu überschreiten. Das Skill ist unter MIT-Lizenz veröffentlicht, Rückmeldungen laufen über eine Cloudflare-Adresse für Sicherheitsforschung mit KI.

Wer einen Coding-Agenten für Schwachstellenanalyse einsetzen will, sollte auf den Ablauf achten, nicht auf das Modell: ein Prüfplan mit Kennungen, getrennte Finder und Prüfer, drei klar definierte Urteile und Datensätze, die eine Pipeline lesen kann. Ein Sicherheitsaudit wird damit zu einem wiederkehrenden Vorgang mit wachsendem Ledger statt zu einem einmaligen Knopfdruck. Ein einzelner Durchlauf findet etwa die Hälfte aller Schwachstellen. Der Rest braucht weitere Läufe.

Quelle: github.com

23 Punkte im Artificial Analysis Intelligence Index, erreicht mit 5,1 Milliarden aktiven Parametern pro Token. Diese Zahl beschreibt das Verhältnis von Leistung zu Rechenaufwand, und darum geht es bei Ling-3.0-flash-Fin von der Ant Group. Das Modell liegt damit auf der Pareto-Grenze zwischen Intelligenz und aktiver Parameterzahl: Es liefert für seinen Rechenbedarf überdurchschnittlich viel. Wer offene Modelle für den produktiven Einsatz auswählt, achtet heute auf solche Verhältnisse, nicht nur auf die absolute Bestenliste.

Ant Group hat Ling-3.0-flash-Fin als Open-Weights-Modell veröffentlicht, das auf Ling-3.0-flash aufbaut und sich an Finanzarbeit richtet. Nach Angaben des Unternehmens entstand es gemeinsam mit Finanzinstituten und Branchenfachleuten, um Aufgaben wie das Prüfen von Quellen, den Aufbau von Bewertungstabellen und das Schreiben von Berichten zu unterstützen. Es ist ein reines Textmodell, während der zuvor veröffentlichte Vorgänger Ling-3.0-flash-VL auch Bilder und Videos als Eingabe verarbeitet und 25 Punkte im Intelligence Index erreicht. Der Vergleich der beiden zieht sich durch diese Auswertung und sagt mehr über Fins Ausrichtung als jede Marketingformulierung.

Wofür Ant Group das finanzorientierte KI-Modell positioniert

Die genannten Anwendungsfälle klingen bewusst nüchtern: Quellen prüfen, Bewertungsmodelle in Tabellen aufbauen, Berichte formulieren. Das sind Tätigkeiten, die in Analystenhäusern, Investmentabteilungen und Prüfungsgesellschaften einen großen Teil der Arbeitszeit binden. Und sie haben eine Gemeinsamkeit: Sie sind fehlerempfindlich. Ein falsch zitierter Geschäftsbericht oder eine Formel, die stillschweigend auf die falsche Zeile verweist, richtet mehr Schaden an als eine fehlende Antwort. Genau dort setzt Ant Group an. Ling-3.0-flash-Fin soll nicht den breitesten Werkzeugkasten mitbringen, sondern den passenden.

Die Abgrenzung zum Schwestermodell ist aufschlussreich. Während Ling-3.0-flash-VL Bilder und Videos als Eingabe akzeptiert, beschränkt sich Fin auf Text. Wer viel mit gescannten Dokumenten, Kurscharts oder Präsentationen arbeitet, verliert damit eine Fähigkeit, die im Finanzalltag zählt. Die Frage ist also nicht, ob Fin das bessere Modell ist, sondern für welche Arbeit sich der Verzicht auf Bildeingabe lohnt. Ein Modell ohne Augen kann trotzdem sehr gut rechnen — es sieht nur nicht, worüber es rechnet.

124 Milliarden Parameter, 5,1 Milliarden aktiv: wie das MoE-Modell arbeitet

Hinter den Zahlen steht ein MoE-Modell, also eine Mixture of Experts. Man kann sich das wie eine große Fachberatung vorstellen: Die 124 Milliarden Parameter sind die gesamte Belegschaft, doch pro Token werden nur 5,1 Milliarden davon aktiviert. Für jeden kleinen Arbeitsschritt ruft das System nur die Spezialisten herein, die gerade gebraucht werden, statt das ganze Haus zu beschäftigen. Deshalb lässt sich ein Modell dieser Gesamtgröße überhaupt wirtschaftlich betreiben. Und deshalb ist die aktive Parameterzahl inzwischen die wichtigere Größe als die Gesamtzahl.

Das Kontextfenster liegt bei 256.000 Token, was für Jahresabschlüsse, Vertragswerke oder längere Rechercheketten ausreicht. Die Lizenz ist MIT, eine der freizügigsten überhaupt, und der Zugang läuft unter anderem über OpenRouter, inklusive eines ratenbegrenzten kostenlosen Endpunkts. Offene Gewichte, großzügige Lizenz und geringer Aktivierungsaufwand — das zusammen macht dieses Modell für Finanzanwendungen interessant. Du kannst es selbst hosten, ohne dass die Rechnung außer Kontrolle gerät, und das ist in regulierten Umgebungen oft die Voraussetzung dafür, dass ein Modell überhaupt in Frage kommt.

Die Benchmarks: Intelligence Index, Pareto-Grenze und der Vergleich mit MiniMax-M2.7

Auf dem Intelligence Index erreicht Ling-3.0-flash-Fin 23 Punkte und zieht damit mit MiniMax-M2.7 gleich. Der Unterschied liegt im Aufwand. Fin aktiviert 5,1 Milliarden Parameter pro Token, MiniMax-M2.7 rund 10 Milliarden. Etwa halbe Rechenlast für dasselbe Ergebnis. Im Dauerbetrieb ist das relevanter als jeder Spitzenwert, weil sich Kosten über Millionen Anfragen summieren. Wer ein Modell in eine Pipeline einbaut, merkt den Unterschied zwischen 5 und 10 Milliarden aktiven Parametern jeden Tag.

Anders sieht es aus, wenn man die gesamte Modellgröße betrachtet. Ling-3.0-flash-VL kommt auf 25 Punkte bei 5,5 Milliarden aktiven Parametern, beide Ling-Modelle haben 124 Milliarden Parameter insgesamt. Qwen3.8 27B in der xhigh-Konfiguration erreicht mit 27 Milliarden Gesamtparametern einen Wert von 34 und liegt damit auf der Frontier bezogen auf die Gesamtgröße, während die Ling-Modelle dort darunter bleiben. Es gibt also nicht die eine Rangliste, sondern mindestens zwei Grenzlinien: eine für aktive Parameter, eine für das Gesamtmodell. Je nachdem, ob bei dir Speicherplatz oder Rechenzeit der Engpass ist, fällt die Bewertung unterschiedlich aus.

24 Punkte im Finance & Accounting Index und die Frage der Halluzinationen

Im Artificial Analysis Finance & Accounting Index kommt Ling-3.0-flash-Fin auf 24 Punkte und damit auf denselben Wert wie Ling-3.0-flash-VL. Dieser Index bündelt mehrere Fähigkeiten: betriebswirtschaftliches Wissen, logisches Schlussfolgern, agentische Arbeit, die Analyse langer Kontexte und die Zuverlässigkeit, nichts zu erfinden. Dass ein Textmodell hier gleichauf mit einem multimodalen liegt, zeigt: Für dieses Ergebnis spielt die Bildeingabe keine entscheidende Rolle. Die Ausrichtung auf Finanzsprache und Finanzdokumente scheint den fehlenden Eingabekanal zumindest teilweise auszugleichen.

Genauer betrachtet zeigt sich ein Zielkonflikt. Fin erzielt eine höhere Genauigkeit beim betriebswirtschaftlichen Wissen, nämlich 17 Prozent gegenüber 11 Prozent beim VL-Modell. Gleichzeitig halluziniert es häufiger: Die Nicht-Halluzinationsrate liegt bei 67 Prozent gegenüber 81 Prozent. Umgerechnet erfindet Fin also in 33 Prozent der geprüften Fälle etwas, während VL bei 19 Prozent liegt. Mehr richtige Fakten, aber auch mehr erfundene.

In der Finanzarbeit ist das ein unangenehmes Muster, weil ein falsches Ergebnis nicht immer als falsch erkennbar ist. Eine erfundene Kennzahl sieht genauso aus wie eine recherchierte. Wer das Modell einsetzt, sollte deshalb jede Zahl gegen die Originalquelle prüfen. Das Modell soll beim Prüfen von Quellen helfen, braucht aber selbst diese Prüfung. Der Nutzen liegt damit weniger im fertigen Ergebnis als in der Vorarbeit — Material sichten, Struktur vorschlagen, Entwürfe bauen.

Agentische Aufgaben: GDPval, AA-Briefcase, AutomationBench und Terminal-Bench

Bei professionellen Wissensaufgaben schneidet Fin etwas schwächer ab als sein Schwestermodell. Auf GDPval-AA v2, einem Benchmark für die Erstellung von Dokumenten und Tabellen, erreicht es 1171 Elo gegenüber 1225 für VL, liegt damit aber noch deutlich über MiniMax-M2.7 mit 1087. Bei AA-Briefcase, wo Agenten aus großen Dateisammlungen Tabellen, Präsentationen und Memoranden erzeugen, kommt Fin auf 967 Elo gegenüber 986 für VL. Die Abstände sind klein, aber sie zeigen in eine klare Richtung: Das Finanzmodell ist beim agentischen Arbeiten nicht die stärkere Variante.

Im Detail ist das Ergebnis gespalten. Fin besteht weniger Rubrik-Prüfungen, nämlich 23,5 gegenüber 24,9 Prozent, und erreicht beim Kriterium Analytical Quality 866 statt 907 Elo. Bei der Präsentationsqualität liegt es mit 1095 zu 1076 jedoch leicht vorn, und das, obwohl ihm die Bildeingabe fehlt, über die das VL-Modell verfügt. Offenbar zahlt sich die Ausrichtung auf Textausgabe an dieser Stelle direkt aus. Ein Modell, das ausschließlich Text verarbeitet, schreibt am Ende vielleicht die gefälligeren Dokumente.

Klarer wird der Abstand bei Aufgaben, die echte Abläufe über mehrere Anwendungen hinweg verlangen. AutomationBench-AA prüft, ob ein Agent Arbeitsabläufe in Geschäftsanwendungen erledigt und dabei vorgegebene Leitplanken einhält. Fin erreicht dort 7 Prozent, VL kommt auf 16 Prozent. Bei Terminal-Bench v4.0, das schwierige Kommandozeilenaufgaben testet, stehen beide Modelle bei 0 Prozent. Anspruchsvolle agentische Arbeit bleibt eine Baustelle, und zwar nicht nur für Fin, sondern für dieses gesamte Modellsegment. Wenn du vorhast, dem Modell selbstständig Workflows zu überlassen, solltest du diese Zahlen genau lesen.

67.000 Output-Tokens pro Aufgabe, Rate-Limit-Zugang und der Blick auf die Kosten

Ein Punkt, der in Benchmark-Tabellen leicht untergeht, ist der Ausgabeverbrauch. Für eine Aufgabe im Intelligence Index produziert Ling-3.0-flash-Fin im Schnitt rund 67.000 Output-Tokens. Das sind etwa 34 Prozent mehr als beim VL-Modell mit ungefähr 50.000 und rund das 3,2-fache von MiniMax-M2.7 mit etwa 21.000 Tokens pro Aufgabe. Ein Modell, das mehr schreibt, ist in der Praxis teurer, langsamer und schwieriger in feste Abläufe zu integrieren. Dazu kommt, dass Fin als Reasoning-Modell ausführlich nachdenkt, bevor es antwortet; diese Ausführlichkeit erklärt einen Teil der Tokenmenge und ist bei komplexen Bewertungsfragen oft erwünscht.

In der Massenverarbeitung, etwa beim Screening tausender Dokumente, wird dieselbe Eigenschaft zum Kostenfaktor. Wer das Modell produktiv betreiben will, sollte deshalb nicht nur die Genauigkeit messen, sondern auch die Token pro erledigter Aufgabe — und die Frage, ob ein knapperes Modell mit etwas geringerer Qualität unterm Strich billiger ans Ziel kommt. Der Zugang über OpenRouter mit einem ratenbegrenzten kostenlosen Endpunkt macht das Ausprobieren leicht, ersetzt aber keine eigene Messung am konkreten Anwendungsfall.

Ling-3.0-flash-Fin ist ein spezialisierter Arbeiter, kein Universalist. 23 Punkte im Intelligence Index bei 5,1 Milliarden aktiven Parametern, 24 Punkte im Finance & Accounting Index, 256.000 Token Kontext und eine MIT-Lizenz ergeben ein Paket, das sich gut selbst hosten und in bestehende Pipelines einfügen lässt. Die Kehrseiten sind ebenso klar: eine Halluzinationsrate von 33 Prozent im Wissensbereich, 7 Prozent bei Automationsabläufen und 0 Prozent bei schwierigen Terminal-Aufgaben. Der realistische Einsatz liegt damit in der Zuarbeit — Quellen finden, Tabellen vorbereiten, Entwürfe schreiben — während die abschließende Prüfung bei Menschen bleibt. Dort, bei der Entlastung von Routinearbeit, liegt sein Nutzen; als eigenständiger Entscheider in Finanzfragen taugt es nach dieser Datenlage nicht.

Quelle: artificialanalysis.ai