Un hub IA auto-hébergé, sans dépendre d’un fournisseur

À force de dépendre d’API propriétaires, on finit par construire sur du sable : tarifs qui bougent, conditions qui changent, données qui partent ailleurs. D’où l’envie d’un hub que l’on contrôle. Cet article est mon article témoin : il sert aussi à montrer tous les formats de contenu que ce blog sait afficher.

Un fournisseur, c’est pratique — jusqu’au jour où c’est lui qui décide à votre place.
Le raisonnement de départ

L’architecture en bref

Une passerelle en façade reçoit les requêtes et les route vers un moteur d’inférence qui fait tourner des modèles open-weights. La puissance GPU peut être louée à la demande plutôt que possédée. Voici à quoi ressemble le tableau de bord une fois l’ensemble en place.

capture · dashboard

Figure 1. Le tableau de bord de la passerelle : requêtes entrantes, modèle actif et charge GPU en temps réel.

Les trois briques se répartissent les rôles ainsi :

Une passerelle légère pour l’entrée des requêtes et l’authentification.
Un moteur type vLLM pour servir les modèles efficacement.
Du GPU cloud à l’heure pour absorber les pics sans surinvestir.

La mise en route, étape par étape

Concrètement, voici l’ordre dans lequel je monte l’ensemble — chaque étape est vérifiable avant de passer à la suivante.

Provisionner une machine GPU et installer le moteur d’inférence.
Exposer la passerelle derrière un reverse-proxy avec TLS.
Brancher l’authentification fédérée.
Router un premier modèle et mesurer la latence.

Bon à savoir

Commencez avec un seul petit modèle. Vous validez toute la chaîne — réseau, auth, inférence — avant d’investir dans du gros GPU. Un Q4_K_M de 7B suffit pour le rodage.

Choisir sa puissance GPU

Le bon dimensionnement dépend du modèle visé et du débit attendu. Ce tableau donne des ordres de grandeur pour démarrer :

Profil	VRAM	Modèle type	Coût indicatif
Rodage	12–16 Go	7B quantifié	~0,40 €/h
Production légère	24 Go	13B	~0,90 €/h
Charge soutenue	48 Go+	30B+	~2,50 €/h

Loué à l’heure et éteint hors usage, le poste GPU reste très en-dessous d’un abonnement d’API à volume équivalent.

Router un modèle

Côté passerelle, exposer un modèle tient en quelques lignes de configuration. On déclare le point d’entrée et le moteur cible :

yaml

routes:
  - path: /v1/chat/completions
    upstream: vllm://localhost:8000
    model: mistral-7b-q4
    auth: required   # via identité fédérée

Un simple appel permet ensuite de vérifier que tout répond :

bash

curl https://hub.exemple.fr/v1/chat/completions 
  -H "Authorization: Bearer $TOKEN" 
  -d '{"model":"mistral-7b-q4","messages":[{"role":"user","content":"ping"}]}'

L’authentification fédérée

Plutôt qu’un énième système de comptes, je m’appuie sur des identités fédérées (logique ActivityPub). Cohérent avec une philosophie Fediverse : des espaces communautaires, ouverts, non captifs. Pour approfondir, voir le lexique sur les briques d’infrastructure.

Attention

Ne jamais exposer le moteur d’inférence directement sur Internet. Il doit rester derrière la passerelle, qui porte l’authentification et le rate-limiting. Un port 8000 ouvert, c’est une facture GPU offerte au premier venu.

Ce que ça change, au fond

Le gain final n’est pas que technique. C’est de pouvoir dire à un client : vos données restent chez vous, et votre outil ne dépend pas du bon vouloir d’un fournisseur. C’est exactement l’esprit de l’axe Maîtriser : comprendre sa chaîne pour ne plus la subir.