La llegada de Python 3.13 en octubre de 2024 trajo consigo un cambio que la comunidad llevaba más de una década discutiendo: la posibilidad de ejecutar el intérprete sin el Global Interpreter Lock, conocido como GIL. Ha pasado casi un año desde el lanzamiento y ya tenemos suficientes informes de uso real para separar la promesa del matiz. El resultado es interesante y, como suele pasar, más complicado de lo que los titulares sugirieron.
Qué es exactamente free-threading en 3.13
El PEP 703, aceptado por el comité directivo de Python en 2023, propuso hacer el GIL opcional en tiempo de compilación. Python 3.13 incluye esta capacidad como construcción experimental, indicada con el sufijo t en el binario: python3.13t frente a python3.13. El binario estándar sigue teniendo GIL, porque su eliminación introduce cambios profundos en la gestión de memoria del intérprete que no pueden activarse y desactivarse dinámicamente sin coste.
La diferencia de fondo es que el binario con GIL serializa todo el bytecode Python a un solo hilo dentro del proceso. Esto simplifica la implementación del intérprete y garantiza que las estructuras de datos internas no corrompan. La contrapartida, conocida desde hace años, es que un proceso Python no puede aprovechar varios núcleos para código puro; necesita multiprocessing, que tiene sus propios costes de memoria y serialización, o librerías que liberan el GIL en código nativo como NumPy.
En el binario sin GIL de 3.13, varios hilos Python ejecutan bytecode en paralelo de verdad. Para cargas de trabajo donde muchos hilos hacen trabajo independiente en Python puro, la ganancia puede ser lineal con el número de núcleos. Para cargas donde los hilos pasan la mayor parte del tiempo en código C ya paralelo, la ganancia es nula o muy pequeña porque esas librerías ya liberaban el GIL.
Qué gana de verdad y qué no
En pruebas publicadas por Meta, Cloudflare y varios equipos que han compartido sus resultados, las cargas que más ganan son las de tipo orquestador: muchos hilos haciendo llamadas HTTP en paralelo, parseando JSON, transformando estructuras de datos medianas. En esos casos, free-threading puede dar entre dos y seis veces más rendimiento con cuatro u ocho núcleos. La diferencia es real y medible.
Las cargas puramente de cálculo intensivo en Python puro, sin salir del intérprete, también se benefician, pero estas cargas ya solían estar en NumPy, SciPy o en un binding a C. Si tu bucle caliente ya estaba en código nativo, quitar el GIL no añade casi nada. Las cargas web con entorno tradicional como Django o Flask sobre WSGI tampoco cambian mucho porque los procesos trabajadores ya eran procesos, no hilos.
Hay un grupo que sí se beneficia claramente pero con trabajo: aplicaciones que hoy usan multiprocessing para rodear el GIL pueden volver a hilos, ahorrando la serialización y la memoria duplicada. El ahorro puede ser significativo en cargas con estructuras de datos grandes que se comparten entre trabajadores. Volver de procesos a hilos requiere rediseñar cómo se comparte el estado, que es más fácil con hilos pero no trivial.
El coste oculto: velocidad en un solo hilo
El truco de free-threading no es gratis. La implementación requiere recuento de referencias atómico, candados adicionales en estructuras internas del intérprete y cambios en el recolector de basura. El coste aproximado es una reducción del rendimiento de un solo hilo entre el cinco y el quince por ciento comparado con el mismo Python 3.13 con GIL.
Para cargas que no paralelizan y que corren hilo único, esto es un precio que se paga sin ganancia. De ahí que Python 3.13 haga free-threading opcional y no por defecto. Si tu aplicación es web con un solo proceso por petición, si es un script CLI, si es cualquier cosa donde no tienes varios hilos haciendo trabajo real en Python puro, el binario con GIL sigue siendo el correcto.
Esta decisión de diseño es razonable. No obliga a nadie a pagar el coste si no lo va a rentabilizar. Pero tiene una implicación operativa: los paquetes binarios publicados en PyPI tienen que ofrecer ruedas para ambos ABI, cpython313 y cpython313t, lo que duplica el trabajo de mantenimiento. A mediados de 2025 la cobertura del ecosistema todavía es parcial: las librerías más usadas ya ofrecen ruedas para ambos, pero muchas dependencias de nicho no.
Compatibilidad del ecosistema
Además del trabajo de empaquetado, hay un problema más sutil: mucho código C que interactúa con Python asumía la serialización implícita del GIL. Una extensión C que guardaba estado en variables globales, o que modificaba estructuras Python sin tomar candados explícitos, funcionaba por accidente gracias al GIL. En free-threading ese código se corrompe silenciosamente. La lista de extensiones que han tenido que arreglar bugs ocultos es larga e incluye nombres conocidos.
La PSF ha hecho un buen trabajo documentando qué hay que cambiar, pero el proceso lleva tiempo. En la práctica, el consejo conservador es esperar a que las dependencias críticas de tu aplicación declaren explícitamente compatibilidad con free-threading antes de desplegar en producción. Esperar a Python 3.14, previsto para octubre de 2025, donde está anunciada la promoción de free-threading de experimental a soportado, es una opción prudente.
Cómo probarlo en un entorno real
La forma más segura de empezar a evaluar free-threading es usar los contenedores oficiales de Python 3.13 con la etiqueta freethreading, levantar la aplicación bajo ese intérprete y ejecutar las pruebas habituales. Los problemas suelen aparecer en integración con librerías nativas concretas. En aplicaciones puramente Python puro con pocas dependencias, suele funcionar sin fricción.
Para medir si hay beneficio real, es conveniente comparar con el mismo código en 3.13 con GIL activado. La variable de entorno PYTHON_GIL permite cambiar el comportamiento en tiempo de arranque. Esto da una medida limpia del impacto de la concurrencia sin cambiar versión. Medir con una carga representativa, no con un microbenchmark aislado, es la diferencia entre tomar una decisión útil y una equivocada.
Cuándo compensa migrar
Mi lectura después de ver varias pruebas de concepto es que free-threading vale la pena ahora si tu aplicación cumple tres condiciones: tienes cargas que hoy sufren contención por GIL, tus dependencias están al día, y tienes tiempo para observar en producción con capacidad de rollback. Si falta alguno de los tres, esperar a 3.14 o incluso a 3.15 es perfectamente razonable.
Hay un escenario donde la decisión es más clara: aplicaciones nuevas que van a arrancar en 2026 con horizonte largo. En esas, tiene sentido diseñar asumiendo que free-threading va a ser mayoritario dentro de un par de años, elegir librerías compatibles y usar patrones de concurrencia con hilos en vez de multiprocessing. El coste de adelantarse es pequeño y el beneficio a medio plazo es real.
Para aplicaciones existentes y estables, el cálculo es distinto. No hay que migrar por moda. La mejora de rendimiento puede ser real o puede ser nula dependiendo del perfil de carga. Medir antes de decidir, mantener un plan de vuelta atrás, y aceptar que el ecosistema todavía está madurando son las actitudes que evitan sorpresas.
