Denise Muyco, cofondatrice et PDG de RAVEL – Série d’entretiens

Denise Muyco est cofondatrice et PDG de RAVEL, où elle dirige le développement de logiciels d’orchestration pour les infrastructures complexes de calcul et d’IA. Ingénieure de formation, elle a travaillé au fil de sa carrière dans les infrastructures énergétiques, l’optimisation des processus, les médias numériques, les centres de données et les studios virtuels. Avant de se consacrer à l’IA, elle a contribué à la mise en place d’une infrastructure de calcul haute performance partagée pour le secteur des effets visuels de Vancouver, donnant à une trentaine de studios accès à des ressources de calcul et à une connectivité sécurisée. Cette expérience a façonné sa manière d’aborder la coordination de ressources coûteuses et limitées. Chez RAVEL, elle met à profit une approche d’ingénierie des systèmes pour le placement des charges de travail, l’utilisation des infrastructures, l’interopérabilité et les besoins croissants des environnements d’IA distribués et souverains.

RAVEL développe des logiciels qui aident les organisations à déployer, gérer et faire évoluer des charges de travail de calcul et d’IA dans des infrastructures cloud, sur site et hybrides. Ses produits comprennent RAVEL Orchestrate, destiné aux stations de travail virtuelles haute performance, RAVEL Orchestrate AI, qui automatise et optimise les charges de travail, ainsi que Boost, consacré à la gestion des licences logicielles et à la télémétrie. Les outils de l’entreprise relient les infrastructures, les applications, la virtualisation et la sécurité, tout en offrant une gestion centralisée et une visibilité opérationnelle. RAVEL travaille avec des centres de données, des fournisseurs de services, des équipes informatiques d’entreprise, des groupes de recherche en IA et des studios de création. Forte de ses origines dans la création de contenus numériques, l’entreprise s’attache à simplifier les environnements complexes et à aider les équipes à tirer le meilleur parti des infrastructures dont elles disposent.

Vous avez fondé RAVEL après avoir travaillé pendant des années à la croisée de l’ingénierie, des infrastructures des médias et du calcul distribué. Qu’est-ce qui vous a finalement amenée à créer l’entreprise, et comment la mission de RAVEL a-t-elle évolué à mesure que l’IA générative faisait considérablement augmenter la demande en ressources de calcul ?

Je suis ingénieure de formation et je travaille à la croisée de l’énergie, du calcul et des infrastructures depuis bien avant l’essor actuel de l’IA. Au début de ma carrière, j’ai effectué un stage dans une centrale nucléaire. Plus tard, mes activités dans les médias et les effets visuels m’ont fait découvrir les GPU, les besoins importants en calcul et les contraintes liées aux infrastructures physiques.

Il y a environ 16 ans, le secteur des effets visuels, en pleine croissance à Vancouver, se heurtait directement à ces contraintes. Pour traiter (ou rendre) des contenus de cinéma et de télévision toujours plus complexes dans le cadre de projets à forte valeur, les studios avaient besoin d’énormes capacités de calcul haute performance. Pourtant, peu d’entre eux pouvaient justifier la construction d’infrastructures dédiées suffisantes pour répondre aux pics de demande dans un environnement sécurisé. L’alimentation électrique devenait également une contrainte. Nous avons développé une infrastructure partagée qui a donné à une trentaine de studios accès au calcul haute performance et à une connectivité sécurisée à haut débit.

Le partage des infrastructures a résolu un problème, mais en a créé un autre : comment répartir efficacement des ressources coûteuses et limitées entre différentes organisations et charges de travail ? Cette expérience a finalement conduit RAVEL à adopter une approche fondée sur l’orchestration intelligente des infrastructures.

L’IA représente une version beaucoup plus vaste du même défi fondamental, avec une complexité et des capitaux en jeu bien plus importants. Les charges de travail et les infrastructures ont changé, mais il est devenu encore plus essentiel de faire fonctionner efficacement ensemble des ressources coûteuses et limitées.

Avant RAVEL, vous avez contribué à créer un consortium réunissant une trentaine de studios, plateaux de tournage, sociétés de production et entreprises d’effets visuels de Vancouver, qui pouvaient partager l’accès à une infrastructure de calcul haute performance. Que vous a appris cette expérience sur le calcul distribué, et quels parallèles voyez-vous entre les défis du rendu à Hollywood à l’époque et les enjeux actuels de l’infrastructure dans le secteur de l’IA ?

Mon travail avec le secteur des effets visuels m’a appris que construire et configurer l’infrastructure ne représentait que la moitié du problème. Il fallait partager les ressources de calcul coûteuses en toute sécurité et les utiliser efficacement, tout en veillant au bon fonctionnement de l’ensemble de l’infrastructure, notamment d’un réseau sécurisé capable de transférer d’énormes fichiers. Il fallait planifier les charges de travail, répartir les capacités et déplacer des volumes considérables de données, tandis que les équipes de production cherchaient à obtenir des résultats toujours plus ambitieux, dans le respect de budgets et de délais stricts. L’infrastructure devait être optimisée en permanence pour améliorer son taux d’utilisation et ses performances.

L’IA représente une version beaucoup plus vaste de ce même défi fondamental. Les organisations investissent massivement dans les infrastructures, mais augmenter les capacités ne garantit pas à lui seul une utilisation efficace de ressources coûteuses. Les infrastructures d’IA sont également de plus en plus réparties entre différents sites, fournisseurs et environnements, sous l’effet des contraintes liées à l’énergie, aux capacités, à la sécurité, aux coûts, à la géographie, à la réglementation et à la souveraineté. Le rendu et l’IA correspondent à des charges de travail très différentes, mais ils partagent un défi important sur le plan des infrastructures et de l’écosystème : tous deux dépendent d’une collaboration efficace entre le calcul haute performance, les réseaux, la sécurité et le stockage.

À mesure que les infrastructures d’IA se complexifient, ajouter des capacités de calcul ne suffit pas à résoudre le défi opérationnel qui consiste à les utiliser efficacement. C’est là que l’orchestration et les politiques qui régissent l’écosystème élargi des infrastructures deviennent essentielles. Ensemble, elles aident les organisations à mieux exploiter des ressources coûteuses et limitées, tout en coordonnant les charges de travail dans des environnements toujours plus distribués.

RAVEL se présente comme une couche d’orchestration pour les usines d’IA distribuées. Que signifie pour vous une « usine d’IA », et que manque-t-il aujourd’hui à la pile d’infrastructure pour qu’une couche d’orchestration soit nécessaire ?

À mes yeux, une usine d’IA ne se résume pas à des GPU et à des grappes de calcul haute performance : c’est un écosystème d’infrastructure intégré qui réunit calcul, réseau, stockage, sécurité, alimentation électrique, refroidissement et couches opérationnelles nécessaires à l’exécution des charges de travail d’IA. Les usines d’IA évoluent : de grappes isolées, elles deviennent des écosystèmes de ressources interconnectées réparties sur plusieurs sites et régions. Cette complexité devient de plus en plus difficile à gérer manuellement ou à l’aide de solutions ponctuelles disparates. Une couche d’orchestration répond à ce problème en coordonnant les éléments divers et complexes de la pile et en masquant une partie de cette complexité sous-jacente. L’infrastructure est ainsi plus facile à gérer comme un système coordonné.

Alors que les organisations adaptent leurs centres de données existants à l’IA, nombre de ces installations n’ont pas été conçues à l’origine pour répondre aux exigences des charges de travail d’IA actuelles. L’IA se heurte aujourd’hui à un décalage structurel qui se manifeste sous la forme de trois problèmes majeurs. Le premier concerne l’alimentation électrique : il faut trouver un emplacement disposant d’une alimentation suffisamment fiable pour exécuter des charges de travail à grande échelle. Le deuxième est la fragmentation de l’écosystème : les piles d’IA sont souvent réparties dans des environnements isolés qui ne sont pas conçus pour fonctionner ensemble. Le troisième est le manque de visibilité sur le coût total d’exploitation et de possession, qui peut masquer le coût réel de l’infrastructure d’IA. Résultat : les charges de travail peuvent être mal optimisées, le matériel sous-utilisé et les coûts d’exploitation imprévus peuvent faire grimper le coût total de possession, contribuant ainsi à augmenter le coût par jeton.

L’infrastructure d’IA est de plus en plus répartie entre des clouds hyperscale, des centres de données privés, des systèmes sur site et des fournisseurs spécialisés en GPU. Quels sont les principaux défis auxquels les organisations sont confrontées lorsqu’elles tentent de gérer des charges de travail d’IA dans ces différents environnements ?

Depuis plusieurs années, la course à l’infrastructure d’IA repose sur une hypothèse simple : construire plus grand. Des centres de données plus grands. Des grappes plus grandes. Davantage de GPU. Plus de capacité. Mais le modèle qui consiste à construire toujours plus grand se heurte de plus en plus à des contraintes physiques, économiques et réglementaires.

L’alimentation électrique est limitée. L’accès au réseau prend du temps. Les facteurs économiques, la géographie et la souveraineté déterminent de plus en plus où les infrastructures peuvent et doivent être construites. Le nouveau défi ne consiste pas simplement à bâtir davantage d’infrastructures d’IA, mais à construire les bonnes infrastructures aux bons endroits, tout en faisant fonctionner l’ensemble de ces environnements comme un système coordonné. La tâche devient particulièrement difficile lorsque la capacité est répartie entre des clouds hyperscale, des centres de données privés, des infrastructures sur site et des fournisseurs spécialisés qui n’ont pas nécessairement été conçus pour fonctionner ensemble.

L’alimentation électrique est la contrainte la plus sévère. La disponibilité de l’électricité détermine de plus en plus où l’infrastructure d’IA est construite au départ.

C’est là que la fédération devient essentielle. Elle relie les infrastructures de différents environnements pour former un environnement opérationnel commun. L’orchestration intelligente détermine ensuite où exécuter les charges de travail en fonction de la capacité, de l’alimentation électrique, des performances, des coûts, des politiques, de la résilience et de la souveraineté.

À mesure que l’infrastructure d’IA se déploie davantage, que ce soit dans différents lieux ou chez différents fournisseurs, l’avantage concurrentiel ne viendra pas simplement de la possession d’une plus grande capacité. Il viendra de la capacité à faire fonctionner ces ressources ensemble. La fédération crée le modèle d’infrastructure adapté à cette nouvelle réalité, tandis que l’orchestration intelligente permet de le mettre en œuvre à grande échelle.

C’est le modèle que poursuit l’un de nos clients, RT-One, développeur des plus grands parcs technologiques d’IA et centres de données d’Amérique latine, qui prévoit de mettre en place une infrastructure fédérée à travers les Amériques : relier des capacités distribuées pour pouvoir, à terme, les gérer dans un environnement coordonné.

La pénurie de GPU a suscité une attention considérable, mais l’ajout d’accélérateurs ne se traduit pas nécessairement par une augmentation de la puissance de calcul réellement exploitable pour l’IA. Où se situent selon vous les principales sources d’inefficacité dans l’infrastructure d’IA actuelle, et quelle capacité supplémentaire les entreprises pourraient-elles dégager grâce à une meilleure orchestration ?

La course à l’infrastructure d’IA s’est largement concentrée sur le nombre de gigawatts de nouvelle capacité prévus et sur les capitaux engagés pour la construire. Il est tentant de réduire le problème de l’infrastructure d’IA à une simple pénurie de GPU ou de capacité, mais cette vision ne permet pas de cerner les véritables sources d’inefficacité. Il est important de noter que la capacité prévue n’est pas synonyme de capacité utilisable.

Les grappes de GPU peuvent sembler entièrement réservées, alors que des GPU coûteux restent inutilisés en raison de goulots d’étranglement ailleurs dans la pile. Ceux-ci peuvent concerner le débit du stockage, les pipelines de données, la congestion du réseau, l’inefficacité de la planification des tâches, les exigences de sécurité ou les incompatibilités entre architectures, applications, pilotes et dépendances. Ajouter des GPU ne se traduit pas toujours par une augmentation de la puissance de calcul utilisable.

L’ajout d’infrastructures n’améliore pas automatiquement l’efficacité. Dans bien des cas, il crée davantage de silos tout en faisant grimper les coûts.

Les organisations ont besoin d’une meilleure visibilité et d’un contrôle accru afin d’améliorer l’utilisation des ressources, d’automatiser les décisions liées aux infrastructures et de mieux faire correspondre les charges de travail aux ressources disponibles et aux priorités de l’entreprise. Une meilleure visibilité et un contrôle accru peuvent contribuer à transformer un ensemble de ressources d’infrastructure en un environnement opérationnel plus coordonné. Il n’existe pas de chiffre exact ou universel permettant de déterminer quelle capacité pourrait être libérée grâce à l’orchestration : chaque charge de travail a des exigences qui lui sont propres. Mais une chose est claire : la solution à la capacité immobilisée ou sous-utilisée ne consiste pas simplement à acheter ou à construire davantage.

RAVEL a mis l’accent sur l’interopérabilité entre les infrastructures, les technologies de virtualisation, les systèmes d’identité et les applications. Pourquoi l’interopérabilité devient-elle particulièrement importante à mesure que les charges de travail d’IA gagnent en complexité et se répartissent davantage ?

À mesure que les infrastructures se diversifient, les organisations ont besoin de pouvoir utiliser différentes technologies et différents environnements sans créer davantage de silos d’infrastructure isolés. L’interopérabilité permet aux ressources de calcul, au stockage, aux réseaux et aux applications de différents fournisseurs et environnements de fonctionner ensemble, préservant ainsi la liberté de choix à mesure que les infrastructures évoluent. Toutefois, l’interopérabilité seule ne détermine pas la manière dont ces ressources doivent être utilisées.

C’est là qu’intervient l’orchestration : elle coordonne l’emplacement d’exécution des charges de travail, leurs déplacements et l’application des politiques dans les différents environnements. À mesure que les infrastructures d’IA se répartissent toujours davantage et s’organisent en fédérations, l’interopérabilité offre la flexibilité nécessaire pour fonctionner avec différentes technologies, tandis que l’orchestration transforme ces ressources en un environnement opérationnel coordonné.

RAVEL Orchestrate AI fournit une couche d’orchestration commune aux ressources de calcul, au stockage, aux réseaux et aux autres technologies d’infrastructure, et coordonne les charges de travail d’IA dans les environnements cloud, sur site et hybrides.

La souveraineté des données devient un enjeu majeur pour les gouvernements et les entreprises qui déploient l’IA. En quoi le développement des infrastructures d’IA souveraine change-t-il la manière dont les organisations doivent envisager le placement des charges de travail, le déplacement des données, la sécurité et l’orchestration ?

L’IA souveraine est désormais une priorité stratégique. Elle soulève une question plus fondamentale : que signifie réellement être souverain ? Le débat s’est largement concentré sur la localisation des données, mais je pense que cette définition est trop restrictive.

Je définis l’IA souveraine comme la capacité d’un pays, d’une entreprise, d’une agence gouvernementale ou de toute autre organisation à conserver un contrôle de ses charges de travail d’IA défini par des politiques, notamment sur les données, les modèles, l’infrastructure de calcul, les accès, la sécurité, les opérations et la juridiction qui régissent ces charges de travail. La souveraineté ne signifie pas nécessairement que chaque charge de travail doit rester dans un seul centre de données, ni même sur une infrastructure appartenant à une seule organisation. Elle signifie plutôt que l’organisation définit où une charge de travail est autorisée à s’exécuter, où ses données peuvent résider ou être transférées, qui peut y accéder, quelle infrastructure peut l’exécuter et quelles politiques de sécurité, de réglementation, de localisation géographique, d’exploitation et d’entreprise doivent toujours être respectées. Cette définition centrée sur les charges de travail s’inscrit dans une évolution plus générale du secteur, qui consiste à considérer la souveraineté comme le contrôle de l’ensemble de l’environnement d’IA, et non de la seule localisation des données.

L’approche de RAVEL se distingue particulièrement lorsque l’IA souveraine s’articule avec la fédération. RAVEL Orchestrate AI peut intégrer les exigences de souveraineté en tant que contraintes dans la couche d’orchestration et de gestion des politiques : une charge de travail peut être autorisée à s’exécuter au sein d’une fédération de sites, de clouds, de centres de données, de sites en périphérie ou d’autres infrastructures, mais uniquement sur des ressources conformes aux politiques de souveraineté qui lui sont applicables. À l’intérieur de ce périmètre approuvé, RAVEL peut ensuite déterminer l’infrastructure la plus appropriée en fonction de facteurs tels que l’énergie, le coût, les performances, la capacité, le taux d’utilisation, les caractéristiques du réseau, la localisation et les priorités. La fédération n’élimine pas la souveraineté ; elle peut au contraire s’inscrire dans les limites définies par celle-ci. Une charge de travail gouvernementale sensible pourrait, par exemple, rester entièrement dans des installations approuvées aux États-Unis, tout en étant orchestrée de manière dynamique entre plusieurs sites autorisés. Ce modèle permet aux organisations de bénéficier des avantages d’utilisation des ressources et de résilience qu’offre une infrastructure d’IA distribuée, sans renoncer à contrôler où et comment s’exécutent leurs charges de travail les plus sensibles.

RAVEL est née dans des secteurs tels que les médias, le divertissement, le jeu vidéo et le design, où les charges de travail peuvent nécessiter une puissance de calcul considérable. Comment les exigences de l’IA générative ont-elles fait évoluer la plateforme par rapport aux défis d’infrastructure que vous cherchiez initialement à résoudre pour les professionnels de la création ?

RAVEL a été créée pour résoudre des problèmes d’infrastructure auxquels les artistes et les ingénieurs étaient déjà confrontés : ils exécutaient d’importantes charges de travail de rendu, de simulation et de création de contenu sur des ressources de calcul, de stockage et de réseau coûteuses. Le défi fondamental consistait à faciliter l’accès à des infrastructures hétérogènes, leur partage et leur orchestration, tout en optimisant leur utilisation et leurs performances.

L’IA générative a considérablement accru l’ampleur et la complexité de ce même problème. Au lieu de nous consacrer principalement à l’orchestration d’applications et de charges de travail de rendu, nous devons désormais prendre en compte les modèles d’IA, les moteurs, les agents, les charges de travail d’entraînement et d’inférence, les différentes architectures de GPU, l’évolution rapide des piles logicielles, les transferts de données massifs ainsi que des contraintes beaucoup plus importantes en matière d’énergie, de coût, de sécurité et de disponibilité.

En conséquence, RAVEL a évolué : d’abord principalement axée sur l’orchestration des ressources de calcul, l’entreprise fournit désormais une couche intelligente de contrôle et d’optimisation des infrastructures d’IA. Orchestrate AI s’appuie sur la télémétrie et des règles pour déterminer non seulement si une infrastructure est disponible, mais aussi où et comment une charge de travail doit être exécutée, en fonction de facteurs tels que le coût, la vitesse, la consommation d’énergie, les performances, le taux d’utilisation, l’emplacement et les exigences de souveraineté.

La fédération a également pris une importance croissante, car les infrastructures d’IA ne peuvent plus être considérées comme un ensemble de centres de données isolés ; les organisations doivent pouvoir utiliser intelligemment les capacités de différents sites tout en préservant leur gouvernance et leur sécurité. À bien des égards, l’IA générative n’a pas changé le problème fondamental que RAVEL cherchait à résoudre : elle l’a considérablement amplifié et complexifié, rendant toujours plus essentiels l’orchestration, l’optimisation et la fédération intelligentes.

Votre parcours vous a menée du génie mécanique et de l’optimisation des processus chez Starbucks aux médias numériques, aux centres de données, aux studios virtuels, et désormais aux infrastructures d’IA. Comment cette formation d’ingénieure a-t-elle influencé votre manière de créer des entreprises et de résoudre les problèmes liés aux infrastructures ?

Ma formation d’ingénieure a probablement influencé presque tout dans ma façon de créer des entreprises. Le génie mécanique apprend à examiner un système dans son ensemble, et pas seulement chacun de ses composants, et à se demander où se situent les contraintes, où l’énergie ou les ressources sont gaspillées, et comment améliorer les performances de l’ensemble. Chez Starbucks, j’ai appliqué cette approche à l’optimisation des processus ; plus tard, dans les médias numériques et les effets visuels, le système reposait sur les ressources de calcul, le stockage, les réseaux, les applications et, finalement, des centres de données entiers. La technologie a changé, mais pas vraiment ma façon d’aborder les problèmes. Je me demande toujours : Où se trouve le goulot d’étranglement ? Quelles ressources sont sous-utilisées ? Que peut-on simplifier ? Et comment améliorer le fonctionnement de l’ensemble du système plutôt que d’optimiser un seul de ses éléments ?

C’est tout à fait l’approche que nous avons adoptée pour créer RAVEL. À mon avis, le problème des infrastructures d’IA ne consiste pas simplement à obtenir davantage de GPU ou à construire davantage de centres de données. C’est un problème d’ingénierie des systèmes qui englobe les ressources de calcul, l’énergie, le stockage, les réseaux, les logiciels, les charges de travail, les personnes et, de plus en plus, la géographie et la souveraineté. On peut disposer du GPU le plus rapide au monde, mais si le reste du système n’est pas optimisé, on ne fait que créer un goulot d’étranglement très coûteux. C’est pourquoi, avec RAVEL, nous cherchons à rendre l’infrastructure elle-même plus intelligente, en utilisant la télémétrie, des règles, l’orchestration et la fédération pour déterminer en continu où et comment les charges de travail doivent être exécutées. J’ai commencé ma carrière en optimisant des systèmes physiques ; aujourd’hui, nous appliquons cette même rigueur d’ingénierie à l’optimisation des infrastructures qui alimentent l’IA.

Pour l’avenir, comment pensez-vous que les infrastructures d’IA vont évoluer à mesure que les modèles, les agents et les applications nécessiteront des capacités de calcul distribuées toujours plus importantes ? Pensez-vous que les usines d’IA deviendront une couche normalisée des infrastructures d’entreprise, comme le cloud computing l’a fait au cours de la dernière décennie ?

Je suis tout à fait convaincue que les usines d’IA deviendront une couche fondamentale des infrastructures d’entreprise, comme l’a fait le cloud computing, mais je ne pense pas qu’elles prendront la forme d’un centre de données ou d’un cloud unique et normalisé. À mesure que les modèles, les agents et les applications consommeront des capacités de calcul toujours plus importantes, les entreprises s’appuieront sur un éventail hétérogène de GPU, de CPU, d’infrastructures privées, de néoclouds, de fournisseurs de cloud à très grande échelle, d’environnements en périphérie et de systèmes d’IA spécialisés.

La disponibilité de l’énergie, le coût, la souveraineté, les performances et l’emplacement deviendront aussi importants que la disponibilité des capacités de calcul. Le véritable défi ne consistera pas simplement à construire davantage d’infrastructures, mais à faire fonctionner toutes ces infrastructures distribuées comme un système intelligent unique. L’usine d’IA de demain ne sera pas un bâtiment unique : ce sera un environnement d’infrastructure fédéré couvrant les capacités de calcul, l’énergie, les données et les ressources nécessaires à l’exécution des charges de travail d’IA là où cela s’avère le plus pertinent.

C’est là, à mon avis, que se dessine la prochaine grande couche d’infrastructure. Le cloud computing a abstrait les serveurs et facilité l’accès aux capacités de calcul ; l’étape suivante consiste à abstraire la complexité de toute la pile d’infrastructures d’IA. Les entreprises ne devraient pas avoir à déterminer manuellement quel GPU, centre de données, cloud, source d’énergie ou emplacement géographique doit exécuter chaque modèle ou agent. L’infrastructure devrait de plus en plus prendre elle-même ces décisions, en s’appuyant sur la télémétrie et des règles pour optimiser le coût, la vitesse, la consommation d’énergie, les performances, la disponibilité et la souveraineté. C’est l’avenir que nous préparons chez RAVEL : une couche d’orchestration intelligente qui permet aux charges de travail de circuler entre différentes infrastructures d’IA fédérées tout en respectant les règles et les contrôles de l’organisation. Le cloud a rendu les capacités de calcul accessibles à la demande. Je pense que la prochaine génération d’infrastructures d’IA permettra d’optimiser les ressources à la demande.

Merci pour cet excellent entretien. Les lecteurs qui souhaitent en savoir plus sur l’orchestration des charges de travail d’IA au sein d’infrastructures distribuées peuvent consulter RAVEL.