TensorFlow, en contraste con lo que ya sabés de PyTorch

1. tf.Tensor es inmutable; tf.Variable existe para lo que cambia

Primera diferencia real de diseño: en PyTorch, un mismo torch.Tensor puede ser constante o mutable (con requires_grad y operaciones in-place). En TensorFlow, la distinción es de tipo, no de flag: tf.Tensor es inmutable siempre — para pesos de modelo o cualquier estado que cambie con el tiempo, hace falta tf.Variable:

x = tf.constant([[1., 2., 3.]])   # inmutable
x[0, 0] = 9.                    # TypeError: 'EagerTensor' object does not support item assignment
y = x + 1                        # cada operación devuelve un tensor NUEVO; x sigue igual

var = tf.Variable([0.0, 0.0, 0.0])
var.assign([1, 2, 3])          # mutación explícita, método propio
var.assign_add([1, 1, 1])      # → [2, 3, 4]
var + 1                          # las operaciones sobre una Variable devuelven… un tf.Tensor

Ese último renglón es el que confunde al que viene de PyTorch: var + 1 no es una Variable, es un Tensor inmutable. La Variable es un contenedor con estado; todo lo que se calcula a partir de ella es un valor. Por eso en un training loop de TF los pesos se actualizan con var.assign_sub(lr * grad) (o vía el optimizer), nunca con var = var - lr * grad, que reemplazaría la Variable por un Tensor y rompería el modelo. En PyTorch el equivalente in-place es w.sub_(lr * w.grad) dentro de torch.no_grad().

Ni mejor ni peor que la unificación de PyTorch (un solo tipo Tensor para todo) — es simplemente una decisión de diseño distinta: separar el tipo por su mutabilidad en vez de por un flag sobre el mismo tipo. La ventaja práctica de la versión de TF es que un grafo compilado (§3) sabe de antemano qué es estado y qué es valor; la ventaja de PyTorch es que nunca tenés que preguntarte de qué tipo es lo que tenés en la mano.

2. GradientTape: autograd explícito, no implícito

En PyTorch, cualquier operación sobre un tensor con requires_grad=True queda registrada automáticamente en el grafo. TensorFlow lo hace explícito con un context manager:

x = tf.Variable(1.0)

with tf.GradientTape() as tape:
    y = x**2 + 2*x - 5

g_x = tape.gradient(y, x)   # dy/dx = 2x + 2 → 4.0 en x=1

Es el mismo concepto que loss.backward() de PyTorch (regla de la cadena sobre un grafo registrado durante el forward), con una diferencia de superficie: en TF, el alcance de qué se registra está delimitado explícitamente por el bloque with; en PyTorch, está delimitado por el flag requires_grad de cada tensor. Misma idea, distinto mecanismo de scoping.

Tres reglas del tape que explican casi todos los None inesperados. Uno: el tape sigue automáticamente a las tf.Variable entrenables, pero no a los tf.Tensor — para derivar respecto de una constante hay que decirle tape.watch(c) (el equivalente de requires_grad_(True)). Dos: solo se registra lo que pasa adentro del with; un valor calculado antes de entrar es, para el tape, una constante. Tres: el tape se consume al primer tape.gradient; para pedir dos gradientes del mismo forward hace falta GradientTape(persistent=True), que es el retain_graph=True de PyTorch.

c = tf.constant(1.0)
with tf.GradientTape() as tape:
    y = c**2
tape.gradient(y, c)          # None: c es un Tensor, el tape no lo siguió

with tf.GradientTape() as tape:
    tape.watch(c); y = c**2
tape.gradient(y, c)          # 2.0

El loop de entrenamiento manual, que en PyTorch viste como zero_grad → backward → step, en TF es tape → gradient → apply_gradients. No hay zero_grad: como el gradiente es un valor que devuelve tape.gradient y no un atributo que se acumula en el parámetro, no hay nada que limpiar:

with tf.GradientTape() as tape:
    loss = loss_fn(model(xb), yb)
grads = tape.gradient(loss, model.trainable_variables)         # una lista, alineada con las variables
opt.apply_gradients(zip(grads, model.trainable_variables))    # el optimizer hace los assign_sub

3. tf.function: el grafo estático, pero opcional

Acá está la diferencia histórica más importante, ya suavizada. El decorador @tf.function convierte una función Python en un grafo TensorFlow optimizado la primera vez que se ejecuta ("tracing"), y las llamadas siguientes reusan ese grafo compilado en vez de reinterpretar Python:

@tf.function
def my_func(x):
    print('Tracing.')   # solo se imprime la PRIMERA vez con cada shape/dtype nuevo
    return tf.reduce_sum(x)

my_func(tf.constant([1., 2.]))       # imprime "Tracing." y devuelve 3.0
my_func(tf.constant([3., 4.]))       # mismo shape y dtype: reusa el grafo, no imprime nada
my_func(tf.constant([1., 2., 3.]))   # shape nuevo: "Tracing." otra vez, grafo nuevo
my_func(tf.constant([1, 2]))         # dtype nuevo (int32): "Tracing." de nuevo

Lo que pasa en el tracing es que TF ejecuta la función una vez con tensores simbólicos, grabando cada operación de TF que ve — y todo lo que es Python puro (un print, un append a una lista, un if sobre un valor de Python) corre en ese momento y queda fuera del grafo. Por eso el print sale una vez por trace y no una vez por llamada; si querés imprimir desde adentro del grafo, la operación es tf.print. Y por eso el grafo se indexa por la "firma" de la entrada: shape y dtype de cada tensor, y el valor de cada argumento que sea un escalar de Python (pasarle n=1, n=2, n=3 son tres traces; pasarle tf.constant(n) es uno). Cuando los shapes varían de verdad — secuencias de largo variable — se declara una firma con dimensiones libres, input_signature=[tf.TensorSpec([None], tf.float32)], o se usa reduce_retracing=True para que TF generalice sola.

Es, conceptualmente, el ancestro directo de torch.compile — capturar un grafo optimizado a partir de código Python normal. La diferencia clave es cuándo se volvió opcional: en TensorFlow, tf.function existe desde TF 2.0 (2019) como una optimización que hay que agregar a mano, función por función. En PyTorch, torch.compile llegó después (2023) pero se aplicó de forma mucho más transparente sobre modelos ya escritos en estilo eager puro, sin decorar nada dentro del modelo mismo. Los dos comparten el mismo dolor, eso sí: el re-tracing (TF) o la recompilación (PyTorch, que lo llama "recompile" y también tiene un límite de cuántas tolera) cuando los shapes cambian. Lo que aprendiste sobre dynamic=True y shapes estables para torch.compile en la página de producción de PyTorch aplica tal cual acá.

4. Keras: la razón por la que TensorFlow sigue siendo fácil

Keras es la capa de alto nivel que hace que gran parte del código TensorFlow real se vea casi como pseudocódigo:

model = tf.keras.Sequential([
    tf.keras.layers.Flatten(input_shape=(28, 28)),
    tf.keras.layers.Dense(128, activation='relu'),
    tf.keras.layers.Dropout(0.2),
    tf.keras.layers.Dense(10)
])

model.compile(optimizer='adam', loss=loss_fn, metrics=['accuracy'])
model.fit(x_train, y_train, epochs=5)
model.evaluate(x_test, y_test)

No hay training loop manual acá — compile() + fit() lo esconden por completo. Es el equivalente funcional de Learner.fit() en fastai/miniai o del Trainer de HF: una capa de alto nivel sobre el mismo mecanismo de gradientes que viste expuesto a mano en la página de autograd de PyTorch. La guía oficial de TensorFlow, de hecho, primero muestra el loop manual con GradientTape (para enseñar el mecanismo) y después dice explícitamente: "considerá usar Model.compile/Model.fit antes de escribir el tuyo propio" — el mismo consejo pedagógico que fast.ai dio en su Lección 5 sobre usar un framework en vez de reescribir SGD a mano en cada proyecto.

Vale la pena entender qué hace compile(), porque no compila nada en el sentido de §3: fija el optimizer, la loss y las métricas, y arma el train_step (el bloque de GradientTape de §2) que fit() va a envolver en un tf.function. Es la configuración del loop, no la compilación del modelo. (Existe un jit_compile=True en compile() que sí manda el grafo a XLA; ese es el equivalente honesto de torch.compile.)

# KERAS_BACKEND=torch python entrenar.py   (o "jax", o "tensorflow")
import keras

model = keras.Sequential([
    keras.Input(shape=(28, 28)),          # la entrada se declara aparte; input_shape= en una capa está deprecado
    keras.layers.Flatten(),
    keras.layers.Dense(128, activation='relu'),
    keras.layers.Dropout(0.2),
    keras.layers.Dense(10),
])
model.compile(optimizer='adam',
              loss=keras.losses.SparseCategoricalCrossentropy(from_logits=True),
              metrics=['accuracy'])
model.fit(x_train, y_train, epochs=5)

model(x_test[:4])   # con backend torch devuelve un torch.Tensor; con jax, un jax Array

5. Tabla de equivalencias PyTorch ↔ TensorFlow

La tabla para leer código del otro lado. La columna de TensorFlow usa la API de bajo nivel donde existe y Keras donde es la forma real en que la gente lo escribe; la última columna es lo que cambia de verdad, no la sintaxis.

6. Por qué la industria migró a PyTorch — con honestidad

No es una superioridad técnica absoluta — es una combinación de factores que se reforzaron entre sí:

• Ergonomía de investigación primero: eager por defecto desde el día uno, sin necesitar sesiones ni placeholders para debuggear.
• Efecto de red académico: código de referencia de papers en PyTorch → más reproducciones, más tutoriales, más gente formada.
• Consolidación del ecosistema de LLMs: Hugging Face Transformers, que se convirtió en el estándar de facto para modelos preentrenados, eligió PyTorch como backend principal — y ese ecosistema arrastró todo lo que se construyó alrededor (vLLM, PEFT, TRL, Diffusers).
• TensorFlow 1.x llegó tarde a la ergonomía eager: para cuando TF 2.0 la adoptó (2019), la comunidad de investigación ya había migrado en gran parte.

Y un matiz que la versión corta de la historia se come: lo que ganó no fue "PyTorch el framework" sino "PyTorch el punto de encuentro". Keras 3 corriendo sobre PyTorch (§4) y Transformers retirando su soporte de TensorFlow son el mismo movimiento visto desde dos lados — el ecosistema converge en un formato de tensor y un autograd, y el resto se vuelve capas intercambiables encima. Para tu trabajo con vLLM y NVFP4 eso importa más que cualquier comparación de sintaxis: los kernels, los formatos de pesos y las herramientas de cuantización se escriben una vez, contra PyTorch.

7. Dónde TensorFlow (y JAX) siguen importando

Para que ese tercer estilo no te resulte ilegible cuando lo cruces, esto es todo JAX en seis líneas: no hay Variable, ni tape, ni .grad — hay funciones puras y transformaciones de funciones. jax.grad(f) devuelve otra función que calcula el gradiente de f respecto de su primer argumento, y jax.jit compila con XLA lo que le pases:

import jax, jax.numpy as jnp

def loss(w, x, y): return jnp.mean((x @ w - y)**2)

grad_fn = jax.jit(jax.grad(loss))   # grad: función → función gradiente; jit: función → función compilada
w = jnp.zeros(3)
for _ in range(100):
    w = w - 0.1 * grad_fn(w, x, y)  # sin estado: w es un array nuevo en cada paso, nada se muta

Los pesos son un argumento más de la función, el "modelo" es la función loss, y el training loop es aritmética sobre arrays inmutables (el estilo que tf.Tensor de §1 tenía a medias). Es lo que hace a JAX tan cómodo para paralelizar sobre cientos de TPUs — una función pura se puede compilar y particionar sin preguntarse quién muta qué — y lo que lo hace incómodo para el prototipado rápido que PyTorch resuelve bien. Con reconocer jax.grad, jax.jit y jnp ya podés leer un repo de DeepMind sin perderte; no hace falta más para este curso.

8. Errores comunes

Los cinco primeros son los que le pasan a alguien que viene de PyTorch; el sexto, al revés. Casi todos se ven en el primer print de tipos y shapes.

9. Resumen — cierre del curso completo

1. tf.Tensor inmutable + tf.Variable mutable reemplaza al tensor unificado de PyTorch — misma capacidad, tipos separados. Toda operación devuelve un Tensor, incluso sobre una Variable; el estado solo cambia con assign*.
2. GradientTape es autograd con scoping explícito por bloque, en vez de por flag requires_grad en cada tensor. Sigue Variables solas, Tensores con watch, y devuelve el gradiente como valor — por eso no hay zero_grad.
3. tf.function es el ancestro conceptual de torch.compile — la diferencia real es que PyTorch logró hacerlo transparente años después. El tracing corre Python una vez por firma (shape, dtype, valores Python) y de ahí salen los print únicos y el re-tracing.
4. Keras (compile+fit) es al training loop de TF lo que Learner.fit()/Trainer son en PyTorch — una capa de conveniencia sobre el mismo mecanismo de gradientes. Desde Keras 3 (2023) esa capa es independiente del backend: el mismo modelo corre sobre TensorFlow, JAX o PyTorch.
5. La tabla de §5 resume la traducción: mismas siete operaciones, distinta ubicación del estado (flag vs tipo, atributo vs valor, código vs grafo) y distinto layout de imágenes.
6. La migración a PyTorch fue ergonomía + efecto de red + el ecosistema de HF, no una sola causa técnica — y TensorFlow sigue siendo relevante en mobile/web/serving, mientras la investigación de Google ya se movió a JAX, un tercer framework, funcional y sin estado: jax.grad devuelve funciones, jax.jit las compila.

Con esto se cierra el recorrido completo del curso: Hugging Face LLM Course (12 capítulos), fast.ai (Parte 1 + Parte 2), PyTorch y TensorFlow — de la atención en un transformer al framework que hace correr todo lo demás por debajo.

10. Ponete a prueba

Respondé antes de abrir cada respuesta. Si fallás una, volvé a la sección indicada.

11. Para practicar

import os; os.environ["TF_CPP_MIN_LOG_LEVEL"] = "3"   # silenciar los logs de arranque
import tensorflow as tf

# §1: inmutable vs Variable
x = tf.constant([[1., 2., 3.]])
try: x[0, 0] = 9.
except TypeError as e: print("tf.Tensor:", str(e)[:60])
var = tf.Variable([0., 0., 0.])
var.assign([1, 2, 3]); var.assign_add([1, 1, 1])
print("var =", var.numpy(), "| var + 1 es un", type(var + 1).__name__)

# §2: tape, watch, None
w = tf.Variable(1.0); c = tf.constant(1.0)
with tf.GradientTape() as tape:
    y = w**2 + 2*w - 5 + c**2
print("dy/dw =", tape.gradient(y, w).numpy())
with tf.GradientTape() as tape:
    y = c**2
print("dy/dc sin watch =", tape.gradient(y, c))
with tf.GradientTape() as tape:
    tape.watch(c); y = c**2
print("dy/dc con watch =", tape.gradient(y, c).numpy())

# §3: tracing
@tf.function
def f(x):
    print("Tracing.")                 # Python: solo durante el trace
    tf.print("ejecutando, shape", tf.shape(x))   # grafo: en cada llamada
    return tf.reduce_sum(x)
f(tf.constant([1., 2.])); f(tf.constant([3., 4.]))
f(tf.constant([1., 2., 3.])); f(tf.constant([1, 2]))

@tf.function
def g(n): print("trace de g con", n); return n * 2
for n in (1, 2, 3): g(n)                  # ints de Python
for n in (1, 2, 3): g(tf.constant(n))     # tensores

# KERAS_BACKEND=torch python k3.py ; KERAS_BACKEND=jax python k3.py ; KERAS_BACKEND=tensorflow python k3.py
import keras, numpy as np
print("backend:", keras.backend.backend(), "| keras", keras.__version__)

model = keras.Sequential([
    keras.Input(shape=(28, 28)),
    keras.layers.Flatten(),
    keras.layers.Dense(128, activation="relu"),
    keras.layers.Dropout(0.2),
    keras.layers.Dense(10),
])
model.compile(optimizer="adam",
              loss=keras.losses.SparseCategoricalCrossentropy(from_logits=True),
              metrics=["accuracy"])

rng = np.random.default_rng(0)                              # datos sintéticos, sin descargar MNIST
x = rng.random((512, 28, 28), dtype=np.float32)
y = (x.mean(axis=(1, 2)) * 10).astype("int64") % 10            # una etiqueta que sí depende de la imagen
model.fit(x, y, epochs=2, batch_size=64, verbose=0)
print("loss:", round(float(model.evaluate(x, y, verbose=0)[0]), 3))
print("model(x) devuelve:", type(model(x[:4])))
model.save("m.keras"); print("recargado:", type(keras.saving.load_model("m.keras")).__name__)

import jax, jax.numpy as jnp

def loss(w, x, y): return jnp.mean((x @ w - y)**2)
grad_fn = jax.jit(jax.grad(loss))

key = jax.random.PRNGKey(0)                    # el random también es explícito y sin estado
x = jax.random.normal(key, (64, 3))
w_true = jnp.array([1., -2., 0.5]); y = x @ w_true

w = jnp.zeros(3)
for _ in range(100): w = w - 0.1 * grad_fn(w, x, y)
print(w, float(loss(w, x, y)))

12. Fuentes y para seguir

• TensorFlow basics — la guía en la que se basa esta página: tensores, variables, tape, tf.function y el loop manual seguido del consejo de usar fit.
• Introduction to Tensors y Introduction to Variables — el detalle de §1, incluida la lista de qué operaciones devuelven Tensor a partir de una Variable.
• Introduction to gradients and automatic differentiation — GradientTape completo: watch, persistent, y la sección "Getting a gradient of None" que explica cada caso de §8.
• Better performance with tf.function — tracing, firmas, retracing y efectos secundarios de Python; leela si alguna vez tenés que optimizar código TF de verdad.
• Keras 3 — keras.io — el anuncio y la guía de migración multi-backend; ahí está la lista de lo que cambió respecto de tf.keras y cómo elegir el backend.
• JAX documentation — el "Quickstart" y "Key concepts" son suficientes para leer código JAX; grad, jit, vmap y por qué los arrays son inmutables.