Foundation Models On-Device LLM: Das Tool-Protokoll

Genre: frontier-essay. Der Beitrag benennt den Vertrag für das On-Device-LLM, den Apple auf der WWDC 2025 ausgeliefert hat, und arbeitet die Routing-Frage durch: Wann ist LanguageModelSession die richtige Antwort, wann AppIntent, wann MCP, wann nichts davon.

iOS 26 liefert auf jedem Apple-Intelligence-fähigen Gerät ein Sprachmodell mit 3 Milliarden Parametern aus.¹ Apple nennt das Framework Foundation Models. Das Framework ist lokal. Die Inferenz ist für Apple Silicon optimiert und läuft auf dem Gerät; das Netzwerk ist nicht im Aufrufpfad. Das Modell befindet sich unter SystemLanguageModel.default, Ihre App erhält eine LanguageModelSession, und die typisierte Schnittstelle, mit der diese Sitzung sinnvolle Arbeit leisten kann, ist das Tool-Protokoll.

Das Tool-Protokoll ist der Teil, der für App-Entwickler zählt. Ohne es ist das On-Device-LLM ein Chat-Completion-Endpunkt ohne Verbindung zu den Daten Ihrer App, den Daten Ihres Benutzers oder dem Rest des Systems. Mit ihm kann das Modell typisierte Swift-Funktionen aufrufen, typisierte Ergebnisse zurückbekommen und in seiner nächsten Runde über die Antwort schlussfolgern. Tool-erweiterte On-Device-Generierung ist die eigentliche Fähigkeit des Frameworks. Die Chat-Oberfläche ist die Demo.

TL;DR

• Foundation Models stellt jedem Apple-Intelligence-fähigen Gerät unter SystemLanguageModel.default ein 3-Milliarden-Parameter-LLM zur Verfügung. Das Modell ist lokal; die Inferenz ist für Apple Silicon optimiert und läuft auf dem Gerät; das Netzwerk liegt außerhalb des Aufrufpfads.
• Das Tool-Protokoll ist der Vertrag zwischen dem Modell und Ihrer App. Ein Tool deklariert typisierte Arguments, gibt einen typisierten Output zurück und wird zum Konstruktionszeitpunkt an eine LanguageModelSession gebunden.
• Generable- und Guide-Annotationen erlauben es dem Modell, direkt typisierte Swift-Werte zu erzeugen, nicht nur Strings. Der Decoder ist Teil des Frameworks, nicht Ihres Codes.
• Die Routing-Regel zwischen Foundation Models, App Intents und MCP lautet wer das Modell ausführt und wo. Foundation Models = Ihre App führt das Modell auf dem Gerät aus. App Intents = Apple Intelligence führt das Modell auf dem Gerät aus und leitet an Ihre App weiter. MCP = ein externer Host führt das Modell dort aus, wo er möchte, und greift über einen Tool-Server in Ihre App.

Was das Framework tatsächlich bietet

Drei Primitive tragen das Framework: das Modell, die Sitzung und das Tool.²

SystemLanguageModel. Eine Referenz auf das On-Device-Foundation-Modell. Die Standardinstanz ist an das Gerät des Benutzers gebunden, auf Apple-Intelligence-fähiger Hardware verfügbar und stellt Verfügbarkeitsprüfungen bereit, die die App zur Laufzeit liest, um zu entscheiden, ob das Modell verfügbar ist. Das Framework unterstützt die Konfiguration über SystemLanguageModel(useCase:guardrails:), benutzerdefinierte Adapter und GenerationOptions, aber Sie wählen keine beliebigen Cloud-Modell-IDs aus, wie Sie es bei OpenAI oder Anthropic tun würden; Apple liefert und aktualisiert das On-Device-Modell pro OS-Release und gibt Ihnen die jeweils installierte Version zurück.

LanguageModelSession. Ein zustandsbehaftetes Objekt, das den Konversationszustand über Aufrufe hinweg hält. Die Sitzung übernimmt zum Konstruktionszeitpunkt einen System-Prompt, sammelt im Lauf der Zeit User/Assistant-Turns an und stellt asynchrone Methoden zur Antwortgenerierung bereit. Sitzungen sind leichtgewichtig zu erzeugen und verwerfbar; Sie erstellen eine pro Aufgabe, nicht eine pro App. Eine Meditations-Timer-App erstellt eine Sitzung für „Fasse meine letzten 7 Tage Praxis zusammen”; eine Rezept-App erstellt eine andere Sitzung für „Wandle dieses Rezept für zwei statt vier Personen um”.

Tool (das Protokoll). Ein Swift-Protokoll, das einen Arguments-Typ, einen Output-Typ und eine asynchrone call(arguments:)-Funktion deklariert. Tools werden zum Konstruktionszeitpunkt an eine Sitzung gebunden (LanguageModelSession(tools: [...], instructions: ...)). Wenn das Modell entscheidet, dass es ein Tool benötigt, gibt es einen strukturierten Aufruf aus; das Framework decodiert die Argumente, führt das Tool aus, codiert das Ergebnis und speist es für die nächste Runde zurück in die Sitzung ein. Das Modell sieht kein Swift; das Framework übernimmt das Marshalling.

Die Form des Tool-Protokolls, verdichtet:

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 }
        ]))
    }
}

Das Modell sieht eine Tool-Beschreibung und ein JSON-förmiges Argumentschema. Der Swift-Code sieht typisierten Input und typisierten Output. Die Decode/Encode-Grenze ist der Teil, den Apple verantwortet.

Generable und Guide: Typisierte Ausgabe ohne Parser

Dasselbe Annotationssystem, das Tool-Argumente typisiert, lässt das Modell auch direkt typisierte Swift-Werte erzeugen.³ Eine @Generable-Struktur deklariert ihre Form; das Framework beschränkt die Ausgabe des Modells darauf, ihr zu entsprechen.

@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
)

Das Modell gibt einen PracticeSummary-Wert zurück. Kein JSON-Parsing in Ihrem Code, kein String-Matching auf „headline:”, kein Fallback, falls das Modell ein fehlerhaftes Objekt zurückgegeben hat. Das Framework verwendet Constrained Decoding, um die Token-für-Token-Ausgabe des Modells strukturell mit dem Schema in Einklang zu halten, sodass strukturell ungültige Ausgaben die Grenze nicht passieren.

Die Swift-typisierte Schnittstelle ist das, was das Framework von Cloud-LLM-SDKs unterscheidet. Cloud-SDKs (OpenAI Structured Outputs, Anthropic Tool Use, andere) unterstützen ebenfalls Constrained Decoding, aber der typisierte Wert, den der Entwickler erhält, ist ein JSON-Objekt, das gegen ein Schema validiert und dann in einem separaten Schritt in einen Codable-Swift-Typ decodiert wird. Foundation Models verschmilzt diese Schritte: Das @Generable-Macro und der Decoder des Frameworks erzeugen einen typisierten Swift-Wert als direkten Rückgabewert, wobei die feldweisen @Guide-Annotationen die Intention in die Generierungseinschränkung tragen. Die Ausgabe ist typisiert, weil die Generierung gegen das Swift-Schema typisiert war, nicht gegen eine JSON-Spezifikation, die der Entwickler in Swift rekonstruiert hat.

@Guide-Annotationen sind die Art, wie Sie dem Modell die Intention pro Feld kommunizieren, ohne sie in den Prompt zu schreiben. Die generierte Beschreibung wird Teil der Generierungseinschränkung. Felderorientierte Guides halten den Prompt sauber und das Schema nahe an den Daten.

Die Routing-Frage in drei Varianten

Apple bietet jetzt drei Protokoll-Schnittstellen, über die eine App ihre Domäne einem Sprachmodell zugänglich machen kann. Sie leiten an unterschiedliche Ausführungsumgebungen weiter.

Foundation Models (LanguageModelSession). Ihre App lädt das On-Device-Modell und führt die Inferenz aus. Tools, die die Sitzung aufrufen kann, sind Tools, die der Code Ihrer App definiert. Das Modell verlässt das Gerät nie. Der Benutzer ruft dies nicht über Siri auf; der Code Ihrer App tut es. Der Anwendungsfall liegt innerhalb Ihrer App: eine Meditations-App, die das LLM verwendet, um eine Woche zusammenzufassen, eine Rezept-App, die ein Rezept für weniger Portionen anpasst, ein Wassertracker, der „Ich hatte ein Glas zum Mittagessen” in einen strukturierten Eintrag umwandelt.

App Intents. Apple Intelligence führt im Auftrag des Benutzers ein LLM aus (Apples First-Party-Agent) und leitet Capability-Aufrufe an die AppIntent-Typen Ihrer App weiter. Ihre App führt das Modell nicht aus. Sie deklarieren typisierte Aktionen über das App-Intents-Framework, und Apples System-Stack entscheidet, wann diese aufgerufen werden – basierend auf Benutzeranfragen, Spotlight-Abfragen, Siri-Eingaben oder Shortcuts-Orchestrierung. Im Detail behandelt in App Intents sind Apples neue API zu Ihrer App.⁴

MCP. Ein externer Host (Claude Desktop, Claude Code, Cursor, ChatGPT) führt das Modell aus, das der Entwickler gewählt hat. Ihre App stellt einen Server bereit, den das Modell des Hosts aufrufen kann. Das Modell läuft dort, wo der Host es ausführt; Tool-Aufrufe überqueren einen JSON-RPC-Transport. Behandelt in Zwei Agent-Ökosysteme, eine Einkaufsliste und in der Routing-Frage-Synthese in App Intents vs MCP.⁵

Die Routing-Entscheidung läuft auf wer ist der Agent hinaus.

                  ┌──────────────────────────────────┐
                  │  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)

Eine Meditations-App, die die Woche des Benutzers zusammenfasst, verwendet Foundation Models, weil die App selbst das Modell aufrufen und ein Ergebnis innerhalb der App präsentieren möchte. Die „Logge eine 5-minütige Sitzung”-Funktion derselben App nutzt App Intents, damit Siri sie aufrufen kann. Die „Zeige mir meine letzten Meditationsprotokoll-Einträge”-Funktion derselben App, die von einer Claude Code-Sitzung verwendet wird, nutzt MCP. Drei verschiedene Ausführungsumgebungen, drei verschiedene Verpflichtungen, eine gemeinsame Domänenschicht darunter.

Inferenzbudgets: Was das Framework von Ihnen verlangt

Ein LLM auf dem Gerät auszuführen ist nicht kostenlos. Apple Silicon übernimmt die Inferenz, aber das Modell hat dennoch ein Kontextfenster, ein Token-Budget und eine Wallclock-Latenz, die vom Gerät abhängt. Drei Einschränkungen prägen, wie Sie mit dem Framework gestalten:⁶

Verfügbarkeit ist gerätespezifisch. Nicht jedes iOS-26-Gerät verfügt über Apple Intelligence. Ältere iPhones, gesperrte Geräte und Geräte, auf denen der Benutzer Apple Intelligence deaktiviert hat, geben über SystemLanguageModel.default.availability einen Nicht-Verfügbar-Status zurück. Code, der LanguageModelSession aufruft, ohne die Verfügbarkeit zu prüfen, erzeugt zur Laufzeit einen Generierungsfehler; das richtige Muster ist, die UI im Voraus anhand des Verfügbarkeitsstatus zu verzweigen und einen LLM-freien Pfad zu präsentieren, wenn der Status nicht verfügbar ist. Behandeln Sie das Modell wie ein Feature-Flag, nicht wie eine Garantie.

Latenz ist nicht trivial. Die First-Token-Latenz auf dem iPhone 16 Pro ist für In-App-Interaktionen brauchbar; längere Generierungen und Tool-Aufruf-Ketten sind nicht sofort verfügbar. UI-Muster, die für Cloud-LLM-Streaming funktionieren, funktionieren auch hier; blockieren Sie nicht den Main-Thread, zeigen Sie progressive Ausgabe und gestalten Sie für den Fall, dass der Benutzer mitten in der Generierung wegnavigiert.

Kontextfenster sind kleiner als in der Cloud. Das On-Device-Modell hat ein kleineres Kontextfenster als Cloud-Modelle der GPT-4-Klasse. Lange Dokumente brauchen Zusammenfassung oder Chunking. Lange Gesprächsverläufe müssen gekürzt werden. Tool-Ausgaben, die große strukturierte Payloads zurückgeben, sollten eine Referenz (eine ID, einen Schlüssel) zurückgeben, die die nächste Runde bei Bedarf erneut abrufen kann, nicht das gesamte Payload inline.

Das Constraint-Set ähnelt dem Design für eine Low-End-Edge-Runtime, nicht für ein Frontier-Cloud-Modell. Die Affordanzen des Frameworks machen es angenehmer; die zugrundeliegenden physischen Grenzen verschieben sich nicht.

Wann zu Foundation Models greifen

Die stärksten Einsatzgebiete des Frameworks liegen dort, wo On-Device-Generierung mit geringer Reibung das Produkt ist:

Umformatieren und Umschreiben. Eine freie Notiz des Benutzers in einen strukturierten Eintrag umwandeln, einen Nachrichtenentwurf polieren, ein erfasstes Transkript zusammenfassen. Die Latenztoleranz ist moderat; die Datensensibilität ist hoch; Cloud-Inferenz ist Overkill.

Lokale Synthese über private Daten. Eine Workout-App, die den Trainingsverlauf des Benutzers in eine „Diese Woche”-Zusammenfassung verwandelt. Eine Finanz-App, die das Ausgabeverhalten eines Benutzers erklärt. Eine Tagebuch-App, die Themen über ein Quartal von Einträgen hinweg sichtbar macht. Die Daten sollen das Gerät nicht verlassen; die Antwort soll in der App erscheinen; der Prompt ist begrenzt.

Leichtgewichtige Tool-Aufrufe für app-interne Automatisierung. Eine App, die es dem Benutzer erlaubt zu sagen „Zeig mir das Meditationsprotokoll vom Dienstag”, und die ein Tool verwendet, um die zugrundeliegenden Datensätze abzurufen, dann die Antwort formatiert. Der Agent ist die App, das Tool ist die eigene Datenschicht der App, das Modell ist lokal.

Typkonforme Generierung. Überall dort, wo die App ansonsten einen JSON-Parser oder ein String-Template von Hand schreiben würde, ist @Generable plus @Guide die langlebigere Schnittstelle.

Wann nicht zu Foundation Models greifen

Das Framework ist die falsche Antwort für mehrere häufige Fälle:

Alles, was der Benutzer Siri fragen könnte. „Logge 250 ml Wasser”, „Starte eine 5-minütige Meditation”, „Füge Bananen zu meiner Liste hinzu” sind App Intents. Apple Intelligence ist die Ausführungsumgebung; Ihre App ist das Ziel. Foundation Models ist für die Generierung innerhalb der App, nicht für Siri-geroutete Aktionen. Wenn Sie dieselbe Funktion zweimal bauen (App Intent + LanguageModelSession mit einem Tool), gewinnt der App Intent, weil der Benutzer Siri aufruft, nicht Ihren In-App-Bildschirm.

Alles, was ein externer LLM-Agent steuern soll. Eine Claude Code-Sitzung, die in die Domäne Ihrer App greift, gehört über MCP. Die App führt das LLM nicht aus; der Host tut es; das Modell lebt dort, wo der Host es platziert hat. Foundation Models kann externe Agenten nicht bedienen.

Schweres Reasoning über große Dokumente. Das On-Device-Modell ist klein. Ein 200-seitiger Vertrag, ein langer Codebasis-Kontext oder Multi-Image-Reasoning über viele Fotos gehört in Cloud-Inferenz (Ihre eigene oder die eines Anbieters), wo Kontextfenster und Parameteranzahl zur Last passen. Aufgaben, die den Rahmen des Frameworks überschreiten, erzeugen konkrete Fehler: überschrittenes Kontextfenster, Guardrail-Verletzungen, nicht unterstützte Locales. Bringen Sie diese Fehler bewusst zur Oberfläche, anstatt Abläufe zu entwerfen, die davon abhängen, dass das Modell außerhalb des Rahmens liegende Arbeit bewältigt.

Geräte- und benutzerübergreifende Workflows. Das On-Device-Modell hat nur Zugriff auf das, was die App in die Sitzung übergibt. Geräteübergreifende Synchronisation (Timer-Status von Watch zu iPhone), benutzerübergreifende Zusammenarbeit (geteilte Listen, geteilte Dokumente) und jeder Ablauf, der von serverseitiger Koordination profitiert, brauchen einen Server. Das Modell ist kein Netzwerkprimitiv.

Was ich in meinem Stack anders bauen würde

Das Framework belohnt eine spezifische Architekturentscheidung, die im ersten Anlauf leicht falsch zu treffen ist. Funktionen, die der Benutzer über App-UI aufruft, und das LLM sollten als Tools konsumieren, nicht als doppelte Prosa-Pfade.

Eine Meditations-App könnte ein LLM-zusammengefasstes „Wochenrückblick”-Panel hinzufügen. Der naive Aufbau ist ein einziger Prompt: „Hier sind die Einträge des Benutzers in dieser Woche, schreibe einen Absatz.” Der bessere Aufbau definiert ein WeeklyEntries-Tool, das das Modell aufrufen kann, wenn es wissen muss, was in der Woche war, plus strukturierte WeeklySummary-Ausgabe über @Generable. Der erste Aufbau ist brüchig (das Modell muss bei jedem Aufruf eine lange Liste von Einträgen aufnehmen), teuer in Tokens und produziert unstrukturierte Prosa. Der zweite ist langlebig (der Tool-Aufruf trennt „was ist passiert” von „wie darüber sprechen”), kostengünstig (das Modell holt nur, was es braucht) und strukturiert (das Ergebnis ist ein typisierter Swift-Wert).

Das Muster setzt sich sauber mit App Intents und MCP zusammen. Dieselbe WeeklyEntries-Abfrage ist auch der Rumpf eines AppIntent-Parameter-Resolvers und eines MCP-Tool-Handlers. Eine Swift-Funktion; drei Schnittstellen. Das Modell ruft dieselbe Funktion auf, die der Benutzer aufruft.

Die andere Architekturentscheidung: Tool-Beschreibungen sind Teil des Prompts. Das Modell liest Tool.description, um zu entscheiden, ob und wann es aufgerufen wird. Behandeln Sie die Beschreibung wie einen Docstring, von dem Sie tatsächlich erwarten, dass ein zukünftiger Mitwirkender ihn liest; das Modell ist der zukünftige Mitwirkende.

Was das Muster für den Apple-Stack auf iOS 26+ bedeutet

Drei Erkenntnisse.

1. Das On-Device-LLM ist eine Laufzeitfunktion, kein Backend. Behandeln Sie es wie ein Systemframework mit einem Kontextfenster und einem On-Device-Inferenzbudget, nicht wie einen Remote-Dienst. Die Architekturentscheidungen sind Verfügbarkeit, Latenz, Kontextfenster-Disziplin und strukturierte Ausgabe.

2. Das Tool-Protokoll ist die Schnittstelle. Ohne Tools ist das Modell ein Chat-Completion-Endpunkt ohne Verbindung zu Ihrer Domäne. Mit Tools wird das Modell zu einer strukturierten Abfrageschicht über den Daten Ihrer App.

3. Die Routing-Regel zwischen Foundation Models, App Intents und MCP lautet „wer führt das Modell aus”. In-App-Generierung geht an Foundation Models. Apple-Intelligence-geroutete Funktionen gehen an App Intents. Funktionen für externe Agenten gehen an MCP. Dieselbe Swift-Domänenfunktion kann von allen drei Schnittstellen aufgerufen werden.

Der vollständige Apple-Ecosystem-Cluster: typisierte App Intents für Apple Intelligence; MCP-Server für LLM-übergreifende Agenten; die Routing-Frage zwischen beiden; Live Activities für die Lockscreen-Zustandsmaschine; Liquid-Glass-Patterns für die visuelle Ebene; Multi-Plattform-Auslieferung für geräteübergreifende Reichweite. Der Hub befindet sich in der Apple Ecosystem Series. Für breiteren iOS-mit-AI-Agenten-Kontext siehe den iOS Agent Development Guide.

FAQ

Was ist das Foundation Models Framework in iOS 26?

Foundation Models ist Apples Framework für den Zugriff auf das On-Device-Sprachmodell, das mit Apple-Intelligence-fähigen Geräten in iOS 26 (und iPadOS 26, macOS 26, visionOS 26) ausgeliefert wird. Das Framework legt SystemLanguageModel, LanguageModelSession und das Tool-Protokoll offen, damit Apps typisierte On-Device-LLM-Aufrufe ohne Netzwerkzugriff ausführen können.

Wie funktioniert das Tool-Protokoll?

Ein Tool ist ein Swift-Typ, der eine Arguments-Struktur (annotiert mit @Generable und @Guide), eine asynchrone call(arguments:)-Methode sowie einen Namen und eine Beschreibung deklariert, anhand derer das Modell entscheidet, wann ein Aufruf erfolgen soll. Tools werden zum Konstruktionszeitpunkt an eine LanguageModelSession gebunden. Wenn das Modell entscheidet, dass es ein Tool benötigt, decodiert das Framework die Argumente, führt den Aufruf aus und speist die typisierte Ausgabe zurück in die Sitzung ein.

Was ist der Unterschied zwischen Foundation Models, App Intents und MCP?

Foundation Models ist dafür gedacht, dass Ihre App das LLM auf dem Gerät für In-App-Generierung ausführt. App Intents ist dafür da, dass Apple Intelligence (der Systemagent) die typisierten Funktionen Ihrer App aufruft. MCP ist dafür da, dass externe LLM-Hosts (Claude, ChatGPT usw.) die typisierten Tools Ihrer App über einen JSON-RPC-Transport aufrufen. Die drei Protokolle unterscheiden sich darin, wer das Modell ausführt. Dieselbe Swift-Domänenfunktion kann allen drei dienen.

Kann Foundation Models MCP-Tools aufrufen?

Nein. LanguageModelSession.tools akzeptiert Konformer zu Apples Tool-Protokoll, keine MCP-Tool-Server. Um die beiden zu verbinden, würden Sie ein Foundation-Models-Tool schreiben, dessen call-Methode einen MCP-Client aufruft. Apple hat keinen integrierten Adapter ausgeliefert; die Brücke wäre App-seitiger Code.

Ist das On-Device-Modell gut genug für die Produktion?

Für die Anwendungsfälle, für die das Framework konzipiert ist (Umformatieren, Zusammenfassen, strukturierte Generierung über lokale Daten, leichtgewichtige Tool-Aufrufe), ja. Für Frontier-Reasoning über große Kontexte, multimodales Verständnis im großen Maßstab oder dokumentenübergreifendes Reasoning nicht. Das On-Device-Modell ist ein 3-Milliarden-Parameter-Modell mit einem kleineren Kontextfenster als Cloud-LLMs; wählen Sie Workloads, die in den Rahmen passen.

Referenzen