Gemma 4 26B : Comment faire tourner un LLM en 2 Go de RAM

Si vous souhaitez exécuter localement un modèle de langage de 26 milliards de paramètres, les mathématiques standards sont brutales. Lorsque vous essayez de forcer un modèle de 14 Go dans un espace de 8 Go en utilisant des protocoles de chargement standard, le système d’exploitation panique, tentant de swapper rapidement les données entre le SSD et la RAM, entraînant un thrashing massif et un gel complet du système.

Mais TurboFare adopte une approche différente. C’est un runtime personnalisé spécifique au modèle, construit en Swift et Metal, conçu exclusivement pour contourner ce plafond mémoire. Il exécute avec succès le modèle Gemma 4 26B instruction-tuned en utilisant seulement 2 Go de RAM active, réalisant une réduction de sept fois de la surcharge mémoire.

01 Le problème de la mémoire

Le diagramme ci-dessous compare les besoins de stockage de base par rapport au matériel Apple d’entrée de gamme :

Charger le modèle complet en mémoire d’un coup fait du nombre de 26 milliards de paramètres un mur infranchissable pour les machines de 8 Go. Le matériel rejette simplement cette charge de travail massive.

02 L’architecture Mixture of Experts (MoE)

Le secret de ce budget de 2 Go réside dans l’architecture du modèle. Gemma 4 26B est construit sur une topologie Mixture of Experts (MoE).

Dans un modèle dense standard, chaque paramètre calcule chaque mot. Mais dans un MoE, seuls les experts routés sont actifs. Sur 26 milliards de paramètres totaux, seulement 3,88 milliards s’activent lors d’un seul calcul, car plus de 80% du modèle reste inactif à chaque étape.

03 La solution TurboFare

TurboFare réécrit la boucle d’inférence depuis zéro. Au lieu de s’appuyer sur la capacité brute de la RAM, il mise sur un I/O précis et à la demande du SSD vers Metal.

Répartition de la mémoire (2 Go)

À partir du fichier modèle de 14,3 Go sur SSD, exactement 1,35 Go de poids de base partagés sont extraits et épinglés en permanence en RAM. La mémoire résidente restante (cache KV) se divise en deux chemins : un buffer circulaire borné et une configuration linéaire.

Tous les autres éléments, spécifiquement les experts routés, se voient refuser la résidence en RAM. Ils restent sur le SSD jusqu’à la milliseconde exacte où ils sont nécessaires.

Pour garantir que ces experts puissent voyager assez vite, ils sont compressés en utilisant la quantification 4-bit MLX, gardant leurs tailles de fichier petites et hautement portables.

04 Implémentation technique

Le pipeline de traitement

Le traitement d’un seul token se divise en branches CPU (routage) et GPU (calcul) :

1. CPU Routing : Utilise des poids de routeur 8-bit pour calculer les top 8 experts requis
2. Cache Query : Interroge un cache à 16 slots pour les experts en attente
3. SSD Fetch : Si l’expert n’est pas en cache, déclenche une phase I/O immédiate avec des appels parallèles
4. Direct to Metal : Stream les poids manquants du SSD directement dans les buffers visibles Metal

Concurrence pour masquer la latence

Cette architecture a une vulnérabilité évidente : même les lectures SSD les plus rapides sont considérablement plus lentes que l’accès direct à la RAM. TurboFare utilise la concurrence pour masquer le délai :

Pendant que le CPU et le SSD sont occupés à récupérer les experts routés, le pipeline GPU ne reste pas inactif. Il calcule immédiatement la branche d’expert partagé en utilisant les poids résidents en RAM. Une fois que les experts SSD arrivent, les deux sorties se combinent parfaitement.

Chunked Prefill

Générer des tokens un par un n’est que la moitié du processus. Le moteur doit aussi ingérer le prompt initial de l’utilisateur (phase de prefill). TurboFare traite les prompts par blocs de 128 tokens maximum à la fois.

Cela permet à un seul expert récupéré du SSD d’être appliqué à plusieurs lignes de données simultanément, réutilisant un expert pour des dizaines de tokens, réduisant drastiquement la bande passante mémoire requise.

Streaming Repacker

Cette limitation stricte de la mémoire s’étend jusqu’au téléchargement initial du modèle depuis Hugging Face. Le streaming repacker télécharge les byte ranges distants et les emballe directement dans le format de fichier local .turbo sur le disque, contournant complètement toute étape où le checkpoint complet pourrait s’accumuler en mémoire active.

05 Performances réelles

La valeur de ce moteur repose entièrement sur sa qualité d’exécution en pratique. Voici les résultats du benchmark sur un MacBook Air M2 8 Go de base :

Ces vitesses fluctuent naturellement en fonction de la longueur de votre prompt, de l’état actuel du page cache et de vos spécifications matérielles exactes. Mais les chiffres de base prouvent la thèse centrale : l’inférence locale n’est plus strictement limitée par la quantité de RAM achetée.

06 Implications pour les ingénieurs

Pour les ingénieurs systèmes et les praticiens du machine learning, cela change la façon dont nous évaluons les contraintes matérielles :

• Les wrappers génériques offrent une commodité incroyable, mais leurs hypothèses mémoire monolithiques masquent ce que le matériel sous-jacent est réellement capable de traiter
• Pousser une machine d’entrée de gamme à sa limite absolue nécessite de construire directement pour son architecture
• Utiliser Swift et Metal permet d’extraire chaque once d’optimisation

Le projet réussit en laissant les mathématiques du transformer intactes et en réorganisant la façon dont le matériel gère la propriété des données. En orchestrant le CPU, le GPU et le SSD en un pipeline concurrent unifié, les ingénieurs peuvent déployer des réseaux d’IA massifs sur du matériel grand public qui était supposé être trop petit pour les exécuter.