TensorFlow no detecta la GPU en Windows: causa real y ruta que funciona

Si llegaste aquí siguiendo una guía de 2023 o 2024 que promete GPU en TensorFlow sobre Windows con solo instalar el driver, CUDA Toolkit y cuDNN en las carpetas correctas, hay un dato que esa guía probablemente no menciona: desde hace varias versiones, ese camino ya no lleva a ningún sitio. No es que falte un paso; es que el paquete de Windows dejó de traer los kernels de GPU compilados.

Esto no es una limitación menor ni un bug puntual. Es una decisión de TensorFlow que cambia por completo qué instrucciones tienen sentido hoy en Windows, y por eso antes de tocar un solo instalador conviene entender qué es real y qué es ruido heredado de tutoriales caducados.

Qué funciona hoy y qué no: el cambio que dejó atrás a las guías antiguas

El patrón que describen quienes siguen una guía de 2023 o 2024 es siempre el mismo: nvidia-smi muestra la tarjeta correctamente, el driver está actualizado, nvcc --version responde, y aun así tf.config.list_physical_devices('GPU') devuelve una lista vacía. La reacción instintiva es sospechar de una versión de CUDA mal emparejada con cuDNN, o de una variable PATH mal configurada, y reinstalar todo desde cero con la esperanza de que la segunda vez funcione.

Ese diagnóstico casi nunca es el correcto. El problema no está en cómo se instaló CUDA: está en qué versión de TensorFlow se usa y en qué plataforma se ejecuta. TensorFlow 2.10 fue la última versión con soporte de GPU en Windows nativo. Desde la 2.11, el propio proyecto lo advierte sin rodeos en su guía de instalación: "TensorFlow 2.10 fue la última versión de TensorFlow que soportó GPU en Windows nativo. A partir de TensorFlow 2.11, necesitarás instalar TensorFlow en WSL2, o instalar tensorflow o tensorflow-cpu y, opcionalmente, probar el plugin TensorFlow-DirectML" (traducción del texto oficial). Esa misma advertencia se repite en la página de requisitos de GPU y en la tabla de compilación para Windows, que directamente deja de listar configuraciones de GPU a partir de la versión 2.10 (Python 3.7-3.10, cuDNN 8.1, CUDA 11.2).

Comprobé además el propio paquete publicado en PyPI: la wheel de tensorflow para Windows sigue existiendo en cada versión reciente (2.21.0 incluida, publicada el 6 de marzo de 2026) y se instala sin error, pero esa wheel de Windows se compila sin los kernels de GPU. Puedes incluso ejecutar pip install "tensorflow[and-cuda]" en Windows nativo y verás que instala sin quejarse las dependencias nvidia-cudnn-cu12 y nvidia-cuda-runtime-cu12 declaradas en el propio paquete; no sirve de nada, porque esas librerías no tienen ningún kernel de TensorFlow compilado contra ellas en la wheel de Windows. El extra and-cuda está pensado para Linux y WSL2, no para Windows nativo, y no hay ningún error visible que te avise: simplemente la GPU nunca aparece.

Cómo saber en qué escenario estás

Antes de instalar o desinstalar cualquier cosa, contesta estas tres preguntas en orden:

• ¿Qué versión de TensorFlow tienes? Ejecuta python -c "import tensorflow as tf; print(tf.__version__)". Si es 2.11 o superior y estás en Windows nativo, la GPU nunca se va a activar, sin importar qué controlador o CUDA instales.
• ¿Estás en Windows nativo o dentro de WSL2? Un uname -a dentro de una terminal que se abrió como "Ubuntu" o similar (no PowerShell ni CMD) indica WSL2. Si tu terminal es PowerShell o CMD, estás en Windows nativo.
• ¿Tu driver NVIDIA reconoce la GPU? nvidia-smi debe mostrar el modelo y la versión de driver. Esto es necesario en ambos escenarios, pero no basta por sí solo: un driver correcto con TensorFlow 2.11+ en Windows nativo sigue sin dar GPU.

Con esas tres respuestas ya sabes si tu caso es "necesito moverme a WSL2", "puedo quedarme en TensorFlow 2.10 con sus límites" o "mi proyecto no tiene GPU NVIDIA y esto no me aplica".

La ruta que funciona hoy: TensorFlow dentro de WSL2

La vía oficial y activamente mantenida para GPU en TensorFlow sobre una máquina Windows es ejecutar TensorFlow dentro de WSL2, no en Windows nativo. La documentación de instalación para WSL2 lo confirma: "TensorFlow con acceso a GPU es compatible con WSL2 en Windows 10 build 19044 o superior" (Windows 10 versión 21H2, noviembre de 2021, o cualquier Windows 11).

Un matiz que suele confundir: el manual de NVIDIA para CUDA en WSL es explícito en que no debes instalar ningún driver de GPU dentro de WSL2; el driver se instala solo en Windows y queda expuesto dentro de la distro Linux como libcuda.so. Instalar un driver Linux dentro de WSL2 rompe esa integración.

Los comandos que funcionan hoy, dentro de una terminal WSL2 (Ubuntu):

# 1. Verifica que WSL2 ve la GPU (usa el driver de Windows, no instales uno aquí)
nvidia-smi

# 2. Crea un entorno virtual limpio
python3 -m venv tf_gpu_env
source tf_gpu_env/bin/activate

# 3. Instala TensorFlow con las librerías CUDA/cuDNN como dependencias pip
#    (no hace falta instalar CUDA Toolkit ni cuDNN a mano para esto)
pip install --upgrade pip
pip install tensorflow[and-cuda]

# 4. Verifica que TensorFlow ve la GPU
python3 -c "import tensorflow as tf; print(tf.config.list_physical_devices('GPU'))"

Que la GPU aparezca en esa lista no prueba que el entrenamiento vaya a usarla: list_physical_devices solo confirma que TensorFlow detecta el dispositivo, no que lo esté usando para calcular nada. La comprobación real es forzar una operación con device placement explícito y comparar el tiempo de ejecución en CPU contra GPU:

# 5. Verificación real: ¿el cómputo ocurre en GPU o solo se detecta?
python3 -c "
import time
import tensorflow as tf

size = 4096
a = tf.random.normal((size, size))
b = tf.random.normal((size, size))

for device in ('/CPU:0', '/GPU:0'):
    with tf.device(device):
        start = time.perf_counter()
        c = tf.matmul(a, b)
        _ = c.numpy()  # fuerza la ejecución antes de medir
        elapsed = time.perf_counter() - start
    print(device, 'device real:', c.device, '-', round(elapsed, 3), 's')
"

Si la GPU está realmente en uso, la línea de /GPU:0 debe reportar un c.device que termina en /device:GPU:0 (no en CPU:0) y un tiempo notablemente menor que la misma multiplicación de matrices forzada a CPU. Si ambos tiempos son parecidos, o TensorFlow ignora el tf.device('/GPU:0') y ejecuta igual en CPU, la GPU sigue sin participar en el cómputo real, aunque apareciera en la lista del paso 4.

El extra [and-cuda] resuelve un problema real de las guías antiguas: ya no hace falta descargar cuDNN a mano, copiar carpetas bin/include/lib ni tocar el PATH. Esas librerías llegan como paquetes pip (nvidia-cudnn-cu12, nvidia-cublas-cu12, etc.) versionados junto con TensorFlow. Si además vas a compilar código CUDA propio (no solo usar TensorFlow), sí necesitas instalar el CUDA Toolkit completo dentro de WSL2 con el instalador específico "WSL-Ubuntu" que ofrece NVIDIA, para no pisar el driver que ya está mapeado desde Windows.

Un detalle operativo que las guías rara vez mencionan y que penaliza el entrenamiento sin lanzar ningún error: dentro de WSL2, el I/O sobre el disco de Windows montado en /mnt/c/... es notablemente más lento que sobre el filesystem nativo de Linux. La documentación oficial de Microsoft sobre sistemas de archivos en WSL lo recomienda sin rodeos: para la mejor velocidad, los archivos deben vivir en el filesystem de WSL cuando se trabaja desde una línea de comandos de Linux, y no en rutas como /mnt/c/Users/<usuario>/Project. Si tu dataset de entrenamiento vive en C:\Users\... y lo lees desde WSL2 tal cual, cada lectura de disco cruza ese puente lento; copiarlo primero a una ruta como /home/<usuario>/... dentro de la distro evita ese cuello de botella, sobre todo con datasets grandes o con muchos archivos pequeños (imágenes, por ejemplo).

Tabla de compatibilidad verificada (agosto de 2026)

La fila de Windows nativo la tomé de la tabla oficial de compilación para Windows; la fila de WSL2/Linux, de la tabla de compilación probada y confirmé las versiones exactas de CUDA/cuDNN mirando las dependencias declaradas por el propio paquete tensorflow==2.21.0 en PyPI (nvidia-cudnn-cu12>=9.3.0.75, nvidia-cuda-runtime-cu12>=12.5.82). Esta tabla cambia con cada versión mayor de TensorFlow: si lees esto meses después, revisa la tabla de compilación antes de fijar versiones en un requirements.txt.

Límites de quedarte en Windows nativo con TensorFlow 2.10

Hay casos legítimos para no migrar a WSL2: políticas corporativas que prohíben virtualización anidada, máquinas sin acceso a activar WSL2, o dependencias de herramientas Windows-only que no tienen equivalente sencillo en Linux. Si ese es tu caso, puedes seguir instalando tensorflow<2.11 con conda install -c conda-forge cudatoolkit=11.2 cudnn=8.1.0, exactamente como indicaba la guía original, y funcionará.

Pero hazlo sabiendo lo que implica: TensorFlow 2.10 no recibe parches de seguridad ni corrección de bugs desde 2022, tope en Python 3.10, no tiene ninguna de las mejoras de rendimiento ni de API de las versiones posteriores (Keras 3, mejoras de tf.function, soporte de arquitecturas de GPU más recientes) y las bibliotecas del ecosistema (Keras, TF-Agents, TF-Text) que dependen de versiones más nuevas de TensorFlow dejarán de instalarse limpiamente con el tiempo. No es una solución de largo plazo, es un punto de apoyo temporal mientras se resuelve la razón por la que no puedes usar WSL2.

Alternativas: DirectML y contenedores con Docker Desktop

Antes de descartar Windows nativo del todo, existen dos rutas adicionales, con matices importantes:

• TensorFlow-DirectML-Plugin: permite usar GPUs AMD, Intel o NVIDIA en Windows nativo a través de DirectML en lugar de CUDA. El propio repositorio lo desaconseja para casos nuevos hoy: "El desarrollo de TensorFlow-DirectML-Plugin está pausado hasta nuevo aviso. Para aprovechar las últimas funciones y mejoras de rendimiento de DirectML en escenarios de inferencia, recomendamos ONNX Runtime" (traducción del aviso oficial). Sobre qué versión exige, conviene ser precisos porque las propias fuentes de Microsoft no coinciden entre sí: el README del repositorio en GitHub dice hoy que el plugin "solo funciona con el paquete tensorflow-cpu>=2.12", pero dos frases después, en el mismo párrafo, añade que si tensorflow-cpu no está instalado se instalará automáticamente la versión 2.10.0. La metadata publicada en PyPI resuelve esa contradicción: la única versión que existe del paquete, 0.4.0.dev230202, subida el 3 de febrero de 2023 y sin ninguna release posterior, declara como dependencia exacta tensorflow-cpu==2.10.0, no >=2.12. Lo que pip install tensorflow-directml-plugin instala realmente hoy sigue exigiendo esa versión exacta, tal como confirma también la guía oficial de instalación de Microsoft. El >=2.12 del README no corresponde a ningún release publicado. Y el dato de fondo pesa más que el número exacto: sin actualizaciones desde 2023 y con el desarrollo pausado, esta ruta no va a recibir una versión nueva que cambie ese requisito. Su documentación ya advertía, además, que no estaba pensado para producción. Es una opción para prototipos puntuales de inferencia, no para entrenamiento serio ni para un pipeline que dependa de mantenimiento activo.
• Docker Desktop con backend WSL2: si lo que buscas es reproducibilidad de entorno más que evitar WSL2 del todo, Docker Desktop en Windows expone la GPU a los contenedores a través del mismo backend WSL2. La documentación de Docker es clara en que "el soporte de GPU en Docker Desktop solo está disponible en Windows con el backend WSL2" y requiere drivers NVIDIA actualizados con soporte de GPU-PV. En la práctica esto es la misma dependencia de WSL2 vista desde otro ángulo, útil si ya trabajas con contenedores para aislar versiones de CUDA entre proyectos distintos.

Matriz de decisión según tu escenario

Reducido a una decisión práctica:

• Proyecto nuevo, sin restricciones de virtualización: WSL2 + pip install tensorflow[and-cuda]. Es la única ruta con soporte activo y versiones actualizadas.
• Ya tienes contenedores en tu flujo de trabajo: Docker Desktop con backend WSL2, para no gestionar entornos Python distintos por proyecto.
• Windows nativo obligatorio y solo necesitas inferencia ligera, no entrenamiento: prueba TensorFlow-DirectML-Plugin sabiendo que su desarrollo está pausado y que Microsoft empuja hacia ONNX Runtime para esos mismos casos.
• Windows nativo obligatorio y necesitas entrenar con GPU sí o sí: TensorFlow 2.10 con CUDA 11.2 y cuDNN 8.1 es la única combinación que realmente activa la GPU, con el coste de quedarte congelado en una versión sin mantenimiento.

El error que sigue reproduciendo la mayoría de tutoriales antiguos no es una versión de CUDA mal citada: es asumir que "TensorFlow con GPU en Windows" sigue significando lo mismo que en 2021. Hoy significa, casi siempre, TensorFlow dentro de Linux, aunque ese Linux viva sobre un Windows.