Plateforme privée LLM sur Kubernetes

Construire une plateforme d’inférence privée ne commence pas par le déploiement d’un modèle. Avant de parler de serving, d’API ou d’interface utilisateur, il faut d’abord disposer d’une infrastructure capable d’exécuter et d’orchestrer correctement les workloads.

C’est précisément l’objectif de cette série. Le projet consiste à construire progressivement une plateforme privée d’inférence LLM sur Kubernetes, en utilisant un nœud équipé d’un GPU NVIDIA distant. L’objectif est de partir d’une infrastructure minimale, puis d’ajouter progressivement les différentes briques nécessaires : serving, interface utilisateur, observabilité et administration.

Dans ce premier article, nous ne déployons encore aucun modèle. L’objectif est de comprendre l’architecture cible, les choix techniques et les prérequis nécessaires avant de passer à l’installation du cluster.

Architecture de la plateforme

Avant d’installer quoi que ce soit, il est utile de comprendre l’architecture cible finale. La plateforme sera construite autour de deux machines :

• un nœud control plane K3s, qui héberge le serveur Kubernetes ;
• un nœud worker distant équipé d’un GPU NVIDIA, qui fournira les ressources GPU nécessaires aux workloads.

L’architecture finale sera construite progressivement. Le schéma représente donc la cible du projet.

Les principales briques

La plateforme finale comprendra notamment :

• K3s pour orchestrer les workloads ;
• un nœud GPU NVIDIA distant pour fournir les ressources de calcul ;
• Tailscale pour la connectivité privée entre les machines ;
• vLLM pour servir les modèles et exposer une API compatible avec l’API OpenAI ;
• Open WebUI pour fournir une interface utilisateur ;
• Prometheus et Grafana pour l’observabilité ;
• NVIDIA DCGM Exporter pour exposer les métriques du GPU ;
• un serveur MCP développé en Python pour interagir avec l’infrastructure et exposer des outils d’administration.

Mais avant cela, il faut construire la fondation : le cluster Kubernetes et son nœud GPU.

Pourquoi utiliser un GPU distant ?

Pour ce projet, je n’ai pas choisi de placer le GPU directement dans la machine qui héberge le control plane Kubernetes. Le GPU est hébergé sur une seconde machine distante, qui rejoint le cluster comme worker node. Cette séparation présente plusieurs avantages :

• le control plane reste indépendant des ressources GPU ;
• le serveur GPU peut être démarré ou arrêté indépendamment, ce qui limite les coûts si le GPU est loué à l’heure ;
• il est possible d’utiliser un fournisseur de GPU à la demande (cloud GPU) plutôt que du matériel dédié en permanence ;
• l’infrastructure reste simple à reproduire, avec différents fournisseurs ou sur une infrastructure personnelle ;
• les workloads nécessitant un GPU peuvent être exécutés sur un nœud spécialisé.

Dans mon environnement, le serveur GPU est fourni par Vast.ai et dispose d’une NVIDIA RTX 3090. Le principe reste identique quel que soit le fournisseur (cloud GPU à la demande, machine dédiée chez un hébergeur, ou serveur on-premise).

L’objectif n’est pas de construire ici une architecture de production à grande échelle, mais une infrastructure réaliste permettant d’expérimenter les différentes briques d’une plateforme d’inférence.

Pourquoi K3s ?

K3s est une distribution légère et certifiée de Kubernetes, conçue pour fournir les fonctionnalités essentielles de Kubernetes avec une installation et une exploitation simplifiées.

Pour ce projet, pas besoin de construire un cluster Kubernetes hautement disponible avec plusieurs control planes et une infrastructure distribuée complexe. L’idée est avant tout de disposer d’un environnement Kubernetes suffisamment proche des pratiques réelles pour :

• déployer des workloads ;
• gérer plusieurs nœuds ;
• exploiter un nœud GPU ;
• utiliser Helm ;
• exposer des services ;
• mettre en place l’observabilité ;
• expérimenter différentes briques de la plateforme.

K3s constitue donc un bon compromis entre fonctionnalités Kubernetes, simplicité de déploiement et faible empreinte.

Pourquoi Tailscale ?

Les deux machines utilisées dans ce projet ne se trouvent pas nécessairement sur le même réseau.

Le serveur GPU peut être hébergé chez un fournisseur cloud ou sur une infrastructure distante. Il faut donc permettre au control plane et au worker de communiquer de manière fiable sans dépendre d’une connexion réseau locale. Pour cela, nous utiliserons Tailscale.

Tailscale permet de créer un réseau privé entre les machines autorisées et s’appuie sur WireGuard pour le chiffrement des communications entre les nœuds. L’intérêt ici est surtout de disposer d’une connectivité privée entre les deux machines sans avoir à exposer directement le serveur Kubernetes sur Internet.

Prérequis

Pour reproduire cette architecture, il faut au minimum :

• une première machine Linux pour le serveur K3s (control plane) ;
• une seconde machine Linux équipée d’un GPU NVIDIA, avec un accès administrateur complet (une VM avec accès système total plutôt qu’un conteneur restreint, si vous utilisez un fournisseur de GPU cloud) ;
• un accès root ou sudo sur les deux machines ;
• un compte Tailscale (gratuit pour un usage personnel/lab) ;
• une connectivité Internet sur les deux machines.

Le serveur GPU doit également disposer d’un pilote NVIDIA fonctionnel.

Vous pouvez vérifier le GPU avec :

nvidia-smi

Si cette commande fonctionne correctement, vous disposez déjà d’une première validation du matériel et du pilote.

Pour aller plus loin sur le diagnostic d’un GPU NVIDIA sous Linux, voir mon article précédent : Administrer un GPU NVIDIA sous Linux : les commandes essentielles

Conclusion

Cette première étape permet de poser les bases de la plateforme.

L’objectif n’est pas encore de servir un modèle ou de construire une interface de chat, mais de disposer d’une infrastructure sur laquelle ces composants pourront être déployés proprement. Dans le prochain article, nous allons :

• installer K3s sur le nœud control plane ;
• installer et configurer Tailscale sur les deux machines ;
• préparer le serveur équipé de la NVIDIA RTX 3090 ;
• joindre le serveur GPU au cluster comme worker node ;
• vérifier que les deux nœuds communiquent correctement ;
• vérifier que Kubernetes détecte et expose bien le GPU.

Une fois cette fondation en place, nous pourrons commencer à déployer la première véritable brique de la plateforme : vLLM, pour servir un modèle de langage directement depuis notre cluster Kubernetes.