IA en el dispositivo o en la nube en iOS: Foundation Models frente a la API de OpenAI

Pregúntate dónde vive de verdad la inteligencia de tu app. Esa pregunta importa más que "¿añadimos IA?", y es la que cambia la forma de diseñar una función en iOS. Basta con cambiar, en un proyecto personal, una llamada a la nube por el framework Foundation Models de Apple, que funciona en el dispositivo, para verlo claro: nunca estuviste eligiendo entre dos modelos, sino entre dos lugares donde ejecutar uno.

El lugar pesa más que los benchmarks

La mayoría de las comparaciones discuten puntuaciones de modelos. Para una app de iPhone, la pregunta útil es otra: si la inferencia ocurre en el dispositivo del usuario o en el servidor de otro.

Esa sola decisión se filtra en todo lo que publicas: las promesas de privacidad, la latencia, los costes de funcionamiento, el comportamiento sin red e incluso lo que te preguntará la revisión de la App Store. Elige primero el lugar y muchas otras decisiones dejarán de ser un debate.

En el dispositivo con Foundation Models

El framework de Apple te da un modelo de lenguaje que se ejecuta en local sobre Apple Silicon y usa el Neural Engine. No hay petición de red, ni clave de API que proteger, ni factura por tokens a final de mes.

Una sesión mínima se ve así:

import FoundationModels

// Create a session with the on-device model
let session = LanguageModelSession()

// Ask a simple question — runs entirely on-device
let response = try await session.respond(
    to: "Summarize this note in one sentence: \(userNote)"
)

print(response.content)

Lo que obtienes a cambio de un modelo más pequeño:

• No hay ida y vuelta por la red, así que sigue funcionando en un avión o en un túnel del metro.
• Nada crece con el número de usuarios, porque no le pagas a un proveedor por cada llamada.
• El texto del usuario se queda en el teléfono, algo muy importante en apps de salud, diarios y finanzas.
• Se integra directamente con async/await y SwiftUI, así que se siente como cualquier otro framework del sistema.

El precio es el tamaño. Este modelo es más pequeño y menos capaz que los modelos en la nube de la clase GPT-4. Es muy bueno resumiendo, clasificando y con razonamientos sencillos. Es flojo en la generación larga de varios pasos y en todo lo que requiere comportamiento de agente, así que no construyas esas funciones sobre él.

En la nube con la API de OpenAI

El otro lado de la elección es un razonamiento al nivel de los modelos más avanzados, pagado con una dependencia de la red. Tu función ahora necesita conexión, una clave y una factura.

Este es el mismo tipo de llamada hecha por HTTP:

// Basic async/await network call to OpenAI's API
func fetchCompletion(prompt: String) async throws -> String {
    var request = URLRequest(url: URL(string: "https://api.openai.com/v1/chat/completions")!)
    request.httpMethod = "POST"
    request.setValue("Bearer \(apiKey)", forHTTPHeaderField: "Authorization")
    request.setValue("application/json", forHTTPHeaderField: "Content-Type")

    let body: [String: Any] = [
        "model": "gpt-4o",
        "messages": [["role": "user", "content": prompt]]
    ]
    request.httpBody = try JSONSerialization.data(withJSONObject: body)

    let (data, _) = try await URLSession.shared.data(for: request)
    // Parse response into your own model here
    return String(data: data, encoding: .utf8) ?? ""
}

Yo optaría por esto cuando la calidad de la respuesta es el producto. Imagina que estás creando un asistente de investigación: el razonamiento de un modelo alojado sencillamente no lo puede igualar un modelo local pequeño, así que el coste de la red vale la pena.

Usa los dos

En producción rara vez tienes que elegir uno. Reparte el trabajo según lo que necesita cada tarea y mantén esa decisión fuera de tus vistas, por ejemplo detrás de tu capa MVVM, para que un view model pida un resultado y nunca le importe de dónde viene.

• En el dispositivo: autocompletado, etiquetado, resúmenes rápidos y un plan de respaldo sin conexión.
• A la nube: generación larga y profunda, y todo lo que necesite mucho contexto.

Ese reparto mantiene la app ágil y barata en aproximadamente el 80% de las interacciones, y solo pagas una llamada a la nube cuando la tarea lo justifica. También combina bien con SwiftData: guarda los resultados en una caché local y las peticiones repetidas ni siquiera llegarán a la red.

Cómo decidir rápido

• Necesitas funcionar sin conexión o una privacidad de datos estricta: usa Foundation Models.
• Necesitas razonamiento de primer nivel o una ventana de contexto enorme: usa la API de OpenAI.
• Quieres escalar sin arruinar el presupuesto: opta por un enfoque híbrido y haz que el camino en el dispositivo sea el predeterminado.
• Te preparas para una pregunta de entrevista de iOS sobre arquitectura de IA: explica las dos opciones y cuándo elegirías cada una, porque esa es la respuesta que buscan los entrevistadores.

Ninguna de las dos opciones gana de forma clara. Foundation Models es ya la opción sensata por defecto para funciones rápidas, privadas y baratas, y el trabajo pesado sigue pasando por una API alojada. En 2026 la mejor arquitectura de iOS no consiste en elegir un bando. Consiste en saber con exactitud qué trabajo merece un viaje por la red y cuál no.