Qué pasó con los frameworks de deep learning

Cuando elegimos un framework para entrenar un modelo, normalmente nos fijamos en qué tan fácil es usarlo, si funciona con nuestras GPU y cuántos ejemplos hay disponibles. Es comprensible: queremos que el modelo corra. El problema aparece unos años después, cuando necesitamos actualizarlo y descubrimos que el equipo que mantenía la herramienta ya está trabajando en otra cosa.

La historia de Theano, Caffe, Caffe2, PyTorch, TensorFlow y MXNet tiene bastante de eso. En menos de veinte años hubo proyectos que salieron de universidades, otros que nacieron dentro de empresas y algunos que acabaron en fundaciones. Unos siguen publicando versiones; de otros quedan el código, la documentación y las aplicaciones que todavía dependen de ellos.

Me interesa esa parte de la historia porque mantener un framework es un compromiso mucho más largo que publicar un modelo. La gráfica de arriba reúne esas trayectorias desde 2007, con información revisada al 4 de octubre de 2026.

01 · Cómo leer la gráfica

Cada color corresponde a un framework y cada tramo lleva el nombre de su responsable principal o del estado en que quedó. Puedes seleccionar una barra para ver las fechas y el detalle de lo que ocurrió. Los cuadros punteados son los años anteriores a su publicación.

Hay dos filas que conviene leer con cuidado. Caffe y Caffe2 comparten una porque están relacionados, aunque fueron proyectos distintos. La de Theano incluye sus derivados, hasta llegar a PyTensor. En ambos casos, agruparlos permite seguir la historia del código y de las personas que lo mantuvieron.

Volver a la gráfica ↑

02 · El trabajo de mantenerlo

Theano comenzó en 2007; Caffe se publicó en 2013; TensorFlow y MXNet aparecieron en 2015. PyTorch llegó al público en enero de 2017 y Caffe2 en abril de ese año. En una década se habían acumulado varias formas de resolver un problema parecido: permitir que un investigador entrenara redes neuronales sin escribir por su cuenta todo el código para ejecutarlas.

Después del lanzamiento empieza un trabajo menos visible. Sale una GPU nueva y hay que hacerla funcionar. Cambia Python y algo deja de instalarse. Un usuario encuentra un error que solo ocurre con cierta combinación de bibliotecas. Hay que reproducirlo, corregirlo y explicar qué cambió. Todo eso requiere gente que conozca el proyecto y tenga tiempo para atenderlo.

Ahí me parece que se entiende mejor el peso que adquirieron las empresas. Tienen equipos que necesitan usar estas herramientas y razones para pagar por su mantenimiento. Para un laboratorio, sostener ese esfuerzo durante años puede competir con el trabajo de investigación que le permite conseguir el siguiente financiamiento. Eso ayuda a explicar algunas de estas trayectorias, aunque cada proyecto tuvo sus propias dificultades.

03 · Qué pasó con cada framework

Theano: la historia siguió en PyTensor

Theano salió del grupo de investigación de Montréal. Permitía escribir expresiones matemáticas como un grafo simbólico y convertirlas en código eficiente para CPU y GPU. Buena parte del trabajo consistía en describir el cálculo y dejar que Theano decidiera cómo ejecutarlo.

El 28 de septiembre de 2017, MILA anunció que dejaría el desarrollo principal después de la versión 1.0. Esa versión se publicó el 15 de noviembre. Hubo mantenimiento y versiones posteriores, pero el equipo estaba cerrando esa etapa.

Para quienes dependían de Theano, el anuncio dejaba una tarea pendiente. Los desarrolladores de PyMC tomaron una copia del proyecto en 2020 y la renombraron Aesara en 2021. Más adelante surgieron diferencias sobre la dirección técnica y la forma de tomar decisiones. El 28 de noviembre de 2022, PyMC anunció un nuevo fork: PyTensor.

Esa rama sigue trabajando en 2026. En mayo se anunciaron PyMC 6.0 y PyTensor 3.0, y el 2 de octubre apareció PyTensor 3.3.3. El repositorio original de Theano también remite a esa continuación. Su herencia encontró un lugar en la computación simbólica y probabilística que utiliza PyMC; el proyecto original quedó atrás.

Caffe y Caffe2: de Berkeley a la integración con PyTorch

Caffe nació en Berkeley, con Yangqing Jia y la comunidad de BVLC. Una de sus ventajas era muy práctica: la arquitectura del modelo se podía definir en archivos de configuración. Compartir esos archivos y los pesos facilitaba que otro investigador reprodujera una red.

Facebook presentó Caffe2 en abril de 2017, con una orientación que incluía el despliegue móvil y el entrenamiento distribuido. Al mismo tiempo, la versión 1.0 del Caffe original anunciaba el paso a modo de mantenimiento. Esa sigue siendo la última versión publicada en su repositorio.

Caffe2 tuvo una vida independiente bastante corta. El 2 de mayo de 2018 se anunció su integración con PyTorch para reunir las herramientas de investigación y producción en PyTorch 1.0.

Años después llegó una ruptura que importa si todavía tienes código viejo: el 15 de mayo de 2024 se incorporó la eliminación del código Python de Caffe2 del repositorio de PyTorch. La documentación histórica puede hablar de aquella integración, pero ya no puedes dar por hecho que un programa que importa caffe2.python funcionará con una instalación moderna. El cambio se refiere a esa API; parte de la herencia en C++ es otra historia.

PyTorch: una fundación y bastante más que grafos dinámicos

PyTorch se publicó en enero de 2017, desde Facebook AI Research. Su forma de trabajar resultaba familiar para quien ya programaba en Python: el grafo se construía mientras corría el programa y se podía depurar durante la ejecución. Esa facilidad para probar y corregir modelos fue parte de su atractivo.

Facebook, que adoptó el nombre corporativo Meta en 2021, siguió siendo su principal casa hasta el anuncio de la PyTorch Foundation, el 12 de septiembre de 2022. La fundación quedó bajo Linux Foundation, con varias empresas participantes. Meta permaneció entre ellas.

La herramienta también cambió. En marzo de 2023, PyTorch 2.0 incorporó torch.compile, que permite compilar modelos conservando la experiencia de desarrollo eager. Aquella discusión entre grafos estáticos y dinámicos explica una parte de sus orígenes, pero se queda corta para describir el PyTorch actual.

En 2026 el desarrollo continúa: la versión estable 2.14.0 se publicó el 2 de septiembre.

TensorFlow: sigue en desarrollo

Google publicó TensorFlow el 9 de noviembre de 2015, después de su experiencia con DistBelief. Desde el principio tuvo detrás a una empresa que lo necesitaba para su propio trabajo.

Su barra cambia poco en la gráfica porque Google sigue participando junto con la comunidad. Eso puede esconder cuánto cambió la herramienta. TensorFlow 2.0 adoptó la ejecución eager por defecto, con operaciones que se evalúan directamente, y Keras 3 amplió sus backends a TensorFlow, JAX y PyTorch. Ahora puedes trabajar con Keras sin quedar ligado exclusivamente a TensorFlow.

Al revisar las versiones disponibles al 4 de octubre de 2026, TensorFlow 2.21.0, publicada el 6 de marzo, sigue siendo la estable. También está 2.22.0-rc0, del 24 de septiembre, todavía como candidata. El proyecto sigue publicando cambios; hablar de él como si ya hubiera sido abandonado pierde de vista ese trabajo.

MXNet: el respaldo de AWS y Apache no alcanzó

MXNet apareció en 2015 como una colaboración de investigadores. Recibió el respaldo de AWS en 2016 y entró al Apache Incubator en enero de 2017. Sobre el papel, tenía una combinación prometedora: apoyo empresarial y una fundación con experiencia en proyectos de código abierto.

Pasó varios años en incubación. Se graduó como proyecto de primer nivel de Apache en septiembre de 2022 y, apenas un año después, fue retirado. La ficha de Apache Attic registra el retiro en septiembre de 2023 y la conclusión del traslado al archivo en febrero de 2024.

En 2026 todavía se pueden consultar su código y documentación, pero el proyecto está retirado. Es el caso que más me hace desconfiar de usar el nombre del patrocinador como garantía de futuro. Tener a AWS detrás y formar parte de Apache no aseguró que MXNet pudiera sostenerse.

04 · Qué puede hacer una fundación

Una fundación permite repartir decisiones y responsabilidades entre varios participantes. Para una empresa que depende de una biblioteca desarrollada por otra, esa estructura puede hacer más atractivo contribuir: tiene un espacio para participar en la dirección del proyecto.

Pero las personas que revisan cambios, responden preguntas y preparan versiones siguen necesitando tiempo para hacerlo. La estructura institucional ayuda a organizar ese trabajo; conseguir que alguien lo haga es un problema que permanece. PyTorch y MXNet terminaron en fundaciones y tuvieron resultados muy distintos.

También está el caso de PyMC. Sus desarrolladores necesitaban seguir usando el código que venía de Theano y asumieron el trabajo de continuarlo. La licencia abierta hizo posible el fork; mantenerlo exigió un equipo dispuesto a hacerse cargo.

05 · Elegir una herramienta que dure

Cuando una empresa elige un framework, compromete más que las horas necesarias para instalarlo. Su equipo aprende a usarlo, escribe modelos, prepara procesos de entrenamiento y construye aplicaciones alrededor. Cambiarlo después puede significar revisar años de trabajo.

Por eso, además de probar qué tan rápido entrena un modelo, vale la pena mirar quién responde los reportes de errores, cómo se publican las versiones y cuántas personas conocen las partes difíciles del código. También conviene entender cuánto depende ese esfuerzo de una sola empresa o de un solo laboratorio.

A mí me deja una pregunta bastante concreta: si mañana se retira el equipo que sostiene la herramienta, ¿quién podría hacerse cargo? PyMC encontró una respuesta para el código de Theano. MXNet terminó en un archivo. Esa diferencia puede importar mucho cuando la aplicación que depende de ellos es la tuya.

---

Sobre la gráfica y las fuentes

La gráfica cubre 2007–2026, con información revisada al 4 de octubre de 2026. Cada año muestra el estado alcanzado al cierre, salvo 2026, que llega hasta esa fecha de revisión. Los paneles incluyen las fechas de los cambios y el texto enlaza los anuncios y repositorios consultados.

Los logos pertenecen a sus respectivos titulares. Se tomaron de los sitios y repositorios de los proyectos para ilustrar la gráfica.