Le modèle on-device d'Apple est terrible pour le chat mais étonnamment bon en structured output et tool calling

Je teste intensivement depuis plusieurs semaines le modèle on-device d’Apple — celui de ~3B paramètres qui tourne sur le Neural Engine de n’importe quel Mac avec Apple Silicon. Pour l’évaluer en profondeur, j’ai construit Think Local, une app macOS qui exerce chaque capacité du modèle : chat, génération d’images, structured output, tool calling et comparaison de paramètres.

Ma conclusion : comme chatbot, le modèle est décevant. Mais comme moteur de structured output et tool calling, il est étonnamment efficace.

Cette distinction est importante, car elle change complètement l’usage que vous devriez faire de ce modèle.

Le chat déçoit — et c’est acceptable

Le modèle d’Apple a une fenêtre de contexte de 4.096 tokens. Pour mettre cela en perspective : Claude dispose d'1M de tokens et GPT-4o de 128K. Avec Apple, vous ajoutez un system prompt de 200 tokens, un schema de 150 et trois tours de conversation, et vous atteignez déjà 70%.

La qualité du texte libre n’impressionne pas non plus. Les réponses sont correctes mais génériques, répétitives lors de sessions longues, et les garde-fous se déclenchent avec des faux positifs agaçants — demandez-lui des informations sur la sécurité informatique et il refuse parfois car il interprète “attaque” littéralement.

Si vous l’évaluez comme chatbot, c’est un modèle médiocre. Mais l’évaluer ainsi revient à critiquer un tournevis parce qu’il fait un mauvais marteau.

Là où il excelle : constrained decoding

C’est ici que tout change. Foundation Models supporte @Generable — un macro qui convertit un struct Swift en schema que le modèle est obligé de respecter. Ce n’est pas “demander du JSON et croiser les doigts”. C’est du constrained decoding : durant la génération, le modèle ne peut littéralement pas émettre de tokens qui violent le schema.

@Generable
struct BugReport {
    @Guide(.anyOf(["bug", "feature", "task"]))
    var type: String
    @Guide(.anyOf(["low", "medium", "high", "critical"]))
    var priority: String
    var title: String
    var description: String
}

Avec ce schema, vous dites “Classify: the app crashes when I rotate the device” et il retourne :

{
  "type": "bug",
  "priority": "high",
  "title": "Crash on device rotation",
  "description": "The application crashes when the user rotates..."
}

Les champs contraints (type, priority) sont toujours valides — il ne peut pas inventer une valeur hors de la liste. Les champs libres (title, description) sont cohérents et concis. Je l’ai testé avec des dizaines d’inputs différents : zéro erreur de schema en plus de 200 exécutions.

La différence entre génération libre et constrained decoding sur ce modèle est frappante. C’est comme la différence entre demander à un junior d’écrire ce qu’il veut versus lui donner un formulaire avec des champs définis. Le formulaire gagne toujours.

Tool calling : un modèle de 3B qui sait quand il ne sait pas

C’est ce qui m’a le plus surpris. Définissez un outil get_weather(city: String), demandez-lui “Quel temps fait-il à Madrid ?” et il génère un appel structuré avec les bons paramètres. Demandez-lui “Quelle est la capitale de la France ?” et il répond directement — il sait qu’il n’a pas besoin de l’outil.

Un modèle de 3B paramètres, tournant sur votre portable sans réseau, distingue quand utiliser un outil et quand ne pas l’utiliser. Ce n’est pas parfait — avec des prompts ambigus il se trompe parfois — mais le taux de réussite sur des inputs clairs est remarquable.

Le tool calling d’Apple utilise le même mécanisme de constrained decoding : l’invocation est un struct @Generable, donc les paramètres sont toujours valides. Pas de parsing JSON cassé ni de paramètres inventés.

Image Playground : l’autre modèle dont personne ne parle

Apple Intelligence n’est pas que du texte. Image Playground est un framework séparé qui génère des images on-device en trois styles : animation, illustration et croquis. Il tourne également entièrement sur le Neural Engine, sans réseau.

Le même schéma se répète : pour ce à quoi il est destiné, il fonctionne bien. Icônes, stickers, compositions simples — résultats étonnamment bons. Texte dans les images, anatomie humaine détaillée, compositions complexes — désastreux.

Think Local inclut un Image Studio où vous pouvez tester des prompts et comparer les styles côte à côte. L’intuition que vous obtenez en dix minutes de test de prompts, aucun benchmark ne peut vous la donner.

Les chiffres

Mesurés sur un Mac avec Apple Silicon, utilisant le moniteur de ressources de Think Local :

La donnée sur la batterie est pertinente : le Neural Engine consomme nettement moins que le CPU pour l’inférence. Durant la génération, le CPU augmente légèrement pour le marshalling et l’UI, mais le travail lourd va au Neural Engine. Cela rend viable l’utilisation du modèle en arrière-plan pour l’outillage — hooks git, linters, classificateurs — sans vider le portable.

À quoi il sert et à quoi il ne sert pas

Utilisez-le pour :

• Classification et triage (bugs, emails, tickets) → constrained decoding avec @Generable
• Extraction de données structurées depuis du texte libre → schemas avec @Guide
• Tool calling léger (rechercher, calculer, consulter) → invocations type-safe
• Brouillons et résumés de textes courts → dans la limite des 4K tokens
• Génération d’images simples (icônes, stickers, illustrations) → Image Playground
• Toute tâche où vous pouvez définir le format de sortie

Ne l’utilisez pas pour :

• Conversations longues → la fenêtre de 4K s’épuise en 3-4 tours
• Raisonnement complexe ou multi-étapes → le modèle est trop petit
• Génération créative longue → les réponses sont génériques et répétitives
• Tout ce qui nécessite des connaissances post-octobre 2023

Testez-le

Think Local est open source (MIT). L’app exerce toutes ces capacités avec une UI visuelle : un visualisateur de tokens qui affiche le contexte consommé en temps réel, un éditeur de schemas, un lab de tool calling, et un mode comparaison pour voir comment les réponses changent avec différents paramètres.

git clone https://github.com/frr149/think-local.git
cd think-local
open Package.swift

Prérequis : macOS 26, Apple Silicon, Apple Intelligence activé. Zéro dépendance, zéro clé API.

La conclusion

Apple n’a pas construit un chatbot. Il a construit un moteur d’inférence local avec constrained decoding et tool calling qui se trouve aussi pouvoir faire du chat. Si vous l’évaluez comme chatbot, il perd face à tout. Si vous l’évaluez comme moteur de structured output qui tourne gratuitement sur votre hardware, sans réseau et sans clés API — il n’a pas de concurrence. Littéralement personne d’autre n’offre cela.

La bonne question n’est pas “Apple peut-il concurrencer GPT-4 ?” — il ne le peut pas. La question est “Que puis-je construire avec un modèle de 3B qui tourne gratuitement, en local, avec constrained decoding ?” Et la réponse est : bien plus que vous ne le pensez.