Los errores de datos silenciosos, o corrupción silenciosa de datos (Silent Data Errors/Silent Data Corruption), revelan una brecha creciente entre que un chip supere las pruebas de fabricación tradicionales y su capacidad para producir resultados correctos durante todo su periodo de funcionamiento. Un procesador puede superar las pruebas ATPG, las pruebas de fallos de transición y de fallos atascados, así como las pruebas estructurales a velocidad, y luego ejecutar una operación matemática de forma incorrecta sin registrar un fallo evidente, antes de que el resultado corrupto llegue a una aplicación o a una tarea de entrenamiento de inteligencia artificial.
Este análisis se basa en un estudio publicado por Semiconductor Engineering el 10 de septiembre de 2026, que reúne opiniones y resultados de Advantest, Siemens EDA, NXP, Synopsys, Intel, Meta, Google y proteanTecs. No se trata del lanzamiento de un producto concreto, sino de un cambio en la forma de definir la calidad de un procesador, probar su cobertura y gestionarlo después de su llegada al centro de datos.
Un problema raro a nivel del chip, pero extendido a nivel de la flota
Los errores de datos silenciosos parecen raros cuando se miden en un dispositivo individual, pero se vuelven frecuentes y costosos cuando funcionan millones de procesadores con altos niveles de utilización. Los primeros análisis de Google y Meta indican que estos errores pueden afectar a uno de cada mil servidores, lo que equivale a un nivel de entre 100 y 1.000 partes defectuosas por millón. Incluso una tasa de 10 FIT, es decir, un fallo por cada mil millones de horas de funcionamiento, puede significar que se produzca un error aproximadamente cada cuatro días al desplegar 10 millones de dispositivos.
El peligro reside en que el error puede aparecer en forma de un resultado numérico incorrecto o de un valor no definido, y luego provocar la corrupción de bases de datos, un comportamiento inesperado de un modelo de inteligencia artificial o resultados analíticos contradictorios. Como el propio procesador puede no enviar una señal de error, el fallo quizá no se detecte hasta que aparezca un resultado ilógico al final de una tarea larga.
¿Por qué fallan las pruebas tradicionales?
Los errores silenciosos están relacionados con defectos marginales, como interconexiones metálicas de alta resistencia, defectos de puentes débiles y variaciones de temporización y voltaje, además de los efectos del envejecimiento, la radiación y las condiciones de temperatura y carga. Sus probabilidades aumentan con los nodos de fabricación avanzados, donde los márgenes se estrechan y las interconexiones son más pequeñas y resistentes; asimismo, los encapsulados basados en chiplets incrementan la complejidad de las rutas de verificación.
La industria estima que alrededor del 80% de los errores de ejecución corrupta están relacionados con defectos que escapan a las pruebas de tiempo cero, mientras que el 20% restante aparece de forma intermitente o como consecuencia del envejecimiento. Sin embargo, probar todas las combinaciones posibles de voltaje, frecuencia, temperatura, antigüedad y tipo de carga no es práctico. Además, vincular un fallo que aparece a nivel del sistema con un patrón de defecto específico en la prueba del chip puede tardar semanas y requerir la colaboración de equipos de diseño, pruebas, análisis de fallos e integración de sistemas.
Siemens EDA señala que depender de una sola transición de entrada al probar fallos de retardo puede no simular el funcionamiento funcional real, ya que la transición de múltiples entradas puede producir retardos mayores. Por ello, las pruebas deben dirigirse a múltiples combinaciones de voltaje, temperatura y frecuencia, en lugar de limitarse a modelos de fallos estructurales que no cubren todas las condiciones de uso.
Pruebas más profundas, de la fábrica al centro de datos
Este problema redefine el concepto de cobertura de las pruebas. En lugar de contabilizar el porcentaje de defectos de fabricación conocidos que la prueba puede detectar, la cobertura también pasa a estar relacionada con la probabilidad de descubrir una respuesta computacional incorrecta durante un funcionamiento real y con una carga efectiva. Por eso, las empresas avanzan hacia pruebas funcionales a nivel del sistema, pruebas conscientes de la carga y pruebas en modo de tarea, además de mejorar el diseño de las pruebas integradas y supervisar los márgenes dentro del chip.
La experiencia de Intel muestra la magnitud del desafío. Después de probar 1,2 millones de procesadores a lo largo de cinco generaciones de procesadores Intel Xeon, la empresa necesitó más de 1.000 pruebas funcionales en el conjunto DCDiag y 5.000 pruebas de estrés sintéticas para detectar defectos de errores silenciosos. Las pruebas no estaban distribuidas por igual entre los defectos: aproximadamente el 50% de las piezas defectuosas podía detectarse utilizando solo el 5% de las pruebas, mientras que detectar el 90% de los errores requería más de la mitad de las 1.000 pruebas. Los resultados también mostraron que más del 70% de los defectos solo era detectado por una única prueba y que la receta de pruebas eficaz para una generación de productos no podía trasladarse directamente a la siguiente.
¿Qué cambia en la práctica en las flotas?
La respuesta no se detiene en la puerta de la fábrica. Las empresas que operan centros de datos utilizan capas de inspección mediante software y pruebas de campo para aislar los servidores o núcleos que muestran un comportamiento anómalo. En Meta, el programa Fleetscanner retira el servidor del servicio y lo somete a pruebas computacionales con resultados conocidos, mientras que el programa Ripple ejecuta patrones breves durante el funcionamiento normal. Por su parte, Hardware Sentinel analiza las excepciones de las aplicaciones y el comportamiento del sistema sin asignar cargas de prueba; Meta afirmó que mejoró la detección en un 40% frente a los métodos basados en pruebas en diferentes arquitecturas, aplicaciones y centros de datos.
Google utiliza un conjunto de medidas de protección que incluye la verificación de los conjuntos de pruebas de extremo a extremo, cálculos redundantes y su comparación, comprobaciones de invariantes y aserciones, verificación de los datos durante su transferencia y verificación periódica de los datos almacenados. La medición de las aplicaciones, como el método Spanner, también puede detectar la corrupción y retirar del conjunto los dispositivos sospechosos, mientras que los métodos de inspección se ajustan cuando los dispositivos regresan para identificar los núcleos susceptibles al problema antes de que este se agrave.
De las pruebas previas al envío a la gestión del ciclo de vida del silicio
Estas tendencias impulsan la supervisión continua de los márgenes de temporización, voltaje, temperatura y degradación, así como el uso del análisis de series temporales y del aprendizaje automático para detectar desviaciones antes de que se conviertan en un error silencioso. Las mediciones paramétricas y los modelos de aprendizaje automático pueden ayudar a aislar los dispositivos que se desvían de su perfil esperado, mientras que las pruebas variadas de instrucciones, la ejecución redundante y la comparación entre núcleos pueden aumentar las posibilidades de detección.
Sin embargo, este enfoque no elimina las limitaciones. No existe un único método capaz de captar todos los mecanismos de error, los resultados de las pruebas no se transfieren automáticamente de un diseño a otro y el diagnóstico de la causa raíz sigue siendo difícil cuando el efecto aparece en la aplicación, lejos del defecto físico. El análisis también señala que el intercambio de datos sobre fallos entre fabricantes, proveedores de herramientas de prueba, operadores de centros de datos y universidades sigue siendo limitado debido a consideraciones comerciales y legales. Por tanto, el cambio real no consiste en añadir una prueba aislada, sino en construir una cadena de visibilidad que se extienda desde la fabricación hasta la operación, reconociendo que la calidad del procesador no queda completamente determinada en el momento de su envío.