IA en el dispositivo en teléfonos: la realidad de los 4 tok/s

Tu teléfono puede ejecutar un modelo de lenguaje grande dentro de una pestaña del navegador. Sin servidor, sin clave de API y sin que ningún texto salga del dispositivo.

Así se ve eso en septiembre de 2026: de 4 a 9 tokens por segundo en teléfonos Android de gama alta. Una espera de 76 segundos para el primer token con un prompt largo. Pestañas que se recargan a mitad de la generación sin un error que puedas capturar. Y una detección de funciones que reporta compatibilidad completa con WebGPU en dispositivos que no completan ninguna ejecución de inferencia.

Este artículo presenta el estudio móvil completo detrás del resumen de una sección en LLM en el navegador + WebMCP + MCP UI: el futuro stack de frontend. La misma tesis, con toda la evidencia. Encontrarás una matriz de benchmarks de dispositivos × modelos × longitudes de prompt, las cinco formas en que fallan los teléfonos y el patrón de validación por calentamiento que convierte «¿existe WebGPU?» en «¿este teléfono realmente puede hacerlo?».

En resumen

• La inferencia en navegadores móviles funciona dentro de límites estrechos. Los modelos de clase 3B alcanzan ~4–5 tok/s en decode en el Pixel 7 (enero de 2024) y el Pixel 8 Pro (enero de 2026). Un modelo 1B alcanza ~9–10 tok/s en el Pixel 8a (junio de 2026) y 34 tok/s en el iPhone 17 Pro Max con un motor diseñado específicamente para ello (marzo de 2026).
• La diferencia generacional domina sobre todo lo demás. Un iPhone 11 Pro Max (2019) no completa ninguna ejecución de inferencia; un iPhone 17 Pro Max (2025) vuela. La antigüedad del chip importa más que la versión del sistema operativo.
• La detección de funciones miente en teléfonos. Un iPhone que reporta webgpu: true con soporte para f16, un Pixel cuyo navegador integrado en una app reporta un límite completo de 4 GB y GPU Adreno que pasan todas las comprobaciones aun así fallan en ejecuciones reales. Haz benchmarks; nunca te limites a detectar.
• El contexto largo es lo que mata el rendimiento móvil, no la velocidad de decode. El prefill se ejecuta a ~5–15 tok/s en teléfonos, así que el tiempo hasta el primer token se dispara más allá de ~200 tokens de entrada: 76–77 segundos con 1,200 tokens frente a ~3.8 segundos con 52.
• El patrón para producción es una validación por calentamiento. Carga el modelo de prueba más pequeño, ejecuta una inferencia mínima con tiempo medido y dirige la solicitud al nivel local completo, al nivel local ligero (solo prompts cortos) o al fallback de servidor. Decide el TTFT medido, no el user agent.
• Alcance de WebGPU móvil en septiembre de 2026: Android 12+ en Chrome 121+ (enero de 2024) con GPU Qualcomm, ARM, Intel e Imagination; se espera soporte para Samsung Xclipse alrededor de Chrome 154. Safari 26 lo habilita por defecto (septiembre de 2025). Firefox Android todavía lo mantiene detrás de una flag.

Qué aprenderás aquí

• La matriz completa de benchmarks móviles: qué dispositivos, modelos y longitudes de prompt realmente funcionan en una pestaña del navegador de un teléfono.
• Qué abarca «WebGPU móvil» en septiembre de 2026 y dónde están las brechas.
• Los cinco modos de falla específicos de los teléfonos, con sus síntomas y mecanismos.
• El patrón de validación por calentamiento: flujo de decisión, umbrales y un fragmento ejecutable.
• Cómo ejecutar evals móviles correctamente: diseño de la matriz, disciplina térmica y cuidado con las descargas en conexiones con datos medidos.
• Qué modelos caben en una pestaña de teléfono y qué conviene construir, prototipar o posponer.

La matriz de benchmarks: lee esto primero

Cada cifra de abajo corresponde a una ejecución medida en el navegador de un teléfono real, con su fecha y fuente. Las metodologías varían —estadísticas usage de WebLLM frente a medición de tiempo transcurrido, caché fría frente a caliente, cuantización Q4 frente a Q8—, así que toma estas cifras como referencia de orden de magnitud y luego mide tu propia matriz.

Dos filas merecen una aclaración antes de seguir. Las cifras del iPhone 17 Pro Max provienen de pruebas en dispositivos reales mediante LambdaTest, con un motor WGSL de 18 shaders diseñado específicamente para ello y cuantización Q8. Es impresionante, pero se trata de una sola fuente con un stack personalizado, no de un resultado con un motor estándar. La fila de Firefox en escritorio (~1 tok/s frente a ~52 en Chrome para el mismo modelo) está ahí para ilustrar un punto al que volveremos en este artículo. En todas las plataformas, el navegador y el motor con los que mides importan tanto como el chip.

Qué significa «WebGPU móvil» en septiembre de 2026

WebGPU es la única vía para ejecutar inferencia de LLM acelerada por GPU en el navegador de un teléfono: WebLLM funciona exclusivamente con WebGPU, y las rutas rápidas de Transformers.js y wllama también lo necesitan. Esta es la situación por plataforma, según fuentes primarias:

Dos notas sobre el ecosistema completan el panorama. Primero, Transformers.js v4 (9 de febrero de 2026) reescribió su runtime de WebGPU en C++ con soporte para 200+ arquitecturas. Pero sus propias notas de cobertura señalan que la experiencia móvil «todavía es irregular» y recomiendan un fallback a WASM como la opción realista para llegar a un público amplio. La guía oficial de WebGPU todavía advierte que el comportamiento móvil fuera de Chromium es experimental. Segundo, un proyecto comunitario llamado web-ai-bench está construyendo, con aportes de la comunidad, la matriz de compatibilidad WebNN frente a WebGPU frente a WASM que le falta al ecosistema: vale la pena seguirlo y contribuir con los resultados de tu teléfono.

Mi conclusión: la API ya está disponible en términos generales en los dos motores que importan (Chromium Android, WebKit iOS). Todo lo difícil ahora está por encima de la API: drivers, presupuestos de memoria, límites térmicos y entornos anfitriones que reportan capacidades que no pueden cumplir.

Cómo leer la matriz: cinco lecciones

1. La diferencia generacional pesa más que la versión del sistema operativo. El iPhone 11 Pro Max ejecuta Safari 26 y reporta WebGPU con f16, pero no completa nada. El iPhone 17 Pro Max ejecuta la misma familia de sistemas operativos y procesa el decode de un modelo 1B a 34 tok/s. En Android la evolución es menos marcada, pero consistente: el decode de modelos de clase 3B se mantuvo en el rango de 4–5 tok/s desde el Pixel 7 (enero de 2024) hasta el Pixel 8 Pro (enero de 2026). El progreso vino de modelos más pequeños y mejores motores, no de GPU de teléfonos que se hayan vuelto mucho más rápidas para esta carga. Segmenta tu estrategia móvil por generación de chip, no por número de versión del sistema operativo.

2. El prefill es la barrera; el decode marca el mínimo. La comparación entre el Pixel 8 Pro y una PC en web-llm #759 es el ejemplo más claro. El prefill cae ~20× (111 → 5.4 tok/s). El decode baja solo ~3× (18 → 5 tok/s). Esa asimetría explica por qué el TTFT se dispara con la longitud del prompt, mientras que el streaming, una vez que empieza, se siente simplemente lento. Regla de diseño: administra los tokens del prompt como si fueran dinero y transmite cada token que generes.

3. La elección del motor es un multiplicador, no un detalle. Las pruebas entre motores de Ludion encontraron que el mismo modelo en el mismo hardware variaba varias veces en rendimiento según el motor. web-llm #524 reporta que Gemma 2 2B y Phi 3 Mini cierran la pestaña con WebLLM, mientras que los pesos .gguf de la misma clase sí se ejecutan con wllama, aunque «a paso de tortuga», en palabras de quien reportó el problema. Y el motor personalizado webgpu-gemma alcanza 34 tok/s donde los motores estándar logran ~9 en chips Apple comparables. Si tus cifras decepcionan, cambia de motor antes de culpar al teléfono.

4. La elección del navegador influye más de lo que admiten las publicaciones de benchmarks. Firefox con ~1 tok/s frente a Chrome con ~52 en el mismo M3 (Llamas on the Web, mayo de 2026; resultados interactivos en el sitio del benchmark) es la versión de escritorio del bloqueo del navegador integrado de LINE. En teléfonos ocurre lo mismo: Chrome 149 en el Pixel 8a completa ejecuciones que se bloquean en el navegador integrado del mismo dispositivo. «Funciona en el navegador» no es una afirmación sobre la plataforma web: es una afirmación sobre una compilación concreta de un navegador con un driver de GPU concreto.

5. Compara las cuantizaciones de forma explícita o no las compares. Las llamativas cifras del iPhone corresponden a Q8_0; la mayoría de las cifras de WebLLM en teléfonos usan variantes Q4. Una cuantización diferente implica distinto tráfico de memoria, distinta calidad y distintos tamaños de descarga (~1 GB para el 1B Q8 frente a una descarga de alrededor de ~700 MB para modelos 1–1.5B Q4). Toda tabla de benchmarks que publiques —incluida la de este artículo— debe incluir la columna de cuantización, o los lectores compararán puntos que no son comparables.

Por qué fallan los teléfonos de esta manera

La inferencia en escritorio falla con mensajes de error. En teléfonos falla con recargas, bloqueos y páginas de «Aw Snap». Estos son cinco modos de falla, cada uno con su síntoma y mecanismo:

1. Cierre de la pestaña por OOM. El caso clásico. El mecanismo de Android para terminar procesos por falta de memoria cierra Chrome a mitad de la inferencia (el adb logcat en web-llm #209 muestra que lmkd termina el proceso de renderizado para liberar ~5 GB de RSS), o se pierde el dispositivo GPU a mitad de la ejecución. WebLLM 0.2.36 aprendió a capturar errores OOM de createBuffer() (PR #402, mayo de 2024). Pero los ámbitos de error y device.lost resultaron poco confiables antes del cierre: Chrome sigue pidiendo memoria hasta que la pestaña muere. Trata la muerte del proceso como un resultado normal y diseña un mecanismo de recuperación, no solo manejo de errores.

2. Recarga silenciosa (iOS). En el iPhone 11 Pro Max, Llama-3.2-1B llegó a la generación con el backend de WebGPU y luego la página se recargó a mitad del proceso: sin excepción visible en JavaScript y sin un OOM que se pudiera capturar. El modelo más pequeño Qwen2.5-0.5B, mediante wllama, provocó una recarga durante la inicialización. No se completó ninguna ejecución con ninguno de los motores y modelos. Tu telemetría de errores no mostrará nada; solo el seguimiento de ejecuciones completadas detecta este caso.

3. Bloqueo en un navegador integrado en una app. El Pixel 8a en el navegador integrado de LINE reportó webgpu: true, un adaptador Arm Valhall con f16 y el límite completo de 4 GB por buffer. Esos límites son idénticos a los de la ejecución en Chrome que sí se completó en el mismo teléfono. El navegador integrado se bloqueó en todas las ejecuciones. Nada en los límites del adaptador permitía distinguir una configuración viable de una que no lo era. Este es el argumento más contundente a favor de la validación por calentamiento que veremos más abajo.

4. Falla del driver. En GPU Qualcomm Adreno —la familia de GPU dominante en Android—, WebLLM 0.2.84 falla al inicializar el motor con VK_ERROR_DEVICE_LOST incluso para modelos de 0.5B–1B (web-llm #836). Quien reportó el problema señala que 0.2.79 funcionaba mientras que 0.2.80+ falla (0.2.80 trasladó trabajo de CPU a kernels de GPU), lo que hace que el problema dependa de la versión y no solo del hardware. Fija la versión del motor y vuelve a probar cada vez que la actualices.

5. Muerte del worker durante la suspensión. Cuando un teléfono entra en suspensión, puede terminar el Web Worker que mantiene cargado tu modelo. El frontend todavía cree que el modelo está cargado, así que la siguiente inferencia falla con «a valid external Instance reference no longer exists» (web-llm #524). WebLLM corrigió esto para service workers (PR #471) y luego para web workers (PR #533, npm 0.2.56), recargando cuando el estado del backend y el frontend no coincide. De todos modos, diseña para la recarga: vuelve a verificar el estado del modelo después de visibilitychange.

Vale la pena mencionar una medida de mitigación. ggml-webgpu PR #21533 (abril de 2026) limita los buffers de comandos en curso en iOS, donde de otro modo falla el backend de WebGPU. Un bug de WebKit relacionado hace seguimiento de si ese límite es el comportamiento esperado. Los autores de motores están ajustando cada plataforma; tu trabajo es mantenerte al día y volver a medir.

La validación por calentamiento: mide, no supongas

El patrón se desprende de todo lo anterior. Tu comprobación de disponibilidad debe ser ejecutar una inferencia mínima y medir su tiempo, no leer un límite del adaptador. Ludion aplica esta idea como una política de enrutamiento con seis reglas derivadas de 54 ejecuciones archivadas en cinco configuraciones de dispositivos (política). Los navegadores integrados en apps, los entornos sin WebGPU y iOS WebKit se dirigen al servidor. En escritorio se permite ampliamente la ejecución local. Android Chromium solo se permite para prompts cortos (≤200 tokens) con streaming, y los entornos desconocidos se dirigen al servidor por defecto. El siguiente fragmento —basado en CreateMLCEngine de WebLLM— aplica la misma idea como una prueba por sesión:

flowchart TD
    Start["El usuario accede a la función de IA"] --> GPU{"¿navigator.gpu + requestAdapter?"}
    GPU -- "no" --> Server["nivel: servidor — LLM en la nube"]
    GPU -- "sí" --> Load["Cargar el modelo de prueba más pequeño"]
    Load --> Warm["Calentamiento cronometrado: prompt mínimo, límite de 30s"]
    Warm -- "falla / tiempo agotado" --> Server
    Warm -- "TTFT menor de 8s" --> Full["nivel: completo — inferencia local"]
    Warm -- "TTFT mayor de 8s" --> Lite["nivel: ligero — solo prompts cortos"]
    Full --> Re["Volver a probar tras un cierre, suspensión o actualización"]
    Lite --> Re
    Server --> Re

// Warmup gate for WebLLM — measure TTFT on a tiny prompt before enabling features.
// Run once per session (ideally after a user gesture); cache the verdict.
import { CreateMLCEngine } from "@mlc-ai/web-llm";

const WARMUP_MODEL = "SmolLM2-360M-Instruct-q0f16-MLC"; // smallest viable probe; confirm in prebuiltAppConfig for your version
const WARMUP_TIMEOUT_MS = 30000;
const FULL_TIER_TTFT_MS = 8000;

export async function probeLocalTier() {
  if (!navigator.gpu) return { tier: "server", reason: "no-webgpu" };
  const adapter = await navigator.gpu.requestAdapter().catch(() => null);
  if (!adapter) return { tier: "server", reason: "no-adapter" };
  // Adapter limits are advisory only: phones reporting full ceilings have
  // failed every inference run (Ludion, June 2026). The timed warmup is the check.
  const engine = await CreateMLCEngine(WARMUP_MODEL, { logLevel: "WARN" });
  const t0 = performance.now();
  const timeout = setTimeout(() => engine.interruptGenerate?.(), WARMUP_TIMEOUT_MS);
  try {
    const stream = await engine.chat.completions.create({
      messages: [{ role: "user", content: "Reply with exactly: OK" }],
      max_tokens: 8,
      stream: true,
    });
    for await (const chunk of stream) {
      const ttft = performance.now() - t0; // first chunk received = TTFT
      clearTimeout(timeout);
      await engine.unload?.();
      if (ttft > WARMUP_TIMEOUT_MS) return { tier: "server", reason: "warmup-timeout" };
      return ttft < FULL_TIER_TTFT_MS
        ? { tier: "full", ttftMs: Math.round(ttft) }
        : { tier: "lite", ttftMs: Math.round(ttft), maxPromptTokens: 200 };
    }
  } catch (err) {
    return { tier: "server", reason: `warmup-failed:${err?.name ?? "error"}` };
  }
  return { tier: "server", reason: "warmup-empty" };
}

Tres notas de diseño. Primero, el umbral de 8 segundos para el nivel completo y el límite de 200 tokens para el nivel ligero son puntos de partida basados en los datos medidos (Pixel 8a: ~3.8s de TTFT con 52 tokens, inutilizable con 1,200). Calíbralos según el tiempo que los usuarios de tu tarea estén dispuestos a esperar, no el mío. Segundo, la prueba también sirve para calentar los shaders. La primera inferencia después de la carga tarda 2–3× más mientras WebGPU compila los shaders. Una validación que solo compruebe navigator.gpu tanto admitiría dispositivos que no funcionan como mediría mal el tiempo debido a los shaders fríos. Tercero, vuelve a probar ante los eventos que cambian el resultado: cierre de la pestaña, regreso de suspensión, actualización de la versión del motor y cambio de modelo.

Medir bien: metodología de evals móviles

Si la validación por calentamiento es el patrón en tiempo de ejecución, esta es su contraparte durante el desarrollo: la matriz que te dice qué niveles ofrecer. La serie de evals del artículo principal cubre conjuntos de tareas de referencia, puntuación con rúbricas y LLM como juez: consúltala para conocer el método de evaluación de calidad. Esta sección trata del método para medir rendimiento en teléfonos, donde todo lo que es una nota al pie en escritorio se convierte en el tema principal.

Ejecuta una matriz de dispositivos × modelos × longitudes de prompt. El mínimo viable es tres dispositivos (un Android de gama media, un Android de gama alta y un iPhone con iOS 26+) × dos modelos (0.5B y 1B; agrega 3B solo para dispositivos de gama alta) × dos longitudes de prompt (~50 y ~1,200 tokens). Agrega un segundo motor si puedes (WebLLM más wllama o Transformers.js). Las 54 ejecuciones de Ludion en cinco configuraciones de entorno, con caché fría para ambas longitudes de prompt, son la plantilla que conviene seguir (repositorio).

Registra el TTFT para ambas longitudes: es la cifra que predice la viabilidad. El tiempo hasta el primer fragmento transmitido con ~50 tokens te dice si la función se siente ágil. El TTFT con ~1,200 te dice si siquiera puedes ofrecer contexto largo. Este fragmento es todo el instrumento de medición:

// Record TTFT at 50 and 1200 input tokens — the two numbers that predict viability.
// engine: a loaded WebLLM MLCEngine; prompts: your own short/long fixtures.
async function measureTtftCurve(engine, shortPrompt, longPrompt) {
  const run = async (prompt) => {
    const t0 = performance.now();
    const stream = await engine.chat.completions.create({
      messages: [{ role: "user", content: prompt }],
      max_tokens: 32,
      stream: true,
    });
    for await (const chunk of stream) return performance.now() - t0; // first chunk
  };
  const ttftShort = await run(shortPrompt); // ~50 tokens
  await new Promise((r) => setTimeout(r, 5000)); // cool-down: thermals skew back-to-back runs
  const ttftLong = await run(longPrompt); // ~1200 tokens
  return { ttftShortMs: Math.round(ttftShort), ttftLongMs: Math.round(ttftLong) };
}

Trata los cierres y las recargas como resultados de primera clase, no como datos faltantes. Una ejecución que recarga la pestaña es un cero, no un N/A: las «0 filas exitosas» del iPhone 11 Pro Max son la celda más informativa del conjunto de datos de Ludion. Registra la tasa de finalización junto con los tok/s o tus promedios mentirán por sesgo de supervivencia.

Mantén disciplina térmica. Los teléfonos reducen su rendimiento bajo carga sostenida de GPU. Deja que se enfríen entre ejecuciones (la metodología de WebGPU frente a WASM de SitePoint exige un período de enfriamiento entre suites). Aleatoriza el orden de las ejecuciones y regístralo. Un modelo 3B que obtiene 5 tok/s en frío y 3 tok/s en caliente te está hablando del chasis, no de los pesos.

Respeta las conexiones con datos medidos. Un modelo 1.5B requiere una descarga de ~728 MB (la cifra de Ludion para Qwen2.5-1.5B); el 1B Q8 requiere ~1 GB y usa ~1.5 GB de memoria de GPU (gemma-webgpu). Aprovecha la caché al máximo (tanto WebLLM como wllama almacenan los pesos localmente), advierte antes de la primera descarga, ofrece opciones para usar solo Wi-Fi y estudia la transmisión de capas mediante solicitudes Range. Esta descarga fragmentos de pesos de ~44 MB y libera memoria de JS a medida que los subes a la GPU. Mantiene el pico de memoria de JS cerca de 50 MB en iPhones.

Depura en el dispositivo y registra el entorno. Android: chrome://inspect con depuración USB. iOS: Safari Web Inspector por cable. Para cada dispositivo, registra el volcado de chrome://gpu (o equivalente) y un reporte del adaptador de webgpureport. La versión del driver y los límites reportados son la única forma de entender las cifras seis meses después.

Qué modelos caben en una pestaña de teléfono

Los cálculos de memoria deciden antes que los benchmarks. Presupuestos aproximados, con la atribución que merece cada fila:

Las filas marcadas como «estimación» son mi síntesis de cierres y ejecuciones exitosas reportadas, no especificaciones del fabricante. WebLLM expone metadatos vram_required_MB y buffer_size_required_bytes por modelo: léelos en tiempo de ejecución en lugar de confiar en cualquier tabla. Dos notas estructurales. Primero: las variantes de modelos -1k de WebLLM existen porque los dispositivos con maxStorageBufferBindingSize de 128 MB (de la clase del Galaxy S23, web-llm #209; validación implementada en PR #256) no pueden direccionar asignaciones más grandes por buffer. La longitud del contexto es una cuestión de organización de memoria antes que de calidad. Y la caché KV crece con el contexto, así que cada 1k adicional de prompt se paga dos veces: una en tiempo de prefill y otra en memoria que puede provocar la recarga incluso en un teléfono de gama alta.

El modelo que conviene seguir es Gemma 3n (guía para desarrolladores, 26 de junio de 2025). Es una familia de modelos con pesos abiertos diseñada primero para móviles, con submodelos anidados MatFormer (E4B contiene E2B; inferencia hasta 2× más rápida en el submodelo). Los embeddings por capa mantienen solo ~2B/4B parámetros en la memoria del acelerador (huella de 2 GB/3 GB), y compartir la caché KV proporciona mejoras de 2× en prefill. La guía incluye transformers.js entre las herramientas compatibles, pero hasta septiembre de 2026 no hay cifras publicadas de su ejecución en navegadores de teléfonos. Clasifícalo como «lo más probable que cambie esta tabla», no como «listo para producción hoy».

Construir, prototipar o esperar: la edición móvil

Construye ahora: resumen, extracción a JSON y clasificación de entradas cortas, validados mediante calentamiento. Agrega una arquitectura con fallback al servidor donde la pestaña del teléfono sea la ruta rápida, no la única. Agrega un fallback a WASM para embeddings y tareas pequeñas en dispositivos que no pasen la validación. Y ofrece una experiencia de descarga honesta (progreso, advertencias de tamaño y opción de usar solo Wi-Fi). Registra las herramientas de la página una sola vez mediante WebMCP: la inversión para móviles del artículo principal (herramientas primero, modelo después) sigue siendo válida.

Prototipa: chat completamente local en el nivel de gama alta, carga de pesos por streaming con Range y pruebas A/B entre motores (WebLLM frente a wllama frente a Transformers.js v4) en tus dispositivos objetivo reales. Agrega ajustes por generación: lo que vuela en un iPhone de 2025 avanza a paso de tortuga en uno de 2019, así que ofrece valores predeterminados diferentes.

Espera: IA integrada en móviles (solo disponible en escritorio; se creó un prototipo para Android sin fecha de lanzamiento; consulta la tabla del artículo principal). También espera para WebGPU en Firefox Android (detrás de una flag) y para el soporte de Samsung Xclipse (~Chrome 154). Y para cualquier plan que dependa de que los navegadores integrados en apps se comporten como navegadores completos.

Lista de verificación para producción

• Decide según el TTFT medido, nunca según la cadena de UA ni los límites del adaptador. (iOS 26 congela el UA en iPhone OS 18_6: la detección por identidad está rota por diseño).
• Cuenta los cierres y las recargas como resultados; genera alertas ante caídas en la tasa de finalización por clase de dispositivo.
• Vuelve a probar después de salir de suspensión, actualizar el motor, cambiar de modelo o actualizar el navegador.
• Advierte antes de descargas de gigabytes; prioriza la caché; considera streaming con Range por encima de ~500 MB.
• Deja enfriar el dispositivo entre ejecuciones de evals; registra el orden de ejecución, las versiones de drivers y los volcados del adaptador.
• Ofrece una alternativa sin IA: toda función debe funcionar (más lento, del lado del servidor o manualmente) cuando la inferencia local no esté disponible. El argumento de accesibilidad de la serie de evals aplica con el doble de fuerza en teléfonos, donde la tasa de fallas es mayor.
• Instrumenta los resultados de cada nivel (completo / ligero / servidor) en las analíticas del producto: tu validación por calentamiento es un instrumento de medición disfrazado de feature flag.

El verdadero cambio

La frase final del artículo principal fue «recurre primero a la pestaña». Los teléfonos agregan una precisión: recurre primero a la pestaña después de que pase la prueba de calentamiento.

La pestaña de un teléfono es un runtime de inferencia real con un mínimo de 4 tok/s y una capacidad de atención de ~200 tokens. Diseña dentro de esos límites —prompts cortos, salida en streaming, validación basada en mediciones y fallback al servidor— y funciona sin conexión, de forma privada y gratis. Da por hecho que estás en escritorio y la pestaña se recargará sin siquiera dejar una excepción que registrar.

Fuentes

• Notas de campo sobre inferencia en el navegador — informe de Ludion (prueba entre dispositivos de junio de 2026: curva de TTFT del Pixel 8a, ninguna ejecución completada en iPhone 11, bloqueo del navegador integrado de LINE; descarga de Qwen de 728 MB en la justificación de la política v0)
• Ludion-ai/Ludion (54 ejecuciones archivadas, 5 configuraciones, política de enrutamiento R1–R6, cifras de comparación con escritorio)
• La demo de chat no funciona en Android debido a maxStorageBufferBindingSize — web-llm #209 (noviembre de 2023–mayo de 2024: Pixel 7 a 4.4 tok/s, validación de 128MB, modelos -1k, cierres por lmkd)
• Sobre el problema de bajo rendimiento de Chrome en Android — web-llm #759 (3 de enero de 2026: Pixel 8 Pro a 5.1 tok/s, caída del prefill en teléfono frente a PC)
• Gemma 2 2B cierra la pestaña en un teléfono móvil — web-llm #524 (cierre con WebLLM frente a lentitud extrema con wllama, muerte del worker durante la suspensión, correcciones en PR #471/#533)
• Falla la inicialización del motor de WebLLM en GPU Qualcomm Adreno — web-llm #836 (VK_ERROR_DEVICE_LOST en Adreno con modelos de 0.5–1B, dependencia de la versión 0.2.80+)
• Deshabilitar la mayoría de los modelos en teléfonos Android — web-llm PR #256 (enero de 2024: la validación estricta original del tamaño de buffer)
• Capturar el error OOM de WebGPU — web-llm PR #402 (mayo de 2024: captura de OOM de createBuffer(), npm 0.2.36)
• svenflow/webgpu-gemma (13 de marzo de 2026: iPhone 17 Pro Max a 34.4 / 101.1 tok/s mediante LambdaTest)
• gemma-webgpu — npm (streaming mediante solicitudes Range, pico de memoria de JS de ~50 MB, 18 shaders WGSL)
• Llamas on the Web — artículo académico (mayo de 2026: estudio de 16 GPU; el grupo de menor rendimiento incluye iPhones + Adreno/Mali/PowerVR con 4–17 tok/s en decode, solo caben los 4 modelos más pequeños; Firefox ~1 frente a Chrome ~52 en M3)
• Llamas on the Web — benchmark (protocolo de calentamiento antes de medir, advertencia sobre cierre de pestañas en iPhone, WebGPU en el proyecto principal de wllama)
• ggml-webgpu: parametrizar el tamaño de envío y agregar límites específicos para iOS — llama.cpp PR #21533 (3 de abril de 2026: limitación de buffers de comandos en iOS, bug de WebKit 311598)
• Estado de implementación — wiki de gpuweb (estado de disponibilidad de WebGPU por plataforma: fabricantes de Android, Safari 26, flags de Firefox)
• Novedades de WebGPU (Chrome 121) (Android 12+, alcance del lanzamiento para Qualcomm/ARM)
• Actualización de Chrome 121 para Android (fecha de lanzamiento: 23 de enero de 2024)
• Funciones de WebKit en Safari 26.0 (15 de septiembre de 2025: WebGPU habilitado por defecto, cadena de UA de iOS congelada, mención de Transformers.js)
• Intención de lanzamiento: WebGPU en Android — blink-dev (alcance inicial para Adreno/Mali en Android 12+)
• Ejecutar modelos con WebGPU — documentación de Transformers.js (uso de device: "webgpu", advertencia sobre el carácter experimental fuera de Chromium)
• Transformers.js v4 incorpora un runtime de WebGPU (9 de febrero de 2026: runtime en C++, 200+ arquitecturas, «la experiencia móvil todavía es irregular»)
• WebGPU frente a WebASM: benchmarks de inferencia en el navegador — SitePoint (metodología de enfriamiento y niveles de hardware, recomendaciones para fallback a WASM)
• Presentamos Gemma 3n: guía para desarrolladores (26 de junio de 2025: MatFormer, PLE, huella de 2–3 GB, uso compartido de caché KV)
• Construye un chatbot de IA sin conexión con WebLLM y WebGPU — Appwrite (tabla de VRAM por modelo: SmolLM2 380 MB, Phi-3.5 3.7 GB, Llama-3.1-8B 5 GB)
• abhid1234/web-ai-bench (proyecto de matriz WebNN/WebGPU/WASM con aportes de la comunidad)
• Documentación de WebLLM (API del motor: CreateMLCEngine, chat compatible con OpenAI, workers)
• WebLLM — repositorio (motor de LLM en el navegador; solo WebGPU, API compatible con OpenAI)
• Corregir la discrepancia en la recarga del service worker — web-llm PR #471 (recarga del service worker tras una discrepancia de estado durante la suspensión)
• Trasladar la corrección de recarga al web worker — web-llm PR #533 (recarga del web worker tras una discrepancia de estado durante la suspensión, npm 0.2.56)
• Bug 311598 de WebKit — límites de buffers de comandos de WebGPU en iOS (seguimiento para determinar si el límite de envíos en curso en iOS es el comportamiento esperado)
• LLM en el navegador + WebMCP + MCP UI: el futuro stack de frontend (artículo principal: panorama del stack, cifras de escritorio, harness de evals)
• Evaluación de agentes de IA con LangWatch: de impresiones a puntuaciones (metodología de tareas de referencia y rúbricas)
• LLM como juez: evals de aplicaciones de agentes, sesgos y soluciones (puntuación basada en jueces para tareas de prosa)