Intel a annoncé les Inference Microservices le 14 octobre : des conteneurs propres à chaque modèle, chacun servant un grand modèle de langage sur des processeurs Xeon pris en charge. Au démarrage, le conteneur détecte l’hôte, sélectionne le profil Intel adapté à ce modèle et à ce processeur, puis lance vLLM derrière une API HTTP compatible avec OpenAI. Pour un développeur disposant de capacités Xeon, la première tâche consiste à déterminer si une image documentée peut traiter une requête d’application sur un réseau interne, puis à mesurer la charge sur cet hôte.

Les premières images publiées portent l’étiquette 0.1.0. Elles ciblent les Xeon de quatrième, cinquième et sixième génération avec une précision BF16, sous Linux avec Docker Engine 20.10 ou ultérieur, ou Kubernetes 1.24 ou ultérieur. La documentation décrit un paquet de service local, et non un point de terminaison hébergé par Intel : aucune clé API Intel n’est à obtenir. Les affirmations d’Intel selon lesquelles ses profils réduisent le travail de réglage ou améliorent les performances sont celles du fournisseur ; BIG CHANGE n’a pas exécuté ni évalué les images.

Ce qui change

  • Ce qui a changé : Intel a intégré des configurations vLLM propres à chaque modèle dans des conteneurs. Ceux-ci vérifient la présence d’un hôte Xeon pris en charge et choisissent un profil de service intégré avant d’exposer une API standard.
  • Pourquoi c’est important :Une application peut appeler un point de terminaison de chat familier, mais le conteneur ne fournit ni routage de l’application, ni authentification, ni TLS, ni conformité à la licence du modèle, ni preuve qu’une charge de travail donnée respecte ses objectifs de latence et de capacité.
  • À surveiller :Vérifiez si le modèle requis dispose d’une image de catalogue et d’un profil correspondant, puis testez la disponibilité, le comportement des réponses et la charge sur l’hôte prévu. Intel présente la prise en charge GPU, d’autres moteurs et précisions, un Helm chart et un operator comme des travaux à venir, pas comme des fonctions de cette première version.

Ce que gère le conteneur et ce qui reste à la charge de l’équipe

Selon Intel, la détection au démarrage tient compte de la génération Xeon, des cœurs disponibles, de la disposition NUMA et des capacités de processeur prises en charge. L’image propre au modèle résout un profil qui définit la précision, la répartition du travail et la disposition de la mémoire pour vLLM. En l’absence de profil correspondant au modèle, le démarrage échoue au lieu de basculer discrètement vers un profil général. L’image de base d’Intel pour d’autres modèles Hugging Face dispose d’un autre mécanisme de repli vers un profil général. Cette distinction compte pour savoir si un démarrage réussi correspond bien à la configuration particulière que l’équipe voulait évaluer.

L’API documentée expose GET /health, GET /v1/models, POST /v1/chat/completions, POST /v1/completions et GET /metrics sur le port 8000 par défaut. /health renvoie un HTTP 200 avec un corps vide lorsque le modèle est prêt, et un 503 tant qu’il ne l’est pas ; vérifier le code d’état est plus utile que chercher un corps de réponse. /v1/models renvoie l’unique ID du modèle servi. L’application doit fournir cet ID dans une requête de chat et choisir le routage si elle sert plusieurs modèles. Intel documente le streaming et des bibliothèques clientes compatibles avec OpenAI, mais la compatibilité de la forme de requête ne démontre ni la qualité ni la vitesse du modèle et du prompt propres à l’équipe.

Il existe aussi une limite de confiance explicite. Le guide de sécurité précise que le point de terminaison ne fournit ni TLS ni authentification des appelants. N’exposez pas le port 8000 sur un réseau public sans passerelle de protection ou frontière réseau. Pour Kubernetes, Intel recommande de limiter l’accès avec une NetworkPolicy et d’utiliser une passerelle ou un ingress pour TLS et l’authentification. Le service s’exécute sur l’infrastructure du client ; l’équipe est donc également responsable de la capacité de l’hôte, de l’emplacement du cache, de la surveillance et de l’accès aux poids de modèles soumis à restriction.

Une vérification locale documentée, puis un test de charge

Pour l’exemple public Qwen3-4B, le guide de démarrage rapide d’Intel donne cette commande Linux/Docker. Il s’agit uniquement d’une procédure documentée ; BIG CHANGE ne l’a pas exécutée :

Terminal
docker run --rm -p 8000:8000 \
  --cap-add SYS_NICE \
  --shm-size=2g \
  intel/inference-xeon-qwen-qwen3-4b:0.1.0

Intel indique que le premier démarrage télécharge les poids du modèle et peut prendre plusieurs minutes. Dans un second terminal, curl -i http://localhost:8000/health devrait afficher un HTTP 200 avec un corps vide lorsque le moteur est prêt. Ensuite, GET /v1/models devrait identifier Qwen/Qwen3-4B ; une requête POST /v1/chat/completions utilisant cet ID et un tableau messages devrait renvoyer une réponse de chat completion. Ces vérifications établissent seulement que le point de terminaison documenté a démarré et répond. Une décision de déploiement exige encore les mesures de l’équipe sur ses prompts, la concurrence, la latence et les ressources, ainsi que des vérifications du comportement lors de pannes et redémarrages.

Les prérequis suggèrent 32 Go de RAM et 50 Go d’espace disque libre pour le cache avec des modèles de 4B à 8B ; les modèles plus grands nécessitent davantage de mémoire. Ubuntu 22.04 LTS ou ultérieur est recommandé, même si l’exigence logicielle se limite à Linux capable d’exécuter Docker Engine 20.10 ou ultérieur. L’exemple Intel n’exige pas de jeton Hugging Face pour Qwen3-4B, et sa fiche du modèle indique Apache 2.0. D’autres modèles peuvent être soumis à des restrictions : leurs licences, autorisations d’accès et jetons de lecture doivent être vérifiés séparément. La documentation publique d’Intel n’indique aucun prix pour le logiciel microservices et ne fixe pas non plus les coûts matériels ou d’exploitation de ce déploiement.

La liste des fonctions prises en charge d’Intel distingue le parcours intégré et validé des options de pass-through vLLM. L’appel d’outils, la sortie structurée, LoRA et la modification de la longueur de contexte nécessitent des INFERENCE_ENGINE_ARGS indicateurs supplémentaires. Ils peuvent modifier ou invalider la configuration optimisée ; Intel recommande d’examiner la commande résolue avec dry-run et de tester le résultat sous charge. Traitez cela comme un projet d’intégration distinct, pas comme une capacité démontrée par l’image par défaut. Les déploiements Kubernetes peuvent ajouter des réplicas et des sondes de disponibilité, mais le routage entre modèles reste du ressort de l’application ou d’une passerelle. Les précédents articles d’Intel sur la série D portaient sur une annonce distincte de matériel GPU, pas sur cette version de service Xeon.

Sources et lectures complémentaires

  • Annonce d’Intel, 14 octobre 2026. Décrit le conteneur propre au modèle, la détection de l’hôte, les profils, le périmètre Xeon initial et les extensions prévues. Les affirmations sur le réglage et les performances sont celles d’Intel ; BIG CHANGE ne les a pas vérifiées de façon indépendante.
  • Documentation Intel Inference Microservices, indiquée comme mise à jour le 24 septembre 2026. Son 0.1.0guide de démarrage rapide fournit la commande Qwen3-4B et le premier parcours de santé/chat ; la procédure ci-dessus vient uniquement de la documentation.
  • Prérequis, référence de l’API, fonctions prises en charge et conseils de sécurité, documentation Intel indiquée comme mise à jour le 24 septembre 2026. Ces ressources définissent les hôtes pris en charge, les réponses de disponibilité, la distinction entre fonctions intégrées et pass-through vLLM, ainsi que la frontière HTTP sans authentification.
  • Fiche du modèle Qwen/Qwen3-4B, consultée le 15 octobre 2026. Elle indique la licence Apache 2.0 pour le modèle d’exemple ; d’autres modèles peuvent avoir des conditions et restrictions d’accès différentes.