Este es el post #4 de la serie 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á, quizás te interese ver también cómo m2cgen te permite exportar modelos de ML sin llevar Python a producción, que tiene bastante que ver con lo que vamos a hablar hoy.

Estaba en una reunión de arquitectura hace unos meses. Un equipo quería tirar abajo su stack de ML en producción y migrar todo a PyTorch porque "TensorFlow es viejo y nadie lo usa". El argumento principal era que en los papers más recientes todo el mundo usa PyTorch. Les pregunté: ¿dónde corre el modelo hoy? En un servidor con Google Cloud. ¿Hay endpoints móviles? Sí, una app iOS y Android. ¿Cuánto tráfico? Millones de requests por día.

Les dije que no era una mala idea migrar, pero que me explicaran cuánto esfuerzo tenían para reescribir la pipeline de deployment, el serving en producción y el modelo compilado para TFLite en los móviles. Silencio. La migración técnicamente tiene sentido en un mundo ideal donde tenés seis meses y cero usuarios esperando. En el mundo real, TensorFlow sigue siendo la opción cuando el deployment importa más que la elegancia del código de entrenamiento.

Y eso es exactamente lo que lo pone acá, en la lista.

Qué hace

TensorFlow es el framework de machine learning open-source de Google. Arrancó como una librería de C++ con bindings para Python, y eso no es un detalle menor — el core de rendimiento está escrito en C++ y CUDA, y la API de Python es básicamente un wrapper muy poderoso sobre eso. Hoy tiene más de 185k estrellas en GitHub, lo que lo convierte en uno de los repos más starreados de toda la plataforma.

La propuesta central es: construís un grafo computacional que describe tu modelo, y TF lo optimiza y ejecuta. En TF2 esto se volvió más amigable con eager execution por default (podés ejecutar operaciones línea a línea como en PyTorch), pero el poder real está cuando usás @tf.function para compilar funciones en grafos optimizados:

import tensorflow as tf

# Definimos el modelo — acá uso Keras que viene integrado en TF2
model = tf.keras.Sequential([
    tf.keras.layers.Dense(128, activation='relu', input_shape=(784,)),
    tf.keras.layers.Dropout(0.2),  # Regularización para evitar overfitting
    tf.keras.layers.Dense(10, activation='softmax')  # 10 clases de salida
])

# Compilamos con optimizador y función de pérdida
model.compile(
    optimizer='adam',
    loss='sparse_categorical_crossentropy',
    metrics=['accuracy']
)

# Entrenamiento — X_train e y_train son tus datos
model.fit(X_train, y_train, epochs=10, validation_split=0.2)

Pero donde TF realmente brilla es en el ecosistema de deployment. TFLite convierte modelos entrenados en versiones optimizadas para móviles y dispositivos edge — con cuantización que reduce el tamaño del modelo de megabytes a kilobytes sin perder demasiada precisión. TensorFlow Serving es un servidor de modelos en producción que escala horizontal, maneja versioning y tiene latencias bajísimas. TensorFlow.js corre modelos en el browser. Es un ecosistema entero, no solo una librería de entrenamiento.

# Exportar a TFLite para deployment en móvil
converter = tf.lite.TFLiteConverter.from_keras_model(model)

# Cuantización dinámica — reduce tamaño sin reentrenar
converter.optimizations = [tf.lite.Optimize.DEFAULT]

# Convertimos — el resultado es un archivo .tflite que va directo a iOS/Android
tflite_model = converter.convert()

# Lo guardamos al disco
with open('modelo_optimizado.tflite', 'wb') as f:
    f.write(tflite_model)

# Este archivo pesa típicamente 3-10x menos que el modelo original
# y corre sin necesidad de Python en el dispositivo final
print(f'Tamaño del modelo TFLite: {len(tflite_model) / 1024:.1f} KB')

Por qué está en la lista

El sistema de curación lo detectó en 6 awesome lists independientes. Eso no pasa por hype — pasa porque 6 comunidades distintas, con criterios distintos, llegaron a la misma conclusión: es una herramienta que no podés ignorar. Y el veredicto tanto del análisis de IA como el mío fue GEM, que en nuestro sistema significa exactamente lo que parece: algo que tiene valor real y duradero.

Lo que lo diferencia de PyTorch en este contexto no es quién entrena mejor los modelos — en ese juego, honestamente, PyTorch ganó la batalla cultural, especialmente en investigación. Lo que diferencia a TF es el deployment story. TFLite no tiene equivalente directo en el ecosistema PyTorch que sea tan maduro para producción móvil. TorchScript existe, pero si alguna vez intentaste integrar un modelo PyTorch en una app iOS nativa vas a saber el dolor que es comparado con TFLite. TensorFlow Serving lleva años corriendo cargas de producción brutal en Google antes de ser open-source — eso se traduce en robustez que no se consigue de un día para el otro.

El otro factor es Google Cloud. Si tu infraestructura vive ahí, la integración nativa con Vertex AI, Cloud ML Engine y el resto del ecosistema GCP es un multiplicador real. No es lock-in ideológico — es pragmatismo de arquitectura.

Cuándo NO usarlo

Si estás aprendiendo ML desde cero o haciendo investigación, PyTorch (github.com/pytorch/pytorch) te va a hacer la vida mucho más simple. La API es más pythónica, el debugging es más intuitivo porque todo corre en eager mode por default, y la comunidad investigadora está ahí — lo que significa que los papers nuevos tienen código en PyTorch, no en TF. La deuda histórica de TF1 vs TF2 todavía se siente en Stack Overflow: encontrás respuestas contradictorias porque mezclan versiones sin aclarar cuál es cuál. Eso marea.

Tampoco lo usaría para proyectos pequeños donde el deployment es un servidor web normal con Python. En ese caso, podés entrenar con lo que quieras y exportar con m2cgen si el modelo es suficientemente simple, o servir con FastAPI + pickle si no necesitás escala. TF agrega complejidad real — usala cuando el problema lo justifica.

Y si tu equipo no tiene nadie con experiencia en TF, el costo de onboarding para un proyecto nuevo probablemente no vale la pena salvo que el deployment en edge o móvil sea un requerimiento concreto desde el día cero.

TF sigue en pie, y hay razones para eso

Lo que me llevó a confirmar el GEM humano es esto: TensorFlow no está en 6 listas porque esté de moda. Está porque resuelve problemas de producción que otros no resuelven igual de bien. Es el tipo de herramienta que no vas a elegir por entusiasmo sino por necesidad — y cuando la necesitás, vas a estar contento de que existe y de que lleva una década siendo battle-tested.

Este es el post #4 de Awesome Curated: The Tools. La serie sigue — cada herramienta que aparece pasó por un filtro de señal de comunidad, análisis de IA y veredicto humano antes de llegar acá. Si te interesa el tema de ML en particular, el post sobre m2cgen cierra muy bien con este: es exactamente la otra cara de la moneda, cuando el modelo ya está entrenado y necesitás sacarte Python de encima en producción.

Este artículo fue publicado originalmente en juanchi.dev