Estados de una máquina. La fluctuación que llamamos estabilidad

Una memoria DRAM moderna sufre errores corregibles (cambios espontáneos de bits en la memoria) mucho más a menudo de lo que la industria suponía, según el estudio de campo de Schroeder, Pinheiro y Weber publicado por Google en 2009. Una máquina no se cansa, pero falla. Calienta, pierde precisión, sufre desfase de reloj, acumula errores. Decir que es estable porque «no tiene emociones» es ignorar que tiene su propia variabilidad, solo que no la llamamos así. Comparar humano-cansado con IA-en-uso intensivo es ya comparar dos sistemas con estados, no uno con estado y otro sin él.

El axioma que nadie verifica

La afirmación se repite con la cadencia del axioma. Las máquinas son consistentes y los humanos no. No se cansan, no tienen mal día, no se distraen, no necesitan dormir, no se pelean con la pareja antes de ir a la oficina. Por eso, dicen, conviene poner máquinas donde la consistencia importa.

La frase tiene el aire de lo obvio.

Y como casi todo lo que tiene el aire de lo obvio, no resiste media hora de inspección técnica.

El silicio que cambia de bit sin que nadie lo toque

Empecemos por la memoria. Schroeder, Pinheiro y Weber publicaron en 2009 un estudio de campo sobre la flota de Google, decenas de miles de máquinas durante dos años y medio, y encontraron tasas de errores en memoria mucho más altas de lo que la industria venía asumiendo. Órdenes de magnitud por encima del rango que los fabricantes daban como referencia. Una DIMM individual (módulo físico de memoria) sufría miles de errores corregibles al año en una fracción no trivial de los equipos.

Errores corregibles significa bits que cambian solos, en la memoria, sin que nadie los toque. El ECC (Error-Correcting Code, código de corrección de errores) los repara sobre la marcha y el sistema operativo no se entera. Cuando ECC falla, lo que cae es la máquina. Cuando ECC funciona, lo que tienes es una máquina aparentemente consistente que en realidad está corrigiendo basura constantemente.

Sridharan y Liberty refinaron la imagen tres años después en SC12. La mayoría de los errores no son aleatorios, sino concentrados. Hay módulos que fallan poco y módulos que fallan mucho, y los que fallan mucho fallan en sitios específicos. Una celda concreta, una fila concreta, un banco concreto. La máquina envejece, pero envejece desigualmente, como un coche al que se le va gastando un disco de freno antes que el otro. Esto no aparece en la ficha técnica. Aparece después, en producción, cuando alguien tiene cien mil servidores durante varios años y se molesta en mirar.

La temperatura manda

Cualquier procesador moderno tiene un mecanismo de protección térmica que se llama throttling (estrangulamiento de frecuencia: el chip baja automáticamente su velocidad cuando se calienta demasiado). Cuando el silicio supera cierta temperatura, el chip reduce su frecuencia para no quemarse.

Eso significa, en cristiano, que la misma máquina haciendo la misma tarea va a tardar más o menos según cómo de caliente esté la sala, cómo de bien ventilada esté la caja, cómo de cargado de polvo esté el ventilador. Un servidor en agosto a las tres de la tarde rinde menos que el mismo servidor en febrero a las cuatro de la mañana. La diferencia es medible, está documentada en las hojas de NVIDIA, AMD e Intel, y los ingenieros de fiabilidad la conocen perfectamente.

Pero el discurso público sobre la consistencia de las máquinas funciona como si esa variabilidad no existiera. O como si fuera tan pequeña que da igual mencionarla.

No es pequeña. Una GPU entrenando un modelo grande puede perder rendimiento sostenido de forma apreciable por estrangulamiento térmico si la refrigeración no acompaña. En cargas de inferencia con picos, la latencia varía mucho más. Un usuario que pide al mismo modelo la misma pregunta dos veces en horas distintas no va a recibir la respuesta en el mismo tiempo. A veces ni siquiera va a recibir la misma respuesta.

El software también fluctúa

Los modelos de lenguaje no son funciones puras. Cuando un LLM (Large Language Model, modelo de lenguaje grande) produce texto, en cada paso elige una palabra entre un conjunto de candidatos según una distribución de probabilidad. Esa elección no es determinista salvo que se la fuerce a serlo, y rara vez se la fuerza, porque el determinismo total produce salidas peores.

Aleatoriedad controlada, eufemismo de manual

El parámetro temperature (temperatura del muestreo, regula cuánta libertad tiene el modelo al elegir la siguiente palabra) controla esa apertura. Top-p y top-k son dos formas de recortar el conjunto de candidatos antes de muestrear. Holtzman y otros publicaron en 2020 un análisis bastante completo de lo que cambia cuando se mueven esos parámetros, y la respuesta corta es que cambia todo.

Con la misma entrada exacta, el mismo modelo exacto, el mismo hardware exacto, dos llamadas consecutivas pueden producir salidas diferentes. No ligeramente diferentes. Estructuralmente diferentes. Un razonamiento que en una llamada funciona y en otra se descarrila a partir de la tercera frase.

A esto se le llama, dentro de la industria, aleatoriedad controlada. Es un término amable. Lo que está pasando es que el sistema fluctúa, que la fluctuación es parte del producto, y que sin esa fluctuación el producto sería peor en otras dimensiones. La máquina no es determinista en producción aunque su hardware lo sea sobre el papel.

La consistencia, otra vez, es una historia que se cuenta en presentaciones de ventas.

El silicio envejece, aunque no como nosotros

Hay un proceso llamado electromigración (la corriente eléctrica empuja literalmente los átomos del metal por las pistas del chip, desplazándolos con el tiempo). Hay otro llamado NBTI (Negative Bias Temperature Instability, una degradación lenta de cierto tipo de transistores bajo voltaje y temperatura sostenidos). Hay otro llamado inyección de portadores calientes. Cada uno tiene su mecanismo físico y su escala temporal, y todos hacen lo mismo a efectos prácticos.

Un chip que hoy cumple sus especificaciones, dentro de cinco años va a cumplirlas con menos margen, y dentro de diez puede haber dejado de cumplirlas. Constantinescu publicó hace años un panorama de estas tendencias en IEEE Micro, y la imagen que pintó no ha mejorado. El propio manual de Hennessy y Patterson, Computer Architecture: A Quantitative Approach, lleva varias ediciones dedicando capítulos enteros a fiabilidad, errores transitorios y al modelo cuantitativo del fallo, justo lo contrario de tratar la máquina como un punto fijo.

La miniaturización de los procesos modernos, los siete nanómetros, los cinco, los tres, agrava casi todos esos fenómenos. Cuanto más pequeño el transistor, menos átomos lo componen, y más drásticamente le afecta perder unos cuantos.

El bit rot (literalmente «podredumbre de bit»: la degradación lenta de los datos almacenados sin que nadie los toque) tiene también su versión en almacenamiento. Un disco duro magnético, sin tocar, sin leer, sin escribir, va perdiendo orientación en sus dominios magnéticos a lo largo de los años. Un SSD pierde carga en sus celdas. Los sistemas de archivos serios incorporan ya checksumming (cálculo periódico de huellas para detectar cambios) y scrubbing (relectura preventiva de todos los datos) precisamente porque saben que los datos guardados se pudren. Es exactamente la palabra que se usa en la literatura técnica. Rot. El silicio se pudre, despacio, en silencio, mientras pensamos en él como un soporte fiable.

Una nube de estados, no un punto fijo

Toda esta letanía sirve para una sola cosa. Sirve para sostener que la máquina, comparada con el humano, no es un sistema sin estados. Es un sistema con estados distintos, modulados por variables distintas, manifestándose en escalas distintas. Pero estados.

Tiene temperatura. Tiene desgaste. Tiene fluctuación interna. Tiene degradación. Tiene errores transitorios y errores permanentes.

Cuando alguien dice que prefiere una IA porque no se cansa, lo que en realidad está diciendo es que prefiere una variabilidad que no se le presenta como tal a una variabilidad que sí. Lo cómodo es que la máquina no llore, no proteste, no se queje del jefe. Su fluctuación viene en formato de logs que casi nadie lee.

El matiz que evita la demagogia

Aquí conviene introducir el matiz, porque sin matiz la comparación se vuelve barata.

La fluctuación humana y la fluctuación de la máquina no son lo mismo. Y no por la magnitud, sino por algo más interesante. El hambre regula búsqueda. El miedo regula evitación. El cansancio regula descanso. El estado afectivo de un humano, por muy ruidoso que sea para una jornada de trabajo concreta, tiene una función biológica medible, seleccionada durante cientos de millones de años porque ayuda al organismo a sobrevivir y reproducirse.

Es ruido funcional. Es ruido con sentido. Una persona cansada que sigue programando comete más errores, sí, pero también está recibiendo una señal de su cuerpo de que pare. Si para, descansa, vuelve, rinde más. El bucle tiene una lógica.

La entropía sin función

La máquina no tiene esa lógica. La fluctuación del silicio no le sirve para nada. No regula nada. No le pide al chip que descanse. No le ayuda a optimizar su uso de energía en función de un objetivo evolutivo, porque el chip no tiene objetivo evolutivo. Es ruido sin función. Es entropía a la que la ingeniería pone parches en forma de ECC, throttling, redundancia, retries, checksums.

Cuando la máquina falla bien, el parche tapa la entropía. Cuando falla mal, la entropía atraviesa el parche y aparece el bug raro, el corte de servicio, la respuesta incoherente que aparece una vez y no vuelve a aparecer cuando intentas reproducirla. Ese tipo de fallo no es excepción. Es el estado normal del sistema haciéndose visible un momento.

A quién se le imputa el ruido

La industria vende consistencia. Y la vende comparada con qué. Comparada con el operario humano que se distrae, que se enfada, que se equivoca al final del turno. La comparación tiene base, porque el humano efectivamente fluctúa de manera muy visible y la máquina fluctúa de manera muy invisible. Pero oculta algo. La máquina solo es consistente respecto a un hardware nuevo, a un modelo no actualizado, a un corpus de entrenamiento no contaminado por ataques ni por drift (deriva: cambio progresivo de la distribución de datos respecto a la del entrenamiento), a una infraestructura cuyos errores caen dentro del presupuesto del SLA (Service Level Agreement, acuerdo de nivel de servicio).

Cualquier cosa que esté fuera de esa caja deja de ser consistente. Y de la caja se sale enseguida. Un par de años en producción bastan. El propio Google SRE Book, escrito por la gente que mantiene esa infraestructura, da por hecho que los errores ocurren todo el tiempo y construye toda su disciplina sobre presupuestos de fallo, no sobre la ilusión de cero. Es la propia industria reconociendo, en sus manuales internos, que la consistencia es contable, no física.

Hay una asimetría adicional que conviene nombrar. La fluctuación del humano se atribuye al humano. La fluctuación de la máquina se atribuye al usuario, a la red, al prompt (instrucción de entrada al modelo), al caso de uso, al despliegue. Cuando una persona comete un error, la responsabilidad es suya. Cuando un sistema computacional comete un error, la responsabilidad se reparte entre tantos actores que en la práctica no recae sobre nadie.

Esto no es una crítica moralizante. Es una observación sobre cómo se distribuye el riesgo en sistemas opacos. Reconocer que la máquina tiene estados, que su fluctuación es real y medible, obliga a redistribuir esa responsabilidad de otra manera. Si el error puntual no es excepción sino manifestación del estado, entonces el fabricante, el operador y el integrador tienen que asumir algo de ese error como propio. No externalizarlo cada vez al usuario que no supo formular bien la consulta.

Las cifras llevan décadas publicadas

Llamar consistente a un sistema que corrige miles de bit-flips por año, que baja su frecuencia cuando hace calor, que muestrea con aleatoriedad controlada, que envejece en sus pistas de cobre y que pierde carga en sus celdas, es una decisión retórica. Solo se sostiene si nadie mira las cifras.

Las cifras llevan décadas publicadas. En SIGMETRICS, en SC, en IEEE Micro, en los manuales internos de las grandes operadoras. Dicen que la máquina es una nube de estados, no un punto fijo.

Comparar dos nubes, no una nube con un punto

Que la nube sea pequeña comparada con la nube humana es discutible, y depende del eje en que midas. En estabilidad de longitud de jornada, la máquina gana. En estabilidad de razonamiento bajo estrés térmico, no necesariamente. En estabilidad de comportamiento a lo largo de cinco años, el silicio pierde mucho antes de lo que la palabra consistencia sugiere.

Compararnos con la máquina no es comparar un sistema fluctuante con uno fijo. Es comparar dos sistemas fluctuantes que fluctúan por motivos diferentes, en escalas diferentes, con consecuencias diferentes, y cuya fluctuación tiene significados radicalmente distintos.

El humano fluctúa porque está vivo. La máquina fluctúa porque el silicio no aguanta perfectamente lo que le pedimos. Que llamemos a una de las dos estabilidad y a la otra debilidad dice más sobre nosotros que sobre los sistemas.

Definiciones

Bit-flip. Cambio espontáneo del valor de un bit en una memoria, normalmente sin causa externa visible, atribuido a rayos cósmicos, ruido térmico o degradación del silicio. En memorias modernas, suficientemente frecuente como para que los sistemas serios incorporen mecanismos de corrección automática.

ECC (Error-Correcting Code). Código de corrección de errores en hardware. Añade bits redundantes a cada palabra de memoria para detectar y corregir errores de uno o varios bits sobre la marcha, sin que el sistema operativo se entere de que han ocurrido.

Throttling térmico. Mecanismo por el que un procesador reduce automáticamente su frecuencia de reloj cuando supera cierta temperatura, para evitar daños. Implica una pérdida de rendimiento variable que depende de las condiciones ambientales.

Electromigración. Fenómeno físico por el cual la corriente eléctrica desplaza átomos de los conductores metálicos del chip a lo largo del tiempo, deteriorando las pistas y acabando por provocar fallos permanentes.

Bit rot. Degradación lenta de la información almacenada en un medio digital, ya sea magnético o de flash, por causas físicas como pérdida de carga, desmagnetización progresiva o errores acumulados.

Temperature, top-p, top-k. Parámetros que controlan el muestreo en modelos de lenguaje. Temperature ajusta cuánta libertad tiene el modelo al elegir la siguiente palabra. Top-p limita los candidatos al subconjunto cuya probabilidad acumulada llega a cierto umbral. Top-k limita los candidatos a los k más probables.

Drift (de modelo o de datos). Cambio progresivo de la distribución de los datos reales respecto a la distribución sobre la que se entrenó un modelo, que degrada su rendimiento aunque el modelo en sí no cambie.

SLA (Service Level Agreement). Acuerdo formal entre proveedor y cliente que fija umbrales de disponibilidad, latencia o errores aceptables. Los errores dentro del presupuesto del SLA se contabilizan como normales, no como fallo.

Referencias

Schroeder, B., Pinheiro, E. y Weber, W. (2009). DRAM Errors in the Wild: A Large-Scale Field Study. SIGMETRICS. Estudio de campo sobre la flota de Google del que provienen las observaciones sobre la frecuencia de errores corregibles en memoria. https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

Sridharan, V. y Liberty, D. (2012). A Study of DRAM Failures in the Field. SC12. Refinamiento del trabajo anterior, fuente del dato sobre concentración no aleatoria de fallos en módulos y celdas específicos.

Holtzman, A. et al. (2020). The Curious Case of Neural Text Degeneration. ICLR. Referencia para el análisis del muestreo controlado y los efectos de temperature, top-p y top-k en la salida de modelos de lenguaje. https://arxiv.org/abs/1904.09751

Constantinescu, C. Trends and Challenges in VLSI Circuit Reliability. IEEE Micro. Panorama sobre electromigración, NBTI y mecanismos de envejecimiento del silicio referido en el tramo sobre degradación a largo plazo.

Hennessy, J. y Patterson, D. Computer Architecture: A Quantitative Approach (Morgan Kaufmann, 6ª ed., 2017). Manual de referencia clásico para los capítulos sobre fiabilidad y errores transitorios mencionados en el artículo. https://www.elsevier.com/books/computer-architecture/hennessy/978-0-12-811905-1

Google SRE Book. Documentación pública sobre gestión de fallos a escala, contexto general para la afirmación de que los errores dentro del SLA se tratan como normales. https://sre.google/sre-book/table-of-contents/

También te interesa

En otros sitios

#hardware-ia #centros-de-datos #inteligencia #antropomorfismo