News AMD Advancing AI 2026: Epyc, Helios & Co. übernehmen San Franciscos Moscone Center

[CDLABSRadonP...]

Du willst den relevanten Punkt einfach nicht sehen. Wenn der zentrale L3-cache wegfällt ist es kein klassischen CCX mehr.

Wenn es keinen zentralen L3 mehr gibt ist es irrelevant wie die Kerne organisiert werden, weil nicht die Latenz zwischen den Kernen interessiert sondern die Latenz zum gemeinsamen L3. Einen L3 aufzuspiltten und trotzdem als einheitlichen L3 zu behandeln, hat unweigerlich auswirkungen auf die Latenz.

Und die einfachste Lösung wäre gewesen zwei bisherige CCX auf CCD zu packen und nichts an der Anordnung im CCX zu tun. Warum hat AMD dies offensichtlich nicht getan?

Vermutlich kommt es wirklich zum MindBlown-Moment und wir werden morgen V-Cache bzw. Base-Tile-Cache sehen.

Bei der MI300 waren 2 spiegelverkehrte IODs notwendig weil 4 IODs angeordnet werden mussten. Die alternative wäre gewesen die IOD symetrisch zur 90°-Drehung zu machen.

Das sagtest du ja schon und entsprach auch der Situation bei SapphireRapids. Nur waren es dort halt Chiplets, die Kerne enthielten und im CuttingEdge-Node produziert wurden.

 

[Philste]

Natürlich wirft es alles komplett über den Haufen, weil der L3Cache vollkommen fehlt.

Achso, ich dachte es wäre einfach ein Mesh und das rechts neben jedem Kern ist der Cache.

Edit: Sorry, unter den IODs ist der Cache rechts, über den IODs links.

Ergänzung (22. Juli 2026)

Was wohl auch mal wieder in AMDs eher trauriger Tradition steht, inkorrekte Angaben irgendwo zu committen.

Gab es irgendwo offiziell etwas, was auf 32 Kern CCDs/ 128 MB Cache hingedeutet hat? Alles, was ich dazu kenne, sind irgendwelche Slides, die von den üblichen Verdächtigen geteilt wurden und weiß Gott wie alt sind. Es köntensich schlicht herausgestellt haben, dass dee 32 Kern CCX keinen Vorteil bringt, der groß genug ist oder alternativ hat es auch einfach nicht funktioniert.

 

[ETI1120]

Achso, ich dachte es wäre einfach ein Mesh und das rechts neben jedem Kern ist der Cache.

Bisher hat AMD immer den L2-Cache neben dem kern dargestellt. Möglich dass AMD diesesmal darauf verzichtet hat und alles im Kern verschwimmen lässt inklusive L2-cache.

Gab es irgendwo offiziell etwas, was auf 32 Kern CCDs/ 128 MB Cache hingedeutet hat?

Ja dieses Schnisel der Folie die neulich aufgetaucht ist als der Commit mit dem 64 MB L3 Cache bekannt wurde.

Aber dieses Schnipsel hat bei mir sofort ungute Erinnerung an die Fake AMD-Roadmaps von 2020 ausgelöst. Da wurden auch nur Schnipsel gezeigt und wir wissen heute dass Van Gogh nie auf ener Roadmap für Mobil APUs war.

Alles, was ich dazu kenne, sind irgendwelche Slides, die von den üblichen Verdächtigen geteilt wurden und weiß Gott wie alt sind.

Das einzige was ich kenne ist der Schnipsel, der angeblich von einer AMD Folie stammt. Alles das ich kenne sind Folien von MLID oder Posts in Foren oder auf X ohne jeden Beleg.

Es köntensich schlicht herausgestellt haben, dass dee 32 Kern CCX keinen Vorteil bringt, der groß genug ist oder alternativ hat es auch einfach nicht funktioniert.

Sorry zwei Meshs mit 16 kernen ergibt keinen Sinn. Und auch hier nochmal wenn AMD zwei CCX verbaut warum verwirft AMD die bisherige Anordnung?

 

[CDLABSRadonP...]

Also ich zähle da auch 8x32 und nicht 16x16 Cores

Es sind auch definitiv acht CCDs; vor zwei Tagen wurde der bisher nur auf Renderbildern (oder extrem unscharf) gezeigte Aufbau auch in die Kamera gehalten:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

(Originalquelle)
https://wccftech.com/amd-helios-ai-rack-mi455x-6th-gen-epyc-challenging-nvidia/ (für Shots aus den Videos)

Auch @Volker vielleicht etwas für ein Update.

 

[ETI1120]

Vermutlich kommt es wirklich zum MindBlown-Moment und wir werden morgen V-Cache bzw. Base-Tile-Cache sehen.

64 MB wären schon wenig auf die gesamte Fläche des CCD und dann ergibt sich die Frage was sind die Blöcke die zum IOD hin angeordnet sind. Wie gesagt die sind eigentlich viel zu fett wenn man keine SerDes braucht. Aver egal was es ist, ergibt so was mit einem Base Die darunter wenig Sinn.

Aber ich stimme Dir zu, da fehlen noch Infos.

Tiles ist eine Intel-Bezeichnung. In der Industrie heißt es Chiplet.

Das sagtest du ja schon und entsprach auch der Situation bei SapphireRapids. Nur waren es dort halt Chiplets, die Kerne enthielten und im CuttingEdge-Node produziert wurden.

Möglich, bis auf das Advanced Packaging habe ich mich mit Saphhire Rapids nicht beschäft. Das Advanced Packaging war überambitioniert und wurde durch die hoffnungslos veraltete Architektur des SoC überdies untergraben.

Allerdings ist Sapphire Rapids das Stichwort wenn es um die Siliziumbrücken geht. Gibt es nur eine zwischen den beiden IOD oder sind auch die CCD mit dem IOD über eine Siliziumbrücke angeschlossen. Das hätte einen massiven Einfluss auf die Komplexität der Fertigung.

Ergänzung (22. Juli 2026)

Es sind auch definitiv acht CCDs; vor zwei Tagen wurde der bisher nur auf Renderbildern gezeigten Aufbau gezeigt auch in die Kamera gehalten:

Das hatte Lisa Su schon auf der CES 2026 gemacht. Außerdem wäre es ambitioniert die 2. Reihe anzuschließen.

Ergänzung (22. Juli 2026)

Ian Cutress nervt zur Zeit ein wenig. Aber er hat mit seinem Rand gegen CNBC vollkommen recht. Das was CNBC ist alles andere als exclusiv und vor allem kein First Look.

AMD hat Helios zum ersten Mal im Oktober gezeigt und die Chips ohne Kühler hat wie gesagt Lisa Su schon auf der CES 2026 gezeigt.

 

[CDLABSRadonP...]

Ian Cutress nervt zur Zeit ein wenig. Aber er hat mit seinem Rand gegen CNBC vollkommen recht. Das was CNBC ist alles andere als exclusiv und vor allem kein First Look.

AMD hat Helios zum ersten Mal im Oktober gezeigt und die Chips ohne Kühler hat wie gesagt Lisa Su schon auf der CES 2026 gezeigt.

Habe das Posting entsprechend angepasst; erinnere mich nun wieder an die extrem unscharfen Photographien von damals.

 

[basix]

Du willst den relevanten Punkt einfach nicht sehen. Wenn der zentrale L3-cache wegfällt ist es kein klassischen CCX mehr.

Wenn es keinen zentralen L3 mehr gibt ist es irrelevant wie die Kerne organisiert werden, weil nicht die Latenz zwischen den Kernen interessiert sondern die Latenz zum gemeinsamen L3. Einen L3 aufzuspiltten und trotzdem als einheitlichen L3 zu behandeln, hat unweigerlich auswirkungen auf die Latenz.

Und die einfachste Lösung wäre gewesen zwei bisherige CCX auf CCD zu packen und nichts an der Anordnung im CCX zu tun. Warum hat AMD dies offensichtlich nicht getan?

Ich verstehe deine Argumentation nicht. CCX bedeutet "Core Complex". Wie da der Cache angeordnet ist, spielt da keine grundlegenede Rolle. Ja, es ist anders als bisher. Aber die Latenz zum gemeinsamen Cache muss das nicht behindern. Jeder Core spillt immer zuerst in den eigenen lokalen L3$-Slice. Das ist immer noch so. Und auch beim 32 MByte L3$ von Zen 3/4/5 besteht der Cache aus mehreren Blöcken. Solange das zugrunde liegende Netzwerk fürs verbinden der Cache-Slices passt, hast du keine wesentlichen Nachteile bei Latenzen. Die physische Distanz zwischen den Cache-Blöcken ist zwar etwas grösser als bei einem Zen 3/4/5 CCD, aber das ist nicht weltbewegend. Hier hilft, dass man nun 4MB anstatt 2MB verbaut, somit müssen Remote-Slices weniger oft angefragt werden. Was hingegen besser wird bei dieser Anordnung, ist die Core-to-Core Distanz. Quadratisch ist hier besser als rechteckig. Dürfte also schlicht ein Tradeoff zwischen Performance und physischer Anordnung der Cores sein.

 

[BxBender]

Sieht ja wirklich nach 2 16 Core CCX pro CCD aus o.O.

Das wirft ja alles über den Haufen, wobei es zu dem 64MB L3 Leak passt

Ja, sehe ich auf dem Bild auch so.

16 Kerne in einem CCX, 2 Blöcke davon ergeben einen großen CCD, davon gibt es insgesamt 8 um den I/O herum.

Waren es damals in den ersten beiden Zen Runden nicht noch 4CCX pro CCD?
Gibt es einen Grund, warum man nicht gleich von 8 auf 16 geht, damit jeder Kern dann auch den gesamten Cache im CCD nutzen kann, und nicht nur auf seinen CCX beschränkt bleibt?
Vermutlich braucht man das noch als Optimierungspotential für Zen 7? ;-)
Könnte mir aber vorstellen, dass der Sprung und die Fertigung als Block da wegen der Ausfallrate zu hoch ist und zu viel Fläche dann verschrottet wird?
Wie gesagt, ich denke, das wird mit Zen 7 dann kommen.

 

[ETI1120]

Ich verstehe deine Argumentation nicht. CCX bedeutet "Core Complex". Wie da der Cache angeordnet ist, spielt da keine grundlegenede Rolle.

Und da es keine Rolle spielt hat AMD die ganze Zeit diese Anordnung beibehalten, ...

Ja, es ist anders als bisher. Aber die Latenz zum gemeinsamen Cache muss das nicht behindern. Jeder Core spillt immer zuerst in den eigenen lokalen L3$-Slice. Das ist immer noch so. Und auch beim 32 MByte L3$ von Zen 3/4/5 besteht der Cache aus mehreren Blöcken.

... muss nicht behindern ...

Solange das zugrunde liegende Netzwerk fürs verbinden der Cache-Slices passt, hast du keine wesentlichen Nachteile bei Latenzen.

Solange ...

Die physische Distanz zwischen den Cache-Blöcken ist zwar etwas grösser als bei einem Zen 3/4/5 CCD,

Wir haben einen doppelt so großen Die.

Wenn wir eine "Mesh-Topologie" haben sollten, ist es erst Mal die Frage ist es ein Mesh oder ein Torus. Und wie gesagt Mesh und 2 CCX ergibt keinen Sinn. Vor allem wenn das zweite CCX gar nicht direkt an die Ports zum IOD liegt.

Die Latenz kommt übrigens von den Switches und Repeatern im Netzwerk. Und was das anbelangt kommen bei einem Mesh sehr viele zusammen, ...

aber das ist nicht weltbewegend. Hier hilft, dass man nun 4MB anstatt 2MB verbaut, somit müssen Remote-Slices weniger oft angefragt werden. Was hingegen besser wird bei dieser Anordnung, ist die Core-to-Core Distanz. Quadratisch ist hier besser als rechteckig. Dürfte also schlicht ein Tradeoff zwischen Performance und physischer Anordnung der Cores sein.

Ich denke Ihr seht alle nur 64 MB, dann bleibt es bei 2 MByte.

Ihr seit alle mächtig schnell bei schlüssen die auf einer Marketing-Zeichnung von AMD beruhen. Und dann zieht ihr Schlüsse die sich widersprechen.

Ergänzung (22. Juli 2026)

Könnte mir aber vorstellen, dass der Sprung und die Fertigung als Block da wegen der Ausfallrate zu hoch ist und zu viel Fläche dann verschrottet wird?

TSMC geht nur mit einem guten Yield in HVM.

Das Zen 6 Dense CCD ist ca. doppelt so groß wie die bisherigen CCDs.

 

[basix]

Wenn wir eine "Mesh-Topologie" haben sollten, ist es erst Mal die Frage ist es ein Mesh oder ein Torus. Und wie gesagt Mesh und 2 CCX ergibt keinen Sinn. Vor allem wenn das zweite CCX gar nicht direkt an die Ports zum IOD liegt.

Die Latenz kommt übrigens von den Switches und Repeatern im Netzwerk. Und was das anbelangt kommen bei einem Mesh sehr viele zusammen, ...

Es gibt auch andere Topologien neben Mesh und Torus. Dragonfly, Butterfly, Donut, Bypass-Torus, Folded-Torus, ButterDonut, Misaligned-ButterDonut, Double Butterfly, FC, HFC usw.

Die haben alle gegenüber einem "concentrated" Mesh das Ziel, die Anzahl Links, Switches und Hops zwischen den Teilnehmern zu reduzieren, ohne dass die Cross-Section Bandwidth zu stark leidet. Da gibt es viele Paper zu dem Thema. Einige davon von AMD.

Ich denke Ihr seht alle nur 64 MB, dann bleibt es bei 2 MByte.

Kann sein. Ändert nichts daran, dass AMD den L3$ nicht mittig lassen kann und entsprechend das Verbindungsnetzwerk anpassen muss. Insbesondere nicht, wenn es ein 32C CCX sein sollte (Grösse des Die, Anahl Teilnehmer im Netzwerk).

 

[ETI1120]

Es gibt auch andere Topologien neben Mesh und Torus. Dragonfly, Butterfly, Donut, Bypass-Torus, Folded-Torus, ButterDonut, Misaligned-ButterDonut, Double Butterfly, FC, HFC usw.

Beim usw. wird es interessant

Kann sein.

Zerlegt aber Deine Argumentation, die auch so schon die wesentliche Punkte außer acht gelassen hat.

 

[basix]

Beim usw. wird es interessant

Dann erzähl uns doch mal was dazu

Zerlegt aber Deine Argumentation, die auch so schon die wesentliche Punkte außer acht gelassen hat.

Es würde einigen Argumentationen nicht unbedingt widersprechen, eher abschwächen. Und andere Argumentationen wie eine angepassete L3$-Topologie sogar bestärken. Es gibt kein schwarz-weiss.

Stand heute die wahrscheinlichste Aufbauweise ist:

• 32C pro CCD
• 128 MByte pro CCD (mehrere Leaks, Dokumente)
• 16C pro CCX (Blockschaltbild von Venice hier in der News, 64MB L3$ pro CCX Linux Patch)
• Chip-Grösse des CCD schlüssig mit 128MB L3$
• Könnte theoretisch in der alten CCX/L3$ Topologie aufgebaut sein, siehe Zen 5 (Blockschaltbild widerspricht dem)

Zweite Möglichkeit, aber mMn weniger wahrscheinlich:

• 32C pro CCD
• 32C pro CCX (anderer Leak)
• 64 MByte pro CCX (Linux Patch)
• Benötigt zwingend eine andere CCX/L3$-Topologie

Komplett abwegig:

• 3D-Stacked L3$ (Chipgrösse des CCD ist unrealistisch gross)

 

[ETI1120]

Dann erzähl uns doch mal was dazu

Habe ich schon.

Oder genauer: Rachata Ausavarungnirun, Chris Fallin, Xiangyao Yu, Kevin Chang, Greg Nazario, Reetuparna Das, Gabriel H. Loh, Onur Mutlu

Es würde einigen Argumentationen nicht unbedingt widersprechen, eher abschwächen. Und andere Argumentationen wie eine angepassete L3$-Topologie sogar bestärken. Es gibt kein schwarz-weiss.

AFAIU ist die geringe L3-Cache Latenz ein sehr wichtiger Faktor für die Performance der Zen Cores. Diese zu verschlechtern ohne die Kapazität zu erhöhen wäre schon ein gewagter Schritt.

Es würde einigen Argumentationen nicht unbedingt widersprechen, eher abschwächen. Und andere Argumentationen wie eine angepassete L3$-Topologie sogar bestärken. Es gibt kein schwarz-weiss.

Stand heute die wahrscheinlichste Aufbauweise ist:

• 32C pro CCD
• 128 MByte pro CCD (mehrere Leaks, Dokumente)
• 16C pro CCX (Blockschaltbild von Venice hier in der News, 64MB L3$ pro CCX Linux Patch)
• Chip-Grösse des CCD schlüssig mit 128MB L3$
• Könnte theoretisch in der alten CCX/L3$ Topologie aufgebaut sein, siehe Zen 5 (Blockschaltbild widerspricht dem)

Was soll die alte CCX/L3 Topologie sein?

Das Zen 3 CCD hatte laut AMD einen doppelten Ringbus. Was neueres habe ich nicht gefunden. beim Zen 5 Dense CCD bin ich skeptisch, dass es da tatsächlich beim doppelten Ringbus geblieben ist.

Schau Dir doch Mal an wie dünn die Struktur tatsächlich ist, die optisch als Trennlinie wirkt.

Es ergibt keinen Sinn, das eine CCX an das IOD grenzt und damit an die IF-Ports angrenzt und das andere CCX nicht. Da kann ohne eine übergeordnete Struktur die das zweite CCX mit den IF-Ports verbindet nicht funktionieren, was jedoch bedeutet man hat eine andere Topologie.

Zweite Möglichkeit, aber mMn weniger wahrscheinlich:

• 32C pro CCD
• 32C pro CCX (anderer Leak)
• 64 MByte pro CCX (Linux Patch)
• Benötigt zwingend eine andere CCX/L3$-Topologie

Daran kommt man mit 32 Kernen so oder so nicht herum.

Die Frage ist eben welche Topologie wählt AMD und wie sorgt AMD dafür dass die L3-Latenz nicht steigt.

Komplett abwegig:

• 3D-Stacked L3$ (Chipgrösse des CCD ist unrealistisch gross)

Das ist der Punkt der mich auch zögern lässt.

Da müsste AMD noch was anderes draufpacken und dann ergibt die Struktur zum IOD eigentlich keinen Sinn.

Auf der anderen Seite 128 MByte L3 geht nur mit weiteren Tricks am SRAM. Und wenn wir hier tatsächlich einen disaggregierten L3 sehen wird es sehr schwer das mit einem L3-Cchiplet zu verbinden.

Ergänzung (22. Juli 2026)

Eine lange erwartete Meldung:

https://newsroom.amd.com/news/amd-anthropic-strategic-partnership/

 

[basix]

Ah, die Präsentation kenne ich

Der alte L3$-Interconnect hat sich von Point-to-Point (4C) zu "Bisected-Ring" (8C) weiterentwickelt. Beim 16C Zen 5 Dense Chiplet gibt es afaik keine öffentlichen Infos.

Und wieso sollte das mit 2x CCX nicht gehen? Ich würde vermuten, man könnte auf oberen Metal-Layers routen, da dort die Widerstände deutlich kleiner sind, was für längere Leitungen besser wäre.

Ansonsten könnte das Teil in der Mitte auch eine Art Crossbar zwischen den 16C Segmenten sein.

Du, vielleicht überrascht uns AMD und es ist doch 3D-Stacked (und AMD pappt ein paar NPUs neben die Cores oder so ).

 

[ETI1120]

Ah, die Präsentation kenne ich

Es gubt auch einen Fachartikel dazu und Onur Mutlu verwendet es in seinem Vorlesungen.

Der alte L3$-Interconnect hat sich von Point-to-Point (4C) zu "Bisected-Ring" (8C) weiterentwickelt. Beim 16C Zen 5 Dense Chiplet gibt es afaik keine öffentlichen Infos.

In dem Artikel sagen sie Ringe funktionieren bis 10 Knoten.

Und wieso sollte das mit 2x CCX nicht gehen? Ich würde vermuten, man könnte auf oberen Metal-Layers routen, da dort die Widerstände deutlich kleiner sind, was für längere Leitungen besser wäre.

2 CCX ohne übergeordnete Struktur funktionieren wenn beide direkten Kontakt zu ihren IF-Ports haben.

Wenn der eine Kontakt hat und der andere nicht gibt es zwei Lösungen:

• 2 asymetrische CCX, ich würde mich wundern, wenn das überbrücken des anderen CCX ohne Repeater funktionieren würde.
• Übergeordnte Struktur die beide CCX mit den IF Ports verbindet. Aber das wäre ja eine andere Topologie

Ansonsten könnte das Teil in der Mitte auch eine Art Crossbar zwischen den 16C Segmenten sein.

Zum Beispiel, oder Switches zwischen den Ringen

Du, vielleicht überrascht uns AMD und es ist doch 3D-Stacked (und AMD pappt ein paar NPUs neben die Cores oder so ).

So was hatte AMD ja am FAD 2022 angedeutet. aber dann wurde es wieder ziemlich still um die NPU auf der Serverseite.

Mit der Ankündigung von ACE wird es unwahrscheinlicher, ... aber vielleicht hat AMD ja Ideen für weitere Beschleuniger, ...

 

[bensen]

Wobei dies vergleichsweise einfach ist, da sie sauber in einer 2 × 4 × 4-Anordnung in einem der CCDs vertreten sind.

Das passt mal so gar nicht.
Wie hier schon diskutiert wurde, sind es eher 8 Chiplets mit je 2 CCX.

Aber selbst wenn es 16 wären, dann wäre es 2x2x4. 2x4x4 sind 32.


Ansonsten zu der weiteren Diskussion hier. Das sind keine Die shots. Spekulation ist immer schön, aber ich würde da nicht zu viel hinein interpretieren.

 

[ETI1120]

Ansonsten zu der weiteren Diskussion hier. Das sind keine Die shots.

Natürlich sind das keine Die Shots. Das AMD Marketing liebt es nun Mal die Chips mit solchen künstlerischen Grafiken in Szene zu setzen. Allerdings waren die Grafiken bisher nie total falsch. Sie haben haben das eine gezeigt und das andere nicht.

Also wenn AMD nun nicht mehr den zentralen L3-Cache darstellt, dann wird er im Die auch nicht mehr da sein.

 

[Volker]

Ja das sind keine echten Die-Shots, sry falls das Konfusion versursachte. Auch bezüglich der Aufteilung, war bissel dumm geschreiben hier. Das ist halt das Problem wenn man NDA hat und nix sagen darf
Mehr deshalb morgen!

 

[stefan92x]

Das ist halt das Problem wenn man NDA hat und nix sagen darf

In anderen Worten, du kennst Details und AMD gibt Details bekannt. @CDLABSRadonP... kann also in der Hinsicht beruhigt sein.

 

[ETI1120]

@stefan92x Wenn er die Details schon kennt, hat er Zeitmaschine oder hat AMD die Medien vorab eingeweiht?