Nanochat : le boom du ChatGPT self-host à 100 $ – comment en tirer parti dans votre homelab

Nanochat, le nouveau dépôt open source d’Andrej Karpathy, promet un ChatGPT auto-hébergé pour 100 $ : voici comment l’exploiter dans un homelab.

Si vous traînez sur GitHub ou dans les salons DevOps cette semaine, impossible d’échapper à nanochat. En six jours à peine, le dépôt d’Andrej Karpathy a dépassé la barre des 27 000 étoiles et devient l’exemple le plus spectaculaire de LLM « self-host » à coût contenu. Pour un blog axé infrastructure libre et retours d’expérience, c’est l’occasion rêvée de décortiquer ce qui se cache derrière la promesse marketing : « the best ChatGPT that $100 can buy ».

https://github.com/karpathy/nanochat/tree/master/nanochatLogo de nanochat, projet de LLM auto-hébergé
Le logo du projet nanochat, déjà star de GitHub.

Pourquoi nanochat explose les compteurs en ce moment

L’engouement ne relève pas (uniquement) de la hype autour de Karpathy. Nanochat coche plusieurs cases qui parlent à notre communauté :

  • Pipeline complet et transparent : tokenisation, pré-entraînement, fine-tuning, évaluation et interface Web sont regroupés dans un même dépôt MIT.
  • Coût serré documenté : le script speedrun.sh entraîne un modèle de 1,9 Md de paramètres (profondeur 32) en ~4 heures sur un nœud 8x H100, soit ~800 $ publiquement détaillés.
  • Documentation soignée : rapport automatique (report.md) en fin de run, walkthrough pas-à-pas et discussions communautaires actives.
  • Momentum externe : le dépôt est en haut des tendances GitHub (créé le 13 octobre 2025, dernier push ce matin) et alimente déjà les threads sur les forums d’obs et d’auto-hébergement.

La vraie question pour nous n’est donc pas « est-ce que c’est hype », mais « comment l’intégrer intelligemment dans un stack d’auto-hébergement ou de R&D interne ?»

Architecture : une stack LLM compacte mais complète

Nanochat ambitionne d’être le projet « capstone » du cours LLM101n d’Eureka Labs. Concrètement, le dépôt assemble :

  • Un jeu de scripts orchestrés par speedrun.sh pour entraîner le modèle « $100 » (d32) en un seul tenant.
  • Une pile Python légère (gestion des dépendances via uv) pour limiter la dette logicielle.
  • Des modules d’évaluation (CORE, ARC, GSM8K, HumanEval, MMLU) intégrés dans le rapport final.
  • Un serveur Web minimaliste (python -m scripts.chat_web) qui offre une UI type ChatGPT directement depuis la machine d’entraînement.

C’est cette compacité qui séduit : on peut suivre le pipeline de bout en bout, l’instrumenter et le forker sans se battre avec une constellation de sous-modules opaques.

Préparer l’infrastructure : cloud GPU ou homelab musclé ?

Le marketing « $100 » part d’un postulat : vous louez une machine 8x H100 autour de 24 $/h. Dans les faits, peu de labs persos disposent de cette artillerie. Quelques pistes pour rester dans l’esprit tout en collant à la réalité de nos infrastructures :

  • Location ponctuelle : Lambda, RunPod, Vast.ai proposent des nœuds multi-H100 à l’heure. On garde l’expérience complète, mais on planifie précisément la fenêtre d’exécution.
  • Homelab haute performance : un châssis 4x RTX 4090 (ou 2x H100 PCIe) suffit pour reproduire le run en ajustant la taille du batch et la durée.
  • Approche hybride : entraînement initial sur le cloud, puis inference + fine-tuning léger à la maison grâce aux poids exportés (*.safetensors).

Pour visualiser l’impact budget vs. matériel, voici un ordre de grandeur :

Profil Matériel Durée estimée Coût total Notes
Speedrun officiel 8x H100 SXM ~3h51 ~800 $ Stack validée par Karpathy
Homelab enthusiast 4x RTX 4090 ~12h <=150 $ d’énergie Réduire micro_batch_size et activer flash-attn
Cloud spot 4x H100 PCIe ~6h 300 $ Nécessite une surveillance des interruptions

Le point clef : nanochat reste un LLM conséquent. Il n’est pas réaliste de lancer un entraînement from scratch sur un NUC fanless, mais l’infra nécessaire est désormais accessible à une TPE ou à un homelab très avancé.

Lancer nanochat : walkthrough rapide

Une fois la machine trouvée, le déroulé est presque scolaire :

  1. Cloner et préparer l’environnement 
    git clone https://github.com/karpathy/nanochat.git
cd nanochat
uv sync
  2. Configurer les chemins de données
    Personnalisez conf/run/speedrun.yaml pour stocker les jeux de données et checkpoints sur un volume rapide (NVMe ou réseau local haute perf).
  3. Lancer l’entraînement 
    bash speedrun.sh

    Optionnel : encapsulez la commande dans screen ou tmux pour garder la main sur la session (screen -L -S speedrun bash speedrun.sh).

  4. Suivre le run
    Analysez les logs temps réel (tail -f speedrun.log), surveillez la saturation GPU avec nvidia-smi dmon et notez les métriques qui chutent dans report.md.
  5. Servir l’interface 
    source .venv/bin/activate
python -m scripts.chat_web --host 0.0.0.0 --port 8000

    Exposez ensuite le port derrière un reverse-proxy (Traefik, Caddy) pour sécuriser l’accès HTTPS.

Par défaut, on obtient un modèle « d32 » d’~1,9 Md de paramètres. C’est ludique et utile pour prototyper une brique conversationnelle interne (FAQ, support automatisé, etc.), mais il faut accepter des hallucinations fréquentes : viser une couche d’orchestration (RAG, filtres de sécurité) reste indispensable.

Brancher nanochat sur un stack existant

L’exercice « trend » est intéressant s’il alimente des chantiers concrets. Quelques idées glanées auprès de la communauté auto-hébergée :

  • Kubernetes GPU operator : empaquetez l’app Web dans un conteneur et pilotez les GPU via NVIDIA GPU Operator + Device Plugin.
  • SSO et observabilité : mettez l’UI derrière votre fournisseur OIDC (Authelia, Keycloak) et collectez les métriques (prometheus_client) pour suivre latence et tokens générés.
  • Intégration RAG : couplez nanochat avec un vecteur store (Qdrant, Weaviate) pour contextualiser les réponses sur votre base documentaire interne.
  • MLOps maison : versionnez les checkpoints dans MinIO, automatisez le nettoyage des datasets et des artefacts avec Argo Workflows ou GitHub Actions self-hosted.

C’est à ce niveau que l’ADN du blog ressort : nanochat n’est qu’une brique, l’intérêt est de l’insérer dans une architecture maîtrisée, sécurisée et reproductible.

Aller plus loin : fine-tuning, gouvernance et limites

Le projet fournit déjà plusieurs scénarios (run1000.sh, run300.sh) qui explorent différentes profondeurs et budgets. À vous d’expérimenter sur les axes suivants :

  • Datasets sur-mesure : enrichissez data/sources.yaml avec vos corpus maison (tickets support, documentation interne) en gardant un œil sur la licence.
  • Évaluation continue : intégrez le rapport à un pipeline CI (ex : GitLab CI + pytest pour valider quelques prompts critiques).
  • Guardrails : associez un filtre type NeMo Guardrails ou structured-output pour encadrer ce que le modèle peut répondre.
  • Plan de sobriété : script d’arrêt automatique des GPU hors utilisation, mesure de l’empreinte carbone et gestion de la déchets dataset.

Gardez en tête les limites intrinsèques : on reste sur un modèle « micro » face aux mastodontes propriétaires. Nanochat est parfait pour comprendre la chaîne LLM, tester l’industrialisation interne ou proposer un agent spécialisé, pas pour remplacer un GPT-5 en production client.

Checklist express

  • 📈 Surveiller les issues du dépôt : les correctifs tombent quasiment chaque jour depuis l’annonce.
  • 🧪 Mettre en place un jeu de prompts de validation dès le premier run.
  • 🔐 Cadenasser l’accès au service Web (OIDC, réseau privé, quotas).
  • 💾 Externaliser les checkpoints lourds sur du stockage objet répliqué.
  • ♻️ Documenter précisément votre variante pour la partager (ou la rejouer) avec l’équipe.

La tendance nanochat illustre une dynamique claire : l’écosystème open source s’organise pour rendre les LLM avancés réellement auto-hébergeables. À nous de saisir la vague pendant qu’elle est haute, d’en mesurer les limites et d’en tirer des architectures robustes. Rendez-vous dans les commentaires ou sur le canal Matrix habituel si vous avez déjà branché nanochat à vos stacks maison !

Étiquettes

Publications similaires