Erste AA-AgentPerf-Ergebnisse für NVIDIA Vera Rubin NVL72

Alle Artikel

Erste AA-AgentPerf-Ergebnisse für NVIDIA Vera Rubin NVL72

Erste Ergebnisse für NVIDIAs Vera Rubin NVL72 sind jetzt auf AA-AgentPerf live. Das System liefert bis zu ~5,7-fachen Gesamtdurchsatz pro Megawatt seines Vorgängers GB300 NVL72 bei DeepSeek V4 Pro, ~5,4-fachen bei DeepSeek V4.1 Flash, ~3,0-fachen bei GLM-5.2 und ~2,8-fachen bei Kimi K3. Vera Rubin ist NVIDIAs Nachfolger von Blackwell, und Vera Rubin NVL72 ist das Rack-Scale-System mit 72 Rubin-GPUs und 36 Vera-CPUs.

Größter Vorsprung beim Durchsatz pro MW gegenüber GB300 NVL72, Stand 15. Oktober 2026

• ~5,7x DeepSeek V4 Pro bei ~190 tok/s pro Nutzer
• ~5,4x DeepSeek V4.1 Flash bei ~580 tok/s pro Nutzer
• ~3,0x GLM-5.2 bei ~165 tok/s pro Nutzer
• ~2,8x Kimi K3 bei ~67 tok/s pro Nutzer

Agentic-Coding-Workloads sind schwer effizient zu bedienen

Coding-Agents arbeiten in einer Schleife: Das Modell denkt nach und ruft ein Tool auf, das Harness führt dieses Tool aus und hängt seine Ausgabe an die Konversation an, und die gesamte Konversation geht zurück an das Modell für den nächsten Schritt. Da jede Anfrage alles Vorherige enthält, wächst der Kontext ständig, während der Agent Dateien liest, Tests ausführt und Änderungen vornimmt (wobei die Antworten des Modells selbst kurz bleiben), sodass agentischer Verkehr sich deutlich von Chat oder den Prompts fester Länge unterscheidet, die viele Inferenz-Benchmarks verwenden.

AA-AgentPerf spielt echte Coding-Agent-Trajektorien (erzeugt von Agents, die Issues in öffentlichen Code-Repositories lösen) mit einer Reihe von Concurrency-Leveln ab, wobei jeder simulierte Agent drei Trajektorien nacheinander durchläuft und nach jeder Antwort für eine aus echten Tool-Call-Dauern gezogene Tool-Call-Zeit pausiert. Anfragen enthalten bis zu 132K Eingabetoken, während Antworten oft nur ein kurzer Tool-Call sind, und im Durchschnitt wiederholen 97% der Eingabetoken einer Anfrage die vorherige Anfrage.

Wenn ein Serving-Stack dieses wiederholte Präfix in seinem KV-Cache hält, muss er nur die Tokens vorbefüllen, die jeder Turn hinzufügt, statt jedes Mal den gesamten Kontext neu zu verarbeiten. Im folgenden Beispiel wächst eine der längeren Trajektorien über 118 Anfragen von 10K auf 116K Kontext-Tokens, wobei der Agent insgesamt 9,7M Eingabetokens an das Modell sendet (davon nur 116K neu) und das Modell über alle seine Antworten 20K Ausgabetokens generiert.

Eingabetokens pro Anfrage in einer Agent-Session

• Aus vorheriger Anfrage wiederholt
• Neu seit vorheriger Anfrage

Einige der besonderen Merkmale der agentischen Inferenz, die beim Benchmarking eine spezielle Behandlung erfordern, sind:

• KV-Cache-Kapazität und -Wiederverwendung, da Tausende gleichzeitige Agents jeweils Zehntausende Tokens Kontext halten können, die während der Tool-Call-Pausen zwischengespeichert bleiben und für die nächste Anfrage wieder auffindbar sein müssen
• Ungleiche Prefill-Mengen, wobei jeder Turn zwischen wenigen Tokens und Zehntausenden hinzufügen kann (z. B. wenn ein Tool eine große Datei zurückgibt), auf einem langen zwischengespeicherten Präfix
• Kurze Ausgaben, da viele Antworten kurze Tool-Calls sind, was Time to First Token und Scheduling-Overhead wichtiger macht als bei Langtext-Generierung

AA-AgentPerfs Workload bildet diese Merkmale ab:

Bis zu 132K

Eingabetokens pro Anfrage, mit 1M-Token-Kontexten in Kürze

Bis zu182

Anfragen in einer einzigen Trajektorie

Bis zu11M

Eingabetokens, die über eine einzige Trajektorie an das Modell gesendet werden

Bis zu 69K

Neue Eingabetokens, die in einem Zug hinzugefügt werden, wenn ein Tool eine große Ausgabe zurückgibt

Bis zu 5 s

Pause für einen Toolaufruf zwischen einer Anfrage und der nächsten

97%

Anteil der Eingabetokens, die im Durchschnitt aus der vorherigen Anfrage wiederholt werden

AA-AgentPerf-Workload-Statistiken über 500 Trajektorien und 18,997 Anfragen, tokenisiert mit o200k_base. Details dazu in unserer Methodik .

Vera Rubin NVL72 führt GB300 NVL72 mit bis zu ~5,7x pro MW an

Vera Rubin NVL72 behält das Rack-Scale-Design von GB300 NVL72 bei, mit 72 GPUs und 36 CPUs in einer einzigen NVLink-Domäne. Jede Rubin-GPU hat denselben 288 GB Speicher wie Blackwell Ultra, aber die 2,4-fache Speicherbandbreite (dank HBM4), die 1,7-fache NVLink-Bandbreite und das 2,3-fache dense NVFP4-Compute, und die Vera-CPU verdoppelt die NVLink-C2C-Bandbreite zu ihren GPUs, was die Verbindung ist, die jeden KV-Cache, der in den CPU-Speicher ausgelagert wird, überträgt.

Spezifikationen von NVIDIAs Vera Rubin NVL72, Blackwell Ultra und GB300 NVL72 Seiten, Stand Oktober 2026. Gemessene Leistung ist der eigene Leistungsverbrauch jeder GPU unter Last (die GPU und ihr HBM, wie von NVIDIAs DCGM/SMI-Telemetrie gemeldet, ohne CPUs, Netzwerk und Kühlung), über die Konfigurationen an der Frontier jedes Systems für die vier Modelle.

Ergebnisse über die vier Modelle

Jedes der folgenden Diagramme trägt den Gesamtdurchsatz pro MW gemessener GPU-Leistung gegen die Ausgabegeschwindigkeit pro Nutzer auf. Der Gesamtdurchsatz zählt Eingabe-Token (gecachte und neu vorberechnete) und Ausgabe-Token, wobei ~96% davon gecachte Eingaben sind, und die Geschwindigkeit pro Nutzer ist das 25. Perzentil (p25) über Anfragen ohne die Zeit bis zum ersten Token, was die Geschwindigkeit ist, die wir durchgängig zitieren. Jeder Punkt ist eine Serving-Konfiguration bei einer festen Anzahl von Agenten, und der Pfeil markiert Vera Rubins größten Vorsprung gegenüber GB300.

• Beim Spitzen throughput bedient Vera Rubin NVL72 272M tokens/s pro MW bei DeepSeek V4 Pro gegenüber 239M für GB300 NVL72 (1,14x), 571M gegenüber 395M bei DeepSeek V4.1 Flash (1,45x), 272M gegenüber 201M bei GLM-5.2 (1,35x) und 70M gegenüber 56M bei Kimi K3 (1,26x)
• Vera Rubins Vorsprung ist am größten, wo GB300s Durchsatz einbricht, und erreicht ~5,7x bei DeepSeek V4 Pro bei ~190 tok/s pro Nutzer, ~5,4x bei DeepSeek V4.1 Flash bei ~580 tok/s, ~3,0x bei GLM-5.2 bei ~165 tok/s und ~2,8x bei Kimi K3 bei ~67 tok/s. Der Sprung von ~120 auf ~165 tok/s pro Nutzer bei DeepSeek V4 Pro kostet GB300 81% seines Durchsatzes pro MW, verglichen mit 16% für Vera Rubin
• Pro GPU ist Vera Rubins Vorsprung wiederum größer: 2,0x bis 2,5x beim Spitzen throughput, und bis zu ~12x bei DeepSeek V4 Pro bei ~165 tok/s pro Nutzer, ~18x bei DeepSeek V4.1 Flash bei ~580 tok/s, ~7x bei GLM-5.2 zwischen ~200 und ~310 tok/s und ~7x bei Kimi K3 bei ~176 tok/s
• Vera Rubins schnellste Konfigurationen stellen die höchsten Geschwindigkeiten pro Nutzer auf unserer Bestenliste auf: bei DeepSeek V4.1 Flash (906 tok/s, das schnellste Ergebnis für ein Modell), GLM-5.2 (408 tok/s) und Kimi K3 (255 tok/s)

Eine bessere Energieeffizienz senkt die Betriebskosten des Servierens jedes Tokens, und da KI-Rechenzentren zunehmend durch die Leistung, die sie beziehen können, statt durch die Anzahl der installierbaren Beschleuniger begrenzt werden, ermöglicht sie auch, mehr Agenten aus demselben Rechenzentrum zu bedienen. Bei ~165 tok/s pro Nutzer zum Beispiel bedient derselbe GPU-Leistungsbudget auf Vera Rubin NVL72 etwa 5x so viele DeepSeek V4 Pro Tokens wie auf GB300 NVL72. Jeder Punkt auf unserer Bestenliste enthält die dahinterstehende Serving-Konfiguration in unserem Konfigurationsbrowser, sodass Teams von einer abgestimmten Einrichtung für ihre eigene Hardware ausgehen können, anstatt eine eigene Performance-Studie durchzuführen.

DeepSeek V4 Pro Ergebnisse zeigen den größten Vorsprung bei hohen Geschwindigkeiten

DeepSeek V4 Pro hat 1,6T Gesamt- und 49B aktive Parameter und verwendet eine Hybridform aus komprimierter sparsamer und stark komprimierter Attention, um seinen KV-Cache bei langem Kontext klein zu halten.

Total Throughput per MW vs. Output SpeedDeepSeek V4 Pro 0813 (max)

Die Decode-Rate pro Anfrage, d. h. Ausgabe-Token pro Sekunde, die jede Anfrage erhält, nachdem das erste Token angekommen ist (ohne Wartezeit bis zum Erhalt des ersten Tokens). Diagramme zeigen standardmäßig das 25. Perzentil über Anfragen, die Geschwindigkeit, die drei Viertel der Anfragen überschritten haben.

• Beim Spitzen throughput bedient Vera Rubin NVL72 272M tokens/s pro MW bei 69 tok/s pro Nutzer, 1,14x GB300 NVL72s 239M bei 67 tok/s, und bleibt bis ~120 tok/s pro Nutzer etwa 1,1x voraus
• Der Abstand öffnet sich jenseits von ~130 tok/s pro Nutzer, da GB300s Durchsatz abfällt, wobei Vera Rubin 174M tokens/s pro MW bei ~165 tok/s pro Nutzer bedient gegenüber 34M für NVIDIAs GB300-Konfigurationen (5,1x), und 132M bei ~190 tok/s gegenüber ~23M für GB300 (~5,7x). NVIDIAs GB300-Rack-Konfigurationen erreichen bei ~163 tok/s pro Nutzer ihr Maximum, daher stammt die GB300-Linie darüber hinaus von kleinen 4-GPU-Konfigurationen, die wir gebaut haben
• Vera Rubins schnellste Konfiguration läuft bei 298 tok/s pro Nutzer, und oberhalb von ~255 tok/s pro Nutzer bedienen diese 4-GPU-GB300-Konfigurationen mehr Token pro MW als Vera Rubin und verlängern GB300s Ergebnisse auf 340 tok/s
• Vera Rubins Konfigurationen brauchen länger, um das erste Token zurückzugeben (im Median 1,65 s bei ~165 tok/s pro Nutzer, verglichen mit 1,08 s für GB300), und gemessen an der End-to-End-Geschwindigkeit, die diese Wartezeit einschließt, erreicht oder übertrifft GB300 Vera Rubins Durchsatz pro MW bei den meisten Geschwindigkeiten

DeepSeek V4.1 Flash Ergebnisse stellen den höchsten Durchsatz und die höchsten Geschwindigkeiten auf unserer Bestenliste auf

DeepSeek V4.1 Flash hat 552B Backbone-Parameter, von denen es 8B pro Token während des Prefill und 16B während des Decode aktiviert, plus einen 196B-Parameter-Engram-Speicher, den es per Token-Lookup liest. Seine sparse Attention und der FP4 KV-Cache halten den KV-Cache bei ~890 Bytes pro Token, rund ein Viertel von DeepSeek V4 Flashs.

Total Throughput per MW vs. Output SpeedDeepSeek V4.1 Flash (max)

Die Decode-Rate pro Anfrage, d. h. Ausgabe-Token pro Sekunde, die jede Anfrage erhält, nachdem das erste Token angekommen ist (ohne Wartezeit bis zum Erhalt des ersten Tokens). Diagramme zeigen standardmäßig das 25. Perzentil über Anfragen, die Geschwindigkeit, die drei Viertel der Anfragen überschritten haben.

• Vera Rubin NVL72 erreicht mit 571M tokens/s pro MW bei 68 tok/s pro User ihren Höhepunkt – den höchsten Durchsatz pro MW in unserem Leaderboard über alle vier Modelle, vor B300s Spitzenwert von 433M und GB300 NVL72s 395M (bei 31 bzw. 23 tok/s pro User)
• Vera Rubins Vorsprung vor dem GB300 wächst mit der Geschwindigkeit pro Benutzer, von ~1,8x bei 68 tok/s auf ~2,9x bei ~165 tok/s und ~3,4x bis ~3,6x zwischen ~230 und ~350 tok/s, und erreicht ~5,4x bei ~580 tok/s pro Benutzer mit einer 12-GPU-Konfiguration, die die Decodierung auf fünf Worker verteilt
• Vera Rubins schnellstes Ergebnis, 906 tok/s pro Benutzer von einem einzelnen 4-GPU-Server, der einen Agenten bedient, ist das schnellste Ergebnis auf unserem Leaderboard für ein beliebiges Modell, vor 669 tok/s auf B200 und 596 tok/s auf GB300 für DeepSeek V4.1 Flash
• Pro GPU liefert Vera Rubin 651K tokens/s auf dem Höhepunkt, 2,3x GB300s 284K, und ~6,5x die GB300-Linie bei ~300 tok/s pro Benutzer

NVIDIAs Vera Rubin liefert bei DeepSeek V4.1 Flash Antworten mit einer Obergrenze von 2,048 Output-Tokens, verglichen mit 16,384 bei den anderen DeepSeek V4.1 Flash-Ergebnissen auf unserem Leaderboard. Etwa 2% der Antworten erreichten die Obergrenze und die durchschnittliche Antwort war etwa ein Zehntel kürzer (275 bis 301 Tokens gegenüber 319 bis 335), was Vera Rubins Durchsatz moderat begünstigt.

GLM-5.2-Ergebnisse zeigen einen Vorsprung von ~3x bei höheren Geschwindigkeiten

GLM-5.2 hat 753B Parameter insgesamt und 40B aktive Parameter mit DeepSeek-artiger spärlicher Aufmerksamkeit. Wir tragen GLM-5.2 und GLM-5.3 in einem Leaderboard-Diagramm auf, da sie eine Architektur teilen.

Total Throughput per MW vs. Output SpeedGLM-5.2 & 5.3 (max)

Die Decode-Rate pro Anfrage, d. h. Output-Tokens pro Sekunde, die jede Anfrage erhält, nachdem das erste Token angekommen ist (ohne die Wartezeit bis zum Empfang des ersten Tokens). Diagramme zeigen standardmäßig das 25. Perzentil über alle Anfragen, die Geschwindigkeit, die drei Viertel der Anfragen überschritten haben.

• Vera Rubin NVL72 erreicht 272M tokens/s pro MW bei 84 tok/s pro Benutzer auf dem Höhepunkt, 1,35x GB300 NVL72s 201M bei 68 tok/s pro Benutzer
• Bei ~165 tok/s pro Benutzer liefert Vera Rubin 159M tokens/s pro MW, ~3,0x die GB300-Linie bei derselben Geschwindigkeit (~53M), und der Abstand bleibt zwischen ~2,7x und ~3x bis zu ~310 tok/s pro Benutzer
• Vera Rubins schnellstes Ergebnis, 408 tok/s pro Benutzer, ist das schnellste GLM-5.2-Ergebnis auf unserem Leaderboard, vor 333 tok/s auf B300 und 330 tok/s auf GB300
• Gegenüber der End-to-End-Geschwindigkeit gemessen, die die Zeit bis zum ersten Token einschließt, liefert Vera Rubin weiterhin 1,1x bis 1,8x GB300s Durchsatz pro MW über den gesamten Bereich

Kimi K3-Ergebnisse zeigen einen Vorsprung von ~2,8x bei moderaten Geschwindigkeiten

Kimi K3 ist das größte Modell, das wir vorstellen, mit 2.8T Parametern insgesamt und 104B aktiven Parametern, und einem hybriden Design, das in 69 seiner 93 Schichten lineare Aufmerksamkeit verwendet.

Total Throughput per MW vs. Output SpeedKimi K3 (max)

Die Decode-Rate pro Anfrage, d. h. Output-Tokens pro Sekunde, die jede Anfrage erhält, nachdem das erste Token angekommen ist (ohne die Wartezeit bis zum Empfang des ersten Tokens). Diagramme zeigen standardmäßig das 25. Perzentil über alle Anfragen, die Geschwindigkeit, die drei Viertel der Anfragen überschritten haben.

• Jedes System liefert auf Kimi K3 deutlich weniger Tokens pro MW als bei den anderen drei Modellen, wobei Vera Rubin NVL72 mit 70M tokens/s pro MW bei 41 tok/s pro Benutzer auf dem Höhepunkt liegt, 1,26x GB300 NVL72s Spitze von 56M bei 40 tok/s
• Bei ~67 tok/s pro Benutzer liefert Vera Rubin ~2,8x den Durchsatz pro MW der GB300-Linie (59M gegenüber ~21M), und seine 30-Agenten-Konfiguration liefert ~2,4x die GB300-Linie bei 176 tok/s pro Benutzer (9,6M gegenüber ~4,0M). NVIDIAs aktuelle Vera Rubin-Konfigurationen lassen eine Lücke zwischen ~74 und ~176 tok/s pro Benutzer
• Vera Rubins schnellstes Ergebnis, 255 tok/s pro Benutzer von einem einzelnen 8-GPU-vLLM-Server, ist das schnellste Kimi K3-Ergebnis auf unserem Leaderboard, vor B300 (235) und GB300 (194)
• Die Zeit bis zum ersten Token ist bei maximalem Durchsatz auf beiden Systemen lang, mit einem p95 von 9.3 s für Vera Rubins 2,048-Agenten-Konfiguration und 19 s für GB300s 768-Agenten-Konfiguration

NVIDIA hat seinen Vera Rubin-Stack für agentische Workloads optimiert

NVIDIA hat mitgeteilt, wie es seine Vera Rubin- und GB300-Konfigurationen gebaut hat. Der aktuelle Satz an Konfigurationen ist zwischen Vera Rubin und GB300 sehr ähnlich, daher stammt der Großteil des Leistungsunterschieds aus der verbesserten Hardware der neueren Rack-Generation, zusammen mit frühen Rubin-spezifischen Kernels und Optimierungen. Die Techniken umfassen:

• KV-Caching über Speicherebenen hinweg. Da im Durchschnitt 97% der Input-Tokens einer Anfrage aus der vorherigen Anfrage wiederholt werden, ist Prefix-Caching unverzichtbar, und Deployments benötigen jede Speicherebene von HBM bis Host-Speicher (und schließlich Festplatte). Die meisten Vera Rubin-Konfigurationen lagern den KV-Cache über NVLink-C2C in den CPU-Speicher aus, was Vera auf 1.8 TB/s pro Superchip verdoppelt, wobei die Übertragungen andere GPU-Arbeit überlappen, da lange agentische Kontexte die GPU-zu-CPU-Bandbreite in einer Weise offenkundig machen, die kurze synthetische Prompts nicht tun. Die DeepSeek V4 Pro-Prefill-Worker haben 120 bis 200 GiB Host-Speicher für den KV-Cache konfiguriert. Die DeepSeek V4.1 Flash-Konfigurationen halten stattdessen das 196B-Parameter-Engram-Gedächtnis des Modells im CPU-Speicher statt in HBM.
• Sitzungsbewusstes Routing mit NVIDIA Dynamo. Agentensitzungen kehren Runde um Runde zum gleichen Kontext zurück, daher lohnt es sich, jede Anfrage an den Worker zu senden, der bereits den Cache dieser Anfrage hält. Jede Vera Rubin-Konfiguration läuft hinter NVIDIA Dynamo, NVIDIAs Open-Source-Serving-Framework, das die Runden jedes Agenten auf demselben Prefill-Worker hält und bei DeepSeek V4 Pro, GLM-5.2 und Kimi K3 jede Anfrage an den Worker sendet, der den größten Teil ihres Präfixes im Cache hält. Kimi K3s Linear-Attention-Schichten erschweren dies, da ihr rekurrenter Zustand nicht wie ein Standard-KV-Cache zu einem früheren Punkt zurückgerollt werden kann, sodass die Wiederverwendung einen Snapshot erfordert, der an der richtigen Stelle gespeichert wurde.
• Disaggregiertes Serving mit breiter Expert-Parallelität. Ein Turn kann von wenigen Tokens bis zu zehntausenden hinzufügen, also läuft Prefill in allen außer den Konfigurationen mit der niedrigsten Concurrency auf separaten Workern, wo eine große Tool-Ausgabe das Decoding aller anderen Agenten nicht aufhält. NVIDIA dimensioniert jede Seite nach dem Concurrency-Level, was bei DeepSeek V4 Pro ein bis sechs 4-GPU-Prefill-Worker bei steigender Concurrency bedeutet, wobei die Experten des Modells auf bis zu 32 Decode-GPUs verteilt sind und der KV-Cache jeder Anfrage über NVLink vom Prefill zum Decode übergeben wird. Kimi K3s Konfigurationen mit dem höchsten Durchsatz nutzen ebenfalls DWDP (distributed weight data parallelism), eine TensorRT-LLM-Prefill-Technik, beschrieben in diesem Papier.
• Spekulatives Decoding, abgestimmt auf die Batch-Größe. Alle vier Modelle nutzen spekulatives Decoding (DSpark-Draft-Modelle für DeepSeek V4 Pro und Kimi K3, DeepSeek V4.1 Flashs eingebautes DSpark-Drafting und GLM-5.2s eigene Multi-Token-Prediction-Layer), wobei die Draft-Länge für jeden Concurrency-Level abgestimmt ist, z. B. von 7 Tokens bei niedrigerer Concurrency bis 3 beim höchsten bei DeepSeek V4 Pro, da sich Spekulation am meisten auszahlt, wenn Batches klein sind und GPUs Rechenreserven haben. Die Konfiguration hinter dem Ergebnis von ~5.7x bei DeepSeek V4 Pro, mit ~190 tok/s pro Nutzer, drafted 7.
• Rubin-abgestimmte Kernels. NVIDIAs NVFP4-Checkpoints betreiben die MoE-Experten in 4-Bit-Präzision auf für Rubin abgestimmten NVFP4-Kernels, alongside fused kernels für die Architektur jedes Modells (wie DeepSeek V4 Pros Sparse Attention und Hyper-Connections). Derselbe Attention-Kernel muss Eingaben von einer Handvoll Tokens bis 1M verarbeiten, daher muss das Autotuning Bereiche von Shapes abdecken statt sich auf feste zu spezialisieren, was reale agentische Workloads benötigen und Benchmarks mit festen Shapes nicht üben.
• Schnelle host-seitige Anfrageverarbeitung. Jede Anfrage enthält den gesamten bisherigen Gesprächsverlauf (bis zu 132K Tokens in unserer Workload), daher muss das Serving-Frontend bei jedem Turn eine lange Historie tokenisieren und weiterleiten. Dynamos Router ist in Rust geschrieben, um die host-seitige Latenz niedrig zu halten, und die DeepSeek V4 Pro- und GLM-5.2-Konfigurationen ergänzen einen schnellen Tokenizer mit einem Tokenization-Cache und einem schlanken Request-Transport, während die Konfigurationen der anderen Modelle jeden Worker an die CPU-Kerne und den Speicher binden, die seinen GPUs am nächsten sind.

Dies sind erste Ergebnisse auf Vera Rubin, mit frühen Rubin-spezifischen Kernels und Tuning, und NVIDIA erwartet, dass die Leistung mit weiteren Optimierungen weiter steigt.

Übersicht der Vera Rubin-Konfigurationen für jedes Modell

Weiterführende Lektüre

• Vergleichen Sie jedes System auf der AA-AgentPerf-Bestenliste
• Lesen Sie die AA-AgentPerf-Methodik und den Launch-Artikel
• Stöbern Sie in der vollständigen Serving-Konfiguration hinter jedem Ergebnis im Konfigurations-Browser

Lesen Sie die neuesten

Reflection hat Beam veröffentlicht, ihren ersten Modell-Launch

Reflections erstes Modell, Beam, erzielt 30 Punkte im Artificial Analysis Intelligence Index und belegt damit Platz 2 unter den US-Open-Weights-Modellen

16. Oktober 2026

NVIDIA veröffentlicht Nemotron 3.5 Super VL und Nemotron 3.5 Bolt 74B A9B

Nvidias Nemotron 3.5 Super VL ist nun das führende US-Open-Weight-Modell und erzielt 26 Punkte im Artificial Analysis Intelligence Index

15. Oktober 2026