KI-Systeme verlangsamen sich in der Regel nicht wegen mangelnder Rechenleistung, sondern weil das System Daten nicht schnell genug bewegen kann, um den Prozessor konstant mit Informationen zu versorgen.

Mit anderen Worten: Der Engpass liegt nicht in der Fähigkeit, Daten zu verarbeiten, sondern darin, diese Daten mit der Geschwindigkeit bereitzustellen, die moderne KI-Workloads erfordern.

Genau hier wird High Bandwidth Memory (HBM) zu einem wichtigen Bestandteil der Architektur.

Für einen umfassenderen Blick darauf, wie sich Speicher über Flash hinaus entwickelt und warum KI-Systeme heute auf mehrere Ebenen angewiesen sind, siehe unsere Hauptanalyse: NAND wird nicht verschwinden, aber KI-Server sind inzwischen auf mehr als nur Flash angewiesen.

Seit mehr als zwei Jahrzehnten beobachtet GetUSB, wie sich Daten tatsächlich bewegen – nicht nur, wie sie vermarktet werden. In dieser Zeit haben wir mehrere Evolutionszyklen im Storage-Bereich erlebt: vom Rückgang mechanischer Festplatten über den Aufstieg von Flash bis hin zu heutigen Systemen, in denen Storage nicht mehr nur ein passiver Bestandteil ist, sondern ein aktiver Teil der gesamten Infrastruktur geworden ist.

Was aktuell im Bereich der KI-Infrastruktur passiert, fühlt sich wieder wie so ein Wendepunkt an – allerdings mit einer anderen Art von Druck, der diese Entwicklung antreibt.

NAND-Flash verschwindet nicht, darüber gibt es eigentlich keine Diskussion. Es ist weiterhin das Fundament moderner Speicherlösungen und erfüllt diese Aufgabe nach wie vor sehr gut. Gleichzeitig steigt die Nachfrage nach NAND rapide an – vor allem durch KI-Workloads, die enorme Datenmengen benötigen und ständig darauf zugreifen müssen. Diese Nachfrage beginnt spürbar gegen die verfügbare Versorgung zu drücken, sei es durch steigende Preise, strengere Zuteilungen oder schlicht längere Lieferzeiten bei großen Deployments.

Sobald solche Ungleichgewichte sichtbar werden, wartet die Branche nicht einfach ab, bis sich alles wieder normalisiert. Sie sucht nach alternativen Lösungen – und genau an diesem Punkt beginnt sich etwas zu verschieben.

Es gibt diesen Moment, den fast jeder schon mal hatte, auch wenn man nicht groß darüber nachdenkt. Du steckst einen USB-Stick ein, kopierst ein paar Dateien, und irgendwie fühlt sich das Ganze komisch an. Nichts ist kaputt, nichts ist tot, technisch funktioniert alles, aber es hakt so ein bisschen. Vielleicht bricht die Geschwindigkeit plötzlich ein, vielleicht verliert er kurz die Verbindung und kommt wieder, vielleicht wird er wärmer als erwartet. Und dann nimmst du am nächsten Tag einen anderen Stick – gleiche Kapazität, ähnliches Design, vielleicht sogar aus derselben Produktfamilie – und der läuft einfach sauber durch. Keine Aussetzer, kein Drama. Einfach stabil.

Das Spannende daran: Unter der Haube sind diese beiden Sticks oft viel ähnlicher, als man denkt. In vielen Fällen steckt exakt die gleiche Controller-Familie drin und der gleiche NAND-Flash-Typ. Auf dem Papier also praktisch identisch. In der Praxis wirken sie aber wie komplett unterschiedliche Produkte.

Die meisten Leute kaufen einen USB-Stick so wie einen Pack Stifte — billig nehmen, davon ausgehen, dass eh alle gleich funktionieren, und fertig.

Und fairerweise: Für einfachen Datentransfer ist das auch nicht komplett falsch.

Aber wenn du schon mal Probleme mit Datenintegrität hattest, schwankende Performance erlebt hast oder versucht hast, etwas Fortgeschritteneres zu machen wie Schreibschutz oder kontrollierte Verteilung, dann hast du wahrscheinlich gemerkt: USB-Sticks sind eben nicht alle gleich.

Der Unterschied liegt nicht im Plastikgehäuse. Nicht mal im NAND-Speicher.

Es ist der Controller — genauer gesagt, wie dieser Controller im Gerät umgesetzt ist.

Alle paar Monate passiert es wieder.

Jemand kommt in die IT, hält eine microSD-Karte hoch und fragt ganz nüchtern: „Können wir die CID auf der Karte einfach ändern?“

Der ITler schaut auf die Karte. Dann auf die Person. Atmet einmal tief durch.

Die Frage ist nicht falsch. Sie basiert nur auf einer Annahme, die mit der tatsächlichen Hardware-Architektur nicht viel zu tun hat.

Der Unterschied zwischen Firmware-Identität und Software-Simulation

Früher oder später stellt sich fast jeder, der mit USB-Speichermedien arbeitet, dieselbe Frage: Kann ich einen USB-Stick als CD-ROM-Laufwerk erscheinen lassen?

Diese Frage taucht meist dann auf, wenn etwas automatisch starten soll, wie ein Software-Installer funktionieren oder in einer Umgebung mit eingeschränktem USB-Verhalten eingesetzt werden soll. Viele vermuten, es handle sich um eine Windows-Einstellung, eine spezielle Datei oder einen versteckten Trick im Geräte-Manager.

Hier liegt jedoch das grundlegende Missverständnis: Es ist kein Betriebssystem-Trick. Es ist kein Datei-Trick. Und es ist nichts, was man einfach in den Eigenschaften umschaltet.

Es ist eine Geräteidentität, die direkt im USB-Gerät selbst definiert wird.

Micron hat kürzlich die erste PCIe-6.0-SSD vorgestellt – die Micron 9650 – mit sequenziellen Leseraten von bis zu 28 GB/s und Schreibgeschwindigkeiten von über 14 GB/s. Das ist kein kleines Upgrade. Das ist ein architektonischer Sprung.

Auf dem Papier verdoppelt PCIe 6.0 die Bandbreite von PCIe 5.0. Zufällige Lesezugriffe bewegen sich im Millionen-IOPS-Bereich. Für KI-Rechenzentren, die GPUs mit riesigen Trainingsdatensätzen versorgen, ist das kein Marketing-Buzzword. Es bedeutet weniger Leerlaufzeiten, geringere Latenz und eine bessere Auslastung extrem teurer Hardware.

Also, was ist H-Testing für USB-Laufwerke eigentlich?

Ich bin bei einer Weinverkostung. Von der Sorte, bei der eigentlich niemand wirklich etwas verkostet. Alle halten ein Glas, nicken höflich und versuchen auszusehen, als gehörten sie in diesen Raum.

Ich stoße auf einen Tech-Mogul. Große CEO-Ausstrahlung. Kennt Märkte, Bewertungen und Vorstandsetagen — aber keine Flash-Controller.

Irgendwo zwischen dem Pinot Noir und dem, was jemand unbedingt als „sehr exklusiv“ bezeichnet, sagt er:

„Wir hatten einmal ein Problem mit gefälschten USB-Sticks. Jemand erwähnte H-Testing. Was ist das genau?“

An dieser Stelle geraten die meisten Erklärungen aus dem Ruder. Entweder wird es überhöht, als wäre es eine Art Sicherheitszertifizierung, oder heruntergespielt, als wäre es nur ein schnelles Formatieren.

Warum mehrfache DoD-Überschreibverfahren trotz weiter Verbreitung nicht auf Flash-Speicher übertragbar sind

Lange Zeit bedeutete sicheres Löschen vor allem eines: Daten überschreiben. Dann noch einmal überschreiben. Und vielleicht ein drittes Mal, um auf Nummer sicher zu gehen. Dieser Ansatz funktionierte, war messbar und passte gut zu den Richtlinien des US-Verteidigungsministeriums aus den späten 1990er-Jahren.

Das war früher richtig. Heute ist es das nicht mehr. Tun wir nicht länger so, als hätte sich nichts geändert.