Hébergement AI pour les stacks d'inférence, de RAG et d'automatisation

  • cPanel sur CloudLinux
  • Stockage NVMe SSD
  • Accès root complet sur VPS cloud

Déterminez ce dont votre application AI a réellement besoin avant de payer.

La plupart des produits présentés comme des applications AI sont des applications web ordinaires avec, au milieu, un appel HTTP lent et coûteux. Le modèle s'exécute ailleurs. Ce que vous hébergez réellement, c'est une interface, une file d'attente, un stock d'embeddings et un tas de clés API. Ce mélange ne se comporte en rien comme un site vitrine, et c'est la raison pour laquelle tant de projets AI personnels se font brider ou suspendre dès leur premier mois. Cette page expose clairement quelles parties d'une pile AI tournent sans problème sur l'hébergement mutualisé ElySpace, quelles parties nécessitent un VPS cloud avec accès root, et quelles parties personne ne peut faire tourner sans GPU.

Ce qu'une charge de travail AI exige d'un hébergeur

Six exigences qu'un site web ordinaire ne formule jamais. Lisez-les avant de comparer les formules, car ce sont elles qui distinguent un projet d'IA qui tient la route d'un projet bridé par son propre hébergement.

Icône de version d'exécution figée

Un runtime que vous pouvez figer

Les bibliothèques d'IA cassent au moindre changement de version mineure. Une mise à jour du tokenizer ou du SDK client peut modifier vos résultats du jour au lendemain. Vous devez choisir la version de l'interpréteur et figer le jeu de dépendances, et non hériter de ce avec quoi le serveur a été reconstruit la semaine dernière.

Icône de processus de traitement en arrière-plan

Des traitements qui survivent à la requête

Vectoriser un ensemble de documents, réindexer après un téléversement, relancer une génération qui a échoué : rien de tout cela ne tient dans une requête de navigateur. Cela relève d'un worker qui continue de tourner après que le visiteur a fermé l'onglet, ce qui est un besoin d'hébergement très différent.

Icône de stockage de base de données vectorielle

Un endroit où conserver les vecteurs

La recherche documentaire a besoin d'un index. Ce peut être pgvector dans Postgres, un fichier SQLite, ou un moteur dédié comme Qdrant, Weaviate ou Milvus. Chacun réclame de la mémoire et des lectures aléatoires soutenues, et la réponse honnête sur celui qui conviendra dépend du nombre de documents que vous découpez en fragments.

Icône de requête API sortante lente

Des appels sortants lents par nature

Une API de modèle qui répond en huit secondes, c'est normal, ce n'est pas une panne. Votre serveur web, votre délai d'expiration PHP ou Node, votre proxy et votre navigateur ne sont pas du tout d'accord sur ce point. Mettre d'accord les délais d'expiration, les relances et les réglages keep-alive représente l'essentiel du travail pour livrer une fonctionnalité d'IA.

Icône de connexion en streaming

Une connexion qui reste ouverte

Le streaming token par token signifie qu'un visiteur occupe une connexion pendant toute la durée de la réponse. Dix personnes qui discutent en même temps, ce sont dix connexions simultanées qui ne font presque rien, c'est-à-dire exactement le schéma que les limites de concurrence de l'hébergement mutualisé sont faites pour bloquer.

Icône de protection des clés API secrètes

Des clés qui n'atteignent jamais le navigateur

Une clé d'API de modèle placée dans le JavaScript front end, c'est une facture que quelqu'un d'autre peut faire grimper. Les clés doivent résider dans un fichier situé hors de la racine web, ou dans un fichier d'environnement que le serveur refuse de servir, chaque appel passant par votre propre back end afin que vous puissiez en limiter le débit et le journaliser.

Où se situe chaque composant d'une pile AI

Aucun hébergeur ne peut proposer toutes les colonnes ci-dessous sur une formule d'entrée de gamme. Classer d'abord vos composants dans ces trois catégories vous évitera une migration plus tard.

Fonctionne bien sur un hébergement mutualisé cPanel Nécessite un VPS cloud avec accès root Nécessite un GPU ou une API de modèle
  • Le site de votre produit, sa documentation et ses pages de tarifs
  • Un front-end qui appelle une API de modèle à chaque requête
  • Écrans d'inscription, d'authentification et de facturation
  • Journaux des prompts et des réponses dans MySQL
  • Des traitements par lots sur une tâche cron, pas plus souvent que toutes les 15 minutes
  • Workers de file d'attente et planificateurs qui restent résidents
  • Une base de données vectorielle auto-hébergée avec son propre démon
  • Points de terminaison Websocket et server sent events
  • Docker, systemd et une version de Python que vous avez choisie
  • Robots d'exploration et tâches d'ingestion qui construisent l'index
  • Entraîner ou affiner votre propre modèle
  • Servir un grand modèle à poids ouverts avec la latence d'un chat
  • Génération de voix, d'images ou de vidéos en temps réel
  • Vectoriser des millions de documents en une seule passe
  • Tout ce dont le guide d'installation commence par CUDA

Les magasins vectoriels, les délais d'attente
et les tâches qui ne finissent jamais

Les trois problèmes techniques à l'origine de presque tous les tickets d'assistance que nous recevons des équipes qui hébergent des applications d'IA.

Anatomie d'une stack RAG,
et la partie qui fait mal

Un dispositif de recherche documentaire comporte quatre éléments mobiles : une tâche d'ingestion qui découpe vos documents sources en fragments, un appel d'embedding qui transforme chaque fragment en vecteur, un magasin qui conserve ces vecteurs, et un chemin de requête qui récupère les correspondances les plus proches et les transmet au modèle. Trois de ces quatre éléments coûtent peu. L'ingestion est celui qui fait mal, parce qu'elle arrive par à-coups, qu'elle peut durer des heures et qu'elle sollicite fortement le stockage pendant son exécution. Construisez-la comme une tâche que vous pouvez démarrer, arrêter et reprendre depuis un shell plutôt que comme quelque chose que déclenche une requête web, et le reste de la stack devient de l'hébergement web ordinaire. Les équipes qui construisent le même schéma avec des outils visuels associent généralement cette page à nos formules d'automatisation n8n infogérées, où le moteur de workflow est lui-même le processus de longue durée.

Schéma d'une tâche d'ingestion alimentant un magasin d'embeddings et un chemin de requête

Pourquoi les requêtes AI font sauter
les délais d'attente par défaut de tout le monde

Une génération qui prend douze secondes sera interrompue par au moins un élément situé entre votre code et le visiteur, à moins que vous n'alliez le modifier. PHP a une limite de temps d'exécution des scripts. LiteSpeed a son propre délai d'expiration de connexion. Cloudflare, qui se place devant chaque site ElySpace, ferme une requête qui ne produit aucun octet pendant trop longtemps. La solution n'est pas d'augmenter le délai d'expiration partout : c'est d'envoyer les premiers octets tôt, ou d'accepter la requête, de la confier à un worker et de laisser le navigateur interroger ou s'abonner pour obtenir le résultat. Décidez lequel de ces deux schémas vous utilisez avant de choisir une formule, car le streaming maintient une connexion, contrairement à l'interrogation périodique.

Illustration d'une réponse serveur rapide pour des réponses AI diffusées en continu

Les limites de l'hébergement mutualisé,
en chiffres, avant de construire

ElySpace publie les plafonds de son hébergement mutualisé au lieu de les dissimuler, et pour des travaux liés à l'IA les chiffres comptent davantage que le discours marketing. Les formules d'entrée de gamme sont limitées par CloudLinux aux valeurs ci-dessous, et les règles qui suivent relèvent de la politique de la maison, pas de la préférence. Si votre conception se heurte à l'une d'elles, c'est vers un VPS cloud qu'il faut vous tourner, et il est moins coûteux de l'apprendre maintenant qu'après une suspension.

Le texte complet, y compris les clauses relatives aux applications de messagerie instantanée et aux robots d'exploration, figure dans nos limites de ressources de l'hébergement mutualisé. Lisez en particulier les clauses sur le chat et les robots si vous envisagez un bot d'assistance ou un crawler d'ingestion, car tous deux y sont nommément cités et tous deux ont vocation à vivre dans un environnement dédié.

  • 100% d'un cœur CPU et 1024 MB de mémoire sur les formules d'entrée de gamme
  • 10 processus d'entrée, ce qui constitue votre véritable plafond de simultanéité
  • 10 MB/s d'E/S et 1024 IOPS, partagés avec votre base de données
  • Cron au maximum une fois toutes les 15 minutes
  • Les processus web ne peuvent pas se dupliquer ni lancer de sous-processus
Panneau de contrôle du serveur affichant les limites de ressources et l'accès root

Comment mettre une application AI en ligne
sur ElySpace

Quatre étapes, dans l'ordre qui évite de refaire le travail. La première est celle que l'on saute, et c'est celle qui détermine tout le reste.

01

Triez les composants

Placez chaque composant de votre application dans l'une des trois colonnes ci-dessus. La colonne la plus lourde détermine l'offre.

02

Choisissez l'offre

Un projet uniquement front-end convient à l'hébergement mutualisé. Tout ce qui est résident, conteneurisé ou en streaming démarre sur un VPS cloud.

03

Déployez et figez

Poussez via Git, figez les versions de vos dépendances, placez les clés dans un fichier que le serveur ne servira pas, et planifiez les tâches.

04

Surveillez les compteurs

cPanel affiche en direct votre utilisation du CPU, de la mémoire et des processus d'entrée. Montez en gamme avant que la courbe ne vienne s'aplatir contre le plafond.

GPU ou CPU : la question que la plupart des projets d'AI abordent de travers

Vous n'avez probablement pas besoin d'un GPU. Vous avez presque certainement besoin de l'accès root.

Un GPU n'est nécessaire que si les poids du modèle se trouvent sur votre propre machine. Si vous appelez un modèle hébergé via une API, toutes les opérations lourdes sur les tenseurs se déroulent dans le centre de données de quelqu'un d'autre, et votre serveur se contente de manipuler des chaînes de caractères, d'analyser du JSON et d'écrire en base de données. C'est du travail pour le CPU, et quelques cœurs virtuels suffisent largement. Là où les équipes sont réellement bloquées, ce n'est pas sur la puissance de calcul, c'est sur les droits : elles doivent lancer un démon, ouvrir un port, installer un paquet système ou maintenir un processus en vie, et aucun compte mutualisé nulle part ne le leur permettra. C'est pourquoi la véritable voie d'évolution pour un projet d'AI est un serveur cloud évolutif ou une formule VPS avec accès root plutôt que du matériel exotique. Si votre projet a réellement besoin de configurations accélérées par GPU, elles ne font pas partie des formules ElySpace publiées : parlez-en à notre équipe en nous expliquant ce que vous cherchez à exécuter, et nous vous dirons honnêtement si nous pouvons vous aider.

Serveur virtuel avec cœurs et mémoire dédiés pour les charges de travail d'applications d'AI
Dites-nous ce que vous construisez

Vous ne savez pas dans quelle colonne se situe votre projet ?

Envoyez-nous la structure de votre stack : le framework, l'API de modèle que vous appelez, si quelque chose doit rester résident en mémoire, et approximativement combien de documents vous indexez. Nous vous dirons quelle formule ElySpace convient et, tout aussi utilement, quand ce n'est pas le cas. Le chat en direct et les tickets sont ouverts 24h/24 et 7j/7, et la migration gratuite s'applique si vous déplacez une application AI en service depuis un autre hébergeur. Chaque formule est couverte par l'engagement de disponibilité de 99.9% défini dans notre contrat de niveau de service, et fonctionne sur LiteSpeed Enterprise, CloudLinux, cPanel, Imunify360, JetBackup et un stockage NVMe SSD. Si vous préférez commencer par les fondamentaux, notre présentation de l'hébergement cPanel couvre la plateforme mutualisée, tandis que les formules avec cœurs dédiés conviennent à un front end déjà très sollicité.

Parlez à un ingénieur Ouvrir un ticket
Un ingénieur du support ElySpace examinant une stack applicative

Lisez les avis de nos clients

C'en est probablement assez de notre part, nous laisserons nos clients parler à notre place : avec plus de 2000 avis sur Trustpilot et Facebook, constatez par vous-même pourquoi vous pouvez nous confier la puissance de votre site web.

FAQ sur l'hébergement AI

L'hébergement AI, c'est de l'hébergement web ordinaire dimensionné pour trois usages inhabituels. Une application AI émet des appels sortants lents qui peuvent durer plusieurs secondes, elle a souvent besoin d'un processus qui continue de travailler une fois le visiteur parti, et elle stocke des embeddings qui sont lus en permanence. Un site vitrine ne fait rien de tout cela. L'infrastructure sous-jacente reste la même plateforme LiteSpeed, CloudLinux, cPanel et NVMe que nous exploitons pour chaque client. Ce qui change, c'est le plan dont vous avez besoin et la façon dont vous architecturez l'application par-dessus.

Tout dépend de ce que fait l'application, pas du langage. Un script de type requête-réponse qui appelle l'API d'un modèle et écrit dans MySQL convient très bien. Un service Python qui attend de pouvoir ouvrir son propre port, tourner sous systemd ou lancer des processus de travail ne convient pas, car les comptes mutualisés n'ont pas d'accès root et les processus web ne sont pas autorisés à créer des forks ou des sous-processus. Ouvrez un ticket avec vos besoins avant d'acheter et nous vous confirmerons quels interpréteurs et sélecteurs sont activés sur le plan qui vous intéresse.

Les configurations accélérées par GPU ne font pas partie des formules ElySpace publiées. Nos gammes mutualisée, cloud et VPS reposent sur le CPU, ce qui est la bonne forme pour des applications qui appellent un modèle hébergé via une API plutôt que d'exécuter les poids localement. Si votre projet a réellement besoin d'inférence locale ou de fine-tuning, contactez notre équipe, décrivez le modèle et la latence dont vous avez besoin, et nous vous dirons franchement si nous pouvons monter quelque chose d'adapté ou si vous serez mieux servi ailleurs. Nous préférons dire non que de vous vendre un serveur incapable de faire le travail.

Oui, sur un VPS cloud, où vous avez les droits root et pouvez installer le moteur en tant que service. Qdrant, Weaviate, Milvus et Postgres avec pgvector fonctionnent tous comme leurs propres démons et nécessitent un processus persistant : ils ont donc leur place sur un VPS plutôt que sur un compte mutualisé. Si votre corpus est petit, un index sur fichier tel que SQLite ou un fichier de vecteurs à plat placé dans le répertoire de votre application fonctionnera sur un hébergement mutualisé, sous réserve des mêmes limites d'IO et d'inodes que pour tout autre fichier. Dimensionnez la mémoire en fonction de votre index, pas de vos pages vues.

Non. Prévoyez des exécutions planifiées plutôt qu'un démon résident. Les comptes mutualisés n'ont ni root, ni systemd, ni superviseur : rien ne maintient donc en vie un worker de longue durée ni ne le redémarre après un redémarrage. Ce dont vous disposez, c'est du cron de cPanel, qui ne peut pas se déclencher plus souvent qu'une fois toutes les 15 minutes. C'est suffisant pour une réindexation nocturne ou pour un lot qui vide une file à heure fixe. Ce n'est pas suffisant pour un traitement quasi temps réel. Si votre produit promet un résultat en quelques secondes, le worker a besoin d'un VPS.

Considérez toute connexion persistante comme une fonctionnalité de VPS. Sur un serveur root, vous contrôlez le serveur web, la configuration du proxy et les ports : les websockets et les server sent events sont donc à vous de configurer. Sur un hébergement mutualisé, chaque connexion ouverte est décomptée d'une petite allocation de processus d'entrée : une poignée de conversations simultanées peut donc épuiser la formule tout en n'utilisant presque pas de CPU. Si le streaming est au cœur de votre interface, commencez sur un VPS cloud. Si c'est un simple confort, repliez-vous sur une interrogation périodique du résultat et l'hébergement mutualisé s'en sortira.

Le trafic des prompts et des complétions est du texte : le volume est donc généralement négligeable. Une longue conversation se mesure en kilo-octets, et des milliers d'entre elles ne gêneront pas une formule d'hébergement. L'exception, c'est le média : envoyer de l'audio à transcrire, ou faire passer des images dans un modèle de vision, déplace de vrais octets dans les deux sens et doit être estimé correctement. Tout ce qui nécessite un port sortant inhabituel plutôt que le HTTPS standard doit d'abord être signalé à l'assistance, car les plateformes mutualisées restreignent les ports sortants par défaut.

Lisez la clause relative au chat dans nos politiques d'utilisation des ressources avant de vous lancer. Les applications de chat interactif en temps réel y sont explicitement interdites sur l'hébergement mutualisé, au même titre que les robots d'indexation et les crawlers, et la politique précise que ce type de charge de travail relève d'un environnement dédié. Cela vaut pour un bot de support auto-hébergé comme pour le crawler que vous pourriez écrire pour l'alimenter. Placez les deux sur un VPS cloud. Un widget qui se contente d'envoyer un formulaire et d'afficher une réponse est autre chose, et cela ne pose aucun problème en mutualisé.

Jamais dans le JavaScript côté client, et jamais à l'intérieur de la racine web sans règle de refus. Conservez vos clés dans un fichier caché ou dans un répertoire situé au-dessus de public_html, et assurez-vous que votre .htaccess refuse les requêtes portant sur des noms de fichiers commençant par un point, afin qu'un fichier d'environnement ne puisse jamais être servi. Faites transiter chaque appel au modèle par votre propre back-end pour pouvoir le limiter en débit, le journaliser et changer la clé sans redéployer un client. Imunify360 et le pare-feu de la plateforme protègent le serveur ; seule la conception de votre application protège la clé.

Vous atteindrez le plafond de processus d'entrée bien avant le plafond de CPU. Les requêtes AI passent l'essentiel de leur vie à attendre l'API de quelqu'un d'autre : le graphique dans cPanel montre donc les connexions s'accumuler pendant que le processeur reste inactif. Surveillez l'indicateur des processus d'entrée, pas celui du CPU. Lorsqu'il commence à plafonner, déplacez l'application vers un VPS cloud doté de cœurs dédiés et laissez le front-end statique là où il est. La migration gratuite est incluse, et notre équipe peut déplacer pour vous les fichiers, les bases de données et les entrées cron.