Durante años, un desarrollador de Python que necesitaba una GPU tenía dos opciones realistas, ninguna cómoda. La primera: aprender CUDA C++ lo suficiente como para escribir una extensión, montar una cadena de compilación y mantener los enlaces de vuelta hacia Python, algo que casi nadie hizo. La segunda: subir un nivel en la pila y dejar que la biblioteca de otro se encargara, es decir PyTorch, CuPy o RAPIDS.
La segunda opción explica por qué el ecosistema de GPU en Python prosperó. Pero tiene un límite claro: en cuanto necesitás algo que la biblioteca de arriba no expone, volvés a la primera opción.
Con CUDA 13.3, NVIDIA liberó CUDA Python 1.0, el conjunto de bibliotecas y herramientas que entrega la plataforma CUDA completa desde Python. Según la compañía, Python pasa a ser una forma soportada de usar la plataforma.
¿Qué componentes incluye el lanzamiento?
cuda.core1.0.0, acceso pythónico al runtime de CUDAcuda.compute1.0.0, los algoritmos paralelos de CCCL invocables desde Pythoncuda.bindings13.3.0, enlaces de bajo nivel uno a uno con las APIs de CUDA en C, versionados junto al CUDA Toolkitcuda-pathfinder, que localiza los componentes de CUDA instalados en el entornonvmath-python1.0, las bibliotecas matemáticas de NVIDIA en Python, con su propio calendario de versiones
Un detalle que conviene subrayar: CUDA Python 1.0 nombra un hito, no un número de versión que se escriba en pip. Los componentes se versionan de forma independiente, así que los números disparejos de la lista son deliberados.
¿Qué cambia realmente con la versión 1.0?
No es una reescritura ni un producto nuevo. La mayoría de estas bibliotecas existían y venían mejorando hace tiempo. Lo que cambia es un compromiso: versionado semántico.
En la práctica significa que los cambios que rompen la API solo ocurren en versiones mayores, las versiones menores agregan funciones, los parches corrigen errores, y toda API pública destinada a desaparecer se marca antes como obsoleta en una versión menor, con un camino de reemplazo explícito.
Para quien dudaba en construir sobre alguna de estas bibliotecas por no saber si la API sobreviviría a la próxima actualización, esa garantía es el titular real del anuncio.
Una base en vez de muchas
Antes, llegar a CUDA desde Python significaba elegir una capa de enlace, y había varias. Cada una la mantenía un proyecto distinto, cada una cubría una porción diferente de la API, y cada una tenía su propia idea de qué era un stream, un dispositivo o una asignación de memoria. Si escribías aplicaciones, heredabas la capa que usaran tus dependencias; si escribías bibliotecas, adoptabas la de otro o construías la tuya, y el ecosistema acumulaba una más.
Eso es lo que cambió. Ahora hay una sola vía oficial mantenida por NVIDIA para alcanzar CUDA desde Python.
El beneficio concreto es que las bibliotecas se componen en lugar de apenas coexistir. Un kernel de Numba y una llamada a cuda.compute pueden operar sobre el mismo búfer de GPU en el mismo stream, porque ninguno de los dos trae consigo una capa CUDA privada. Los objetos cruzan las fronteras entre bibliotecas porque, por debajo, son los mismos objetos.
También cambia quién accede a las funciones avanzadas de la plataforma. Los green contexts, que particionan los multiprocesadores de streaming de una GPU para que los kernels sensibles a latencia queden aislados de los kernels de alto rendimiento, antes habrían requerido que cada biblioteca interesada los enlazara y expusiera por su cuenta. Ahora aterrizan una sola vez en cuda.core, y todo lo construido encima puede alcanzarlos.
Tres niveles sobre una misma base
El diagrama se lee de abajo hacia arriba. En el piso está el sistema de runtime: gestión de dispositivos, asignación de memoria, streams y sincronización, grafos de CUDA y compilación JIT.
Encima van las bibliotecas CUDA, interfaces pythónicas a las bibliotecas afinadas de NVIDIA. Ahí están cuda.compute con los algoritmos paralelos de CCCL, nvmath-python con las bibliotecas matemáticas, y NCCL4Py y NVSHMEM4P con las bibliotecas de comunicación NCCL y NVSHMEM. Ninguna reimplementa la capa CUDA de abajo: trabajan sobre los mismos búferes, dispositivos y streams de cuda.core.
Arriba de todo está la escritura de kernels, para cuando querés programar el código de GPU vos mismo. numba-cuda es el lenguaje SIMT para kernels en Python, y junto a él aparecen dos lenguajes específicos más nuevos: cutile-python, un lenguaje de tiles para el modelo de bloques, y cuteDSL, un lenguaje CUTLASS para Tensor Cores.
Dos advertencias importantes. Primero, se entra por el nivel que el problema requiera: nadie tiene que aprender la pila completa, y hay usuarios productivos que nunca salen del nivel de bibliotecas. Segundo, los niveles no son un producto único versionado: algunas piezas nuevas, incluidos varios de los lenguajes de kernels, siguen siendo experimentales y todavía no están cubiertas por la garantía de versionado semántico del 1.0. Conviene saberlo antes de fijar una dependencia de producción sobre una de ellas.
¿Por dónde empezar según el problema?
| Necesidad | Componente | Cuándo usarlo |
|---|---|---|
| Algoritmos ya optimizados | cuda.compute | El problema se descompone en patrones paralelos conocidos (ordenar, reducir, escanear, histograma, top-k) |
| Escribir tu propio kernel | numba-cuda | La lógica no calza con un algoritmo preempaquetado y querés control por hilo |
| Acceso al driver y al runtime | cuda.core, cuda.bindings | Necesitás dispositivos, streams, grafos y compilación en tiempo de ejecución |
cuda.compute trae los algoritmos paralelos de las CUDA Core Compute Libraries como bloques invocables desde el host: ordenamiento, escaneo, reducción, transformación, unique, histograma y top-k, entre otros. Son los mismos algoritmos que respaldan el código CUDA de alto rendimiento en C++, y desde Python son llamadas de función corrientes sobre arreglos de GPU que ya tenés. La versión 1.0 además permite personalizar qué hace un algoritmo con funciones Python ordinarias, incluidas lambdas.
cuda.core es la pieza central del lanzamiento. Expone dispositivos, streams, programas, enlazadores, recursos de memoria y grafos, además de compilación en tiempo de ejecución de CUDA C++, de modo que un kernel puede pasar de código fuente a ejecución sin un paso de compilación aparte. El énfasis está en lo pythónico: los recursos son objetos reales y los fallos lanzan excepciones en vez de devolver códigos de error. Como usa un contexto CUDA estándar, comparte dispositivos, streams y memoria con el resto del ecosistema, así que tus kernels propios pueden correr sobre arreglos de CuPy o tensores de PyTorch sin copiar datos.
Qué implica para los equipos de la región
Para los laboratorios universitarios y las empresas de LatAm que trabajan con GPU, el cambio ataca un costo silencioso: el tiempo que se pierde depurando cuál runtime de CUDA cargó realmente un proceso. cuda-pathfinder suena a herramienta menor hasta que uno recuerda cuántas horas consumió esa pregunta. Y para quienes desarrollan sobre plataformas embebidas de la familia Jetson, la promesa de paridad de funciones entre Python y C++ reduce la necesidad de mantener extensiones en C++ solo para llegar a una capacidad que el stack de Python no exponía.
