Desktop - Blackwell Next (Nachfolger von GB20x - 2026-2028)

[Edgecrusher86]

Guten Tag!
Da der Desktop-Launch an GeForce RTX 50 zumindest auf dem Papier bis Ende März abgeschlossen sein dürfte (Pre-Refresh zumindest), dachte ich, es ist an der Zeit, schon einmal weiter zu denken. :cool:
Dieser Thread soll sich daher nicht um Rubin drehen, sondern alleine dem Desktop/Mobile/PCI-E WS-Pendants, die uns nächste Generation erwarten. ;)

Codename: NVIDIA Blackwell Next (Nachfolger von GeForce Blackwell)
Release: Ca. Q4/2026 - H1 2027
TSMC N3x / N2x oder Samsung 3nm-GAA / 2nm-GAA
24Gb+32Gb GDDR7 @ 32-42 Gbps
PCI-E 5.0/6.0
DP 2.1a(+) / HDMI 2.2


Spekulation des x02 Chips meinerseits:

GeForce RTX 6090
Release: Ca. Q4/2026 - H1 2027
Fertigung: TSMC N3x / N2x oder Samsung 3nm-GAA / 2nm-GAA
MCM: 2-4 Chiplets a 480/240mm² auf einem Interposer mit shared GDDR7
FULL-Chip: 2x 128SM / 4x 64SM [total 256SM - 32768SP FP32]
300-Chip: 2x 112-120SM / 4x 56-60SM [total 224-240SM - 28672 bis 30720SP FP32]
Boost: ~2,9 GHz
Max-Boost: ~3,0-3,1 GHz
Rohleistung FP32 @ Boost: ~166,3 - 178,2 TF/s
AI TOPS: ~2-3x RTX 5090 (6704 - 10056)
36GB GDDR7 (24Gb, 384-bit SI) @ 39-40 Gbps [1872-1920 GB/s]
TGP: 675-750W [2x 12V-2x6]
PCI-E 5.0/6.0
DP 2.1a(+) / HDMI 2.2
MSRP FE: $2499-2999



Einen x03er als RTX 6080 stelle ich mir dann ähnlich mit maximal 2 DIEs vor oder Monolithen. Der x05er wird dann wohl auf jeden Fall monolithisch werden.

Was vermutet Ihr bezüglich der Architektur?

MfG
Edge

[Dimon]

Naja ich schätze das die Energieaufnahme deutlich sinken sollte im vergleich zu Blackwell. Wäre blöd wenn die wieder einen knüppel ansetzen würden (Umwelt und ressourcen z.b.)

[Edgecrusher86]

Mehr Effizienz - vor allem Richtung Ada @ UV - würde mich hier auch wünschen, aber gerade seit Turing geht es leider stetig bergauf mit der Leistungsaufnahme.

[HOT]

Ich wette, dass der neue 102er in einer Variante von N3E gefertigt wird und wieder um die 600mm² groß ist und monolithisch bleibt.

[Cubitus]

Gibt es schon konkrete Informationen? Ein Rubin-Derivat für Gaming wird es wohl nicht sein, oder?

[w0mbat]

Ich wette, dass der neue 102er in einer Variante von N3E gefertigt wird und wieder um die 600mm² groß ist und monolithisch bleibt.
Ich hoffe auf min. N3P.

[Edgecrusher86]

Infos gibt es leider noch gar nicht. Ich tippe diesbezüglich auf frühstens Q1 oder Q2/2026 durch Kopite. Dann darf man wohl von einem Tapeout ausgehen.

Hm, also so sähe das wohl in TSMC N3x aus nach Anand.
In etwa 30% bessere Effizienz bei gleicher Leistung oder grob 15-20% mehr davon bei identischen Verbrauch.
Dann müsste man aber wohl wieder über 700mm² gehen und zudem die Taktraten richtig hoch schrauben, damit zumindest 40-50% bei herum käme auf Blackwell.
Dafür werden bestimmt auch locker 100W on top nötig sein - gehe ich zumindest von aus - auch wenn wir hier extrem früh sind. 761.56mm² sollen es ja beim GB202 sein.
Ein Monolith mit selber Leistung in N3x würde sich wohl grob 400W genehmigen. Zu schade, dass hier nichts über die Dichte steht - aber es sollten locker +20% zu N5 sein, oder?

https://s20.directupload.net/images/250206/4rifilh7.png

https://www.anandtech.com/show/21394/tsmc-performanceoptimized-3nm-process-technology-on-track-for-mass-production-this-year

Bei angenommen nur 600mm² (78,8% GB202 DIE-Size) müsste der Chip schon wahnwitzig hoch takten und/oder einen gewaltigen IPC Sprung haben, um GB202 zum Beispiel um mehr als 10-20% zu schlagen oder sehe ich das falsch?

[HOT]

Ist wurscht, das ist ja eh ein angepasster Prozess dieser Klasse dann.

[AffenJack]

Zu schade, dass hier nichts über die Dichte steht - aber es sollten locker +20% zu N5 sein, oder?


Logik soll noch ganz ordentlich skalieren,je nach Transistortyp, Analog und Sram dagegen fast gar nicht. Es ist im Endeffekt der letzte Node der wenigstens noch halbwegs skaliert.

N2 2028/2029 wird sicher Multichip werden, weil N2 so gar nicht skaliert. Blackwell Next wird sicherlich N3.

Die große unbekannte ist, ob Blackwell Next der letzte monolithische Chip wird oder der erste Multichip. Bei der kaum vorhandenen SRAM Skalierung von N3 und den massiv teuren Wafern von N3 würde es sich anbieten hier auf Multichip zu gehen.

Abhängig davon sind dann ganz unterschiedliche Dinge erreichbar.

[basix]

Ich würde auf monolithisch tippen. Chiplets wird irgendwann kommen, aber aus meiner Sicht noch nicht bei der nächsten Generation.

Man muss es auch so sehen: Raster skaliert nicht so gut mit Chiplets. Raytracing und Neural Rendering sehr wohl.

[Badesalz]

N2 2028/2029 wird sicher Multichip werden, weil N2 so gar nicht skaliert. Blackwell Next wird sicherlich N3.Ggf. gibt es aber ne Weile wieder nennenswerte Schübe beim Takt :freak:

[KarlKastor]

Zu schade, dass hier nichts über die Dichte steht - aber es sollten locker +20% zu N5 sein, oder?

TSMC gibt 1.6 für Logik an. Für eine ganze GPU sind es dann etwa 1.3.

Ich stimme dir also vollkommen zu. Will man wieder einen größeren Sprung machen, wird der Chip ganz sicher größer als 600 mm².
Und auch die TDP wird nicht mehr niedriger werden, denn sonst bekommt man auch keinen nennenswerten Performancesprung hin. Es sei denn Nvidia kann die Effizienz rein durch die Architektur erheblich verbessern.

[HOT]

Wer weiss, vielleicht setzt NV auch weider 2 Generationen auf N3. N2P ist zwar leistungsfähiger aber wie gesagt auch sehr teuer und die Packdichte dürfte nur wenig steigen.
Ich würd mich ab jetzt von den großen Sprüngen pro Generation wegen der Fertigung verabschieden, Ada war ja nur so viel besser, weil der von quasi Samsung 10nm auf TSMC 5nm gesprungen ist. Ich schätze, man muss sich an 10-30% pro Generation begnügen, bis wirklich Chiplets in einem komplexen Design eingesetzt werden.

Wer sich übrigens fragt, ob 4N nicht doch N4 ist, N4 hatte den Ramp der Massenproduktion und Tape Outs erst ab Juli 22, da war Ada schon lange auf dem Weg. NV hat definitiv eine N5-Customisierung für Ada gemacht. N4P/X ist übrigens auch gar nicht möglich gewesen für BW und die AMD-Produkte, da N4P/X lt. TSMC Massenproduktion erst in H2 2024 gerampt wurde, N3P/X sogar er in 25, N4P/X und N3P/X laufen also quasi parallel. Wenn NV jetzt also einen Grafikchip designt wird die Basis dafür N3P/X sein. AMDs MI350 und Turin Dense sind N3E und alles was danach von AMD kommt wird auch N3P/X-Basis sein falls es sich für AMD lohnt oder man bleibt andernfalls bei N3E. AMD hat sich ja als letztes mit Pheonix verbrannt, Tape Out in der Risc-Production-Phase und zack 1/2 Jahr Verzögerung, hat sich überhaupt nicht gelohnt.

[reaperrr]

Und auch die TDP wird nicht mehr niedriger werden, denn sonst bekommt man auch keinen nennenswerten Performancesprung hin. Es sei denn Nvidia kann die Effizienz rein durch die Architektur erheblich verbessern.
Kommt drauf an, was man unter "nennenswert" versteht.
~30% mehr Perf würden sie wohl auch wieder in einer 450W-TDP (oder meinetwegen 475W-TDP) wie bei der 4090 unterbekommen.
Die 5090 scheint schon für die letzten paar Prozent relativ hart über den SweetSpot getrieben worden zu sein, die wäre in 4090-TDP nicht viel langsamer ausgefallen (zumal unterhalb von 4K eh oft im CPU-Limit).

Aber die Zeiten von "~5% mehr IPC je SM, 80% mehr SM und 30-50% mehr Takt" in einer Gen sind definitiv vorbei. Ada war der letzte große Sprung von NV, solange auf Seiten von TSMC/Intel/Samsung kein Wunder geschieht, wonach es derzeit nun wirklich nicht aussieht.
Die brauchen die ganzen "Tricks" wie GAA/RibbonFET/PowerVias/HighNA usw. ja schon, um überhaupt noch Skalierungen von Bedeutung hinzukriegen.

[HOT]

Und genau da liegt der Knackpunkt, diese Skalierungen sind irre teuer, TSMC wird zudem erst im 2H 2025 nennenswerte Yields haben, da soll die Massenproduktion starten. Klar, Apple ist wieder vorne mit dabei, aber alle anderen sicherlich nicht. MMn wäre es einen GPU-Launch Anfang 27 einfach zu früh für N2.
N2P/X hat übrigens die PowerVIAs verloren lt. Anandtech noch und wird frühestens Ende 2026 starten, also sicherlich erst 2027. Das wäre dann die nächste Option für Post-BW-Next.

[Badesalz]

Aber die Zeiten von "~5% mehr IPC je SM, 80% mehr SM und 30-50% mehr Takt" in einer Gen sind definitiv vorbei. Ada war der letzte große Sprung von NV, solange auf Seiten von TSMC/Intel/Samsung kein Wunder geschieht, wonach es derzeit nun wirklich nicht aussieht.
Die brauchen die ganzen "Tricks" wie GAA/RibbonFET/PowerVias/HighNA usw. ja schon, um überhaupt noch Skalierungen von Bedeutung hinzukriegen.Am Ende das Rennen zwischen AMD und NV doch wie beim Igel und Hase? :usweet:

[HOT]

Mehr so Igel und Igel aber ohne Tricks ;).

[AffenJack]

TSMC gibt 1.6 für Logik an. Für eine ganze GPU sind es dann etwa 1.3.


Das sind aber auch nur die langsamen Transistoren mit High-Density. Ich weiß nicht, wie weit sich das zu sonstigen Nodes unterscheidet, weil es ja sonst auch HD und HP Libraries gibt. Aber TSMC hat diesmal ja sehr stark mit Finflex geworben und den 3 Transistorarten.

[HOT]

Wenn jemand die Transistormenge und die Größe des CCDs von Turin Dense kennt, kann man die Praxis mal überprüfen, wieviel N3E ggü. N4 bringt.

[Badesalz]

Mehr so Igel und Igel aber ohne Tricks ;).Ah... Nicht verstanden. Schon ok ;)

Wenn jemand die Transistormenge und die Größe des CCDs von Turin Dense kennt, kann man die Praxis mal überprüfen, wieviel N3E ggü. N4 bringt.TAKT. Hab ich das schon erwähnt? Wir gehen, für ne Weile jedenfalls, wieder über den TAKT. Dafür brauchst du keine Transistoren zählen...

[KarlKastor]

Das sind aber auch nur die langsamen Transistoren mit High-Density.
Das weißt du woher?

[Zossel]

Das sind aber auch nur die langsamen Transistoren mit High-Density. Ich weiß nicht, wie weit sich das zu sonstigen Nodes unterscheidet, weil es ja sonst auch HD und HP Libraries gibt. Aber TSMC hat diesmal ja sehr stark mit Finflex geworben und den 3 Transistorarten.

Nun ja, Transen mit niedrigen QGx können auch Vorteile beim Speed und Stromverbrauch haben. (Siehe Anhang)

[AffenJack]

Das weißt du woher?

Schau dir die TSMC Präsis an:
https://images.anandtech.com/doci/17452/tsmc-finflex-june-2022_575px.png

Nebenbei, dieses Foliendesign ist einfach mal richtig schlecht. Da wird keine X/Y-Achse beschriftet, damit man 0,85x Area aussehen lassen kann, als hätte sich die Area halbiert.

[Zossel]

Nebenbei, dieses Foliendesign ist einfach mal richtig schlecht. Da wird keine X/Y-Achse beschriftet, damit man 0,85x Area aussehen lassen kann, als hätte sich die Area halbiert.

Alles ist relativ.

[KarlKastor]

@Affenjack
Die kenne ich. Die sagt aber nicht, was für einen Sprung es von HP zu HP gibt und das 60% Logik nur für HD gilt.

[AffenJack]

@Affenjack
Die kenne ich. Die sagt aber nicht, was für einen Sprung es von HP zu HP gibt und das 60% Logik nur für HD gilt.

Die Spanne HP-Design zu HD-Design hast du aber auf der Folie. Deshalb hast du ja auch ne Linie beim N5 Prozess, je nachdem ob HD oder HP optimiert.

Deshalb ist mir das mit den Designs mit Finflex nicht so richtig klar, weil da da in jedem Finflex Design noch die Spanne HD zu HP drin ist?

Der einzelne Transistor interessiert am Ende eh weniger, weil das Design auch so ne Mischung ist. Die Folie zeigt eher die Realität die zu erwarten ist bei nem implementierten Design.

Am Ende aber auch so noch alles Theorie, das einfachste wäre Apple und TSMC 3nm Chips mit 4/5nm in der Density zu vergleichen.
https://semiwiki.com/forum/index.php?threads/apple-a17pro-transistor-density.20388/

Sollen wohl Faktor 1,3 sein am Ende, wie du schon geschrieben hast. Zusätzlich ist bei Apple der Takt um 10% gestiegen. Das würde ich auch von den GPUs als Baseline nehmen.
Von irgendwelchen übertriebenen Ghz-Steigerungen wie immer wieder spekuliert würde ich Abstand nehmen. Das hat sich immer wieder als falsch heraus gestellt.

Wenn also Nvidia nicht irgendwie signifikant durch die Architektur pro Transistor schneller wird, wo ich nach Blackwell dran zweifle, dann wäre normal zu erwarte:

761mm²/1.3=585mm² | *1.15 =672 mm²
1,15 Transistoren mit 1,1x Takt = 26% mehr Geschwindigkeit.

Wenn es nicht in Richtung Chiplets geht, erwarte ich erstmal nicht mehr.

[basix]

Aufgrund fehlendem Thread aber potentiellem Thema für zuküftige HPC/ML/AI Accelerators wie auch Consumer GPUs packe ich das mal hier rein.

FP64 auf modernen Consumer GPUs:
Typisch ist 1/64 rate von FP64 (Nvidia seit Pascal, AMD seit RDNA4). Man kann FP64 allerdings mit FP32 emulieren, mit ~1/20 der FP32 FLOPS.

Hier ein theoretischer Ansatz:
https://stackoverflow.com/questions/29344800/emulating-fp64-with-2-fp32-on-a-gpu

Hier ein praktischer Ansatz:
https://forums.developer.nvidia.com/t/weekend-project-fp64-emulation-on-consumer-grade-gpus/291205

Ist anscheinend kein 1-1 Ersatz und Energieverbrauch mässig sicher deutlich schlechter. Aber dennoch ein interessanter Ansatz, Recheneinheiten zu zweckentfremden um eine höhere FP64 Performance zu erreichen. In den meisten Fällen dürfte es sich aber lohnen, die Applikation auf FP32 auszurichten und nur wenn zwingend nötig auf FP64 zu setzen.

Hier ein aktuelles Paper, das auf einer RTX 4090 ~7.4...9.8 TFLOPS FP64 erreicht (mit Tensor Cores emuliert): Ozaki Scheme 2
Das ist gleich viel oder sogar mehr wie auf einer V100 und ~6x mehr als die nativen 1/64er FP64-Rechenwerke. Interessant ist auch, dass man mit der Anzahl Matrix-Operationen die Genaugkeit des Resultats steigt. Damit könnte man einen Algorithmus auf die Genauigkeit hin feintunen. Da brauche ich 32bit, da 48bit, da 64bit, da 96bit. Ob sich das ein Programmierer antut ist eine andere Frage :D
https://arxiv.org/html/2504.08009v1

Im Paper verwenden sie INT8 auf den Tensor Cores für die FP64-Emulation. Wird spannend, wenn sie das auf B200 laufen lassen. Das Ding hat 4500 TOPS verglichen mit 2000 TOPS bei H200 und 660 TOPS bei RTX 4090. H200 erreicht ~8x emulierte FP64 Performance der 4090 bei ~3x theoretischen TOPS. Lässt sich das auf B200 übertragen, könnte man mit B200 ~120...150 TFLOPS FP64 erreichen. B200 schafft nativ mit FP64 HW-Units nur 40 TFLOPS FP64.
We also plan to conduct further experiments on GPUs with higher INT8 Tensor Core performance, such as the B200, to explore the potential of our method on next-generation architectures.

Und das "Ozaki Scheme" hat schon noch etwas Gewicht, wenn man sich anschaut von wo her der Herr Ozaki kommt:
1 Department of Mathematical Sciences, Shibaura Institute of Technology, Japan
2 RIKEN Center for Computational Science, Japan

[Badesalz]

Gabs da nicht schonmal was ähnliches mit BF16 nach FP32? Den Wetterheinis hätte das angeblich gereicht (?)

PS:
AMD splittet nun jedenfalls. 450X für AI und 430X für HPC. Ich hab auch das Gefühl, so bisschen was ähh... beirechnen, wird das noch akzeptiert, aber die HPC Community die FP64 rechnet, die wird sich mit FP64-Emulationen wahrscheinlich schwer tun :usweet:

120 wäre schon roh grob die 430X. NV hat HPC ziemlich runtergefahren (damit AMD von etwas leben kann? :usweet:)

[basix]

Das coole an der Sache wäre ja, dass man den selben Chip und die selben Recheneinheiten verwenden kann. Dedizierte FP64 Units könnte man allenfalls komplett weglassen. Das spart Chipfläche oder steigert die Performance. Damit spart man sich zwei separate Chips und kann unter Umständen die Performance sogar erhöhen (verglichen mit einem "50/50" HPC / AI Chip).

Das Thema Präzision ist natürlich ein Thema. Aber im Paper wird ja gezeigt, dass es geht. Ist halt alles DGEMM (Matrix Operationen). Vektor-FP64 wäre ein zusätzliches Thema.

[Skysnake]

Also extenden Precision Libs für FP128 usw gibt es schon seit Ewigkeiten für CPUs. Überrascht mich jetzt überhaupt nicht, aber ist halt die Frage, ob man sich das wirklich antun will.

[Troyan]

Das coole an der Sache wäre ja, dass man den selben Chip und die selben Recheneinheiten verwenden kann. Dedizierte FP64 Units könnte man allenfalls komplett weglassen. Das spart Chipfläche oder steigert die Performance. Damit spart man sich zwei separate Chips und kann unter Umständen die Performance sogar erhöhen (verglichen mit einem "50/50" HPC / AI Chip).

Das Thema Präzision ist natürlich ein Thema. Aber im Paper wird ja gezeigt, dass es geht. Ist halt alles DGEMM (Matrix Operationen). Vektor-FP64 wäre ein zusätzliches Thema.

nVidia lässt mit Blackwell (Ultra) FP64 doch schon weg. :biggrin:

[Badesalz]

Der Müll ist einfach nur noch überall.
Ich wollte das kurz finden (war auf YT, gesucht aber über Google), mit den BF16 nach FP32. Paar Schlagwörter hingezimmert...

Ej... die ersten 3 Seiten nur mixed precision training und quantizing LLMs und LLM architektures und FP LLM otimization... :umassa:

:ubash3:

edit:
12:21 sieht strange aus
https://www.youtube.com/watch?v=gZA3bGlo8h8

edit2:
Hab noch keinen Japaner erlebt der SO gut Englisch spricht

[basix]

Danke für das Video.

Die Japaner sind sich das anscheinend echt am überlegen. Sie erstellen entsprechende mathematische Modelle etc. um FP64 emulieren zu können.
Und spekulieren mal ~1000 TFLOPS emulierte FP64 für Rubin Ultra :D

[Badesalz]

Bei dem ganzen Geseier über NextFugaku und Fujitsus übertolle Monaka, werden sie da nun doch dick was von NV dabei stellen ;)

[ChaosTM]

Fugaku war der schnellste und effizienteste Supercomputer damals vor einem halben Jahrhundet.. äh, ..Jahrzehnt

Ohne NV wird das aber schwer zu wiederholen sein..

[basix]

Bei dem ganzen Geseier über NextFugaku und Fujitsus übertolle Monaka, werden sie da nun doch dick was von NV dabei stellen ;)

Das eine sind CPUs und das andere GPUs. Das hat beides Platz und Berechtigung in einem HPC-Cluster, da unterschiedliche Stärken ;)

Ohne NV wird das aber schwer zu wiederholen sein..
Ich glaube der primäre Grund ist vor allem NVLink und dessen Einfluss auf die Skalierbarkeit der Nodes. Die Monaka-CPUs sollen ja ebenfalls NVLink supporten (oder zumindest die CPUs, welche bei NextFugaku zum Einsatz kommen werden).
Ein NVL72 oder bis NextFugaku NVL576 mässiger Aufbau hat grosse Vorteile:
- Hohe Compute-Density (=geringer Platzbedarf)
- Verbesserte Skalierbarkeit von HPC-Applikationen (hohe Bandbreite, niedrige Latenz)

Kommt da noch die FP64-Emulation via INT8 obendrauf, hat man auch mit den GPUs hohe FP64-mässige Performance für generelle HPC-Applikationen.

Natürlich ginge eine NVLink mässige Rack-Scale Lösung auch mit Ultra-Ethernet etc. aber NVLink ist bereits im Markt und hat sich technisch bewiesen. Also zu guten Teilen auch eine Timeline- sowie Risikominimeirungs-Geschichte fürs R&D (vs. z.B. GPUs von AMD).

[Badesalz]

Das eine sind CPUs und das andere GPUs. Das hat beides Platz und Berechtigung in einem HPC-Cluster, da unterschiedliche Stärken ;) :rolleyes:
Welche GPUs nutzt Fugaku? Sie haben bis dahin geglaubt, sie können das wieder mit SVE erledigen (*)
https://www.fujitsu.com/global/about/research/technology/fujitsu-monaka/

Ich glaube der primäre Grund ist vor allem NVLink und dessen Einfluss auf die Skalierbarkeit der Nodes.Dazu kam es imho erst später. Nach NVs Zug entstand die Idee mit Monoka-X.
Kommt da noch die FP64-Emulation via INT8 obendrauf, hat man auch mit den GPUs hohe FP64-mässige Performance für generelle HPC-Applikationen.(*) Ich denke Ozaki Scheme 2 war der am massivsten entscheidende Faktor :wink:
Natürlich ginge eine NVLink mässige Rack-Scale Lösung auch mit Ultra-Ethernet etc. aber NVLink ist bereits im Markt und hat sich technisch bewiesen. Also zu guten Teilen auch eine Timeline- sowie Risikominimeirungs-Geschichte fürs R&D (vs. z.B. GPUs von AMD).Jep.

Bis 2030 wird es längst UltraEthernet 800G/Link geben, UAlink ohne Ethernet-Aufsatz und dazu Broadcom in Bestform. Sollen sie halt nehmen was sie gut finden, aber ich denke Jensen brauchte einen Fallbeispiel für den neusten Zug und fand es eine gute Idee Riken anzurufen ;) Das Angebot war gerantiert nicht zu verachten...
Ozaki Scheme 2 wurde imho 04.2025 publiziert.

Hier taucht nicht ein einziges Mal Nvidia auf :tongue:
https://www.livescience.com/technology/computing/japan-to-start-building-1st-zeta-class-supercomputer-in-2025-1000-times-more-powerful-than-todays-fastest-machines

Seit erst etwa 8 Tagen wird gerührt was das Zeug hält. Es ist also kaum 4 Wochen her, daß sie sich geeinigt haben
https://www.hardwareluxx.de/index.php/news/allgemein/wirtschaft/66846-fujitsu-und-nvidia-viel-internationale-zusammenarbeit-für-fugakunext.html

edit:
Das allgemeine Prob ist, daß wir nicht nur bei PCIe oder DDR gegen eine Wand laufen (oder Render-GPUs). Das Thema hat trotz gelegentlichen theoretischen Fantasien tatsächlich auch Lichtwellenleiter. Die nötige Energie es für auf Silicon verwertbar umzusetzen ist nur das eine. TSMC macht das schon :wink:
Das größere Thema aktuell sind die (Durch)Verbindungen. Niemand im RZ mag die 16fach "Anschlüsse" (also Links). Geschweige noch mehr. Das ist alles nur aus der Not entstanden und ist technisch ein ziemlicher Husarenritt.

Entscheidend ist also die Bandbreite pro Lane und diesmal haben sie sich schon ziemlich gequält 200G/Lane wirtschaftlich hinzubekommen.
Da wird es IMHO erstmal also auch nicht so schnell wieder mehr kommen. Auf beiden Seiten nicht. Die dahinter steckende Physik kann auch Nvidia nicht mit Mrd. erschlagen. NVs Vorsprung wird also auch da schrumpfen.

[basix]

:rolleyes:
Welche GPUs nutzt Fugaku? Sie haben bis dahin geglaubt, sie können das wieder mit SVE erledigen (*)
https://www.fujitsu.com/global/about/research/technology/fujitsu-monaka/

Dazu kam es imho erst später. Nach NVs Zug entstand die Idee mit Monoka-X.

(*) Ich denke Ozaki Scheme 2 war der am massivsten entscheidende Faktor :wink:
Jep.

Die Compute und HPC-Landschaft hat sich in den letzten paar Jahren massiv geändert und das auch ziemlich schnell. NVL72 Rackscale Solution ist auch noch relativ jung (wurde im März 2024 vorgestellt und angekündigt). Fugaku ging im Mai 2020 in Betrieb. Was gab es dort? V100 und das wars. A100 wurde erst im Mai 2020 vorgestellt. Dass Fugaku keine GPUs verwendet hat ist also nicht so erstaunlich. Gibt ja noch PEZY etc., die Japaner sind da also generell ein wenig eigen ;)

Ich denke allerdings wie du, dass FugakuNext initial ohne GPUs geplant war. Fugaku war sehr erfoglreich, auch ohne GPUs. Aber die Rahmenbedingungen haben sich mittlerweile geändert und die Japaner haben deswegen das letzte Jahr oder sogar schon vorher (Ozaki Scheme 1 wurde Spetember 2024 veröffentlicht) intensiv Zeit in FP64 Emulation investiert um zu schauen, ob das sinnvoll geht. Mit Ozaki Scheme 2 sind sie anscheinend zufrieden genug. Und damit können sie die "effektive FP64 Performance" nach oben drücken, ohne ihre CPU neu designen zu müssen (aka zusätzliche INT8 Matrix Units usw.). Aber dass man sich FP64-Emulation überhaupt detailliert angeschaut hat, liegt in der Entwicklung bei den GPUs und deren Ökosystem (in den Ozaki Scheme Papers werden nur GPUs genannt und keine Monaka-CPUs welche auch FP8 können).

Und hier ist dann NVLink schon eine gute Technologie. Dazu auch der ganze SW-Stack und Compute-Libraries von Nvidia. Das darf man auch nicht vergessen. GPU-Acceleration bekommt industrieweit viel Aufmerksamkeit (= Engineering-Stunden) und wenn die Japaner 2030...2040 (die Betriebsdauer von FugakuNext) ihr eigenes Süppchen ohne GPUs kochen würden, ist das wohl eher nachteilig für ihre System-Performance.

Es gibt also sicher mehrere Gründe für den Deal. De Japaner sehen ja auch in welche Richtung sich die HPC-Landschaft bewegt. Aber dass man spezifisch Nvidia genommen hat und nicht AMD oder jemand anderes ist mMn NVLink und dessen Maturität (und die SW-Libraries). Mit Monaka-X und integrierter NVLink Schnittstelle könnten sie zudem NVLink mässige CPU-only Cluster aufbauen. Momentan verbietet das aber die NVLink Fusion Spezifikation (es muss immer eine Nvidia CPU oder GPU dabei sein). Vielleicht noch ein Grund, wieso man Nvidia GPUs nehmen "musste" ;)

Der technische "Vorteil" von NVLink wird sich sicher schmälern. Aber wie gesagt: Timeline und Maturität. Die Japaner designen ihre Chips jetzt. Monaka gibt es schon in einer ersten Version. Und es ist zudem auch unwahrscheinlich, dass es 2030 deutlich bessere GPUs als die von Nvidia geben wird. AMD wird vermutlich auf Augenhöhe sein aber nicht deutlich besser.

Wie gut der Deal zwischen Riken und Nvidia ist, ist schwierig zu beantworten. Nicht ohne Grund sind an vielen Orten AMD Systeme unterwegs, aufgrund mehr Bang-for-the-Buck. Die Herstellungskosten der Chips von AMD und Nvidia werden sich nicht gross unterscheiden. Ist also eher eine Frage der Marge. Aber öffentliche/nationale HPC-Supercomputer sind typischerweise relativ günstig unterwegs (Prestige für Hersteller), das wird hier nicht anders sein. Und ob da Nvidia den ersten Zug gemacht hat? Ich weiss nicht, die haben momentan einen ganz andere Fokus ;)

Aber das Ozaki Scheme 2 könnte eine coole Ergänzung für den Nvidia SW-Stack sein. Nvidia traue ich es zu, dass sie das schön in ihre Libraries integrieren und damit den "HPC-Bumms" ihrer GPUs nochmals deutlich steigern können, auch wenn man primär auf Low-Precision-Matrix-Units für ML/AI setzen.

Edit:
Ozaki Scheme 1 wird bereits von Nvidia in HPC-Benchmarks verwendet:
https://indico.cern.ch/event/1538409/contributions/6522024/attachments/3097817/5488258/OZAKI_slide_CERN.pdf
https://developer.nvidia.com/nvidia-hpc-benchmarks-downloads
FP64 Emulation using Ozaki Scheme I will be released in second half of 2025 by NVIDIA.
Schei**e für GB300 Käufer, da dort INT8 Througput auf Kosten von +50% FP4-Dense stark reduziert wurde ;)

Und ich finde dass das Ozaki Scheme 1/2 auch für Consumer extrem interessant ist. Gaming-Chips haben seit längerem kaum FP64-Durchsatz. Mit einer FP64-Emulation via INT8 Matrix-Cores könnten hier CAD/Simulations Applikationen oder auch Unis / Wissenschaftler mit wenig Budget profitieren. Wissentschaftliche Berechnungen und Simulationen mit hoher Präzision (FP64-Emulation) auf einer relativ preisgünstigen Gaming-GPU wären ein Fortschritt, den man so nicht hat erwarten können ;)

Und zudem kann man auch FP16 und FP32 emulieren. Beispiel anhand Ozaki Scheme 1:
- FP16 3x INT8 matmul
- FP32 10x INT8 matmul
- FP64 36x INT8 matmul

Ozaki Scheme 2:
- FP16 ~5x INT8 matmul
- FP32 ~8x INT8 matmul
- FP64 ~16x INT8 matmul

Keine Ahnung, vielleicht sehen wir in Zukunft HW, welche alle Präzisionen mit Basis-Units wie z.B. INT8 emuliert. Ist sicher eine far-fetched Vision, aber wenn Moore's Law usw. am Ende sind, sucht man sich andere und zum Teil kreative Lösungen. Eine emulierte FP16 Operation dürfte nicht viel effizienter sein als eine native FP16 Operation (in pJ). Aber man benötigt 8...10x weniger Chipfläche für INT8 mult+add verglichen mit FP16 mult+add. Sobald man in Richtung FP32 oder gar FP64 geht, werden die Effizienz- und Chipflächenvorteile dann sehr gross. Der Performance-Vorteil schält sich bei GH200 allerdings erst bei grossen Matrizen raus. Kleinere Matrizen oder Vektoren profitieren vermutlich nicht davon (ausser man kann das irgendwie noch lösen, algorithmisch oder in HW). Bei einer 4090 sieht es etwas besser aus, da deren Tensor-Cores weniger breit sind.
https://substackcdn.com/image/fetch/$s_!J1KK!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fda79e0ce-cba5-48c8-8344-a7cceb52e34c_2419x1277.png

======================================

Die Nodes von FugakuNext scheinen etwas anders aufgebaut zu sein wie NVL72 heute (wenn das Schaubild stimmt). Eher so wie MI300A bei El Capitan. Aber das kann auch eine starke Vereinfachung sein:
https://www.nextplatform.com/wp-content/uploads/2025/08/riken-fugakunext-salients-japanese.jpg

[Badesalz]

Bei 12:15 werden die Rundungsfehler angezeigt. Mal schauen wie das außerhalb von Riken angenommen wird. Ich halte das aber tatsächlich für eine große Sache.

Und hier ist dann NVLink schon eine gute Technologie. Dazu auch der ganze SW-Stack und Compute-Libraries von Nvidia. Das darf man auch nicht vergessen. Das und AMD...
Was anscheinend - wenn man sich den ganzen Content anschaut - viele nicht auf dem Radar haben ist NVs Achter Domäne
Wahrscheinlich redet man nicht so viel darüber um AMD nicht zu sehr weh zu tun, weil etwas in der Hinterhand zu haben gegenüber NV ist der Sache immer zuträglich.
Im Gegensatz zu vielen anderen Sachen sind sie da nämlich imho noch erst beim Nachmachen :tongue:

Das ist nämlich so, daß wenn man einen 8ter Gespann (NV) hat, arbeitet man ("ansprechen") halt mit 8 GPUs.
Wenn man einen 16er hat, arbeitet man mit 8 GPUs. Wenn man 32 GPUs hat, arbeitet man mit 8 GPUs. usw. usw. Wenn man entsprechend skaliert hat man selbst, immer als wenn nur 8 GPUs zu beachten. Es sei denn halt man möchte das anders aufteilen.
DAS ist tatsächlich jenes Feature des "software stacks" welches sich den ersten Podiumsplatz mit dem Mellanox-Netzwerk teilt.

Was die Soft sonst angeht verfolgt AMD wohl einen anderen Ansatz. Cuda haben sie fast schon abgefrüstückt. Das ist aber auch nicht das Thema gewesen. Es ging nie um Libs. Da musste man nur entsprechende Zahl von tauglicher Manpower drauf werfen. Was sie schon taten und tun, nachdem die Kohle dafür endlich ausreicht.

Bei den Tools dagegen haben sie aber imho keine Chance (mehr) (*) Sie möchten eine konkurrenzfähige Basis für einen Markt erschaffen in dem Omniverses und Cosmos von Dritten angeboten wird. Das wird hart...
Viele der gestandenen NV-Kunden unterstützen das aber leise und hinter der vorgehaltenen Hand.
Der letzte Warnschuss dazu wie es laufen KANN, wenn man sich einer sehr guten aber irgendwann absolut dominierenden Lösung ergibt, gab es Ende 2023 als Broadcom sich VMware einverleibte.
Das schreckte endgültig auf. Keiner in der Branche hat Bock von einem Jean-Baptiste Emanuel Zorg komplett abhängig zu sein.

Egal ist das eigentlich nur Musk. Da geht es aber nicht nur um das mittlerweile gewöhnliche AI-Zeug like ChatGPT. Musk fährt komplett auf Omniverse und Cosmos ab und er is schon dermassen systemrelevant wie quasi überlebenswichtig für die USA, daß NV ihm mit Verträgen nie mehr blöd kommen kann. Sonst kommt das Weiße Haus blöd NV. Heute eh ;) aber auch post-Trump wird das noch so sein. Das weiß er.

(*)
https://www.youtube.com/watch?v=9Uch931cDx8

Die Sache mit den Digital Twins ist absolut primär. Nicht der Müll mit stable diffusion...
https://www.youtube.com/watch?v=w_yX_Ih1fgE

[basix]

Stable Diffusion ist schon nice, habe ich erst gestern verwendet :D

Eine mögliche HW-Vision für Rubin und Feynman:

Rubin wird verglichen zu Blackwell vermutlich nicht viel ändern. Blackwell hat FP64 FLOPS verglichen zu Hopper eh schon zurückgestutzt. Das heisst, FP64 und ML/AI FLOPS werden brav synchron nach oben skaliert. Es gibt ja bereits ankündigungen von HPC-Clustern mit Rubin, wo reduzierte FP64-Performance wohl weniger erwünscht ist (z.B. "Blue Lion" am Leibniz-Rechenzentrum oder "Doudna" am Lawrence Berkeley National Lab). Bei Rubin geht es mehr um Packaging (Rubin soll Chiplets und Stacking verwenden, dazu Rubin Ultra mit 4x Chips), HBM4 sowie Rackscale System-Skalierung (NVL576).
Feynman könnte Matrix FP16 / BF16 sowie TF32 emulieren. Diese Formate werden bei ML/AI eh immer weniger oft verwendet, man schwenkt auf FP8 Training und FP4 Inferencing um. Was hilft uns das? Der frei werdende Platz aufgrund weglassen der FP16-ALUs dürfte ungefähr reichen, sodass man INT8 / FP8 / FP4 um 4x nach oben skalieren könnte. Damit hätte man mit nur 1x Generation eine sehr hohe Performance-Steigerung für die typisch verwendeten ML/AI-Datenformate erreicht. FP16 / BF16 / TF32 bleibt etwas zurück und wird aufgrund Emulation nicht stark angehoben, aber dennoch um ~2x beschleunigt. FP32 / FP64 Vektor & Matrix nativ bleibt an Ort und Stelle (wären ca. 160...250 TFLOPS für Rubin Ultra & Feynman und somit immerhin 4...6x von B200). Für native FP64 Operationen gibt es sicher immer noch Use Cases, aber man spendiert keine zusätzliche Chipfläche dafür. FP32 / FP64 Matrix wird mittels Emulation allerdings stark beschleunigt. Wir reden hier von 80...120 PetaOPS INT8 (Dense), welche via den Ozaki Schemas in 4...6 PetaFLOPS FP64 resultieren würden. Das wäre 20...30x mehr als das, was die nativen FP64 Units liefern würden. Da man einige Einheiten weglässt (FP16 etc.) oder nicht skaliert (FP32 / FP64) wird mit neuen Fertigungsprozessen vermutlich etwas Platz frei. Der wird dann mit Caches gefüllt um den gestiegenen FLOPS / TOPS unter die Arme zu greifen.

[Badesalz]

Für native FP64 Operationen gibt es sicher immer noch Use Cases, aber man spendiert keine zusätzliche Chipfläche dafür.Ich schätze es wird sich ein Ablauf entwickeln in dem man die INT8 Emus in bestimmten Abständen mit nativen FP64 nur noch gegencheckt.

Wo hast du eigentlich die Zahlen zu Feynman her?

[basix]

Ich schätze es wird sich ein Ablauf entwickeln in dem man die INT8 Emus in bestimmten Abständen mit nativen FP64 nur noch gegencheckt.

Ja, so etwas in die Richtung schwebt mir auch vor. Dass ein Grossteil eines Algorithmus mit emulierten FP64-DGEMM läuft und evtl. noch 5...10% in nativen FP64. Entweder für einen Check oder weil Vektoren, kleine Matrizen oder andere Präzisions-Geschichten dort mehr Gewicht haben.

Dadurch läuft immer noch der komplette Algorithmus in FP64 und es sind keine PINN oder ML/AI Näherungen notwendig. Ist also immer noch "klassisches" HPC / FP64 Computing. Das hat schon so seine Sexyness.


Wo hast du eigentlich die Zahlen zu Feynman her?
Zu Feynman gibt es nichts öffentliches.

Ich habe einfach ein paar Annahmen getroffen:

Rubin wird in HPC Supercomputern eingesetzt. Deswegen dürfte die native FP64 Performance ansteigen (anders als bei Blackwell)
Rubin wird 2.5x schneller als Blackwell werden (20 vs. 50 PetaFLOPS FP4 Matrix inkl. Sparsity). GB200 liefert 40 TFLOPS FP64, macht somit 100 TFLOPS FP64 für Rubin. Eine Steigerung um nur 1.25x und somit einer Halbierung der FP64 Units relativ zu Tensor-Cores halte ich für relativ unwahrscheinlich. Das wären bei FP64 Vektor gerade mal +50% gegenüber Hopper. 2.5x verglichen zu Blackwell und 3x verglichen zu Hopper hören sich da besser an. FP64 TFLOPS vs. Speicherbandbreite würde auch in etwa zu den 3x Unterschied zu Hopper passen.
Rubin Ultra hat dann 100 PetaFLOPS FP4 mit Sparsity. Rubin Ultra ist ein doppelter Rubin, macht also 200 TFLOPS FP64 Vektor
Anhand der FP4 Performance kommen vermutlich 25 PetaOPS INT8 ohne Sparsity raus (was man für die FP64 Emulation braucht)
Speku für Feynman (Achtung: Höchst spekulativ!): Emulation von >=BF16/FP16 Tensor-Berechnungen via Ozaki Scheme 1/2. Das umfasst also FP16 / BF16 & TF32 (und FP64). Das spart Chipfläche ein (siehe die Tabelle von hier https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13804874#post13804874)
FP16 Units benötigen viel mehr Fläche als FP8 oder INT8. Die Grösse der Multiplizierer steigt ungefähr quadratisch mit der Anzahl Bits. FP16 benötigt also knap 3...4x Fläche von FP8. Deswegen die Annahme, dass man durch weglassen von nativen FP16 Units die anderen Units um ~4x erhöhen kann.
Dadurch würden aus den 25 PetaOPS INT8 von Rubin Ultra ~100 PetaOPS INT8 bei Feynman werden (Achtung: Höchst spekulativ!). Dito FP8 und FP4, welche auf 100 resp. 200 PetaFLOPS ansteigen würden (beides ohne Sparsity, 4x verglichen zu Rubin Ultra) und in ML/AI Kreisen natürlich sehr gerne gesehen würden.
FP64 Units würde ich dann bei Feynman nicht erhöhen, sondern via Ozaki Scheme 1/2 und INT8 Tensor-Cores emulieren. Deswegen bleibt es bei nativ ~200 TFLOPS FP64.
Durch das nicht steigern der FP64 Units und dem Weglassen von nativen FP16 Tensor Cores sowie Steigerung der Lower Precision Units reagiert man auf die Trends in der ML/AI Community. Das verstärkt den ML/AI Fokus des Designs, wo schlichtweg das meiste Geld verdient wird. Ein solcher Umschwung im Design wäre also gewissermassen naheliegend.
FP16 Tensor emuliert wäre da nichtmal der leidtragende. Anstatt 4x Performance wie bei INT8/FP/FP4 erreicht man halt "nur" ~2x Speedup verglichen mit Rubin Ultra. Aber der Industrie ist das vermulich nicht so wichtig, da bereits heute immer weniger in FP16 trainiert wird
FP32 & FP64 DGEMM (Matrix) wären die grossen Gewinner von dem. Via Emulation via Ozaki Scheme 1/2 erreicht man 100 PetaFLOPS / 20...25 = 4...5 PetaFLOPS FP64. Das ist viel mehr als die 200 TFLOPS, welche nativ bereitgestellt werden. Und das obwohl man auf primär INT8 Matrix-Units umgeschwenkt ist im Hardware-Design von Feynman. Ich sehe da also sehr schöne Synergien, welche für ML/AI von Vorteil sind als auch klassisches HPC mit FP64 Präzision.
Mit 200 TFLOPS FP64 Vektor nativ vs. 4000...5000 TFLOPS FP64 DGEMM emuliert via INT8 kommt dann auch die ~5% / 95% Aufteilung des Algorithmus her. 5% wird in nativ FP64 Vektor gemacht, 95% in FP64 DGEMM emuliert. Vektor-Units und Tensor-Cores können zudem parallel arbeiten (solange Caches und Bandbreite das mitmachen)
Im Endeffekt auch eine deutliche Reduktion des "Dark Silicon", weil man die selben Units für mehr Anwendungsbereiche verwendet.


Einere weiter Speku meinerseits wäre eine verbesserte Bitnet Unterstützung bei Feynman. Das umfasst DNN mit 1...3bit Präzision, primär 1.58bit und 2bit. Vielleicht sehen wir das aber sogar bereits bei Rubin:
https://arxiv.org/abs/2504.12285
https://arxiv.org/pdf/2502.02631

Wie man das potentiell lösen könnte:

BitNet benötigt je nach Umsetzung 2bit Multiplier mit 8/16bit Accumulate oder zum Teil sogar nur 2bit Addierer
Ein 8bit Multiplier hat afaik 4x 4bit Multiplier integriert (deswegen auch der quadratische Zuwachs der Fläche bei 4bit -> 8bit).
Ein 4x bit Multiplier hat 3x 4bit Addierer integriert (total also 12x 4bit Addierer in einem 8bit Multiplier)
BitNet Acceleration könnte man also mit den Sub-Einheiten einer bestehenden 8bit Matmul Einheit umsetzen. Wir reden hier von ~4x Acceleration in der Matmul Version und ~8x Acceleration in der reinen Addierer Version. Aus den 100 PetaOPS INT8 würden dann 400 PetaOPS "BitNet" Operationen (Matmul) oder "800 PetaOPS" in der reinen Addierer Version (soweit ich verstehe sind das effektiv auch nur 400 PetaOPS da 4bit Matmul 2x OPS aus Multiplikation und Addition sind und hier nur eine Addition gemacht wird, also effektiv 1x OPS ist aber der DNN Throughput dennoch verdoppelt wird). Eine sehr hohe Steigerung verglichen zu den 50 PetaFLOPS FP4 ohne Sparsity bei Rubin Ultra.
Dass alles "nur" durch angepasste Anzahl und Re-Purposing der Rechenwerke für FP16/FP64 etc. Emulation via INT8 sowie zusätzlichem Support für BitNet DNN.
Keine Ahnung, ob sich das sinnvoll in HW umsetzen lässt (Routing, Kontrolllogik). Speicherbandbreiten-Anforderung dürfte keine Rolle spielen, da man von 8bit auf 2bit runtergeht und dabei 4x mehr TOPS bietet, sich das also die Waage hält.

[Badesalz]

Ja, so etwas in die Richtung schwebt mir auch vor. Dass ein Grossteil eines Algorithmus mit emulierten FP64-DGEMM läuft und evtl. noch 5...10% in nativen FP64. Entweder für einen Check oder weil Vektoren, kleine Matrizen oder andere Präzisions-Geschichten dort mehr Gewicht haben.Es gibt 2 primäre Kundschaften dafür. Ingenieurwesen und Wissenschaft. Ich schätze die erstgenannten werden das recht schnell assimilieren und die zweitgenannten sich dem anschließend vorsichtig nähern :wink:

Das hat schon so seine Sexyness.Auf jeden Fall. Mal sehen wie Skysnake damit klar kommt :tongue:

[AffenJack]

Einere weiter Speku meinerseits wäre eine verbesserte Bitnet Unterstützung bei Feynman. Das umfasst DNN mit 1...3bit Präzision, primär 1.58bit und 2bit. Vielleicht sehen wir das aber sogar bereits bei Rubin:
https://arxiv.org/abs/2504.12285
https://arxiv.org/pdf/2502.02631


Das würde ich schon bei Rubin erwarten. Jede neue Gen hat die Datenformate nach unten erweitert in den letzten Jahren. Rubin dürfte das gleiche Prinzip nochmal weiterfahren.

Bei FP64 und höheren Präzisionen glaube ich bist du zu optimitisch. Höhere Präzision würde ich nicht viel erwarten. Rubin Ultra schätze ich dann erst recht komplett abgespeckt, wie bei Blackwell Ultra.

[basix]

Eben, kann sein dass Nvidia hinsichtlich BitNet schnell aufspringt. Cool wäre es.

Hinsichtlich Präzision:
Turing und Ampere konnten INT4 und sogar INT1. Hopper und Blackwell haben das wieder entfernt. INT8 ist dort das kleinste Integer Format. Mit ein paar Microkernels kann man das glaube ich pimpen (z.B. Bitnet mit INT8 beschleunigen und INT8 in 4x 2bit Werte aufteilen). Damit erreicht man aber nicht maximale Performance. Nvidia hat also keinen Nutzen in den Datenformaten gesehen und wieder entfernt. Ich kann mir vorstellen, dass das auch mit FP16 passieren wird (nicht komplett entfernt, aber verglichen zu Blackwell allenfalls halbiert relativ zu FP8 und FP4)

Beim FP64 Verhältnis könnte Nvidia zurückfahren. Aber es gibt bereits auffällig viele Supercomputer, welche auf Vera + Rubin setzen werden. Mit nur wenig FP64-Bumms erscheint mir das eher merkwürdig. Nvidia setzt bei Rubin erstmals auch auf Chiplets und mit N3P wird viel Logikfläche frei. Da dürften also schon auch einige FP64-Units ihren Platz finden ;)

Rubin Ultra ist ausserdem ein ganz anderes Kaliber als Blackwell Ultra. Blackwell Ultra ist der selbe Chip wie Blackwell mit ein paar internen Anpassungen, um FP4-Througput zu pushen. Rubin Ultra ist glatt ein verdoppelter Rubin: Doppelt so viele Chips und HBM-Stacks.

[Badesalz]

Beim FP64 Verhältnis könnte Nvidia zurückfahren. Aber es gibt bereits auffällig viele Supercomputer, welche auf Vera + Rubin setzen werden.Nachdem AMD den Exaflop real geknackt und beim zweiten Projekt gleich an 2 kratzte (1.7 Exaflops) hab ich das schon so erwartet. Also, daß nun wieder andere an der Reihe sind.
Wonach ich schon wohl schlecht einmal gesucht hab, weil außer Blue Lion und Doudna fand ich bisher nicht viel. Das sind 2 Maschinen von den "auffällig viele".

Gibts da eine aktuelle Liste mit den auffällig vielen?

PS:
Bzw. ist das wohl weniger AMD oder Nvidia, sondern mal HPE mal Dell ranlassen.
Und GOV/DOE allgemein interessiert sich imho nur bedingt für Sachen wie BitNet. KI-Race findet offiziell einerseits nicht in den staatlichen Rechenzentren statt und andererseits setzt Darpa bei dem Thema anscheinend auf Cerebras und das ist eben auch eine ganz andere Nummer als der Quark mit gemoddeten GPUs.

Wobei Blackwell drückt langsam. CS-4 is comming ;)
https://arxiv.org/html/2503.11698v1

edit:
Rubin Ultra ist glatt ein verdoppelter Rubin: Doppelt so viele Chips und HBM-Stacks.Und 1.5kW pro Sockel?

[basix]

Und 1.5kW pro Sockel?

Eher 2...3kW ;)

Gibts da eine aktuelle Liste mit den auffällig vielen?
OK, vielleicht trügt das Bild wenn man News anschaut (letzte 2-3 Monate). Da kam Rubin oft vor. Aber von AMDs MI400 hört man jedenfalls nichts ;)

Indizien für hohe FP64 Performance sind für mich die 10x Performance bei 2..3x Energieverbrauch von Doudna. Das ist 3..5x effizienter als Perlmutter.
- A100 kommt in der Spitze auf ~40 GFLOPS/W (Perlmutter)
- H100 kommt in der Spitze auf ~65 GFLOPS/W
- Blackwell taucht nirgends in der Top500 / Green500 auf
- Blue Lion soll anhand der 3...5x Effizienzsteigerung ~120...200 GFLOPS/W erreichen

Doudna ist mal als Exascale-System angekündigt worden. Der Vorgänger Perlmutter bietet 113 PetaFLOPS FP64 Rpeak und 80 PetaFLOPS Rmax bei ~3 MW. Applikationen sollen ebenfalls >= 10x schneller laufen wie bei Perlmutter. Das sind für mich schon eindeutige Indizien auf viel FP64-Leistung. Will man die 1.0 ExaFLOPS Rmax übetreffen, muss man 13x mehr Bumms bringen bei 6...9 MW. Da ist selbst Frontier und El Capitan weit weg davon (welche auf ~H100 Niveau liegen). Dort braucht man für 1.0 ExaFLOPS Rmax ~17...18 MW. Rubin muss also mindestens 2x so effizient wie H100 und MI250X/MI300A sein und das passt dann auch wieder mit den 3x verglichen zu A100.

Ich sehe da nicht, wie das bei stagnierenden FP64-Units klappen soll. Klar, vielleicht hat sich was an der Planung rund um ExaScale geändert und Applikations-Performance ist "Netto-Performance" mit anderem Zeugs wie Bandbreite, Networking und Rackscale-Systemen miteinbezogen. Aber das ist sogar noch spekulativer als meine Erwartung von doch anständiger FP64 Performance bei Rubin ;)

Edit:
100 TFLOPS FP64 bei Rubin würden auch gut passen, wenn man sich A100, H100 sowie (G)B200 anschaut. FP64-FLOPS und Bandbreite würden ziemlich gut passen. Rubin soll ausserdem 2.5x ML/AI Performance verglichen mit Blackwell liefern. Die 2.5x FP64 FLOPS würden also einer gleichmässigen Skalierung entsprechen. 3...5x effizienter bei 2.5...3x Verbrauch von A100 deuten auch eher auf 10x Rohleistung hin anstatt nur 5x.
Chip|FP64 Vektor [TFLOPS]|HBM Bandbreite [TByte/s]|TDP
A100|10|2.0|400W
H100|34|3.9|700W
B200|40|8.0|1000W
R100|100 (estimated)|13.0|1000W+ (estimated)

[Badesalz]

OK, vielleicht trügt das Bild wenn man News anschaut (letzte 2-3 Monate). Da kam Rubin oft vor. Aber von AMDs MI400 hört man jedenfalls nichts ;)Planungssicherheit. NV hat die Racks schon fertig und 1x bewährt.

AMD bringt es erst raus. Mit UltraEthernet und UAlink 1.0. Das muss sich erst einmal im Felde zeigen :wink: Diesmal hat sich dafür wiederum Altman angetan gezeigt.

[basix]

Es ist jedenfalls spannend, was momentan auch in der klassischen HPC community passiert. Not macht erfinderisch, heisst es doch so schön.

Daraus ist nun das Ozaki Scheme geboren worden, welches auch bei Nvidia auf helle Ohren trifft ;)
https://developer.nvidia.com/blog/nvidia-top500-supercomputers-isc-2025/
https://developer-blogs.nvidia.com/wp-content/uploads/2025/06/Figure-1-Performance-Comparison-of-Native-FP64-and-Emulation-in-BerkeleyGW-Silicon-Simulations-1024x773-png.webp

Anscheinend hat man das Ozaki Scheme nun auch bei mehreren Applikationen evaluiert und bitgenaue Resultate erzielt, wie man sie auch mit regulären FP64-Units erzielt hat.
Da das nun in Libraries gegossen wird, muss man sich als Anwender wohl deutlich weniger um die Feinheiten rund um Emulation und Zahlenpräzision kümmern.
Schubst man den Algorithmus durch FP64-Emulation kommt das selbe Resultat wie bei nativen FP64 Einheiten raus. Das freut doch den Skysnake ;)
Ob man mit FP64-Emulation schneller ist hängt sicher noch vom jeweiligen Algorithmus ab. Das muss man dann halt messen und vergleichen.

Hier ein interessanter Blog von jemandem, der die ISC 2025 besucht hat:
https://blog.glennklockwood.com/2025/06/isc25-recap.html
Und bei diesem Satz musste ich schmunzeln, da sie vermutlich doch ziemlich nahe an der Wahrheit liegen wird. Das Ozaki Scheme ist ein perfektes Beispiel dafür.
And maybe this is the future of HPC conferences: rather than being where new technology is announced, perhaps ISC will become where the scientific community tries to figure out how they can use others' technology to solve problems. That idea - figuring out how to make use of whatever the AI industry is releasing - was certainly pervasive throughout the ISC program this year.

Edit:
Neben FP64-Emulation ist auch Mixed-Precision bei HPC im Vormarsch. Hier verwenden sie für eine Klimasimulation neben einem neuen Algorithmus-Design auch FP32 und FP16 via Matrix-Accelerators
https://arxiv.org/html/2408.04440v2

Bei Mixed-Precision sehe ich eine zusätzliche Synergie mit dem Ozaki Scheme:
Feingranulare Präzision. Da die Anzahl Iterationen im Ozaki Scheme die Präzision ~linear erhöhen, könnte man auch Zwischenformate wie FP12, FP24 oder FP48 implementieren. Das wäre noch einen Schritt weiter als normale FP16/FP32/FP64 Datentypen zu verwenden.

FP64 für alles ist wie ein Vorschlaghammer. Ist einfach und man kriegt alles klein, ist aber oftmals überdimensioniert. Mit Mixed-Precision rechnet man nur noch selektiv in FP64, nur dort wo es nötig ist. Das erhöht die Performance wohl oftmals enorm. Macht aber vermutlich die ganze Rechnerei noch komplexer als sie eh schon ist. Da braucht es zwingend gute Libraries, Tools und Abstraktionslayer sowie Verifikationsverfahren damit z.B. Wissenschaftler nicht mit all diesen Details überfordert werden.

[Badesalz]

Tja Pech. Umdesignen kann AMD den MI400 nicht mehr oder? :rolleyes:

[Zossel]

FP64 für alles ist wie ein Vorschlaghammer. Ist einfach und man kriegt alles klein, ist aber oftmals überdimensioniert. Mit Mixed-Precision rechnet man nur noch selektiv in FP64, nur dort wo es nötig ist. Das erhöht die Performance wohl oftmals enorm. Macht aber vermutlich die ganze Rechnerei noch komplexer als sie eh schon ist. Da braucht es zwingend gute Libraries, Tools und Abstraktionslayer sowie Verifikationsverfahren damit z.B. Wissenschaftler nicht mit all diesen Details überfordert werden.

Simulationen verwenden gerne für die nächste Berechnung das Ergebnis der vorherigen Berechnung, da wird man aufpassen müssen sich keine heftigen Fehlerfortpflanzungen zu ziehen:

Beispiel: https://de.wikipedia.org/wiki/Schmetterlingseffekt#Wissenschaftlicher_Hintergrund

[Badesalz]

Simulationen verwenden gerne für die nächste Berechnung das Ergebnis der vorherigen Berechnung, da wird man aufpassen müssen sich keine heftigen Fehlerfortpflanzungen zu ziehen:Ich glaub ich ping mal wieder den Lehmann an :tongue: (FluidX3D)

[Gipsel]

Anscheinend hat man das Ozaki Scheme nun auch bei mehreren Applikationen evaluiert und bitgenaue Resultate erzielt, wie man sie auch mit regulären FP64-Units erzielt hat.Die Erfinder behaupten das nicht, sondern sprechen nur von "vergleichbaren" Ergebnissen. Die maximalen Fehlerangaben im Paper suggerieren auch, daß man mit entsprechendem Aufwand (höhere Präzision dauert halt ein wenig länger und die läßt sich als Parameter festlegen) den maximalen Fehler auf die Genauigkeit von FP64 (oder theoretisch auch drunter) drücken kann, aber auch das garantiert Dir keine bitgenauen Resultate, sondern nur eine (eventuell auch hohe) Wahrscheinlichkeit, daß das Ergebnis identisch ist.
Dies verhindert nicht den Einsatz, erfordert aber gegebenfalls, daß man sich über den zum Einsatz kommenden Zahlenbereich und eventuelle Auswirkungen von solchen Rundungsfehlern im Klaren ist. Im Prinzip sollte man das immer im Hinterkopf behalten. Das Hauptproblem dürfte in der Validierung der Korrektheit der Berechnungen liegen, wenn Ergebnisse mal so und mal so berechnet werden.

[Badesalz]

Was ist das jetzt? Ich schreib schon 2x, daß dies 100% immer mal gegengerechnet wird. Wird trotzdem mehrfach schneller.

Die kontraproduktiven Klammern kaschieren bisschen die seltsame Aussage (Rundungsfehler? ;) ) in dem Satz. Da steht:
"Die maximalen Fehlerangaben im Paper suggerieren auch, daß man mit entsprechendem Aufwand den maximalen Fehler auf die Genauigkeit von FP64 drücken kann, aber auch das garantiert Dir keine bitgenauen Resultate, sondern nur eine Wahrscheinlichkeit, daß das Ergebnis identisch ist."

Also... Die Folien enthalten Beispiele bis wieviel hinter dem Koma es passt. Wo ist da die stelle wo man darüber noch oraklen müsste?

Und das Papier kann nicht einerseits sagen (dein Satz) der maximale Fehler lässt sich auf FP64 Genauigkeit drücken, und andererseits gibt es keine Bitgenauigkeit und nur eine Wahrscheinlichkeit. Hä?

Skysnake... Nie ist er da, wenn man ihn braucht :wink:

[Gipsel]

Da steht:
"Die maximalen Fehlerangaben im Paper suggerieren auch, daß man mit entsprechendem Aufwand den maximalen Fehler auf die Genauigkeit von FP64 drücken kann, aber auch das garantiert Dir keine bitgenauen Resultate, sondern nur eine Wahrscheinlichkeit, daß das Ergebnis identisch ist."

Also... Die Folien enthalten Beispiele bis wieviel hinter dem Koma es passt. Wo ist da die stelle wo man darüber noch oraklen müsste?Die Letzte, die ins Datenformat paßt (ulp (https://en.wikipedia.org/wiki/Unit_in_the_last_place)). Die ist auch bei einer Genauigkeit, die nominell besser als die Auflösung des Zieldatenformats ist, nicht garantiert identisch.
Und das Papier kann nicht einerseits sagen (dein Satz) der maximale Fehler lässt sich auf FP64 Genauigkeit drücken, und andererseits gibt es keine Bitgenauigkeit und nur eine Wahrscheinlichkeit. Hä?Ist aber so. Das Paper sagt nicht, es gäbe identische Ergebnisse (sie nennen es 'comparable results').
Und warum identische Ergebnisse nicht garantiert sind, erkennt man an einem einfachen Beispiel:
Messe eine Distanz mit 2 verschiedenen Verfahren, die beide maximal einen Millimeter Abweichung voneinander zeigen (Genauigkeit des Verfahrens) und runde dann auf ganze Zentimeter (FP64 Auflösung). Die Wahrscheinlichkeit, daß sich das Endergebnis unterscheidet, beträgt dann bis zu 10%. Und wenn man nur 1 oder 2 Bit mehr Genauigkeit hat, sind es eben (je nachdem, ob es einen Bias in der Genauigkeit gibt oder nicht) irgendwo zwischen 12,5% und 50% der Fälle mit einer Abweichung zu rechnen. Beweisbar immer identische Ergebnisse zu erhalten, ist oft nicht ganz einfach (und insbesondere, wenn sich die Berechnungsweise unterscheidet, kann es sogar unmöglich sein).
IEEE-754 konforme Fließkommaeinheiten garantieren übrigens, daß jede Operation das korrekt gerundete Ergebnis einer hypothetisch mit unendlicher Genauigkeit durchgeführten Rechnung ist (die Abweichung vom 'perfekten' Ergebnis unendlicher Genauigkeit ist <=0.5 ulp). Und da geht Einiges an Aufwand rein, um das sicherzustellen. *

Und was ich vorhin noch schrieb, ist daß man sich als Programmierer (oder auch Anwender) der Grenzen und Limitierungen des benutzten Algorithmus bewußt sein sollte, damit man es vermeidet, daß eventuelle Abweichungen/Rundungsfehler beim Aneinanderhängen von Operationen exponentiell anwachsen. Das gilt aber eigentlich immer, unabhängig von dieser FP64 Emulation für Matrixoperationen.

*: Intel hat da beim FDIV Bug des Ur-Pentiums geschludert, so daß der bei einem Anteil von ~1,3E-10 (0,00000001316%) der möglichen Eingangswerte ein falsches Ergebnis auswarf (nicht völlig falsch, nur ungenau). Und daran erinnert man sich heute noch. ;)

[Badesalz]

Alles plausibel. Ich denke es kommt trotzdem ;) (#41, #43)

Ich zapf mal die Tage paar Leute dazu an :up: (die auch keinen NV-bias kennen)

PS:
x87 konnte doch long double (?) :wink:

[basix]

Die Erfinder behaupten das nicht, sondern sprechen nur von "vergleichbaren" Ergebnissen. Die maximalen Fehlerangaben im Paper suggerieren auch, daß man mit entsprechendem Aufwand (höhere Präzision dauert halt ein wenig länger und die läßt sich als Parameter festlegen) den maximalen Fehler auf die Genauigkeit von FP64 (oder theoretisch auch drunter) drücken kann, aber auch das garantiert Dir keine bitgenauen Resultate, sondern nur eine (eventuell auch hohe) Wahrscheinlichkeit, daß das Ergebnis identisch ist.
Dies verhindert nicht den Einsatz, erfordert aber gegebenfalls, daß man sich über den zum Einsatz kommenden Zahlenbereich und eventuelle Auswirkungen von solchen Rundungsfehlern im Klaren ist. Im Prinzip sollte man das immer im Hinterkopf behalten. Das Hauptproblem dürfte in der Validierung der Korrektheit der Berechnungen liegen, wenn Ergebnisse mal so und mal so berechnet werden.

Ich hatte mich da auf das hier bezogen:
https://hal.science/hal-02986873v1/document
This paper presented an accurate and reproducible implementation
of the CG method on CPUs and GPUs. The accurate and repro-
ducible operations were introduced into all the inner-product-based
operations in the CG method through the Ozaki scheme, which
performs the correctly-rounded operation. We conducted numeri-
cal experiments on different platforms, including CPUs and GPUs.
While the implementations using existing vendor libraries might
return non-identical results, our implementations always returned
a bit-level identical result.

Wenn ich das nochmals lese hat sich das "bit-level identical" auf verschiedene CPU vs. GPU Solver bezogen, welche das Ozaki Scheme nutzen.

Tja Pech. Umdesignen kann AMD den MI400 nicht mehr oder? :rolleyes:
Wieso sollte man? Wird viele INT8 Matrix-OPS liefern ;) Dazu wohl auch genug FP32 und FP16 für irgendwelche Mixed-Precision Sachen.

[Zossel]

x87 konnte doch long double (?) :wink:

Auf dem !!internen!! Stack hat rechnet X87 mit 80 Bit, der Stack ist allerdings nicht beliebig groß.
Je nachdem wie oft Zahlen beim rausschreiben auf 64 Bit gerundet werden können sich Ergebnisse unterscheiden.

[mksn7]

Auf dem !!internen!! Stack hat rechnet X87 mit 80 Bit, der Stack ist allerdings nicht beliebig groß.
Je nachdem wie oft Zahlen beim rausschreiben auf 64 Bit gerundet werden können sich Ergebnisse unterscheiden.

Mehr Bits! klingt erstmal toll, war aber praktisch gesehen eine dumme Idee. Kleinste, völlig unabhängige Veränderung im Code (oder in der Ccompilerversion) können Entscheidungen des Compilers ob eine Variable im X87 Register bleibt oder zwischendurch mal in den Speicher gespillt wird (und dabei gerundet wird) verändern, und schon sind die Ergebnisse nicht mehr die gleichen. Reproduzierbare, konsistente Genauigkeit ist wichtiger als die absolute Genauigkeit.

Also würden die viele libraries lieber nicht je nach Hardwarefähigkeiten automatisch zwischen emuliert und nativ fp64 wechseln, sondern sich für das eine oder das andere entscheiden.

[basix]

Also würden die viele libraries lieber nicht je nach Hardwarefähigkeiten automatisch zwischen emuliert und nativ fp64 wechseln, sondern sich für das eine oder das andere entscheiden.

Ja, ich denke das eine gute Idee und vermeidet Kopfschmerzen. CPU und GPU Solver scheinen ja die gleichen Resultate zu liefern.

Zum Ozaki Scheme, IEEE 754 FP64 und Nvidias Libraries
Könnte Nvidia hier nicht entsprechende Checks und Zusatzmassnahmen einbauen, sodass emulierte FP64 Berechnungen die selben numerischen Outputs liefer wie native FP64 Berechnungen? Das wäre für alle Anwender ja am einfachsten. Evtl. verliert man ein bisschen an Performance, netto ist es aber ein Win-Win5:
- Erhöhte FP64 Performance für Anwender
- Erhöhte FP64 Performance für Nvidias GPUs mit Tensor-Cores
- Direktes Drop-In Replacement für native FP64 Berechnungen (keine zusätzlichen Checks von Anwender / Algorithmus Seite notwendig)
- Zukünftig kann man native FP64-Units noch weiter zurückstutzen und noch stärker auf ML/AI Acceleration-Units setzen
- Mehr ML/AI Acceleration-Units? Würde die emulierte FP64 Performance noch weiter erhöhen

[Badesalz]

Zum Ozaki Scheme, IEEE 754 FP64 und Nvidias Libraries
Könnte Nvidia hier nicht entsprechende Checks und Zusatzmassnahmen einbauen, sodass emulierte FP64 Berechnungen die selben numerischen Outputs liefer wie native FP64 Berechnungen? 2 Beiträge noch dann fange ich an zu glauben, daß Jensen selbst sich das Scheme erdacht hat :rolleyes:

[basix]

Erfunden hat er es sicher nicht ;) Und auch AMD und Intel und generell jeder mit eigenen HW-Designs kann die gleiche FP64 Emulation einbauen. Nvidia wird da vermutlich einfach der Schnellste sein. Und wir sind im Blackwell-Next Thread ;)
Es ging mir bei der Frage aber mehr um das generelle Thema FP64 Präzision und ob man das IEEE 754 Format eben auch emulieren könnte. Eine 1-1 Austauschbarkeit von IEEE 754 FP64 nativ vs. Emulation wäre ein riesen Ding.

Für Nvidia ist es natürlich etwas, was sie jetzt nur zu gerne in die Welt rausposaunen, vermarkten und in ihren GPUs verwenden wollen. Falls DGEMM Emulation sogar generell schneller und energieffizienter als natives FP64 sein sollte, erlaubt das prinzipiell auch eine Vereinheitlichung und Vereinfachung der HW und noch mehr Platz für ML/AI Units in ihren GPUs, ohne die klassische HPC-Community auf der Strecke zu lassen. Und daneben auch die ganzen klassischen CAD, CFD usw. Use-Cases, welche via Emulation auch auf Consumer/Workstation-GPUs massiv schneller wären. Für Nvidia ist es also vor allem eines: Ein grosser Business Case ;)

Das gilt aber genauso für AMD und andere Firmen mit ML/AI Accelerators.

Ich für mich sehe es da relativ neutral hinsichtlich Firma. FP64 Emulation scheint anhand der ersten Informationen einiges Potential zu haben. Ob es dann einen Durchbruch gibt, werden wir noch sehen.

[Zossel]

Mehr Bits! klingt erstmal toll, war aber praktisch gesehen eine dumme Idee. Kleinste, völlig unabhängige Veränderung im Code (oder in der Ccompilerversion) können Entscheidungen des Compilers ob eine Variable im X87 Register bleibt oder zwischendurch mal in den Speicher gespillt wird (und dabei gerundet wird) verändern, und schon sind die Ergebnisse nicht mehr die gleichen. Reproduzierbare, konsistente Genauigkeit ist wichtiger als die absolute Genauigkeit.

Typischer Intel-Müll.

[Zossel]

2 Beiträge noch dann fange ich an zu glauben, daß Jensen selbst sich das Scheme erdacht hat :rolleyes:

Eigentlich macht man so was durch die entsprechende Auslegung der Algorithmen.
Seit dieser IEEE-Norm für Floats kann man sich schon besser auf das verlassen was da gerechnet wird, das war nicht immer so.

Und es gibt durchaus sicherheitsrelevante Sache die auf Computern gerechnet werden, da braucht es wirklich keine weitere Fehlerquelle. Rechenfehler durch xls sind ja mittlerweile legendär, und davon braucht es nicht mehr.

[Badesalz]

@zossel
Der Text ist ok, aber passt nicht so ganz zum Quote ;) basix hat den Joke aber gecheckt :up:


Nun... Wir werden erst schauen müssen wie die Idee einerseits vom Ingenieurwesen und andererseits von der Wissenschaft angenommen wird.
Auch mal eben 10x schneller durch OS2-M8 mit gleicher HW wird beständig reizen. Imho wird sich dem kaum jemand verwehren können und nicht wenigstens ordentliche Testphasen fahren ;)

Erstmal wird man das also eh erst aktiv benutzen müssen (Tests in realen Fällen) und dann werden sich in der Scene die positiven wie negativen Erfahrungen und Berichte der Projektleiter bestimmt ordentlich mehren :rolleyes: ERST DANN zeigt sich wieviel das Zeug real und praktisch taugt. Nicht durch vorab philosophisch-mathematische Thesen.

Die Frage für ein Forum ist eigentlich eher nur, ob das attraktiv genug ist, daß sich das wer auf diese Weise anschaut. Meine Antwort ist ja, ist es.
Wenn man das Ergebnis am nächsten Tag hat und nicht nach einer Woche, welches verlässlich erzählt, ob man ggf. auf dem Holzweg ist, dann wird das eh direkt angenommen. Den besten Weg nach jener Suche, kann man ja ab da mit legacy FP64 gehen. Beschleunigt das gesamte Verfahren als Ganzes, trotzdem massiv.

In anderen Fällen kann man ggf. auch etwas in gefühlter quasi-echtzeit (<0,5s) machen, statt jeweils 10s (bei gleicher Grid-Auflösung!) nach jeder Veränderung zu warten. Das wäre auch nur was den Flow der Arbeit angeht schon ein RIESEN Sprung.