Los números de TDP de CPU en portátiles suelen ser cuentos de hadas

El TDP no es un termómetro ni un vatímetro

TDP (Thermal Design Power) suena a medida. Parece una medida. La gente lo cita como una medida. En portátiles, a menudo no es una medición de la potencia que verás en la toma de pared, en la batería o incluso en el paquete de la CPU bajo tu carga de trabajo.

En la práctica, el “TDP” en portátiles suele ser una etiqueta para el sobre térmico previsto del procesador bajo ciertas condiciones definidas que pueden no coincidir con tus condiciones, la refrigeración de tu portátil o las decisiones de firmware de tu fabricante. La CPU tiene un modelo interno de potencia y temperatura, el firmware establece límites y el sistema operativo solicita rendimiento. Lo único que garantiza “TDP” es que alguien reunió y habló sobre ello.

Lo que se supone que representa el TDP

Históricamente, el TDP se usaba para dimensionar la refrigeración: disipadores, ventiladores, rejillas y flujo de aire del chasis. La meta no era la “potencia máxima”, era “el calor a extraer durante una carga sostenida que al vendedor le importa”. Esa diferencia sutil importa: sostenida, carga definida, reglas definidas por el vendedor.

Lo que los compradores de portátiles creen que representa

• Una promesa de rendimiento sostenido.
• Una promesa de consumo máximo de potencia.
• Un proxy de “esta CPU es más rápida que aquella CPU”.
• Una garantía de que dos portátiles con la misma CPU rendirán de forma similar.

Sólo una de esas afirmaciones es ocasionalmente verdadera, y aun así sólo por accidente.

En qué se convierte el TDP en portátiles

Se convierte en un gancho de marketing para clasificar una familia de CPU: “serie U es eficiente”, “serie H es rápida”, “HX es tipo sobremesa”. Luego los OEM establecen sus propios límites sostenidos y de ráfaga para encajar en el chasis, objetivos de batería, metas de ruido y segmentación de producto. El chip puede ser capaz de ráfagas de 60–90W, pero el portátil puede permitir eso por 10 segundos, 28 segundos o “hasta que el usuario abra Slack”.

Broma #1: El TDP de los portátiles es como un pronóstico del tiempo: técnicamente derivado de modelos, pero aún así no es algo por lo que debas apostar tu viaje al trabajo.

Cómo llegamos aquí: la deriva del TDP de la ingeniería a las sensaciones

Los CPUs para portátiles no se volvieron engañosos de la noche a la mañana. La industria evolucionó a un lugar donde las CPUs pueden exceder sus envolventes térmicas “base” de forma rutinaria, y donde los OEMs ajustan agresivamente para delgadez y duración de batería. El problema es que la hoja de especificaciones no evolucionó hacia algo que los consumidores puedan usar.

Hechos interesantes y contexto histórico (breve, concreto)

1. El turbo hizo políticamente incómodo el “consumo base”. Una vez que las CPUs empezaron a subir la frecuencia oportunísticamente por encima de la base, la “potencia típica” dejó de ser estable.
2. El modelo de límites de potencia de Intel (PL1/PL2/Tau) normalizó la potencia en ráfaga. La potencia sostenida y la potencia a corto plazo se convirtieron en controles distintos, no en un único número.
3. Las piezas móviles empujaron la integración. GPUs integradas y controladores de memoria significan que la potencia del paquete de la CPU no es “solo núcleos”, por lo que las mezclas de cargas varían enormemente.
4. El diseño thin-and-light se convirtió en un punto de venta principal. Muchos portátiles se diseñan primero para ruido y grosor, luego se rellenan los límites de potencia.
5. La segmentación de producto por parte de los OEM es real. Dos modelos con la misma CPU pueden ajustarse deliberadamente a potencias sostenidas diferentes para mantener una escalera de precios.
6. La batería y las restricciones del VRM importan. Un portátil puede no poder suministrar mucha potencia desde la batería sin caída de voltaje, calor o preocupaciones de desgaste a largo plazo.
7. La temperatura de la carcasa y la comodidad se convirtieron en restricciones. “No quemar al usuario” es un límite de diseño; a menudo vence a “alcanzar el número del benchmark”.
8. Los ajustes “Mejor rendimiento” de Windows cambiaron expectativas. Los perfiles de energía del SO pueden cambiar el comportamiento de PL1/PL2 sin decirlo en lenguaje claro.
9. Los límites a nivel de plataforma (adaptador CA, USB-C PD) se volvieron cuellos de botella comunes. Un adaptador USB-C de 65W puede limitar una CPU “45W” una vez que el resto del sistema toma su parte.

Aquí está la parte incómoda: el proveedor del chip puede publicar un número, pero tu portátil es un tratado negociado entre firmware, térmicas y el deseo corporativo de no canibalizar el modelo “Pro”.

Los controles reales: PL1, PL2, Tau, cTDP y compañía

Si quieres realidad, ignora el TDP y aprende el plano de control. Los distintos proveedores nombran las cosas de forma diferente, pero la estructura es similar: un límite de potencia sostenida, un límite de impulso a corto plazo y restricciones térmicas que anulan todo cuando la refrigeración se satura.

PL1: el presupuesto de potencia sostenida

PL1 suele ser la potencia “a largo plazo”. El portátil puede funcionar ahí indefinidamente si la refrigeración lo soporta. Los OEM a menudo establecen PL1 por debajo de la “clase TDP” anunciada de la CPU, porque están diseñando para acústica, batería o temperatura de la carcasa.

En el mundo real: PL1 es el número que rige tu compilación de 10 minutos, tu render largo, tu simulación sostenida y tus quejas “¿por qué el portátil va más lento después del primer minuto?”.

PL2: el presupuesto de impulso a corto plazo

PL2 es el límite de “ráfaga”. Es por lo que los portátiles se sienten ágiles al abrir aplicaciones, exportar un archivo pequeño o ejecutar un benchmark corto. PL2 es también la razón por la que los revisores obtienen gráficos atractivos con ejecuciones breves.

PL2 puede ser de 2–3× PL1 en algunos diseños. Eso no es hacer trampa. Ese es el punto. El engaño ocurre cuando el marketing implica que el comportamiento de ráfaga es el comportamiento sostenido.

Tau: la ventana temporal (la parte que todo el mundo olvida)

Tau es efectivamente “cuánto tiempo podemos hacernos pasar por sobremesa”. Define cuánto tiempo se puede usar PL2 antes de caer hacia PL1. Algunos portátiles se envían con Tau largo para competitividad en benchmarks. Otros lo mantienen corto para evitar soak térmico y picos de ruido.

cTDP / rangos de potencia configurables

Muchas CPUs móviles soportan rangos configurables: 12–15W, 15–28W, 35–45W, etc. Ese rango no significa que tengas “una CPU de 28W”. Es la CPU siendo capaz de operar en distintos envolventes según el ajuste del OEM.

Si ves la misma CPU en portátiles diferentes con rendimiento radicalmente distinto, esta es la razón nueve de cada diez.

Trote térmico vs limitación de potencia

La gente culpa al “throttling térmico” por todo, pero la limitación por potencia es con frecuencia el primer limitador. La CPU puede nunca alcanzar su máximo térmico duro; puede simplemente mantenerse en un PL1 bajo porque el OEM quiere la curva de ventilador silenciosa.

Esa distinción importa, porque la solución difiere:

• Limitado por potencia: cambia la política de potencia (si es posible), ajustes de firmware, o acepta la elección del producto.
• Limitado térmicamente: mejora la refrigeración (limpieza, repaste, alineación de pads, curva de ventilador), reduce la temperatura ambiente o reduce la carga.

La visión de un responsable de fiabilidad sobre la gestión de energía en portátiles

En sistemas de producción, asumes que existe un lazo de control. En portátiles tienes varios: DVFS de la CPU, lógica del controlador embebido para ventiladores, planes de energía del SO y a veces demonios del proveedor que se pelean entre sí. No “fijas un TDP”. Gestionas un sistema de restricciones.

Una cita de operaciones pertenece aquí. Aquí hay una idea parafraseada de Werner Vogels (CTO de Amazon): idea parafraseada: Todo falla, y deberías diseñar y operar como si la falla fuera normal.

Los límites de potencia no son fallo, pero deben tratarse como un modo normal que debes observar y planear en torno a él.

El portátil es el producto (la CPU es solo pasajera)

Dos portátiles pueden compartir el mismo modelo de CPU y aun así comportarse como especies diferentes. Porque la CPU no es el sistema. El sistema es: capacidad de refrigeración, masa del disipador, calidad de la cámara de vapor, diseño de ventiladores, geometría de entrada/salida de aire, ajuste de firmware, diseño del VRM, vatios del adaptador y si el OEM limitó el rendimiento en batería sin decirlo.

Refrigeración: el estado estable vence a las gráficas de pico

El rendimiento de la refrigeración trata sobre la extracción de calor en estado estable. Un portátil fino puede absorber una ráfaga (masa térmica), pero no puede sostenerla sin flujo de aire y área de aletas. Cuando los revisores ejecutan un bucle de benchmark corto, la primera pasada es la luna de miel. La décima pasada es el matrimonio.

Entrega de potencia y límites del adaptador

Una “CPU de 45W” en un sistema con un adaptador USB-C PD de 65W ya está en una negociación con la GPU, la pantalla, el SSD y la carga. Bajo carga, el sistema podría:

• reducir la potencia de la CPU para mantener la carga, o
• dejar de cargar y mantener el rendimiento, o
• consumir la batería incluso estando enchufado (sí, de verdad).

El modo batería es un universo propio

Muchos portátiles limitan la potencia de la CPU significativamente en batería para preservar la vida útil de los ciclos y evitar caídas de voltaje. Si trabajas de verdad con la batería, debes medir el rendimiento con batería. De lo contrario estás benchmarkeando una máquina diferente a la que usas.

Software del proveedor y “modos de potencia IA”

Las utilidades del proveedor pueden anular políticas del SO, limitar PL1 cuando se activa el “modo silencioso” o incluso cambiar límites según la aplicación activa. A veces lo hacen bien. A veces lo hacen para alcanzar un objetivo de certificación de ruido. En cualquier caso, necesitas saber quién está en control.

Broma #2: La curva del ventilador del portátil fue diseñada por alguien que piensa que “silencioso” significa “dejar que la CPU sufra en silencio”.

Modos de fallo que sí puedes diagnosticar

Cuando un portátil rinde poco, quieres una lista corta de causas raíz plausibles. Aquí está el conjunto al que recurro, porque se mapean limpiamente a mediciones.

1) Ráfaga corta, luego colapso

Patrón: rápido durante 10–60 segundos, luego las frecuencias caen y no se recuperan.

Probable causa: PL2 permitido, pero PL1 es bajo, o la refrigeración se satura y fuerza un estado estable bajo.

Decisión: si necesitas rendimiento sostenido, elige un chasis más grueso o un modelo conocido por mayor potencia sostenida, no una clase TDP anunciada más alta.

2) Siempre lento, incluso al inicio

Patrón: nunca sube mucho.

Probable causa: SO en ahorro de energía, “modo silencioso” del proveedor, límites en batería, adaptador de baja potencia o un sensor/fan atascado.

Decisión: valida la fuente de energía y el plan de energía primero; sólo entonces persigue temáticas térmicas.

3) Rendimiento que varía mucho de un día a otro

Patrón: a veces genial, a veces terrible, sin cambios en la carga.

Probable causa: software en segundo plano, tareas de actualización de Windows, servicio de energía del proveedor que cambia modos, acumulación de polvo, temperatura ambiente o una configuración de docking/carga inestable.

Decisión: establece una medición repetible: misma fuente de energía, mismo modo, misma carga, misma temperatura ambiente.

4) Enchufado pero aún limitando mucho

Patrón: “modo AC” pero la potencia está limitada como en batería.

Probable causa: adaptador no reconocido, negociación USB-C PD a menor potencia, cable dañado o bug de firmware forzando la política de batería.

Decisión: confirma la potencia negociada y si la batería se está cargando bajo carga.

5) La CPU no es el cuello de botella

Patrón: las frecuencias están bien, pero las tareas siguen lentas.

Probable causa: presión de memoria, límites de E/S de almacenamiento, cifrado de disco en segundo plano o throttling térmico en el SSD.

Decisión: demuestra que la CPU está saturada antes de culpar a que “el TDP miente”.

Guion de diagnóstico rápido

Cuando alguien dice “este portátil es lento”, no empieces por repastar. No empieces por comprar una base de refrigeración. No empieces por una suite de benchmarks que toma una hora. Quieres un triage de 10 minutos que aisle el limitador dominante.

Primero: confirma la fuente de energía y la política

• ¿La máquina está en batería, en CA o en una docking?
• ¿Se está cargando realmente bajo carga?
• ¿El SO está en un plan de energía restrictivo?
• ¿El software del proveedor fuerza “silencioso” o “eco”?

Segundo: observa los límites mientras ejecutas una carga sostenida

• Observa la potencia del paquete de la CPU a lo largo del tiempo (no sólo el pico).
• Observa frecuencia y temperatura juntas.
• Busca indicadores de “límite de potencia” vs “throttle térmico”.

Tercero: comprueba el resto del sistema por el auténtico cuello de botella

• Presión de memoria y actividad de swap.
• Rendimiento y latencia de almacenamiento bajo carga.
• Uso de GPU si la carga se descarga allí.
• Tareas en segundo plano que roban tiempo de CPU.

Cuarto: decide si es una reparación o una incompatibilidad de producto

Si el portátil se comporta exactamente como fue diseñado (PL1 bajo por silencio), a veces puedes ajustar parámetros. Pero a menudo la “solución” es elegir un portátil diseñado para potencia sostenida. Cruento, pero más barato que semanas de frustración.

Tareas prácticas: comandos, salidas y decisiones

Estas son comprobaciones reales y ejecutables. Uso ejemplos en Linux porque son observables y scriptables. El método importa más que el SO.

Task 1: Identify CPU model and base characteristics

cr0x@server:~$ lscpu | sed -n '1,25p'
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Model name:                           13th Gen Intel(R) Core(TM) i7-13700H
CPU(s):                               20
Thread(s) per core:                   2
Core(s) per socket:                   14
CPU max MHz:                          5000.0000
CPU min MHz:                          400.0000

Qué significa: Confirma la CPU y la frecuencia máxima anunciada. Esto no te dice nada sobre el rendimiento sostenido, pero fija expectativas para el comportamiento de turbo.

Decisión: Si esto es una pieza “U” en un chasis delgado y esperas comportamiento de estación de trabajo, detente y reajusta expectativas antes de perseguir fantasmas.

Task 2: Confirm which driver and governor is active (Linux)

cr0x@server:~$ cpupower frequency-info | sed -n '1,40p'
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  hardware limits: 400 MHz - 5.00 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 5.00 GHz.
                  The governor "powersave" may decide which speed to use

Qué significa: Con intel_pstate, “powersave” suele ser el modo normal y aún permite turbo, pero puede verse influido por EPP/energy bias.

Decisión: Si estás diagnosticando rendimiento, fuerza temporalmente “performance” para eliminar una variable.

Task 3: Temporarily switch to performance governor (diagnostic)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Qué significa: Estás pidiendo al SO que favorezca el rendimiento. Esto no anula PL1/PL2 del firmware, pero ayuda a mostrar lo que la plataforma puede hacer.

Decisión: Si el rendimiento mejora mucho, tu problema es política, no refrigeración. Entonces decide si toleras el impacto en batería/ruido.

Task 4: Watch frequency and temperature in real time

cr0x@server:~$ sudo turbostat --quiet --interval 2
     CPU     Avg_MHz   Busy%   Bzy_MHz  TSC_MHz  CoreTmp  PkgTmp  PkgWatt
       -       3120    92.15     3385     1896     86.0    90.0    44.72
       -       2650    99.02     2675     1896     92.0    96.0    28.11
       -       2580    99.11     2600     1896     94.0    97.0    24.95

Qué significa: Puedes ver el patrón clásico: alta potencia del paquete inicialmente, luego una caída (a menudo hacia PL1), mientras la temperatura se aproxima al techo.

Decisión: Si PkgWatt cae mientras las temperaturas son altas, estás o bien limitado térmicamente o el firmware está imponiendo una potencia sostenida baja para evitar soak térmico.

Task 5: Run a sustained CPU load to expose PL1 behavior

cr0x@server:~$ stress-ng --cpu 0 --timeout 180s --metrics-brief
stress-ng: info:  [23110] dispatching hogs: 20 cpu
stress-ng: metrc: [23110] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [23110] cpu            3154210    180.00   1790.22    12.11     17523.39

Qué significa: Una carga sostenida de 3 minutos es suficiente para que muchos portátiles salgan de PL2 y se asienten en límites de estado estable.

Decisión: Combina esto con turbostat. Si ves una caída después de 28–60 segundos, esa es tu realidad sostenida.

Task 6: Check Intel RAPL energy counters (power telemetry)

cr0x@server:~$ sudo powercap-info -p intel-rapl
Zone 0
  Name: package-0
  Enabled: yes
  Energy: 879.23 J
  Max energy range: 262143.99 J
Zone 0 subzone 0
  Name: core
  Energy: 522.17 J
Zone 0 subzone 1
  Name: uncore
  Energy: 101.55 J
Zone 0 subzone 2
  Name: dram
  Energy: 87.49 J

Qué significa: Los contadores RAPL te permiten estimar la potencia media durante un intervalo tomando muestras de energía antes/después.

Decisión: Si la energía del paquete aumenta lentamente durante una carga sostenida, tu plataforma está imponiendo un techo de potencia bajo sin importar el “TDP”.

Task 7: Look for thermal and power limit messages in the kernel log

cr0x@server:~$ sudo dmesg | egrep -i 'thrott|thermal|pstate|rapl|power limit' | tail -n 15
intel_rapl_common: Found RAPL domain package
thermal thermal_zone7: critical temperature reached (105 C), shutting down
intel_pstate: turbo disabled by BIOS or unavailable on processor

Qué significa: Esto revela eventos duros: turbo deshabilitado, eventos térmicos críticos o problemas de configuración de plataforma.

Decisión: Si ves “turbo disabled by BIOS”, deja de ajustar en el SO. Tu limitador es la política de firmware.

Task 8: Inspect current thermal zones and temperatures

cr0x@server:~$ for z in /sys/class/thermal/thermal_zone*/type; do echo -n "$(basename $(dirname $z)) "; cat $z; done | head
thermal_zone0 x86_pkg_temp
thermal_zone1 acpitz
thermal_zone2 INT3400 Thermal

cr0x@server:~$ cat /sys/class/thermal/thermal_zone0/temp
94000

Qué significa: Las temperaturas a menudo están en miligrados Celsius. 94000 significa 94°C.

Decisión: Si la temperatura del paquete está cerca del punto de throttling con carga moderada, probablemente tienes un problema de refrigeración (polvo, fallo de ventilador, pasta degradada) o una curva de ventilador extremadamente conservadora.

Task 9: Check whether you’re swapping (memory pressure masquerading as CPU slowness)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            32Gi        29Gi       1.1Gi       1.2Gi       2.3Gi       1.9Gi
Swap:            8Gi       6.5Gi       1.5Gi

Qué significa: Un uso intensivo de swap puede hacer que “las tareas de CPU” parezcan lentas porque todo espera al almacenamiento.

Decisión: Si swap está activo durante builds, VMs o contenedores, tu “problema de TDP” puede ser en realidad “no hay suficiente RAM”.

Task 10: Confirm storage isn’t the bottleneck (NVMe)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (laptop) 	01/12/2026 	_x86_64_	(20 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.12    0.00    6.21   22.18    0.00   36.49

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1          92.0   8120.0     0.0    0.00   12.10    88.26    41.0   6240.0    18.33   152.20    1.22  96.00

Qué significa: Alto %iowait y %util cercano a saturado significa que el disco está ocupado; la CPU podría estar esperando.

Decisión: Si el I/O es el limitador, aumentar límites de potencia de CPU no ayudará. Arregla el almacenamiento (SSD más rápido, evita throttling térmico, reduce la amplificación de escritura) o reduce la carga de I/O.

Task 11: Check NVMe drive temperature (SSD throttling can look like CPU throttling)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i 'temperature|warning'
temperature                             : 72 C
warning_temp_time                       : 3
critical_temp_time                      : 0

Qué significa: SSD a 72°C con tiempo de advertencia sugiere que puede estar haciendo throttling intermitente, especialmente en portátiles delgados con mal flujo de aire sobre el SSD.

Decisión: Si el tiempo de advertencia sube durante builds, añade una almohadilla térmica/disipador o reduce escrituras sostenidas (por ejemplo, cambia el directorio de compilación a tmpfs si la RAM lo permite).

Task 12: Check for cgroup CPU throttling (containers make everything confusing)

cr0x@server:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/cpu.stat 2>/dev/null | head
usage_usec 928381223
user_usec  812332110
system_usec 116049113
nr_periods  22990
nr_throttled 1420
throttled_usec 91822111

Qué significa: Si nr_throttled es alto, el planificador está limitando el uso de CPU por cuotas de cgroup, no porque la CPU esté limitada por potencia.

Decisión: Arregla los límites de contenedores (Docker/Kubernetes CPU quota) antes de culpar a las térmicas del portátil.

Task 13: Check AC adapter / battery state (on Linux via upower)

cr0x@server:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 | egrep -i 'state|percentage|energy-rate|time to'
  state:               charging
  percentage:          83%
  energy-rate:         28.1 W
  time to full:        0.9 hours

Qué significa: Estado de carga positivo y una tasa de energía sensata indican que el adaptador está entregando suficiente potencia para ejecutar el sistema y cargar.

Decisión: Si el estado cambia a “discharging” bajo carga mientras está enchufado, tu adaptador/dock es un limitador. Mejora el adaptador o evita ese dock para cargas pesadas.

Task 14: Verify CPU idle behavior (background load stealing your turbo budget)

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:18:02 up  2:41,  1 user,  load average: 6.21, 5.90, 4.40
Tasks: 412 total,   3 running, 409 sleeping,   0 stopped,   0 zombie
%Cpu(s): 26.2 us,  6.3 sy,  0.0 ni, 63.1 id,  4.1 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :  31890.8 total,   1220.4 free,  29401.1 used,   1269.3 buff/cache
MiB Swap:   8192.0 total,   1581.2 free,   6610.8 used.   1820.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 4121 cr0x      20   0 5429812 617148  82192 R  182.3   1.9   5:21.83 chrome
 8892 cr0x      20   0 2916420 501120  61444 S   78.1   1.5   2:11.20 docker

Qué significa: CPU y presión de memoria en segundo plano pueden impedir estados profundos de reposo y reducir la reserva de turbo, especialmente en sistemas térmicamente limitados.

Decisión: Si el “idle” no está inactivo, arregla los ofensores en segundo plano antes de culpar al envelope de la CPU.

Tres microhistorias corporativas desde las trincheras de límites de potencia

Microhistoria 1: Un incidente causado por una suposición errónea

Un equipo desplegó una flota de “portátiles estándar para desarrolladores” para un nuevo sistema de builds interno que ejecutaba compilación local, pruebas unitarias y builds de contenedores. La decisión de compra se tomó con una rúbrica simple: CPU de última generación, “clase 45W”, 32GB RAM, buen teclado. Las máquinas parecían idénticas en papel. Procurement estaba encantado. Los ingenieros estaban… menos encantados.

En una semana, los tiempos de build divergieron. Algunos desarrolladores terminaron un build completo en un tiempo razonable; otros tardaron casi el doble. Las máquinas lentas no estaban rotas. No tenían malware. Ni siquiera estaban particularmente calientes. Simplemente estaban atascadas en un límite de potencia sostenida más bajo porque esas unidades eran una variante de chasis más delgada con un objetivo acústico más silencioso.

La suposición errónea fue sutil: “mismo modelo de CPU equivale a mismo rendimiento”. Esa suposición funcionaba en el mundo de sobremesa. Falló en el mundo de portátiles, porque el sobre térmico sostenido de la CPU era esencialmente una decisión del OEM. La etiqueta “45W” no describía lo que los portátiles podían sostener; describía lo que teóricamente la CPU podía configurarse para manejar.

La solución fue aburrida y cara: estandarizar en un modelo específico de portátil, no en un SKU de CPU, y calificarlo con una prueba de carga sostenida de 10 minutos como parte de la aceptación. También actualizaron el formulario interno de solicitud de hardware para incluir “potencia de paquete sostenida bajo carga”, porque es más difícil de manipular que “TDP”.

Microhistoria 2: Una optimización que se volvió contraproducente

Un ingeniero orientado al rendimiento decidió “arreglar” cargas tipo CI lentas en portátiles forzando modos de máximo rendimiento en toda la flota. El cambio se empujó como configuración: poner el governor en performance, desactivar ahorro agresivo de energía y mantener los ventiladores más proactivos. Los benchmarks cortos mejoraron inmediatamente y el ingeniero recibió algunos mensajes agradecidos.

Entonces llegó el contragolpe. El desgaste de baterías aumentó notablemente en un par de meses. Máquinas que solían durar jornadas largas necesitaban carga a mediodía. Algunos portátiles empezaron a calentarse incluso en idle, porque las tareas en segundo plano más el sesgo agresivo de rendimiento impedían que la CPU entrara en estados eficientes de bajo consumo. En un subconjunto de unidades, los rodamientos de los ventiladores empezaron a sonar desagradablemente antes de lo esperado.

La sorpresa mayor fue la experiencia de los desarrolladores: los portátiles se volvieron más ruidosos en áreas abiertas y la gente empezó a activar los “modos silenciosos” del proveedor para sobrellevarlo. Eso reintrodujo silenciosamente límites bajos de PL1 e inconsistencia en el rendimiento. La optimización creó un sistema de dos clases: quienes toleraban ruido obtenían velocidad, y el resto obtenía imprevisibilidad.

La lección: forzar el modo performance globalmente trata un síntoma (velocidad a corto plazo) e ignora la función objetivo del sistema (batería, acústica, térmicas, longevidad). El enfoque más correcto fue ofrecer un perfil documentado de “carga pesada” que los ingenieros pudieran activar cuando estuvieran enchufados, y medir rendimiento sostenido en lugar de perseguir turbo pico.

Microhistoria 3: Una práctica aburrida pero correcta que salvó el día

Un equipo de plataforma mantenía una lista interna de “portátiles con rendimiento conocido” para ingenieros que rutinariamente ejecutaban bases de datos locales, VMs y compiladores. La lista no mencionaba el TDP ni una vez. Especificaba modelos, versiones de BIOS, vatios del adaptador y una prueba de aceptación simple: ejecutar una carga sostenida de CPU de 10 minutos y registrar la potencia del paquete estabilizada, la frecuencia y la temperatura.

Cuando llegó un ciclo de renovación, el proveedor ofreció un modelo nuevo tentador: más delgado, más ligero, misma generación de CPU y una etiqueta brillante de “alto rendimiento”. Pasó sin problemas las demos cortas. El equipo de plataforma aún ejecutó la prueba de aceptación, porque eso era lo que siempre hacían.

El nuevo modelo subía duro, luego se asentaba en una potencia sostenida mucho más baja que el modelo anterior. No era catastrófico; simplemente no era la herramienta adecuada para ingenieros que viven en compiladores y VMs. La explicación del proveedor fue predecible: objetivos acústicos, limitaciones del chasis y una curva de ventilador diferente. Nada estaba “mal”.

Porque el equipo había institucionalizado una prueba aburrida, detectaron la discrepancia antes de que se emitieran órdenes de compra. Aprobaban el modelo para uso general de oficina, pero conservaron la línea anterior más gruesa (o una alternativa) para usuarios intensivos. Sin drama. Sin salones de guerra por builds lentos. Solo una evasión silenciosa del dolor.

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

1) “Mi CPU es 45W pero sólo consume ~25W bajo carga”

Síntoma: La potencia del paquete se estabiliza muy por debajo de la clase anunciada.

Causa raíz: El OEM fijó PL1 bajo para cumplir objetivos de ruido/temperatura de piel, o la fuente de energía (adaptador/dock) no puede entregar suficiente margen.

Solución: Valida con el adaptador del OEM; comprueba el estado de carga bajo carga; si PL1 está capado por firmware, tu única solución real es otro modelo de portátil o un modo de rendimiento del proveedor que eleve PL1.

2) “Es rápido durante 30 segundos, luego lento para siempre”

Síntoma: Altas frecuencias iniciales, luego una meseta estable más baja.

Causa raíz: Expira la ráfaga PL2 (ventana Tau), luego la CPU cae a PL1; a veces el soak térmico fuerza límites incluso más bajos.

Solución: Mide la potencia sostenida después de 3–10 minutos; elige hardware según esa meseta, no según la primera pasada de un benchmark.

3) “En batería, mi portátil se convierte en otra máquina”

Síntoma: Gran caída de rendimiento sin enchufe.

Causa raíz: Límites de descarga de batería, firmware conservador en batería o cambio de plan del SO.

Solución: Si necesitas rendimiento en batería, compra sistemas conocidos por permitir mayor potencia en batería. De lo contrario, acepta que el modo batería es para eficiencia y planifica el flujo de trabajo acorde.

4) “Enchufado, pero aún lento y sin cargar”

Síntoma: El porcentaje de batería disminuye lentamente mientras está conectado.

Causa raíz: Vatios del adaptador insuficientes, USB-C PD negociado a menos de lo esperado o dock que no puede abastecer bajo carga.

Solución: Usa el adaptador de alta potencia del OEM; reemplaza el cable; evita docks de baja potencia para cargas sostenidas.

5) “La temp de la CPU está bien, pero las frecuencias siguen bajas”

Síntoma: Temperaturas por debajo del punto de throttling, sin embargo frecuencia/potencia bajas.

Causa raíz: Ejecución de límites por potencia, EPP/energy bias, “modo silencioso” del proveedor o cuotas de cgroup.

Solución: Comprueba la política de potencia y el throttling por cgroups; verifica que el turbo no esté deshabilitado en BIOS; luego considera los perfiles de rendimiento del proveedor.

6) “Repasté y apenas ayudó”

Síntoma: Temperaturas pico más bajas pero mismo rendimiento sostenido.

Causa raíz: El rendimiento sostenido está limitado por potencia, no por térmicas; PL1 del OEM es el techo.

Solución: Deja de tratar la refrigeración como la única palanca. Mide el comportamiento de PL1; si está capado, acéptalo o cambia de hardware.

7) “Los benchmarks lucen genial, el trabajo real es mediocre”

Síntoma: Altas puntuaciones en pruebas cortas, lento en compilaciones/renders largos.

Causa raíz: Los benchmarks favorecen ráfagas; tu carga es sostenida y calienta el chasis.

Solución: Usa benchmarks sostenidos (ejecuciones en bucle, cargas de 10 minutos) y monitoriza la potencia del paquete y las frecuencias estabilizadas.

8) “Actualizar CPU no ayudó mucho a mi carga”

Síntoma: La CPU más nueva se siente similar.

Causa raíz: La carga está limitada por I/O, memoria o GPU; o el nuevo portátil tiene límites sostenidos más bajos a pesar del silicio más moderno.

Solución: Mide cuellos de botella (iowait, swap, utilización GPU). Si la potencia sostenida es menor, compraste una historia más delgada, no una máquina más rápida.

Listas de verificación / plan paso a paso

Lista A: Comprar un portátil para trabajo sostenido de CPU

1. Elige por modelo, no por SKU de CPU. La misma CPU en distintos chasis puede comportarse de forma muy distinta.
2. Exige números sostenidos. Busca reseñas/pruebas que muestren bucles de varios minutos y potencia estabilizada.
3. Prefiere refrigeración más gruesa para cargas largas. Cámara de vapor, doble ventilador, salida adecuada. El peso es una característica de rendimiento.
4. Comprueba la potencia del adaptador. Asegura que la fuente pueda cubrir CPU+GPU+carga. USB-C PD es cómodo, no mágico.
5. Confirma expectativas en batería. Si realmente lo necesitas, pruébalo.
6. Atento a modos de rendimiento del proveedor. Algunos son controles honestos; otros son envoltorios UI para “hazlo ruidoso”.
7. Planifica la refrigeración del SSD. Builds sostenidos y VMs pueden calentar NVMe hasta hacer throttling.
8. No te obsesiones con gráficos de una sola pasada. Pregunta: ¿qué pasa en el minuto 8?

Lista B: Diagnosticar un portátil existente que “debería ser más rápido”

1. Normaliza variables: adaptador OEM, enchufado, ambiente estable, tapa abierta, nada de calor por manta en la cama.
2. Define una política de energía conocida (modo performance temporal) y desactiva “modo silencioso” del proveedor.
3. Ejecuta una carga sostenida de CPU por 3–10 minutos.
4. Observa: potencia del paquete, frecuencia, temperatura, comportamiento del ventilador.
5. Decide: limitado por potencia vs limitado térmicamente vs otro cuello de botella (RAM/SSD/cgroups).
6. Si es térmico: limpia rejillas/ventiladores, verifica que los ventiladores giren, revisa pasta/pads, considera una base refrigerante como solución temporal.
7. Si es límite de potencia por diseño: evalúa opciones de firmware; de lo contrario deja de gastar tiempo y acepta el envelope del producto.
8. Si es “otro cuello de botella”: arregla presión de RAM, saturación de I/O o cuotas de contenedores.

Lista C: Fijar expectativas para equipos (edición empresarial)

1. Estandariza en modelos específicos. No “cualquier i7”. Un modelo, baseline de BIOS, adaptador baseline.
2. Define una prueba de aceptación. Carga sostenida + potencia del paquete estabilizada observada.
3. Documenta modos de potencia. “Silencioso”, “equilibrado”, “rendimiento” y cuándo usarlos.
4. Proporciona una capa de workstation. Algunos ingenieros necesitan rendimiento sostenido; fingir que no importa desperdicia dinero en nómina.
5. Instrumenta el dolor del desarrollador. Rastrea tiempos de build y presión de recursos; trátalo como latencia en producción.

Preguntas frecuentes

1) ¿Es el TDP la potencia máxima consumida?

No. En CPUs móviles modernas, las ráfagas cortas pueden exceder mucho la “clase TDP”. La potencia sostenida también puede estar por debajo, dependiendo de los límites del OEM.

2) ¿Por qué dos portátiles con la misma CPU rinden distinto?

Porque el OEM fija límites de potencia sostenida y de ráfaga, curvas de ventilador y a veces soluciones térmicas diferentes. El modelo de CPU es solo una entrada al rendimiento.

3) ¿Qué importa más que el TDP para trabajo sostenido?

La potencia del paquete y la frecuencia estabilizadas después de varios minutos de carga, además de si el sistema está limitado por potencia o por térmicas en ese estado estable.

4) Si subo límites de potencia, ¿siempre tendré más rendimiento?

Sólo si tienes margen térmico y entrega de potencia adecuada. Si no, obtendrás temperaturas más altas, ventiladores más ruidosos y luego throttling de vuelta al mismo lugar.

5) ¿Por qué mi portátil hace throttling incluso cuando la temp de la CPU no está en el máximo?

Porque los límites de potencia pueden fijar el rendimiento antes de alcanzarse los límites térmicos. Además, otros sensores (VRM, temperatura de piel) pueden disparar throttles a nivel de plataforma.

6) ¿Ayuda el undervolting?

A veces. Reducir voltaje puede bajar la potencia a una frecuencia dada, lo que puede mejorar las frecuencias sostenidas dentro del mismo envelope térmico/potencia. En muchas plataformas modernas, el undervolting puede estar restringido por firmware por razones de seguridad/estabilidad.

7) ¿“15W” vs “28W” es una diferencia real?

Puede ser enorme para cargas sostenidas, pero sólo si el portátil realmente permite esos límites sostenidos. Algunos chips “capaces de 28W” se envían en portátiles que sostienen mucho menos bajo carga.

8) ¿Cuál es la prueba más simple que puedo ejecutar para ver la capacidad sostenida real de mi portátil?

Ejecuta una tensión de CPU de 3–10 minutos (o tu carga real) mientras observas la potencia del paquete y la frecuencia a lo largo del tiempo. La meseta es tu realidad.

9) ¿Por qué los revisores y las hojas de especificaciones siguen enfocándose en el TDP?

Porque es un número único que cabe en una tabla comparativa. El comportamiento sostenido real es una curva, y las curvas son inconvenientes para marketing y filtros de compra.

10) ¿Debería comprar un portátil gaming para trabajo de CPU?

No automáticamente, pero muchos chasis de gaming tienen mejor refrigeración sostenida y presupuestos de potencia más altos. Si valoras rendimiento sostenido sobre portabilidad y ruido, puede ser una elección racional.

Conclusión: próximos pasos que no desperdiciarán tu dinero

Deja de comprar portátiles como si fueran CPUs de sobremesa en cajas diferentes. El TDP no es un contrato. En portátiles, es más bien una sugerencia que se enmienda por firmware, refrigeración y estrategia de producto.

Qué hacer a continuación:

1. Mide tu propia realidad: ejecuta una carga sostenida y observa la potencia del paquete, la frecuencia y la temperatura hasta que se estabilicen.
2. Clasifica el limitador: política de potencia, cap de PL1 del OEM, saturación térmica, adaptador/dock o cuellos de botella no CPU como RAM/SSD.
3. Ajusta sólo lo que vale la pena ajustar: arregla carga de fondo, confirma vatios del adaptador, limpia vías de refrigeración. No repastes un portátil que está simplemente capado por firmware.
4. Al comprar: elige modelos probados para sostener la potencia que necesitas y trata “clase TDP” como una etiqueta familiar aproximada, no como una garantía de rendimiento.

La CPU puede ser excelente. El portátil aún puede mentir. Tu trabajo es hacerla confesar con mediciones.