`pip install torch` en una sola línea — ¿por fin se resolverá una deuda histórica del empaquetado en Python?
(talkpython.fm)La alianza de NVIDIA, Astral y Quansight presenta Wheel Next: el estándar de empaquetado de próxima generación que no distingue entre CPU y GPU
Fuente: Talk Python To Me, Episode #544 |
Contexto: una rueda que se quedó detenida en 2009
Cuando ejecutas pip install numpy, ¿qué binario se instala? No importa si tu CPU es un AMD Zen 4 moderno o un Apple M4. El wheel que se instala está compilado para usar solo instrucciones x86-64 del nivel de 2009.
Aunque quieras usar instrucciones SIMD modernas como SSE4 o AVX2, el instalador no tiene forma de saber si esas funciones están soportadas. El resultado, en paquetes como PyTorch, son archivos binarios enormes que rozan los 900 MB y páginas de guía de instalación tan complejas como un “libro de acertijos”.
Para resolver este problema, la alianza de NVIDIA, Astral y Quansight está impulsando la iniciativa Wheel Next. Su núcleo es una serie de PEPs que permiten que el paquete declare el hardware que necesita y que instaladores como uv puedan elegir automáticamente la compilación correcta.
Presentación de los invitados
En este episodio participaron tres figuras clave.
Jonathan Dekhtiar (NVIDIA) — Ingeniero que quedó fascinado por CUDA, completó incluso un PhD y luego se unió a NVIDIA. Durante los últimos dos años ha trabajado en mejorar la intersección entre CUDA y Python, y es uno de los principales impulsores de la iniciativa Wheel Next.
Ralf Gommers (Quansight) — Desarrollador con doctorado en física que usa Python desde 2004. Es release manager de NumPy y SciPy, y actualmente co-CEO de Quansight, una corporación de beneficio público. También es autor de la guía PyPackaging Native, que organiza de forma sistemática los problemas del empaquetado nativo en Python.
Charlie Marsh (Astral) — Fundador y CEO de Astral, creadora de uv, ruff y ty. Desde la fundación de la empresa en octubre de 2022, se ha enfocado en mejorar la velocidad y la experiencia de usuario del ecosistema Python.
El problema central: la “trampa del mínimo común denominador”
Cuando se compila un wheel para x86-64, solo se pueden usar funciones de CPU previas a 2009. Instrucciones que aparecieron después, como SSE4 o AVX2, simplemente no pueden utilizarse porque el instalador no tiene forma de saber si están presentes.
La diferencia de rendimiento entre las capacidades de hardware de 2009 y las de 2019~2023 puede llegar, según el caso, a 10~20 veces.
La situación en ARM es similar. El target base actual para compilaciones de ARM es, en la práctica, del nivel de una Raspberry Pi. Eso significa que incluso en una MacBook Pro con chip M4 Max se ejecuta un binario compilado como si fuera para una Raspberry Pi.
Según la encuesta de desarrolladores de Python de JetBrains, alrededor de 40~50 % de los desarrolladores de Python trabajan en ciencia de datos o computación científica. Es una comunidad enorme que está desperdiciando sistemáticamente una cantidad inmensa de rendimiento.
Cómo ha sobrevivido NumPy
NumPy resolvió este problema por su cuenta. Compila varias veces el mismo código fuente apuntando a múltiples arquitecturas de CPU, como Haswell o Skylake, y luego las combina en un único módulo de extensión de Python. En tiempo de ejecución detecta la CPU y despacha la mejor ruta de código.
Intel asignó ingenieros durante años para optimizar las rutas de código x86, y ARM también cuenta con un maintainer de NumPy dedicado. Gracias a eso, el rendimiento es excelente, pero este enfoque está en una escala que solo unos pocos proyectos grandes pueden sostener.
SciPy, scikit-learn, Pandas y Pillow ya tienen optimizaciones SIMD implementadas en su código, pero no tienen una forma de empaquetarlas y distribuirlas dentro de wheels, así que en la práctica no pueden distribuirlas.
El caso de PyTorch: un “libro de acertijos” de 900 MB
Los wheels de PyTorch publicados en PyPI pesan alrededor de 900 MB. Esto se debe a que las bibliotecas CUDA para 5 o 6 arquitecturas de GPU están agrupadas en un solo binario. El equipo de PyTorch está haciendo enormes esfuerzos para no superar 1 GB.
Quienes necesitan una versión específica de CUDA deben configurar manualmente una URL de índice separada, y páginas de instalación de paquetes como vLLM son tan complejas como un “libro de acertijos”.
¿Qué pasaría si Wheel Next se concreta?
uv pip install torch
Con esa sola línea bastaría. El instalador detectaría automáticamente la GPU, identificaría la versión correcta de CUDA y descargaría un wheel liviano de unos 200~250 MB optimizado para ese hardware. Astral ya construyó un prototipo funcional en una rama de uv con soporte para variantes (variant-enabled).
La filosofía de diseño de Wheel Next: un sistema extensible, no una lista fija
El enfoque actual codifica los platform tags de forma rígida en el nombre del archivo. Cada vez que aparece un nuevo requisito, hay que añadir otra etiqueta, y repetir eso termina convirtiéndose en una carga de mantenimiento interminable.
Wheel Next es diferente. Los paquetes pueden declarar metadatos de variantes arbitrarias (variant), y mediante una interfaz de plugins el instalador puede detectar dinámicamente las propiedades de la plataforma para elegir el wheel óptimo. En vez de poner etiquetas a cada versión de CUDA, la idea es crear un sistema general y extensible.
El diseño se inspira en archspec del gestor de paquetes para supercomputadoras Spack, así como en Conda-forge y Nix.
Estado de los PEP
Principales PEP relacionados con esta iniciativa:
| PEP | Título | Estado |
|---|---|---|
| PEP 817 | Wheel Variants Beyond Platform Tags | Draft |
| PEP 825 | Wheel Variants Package Format | Draft |
PEP 817 batió el récord como el PEP más largo de la historia. Solo la revisión por parte de los editores de PEP tomó más de un mes. Después se dividió en unidades más manejables, y ahora las discusiones sobre instaladores, backends de build e index servers avanzan por separado.
Python Build Standalone: una palanca silenciosa
Charlie Marsh mencionó un dato interesante. Astral mantiene el proyecto Python Build Standalone. Cuando instalas Python con uv, lo que realmente se descarga es una compilación de este proyecto.
El objetivo de Astral es lanzar la distribución de Python más rápida posible únicamente mediante optimizaciones de compilación, sin modificar el código fuente de CPython. Charlie dijo que cree tener hoy la versión de Python más rápida, aunque no lo afirmará oficialmente porque todavía no ha publicado una metodología de benchmark rigurosa.
Dado que muchísimos desarrolladores ya usan uv para bootstrapping de Python, la elección de builds de Astral puede convertirse en una palanca con enorme impacto sobre el rendimiento de Python.
Una colaboración industrial sin precedentes
En marzo de 2025 se celebró una cumbre presencial en la que se reunieron representantes de unas 20 empresas. El equipo de PyTorch de Meta y el equipo de JAX de Google presentaron cada uno sus propios desafíos.
Actualmente, las empresas y proyectos open source que contribuyen a la iniciativa Wheel Next son los siguientes:
Empresas: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks y más de 14 en total
Proyectos open source: NumPy, SciPy, PyTorch, scikit-learn, JAX, entre otros
Durante el proceso de prototipado, se trabajó haciendo forks de casi todos los componentes del ecosistema de empaquetado de Python, incluyendo pip, warehouse (PyPI), setuptools, scikit-build-core y la librería packaging. Por supuesto, el objetivo final es volver a unir todo eso.
Próximos pasos
Según la estimación de Ralf, durante todo 2026 continuarán la revisión de los PEP y las actualizaciones de los prototipos, y después vendrán las actualizaciones de PyPI, Twine y las herramientas que consumen metadatos. Parece que la preparación integral del ecosistema ocurrirá después de 2026.
Pero Jonathan es optimista. Cree que, en cuanto el estándar esté disponible, la adopción en el ecosistema de ML y computación científica será rápida, porque los paquetes clave ya participan en el grupo de trabajo de Wheel Next.
Glosario de términos clave
| Término | Descripción |
|---|---|
| Wheel | Formato estándar de distribución binaria de paquetes de Python (.whl) |
| Wheel Variants | Extensión propuesta en PEP 817/825. Distingue varias compilaciones del mismo paquete según las propiedades del hardware |
| SIMD | Instrucciones de CPU que procesan varios datos al mismo tiempo con una sola instrucción (SSE4, AVX2, ARM Neon, etc.) |
| Fat Binary | Binario que agrupa código compilado para varios targets de hardware. Actualmente lo usan NumPy y PyTorch |
| Platform Tags | Información de SO, arquitectura y versión de Python codificada en el nombre del archivo wheel |
| Python Build Standalone | Proyecto de compilaciones redistribuibles de CPython mantenido por Astral |
| Variant Provider Plugin | Interfaz que permite al instalador detectar dinámicamente propiedades del hardware (como la versión del driver de GPU) para elegir la variante correcta del wheel |
Cierre
“Idealmente, el usuario común no debería tener que preocuparse por nada de esto. Simplemente debería obtenerlo automáticamente a través de uv o pip.” — Charlie Marsh
El sistema de empaquetado de Python fue diseñado en una época más simple. Pero ahora que las cargas de trabajo de ciencia de datos e IA se han disparado, ese diseño se ha convertido en un cuello de botella en rendimiento, ancho de banda y experiencia de usuario.
Wheel Next es un caso poco común en el que competidores como NVIDIA, AMD, Intel, Google y Meta se sientan en la misma mesa para redactar PEPs juntos e invertir en infraestructura compartida. El prototipo de uv ya demostró su viabilidad técnica. Tomará tiempo para que el resto del ecosistema se ponga al día, pero ese futuro bien vale la espera.
Enlaces relacionados
- wheelnext.dev — Sitio oficial del proyecto Wheel Next
- PEP 817 — Wheel Variants Beyond Platform Tags
- PEP 825 — Wheel Variants Package Format
- pypackaging-native.github.io — Guía sobre los problemas del empaquetado nativo en Python
- astral.sh/pyx — Registro de paquetes pyx de Astral
Este artículo es una traducción y edición del contenido de Talk Python To Me Episode #544.
2 comentarios
Por suerte, en Wheel Next participa una empresa nacional llamada Lablup.
https://wheelnext.dev/who_are_we/
Todas las demás empresas de IA no están patrocinando, apoyando ni participando.
¡¡RabbleUp es genial!!