Stille Datenfehler oder stille Datenkorruption (Silent Data Errors/Silent Data Corruption) offenbaren eine wachsende Lücke zwischen dem Bestehen herkömmlicher Fertigungstests durch einen Chip und seiner Fähigkeit, während der gesamten Betriebsdauer korrekte Ergebnisse zu erzeugen. Ein Prozessor kann ATPG-Tests sowie Tests auf Übergangsfehler, stuck-at-Fehler und strukturelle Fehler bei Betriebsgeschwindigkeit bestehen und anschließend eine Berechnung falsch ausführen, ohne einen eindeutigen Fehler zu protokollieren, bevor das verfälschte Ergebnis an eine Anwendung oder einen Trainingsauftrag für künstliche Intelligenz weitergegeben wird.
Diese Einschätzung stützt sich auf eine am 10. September 2026 von Semiconductor Engineering veröffentlichte Analyse, die Einschätzungen und Ergebnisse von Advantest, Siemens EDA, NXP, Synopsys, Intel, Meta, Google und proteanTecs zusammenführt. Es geht nicht um die Einführung eines bestimmten Produkts, sondern um einen Wandel in der Definition der Prozessorqualität, der Prüfung ihrer Testabdeckung und ihrer Verwaltung nach dem Eintreffen im Rechenzentrum.
Ein seltenes Problem auf Chipebene, ein weitreichendes Problem auf Flottenebene
Stille Datenfehler wirken bei der Messung an einem einzelnen Gerät selten, werden jedoch häufig und kostspielig, wenn Millionen von Prozessoren mit hoher Auslastung betrieben werden. Frühe Analysen von Google und Meta deuten darauf hin, dass solche Fehler einen von tausend Servern betreffen können, was einem Niveau von 100 bis 1.000 fehlerhaften Teilen pro Million entspricht. Selbst eine Rate von 10 FIT, also einem Fehler pro einer Milliarde Betriebsstunden, kann bei der Bereitstellung von 10 Millionen Geräten ungefähr alle vier Tage einen Fehler bedeuten.
Die Gefahr besteht darin, dass der Fehler als falsches numerisches Ergebnis oder als nicht definierter Wert auftreten und anschließend Datenbanken beschädigen oder ein unerwartetes Verhalten eines KI-Modells oder widersprüchliche Analyseergebnisse verursachen kann. Da der Prozessor selbst möglicherweise kein Fehlersignal sendet, wird die Störung unter Umständen erst entdeckt, wenn am Ende eines langen Auftrags ein unplausibles Ergebnis erscheint.
Warum versagen herkömmliche Tests?
Stille Fehler stehen mit marginalen Defekten wie Metallverbindungen mit hohem Widerstand, schwachen Brückenfehlern sowie Änderungen von Timing und Spannung in Verbindung; hinzu kommen Alterungs- und Strahlungseffekte sowie Temperatur- und Lastbedingungen. Ihre Wahrscheinlichkeit steigt bei fortgeschrittenen Fertigungsknoten, bei denen die Margen schrumpfen und die Verbindungen kleiner und widerstandsbehafteter werden. Außerdem erhöhen auf Chiplets basierende Gehäuse die Komplexität der Prüfpfade.
Die Industrie schätzt, dass etwa 80 % der fehlerhaften Ausführungsergebnisse mit Defekten verbunden sind, die Zero-Time-Tests entgehen, während die verbleibenden 20 % sporadisch oder infolge der Alterung auftreten. Alle möglichen Kombinationen aus Spannung, Frequenz, Temperatur, Alter und Lasttyp zu testen, ist jedoch nicht praktikabel. Zudem kann es Wochen dauern, einen auf Systemebene aufgetretenen Fehler mit einem bestimmten Fehlermuster im Chiptest zu verknüpfen; dafür ist die Zusammenarbeit von Teams aus Design, Test, Fehleranalyse und Systemintegration erforderlich.
Siemens EDA weist darauf hin, dass die Verwendung eines einzelnen Eingangssignals beim Testen von Verzögerungsfehlern den tatsächlichen funktionalen Betrieb möglicherweise nicht abbildet, da das Umschalten mehrerer Eingänge größere Verzögerungen erzeugen kann. Daher müssen Tests mehrere Spannungs-, Temperatur- und Frequenzbereiche abdecken, anstatt sich auf strukturelle Fehlermodelle zu beschränken, die nicht alle Nutzungsbedingungen abdecken.
Tiefere Tests – von der Fabrik bis zum Rechenzentrum
Dieses Problem definiert das Konzept der Testabdeckung neu. Statt lediglich den Anteil bekannter Fertigungsfehler zu berechnen, die ein Test erkennen kann, wird die Abdeckung auch mit der Wahrscheinlichkeit verknüpft, ein falsches Rechenergebnis während eines realen Betriebs unter tatsächlicher Last zu entdecken. Deshalb wenden sich Unternehmen Funktionstests auf Systemebene, lastbewussten Tests und aufgabenbezogenen Tests zu, ergänzt durch eine verbesserte Entwicklung eingebetteter Tests und die Überwachung der Margen innerhalb des Chips.
Die Erfahrung von Intel verdeutlicht das Ausmaß der Herausforderung. Nach dem Test von 1,2 Millionen Prozessoren über fünf Generationen von Intel-Xeon-Prozessoren hinweg benötigte das Unternehmen mehr als 1.000 Funktionstests in der DCDiag-Suite sowie 5.000 synthetische Stresstests, um Defekte stiller Fehler zu erkennen. Die Tests waren nicht gleichmäßig auf die Defekte verteilt: Rund 50 % der fehlerhaften Teile konnten mit nur 5 % der Tests erkannt werden, während die Erkennung von 90 % der Fehler mehr als die Hälfte der 1.000 Tests erforderte. Die Ergebnisse zeigten außerdem, dass mehr als 70 % der Defekte nur von einem einzigen Test erkannt wurden und dass das wirksame Testrezept einer Produktgeneration nicht unmittelbar auf die nächste Generation übertragbar war.
Was ändert sich in der Praxis in den Flotten?
Die Reaktion beschränkt sich nicht auf das Werkstor. Betreiber von Rechenzentren setzen mehrere Ebenen aus Softwareprüfungen und Tests im Feld ein, um Server oder Kerne mit ungewöhnlichem Verhalten zu isolieren. Bei Meta nimmt das Programm Fleetscanner den Server außer Betrieb und führt ihn durch Rechentests mit bekannten Ergebnissen, während das Programm Ripple während des normalen Betriebs kurze Muster ausführt. Hardware Sentinel analysiert dagegen Anwendungsausnahmen und das Systemverhalten, ohne Testlasten zuzuweisen. Meta gab an, dass dadurch die Erkennung im Vergleich zu testbasierten Methoden über verschiedene Architekturen, Anwendungen und Rechenzentren hinweg um 40 % verbessert wurde.
Google verwendet eine Reihe von Schutzmaßnahmen, darunter die Ende-zu-Ende-Validierung von Testsätzen, doppelte Berechnungen und deren Vergleich, Prüfungen von Invarianten und Zusicherungen, die Überprüfung von Daten während ihrer Übertragung sowie die regelmäßige Überprüfung gespeicherter Daten. Auch die Messung von Anwendungen, etwa mit dem Spanner-Ansatz, kann Korruption erkennen und verdächtige Geräte aus der Flotte entfernen. Bei der Rückkehr der Geräte werden Prüfmethoden angepasst, um gefährdete Kerne zu bestimmen, bevor sich das Problem verschärft.
Vom Versandtest zur Verwaltung des gesamten Siliziumlebenszyklus
Diese Entwicklungen treiben die kontinuierliche Überwachung von Timing-, Spannungs-, Temperatur- und Alterungsmargen sowie den Einsatz von Zeitreihenanalysen und maschinellem Lernen voran, um Abweichungen zu erkennen, bevor sie sich in einen stillen Fehler verwandeln. Parametrische Messungen und Modelle des maschinellen Lernens können dabei helfen, Geräte zu isolieren, die von ihrem erwarteten Profil abweichen. Unterschiedliche Befehlstests, redundante Ausführung und Vergleiche zwischen Kernen können die Erkennungschancen ebenfalls erhöhen.
Dieser Ansatz beseitigt die Einschränkungen jedoch nicht. Es gibt keine einzelne Methode, die alle Fehlermechanismen erfasst, und Testergebnisse lassen sich nicht automatisch von einem Design auf ein anderes übertragen. Auch die Ursachenanalyse bleibt schwierig, wenn die Auswirkung in einer Anwendung weit entfernt vom physischen Defekt auftritt. Die Analyse weist außerdem darauf hin, dass der Austausch von Fehlerdaten zwischen Herstellern, Anbietern von Testwerkzeugen, Rechenzentrumsbetreibern und Universitäten aufgrund geschäftlicher und rechtlicher Erwägungen weiterhin begrenzt ist. Die tatsächliche Veränderung besteht daher nicht im Hinzufügen eines einzelnen Tests, sondern im Aufbau einer durchgängigen Beobachtungskette von der Fertigung bis zum Betrieb – verbunden mit der Erkenntnis, dass die Qualität eines Prozessors nicht vollständig in dem Moment entschieden wird, in dem er versandt wird.