Google Gemma 4 corre nativo en iPhone: lo probé y la brecha entre 'funciona' y 'es útil' sigue siendo enorme

En 2005, cuando administraba el cyber café, tuve mi primer contacto real con la brecha entre que algo funcione y que algo sirva. Instalé un proxy cache para optimizar el ancho de banda. Corría perfecto. Los logs mostraban hits. Y sin embargo, los pibes seguían quejándose de que el Counter-Strike laggueaba igual. La solución técnica estaba, pero el problema real — latencia de juego en tiempo real — no lo resolvía ni de cerca.

Cuando leí que Gemma 4 corre nativo en iPhone con inferencia completamente offline, lo primero que hice fue intentar replicarlo. Tengo un iPhone 13 con 128GB casi llenos — fotos del perro, builds de Xcode que olvidé borrar, tres versiones de TestFlight de proyectos propios. No exactamente el hardware ideal. Pero bueno.

Spoiler: funciona. Y la historia de por qué eso no es suficiente es exactamente la misma historia de toda la inferencia local en mobile desde que existe.

LLM on-device en iPhone: qué es lo que Google realmente logró

Gemma 4 es la cuarta generación de la familia de modelos open source de Google. Lo que cambió ahora es la distribución del modelo en variantes cuantizadas lo suficientemente pequeñas como para correr en hardware móvil ARM con Neural Engine — específicamente los chips A-series de Apple.

El setup usa MediaPipe LLM Inference API, que Google liberó para iOS, y un modelo Gemma 4 en formato cuantizado INT4 o INT8 dependiendo de la variante. El peso total del modelo que termina en el dispositivo ronda los 2GB para la variante más chica. Nada trivial cuando tu teléfono tiene 4GB de RAM compartida entre sistema operativo, apps y el propio modelo.

Lo que hace esto técnicamente interesante no es que un LLM corra en mobile — eso pasó antes, con variantes de LLaMA y Mistral. Lo que cambia es:

1. El soporte oficial de Google — que trae tooling serio, no un port experimental de fin de semana
2. La integración con MediaPipe — que ya tiene infraestructura madura para inference en edge
3. El timing — que llega justo cuando Apple está bajo presión máxima por quedarse atrás en IA

Cómo lo repliqué (con todo lo que salió mal)

Primer intento: seguir la documentación oficial de MediaPipe para iOS. El setup básico requiere un proyecto Xcode con MediaPipeTasksGenAI como dependencia SPM:

// Package.swift — agregar la dependencia de MediaPipe
.package(
    url: "https://github.com/google/mediapipe",
    // Verificá la versión más reciente antes de usar esto
    from: "0.10.14"
),

El modelo en sí lo descargás desde Hugging Face — la variante gemma-4-it-gpu-int4 es la que probé. Son 1.8GB de descarga. Con mi conexión de casa, eso tardó exactamente el tiempo justo para que me arrepienta a la mitad y siga igual.

Una vez que tenés el modelo en el bundle (o en un path local), la inicialización es sorprendentemente limpia:

import MediaPipeTasksGenAI

// Configurar opciones del LLM
let options = LlmInference.Options(modelPath: modelPath)
options.maxTokens = 1024
// maxTopK controla la diversidad de respuestas
options.maxTopK = 40

// Inicializar la inferencia — esto tarda varios segundos
let llmInference = try LlmInference(options: options)

// Generar respuesta
let result = try llmInference.generateResponse(
    inputText: "Explicá qué es un transformer en 3 líneas"
)
print(result)

Primer problema real: el tiempo de carga del modelo. En mi iPhone 13, inicializar el contexto del modelo tarda entre 8 y 12 segundos. No es un número que podés esconder detrás de un spinner de "estamos procesando tu consulta". Es una eternidad en términos de UX móvil.

Segundo problema: la velocidad de generación. La variante INT4 genera alrededor de 8-12 tokens por segundo en mi hardware. Para texto corto, eso es aceptable. Para cualquier respuesta que necesite más de 200 tokens, estás mirando el cursor parpadeante durante 20 segundos. El usuario promedio cierra la app en 10.

Tercer problema — y este es el más interesante — la calidad de respuesta en ese tamaño de modelo. Gemma 4 en variante cuantizada para mobile no es el mismo Gemma 4 que corré en un servidor con una A100. La cuantización, el recorte de contexto, las optimizaciones para memoria baja: todo eso se paga en calidad. No dramáticamente, pero sí lo suficiente como para que la experiencia se sienta como hablarle a un asistente que tomó un somnífero.

El gap real: entre 'corre' y 'es útil para algo concreto'

Acá es donde la historia se pone interesante, porque esto no es único de Gemma 4 ni de iPhone. Es la historia de toda la inferencia local en dispositivos desde que empezamos a intentarlo.

El problema no es técnico en el sentido clásico. Los números están ahí — el modelo corre, genera tokens, no crashea. El problema es que los casos de uso que justifican tener un LLM embebido en una app mobile son exactamente los casos de uso que más sufren con las limitaciones de hardware:

• Asistentes conversacionales: necesitás contexto largo y velocidad de respuesta rápida. Ambas cosas están limitadas.
• Procesamiento de texto offline: acá el caso de uso es más fuerte — tomar notas y resumirlas sin internet, por ejemplo. Con 8-12 tokens/seg y respuestas de calidad razonable, esto empieza a tener sentido.
• Code completion offline: olvidate. Para eso necesitás un modelo más grande con training específico en código.
• RAG sobre documentos locales: este es el caso más prometedor. Si combinás inferencia local con un MCP server bien configurado, la privacidad del dato local se vuelve un argumento concreto.

Lo que me quedó claro después de dos días jugando con esto: los casos de uso donde la inferencia local en mobile realmente gana son los casos donde el modelo no necesita ser muy inteligente — clasificación de texto, extracción de entidades, sentiment analysis simple. Para eso, hay soluciones más eficientes que un LLM de 2GB.

Para los casos donde necesitás inteligencia real, los tokens por segundo no alcanzan todavía.

Lo que esto le hace al argumento de Apple como rezagada de IA

Acá está lo verdaderamente interesante de este momento.

Apple viene siendo martillada por analysts, por la prensa tech, por usuarios, por todos — diciendo que se quedó atrás en IA. Siri es una vergüenza comparada con Gemini o ChatGPT. Apple Intelligence llegó tarde y con menos features de las prometidas. El chip A-series tiene Neural Engine desde el A11, pero lo subutilizaron durante años.

Y ahora Google — no Apple — es quien demuestra que el hardware de Apple corre inferencia local seria.

Eso es un movimiento estratégico interesante. Google básicamente dice: "el hardware que vos vendiste durante años es suficientemente bueno para lo que nosotros construimos". Apple queda en una posición incómoda donde su propio silicio está siendo usado como argumento para el ecosistema de un competidor.

Al mismo tiempo, esto presiona a Apple a mostrar qué puede hacer con control total del stack — algo que Google no tiene. Si alguien debería poder optimizar inferencia local en iPhone mejor que nadie, es Apple. Tienen el compilador, el runtime, el hardware y el sistema operativo.

Lo que estamos viendo es básicamente Google forzando la mano. Y para los que construimos software, eso significa que la window para que Apple ignore esto se está cerrando rápido.

También me hace pensar en algo que escribí cuando estaba optimizando imágenes Docker para producción: el tamaño importa, pero importa en relación a lo que te da. Un modelo de 2GB que genera 10 tokens/seg tiene que justificar ese costo con casos de uso que genuinamente no pueden ir a la nube. Privacidad. Offline. Latencia cero de red.

Esos casos existen. Pero son menos de los que el hype implica.

Errores comunes cuando intentás esto

Error 1: Bajarte el modelo más grande disponible

Hay variantes más grandes de Gemma 4. En iPhone, no las uses. El límite de memoria para una app en iOS en condiciones normales está cerca de 3-4GB antes de que el sistema empiece a matar procesos. Un modelo grande te come todo ese espacio y el sistema operativo te mata la app antes de que termines de cargar.

Error 2: No manejar el tiempo de carga como ciudadano de primera clase

El onboarding del modelo tiene que pasar en background, con estado persistente. No podés inicializar el contexto en cada request. Cargalo una vez, mantené el estado, y si el sistema te mata por memoria, cargalo de nuevo con una UI que lo comunique. Si sobreingeniás la arquitectura del agente antes de resolver este problema básico, vas a construir algo que nunca es usable.

Error 3: Esperar calidad de API cloud

El modelo cuantizado para mobile no es el mismo modelo. Bajá las expectativas de calidad un escalón y diseñá prompts más directivos, con menos ambigüedad, y contextos más cortos. La diferencia entre un prompt bien diseñado para mobile inference y uno genérico puede ser enorme.

Error 4: No medir tokens/seg en tu target device

Cada generación de chip es distinta. Lo que corre bien en un iPhone 15 Pro puede ser inutilizable en un iPhone 12. Medí en el hardware más limitado de tu target audience antes de comprometerte con la feature.

// Medir velocidad de generación — útil para decidir si el modelo es viable
let startTime = Date()
var tokenCount = 0

// Generar con callback para contar tokens
try llmInference.generateResponseAsync(
    inputText: prompt
) { partialResult, error in
    if let partial = partialResult {
        // Aproximación: contar palabras como proxy de tokens
        tokenCount += partial.split(separator: " ").count
    }
}

let elapsed = Date().timeIntervalSince(startTime)
let tokensPerSec = Double(tokenCount) / elapsed
print("Velocidad aproximada: \(tokensPerSec) tokens/seg")

FAQ — Preguntas frecuentes sobre LLM on-device en iPhone

¿Qué iPhone mínimo necesitás para correr Gemma 4 offline?
La guía oficial de Google indica compatibilidad desde iPhone 12 en adelante, que tiene chip A14 Bionic con Neural Engine de 16 núcleos. En la práctica, la experiencia de uso es significativamente mejor desde iPhone 14 para arriba. En iPhone 12 y 13, los tiempos de carga y la velocidad de generación son los cuellos de botella más notorios.

¿Cuánto espacio ocupa Gemma 4 en el dispositivo?
La variante cuantizada INT4 para mobile ocupa aproximadamente 1.8GB en disco. A eso sumale el runtime de MediaPipe y tu propia app. Estás hablando de cerca de 2.2-2.5GB de espacio adicional en el dispositivo. No es trivial para usuarios con 64GB o 128GB casi llenos — como yo.

¿Los datos salen del dispositivo con inferencia local?
No. Esa es la promesa core de on-device inference: el texto que le mandás al modelo y las respuestas que genera nunca salen del hardware. No hay llamadas a ningún servidor. Para casos de uso con datos sensibles — notas médicas, documentos legales, conversaciones privadas — este es el argumento más fuerte a favor de la inferencia local.

¿Vale la pena frente a simplemente llamar a la API de Gemini?
Depende estrictamente del caso de uso. Si el usuario necesita internet de todas formas para usar tu app, la API cloud da mejor calidad, más velocidad y cero overhead de storage. On-device tiene sentido cuando: a) la privacidad del dato es crítica, b) el caso de uso es genuinamente offline, o c) querés cero latencia de red para interacciones muy cortas y simples.

¿Esto funciona en Android también?
Sí, y en Android el story es incluso más fragmentado. MediaPipe LLM Inference API soporta Android, pero la variedad de chipsets (Qualcomm, MediaTek, Google Tensor) hace que el performance varíe mucho más que en el ecosistema controlado de Apple. En Pixel 8 con Tensor G3 los números son similares a iPhone 13.

¿Qué tan diferente es de Core ML de Apple?
Core ML es la framework de Apple para ML on-device, pero está diseñada principalmente para modelos de inferencia específica (clasificación de imágenes, NLP acotado, detección de objetos) — no para LLMs generativos. Apple Foundation Models en iOS 18 es el equivalente directo, pero el acceso está limitado y los modelos son propietarios. MediaPipe con Gemma 4 es la primera opción open source y con control total del modelo para iOS.

Conclusión: el hardware ganó la carrera que el software todavía no terminó

Que Gemma 4 corra nativo en iPhone es un hito técnico real. No es hype vacío. Los números están, el código corre, y los casos de uso concretos — aunque más acotados de lo que el título sugiere — existen.

Pero lo más importante de este momento no es el modelo. Es que estamos llegando al punto donde el hardware de los teléfonos que ya existen en los bolsillos de la gente es suficiente para inferencia local seria. Eso cambia el conversation sobre privacidad, sobre dependencia de cloud, sobre qué tipo de apps son posibles sin internet.

Y le pone una presión enorme a Apple para mostrar qué puede hacer cuando controla cada capa del stack. Si Google puede hacer esto con acceso limitado al hardware, imaginate lo que Apple debería poder hacer con acceso total.

Yo sigo con mi iPhone 13 con 128GB casi llenos y Gemma 4 instalado en un proyecto de Xcode que probablemente no llegue a producción. Pero la próxima vez que diseñe una rutina de automatización que procese texto sensible, voy a evaluar on-device antes de mandar datos a un servidor externo.

El gap entre 'corre' y 'es útil' sigue existiendo. Pero se está cerrando más rápido de lo que esperaba.

Si lo probaste en tu hardware, contame los números que te dieron — los tokens/seg varían bastante por generación de chip y me interesa armar un dataset propio de performance real.