Foundation Models On-Device LLM: El Protocolo Tool

Género: ensayo de frontera. La publicación nombra el contrato del LLM on-device que Apple lanzó en la WWDC 2025 y recorre la cuestión del enrutamiento: cuándo LanguageModelSession es la respuesta correcta, cuándo es AppIntent, cuándo es MCP, cuándo no es ninguno de los anteriores.

iOS 26 incluye un modelo de lenguaje de 3000 millones de parámetros en cada dispositivo compatible con Apple Intelligence.¹ Apple llama al framework Foundation Models. El framework es local. La inferencia está optimizada para Apple silicon y se ejecuta en el dispositivo; la red no está en la ruta de la llamada. El modelo vive en SystemLanguageModel.default, tu app obtiene una LanguageModelSession, y la superficie tipada para permitir que esa sesión haga trabajo útil es el protocolo Tool.

El protocolo Tool es la parte que importa para los desarrolladores de apps. Sin él, el LLM on-device es un endpoint de chat completion sin conexión con los datos de tu app, los datos de tu usuario o el resto del sistema. Con él, el modelo puede llamar a funciones tipadas de Swift, recibir resultados tipados de vuelta y razonar sobre la respuesta en su próximo turno. La generación on-device aumentada con herramientas es la capacidad real del framework. La superficie de chat es la demo.

TL;DR

• Foundation Models le da a cada dispositivo elegible para Apple Intelligence un LLM de 3000 millones de parámetros en SystemLanguageModel.default. El modelo es local; la inferencia está optimizada para Apple silicon y se ejecuta en el dispositivo; la red está fuera de la ruta de la llamada.
• El protocolo Tool es el contrato entre el modelo y tu app. Una herramienta declara Arguments tipados, devuelve un Output tipado, y se vincula a una LanguageModelSession en el momento de la construcción.
• Las anotaciones Generable y Guide permiten al modelo producir valores tipados de Swift directamente, no solo cadenas de texto. El decodificador es parte del framework, no de tu código.
• La regla de enrutamiento entre Foundation Models, App Intents y MCP es quién ejecuta el modelo y dónde. Foundation Models = tu app ejecuta el modelo en el dispositivo. App Intents = Apple Intelligence ejecuta el modelo en el dispositivo y enruta a tu app. MCP = un host externo ejecuta el modelo donde quiera y llega a tu app a través de un servidor de herramientas.

Lo que el framework realmente proporciona

Tres primitivas sostienen el framework: el modelo, la sesión y la herramienta.²

SystemLanguageModel. Una referencia al modelo fundacional on-device. La instancia predeterminada está vinculada al dispositivo del usuario, disponible en hardware elegible para Apple Intelligence, y expone verificaciones de capacidad que la app lee en tiempo de ejecución para decidir si el modelo está disponible. El framework admite configuración a través de SystemLanguageModel(useCase:guardrails:), adaptadores personalizados y GenerationOptions, pero no eliges IDs arbitrarios de modelos en la nube como lo harías contra OpenAI o Anthropic; Apple envía y actualiza el modelo on-device por cada lanzamiento del SO, y el framework te entrega la versión que esté instalada actualmente.

LanguageModelSession. Un objeto con estado que mantiene el contexto de la conversación a lo largo de las llamadas. La sesión recibe un prompt del sistema en la construcción, acumula turnos de usuario/asistente con el tiempo, y expone métodos asíncronos para generar respuestas. Las sesiones son ligeras de crear y desechables; creas una por tarea, no una por app. Una app de meditación crea una sesión para “resúmeme mis últimos 7 días de práctica”; una app de recetas crea una sesión diferente para “convierte esto para dos personas en lugar de cuatro”.

Tool (el protocolo). Un protocolo de Swift que declara un tipo Arguments, un tipo Output y una función asíncrona call(arguments:). Las herramientas se vinculan a una sesión en el momento de la construcción (LanguageModelSession(tools: [...], instructions: ...)). Cuando el modelo decide que necesita una herramienta, emite una llamada estructurada; el framework decodifica los argumentos, ejecuta la herramienta, codifica el resultado y lo retroalimenta a la sesión para el próximo turno. El modelo no ve Swift; el framework hace el marshalling.

La forma del protocolo Tool, condensada:

import FoundationModels

struct WaterEntryLookup: Tool {
    let name = "lookup_water_entries"
    let description = "Look up water intake entries for a given date range."

    @Generable
    struct Arguments {
        @Guide(description: "Start date in ISO-8601 format")
        let startDate: String

        @Guide(description: "End date in ISO-8601 format")
        let endDate: String
    }

    func call(arguments: Arguments) async throws -> ToolOutput {
        let entries = try store.entries(
            from: ISO8601DateFormatter().date(from: arguments.startDate) ?? .now,
            to: ISO8601DateFormatter().date(from: arguments.endDate) ?? .now
        )
        return ToolOutput(GeneratedContent(properties: [
            "count": entries.count,
            "total_ml": entries.reduce(0) { $0 + $1.amountMl }
        ]))
    }
}

El modelo ve una descripción de la herramienta y un esquema de argumentos con forma de JSON. El código Swift ve entrada tipada y salida tipada. La frontera de codificación/decodificación es la parte de la que se encarga Apple.

Generable y Guide: salida tipada sin un parser

El mismo sistema de anotaciones que tipa los argumentos de las herramientas también permite al modelo producir valores tipados de Swift directamente.³ Una struct @Generable declara su forma; el framework restringe la salida del modelo para que coincida.

@Generable
struct PracticeSummary {
    @Guide(description: "Single-sentence headline summarizing the user's week")
    let headline: String

    @Guide(description: "Total practice duration this week in minutes")
    let totalMinutes: Int

    @Guide(description: "Three short observations as bullet points")
    let observations: [String]
}

let session = LanguageModelSession(instructions: "You are a meditation coach.")
let summary = try await session.respond(
    to: "Summarize this week of practice given the entries.",
    generating: PracticeSummary.self
)

El modelo devuelve un valor PracticeSummary. Sin parsing de JSON en tu código, sin coincidencia de cadenas para “headline:”, sin fallback cuando el modelo devuelve un objeto malformado. El framework usa decodificación restringida para mantener la salida token por token del modelo estructuralmente alineada con el esquema, de modo que la salida estructuralmente inválida no se cuele más allá de la frontera.

La superficie tipada de Swift es lo que distingue al framework de los SDKs de LLM en la nube. Los SDKs en la nube (OpenAI Structured Outputs, uso de herramientas de Anthropic, otros) también admiten decodificación restringida, pero el valor tipado que recibe el desarrollador es un objeto JSON validado contra un esquema, luego decodificado en un tipo Swift Codable como un paso separado. Foundation Models colapsa esos pasos: el macro @Generable y el decodificador del framework producen un valor tipado de Swift como retorno directo, con las anotaciones @Guide por campo llevando la intención a la restricción de generación. La salida es tipada porque la generación fue tipada contra el esquema de Swift, no contra una especificación JSON que el desarrollador reconstruyó en Swift.

Las anotaciones @Guide son la forma de comunicar la intención por campo al modelo sin escribirla en el prompt. La descripción generada se convierte en parte de la restricción de generación. Las guías a nivel de campo mantienen el prompt limpio y el esquema cerca de los datos.

La cuestión del enrutamiento, de tres formas

Ahora Apple ofrece tres superficies de protocolo que una app puede usar para exponer su dominio a un modelo de lenguaje. Enrutan a diferentes ejecutores.

Foundation Models (LanguageModelSession). Tu app carga el modelo on-device y ejecuta la inferencia. Las herramientas que la sesión puede llamar son herramientas que el código de tu app define. El modelo nunca abandona el dispositivo. El usuario no invoca esto a través de Siri; el código de tu app sí. El caso de uso está dentro de tu app: una app de meditación que usa el LLM para resumir una semana, una app de recetas que adapta una receta para menos porciones, un rastreador de agua que convierte “tomé un vaso con el almuerzo” en una entrada estructurada.

App Intents. Apple Intelligence ejecuta un LLM en nombre del usuario (el agente propio de Apple) y enruta llamadas de capacidad a los tipos AppIntent de tu app. Tu app no ejecuta el modelo. Declaras acciones tipadas a través del framework App Intents, y la pila del sistema de Apple decide cuándo invocarlas según la solicitud del usuario, la consulta de Spotlight, la entrada de Siri o la orquestación de Shortcuts. Cubierto en detalle en App Intents Are Apple’s New API to Your App.⁴

MCP. Un host externo (Claude Desktop, Claude Code, Cursor, ChatGPT) ejecuta el modelo que el desarrollador eligió. Tu app expone un servidor que el modelo del host puede llamar. El modelo se ejecuta donde sea que el host lo ejecute; las llamadas a herramientas cruzan un transporte JSON-RPC. Cubierto en Two Agent Ecosystems, One Shopping List y la síntesis de la cuestión del enrutamiento en App Intents vs MCP.⁵

La decisión de enrutamiento se reduce a quién es el agente.

                  ┌──────────────────────────────────┐
                  │  Who is the language model?       │
                  └────┬─────────────┬─────────────┬──┘
                       │             │             │
              ┌────────┴────┐ ┌──────┴──────┐ ┌────┴──────┐
              │ Your app's  │ │   Apple     │ │  External │
              │ own use of  │ │ Intelligence│ │   host's  │
              │   LLM       │ │   agent     │ │   agent   │
              └──────┬──────┘ └──────┬──────┘ └────┬──────┘
                     │               │             │
                     ▼               ▼             ▼
              Foundation Models  App Intents     MCP
              + Tool protocol   + AppEntity    + tools/list
              (on-device, your  (system runs   (host runs
               app runs model)   the model)     the model)

Una app de meditación que resume la semana del usuario usa Foundation Models porque la app misma quiere llamar al modelo y presentar un resultado dentro de la app. La capacidad de “registrar una sesión de 5 minutos” de la misma app usa App Intents para que Siri pueda invocarla. La capacidad de “muéstrame las últimas entradas de mi registro de meditación” de la misma app usada por una sesión de Claude Code usa MCP. Tres ejecutores distintos, tres obligaciones distintas, una capa de dominio compartida debajo.

Presupuestos de inferencia: lo que el framework te pide

Ejecutar un LLM on-device no es gratis. Apple silicon maneja la inferencia, pero el modelo todavía tiene una ventana de contexto, un presupuesto de tokens y una latencia de reloj de pared que depende del dispositivo. Tres restricciones moldean cómo diseñas con el framework:⁶

La disponibilidad es por dispositivo. No todos los dispositivos con iOS 26 tienen Apple Intelligence. Los iPhones más antiguos, los dispositivos bloqueados y los dispositivos donde el usuario ha desactivado Apple Intelligence devuelven un estado de no disponible desde SystemLanguageModel.default.availability. El código que llama a LanguageModelSession sin verificar la disponibilidad expone un error de generación en tiempo de ejecución; el patrón correcto es ramificar la UI según el estado de disponibilidad de antemano y presentar una ruta sin LLM cuando el estado no esté disponible. Trata el modelo como un feature flag, no como una garantía.

La latencia no es trivial. La latencia del primer token en el iPhone 16 Pro es usable para interacciones dentro de la app; las generaciones más largas y las cadenas de llamadas a herramientas no son instantáneas. Los patrones de UI que funcionan para streaming de LLM en la nube también funcionan aquí; no bloquees el hilo principal, sí muestra salida progresiva y diseña para el caso en que el usuario navegue fuera a mitad de la generación.

Las ventanas de contexto son más pequeñas que en la nube. El modelo on-device tiene una ventana de contexto más pequeña que los modelos en la nube de la clase GPT-4. Los documentos largos necesitan resumen o segmentación. El historial largo de conversación necesita recorte. Las salidas de herramientas que devuelven payloads estructurados grandes deberían devolver una referencia (un ID, una clave) que el próximo turno pueda volver a obtener bajo demanda, no el payload completo en línea.

El conjunto de restricciones es similar a diseñar para un runtime edge de gama baja, no para un modelo frontera en la nube. Las facilidades del framework lo hacen más placentero; los límites físicos subyacentes no se mueven.

Cuándo recurrir a Foundation Models

Los ajustes más fuertes del framework son donde la generación on-device de baja fricción es el producto:

Reformateo y reescritura. Convierte una nota libre del usuario en una entrada estructurada, pule un mensaje borrador, resume una transcripción capturada. La tolerancia a la latencia es moderada; la sensibilidad de los datos es alta; la inferencia en la nube es excesiva.

Síntesis local sobre datos privados. Una app de entrenamiento que convierte el historial de entrenamiento del usuario en un resumen de “esta semana”. Una app de finanzas que explica el patrón de gasto del usuario. Una app de diario que muestra temas a lo largo de un trimestre de entradas. Los datos no deberían salir del dispositivo; la respuesta debería aparecer dentro de la app; el prompt es acotado.

Llamadas a herramientas ligeras para automatización interna de la app. Una app que permite al usuario decir “muéstrame el registro de meditación del martes” y usa una herramienta para obtener los registros subyacentes, luego formatea la respuesta. El agente es la app, la herramienta es la propia capa de datos de la app, el modelo es local.

Generación conforme a tipo. En cualquier lugar donde la app de otro modo escribiría a mano un parser JSON o una plantilla de cadenas, @Generable más @Guide es una superficie más duradera.

Cuándo no recurrir a Foundation Models

El framework es la respuesta equivocada para varios casos comunes:

Cualquier cosa que el usuario podría pedirle a Siri. “Registra 250 ml de agua”, “Inicia una meditación de 5 minutos”, “Agrega plátanos a mi lista” son App Intents. Apple Intelligence es el ejecutor; tu app es el destino. Foundation Models es para generación dentro de la app, no para acciones enrutadas por Siri. Si construyes la misma capacidad dos veces (App Intent + LanguageModelSession con una herramienta), gana el App Intent porque el usuario invoca a Siri, no a tu pantalla dentro de la app.

Cualquier cosa que un agente LLM externo deba conducir. Una sesión de Claude Code que se mete en el dominio de tu app pertenece a MCP. La app no ejecuta el LLM; el host sí; el modelo vive donde sea que el host lo haya puesto. Foundation Models no puede servir a agentes externos.

Razonamiento pesado sobre documentos grandes. El modelo on-device es pequeño. Un contrato de 200 páginas, un contexto de codebase largo o razonamiento multi-imagen sobre muchas fotos pertenece a inferencia en la nube (tuya o de un proveedor), donde la ventana de contexto y el conteo de parámetros coinciden con la carga de trabajo. Las tareas que exceden el sobre del framework producen errores concretos: ventana de contexto excedida, violaciones de guardrails, locales no admitidas. Expón esos errores deliberadamente en lugar de diseñar flujos que dependan de que el modelo maneje trabajo fuera del sobre.

Flujos de trabajo entre dispositivos y entre usuarios. El modelo on-device tiene acceso solo a lo que la app pasa a la sesión. La sincronización entre dispositivos (estado de temporizador desde Watch a iPhone), la colaboración entre usuarios (listas compartidas, documentos compartidos) y cualquier flujo que se beneficie de coordinación del lado del servidor necesitan un servidor. El modelo no es una primitiva de red.

Lo que construiría diferente en mi stack

El framework recompensa una elección arquitectónica específica que es fácil equivocar en el primer intento. Las capacidades que el usuario invoca a través de la UI de la app y el LLM deberían consumirse como herramientas, no como rutas duplicadas en prosa.

Una app de meditación podría agregar un panel de “revisión semanal” resumido por LLM. La construcción ingenua es un solo prompt: “Aquí están las entradas del usuario de esta semana, escribe un párrafo.” La mejor construcción define una herramienta WeeklyEntries que el modelo puede llamar cuando necesita saber qué hubo en la semana, más una salida WeeklySummary estructurada vía @Generable. La primera construcción es frágil (el modelo tiene que ingerir una larga lista de entradas en cada llamada), costosa en tokens y produce prosa no estructurada. La segunda es duradera (la llamada a la herramienta separa “qué pasó” de “cómo hablar de ello”), barata (el modelo solo obtiene lo que necesita) y estructurada (el resultado es un valor tipado de Swift).

El patrón se compone limpiamente con App Intents y MCP. La misma consulta WeeklyEntries también es el cuerpo de un resolver de parámetros de AppIntent y de un manejador de herramientas de MCP. Una función Swift; tres superficies. El modelo llama a la misma función que llama el usuario.

La otra decisión arquitectónica: las descripciones de las herramientas son parte del prompt. El modelo lee Tool.description para decidir si y cuándo llamar. Trata la descripción como un docstring que realmente esperas que un futuro contribuyente lea; el modelo es el futuro contribuyente.

Lo que el patrón significa para el stack de Apple en iOS 26+

Tres conclusiones.

1. El LLM on-device es una función en tiempo de ejecución, no un backend. Trátalo como un framework del sistema con una ventana de contexto y un presupuesto de inferencia on-device, no como un servicio remoto. Las decisiones arquitectónicas son disponibilidad, latencia, disciplina de ventana de contexto y salida estructurada.

2. El protocolo Tool es la superficie. Sin herramientas, el modelo es un endpoint de chat completion sin conexión con tu dominio. Con herramientas, el modelo se convierte en una capa de consulta estructurada sobre los datos de tu app.

3. La regla de enrutamiento entre Foundation Models, App Intents y MCP es “quién ejecuta el modelo”. La generación dentro de la app va a Foundation Models. Las capacidades enrutadas por Apple Intelligence van a App Intents. Las capacidades de agente externo van a MCP. La misma función de dominio Swift puede ser llamada por las tres superficies.

El cluster completo del Ecosistema Apple: App Intents tipados para Apple Intelligence; servidores MCP para agentes cross-LLM; la cuestión del enrutamiento entre los dos; Live Activities para la máquina de estados de la Lock Screen; patrones de Liquid Glass para la capa visual; envío multiplataforma para alcance entre dispositivos. El hub está en la Serie del Ecosistema Apple. Para un contexto más amplio de iOS con agentes de IA, consulta la guía de iOS Agent Development.

FAQ

¿Qué es el framework Foundation Models en iOS 26?

Foundation Models es el framework de Apple para acceder al modelo de lenguaje on-device que viene con los dispositivos elegibles para Apple Intelligence en iOS 26 (y iPadOS 26, macOS 26, visionOS 26). El framework expone SystemLanguageModel, LanguageModelSession y el protocolo Tool para que las apps puedan ejecutar llamadas tipadas de LLM on-device sin acceso a la red.

¿Cómo funciona el protocolo Tool?

Un Tool es un tipo de Swift que declara una struct Arguments (anotada con @Generable y @Guide), un método asíncrono call(arguments:), y un nombre + descripción que el modelo usa para decidir cuándo llamar. Las herramientas se vinculan a una LanguageModelSession en el momento de la construcción. Cuando el modelo decide que necesita una herramienta, el framework decodifica los argumentos, ejecuta la llamada y retroalimenta la salida tipada a la sesión.

¿Cuál es la diferencia entre Foundation Models, App Intents y MCP?

Foundation Models es para que tu app ejecute el LLM on-device para generación dentro de la app. App Intents es para que Apple Intelligence (el agente del sistema) llame a las capacidades tipadas de tu app. MCP es para que hosts LLM externos (Claude, ChatGPT, etc.) llamen a las herramientas tipadas de tu app a través de un transporte JSON-RPC. Los tres protocolos difieren en quién ejecuta el modelo. La misma función de dominio Swift puede servir a los tres.

¿Puede Foundation Models llamar a herramientas MCP?

No. LanguageModelSession.tools acepta conformantes al protocolo Tool de Apple, no servidores de herramientas MCP. Para puentear los dos, escribirías un Tool de Foundation Models cuyo método call invoque un cliente MCP. Apple no ha lanzado un adaptador integrado; el puente sería código del lado de la app.

¿Es el modelo on-device lo suficientemente bueno para producción?

Para los casos de uso para los que el framework está diseñado (reformateo, resumen, generación estructurada sobre datos locales, llamadas a herramientas ligeras), sí. Para razonamiento de frontera sobre contextos grandes, comprensión multimodal a escala o razonamiento entre documentos, no. El modelo on-device es un modelo de 3000 millones de parámetros con una ventana de contexto más pequeña que los LLMs en la nube; elige cargas de trabajo que se ajusten al sobre.

Referencias