Foundation Models auf Private Cloud Compute

Das geräteinterne Foundation Model hat ein Geschwistermodell bekommen. iOS 27 stattet das Framework mit einem serverskaligen Modell aus, das auf Private Cloud Compute läuft, mit einem Kontextfenster von 32K und Reasoning, und Sie erreichen es, indem Sie eine einzige Codezeile ändern¹. Dieselbe LanguageModelSession, dasselbe Generable, dasselbe Tool-Protokoll⁴. Der größere Schritt liegt darunter: Apple hat das Framework über ein öffentliches Protokoll für nahezu jedes LLM geöffnet, sodass das geräteinterne Modell, das Cloud-Modell, ein lokales Modell, das Sie ausliefern, ein Open-Source-Modell von Hugging Face und bald auch Claude und Gemini alle derselben Swift-API gehorchen². Sie programmieren nicht mehr gegen ein Modell, sondern gegen einen austauschbaren Steckplatz.

Dieser Beitrag bildet die Cloud- und Anbieterschicht oberhalb der Framework-Referenz. Falls Sie LanguageModelSession, das Tool-Protokoll oder die geführte Generierung noch nicht kennen, beginnen Sie mit der Erläuterung zum Foundation Models Framework und dem Beitrag zum Tool-Calling unter iOS 27 und kommen Sie dann zurück.

Kurzfassung

• Private Cloud Compute bringt ein größeres Servermodell in das Foundation Models Framework, umschaltbar durch das Ändern einer einzigen Zeile gegenüber dem geräteinternen Modell. Es bietet ein Kontextfenster von 32K gegenüber den geräteinternen 4K, unterstützt Reasoning auf drei Stufen und läuft unter iOS, macOS, visionOS und watchOS¹².
• Die Datenschutzhaltung entspricht der des Systemmodells: Apple hat PCC so konzipiert, dass Benutzerdaten niemals gespeichert und ausschließlich für die jeweilige Anfrage verwendet werden, unabhängig von Forschern verifiziert, ohne API-Schlüssel, ohne Kontoeinrichtung und ohne Token-Kosten für die Entwicklerin oder den Entwickler¹.
• Jeder Benutzer erhält ein tägliches Anfragelimit, das auf das iCloud-Konto angerechnet wird und über iCloud+ erweiterbar ist. Behandeln Sie das Limit in Ihrer UI, indem Sie den Kontingentzustand des Modells prüfen und ein dauerhaftes, handlungsorientiertes Bedienelement anzeigen statt einer Meldung. Beantragen Sie den Zugang auf der Entwickler-Website; verfügbar für Apps mit weniger als 2 Mio. Downloads¹.
• Das neue LanguageModel-Protokoll macht jedes Modell austauschbar: System, PCC, Core AI für lokale Modelle auf der ANE, MLX für die Hugging-Face-Community und künftig Anbieterpakete von Anthropic und Google².
• DynamicProfile lässt eine einzelne Session mitten im Gespräch zwischen diesen Modellen wechseln, sodass ein Brainstorming-Schritt PCC mit hoher Temperatur nutzen und ein Review-Schritt auf das geräteinterne Modell zurückfallen kann, um Serveraufrufe zu sparen³.

Ein größeres Modell, dieselben drei Zeilen

Letztes Jahr lautete die Botschaft, dass das Prompten des geräteinternen Modells drei Zeilen erfordert: eine Session erstellen, respond aufrufen, die Antwort lesen¹. Dieses Jahr erstreckt sich diese Botschaft auf die Cloud. Das Framework bietet eine einheitliche Swift-API, unabhängig davon, mit welchem Modell Sie sprechen, sodass der Wechsel vom geräteinternen Systemmodell zum PCC-Modell nur das Modell ändert, das Sie konstruieren, und sonst nichts¹. Strukturierte Ausgabe über Generable und Tool-Calling verhalten sich bei beiden identisch¹.

Louis in Session 319: Das Prompten des geräteinternen Modells erfordert drei Zeilen, und der Wechsel zum PCC-Servermodell ist eine Änderung von einer Zeile hin zu einem deutlich größeren Modell mit größerem Kontext und Reasoning.

Die Form des Austauschs, in den Begriffen des Frameworks selbst:

import FoundationModels

// On-device: the System model.
let onDevice = LanguageModelSession(model: SystemLanguageModel.default)

// Cloud: swap the model. Same session API, same prompts, same tools.
let cloud = LanguageModelSession(model: PrivateCloudComputeLanguageModel.default)

let summary = try await cloud.respond(to: "Summarize this 30-page contract.")

Die Symbolnamen stammen direkt aus der Session: Apple stellt das Cloud-Modell als PrivateCloudComputeLanguageModel bereit, und die Session zeigt die Kontextgröße, die über eine contextSize-Eigenschaft sowohl an SystemLanguageModel als auch an PrivateCloudComputeLanguageModel abgelesen wird¹. Weil das Cloud-Modell demselben LanguageModel-Protokoll entspricht wie jedes andere Modell, bemerkt der Rest Ihres Codes den Unterschied nicht².

Eine Einschränkung übernimmt sich vom geräteinternen Modell und verdient eine harte Prüfung: PCC läuft ausschließlich auf Geräten, die Apple Intelligence unterstützen. Prüfen Sie die Verfügbarkeits-API und behandeln Sie den Fall, dass Apple Intelligence nicht verfügbar ist, genauso, wie Sie das geräteinterne Modell bereits absichern¹.

Was PCC Ihnen bringt und was es kostet

PCC ist Apples Antwort auf die Anwendungsfälle, die das geräteinterne Modell nicht erreicht: Assistenten, die über große Benutzereingaben hinweg argumentieren, oder Funktionen, die viele Tool-Aufrufe mit großen Ausgaben auslösen¹. Der Kompromiss ist konkret statt gefühlsbasiert, und die Session stellt ihn als direkten Vergleich dar.

Zwei Zeilen tragen den größten Teil der Entscheidung. Der Sprung von 4K auf 32K macht die Funktion „ein langes Dokument mit Bildern zusammenfassen” auf dem Cloud-Modell tragfähig und auf dem geräteinternen beengt¹. Reasoning ist die andere: Wo eine schlichte Antwort den Prompt liest und generiert, erzeugt eine Reasoning-Antwort zusätzlichen Text in einem separaten Segment des Transkripts, bevor sie antwortet¹. Die drei Stufen skalieren dieses Denkbudget. Leicht sammelt etwas zusätzlichen Kontext, moderat argumentiert tiefer, und tief kann ein Reasoning-Segment erzeugen, das länger ist als die Antwort selbst¹. Sie legen die Stufe fest, wenn Sie respond auf der Session aufrufen¹.

Reasoning ist nicht umsonst. Das Reasoning-Segment ist Text, den das Modell erzeugt, daher verbraucht es Token und zählt gegen das Kontextbudget von 32K¹. Die Session ist unverblümt bezüglich der Disziplin, die das verlangt: Entscheiden Sie zwischen geräteintern und PCC und wählen Sie die Reasoning-Stufe anhand von Daten statt nach Gefühl¹. Apple hat in Xcode ein neues Evaluations-Framework genau dafür ausgeliefert, denn das geräteinterne Modell schneidet bei vielen Aufgaben besser ab, als Sie erwarten, und der einzige Weg, das zu wissen, ist zu messen¹.

Die Datenschutzhaltung ist die Schlagzeile

Ein Servermodell, das die privaten Eingaben des Benutzers verarbeitet, ist gewöhnlich die Stelle, an der die Datenschutzgeschichte auseinanderfällt. PCC ist so gebaut, dass das nicht passiert. Apple hat Private Cloud Compute mit Ende-zu-Ende-Datenschutz im Blick konzipiert und stellt sicher, dass Benutzerdaten niemals gespeichert und ausschließlich für die Anfrage verwendet werden, und Forscher haben das Design unabhängig verifiziert¹. PCC betreibt bereits Apple Intelligences eigene komplexe Aufgaben; das Framework öffnet eben diese Infrastruktur für Ihre App¹.

Die betrieblichen Konsequenzen sind der Teil, den Entwickler spüren. PCC ist neben iCloud in das Betriebssystem integriert, sodass keine Authentifizierung zu verdrahten ist, keine API-Schlüssel zu rotieren sind und keine Kontoeinrichtung vom Benutzer verlangt werden muss¹. Der Benutzer braucht ein Gerät, das Apple Intelligence unterstützt, und sonst nichts. Für Sie als Entwicklerin oder Entwickler entstehen keine Token-Kosten; jeder Benutzer erhält ein tägliches Limit, und Benutzer können es über iCloud+ erhöhen¹. Das Modell ist für Apps mit weniger als 2 Mio. Downloads verfügbar, und Sie beantragen es auf der Entwickler-Website¹.

Session 319 zu den Datenschutzgarantien: keine Kontoeinrichtung, keine Authentifizierung, keine API-Schlüssel und keine Token-Kosten für die Entwicklerin oder den Entwickler, wobei die Anfragen jedes Benutzers auf dessen iCloud-Konto angerechnet werden.

Update, 8. Juni 2026: PCC verlässt Apple silicon

In derselben Woche, in der die WWDC eröffnet wurde, veröffentlichte Apple einen Sicherheitsbeitrag, der ändert, wo PCC läuft. PCC erstreckt sich nun auf Google Cloud mit NVIDIA-GPUs für neue Apple-Intelligence-Workloads und „weitet unsere branchenführenden PCC-Datenschutzverpflichtungen erstmals auf Rechenzentren von Drittanbietern aus”⁵. Das Framework, auf das Sie abzielen, ändert sich nicht. Die Infrastruktur darunter schon.

Apple hält den Vertrag identisch. Die fünf Kernanforderungen bleiben exakt, wie sie waren: „stateless computation, enforceable guarantees, no privileged runtime access, non-targetability, and verifiable transparency”⁵. Was sich ändert, ist die Implementierung, die Apple als „NVIDIA Confidential Computing with NVIDIA GPUs, Intel CPUs with TDX, and Google’s Titan chip” benennt⁵. Apple härtet diese Basis in zwei Punkten über eine reine Confidential-Computing-Standardbereitstellung hinaus, die Entwickler beachten sollten. Es pflegt „a cryptographically verifiable, append-only ledger of all Google Cloud hardware that is part of the PCC fleet”, und für Komponenten, die Benutzerdaten exfiltrieren könnten, ist „software attestation is rooted in at least two separate roots of trust from independent vendors”⁵.

Die Zeile, die für die Datenschutzhaltung am meisten zählt, betrifft die Kontrolle. Apple erklärt, dass „Apple retains complete control over PCC software; Apple devices will only trust PCC software that is cryptographically approved by Apple”⁵. Die Verifizierungsgeschichte für Forscher überträgt sich ebenfalls: Apple sagt, es werde alle Binärdateien zur öffentlichen Inspektion veröffentlichen und über das Apple Security Bounty Program Zugang zu Live-PCC-Knoten im Forschungsmodus bereitstellen⁵. Der Rollout erfolgt gestaffelt, „ramping towards the complete set of protections throughout the summer preview period”, sodass eine Funktion, die Sie gegen PCC ausliefern, während der Vorschau eine bewegliche Reihe von Garantien erbt statt der endgültigen⁵.

Die Erkenntnis für den Code in diesem Beitrag: Die obigen Datenschutzaussagen gelten für das PCC-Modell, ob es nun von Apple silicon oder von Google Cloud aus antwortet, denn Apple behält dieselben fünf Anforderungen und dieselbe geräteseitige Vertrauensschranke bei. PCC ist außerdem Apples Erstanbieter-Antwort dort, wo Drittanbietermodelle nicht folgen können, was sich mit Apples Erstanbieter-Antwort auf Prompt Injection aus derselben Woche ergänzt.

Labornotiz: PCCs Garantien enden an der Framework-Grenze

Ein Punkt, gegenüber dem die WWDC-Labs unverblümt waren, lohnt sich neben dieser Erweiterung hervorzuheben, denn er zieht die Linie, die das Marketing nicht zieht. PCCs Garantien, statusloses Rechnen, Non-Targetability und ephemerer Speicher, erstrecken sich nicht auf Drittanbietermodelle, die Sie über das Sprachmodellprotokoll des Frameworks erreichen, etwa Gemini oder Claude. Wenn Ihre Session an ein Anbieterpaket statt an das System- oder PCC-Modell weiterleitet, liegt es in der Verantwortung der Entwicklerin oder des Entwicklers, die Bedingungen dieses Anbieters zu lesen und die daraus resultierenden Datenflüsse offenzulegen, einschließlich in den Datenschutz-Nährwertkennzeichnungen des App Store⁶. Das Protokoll gibt Ihnen eine Swift-API über alle Modelle hinweg, aber es gibt Ihnen nicht eine Datenschutzhaltung über sie hinweg. Diese Offenlegungsarbeit fällt Ihnen zu, nicht Apple.

Das tägliche Limit handhaben, ohne die UI zu zerstören

Das tägliche Limit ist die eine Stelle, an der ein Cloud-Modell in die UX eingreift, und die Session hat eine klare Meinung dazu, wie man damit umgeht. Anfragen werden auf das iCloud-Konto des Benutzers angerechnet, und eine Anfrage, die das Limit überschreitet, löst einen Fehler aus¹. Diesen rohen Fehler in der UI anzuzeigen, ist der falsche Schritt, denn der Fehler ist nicht handlungsorientiert¹.

Prüfen Sie stattdessen den Kontingentzustand am Modell und rendern Sie Ihr eigenes Bedienelement. Die Session prüft isLimitReached an der quotaUsage des Modells und zeigt, wenn das Limit überschritten ist, eine Schaltfläche, mit der der Benutzer sein Limit verwalten oder erhöhen kann¹. Zwei Regeln bestimmen die Darstellung. Verwenden Sie keine Meldung, denn der Limitzustand sollte bestehen bleiben, statt verworfen zu werden; aktualisieren Sie stattdessen den Zustand Ihrer UI, zum Beispiel indem Sie die Anfrage-Schaltfläche deaktivieren und darunter eine dezente Beschriftung mit einer Upgrade-Aktion anzeigen¹. Und erkennen Sie auch den herannahenden Fall: Das Modell stellt einen belowLimit-Zustand bereit, sodass Sie einen Benutzer warnen können, der nahe dran ist, und ihn entscheiden lassen, welche Anfragen es wert sind, ausgegeben zu werden¹.

// Sketch following the session's pattern.
let quota = PrivateCloudComputeLanguageModel.default.quotaUsage
if quota.isLimitReached {
    // Persistent label + upgrade button. No alert.
    showUpgradeAffordance()
} else if quota.belowLimit {
    // Optional: warn the user they are nearing the daily limit.
    showNearingLimitNotice()
}

Xcode hilft Ihnen, dies zu bauen, ohne echtes Kontingent zu verbrennen. In den Debug-Optionen des Schemas bietet die Einstellung „Simulate Apple Foundation Models Availability” die Optionen „Quota Usage Limit Reached” und „Nearing Usage Limit”, sodass Sie beide UI-Zustände im Simulator durchspielen können¹.

Bringen Sie Ihr eigenes LLM mit: das Anbieterprotokoll

Die tiefergehende Änderung in iOS 27 ist, dass Foundation Models aufgehört hat, ein Ein-Modell-Framework zu sein. Apple hat das geräteinterne Systemmodell neu aufgebaut und drei weitere Erstanbieteroptionen hinzugefügt und dann die Tür für alle anderen geöffnet. PCC bringt das Servermodell mit Reasoning und 32K Kontext. Core AI lässt lokale Modelle effizient auf der Apple Neural Engine laufen. MLX erschließt die Tausenden von Modellen der MLX-Community auf Hugging Face per Modell-ID². Und weil das alles auf einem neuen öffentlichen Protokoll aufsetzt, können Frontier-Anbieter eigene Swift-Pakete ausliefern; Apple nannte Anthropic und Google, die Claude und Gemini über dasselbe Framework zu Swift-Entwicklern bringen².

Christopher Webb in Session 339: Über das Systemmodell hinaus ergänzt das Framework PCC, Core AI und MLX, und ein öffentliches Protokoll erlaubt Anbietern wie Anthropic und Google, es mit eigenen Swift-Paketen zu erweitern.

Das Protokoll hat zwei Teile, und die Aufteilung ist das ganze Design. LanguageModel beschreibt das Modell gegenüber dem Framework: Es deklariert Fähigkeiten und gibt eine Konfiguration zurück. LanguageModelExecutor ist der Ort, an dem die Arbeit lebt, mit einem Initializer, der diese Konfiguration entgegennimmt, einem prewarm zum Laden von Gewichten oder Öffnen von Verbindungen vor der ersten Anfrage und einem respond, das die Generierung an die Session zurückstreamt². Die Konfiguration ist das Bindeglied zwischen beiden, und sie ist der Nachschlageschlüssel. Jede Session hält einen Executor-Store; wenn ein Modell eine Konfiguration erzeugt, die der Store noch nicht gesehen hat, baut das Framework einen Executor und cached ihn, und die Session beschreibt die Konfiguration als Hashable, sodass ein zweites Modell mit derselben Konfiguration auf denselben Executor aufgelöst wird². Dieses Caching ist das, was es einer zustandsbehafteten Integration erlaubt, einen KV-Cache oder eine dauerhafte Verbindung über Aufrufe hinweg zu halten, statt Arbeit zu wiederholen².

Für einen Modellanbieter ist die Aufgabe des Executors Übersetzung. Das Framework reicht ihm ein Transkript, eine Folge typisierter Einträge, und der Executor bildet diese Einträge auf die Rollen ab, die seine eigene Inferenz-Engine spricht². Apple definiert sechs Eintragstypen: Instructions, Prompts, Tool-Aufrufe, Tool-Ausgaben, Antworten und Reasoning². Ein Modell, das nur über System-, Benutzer- und Assistant-Rollen verfügt, bildet Tool-Aufrufe und Reasoning auf Assistant ab; ein Modell mit einer eigenen Tool-Rolle leitet stattdessen dorthin². Jede Anfrage trägt zudem die Absicht der Entwicklerin oder des Entwicklers in zwei Eigenschaftsbeuteln: ContextOptions für das, was in den Prompt geht, etwa die Reasoning-Stufe oder ein Antwortschema, und GenerationOptions für die Decoder-Schleife, etwa Sampling, Temperatur und Länge². Auf dem Rückweg streamt der Executor Ereignisse über einen Kanal, beginnend mit einem Metadaten-Update (Modell- und Anfrage-IDs) und einem Nutzungs-Update (Prompt-Token-Zählungen) vor den Text-Deltas, sodass die Entwicklerin oder der Entwickler die Kosten einer Anfrage erfährt, ohne auf den gesamten Stream zu warten².

Die Fehlergeschichte ist für App-Entwickler wichtig, selbst wenn sie nie einen Anbieter schreiben. Foundation Models liefert LanguageModelError für die Fälle, die jedes Modell trifft: Überläufe des Kontextfensters, Ratenbegrenzungen, Verweigerungen und mehr². Ein Anbieter sollte einen davon werfen, wenn er passt, denn jeder Framework-Nutzer weiß bereits, wie man ihn abfängt, und benutzerdefinierte Fehlertypen für Fehler reservieren, die nur sein eigener Dienst erzeugt, etwa eine Abonnementstufe oder einen Kontozustand². Anbieter erhalten außerdem Raum zur Differenzierung über benutzerdefinierte Antwort-Metadaten (Token pro Sekunde, Zeit bis zum ersten Token) und benutzerdefinierte Segmenttypen, die das Protokoll auf neue Modalitäten wie Audio oder Video erweitern, die alle durch dieselbe Session fließen². Cloud-Anbieter erhalten einen pointierten Hinweis zu Anmeldedaten: Nehmen Sie keinen API-Schlüssel als einfache Zeichenkette entgegen; bieten Sie einen Token-Provider oder einen Anmeldevorgang an, speichern Sie Token im Keychain und koppeln Sie es mit Geräteattestierung über App Attest².

Agentische Implikationen: Modelle innerhalb einer Session routen

Das Anbieterprotokoll und PCC zahlen sich aus, wenn Sie aufhören, an ein Modell pro App zu denken, und anfangen, an ein Modell pro Aufgabe zu denken. Genau das ermöglicht DynamicProfile. Es lässt eine einzelne LanguageModelSession mitten im Gespräch Modelle wechseln und die beste Konfiguration für die jeweils vorliegende Aufgabe auswählen³.

Erik und Oliver in Session 242: Eine Bastel-App deklariert Profile, die als Agenten agieren, brainstormt auf PCC mit hoher Temperatur, plant mit tiefem Reasoning und prüft auf dem geräteinternen Modell, um Serveraufrufe zu sparen.

Das Beispiel der Session ist eine Bastel-App mit drei Phasen. Brainstorming will breites Wissen und Kreativität, daher nutzt sein Profil PrivateCloudComputeLanguageModel mit auf 1 gesetzter Temperatur³. Planung will Tiefe, daher bleibt sie auf PCC und setzt reasoningLevel auf tief³. Review ist routinemäßige Anleitung, während der Benutzer arbeitet, daher fällt sie auf SystemLanguageModel zurück, um unnötige Serveraufrufe zu sparen, was zugleich das tägliche PCC-Kontingent des Benutzers für die Arbeit aufbewahrt, die es braucht³. Der Rumpf eines DynamicProfile wird bei jedem Prompt neu ausgewertet, sodass die Session, wenn die App den Modus wechselt, die Persona wechselt: den Hut tauschen oder den Agenten tauschen³.

Das Routen zwischen Modellen unterschiedlicher Kontextgröße erzwingt eine Disziplin, die das rein geräteinterne Framework nie verlangte. Der Wechsel von PCCs 32K auf die geräteinternen 4K kann das Beschneiden von Einträgen erfordern, damit sie passen, und die Session nennt auch einen Datenschutzzweck: private Informationen aus bestehenden Einträgen redigieren, wenn man zu einem weniger privaten Modell wechselt³. Der historyTransform des Frameworks wendet vor dem Prompten eine lokale, zerstörungsfreie Transformation an, sodass Sie für ein Modell beschneiden, ohne Kontext zu verlieren, den der nächste Schritt brauchen könnte³. Mutation kostet etwas: Das Anhängen an das Transkript bewahrt den KV-Cache und minimiert die Zeit bis zum ersten Token, während das Umschreiben der Historie (Einträge entfernen, Tools ändern, Instructions aktualisieren) den Cache typischerweise ungültig macht und Latenz hinzufügt³. Letztes Jahr war die Session-API append-only, um diese Optimierung zu garantieren; dieses Jahr hat Apple die Stützräder abgenommen, und der einzige Weg, das Caching-Verhalten eines Modells zu kennen, ist, mit dem Foundation Models Instrument in Xcode zu messen³.

Entscheidung: geräteintern, PCC oder Ihr eigener Anbieter

Die drei Optionen sind keine Leiter. Jede ist für eine andere Art von Problem richtig.

Greifen Sie zuerst zum geräteinternen Systemmodell. Es ist kostenlos, funktioniert offline, hat keine Anfragelimits, und der iOS-27-Neuaufbau hat es bei der Befolgung von Anweisungen verbessert und Bildeingabe hinzugefügt². Sein 4K-Kontext ist die eigentliche Obergrenze¹. Evaluieren Sie, bevor Sie annehmen, mehr zu brauchen, denn die Session warnt, dass Sie überrascht sein werden, wie gut es abschneidet¹.

Greifen Sie zu Private Cloud Compute, wenn die Aufgabe das geräteinterne Modell übersteigt und die Daten sensibel sind. Lange Dokumente, die das 32K-Fenster brauchen, mehrstufiges Reasoning oder viele Tool-Aufrufe mit großen Ausgaben¹. PCC ist die einzige Cloud-Option, die Apples Datenschutzhaltung beibehält, ohne Schlüssel, ohne Konto und ohne Token-Kosten, finanziert durch ein tägliches Limit pro Benutzer, um das herum Sie konzipieren¹. Wählen Sie es, wenn Sie sonst Ihr eigenes Servermodell aufsetzen und die Datenschutzprüfung fürchten würden.

Greifen Sie zu Ihrem eigenen Anbieter, wenn Sie ein bestimmtes Modell brauchen, das die Plattform nicht bietet. Core AI für ein lokales Modell, das Sie bündeln und auf der ANE ausführen, MLX für ein Open-Source-Modell per ID oder ein Anbieterpaket (Claude, Gemini) für ein Frontier-Modell². Sie übernehmen die Handhabung von Anmeldedaten, die Attestierung und die Datenschutzoffenlegung und erhalten im Gegenzug ein benanntes Modell hinter derselben LanguageModelSession, die Ihre App bereits spricht². Die Session ist ausdrücklich, dass geräteinterne und Cloud-Modelle sehr unterschiedliche Datenschutzeigenschaften haben und der Benutzer es verdient, zu wissen, welches gerade antwortet².

Mischen Sie sie in einer Session, wenn sich die Phasen unterscheiden. Das ist der DynamicProfile-Fall: PCC für die schweren kreativen oder Reasoning-Schritte, das geräteinterne Modell für routinemäßige, wobei jedes Profil sein eigenes Modell, seine Temperatur und seine Reasoning-Stufe trägt³.

FAQ

Wie wechsle ich vom geräteinternen Modell zu Private Cloud Compute?

Ändern Sie das Modell, das Sie an LanguageModelSession übergeben. Das Framework bietet eine einheitliche Swift-API über alle Modelle hinweg, sodass der Wechsel vom geräteinternen Systemmodell zu PrivateCloudComputeLanguageModel eine Änderung von einer Zeile ist und Ihre Prompts, Ihre Generable-Ausgabe und Ihre Tools gleich funktionieren¹. PCC läuft ausschließlich auf Geräten, die Apple Intelligence unterstützen, behalten Sie also Ihre Verfügbarkeitsprüfung bei¹.

Ist Private Cloud Compute so privat wie das geräteinterne Modell?

Apple hat PCC so konzipiert, dass Benutzerdaten niemals gespeichert und ausschließlich für die Anfrage verwendet werden, und das Design wurde von Forschern unabhängig verifiziert¹. Es ist neben iCloud in das Betriebssystem integriert, sodass es keine API-Schlüssel, keine Kontoeinrichtung und keine Authentifizierung gibt, die Sie verwalten müssten¹. Geräteintern gewinnt weiterhin beim Offline-Betrieb und bei unbegrenzten Anfragen; PCC gewinnt bei Kontextgröße und Reasoning¹.

Was kostet PCC, und wie hoch ist das tägliche Limit?

Für Sie als Entwicklerin oder Entwickler entstehen keine Token-Kosten¹. Jeder Benutzer erhält ein tägliches Anfragelimit, das auf das iCloud-Konto angerechnet wird, und Benutzer können über iCloud+ auf ein höheres Limit upgraden¹. Behandeln Sie das Limit in Ihrer UI, indem Sie den Kontingentzustand des Modells prüfen (isLimitReached, belowLimit) und ein dauerhaftes, handlungsorientiertes Upgrade-Bedienelement statt einer Meldung anzeigen¹. Das Modell ist für Apps mit weniger als 2 Mio. Downloads verfügbar, und Sie beantragen es auf der Entwickler-Website¹.

Was bedeutet „bringen Sie Ihr eigenes LLM mit” eigentlich?

Apple hat ein öffentliches LanguageModel-Protokoll hinzugefügt, sodass jedes Modell in das Foundation Models Framework eingebunden und über dieselbe API wie Apples eigenes aufgerufen werden kann². Über das Systemmodell und PCC hinaus ergänzt das Framework Core AI für lokale Modelle auf der ANE und MLX für Hugging-Face-Community-Modelle, und Apple nannte Anthropic und Google, die Swift-Pakete für Claude und Gemini ausliefern². Ein Anbieter implementiert LanguageModel plus einen LanguageModelExecutor, der das Transkript des Frameworks in sein eigenes Format übersetzt und die Generierung zurückstreamt².

Kann eine Session mehr als ein Modell verwenden?

Ja. DynamicProfile lässt eine einzelne LanguageModelSession mitten im Gespräch Modelle wechseln und die beste Konfiguration je Aufgabe wählen³. Ein Profil trägt sein eigenes Modell, seine Instructions, seine Temperatur und seine Reasoning-Stufe, und der Profilrumpf wird bei jedem Prompt neu ausgewertet, sodass eine Session im selben Gespräch auf PCC brainstormen und auf dem geräteinternen Modell prüfen kann³. Achten Sie dabei auf die Lücke in der Kontextgröße zwischen den Modellen und auf die KV-Cache-Kosten des Umschreibens der Historie³.

Das vollständige Apple-Ecosystem-Cluster: die Erläuterung zum Foundation Models Framework; die Tool-Calling-Steuerungen unter iOS 27; die Unterscheidung der agentischen Workflows; und das geräteinterne LLM. Der Knotenpunkt ist die Apple Ecosystem Series. Für breiteren Kontext zu iOS mit KI-Agenten siehe den iOS Agent Development Guide.