RustGPT : un LLM transformeur pur entièrement implémenté en Rust depuis zéro

• RustGPT est un modèle de langage basé sur un transformeur implémenté sans framework de machine learning externe, uniquement avec Rust pur et ndarray
• Il est conçu pour apprendre des connaissances factuelles et des schémas conversationnels via le pré-entraînement (pre-training) et le réglage par instructions (instruction tuning)
• Sa structure suit une architecture LLM classique : tokenizer → embeddings → blocs de transformeur → projection de sortie
• Il fournit une structure de code modulaire et du code de test, ce qui permet de comprendre en détail les processus d’entraînement, d’inférence et d’optimisation
• C’est une ressource de référence importante pour les développeurs et apprenants de l’écosystème Rust qui veulent implémenter un LLM depuis zéro sans dépendre d’un framework

---

Aperçu du projet

• RustGPT est un projet open source qui implémente un LLM uniquement avec le langage Rust et la bibliothèque d’algèbre linéaire (ndarray), sans framework de machine learning externe ni dépendances complexes
• Son objectif principal est d’implémenter directement les composants essentiels des LLM modernes (transformeur, attention, embeddings, optimisation, etc.) et de comprendre le processus d’entraînement
• Contrairement à d’autres LLM grand public, il conçoit directement en code Rust l’ensemble de la structure du transformeur, de la rétropropagation, du tokenizer et de l’optimiseur, ce qui permet aux développeurs et chercheurs Rust de comprendre et d’étendre les principes du deep learning depuis les bases
• Son élément distinctif est l’utilisation de ndarray pour les opérations matricielles, sans dépendre de packages de machine learning externes comme PyTorch ou TensorFlow
• Grâce à une modularité solide et à une bonne couverture de tests, il convient à divers expérimentations et améliorations, ainsi qu’à un usage pédagogique de type « LLM from scratch »

Principales caractéristiques et méthode d’implémentation

• Architecture transformeur : texte d’entrée → tokenisation → embeddings → blocs de transformeur → prédiction finale
  • Le texte d’entrée passe par un processus de tokenisation avant d’être converti en vecteurs d’embeddings
  • Les embeddings traversent des Transformer Blocks (attention multi-tête + réseau feed-forward)
  • Enfin, la couche de projection de sortie génère une distribution de probabilité sur le vocabulaire afin d’effectuer la prédiction

Structure de l’implémentation

• main.rs : pipeline d’entraînement, préparation des données, exécution du mode interactif
• llm.rs : logique globale de propagation avant, rétropropagation et entraînement du LLM
• transformer.rs, self_attention.rs, feed_forward.rs : blocs de transformeur principaux
• embeddings.rs, output_projection.rs : embeddings et couche de sortie finale
• adam.rs : implémentation de l’optimiseur Adam
• Chaque module inclut un code de test correspondant (tests/) permettant de valider les fonctionnalités

Méthode d’entraînement, de test et flux de données

• Processus d’entraînement
  • Construction du vocabulaire → pré-entraînement (100 epochs, données de phrases factuelles) → instruction tuning (100 epochs, données conversationnelles)
  • Exemple de pré-entraînement : "The sun rises in the east and sets in the west"
  • Exemple d’instruction tuning : "User: How do mountains form? Assistant: ..."
• Prise en charge du mode interactif
  • Une fois l’entraînement terminé, il est possible de tester des échanges basés sur prompt-réponse
  • Exemple : "How do mountains form?" → "Mountains are formed through tectonic forces or volcanism..."

Détails techniques

• Taille du vocabulaire : configuration dynamique basée sur les données d’entraînement
• Dimension des embeddings : 128, couches cachées : 256
• Longueur maximale de séquence : 80 tokens
• Architecture : 3 blocs de transformeur + embeddings + couche de sortie
• Algorithme d’entraînement : optimiseur Adam, gradient clipping (limite de norme L2 à 5.0)
• Taux d’apprentissage : pre-training 0.0005, instruction tuning 0.0001
• Fonction de perte : cross-entropy loss

Caractéristiques du modèle et du code

• Tokenizer personnalisé (gestion de la ponctuation)
• Génération de texte basée sur le greedy decoding
• Structure en couches modulaire et interfaces claires
• Couverture de tests : tests unitaires fournis pour chaque couche et fonctionnalité
• Dépendances : uniquement ndarray (opérations matricielles), rand / rand_distr (initialisation aléatoire), sans ML externe comme PyTorch/TensorFlow
• Valeur pédagogique : idéal pour apprendre la structure interne et les principes d’entraînement des LLM modernes

Possibilités d’évolution

• Intégration d’architectures avancées : attention multi-tête, RoPE, encodage positionnel, etc.
• Optimisation des performances : SIMD, entraînement parallèle, amélioration de l’efficacité mémoire
• Prise en charge de la sauvegarde/du chargement du modèle
• Ajout d’un échantillonnage amélioré (beam search, Top-k/Top-p) et de métriques d’évaluation

Importance

• Projet d’apprentissage et d’expérimentation montrant qu’il est possible d’implémenter directement un LLM uniquement en Rust, sans dépendre de frameworks Python comme PyTorch ou TensorFlow
• Une référence utile pour les développeurs qui veulent comprendre le fonctionnement interne des LLM et construire des systèmes de ML dans un environnement Rust

[t7vonn]

C’est propre.

[ahwjdekf]

Pourquoi donc ? C’est du genre : moi aussi, je peux faire ça ?

[cosine20]

La grandeur d’un karma à -47 mdr

[skrrgang]

Rien qu’à voir le r de Rust, ça vous démange et ça vous énerve, pas vrai ? hahaha

[aer0700]

Il y aura sûrement des choses à apprendre en le construisant.

[devjeonghwan]

On ne peut pas le créer sans l’avoir essayé.

[GN⁺]

Avis Hacker News

• On voit du code avec des commentaires générés automatiquement par GPT ou des constantes déjà définies réécrites en double, donc je pense qu’il faudrait supprimer ce genre de choses. Par exemple, des constantes comme const MAX_SEQ_LEN: usize = 80 existent déjà dans lib.rs, donc il vaudrait mieux utiliser directement ces constantes comme l’indique le commentaire

  • Le fait que ce genre de chose soit resté montre à mon avis que le résultat n’a pas été réellement produit avec compréhension par le développeur
  • Je me demande si une PR liée a été envoyée
  • Concernant la manière d’utiliser les constantes, l’auteur ne savait peut-être simplement pas comment faire. Moi aussi, durant ma première semaine avec Rust, je me souviens avoir beaucoup réfléchi au nommage et à la structure du code
  • Je me demande si un style Rust de vibe coding risque de faire baisser la qualité globale du code dans l’écosystème
  • Je pense que cette remarque est tout à fait juste

• J’ai déjà perdu plusieurs jours dans l’enfer des dépendances Python, donc l’approche Rust où un simple cargo run suffit me semble vraiment être un rêve. Mais je suis curieux de savoir quelle a été la partie la plus douloureuse sans framework. Je parierais sur le débogage de la logique de backpropagation

  • Je recommande l’outil uv. Pour l’avoir utilisé moi-même, il a rendu l’exécution des projets Python 90 % plus pratique Voir uv
  • Je pense que le plus difficile est du côté de l’utilisation des ressources, comme le GPU
  • Cette manière de parler des problèmes de dépendances Python pouvait se comprendre vers 2010, mais en 2025 je trouve que c’est une énorme exagération
  • On dit que cargo run est un rêve, mais en réalité je trouve encore mieux l’expérience typique de cargo build, qui recompile tout Internet et réchauffe le CPU en hiver
  • J’ai l’impression que les gens qui encensent cargo comprennent mal les compromis de la gestion des dépendances. Recompiler toutes les bibliothèques à chaque fois comme en C est inefficace, mais des systèmes comme npm ou cargo, qui permettent d’ajouter trop facilement des dépendances, entraînent aussi de sérieux inconvénients comme la prolifération des dépendances, les temps de build et les problèmes de sécurité. Un bon système de build n’est pas forcément synonyme de facilité à ajouter des dépendances, et je ne pense pas non plus qu’un modèle où n’importe qui peut enchevêtrer des dépendances dans un dépôt centralisé soit vraiment sain

• Je travaille sur un projet Rust similaire. Il existe une version qui tourne dans le navigateur via WebAssembly, et le démo navigateur ainsi que le code source sont publics

• L’ensemble de packages ndarray, rand, rand_distr a l’air propre

  • Par curiosité, j’ai regardé l’arbre des dépendances avec cargo tree, et pour l’instant il semble encore propre
  • Je ne pense pas que cet arbre ait une grande signification. Le code peut très bien être inefficace parce qu’il réimplémente des choses à la main, et selon les cas il peut même être préférable d’utiliser correctement des bibliothèques externes
  • Je me demande si cette appréciation est ironique, ou s’il manque du contexte

• Je pense que la sûreté mémoire de Rust est assez utile pour réduire les buffer overflows dans l’implémentation d’un transformer. Les kernels CUDA gardent malgré tout un avantage en performances. Je me demande aussi si le tokenizer recrée un BPE ou s’il utilise une bibliothèque existante

• Moi aussi, en créant picogpt en Rust, je me suis beaucoup appuyé sur le billet GPT from scratch de jaykmody. Lien du projet

• Félicitations, et je voudrais ajouter une petite remarque : dans un LLM, il vaudrait mieux ne pas réutiliser le même transformer block mais donner à chacun sa propre instance. J’ai moi aussi déjà fait un exercice de ce type pour construire les bases avec Zig et MLX, puis j’ai progressivement ajouté des fonctionnalités avant de basculer vers PyTorch/Transformers

  • Cela dit, je pense que ce genre d’exercice n’a de sens que lorsqu’on écrit soi-même le code. L’intérêt est dans le fait de le construire sans l’aide de GPT

• Le commentaire de l’auteur du projet est récapitulé sur Reddit

• J’aime le fait que l’ensemble du projet ait une structure vraiment facile à lire

  • Je voudrais signaler qu’il s’agit de code généré par IA
  • Le style est très procédural / orienté objet, donc il est difficile de dire qu’il s’agit d’un bon style Rust au sens strict. Un style plus fonctionnel, avec des itérateurs et des enum, est généralement considéré comme plus concis et plus idéal. Mais comme expérimentation d’idées, c’est largement acceptable
  • Je ne savais pas que Rust pouvait être aussi lisible. J’ai même parfois l’impression que les ingénieurs Rust évitent ce genre de code simple et se livrent à une sorte de concours d’auto-sabotage. Du coup, tout ce que j’ai vécu avec la communauté Rust et la culture du recrutement me paraît cohérent

• Je suis curieux de connaître la source du dataset. Je vais chercher moi-même, mais je laisse la question. J’ai développé une architecture qui fonctionne surtout sur CPU et sans backpropagation, et elle marche bien sur des datasets de classification. Elle permet des mises à jour incrémentales à l’exemple unique, donc elle pourrait aussi servir pour l’apprentissage continu. Je n’ai fait qu’un entraînement de démonstration sur tiny.txt, et je n’ai encore jamais essayé de grand modèle de langage. Comme mon architecture semble pouvoir assez bien fonctionner comme assistant on-device ou on-premise, je vais continuer à expérimenter. Je me demande s’il existe des datasets open source d’entraînement LLM à recommander

  • Le Hermes-3 Dataset est pas mal
  • Sur Hugging Face, il existe divers jeux de chaînes utilisateur-assistant issus d’OpenAI et d’Anthropic, mais il faut faire attention car il y a beaucoup d’hallucinations. Pour l’instruction fine-tuning, c’est plutôt correct. Si ce que tu veux, c’est l’instruction following, je recommande kimi k2 distillation
  • Ce projet inclut directement les données d’entraînement dans le fichier main.rs. Il s’agit d’environ 50 phrases courtes de culture générale, probablement pour réduire le temps d’entraînement. Du coup, hors données de type script, les performances chutent brutalement. Exemples de prompts et résultats :
    • entrée "hello" : "Eclipses occur when one celestial body moves into the shadow of another", etc., ce qui correspond assez bien
    • entrée "what are facts" : répétition d’une liste de mots sans signification
    • entrée "how are mountains formed?" : sortie incohérente avec des mots disjoints et sans sens