Kepler Communications vient de lancer le premier cluster de calcul orbital opérationnel — 40 GPU fonctionnant en orbite terrestre. Sophia Space est le premier client. Il ne s’agit pas d’un projet de recherche ou d’une preuve de concept. C’est une infrastructure opérationnelle.
Pourquoi c’est important maintenant
La capacité GPU au sol est limitée. Les fournisseurs de cloud augmentent leurs prix. Les coûts de transfert de données de l’espace vers la Terre étaient prohibitifs il y a quelques années. Mais l’économie a changé.
Le calcul orbital résout un problème spécifique : le traitement des données là où elles se trouvent. Les satellites collectent d’énormes quantités d’images, de données de capteurs et de télémétrie. L’expédition de ces données brutes vers la Terre coûte en bande passante. Le traitement en orbite — près de la source — réduit considérablement la latence et les coûts de transfert.
Pour Sophia Space, le premier cas d’utilisation documenté semble être le traitement d’images satellites. C’est l’application la plus évidente au début : exécuter l’inférence sur les images avant de décider de ce qu’il faut télécharger.
La configuration technique construite par Kepler
40 GPU en orbite, c’est peu selon les normes terrestres. Un seul grand centre de données en exécute des milliers. Mais dans l’espace, les contraintes d’alimentation sont brutales. Chaque GPU consomme une puissance importante. Les panneaux solaires ne peuvent générer qu’une quantité limitée. Cela signifie que le cluster de Kepler est conçu pour l’efficacité, pas pour le débit.
Cette contrainte façonne en fait qui sont les premiers clients : les entreprises qui traitent des charges de travail spécifiques (analyse d’images satellites, modélisation atmosphérique) où l’efficacité par GPU est plus importante que l’échelle brute.
La première vraie contrainte : la gestion thermique
Refroidir 40 GPU dans le vide de l’espace est contre-intuitif. On ne peut pas utiliser de ventilateurs. La chaleur est directement rayonnée vers l’espace, ce qui semble idéal jusqu’à ce que vous conceviez des panneaux radiatifs qui restent dans l’enveloppe thermique d’un satellite. C’est pourquoi le calcul orbital ne pourra pas évoluer comme les clusters au sol — du moins pas tant que quelqu’un n’aura pas résolu la dissipation thermique multi-kilowatts dans le vide à un poids raisonnable.
Le cluster de Kepler fonctionne probablement à des réglages de puissance inférieurs à ceux de ses équivalents au sol, échangeant une partie des performances contre la stabilité thermique.
Que se passe-t-il ensuite
Si le cas d’utilisation de Sophia Space fonctionne — si le coût par inférence et les améliorations de latence justifient la prime de l’infrastructure orbitale — vous verrez davantage d’opérateurs de satellites adopter le même schéma. Le traitement d’images, la modélisation météorologique et la fusion de capteurs en temps réel sont les suites logiques.
Le plus grand enjeu n’est pas de concurrencer AWS ou Azure sur la puissance de calcul brute. Il s’agit de capturer la niche où l’économie de la localisation des données change la donne. C’est plus restreint que ce que les hyperscalers opèrent, mais le potentiel de marge est plus élevé car vous résolvez un problème qu’aucun cluster au sol ne peut aborder aussi efficacement.
Une chose à faire aujourd’hui
Si vous travaillez avec des images satellites, de la télédétection ou de la télémétrie en temps réel depuis l’espace, cartographiez votre pipeline de traitement. Identifiez les étapes qui pourraient s’exécuter en orbite par rapport au sol. Même si le calcul orbital de Kepler n’est pas adapté à votre volume actuel, comprendre l’économie vous positionne avant que la capacité ne se resserre davantage.
