Foire aux questions sur l’utilisation de l’IA dans les applications Windows

Cela dépend de votre matériel cible et de votre cas d’usage. Windows API IA fournissent le chemin d’accès le plus simple pour Copilot+ PCs : appels d’API uniques pour OCR, description d’image, synthèse de texte et conversation Phi Silicon, sans aucune gestion des modèles requise. Foundry Local est le bon choix lorsque vous avez besoin d’un catalogue de modèles plus large, d’une prise en charge matérielle non Copilot+ PC ou d’un accès à l’API compatible OpenAI. Windows ML vous offre le plus de contrôle : apportez directement n’importe quel modèle ONNX et gérez les fournisseurs d’exécution. Pour une comparaison côte à côte, consultez Choisir votre solution IA Windows.

Cela dépend de la fonctionnalité que vous utilisez. Windows API IA nécessitent un Copilot+ PC avec un NPU. Foundry Local s’exécute sur n’importe quel appareil Windows avec un GPU compatible DirectX 12, y compris les appareils sans NPU. Windows ML prend en charge un large éventail de processeurs, de GPU et de processeurs réseau. Pour plus d’informations, consultez la liste matérielle prise en charge .

Yes. Foundry Local expose une API REST compatible OpenAI. Démarrez le service local avec foundry service start, puis pointez votre client OpenAI sur le point de terminaison local : le nom du modèle, les messages et les appels de diffusion en continu fonctionnent sans modification. Voir Get started with Foundry Local pour connaître le format de l’endpoint.

Les sdk natifs (C#, Python, JavaScript, Rust) sont actuellement en version alpha/préversion. Le runtime ONNX sous-jacent et l’infrastructure de service de modèle sont de niveau production. Pour les applications mises en production aujourd’hui, considérez la surface d’API du SDK comme susceptible d’évoluer et fixez les versions de vos packages. Consultez What is Foundry Local pour connaître le dernier état de stabilité.

Oui, une fois qu’un modèle est téléchargé et mis en cache sur l’appareil, Foundry Local effectue une inférence entièrement sur l’appareil sans dépendance cloud. Le téléchargement initial du modèle nécessite un accès Internet. Au démarrage, Foundry Local peut tenter d’actualiser le catalogue de modèles, mais cela n’est pas nécessaire : si l’appareil est hors connexion, il revient au catalogue mis en cache et l’inférence se poursuit normalement. La méthode IsCachedAsync (C#) / is_cached (Python) du SDK vous permet de vérifier la disponibilité du modèle avant de tenter d'effectuer une inférence, afin de pouvoir gérer correctement le cas où le modèle est hors ligne.

Foundry Local détecte le matériel disponible au démarrage et sélectionne le meilleur fournisseur d’exécution : Qualcomm NPU (QNN), tout GPU compatible DirectX 12 via WinML/DirectML (AMD, Intel, NVIDIA, Qualcomm), GPU NVIDIA via CUDA, ou le CPU comme solution de repli. Vous demandez un modèle par alias (par exemple phi-3.5-mini) et Foundry Local sert automatiquement la variante optimisée matériellement pour l’appareil. Votre code d’application est identique dans toutes les configurations matérielles.

Non. Foundry Local s’exécute entièrement sur l’appareil. Les données d’entrée et de sortie de l’inférence ne quittent jamais la machine. Le seul trafic réseau est le téléchargement initial du modèle et les actualisations facultatives des métadonnées de catalogue. Au démarrage, Foundry Local peut tenter d’actualiser le catalogue de modèles, mais cela n’est pas nécessaire : si l’appareil est hors connexion, il revient au catalogue mis en cache et l’inférence se poursuit normalement.

Windows API IA traitent les données localement sur l’appareil à l’aide du NPU. Les données d’entrée ne sont pas envoyées aux serveurs Microsoft. Pour obtenir des conseils sur les pratiques d’IA responsables, le consentement et la transparence, consultez Développement d’applications et fonctionnalités d’INTELLIGENCE artificielle responsable sur Windows.

Windows ML permet à votre application d’utiliser une version partagée d’ONNX Runtime à l’échelle du système et de télécharger dynamiquement des fournisseurs d’exécution (EP) propres aux fournisseurs, afin que l’inférence des modèles soit optimisée pour le processeur, le GPU ou le NPU de l’appareil, sans que votre application ait à embarquer de volumineux binaires du runtime ou des EP. Utilisez-le lorsque vous devez apporter votre propre modèle ONNX ou souhaitez contrôler complètement la sélection EP. Consultez la vue d’ensemble de Windows ML.

DirectML est une API d’accélération GPU de bas niveau pour le Machine Learning, basée sur Direct3D 12. Il prend en charge tous les GPU compatibles avec DirectX 12 d’AMD, Intel, NVIDIA et Qualcomm. ONNX Runtime utilise DirectML comme fournisseur d’exécution sur Windows lorsque CUDA n’est pas disponible.

foundry-local-sdk-winmlest le package spécifique Windows : il inclut l’accélération matérielle via Windows ML et est recommandé sur Windows. foundry-local-sdkest le package multiplateforme pour macOS, Linux ou Windows sans accélération matérielle. N’en installez qu’un seul : les deux paquets épinglent des versions différentes de onnxruntime-core et seront en conflit s’ils sont tous deux installés. Notez que foundry-local sur PyPI (sans -sdk) est un package tiers non lié — installation foundry-local-sdk ou foundry-local-sdk-winml.

Ouvrez le Gestionnaire des tâches (Ctrl+Shift+Esc), sélectionnez l’onglet Performances , puis recherchez les entrées GPU et NPU dans le volet gauche. Vous pouvez également exécuter foundry model list à partir de la ligne de commande : Foundry Local affiche les fournisseurs d’exécution actifs pour votre matériel lorsqu’il démarre le service.