TensorFlow remains widely used for production ML, especially mobile and edge deployment

TensorFlow: the ML elephant that's still standing

This is post #4 in the Awesome Curated: The Tools series — where I do deep dives on the tools that pass the filter of our automated curation system. If you landed here directly, you might also want to check out how m2cgen lets you export ML models without shipping Python to production, because it connects pretty directly to what we're talking about today. I was in an architecture meeting a few months ago. A team wanted to tear down their ML production stack and migrate everything to PyTorch because "TensorFlow is old and nobody uses it anymore." The main argument was that all the recent papers use PyTorch. I asked: where does the model run today? On a server on Google Cloud. Are there mobile endpoints? Yes — an iOS and Android app. How much traffic? Millions of requests per day. I told them migrating wasn't necessarily a bad idea, but could they walk me through how much effort it would take to rewrite the deployment pipeline, the production serving layer, and the compiled TFLite model running on those mobile devices. Silence. The migration makes technical sense in an ideal world where you have six months and zero users waiting. In the real world, TensorFlow is still the answer when deployment matters more than the elegance of your training code. And that's exactly what puts it here, on the list. What it does TensorFlow is Google's open-source machine learning framework. It started as a C++ library with Python bindings, and that's not a minor detail — the performance core is written in C++ and CUDA, and the Python API is essentially a very powerful wrapper over that. Today it has over 185k GitHub stars, which makes it one of the most starred repos on the entire platform. The core proposition is: you build a computational graph that describes your model, and TF optimizes and executes it. In TF2 this got a lot friendlier with eager execution on by default (you can run operations line by line, just like in PyTorch), but the real power kicks in when you use @tf.function to compile functions into optimized graphs: import tensorflow as tf # Define the model — I'm using Keras which ships built into TF2 model = tf.keras.Sequential([ tf.keras.layers.Dense(128, activation='relu', input_shape=(784,)), tf.keras.layers.Dropout(0.2), # Regularization to prevent overfitting tf.keras.layers.Dense(10, activation='softmax') # 10 output classes ]) # Compile with optimizer and loss function model.compile( optimizer='adam', loss='sparse_categorical_crossentropy', metrics=['accuracy'] ) # Training — X_train and y_train are your data model.fit(X_train, y_train, epochs=10, validation_split=0.2) But where TF really shines is the deployment ecosystem. TFLite converts trained models into optimized versions for mobile and edge devices — with quantization that shrinks model size from megabytes to kilobytes without losing too much accuracy. TensorFlow Serving is a production model server that scales horizontally, handles versioning, and delivers extremely low latencies. TensorFlow.js runs models in the browser. It's an entire ecosystem, not just a training library. # Export to TFLite for mobile deployment converter = tf.lite.TFLiteConverter.from_keras_model(model) # Dynamic quantization — reduces size without retraining converter.optimizations = [tf.lite.Optimize.DEFAULT] # Convert — the output is a .tflite file that goes straight to iOS/Android tflite_model = converter.convert() # Save to disk with open('optimized_model.tflite', 'wb') as f: f.write(tflite_model) # This file is typically 3-10x smaller than the original model # and runs without needing Python on the target device print(f'TFLite model size: {len(tflite_model) / 1024:.1f} KB') Why it made the list The curation system picked it up in 6 independent awesome lists. That doesn't happen because of hype — it happens because 6 different communities, with different criteria, all reached the same conclusion: this is a tool you can't ignore. And the verdict from both the AI analysis and my own review was GEM, which in our system means exactly what it sounds like: something with real, lasting value. What differentiates TF from PyTorch in this context isn't which one trains models better — in that game, honestly, PyTorch won the cultural war, especially in research. What sets TF apart is the deployment story. TFLite has no direct equivalent in the PyTorch ecosystem that's anywhere near as mature for production mobile use. TorchScript exists, but if you've ever tried to integrate a PyTorch model into a native iOS app you already know the pain compared to TFLite. TensorFlow Serving spent years handling brutal production workloads inside Google before it was ever open-sourced — that translates into a level of robustness you simply can't manufacture overnight. The other factor is Google Cloud. If your infrastructure lives there, the native integration with Vertex AI, Cloud ML Engine, and the rest of the GCP ecosystem is a real multiplier. It's not ideological lock-in — it's architectural pragmatism. When NOT to use it If you're learning ML from scratch or doing research, PyTorch (github.com/pytorch/pytorch) will make your life much simpler. The API is more Pythonic, debugging is more intuitive because everything runs in eager mode by default, and the research community lives there — which means new papers come with PyTorch code, not TF. The historical baggage of TF1 vs TF2 still haunts Stack Overflow: you find contradictory answers because people mix versions without clarifying which is which. It's disorienting. I wouldn't use it for small projects where deployment is just a normal Python web server either. In that case, you can train with whatever you want and export with m2cgen if the model is simple enough, or serve with FastAPI + pickle if you don't need scale. TF adds real complexity — use it when the problem justifies it. And if your team has nobody with TF experience, the onboarding cost for a new project probably isn't worth it unless edge or mobile deployment is a concrete requirement from day zero. TF is still standing, and there are reasons for that What pushed me to confirm the human GEM verdict is this: TensorFlow isn't on 6 lists because it's trending. It's there because it solves production problems that others don't solve as well. It's the kind of tool you won't pick out of enthusiasm — you'll pick it out of necessity. And when you need it, you'll be glad it exists and that it's spent a decade getting battle-tested. This is post #4 in Awesome Curated: The Tools. The series continues — every tool that shows up here has been through a community signal filter, AI analysis, and a human verdict before making the cut. If you're particularly interested in the ML angle, the post on m2cgen pairs really well with this one: it's exactly the other side of the coin, when the model is already trained and you need to get Python out of your production stack entirely. This article was originally published on juanchi.dev

17 hours ago

TensorFlow: el elefante de ML que sigue en pie

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

17 hours ago