Créez votre propre Cloud Stack IA local privé en moins de 20 minutes

Créez votre propre Cloud Stack IA local privé en moins de 20 minutes

J’ai beaucoup parlé du package Local AI sur ma chaîne. C’est de loin la méthode la plus simple pour mettre en place toute votre infrastructure d’IA locale dans une seule pile, gratuitement. Je parle de vos modèles de langage (LLMs), bases de données, outils d’automatisation, recherche web locale et interface utilisateur. Comme je vais vous le montrer, vous pouvez utiliser ce package pour déployer très facilement des environnements d’IA locaux dans le cloud à la demande.

Pourquoi déployer votre IA locale dans le cloud ?

Voici la situation : même avec une IA locale, vous ne voulez pas toujours qu’elle fonctionne sur votre propre ordinateur pour plusieurs raisons :

  • Vous avez d’autres personnes, comme votre équipe interne, qui doivent utiliser votre configuration d’IA locale
  • Vous voulez qu’elle fonctionne 24h/24, 7j/7 sans que votre stack n’accapare constamment toutes les ressources de votre machine
  • Vous souhaitez accéder à du matériel que vous ne possédez pas
  • Ou peut-être toutes ces raisons combinées

La bonne nouvelle, c’est que déployer votre stack d’IA locale dans le cloud résout tous ces problèmes. Et c’est toujours considéré comme « local » tant que vous gérez vous-même l’instance cloud.

Dans cette vidéo, je vais vous guider étape par étape pour prendre le package Local AI et le déployer sur votre propre instance cloud privée. Vous pourrez ainsi profiter de l’IA locale sans être limité à votre seule machine. De plus, avec les nouvelles fonctionnalités du package Local AI, ce processus n’a jamais été aussi simple.

Ce guide est direct, sans fioritures. Je couvrirai également les fournisseurs cloud et les différentes exigences matérielles, car je sais que ce sont des considérations importantes pour l’IA locale. En plus de tout cela, je vous montrerai comment configurer des sous-domaines pour des services comme n8n et Open WebUI, ce qui en fait un guide vraiment complet.

Présentation du package Local AI

Voici le package Local AI. Je mettrai un lien vers ce dépôt GitHub dans la description de cette vidéo. L’avantage de ce package est qu’il regroupe tous ces services d’IA locale que vous voyez ici, le tout d’une manière où nous pouvons l’installer et le configurer en quelques étapes seulement, comme je l’ai expliqué dans ce README. C’est incroyablement simple de tout mettre en place.

Dans une précédente vidéo sur ma chaîne, que je vais lier ici, je montre comment utiliser ces étapes pour configurer tout sur notre propre ordinateur. Maintenant, nous allons le faire dans le cloud.

Ce package, initialement créé par l’équipe n8n, a été étendu par mes soins pour inclure tous ces services :

  • n8n
  • Supabase
  • Ollama
  • Open WebUI
  • Flowise
  • Quadrant
  • CRX NG pour la recherche web locale et privée (incluant Redis pour la mise en cache)

Ce qui est vraiment important pour cette vidéo, c’est que j’ai inclus Caddy, qui gère HTTPS et TLS. Cela nous permet d’avoir des points d’accès sécurisés pour tous nos services exécutés dans le cloud. Vous pouvez, par exemple, aller sur n8n.votredomaine.com, et cela vous amènera directement à l’instance n8n hébergée de manière sécurisée dans le cloud. C’est grâce à Caddy, et c’est vraiment important pour notre configuration.

Choix du fournisseur cloud

Pour cette vidéo, nous allons utiliser Digital Ocean pour déployer notre package Local AI. Ils ne sponsorisent pas cette vidéo, cette vidéo n’a pas de sponsor du tout. Je les utilise personnellement et je les recommande généralement, c’est pourquoi je les présente ici. Ils offrent les meilleures options pour les instances CPU selon moi.

Si vous n’exécutez pas de grands modèles LLM locaux nécessitant un GPU dédié, Digital Ocean vous offre les meilleures options que j’ai vues. Vous avez également Akamai Cloud (anciennement Linode), qui est une autre bonne option pour les instances CPU.

Pour les plateformes d’instances GPU, je tiens à souligner qu’il est important de faire vos propres recherches en fonction de vos besoins et de votre budget. Il existe de nombreuses options :

  • Lambda Labs
  • Vultr
  • Paperspace (qui fait partie de Digital Ocean mais est sa propre plateforme)

Et si vous voulez aller vers des solutions plus professionnelles, nous avons bien sûr AWS, Google Cloud et Microsoft Azure. Toutes ces plateformes vous fourniront des instances GPU sur lesquelles vous pourrez déployer le package Local AI exactement de la même manière que nous allons le faire avec Digital Ocean.

Il n’y a que quelques plateformes qui ne fonctionnent pas au mieux, et je vais les couvrir rapidement. Je veux m’assurer de tout couvrir pour que vous ne vous retrouviez pas à utiliser une plateforme qui ne fonctionne tout simplement pas :

  • TensorDO est une excellente plateforme pour des GPU bon marché, mais ils ne vous permettent pas d’ouvrir tous les ports dont vous avez besoin pour le package Local AI.
  • Nous avons aussi des plateformes comme RunPod et Novita qui sont également excellentes, mais elles déploient tout sous forme de conteneurs, et comme vous ne pouvez pas exécuter facilement des conteneurs dans des conteneurs, c’est beaucoup plus de travail pour mettre en place le package Local AI.

C’est pourquoi je m’en tiens à Digital Ocean, qui propose également des droplets GPU si vous voulez payer plus pour avoir quelque chose de vraiment puissant pour vos LLM locaux.

Création de notre instance

J’ai créé un nouveau projet dans Digital Ocean. Je vais cliquer sur « Create » puis « Droplets » en haut à droite. Pour garder les coûts bas pour cette démo, je vais créer une instance CPU, donc sans GPU dédié.

Je choisis ma région, je descends et je sélectionne cette instance à 42 $ par mois. Elle nous donne 8 Go de RAM et deux CPU. C’est suffisant pour l’ensemble du package Local AI, sauf si vous voulez exécuter des LLM locaux plus grands.

Si vous voulez exécuter des LLM plus grands que 7 ou 8 milliards de paramètres, vous aurez besoin d’un GPU dédié, ce qui vous coûtera beaucoup plus cher. Mais c’est nécessaire si vous voulez utiliser des LLM plus grands comme ceux de 14, 32 ou 70 milliards de paramètres.

Beaucoup de gens optent pour une instance CPU parce que c’est moins cher, et ils hébergeront Ollama ailleurs ou utiliseront simplement une API comme OpenRouter. Au moins, le reste de leur stack est toujours privé et local, ils ne paient rien pour ces services à part la machine pour les héberger. C’est ce que nous allons faire ici.

Bien sûr, si vous avez votre propre serveur, j’espère que vous avez un GPU pour couvrir ce besoin.

Pour notre image, je veux que tout soit configuré avec Docker, et Ubuntu est la distribution Linux la plus populaire, donc je vais sélectionner celle-ci dans le marketplace. Si vous suivez avec un autre fournisseur, vous pourrez trouver une instance Linux Ubuntu et suivre les mêmes commandes que je vais couvrir.

Pour l’authentification, les clés SSH sont un peu plus sécurisées, mais pour simplifier, je vais configurer un mot de passe. Je vais définir mon mot de passe, puis pour mon nom d’hôte, je vais simplement mettre « YouTube-Local-AI-Package ».

Configuration de notre instance

Maintenant que notre instance est créée, je peux cliquer dessus, aller à « Access » puis lancer une console droplet avec root, car j’ai besoin d’avoir un accès privilégié pour exécuter certaines des commandes que je vais vous montrer.

Une fois dans notre instance, il y a quelques étapes à suivre avant de pouvoir suivre les instructions de base et extraire le dépôt du package Local AI. En revenant au README, j’ai une section dédiée pour certaines des choses supplémentaires que vous devez faire lorsque vous déployez dans le cloud, car nous devons ouvrir des pare-feu et configurer nos enregistrements DNS.

Configuration du pare-feu

Pour la partie pare-feu, j’ai déjà exécuté ces commandes dans l’instance. Vous n’avez pas besoin de me regarder coller toutes ces commandes, mais vous devez activer vos règles de pare-feu et ouvrir les ports pour tous nos différents services Local AI comme Supabase, Flowise, Open WebUI et n8n.

Si vous voulez exposer CRX NG ou Ollama, vous pouvez également exécuter ces commandes. La raison pour laquelle je ne le fais pas par défaut est que CRX NG et Ollama ne sont pas protégés par mot de passe comme nos autres services, donc vous les exposeriez à quiconque pour les utiliser. Typiquement, je les garde privés et je n’ouvre pas ces ports. Les autres services Local AI sur l’instance peuvent y accéder via localhost, mais depuis l’extérieur, en accédant depuis Internet, vous ne pourriez pas utiliser CRX NG ou Ollama.

Après avoir configuré toutes vos règles de pare-feu, vous exécutez simplement ufw reload et toutes ces règles prennent effet. Gardez à l’esprit que pour tout cela, vous devez avoir un accès privilégié.

Configuration des enregistrements DNS

Maintenant, nous devons configurer nos enregistrements DNS, et ce sera à peu près la même chose quel que soit votre fournisseur DNS. J’utilise Hostinger (non sponsorisé), c’est juste ce que j’utilise pour mon DNS pour automator.ai.

Ce que vous voulez faire, c’est aller sur Digital Ocean, trouver votre IPv4 et la copier, puis la coller dans le champ « Points to » (ou équivalent) de votre fournisseur DNS. Vous voulez que ce soit un enregistrement de type A, et pour le nom, c’est le sous-domaine que vous voulez utiliser.

Si nous voulons que yt-n8n.automator.ai pointe vers l’instance n8n dans notre droplet Digital Ocean, nous le configurons comme ceci : nous disons que le nom est « yt-n8n », c’est notre sous-domaine. Je vais ajouter cet enregistrement, cliquer sur confirmer, puis nous pouvons faire de même pour tous nos autres services :

  • yt-supabase
  • yt-openwebui
  • yt-flowise

Vous pouvez faire la même chose pour CRX, Ollama, ou tout autre service que vous pourriez ajouter vous-même au package Local AI.

C’est tout pour le DNS, et c’est tout ce que nous avons comme étapes supplémentaires pour le déploiement dans le cloud. Maintenant, nous pouvons passer aux étapes d’installation de base.

Installation du package Local AI

Je vais commencer par copier la commande git clone, ouvrir mon instance, coller ceci, cloner le dépôt, puis changer de répertoire. Maintenant, tout ce que nous voyons avec ls est ce que nous avons à la racine de notre dépôt GitHub.

Une étape supplémentaire que je dois faire ici, juste parce que j’ai tout dans une branche de fonctionnalité en ce moment, je dois changer de branche. Vous n’aurez pas à le faire car j’aurai tout dans la branche principale au moment où vous regardez cette vidéo.

Maintenant, nous avons toute la configuration pour des choses comme Caddy, que je ne vais pas détailler ici pour garder ce tutoriel concis, mais vous pouvez y plonger si vous êtes curieux.

Ce que nous voulons faire maintenant, c’est configurer nos variables d’environnement. J’ai un exemple pour tout dans ce fichier .env.example. Nous voulons copier le fichier .env.example dans un nouveau fichier .env. Maintenant, le contenu de .env est exactement le même que .env.example, et nous allons utiliser Nano pour l’éditer.

Cela suppose que vous avez déjà Nano, Git et Docker installés. Je le mentionne dans le README, ce sont des prérequis que vous pouvez installer en fonction de votre distribution Linux si vous ne les avez pas déjà.

Dans le fichier .env, j’ai des commentaires qui vous indiquent quelles variables sont requises et comment configurer toutes ces variables :

  • Pour n8n, c’est juste une chaîne alphanumérique que vous voulez définir comme quelque chose d’assez long pour la rendre sécurisée.
  • Pour les secrets Supabase, vous voulez configurer votre mot de passe PostgreSQL et aussi les détails de connexion pour votre tableau de bord Supabase.
  • J’ai des liens ici qui vous amènent au guide d’auto-hébergement de Supabase, qui vous aidera à configurer votre JWT secret, clé anonyme et clé de rôle de service, et qui rend le processus très facile.
  • Pour votre ID de pool ou de locataire, vous pouvez le définir à n’importe quel numéro, comme 1000 par exemple.

C’est vraiment facile de configurer toutes ces valeurs. La seule chose que je vais vous montrer ici, c’est la configuration de Caddy, car ce sont tous nos sous-domaines.

Je vais décommenter tous les sous-domaines que nous avons configurés dans Hostinger ou quel que soit votre fournisseur DNS. Je ne vais pas décommenter Ollama et CRX NG car je ne les utilise pas.

Pour l’email Let’s Encrypt, vous pouvez simplement mettre votre email, comme col@automator.ai. Pour les noms d’hôtes, changez-les évidemment pour correspondre aux sous-domaines que vous avez configurés dans votre fournisseur et à votre domaine réel. Pour n8n par exemple, c’était yt-n8n.automator.ai.

Pour sauvegarder et quitter ce fichier avec Nano, il y a quelques commandes : d’abord Ctrl+X, puis il vous demandera si vous voulez sauvegarder, donc vous taperez simplement Y, et enfin vous pouvez appuyer sur Entrée. Donc encore une fois, c’est Ctrl+X, puis Y, puis Entrée.

Maintenant, nous sommes prêts à exécuter ce script qui va tout démarrer avec Docker.

En revenant au README, il y a quelques options différentes pour cette commande, car il y a différents profils à utiliser selon votre GPU ou si vous voulez exécuter en mode CPU. Si vous avez une instance cloud avec un GPU Nvidia, comme si vous utilisez Lambda Labs ou AWS ou quelque chose comme ça, ou une instance GPU Digital Ocean, alors vous exécuterez cette commande, peut-être en remplaçant python par python3 (beaucoup de distributions Linux nécessitent que vous spécifiiez python3 pour la commande).

Pour notre cas spécifique, puisque nous avons juste une instance CPU, je vais exécuter cette commande pour exécuter l’instance Ollama sur mon CPU parce que je n’ai pas de GPU. Je vais copier ça, revenir ici et le coller.

Vous voyez qu’il dit « python not found », donc typiquement cela signifie que vous devez ajouter un 3 à la fin, en spécifiant python3. Je vais exécuter ceci et maintenant ça va lancer tout le processus où il extrait le dépôt Supabase et démarre les conteneurs Supabase. Il y a des paramètres en coulisses qu’il configure pour CRX également.

Ce script s’occupe de beaucoup de choses. Vous le verrez extraire et exécuter les conteneurs Supabase, puis il attendra un peu et extraira et exécutera le reste des conteneurs pour notre stack Local AI. Il a tout regroupé dans un seul réseau Docker Compose, donc tous les conteneurs peuvent communiquer entre eux.

Cela prendra un peu de temps car certains de ces conteneurs sont assez volumineux et il doit extraire le modèle Ollama et importer les workflows n8n et tout le reste. Je vais faire une pause et revenir une fois que ce sera terminé.

Test de notre déploiement

Quelques minutes plus tard, tous nos conteneurs sont en marche. Vos logs devraient ressembler à quelque chose comme ceci. Il y a eu un petit problème avec mon droplet Digital Ocean, c’est pourquoi vous voyez un espace vide, mais vos logs ressembleront à quelque chose comme ceci, où nous avons les conteneurs Supabase extraits et exécutés, puis la même chose pour le reste de notre package Local AI pour tout comme n8n, Open WebUI et Caddy.

Pour voir tous vos conteneurs en cours d’exécution, vous pouvez utiliser la commande docker ps. Elle vous montrera chacun des conteneurs dans la pile. Vous pouvez vous assurer qu’ils indiquent tous qu’ils sont opérationnels. Si vous en voyez qui sont arrêtés ou qui redémarrent, vous avez probablement un problème que vous voudriez examiner.

Vous pouvez également faire docker logs -f suivi du nom de votre conteneur, et cela vous donnera tous les logs pour ce conteneur spécifique. Nous regardons Caddy ici, et le -f signifie qu’il suivra les logs au fur et à mesure qu’ils arrivent. Ce sont juste quelques commandes pour vous aider à gérer votre pile.

Maintenant, nous pouvons aller sur notre navigateur et tester cela. Je vais ouvrir un nouvel onglet et aller sur yt-n8n.automator.ai, et voilà ! Nous avons notre page d’inscription vierge pour n8n. Nous pouvons aller sur yt-supabase.automator.ai et cela nous amènera à notre tableau de bord nous demandant de nous connecter. Nous pouvons faire yt-openwebui.automator.ai, et voilà, nous avons Open WebUI.

Tout fonctionne parfaitement. Je peux m’y connecter depuis un navigateur externe sur mon ordinateur, et c’est magnifique.

Je ne vais pas couvrir comment utiliser toutes ces différentes plateformes ici. Il y a d’autres vidéos sur ma chaîne que je vais lier dans la description de cette vidéo si vous voulez plonger dans la création d’agents locaux avec n8n et Ollama et tout ce qui est ici. Nous voulions juste nous concentrer sur la mise en place de notre stack Local AI hébergée dans le cloud, et nous y sommes parvenus.

Conclusion

Voilà donc la méthode la plus rapide pour déployer votre configuration d’IA locale dans le cloud. Dans l’ensemble, j’ai beaucoup plus à venir pour le package Local AI, car j’ajoute constamment de nouveaux services, j’apporte des améliorations constantes et je publie plus de contenu pour des choses comme des guides sur la création d’agents d’IA locaux utilisant ce package.

Si vous avez apprécié ce contenu et que vous attendez avec impatience plus de choses sur l’IA locale et les agents d’IA, j’apprécierais vraiment un like et un abonnement. Sur ce, je vous retrouve dans la prochaine vidéo.