Inférence IA sur Windows Server

L’inférence locale d’IA est le processus consistant à exécuter un modèle d’IA entraîné sur une infrastructure que vous ou votre organisation contrôlez. Le scénario principal de Windows Server est l’inférence distribuée : un serveur modèle compatible OpenAI fonctionne sur Windows Server, et les clients distants envoient des requêtes à leur point de terminaison via le réseau. Par exemple, Visual Studio Code sur une station de travail Windows 11 peut envoyer des requêtes au serveur et recevoir des résultats générés.

Les organisations utilisent l’inférence distribuée pour donner à plusieurs clients accès au calcul partagé du modèle tout en contrôlant où voyagent les requêtes et les sorties. Ce contrôle dépend de l’emplacement du point de terminaison, du trajet réseau, de la configuration du client, de l’acquisition de modèles, des diagnostics et d’autres services de la solution.

Cet article aide les administrateurs et développeurs Windows Server à décider quand utiliser l’inférence locale et à identifier les considérations d’infrastructure pour ce choix.

Comment fonctionne l’inférence IA sur Windows Server

Grâce à l'inférence locale par IA sur Windows Server, les applications et outils distants se connectent à l'adresse réseau du serveur modèle, envoient des requêtes et reçoivent des réponses. Les clients ne chargent ni ne font tourner le modèle localement.

Cette topologie confère à Windows Server un rôle distinct. Le serveur centralise la capacité de calcul et de GPU, le stockage et l’hébergement du modèle, l’accès au réseau, les opérations de service et la gestion de la capacité pour plusieurs clients. Les administrateurs gèrent le service partagé et son infrastructure, tandis que les développeurs configurent les clients pour l’URL de base du terminaison, l’identifiant de modèle, l’API prise en charge et la méthode d’authentification du point de terminaison.

La solution contient ces éléments :

  • Client distant : une application, un outil de développement ou un outil administratif qui envoie des invites ou d’autres entrées de modèle via le réseau. Les clients peuvent fonctionner sur Windows 11, Windows Server ou toute autre plateforme prise en charge.
  • Interface : Un SDK ou une API HTTP qui définit les formats de requête et de réponse. De nombreux environnements d’exécution partagés exposent par exemple des API compatibles OpenAI.
  • Modèle serveur et modèle : L’exécution orientée serveur qui charge un modèle entraîné, planifie les requêtes d’inférence et renvoie la sortie via le point de terminaison.
  • Infrastructure Windows Server : L’hôte physique ou la machine virtuelle, le processeur, la mémoire, le stockage, les ressources GPU, le réseau et les outils de gestion qui supportent et exposent la charge de travail partagée.

Un point de terminaison implémente un ou plusieurs formats d’API utilisés par les clients, mais la compatibilité ne signifie pas que chaque point de terminaison supporte toutes les capacités. Les clients peuvent nécessiter des routes spécifiques, des identifiants de modèle, un comportement de streaming, des appels d’outils ou de fonctions, des méthodes d’authentification ou des champs de requête. Confirmez à la fois les exigences du client et les capacités du point de terminaison avant de les connecter.

L’inférence embarquée a des limites différentes. L’application charge et exécute le modèle sur le même appareil, souvent dans le processus applicatif, au lieu d’appeler un serveur modèle. Windows ML fournit ce cadre d’inférence applicative pour les modèles ONNX. Foundry Local cible également les flux de travail intégrés à l’appareil. Le SDK local Foundry intègre l’exécution dans une application, et son interface en ligne de commande gère les modèles et un service local sur un seul appareil. Ces options peuvent fonctionner sur du matériel Windows Server, mais elles ne fournissent pas à elles seules un service d'inférence distribué que les administrateurs exploitent de manière centralisée pour plusieurs clients.

Choisissez votre approche d’inférence

Choisissez une approche basée sur l’endroit où l’inférence s’exécute, le nombre de clients nécessaires au modèle et qui exploite l’exécution. Utilisez Windows Server comme point d’accès partagé pour centraliser les modèles et calculer pour les clients distants. Cette approche ajoute des exigences de réseau, de sécurité, de capacité et de disponibilité. Autrement, utilisez l’inférence embarquée ou sur l’appareil dans Windows Server lorsqu’une application ou un appareil doit gérer le cycle de vie de l’environnement d’exécution et du modèle.

Approach Meilleur ajustement Modèle opérationnel Limites importantes
Point de terminaison Windows Server Plusieurs applications ou outils distants qui consomment un service modèle géré par une équipe centrale des opérations Un serveur modèle sur Windows Server gère le chargement des modèles, la planification des requêtes, la concurrence et l’API. Les clients distants utilisent l’URL de base du point de terminaison, l’identifiant de modèle et les paramètres d’authentification approuvés par leur organisation. Le produit que vous sélectionnez détermine l’installation à l’exécution, le déploiement des terminaux, le support de l’API et les caractéristiques de mise à l’échelle. Cet article part du principe que le point de terminaison existe et que les clients peuvent l’atteindre.
Windows ML Applications Windows qui exécutent des modèles ONNX sur le même appareil L’application utilise le runtime ONNX que Windows supporte, soit en tant que composant système partagé, soit en autonomie avec l’application. Les fournisseurs d’exécution optionnels utilisent les ressources CPU, GPU ou NPU disponibles. Windows ML est un cadre d’inférence applicative, et non un point de terminaison de service de modèles compatible OpenAI. Les exigences du fournisseur d’exécution, du pilote, du matériel et du modèle varient.
Foundry Local Applications et flux de développement nécessitant une inférence sur un seul périphérique, intégrée à l’appareil et un catalogue de modèles sélectionné L’application exécute généralement l’inférence en cours via le SDK. La CLI locale de Foundry peut gérer des modèles et un service local sur l’appareil. Foundry Local peut fonctionner sur du matériel serveur, mais sa conception ne vise pas l’inférence multi-utilisateur sur les serveurs. Il ne propose pas de file d’attente de requêtes simultanées, de batch continu ou de partage efficace des GPU pour de nombreux clients simultanés.

Les approches ne sont pas mutuellement exclusives au sein d’une organisation. Une application peut intégrer un modèle ONNX via Windows ML, un développeur peut utiliser Foundry Local sur un poste de travail, et des outils de développement à distance ainsi que des applications métier peuvent utiliser un point de terminaison partagé sur Windows Server. Traitez chaque chemin comme une charge de travail distincte, avec son propre modèle, matériel, sécurité et exigences de support.

Planifiez l’infrastructure Windows Server pour l’inférence IA

L’architecture du modèle, le nombre de paramètres, la quantification, la longueur du contexte, la concurrence des requêtes et les cibles de latence déterminent le calcul et la mémoire requis. Certains modèles fonctionnent sur un CPU, tandis que d’autres charges bénéficient de l’accélération GPU. Un GPU n’est pas un prérequis pour toutes les solutions d’inférence.

Pour une charge de travail sur un hôte Windows Server physique, l’exécution peut utiliser le matériel et les API que Windows Server et le fabricant matériel prennent en charge. Pour une charge de travail dans une machine virtuelle Hyper-V, sélectionnez une option de virtualisation GPU appropriée. Le plan d’accélération GPU dans Windows Server compare l’accès direct à l’hôte, l’attribution discrète de périphériques (DDA), le partitionnement GPU et les scénarios de conteneurs Windows. Le partitionnement GPU est disponible dans Windows Server 2025 ou ultérieur et constitue un choix d’infrastructure optionnel.

Prévoyez également ces ressources :

  • Mémoire et mémoire GPU : Prendre en compte le modèle chargé, les besoins contextuels et de cache, les requêtes concurrentes et les autres processus sur l’hôte.
  • Stockage : Fournir des contrôles de capacité et d’accès pour les fichiers modèles, les paquets à l’exécution, les journaux et les données temporaires. L’acquisition du modèle peut nécessiter une connexion réseau externe même lorsque l’inférence s’exécute localement.
  • Réseau : Pour un point de terminaison partagé, estimez la bande passante et la latence entre les clients et le point de terminaison. Définissez quels réseaux et hôtes peuvent accéder au service.
  • Disponibilité et capacité : Décidez comment les clients se comportent lorsque le point de terminaison est indisponible ou fonctionne à pleine capacité. Valider la concurrence et le débit à l’aide de modèles et de requêtes représentatifs avant toute mise en production.

Sécuriser et faire fonctionner l’inférence IA sur Windows Server

Le placement local ne constitue pas de frontière de sécurité en soi. Définir la frontière dans laquelle les requêtes, données récupérées, fichiers modèles, sorties, journaux et diagnostics doivent rester à l’intérieur, puis vérifier chaque composant par rapport à cette frontière.

Protéger le trafic réseau avec des paramètres TLS approuvés, authentifier et autoriser les clients, restreindre l’accès aux points de terminaison avec des contrôles réseau, et stocker les identifiants dans un magasin secret approuvé. Ne mettez pas de crédents dans les fichiers sources ou la configuration d’outils que d’autres utilisateurs peuvent lire. Examinez les licences modèles et les sources d’acquisition avant de déployer les fichiers modèles.

Validez la sortie du modèle avant de vous y fier. Maintenir une surveillance humaine appropriée pour les actions ou décisions conséquentes.

Gérez l’infrastructure Windows Server via vos outils d’administration établis, y compris Windows Admin Center lorsqu’il prend en charge les opérations requises. Suivez la documentation d’exécution relative au cycle de vie du modèle et aux opérations spécifiques au point de terminaison. Au minimum, prévoyez d’observer l’état des terminaux, la latence des requêtes, le débit, les pannes, l’utilisation du processeur et de la mémoire, l’utilisation du GPU et de la mémoire lorsque cela est applicable, ainsi que la capacité de stockage. Les métriques disponibles et les opérations de gestion varient selon le temps d’exécution, donc cet article ne prescrit pas une seule implémentation d’observabilité.

Scénarios d’inférence d’IA locale courants

L’inférence locale peut supporter les charges de travail des développeurs, administrateurs et applications tout en maintenant le chemin d’inférence dans la limite choisie par l’organisation.

  • Assistance au codage : Connectez un outil de développement pris en charge, tel que Visual Studio Code sur Windows 11, à un point de terminaison existant sur Windows Server pour une explication, une génération, une révision ou un dépannage de code. Le code source et les prompts transitent sur le réseau jusqu’à ce point de terminaison ; incluez donc le chemin réseau, le point de terminaison et ses opérateurs dans le périmètre des données.
  • Assistance administrative : Relier un outil administratif à un modèle capable d’expliquer ou de proposer des commandes. Examinez les commandes générées et comprenez leurs effets avant de les exécuter, surtout lorsqu’elles changent d’état système.
  • Traitement des documents : Utilisez une application pour résumer, classer, extraire ou indexer des documents avec un modèle local. L’application reste responsable de l’autorisation de sourcer les documents et les résultats générés.
  • Applications conversationnelles : Ajoutez des expériences de chat ou de questions-réponses à une application existante. L’application peut combiner un point de terminaison modèle avec des données d’entreprise autorisées, mais elle doit appliquer des contrôles d’accès indépendamment du modèle.

Prochaines étapes pour l’inférence locale de l’IA sur Windows Server

  • Last updated on