Foundation Models LLM auf dem Gerät: Das Tool-Protokoll

Der Vertrag für das geräteinterne LLM, den Apple auf der WWDC 2025 vorgestellt hat, wirft sofort eine Routing-Frage auf: Wann ist LanguageModelSession die richtige Antwort, wann AppIntent, wann MCP und 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 arbeitet lokal. Die Inferenz ist für Apple Silicon optimiert und läuft auf dem Gerät; das Netzwerk liegt nicht im Aufrufpfad. Das Modell ist unter SystemLanguageModel.default zu finden, Ihre App erhält eine LanguageModelSession, und die typisierte Schnittstelle, mit der diese Session sinnvolle Arbeit leisten kann, ist das Tool-Protokoll.

Für App-Entwickler ist das Tool-Protokoll der entscheidende Teil. Ohne dieses ist das geräteinterne LLM lediglich ein Chat-Completion-Endpunkt ohne Verbindung zu den Daten Ihrer App, den Daten Ihres Benutzers oder dem Rest des Systems. Damit kann das Modell typisierte Swift-Funktionen aufrufen, typisierte Ergebnisse zurückerhalten und im nächsten Zug über die Antwort schlussfolgern. Tool-gestützte Generierung auf dem Gerät 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 LLM mit 3 Milliarden Parametern 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 eine typisierte Output zurück und wird zum Konstruktionszeitpunkt an eine LanguageModelSession gebunden.
• Mit Generable- und Guide-Annotationen kann das Modell typisierte Swift-Werte direkt erzeugen, nicht nur Strings. Der Decoder gehört zum Framework, nicht zu Ihrem Code.
• Die Routing-Regel zwischen Foundation Models, App Intents und MCP lautet: Wer führt das Modell aus 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 beliebig aus und greift über einen Tool-Server in Ihre App.

Was das Framework tatsächlich bereitstellt

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

SystemLanguageModel. Eine Referenz auf das geräteinterne 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:), eigene 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 geräteinterne Modell pro OS-Release und übergibt Ihnen jeweils die installierte Version.

LanguageModelSession. Ein zustandsbehaftetes Objekt, das den Konversationsstand über Aufrufe hinweg hält. Die Session erhält bei der Konstruktion einen System-Prompt, sammelt im Zeitverlauf Benutzer-/Assistenten-Züge und stellt asynchrone Methoden zur Antwortgenerierung bereit. Sessions sind leichtgewichtig zu erstellen und vergänglich; Sie erstellen eine pro Aufgabe, nicht eine pro App. Ein Meditations-Timer erstellt eine Session für „Fasse meine letzten 7 Tage Praxis zusammen”; eine Rezept-App erstellt eine andere Session für „Wandle dieses Rezept für zwei statt für vier Personen um”.

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

Die vollständigen Anforderungen des Protokolls: name: String, description: String, ein zugehöriger Arguments-Typ, der ConvertibleFromGeneratedContent entspricht, ein zugehöriger Output-Typ, der PromptRepresentable entspricht, und eine asynchrone call(arguments:)-Methode. Das @Generable-Makro auf dem Arguments-Struct generiert die ConvertibleFromGeneratedContent-Konformität automatisch; bei Output erfüllen String und GeneratedContent diese Anforderung bereits. Die in Apples Dokumentation gezeigten Beispiele liefern String oder [String] zurück.

Die Form des Tool-Protokolls in Kurzform:

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 -> String {
        let entries = try store.entries(
            from: ISO8601DateFormatter().date(from: arguments.startDate) ?? .now,
            to: ISO8601DateFormatter().date(from: arguments.endDate) ?? .now
        )
        let totalMl = entries.reduce(0) { $0 + $1.amountMl }
        return "Found \(entries.count) entries totalling \(totalMl)ml."
    }
}

Das Modell sieht eine Tool-Beschreibung und eine Argumentform aus dem Generierungsschema. Der Swift-Code sieht typisierte Eingaben und typisierte Ausgaben. Die Decode-/Encode-Grenze gehört Apple. Die Tool-Ausgabe kann ein String oder ein GeneratedContent-Objekt sein; das obige Beispiel gibt String zurück, da das Modell selbst der Konsument für die Schlussfolgerungen im nächsten Zug ist.

Generable und Guide: Typisierte Ausgabe ohne Parser

Dasselbe Annotationssystem, das Tool-Argumente typisiert, lässt das Modell auch typisierte Swift-Werte direkt erzeugen.³ Ein @Generable-Struct deklariert seine Form; das Framework beschränkt die Ausgabe des Modells darauf, dieser 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
)

Der Aufruf liefert ein Response<PracticeSummary> zurück, dessen content ein typisiertes PracticeSummary ist. Kein JSON-Parsing in Ihrem Code, kein String-Matching auf „headline:”, kein Fallback, wenn das Modell ein fehlerhaftes Objekt zurückgegeben hat. Das Framework verwendet Constrained Sampling, um die Token-für-Token-Ausgabe des Modells strukturell am Schema auszurichten, sodass strukturell ungültige Ausgaben die Grenze nicht passieren. Die obige Session erhält keine Tools, da typisierte Ausgabe und Tool-Aufrufe unabhängige Fähigkeiten sind; eine Session kann @Generable für die Antwortform nutzen, Tools zur Verankerung, beides oder keines davon.

Die Swift-typisierte Schnittstelle unterscheidet das Framework von SDKs für Cloud-LLMs. Cloud-SDKs (OpenAI Structured Outputs, Anthropic Tool Use und andere) unterstützen ebenfalls Constrained Sampling, doch der typisierte Wert, den der Entwickler erhält, ist ein JSON-Objekt, das gegen ein Schema validiert und anschließend in einem separaten Schritt in einen Codable Swift-Typ dekodiert wird. Foundation Models fasst diese Schritte zusammen: Das @Generable-Makro und der Decoder des Frameworks erzeugen direkt einen typisierten Swift-Wert als Rückgabewert, wobei die feldbezogenen @Guide-Annotationen die Absicht in die Generierungsbeschrä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 der Weg, um dem Modell die Absicht pro Feld mitzuteilen, ohne sie in den Prompt zu schreiben. Die generierte Beschreibung wird Teil der Generierungsbeschränkung. Feldbezogene Guides halten den Prompt sauber und das Schema nahe an den Daten.

Die Routing-Frage in drei Varianten

Apple bietet inzwischen drei Protokollschnittstellen, über die eine App ihre Domäne einem Sprachmodell zugänglich machen kann. Sie leiten an unterschiedliche Ausführer weiter.

Foundation Models (LanguageModelSession). Ihre App lädt das geräteinterne Modell und führt die Inferenz aus. Tools, die die Session 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 das. Der Anwendungsfall liegt innerhalb Ihrer App: eine Meditations-App, die das LLM nutzt, um eine Woche zusammenzufassen, eine Rezept-App, die ein Rezept für weniger Portionen anpasst, ein Wasser-Tracker, 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 hauseigener 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 auf Basis von Benutzeranfragen, Spotlight-Abfragen, Siri-Eingaben oder Shortcuts-Orchestrierung, wann diese aufgerufen werden. Im Detail behandelt in App Intents Are Apple’s New API to Your App.⁴

MCP. Ein externer Host (Claude Desktop, Claude Code, Cursor, ChatGPT) führt das vom Entwickler gewählte Modell aus. 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 Two Agent Ecosystems, One Shopping List sowie der Synthese der Routing-Frage in App Intents vs MCP.⁵

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

                  ┌──────────────────────────────────┐
                  │  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, nutzt Foundation Models, weil die App selbst das Modell aufrufen und ein Ergebnis innerhalb der App präsentieren möchte. Die Funktion „eine 5-minütige Sitzung protokollieren” derselben App nutzt App Intents, damit Siri sie aufrufen kann. Die Funktion „zeige mir meine letzten Meditations-Logbucheinträge”, die von einer Claude Code-Session genutzt wird, verwendet MCP. Drei verschiedene Ausführer, drei verschiedene Pflichten, eine gemeinsame Domänenschicht darunter.

Inferenz-Budgets: Was das Framework von Ihnen verlangt

Ein LLM auf dem Gerät auszuführen, ist nicht kostenlos. Apple Silicon übernimmt die Inferenz, doch das Modell hat weiterhin ein Kontextfenster, ein Token-Budget und eine geräteabhängige Wall-Clock-Latenz. Drei Beschränkungen prägen den Entwurf mit dem Framework:⁶

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 ohne Verfügbarkeitsprüfung aufruft, löst zur Laufzeit einen Generierungsfehler aus; das richtige Muster besteht darin, die Benutzeroberfläche im Voraus anhand des Verfügbarkeitsstatus zu verzweigen und einen LLM-freien Pfad bereitzustellen, wenn der Status nicht verfügbar ist. Behandeln Sie das Modell als Feature-Flag, nicht als Garantie.

Die Latenz ist nicht trivial. Die First-Token-Latenz auf iPhone 16 Pro Hardware ist nach unseren Tests bei Return für In-App-Interaktionen brauchbar; längere Generierungen und Tool-Aufruf-Ketten erfolgen nicht sofort. UI-Muster, die für das Streaming von Cloud-LLMs funktionieren, funktionieren auch hier; blockieren Sie nicht den Hauptthread, zeigen Sie progressive Ausgaben an und gestalten Sie für den Fall, dass der Benutzer mitten in der Generierung wegnavigiert.

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

Die Beschränkungen ähneln dem Entwurf für eine schwache Edge-Runtime, nicht für ein Frontier-Cloud-Modell. Die Affordanzen des Frameworks machen es angenehmer; die zugrunde liegenden physikalischen Grenzen bewegen sich nicht.

Wann sollten Sie zu Foundation Models greifen

Am besten passt das Framework dort, wo geräteinterne, reibungsarme Generierung das Produkt ist:

Umformatierung und Umformulierung. Verwandeln Sie eine freie Notiz des Benutzers in einen strukturierten Eintrag, polieren Sie eine Nachrichtenentwurf, fassen Sie ein erfasstes Transkript zusammen. Die Latenztoleranz ist moderat; die Datensensibilität ist hoch; Cloud-Inferenz wäre überdimensioniert.

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

Leichtgewichtiges Tool-Calling für app-interne Automatisierung. Eine App, die es dem Benutzer erlaubt zu sagen „zeig mir das Meditations-Log vom Dienstag” und ein Tool nutzt, um die zugrunde liegenden Datensätze abzurufen, um anschließend die Antwort zu formatieren. Der Agent ist die App, das Tool ist die eigene Datenschicht der App, das Modell ist lokal.

Typkonforme Generierung. Überall dort, wo die App andernfalls einen JSON-Parser oder eine String-Vorlage von Hand schreiben würde, ist @Generable plus @Guide die robustere Schnittstelle.

Wann sollten Sie nicht zu Foundation Models greifen

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

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 der Ausführer; Ihre App ist das Ziel. Foundation Models ist für die Generierung innerhalb der App gedacht, 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-Session, 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 externen Agenten nicht dienen.

Schweres Reasoning über große Dokumente. Das geräteinterne Modell ist klein. Ein 200-seitiger Vertrag, ein langer Codebase-Kontext oder Multi-Image-Reasoning über viele Fotos gehören in die Cloud-Inferenz (Ihre eigene oder die eines Anbieters), wo Kontextfenster und Parameteranzahl zur Workload passen. Aufgaben, die den Rahmen des Frameworks überschreiten, erzeugen konkrete Fehler: überschrittenes Kontextfenster, Guardrail-Verstöße, nicht unterstützte Lokalisierungen. Bringen Sie diese Fehler bewusst zum Vorschein, statt Abläufe zu entwerfen, die darauf angewiesen sind, dass das Modell rahmensprengende Arbeit bewältigt.

Geräte- und benutzerübergreifende Workflows. Das geräteinterne Modell hat nur Zugriff auf das, was die App in die Session ü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 Netzwerk-Primitiv.

Was ich in meinem Stack anders bauen würde

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

Eine Meditations-App könnte einen LLM-zusammengefassten „Wochenrückblick”-Bereich hinzufügen. Der naive Aufbau ist ein einziger Prompt: „Hier sind die Einträge des Benutzers für diese 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 Eintragsliste aufnehmen), token-teuer und produziert unstrukturierte Prosa. Der zweite ist robust (der Tool-Aufruf trennt „was passiert ist” von „wie darüber gesprochen wird”), günstig (das Modell holt nur, was es braucht) und strukturiert (das Ergebnis ist ein typisierter Swift-Wert).

Das Muster lässt sich sauber mit App Intents und MCP kombinieren. 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 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 geräteinterne LLM ist eine Laufzeitfunktion, kein Backend. Behandeln Sie es wie ein System-Framework mit einem Kontextfenster und einem geräteinternen Inferenz-Budget, nicht wie einen Remote-Dienst. Die architektonischen Entscheidungen betreffen 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 die Daten Ihrer App.

3. Die Routing-Regel zwischen Foundation Models, App Intents und MCP lautet „wer führt das Modell aus”. Die 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.

Drei Schwester-Beiträge gehen tiefer in das Foundation Models Framework: Foundation Models use cases zu den Workload-Fit-Entscheidungen, custom adapters zum Feinabstimmen des geräteinternen Modells auf App-Daten und the agentic workflow zur Aufteilung zwischen In-App- und Tooling-LLM.

Der vollständige Apple-Ecosystem-Cluster: typisierte App Intents für Apple Intelligence; MCP-Server für LLM-übergreifende Agenten; die Routing-Frage zwischen den beiden; Live Activities für die Lock-Screen-Zustandsmaschine; Liquid Glass patterns für die visuelle Ebene; multi-platform shipping für geräteübergreifende Reichweite. Der Hub befindet sich in der Apple Ecosystem Series. Für umfassenderen Kontext zu iOS mit AI-Agenten 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 geräteinterne Sprachmodell, das mit Apple-Intelligence-fähigen Geräten in iOS 26 (sowie iPadOS 26, macOS 26, visionOS 26) ausgeliefert wird. Das Framework stellt SystemLanguageModel, LanguageModelSession und das Tool-Protokoll bereit, sodass Apps typisierte, geräteinterne LLM-Aufrufe ohne Netzwerkzugriff ausführen können.

Wie funktioniert das Tool-Protokoll?

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

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 die In-App-Generierung ausführt. App Intents ist dafür gedacht, dass Apple Intelligence (der System-Agent) die typisierten Funktionen Ihrer App aufruft. MCP ist dafür gedacht, dass externe LLM-Hosts (Claude, ChatGPT etc.) 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 Implementierungen von Apples Tool-Protokoll, nicht 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 geräteinterne Modell für die Produktion gut genug?

Für die Anwendungsfälle, für die das Framework konzipiert ist (Umformatierung, Zusammenfassung, strukturierte Generierung über lokale Daten, leichtgewichtiges Tool-Calling), ja. Für Frontier-Reasoning über große Kontexte, multimodales Verstehen im großen Maßstab oder dokumentübergreifendes Reasoning, nein. Das geräteinterne Modell ist ein Modell mit 3 Milliarden Parametern und einem kleineren Kontextfenster als Cloud-LLMs; wählen Sie Workloads, die in den Rahmen passen.

References