RTX 20, 30 y 40: los modders liberan la potencia de IA oculta

Los proyectos gpu-unlock, gpu-unlock-ada y Turing-unlock abordan una limitación del rendimiento de ciertas instrucciones Tensor en las GeForce. Los casos mejor documentados afectan a cálculos FP16 o BF16 con acumulación en FP32, así como a TF32 en las arquitecturas compatibles. La acumulación indica la precisión utilizada para sumar los resultados intermedios: dos cálculos con datos FP16 no siguen necesariamente la misma ruta de hardware.

El desbloqueo se aplica antes de cargar el controlador de NVIDIA y modifica ajustes internos de la GPU. No añade núcleos ni memoria de vídeo y no requiere flashear el VBIOS. Su efecto es volátil: una interrupción de la alimentación de la GPU puede borrarlo. Los proyectos retoman trabajos realizados con tarjetas de minería CMP, adaptados especialmente por Zagitta y, en el caso de Ada, a partir del trabajo de TOTORONG.

Los resultados siguientes proceden de los desarrolladores y sus colaboradores. Hardware Reference ha contrastado las publicaciones y los protocolos; no hemos reproducido estas pruebas en nuestro propio banco de pruebas.

El repositorio gpu-unlock de Zagitta recopila las siguientes mediciones de multiplicación de matrices densas con acumulación FP32. Las cifras están redondeadas en su resumen; los porcentajes son los anunciados por el proyecto a partir de las mediciones originales.

Estos informes utilizan configuraciones diferentes: ilustran la mejora antes/después en cada tarjeta y no constituyen una clasificación realizada con un protocolo común. Los TFLOPS expresan aquí rendimiento de cálculo, no fotogramas por segundo en un juego.

El informe comparativo antes/después de gpu-unlock-ada resulta especialmente instructivo. Se comparó la misma RTX 4090 antes y después de la activación, con el controlador NVIDIA 615.78.08, CUDA 13.4.92 y un límite de 450 W. El rendimiento de las instrucciones pasa de 160,4 a 320,4 TFLOPS en FP16/FP32 y de 159,7 a 320,2 TFLOPS en BF16/FP32.

Ampliar

Las multiplicaciones de matrices cuBLAS de esa misma comparación muestran diferencias más modestas. Todas utilizan acumulación FP32; N indica el tamaño de las matrices cuadradas N × N. Los valores son las medianas publicadas y las diferencias siguientes se calculan a partir de ellos.

El caso BF16 a 4 096³ permanece, por tanto, prácticamente sin cambios. El informe abarca una sola pareja de mediciones, con el escritorio activo, y no valida la estabilidad prolongada. FP16 con acumulación FP16 y las pruebas de control INT8 también se mantienen cerca de su nivel inicial.

El repositorio Turing-unlock documenta una prueba realizada el 22 de octubre con una ASUS RTX 2080 Ti de 11 GiB. El rendimiento de las instrucciones FP16 con acumulación FP32 pasa de 46,9361 a 93,6649 TFLOPS, casi el doble. En la multiplicación cuBLAS a 8 192³, aumenta de 48,1488 a 85,1705 TFLOPS, aproximadamente un 77 %. FP16 con acumulación FP16 permanece sin cambios.

Esta demostración se refiere a una tarjeta y una plataforma identificadas con precisión. Su cargador experimental no es un instalador universal. También muestra que desbloquear el cálculo no exige aumentar la capacidad de memoria: los 11 GiB de la tarjeta siguieron siendo 11 GiB.

La prueba de Cryptolab aporta un contrapunto útil. Compara 18 solicitudes en total con Qwen3.8 27B Q4_K_M y MTP en Ollama 0.33.2, sobre una RTX 3090 de 24 GiB limitada a 350 W. Cada perfil incluye tres pruebas por estado, con una salida de 256 tokens. Las tasas siguientes son medianas, en tokens por segundo.

Hay que interpretar estos resultados con cautela: las frecuencias no estaban fijadas y las condiciones térmicas diferían entre las series. En particular, la frecuencia SM mediana medida pasa de 1 470 a 1 545 MHz. Estas diferencias describen el rendimiento observado sin aislar el efecto del desbloqueo por sí solo. Las respuestas emparejadas tienen, no obstante, las mismas huellas SHA-256.

Las tareas de difusión pueden beneficiarse más de los cálculos afectados. Un colaborador de nv-uefi-unlocker comunica los dos primeros resultados siguientes con una RTX 3080 LHR en Windows y tres pruebas por estado. Otro informe sobre una RTX 4090 mide LTX-2.5 en ComfyUI. Cada fila compara el mismo trabajo antes y después del desbloqueo; las máquinas y los modelos difieren entre filas.

El porcentaje indica el aumento del rendimiento para un mismo trabajo, calculado como duración antes / duración después − 1. Un aumento del rendimiento del 28,8 % equivale así a aproximadamente un 22,3 % menos de tiempo. En la RTX 4090, el beneficio cambia con el límite de potencia; el desbloqueo por sí solo no elimina esa restricción.

Un LLM primero procesa el prompt y después genera su respuesta token a token. La primera fase puede implicar muchas multiplicaciones de matrices. La segunda suele estar limitada por las transferencias de memoria, especialmente para una solicitud aislada. Acelerar los Tensor Cores no resuelve ese segundo cuello de botella.

Un informe publicado el 31 de octubre sobre una RTX 3070 Ti ilustra esta diferencia con Qwen3-1.7B BF16 en llama.cpp: el procesamiento de 4 096 tokens pasa de 9 382 a 12 895 tokens/s, aproximadamente un 37 % más, mientras que la generación se mantiene en 141,8 y después 141,7 tokens/s. El mismo modelo en Q8_0 solo mejora alrededor de un 2 % en el procesamiento del prompt.

En la conversación de LocalLLaMA enlazada en torno al proyecto, un usuario de una RTX 3080 con memoria modificada también comunica que no obtuvo mejoras con su modelo Q6_K. Este testimonio no sustituye a un protocolo completo, pero recuerda un punto esencial: el formato de los pesos no basta para prever la mejora. Hay que conocer las operaciones que realmente utiliza el motor de inferencia.

INT8 y el cálculo CUDA FP32 convencional no se duplican en las pruebas de control publicadas. FP8 requiere más matices: el repositorio de Ada describe mejoras en ciertas rutas FP8 con acumulación FP32, pero también pruebas prácticamente sin cambios. Por tanto, sería engañoso presentar todos los modelos INT8 o FP8 como automáticamente acelerados. Estos resultados no demuestran ninguna mejora de FPS en juegos.

La novedad difundida por VideoCardz es nv-uefi-unlocker, desarrollado por physicsdolphin. Esta herramienta se ejecuta desde una memoria USB antes del sistema operativo, aplica el procedimiento y después devuelve el control al cargador de arranque de Windows o Linux. Evita repetir manualmente una larga secuencia en cada prueba, pero sigue requiriendo preparación y comprobaciones en la máquina de destino.

Por defecto, su pantalla de inicio solicita confirmación. La documentación contempla un modo automatizado explícito y pide repetir la operación después de un arranque en frío. Una prueba con una RTX 4060 Laptop mide un aumento de 29,89 a 49,02–49,33 TFLOPS en GEMM FP16 a 4 096, aproximadamente un 65 % más, únicamente con este desbloqueo.

Fuente: matriz de compatibilidad detallada, consultada el 31 de octubre de 2026.

El procedimiento UEFI estándar requiere desactivar Secure Boot o utilizar una aplicación EFI firmada con una clave reconocida. Los portátiles pueden perder el desbloqueo cuando se apaga la GPU dedicada. Los autores también señalan fallos de arranque en algunas plataformas: la automatización no convierte una modificación experimental en una función con soporte oficial de NVIDIA.

La publicación de Mia del 24 de octubre que aparece a continuación difundía los primeros resultados de Ampere, centrados entonces sobre todo en Linux. Los proyectos han evolucionado desde entonces, especialmente con la herramienta UEFI.