Local est une propriété de la charge
« Exécuter l’IA localement » peut désigner plusieurs architectures : un modèle intégré à une application de bureau, un serveur d’inférence dans un centre de données, un service Kubernetes sur infrastructure privée ou un système en périphérie proche des machines et capteurs.
Foundry Local répond à une forme précise : l’inférence est livrée avec l’application et exécutée sur l’appareil de l’utilisateur. Microsoft décrit des SDK pour plusieurs langages, un catalogue organisé de modèles optimisés, l’accélération matérielle automatique, la gestion du cycle de vie et une interface compatible OpenAI.
C’est utile — mais ce n’est pas une plateforme serveur multi-utilisateur.
Quand l’inférence sur l’appareil convient
Foundry Local est un candidat crédible lorsque la mission présente une ou plusieurs conditions :
- prompts et sorties doivent rester sur l’appareil pendant l’inférence ;
- l’application doit continuer sans connectivité ;
- la réponse ne peut pas attendre un aller-retour cloud ;
- un seul utilisateur interagit avec le modèle sur son matériel ;
- un modèle local pris en charge atteint l’objectif mesuré ;
- la distribution et la mise à jour des modèles sont maîtrisables.
Les exemples comprennent l’assistance documentaire privée sur un ordinateur géré, le support hors ligne sur le terrain, la transcription locale ou une application interactive utilisant un petit modèle pour classifier ou rédiger immédiatement.
L’exécution locale ne rend pas toute l’application privée. Téléchargements de modèles, mises à jour, diagnostics, synchronisation et éventuel repli cloud exigent toujours un flux documenté.
Quand elle ne convient pas
N’utilisez pas un runtime client comme plateforme serveur pour de nombreux utilisateurs simultanés. L’inférence partagée requiert files d’attente, traitement par lots, gestion de capacité, isolation et utilisation GPU conçus pour un service.
Le local peut aussi être inadapté si le processus nécessite un modèle trop grand pour le matériel, une recherche centralisée sur des sources changeantes, une performance uniforme sur des appareils très variés ou des contrôles que la flotte ne peut pas assurer.
« Aucun coût cloud par jeton » ne signifie pas absence de coût. Comptez le matériel, la distribution des modèles, le stockage, l’énergie, le support, les échecs de mise à jour et les tests sur le parc.
Concevoir explicitement la route hybride
Une application hybride peut utiliser plusieurs voies :
- un modèle local traite les tâches sensibles, routinières ou critiques en latence ;
- un modèle cloud géré traite les cas complexes demandant davantage de capacité ;
- une recherche privée prépare un contexte minimal ;
- une couche de politique décide si la requête peut quitter l’appareil ou la frontière ;
- le travail en attente se synchronise au retour de la connexion.
Le routeur devrait être déterministe lorsque c’est possible. Fondez-le sur la classification des données, le type de tâche, la connectivité, la capacité mesurée du modèle, le budget de latence et le consentement — pas sur un modèle sans contrainte choisissant lui-même où envoyer les données.
Rendez tout repli visible. Si le modèle local est indisponible, l’application ne doit pas envoyer silencieusement la requête vers le cloud.
Évaluer sur chaque appareil cible
Une variante locale peut se comporter différemment du modèle cloud utilisé en développement. Évaluez les modèles, la quantification, les prompts, le runtime et les classes de matériel qui seront réellement livrés.
Mesurez :
- réussite de la tâche et défaillances critiques ;
- temps de démarrage et latence ;
- mémoire, stockage et consommation d’énergie ;
- comportement sur CPU, GPU et NPU ;
- reprise hors ligne et après téléchargement interrompu ;
- compatibilité des versions et retour arrière ;
- différences entre les voies locale et cloud.
Figez les versions lorsque la reproductibilité compte. Traitez les mises à jour de modèle et de runtime comme des changements applicatifs soumis à la porte de livraison.
Exploiter la flotte
L’IA sur appareil déplace une partie des opérations vers le terminal. Définissez comment les modèles sont approuvés, distribués, mis en cache, supprimés et pris en charge. Sachez quelles versions sont actives et comment retirer un paquet vulnérable ou défectueux.
Ne collectez que la télémétrie nécessaire, dans les limites du consentement et de la confidentialité. L’inférence locale ne doit pas devenir une raison de copier des prompts sensibles dans des journaux centraux.
Choisir l’environnement suffisant le plus simple
Le bon déploiement est l’environnement le moins complexe qui satisfait qualité, confidentialité, latence, continuité, coût et responsabilité opérationnelle.
Utilisez l’appareil lorsqu’il constitue réellement la meilleure frontière. Utilisez un service géré ou privé lorsque capacité et contrôle centraux sont requis. Utilisez l’hybride uniquement lorsque des catégories de travail distinctes justifient la complexité supplémentaire de routage et d’observabilité.
Référence officielle
Microsoft explique le périmètre, les scénarios, le traitement local, la gestion des modèles et les limites serveur dans Qu’est-ce que Foundry Local ?.