Réservez de la capacité GPU à court terme pour vos workloads ML avec EC2 Capacity Blocks et SageMaker

Inférence adaptée à la capacité : basculement automatique entre instances pour les endpoints SageMaker AI

Amazon SageMaker AI vient d'introduire une fonctionnalité baptisée "capacity-aware instance pool" pour ses endpoints d'inférence, disponible immédiatement pour les nouveaux déploiements comme pour les endpoints existants. Concrètement, les équipes peuvent désormais définir une liste ordonnée de types d'instances GPU plutôt qu'un type unique, et SageMaker parcourt automatiquement cette liste dès qu'une contrainte de capacité se présente, que ce soit à la création de l'endpoint, lors d'un scale-out ou d'un scale-in. Cette mécanique de bascule automatique fonctionne pour les Single Model Endpoints, les endpoints basés sur des Inference Components, et les Asynchronous Inference endpoints. Les métriques Amazon CloudWatch bénéficient également d'une nouvelle dimension InstanceType, permettant de suivre latence, débit, utilisation GPU et nombre d'instances par type de matériel au sein d'un même endpoint. Jusqu'ici, le déploiement d'un modèle sur SageMaker imposait de choisir un seul type d'instance au moment de la création. Si ce type manquait de capacité, l'endpoint échouait avec une erreur "Insufficient Capacity", forçant les équipes à itérer manuellement sur des alternatives, chaque tentative prenant plusieurs minutes avant de connaître son issue. Le problème se répétait à chaque phase du cycle de vie : lors des montées en charge automatiques, l'autoscaler relançait indéfiniment des requêtes sur le même type d'instance indisponible pendant que le trafic continuait d'augmenter, et lors des descentes, toutes les instances étaient candidates à la suppression sans distinction de priorité. Avec les instance pools, SageMaker essaie le type préféré en premier, bascule immédiatement sur le suivant si nécessaire, et retire en priorité les instances de fallback lors des scale-in, laissant la flotte revenir naturellement vers le matériel privilégié quand il redevient disponible. Cette annonce s'inscrit dans un contexte où l'accès aux GPU reste l'un des goulots d'étranglement les plus critiques pour les organisations qui industrialisent des charges IA en production. Les grands modèles de langage et les architectures multimodales exigent des types d'instances spécifiques, souvent soumis à une forte tension sur les capacités cloud. AWS rejoint ainsi une tendance plus large dans laquelle les fournisseurs cloud intègrent nativement des mécanismes de résilience face aux pénuries de compute, réduisant la charge opérationnelle sur les équipes MLOps. La possibilité de migrer des endpoints existants sans reconstruction complète est un signal fort : AWS cible autant les workloads de production déjà déployés que les nouveaux projets. Les suites logiques seraient une extension à d'autres services d'inférence managés et une intégration plus fine avec les stratégies de spot instances pour optimiser les coûts tout en maintenant la disponibilité.

On a testé le MacBook Pro M5 Pro avec 48 Go de RAM : la config parfaite pour de l’IA locale ?

Apple a lancé début 2025 son MacBook Pro équipé de la puce M5 Pro, disponible à partir de 3 199 euros dans sa configuration 48 Go de RAM unifée. La version haut de gamme, le M5 Max avec 128 Go de mémoire, monte jusqu'à 6 429 euros sans augmentation du stockage. Des journalistes tech ont soumis cette machine à des tests intensifs de LLM locaux, faisant tourner des modèles open source tels que Mistral, DeepSeek, les modèles Alibaba Qwen et plusieurs variantes Google Gemma directement sur le matériel, sans connexion cloud. Ce type de configuration intéresse de plus en plus les développeurs, chercheurs et professionnels qui veulent exécuter des modèles de langage en local pour des raisons de confidentialité, de latence ou de coût. La mémoire unifiée des puces Apple Silicon est une architecture particulièrement adaptée à ce cas d'usage : contrairement aux PC classiques où la RAM et la VRAM sont séparées, le CPU et le GPU partagent le même pool mémoire, ce qui permet de charger entièrement des modèles de 30 à 70 milliards de paramètres sans swap. Les résultats des tests montrent des vitesses d'inférence utilisables au quotidien, loin derrière un GPU NVIDIA haut de gamme mais suffisantes pour un workflow professionnel autonome. Cette tendance s'inscrit dans un mouvement plus large de démocratisation de l'IA locale, accéléré par la sortie de modèles open source performants et compacts. Des acteurs comme Mistral AI, DeepSeek ou Alibaba proposent désormais des versions quantisées de leurs modèles optimisées pour ce type de matériel. Face aux interrogations croissantes sur la souveraineté des données et la dépendance aux API cloud, le couple Apple Silicon + ollama ou LM Studio s'impose comme une alternative crédible pour les professionnels prêts à investir plusieurs milliers d'euros dans une machine autonome.

💬 Le M5 Pro 48 Go, c'est le premier Mac où je me dis que l'IA locale est devenue praticable sans compromis majeur. Tu charges un modèle de 30 à 70 milliards de paramètres, ça tourne sur la même mémoire que le reste, pas de swap, pas de GPU externe à brancher. 3 200 euros de base, c'est cher, et la vitesse d'inférence reste loin d'un bon GPU NVIDIA, mais pour du travail autonome sur des données confidentielles, j'ai du mal à voir mieux dans ce format.

NVIDIA Spectrum-X, le réseau Ethernet ouvert conçu pour l'IA, s'impose comme référence à grande échelle, avec MRC

NVIDIA a annoncé que son infrastructure réseau Spectrum-X Ethernet intègre désormais le protocole MRC (Multipath Reliable Connection), une innovation développée conjointement avec OpenAI et Microsoft, et désormais publiée en spécification ouverte via l'Open Compute Project. MRC est un protocole de transport RDMA qui permet à une seule connexion réseau de distribuer le trafic sur plusieurs chemins simultanément, améliorant le débit, l'équilibrage de charge et la disponibilité des infrastructures d'entraînement IA à grande échelle. Parmi les premiers déploiements en production figurent le datacenter Fairwater de Microsoft et le datacenter Abilene d'Oracle Cloud Infrastructure, deux des plus grandes usines IA au monde dédiées à l'entraînement de modèles de pointe. OpenAI a notamment intégré MRC dans sa génération Blackwell : Sachin Katti, responsable du calcul industriel chez OpenAI, a confirmé que le protocole a permis d'éviter la majorité des ralentissements réseau habituels lors des runs d'entraînement frontier à grande échelle. L'enjeu est directement économique et computationnel : dans un cluster d'entraînement réunissant des milliers de GPU, la moindre interruption réseau peut bloquer l'intégralité d'un job d'entraînement, laissant des GPU à l'arrêt et brûlant des millions de dollars en temps de calcul inutilisé. MRC répond à ce problème en détectant les pannes réseau en quelques microsecondes et en reroutant automatiquement le trafic dans le matériel lui-même, sans intervention logicielle. Le protocole maintient également une bande passante élevée sous congestion en évitant dynamiquement les chemins surchargés en temps réel, et minimise l'impact des pertes de paquets grâce à une retransmission intelligente et ciblée. Les administrateurs gagnent par ailleurs une visibilité granulaire sur les chemins de trafic, ce qui simplifie considérablement les opérations à très grande échelle. Cette annonce s'inscrit dans une course mondiale à la construction d'infrastructures réseau capables de suivre l'explosion des besoins en calcul IA. Jusqu'ici, InfiniBand de Mellanox, aussi propriété de NVIDIA, dominait les clusters HPC et IA haute performance, tandis qu'Ethernet était perçu comme moins adapté aux charges de travail intensives. Spectrum-X représente la tentative de NVIDIA de rendre Ethernet compétitif sur ce terrain en y ajoutant une couche matérielle et protocolaire dédiée à l'IA. La publication de MRC comme spécification ouverte via l'Open Compute Project est un signal stratégique fort : en permettant à d'autres acteurs d'implémenter le protocole, NVIDIA cherche à imposer Spectrum-X comme standard de facto du réseau Ethernet pour l'IA, face aux alternatives comme Ultra Ethernet Consortium poussé par AMD, Intel et d'autres. La prochaine étape sera de voir si d'autres fournisseurs cloud et constructeurs de clusters adoptent MRC à leur tour.

Gemini tourne désormais sur un serveur isolé du réseau, et s'efface si on coupe le courant

Cirrascale Cloud Services a annoncé lors du Google Cloud Next 2026 à Las Vegas un accord élargi avec Google Cloud pour déployer le modèle Gemini en mode entièrement déconnecté, sur des serveurs physiques isolés d'internet. Cirrascale devient ainsi le premier fournisseur de cloud spécialisé à proposer le modèle phare de Google sous forme d'appliance privée, installée soit dans les centres de données de Cirrascale, soit directement dans les locaux du client. Le système repose sur un serveur certifié Google, fabriqué par Dell, équipé de huit GPU Nvidia et protégé par des mécanismes de calcul confidentiel. Une préversion est disponible immédiatement, avec une disponibilité générale attendue en juin ou juillet 2026. Dave Driggers, PDG de Cirrascale, a insisté sur un point clé : il s'agit du modèle Gemini complet, sans aucune restriction ni version allégée, déployé dans un environnement où les données d'entrée comme de sortie restent entièrement sous le contrôle du client. Fait notable sur le plan technique, les poids du modèle résident uniquement en mémoire volatile : dès que l'alimentation est coupée, le modèle disparaît sans laisser de trace persistante. Cette annonce répond à un problème structurel qui bloque depuis des années les secteurs régulés comme la finance, la santé, la défense et les administrations publiques. Ces organisations devaient jusqu'ici choisir entre accéder aux modèles les plus puissants via des API cloud publiques, au risque d'exposer leurs données sensibles à l'infrastructure d'un tiers, ou se contenter de modèles open source moins performants hébergés en interne. Le déploiement Cirrascale entend supprimer ce compromis. Driggers décrit l'escalade du problème de confiance : après les inquiétudes sur les données propriétaires confiées aux hyperscalers, les entreprises ont pris conscience que les prompts et les réponses générées étaient également récupérés par ces mêmes plateformes pour alimenter leurs propres systèmes, ce qui a rendu la demande de souveraineté totale incontournable. Cette évolution s'inscrit dans un mouvement plus large de migration des modèles d'IA frontier hors des centres de données des grands hyperscalers, vers les infrastructures propres des clients, ce qui représente une rupture avec la logique cloud dominante de la dernière décennie. Driggers distingue explicitement cette offre des déploiements on-premises proposés par Microsoft Azure avec les modèles OpenAI ou par AWS Outposts : dans ces cas, les modèles restent liés à l'infrastructure de leurs éditeurs. Ici, Google ne possède pas le matériel, et son modèle fonctionne en dehors de tout réseau Google. Pour le géant de Mountain View, accepter ce niveau de délégation sur son modèle le plus avancé traduit une stratégie commerciale claire : conquérir les marchés réglementés qui lui étaient jusqu'ici fermés, quitte à renoncer au contrôle direct de l'inférence.

💬 Le truc des poids uniquement en mémoire volatile, c'est la partie que je trouve la plus maligne. Parce que le blocage dans les secteurs régulés c'était pas juste "mes données sortent du réseau", c'était aussi "quelqu'un peut extraire ou copier le modèle", et là, coupe l'alimentation, ça disparaît. Google accepte de perdre le contrôle de l'inférence de son meilleur modèle pour aller chercher des marchés qui lui étaient fermés depuis des années. Ça, c'est un vrai mouvement.