SemiAnalysis 4-hi-HBM-Analyse: Warum kürzere Stacks bei KI-Inferenz gewinnen könnten
SemiAnalysis stellt das Wettrennen der KI-Speicherbranche zu immer höheren Stacks infrage und argumentiert, dass 4-hi HBM die volle Bandbreite mit nur einem Drittel der DRAM-Dies liefern kann.
Diese Behauptung ist bedeutsam, weil Hersteller von Beschleunigern seit Jahren immer höhere Speicher-Stacks einsetzen. Mehr Schichten erhöhten die Kapazität, unterstützten größere Modelle und machten High-Bandwidth Memory zu einem unverzichtbaren Bestandteil des KI-Computings.
Die SemiAnalysis 4-hi HBM analysis besagt, dass Inferenz diese Rechnung nun verändert. Systeme auf Rack-Ebene bieten mehr Gesamtkapazität, während Quantisierung und Cache-Offloading die Speichermenge reduzieren, die jede GPU vorhalten muss.
Der Bericht behauptet nicht, dass jede Arbeitslast weniger Speicher benötigt. Training, große Batches und zukünftige Modelle können weiterhin von höheren Stacks profitieren. Sein präziseres Argument betrifft interaktive Inferenz, bei der die Bandbreite die Token-Generierung häufig begrenzt, bevor die Kapazität knapp wird.
Dadurch entsteht ein direkter Wettbewerb zwischen zwei Designprioritäten. Die eine bevorzugt maximale Speicherkapazität pro Beschleuniger. Die andere maximiert die Token-Bandbreite aus jedem begrenzten DRAM-Wafer.
Nvidias berichtete Verringerung des Rubin-Ultra-Speichers liefert das unmittelbare Signal. Laut SemiAnalysis wird der Beschleuniger 192GB HBM tragen, gegenüber 288GB bei Standard-Rubin und Blackwell Ultra.
Das Unternehmen hat eine 4-hi-Konfiguration für Rubin Ultra bislang nicht öffentlich detailliert. Die berichtete Bewegung hin zu 8-hi-Stacks deutet jedoch darauf hin, dass immer höhere HBM-Stacks keine automatische Wahl mehr sind.
Wenn sich diese Logik auf 4-hi HBM4E übertragen lässt, könnte die KI-Infrastruktur weniger DRAM-Dies einsetzen, ohne die externe Bandbreite jedes Stacks einzubüßen. Das würde Speicherkosten senken und aus dem begrenzten Wafer-Angebot mehr nutzbare HBM-Packages erzeugen.
Nvidias Speicher-Roadmap bewegt sich nicht mehr nur in eine Richtung
Die entscheidende Veränderung besteht nicht darin, dass Nvidia plötzlich wenig Speicher benötigt. Vielmehr scheint zusätzliche Kapazität nicht mehr um jeden Preis wertvoll zu sein.
Blackwell Ultra hat die Richtung zu hoher Kapazität klar vorgegeben. Nvidia gibt 288GB HBM3E pro Blackwell-Ultra-GPU und 20TB für ein GB300-NVL72-Rack an.
Die GB300 specifications des Unternehmens nennen zudem eine aggregierte GPU-Speicherbandbreite von bis zu 576TB pro Sekunde. Diese Werte zeigen, warum Nvidia zuvor sowohl Kapazität als auch Bandbreite betonte.
SemiAnalysis berichtet nun, dass Rubin Ultra einen Teil dieses Trends umkehren wird. Die erwarteten 192GB pro GPU entsprechen einer Reduzierung um ein Drittel gegenüber Blackwell Ultra und konventionellem Rubin.
Der Vergleich erfordert etwas Vorsicht. Berichten zufolge wurde Rubin Ultras Architektur von vier auf zwei Compute-Dies geändert. Seine zuvor erwartete Speicherkapazität bezog sich daher auf ein anderes Systemdesign.
Selbst nach Bereinigung um diese Änderung schätzt SemiAnalysis, dass der Speicher von zuvor 256GB pro Compute-Die auf 96GB sinkt. Das ist ein substanzieller Architektur-Neustart, keine kosmetische Anpassung der Spezifikation.
Der Bericht nennt die Versorgung als einen Grund. Nvidia hat Berichten zufolge erhebliche Kapazitäten für fortschrittliche Logik und Packaging gesichert, doch die verfügbaren HBM-Wafer können keine vergleichbaren Mengen an 12-hi-Stacks unterstützen.
Ein 12-hi-Stack enthält zwölf zentrale DRAM-Dies über seinem Base-Die. Ein 8-hi-Stack nutzt acht, sodass dieselbe verarbeitete DRAM-Menge mehr fertige Stacks unterstützen kann.
Das ist wichtig, weil HBM pro Bit mehr Fertigungskapazität verbraucht als konventioneller DRAM. Through-Silicon Vias, bekannt als TSVs, übertragen Signale und Strom vertikal durch den Speicher-Stack.
Diese TSVs erfordern zusätzliche Verarbeitungsschritte. HBM-Dies enthalten zudem Fläche für vertikale Verbindungen, was die Bitdichte gegenüber gewöhnlichem Speicher auf einem ähnlichen Prozess verringert.
SemiAnalysis schätzte zuvor, dass HBM pro Bit ungefähr die dreifache Wafer-Kapazität von Commodity-DRAM verbraucht. Mit der Produktion von HBM4 nähert sich diese Schätzung dem Vierfachen.
Diese Zahl ist eine Analystenschätzung, kein Industriestandard. Die zugrunde liegende Fertigungsbelastung ist bei Speicheranbietern jedoch gut etabliert.
SK hynix, Samsung und Micron müssen mehrere funktionsfähige Dies verarbeiten, ausdünnen, verbinden, testen und verpacken. Jede zusätzliche Schicht steigert den Materialeinsatz und setzt das Package weiteren Ausbeuterisiken aus.
Höhere Stacks rechtfertigten diesen Aufwand in der Vergangenheit, weil Beschleuniger ihre Kapazität benötigten. Modellgewichte, Aktivierungen, Gradienten, Optimizer-Zustände und Key-Value-Caches konkurrieren bei verschiedenen Arbeitslasten um Speicher.
Die neue Entscheidung deutet darauf hin, dass die Kapazität für einige Inferenzsysteme einen Schwellenwert überschritten hat. Sobald ein Rack den erforderlichen Working Set hält, schafft zusätzlicher Speicher auf jeder GPU weniger Mehrwert.
Nvidia hat SemiAnalysis’ genaue Aufschlüsselung der Rubin-Ultra-Kapazität nicht öffentlich bestätigt. Die Behauptung sollte daher als berichtete Roadmap-Änderung und nicht als endgültige Produktspezifikation behandelt werden.
Dennoch können Vorbereitungen in der Lieferkette eine Richtung vor einem öffentlichen Launch offenlegen. SemiAnalysis zufolge bereiten Lieferanten 8-hi-Konfigurationen darauf vor, nach einem Branchenschub zu 12-hi- und 16-hi-Produkten zum Standard zu werden.
Die berichtete Änderung eröffnet Raum für 4-hi HBM. Wenn acht Schichten ausreichen, müssen Entwickler fragen, ob vier Schichten ausgewählte Inferenzdeployments wirtschaftlicher bedienen können.
Während des jüngsten Kapazitätswettlaufs hätte diese Frage rückwärtsgewandt geklungen. Unter starken DRAM-Engpässen wird sie zu einer der praktischsten Architekturentscheidungen der Branche.
SemiAnalysis 4-hi HBM erhält die Bandbreite und spart Dies ein
Ein kürzerer HBM-Stack reduziert die Kapazität, verringert aber nicht automatisch die externe Bandbreite des Packages.
HBM überträgt Daten über eine sehr breite Schnittstelle, statt sich allein auf extrem hohe Signalisierungsgeschwindigkeiten zu stützen. HBM4 erweitert diese Schnittstelle auf 2.048 Datenverbindungen pro Stack.
Der HBM4 standard wurde im April 2025 von JEDEC veröffentlicht. Er definiert die Grundlage für eine neue Generation von KI- und Hochleistungsspeichern.
Laut SemiAnalysis kann jeder HBM4-DRAM-Die auf bis zu 512 der Datenverbindungen des Stacks zugreifen. Vier Dies können daher alle 2.048 Verbindungen belegen.
Das Hinzufügen eines fünften bis zwölften Dies erhöht die Kapazität. Es erweitert die externe Schnittstelle jedoch nicht über diese 2.048 Verbindungen hinaus.
Die verfügbaren Pins werden bei einem höheren Stack auf mehr Speicherschichten verteilt. Der Stack stellt dem Beschleuniger weiterhin dieselbe Gesamtschnittstelle bereit.
Das ist der zentrale Mechanismus hinter dem Argument für kurze Stacks. Ein 4-hi-, 8-hi- und 12-hi-Package kann eine vergleichbare nominale Bandbreite bieten, wenn sie dieselbe Generation und Signalisierungsrate verwenden.
Ihre Kapazitäten unterscheiden sich deutlich. SemiAnalysis modelliert zentrale HBM4E-Dies mit 32 Gigabit, was 16GB für 4-hi, 32GB für 8-hi und 48GB für 12-hi ergibt.
Dabei handelt es sich um modellierte zukünftige Konfigurationen, nicht um allgemein verfügbare Handelsprodukte. Sie veranschaulichen, wie die Schichtanzahl die Kapazität verändert, während die Package-Schnittstelle unverändert bleibt.
Die wirtschaftliche Unterscheidung folgt daraus, was Lieferanten verbrauchen. Der DRAM-Anteil bestimmt einen großen Teil der Kosten eines HBM-Stacks, während Inferenzkunden häufig die Bandbreite schätzen, die ihre Beschleuniger versorgt.
Ein 4-hi-Käufer erhält weniger Gigabyte. Der Käufer kann dennoch den Datenpfad erhalten, der nötig ist, um die Recheneinheiten zu versorgen.
Das verändert die relevante Effizienzkennzahl. Kapazitätsorientierte Beschaffung fragt, wie viele Gigabyte neben jeden Beschleuniger passen. Bandbreitenorientierte Beschaffung fragt, wie viele Tokens diese Speicherverbindungen unterstützen können.
Bei der Inferenz kann die zweite Frage dominieren. Autoregressives Decoding erzeugt Ausgaben sequenziell, und jeder Schritt muss die aktiven Gewichte des Modells aus dem Speicher lesen.
Der Prozess führt für jedes bewegte Byte oft relativ wenig Rechenarbeit aus. Dadurch wird Decoding bandbreitenlimitiert, was bedeutet, dass die Datenbereitstellung den Durchsatz begrenzt, bevor es die Rohrechenleistung tut.
Ein höherer Stack hilft nur, wenn die Arbeitslast seine zusätzliche Kapazität nutzt. Andernfalls enthalten die zusätzlichen Dies Informationen, die die verfügbare Bandbreite nicht häufig genug lesen kann.
SemiAnalysis nennt zur Veranschaulichung eine HBM4E-Bandbreite von 3.328GB pro Sekunde je Stack. Diese Zahl leitet sich aus 2.048 Pins ab, die mit 13 Gigabit pro Sekunde arbeiten.
Bei 100 erzeugten Tokens pro Sekunde entspricht das 33,28GB theoretischer Bandbreite für jeden Token. Der nutzbare Working Set kann dieses Budget nicht überschreiten, wenn jeder Token ihn einmal lesen muss.
Ein 48GB-Stack würde dann mehr Daten enthalten, als die theoretische Bandbreite pro Token durchsuchen kann. Ein Teil der Kapazität bliebe für diese spezifische Arbeitslast bei dieser Geschwindigkeit unzugänglich.
Reale Systeme erreichen niemals jede Einheit ihrer nominalen Bandbreite dauerhaft. Protokoll-Overhead, Zugriffsmuster, Kommunikation und Softwareverhalten reduzieren den effektiven Durchsatz.
Diese Einschränkung kann das Argument für kurze Stacks stärken. Eine geringere nutzbare Bandbreite bedeutet, dass die Arbeitslast ihre Bandbreitengrenze erreicht, bevor sie die gesamte installierte Kapazität ausschöpfen kann.
Das durch diesen Mechanismus erklärte 4-hi HBM ist nicht einfach nur günstigerer Speicher. Es ist eine Konfiguration, die externe Bandbreite von maximaler vertikaler Dichte trennt.
Die Unterscheidung beeinflusst auch den Fertigungsausstoß. Ein Wafer, der für Vier-Schichten-Stacks verwendet wird, kann theoretisch dreimal so viele Packages unterstützen wie einer für Zwölf-Schichten-Stacks.
Die tatsächlichen Gewinne hängen von Ausbeuten, der Verfügbarkeit von Base-Dies, Tests und dem Packaging-Durchsatz ab. Kürzere Stacks sollten außerdem einige kumulative Montageverluste vermeiden, die mit zusätzlichen Schichten verbunden sind.
SemiAnalysis argumentiert, dass die daraus resultierende Bandbreite pro HBM-Wafer ebenso wichtig ist wie Tokens pro Watt. Beide Kennzahlen messen den nutzbaren KI-Output im Verhältnis zu einer Ressource, die sich nicht schnell erweitern lässt.
Warum Inferenz Bandbreite stärker bewertet als maximale Kapazität
Interaktive Inferenz belohnt Speicher, der den Prozessor schnell versorgen kann, während ungenutzte Kapazität wenig zum Token-Durchsatz beiträgt.
Training und Inferenz stellen unterschiedliche Anforderungen an HBM. Training speichert Gewichte, Aktivierungen, Gradienten und Optimizer-Daten, während große Batches durch Forward- und Backward-Passes verarbeitet werden.
Diese Arbeitslast kann enorme Kapazität beanspruchen. Sie führt zudem genug Rechenoperationen aus, um bei vielen Vorgängen rechenlimitiert zu werden.
Inferenz-Decoding ist anders. Das System liest wiederholt aktive Gewichte und den Key-Value-Cache des Nutzers, kurz KV-Cache, während es Token für Token erzeugt.
Der KV-Cache speichert Aufmerksamkeitsinformationen aus früheren Tokens. Er verhindert, dass das Modell bei jedem weiteren erzeugten Token die gesamte Unterhaltung neu berechnen muss.
Mehr Nutzer und längere Kontexte vergrößern diesen Cache. Größere Kapazität ist jedoch nur wertvoll, wenn das System diese Nutzer innerhalb eines akzeptablen Latenzziels bedienen kann.
Batching verkompliziert das Bild. Durch die gemeinsame Verarbeitung mehrerer Anfragen kann ein Server einen Lesevorgang der Modellgewichte auf mehrere Nutzer verteilen.
Größere Batches verbessern den Gesamtdurchsatz, benötigen aber auch mehr KV-Cache-Kapazität. Hier können 8-hi- oder 12-hi-Stacks wieder einen Vorteil gewinnen.
Der Zielkonflikt ist Interaktivität. Ein Anbieter kann länger warten, um größere Batches zu bilden, oder Tokens mit kleineren Batches schnell zurückgeben.
SemiAnalysis modelliert diese Beziehung mit Kimi K3 auf einer künftigen Rubin-Ultra-NVL576-Konfiguration. Dabei zeigt sich, dass höhere Stacks mit steigender erforderlicher Geschwindigkeit pro Nutzer abnehmende Durchsatzgewinne liefern.
Bei modellierten 213 Tokens pro Sekunde für jeden Nutzer stellt der Bericht keinen Durchsatzvorteil über 4-hi hinaus fest. Die Bandbreitengrenze wird erreicht, bevor zusätzliche Speicherkapazität nutzbar wird.
An anderen Punkten der Kurve steigert 8-hi den maximalen Durchsatz um 8 Prozent. Eine 12-hi-Konfiguration erhöht ihn gegenüber 4-hi um 10 Prozent.
Diese Verbesserungen sind innerhalb des Modells real. Die Frage ist, ob sie die zusätzlichen Speicher- und Systemkosten ausgleichen.
SemiAnalysis schätzt, dass sein modelliertes 8-hi-Rubin-Ultra-System 12,1 Prozent mehr kostet als die 4-hi-Basis. Seine 12-hi-Konfiguration erhöht die Kosten um 26,3 Prozent.
Dabei handelt es sich um Analystenschätzungen auf Grundlage künftiger Komponenten und angenommener Speicherpreise. Es sind weder Herstellerangebote noch gemessene Betriebskosten eingesetzter Rubin-Ultra-Systeme.
Unter diesen Annahmen wächst der Durchsatz langsamer als die Systemkosten. Die daraus resultierenden Kosten pro Token sind bei beiden höheren Konfigurationen höher.
Dies ist die stärkste Aussage im SemiAnalysis-Fall für 4-hi-HBM. Kürzere Stapel senken nicht nur die Hardwarekosten; sie verbessern auch den modellierten Output pro ausgegebenem Betrag.
Rack-Scale-Computing macht das Argument plausibler. Frühere Server verbanden acht GPUs, sodass der Speicher jedes einzelnen Geräts das gesamte Serving-System stark begrenzte.
Ein H100-HGX-System stellte insgesamt 640GB HBM bereit. Große Modellgewichte konnten den Großteil dieser Kapazität belegen, bevor das System überhaupt nennenswerte KV-Caches speicherte.
Der H200 entschärfte diesen Druck, indem er jeder GPU mehr Speicher hinzufügte. In dieser Phase hatte eine höhere Kapazität pro Gerät unmittelbaren operativen Nutzen.
GB300 NVL72 verändert den Maßstab. Nvidia verbindet 72 Blackwell-Ultra-GPUs über NVLink und schafft damit eine deutlich größere gemeinsame Kommunikationsdomäne.
Das Rack verfügt über etwa 20TB GPU-Speicher. Seine Gesamtkapazität ist wesentlich höher als die eines Hopper-Servers mit acht GPUs.
SemiAnalysis vergleicht dieses Wachstum mit Kimi K3, einem Mixture-of-Experts-Modell mit 2,8 Billionen Parametern. Solche Modelle aktivieren für jedes Token nur einen Teil ihrer Experten.
Der Bericht schätzt, dass eine quantisierte Kimi-K3-Replik 1.561GB belegt. Das würde weniger als 8 Prozent einer rund 21TB großen GB300-NVL72-Konfiguration beanspruchen.
Quantisierung stellt Zahlen mit weniger Bits dar und reduziert dadurch Gewichtsspeicher und Speicherverkehr. Sie tauscht einen Teil der numerischen Präzision gegen deutlich geringere Hardwareanforderungen ein.
Große NVLink-Domänen verteilen Experten zudem auf mehr GPUs. Das Arrangement erhöht die Kommunikationsanforderungen, reduziert jedoch die Anzahl der Modellgewichte, die jedes Gerät vorhalten muss.
Rubin Ultra erweitert die Domäne Berichten zufolge von NVL72 auf NVL576. Dieser achtfache Anstieg verbundener GPUs kann eine Reduzierung des HBM pro Beschleuniger um ein Drittel überwiegen.
Kapazität entwickelt sich damit von einem Problem einzelner GPUs zu einem Problem der Rack-weiten Zuteilung. Eine Bereitstellung kann ein großes Modell vorhalten und zugleich schlankere lokale Speicherstapel verwenden.
Das beseitigt Speichergrenzen nicht. Es verändert, wo Architekten sie lösen und welche Ressource zuerst knapp wird.
Cache-Offloading hilft, aber 4-hi-HBM ist kein Selbstläufer
Die Strategie mit kurzen Stapeln funktioniert nur, wenn Software, Sekundärspeicher und das Verhalten der Workloads verhindern, dass die reduzierte HBM-Kapazität zum Engpass wird.
SemiAnalysis testete einen Teil dieser Annahme mit einem InferenceX-Workload unter Verwendung von Kimi K3 und 16 GB300-GPUs. Acht GPUs übernahmen Prefill, während acht Decode verarbeiteten.
Prefill verarbeitet den Prompt, bevor die Tokengenerierung beginnt. Die Trennung von Decode ermöglicht es Betreibern, jede Phase auf unterschiedliche Rechen- und Speichereigenschaften abzustimmen.
Das Experiment reduzierte die zulässige HBM-Auslastung von 92 Prozent auf 85 Prozent. Das ist deutlich weniger als die Kapazitätskürzung zwischen 8-hi- und 4-hi-Stapeln.
Dennoch verringerte das Limit den verfügbaren KV-Cache-Speicher erheblich. Laut Bericht sank die KV-Gesamtkapazität für Serving von 53GB auf 34GB pro GPU.
Bei entkoppelten Paaren fiel das verfügbare Budget von 44GB auf 24GB. Diese Änderungen entsprachen Reduzierungen um 36 Prozent beziehungsweise 44 Prozent.
Der Durchsatz blieb über die meisten getesteten Parallelitätsstufen hinweg ähnlich. Die eingeschränkte Konfiguration verlagerte inaktive KV-Cache-Daten in gewöhnlichen Server-DRAM.
Dieser Prozess wird KV-Cache-Offloading genannt. Dabei bleiben häufig abgerufene Informationen im HBM, während kältere Gesprächszustände in langsameren, größeren Speicher verschoben werden.
Agentische Workloads können für diesen Ansatz geeignet sein. Sie pausieren oft, während Tools laufen, CPUs Code ausführen oder externe Dienste Informationen zurückgeben.
Während dieser Pausen benötigt die GPU nicht sofort den Cache jeder Unterhaltung. Das Verschieben kälterer Daten kann teuren HBM für aktive Anfragen freigeben.
Der eingeschränkte Test stieß auf eine klare Grenze. Sobald die Parallelität 70 überstieg, sank der Durchsatz gegenüber der speicherreicheren Konfiguration um fast 30 Prozent.
Die GPU-KV-Auslastung hatte 100 Prozent erreicht. Preemption, wiederholte Transfers und Warteschlangen verringerten daraufhin die produktive Arbeit.
Der eingeschränkte Lauf verzeichnete zudem mehr als zehnmal so viele Lesevorgänge aus dem DRAM-basierten KV-Cache. Offloading minderte den Kapazitätsdruck, erhöhte jedoch den Verkehr über eine langsamere Ebene.
Dieses Ergebnis ist zugleich unterstützend und warnend. Es zeigt, dass Software die Leistung nach einer spürbaren Speicherreduzierung bewahren kann, jedoch nur unterhalb einer vom Workload abhängigen Schwelle.
Ein Produktionsdienst mit vielen gleichzeitigen Nutzern mit langem Kontext kann diese Schwelle überschreiten. In diesem Fall können höhere HBM-Stapel größere Batches und einen höheren Gesamtdurchsatz unterstützen.
Auch die Netzwerkkapazität ist relevant. Die Verteilung von Modellexperten und Caches über Hunderte Beschleuniger erzeugt intensive All-to-All-Kommunikation.
Ein System kann aufhören, durch Speicherkapazität begrenzt zu sein, und stattdessen netzwerkgebunden werden. Dieses Ergebnis lässt zwar weiterhin zusätzlichen HBM ungenutzt, garantiert jedoch keine effiziente Gesamtleistung.
Sekundärer DRAM stellt eine weitere Einschränkung dar. Serverspeicher erlebt eigenen Lieferdruck, da KI-Systeme die CPU-seitige Kapazität erhöhen.
Offloading verbraucht zudem Energie und erhöht die operative Komplexität. Die Software muss entscheiden, was hot bleibt, was verschoben wird und wann Daten zurückkehren müssen.
Schlechte Entscheidungen können Kapazitätseinsparungen in Latenzspitzen verwandeln. Die Architektur benötigt sorgfältige Planung, Cache-Verwaltung und Workload-Isolation.
Das künftige Modellwachstum stellt die größere Unsicherheit dar. SemiAnalysis räumt ein, dass seine Analyse einen gegenwärtigen Workload auf später erwartete Hardware anwendet.
KI-Server bleiben häufig länger als fünf Jahre im Einsatz. Modelle, Kontexte, Nutzerparallelität und Reasoning-Workloads können sich in diesem Zeitraum drastisch verändern.
Der Bericht unterzieht ein Modell mit der dreifachen Größe von Kimi K3 und dem dreifachen Cache-Bedarf pro Nutzer einem Stresstest. Unter dieser Annahme werden höhere Stapel nützlicher.
Seine 8-hi-Konfiguration liefert insgesamt 36 Prozent mehr Tokens als 4-hi. Die 12-hi-Version liefert 47 Prozent mehr, obwohl beide mit geringerer Geschwindigkeit pro Nutzer arbeiten.
Unter Einbeziehung der geschätzten Kosten wird 8-hi unterhalb von 180 Tokens pro Sekunde pro Nutzer vorteilhaft. Das 12-hi-System kann seinen modellierten Kostenanstieg weiterhin nicht ausgleichen.
Diese Ergebnisse zeigen, warum 4-hi-HBM keine universelle Empfehlung werden kann. Die bevorzugte Stapelhöhe hängt von Modellgröße, Latenzzielen, Batching und Systemlebensdauer ab.
Trainingssysteme bleiben ein besonders ungeeignetes Ziel für aggressive Kapazitätsreduzierungen. Ihre Aktivierungen, Gradienten und Optimizer-Zustände können den gesamten verfügbaren Speicher beanspruchen.
Inference-Systeme, die viele unabhängige Modelle bedienen, benötigen ebenfalls Kapazität. Betreiber könnten Flexibilität höher bewerten als die niedrigsten Kosten für einen optimierten einzelnen Workload.
Hardwarekäufer stehen vor einem Optionalitätsproblem. Ein 4-hi-Beschleuniger kann für den heutigen Dienst effizient sein, nach Veränderungen der Workloads jedoch einschränkend wirken.
Forscher könnten Modelle an die installierte Hardware anpassen. Schleifenberechnungen, Quantisierung, sparse Experten und kleinere Caches können die Abhängigkeit von gespeicherten Parametern verringern.
Diese Anpassung ist nicht garantiert. Verbesserungen der Modellqualität könnten erneut aus höheren Parameterzahlen oder speicherintensiven Architekturen hervorgehen.
Die beste Lesart ist daher enger gefasst. Vierlagiger HBM bietet eine starke Konfiguration für sorgfältig charakterisierte Inference, aber keinen automatischen Ersatz für höhere Speicherstapel.
Weniger Schichten erhöhen den Druck auf Speicherlieferanten und Systemhersteller
Wenn Käufer Bandbreite statt Gigabytes optimieren, verlagert sich der wirtschaftliche Druck von der DRAM-Produktion hin zu Base-Dies, Packaging, Netzwerken und vollständiger Systemintegration.
SK hynix, Samsung und Micron investieren seit Jahren in die Entwicklung dichterer und höherer HBM-Stapel. Ihre Roadmaps betonen Kapazität, Signalisierungsgeschwindigkeit, Packaging-Ausbeute und Wärmekontrolle.
SK hynix begann 2025 mit der Auslieferung von 12-lagigen HBM4-Mustern. Seine HBM4 announcement beschrieb 36GB-Pakete mit mehr als 2TB pro Sekunde Bandbreite.
Diese Produktausrichtung bleibt für Training und kapazitätsintensive Inference sinnvoll. Eine spürbare Verlagerung zu 4-hi würde eine ganz andere Beschaffungspriorität schaffen.
Kunden könnten bei weniger Core-Dies die volle Schnittstellenbandbreite verlangen. Lieferanten würden mehr Packages, jedoch weniger DRAM-Bits in jedem einzelnen ausliefern.
Auf den ersten Blick wirkt das negativ für die HBM-Umsätze. Anbieter haben davon profitiert, in jede Beschleunigergeneration mehr spezialisierte DRAM-Inhalte zu verkaufen.
SemiAnalysis argumentiert, dass das Ergebnis ausgewogener sein könnte. Kürzere Stapel könnten die Montageausbeute verbessern und die Zahl verkaufsfähiger Packages pro Wafer erhöhen.
Ein Lieferant könnte auch Bandbreitenwert bepreisen, statt HBM primär als Gigabyte-Produkt zu behandeln. Ob Kunden dieses Modell akzeptieren, bleibt ungewiss.
Der Versorgungsvorteil ist deutlicher. Der Wechsel von 12-hi zu 4-hi verdreifacht theoretisch die Zahl der aus einer festen DRAM-Menge verfügbaren Stapel-großen Die-Gruppen.
Der tatsächliche Anstieg kann das einfache Verhältnis übertreffen, wenn kürzere Stapel die Packaging-Ausbeute erhöhen. Er bleibt darunter, wenn andere Komponenten knapp werden.
Jedes HBM-Package benötigt weiterhin einen Base-Die, Tests, Stapelung und die Anbindung neben einem Beschleuniger. Die Vervielfachung des Package-Outputs erhöht die Nachfrage in all diesen Schritten.
HBM4 macht den Base-Die wichtiger, da er mehr Logik enthält und einen fortschrittlichen Foundry-Prozess nutzen kann. DRAM-Einsparungen schaffen keine entsprechende Foundry-Kapazität.
Mehr Speicherpackages benötigen auch mehr Beschleunigerpackages. Diese Packages erfordern Interposer, organische Substrate, Stromversorgung, Kühlung und hochdichte Montage.
Der Engpass kann sich daher verlagern, statt zu verschwinden. Logic-Wafer, Base-Dies, Substrate, Leiterplatten und Systemintegration würden allesamt einer höheren Nachfrage ausgesetzt sein.
Große Scale-up-Domänen verschärfen eine weitere Einschränkung. Mehr Beschleuniger erfordern umfangreiches Switching und Networking, bevor ihr aggregierter Speicher als praktisch nutzbare gemeinsame Ressource fungiert.
Nvidias GB300 NVL72 nutzt neun NVSwitch-Trays, um 72 GPUs zu verbinden. Sein NVLink-Gewebe der fünften Generation liefert 130TB pro Sekunde aggregierte Bandbreite.
Künftige NVL576-Systeme müssen diesen Maßstab erheblich erweitern. Ihre Wirtschaftlichkeit hängt davon ab, dass das Netzwerk schnell genug bleibt, um verteilte Experten und Cache-Bewegungen zu unterstützen.
Strom bleibt die letzte Grenze. Eine Verdopplung der Anzahl bandbreitenstarker HBM-Packages hilft nur, wenn Betreiber die daran angeschlossenen Beschleuniger auch einsetzen können.
Eine 4-hi-Strategie kann das DRAM-Angebot strecken, ohne neue elektrische Kapazität zu schaffen. Rechenzentrumsbau, Kühlung und Netzzugang bestimmen weiterhin die nutzbare Rechenleistung.
Dieser Druck erklärt, warum Tokens pro HBM-Wafer eine hilfreiche, aber keine vollständige Kennzahl sind. Betreiber müssen Tokens pro Watt, Rack, Netzwerkport und Kapitalbudget gemeinsam optimieren.
Die Änderung würde auch konventionelle Speichermärkte beeinflussen. Die HBM-Produktion konkurriert mit Server-, PC- und Mobile-DRAM um Fertigungsressourcen.
Die Nutzung weniger HBM-Core-Dies kann etwas Waferkapazität für diese Produkte zurückgeben. Diese Entlastung ist relevant, da CPU-seitiger Speicher parallel zu agentischen KI-Bereitstellungen wächst.
Der Vorteil hängt jedoch von der tatsächlichen Einführung ab. Ein 4-hi-Design, das wesentlich mehr Beschleuniger-Auslieferungen ermöglicht, könnte einen Teil der Einsparungen durch ein höheres Gesamtstückvolumen aufbrauchen.
Speicherlieferanten könnten sich auch gegen eine schnelle Verschiebung wehren, wenn sie die Bitnachfrage schwächt. Ihre Reaktion wird sich in Produktverfügbarkeit, Qualifizierungsplänen und Kapazitätszuteilung zeigen.
Der Hauptwettbewerb lautet daher nicht Nvidia gegen einen einzelnen Speicheranbieter. Es geht um bandbreitenorientiertes Inferenzdesign gegen kapazitätsorientierte HBM-Ökonomie.
Diese Gegenüberstellung macht die Folgen für die Branche deutlich. Niedrige Stacks gewinnen, wenn Bandbreite Umsatz schafft und installierte Gigabytes dies nicht tun.
Höhere Stacks gewinnen, wenn Kunden zusätzliche Kapazität in größere Batches, mehr Modelle oder langfristigere Hardwareflexibilität umsetzen können.
Drei Signale werden zeigen, ob 4-hi HBM wirklich gewinnt
Die These der niedrigen Stacks wird erst glaubwürdig, wenn Produkt-Roadmaps, Produktionsverfügbarkeit und gemessene Inferenzergebnisse zusammenlaufen.
Das erste Signal ist Nvidias finale Rubin-Ultra-Konfiguration. Öffentliche Dokumentation muss Speicherkapazität, Stack-Höhe, Bandbreite und die NVL576-Systemarchitektur bestätigen.
Eine bestätigte 192GB-Konfiguration mit 8-hi HBM würde das Richtungsargument stützen. Eine Rückkehr zu 12-hi würde Behauptungen schwächen, dass sich die Kapazitätsanforderungen allgemein entspannt haben.
Ein kommerzielles 4-hi-Rubin-Produkt wäre ein wesentlich stärkerer Beleg. Bis dahin bleibt der SemiAnalysis-Vorschlag zu 4-hi HBM eine fundierte Prognose über künftige ASICs und Beschleuniger.
Das zweite Signal ist die Lieferantenqualifizierung von schnellem 4-hi HBM4 oder HBM4E. Anbieter müssen diese Packages mit den von Beschleunigerentwicklern benötigten Signalisierungsraten liefern.
Die nominelle Schnittstellenbreite allein reicht nicht aus. Produkte benötigen akzeptable Ausbeuten, Thermik, Zuverlässigkeit und nachhaltige Leistung in vollständigen Systemen.
Beobachten Sie, ob SK hynix, Samsung oder Micron 4-hi-Konfigurationen in öffentliche Roadmaps aufnehmen. Kunden-Sampling würde zeigen, dass niedrige Stacks über interne Architekturstudien hinausgekommen sind.
Beobachten Sie auch das Preismodell. Wenn die Kosten für 4-hi vor allem mit seiner geringeren Kapazität skalieren, wird seine Bandbreitenökonomie überzeugend.
Wenn Lieferanten den Großteil des Werts dem Base Die und der Schnittstelle zurechnen, könnten die erwarteten Einsparungen geringer ausfallen. Package-Engpässe könnten trotz geringeren DRAM-Inhalts ebenfalls hohe Aufschläge erhalten.
Das dritte Signal sind unabhängige Inferenztests über unterschiedliche Workloads hinweg. Benchmarks müssen interaktive Assistenten, agentische Dienste, Anfragen mit langem Kontext und Deployments mit großen Batches umfassen.
Der durchschnittliche Token-Durchsatz wird nicht ausreichen. Tests benötigen Geschwindigkeit pro Nutzer, Queueing-Verhalten, Cache-Trefferraten, Offload-Traffic und Tail-Latenz.
Die Ergebnisse sollten zudem Modelle unterschiedlicher Größe und Architektur vergleichen. Eine für Kimi K3 optimierte Konfiguration kann nicht die beste Wahl für jedes künftige Frontier-Modell belegen.
Der entscheidende Nachweis wird ein stabiler Kostenvorteil pro Token unter realistischen Service-Level-Zielen sein. Dieser Vorteil muss auch bei hoher Parallelität und wechselnden Workload-Mischungen bestehen bleiben.
Entwickler sollten sich dafür interessieren, weil Hardwarebeschränkungen das Modelldesign prägen. Verfügbarer Speicher beeinflusst Quantisierung, Expert-Platzierung, Kontextverarbeitung und Cache-Richtlinien.
Unternehmenskäufer sollten sich dafür interessieren, weil Schlagzeilenkapazität irreführend sein kann. Mehr HBM garantiert keine nützlichere Inferenz, wenn Bandbreite, Netzwerk oder Latenz die Grenze setzen.
Infrastrukturteams sollten Working Sets auf Rack-Ebene bewerten. Sie sollten Training, Prefill, Decode und agentische Workloads voneinander trennen, bevor sie sich für ein Speicherprofil entscheiden.
Sie sollten zudem operative Reserven vorhalten. Ein eng auf 4-hi optimiertes System kann seinen Vorteil verlieren, wenn sich die Nachfrage zu größeren Batches oder mehr gleichzeitig ausgeführten Modellen verschiebt.
Die übergeordnete Lehre lautet nicht, dass weniger Speicher immer gewinnt. Speicher sollte vielmehr nach der Ressource beschafft werden, die ein Workload tatsächlich verbraucht.
Für interaktive Inferenz ist diese Ressource oft Bandbreite. Vierlagiges HBM kann den vollständigen externen Datenpfad beibehalten und zugleich weniger knappe DRAM-Dies verwenden.
Damit stellt die SemiAnalysis-Analyse zu 4-hi HBM die Annahmen der Branche zugunsten höchstmöglicher Stacks ernsthaft infrage. Die nächsten Produktveröffentlichungen werden zeigen, ob Hardwareteams dem zustimmen.
Bevor Sie sich auf eine künftige Beschleunigerflotte festlegen, stellen Sie drei Fragen. Passt das Working Set auf Rack-Ebene, können kalte Cache-Daten sicher verschoben werden, und steigert zusätzliche Kapazität den nutzbaren Durchsatz?
Wenn die Antworten auf Bandbreite hindeuten, verdient der kurze König einen Platz auf der Roadmap.
