Dos propietarios de portátiles con Snapdragon X2 Elite atribuyen al driver gráfico Adreno 32.0.181.0, distribuido por Qualcomm a finales de octubre, una caída de rendimiento de entre el 69 y el 87 % al ejecutar modelos de lenguaje en local y renders hasta seis veces más lentos en Adobe Premiere Pro. Los avisos, publicados en el foro r/snapdragon de Reddit con pocos días de diferencia y recogidos el 1 de noviembre por Wccftech, no cuentan por ahora con confirmación ni respuesta de Qualcomm.
Las claves del driver Adreno 32.0.181.0 en 20 segundos
- Qué ha pasado: tras actualizar del driver 32.0.172.2 al 32.0.181.0, un Surface Laptop con Snapdragon X2 Elite pasa de 98,1 a 12,8 tokens por segundo en GPU con llama.cpp.
- Qué se ve afectado: solo la ruta OpenCL de la GPU Adreno. La CPU, la NPU y WebGPU mantienen sus cifras.
- Quién lo dice: dos usuarios de Reddit; uno aporta mediciones repetibles y el otro, en Premiere, no conserva pruebas.
- Qué hacer: quien dependa de IA local en GPU o de render acelerado puede quedarse en la 32.0.172.2 o revertir el controlador hasta que haya corrección.
Una actualización pensada para juegos
El driver 32.0.181.0 no se presentó como una mejora de cómputo. Según las notas de versión recogidas por VideoCardz, la actualización llega a través del Snapdragon Control Panel y del Software Center de Qualcomm, sustituye a la 31.0.170.0 en la primera generación de Snapdragon X y a la 32.0.172.2 en la familia X2, y su lista de cambios se centra en estabilidad y calidad gráfica en títulos concretos. En los equipos X2 menciona, entre otros, Assassin’s Creed Black Flag Resynced, Forza Horizon 6, Grand Theft Auto V Legacy, Marvel Rivals, NBA 2K26 y World War Z.
Nada en ese registro de cambios anticipa efectos sobre OpenCL, la interfaz de cómputo que usan muchas aplicaciones para mandar trabajo general, no gráfico, a la GPU. Y ahí es justo donde aparece el problema. Conviene recordar además que este paquete genérico de Qualcomm es independiente de los drivers que publica cada fabricante de portátiles en su página de soporte, que suelen llegar más tarde y con su propia validación.
Las dos denuncias afectan, por ahora, solo a equipos Snapdragon X2. No hay informes de comportamiento similar en la primera generación de Snapdragon X, que recibe el mismo número de versión, aunque la ausencia de quejas tampoco equivale a una comprobación.
De 98 a 13 tokens por segundo en el mismo portátil
El informe más detallado es el del usuario de Reddit u/NonVeganLasVegan, que trabaja con un Microsoft Surface Laptop 8th Edition con Snapdragon X2 Elite y GPU Adreno X2-85. Ejecutó la generación de texto con llama.cpp, el motor de código abierto más extendido para correr modelos de lenguaje en equipos personales, usando su backend OpenCL, que es el que emplea sobre GPU Adreno en Windows. Según su relato, el portátil, el software, los modelos y el sistema operativo eran los mismos en ambas pruebas, y el equipo estaba conectado a la corriente.
Las cifras que publicó, en tokens por segundo de generación en GPU:
| Modelo | Driver 32.0.172.2 | Driver 32.0.181.0 | Caída |
|---|---|---|---|
| Qwen3-0.6B | 98,1 | 12,8 | 87 % |
| Qwen3-4B | 29,5 | 9,0 | 69 % |
| Qwen3-Coder-30B-A3B-Instruct | 26,8 | 5,9 | 78 % |
Lo que da peso al informe no es la magnitud de la caída sino el método. El usuario instaló y desinstaló el driver varias veces: el problema aparecía con la 32.0.181.0 y desaparecía al volver a la 32.0.172.2. También midió las otras vías de cálculo del chip. La generación de texto en CPU apenas varió entre un 1 y un 4 %, y la NPU se movió dentro de un margen de unos pocos puntos en uno u otro sentido. El mismo modelo pequeño, Qwen3-0.6B, ejecutado en la GPU pero a través de WebGPU en lugar de OpenCL, se mantuvo en torno a 90 tokens por segundo con ambos drivers.
El procesamiento del prompt —la fase en la que el modelo lee la entrada antes de empezar a responder— no cambió en los modelos pequeños, pero cayó un 73 % en Qwen3-Coder-30B-A3B-Instruct. Con todo ello, el autor concluye que la regresión está en la implementación de OpenCL del nuevo controlador y no en el hardware ni en llama.cpp.
Premiere Pro: de 1 minuto y 40 segundos a 10 minutos
El segundo aviso es menos sólido. El usuario u/FullTimePedestrian, propietario de un ASUS Zenbook A16 —el mismo modelo de portátil en el que se ha probado Snapintosh, el proyecto que lleva macOS 27 a un equipo con Snapdragon X2 y GPU Adreno—, advirtió a otros usuarios de que no actualizaran al 32.0.181.0 si trabajan con Adobe Premiere Pro. Según su testimonio, un vídeo de siete minutos en 1080p que antes exportaba en 1 minuto y 40 segundos pasó a tardar unos diez, aproximadamente seis veces más. No guardó capturas ni registros de la prueba anterior, de modo que la cifra es una estimación personal y no puede contrastarse.
Que coincida en el tiempo y en la versión con el caso de llama.cpp hace razonable sospechar una causa común en la parte de cómputo del driver, pero es una hipótesis, no un hecho demostrado: Premiere no depende necesariamente de OpenCL para todo su proceso de exportación, y ninguno de los dos usuarios ha aislado qué componente concreto falla en el editor de vídeo.
Lo que todavía no se sabe
Hay varias ausencias que conviene subrayar. Qualcomm no ha comentado públicamente los informes y no existe todavía un driver corregido, según ShiftDelete. Wccftech señala que el problema se ha trasladado al servidor de Discord de Qualcomm para desarrolladores, lo que puede acelerar un parche, pero no hay calendario.
Tampoco hay pruebas independientes con varios equipos y configuraciones. Todo lo publicado procede de dos usuarios, con dos portátiles distintos y un único conjunto de mediciones verificables. Algunos medios han difundido el porcentaje del 87 % como si describiera el rendimiento general del chip; no es así. Esa cifra corresponde al mejor caso de caída en un modelo diminuto, en una sola vía de ejecución y en una sola máquina. Fuera de OpenCL, los datos disponibles apuntan a que el procesador se comporta igual que antes.
Un tropiezo en el terreno que Qualcomm quiere ganar
El episodio llega en un momento delicado. Qualcomm presentó la familia Snapdragon X2 Elite en su Snapdragon Summit de septiembre de 2025 con la inteligencia artificial en el centro del discurso: CPU Oryon de tercera generación con hasta 18 núcleos, fabricación en 3 nm de TSMC y una NPU Hexagon de 80 TOPS, frente a los 45 TOPS de la primera generación. Los primeros portátiles llegaron en la primera mitad de 2026.
En ese discurso, la NPU acapara los titulares, pero en la práctica mucha gente que ejecuta modelos en local recurre a la GPU, porque herramientas como llama.cpp o las interfaces construidas sobre él tienen ahí un soporte más maduro y flexible que en la NPU, que exige modelos convertidos a formatos concretos. Para ese usuario, que la GPU pierda tres cuartas partes de su rendimiento con una actualización rutinaria es algo más que una anécdota, sobre todo cuando el hardware para ejecutar modelos en el PC ya se elige con lupa. Las GPU Adreno llevan desde el estreno de Windows sobre Arm arrastrando la percepción de necesitar más pulido de software que los núcleos de CPU, y un driver que empeora una carga de trabajo en lugar de mejorarla no ayuda a desmontarla.
Para empresas que estén evaluando portátiles con Arm como estaciones de desarrollo o para ejecutar asistentes de código en local, en pleno debate sobre si compensa más pagar tokens en la nube o invertir en hardware propio, la lección es menos sobre Qualcomm y más sobre gestión de flotas: los drivers gráficos también son una pieza que conviene probar en un grupo reducido de equipos antes de desplegarla, igual que una actualización del sistema operativo.
Cómo volver al driver anterior
Quien ya haya instalado la 32.0.181.0 y note la caída puede revertirla desde Windows, sin herramientas de terceros:
- Abrir el Administrador de dispositivos (clic derecho en el botón de Inicio).
- Desplegar Adaptadores de pantalla y abrir las propiedades de la GPU Qualcomm Adreno.
- En la pestaña Controlador, pulsar Revertir al controlador anterior. Si la opción aparece en gris, se puede instalar manualmente la 32.0.172.2 o el driver del fabricante del portátil desde su página de soporte.
- Comprobar la versión activa en esa misma pestaña tras reiniciar.
Mientras tanto, quien use llama.cpp tiene una alternativa sin tocar drivers: según las mediciones publicadas, WebGPU, la CPU y la NPU no se han visto afectadas, aunque su rendimiento varía según el modelo y la herramienta. Como ocurre con los controladores de NVIDIA o AMD, no es obligatorio instalar cada versión en cuanto aparece: si el equipo funciona bien y la novedad no aporta nada al uso concreto, esperar unos días a que la comunidad la pruebe es una precaución razonable.
Preguntas frecuentes
¿Qué versión del driver Adreno está causando el problema?
Los dos usuarios señalan la 32.0.181.0, publicada por Qualcomm a finales de octubre de 2026 para Snapdragon X y X2. La versión anterior en los equipos X2, la 32.0.172.2, no presenta la caída según las pruebas publicadas.
¿Afecta a todo el rendimiento del Snapdragon X2 Elite?
No, según los datos disponibles. La caída se limita a cargas de cómputo en GPU mediante OpenCL, como llama.cpp. La CPU, la NPU y la GPU a través de WebGPU mantienen sus cifras. En Premiere Pro hay un testimonio de exportaciones seis veces más lentas, pero sin pruebas documentadas.
¿Se ven afectados los portátiles con Snapdragon X de primera generación?
No hay informes de ello. El driver 32.0.181.0 también se distribuye para la primera generación, pero las denuncias publicadas se refieren solo a equipos Snapdragon X2 Elite.
¿Ha reconocido Qualcomm el fallo?
No. A fecha de publicación, Qualcomm no ha comentado los informes ni ha publicado un driver corregido. El problema se ha comunicado en su canal de Discord para desarrolladores.
Fuente: Wccftech, a partir de publicaciones de usuarios en Reddit (r/snapdragon)
