Foundation Models será de código abierto: qué abre Apple y qué cambia para Swift

Apple anunció en la WWDC26 que publicará como código abierto el núcleo de FoundationModels. Este movimiento amplía considerablemente el alcance de un framework que nació en 2025 como puerta de entrada, desde aplicaciones Apple, al modelo local de Apple Intelligence. Sin embargo, la frase «Foundation Models será de código abierto» puede inducir a una conclusión equivocada: Apple abre la infraestructura de programación, no los pesos de sus modelos.

La diferencia importa. El valor de FoundationModels no reside únicamente en ejecutar el modelo de unos 3.000 millones de parámetros incluido en el sistema. También ofrece sesiones, transcripciones, generación guiada de tipos Swift, herramientas, transmisión de resultados y control del contexto. Al abrir esa capa y añadir protocolos para conectar otros modelos, Apple convierte una API ligada inicialmente al sistema en un modelo de programación reutilizable en aplicaciones, servidores Swift y motores de inferencia de terceros.

El modelo mental: tres piezas distintas

Conviene separar tres conceptos que suelen aparecer mezclados bajo el nombre Foundation Models.

El primero es el modelo de lenguaje de Apple Intelligence. Sus parámetros, datos de entrenamiento y su distribución siguen bajo control de Apple. En dispositivos compatibles, SystemLanguageModel permite utilizar el modelo instalado por el sistema sin descargar sus pesos ni administrar un servicio de inferencia remoto. Que el framework sea abierto no convierte ese modelo en un modelo de pesos abiertos ni permite copiarlo a otras plataformas como Linux.

El segundo es el framework FoundationModels. Esta es la capa Swift que representa instrucciones, mensajes, respuestas, herramientas y sesiones. Apple ha anunciado que su núcleo será de código abierto durante el verano de 2026, con la intención explícita de que la misma API pueda utilizarse allí donde se ejecute Swift, incluidos servidores Linux.

El tercero es FoundationModelsUtilities, un paquete separado que ya está publicado en GitHub con licencia Apache 2.0. Incluye componentes experimentales que pueden evolucionar entre versiones de los sistemas operativos: gestión del historial, carga de conocimiento procedimental mediante skills y un adaptador para servicios compatibles con la API Chat Completions.

📌 Por tanto, la definición de «abierto» describe el código que coordina una interacción con un LLM. El modelo concreto que produce los tokens puede seguir siendo local y propietario, ejecutarse en el Private Cloud Compute, pertenecer a un proveedor externo o ser un modelo abierto cargado mediante otro motor.

De una API para un modelo a una API para cualquier modelo

La novedad estructural de las plataformas 27 es el protocolo LanguageModel. Una aplicación ya no tiene que identificar FoundationModels exclusivamente con SystemLanguageModel: una sesión puede trabajar con cualquier implementación que declare sus capacidades y proporcione un “ejecutor”.

LanguageModelExecutor actúa como puente entre los tipos del framework y el sistema que genera la respuesta. Recibe una solicitud con la transcripción y las opciones de contexto y generación; después traduce esos datos al formato del motor local o del servicio remoto y envía los fragmentos generados a un canal de salida. La API común queda a un lado de la interfaz y los detalles del proveedor al otro.

En una aplicación que utilice el modelo del sistema, el código básico mantiene la forma conocida:

import FoundationModels

func summarize(_ notes: String) async throws -> String {
    let model = SystemLanguageModel.default
    let session = LanguageModelSession(model: model)

    let response = try await session.respond(
        to: "Resume estas notas de mantenimiento en tres puntos: \(notes)"
    )

    return response.content
}

La idea relevante no es que todos los modelos respondan igual. Cada uno conserva límites de contexto, modalidades, políticas, costes y capacidades diferentes. La abstracción permite mantener la estructura de la aplicación —sesión, transcripción, herramientas y resultados tipados— mientras se sustituye el componente que realiza la inferencia.

Apple proporciona integraciones para varios destinos. SystemLanguageModel sigue dando acceso al modelo local; PrivateCloudComputeLanguageModel permite solicitar más capacidad de razonamiento y una ventana de contexto mayor; CoreAILanguageModel conecta modelos preparados con Core AI, y MLXLanguageModel facilita trabajar con modelos locales mediante MLX. Además, un proveedor puede distribuir su propia conformidad a LanguageModel como paquete Swift.

Qué aporta realmente el código abierto

La primera consecuencia es la portabilidad del código de manejo. Un equipo puede compartir en mayor medida sus tipos generables, herramientas y lógica de sesión entre una aplicación y un servicio escrito en Swift. En el cliente puede elegir inferencia local para una operación privada y breve; en el servidor puede utilizar un modelo de mayor tamaño para un trabajo que necesite más contexto.

La segunda es la inspección interna. Cuando una abstracción gestiona transcripciones, llamadas a herramientas y generación estructurada, poder estudiar su implementación ayuda a entender sus garantías y límites. También permite diagnosticar incompatibilidades, proponer cambios y construir integraciones sin depender de reproducir una API propietaria distinta.

La tercera es un ecosistema común para proveedores. La sesión deja de ser una envoltura exclusiva de un modelo de Apple y pasa a funcionar como una interfaz entre la lógica de producto y los distintos motores. Esto reduce el acoplamiento, aunque no lo elimina: una función diseñada alrededor de imágenes, razonamiento prolongado o herramientas paralelas seguirá necesitando un modelo que declare y cumpla esas capacidades.

🌍 El soporte de Linux resulta especialmente significativo para Swift de lado servidor. No implica que el modelo local de Apple Intelligence vaya a ejecutarse en una máquina Linux. Significa que el núcleo abierto de FoundationModels podrá alojar la misma representación de sesiones y conectar desde ella un modelo disponible en ese entorno.

FoundationModelsUtilities como laboratorio de patrones

Apple separa del núcleo un paquete de utilidades porque las prácticas alrededor de los LLM cambian con rapidez. Esa decisión permite publicar componentes con un ritmo distinto al de iOS o macOS y mantiene la separación entre qué parte constituye la base estable y cuál explora soluciones emergentes.

Una de esas áreas es la gestión del contexto. Las conversaciones largas acumulan mensajes, resultados de herramientas y contenido que puede dejar de ser útil con el tiempo. Las utilidades incluyen modificadores de perfil para descartar llamadas ya completadas, mantener ventanas móviles o resumir el historial. No crean contexto infinito: aplican políticas para gastar de forma más deliberada los tokens disponibles en la ventana de cada modelo.

Otro área son las skills. En este contexto, una skill contiene conocimiento procedimental que puede incorporarse cuando una tarea lo necesita, en lugar de ocupar permanentemente las instrucciones de la sesión. La carga bajo demanda reduce contaminación del contexto y puede mejorar el tiempo hasta el primer token, pero exige diseñar bien la selección: una habilidad irrelevante o instrucciones contradictorias degradarán el resultado.

El paquete también contiene ChatCompletionsLanguageModel, orientado a servidores que exponen el conocido formato Chat Completions. Es una forma práctica para experimentar con un servicio existente desde el modelo de programación de Apple. No garantiza por sí sola equivalencia semántica: dos proveedores pueden interpretar de manera diferente las herramientas, la generación estructurada, el muestreo o la transmisión por fragmentos.

Para añadir el paquete a un proyecto, se utiliza Swift Package Manager con su repositorio oficial:

dependencies: [
    .package(
        url: "https://github.com/apple/foundation-models-utilities",
        from: "0.1.0"
    )
]

Como el propio repositorio califica estos patrones de emergentes y experimentales, conviene fijar versiones, revisar los cambios antes de actualizar y ocultar su uso detrás de límites controlados cuando la aplicación necesite estabilidad.

Lo que no cambia con el anuncio

🔒 Abrir el framework no cambia las reglas de privacidad del modelo elegido. Una respuesta generada por SystemLanguageModel puede permanecer en el dispositivo, mientras que una implementación conectada a un servicio externo envía datos según las condiciones de ese proveedor. Compartir LanguageModelSession no hace equivalentes ambos recorridos. La interfaz debería comunicar claramente cuándo una operación abandona el dispositivo y aplicar minimización de datos, consentimiento y controles adecuados.

Tampoco desaparece la necesidad de evaluar. Sustituir un modelo puede alterar precisión, latencia, formato, seguridad y coste incluso cuando el proyecto compila sin cambios. Las plataformas 27 incorporan un framework de evaluaciones y mejores instrumentos precisamente porque una abstracción uniforme no ofrece resultados uniformes.

La disponibilidad también sigue siendo parte del diseño. El modelo del sistema depende de un dispositivo compatible, de Apple Intelligence y de su estado en ese momento. Un modelo remoto depende de la red, una autenticación, sus cuotas y condiciones comerciales. Una aplicación robusta consulta disponibilidad, contempla errores de modelo y sesión y define una experiencia alternativa que no dependa de que la generación siempre funcione.

Finalmente, las APIs anunciadas para las plataformas 27 permanecen en fase beta en julio de 2026. Apple advierte que la documentación es preliminar y que las implementaciones deben probarse de nuevo con las versiones finales. Además, el anuncio de la apertura de la más piezas indica que «más adelante este verano»; aunque FoundationModelsUtilities ya puede consultarse, pero no debe confundirse con la publicación completa del framework.

Cómo diseñar una integración preparada para varios modelos

Una buena arquitectura comienza por expresar la capacidad que necesita el producto, no el proveedor que está de moda. Clasificar texto breve, extraer una estructura, analizar una imagen y ejecutar un flujo agente son problemas distintos. Sus requisitos permiten decidir si basta el modelo local o hacen falta más contexto, herramientas específicas o razonamiento en servidor.

También conviene conservar una frontera propia alrededor de la generación. Esa capa puede seleccionar el modelo, construir instrucciones, comprobar disponibilidad y traducir errores a conceptos del producto. Los tipos @Generable y las herramientas pueden permanecer cerca del dominio, mientras la elección de infraestructura queda centralizada.

✅ La sustitución de modelos debe verificarse con un conjunto estable de casos reales. Las evaluaciones han de medir al menos cierta corrección, cumplimiento del formato, latencia y comportamiento ante entradas diversas. Si existe una ruta local y otra remota, ambas necesitan pruebas independientes y criterios explícitos para decidir cuándo cambiar de una a otra.

La apertura de FoundationModels no libera el modelo de Apple Intelligence, pero sí abre una pieza con potencial para resultar más duradera: el lenguaje común con el que las aplicaciones Swift describen generación, contexto y herramientas. Al separar ese modelo de programación del motor de inferencia, Apple permite combinar privacidad local, modelos abiertos, servicios externos y Swift de lado servidor sin reconstruir toda la aplicación para cada destino. El beneficio real será una arquitectura menos acoplada, siempre que no confundamos una API uniforme con capacidades, costes y/o garantías uniformes.