Mojo 1.0 Apache 2.0: la apuesta heterogénea de Modular post-Qualcomm
Mojo 1.0 Apache 2.0: la apuesta heterogénea de Modular post-Qualcomm
El anuncio de ModCon 2026 tiene cuatro cosas importantes, y la que más ruido hizo en HN no es la que más te va a cambiar la vida. Mojo 1.0 pasó a Apache 2.0 completo: compiler, toolchain, todo. Pero debajo de eso, Modular está empujando una tesis mucho más grande: escribir tu modelo una vez y que corra en una GPU NVIDIA, un TPU de Google, un Trainium de AWS o un Qualcomm Dragonfly sin reescribir nada. Si te interesa correr LLMs en casa — y leyendo este blog supongo que sí — esa segunda parte es la que mueve la aguja.
El contexto es raro: Chris Lattner (el mismo de LLVM y Swift) fundó Modular, la empresa fue adquirida por Qualcomm el 29 de julio, y veinte días después liberan el lenguaje completo bajo Apache 2.0. La lectura cínica dice "lo soltaron porque Qualcomm no sabe qué hacer con un lenguaje". La lectura interesante dice otra cosa, y es la que vale la pena mirar.
Qué se liberó exactamente y qué no
Hay tres componentes en el stack de Modular, y el nivel de apertura de cada uno es distinto. Importa entenderlo porque define qué podés forkear, qué podés usar en producción y qué sigue siendo una caja negra.
Lo primero, y lo más visible, es el lenguaje Mojo. Lo que se liberó bajo Apache 2.0 es el compiler y todo el toolchain: podés leer el código del compilador, enviar parches, hacer un fork y compilar tu propia versión. Esto es lo que faltaba para que Mojo pasara de "lenguaje con standard library abierta" a "proyecto que podés mantener vos mismo si la fundación detrás se cae". Es exactamente la transición que Python hizo hace décadas y la que Rust hizo cuando Mozilla dejó de tener el control exclusivo.
Lo segundo, y más sutil, es el runtime MAX. Acá Modular eligió un modelo source-available, no open source clásico. MAX sigue siendo código que podés leer y compilar, pero hay restricciones de uso — específicamente, ya no contiene restricciones por tipo de dispositivo (la limitación vieja que obligaba a pagar si querías correr en hardware que no fuera NVIDIA) y viene con un "open alliance program" donde partners pueden integrarse. El código está, pero no podés hacer un fork comercial libre sin hablar con Modular primero. Es un compromiso pensado: lo suficiente abierto para que el ecosistema crezca, lo suficiente cerrado para que haya un negocio alrededor.
Lo tercero es Modular Cloud, el servicio de inferencia administrada. Esto sigue siendo un producto comercial: pricing por token, deployments dedicados, regiones, soporte. Lo importante de la nube es que ya está en producción sirviendo tráfico real — incluyendo a MiniMax como flagship customer, corriendo M3 con 1M de contexto y arquitectura de atención sparse (MSA) a billones de tokens por minuto. Que un modelo de un hyperscaler chino corra sobre el stack de Modular es señal de que el producto funciona, no vaporware.
La tesis heterogénea: por qué importa si corrés LLMs en casa
El anuncio técnico más fuerte no es el open source. Es que el mismo modelo escrito en Mojo + MAX corre, sin reescritura, sobre cinco tipos de hardware distintos: GPUs NVIDIA, GPUs AMD, AWS Trainium, Google TPUs, Qualcomm Cloud AI 100 Ultra y Qualcomm Dragonfly. Modular dice que habilitar cada plataforma nueva les costó una fracción del esfuerzo tradicional — mencionan más de 10x de reducción en engineering effort, y que HTEC (un partner) trajo TPUs ellos solos en pocos meses con un equipo chico.
Hasta ahora, el stack de inferencia tenía una propiedad incómoda: cada backend tenía su propio dialecto. vLLM para NVIDIA, TGI para HF, TensorRT-LLM para producción NVIDIA, llama.cpp para CPU y Apple Silicon, XLA para TPUs, NeuronX para Trainium. Si querías comparar el mismo modelo en hardware distinto, el código cambiaba. El benchmark que publicabas en una GPU no era portable a otra. Y esto no era accidental: cada vendor tiene incentivo a que su hardware sea el más fácil de usar, no a que sea intercambiable.
Lo que Modular está intentando es lo que el ecosistema CUDA hizo mal durante una década: separar el modelo del silicio. Si MAX cumple lo que promete, podés escribir kernels una vez y moverte entre Trainium, TPU y GPU según precio, disponibilidad y latencia. Para un equipo chico que está corriendo modelos en hardware no-NVIDIA (algo que en swiftlet-80b-en-4gb-ram-mac-iphone vimos que es viable para Apple Silicon, y que con linux-7-3-vram-overcommit-gpu-memory-management se vuelve más amigable en Linux), la promesa es concreta.
El elefante en la sala: Qualcomm
Modular es ahora una subsidiaria de Qualcomm. Y Qualcomm tiene una reputación específica en la comunidad open source: históricamente cerrada, históricamente opaca sobre el roadmap de drivers, y con el Adreno GPU soportado de manera irregular en Linux. Si sos developer, "Qualcomm adquiere un proyecto open source" activa reflejos defensivos automáticos. Los comentarios en el thread de HN son exactamente eso: entusiasmo por el lenguaje combinado con sospecha sobre el dueño.
Hay tres lecturas posibles de por qué soltaron Mojo justo después de la adquisición:
La primera, cínica: Qualcomm quiere extraer valor de Modular Cloud mientras el lenguaje se muere lentamente por abandono. El open source es un gesto para mantener a los developers enganchados mientras el negocio real (la nube, los chips Dragonfly para data centers) captura el valor. Esta lectura es plausible y hay precedentes (MySQL después de Oracle, MariaDB como escape).
La segunda, neutral: el plan original de Modular siempre fue abrir el lenguaje. La adquisición de Qualcomm les dio el capital para hacerlo sin depender de monetization del lenguaje en sí, y la fecha es coincidencia con la maduración del proyecto (Mojo 1.0 salió la semana anterior). Bajo esta lectura, Qualcomm adquiere una plataforma de inferencia heterogénea, y el lenguaje es un complemento abierto para que el ecosistema crezca alrededor del hardware que Qualcomm quiere vender.
La tercera, optimista: Qualcomm está apostando a que el futuro de la inferencia es heterogéneo y multi-vendor, no monolítico sobre NVIDIA. Liberar Mojo bajo Apache 2.0 es la única manera de que aparezca un ecosistema que no dependa de CUDA. Qualcomm tiene un interés estratégico directo en romper el monopolio de CUDA porque su hardware para data centers vive o muere según cuán fácil sea programarlo. Bajo esta lectura, abrir Mojo es una jugada competitiva seria, no un gesto vacío.
No sé cuál de las tres es la correcta. Pero los próximos seis meses van a ser reveladores: si Qualcomm mantiene el ritmo de releases, responde issues en GitHub y aporta engineers al proyecto, la lectura optimista se valida. Si Mojo entra en un limbo de commits espaciados y roadmap opaco, fue gesto.
Qué podés hacer hoy con Mojo 1.0
Para los que quieran meter las manos, Mojo 1.0 ya está usable para tres cosas concretas.
La primera es escribir kernels GPU portables. La sintaxis inspirada en Python pero con tipado fuerte, comptime para metaprogramación, y un sistema de ownership/borrowing que recuerda a Rust. Si ya escribiste CUDA, vas a sentir el cambio: menos boilerplate, sintaxis que se lee más cerca de NumPy, mismo nivel de control fino sobre memoria y paralelismo. El repositorio en GitHub tiene ejemplos de kernels escritos en pocas líneas que serían 50+ líneas de CUDA.
La segunda es experimentar con inference servers heterogéneos. Si tenés acceso a un TPU o un Trainium (Google Cloud y AWS respectivamente), podés probar el mismo modelo en hardware distinto sin reescribir el serving stack. El claim de "10x menos esfuerzo para habilitar hardware nuevo" no lo puedo verificar yo solo, pero los reportes de HTEC trayendo TPUs en meses con pocos engineers son consistentes con ese número.
La tercera, y la más especulativa, es portar tu propio runtime de inferencia. Si sos el tipo de persona que en meta-muse-glimmer-30b-agente-local-que-siempre-esta-ahi se preguntó "qué pasa si corro un modelo de 30B en hardware que no es Apple Silicon ni NVIDIA", Mojo te da un lenguaje donde escribir ese runtime es razonable. Antes era un proyecto en C++ o CUDA; ahora es un proyecto en un lenguaje con mejor tooling y un compilador que podés inspeccionar.
El caveat importante: Mojo no es todavía un superset de Python. La promesa original era esa, y Modular pivoteó. Si tenías código Python esperando migrar tal cual, no va a funcionar. La migración asistida por IA funciona razonablemente bien según reportes del thread, pero no esperes drop-in compatibility.
La pregunta que importa para los que seguimos este blog
Mojo importa acá por una razón concreta, que conecta varias historias que ya cubrimos. Si la promesa de "escribir una vez, correr en cualquier acelerador" se cumple, el costo de mover un modelo entre hardware deja de ser un proyecto de semanas y pasa a ser una decisión de runtime. Eso cambia el cálculo de tokenpocalypse-costo-coding-agents-4-palancas: si podés rutear el mismo modelo entre una GPU local, un TPU rented y un Trainium spot según precio del momento, la optimización de costos deja de ser "qué modelo uso" y pasa a ser "dónde corre".
También cambia la conversación sobre el monopolio de NVIDIA en inferencia. Cerebras (cerebras-gpt-5-6-sol-ultrafast-750-tokens-segundo) está empujando hardware alternativo, pero el problema de Cerebras era siempre el lock-in: si escribís para WSE, no podés moverte a otra cosa. Si MAX cumple lo que dice, ese lock-in se rompe. Y la presión competitiva sobre NVIDIA pricing de inferencia se vuelve real.
Mi opinión, después de leer todo: vale la pena mirarlo, no instalarlo todavía. Mojo 1.0 bajo Apache 2.0 cambia el cálculo de "puedo confiar en que el lenguaje va a existir en cinco años" — eso ya estaba respondido. Lo que todavía no está respondido es "el lenguaje va a tener tracción real o va a quedar en el nicho de kernel writers con tiempo libre". El termómetro va a ser GitHub: stars, contributors externos, issues respondidos, RFCs abiertos. Si en seis meses esos números se ven sanos, Mojo se vuelve un actor real en el stack de inferencia. Si no, se vuelve un proyecto interesante que Qualcomm mantiene con presupuesto y nadie usa.
El repo en GitHub está abierto. El blog post de Modular tiene los detalles completos. Y si querés leer el ángulo opuesto — por qué hay que ser escéptico — el thread de HN tiene de los dos lados en cantidades parejas.