Foundation Models sur Private Cloud Compute

Le Foundation Model on-device a désormais un frère. iOS 27 dote le framework d’un modèle à l’échelle d’un serveur qui s’exécute sur Private Cloud Compute, avec une fenêtre de contexte de 32K et du raisonnement, et vous l’atteignez en changeant une seule ligne de code¹. Même LanguageModelSession, même Generable, même protocole Tool⁴. Le geste le plus important se trouve en dessous : Apple a ouvert le framework à presque n’importe quel LLM via un protocole public, de sorte que le modèle on-device, le modèle cloud, un modèle local que vous livrez, un modèle open source de Hugging Face, et bientôt Claude et Gemini répondent tous à la même API Swift². Vous cessez de coder face à un modèle pour commencer à coder face à un emplacement que vous pouvez interchanger.

Cet article constitue la couche cloud-et-fournisseur posée par-dessus la référence du framework. Si vous n’avez pas encore rencontré LanguageModelSession, le protocole Tool ou la génération guidée, commencez par l’explication du framework Foundation Models et l’article sur le tool calling d’iOS 27, puis revenez ici.

En bref

• Private Cloud Compute apporte un modèle serveur plus grand dans le framework Foundation Models, commutable en changeant une seule ligne par rapport au modèle on-device. Il offre une fenêtre de contexte de 32K contre 4K en on-device, prend en charge le raisonnement à trois niveaux, et s’exécute depuis iOS, macOS, visionOS et watchOS¹².
• La posture de confidentialité correspond à celle du modèle système : Apple a conçu PCC pour que les données utilisateur ne soient jamais stockées et soient utilisées uniquement pour la requête, ce qui a été vérifié de façon indépendante par des chercheurs, sans clés API, sans configuration de compte et sans coût en tokens pour le développeur¹.
• Chaque utilisateur dispose d’une limite quotidienne de requêtes décomptée sur son compte iCloud, augmentable via iCloud+. Gérez la limite dans votre UI en vérifiant l’état du quota du modèle et en affichant un contrôle persistant et exploitable plutôt qu’une alerte. Faites une demande d’accès sur le site développeur ; disponible pour les apps de moins de 2 M de téléchargements¹.
• Le nouveau protocole LanguageModel fait de chaque modèle un élément interchangeable : System, PCC, Core AI pour les modèles locaux sur l’ANE, MLX pour la communauté Hugging Face, et des packages de fournisseurs d’Anthropic et de Google à venir².
• DynamicProfile permet à une seule session de passer d’un de ces modèles à l’autre en pleine conversation, de sorte qu’un tour de brainstorming peut utiliser PCC avec une température élevée et qu’un tour de relecture peut basculer vers le modèle on-device pour économiser des appels serveur³.

Un modèle plus grand, les mêmes trois lignes

L’an dernier, l’argument était que solliciter le modèle on-device tient en trois lignes : créer une session, appeler respond, lire la réponse¹. Cette année, cet argument s’étend au cloud. Le framework offre une API Swift unifiée quel que soit le modèle auquel vous vous adressez, de sorte que passer du modèle System on-device au modèle PCC ne change que le modèle que vous construisez, et rien d’autre¹. La sortie structurée via Generable et le tool calling se comportent de façon identique entre les deux¹.

Louis dans la session 319 : solliciter le modèle on-device tient en trois lignes, et passer au modèle serveur PCC est un changement d’une seule ligne vers un modèle bien plus grand, doté d’un contexte plus vaste et du raisonnement.

La forme de la permutation, dans les termes mêmes du framework :

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.")

Les noms de symboles viennent directement de la session : Apple expose le modèle cloud sous le nom PrivateCloudComputeLanguageModel, et la session montre la taille du contexte lue depuis une propriété contextSize présente à la fois sur SystemLanguageModel et PrivateCloudComputeLanguageModel¹. Parce que le modèle cloud se conforme au même protocole LanguageModel que tous les autres modèles, le reste de votre code ne remarque pas la différence².

Une contrainte se reporte depuis le modèle on-device et mérite une vérification stricte : PCC ne s’exécute que sur les appareils prenant en charge Apple Intelligence. Vérifiez l’API de disponibilité et gérez le cas où Apple Intelligence est indisponible, de la même manière que vous conditionnez déjà le modèle on-device¹.

Ce que PCC vous apporte, et ce que cela coûte

PCC est la réponse d’Apple aux cas d’usage que le modèle on-device ne peut pas atteindre : des assistants qui raisonnent sur de grandes entrées utilisateur, ou des fonctionnalités qui déclenchent de nombreux appels d’outils aux sorties volumineuses¹. Le compromis est concret plutôt qu’à l’instinct, et la session le présente sous forme de face-à-face.

Deux lignes portent l’essentiel de la décision. Le passage de 4K à 32K est ce qui rend la fonctionnalité « résumer un long document avec des images » viable sur le modèle cloud et à l’étroit sur le modèle on-device¹. Le raisonnement est l’autre : là où une réponse simple lit le prompt et génère, une réponse avec raisonnement génère du texte supplémentaire dans un segment distinct de la transcription avant de répondre¹. Les trois niveaux dimensionnent ce budget de réflexion. Le niveau léger rassemble un peu de contexte supplémentaire, le niveau modéré raisonne plus en profondeur, et le niveau profond peut produire un segment de raisonnement plus long que la réponse elle-même¹. Vous définissez le niveau lorsque vous appelez respond sur la session¹.

Le raisonnement n’est pas gratuit. Le segment de raisonnement est du texte généré par le modèle : il consomme donc des tokens et est décompté du budget de contexte de 32K¹. La session est sans détour sur la discipline que cela exige : décidez entre on-device et PCC, et choisissez le niveau de raisonnement, à partir de données plutôt qu’à l’instinct¹. Apple a livré un nouveau framework Evaluations dans Xcode précisément pour cela, parce que le modèle on-device se comporte mieux que prévu sur de nombreuses tâches et que la seule manière de le savoir est de mesurer¹.

La posture de confidentialité est le grand titre

Un modèle serveur qui traite les entrées privées de l’utilisateur est généralement l’endroit où le récit de la confidentialité s’effondre. PCC est conçu pour que cela n’arrive pas. Apple a conçu Private Cloud Compute en pensant à une confidentialité de bout en bout, en garantissant que les données utilisateur ne sont jamais stockées et sont utilisées uniquement pour la requête, et des chercheurs ont vérifié la conception de façon indépendante¹. PCC alimente déjà les tâches complexes d’Apple Intelligence ; le framework ouvre cette même infrastructure à votre app¹.

Les conséquences opérationnelles sont la partie que les développeurs ressentent. PCC est intégré au système d’exploitation aux côtés d’iCloud, il n’y a donc aucune authentification à câbler, aucune clé API à faire tourner et aucune configuration de compte à demander à l’utilisateur¹. L’utilisateur a besoin d’un appareil prenant en charge Apple Intelligence, et rien de plus. Il n’y a aucun coût en tokens pour vous, le développeur ; chaque utilisateur dispose d’une limite quotidienne, et les utilisateurs peuvent l’augmenter via iCloud+¹. Le modèle est disponible pour les apps de moins de 2 M de téléchargements, et vous faites la demande sur le site développeur¹.

Session 319 sur les garanties de confidentialité : aucune configuration de compte, aucune authentification, aucune clé API et aucun coût en tokens pour le développeur, avec les requêtes de chaque utilisateur décomptées sur son compte iCloud.

Mise à jour, 8 juin 2026 : PCC quitte Apple silicon

La semaine même de l’ouverture de la WWDC, Apple a publié un article de sécurité qui change l’endroit où PCC s’exécute. PCC s’étend désormais à Google Cloud sur des GPU NVIDIA pour les nouvelles charges de travail d’Apple Intelligence, « étendant pour la première fois nos engagements de confidentialité PCC, leaders du secteur, à des centres de données tiers »⁵. Le framework que vous ciblez ne change pas. L’infrastructure en dessous, oui.

Apple maintient le contrat à l’identique. Les cinq exigences fondamentales restent exactement ce qu’elles étaient : « calcul sans état, garanties applicables, aucun accès privilégié au runtime, non-ciblabilité et transparence vérifiable »⁵. Ce qui change, c’est l’implémentation, qu’Apple nomme « NVIDIA Confidential Computing avec des GPU NVIDIA, des processeurs Intel avec TDX, et la puce Titan de Google »⁵. Apple renforce cette base au-delà d’un déploiement standard de confidential computing de deux façons que les développeurs devraient noter. Apple maintient « un registre cryptographiquement vérifiable, en ajout seul, de tout le matériel Google Cloud qui fait partie de la flotte PCC », et pour les composants qui pourraient exfiltrer des données utilisateur, « l’attestation logicielle est ancrée dans au moins deux racines de confiance distinctes provenant de fournisseurs indépendants »⁵.

La phrase qui compte le plus pour la posture de confidentialité concerne le contrôle. Apple déclare qu’« Apple conserve un contrôle complet sur le logiciel PCC ; les appareils Apple ne feront confiance qu’au logiciel PCC cryptographiquement approuvé par Apple »⁵. Le récit de vérification destiné aux chercheurs se reporte lui aussi : Apple indique qu’il publiera tous les binaires pour inspection publique et fournira un accès à des nœuds PCC en direct, en mode recherche, via l’Apple Security Bounty Program⁵. Le déploiement est échelonné, « montant en puissance vers l’ensemble complet de protections tout au long de la période de prévisualisation estivale », de sorte qu’une fonctionnalité que vous livrez face à PCC hérite d’un ensemble mouvant de garanties durant la prévisualisation, plutôt que de l’ensemble final⁵.

Ce qu’il faut retenir pour le code de cet article : les affirmations de confidentialité ci-dessus tiennent pour le modèle PCC qu’il réponde depuis Apple silicon ou depuis Google Cloud, parce qu’Apple conserve les cinq mêmes exigences et la même barrière de confiance côté appareil. PCC est aussi la réponse first-party d’Apple là où les modèles tiers ne peuvent pas suivre, ce qui fait pendant à la réponse first-party d’Apple à l’injection de prompt issue de la même semaine.

Note de labo : les garanties de PCC s’arrêtent à la frontière du framework

Un point sur lequel les labs de la WWDC ont été directs mérite d’être mis en avant à côté de cette expansion, car il trace la ligne que le marketing ne trace pas. Les garanties de PCC — calcul sans état, non-ciblabilité et stockage éphémère — ne s’étendent pas aux modèles tiers que vous atteignez via le protocole de modèle de langage du framework, comme Gemini ou Claude. Lorsque votre session est routée vers un package de fournisseur plutôt que vers le modèle System ou PCC, c’est au développeur qu’il revient de lire les conditions de ce fournisseur et de divulguer les flux de données qui en résultent, y compris dans les étiquettes nutritionnelles de confidentialité de l’App Store⁶. Le protocole vous donne une seule API Swift à travers les modèles, mais il ne vous donne pas une seule posture de confidentialité à travers eux. Ce travail de divulgation vous incombe, pas à Apple.

Gérer la limite quotidienne sans casser l’UI

La limite quotidienne est le seul endroit où un modèle cloud empiète sur l’UX, et la session a un avis tranché sur la façon de la gérer. Les requêtes sont décomptées sur le compte iCloud de l’utilisateur, et une requête qui dépasse la limite lève une erreur¹. Faire remonter cette erreur brute dans l’UI est une mauvaise décision, car l’erreur n’est pas exploitable¹.

À la place, vérifiez l’état du quota sur le modèle et affichez votre propre contrôle. La session vérifie isLimitReached sur le quotaUsage du modèle et, lorsque la limite est dépassée, affiche un bouton qui permet à l’utilisateur de gérer ou d’augmenter sa limite¹. Deux règles régissent la présentation. N’utilisez pas d’alerte, car l’état de limite devrait persister plutôt que d’être fermé ; mettez plutôt à jour l’état de votre UI, par exemple en désactivant le bouton de requête et en affichant en dessous un libellé discret accompagné d’une action de mise à niveau¹. Et détectez aussi le cas où l’on s’en approche : le modèle expose un état belowLimit pour que vous puissiez avertir un utilisateur qui est proche de la limite, en le laissant décider quelles requêtes valent la peine d’être dépensées¹.

// 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 vous aide à construire cela sans consommer de quota réel. Dans les Debug Options du scheme, le paramètre « Simulate Apple Foundation Models Availability » propose « Quota Usage Limit Reached » et « Nearing Usage Limit », de sorte que vous pouvez exercer les deux états d’UI dans le simulateur¹.

Apportez votre propre LLM : le protocole de fournisseur

Le changement le plus profond d’iOS 27 est que Foundation Models a cessé d’être un framework à modèle unique. Apple a reconstruit le modèle System on-device et a ajouté trois autres options first-party, puis a ouvert la porte à tous les autres. PCC apporte le modèle serveur avec raisonnement et un contexte de 32K. Core AI exécute efficacement des modèles locaux sur l’Apple Neural Engine. MLX déverrouille les milliers de modèles de la communauté MLX sur Hugging Face par identifiant de modèle². Et parce que tout cela repose sur un nouveau protocole public, les fournisseurs de pointe peuvent livrer leurs propres packages Swift ; Apple a cité Anthropic et Google comme apportant Claude et Gemini aux développeurs Swift via le même framework².

Christopher Webb dans la session 339 : au-delà du modèle système, le framework ajoute PCC, Core AI et MLX, et un protocole public permet à des fournisseurs comme Anthropic et Google de l’étendre avec leurs propres packages Swift.

Le protocole comporte deux pièces, et la répartition constitue toute la conception. LanguageModel décrit le modèle au framework : il déclare des capacités et renvoie une configuration. LanguageModelExecutor est l’endroit où réside le travail, avec un initialiseur qui prend cette configuration, un prewarm pour charger les poids ou ouvrir des connexions avant la première requête, et un respond qui diffuse la génération en flux vers la session². La configuration est le lien entre les deux, et c’est la clé de recherche. Chaque session détient un magasin d’exécuteurs ; lorsqu’un modèle produit une configuration que le magasin n’a pas encore vue, le framework construit un exécuteur et le met en cache, et la session décrit la configuration comme Hashable, de sorte qu’un second modèle avec la même configuration se résout au même exécuteur². C’est cette mise en cache qui permet à une intégration avec état de conserver un cache KV ou une connexion persistante d’un appel à l’autre, au lieu de refaire le travail².

Pour un fournisseur de modèle, le travail de l’exécuteur est de la traduction. Le framework lui remet une transcription, une séquence d’entrées typées, et l’exécuteur fait correspondre ces entrées aux rôles que parle son propre moteur d’inférence². Apple définit six types d’entrée : instructions, prompts, appels d’outils, sorties d’outils, réponses et raisonnement². Un modèle ne disposant que des rôles système, utilisateur et assistant fait correspondre les appels d’outils et le raisonnement à l’assistant ; un modèle doté d’un rôle d’outil dédié les y route à la place². Chaque requête transporte aussi l’intention du développeur dans deux sacs de propriétés : ContextOptions pour ce qui entre dans le prompt, comme le niveau de raisonnement ou un schéma de réponse, et GenerationOptions pour la boucle de décodage, comme l’échantillonnage, la température et la longueur². En sortie, l’exécuteur diffuse des événements sur un canal, en commençant par une mise à jour de métadonnées (identifiants de modèle et de requête) et une mise à jour d’usage (nombres de tokens du prompt) avant les deltas de texte, de sorte que le développeur connaît le coût d’une requête sans attendre la totalité du flux².

Le récit des erreurs compte pour les développeurs d’apps, même s’ils n’écrivent jamais de fournisseur. Foundation Models livre LanguageModelError pour les cas que tout modèle rencontre : dépassements de fenêtre de contexte, limites de débit, refus, et plus encore². Un fournisseur devrait en lever une lorsque cela convient, parce que tout utilisateur du framework sait déjà comment l’attraper, et réserver des types d’erreur personnalisés aux défaillances que seul son propre service produit, comme un palier d’abonnement ou un état de compte². Les fournisseurs disposent aussi d’une marge pour se différencier via des métadonnées de réponse personnalisées (tokens par seconde, temps avant le premier token) et des types de segment personnalisés qui étendent le protocole à de nouvelles modalités telles que l’audio ou la vidéo, le tout transitant par la même session². Les fournisseurs cloud reçoivent un rappel ciblé sur les identifiants : ne prenez pas une clé API sous forme de chaîne brute ; proposez un fournisseur de jetons ou un flux de connexion, persistez les jetons dans le Keychain, et associez cela à une attestation d’appareil via App Attest².

Implications agentiques : router des modèles à l’intérieur d’une seule session

Le protocole de fournisseur et PCC paient lorsque vous cessez de penser un modèle par app pour commencer à penser un modèle par tâche. C’est ce que permet DynamicProfile. Il laisse une seule LanguageModelSession changer de modèle en pleine conversation, en sélectionnant la meilleure configuration pour la tâche qui se présente³.

Erik et Oliver dans la session 242 : une app de loisirs créatifs déclare des profils qui agissent comme des agents, faisant du brainstorming sur PCC à température élevée, planifiant avec un raisonnement profond, et relisant sur le modèle on-device pour économiser des appels serveur.

L’exemple de la session est une app de loisirs créatifs à trois phases. Le brainstorming veut une connaissance large et de la créativité, son profil utilise donc PrivateCloudComputeLanguageModel avec la température fixée à 1³. La planification veut de la profondeur, elle reste donc sur PCC et fixe reasoningLevel à profond³. La relecture est un accompagnement de routine au fil du travail de l’utilisateur, elle bascule donc vers SystemLanguageModel pour économiser des appels serveur inutiles, ce qui préserve aussi le quota PCC quotidien de l’utilisateur pour le travail qui en a besoin³. Le corps d’un DynamicProfile se réévalue à chaque prompt, de sorte qu’à mesure que l’app change de mode, la session change de persona : elle change de casquette, ou change d’agent³.

Router entre des modèles de tailles de contexte différentes impose une discipline que le framework on-device uniquement n’a jamais exigée. Passer des 32K de PCC aux 4K on-device peut nécessiter de rogner des entrées pour tenir, et la session nomme aussi un usage lié à la confidentialité : caviarder les informations privées des entrées existantes lors d’un passage vers un modèle moins privé³. Le historyTransform du framework applique une transformation locale et non destructive avant de solliciter le modèle, de sorte que vous rognez pour un modèle sans perdre le contexte dont le tour suivant pourrait avoir besoin³. La mutation a un coût : ajouter à la transcription préserve le cache KV et minimise le temps avant le premier token, tandis que réécrire l’historique (supprimer des entrées, changer les outils, mettre à jour les instructions) invalide généralement le cache et ajoute de la latence³. L’an dernier, l’API de session était en ajout seul pour garantir cette optimisation ; cette année, Apple a retiré les petites roues, et la seule façon de connaître le comportement de mise en cache d’un modèle est de mesurer avec le Foundation Models Instrument dans Xcode³.

Décision : on-device, PCC, ou votre propre fournisseur

Les trois options ne forment pas une échelle. Chacune convient à une forme de problème différente.

Tournez-vous d’abord vers le modèle System on-device. Il est gratuit, fonctionne hors ligne, n’a aucune limite de requêtes, et la reconstruction d’iOS 27 l’a rendu meilleur pour le suivi des instructions et lui a ajouté l’entrée d’image². Son contexte de 4K est le vrai plafond¹. Évaluez avant de présumer que vous avez besoin de plus, car la session vous avertit que vous serez surpris de sa performance¹.

Tournez-vous vers Private Cloud Compute lorsque la tâche dépasse le modèle on-device et que les données sont sensibles. De longs documents qui exigent la fenêtre de 32K, un raisonnement multi-étapes, ou de nombreux appels d’outils aux sorties volumineuses¹. PCC est la seule option cloud qui conserve la posture de confidentialité d’Apple, sans clés, sans compte et sans coût en tokens, financée par une limite quotidienne par utilisateur que vous concevez en conséquence¹. Choisissez-le quand, autrement, vous monteriez votre propre modèle serveur et redouteriez la revue de confidentialité.

Tournez-vous vers votre propre fournisseur lorsque vous avez besoin d’un modèle spécifique que la plateforme ne vous donne pas. Core AI pour un modèle local que vous embarquez et exécutez sur l’ANE, MLX pour un modèle open source par identifiant, ou un package de fournisseur (Claude, Gemini) pour un modèle de pointe². Vous prenez en charge la gestion des identifiants, l’attestation et la divulgation de confidentialité, et en échange vous obtenez un modèle nommé derrière la même LanguageModelSession que votre app parle déjà². La session est explicite : les modèles on-device et cloud ont des caractéristiques de confidentialité très différentes, et l’utilisateur mérite de savoir lequel répond².

Mêlez-les dans une seule session lorsque les phases diffèrent. C’est le cas de DynamicProfile : PCC pour les tours créatifs ou de raisonnement lourds, le modèle on-device pour les tours de routine, chaque profil portant son propre modèle, sa température et son niveau de raisonnement³.

FAQ

Comment passer du modèle on-device à Private Cloud Compute ?

Changez le modèle que vous passez à LanguageModelSession. Le framework offre une API Swift unifiée à travers les modèles, de sorte que passer du modèle System on-device à PrivateCloudComputeLanguageModel est un changement d’une seule ligne, et vos prompts, votre sortie Generable et vos outils fonctionnent à l’identique¹. PCC ne s’exécute que sur les appareils prenant en charge Apple Intelligence, conservez donc votre vérification de disponibilité¹.

Private Cloud Compute est-il aussi privé que le modèle on-device ?

Apple a conçu PCC pour que les données utilisateur ne soient jamais stockées et soient utilisées uniquement pour la requête, et la conception a été vérifiée de façon indépendante par des chercheurs¹. Il est intégré au système d’exploitation aux côtés d’iCloud, il n’y a donc aucune clé API, aucune configuration de compte et aucune authentification à gérer de votre côté¹. L’on-device l’emporte toujours sur le fonctionnement hors ligne et les requêtes illimitées ; PCC l’emporte sur la taille de contexte et le raisonnement¹.

Que coûte PCC, et quelle est la limite quotidienne ?

Il n’y a aucun coût en tokens pour vous, le développeur¹. Chaque utilisateur dispose d’une limite quotidienne de requêtes décomptée sur son compte iCloud, et les utilisateurs peuvent l’augmenter via iCloud+ pour une limite plus élevée¹. Gérez la limite dans votre UI en vérifiant l’état du quota du modèle (isLimitReached, belowLimit) et en affichant un contrôle de mise à niveau persistant et exploitable plutôt qu’une alerte¹. Le modèle est disponible pour les apps de moins de 2 M de téléchargements, et vous faites la demande sur le site développeur¹.

Que signifie réellement « apportez votre propre fournisseur de LLM » ?

Apple a ajouté un protocole public LanguageModel, de sorte que n’importe quel modèle peut se brancher dans le framework Foundation Models et être appelé via la même API que celui d’Apple². Au-delà du modèle System et de PCC, le framework ajoute Core AI pour les modèles locaux sur l’ANE et MLX pour les modèles de la communauté Hugging Face, et Apple a cité Anthropic et Google comme livrant des packages Swift pour Claude et Gemini². Un fournisseur implémente LanguageModel plus un LanguageModelExecutor qui traduit la transcription du framework dans son propre format et diffuse la génération en retour².

Une seule session peut-elle utiliser plus d’un modèle ?

Oui. DynamicProfile permet à une seule LanguageModelSession de changer de modèle en pleine conversation, en choisissant la meilleure configuration par tâche³. Un profil porte son propre modèle, ses instructions, sa température et son niveau de raisonnement, et le corps du profil se réévalue à chaque prompt, de sorte qu’une session peut faire du brainstorming sur PCC et relire sur le modèle on-device dans la même conversation³. Surveillez l’écart de taille de contexte entre les modèles et le coût de cache KV de la réécriture de l’historique lorsque vous le faites³.

L’ensemble complet du cluster Apple Ecosystem : l’explication du framework Foundation Models ; les contrôles de tool calling d’iOS 27 ; la distinction du flux de travail agentique ; et le LLM on-device. Le hub est la Série Apple Ecosystem. Pour un contexte plus large sur iOS avec des agents d’IA, consultez le guide de développement d’agents iOS.