KI auf dem Gerät oder in der Cloud unter iOS: Foundation Models gegen die OpenAI API

Frag dich, wo die Intelligenz deiner App eigentlich sitzt. Diese Frage ist wichtiger als "Sollen wir KI einbauen?", und sie ist es, die das Design einer iOS-Funktion verändert. Wer in einem Nebenprojekt einen Cloud-Aufruf durch Apples Foundation Models Framework auf dem Gerät ersetzt, merkt es schnell: Man hat nie zwischen zwei Modellen gewählt, sondern zwischen zwei Orten, an denen eines läuft.

Der Ort schlägt die Benchmarks

Die meisten Vergleiche streiten über Modell-Scores. Für eine iPhone-App ist eine andere Frage nützlicher: Findet die Inferenz auf dem Gerät des Nutzers statt oder auf dem Server von jemand anderem?

Diese eine Entscheidung sickert in alles, was du auslieferst: Datenschutzversprechen, Latenz, laufende Kosten, Verhalten ohne Netz, sogar die Fragen, die dir das App-Store-Review stellen wird. Leg zuerst den Ort fest, dann sind viele andere Entscheidungen keine Diskussion mehr.

Auf dem Gerät mit Foundation Models

Apples Framework liefert ein Sprachmodell, das lokal auf Apple Silicon läuft und die Neural Engine nutzt. Es gibt keinen Netzwerk-Request, keinen API-Schlüssel, den du schützen musst, und keine Rechnung pro Token am Monatsende.

Eine minimale Session sieht so aus:

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)

Was du im Gegenzug für das kleinere Modell bekommst:

• Kein Weg übers Netz und zurück, also funktioniert es auch im Flugzeug oder im U-Bahn-Tunnel.
• Nichts wächst mit der Zahl deiner Nutzer, denn du zahlst keinem Anbieter jeden Aufruf.
• Der Text der Nutzer bleibt auf dem Telefon, und das ist für Gesundheits-, Tagebuch- und Finanz-Apps eine große Sache.
• Es fügt sich direkt in async/await und SwiftUI ein und fühlt sich deshalb wie jedes andere System-Framework an.

Der Preis dafür ist die Größe. Dieses Modell ist kleiner und weniger leistungsfähig als Cloud-Modelle der GPT-4-Klasse. Im Zusammenfassen, Klassifizieren und bei leichtem Schlussfolgern ist es sehr gut. Bei langer mehrstufiger Generierung und bei allem, was agentenartiges Verhalten braucht, ist es schwach, also bau solche Funktionen nicht darauf auf.

Cloud mit der OpenAI API

Die andere Seite der Wahl ist Schlussfolgern auf dem Niveau der Spitzenmodelle, bezahlt mit einer Abhängigkeit vom Netz. Deine Funktion braucht jetzt eine Verbindung, einen Schlüssel und eine Rechnung.

Hier ist die gleiche Art von Aufruf über 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) ?? ""
}

Ich würde diesen Weg wählen, wenn die Qualität der Ausgabe das Produkt ist. Angenommen, du baust einen Recherche-Assistenten: Das Schlussfolgern eines gehosteten Modells kann ein kleines lokales Modell einfach nicht leisten, also lohnen sich die Netzwerkkosten.

Nutze beides

In der Produktion musst du dich selten für eines entscheiden. Teil die Arbeit danach auf, was jede Aufgabe braucht, und halt diese Entscheidung aus deinen Views heraus, zum Beispiel hinter deiner MVVM-Schicht, damit ein View Model ein Ergebnis anfordert und sich nie darum kümmert, woher es kommt.

• Auf dem Gerät: Autovervollständigung, Tagging, schnelle Zusammenfassungen und ein Offline-Fallback.
• In die Cloud: tiefe, lange Generierung und alles, was viel Kontext braucht.

Diese Aufteilung hält die App bei etwa 80% der Interaktionen flott und günstig, und für einen Cloud-Aufruf zahlst du nur, wenn die Aufgabe es rechtfertigt. Sie passt auch gut zu SwiftData: Speichere Ergebnisse lokal im Cache, dann gehen wiederholte Anfragen gar nicht erst ins Netz.

Schnell entscheiden

• Offline-Betrieb oder strikter Datenschutz ist Pflicht: nimm Foundation Models.
• Du brauchst Schlussfolgern der Spitzenklasse oder ein riesiges Kontextfenster: nimm die OpenAI API.
• Du willst skalieren, ohne das Budget zu sprengen: setz auf ein Hybridmodell und mach den Weg auf dem Gerät zum Standard.
• Du bereitest dich auf eine iOS-Interviewfrage zur KI-Architektur vor: Erklär beide Varianten und wann du welche wählen würdest, denn genau diese Antwort wollen Interviewer hören.

Keine der beiden Optionen gewinnt klar. Foundation Models ist inzwischen die vernünftige Standardwahl für schnelle, private und günstige Funktionen, die schwere Arbeit läuft weiterhin über eine gehostete API. Im Jahr 2026 geht es bei guter iOS-Architektur nicht darum, sich für eine Seite zu entscheiden. Es geht darum, genau zu wissen, welche Arbeit einen Weg übers Netz verdient und welche nicht.