SpaceX adquiere Cursor por US$60.000M, DiffusionGemma rompe récord de velocidad y Hugging Face publica un robot bipedal por US$2.500

El día empieza con la operación de M&A más grande del año en inteligencia artificial: SpaceX confirmó esta mañana la adquisición de Cursor por US$60.000 millones. Es la primera movida grande de SpaceX como empresa pública desde su salida a bolsa hace cuatro días, y consolida una jugada que veníamos viendo armarse desde mayo. Sobre eso, dos noticias que mueven el cálculo práctico para equipos chicos: Google liberó DiffusionGemma y abrió el camino a más de mil tokens por segundo en una sola GPU, y Hugging Face publicó un humanoide do-it-yourself completo por US$2.500 que pone la robótica al alcance de cualquier facultad. Tres noticias que cuentan la misma historia desde ángulos opuestos: mientras los grandes consolidan poder a fuerza de compras gigantes, la base se vuelve cada vez más accesible para quien tenga curiosidad y un poco de tiempo.

Qué pasó: SpaceX confirmó hoy 16 de junio que va a adquirir Anysphere, la empresa detrás del editor de código con inteligencia artificial Cursor, por US$60.000 millones en una transacción completamente en acciones. El cierre del trato se espera para el tercer trimestre de 2026, sujeto a aprobaciones regulatorias. Es la primera adquisición grande de SpaceX desde su salida a bolsa el 12 de junio, donde levantó cerca de US$75.000 millones a una valuación de US$1.75 billones (un trillón y medio en notación inglesa). El trato no salió de la nada. Desde abril SpaceX tenía un acuerdo de opción con Anysphere que le daba dos caminos: pagar aproximadamente US$10.000 millones por una asociación estratégica, o pagar US$60.000 millones para adquirir la empresa entera más adelante en el año. Hoy ejercieron la segunda opción.

Por qué Cursor vale tanto: los números explican parte de la historia. Cursor cerró junio con un revenue anualizado de US$4.000 millones, desde aproximadamente US$3.000 millones en abril y US$2.000 millones en febrero. Más de US$2.600 millones de esa cifra vienen del segmento empresarial. La empresa pasó de prácticamente desconocida a referencia obligada en herramientas de desarrollo en menos de dos años, en buena medida por una experiencia de producto que se siente nativa para programadores y por una integración con modelos frontera (Claude, GPT) que tomó la delantera frente a competidores como GitHub Copilot. Otro detalle relevante: SpaceXAI (lo que antes era xAI hasta que Musk lo fusionó dentro de SpaceX a inicios de año) ha estado entrenando un modelo en conjunto con Cursor durante varios meses. Ese modelo se espera que se despliegue tanto dentro de Cursor como dentro de Grok Build en las próximas semanas.

Lo que esto significa de verdad para builders LATAM y para el resto del ecosistema: estamos viendo la consolidación de la jugada "modelo más herramienta más distribución más cómputo" en un solo proveedor. SpaceX ya controla un modelo frontera propio a través de SpaceXAI, ahora controla el editor de código con más tracción del mercado, y de fondo tiene Starlink como capa de distribución global más cualquier capacidad de cómputo que decida acumular. Es la versión Musk de lo que Microsoft intentó construir con la inversión en OpenAI y lo que Google tiene de forma orgánica con DeepMind, Gemini y la pila completa de Cloud. La diferencia es que la concentración se está dando ahora a velocidad de mercado público, no a velocidad de planeación corporativa. Para developers LATAM que llevan dos años pagando US$20 al mes por Cursor, la pregunta práctica honesta es qué pasa con el precio, los términos de uso y el roadmap cuando el dueño cambia. La historia de adquisiciones grandes en el sector muestra que en los primeros doce meses casi nada cambia visiblemente, pero después de eso los términos suelen alinearse a los intereses estratégicos del nuevo dueño. Para founders LATAM construyendo herramientas competidoras o complementarias a Cursor, el techo competitivo acaba de subir de manera significativa, y la ventana para diferenciarse en nichos específicos (lenguajes locales, integraciones regionales, regulación) se vuelve más importante que pretender competir frontalmente. Y para cualquier equipo que tenga una dependencia crítica de Cursor en su flujo de trabajo, vale acelerar lo que el lunes pasado planteamos como ejercicio estratégico: identificar herramientas de respaldo, probarlas en serio, y tener una arquitectura que permita cambiar sin reescribir el producto.

Fuentes:

Qué pasó: El 10 de junio Google DeepMind liberó DiffusionGemma, un modelo de 26 mil millones de parámetros con arquitectura mixture-of-experts (3.800 millones activos por token) que genera texto usando un mecanismo de diffusion en lugar del clásico autoregresivo token por token. La diferencia es importante. Mientras los modelos tradicionales escriben una palabra, esperan, escriben la siguiente, DiffusionGemma arranca con ruido y va refinando bloques de 256 tokens en paralelo hasta llegar al texto final. El resultado práctico se mide en velocidad. Más de 1.000 tokens por segundo en una NVIDIA H100, más de 700 en una RTX 5090 de consumo. Cuantizado entra cómodamente en 18 GB de VRAM, con soporte day-zero en vLLM, Hugging Face Transformers, Apple MLX y Unsloth. La licencia es Apache 2.0 y el modelo ya está disponible en Hugging Face, Kaggle y Vertex AI.

Lo que importa entender sin que te lo vendan más bonito de lo que es: DiffusionGemma rinde por debajo de Gemma 4 en benchmarks de razonamiento como MMLU y en pruebas de programación. Google lo posiciona explícitamente como experimental, pensado para flujos de trabajo donde la velocidad pesa más que la calidad absoluta. No es un reemplazo de tu modelo de producción si lo que necesitas son respuestas matizadas o código complejo.

Pero entonces, ¿por qué es interesante? Porque cambia la economía del inference local para tareas que ya hoy se podrían correr sin pagar API y nadie lo hace por pereza arquitectónica. Autocompletado en un editor interno, clasificación masiva de tickets de soporte, borradores iniciales que luego pasan por revisión humana, generación de variantes de texto para pruebas A/B. Para un equipo LATAM de dos a cinco personas con presupuesto ajustado, tener 1.000 tokens por segundo corriendo en una sola GPU significa que muchas tareas que estabas mandando a la API de OpenAI o Anthropic pueden quedarse adentro, en tu infraestructura, sin factura mensual sorpresa. Vale pilotearlo esta semana en lo no crítico y medir tres cosas: velocidad real en tu hardware, calidad subjetiva del resultado, y costo comparado con tu factura actual de API.

Fuentes:

Qué pasó: Hugging Face liberó LeRobot Humanoid, un kit de robot bipedal de aproximadamente US$2.500 en partes, construido principalmente con piezas impresas en 3D, componentes electrónicos comerciales y servomotores accesibles. Importante aclarar lo que es y lo que no es. En esta primera versión, el robot consiste específicamente en la mitad inferior (piernas y pelvis) con capacidad de mantenerse parado y caminar. La plataforma no es solo el hardware sino todo el stack que lo acompaña: lista de materiales con proveedores, archivos imprimibles, instrucciones de armado, herramientas de software para calibración y simulación, y los entornos de entrenamiento que la propia empresa usa internamente sobre LeRobot, el framework open source de robótica que viene construyendo hace meses.

Por qué importa más allá del titular: dos mil quinientos dólares es el orden de magnitud de un buen MacBook Pro, o de una matrícula universitaria en muchos países de la región. No es un robot de juguete educativo y tampoco pretende ser la respuesta a Optimus de Tesla. Es la versión "Raspberry Pi de la robótica bipedal". Suficiente para que un equipo de investigación en una universidad regional, un laboratorio de innovación en una empresa mediana, o un colectivo de makers serios puedan empezar a hacer experimentos reales en marcha, balance y aprendizaje por imitación, sin depender de plataformas cerradas o de hardware industrial que cuesta sesenta veces más. Y si el roadmap incluye liberar el torso y los brazos más adelante, lo que arranca como un par de piernas se va a ir convirtiendo en un humanoide completo modular.

Lo que esto desbloquea para LATAM, concretamente: las universidades de la región llevan años intentando hacer investigación en robótica bipedal con presupuestos que no alcanzan ni para una sola pierna de un robot Unitree. Con esta plataforma, una facultad de ingeniería puede armar tres o cuatro unidades por el costo de uno solo del hardware comercial cerrado, ponerlas en el laboratorio de estudiantes de grado y empezar a publicar trabajo serio. La barrera dejó de ser presupuestaria y pasó a ser de talento y de voluntad institucional. Para empresas que están armando equipos de robótica aplicada en logística, comercio minorista o manufactura, este es el camino más razonable para hacer prototipos antes de comprometerse a comprar hardware caro de proveedores. Y para makers individuales y colectivos, abre el espacio que la Raspberry Pi abrió para la electrónica de consumo hace quince años.

Fuentes:

La oportunidad concreta con DiffusionGemma no es reemplazar tu modelo de producción, es ver qué porcentaje de tu factura mensual de API podrías mover a un modelo local sin perder calidad útil. Tres pasos para responderlo en menos de un día de trabajo.

Primero, identifica candidatos honestos en tu stack. Mira tu registro de llamadas a la API de las últimas dos semanas y separa las que son de baja complejidad: clasificación de texto, extracción de campos estructurados, generación de borradores que después un humano revisa, autocompletado de campos de formulario, sugerencias de etiquetas. No mires todavía las llamadas que generan respuestas que van directo al cliente sin revisión. Para empezar, importa la base, no el caso de mayor riesgo.

Segundo, prueba con tu propio dataset. Descarga el modelo cuantizado desde Hugging Face (entra en 18 GB de VRAM, así que sirve una RTX 4090 o una RTX 5090 si tienes acceso, o una instancia spot de cloud por dos o tres horas). Toma cien ejemplos representativos de la tarea candidata, pásalos por DiffusionGemma y por tu modelo actual, y mide tres métricas concretas: tiempo de respuesta promedio, calidad subjetiva en una escala de uno a cinco, y costo por ejemplo. La calidad subjetiva la evalúas tú o un colega del equipo en modo ciego, sin saber qué modelo generó cada respuesta.

Tercero, decide con número en mano. Si la calidad subjetiva de DiffusionGemma queda dentro de un punto del modelo actual y la velocidad es mejor (que casi seguro lo va a ser), el caso económico es claro. Si la calidad cae dos puntos o más, ese flujo específico no es candidato y vale dejarlo en la API por ahora.

La trampa que evitar es asumir que open weights significa peor y no medir. La velocidad de DiffusionGemma probablemente compense para más casos de los que intuitivamente parece. Hacer la medición en tu propio dataset es la diferencia entre decidir con sesgo y decidir con datos.