Esta es la parte 5 de Awesome Curated: The Tools, donde hago deep dives en las herramientas que pasan el filtro de nuestro sistema de curación automático. Si llegaste directo acá, te recomiendo arrancar desde el post #1 sobre Docker for Novices para entender cómo funciona el proceso. En el post anterior estuvimos con TensorFlow. Hoy toca su eterno rival — y, spoiler, el que terminó ganando la batalla por los corazones de los investigadores.

Hace un par de años estaba intentando reproducir un paper de NLP. Cosa de todos los días en el mundo académico: el autor publica el código, vos lo bajás, rezás, y tratás de que corra. El paper era de 2019. El código, en TensorFlow 1.x. El quilombo que me armé con las versiones, los grafos estáticos, el tf.Session(), los placeholder... perdí medio día. Después encontré una reimplementación no oficial en PyTorch. Funcionó en quince minutos. Esa diferencia — la de sentir que el framework trabaja con vos y no contra vos — es exactamente lo que voy a intentar explicar en este post.

PyTorch no necesita presentación en 2025, pero merece una explicación honesta. Porque hay una diferencia entre saber que algo existe y entender por qué ganó.

Qué hace

PyTorch es una librería open source de machine learning desarrollada principalmente por Meta AI (antes Facebook AI Research). Está basada en Torch, una librería de cómputo científico que venía del mundo Lua, y desde 2016 vive en Python como ciudadano de primera clase.

El diferencial técnico que lo define es su enfoque define-by-run (también llamado grafo dinámico o eager execution). A diferencia del TensorFlow original que construía un grafo de computación estático y después lo ejecutaba, PyTorch construye el grafo mientras ejecuta. Esto puede sonar como un detalle de implementación, pero en la práctica cambia todo: podés usar un debugger normal, podés poner un print() en el medio de tu red neuronal y ver qué está pasando, podés tener lógica condicional real con if y for de Python.

import torch
import torch.nn as nn

# Definición de una red neuronal simple — todo es Python puro, sin magia
class RedSimple(nn.Module):
    def __init__(self):
        super().__init__()
        # Una capa oculta de 128 neuronas, una de salida con 10 clases
        self.capas = nn.Sequential(
            nn.Linear(784, 128),  # entrada: imagen 28x28 aplanada
            nn.ReLU(),            # función de activación
            nn.Linear(128, 10)    # salida: 10 clases (ej: dígitos MNIST)
        )

    def forward(self, x):
        return self.capas(x)

# Instanciamos la red y la mandamos a GPU si está disponible
dispositivo = torch.device("cuda" if torch.cuda.is_available() else "cpu")
red = RedSimple().to(dispositivo)

# El autograd calcula los gradientes automáticamente — backprop gratis
print(red)

El soporte nativo de GPU vía CUDA es transparente: movés un tensor con .to(device) y listo. El sistema de autograd calcula los gradientes automáticamente para cualquier operación que hagas sobre tensores, lo que significa que implementar backpropagation custom es sorprendentemente manejable.

El ecosistema que creció alrededor es monumental: torchvision para computer vision, torchaudio para procesamiento de audio, HuggingFace Transformers (que corre principalmente sobre PyTorch), PyTorch Lightning para estructurar el training loop sin volverse loco. Si buscás la implementación oficial de algún paper de los últimos cinco años, con alta probabilidad está en PyTorch.

# Ejemplo de training loop básico — esto es lo que Lightning después abstrae
optimizer = torch.optim.Adam(red.parameters(), lr=1e-3)
criterio = nn.CrossEntropyLoss()

for epoch in range(10):
    for imagenes, etiquetas in dataloader:  # dataloader itera el dataset
        imagenes = imagenes.to(dispositivo)
        etiquetas = etiquetas.to(dispositivo)

        optimizer.zero_grad()          # limpiamos gradientes del paso anterior
        predicciones = red(imagenes)   # forward pass
        loss = criterio(predicciones, etiquetas)  # calculamos error
        loss.backward()                # backward pass — autograd en acción
        optimizer.step()               # actualizamos pesos

    print(f"Epoch {epoch+1}, Loss: {loss.item():.4f}")

Por qué está en la lista

Apareció en 6 awesome lists independientes. Eso no es casualidad. El sistema de curación que usamos en esta serie trata esa señal de consenso como un indicador fuerte: cuando comunidades distintas, con criterios distintos, coinciden en recomendar la misma herramienta, algo está pasando.

Lo que está pasando con PyTorch es que ganó la guerra de los frameworks de deep learning — y la ganó de la manera más convincente posible: ganándola primero en investigación y después filtrándose a producción. Hoy la mayoría de los papers en NeurIPS, ICML y similares publican código en PyTorch. HuggingFace, que es básicamente el hub de modelos más importante del mundo, está construido sobre PyTorch. Eso genera un flywheel brutal: más investigadores → más papers → más código → más adopción → más investigadores.

Comparado con TensorFlow (que cubrimos en el post anterior), PyTorch tiene una API más pythónica y una experiencia de debugging significativamente más humana. TensorFlow recuperó terreno con Keras y eager execution, pero la percepción de la comunidad investigadora ya estaba formada. Para equipos que construyen y experimentan rápido, PyTorch es la opción que tiene menos fricción.

El respaldo de Meta garantiza recursos de desarrollo serios. No es un proyecto de hobby con riesgo de abandono — es infraestructura crítica para uno de los jugadores más grandes del ecosistema AI.

Cuándo NO usarlo

Primero y principal: si no estás haciendo deep learning, probablemente no lo necesitás. Para clasificación, regresión, árboles de decisión, clustering — scikit-learn te va a dar lo mismo con un décimo de la complejidad. PyTorch es un cañón, y no todos los problemas son un elefante.

Segundo: el deployment a producción históricamente fue el talón de Aquiles. TensorFlow con TFLite o TensorFlow Serving tiene una historia más larga y más rodada para servir modelos en edge o en APIs de alta escala. PyTorch mejoró esto con TorchScript (para serializar modelos) y ONNX (para exportar a otros runtimes), pero esas herramientas agregan fricción real — y si venís del post de m2cgen, sabés que a veces la solución más elegante al deployment es no llevar el framework a producción en absoluto.

Tercero: el consumo de memoria en GPU para modelos grandes es un mundo aparte. Sin conocimiento de las internals — gradient checkpointing, mixed precision, data parallelism — es fácil quedarse sin VRAM y no entender por qué.

Cierre

PyTorch es de esas herramientas que tiene el consenso de la comunidad no por marketing sino porque resolvió un problema real mejor que la competencia. El grafo dinámico, la API pythónica, el ecosistema que creció alrededor — todo apunta en la misma dirección. Si vas a meterte en deep learning, es el punto de partida más razonable que existe hoy.

Esta fue la entrega #5 de Awesome Curated: The Tools. La serie sigue — cada tool que aparece acá pasó por un proceso de curación que combina señal de múltiples awesome lists, análisis de IA y veredicto humano mío. Si querés ver el recorrido completo desde Docker hasta acá, arrancá desde el primer post. La próxima herramienta ya está en el pipeline.

Este artículo fue publicado originalmente en juanchi.dev