Por qué las CPU se calientan: turbo, límites de potencia y realidad

diciembre 22, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 0

¿Te fue útil?

Compraste “una CPU de 125W” y está consumiendo 230W, rozando los 100°C, y tu monitor te hace pensar que la sala está en llamas. Mientras tanto, la carga es “solo” un trabajo de compilación, un vacuum de base de datos o un nodo de Kubernetes que se suponía que sería aburrido.

No es un misterio. Es la realidad moderna: la CPU acelerará hasta que golpee un límite—temperatura, potencia, corriente o tiempo—y luego negociará con la física en tiempo real. Tu trabajo, como la persona que opera sistemas que no deben avergonzar a la empresa, es hacer esos límites explícitos, observables y alineados con la realidad.

Las CPU se calientan a propósito

Las CPU modernas no están “yéndose de control”. Hacen exactamente lo que fueron diseñadas para hacer: convertir margen térmico y eléctrico en rendimiento, y luego reducirse en el instante en que alcanzan una restricción. Ese es todo el sentido del comportamiento turbo en Intel y AMD, en desktop y servidor, portátil y estación de trabajo.

Los modelos mentales antiguos—“la CPU usa su potencia nominal”, “la temperatura es un signo de fallo”, “la frecuencia es fija”—ahora son caros operativamente. Crean el peor tipo de incidente: el lento y verosímil. El servicio no se cae; simplemente se vuelve más lento, más ruidoso y más difícil de diagnosticar porque oscila con la temperatura ambiente, el polvo, las curvas de ventilador y las decisiones del scheduler.

Si operas producción, deja de tratar la temperatura de la CPU como una simple luz de salud roja/amarilla/verde. La temperatura es una variable de control para el boost. Una CPU a 95°C puede estar sana y rápida; una CPU a 70°C puede estar inestable y en throttling por límites de potencia o corriente. La pregunta interesante no es “qué tan caliente está”, sino “qué límite está activo, y ese límite es el que pretendíamos?”

Datos interesantes y contexto histórico (útiles para reuniones)

TDP derivó de especificación de ingeniería a jerga de marketing. El “thermal design power” inicial estaba pensado para dimensionar el cooler en condiciones base, no para indicar “la máxima potencia que la CPU jamás consumirá”.
Intel Turbo Boost (generalizado alrededor de 2008) hizo la potencia de la CPU dinámica. La frecuencia se volvió función del margen, no una propiedad estática del SKU.
Las instrucciones AVX cambiaron el juego. Cálculo vectorial pesado puede disparar la densidad de potencia y activar reglas de turbo u offsets distintos comparados con código escalar.
La era Zen de AMD normalizó “temperatura como objetivo”. Muchas partes Ryzen alcanzan felizmente un límite térmico bajo boost porque el lazo de control está diseñado así.
Los centros de datos empujaron a los proveedores hacia picos de corto plazo. El rendimiento por ráfaga vende en benchmarks; el rendimiento sostenido es tu problema a menos que fijes límites.
Los nodos de proceso redujeron tamaño, pero la densidad de potencia no desapareció mágicamente. Transistores más pequeños pueden significar más calor por mm², no menos.
Los servidores solían priorizar el flujo de aire. Ventiladores de alta presión estática y conductos eran normales; los chasis de consumidor se optimizan para silencio y estética.
La gestión de potencia por firmware se volvió parte central del comportamiento de la plataforma. La CPU no está sola: los límites del VRM de la placa base y los valores predeterminados del BIOS pueden cambiar mucho cómo se comporta un “125W”.

Una cita que la gente de operaciones debería pegar en su monitor (idea parafraseada): “La esperanza no es una estrategia.” —idea parafraseada atribuida a liderazgo militar; en términos SRE: mídelo, o estás adivinando.

Broma #1: Una CPU a 100°C no está “en pánico”, está “maximizando el valor para los accionistas”. Lamentablemente, tú eres el valor para los accionistas.

Turbo, PL1/PL2/Tau y la trampa del “TDP”

Empieza con la verdad incómoda: esa etiqueta de “125W” suele ser más un punto de diseño que una promesa sobre el consumo real. La potencia real del paquete de la CPU puede excederla—a veces dramáticamente—dependiendo de los valores por defecto del firmware, las características de la carga y la refrigeración. Si el sistema puede enfriarla y alimentarla, la CPU aceptará la oferta.

El lazo de control básico: el rendimiento persigue límites

Las CPU modernas eligen continuamente frecuencia y voltaje basadas en:

Límite de temperatura (TjMax, típicamente alrededor de 95–105°C según el modelo)
Límites de potencia (Intel: PL1/PL2 con una ventana de tiempo Tau; AMD: PPT/TDC/EDC y reglas PBO)
Límites de corriente eléctrica (capacidad del VRM, restricciones de entrega del socket)
Guardas de fiabilidad (modelos de envejecimiento del silicio, sensores de hotspot)
Clasificación de la carga (AVX, ancho de vector, ocupación de núcleos, picos transitorios)

Tu CPU es básicamente un SRE para sí misma: intenta cumplir un SLO (“ir rápido”) respetando presupuestos de error (“no derretirse”). Cuando ves “sube a 5.6GHz y luego baja”, eso no es un defecto; es la política funcionando.

Lenguaje estilo Intel: PL1, PL2, Tau

En muchas plataformas Intel:

PL1: límite de potencia sostenido a largo plazo. Piensa en “presupuesto en estado estable”.
PL2: límite de potencia turbo a corto plazo. Piensa en “ráfaga”. A menudo mucho mayor que PL1.
Tau: la ventana de tiempo (en segundos) durante la cual PL2 está permitido antes de volver hacia PL1.

En la práctica, muchas placas llegan con valores por defecto permisivos: PL2 alto y Tau largo, o efectivamente “ilimitado” dentro de lo razonable. Por eso puedes ver una CPU “125W” sentada a 200W indefinidamente—porque el proveedor de la placa decidió que vender cifras de benchmark importaba más que respetar un sobre térmico conservador.

Lenguaje estilo AMD: PPT, TDC, EDC y PBO

El comportamiento de boost de AMD suele enmarcarse alrededor de:

PPT: package power tracking (un tope en la potencia total del socket)
TDC: límite de corriente sostenida
EDC: límite de corriente a corto plazo
PBO: Precision Boost Overdrive (perillas de política para aflojar límites si la refrigeración y los VRM lo permiten)

AMD tiende a tratar la temperatura como un poste de meta: elevará relojes hasta acercarse a un objetivo térmico (o hasta golpear límites de potencia/corriente). Por eso “siempre llega a 95°C” no es automáticamente “malo”, especialmente con refrigeradores pequeños o chasis compactos. La pregunta es: ¿obtienes rendimiento estable y predecible, o el sistema está oscilando y entrando en throttling bajo carga sostenida?

La trampa del TDP en términos de producción

TDP es útil para que un diseñador de hardware dimensione un cooler en condiciones base. En operaciones de producción, “TDP” es una mentira que te dices para dejar de pensar. No construyas tus planes de capacidad sobre ello.

En su lugar, planifica alrededor de la potencia sostenida del paquete bajo tu carga real, con tus valores BIOS reales, en tu chasis real, a tu temperatura ambiente real, con tu nivel de polvo real seis meses después. No es romántico, pero es cómo evitas llamadas de fin de semana.

Objetivos de temperatura y por qué 95–100°C es “normal”

Hay dos conversaciones distintas que la gente mezcla:

¿El silicio está seguro? Usualmente sí, hasta la temperatura máxima de unión especificada (TjMax). La CPU reducirá frecuencia para protegerse.
¿El sistema rinde de forma predecible? Aquí es donde puedes perder dinero. Throttling, ruido de ventiladores y jitter de frecuencia pueden convertir un nodo predecible en uno caótico.

Los proveedores no eligieron 95–100°C porque disfruten del drama. Lo eligieron porque tener ese margen térmico les permite enviar relojes de boost más altos dentro de un presupuesto fijo de potencia/área, y porque los sensores internos y lazos de control son lo bastante buenos para operar cerca del límite con seguridad.

Throttling térmico vs throttling por potencia vs throttling por corriente

“Throttling” es un término paraguas. Necesitas diferenciar:

Throttling térmico: la temperatura alcanza el límite; la frecuencia baja para reducir calor.
Throttling por límite de potencia: la potencia del paquete alcanza PL1/PL2/PPT; la frecuencia baja aunque las temperaturas estén bien.
Throttling por corriente/VRM: límites de plataforma, temperatura del VRM o topes de corriente forzan la reducción de frecuencia.

Cada uno tiene una solución diferente. Reaplicar pasta térmica no arreglará un tope de potencia. Subir los límites de potencia no arreglará un cooler mal montado. Y subir límites para “arreglar rendimiento” puede desestabilizar racks si tus PDU y flujo de aire no están dimensionados.

Realidad del enfriamiento: contacto, flujo de aire y física del chasis

La temperatura de la CPU en un panel de monitoreo es el último eslabón de una cadena. La cadena comienza en el die, viaja por el heat spreader, por la pasta térmica, hasta la base del cooler, a las aletas, al aire del chasis, al aire de la sala y finalmente al presupuesto del HVAC.

Cuando diagnosticas CPUs calientes, asume primero las fallas físicas aburridas. La mitad de las veces no es firmware; es mecánica.

Los culpables más comunes en el mundo real

Mala presión de contacto o montaje desigual. El sensor de hotspot de la CPU dice la verdad: una esquina está cocinándose.
Problemas con la pasta térmica. Demasiada, muy poca, seca o expulsada tras ciclos térmicos.
Recirculación de aire. El cooler reutiliza su propio escape porque el diseño del chasis es decorativo, no aerodinámico.
Curvas de ventilador optimizadas para “silencio”. El silencio es agradable. Silencio bajo carga sostenida también es cómo compras throttling.
Negligencia de polvo y filtros. La caída de presión aumenta, el flujo de aire disminuye, las temperaturas suben y un día todo cruza un umbral.
Deriva de temperatura ambiente. Las suposiciones de “pasillo frío” fallan cuando faltan paneles de cierre o una unidad CRAC está caída.

Broma #2: “Lo arreglaremos con un cooler más grande” es la versión de hardware de “simplemente añade reintentos”. Funciona hasta que ya no funciona.

Guía rápida de diagnóstico

Quieres una respuesta rápida a dos preguntas: qué límite está activo, y ese límite es esperado. Aquí está la secuencia que te lleva allí sin sacrificios rituales.

Primero: confirma que el síntoma es real (no un artefacto de sensor/telemetría)

Revisa temperatura y frecuencia de la CPU bajo una carga conocida.
Corrobora con al menos dos herramientas (sensores del kernel + herramienta del proveedor o herramienta basada en MSR).
Verifica que la carga es la que crees (un hilo caliente vs todos los núcleos).

Segundo: identifica el limitador activo

Busca banderas de throttling térmico y caídas de frecuencia que se correlacionen con el techo de temperatura.
Revisa la potencia del paquete y los límites de potencia (PL1/PL2/Tau o PPT/TDC/EDC).
Revisa límites de corriente/VRM y sensores térmicos de plataforma (VRM, temperatura de entrada).

Tercero: decide si arreglar refrigeración, política de potencia o la carga

Si está limitado por temperatura: mejora el contacto, el flujo de aire, la curva de ventiladores o reduce voltaje/potencia.
Si está limitado por potencia: decide si quieres rendimiento sostenido (subir PL1/PPT) o térmicas predecibles (bajar PL2/Tau o capear frecuencia).
Si está provocado por la carga: identifica rutas de código AVX pesadas, límites de CPU en contenedores, afinidad de scheduler y vecinos ruidosos.

Este orden importa. A la gente le encanta empezar en el BIOS porque da sensación de control. Empieza por la observación, luego por la política. El hardware no se preocupa por tus sentimientos.

Tareas prácticas (comandos, salidas, qué significa, qué decides)

Estas están diseñadas para servidores y estaciones de trabajo Linux. Algunas requieren paquetes (como lm-sensors, linux-tools), pero los comandos son realistas y comunes en runbooks de producción.

Tarea 1: Ver el comportamiento actual de la frecuencia de la CPU (¿está haciendo boost, está atascada?)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\\(s\\)|Thread|Core|Socket|MHz'
Model name:                           Intel(R) Xeon(R) CPU
CPU(s):                               32
Thread(s) per core:                   2
Core(s) per socket:                   16
Socket(s):                            1
CPU MHz:                              1198.523

Qué significa: La línea “CPU MHz” es una instantánea y puede ser engañosa en sistemas modernos. Aun así, si nunca sube bajo carga, puede que estés forzado por un governor bajo o un tope de potencia.

Decisión: Si la frecuencia parece baja, pasa a monitorización en vivo por núcleo (Tarea 2) y revisa el governor (Tarea 3).

Tarea 2: Vigila frecuencia por núcleo, temperatura y banderas de throttling (Intel)

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 2
     CPU     Avg_MHz   Busy%   Bzy_MHz   TSC_MHz  PkgTmp  PkgWatt
       -        4123   92.15      4473      2500      98   212.34
     IRQ        1020

Qué significa: Alto Busy% y alta PkgTmp cerca del techo con alto PkgWatt sugiere que la CPU está utilizando potencia de turbo. Si PkgTmp alcanza 100 y Bzy_MHz cae, probablemente estás en throttling térmico.

Decisión: Si PkgTmp está cerca del máximo, revisa indicadores de throttling térmico (Tarea 4) y la ruta de refrigeración. Si PkgWatt es alto, confirma PL1/PL2 (Tarea 5).

Tarea 3: Confirma el governor de escalado de frecuencia de la CPU (¿estás en “powersave” por accidente?)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Qué significa: performance solicita frecuencias más altas. powersave o una política de plataforma puede limitarte.

Decisión: Si no es performance (o no es la política que querías), cámbialo mediante las herramientas de tu distro o perfiles tuned. Si es correcto, busca límites de potencia/térmicos en su lugar.

Tarea 4: Revisa contadores de throttling térmico del kernel (Intel MSRs expuestos vía sysfs en algunas plataformas)

cr0x@server:~$ grep . /sys/devices/system/cpu/cpu*/thermal_throttle/* 2>/dev/null | head
/sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count:3
/sys/devices/system/cpu/cpu0/thermal_throttle/package_throttle_count:8

Qué significa: Si estos contadores aumentan durante la carga, la CPU está activamente en throttling por temperatura.

Decisión: Si los contadores de throttling suben, trata esto como un problema de refrigeración/política de potencia, no como un “misterio de CPU lenta”. Mejora refrigeración o reduce potencia (Tareas 11–12).

Tarea 5: Leer límites de potencia Intel RAPL (PL1/PL2) si están disponibles

cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
125000000
cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw
225000000

Qué significa: Constraint 0 es comúnmente el límite sostenido (similar a PL1) y constraint 1 el límite de corto plazo (similar a PL2). Aquí: 125W sostenido, 225W turbo.

Decisión: Si PL2 es enorme y las térmicas son un problema, baja PL2 o acorta Tau (BIOS o herramientas de plataforma). Si el rendimiento es demasiado bajo, puede que necesites subir PL1—pero solo si tu refrigeración y entrega de potencia pueden sostenerlo.

Tarea 6: Comprobar sensores de temperatura de la CPU (genérico)

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +97.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +95.0°C  (high = +90.0°C, crit = +100.0°C)
Core 1:        +96.0°C  (high = +90.0°C, crit = +100.0°C)

Qué significa: Vives cerca del límite crítico. Esto puede ser esperado en pruebas de estrés, pero si ocurre bajo carga de servicio normal, estás gastando tu presupuesto de rendimiento en calor.

Decisión: Correlaciona temperaturas con frecuencia y potencia (Tareas 2 y 5). Si las temperaturas son altas a potencia moderada, sospecha montaje/flujo de aire.

Tarea 7: Confirma la carga y si es mono-hilo o multihilo

cr0x@server:~$ top -b -n1 | head -15
top - 12:20:18 up 41 days,  3:10,  1 user,  load average: 23.41, 18.92, 12.10
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.7 us,  2.1 sy,  0.0 ni,  4.8 id,  0.2 wa,  0.0 hi,  0.2 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
8421 build     20   0 2451280 512404  23344 R  3200  3.1  18:01.22 clang

Qué significa: Un proceso consumiendo ~3200% de CPU en un sistema de 32 hilos sugiere paralelismo amplio. Eso cambia el comportamiento de boost: el turbo con todos los núcleos es menor que el turbo de 1–2 núcleos, y la potencia del paquete sube rápido.

Decisión: Si esto es “normal”, fija objetivos realistas de potencia/refrigeración sostenida. Si es inesperado, encuentra por qué se está ejecutando el trabajo (fallo en CI, pool de hilos desbocado, solapamiento de cron).

Tarea 8: Ver si estás bloqueado por I/O (se culpa al CPU pero el cuello de botella está en otro lado)

cr0x@server:~$ iostat -xz 2 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.20    0.00    4.10   42.30    0.00   18.40

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  svctm  %util
nvme0n1         220.0   180.0  50240   38912     390.4      8.12   18.21   1.05  42.00

Qué significa: Alto iowait significa que los ciclos de CPU no son el factor limitante; el sistema espera almacenamiento. Las CPUs pueden calentarse igualmente (picos de turbo en background), pero “la CPU está caliente así que la CPU es el problema” a menudo es incorrecto.

Decisión: Si iowait es alto, arregla latencia/cola del almacenamiento primero. De lo contrario ajustarás límites de CPU para enmascarar un problema de I/O y aún así fallarás en tu SLO.

Tarea 9: Ver límites de CPU en contenedores o throttling de Kubernetes (parece throttling térmico, pero son cgroups)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.max 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
200000 100000

Qué significa: Este ejemplo es una cuota de 200ms de tiempo de CPU por periodo de 100ms, efectivamente 2 CPUs de tiempo. Si tu carga espera 8 cores, “se throttleará” independientemente de la temperatura.

Decisión: Si hay cuotas presentes, alinea requests/limits con expectativas. No persigas fantasmas de refrigeración.

Tarea 10: Detectar comportamiento AVX indirectamente vía picos de potencia y caídas de frecuencia

cr0x@server:~$ sudo perf stat -a --timeout 5000 2>&1 | head -12
 Performance counter stats for 'system wide':

       120,345,882,112      cycles
        65,112,004,331      instructions              #    0.54  insn per cycle
             2,114,220      context-switches
                12,804      cpu-migrations

Qué significa: IPC bajo bajo cómputo intenso puede correlacionar con código vectorial, stalls de memoria o throttling. Perf no te dirá “AVX” explícitamente aquí, pero cuando se combina con turbostat mostrando altos vatios y relojes más bajos, AVX es un sospechoso habitual.

Decisión: Si esto se correlaciona con cargas previsibles (compresión, criptografía, inferencia ML), considera políticas de frecuencia AVX, topes de potencia o mover esa carga a nodos dimensionados para ella.

Tarea 11: Revisar RPM de ventiladores y salud del flujo de aire (servidores con IPMI)

cr0x@server:~$ sudo ipmitool sdr type Fan
FAN1             | 8600 RPM        | ok
FAN2             |  900 RPM        | cr
FAN3             | 8700 RPM        | ok

Qué significa: Un ventilador está en estado crítico y apenas gira. Tu CPU se calentará, y peor aún, el sistema puede tener flujo de aire desigual causando hotspots.

Decisión: Reemplaza el ventilador, revisa políticas de control de ventiladores, confirma que no haya cables obstruyendo. No “soluciones” esto bajando límites de potencia a menos que sea un parche temporal.

Tarea 12: Validar temperatura de entrada/ambiente (tu “refrigeración” puede ser fallo de sala)

cr0x@server:~$ sudo ipmitool sensor | egrep -i 'Inlet|Ambient|Temp' | head
Inlet Temp       | 29 degrees C     | ok
Ambient Temp     | 30 degrees C     | ok
CPU1 Temp        | 96 degrees C     | ok

Qué significa: Una entrada de 29–30°C no es catastrófica, pero reduce tu margen térmico. Si antes las CPUs estaban en 80°C y ahora llegan a 96°C con la misma carga, revisa la sala y la contención de aire.

Decisión: Si la entrada es alta, trata esto como un problema de instalaciones/flujo de aire. Bajar turbo puede ser una guarda temporal, no la solución real.

Tarea 13: Detectar razones de throttling en nodos con GPU NVIDIA (porque las quejas de calor de CPU a menudo ocurren en nodos mixtos)

cr0x@server:~$ nvidia-smi -q | egrep -i 'Power Limit|Clocks Throttle Reasons' -A5
    Power Limit                      : 300.00 W
    Clocks Throttle Reasons
        Idle                         : Not Active
        Applications Clocks Setting   : Not Active
        SW Power Cap                 : Active
        HW Thermal Slowdown          : Not Active

Qué significa: Si la GPU está limitada por potencia, tu carga puede desplazarse a la CPU, incrementando potencia y calor de CPU de formas inesperadas. Los nodos mixtos están llenos de efectos de segundo orden.

Decisión: Coordina presupuestos de potencia CPU/GPU. Evita “arreglar la CPU” en aislamiento cuando el tope de potencia a nivel de nodo es la política real.

Tarea 14: Detectar mala configuración del BIOS vía dmesg (zonas térmicas, disponibilidad de RAPL, pistas de microcode)

cr0x@server:~$ dmesg | egrep -i 'microcode|rapl|thermal|throttl' | tail -10
microcode: updated early to revision 0x2f, date = 2023-08-10
intel_rapl_common: Found RAPL domain package
thermal thermal_zone0: failed to read out thermal zone (-61)

Qué significa: Si zonas térmicas fallan al leerse, tu OS puede estar sin sensores o las tablas ACPI son raras. Podrías estar ciego o medio ciego a las razones de throttling.

Decisión: Arregla la visibilidad primero (actualización de firmware, parámetros de kernel, drivers correctos). No ajustes lo que no puedes observar.

Tres mini-historias del mundo corporativo

Mini-historia 1: El incidente causado por una suposición errónea

Una compañía desplegó una tanda de “runners de alta performance” para CI. La hoja de procuración decía que las CPUs eran partes de 125W. El equipo de facilities presupuestó potencia de rack y refrigeración en consecuencia. Todos se sintieron responsables. Todos estaban equivocados en la misma dirección, que es como nacen los incidentes.

En el día uno, todo fue genial. Las compilaciones fueron más rápidas, los desarrolladores contentos y los runners parecían estables. Entonces llegó un lanzamiento de producto y el volumen de CI se duplicó. La flota de runners pasó de “ráfagas” a “sostenido en todos los núcleos”. La potencia del paquete subió muy por encima de 125W en la mayoría de nodos, los ventiladores gritaron y el cluster empezó a comportarse como si tuviera una red inestable.

La red no estaba inestable. Las CPUs estaban entrando en throttling térmico fuerte, y los nodos oscilaban: boost → calor → throttle → enfriar → boost. Las latencias se dispararon en todos los lugares equivocados: subidas de artefactos, fetches de cache, incluso sesiones SSH para diagnosticar el problema. Los humanos interpretaron los síntomas como “la red está saturada” porque eso es lo que la lentitud se siente.

Eventualmente graficaron frecuencia vs temperatura vs potencia del paquete y vieron el patrón de sierra. La solución real fue aburrida: establecer límites de potencia sostenida sensatos (reducir los valores por defecto de “turbo infinito”), ajustar curvas de ventilador y añadir dos paneles ciegos que faltaban desde la instalación. El rendimiento pico fue algo menor, pero las compilaciones finalizaron más rápido en general porque dejaron de entrar en thrash.

La suposición errónea no era “las CPUs se calientan”. Era “TDP es el máximo”. Una vez eliminada esa suposición, el sistema volvió a ser predecible—como debió ser desde el primer día.

Mini-historia 2: La optimización que salió mal

Otro equipo corrió servicios sensibles a latencia en nodos de propósito general. Querían rendimiento consistente y decidieron “fijar en performance” en toda la flota: governor en performance, turbo máximo permitido y P-states agresivos. Parecía correcto en papel. Menos transiciones de frecuencia, menos picos en la latencia tail. Simple.

Durante una semana, las métricas mejoraron. Entonces llegó el verano y la entrada del datacenter subió un par de grados. Nada dramático. Aún dentro de spec. Pero los nodos ahora tenían menos margen térmico. La alta frecuencia siempre activa mantuvo la potencia media del paquete más alta incluso con carga moderada. Las curvas de ventilador respondieron tarde. Las temperaturas de CPU pasaron más tiempo cerca del límite todo el día.

El efecto negativo fue sutil: no apagones térmicos, sino micro-throttling en picos de tráfico. El servicio no se cayó; simplemente se volvió impredecible. El autoscaling se disparó con más frecuencia, lo que incrementó la carga del cluster, lo que subió temperaturas aún más. Un bucle de retroalimentación elegante: no catastrófico, solo caro e irritante.

La solución no fue “desactivar turbo”. Fue política: capear la potencia sostenida a lo que el chasis puede enfriar en la peor temperatura de entrada, y luego dejar que el turbo exista dentro de esa guardia. También dividieron la flota: algunos nodos afinados para latencia, otros para rendimiento. El “modo performance” único fue el error real.

La optimización que ignora la variación del entorno no es optimización. Es un incidente con buenas intenciones.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de almacenamiento tenía un cluster de nodos de base de datos con compaction y cifrado intensivos. Ya habían sufrido antes, así que estandarizaron una checklist de puesta en servicio: verificar visibilidad de sensores, verificar límites de potencia, verificar control de ventiladores y luego correr una prueba de carga sostenida mientras capturaban frecuencia, temperatura y potencia del paquete.

Durante una renovación rutinaria de hardware, un lote nuevo de nodos mostró benchmarks ligeramente mejores en el burn-in del proveedor. Todo esperaba que fuera una victoria. La checklist del equipo detectó otra cosa: en una prueba de estrés de 30 minutos la potencia del paquete se mantuvo elevada mucho más allá de la ventana de turbo esperada y las temperaturas rondaron el techo térmico.

Los nodos no estaban fallando aún, pero vivían al límite. El equipo comparó perfiles BIOS y encontró al culpable: un preset “performance” que efectivamente eliminaba el tope sostenido de potencia previsto. Probablemente estaba bien para un banco de pruebas con aire abierto y un técnico presente. En un rack, era un problema de lenta evolución.

Revirtieron a la política BIOS base, validaron de nuevo y despacharon los nodos. Dos semanas después, una unidad de refrigeración en una fila tuvo un problema; las temperaturas de entrada subieron. Esos nodos se mantuvieron estables mientras los hosts de “configuración por defecto” de un equipo adyacente empezaron a throttlear. Sin informe de incidente. Solo un día tranquilo, que es el mayor elogio que puede dar la producción.

La validación aburrida y repetible vence a la afinación heroica. Siempre.

Errores comunes: síntoma → causa raíz → solución

Estos son los patrones que aparecen en canales reales de incidentes: afirmaciones confiadas, diagnóstico equivocado, resolución lenta.

1) Síntoma: La CPU llega a 100°C instantáneamente bajo carga

Causa raíz: Problema de contacto del cooler (presión de montaje, standoff faltante, film protector aún puesto, pasta seca).

Solución: Reasentar el cooler, reaplicar pasta correctamente, verificar torque de montaje uniforme. Reprueba con una carga sostenida observando la tasa de subida de temperatura; comportamiento de instantáneo a límite es una señal física roja.

2) Síntoma: La temperatura está bien (70–80°C) pero el rendimiento es bajo y las frecuencias están capadas

Causa raíz: Throttling por límite de potencia (PL1/PPT bajo) o cuota de cgroup de CPU.

Solución: Revisa RAPL/valores BIOS y cuotas de cgroup. Eleva límites sostenidos solo si la refrigeración y el presupuesto de potencia del nodo lo soportan.

3) Síntoma: El rendimiento oscila cada 10–60 segundos

Causa raíz: Comportamiento de la ventana Tau o histéresis de la curva de ventilador causando ciclos boost/throttle; también posible ciclaje térmico del VRM.

Solución: Afina PL2/Tau y curvas de ventilador para estabilidad. Considera reducir ligeramente el pico para eliminar la oscilación y mejorar el rendimiento global.

4) Síntoma: Un nodo corre más caliente que nodos idénticos

Causa raíz: Varianza mecánica (pasta, montaje), fallo de ventilador, flujo de aire obstruido o deriva de perfil BIOS.

Solución: Compara ajustes BIOS, RPM de ventilador y lecturas de sensores lado a lado. Intercambia ventiladores, revisa ducting y vuelve a asentar el cooler si es necesario.

5) Síntoma: Tras actualización de microcode/BIOS, las CPU corren más calientes

Causa raíz: El firmware cambió la política de boost o los límites de potencia. A veces “parches de seguridad” alteran rendimiento/potencia indirectamente.

Solución: Re-valida PL1/PL2/PPT después de cambios de firmware. Mantén una captura base de turbostat/sensors bajo carga fija para comparación.

6) Síntoma: Solo ciertas cargas se sobrecalientan (compresión, crypto, ML), otras no

Causa raíz: Código vectorial/AVX pesado aumenta densidad de potencia; también uso de todos los núcleos a alta utilización.

Solución: Considera colocación de cargas (nodos dedicados), ajusta topes de potencia o acepta un turbo all-core más bajo. No dimensionar la refrigeración según “comportamiento medio” de la aplicación.

7) Síntoma: La fila del datacenter está “dentro de spec” pero aumenta el throttling en tardes calurosas

Causa raíz: La temperatura de entrada reduce margen; problemas de contención; paneles ciegos faltantes; recirculación.

Solución: Arregla gestión de flujo de aire e higiene de rack. Usa sensores de temperatura de entrada como telemetría de primera clase y alerta sobre deriva, no solo umbrales absolutos.

Listas de verificación / plan paso a paso

Paso a paso: hacer las térmicas de la CPU predecibles (no necesariamente más frías)

Define tu objetivo. ¿Este nodo está afinado para throughput, latencia o acústica? Elige un objetivo primario; los demás son restricciones.
Captura una línea base bajo una carga sostenida fija. Registra potencia del paquete, temperatura, frecuencia y contadores de throttling.
Verifica visibilidad y corrección de sensores. Si los sensores faltan o están rotos, para y arregla eso primero.
Revisa el tipo de throttling. Térmico vs potencia vs cgroups. Diagnostica antes de girar perillas.
Define una política de potencia sostenida. Escoge PL1/PPT que tu refrigeración pueda sostener en la peor temperatura ambiente.
Define la política de ráfaga deliberadamente. PL2/Tau debe reflejar la ráfaga de tu carga. Las compilaciones y compactions no son “ráfagas”.
Valida salud del flujo de aire. RPM de ventiladores, filtros, ducting, paneles ciegos y gestión de cables.
Re-prueba la misma carga. Busca estabilidad: no haya sierra de frecuencia, ni temperaturas que se desplacen.
Despliega con guardarraíles. Alerta sobre contadores de throttling, no solo temperatura. La temperatura sola es una historia incompleta.
Re-valida tras cambios. Las actualizaciones BIOS, upgrades de kernel y movimientos de chasis cambian el comportamiento.

Checklist operacional: qué alertar

Aumento de contadores de thermal throttle (por núcleo y paquete) durante ventanas de carga habituales.
Frecuencia sostenida por debajo del esperado all-core a alta utilización.
Deriva de temperatura de entrada respecto a la línea base normal para ese rack/fila.
Anomalías en ventiladores: un ventilador con RPM baja, ventilador en estado “cr”, o PWM de ventilador al máximo constantemente.
Anomalías en potencia del paquete: nodos consumiendo materialmente más potencia que pares del fleet bajo carga similar.

Preguntas frecuentes

1) ¿Es seguro 95–100°C para mi CPU?

Usualmente sí si está dentro del TjMax especificado y la CPU se comporta normalmente (sin crashes, sin WHEA storms, sin apagados). Seguro no significa óptimo. Si estás en throttling, estás pagando por rendimiento que no obtienes.

2) ¿Por qué mi CPU “125W” tira 200W?

Porque TDP no es “consumo máximo”, y porque los límites de potencia del firmware (PL2 y Tau, o políticas PBO) pueden permitir turbo sostenido muy por encima del número de marketing. Muchas placas vienen con valores agresivos por defecto.

3) ¿Debo desactivar el turbo para arreglar el calor?

Como último recurso o mitigación temporal, sí. Pero desactivar turbo es un instrumento tosco. Prefiere establecer límites sostenidos sensatos (PL1/PPT) y un límite de ráfaga razonable (PL2/Tau). A menudo obtienes mejor throughput total evitando la oscilación.

4) ¿Por qué una actualización de BIOS cambió mis temperaturas?

Las actualizaciones de BIOS pueden cambiar microcode, tablas de boost, valores por defecto de límites de potencia, lógica de control de ventiladores y calibración de sensores. Trata las actualizaciones de firmware como cambios de rendimiento: captura la base antes y valida después.

5) Mi CPU está fría pero el rendimiento sigue mal. ¿Por qué?

Causas comunes: throttling por límite de potencia, cuota de cgroup, contención de ancho de banda de memoria o esperas de I/O. La temperatura no es un indicador universal de cuello de botella. Revisa límites de potencia e iowait antes de volver a aplicar pasta.

6) ¿Importa la pasta térmica en servidores?

La calidad de la pasta importa menos que la correcta aplicación y la presión de montaje adecuada. Una pasta intermedia aplicada correctamente vence a una pasta exótica aplicada mal. Además: el rendimiento de la pasta se degrada con el tiempo y ciclos térmicos; planifica mantenimiento en hosts de larga vida.

7) ¿Son los AIO de líquido la solución?

A veces. Pueden mover calor a un radiador más grande y reducir temperaturas de hotspot. También añaden bombas, riesgos de fugas y un modo de falla más difícil de detectar que “ventilador parado”. En flotas de producción, la simplicidad suele ganar a menos que tengas madurez operacional sólida alrededor del refrigerado líquido.

8) ¿Por qué la temperatura de mi CPU sube instantáneamente y luego se estabiliza?

Los sensores de hotspot reaccionan rápido, y los turbo pueden aplicar alto voltaje y frecuencia de inmediato. Un pico rápido que se estabiliza puede ser normal. Un pico que alcanza el límite térmico y desencadena throttling repetido sugiere contacto de refrigeración o turbo de potencia excesivo.

9) ¿Cuál es la mejor métrica única para alertar?

Si solo puedes escoger una, alerta sobre eventos de thermal throttling (contadores en aumento) durante carga habitual. Está más cerca de “se está negando rendimiento” que la temperatura bruta.

10) ¿Puede ayudar el undervolting?

Puedes reducir potencia y calor para el mismo rendimiento, pero en muchas plataformas está cada vez más restringido y añade riesgo de estabilidad si se hace agresivamente. En producción, prefiere límites de potencia soportados por el proveedor y perfiles BIOS validados en lugar de aventuras de undervolt por nodo.

Conclusión: pasos prácticos siguientes

Las CPU se calientan porque el contrato moderno es simple: usar cada vatio y grado disponible para ir más rápido, hasta que un límite diga que pares. Si no eliges los límites, tu proveedor de placa, valores por defecto de firmware y las condiciones ambientales los elegirán por ti. Eso no es gobernanza; es vibes.

Pasos que puedes hacer realmente esta semana:

Establece una línea base en un nodo representativo bajo carga sostenida con turbostat y sensors; captura frecuencia, temperatura y potencia del paquete juntos.
Decide tu objetivo de potencia sostenida (PL1/PPT) basado en lo que tu chasis y sala pueden enfriar en la peor temperatura de entrada.
Define el comportamiento de ráfaga intencionalmente (PL2/Tau o política PBO) para evitar throttling en sierra.
Alerta sobre contadores de throttling, anomalías en ventiladores y deriva de temperatura de entrada—no solo “CPU temperatura > 90°C”.
Documenta el perfil BIOS como política de producción. Trátalo como configuración, porque lo es.

No necesitas CPUs más frías. Necesitas CPUs predecibles. La previsibilidad es como duermes tranquilo.