El modelo on-device de Apple es terrible para chat pero sorprendentemente bueno en structured output y tool calling

| Última modificación: 4 de mayo de 2026 | Tiempo de Lectura: 4 minutos
Premios Blog KeepCoding 2025

Co-Fundador de KeepCoding

Llevo semanas haciendo stress-test del modelo on-device de Apple — el de ~3B parámetros que corre en el Neural Engine de cualquier Mac con Apple Silicon. Para probarlo a fondo construí Think Local, una app macOS que ejercita cada capacidad del modelo: chat, generación de imágenes, structured output, tool calling y comparación de parámetros.

Mi conclusión: como chatbot, el modelo es terrible. Pero como motor de structured output y tool calling, es sorprendentemente bueno.

Esa distinción importa, porque cambia completamente para qué deberías usar este modelo.

El chat es decepcionante — y eso está bien

El modelo de Apple tiene una ventana de contexto de 4.096 tokens. Para ponerlo en perspectiva: Claude tiene 1M de tokens y GPT-4o tiene 128K. Con Apple, metes un system prompt de 200 tokens, un schema de 150 y tres turnos de conversación, y ya estás al 70%.

La calidad del texto libre tampoco impresiona. Las respuestas son correctas pero genéricas, repetitivas en sesiones largas, y los guardrails saltan con falsos positivos molestos — pregúntale sobre seguridad informática y a veces se niega porque interpreta «ataque» literalmente.

Si lo evalúas como chatbot, es un modelo mediocre. Pero evaluarlo así es como criticar a un destornillador porque es mal martillo.

Donde brilla: constrained decoding

Aquí cambia todo. Foundation Models soporta @Generable — un macro que convierte un struct Swift en un schema que el modelo está obligado a respetar. No es «pedir JSON y cruzar los dedos». Es constrained decoding: durante la generación, el modelo literalmente no puede emitir tokens que violen el schema.

@Generable
struct BugReport {
    @Guide(.anyOf(["bug", "feature", "task"]))
    var type: String
    @Guide(.anyOf(["low", "medium", "high", "critical"]))
    var priority: String
    var title: String
    var description: String
}

Con este schema, le dices «Classify: the app crashes when I rotate the device» y devuelve:

{
  "type": "bug",
  "priority": "high",
  "title": "Crash on device rotation",
  "description": "The application crashes when the user rotates..."
}

Los campos restringidos (type, priority) son siempre válidos — no puede inventarse un valor fuera de la lista. Los campos libres (title, description) son coherentes y concisos. Lo probé con decenas de inputs distintos: cero errores de schema en más de 200 ejecuciones.

La diferencia entre generación libre y constrained decoding en este modelo es brutal. Es como la diferencia entre pedirle a un junior que escriba lo que quiera vs. darle un formulario con campos definidos. El formulario siempre gana.

Tool calling: un modelo de 3B que sabe cuándo no sabe

Esto fue lo que más me sorprendió. Define una herramienta get_weather(city: String), pregúntale «¿Qué tiempo hace en Madrid?» y genera una invocación estructurada con los parámetros correctos. Pregúntale «¿Cuál es la capital de Francia?» y responde directamente — sabe que no necesita la herramienta.

Un modelo de 3B parámetros, corriendo en tu portátil sin red, distingue cuándo usar una herramienta y cuándo no. No es perfecto — con prompts ambiguos a veces se confunde — pero el nivel de acierto en inputs claros es notable.

El tool calling de Apple usa el mismo mecanismo de constrained decoding: la invocación es un struct @Generable, así que los parámetros siempre son válidos. No hay parsing de JSON roto ni parámetros inventados.

Image Playground: el otro modelo que nadie menciona

Apple Intelligence no es solo texto. Image Playground es un framework separado que genera imágenes on-device en tres estilos: animación, ilustración y boceto. También corre enteramente en el Neural Engine, sin red.

El patrón se repite: para lo que está diseñado, funciona bien. Iconos, stickers, composiciones simples — resultados sorprendentemente buenos. Texto dentro de imágenes, anatomía humana detallada, composiciones complejas — desastroso.

Think Local incluye un Image Studio donde puedes probar prompts y comparar estilos lado a lado. La intuición que sacas en diez minutos probando prompts no la da ningún benchmark.

Los números

Medido en un Mac con Apple Silicon, usando el monitor de recursos de Think Local:

Métrica Valor
Velocidad de generación ~40 tok/s
Cold start (sin prewarm) ~800ms
Cold start (con prewarm) ~200ms
RAM del modelo ~1.2 GB
Ventana de contexto 4.096 tokens
Parámetros ~3B
Impacto en batería Mínimo (Neural Engine)

El dato de batería es relevante: el Neural Engine consume notablemente menos que la CPU para inferencia. Durante la generación, el CPU sube un poco por marshalling y UI, pero el trabajo pesado va al Neural Engine. Esto hace viable usar el modelo en background para tooling — hooks de git, linters, clasificadores — sin drenar el portátil.

Para qué sirve y para qué no

Úsalo para:

  • Clasificación y triaje (bugs, emails, tickets) → constrained decoding con @Generable
  • Extracción de datos estructurados de texto libre → schemas con @Guide
  • Tool calling ligero (buscar, calcular, consultar) → invocaciones tipo-safe
  • Draft y resumen de textos cortos → dentro del límite de 4K tokens
  • Generación de imágenes simples (iconos, stickers, ilustraciones) → Image Playground
  • Cualquier tarea donde puedas definir el formato de salida

No lo uses para:

  • Conversaciones largas → la ventana de 4K se agota en 3-4 turnos
  • Razonamiento complejo o multi-step → el modelo es demasiado pequeño
  • Generación creativa larga → las respuestas son genéricas y repetitivas
  • Nada que requiera knowledge post-octubre 2023

Pruébalo

Think Local es open source (MIT). La app ejercita todas estas capacidades con UI visual: un visualizador de tokens que muestra el contexto consumido en tiempo real, un editor de schemas, un lab de tool calling, y un compare mode para ver cómo cambian las respuestas con distintos parámetros.

git clone https://github.com/frr149/think-local.git
cd think-local
open Package.swift

Requisitos: macOS 26, Apple Silicon, Apple Intelligence activado. Cero dependencias, cero API keys.

La conclusión

Apple no ha construido un chatbot. Ha construido un motor de inferencia local con constrained decoding y tool calling que resulta que también puede chatear. Si lo evalúas como chatbot, pierde contra todo. Si lo evalúas como motor de structured output que corre gratis en tu hardware, sin red y sin API keys — no tiene competencia. Literalmente nadie más ofrece eso.

La pregunta correcta no es «¿puede Apple competir con GPT-4?» — no puede. La pregunta es «¿qué puedo construir con un modelo de 3B que corre gratis, en local, con constrained decoding?» Y la respuesta es: bastante más de lo que piensas.


Read this article in English.

Noticias recientes del mundo tech


¡CONVOCATORIA ABIERTA!

Desarrollo de apps móviles ios & Android

Full Stack Bootcamp

Clases en Directo | Profesores en Activo | Temario 100% actualizado

Descárgate también el informe de tendencias en el mercado laboral 2026.

Fórmate con planes adaptados a tus objetivos y logra resultados en tiempo récord.
KeepCoding Bootcamps
Resumen de privacidad

Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.