Alguien del equipo compra un portátil “modelo RTX”, aprueban el presupuesto, llega la caja y luego los benchmarks se estrellan. Mismo nombre de GPU que las unidades de review, mismas viñetas de marketing, y aun así rinde como si corriera con un paracaídas.
Ese paracaídas suele ser el TGP: Total Graphics Power. Es el presupuesto de vatios que decide qué tan rápido se permite que funcione la GPU del portátil durante más de unos segundos. Las marcas saben que importa. También saben que arruina las jerarquías de producto limpias. Así que a menudo lo ocultan, lo diluyen o lo entierran en tres notas al pie.
TGP es el número de modelo real
En sobremesa, “RTX 4070” significa algo bastante estable. En portátiles, es más bien un apellido de familia. La persona real que te encuentras es “RTX 4070 Laptop GPU a 140 W con MUX y refrigeración decente” o “RTX 4070 Laptop GPU a 60 W en un chasis delgado que prioriza el silencio sobre la física”. Esos son productos diferentes con la misma placa.
El TGP es la envolvente de vatios para el paquete de la GPU (y a veces sus raíles de potencia asociados). Dicta relojes sostenidos, comportamiento sostenido de la memoria bajo carga y cuán agresivo puede ser el sistema al aumentar frecuencias cuando la CPU también demanda potencia. Si trabajas con rendimiento para ganarte la vida—SRE, desarrollador, diseñador, científico de datos—el comportamiento sostenido es lo único que importa. Los números de ráfaga son para diapositivas de keynote.
En la práctica, el TGP determina:
- Tasas de fotogramas y tiempos de render después de los primeros 30–120 segundos.
- Consistencia: stutter, jitter y “¿por qué esta compilación es más lenta a las 14:00 que a las 9:00?”
- Ruido de los ventiladores y temperatura de la piel: porque la potencia se convierte en calor, y el calor se vuelve ruido o throttling.
- Comportamiento de la batería: objetivos de potencia más altos a menudo implican conmutaciones más agresivas y peor estabilidad sin enchufe.
Si te llevas una cosa: al comparar portátiles, estás comparando sistemas de refrigeración y políticas de potencia tanto como GPUs.
TGP, TDP, TBP: qué es qué y por qué el marketing adora la confusión
Estos acrónimos son una tormenta perfecta de “suficientemente científico para sonar serio” y “lo bastante distinto para weaponizarlo en una ficha técnica”. Aquí tienes el mapeo práctico que funciona en campo.
TGP (Total Graphics Power)
El TGP es el presupuesto de potencia definido por el proveedor para la GPU del portátil. Normalmente se aplica por firmware y controladores como un límite de potencia (a veces múltiples límites: largo plazo, corto plazo y pico). Algunas plataformas permiten margen extra mediante funciones como NVIDIA Dynamic Boost, que puede desplazar el presupuesto de potencia de la CPU a la GPU en las condiciones adecuadas.
TDP (Thermal Design Power)
El TDP es un número para planificación térmica. En CPUs, puede ser una referencia para potencia sostenida a relojes base, no necesariamente el máximo. En GPUs, el marketing de portátiles a veces usa TDP de forma laxa cuando en realidad quiere decir “algún límite de potencia en ese vecindario”. No apuestes tu compra a eso.
TBP (Total Board Power)
En sobremesa, TBP a menudo incluye toda la tarjeta gráfica: GPU, VRAM, reguladores y a veces ventiladores. En portátiles, TBP se usa con menos consistencia. Algunos OEMs hablan de “Maximum Graphics Power” o “GPU power” y esperan que finjas que es un término estándar.
Lo que te importa al comprar o diagnosticar: la potencia sostenida real que consume la GPU bajo tu carga y si el sistema está limitado por potencia o por temperatura.
Una frase que mantengo pegada al monitor mental es una idea parafraseada a menudo atribuida a W. Edwards Deming: Si no puedes medirlo, no puedes mejorarlo.
Sea correcta la atribución o no, el punto es válido: no arreglas lo que te niegas a observar.
Cómo el TGP se convierte en FPS (y por qué no es lineal)
Más vatios suelen significar más rendimiento, pero no es una línea recta. Verás rendimientos decrecientes por curvas voltaje-frecuencia, cuellos de botella de memoria y saturación térmica. El modelo mental útil es:
- Bins de bajo TGP (p. ej., 45–80 W): la GPU suele estar limitada por potencia casi constantemente. El rendimiento escala mucho con los vatios. Estos son los portátiles donde “mismo nombre de GPU” no significa nada.
- Bins de TGP medio (p. ej., 90–115 W): la escala continúa pero empieza a aplanarse. La calidad de la refrigeración se convierte en diferenciador.
- Bins de alto TGP (p. ej., 125–175 W): aún puedes ganar rendimiento, pero lo pagas en ruido, calor y a veces portabilidad. Además, la CPU pasa a ser una parte mayor del rendimiento en juegos/estaciones de trabajo, especialmente en escenarios de FPS altos.
También, las GPUs de portátil rara vez van solas. Comparten un ecosistema térmico y de potencia con:
- Comportamiento de boost de la CPU (PL1/PL2 en Intel, PPT/EDC/TDC en AMD, límites OEM en ambos).
- Tubos de calor/cámara de vapor compartidos: la carga de la CPU puede calentar la ruta térmica de la GPU y viceversa.
- Refrigeración de VRM: reguladores sobrecalentados pueden disparar reducciones de potencia incluso cuando las temperaturas del die de la GPU parecen “bien”.
- Ruta de la pantalla: Optimus, Advanced Optimus, interruptor MUX y rutas de monitor externo pueden cambiar características de rendimiento y latencia.
Broma #1: El marketing de portátiles trata el vataje como tu salario—nunca se habla en público, y todo el mundo asume que es más alto de lo que es.
Por qué las marcas esconden el TGP
Porque el TGP rompe la historia ordenada. Si un proveedor deja claro “RTX 4070 (60 W)” junto a “RTX 4070 (140 W)”, un segmento de compradores entenderá al instante que no son lo mismo, y algunos degradarán el modelo delgado a una GPU más barata que rinde igual a menor potencia.
También hay razones prácticas por las que los OEMs se vuelven resbaladizos:
- La potencia es “hasta”: Dynamic Boost y modos OEM cambian límites según termales, tamaño del adaptador y carga CPU. Publicar un número único les parece arriesgado.
- Enredo de SKUs por región: el mismo chasis vendido en dos regiones puede salir con pads de refrigeración distintos, versiones de BIOS diferentes o adaptadores distintos.
- Objetivos acústicos: algunas líneas de producto están afinadas para ruido. No quieren “este es más lento” en negrita; quieren “studio-quiet”.
Como operador, no te importa por qué lo ocultan. Te importa que esté oculto. Trata el TGP escondido como un olor en la compra.
Datos interesantes y contexto histórico
Esto no es trivia por trivia. Explican por qué la potencia de GPU en portátiles se volvió un desastre.
- Branding “Max-Q” temprano (finales de 2010s) intentó señalar variantes de GPU enfocadas en eficiencia, pero las implementaciones OEM variaron enormemente en relojes, termales y objetivos de ruido.
- Más tarde, “Max-Q” dejó de ser un SKU distinto y se convirtió en un conjunto de tecnologías (gestión de potencia, afinación acústica), lo que dificultó inferir el vataje por el nombre.
- El nombre de GPU se reutilizó en grandes rangos de vatios a medida que los diseños de portátil se diversificaron: delgados, creador y reemplazos de sobremesa querían la misma insignia para vender.
- El desplazamiento de potencia estilo Dynamic Boost se volvió más común cuando los OEMs vieron que podían intercambiar margen de CPU por margen de GPU en juegos—hasta que la carga cambia y el intercambio duele.
- El adaptador de corriente entró en la ecuación: un sistema que se envía con un adaptador más pequeño puede limitar el consumo combinado CPU+GPU aunque la refrigeración pudiera soportar más.
- Cámaras de vapor y metal líquido ayudaron a algunos diseños a sostener TGP más altos, pero también aumentaron la variabilidad: la calidad de montaje y el efecto de degradación puede cambiar resultados a largo plazo.
- El ruteo de pantalla (Optimus vs MUX) se volvió un factor de rendimiento: a dónde van los fotogramas afecta overhead y latencia, especialmente en altas tasas de refresco.
- Las actualizaciones de firmware pueden cambiar límites: los OEMs a veces ajustan curvas de ventilador y límites después del lanzamiento por devoluciones, quejas de ruido o casos térmicos límite.
Guía rápida de diagnóstico
Si un portátil con una “buena GPU” se siente lento, no adivines. Puedes encontrar el cuello de botella en menos de 10 minutos si revisas las cosas correctas en el orden correcto.
Primero: confirma que realmente estás usando la ruta dGPU que crees
- ¿La aplicación se está ejecutando en la GPU discreta, no en la iGPU?
- ¿La pantalla interna está ruteada a través de la iGPU (Optimus) y cuesta rendimiento/latencia?
- ¿Una actualización de controladores restableció la configuración de “GPU preferida”?
Segundo: determina si estás limitado por potencia o por temperatura
- Observa consumo de potencia de la GPU, relojes y temperatura bajo una carga sostenida.
- Si el consumo alcanza un techo duro con temperaturas razonables, es un límite de potencia.
- Si la temperatura se queda en un techo y los relojes bajan, es throttling térmico o un problema de hotspot/VRM.
Tercero: identifica quién está robando el presupuesto (CPU vs GPU)
- Ejecuta una carga intensiva de GPU y otra intensiva de CPU por separado, luego juntas.
- Si la carga combinada hunde la potencia de la GPU, estás en un diseño de potencia/termal compartido donde el boost de la CPU es el abusón.
Cuarto: revisa modos OEM y comportamiento del BIOS/EC
- Los modos “Silent”, “Balanced” y “Performance” no son cosméticos. A menudo cambian los topes de TGP.
- Algunos modos sólo se desbloquean con corriente alterna y el adaptador correcto conectado.
Quinto: decide qué tipo de arreglo es aceptable
- Si es un fallo de compra: devolución/cambio, SKU distinto, chasis diferente.
- Si es un fallo de operaciones: controlador, modo, polvo, pasta térmica, curva de ventilador, plan de energía.
- Si es una limitación física: acéptalo o rediseña el requisito (eGPU, sobremesa, GPU remota).
Tareas prácticas: comandos, salidas y decisiones
Estos son chequeos reales y ejecutables. No son teóricos. Cada tarea incluye qué buscas y qué decisión tomas a partir de ello. Los ejemplos asumen Linux. Windows tiene herramientas equivalentes, pero Linux te deja ver la tubería sin un baile interpretativo GUI.
Task 1: Identify the GPU and driver actually in use
cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display'
00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Xe Graphics [8086:9a49]
01:00.0 3D controller [0302]: NVIDIA Corporation AD106M [GeForce RTX 4070 Laptop GPU] [10de:2820]
Qué significa: Tienes una iGPU y una dGPU NVIDIA. La dGPU está presente en PCIe y debería ser utilizable.
Decisión: Continúa. Si la dGPU no aparece listada, estás ante una configuración del BIOS, una ausencia de hardware o un dispositivo muerto—no un misterio de TGP.
Task 2: Confirm the NVIDIA driver is loaded and the GPU is visible to NVML
cr0x@server:~$ nvidia-smi
Tue Jan 13 10:22:41 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 555.58.02 Driver Version: 555.58.02 CUDA Version: 12.5 |
|-----------------------------------------+------------------------+----------------------|
| 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 GeForce RTX 4070 ... Off | 00000000:01:00.0 Off | N/A |
| N/A 54C P2 62W / 140W | 2210MiB / 8192MiB | 43% Default |
+-----------------------------------------+------------------------+----------------------+
Qué significa: NVML reporta un tope de potencia de 140 W. Eso es una pista fuerte del techo de TGP configurado (o uno de ellos).
Decisión: Si Pwr:Usage/Cap muestra algo como 50W / 60W en un modelo supuestamente de alto rendimiento, has encontrado al culpable. Siguiente: verifica si ese tope cambia con modos OEM, adaptador de CA o Dynamic Boost.
Task 3: Sample power draw and clocks over time (sustained behavior)
cr0x@server:~$ nvidia-smi --query-gpu=timestamp,power.draw,power.limit,clocks.sm,clocks.mem,temperature.gpu,utilization.gpu --format=csv -l 2
timestamp, power.draw [W], power.limit [W], clocks.sm [MHz], clocks.mem [MHz], temperature.gpu, utilization.gpu [%]
2026/01/13 10:23:02, 118.45 W, 140.00 W, 2100 MHz, 8001 MHz, 72, 98 %
2026/01/13 10:23:04, 139.12 W, 140.00 W, 2235 MHz, 8001 MHz, 78, 99 %
2026/01/13 10:23:06, 139.87 W, 140.00 W, 2220 MHz, 8001 MHz, 79, 99 %
Qué significa: La GPU está saturando el límite de potencia mientras la utilización se mantiene alta. Eso es un clásico comportamiento limitado por potencia.
Decisión: Si el rendimiento es bajo y estás pegado a un límite de potencia bajo, tus únicas soluciones son: cambiar modo/BIOS, mejorar la refrigeración (a veces aumenta la potencia permitida) o aceptar que el SKU es de bajo TGP por diseño.
Task 4: Check for Optimus/iGPU display path (common hidden tax)
cr0x@server:~$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x43 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 5 associated providers: 1 name:modesetting
Provider 1: id: 0x1f3 cap: 0x2, Sink Output crtcs: 4 outputs: 4 associated providers: 1 name:NVIDIA-G0
Qué significa: El sistema probablemente está en modo híbrido donde la iGPU es la proveedora de pantalla primaria y la GPU NVIDIA es un dispositivo de offload.
Decisión: Si necesitas FPS máximos/latencia mínima, considera habilitar un modo MUX “solo dGPU” (si está disponible) o usar un monitor externo conectado a la salida de la dGPU.
Task 5: Confirm which GPU is rendering a given app (per-process)
cr0x@server:~$ nvidia-smi pmon -c 1
# gpu pid type sm mem enc dec jpg ofa command
0 24819 G 78 12 0 0 0 0 blender
Qué significa: El proceso está usando la GPU NVIDIA (bien). Si no ves nada, probablemente estás en la iGPU o usando ruta de render por CPU.
Decisión: Si la app no está en la dGPU, arregla la configuración de la aplicación, variables de entorno o la preferencia de GPU del SO antes de culpar al TGP.
Task 6: See whether power management is clamping performance states
cr0x@server:~$ nvidia-smi --query-gpu=pstate,clocks.sm,clocks.gr,clocks.mem --format=csv
pstate, clocks.sm [MHz], clocks.gr [MHz], clocks.mem [MHz]
P2, 2100 MHz, 2100 MHz, 8001 MHz
Qué significa: Muchas GPUs de portátil se quedan en P2 bajo cargas de cómputo; P0 es común en gaming/gráficos. No te alarmes sólo porque no esté en P0, pero vigila relojes y utilización.
Decisión: Si estás atascado en un estado P bajo con relojes bajos mientras la utilización es alta, puede indicar un tope por política, un fallo de controlador o estar en batería/modo silencioso.
Task 7: Check AC adapter and power supply constraints (the silent limiter)
cr0x@server:~$ upower -d | sed -n '/line-power/,/Device/p'
Device: /org/freedesktop/UPower/devices/line_power_AC
native-path: AC
power supply: yes
online: yes
has history: no
has statistics: no
Qué significa: La máquina ve alimentación CA. Algunos OEMs aún aplican topes distintos según la potencia del adaptador, pero al menos no estás en “modo batería”.
Decisión: Si online: no, deja de probar rendimiento. Conecta la alimentación. Luego vuelve a probar, porque el modo batería suele recortar el TGP fuertemente.
Task 8: Look for CPU power limits that starve the GPU
cr0x@server:~$ sudo turbostat --Summary --quiet --interval 2 | head -n 6
Avg_MHz Busy% Bzy_MHz IPC PkgWatt CorWatt GFXWatt
3180 62.14 5116 1.41 62.33 39.88 0.05
4022 71.02 5663 1.38 78.90 52.41 0.06
Qué significa: La potencia del paquete CPU es alta. En un diseño térmico compartido, esto puede reducir el margen de la GPU vía reversión de Dynamic Boost o saturación térmica.
Decisión: Si el rendimiento de la GPU cae cuando la CPU está activa, limita el boost de la CPU (ajuste OEM, plan de energía) o elige un portátil con mejor refrigeración compartida.
Task 9: Check kernel logs for thermal or power events
cr0x@server:~$ sudo dmesg -T | egrep -i 'thrott|thermal|power limit' | tail -n 8
[Tue Jan 13 10:18:11 2026] thermal thermal_zone7: critical temperature reached (105 C), shutting down
[Tue Jan 13 10:19:42 2026] CPU: Package power limit exceeded, capping frequency
[Tue Jan 13 10:23:15 2026] nvidia-modeset: WARNING: GPU temperature threshold exceeded, performance state reduced
Qué significa: El sistema se delata. Esos mensajes distinguen entre “el TGP es bajo por diseño” y “tu refrigeración está fallando”.
Decisión: Si ves eventos críticos térmicos, para. Limpia, repasta, revisa comportamiento de ventiladores y valida las salidas. Esto es trabajo de fiabilidad, no de ajuste fino.
Task 10: Verify fan control and thermal zones (are fans even responding?)
cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +93.0°C (high = +100.0°C, crit = +105.0°C)
nvme-pci-0100
Adapter: PCI adapter
Composite: +68.9°C (low = -0.1°C, high = +84.8°C)
nvidia-gpu-pci-0100
Adapter: PCI adapter
temp1: +79.0°C
Qué significa: La CPU está muy caliente, la GPU está tibia, el NVMe está caliente. Ese valor de NVMe importa más de lo que la gente piensa: la limitación del SSD puede disfrazarse como “GPU lenta” en cargas de creación de contenido.
Decisión: Si la CPU está cerca de crítico bajo carga mixta, espera que la potencia de la GPU caiga. Mejora la refrigeración, cambia modo o reduce el boost de la CPU.
Task 11: Check NVMe throttling during “GPU workloads” that actually stream data
cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep -i 'temperature|warning|critical'
temperature : 69 C
warning_temp_time : 17
critical_comp_time : 0
Qué significa: El SSD ha pasado tiempo por encima de su temperatura de aviso. En builds con muchos activos o en scrubbing de vídeo, eso puede reducir el throughput y causar paradas.
Decisión: Si el tiempo de aviso crece durante tu carga, añade un pad térmico/disipador al NVMe, mejora el flujo de aire o evita portátiles que monten el NVMe bajo una GPU que calienta mucho.
Task 12: Validate that the GPU is hitting “PerfCap” reasons (power vs thermal)
cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '/Performance State/,/Clocks Event Reasons/p'
Performance State : P2
Clocks Event 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
Qué significa: La GPU está siendo limitada por un tope de potencia por software, no por termales. Esa es la huella de un tope de TGP bajo o un modo que limita vatios.
Decisión: Si SW Power Cap: Active domina, persigue la política de potencia (modo OEM, Dynamic Boost, driver, límites VBIOS). Si HW Thermal Slowdown está activo, persigue la refrigeración.
Task 13: Watch CPU frequency scaling policy (Linux power governor matters)
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Qué significa: Estás en powersave. En muchos sistemas esto puede reducir la capacidad de respuesta y cambiar cómo la plataforma comparte potencia.
Decisión: Para pruebas de rendimiento, establece una política consistente. Si no puedes, tus datos de benchmark son basura.
Task 14: Set a consistent CPU governor for repeatable tests
cr0x@server:~$ sudo apt-get install -y linux-tools-common linux-tools-generic
...output...
cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Qué significa: Has reducido una fuente de variación. Ahora el comportamiento de potencia de la GPU es más fácil de interpretar.
Decisión: Usa esto antes de comparar “modo A vs modo B” o antes de culpar al TGP. De lo contrario estarás midiendo el governor.
Task 15: Confirm if the system is running in a vendor “quiet” mode (common hidden TGP clamp)
cr0x@server:~$ cat /sys/firmware/acpi/platform_profile
quiet
Qué significa: La plataforma está explícitamente ajustada para operación silenciosa. Eso suele implicar curva de ventilador reducida y menor TGP.
Decisión: Cambia a performance o balanced para trabajo real si necesitas la GPU. Si eso no es aceptable acústicamente, compraste el chasis equivocado para la tarea.
Task 16: Switch platform profile (when supported) and re-measure power cap
cr0x@server:~$ echo performance | sudo tee /sys/firmware/acpi/platform_profile
performance
cr0x@server:~$ nvidia-smi --query-gpu=power.limit --format=csv
power.limit [W]
140.00 W
Qué significa: En algunos sistemas el tope de GPU cambia con el perfil; en otros no. Lo importante es que lo mediste, no que lo supusieras.
Decisión: Si el límite aumenta tras cambiar el perfil, incorpora eso en tu procedimiento operativo estándar. Si no cambia, probablemente estés atado por VBIOS o topes duros del OEM.
Tres microhistorias corporativas del mundo real
Microhistoria 1: El incidente causado por una suposición errónea
Un equipo de diseño desplegó un nuevo estándar de portátil para un grupo distribuido que hacía renders acelerados por GPU. Compras hizo lo que hace compras: estandarizó en un único modelo “clase RTX” y negoció un descuento. Todos contentos. Durante unas dos semanas.
Entonces llegaron los tickets. Los renders tardaban entre 30–50% más que la generación anterior. Al principio se asumió regresión de drivers, luego se culpó al renderizador y después a actualizaciones de Windows. Los SREs se vieron arrastrados porque “el render farm está lento”, aunque la mitad de los trabajos se ejecutaban localmente en portátiles.
El equipo hizo lo obvio primero: benchmark lado a lado del antiguo y el nuevo. El nuevo portátil alcanzaba relojes impresionantes durante un minuto y luego se asentaba en un estado sostenido que era… sospechosamente mediocre. Los termales estaban bien. Los ventiladores eran silenciosos. Demasiado silenciosos.
La causa raíz fue dolorosamente simple: asumieron que el nombre de la GPU implicaba una clase de rendimiento. No era así. La GPU del nuevo portátil estaba configurada con un TGP mucho más bajo que el modelo anterior. Misma insignia. Física distinta. El proveedor había optimizado el chasis para confort acústico y duración de batería, y el límite de potencia de la GPU formaba parte de ese trato.
La solución no fue un ajuste. Fue revertir la compra. Trasladaron al equipo a un chasis más grueso con mayor límite de potencia sostenida y pusieron “potencia GPU sostenida mínima” como requisito en la siguiente RFP. La lección real: trata el nombre de la GPU como una pista, no como un contrato.
Microhistoria 2: La optimización que salió mal
Un grupo de producto quería más autonomía de batería en viajes. Desplegaron un script de “eficiencia”: pone el perfil de plataforma en quiet, prefiere iGPU para la mayoría de apps y limita el rendimiento de la CPU. El despliegue fue limpio, automatizado y con buena intención.
Luego vinieron los bugs raros. Los desarrolladores dijeron que las compilaciones Docker iban bien, pero sus notebooks de ML eran inconsistentes. A veces el entrenamiento era rápido; a veces iba muy lento. Las videollamadas ocasionalmente provocaban tartamudeos durante una compilación intensiva en GPU. Todos culparon “al driver GPU” porque es lo habitual.
El postmortem fue un clásico “dos optimizaciones que colisionan”. El modo quiet redujo la agresividad del ventilador y limitó la potencia de la GPU. Mientras tanto, el tope de la CPU cambió cómo la plataforma asignaba potencia compartida. Bajo cargas mixtas—navegador, llamada, notebook—el sistema oscilaba entre políticas y la GPU daba topes de potencia de forma impredecible.
Intentaron arreglarlo con más scripts. Empeoró. La solución real fue aburrida: separar el modo viaje del modo estación de trabajo y hacer el cambio de modo explícito. Con CA y en modo workstation, el portátil corrió con un tope de GPU alto y termales predecibles. En batería y modo viaje, los usuarios aceptaron entrenamientos más lentos como intercambio.
La optimización falló porque no estaba acotada. Las políticas de eficiencia deben ser opt-in y conscientes de la carga. Si no, se vuelven incidentes de rendimiento invisibles.
Microhistoria 3: La práctica aburrida pero correcta que salvó el día
Un equipo de medios tenía la costumbre que parecía pedante: cada SKU de portátil nuevo pasaba por una breve “prueba de rendimiento sostenido”. Diez minutos de carga intensiva de GPU, diez minutos de carga intensiva de CPU y luego diez minutos de carga combinada. Registraban consumo de potencia, relojes y temperaturas, y guardaban los resultados junto a los registros de compra.
No era glamuroso. No daba diapositivas. Pero sí creó una línea base. Cuando una actualización de firmware llegó a mitad de trimestre y los editores empezaron a quejarse por tiempos de exportación, el equipo no discutió sensaciones. Compararon la nueva telemetría con la línea base.
Los datos mostraron que el tope de potencia de la GPU no cambió, pero el comportamiento de la curva de ventilador sí; la GPU ahora sufría slowdown térmico en las mismas condiciones ambientales. La actualización era probablemente un ajuste para controlar el ruido. El equipo volvió a la versión anterior del firmware en las unidades afectadas, la fijó como estable y escaló el problema al proveedor con evidencia.
Evitaban un mes de pérdida de productividad porque trataron los portátiles como sistemas de producción: establece una línea base, observa y controla cambios. Aburrido. Correcto. Eficaz.
Errores comunes: síntoma → causa raíz → solución
Esta es la parte donde dejamos de culpar a la “mala silicona” y empezamos a diagnosticar como adultos.
1) Síntoma: “Misma GPU que en reviews, pero 20–40% más lenta”
Causa raíz: Configuración de TGP más baja (a menudo ligada a chasis delgado, perfil silencioso o SKU regional).
Solución: Verifica el tope de potencia con nvidia-smi. Revisa modo de rendimiento OEM y ajustes MUX. Si el tope es fundamentalmente bajo, cambia por un SKU de mayor TGP o por otro chasis.
2) Síntoma: “Rápido durante un minuto, luego cae y se mantiene bajo”
Causa raíz: Saturación térmica o sobrecalentamiento de VRM; a veces tubos de calor compartidos con la CPU provocan soak térmico.
Solución: Registra temperaturas y razones de PerfCap. Limpia las ventilaciones, valida el rampado del ventilador, considera repastar. Reduce el boost de la CPU para cargas mixtas.
3) Síntoma: “El consumo GPU no supera X vatios incluso estando frío”
Causa raíz: Tope de potencia por software (política), límite VBIOS o tope del modo OEM.
Solución: Cambia el perfil de plataforma, asegúrate de CA y del adaptador correcto, actualiza BIOS/EC y vuelve a probar. Si no cambia, asume que es un límite de diseño.
4) Síntoma: “El monitor externo hace los juegos más rápidos”
Causa raíz: Pantalla interna ruteada por la iGPU (Optimus), el puerto externo está cableado a la dGPU.
Solución: Usa MUX “solo dGPU” para la pantalla interna si está disponible, o usa el puerto cableado a la dGPU para sesiones críticas de rendimiento.
5) Síntoma: “Baja utilización de GPU, pero FPS también bajos”
Causa raíz: Cuello de botella de CPU, presupuesto de potencia robado por la CPU o un tope/sincronización (V-Sync, limitador de frames).
Solución: Revisa potencia de paquete CPU y frecuencia por núcleo bajo carga, desactiva límites para pruebas y compara comportamiento GPU-only vs carga combinada.
6) Síntoma: “Rendimiento inconsistente día a día”
Causa raíz: Cambios de temperatura ambiente, acumulación de polvo, cambios de firmware o apps en segundo plano que alteran la carga CPU (y por tanto la potencia compartida).
Solución: Haz una línea base en un modo controlado, sigue versiones de firmware/driver y mide razones de PerfCap para separar térmico de políticas.
7) Síntoma: “En batería, es inutilizable”
Causa raíz: Límites de descarga de batería recortan fuertemente potencia de GPU y CPU para proteger la batería.
Solución: Acepta la física. Para trabajo GPU, conecta a CA. Si necesitas rendimiento de GPU sin enchufe, estás describiendo otra clase de dispositivo (y será más pesado).
8) Síntoma: “Después de actualizar el driver, la GPU no hace boost”
Causa raíz: Ajustes restablecidos (selección de GPU por app, modo de gestión de energía) o un bug que interactúa con EC del OEM.
Solución: Revisa la selección por app, verifica topes de potencia y revierte si es necesario. Trata las actualizaciones de driver como ventanas de cambio.
Listas de verificación / plan paso a paso
Lista de compra: cómo no comprar el “mismo GPU” equivocado
- Exige el rango de TGP por escrito para el SKU exacto (no la familia del producto).
- Exige la potencia del adaptador incluido en la caja; no dejes que “varíe por región”.
- Pregunta si existe un interruptor MUX y si puede forzarse a solo dGPU.
- Pide reclamaciones de rendimiento sostenido (10–20 minutos de carga), no solo “boost clock”.
- Prefiere reseñas que registren vatios con el tiempo y muestren razones de PerfCap, no solo FPS promedio.
- Compra una unidad primero, ejecuta tu prueba de intake y luego escala el pedido.
Lista de prueba de entrada (15–30 minutos por modelo)
- Actualiza OS, pero fija versiones de drivers durante la ventana de prueba.
- Establece perfil de plataforma consistente (balanced o performance) y confirma CA.
- Registra potencia/reloj/temp de la GPU cada 2 segundos durante una carga sostenida.
- Ejecuta carga solo CPU y observa si luego cambia el tope de potencia de la GPU.
- Ejecuta carga combinada CPU+GPU y mide si la potencia de la GPU colapsa.
- Registra temperatura ambiente y ruido de ventilador subjetivamente (“silencioso, tolerable, secador de pelo”).
- Guarda logs junto con el registro de compra.
Lista de operaciones: cuando un usuario dice “mi portátil GPU va lento”
- Verifica que la app use la dGPU (no la iGPU).
- Verifica que el portátil esté en CA y en un perfil no silencioso.
- Revisa el tope de potencia en
nvidia-smiy razones de PerfCap bajo carga. - Revisa temperaturas y mensajes dmesg de límite térmico/potencia.
- Verifica si la ruta de pantalla externa cambia el rendimiento.
- Decide: arreglo de configuración, mantenimiento o cambio de compra.
Broma #2: Si quieres un portátil delgado, silencioso, fresco y rápido, estás buscando un unicornio—alimentado por un adaptador de 240W.
Preguntas frecuentes
1) ¿Qué es exactamente el TGP?
El TGP es el presupuesto de potencia que el portátil permite que consuma la GPU bajo carga sostenida. Un TGP más alto suele implicar relojes sostenidos y mejor rendimiento—siempre que la refrigeración acompañe.
2) ¿Por qué dos portátiles con el mismo nombre de GPU rinden distinto?
Porque el nombre no incluye el límite de potencia, la capacidad de refrigeración, el diseño de VRM, las reglas OEM de reparto de potencia o el ruteo de pantalla. En portátiles, esos factores hacen el producto.
3) ¿Es fiable “hasta 140W”?
Es un techo, no una promesa. Puede que solo lo alcances bajo condiciones específicas: CA, modo performance, ambiente fresco y una carga que dependa de la GPU sin que la CPU le robe presupuesto.
4) ¿Más TGP siempre es mejor?
No siempre. Más allá de cierto punto, obtienes rendimientos decrecientes y mucho más ruido y calor. Además, algunos portátiles de alto TGP ejecutan mal la refrigeración y acaban haciendo throttling de todas formas.
5) ¿Cómo compruebo el TGP en un portátil que ya tengo?
En NVIDIA, nvidia-smi suele mostrar un tope de potencia. El método más fiable es registrar el consumo real bajo carga sostenida y comprobar las razones de PerfCap para ver qué te limita.
6) ¿Cuál es la relación entre Dynamic Boost y TGP?
Dynamic Boost puede desplazar el presupuesto de potencia entre CPU y GPU. Puede aumentar efectivamente la potencia GPU en cargas GPU-intensivas, pero también puede reducir el margen GPU cuando la carga CPU sube.
7) ¿Importa un interruptor MUX para el TGP?
No directamente, pero puede cambiar el rendimiento real. Un MUX puede rutear la pantalla directamente a la dGPU, reduciendo overhead y a veces mejorando consistencia y latencia.
8) ¿Puede el undervolting ayudar en un portátil de bajo TGP?
Pueda ayudar eficiencia y termales, lo que podría permitir que la GPU mantenga relojes más altos dentro del mismo tope de potencia. Pero el undervolting no convertirá un diseño de 60W en uno de 140W.
9) ¿Por qué mi GPU alcanza altas temperaturas incluso a vatios modestos?
Limitaciones de refrigeración: ventilaciones obstruidas, pasta seca, mal contacto, curvas de ventilador conservadoras o soak térmico desde la CPU. También revisa límites de VRM o hotspots que no son obvios desde un único valor de “temp GPU”.
10) ¿Debo priorizar TGP de GPU o rendimiento de CPU para el trabajo?
Depende de la carga. Para renderizado GPU, entrenamiento ML y juegos, el TGP suele ser decisivo. Para compilaciones y simulaciones intensivas en CPU, la potencia sostenida y refrigeración de la CPU importan más. Muchas cargas reales son mixtas, así que quieres un portátil que no colapse bajo carga combinada.
Conclusión: qué hacer a continuación
Si vas a comprar: exige el vataje. No “RTX lo que sea”, no “Max performance”, no “creator edition”. Pide el rango del límite de potencia de la GPU, la potencia del adaptador y si el portátil puede sostener esa potencia al menos 10–15 minutos sin throttling. Si el vendedor no puede responder, trátalo como un riesgo no acotado—porque lo es.
Si estás diagnosticando: deja de discutir con sensaciones. Mide consumo de potencia GPU, topes de potencia, razones de PerfCap y temperaturas bajo una carga sostenida. Decide si estás limitado por potencia, por temperatura o si la CPU te roba presupuesto. Luego elige la categoría de arreglo: modo/configuración, mantenimiento o reemplazo. Los sistemas de producción no se arreglan deseando. Los portátiles tampoco.