Límites de potencia y Boost: por qué tu GPU parece tener mente propia

Compraste una GPU que anuncia un reloj de boost “hasta” cierto valor heroico. Luego ejecutas una carga real, ves cómo los relojes fluctúan como un metrónomo con cafeína, y el rendimiento queda en cualquier punto entre “aceptable” y “¿por qué pago por esto?”. Bienvenido al rendimiento moderno de GPU: se negocia, no se garantiza.

En producción, esto no es una curiosidad de frikis. Los topes de potencia, las térmicas y los gestores de boost deciden si cumples tu SLA, si pierdes una ventana de procesamiento por lotes o si pasas el fin de semana demostrando a finanzas que “nada cambió” es una mentira.

El contrato real: “hasta” hace mucho trabajo

La mayoría de la gente trata una GPU como un motor de frecuencia fija: compras un número de modelo y obtienes una velocidad. Pero las GPUs modernas se comportan más como una flota de pequeños gobernadores negociando con la física y el firmware. El reloj de boost publicitado es un techo, no una promesa, y la distancia entre el “techo” y la “realidad” la decide una pila de límites:

• Límite de potencia (W): el presupuesto que la tarjeta puede gastar.
• Límite de voltaje (V): lo que el silicio y los VRM toleran en ese momento.
• Límite térmico (°C): lo que la refrigeración puede disipar y cuán agresivo es el firmware para protegerse.
• Límites de corriente/VRM: la realidad eléctrica de la placa, a menudo invisible a menos que tengas herramientas del proveedor.
• Características de la carga de trabajo: distintos kernels estresan distintas partes del chip; “100% de utilización” no es una sola cosa.

Así que tu GPU no tiene una mente propia. Tiene restricciones. Lo que ocurre es que esas restricciones cambian con el tiempo, y el lazo de control reacciona más rápido de lo que tus paneles de monitorización interpretan.

Hechos interesantes y contexto histórico (la versión corta y concreta)

1. Los relojes boost se hicieron mainstream porque las frecuencias fijas desperdiciaban eficiencia. El silicio varía; la potencia y las térmicas varían; el control dinámico vende mejor rendimiento “típico”.
2. GPU Boost de NVIDIA (era Kepler) convirtió los relojes en oportunistas. En vez de “una frecuencia”, obtuviste un rango de frecuencias moduladas por el margen disponible.
3. Las GPUs de centro de datos no escaparon al boost; solo lo envolvieron en política. Los límites de potencia, el modo persistente y los application clocks existen porque los operadores pidieron previsibilidad.
4. Los “power viruses” son reales. Ciertas mezclas de instrucciones pueden consumir potencia desproporcionada; los proveedores ajustan los gobernadores en parte para sobrevivir cargas de caso peor.
5. La ranura PCIe y los conectores de 8 pines son contratos de potencia físicos. Los socios de placa no pueden “tirar de todo” sin respetar lo que los conectores y las pistas pueden entregar de forma segura.
6. “TDP” no es una unidad universal de verdad. Es un objetivo de diseño y una simplificación de marketing; lo que importa operativamente es la potencia real de la placa y el comportamiento sostenido.
7. La temperatura de la memoria se volvió un problema de primera clase con GDDR6X y pilas HBM de alta densidad. Tu núcleo puede estar bien mientras la memoria se cocina en silencio y activa throttling.
8. Las curvas de ventiladores pasaron de objetivos acústicos a objetivos de fiabilidad. Muchos perfiles “silenciosos” permiten que se desarrollen puntos calientes; los centros de datos prefieren un flujo de aire aburrido antes que un ruido agradable.

Boost no es magia; es un lazo de control

El comportamiento de boost es un controlador de realimentación. La GPU mide un conjunto de sensores—consumo de energía, temperaturas, rieles de voltaje, a veces corriente inferida—y elige el estado de rendimiento estable más alto dentro de los límites. Esa elección se reevalúa continuamente. Si esperas que el reloj sea una línea plana, esperas que un termostato sea un interruptor de luz.

Qué está optimizando el boost

El algoritmo de boost normalmente intenta maximizar el rendimiento respetando:

• el límite de potencia configurado,
• los objetivos térmicos,
• márgenes de estabilidad voltaje/frecuencia,
• las restricciones de seguridad de la placa (temperaturas VRM, límites de corriente),
• y a veces reglas acústicas mediante curvas de ventilador.

Si tu carga es corta y con picos, el boost subirá. Si es larga y sostenida, el boost se estabilizará. El primer minuto puede parecer asombroso. Los siguientes 30 minutos cuentan la verdad.

Una cita para mantenerte honesto

Idea parafraseada (atribuida a W. Edwards Deming): “No puedes gestionar lo que no mides.” En el mundo GPU: no puedes ajustar lo que no atribuyes.

Dos tipos de “se ralentizó”

Hay dos modos amplios de fallo que se confunden:

• Estrangulamiento de reloj (throttling): la GPU reduce intencionalmente la frecuencia por límites de potencia/térmicos/voltaje.
• Inanición del pipeline: la GPU podría ir más rápido, pero espera por memoria, transferencias PCIe, planificación de CPU, disco o red. Esto suele aparecer como “baja utilización” y hace que la gente persiga el problema equivocado.

Regla seca y divertida: una GPU al 99% de utilización aún puede estar aburrida; solo está aburrida de forma muy consistente.

La pila de límites: potencia, voltaje, temperatura y la “realidad de la placa”

Límite de potencia: el gran control evidente que oculta aristas

El límite de potencia es el concepto más sencillo: capar la potencia de la placa en X vatios. Pero interactúa con todo lo demás. Si limitas demasiado la potencia, la frecuencia cae para mantenerse dentro del presupuesto. Si la elevas, podrías obtener más rendimiento—hasta que las térmicas o la estabilidad de voltaje se conviertan en el nuevo limitador. En la práctica, estás escogiendo qué limitador quieres alcanzar primero.

En producción, los límites de potencia suelen ser decisiones políticas: “tenemos 2,4 kW por servidor,” “necesitamos N GPUs por rack,” “no podemos disparar los interruptores durante un lote.” Esas son restricciones legítimas. El error es esperar el mismo rango de rendimiento después de haber cambiado la física.

Térmicas: no solo “temperatura GPU”, sino puntos calientes y memoria

La mayoría revisa la “temperatura GPU” y pasa a otra cosa. Eso es como revisar el termostato del vestíbulo y declarar el edificio entero en buen estado. Las tarjetas modernas tienen puntos calientes (temperatura de unión), temperaturas de memoria, temperaturas de VRM y a veces sensores separados para distintas partes del paquete. El núcleo puede mostrar 70°C mientras un punto caliente alcanza el umbral de throttling.

Además: la refrigeración es un sistema. Flujo de aire de la caja, filtros de polvo, curvas de ventilador, pads térmicos y la temperatura de entrada del rack importan. Tu GPU no ve tu orden de compra. Ve calor.

Voltaje y calidad del silicio: por qué dos GPUs “idénticas” se comportan distinto

Incluso dentro de un mismo SKU, los chips varían. Una GPU alcanza cierta frecuencia a menor voltaje; otra necesita más. Más voltaje significa más potencia. Más potencia significa más calor. Así que dos tarjetas con el mismo límite de potencia pueden llegar a relojes de estado estable distintos. Eso no es “defectuoso.” Es la realidad del binning filtrándose en tus gráficas.

Límites de placa: VRMs, conectores y salvaguardas del firmware

El dado de la GPU es solo parte de la historia. Los reguladores de voltaje de la placa (VRMs) y la ruta de entrega de potencia tienen límites. Cuando los VRMs se calientan, algunas tarjetas reducen potencia o frecuencia para protegerse. Puede que no obtengas una alerta bonita. Recibirás una caída “misteriosa” del rendimiento después de 10–20 minutos.

Y sí, el firmware de tu GPU es conservador a propósito. La alternativa es un departamento de garantías que no puede dormir.

Por qué los relojes y el rendimiento fluctúan (incluso cuando jurarías que no cambió nada)

1) Cambios de fase en la carga de trabajo

Los trabajos de entrenamiento y las canalizaciones de render tienen fases: carga de datos, aumentos, computación, sincronización. Algunas fases son intensivas en cómputo y golpean límites de potencia. Otras son intensivas en memoria y golpean el ancho de banda. Otras están limitadas por la CPU y la GPU queda esperando. Si trazas relojes sin correlacionar con la actividad de los kernels o la utilización, interpretarás el comportamiento normal de fases como un “problema”.

2) Temperatura ambiente y variación del aire de entrada

Los centros de datos no son utopías termodinámicas. Unos pocos grados más en el aire de entrada pueden ser la diferencia entre sostener un bin de boost o alcanzar un objetivo térmico. Si tu rack está cerca de una trayectoria de retorno o una fuga de pasillo caliente, tu GPU “se ralentiza aleatoriamente” en la hora punta de la instalación.

3) Política de curva de ventilador (acústica vs rendimiento)

Las tarjetas de consumo suelen priorizar el silencio. El silencio es encantador hasta que se convierte en una estrategia de throttling. En servidores, normalmente quieres lo opuesto: refrigeración agresiva y predecible para que tu rendimiento en estado estable sea estable. Si te importa el rendimiento, establece una política de ventilador que te haga impopular en oficinas abiertas.

4) La aplicación del límite de potencia se promedia, no es instantánea

Los límites de potencia suelen aplicarse sobre un intervalo de control. Los picos cortos pueden sobrepasar y luego “pagarse” con una caída. Eso puede crear oscilación: la frecuencia sube, la potencia sobrepasa, el gobernador reduce, repetir. Lo verás como relojes entrecortados y tiempos de cuadro desiguales o varianza en tiempos por paso.

5) Dominios de potencia compartidos y contención multi-GPU

En un servidor denso, varias GPUs comparten la capacidad de la PSU, a veces zonas de refrigeración, y siempre la realidad térmica de la instalación. Una GPU que calienta el chasis puede degradar a sus vecinas. Además, “misma configuración del servidor” no es lo mismo que “mismo flujo de aire,” especialmente si el ventilador de una GPU es ligeramente menos efectivo o una cubierta está mal asentada.

6) Actualizaciones de controladores y firmware

Los controladores pueden cambiar el comportamiento de boost, el reporte de potencia y las políticas térmicas. Las actualizaciones de firmware pueden cambiar tablas de potencia. Si tratas a los controladores como “solo software”, te llevarás sorpresas. Los controladores son parte del sistema de control.

Chiste corto #1: Una actualización de driver es como una mejora de rendimiento gratis—hasta que es una degradación de rendimiento gratis con mejores notas de lanzamiento.

Guía rápida de diagnóstico

Si el rendimiento es inconsistente, no empieces con “ajustes.” Empieza por la atribución. Este es el camino más corto que he encontrado que funciona cuando suena el pager.

Primero: determina si estás limitado por cómputo, potencia o si estás esperando

1. Revisa utilización, relojes y potencia durante el periodo lento. Si la utilización es alta y la potencia está cerca del límite, estás limitado por potencia. Si la utilización es alta y la temperatura está cerca del objetivo, estás limitado por térmicas. Si la utilización es baja, probablemente estás esperando por otra cosa.
2. Compara telemetría de “ejecución buena” vs “ejecución mala” en el mismo host si es posible. Buscas qué cambió: consumo de potencia, temperaturas, contadores de errores, ancho de banda PCIe, tiempo robado de CPU, rendimiento de disco.
3. Determina el motivo del limitador (potencia vs térmico vs fiabilidad). En NVIDIA, esto a menudo se mapea a “PerfCap Reason.” En AMD, lo inferirás por sensores SMI y comportamiento de relojes.

Segundo: valida rápidamente la capa física

1. ¿El flujo de aire del chasis es correcto? RPM de ventiladores, temperatura de entrada, polvo, cubiertas, paneles cegados. Los problemas de refrigeración se hacen pasar por “rendimiento aleatorio”.
2. ¿La PSU/entrada de energía es estable? Las limitaciones de potencia a nivel de servidor pueden sujetar GPUs sin avisar amablemente.
3. ¿El enlace PCIe está sano? Un enlace degradado a x8 o Gen3 puede perjudicar ciertas cargas y causar bloqueos raros.

Tercero: comprueba políticas de software y planificación

1. Configuraciones de gestión de energía (persistence, application clocks, power cap). La mala configuración es común, especialmente tras imágenes o cambios de orquestación.
2. Restricciones de contenedores/VM (particiones MIG, cgroups, límites del plugin de dispositivo). A veces “perdiste rendimiento” porque obtuviste un slice diferente del hardware.
3. Interacciones térmicas/energéticas con otros tenants en el mismo host. Vecinos ruidosos existen también en la física.

Tareas prácticas: comandos, salidas y qué significa la salida

Estas son tareas reales que puedes ejecutar hoy en hosts Linux. Cada una incluye (1) el comando, (2) una salida representativa, y (3) la decisión que tomas basada en ella. El objetivo es operativo: aislar el limitador y luego elegir la solución de menor riesgo.

Task 1: Snapshot de potencia, relojes y utilización GPU (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,uuid,pstate,clocks.sm,clocks.mem,temperature.gpu,power.draw,power.limit,utilization.gpu --format=csv
name, uuid, pstate, clocks.sm [MHz], clocks.mem [MHz], temperature.gpu, power.draw [W], power.limit [W], utilization.gpu [%]
NVIDIA A10, GPU-6b7..., P0, 1680, 6251, 74, 142.31, 150.00, 98

Significado: Estás cerca del límite de potencia (142/150 W) con alta utilización en P0. Si el rendimiento es bajo, probablemente estás limitado por potencia, no por “driver roto”.

Decisión: Si las térmicas están bien y el presupuesto de la PSU lo permite, aumenta ligeramente el límite de potencia (o deja de esperar relojes pico bajo un límite estricto). Si el límite está impuesto por política, enfócate en perf-per-watt (undervolt, programación de cargas o fusión de kernels).

Task 2: Identificar por qué la GPU está limitando rendimiento (PerfCap reason)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,120p'
==============NVSMI LOG==============

Performance State                      : P0
Clocks Throttle Reasons
    Idle                               : Not Active
    Applications Clocks Setting         : Not Active
    SW Power Cap                        : Not Active
    HW Slowdown                         : Not Active
    HW Thermal Slowdown                 : Not Active
    HW Power Brake Slowdown             : Not Active
    Sync Boost                          : Not Active
    SW Thermal Slowdown                 : Not Active
    Display Clock Setting               : Not Active

Significado: No hay razones de throttling activas ahora mismo. Si aun así ves bajo rendimiento, el cuello de botella probablemente no sea un throttle duro; puede que estés limitado por memoria, CPU o I/O.

Decisión: Deja de “arreglar relojes”. Pasa a perfilar (desglose de utilización, tráfico PCIe, saturación de CPU) y revisa la canalización de datos.

Task 3: Vigilar jitter de potencia/reloj en el tiempo (rápido y sucio)

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,power.draw,clocks.sm,temperature.gpu,utilization.gpu --format=csv -l 1 | head -n 8
timestamp, power.draw [W], clocks.sm [MHz], temperature.gpu, utilization.gpu [%]
2026/01/13 09:21:01, 148.22, 1710, 78, 99
2026/01/13 09:21:02, 149.87, 1695, 79, 99
2026/01/13 09:21:03, 150.02, 1665, 80, 99
2026/01/13 09:21:04, 149.95, 1635, 81, 99
2026/01/13 09:21:05, 149.90, 1605, 82, 99
2026/01/13 09:21:06, 149.88, 1590, 83, 99

Significado: La potencia está al tope mientras la temperatura sube; los relojes descienden en escalones. Ese es el comportamiento clásico “tope de potencia + térmicas crecientes”.

Decisión: Mejora la refrigeración o reduce la potencia por unidad de trabajo (undervolt u optimiza kernels). Aumentar el límite de potencia no ayudará si además te acercas a límites térmicos.

Task 4: Verificar límite de potencia configurado vs min/máx soportados (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d POWER | sed -n '1,120p'
Power Readings
    Power Management                    : Supported
    Power Draw                          : 142.31 W
    Power Limit                         : 150.00 W
    Default Power Limit                 : 150.00 W
    Enforced Power Limit                : 150.00 W
    Min Power Limit                     : 60.00 W
    Max Power Limit                     : 180.00 W

Significado: La tarjeta puede llegar a 180 W, pero estás limitado a 150 W (por defecto). Si esperabas más rendimiento, tu expectativa está desalineada con la política configurada.

Decisión: Si tu rack/servidor admite más potencia y refrigeración, aumenta a un valor probado. Si no, ajusta para eficiencia y acepta relojes menores.

Task 5: Fijar un límite de potencia (NVIDIA) y verificar que se aplicó

cr0x@server:~$ sudo nvidia-smi -pl 170
Power limit for GPU 00000000:65:00.0 was set to 170.00 W from 150.00 W.

cr0x@server:~$ nvidia-smi --query-gpu=power.limit,power.draw --format=csv
power.limit [W], power.draw [W]
170.00, 156.04

Significado: El nuevo límite se aplicó. Si los relojes aumentan y las térmicas se mantienen controladas, compraste rendimiento con vatios.

Decisión: Ejecuta una prueba sostenida larga. Si el rendimiento mejora pero suben las tasas de error o desaparece el margen térmico, vuelve atrás y busca una optimización más segura (undervolt, flujo de aire o planificación).

Task 6: Comprobar ancho/velocidad del enlace PCIe (NVIDIA vía nvidia-smi)

cr0x@server:~$ nvidia-smi -q -d PCI | sed -n '1,140p'
PCI
    Bus                               : 00000000:65:00.0
    PCIe Generation
        Max                           : 4
        Current                       : 3
    Link Width
        Max                           : 16x
        Current                       : 8x

Significado: Esperabas Gen4 x16 pero estás ejecutando Gen3 x8. Eso puede destrozar cargas pesadas en transferencias de datos y causar “subutilización” de la GPU que parece throttling.

Decisión: Revisa la configuración del BIOS, el asiento del riser, la bifurcación de lanes y si otro dispositivo robó lanes. Arregla PCIe antes de tocar relojes.

Task 7: Confirmar driver del kernel y modo persistente (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=driver_version,persistence_mode --format=csv
driver_version, persistence_mode
550.54.14, Disabled

Significado: El modo persistente está deshabilitado. Eso puede añadir latencia y provocar churn de relojes/pstates entre trabajos, especialmente en tareas de corta duración.

Decisión: En nodos de cómputo dedicados, habilita persistence mode para reducir variabilidad. En escritorios compartidos, considera los trade-offs.

cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:65:00.0.

Task 8: Forzar application clocks (donde esté soportado) para previsibilidad

cr0x@server:~$ nvidia-smi -q -d SUPPORTED_CLOCKS | sed -n '1,80p'
Supported Clocks
    Memory                             : 6251 MHz
        Graphics                       : 1710 MHz
        Graphics                       : 1680 MHz
        Graphics                       : 1650 MHz

cr0x@server:~$ sudo nvidia-smi -ac 6251,1680
Applications clocks set to "(MEM 6251, SM 1680)" for GPU 00000000:65:00.0

Significado: Has cambiado boost oportunista por relojes estables (dentro de límites de potencia/térmicos). Esto reduce la variabilidad entre ejecuciones en muchos trabajos por lotes.

Decisión: Úsalo para trabajos de producción que valoran previsibilidad más que picos máximos. Valida térmicas y tasas de error.

Task 9: Revisar errores ECC que se correlacionen con throttling o reintentos

cr0x@server:~$ nvidia-smi -q -d ECC | sed -n '1,120p'
ECC Mode
    Current ECC                        : Enabled
ECC Errors
    Volatile
        Single Bit
            Device Memory              : 0
        Double Bit
            Device Memory              : 0
    Aggregate
        Single Bit
            Device Memory              : 12
        Double Bit
            Device Memory              : 0

Significado: Has visto errores corregidos históricamente. No son necesariamente fatales, pero pueden correlacionarse con térmicas marginales, hardware envejecido o ajustes demasiado agresivos.

Decisión: Si los errores aumentan durante periodos de alta potencia/térmicos, reduce relojes/potencia, mejora la refrigeración y considera chequeos de salud de hardware o políticas de RMA.

Task 10: Comprobar relojes/potencia/temperaturas en GPUs AMD (herramientas ROCm)

cr0x@server:~$ rocm-smi --showtemp --showpower --showclocks --showuse
===================== ROCm System Management Interface =====================
GPU  Temp   AvgPwr  SCLK     MCLK     GPU%  
0    79.0c  262.0W  1720Mhz  1200Mhz  97%   

Significado: Alta utilización, alta potencia y temperaturas en los altos 70s. Si los relojes descienden con el tiempo, probablemente te acercas a un límite térmico o de potencia.

Decisión: Revisa temperaturas de puntos calientes/memoria si están disponibles, luego ajusta políticas de ventilador/potencia o mejora el flujo de aire del chasis.

Task 11: Validar presión y planificación de CPU (no culpes a la GPU por problemas de CPU)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (server) 	01/13/2026 	_x86_64_	(64 CPU)

09:24:01     CPU    %usr   %nice    %sys %iowait   %irq   %soft  %steal  %idle
09:24:02     all   62.10    0.00   12.55    8.31   0.00    1.22    0.00  15.82
09:24:02      7   98.00    0.00    1.00    0.00   0.00    0.00    0.00   1.00
09:24:02     19   97.00    0.00    2.00    0.00   0.00    0.00    0.00   1.00

Significado: Algunas CPUs están cercanas al 100%. Si tu canalización es intensiva en CPU (preparación de datos, compresión, aumentos), la GPU puede sufrir inanición y mostrar dips de utilización periódicos.

Decisión: Aumenta la asignación de CPU, fija hilos de forma sensata, reduce el trabajo por muestra en CPU o traslada preprocesos a la GPU.

Task 12: Identificar cuellos de botella de I/O (almacenamiento o red) que parecen “la GPU no hace boost”

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server) 	01/13/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          41.12    0.00   10.44   18.90    0.00   29.54

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         220.0  35200.0     0.0    0.0    8.90   160.0     40.0   5120.0    3.20   2.10  92.0

Significado: Alto iowait y ~92% de utilización del dispositivo. Tu loader de datos puede estar dejando a la GPU sin datos, causando dips de utilización y relojes promedio más bajos.

Decisión: Arregla I/O primero: cachea datasets localmente, aumenta paralelismo de lectura con cuidado, prefetch, usa tiers de almacenamiento más rápidos o reduce lecturas por paso.

Task 13: Detectar problemas térmicos vía sensores del sistema (ventiladores y chasis)

cr0x@server:~$ sensors | sed -n '1,120p'
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +86.0°C  (high = +90.0°C, crit = +100.0°C)

nvme-pci-0100
Adapter: PCI adapter
Composite:    +79.9°C  (low  =  -0.1°C, high = +84.8°C)

ipmi_si-isa-0000
Adapter: ISA adapter
System Fan1:  9800 RPM
System Fan2:  9600 RPM

Significado: Las temperaturas del sistema y del NVMe están altas; los ventiladores ya están al máximo. Si las GPUs hacen throttling, puede ser por flujo de aire del chasis o temperatura de entrada, no “la GPU”.

Decisión: Revisa el flujo de aire del rack, paneles cegados, filtros obstruidos y si el servidor está tomando aire del pasillo caliente.

Task 14: Verificar limitación de potencia a nivel de servidor (IPMI)

cr0x@server:~$ sudo ipmitool dcmi power reading
    Instantaneous power reading:                   980 Watts
    Minimum during sampling period:                740 Watts
    Maximum during sampling period:               1080 Watts
    Average power reading over sampling period:    945 Watts

Significado: El consumo del servidor está cerca de lo que muchas PSUs/alimentaciones de rack pueden tolerar. Algunas plataformas imponen límites o comportamiento de “freno de potencia” al acercarse a límites.

Decisión: Confirma políticas de potencia en BIOS/firmware. Si la plataforma está frenando por potencia bajo carga, los ajustes a nivel GPU no estabilizarán el rendimiento hasta que abordes los presupuestos de potencia de la plataforma.

Task 15: Asegurarte de que nadie fijó un límite de potencia bajo por accidente (persistencia y scripts de arranque)

cr0x@server:~$ grep -R --line-number "nvidia-smi -pl" /etc /usr/local 2>/dev/null | head
/etc/systemd/system/gpu-tune.service:9:ExecStart=/usr/bin/nvidia-smi -pl 120

Significado: Hay una unidad systemd forzando un cap de 120 W. Eso explica tu regresión de rendimiento “repentina” tras el aprovisionamiento.

Decisión: Arregla la fuente de la verdad en gestión de configuraciones. No “hotfixees” un host y esperes que permanezca arreglado.

Tres mini-historias corporativas desde las trincheras

Mini-historia #1: El incidente causado por una suposición incorrecta

Desplegaron una nueva tanda de nodos GPU para entrenamiento nocturno de modelos. Mismo SKU de GPU, misma versión de driver, misma imagen de contenedor. La primera semana pareció bien. Luego llegó un martes: los trabajos empezaron a fallar en la entrega matutina y el on-call recibió un pager por un panel que solo entendía “rendimiento abajo”.

La suposición inicial fue encantadoramente humana: “El cluster es más grande ahora, así que debe ser el scheduler.” Ajustaron reglas de colocación, movieron trabajos entre nodos e incluso reiniciaron algunos demonios. El rendimiento siguió inconsistente. Algunos nodos iban rápidos. Otros lentos. Ningún patrón, salvo que los lentos estaban todos en una fila de racks.

Un SRE escéptico finalmente trazó consumo de potencia de GPU y temperatura versus la temperatura de entrada del rack desde sensores de la instalación. La correlación fue grosera. Esa fila de racks tenía aire de entrada ligeramente más cálido debido a una baldosa de piso mal situada y una abertura sin sellar cerca de un corte para cables. Las GPUs no estaban fallando; se estaban protegiendo, asentándose en un reloj de estado estable más bajo bajo presión térmica.

La solución no fue un parche de software. Fue una reparación de instalaciones más una política de ventilador más agresiva en esos nodos. Después de eso, los tiempos de entrenamiento se estabilizaron. El action item del postmortem fue dolorosamente simple: “Deja de asumir que números de pieza idénticos significan rendimiento idéntico in situ”.

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

Un equipo de rendimiento quería mejor rendimiento por vatio. Probaron undervolting en un pequeño conjunto de GPUs, vieron resultados prometedores y lo incorporaron a una imagen dorada. El rendimiento medio mejoró ligeramente y los gráficos de la factura de energía se vieron más bonitos. Todos se sintieron listos.

Luego aparecieron fallos raros. No de inmediato. Unas semanas después, algunos trabajos comenzaron a fallar con errores CUDA “illegal memory access”. No todos los trabajos, no todos los nodos. El peor tipo de bug: intermitente, dependiente de carga y alérgico a reproducirse en horario laboral.

La causa raíz fue una configuración de undervolt que era estable para su benchmark, pero marginal para una mezcla de kernels diferente usada por otro equipo. El gobernador de boost ocasionalmente escogía un bin de frecuencia más alto bajo ciertas condiciones térmicas, y esa frecuencia no era estable con el voltaje reducido. La “optimización” había estrechado silenciosamente el margen de estabilidad.

La solución fue tratar el undervolting como cualquier otro cambio con radio de impacto: perfiles por SKU, pruebas de soak más largas y gating a workloads específicos. Mantuvieron el undervolt, pero dejaron de fingir que era un almuerzo gratis. Puedes intercambiar vatios por fiabilidad; solo necesitas ser explícito sobre ello.

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

Un equipo que ejecutaba inferencia con GPU tenía una costumbre que parecía anticuada: cada nodo pasaba por una “caracterización térmica y de potencia” básica en CI antes de admitirse en el pool. No era glamoroso. Era una prueba larga que producía un puñado de gráficas y una etiqueta de aprobado/reprobado.

Un día llegó un envío de vendor con una revisión menor de la placa. Mismo nombre de SKU, mismas especificaciones publicitadas. La prueba de caracterización marcó varios nodos: alcanzaban límites térmicos antes y se asentaban en relojes más bajos bajo carga sostenida. Nada estaba “roto”, pero el envelope de rendimiento era lo suficientemente distinto para importar en la planificación de capacidad.

Porque lo detectaron antes de producción, ajustaron la colocación en rack (zonas más frías para esos nodos), actualizaron la política de límites de potencia y evitaron sobreasignar la flota de inferencia. Sin incidente. Sin pager. Solo una nota interna: “La nueva revisión se comporta diferente; prográmenla en consecuencia”.

Es difícil celebrar incidentes que nunca suceden, pero ese es literalmente el trabajo. Las prácticas aburridas suelen ser las únicas que escalan.

Chiste corto #2: El mejor tipo de outage es el que previenes. El segundo mejor es el que ocurre durante tus vacaciones.

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

Esta es la sección que la gente lee después de haber probado tres “tweaks” y empeorado las cosas. De nada.

1) Síntoma: “El reloj de boost nunca alcanza el número anunciado”

• Causa raíz: El boost anunciado es oportunista y depende del margen disponible; estás limitado por potencia o térmicas, o tu carga es lo suficientemente pesada como para activar bins sostenidos más bajos.
• Solución: Mide relojes sostenidos bajo tu carga real; fija expectativas realistas. Mejora refrigeración, sube el límite de potencia (si es seguro) o usa application clocks para previsibilidad.

2) Síntoma: “El rendimiento es genial durante 60 segundos, luego cae”

• Causa raíz: Soak térmico. Disipador, memoria, VRMs alcanzan estado estable y activan objetivos térmicos o protección de VRM.
• Solución: Ejecuta pruebas de 20–30 minutos; arregla flujo de aire, curvas de ventilador, repaste/repad si aplica, reduce ligeramente el límite de potencia para evitar saturación térmica.

3) Síntoma: “La utilización GPU es baja; los relojes son bajos; debe estar throttling”

• Causa raíz: La GPU está esperando—preprocesado de CPU, cuello de botella I/O, transferencia PCIe, sincronización o tamaños de batch pequeños.
• Solución: Revisa iowait, saturación de CPU, enlace PCIe y solapamiento de la canalización. Optimiza la entrada de datos, aumenta el batch si es posible y prefetch.

4) Síntoma: “Mismo trabajo, nodos distintos, 15–25% de varianza”

• Causa raíz: Diferentes zonas de refrigeración, distinta calidad de silicio, distintos límites de potencia, distintos estados de enlace PCIe o distintos tenants en background.
• Solución: Estandariza: aplica límites de potencia con gestión de configuración, valida PCIe, caracteriza nodos y aísla vecinos ruidosos.

5) Síntoma: “Después de actualizar drivers, el consumo cambió y los relojes se ven raros”

• Causa raíz: El driver/firmware alteró tablas de boost, interpretación de sensores o políticas por defecto (incluido comportamiento de ventilador).
• Solución: Trata las actualizaciones de driver como actualizaciones de kernel: prueba en canarios con tus cargas reales, compara telemetría y mantén rutas de rollback.

6) Síntoma: “Subir el límite de potencia no incrementó rendimiento”

• Causa raíz: Estás limitado por térmicas, por ancho de banda de memoria o por restricciones de estabilidad voltaje/frecuencia.
• Solución: Revisa temperaturas (incluyendo puntos calientes/memoria si están disponibles), mejora refrigeración u optimiza patrones de acceso a memoria. No sigas añadiendo vatios a un problema de calor.

7) Síntoma: “Los relojes oscilan cada segundo; el rendimiento es entrecortado”

• Causa raíz: Oscilación del lazo de control del límite de potencia, boosting transitorio agresivo o una carga que alterna rápidamente entre cómputo y espera.
• Solución: Considera application clocks, un límite de potencia ligeramente menor para evitar overshoot, suaviza la programación de la carga y asegura refrigeración estable.

8) Síntoma: “Errores GPU o caídas de trabajo tras undervolting/overclocking”

• Causa raíz: Margen de estabilidad reducido; el boost ocasionalmente selecciona puntos V/F inestables; los cambios de temperatura alteran la estabilidad.
• Solución: Revertir a stock, luego reintroducir ajustes con pruebas de soak y monitoreo de errores. En producción, prioriza la corrección sobre los logros de rendimiento.

Listas de verificación / plan paso a paso (rendimiento estable a propósito)

Checklist A: Establecer una línea base en la que puedas confiar

1. Elige una carga representativa y sostenida (no un benchmark de 30 segundos). Ejecútala 20–30 minutos.
2. Recopila telemetría: consumo de potencia, límite de potencia, relojes, temperatura, utilización y cualquier razón de throttling.
3. Registra el entorno: temperatura de entrada, política de ventilador, modelo de chasis, versión de driver, versión de firmware.
4. Documenta los rangos de estado estable esperados: “Potencia 145–155 W, temp 70–78°C, relojes 1600–1700 MHz.”

Checklist B: Decide qué quieres realmente (pico vs predecible)

• Si necesitas menor latencia en la cola o finalización consistente de lotes: prefiere relojes de aplicación fijos y límites de potencia conservadores.
• Si necesitas máximo rendimiento pico y toleras variabilidad: permite boost, pero asegura margen térmico y evita undervolts marginales.
• Si buscas mejor perf-per-watt: ajusta límites de potencia y undervolt con cuidado, pero valida estabilidad bajo tu mezcla real de kernels.

Checklist C: Secuencia segura de ajuste (haz esto, no gires perillas al azar)

1. Arregla flujo de aire primero. Un entorno térmico estable hace que cada otro cambio sea más fácil de razonar.
2. Establece/verifica la política de límite de potencia (y asegúrate de que persista tras reinicios).
3. Prueba application clocks si tu plataforma los soporta y tu carga se beneficia de estabilidad.
4. Sólo entonces considera undervolting, con pruebas de soak y monitoreo de errores.
5. Vuelve a ejecutar la carga base y compara métricas de estado estable, no del primer minuto.

Checklist D: En qué alertar (porque las sorpresas son enemigas)

• Consumo sostenido de potencia pegado al límite con relojes en descenso: estás limitado por potencia; la planificación de capacidad debe asumir ese estado.
• Temperatura acercándose al objetivo con RPM de ventilador en aumento: estás cerca del techo térmico; un día caluroso puede causar caída de rendimiento.
• Enlace PCIe degradado (Gen/anchura): indica problemas de asiento/hardware, BIOS o contención de plataforma.
• Errores ECC corregidos en tendencia al alza: pueden ser aviso temprano de marginalidad de hardware o ajustes demasiado agresivos.

Preguntas frecuentes

1) ¿Por qué cambia el reloj de mi GPU incluso cuando la utilización es 100%?

Porque 100% de utilización no significa densidad de potencia constante. Distintos kernels estresan distintas unidades funcionales, cambiando consumo y comportamiento térmico. El gobernador ajusta relojes para mantenerse dentro de los límites.

2) ¿“Límite de potencia” es lo mismo que TDP?

No. TDP es un término objetivo de diseño usado de forma inconsistente entre proveedores. Límite de potencia es una política aplicada (a menudo en vatios) que restringe directamente el algoritmo de boost. Operativamente, el límite de potencia es lo que puedes controlar y medir.

3) Si subo el límite de potencia, ¿siempre mejorará el rendimiento?

No. Si estás limitado por ancho de banda de memoria, subir la potencia no ayudará. Si estás limitado térmicamente, aumentar potencia puede empeorar el rendimiento con el tiempo al forzarte a throttling antes. Valida con pruebas sostenidas.

4) ¿Cuál es la forma más rápida de saber si estoy limitado por potencia?

Comprueba si power.draw se aproxima a power.limit mientras la utilización es alta y los relojes están por debajo del máximo soportado. En NVIDIA, “PerfCap reason” o razones de throttling pueden confirmarlo.

5) ¿Por qué dos GPUs idénticas tienen relojes distintos en estado estable?

Varianza del silicio (voltaje requerido para una frecuencia dada), diferencias sutiles de refrigeración, diferencias en placa/VRM e incluso presión de montaje pueden causar diferencias medibles. En flotas, trata el rendimiento como una distribución, no como un número único.

6) ¿Debería bloquear los application clocks en producción?

Si la previsibilidad importa y tu plataforma lo soporta, sí—a menudo. Cambias rendimiento pico por repetibilidad. Para pipelines por lotes con deadlines, suele ser una ganancia.

7) ¿El undervolting reduce rendimiento?

Puedes ver una reducción, pero a menudo no si estás limitado por potencia. El undervolt puede permitir mantener relojes más altos dentro del mismo límite de potencia. La trampa es la estabilidad: debes hacer pruebas de soak bajo tu mezcla real de kernels y vigilar errores.

8) ¿Por qué mi GPU está “fría” pero igual lenta?

Porque puede que estés esperando por CPU, almacenamiento, red o transferencias PCIe. Una GPU fría con baja utilización suele estar desabastecida, no throttling. Arregla la canalización, no la curva de ventilador.

9) ¿La containerización puede afectar el comportamiento de boost y potencia?

Sí. Los contenedores pueden cambiar disponibilidad de CPU, comportamiento I/O y concurrencia de trabajos, lo que altera el ciclo de trabajo de la GPU. Además, los device plugins y la partición (como MIG) pueden cambiar la porción de hardware que recibes.

10) ¿Qué debo estandarizar en una flota de GPUs?

Versiones de driver/firmware, política de límite de potencia, modo persistente, política de ventilador/flujo de aire y una prueba de caracterización de estado estable. La estandarización es cómo conviertes “arte” en operaciones.

Conclusión: siguientes pasos que realmente reducen sorpresas

Si tu GPU se comporta como si tuviera mente propia, es porque solo miras el número principal (reloj) e ignoras el contrato (límites). El boost no es una promesa; es un algoritmo de mejor esfuerzo negociando vatios y calor.

Haz esto a continuación, en este orden:

1. Mide el comportamiento sostenido bajo cargas reales (20–30 minutos), no benchmarks de pico.
2. Atribuye el limitador: potencia, térmico o “esperando por otra cosa”.
3. Arregla la capa física: flujo de aire, temperatura de entrada, salud del enlace PCIe, política de potencia del servidor.
4. Elige una política: relojes previsibles (application clocks) o boost oportunista (con margen térmico).
5. Ajusta con cuidado: límites de potencia primero, undervolt al final, y solo con pruebas de soak y monitoreo de errores.

Cuando tratas a las GPUs como sistemas de producción—gobernados, restringidos y observables—el “misterio” desaparece. Aún pelearás contra la física. Pero al menos sabrás qué lado está ganando.