Snap procesa cada mañana más de 10 petabytes de datos en una ventana de tres horas para correr los miles de experimentos A/B que definen qué llega o no a los 940 millones de usuarios de Snapchat. Hasta hace poco, ese proceso corría en CPUs. Ahora corre en GPUs con las librerías abiertas de NVIDIA —cuDF y RAPIDS Accelerator para Apache Spark— sobre Google Kubernetes Engine, y los resultados son difíciles de ignorar: 76% de reducción en costo diario y 4x de speedup con el mismo número de máquinas.
Lo que convierte este caso en algo más que un comunicado de relaciones públicas de NVIDIA es la escala del problema que resuelve y la forma en que llegaron a él.
¿Qué hace cuDF exactamente?
Apache Spark es el framework estándar para procesamiento de datos distribuido a escala. Históricamente corre en CPUs. cuDF —parte de las librerías RAPIDS de NVIDIA— permite ejecutar workloads de Spark sobre GPUs sin cambiar el código. Es una migración transparente: el mismo pipeline, diferente hardware de cómputo.
IA para el Resto de Nosotros
La nueva versión de mi curso estrella para aprender a usar la IA de forma práctica, simple y útil en tu día a día. Comienza el 24 de marzo.
→ Inscríbete hoy 🚀La clave técnica es que el tipo de operaciones que Snap ejecuta en sus pipelines de A/B testing —joins, aggregations, transformaciones sobre columnas masivas— son exactamente el tipo de operaciones que las GPUs paralelizan de forma natural. El match entre el workload y el hardware es inusualmente bueno.
El resultado concreto: Snap necesitó 2.100 GPUs corriendo en paralelo para sus dos pipelines más grandes, en lugar de los 5.500 que hubiera necesitado con su arquitectura anterior. Optimizar cómo se usan las GPUs es una de las fronteras más activas de la ingeniería de IA hoy, y este caso ilustra por qué.
¿Por qué importa el modelo open source aquí?
La decisión de Snap de construir sobre librerías abiertas (Apache Spark + cuDF) en vez de una solución propietaria tiene implicancias que van más allá de los costos. Significa que el stack es auditable, que otros pueden replicarlo, y que la empresa no queda atada a un vendor específico para ese componente de su infraestructura.
Este es el mismo patrón que hyperscalers europeos como Nscale están adoptando: construir sobre capas abiertas para evitar dependencia de los grandes proveedores de nube. La diferencia es que Snap lo hace desde adentro de un proveedor de nube (Google Cloud), lo que muestra que open source y cloud no son excluyentes.
La lección para empresas que escalan datos con IA
El CTO de datos de Snap fue directo: “No nos dábamos cuenta de que teníamos una mina de oro. Migramos nuestros dos pipelines más grandes, pero hay mucha oportunidad por delante.” Eso traduce a: la adopción fue conservadora por diseño, y los resultados fueron mejores de lo esperado.
Para cualquier empresa que procesa grandes volúmenes de datos con Spark —telcos, retailers, fintechs, medios— el caso de Snap es una referencia concreta. No es teoría: son números internos de enero a marzo de 2026, con workloads reales.
El costo de no migrarlo es también concreto: Snap habría necesitado casi el triple de GPUs para escalar su roadmap de experimentación sin este cambio. Ese delta tiene un precio real en un mercado donde las GPUs siguen siendo escasas y caras.
Por qué importa
El debate sobre el costo de la IA suele vivir en la capa de los modelos —cuánto cuesta entrenar, cuánto cuesta una llamada a API. Pero hay una capa de infraestructura de datos que es igual de costosa y mucho menos discutida: los pipelines que alimentan esos modelos. NVIDIA está bajando el costo real de la IA desde múltiples ángulos, y este es uno de los menos visibles para el público general.
Snap demostró que migrar ese tipo de workloads a GPUs con librerías abiertas no requiere reescribir código, no requiere cambiar de proveedor de nube, y genera ahorros inmediatos y masivos. La barrera de adopción es baja. La pregunta es cuántas empresas lo están aprovechando.
