Subvoltaje en GPUs: el truco silencioso de rendimiento que nadie te cuenta

Qué es realmente el subvoltaje (y qué no es)

Subvoltaje significa ejecutar la GPU con un voltaje menor que el predeterminado del fabricante para una frecuencia dada.
Bien hecho, reduce potencia y calor manteniendo el rendimiento igual —o mejorándolo al prevenir
estrangulamientos por térmicos o potencia.

Lo que no es no:

• No es subrelojado: puedes subvoltear y mantener relojes altos. Subrelojear reduce la frecuencia; subvoltear reduce el voltaje. Puedes hacer ambas cosas, pero no las confundas.
• No es “overclocking gratis”: estás optimizando el punto de operación. Si quieres números máximos de benchmark para capturas de pantalla, ese es otro hobby.
• No es una promesa segura de garantía: algunos fabricantes consideran las ediciones de curva como “tuning”. En un centro de datos, los power caps suelen ser más seguros que hackear la curva de voltaje.
• No es una configuración universal: dos GPUs del mismo modelo pueden tener distinta calidad de silicio. No copies y pegues un número de voltaje como si fuera un manifiesto de Kubernetes.

Aquí está el modelo mental: intentas posicionarte en la “rodilla” de la curva donde cada vatio extra compra muy poco rendimiento.
Si operas por encima de esa rodilla, pagas por calor.

Por qué funciona: comportamiento de boost, límites de potencia y realidad térmica

Las GPUs modernas no corren a un reloj fijo. Persiguen un objetivo móvil limitado por al menos tres techos:
límite de potencia, límite de temperatura y límite de fiabilidad del voltaje.
El driver/firmware reducirá los relojes con gusto para protegerse. Tu carga de trabajo no tiene voto.

La potencia es el limitador silencioso del rendimiento

El consumo de energía de la GPU es aproximadamente proporcional a V² × f (voltaje al cuadrado por frecuencia), más fuga.
Ese término al cuadrado es por qué el subvoltaje es tan efectivo. Recorta un poco de voltaje y con frecuencia cortas una porción notable de potencia,
lo que reduce la temperatura, reduce la fuga y reduce la potencia otra vez. Es un lazo de retroalimentación positivo, en buena dirección.

Por qué “menos voltaje” puede significar “más velocidad”

Cuando estás limitado por potencia o por térmicos, la GPU hace boost hasta chocar con un techo y luego retrocede.
Si bajas el voltaje, la misma frecuencia cuesta menos vatios. Eso significa que la GPU puede sostener relojes más altos por más tiempo antes de
alcanzar el techo. Tu reloj promedio sube. Tu tiempo de ejecución en reloj real baja.

Por eso el subvoltaje puede superar las configuraciones de fábrica en cargas sostenidas:
renders largos, épocas de entrenamiento, lotes de inferencia, kernels de compilación, cualquier cosa que corra minutos, no milisegundos.

El throttling no es una falla; es un síntoma

En términos de SRE, el throttling es retropresión. Es la GPU diciéndote: “Me quedé sin presupuesto: vatios, térmicos, o ambos.”
El subvoltaje aumenta el margen haciendo que cada unidad de trabajo cueste menos.

Una cita que la gente de operaciones aprende a la fuerza:
parafraseada: Todo falla, todo el tiempo; tu trabajo es diseñar para ello. — Werner Vogels

El subvoltaje forma parte de diseñar para la realidad: potencia y refrigeración son finitas, y tus cargas de trabajo no se detienen educadamente a las 5 PM.

Hechos e historia: cómo llegamos aquí

El subvoltaje parece un truco moderno porque la gente habla mayormente de overclocking. Pero existe desde que el silicio tiene
variabilidad y los fabricantes han tenido que enviar piezas que funcionen en el peor caso plausible.

8 hechos concretos que hacen que el subvoltaje tenga sentido

1. Dynamic voltage and frequency scaling (DVFS) tiene décadas; CPUs y GPUs han buscado “justo el voltaje suficiente” para rendimiento durante mucho tiempo.
2. Existen bins porque los chips difieren: dos dies de la misma oblea pueden necesitar distinto voltaje para la misma frecuencia. Los valores por defecto deben cubrir el extremo débil de la distribución.
3. Algoritmos estilo GPU Boost (diversos nombres según la generación) hicieron que los relojes sean oportunistas en lugar de fijos, lo que convirtió a la potencia y la temperatura en los verdaderos gobernantes.
4. La entrega de potencia se volvió más compleja: las GPUs modernas tienen muchas rails y comportamientos transitorios agresivos; los fabricantes incorporan margen para sobrevivir picos.
5. Los nodos de proceso se redujeron, la fuga aumentó: en geometrías más pequeñas, la fuga y el comportamiento de hotspots se volvieron partes más importantes de la historia de potencia, no solo la potencia de conmutación.
6. Los centros de datos empezaron a preocuparse por los vatios como dinero: porque lo es—capex, opex y la capacidad de encajar más computación bajo el mismo recinto de la instalación.
7. El silicio móvil forzó una cultura de eficiencia: GPUs de portátil y SoCs normalizaron la idea de que la gestión de potencia es gestión de rendimiento.
8. La densidad térmica es la nueva velocidad de reloj: no puedes “simplemente enfriarlo más” para siempre; el flujo de calor y los límites acústicos se convierten en restricciones duras.

Broma 1/2: Hacer subvoltaje es como finalmente arreglar tu dieta en vez de comprarte un cinturón más grande. Es menos dramático, pero tu yo futuro te agradece.

Dónde ayuda el subvoltaje (y dónde no)

Dónde destaca

• Cómputo sostenido: entrenamiento, inferencia, renderizado, transcodificación, simulación científica. Cualquier cosa que se caliente lo suficiente por tiempo prolongado.
• Acústica y presupuestos térmicos: estaciones de trabajo en oficinas, despliegues en el borde, racks con flujo de aire limitado.
• Densidad multi-GPU: cuando varias tarjetas comparten el flujo de aire del chasis y la “GPU del medio” siempre vive peor.
• Entornos con límite de potencia: colocation, circuitos de laboratorio, UPS compartidos o sobres de potencia estrictos a nivel de rack.
• Predictibilidad: reducir el throttling reduce la variación ejecución a ejecución, lo que importa en pipelines de producción.

Dónde es una pérdida de tiempo

• Pipelines limitados por CPU: si tu GPU espera datos o a la CPU, recortar vatios no cambiará el rendimiento.
• Entrenamiento limitado por I/O: lecturas lentas del dataset, cuello de botella en descompresión o saturación de almacenamiento en red.
• Cargas de ráfaga críticas por latencia: si la carga es corta y nunca alcanza equilibrio térmico, el subvoltaje se trata más de ruido y consumo que de velocidad.

El punto no es “subvoltear siempre”. El punto es “deja de asumir que los ajustes de fábrica son óptimos para tus restricciones”.
Los fabricantes optimizan para “funciona para todos”, no para “lo mejor para ti”.

Guía de diagnóstico rápido: encuentra el cuello de botella rápidamente

Cuando un trabajo GPU es lento o inestable, la gente culpa de inmediato a “la GPU”. Eso es pereza.
Diagnostica en este orden para evitar pasar un día ajustando algo que no te estaba limitando.

Primero: confirma que la GPU está realmente ocupada

• Revisa la utilización de GPU y los relojes durante la carga de trabajo.
• Si la utilización es baja, inspecciona CPU, I/O, dataloader, red o planificación.

Segundo: busca throttling (potencia, térmico, fiabilidad)

• Mira las razones de límite de potencia, hits de límite de temperatura o caídas de reloj bajo carga.
• Correlaciona temperatura, consumo y frecuencia de reloj en el tiempo.

Tercero: revisa “molestias de centro de datos”

• Enlace PCIe negociado incorrectamente en ancho/velocidad.
• Particiones MIG/vGPU limitando recursos.
• Errores ECC o eventos Xid causando reintentos o resets de contexto.
• Curvas de ventilador o flujo de aire del chasis provocando que una GPU haga throttling antes que las otras.

Cuarto: ajusta para eficiencia, no para bravura

• Empieza con un power cap (simple, reversible, amigable para auditoría).
• Si necesitas más, ajusta la curva de frecuencia y voltaje (más arriesgado, más variable).
• Prueba estabilidad con el patrón real de tu carga, no sólo con una prueba sintética de burn.

Tareas prácticas con comandos: medir, cambiar, verificar, decidir

Estas son tareas de campo. Cada una incluye: un comando, qué significa la salida típica y la decisión que tomas.
Los comandos asumen Linux con drivers NVIDIA instalados donde aplique.

Task 1: Identify GPUs and driver baseline

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:12:04 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14    CUDA Version: 12.4     |
|-----------------------------------------+----------------------+----------------------|
| GPU  Name                  Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf           Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|  0  NVIDIA RTX A5000              Off   | 00000000:3B:00.0  Off |                  N/A |
| 30%   67C    P2               188W / 230W|   8120MiB / 24576MiB |     92%      Default |
+-----------------------------------------+----------------------+----------------------+

Significado: Tienes la línea base del driver/CUDA, uso y límite de potencia actuales, y utilización.
Si no puedes reproducir números más tarde, empieza aquí.

Decisión: Registra la versión del driver y el modelo de GPU. Los resultados del tuning no se generalizan entre cambios de driver tan bien como la gente piensa.

Task 2: Check if persistence mode is helping or harming your environment

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

Significado: El modo persistente mantiene el contexto del driver caliente; puede reducir la latencia del primer trabajo y prevenir rarezas de estados de reloj/potencia.

Decisión: Habilítalo en nodos de cómputo dedicados. En escritorios compartidos, sopésalo frente a políticas de consumo en reposo.

Task 3: Log power, clocks, temperature over time (the “stop guessing” step)

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,pstate,clocks.sm,clocks.mem,temperature.gpu,power.draw,power.limit,utilization.gpu --format=csv -l 2
timestamp, pstate, clocks.sm [MHz], clocks.mem [MHz], temperature.gpu, power.draw [W], power.limit [W], utilization.gpu [%]
2026/01/13 10:14:00, P2, 1785, 7001, 69, 192.34, 230.00, 94
2026/01/13 10:14:02, P2, 1740, 7001, 72, 201.11, 230.00, 95
2026/01/13 10:14:04, P2, 1650, 7001, 78, 229.85, 230.00, 96

Significado: Si los relojes caen mientras la utilización permanece alta y la potencia se queda en el límite, estás limitado por potencia. Si la temperatura sube y los relojes bajan antes de alcanzar el límite de potencia, estás limitado térmicamente.

Decisión: Decide si el subvoltaje debe implementarse como un power cap primero (usualmente sí), o si se requiere trabajo de flujo de aire/térmico.

Task 4: Check for throttling (the smoking gun)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE
==============NVSMI LOG==============

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

Significado: “SW Power Cap: Active” significa que el driver está aplicando un límite de potencia. Tu GPU quiere hacer más boost pero está bloqueada por vatios.

Decisión: Afinar el power cap probablemente aumente los relojes sostenidos si puedes reducir vatios por MHz mediante métodos similares al subvoltaje (a menudo mediante un límite de potencia menor y/o una curva de frecuencia).

Task 5: Inspect supported power limits and default cap

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

Power Readings
    Power Management                  : Supported
    Power Draw                        : 201.11 W
    Power Limit                       : 230.00 W
    Default Power Limit               : 230.00 W
    Enforced Power Limit              : 230.00 W
    Min Power Limit                   : 120.00 W
    Max Power Limit                   : 230.00 W

Significado: Puedes establecer entre 120W y 230W. Ese rango es tu palanca segura de “power cap”.

Decisión: Empieza con una reducción moderada (por ejemplo, 230W → 200W) y mide el rendimiento y los relojes. Si el rendimiento se mantiene, sigue reduciendo hasta que no lo haga.

Task 6: Apply a power cap (most production-friendly undervolt proxy)

cr0x@server:~$ sudo nvidia-smi -i 0 -pl 200
Power limit for GPU 00000000:3B:00.0 was set to 200.00 W from 230.00 W.

Significado: Has limitado la potencia máxima de la GPU. Esto a menudo reduce voltaje y aumenta la eficiencia automáticamente.

Decisión: Ejecuta inmediatamente tu carga y registra relojes/utilización. Si los relojes se vuelven más estables (menos sierra) y el rendimiento es igual o mejor, lo mantienes.

Task 7: Verify sustained clocks improved (or at least stopped falling apart)

cr0x@server:~$ nvidia-smi --query-gpu=clocks.sm,power.draw,temperature.gpu,utilization.gpu --format=csv -l 2
clocks.sm [MHz], power.draw [W], temperature.gpu, utilization.gpu [%]
1800, 198.22, 70, 95
1800, 199.01, 71, 96
1800, 199.44, 71, 96

Significado: Relojes estables con menor consumo es el objetivo. Si antes la GPU rebotaba entre 1650–1800 MHz y ahora se queda en 1800 MHz, compraste rendimiento real.

Decisión: Mantén el cap si reduce la varianza. La varianza es un impuesto en la planificación de capacidad.

Task 8: Check PCIe link width and speed (avoid blaming power for a bus issue)

cr0x@server:~$ nvidia-smi -q | sed -n '/PCI/,/GPU Link/p'
    PCI
        Bus                               : 0x3B
        Device                            : 0x00
        Domain                            : 0x0000
        Bus Id                            : 00000000:3B:00.0
        GPU Link Info
            PCIe Generation
                Max                       : 4
                Current                   : 1
            Link Width
                Max                       : 16x
                Current                   : 1x

Significado: Si ves Gen1 x1 cuando esperabas Gen4 x16, tu carga podría estar limitada por PCIe, no por voltaje de GPU.

Decisión: Arregla el asiento físico, configuración BIOS, risers o bifurcación. No “subvoltees para arreglar rendimiento” cuando el bus está lento.

Task 9: Confirm the workload is GPU-bound (quick-and-dirty)

cr0x@server:~$ nvidia-smi dmon -s pucvmt -d 2 -c 5
# gpu   pwr gtemp mtemp  sm   mem   enc   dec   mclk   pclk
# Idx     W     C     C   %     %     %     %   MHz    MHz
    0   199    71     -  96    42     0     0  7001   1800
    0   199    71     -  97    41     0     0  7001   1800
    0   198    71     -  96    41     0     0  7001   1800
    0   199    71     -  97    42     0     0  7001   1800
    0   199    72     -  96    42     0     0  7001   1800

Significado: “sm” cerca de 100% sugiere bound por cómputo. Si “sm” está bajo mientras la CPU está alta o el I/O está saturado, el subvoltaje no cambiará mucho.

Decisión: Ajusta la potencia de la GPU sólo una vez confirmes que la GPU es el recurso limitante en el camino crítico.

Task 10: Check CPU, memory pressure, and I/O bottlenecks (so you don’t chase ghosts)

cr0x@server:~$ vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  0      0 421032  52224 812340    0    0    12    34  812 1490 62 11 26  1  0
 9  0      0 418900  52224 811998    0    0    10    22  790 1522 64 10 25  1  0
12  1      0 120044  52180 812100    0    0  9020  1100  920 1801 55 12 16 17  0
10  2      0  98020  52000 812220    0    0 12010  2300  980 2102 48 10 12 30  0

Significado: El aumento de “wa” (I/O wait) y grandes “bi/bo” significa que la CPU espera disco. Tu GPU puede estar hambrienta.

Decisión: Arregla la tubería de datos: ancho de banda de almacenamiento, caching, hilos del dataloader, prefetching, formato del dataset. El subvoltaje no cura discos lentos.

Task 11: Look for GPU errors and resets (stability before cleverness)

cr0x@server:~$ sudo dmesg -T | egrep -i "NVRM|Xid|gpu" | tail -n 8
[Tue Jan 13 10:20:11 2026] NVRM: Xid (PCI:0000:3b:00): 31, Ch 0000007e, intr 00000000. MMU Fault
[Tue Jan 13 10:20:11 2026] NVRM: Xid (PCI:0000:3b:00): 13, Graphics Engine Exception
[Tue Jan 13 10:20:12 2026] NVRM: GPU 0000:3b:00.0: GPU has fallen off the bus.

Significado: Los errores Xid pueden indicar bugs de driver, relojes/voltaje inestables, señalización PCIe mala o problemas de entrega de potencia. “Fallen off the bus” no es una oportunidad de tuning; es un incidente.

Decisión: Revierte el tuning a stock, revisa el asiento/hardware/power, considera cambiar driver y sólo entonces reintenta caps de potencia conservadores.

Task 12: Confirm ECC and memory error counters where available

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

ECC Mode
    Current                            : Enabled
    Pending                            : Enabled
ECC Errors
    Volatile
        Single Bit
            Device Memory              : 0
        Double Bit
            Device Memory              : 0
    Aggregate
        Single Bit
            Device Memory              : 2
        Double Bit
            Device Memory              : 0

Significado: Las correcciones de un solo bit agregadas pueden ser normales en vidas largas; picos o errores de doble bit son un problema. Los subvoltajes inestables a veces pueden manifestarse como errores de memoria, dependiendo de la arquitectura y las condiciones.

Decisión: Si los contadores aumentan durante el tuning, revierte. La corrupción silenciosa es el peor tipo de velocidad.

Task 13: Validate your power cap actually persists (or deliberately doesn’t)

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

Significado: “Enforced” coincide con lo configurado. Si vuelve a su valor después del reinicio, es normal a menos que lo fijes mediante un servicio de arranque.

Decisión: Decide la política: tuning efímero para experimentos vs. tuning codificado vía systemd para producción.

Task 14: Create a small systemd unit to apply a power limit on boot

cr0x@server:~$ cat /etc/systemd/system/gpu-powercap.service
[Unit]
Description=Set NVIDIA GPU power limit
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -i 0 -pl 200

[Install]
WantedBy=multi-user.target

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl enable --now gpu-powercap.service
Created symlink /etc/systemd/system/multi-user.target.wants/gpu-powercap.service → /etc/systemd/system/gpu-powercap.service.

Significado: Has operacionalizado el tuning. Nadie tiene que recordar un paso manual a las 2 AM.

Decisión: Usa esto para caps conservadores y estables. No apliques offsets experimentales de curva automáticamente en una flota sin puertas de validación.

Task 15: Compare performance per watt (you need a metric that management understands)

cr0x@server:~$ python3 - <<'PY'
import time, subprocess, statistics
def sample(n=10, interval=1):
    p=[]
    for _ in range(n):
        out=subprocess.check_output(["nvidia-smi","--query-gpu=power.draw","--format=csv,noheader,nounits"]).decode().strip()
        p.append(float(out.splitlines()[0]))
        time.sleep(interval)
    return statistics.mean(p), statistics.pstdev(p)
mean, sd = sample()
print(f"avg_power_w={mean:.2f} stdev_w={sd:.2f}")
PY
avg_power_w=199.12 stdev_w=0.63

Significado: Menor potencia promedio y menor desviación estándar suelen correlacionar con relojes más estables y menos eventos de throttling.

Decisión: Empareja esto con el throughput de tu carga (imágenes/seg, tokens/seg, muestras/seg). Adopta el tuning sólo si el rendimiento por vatio mejora sin regresiones de estabilidad.

Métodos: power caps, curvas voltaje/frecuencia y “no luchar contra el firmware”

Method A: Power cap first (recommended for production)

Establecer un límite de potencia más bajo es la forma más aburrida de “subvoltear”, y por eso gana en entornos corporativos.
Es auditable, reversible y no depende tanto de la lotería de silicio por tarjeta como las ediciones manuales de curva de voltaje.

Los power caps funcionan porque el controlador interno de la GPU muchas veces elegirá un punto de operación con menor voltaje/frecuencia para mantenerse bajo el cap.
No estás editando explícitamente milivoltios, pero logras el mismo resultado: menos vatios para trabajo casi idéntico.

Enfoque práctico:

• Reduce en pasos (por ejemplo, 10–15% a la vez).
• Ejecuta la carga real el tiempo suficiente para que haya soak térmico (10–30 minutos mínimo).
• Registra relojes/potencia/temp; anota el throughput.
• Detente cuando el throughput caiga notablemente o se amenacen los SLOs de latencia.

Method B: Frequency locking (sometimes useful, sometimes a trap)

Bloquear los relojes GPU puede hacer el rendimiento más predecible, útil para inferencia sensible a latencia.
Pero los locks de reloj también pueden forzar un voltaje mayor del necesario o pelear contra el algoritmo de boost de manera contraproducente.

Si bloqueas relojes, debes verificar que la potencia y temperaturas no se disparen y que no estés provocando problemas de estabilidad.
Predecible es bueno. Predeciblemente caliente no lo es.

Method C: Voltage/frequency curve editing (powerful, high-touch)

Editar la curva es el subvoltaje de entusiastas: elige una frecuencia objetivo y fíjala a un punto de voltaje menor.
Puede dar excelentes resultados en una estación de trabajo individual donde puedas vigilarla.

En flotas, editar curvas tiene dos problemas:

• Variabilidad por tarjeta: una tarjeta es estable a un voltaje dado; su vecina no lo es.
• Complejidad operacional: actualizaciones de driver, herramientas GUI y comportamiento en reboot pueden romper suposiciones. Tu cola de tickets no estará impresionada.

Method D: The “leave it alone” option that still helps

A veces el mejor subvoltaje es arreglar el flujo de aire para que la tarjeta no esté todo el día en el límite térmico.
Bajar la temperatura reduce la fuga, lo que es efectivamente una ganancia de eficiencia “gratis” sin tocar controles de voltaje.

Broma 2/2: El subvoltaje más fácil es quitar el polvo del filtro de admisión. También es el truco menos a la moda, por eso funciona.

Pruebas de estabilidad que no te hagan perder la semana

Las fallas por subvoltaje rara vez son educadas. Aparecen como un solo trabajo que se cae a la hora seis, un reset de driver, o un problema numérico sutil.
Tus pruebas deben coincidir con cómo realmente ejecutas la GPU.

Qué significa “estable” en producción

• No resets de driver: no tormentas Xid, no “fallen off the bus”.
• No regresiones de corrección: las distribuciones de salida se mantienen consistentes; no NaNs inexplicables.
• No decadencia de reloj a largo plazo: el rendimiento no se degrada lentamente a medida que el chasis se calienta.
• Latencia cola predecible: p95/p99 no empeoran por throttling esporádico o reintentos.

Diseño de pruebas que respeta la realidad

Usa al menos dos patrones:

• Estado estable: carga constante durante 30–60 minutos. Esto detecta problemas de equilibrio térmico.
• Ciclos ráfaga + inactivo: el patrón que realmente tienes en producción. Esto detecta bugs en transiciones DVFS y problemas transitorios de potencia/voltaje.

Qué registrar durante las pruebas

• clocks.sm, clocks.mem
• power.draw, power.limit
• temperature.gpu (y hotspot si tu herramienta lo recoge)
• utilization.gpu, uso de memoria
• dmesg para Xid, logs de aplicación para NaNs o reintentos

Criterios de aceptación que puedas defender

• Throughput dentro de ±1–2% de la línea base (o mejor) bajo carga en estado estable.
• No aumento en contadores de error; no nuevos errores de kernel/driver.
• Menor consumo promedio y/o menor temperatura a igual throughput.
• Varianza reducida: menos caídas de reloj, distribución de latencia más ajustada.

Tres mini-historias corporativas desde las trincheras

Story 1: The incident caused by a wrong assumption (“stock settings are safe”)

Un equipo desplegó nuevos nodos GPU para entrenamiento de modelos. Mismo proveedor, mismo chasis, misma imagen “aprobada”.
La única diferencia fue la instalación: una fila más cálida, flujo de aire ligeramente peor y un PDU que trabajaba más cerca de su límite.
Todo pasó pruebas rápidas de humo.

Tres días después, los trabajos empezaron a fallar en un patrón que parecía aleatorio. Una corrida de entrenamiento se caía en los límites de época.
Otra se enlentecía sin causa clara. La gente culpó al framework, luego al dataset, luego al driver.
Mientras tanto, las métricas GPU contaban una historia aburrida: consumo de potencia fijado en el cap, temperaturas rozando el límite térmico,
relojes balanceándose como un metrónomo.

La suposición equivocada fue pensar que “los valores por defecto del fabricante son conservadores.” Son conservadores para la corrección funcional en distintos entornos,
no para la estabilidad de rendimiento en un rack apretado con temperatura ambiente elevada. Los valores por defecto también asumen que tienes la refrigeración que la diapositiva de marketing del fabricante imagina.

La solución fue vergonzosamente simple: capear la potencia en un porcentaje moderado y dejar de empujar la tarjeta a una esquina donde constantemente hacía throttling.
Los fallos desaparecieron. El throughput se volvió predecible. El equipo aprendió la lección operacional: la estabilidad no es una configuración por defecto; es un estado afinado.

Story 2: The optimization that backfired (“we can go lower, it’s fine”)

Otro grupo persiguió la eficiencia con fuerza porque el precio de la electricidad pasó a la agenda. Piloteaban subvoltaje bajando agresivamente
los límites de potencia y aplicando locks de frecuencia para “mantenerlo consistente.” Los benchmarks iniciales se veían geniales: menor potencia, casi el mismo throughput.
Alguien declaró la victoria.

Luego la inferencia empezó a mostrar picos raros de latencia y salidas ocasionalmente inválidas —lo justo para disparar reintentos downstream.
Los reintentos aumentaron la carga. La carga aumentó la temperatura. La temperatura aumentó el throttling. El throttling aumentó la latencia. Se formó un bucle de retroalimentación, el malo.
Nada “falló” en voz alta; simplemente se volvió más lento y más caro.

El retroceso vino de afinar sólo para el comportamiento promedio e ignorar el riesgo de cola. Al empujar demasiado cerca del borde de estabilidad, aumentaron la tasa
de errores corregibles y ralentizaciones transitorias. El sistema compensó con reintentos y timeouts, haciendo que el servicio pareciera inestable.

El plan de reparación fue retroceder: aflojar el cap, quitar locks de reloj duros y adoptar una política de “eficiencia con margen.”
También añadieron un canario: un nodo con la nueva configuración, con alertas sobre la distribución de latencia y errores de driver. El tuning final todavía ahorró energía,
pero dejó de ser un deporte extremo.

Story 3: The boring but correct practice that saved the day (“measure first, change once”)

Un equipo de plataforma corría una flota mixta de GPUs en varias líneas de producto. Tenían un mal historial con tuning “ingenioso”:
scripts aleatorios, ajustes no documentados y outages de fin de semana.
Así que implementaron una política aburrida: cada cambio en GPU debe estar ligado a una métrica y validado en un set canario con rollback.

Cuando exploraron el subvoltaje, no empezaron tocando curvas de voltaje. Empezaron registrando:
distribuciones de consumo, razones de throttling y throughput por trabajo. Luego aplicaron un cambio: un power cap moderado, idéntico para un mismo modelo.
Usaron una unidad systemd para hacerlo cumplir y una etiqueta en su inventario para rastrear qué nodos estaban afinados.

Un mes después, una actualización de driver cambió ligeramente el comportamiento de boost. En nodos no afinados, la varianza de rendimiento aumentó—algunos trabajos se enlentecieron en horas pico.
En nodos afinados, el power cap actuó como guardarraíl: temperaturas y relojes se mantuvieron dentro de un sobre predecible.
Los nodos afinados se convirtieron en la línea base “conocida buena” durante la revisión del incidente.

La lección no fue “los power caps son magia.” La lección fue que la higiene operacional vence a las heroicas.
El subvoltaje hecho como un cambio controlado se convierte en una característica de fiabilidad, no en un hobby.

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

1) Performance got worse immediately after undervolting

Síntoma: El throughput cae, los relojes GPU más bajos que antes, la utilización sigue alta.

Causa raíz: Power cap demasiado agresivo; empujaste por debajo de la rodilla y la GPU no puede sostener la frecuencia objetivo.

Solución: Aumenta el límite de potencia en pequeños pasos hasta que los relojes se estabilicen; detente en el mejor punto perf/vatio, no en el número más bajo de vatios.

2) Random job crashes after hours of “fine” operation

Síntoma: Corridas largas de entrenamiento fallan; dmesg muestra errores Xid o resets de GPU.

Causa raíz: La curva voltaje/frecuencia era demasiado optimista para esa tarjeta particular en condiciones con soak térmico; o la inestabilidad del PSU/PCIe se manifestó bajo transientes.

Solución: Restaura a stock o a un power cap conservador, vuelve a probar bajo el peor ambiente; verifica el asiento PCIe y cables de alimentación; evita tuning por tarjeta en flotas.

3) Lower power, but no performance improvement at all

Síntoma: Los vatios bajan, pero el tiempo en reloj no cambia y la utilización de GPU no está al máximo.

Causa raíz: Cuello de botella en CPU, I/O o red; la GPU no es el limitador.

Solución: Perfil la tubería: dataloader, ancho de banda de almacenamiento, descompresión, hilos de CPU, PCIe. Ajusta la capa correcta.

4) One GPU in a multi-GPU box keeps throttling while others don’t

Síntoma: La GPU 2 siempre más caliente, relojes más bajos, más flags de throttling.

Causa raíz: Desequilibrio de flujo de aire; la tarjeta del medio recircula aire caliente; curvas de ventilador limitadas por el diseño del chasis.

Solución: Mejora el flujo de aire, reorganiza el orden de tarjetas si es posible, o aplica power caps por GPU para que la tarjeta más caliente deje de cocinarse a sí misma.

5) “Undervolt” settings don’t survive reboot

Síntoma: Tras reiniciar, el límite de potencia vuelve al valor por defecto.

Causa raíz: Los power caps son configuraciones en tiempo de ejecución a menos que se persistan mediante gestión de servicios.

Solución: Usa una unidad systemd (como se mostró) o tu herramienta de gestión de configuración para aplicar límites conocidos al arrancar.

6) Latency tail gets worse while averages look fine

Síntoma: p99 de latencia se dispara bajo carga; el promedio de throughput está bien.

Causa raíz: Ajuste demasiado cerca del borde causando throttling intermitente o reintentos; locks de reloj duros pueden empeorar comportamiento transitorio.

Solución: Retrocede: límite de potencia ligeramente más alto, quita locks de reloj y afina para reducir varianza. Observa razones de throttling y logs de error.

7) Fans got quieter but the GPU is still hot

Síntoma: Menos ruido, pero las temperaturas siguen cerca del límite, los relojes oscilan.

Causa raíz: La política de curva de ventilador o el flujo de aire del chasis limitan la capacidad de enfriamiento; reducir la velocidad del ventilador oculta el síntoma pero no la restricción.

Solución: Mantén el subvoltaje/power cap, pero arregla el flujo de aire. Silencio está bien; estabilidad es requerida.

Listas de verificación / plan paso a paso

Step-by-step: production-safe undervolting via power caps

1. Base: registra modelo, versión de driver, límite de potencia por defecto y throughput de la carga.
2. Observa: registra relojes, potencia, temp y razones de throttling durante una ejecución representativa.
3. Confirma cuello de botella: asegúrate que la utilización GPU es alta y que hay throttling (potencia/térmico).
4. Aplica cap moderado: reduce el límite de potencia ~10–15%.
5. Prueba soak térmico: ejecuta la carga 30–60 minutos; registra métricas.
6. Evalúa: compara throughput, varianza, errores y temperaturas.
7. Itera: reduce más hasta que el rendimiento baje o la latencia cola empeore.
8. Codifica: implementa un mecanismo de aplicación en arranque (systemd/gestión de configuración).
9. Canario: despliega a un subconjunto pequeño; monitoriza durante una semana con cargas reales.
10. Despliegue: expande gradualmente; mantén el rollback trivial.

Step-by-step: workstation-style curve tuning (high-touch)

1. Empieza con un power cap de todos modos; te da una base segura.
2. Elige una frecuencia sostenida objetivo que ya observes bajo carga.
3. Reduce el voltaje incrementalmente manteniendo esa frecuencia; prueba la estabilidad con soak térmico.
4. Detente al primer signo de inestabilidad (errores, resets, NaNs) y retrocede.
5. Documenta la configuración por GPU, no por modelo. Sí, es molesto. Esa es la realidad.

Operational checklist: what to monitor continuously

• Consumo de potencia de GPU y power limit aplicado
• Razones de throttling
• Temperatura y comportamiento de ventiladores (incluyendo hotspot si puedes recogerlo)
• Errores Xid / resets de driver
• Distribución de throughput por trabajo y latencia de cola
• Contadores de error ECC donde aplique

Preguntas frecuentes

1) Is undervolting safe for the GPU?

Bajar voltaje es generalmente menos estresante eléctricamente que subirlo, pero “seguro” en operaciones significa “estable y correcto.”
Un subvoltaje inestable puede hacer caer trabajos o corromper resultados. Usa power caps conservadores primero y valida la estabilidad.

2) Why does undervolting sometimes improve performance?

Porque reduces potencia y calor, lo que reduce el throttling. La GPU puede sostener relojes de boost más tiempo dentro de los mismos límites.
Los relojes promedio importan más que los picos.

3) Should I undervolt by editing a voltage curve or just set a power limit?

En producción: empieza con un límite de potencia. Es más simple, más consistente entre tarjetas y más fácil de automatizar y revertir.
Editar curvas es mejor para estaciones de trabajo de usuario único donde puedes probar por tarjeta.

4) How do I know if I’m power-limited or thermal-limited?

Observa las razones de throttling y correlaciona relojes con consumo y temperatura. Si el consumo se queda en el cap y “SW Power Cap” está activo, es limitado por potencia.
Si la temperatura alcanza un límite y “HW Thermal Slowdown” está activo, es limitado térmicamente.

5) What’s a reasonable first power cap reduction?

Aproximadamente 10–15% por debajo del valor por defecto es un punto de partida práctico. Luego mide. El valor correcto depende del modelo, la refrigeración y la carga.
El único error es hacer un salto grande y llamarlo “tuning.”

6) Will undervolting reduce GPU lifespan?

Temperaturas y potencia más bajas generalmente ayudan la longevidad. El mayor riesgo es la inestabilidad que causa resets y churn operacional, no el desgaste físico.
Mantén margen y monitoriza señales de error.

7) Does undervolting help memory-bound workloads?

A veces. Si tu carga está limitada por ancho de banda de memoria y la GPU ya no hace boost alto en relojes de núcleo, el subvoltaje puede no cambiar mucho el throughput.
Aún puede reducir consumo y ruido. No esperes milagros.

8) Can I apply the same undervolt settings to every GPU of the same model?

Para power caps, a menudo sí dentro de lo razonable. Para ediciones de curva de voltaje, no—la variación de silicio lo hace arriesgado.
Incluso los power caps deberían promoverse mediante canarios porque el flujo de aire del chasis y las condiciones ambientales varían por rack.

9) How does undervolting interact with multi-tenant scheduling?

Los power caps pueden mejorar la equidad al reducir runaway térmico y evitar que una GPU caliente arrastre a las vecinas por el flujo de aire compartido.
Pero si los inquilinos tienen expectativas de rendimiento distintas, necesitas política: caps por cola, por partición o por clase de nodo.

10) What’s the quickest “tell” that undervolting is helping?

Menos sierra en los relojes bajo carga sostenida, menor temperatura y throughput igual o mejor.
Si tus relojes dejan de rebotar mientras la utilización permanece alta, usualmente encontraste un punto de operación mejor.

Próximos pasos

Si sólo vas a hacer una acción: implementa un power cap medido, no una curva de voltaje heroica, y evalúalo con telemetría de cargas reales.
El subvoltaje no es un truco de fiesta; es ingeniería de capacidad.

1. Establece la línea base de tu carga: throughput, relojes, potencia, temperatura, razones de throttling.
2. Aplica un power cap moderado y vuelve a medir bajo condiciones con soak térmico.
3. Detente cuando el rendimiento baje, la latencia cola empeore o aparezcan errores.
4. Codifica la configuración con systemd/gestión de configuración y despliega vía canarios.

Terminarás con GPUs que corren más frías, más silenciosas y a menudo más rápidas donde importa: trabajo sostenido y repetible en producción.
Que es el único tipo de rendimiento que importa una vez que has dejado atrás las gráficas de benchmarks.