Apple Foundation Models : le framework de LLM embarqué, expliqué

Le framework Foundation Models donne à une application un accès direct, gratuit et hors ligne au grand modèle de langage embarqué qui alimente Apple Intelligence¹. Aucune clé API, aucune facturation au token, aucun aller-retour réseau, aucune donnée qui quitte l’appareil. Pour toute une catégorie de fonctionnalités qui imposaient autrefois un LLM dans le cloud et une revue de confidentialité, le coût tombe désormais à zéro. La contrepartie porte sur les capacités : le modèle embarqué est petit, la fenêtre de contexte est limitée et le framework trace des frontières nettes autour de ce qu’il accepte ou refuse de faire. Connaître ces frontières, c’est tout l’enjeu.

Voici la référence sur le framework lui-même : les types que vous appelez réellement, la fonctionnalité qui justifie à elle seule son adoption, et le point où il faut s’arrêter pour passer à plus gros.

En résumé

• LanguageModelSession est le point d’entrée. Créez-en une, appelez respond(to:), récupérez du texte. Le contexte multi-tours vit dans la session ; un traitement en un seul tour reçoit une session neuve à chaque fois².
• La génération guidée est la raison d’utiliser ce framework. Annotez un type Swift avec @Generable et le modèle renvoie ce type, rempli et validé par le système de types, au lieu d’une chaîne de caractères qu’il faut analyser³.
• Le protocole Tool permet au modèle d’appeler votre code en cours de génération pour récupérer des données ou déclencher une action, puis d’intégrer le résultat à sa réponse⁴.
• Vérifiez SystemLanguageModel.default.availability avant toute chose. Le modèle est absent sur les appareils non éligibles, lorsque Apple Intelligence est désactivé, ou pendant son téléchargement⁵.
• La fenêtre de contexte est bien réelle, et étroite. SystemLanguageModel.default.contextSize indique le budget de tokens partagé entre l’invite et la réponse⁶. Sur l’appareil, ce budget est de 4 000 tokens ; le modèle Private Cloud Compute le porte à 32 000¹⁴. Anticipez-le, sinon la session lève une erreur.
• Nécessite iOS 26 et un appareil compatible Apple Intelligence. En dessous de ce seuil, le framework n’existe pas. Les bêtas d’iOS 27 étendent la même API avec l’entrée d’images, le contrôle de l’appel d’outils requête par requête, et un modèle serveur sur Private Cloud Compute¹²¹³¹⁴.

Ce qu’est le framework, et ce qu’il n’est pas

Foundation Models n’est pas une surcouche autour d’un point de terminaison dans le cloud. Le modèle réside sur l’appareil, est livré avec le système d’exploitation et s’exécute sur le Neural Engine. Ce seul fait gouverne chaque décision de conception de l’API et chaque décision que vous prenez en l’utilisant.

Ce que vous obtenez : génération de texte, résumé, classification, extraction, réécriture de textes courts et sortie structurée, le tout embarqué et gratuit. Ce que vous n’obtenez pas : un modèle de pointe. Apple a conçu le modèle embarqué pour des tâches linguistiques ciblées à l’intérieur d’une application, pas pour du raisonnement ouvert, pas pour l’analyse de longs documents, pas pour une culture générale que l’on pourrait interroger. Apple le dit explicitement, et ce cadrage compte : il fixe des attentes que l’API vous laissera sinon transgresser¹.

Le modèle mental qui vous évitera bien des ennuis : considérez le modèle embarqué comme un stagiaire rapide, discret et gratuit, excellent pour mettre en forme du texte et catastrophique dès qu’il s’agit de connaître des faits. Donnez-lui de la matière et une consigne claire. Ne lui posez pas de questions auxquelles il n’a aucun moyen de répondre.

LanguageModelSession : le point d’entrée

Toute interaction commence par une session.

import FoundationModels

let session = LanguageModelSession()
let response = try await session.respond(to: "Summarize this review in one sentence: \(reviewText)")
print(response.content)

La session conserve l’état de la conversation. Chaque appel à respond(to:) s’ajoute à la transcription en cours : une session que vous gardez en mémoire se souvient donc de ce qui précède. Pour une fonctionnalité de chat, c’est exactement ce qu’il faut. Pour des tâches ponctuelles indépendantes (résumer ceci, classer cela), créez une session neuve à chaque appel afin qu’aucun contexte périmé ne s’infiltre et ne dévore votre budget de tokens².

respond(to:) est async throws. La méthode suspend l’exécution pendant que le modèle travaille et lève une erreur quand la requête dépasse la fenêtre de contexte, quand le modèle est indisponible, ou quand les garde-fous rejettent le contenu. Chacun de ces cas est une branche réelle à traiter, pas un cas limite à ignorer.

Pour une interface réactive, préférez le flux continu à l’attente. streamResponse(to:) livre la sortie partielle au fil de la génération, ce qui transforme trois secondes de blocage en un texte qui s’écrit sous les yeux de l’utilisateur⁷.

Génération guidée : la fonctionnalité qui justifie le framework

Voici ce qui vaut à soi seul le détour. La plupart des intégrations de LLM consacrent un tiers de leur code à extorquer du JSON valide au modèle, et les deux autres tiers à se prémunir contre les fois où cela échoue quand même. Foundation Models supprime ce travail.

Annotez un type Swift avec @Generable, demandez à la session de le générer, et le modèle renvoie une instance de ce type, remplie et typée³ :

@Generable
struct Recipe {
    @Guide(description: "The dish name")
    let title: String

    @Guide(description: "Ingredients, each as 'quantity item'")
    let ingredients: [String]

    @Guide(description: "Total minutes, start to finish", .range(5...240))
    let minutes: Int
}

let session = LanguageModelSession()
let response = try await session.respond(
    to: "A weeknight pasta for two.",
    generating: Recipe.self
)
let recipe = response.content   // a Recipe, not a String

Aucune analyse syntaxique. Aucun JSONDecoder. Aucune boucle de nouvelle tentative pour une sortie malformée. La macro @Guide contraint chaque champ : une description que le modèle lit comme une instruction, et des limites facultatives comme une plage numérique ou une expression régulière que la sortie doit respecter⁸. Le framework ne demande pas poliment au modèle un nombre entre 5 et 240 ; il contraint le décodage pour que le champ ne puisse pas revenir autrement.

La discipline ainsi imposée constitue la vraie valeur. Vous concevez d’abord le type de sortie, en Swift, sous le contrôle du compilateur. Le modèle remplit un contrat que vous avez défini au lieu de renvoyer une prose qu’il faut décortiquer. Pour l’extraction, le remplissage de formulaires et toute fonctionnalité qui transforme du langage en données, la génération guidée fait la différence entre une démo et du code prêt à livrer.

Un réglage mérite d’être connu : respond(to:generating:) fixe includeSchemaInPrompt à true par défaut, ce qui injecte la structure de votre type dans l’invite pour orienter le modèle. Laissez-le activé, sauf si le modèle connaît déjà le format par son entraînement ou par les tours précédents de la session ; le désactiver pour économiser des tokens sur un format que le modèle n’a jamais vu, c’est la garantie de récupérer n’importe quoi⁹.

Appel d’outils : donner au modèle accès à votre code

La génération guidée façonne ce qui sort. L’appel d’outils change ce qui entre. Un outil est un fragment de votre code que le modèle peut invoquer en cours de génération pour obtenir une information dont il ne dispose pas ou pour effectuer une action, puis poursuivre sa réponse en s’appuyant sur le résultat⁴.

Un outil se conforme au protocole Tool : un name, une description que le modèle lit pour décider quand l’appeler, un type Arguments annoté @Generable, et une méthode call(arguments:) qui fait le travail⁴ :

struct FindContacts: Tool {
    let name = "findContacts"
    let description = "Find a specific number of contacts from the address book"

    @Generable
    struct Arguments {
        @Guide(description: "How many contacts to return", .range(1...10))
        let count: Int
    }

    func call(arguments: Arguments) async throws -> [String] {
        // Fetch contacts, return formatted names.
    }
}

let session = LanguageModelSession(tools: [FindContacts()])
let response = try await session.respond(to: "Draft a dinner invite to three of my contacts.")

Le déroulé : le modèle estime qu’il lui faut des contacts, appelle votre outil avec un count validé, vous renvoyez les données, et le modèle rédige l’invitation avec de vrais noms. Les arguments arrivent typés et vérifiés par la même mécanique de génération guidée : vous n’avez donc jamais à deviner l’intention du modèle dans du texte libre. La description de l’outil est votre seul levier sur le moment où le modèle y aura recours ; rédigez-la comme la documentation d’une fonction qu’un autre ingénieur, sans aucun autre contexte, devra lire et utiliser correctement.

C’est aussi le point de jonction où Foundation Models rejoint le reste de l’histoire des agents. Un outil appelé par le modèle embarqué et un App Intent¹¹ appelé par Apple Intelligence sont deux surfaces différentes de même forme : une capacité nommée, décrite et typée. Concevez la capacité une fois et vous pourrez l’exposer par les deux voies.

Disponibilité : la vérification incontournable

Le modèle n’est pas toujours là. Il est absent des appareils qui ne prennent pas en charge Apple Intelligence, quand l’utilisateur l’a désactivé, et pendant la fenêtre où le système d’exploitation télécharge encore les ressources du modèle. Livrez du code qui présuppose son existence et il plantera, se dégradera silencieusement ou se figera pour une partie de vos utilisateurs que vous n’aurez jamais testée.

Vérifiez SystemLanguageModel.default.availability et traitez chaque motif séparément⁵ :

switch SystemLanguageModel.default.availability {
case .available:
    // Show the intelligence feature.
case .unavailable(.deviceNotEligible):
    // Hide it. This device will never have the model.
case .unavailable(.appleIntelligenceNotEnabled):
    // Prompt the user to turn on Apple Intelligence.
case .unavailable(.modelNotReady):
    // Downloading or otherwise not ready yet. Try again later.
case .unavailable(let other):
    // Unknown reason. Fail closed.
}

Ces trois motifs appellent trois réponses produit différentes, et les confondre reste la manière la plus répandue de donner à ces fonctionnalités un air de dysfonctionnement. deviceNotEligible est définitif : masquez la fonctionnalité, n’insistez pas. appleIntelligenceNotEnabled relève d’un réglage que l’utilisateur contrôle : une invite unique est légitime. modelNotReady est temporaire : réessayez, n’affichez pas d’erreur. Construisez le chemin d’indisponibilité avec le même soin que le chemin nominal, car pour une part bien réelle des appareils, c’est le seul chemin.

Quand le modèle est disponible et que vous savez qu’une requête arrive, prewarm() sur la session le préchauffe pour que la première réponse arrive plus vite¹⁰. Utile sur un écran où l’utilisateur est sur le point d’agir, du gaspillage si vous l’appelez à tout hasard.

En pratique : une fonctionnalité complète dans un seul fichier

Les pièces ci-dessus se combinent en une vraie fonctionnalité avec moins de code que n’en réclament la plupart des couches réseau pour un seul point de terminaison. L’exemple ci-dessous est un écran SwiftUI complet et compilable qui transforme des notes de réunion libres en actions structurées : vérification de disponibilité, type de sortie @Generable, un appel de génération guidée, et les trois branches d’indisponibilité traitées. Chaque symbole provient de la surface du framework documentée plus haut²³⁵⁸.

import SwiftUI
import FoundationModels

@Generable
struct ActionItems {
    @Guide(description: "One-sentence summary of the meeting")
    let summary: String

    @Guide(description: "Concrete follow-up tasks, each starting with a verb")
    let tasks: [String]

    @Guide(description: "How urgent the follow-ups are overall", .anyOf(["low", "medium", "high"]))
    let urgency: String
}

struct MeetingNotesView: View {
    @State private var notes = ""
    @State private var result: ActionItems?
    @State private var errorMessage: String?

    var body: some View {
        Form {
            TextField("Paste meeting notes", text: $notes, axis: .vertical)
                .lineLimit(6...12)

            Button("Extract action items") {
                Task { await extract() }
            }
            .disabled(notes.isEmpty)

            if let result {
                Section(result.summary) {
                    ForEach(result.tasks, id: \.self) { Text($0) }
                    Text("Urgency: \(result.urgency)")
                }
            }

            if let errorMessage {
                Text(errorMessage).foregroundStyle(.secondary)
            }
        }
    }

    private func extract() async {
        switch SystemLanguageModel.default.availability {
        case .available:
            do {
                let session = LanguageModelSession()
                let response = try await session.respond(
                    to: "Extract the action items from these notes: \(notes)",
                    generating: ActionItems.self
                )
                result = response.content
            } catch {
                errorMessage = "The model could not process these notes."
            }
        case .unavailable(.appleIntelligenceNotEnabled):
            errorMessage = "Turn on Apple Intelligence in Settings to use this feature."
        case .unavailable(.modelNotReady):
            errorMessage = "The model is still downloading. Try again shortly."
        case .unavailable:
            errorMessage = "This feature needs an Apple Intelligence-capable device."
        }
    }
}

Trois détails méritent l’attention dans un exemple aussi bref. Le type de sortie est l’API : ActionItems définit exactement ce que produit la fonctionnalité, et la contrainte @Guide sur urgency garantit que la chaîne ne pourra pas revenir avec une valeur hors des trois autorisées⁸. La session est créée à chaque appel parce que chaque extraction est indépendante ; une session conservée traînerait les notes précédentes dans le budget de tokens². Enfin, les branches d’indisponibilité produisent trois expériences utilisateur distinctes, et non une erreur générique unique : c’est là toute la différence entre une fonctionnalité qui se dégrade honnêtement et une fonctionnalité qui semble cassée. Collez le fichier dans un projet iOS 26, exécutez-le sur un appareil compatible Apple Intelligence, et cela fonctionne.

La fenêtre de contexte, et le moment où elle ne suffit plus

SystemLanguageModel.default.contextSize indique le budget de tokens dans lequel le modèle travaille, et ce budget est partagé : l’invite et la réponse doivent tenir ensemble⁶. Le chiffre est modeste face à un modèle du cloud, et cela se ressent vite sur de vraies données. Un long document, un historique de conversation complet, un résultat d’outil volumineux : chacun peut faire exploser le budget et faire lever une erreur à respond.

Deux modes de défaillance en découlent, et il vous revient de les prévenir. D’abord la dérive lente : une session multi-tours accumule de la transcription jusqu’à ce qu’un tour de trop la fasse déborder. On la maîtrise en ouvrant des sessions neuves pour les travaux sans lien et en gardant une entrée sobre à chaque tour. Ensuite la requête unique surdimensionnée : un PDF de 20 pages ne rentre pas, point final. Découpez-le, résumez les morceaux, puis raisonnez sur les résumés (le map-reduce que les ingénieurs LLM connaissent bien), ou acceptez que la tâche n’ait pas la bonne forme pour un modèle embarqué.

La fenêtre de contexte est le signal le plus net pour la décision qui compte vraiment avec ce framework : quand rester sur l’appareil et quand le quitter. Les chiffres sont désormais publics : le modèle embarqué travaille dans un budget de 4 000 tokens, et le modèle serveur Private Cloud Compute porte ce budget à 32 000¹⁴. Tout ce qui suit sur le découpage s’applique avec ces ordres de grandeur en tête.

Ce qu’apportent les bêtas d’iOS 27

Tout ce qui précède décrit le framework tel qu’il est sorti dans iOS 26, et rien n’y est périmé. Les bêtas d’iOS 27 étendent la même surface dans quatre directions, dont aucune ne casse le modèle mental d’iOS 26¹².

L’invite accepte des images. Le modèle embarqué gagne des capacités de vision : vous insérez une pièce jointe image dans une invite aux côtés du texte et le modèle répond à propos des deux. Les nouveaux types sont Attachment, ImageAttachmentContent et ImageReference, et les pièces jointes acceptent UIImage, NSImage, CGImage, les types Core Image, les tampons de pixels CoreVideo et les URL de fichiers¹²¹³. Les images fonctionnent dans n’importe quelle taille et n’importe quel format, mais elles puisent dans le même budget de tokens que votre texte : la fenêtre embarquée de 4 000 tokens devient donc vite la contrainte de conception¹³. Le parcours complet se trouve dans L’entrée d’images de Foundation Models dans iOS 27.

L’appel d’outils gagne un régulateur. GenerationOptions reçoit un toolCallingMode que vous définissez requête par requête, lequel contrôle la façon dont le modèle interagit avec les outils que vous avez attachés, et le framework Vision fournit des implémentations prêtes à l’emploi, OCRTool et BarcodeReaderTool, que vous attachez à une session au lieu d’écrire votre propre code de reconnaissance¹⁵. Le détail du comportement est traité dans le contrôle de l’appel d’outils dans iOS 27.

Un modèle plus gros, à une ligne de distance. PrivateCloudComputeLanguageModel exécute la même API sur le modèle serveur d’Apple hébergé par Private Cloud Compute, derrière un droit d’accès, avec la fenêtre de contexte de 32 000 tokens et des capacités de raisonnement que le modèle embarqué n’a pas¹²¹⁴. La génération guidée et les outils fonctionnent à l’identique ; changer de modèle tient à l’argument model de la session.

Les sessions gagnent en marge de contrôle. Les bêtas ajoutent ContextOptions, TranscriptErrorHandlingPolicy, des profils dynamiques (DynamicInstructions, LanguageModelSession.DynamicProfile) et un protocole de fournisseur de modèle personnalisé (LanguageModel, LanguageModelExecutor) qui permet à une session de piloter un modèle que vous fournissez plutôt que celui du système¹². watchOS rejoint également la liste des plateformes en 27.0¹².

Ce qu’il faut retenir : le code iOS 26 compile et se comporte de la même façon sur iOS 27. Les bêtas élargissent ce qu’une invite peut transporter et l’endroit où le modèle peut s’exécuter ; elles ne changent pas la nature du framework.

Quand ne pas utiliser Foundation Models

Le framework est gratuit, confidentiel et hors ligne, ce qui donne envie d’y recourir partout. Résistez. Passez au-delà quand :

• Vous avez besoin d’un vrai raisonnement ou d’une culture générale étendue. Le modèle embarqué est petit par conception. Le raisonnement ouvert, la génération de code et l’analyse en profondeur relèvent d’un modèle de pointe dans le cloud. Les demander au modèle embarqué produit des réponses assurées et fausses.
• L’entrée ne tient pas dans la fenêtre de contexte et le découpage en détruirait le sens. Certaines tâches exigent de tout voir d’un coup.
• Il vous faut un modèle que vous contrôlez : un checkpoint précis, un modèle affiné, des poids personnalisés, un versionnage déterministe d’une mise à jour d’OS à l’autre. Apple livre et met à jour le modèle selon son calendrier, pas le vôtre.
• Vous êtes en dessous d’iOS 26 ou sur un appareil non éligible. Le framework n’existe tout simplement pas, et la vérification de disponibilité vous le rappellera à chaque exécution.

Pour les cas embarqués que le framework ne couvre pas (un modèle personnalisé, vos propres poids, un entraînement sur l’appareil), les couches en dessous sont Core ML pour un modèle converti figé, MLX pour les modèles à poids ouverts et les modèles affinés qui vous appartiennent, et Core AI dans iOS 27 quand il vous faut un contrôle explicite sur la spécialisation et l’ordonnancement. Pour les cas qui exigent réellement de l’échelle, Private Cloud Compute ou un LLM dans le cloud derrière une frontière de confidentialité reste la réponse honnête. Foundation Models ne remplace aucun d’entre eux. C’est le bon premier réflexe pour un travail linguistique ciblé sur du texte que vous détenez déjà, et le mauvais réflexe pour tout le reste.

La compétence que récompense ce framework n’est pas l’art de l’invite. C’est le discernement sur le périmètre : confier au modèle les tâches où il excelle, concevoir des types @Generable qui capturent exactement ce dont vous avez besoin, et reconnaître le moment où le travail dépasse les capacités de l’appareil. Développez avec ces réflexes et le modèle embarqué abattra gratuitement une quantité de travail surprenante. Ignorez-les et vous livrerez une fonctionnalité qui casse pour tout utilisateur dont l’entrée aura dépassé d’un token la limite.

FAQ

Le framework Foundation Models d’Apple est-il gratuit ?

Oui. Le framework donne à une application un accès direct, gratuit et hors ligne au modèle embarqué qui alimente Apple Intelligence. Il n’y a ni clé API, ni facturation au token, ni aller-retour réseau¹.

Quels appareils et quelle version d’iOS Foundation Models exige-t-il ?

Il exige iOS 26 et un appareil compatible Apple Intelligence. En dessous de ce seuil, le framework n’existe pas, et même sur un OS pris en charge, le modèle est absent sur les appareils non éligibles, quand Apple Intelligence est désactivé, ou pendant le téléchargement du modèle. Vérifiez toujours SystemLanguageModel.default.availability avant de l’utiliser⁵.

Comment obtenir une sortie structurée et typée plutôt qu’une chaîne de caractères ?

Annotez un type Swift avec @Generable et le modèle renvoie ce type, rempli et validé par le système de types, au lieu d’une chaîne qu’il faut analyser. Cette génération guidée est la seule fonctionnalité qui justifie à elle seule l’usage du framework³.

Quelle est la fenêtre de contexte du modèle embarqué d’Apple ?

SystemLanguageModel.default.contextSize indique le budget de tokens, partagé entre l’invite et la réponse générée⁶. Le modèle embarqué offre 4 000 tokens ; le modèle Private Cloud Compute en offre 32 000¹⁴. Les documents longs et les historiques multi-tours étendus dépasseront le budget embarqué : anticipez la limite, sinon la session lève une erreur.

Foundation Models fonctionne-t-il hors ligne, et envoie-t-il des données à Apple ?

Il s’exécute entièrement sur l’appareil, sur le Neural Engine. Aucune donnée ne quitte l’appareil et aucun aller-retour réseau n’est nécessaire, ce qui le rend adapté aux fonctionnalités qui exigeaient autrefois un LLM dans le cloud et une revue de confidentialité¹.

Le modèle embarqué peut-il appeler mon propre code en cours de génération ?

Oui. Le protocole Tool permet au modèle d’invoquer votre code pour récupérer des données ou déclencher une action pendant la génération, puis d’intégrer le résultat à sa réponse⁴.

Quand ne faut-il pas utiliser Foundation Models ?

Passez au-delà dès qu’il vous faut un modèle de pointe : raisonnement ouvert, génération de code, analyse de longs documents ou culture générale. Apple a conçu le modèle embarqué pour des tâches linguistiques ciblées à l’intérieur d’une application ; lui demander une intelligence générale produit des réponses assurées et fausses¹.

Qu’apporte iOS 27 à Foundation Models ?

Les bêtas d’iOS 27 ajoutent l’entrée d’images (pièces jointes dans l’invite, créées à partir d’UIImage, CGImage, de tampons de pixels et d’autres sources), le contrôle de l’appel d’outils requête par requête via GenerationOptions, les outils Vision prêts à l’emploi OCRTool et BarcodeReaderTool, ainsi que PrivateCloudComputeLanguageModel pour exécuter la même API sur le modèle serveur d’Apple à contexte de 32 000 tokens^12131415. Le code iOS 26 fonctionne sans modification.