TurboFieldfare : Gemma 4 26B-A4B sur un MacBook 8 Go, experts en streaming depuis le SSD

Le problème : 14,3 Go de poids pour une machine qui en a 8

Gemma 4 26B-A4B compte 26 milliards de paramètres au total, mais seulement environ 3,88 milliards sont actifs par token. C'est cette dissymétrie qui rend le projet possible. Le README indique que TurboFieldfare ne charge jamais l'intégralité du modèle : il conserve en mémoire le cœur partagé de 1,35 Go et le cache KV FP16, puis fait défiler depuis le SSD uniquement les experts requis pour chaque token. La cible revendiquée est donc un Mac Apple Silicon disposant de 8 Go de RAM, avec un M2 MacBook Air 8 Go comme machine validée. Le public visé n'est pas celui qui possède déjà 64 Go de mémoire unifiée et peut charger le modèle entier. C'est celui qui a un portable d'entrée de gamme, qui refuse d'envoyer ses requêtes à une API distante, et qui accepte en échange des débits mesurés de l'ordre de 5,1 à 6,3 tok/s sur M2. Le projet est explicitement mono-modèle : ce n'est pas un wrapper autour de MLX ou de llama.cpp, mais un runtime écrit pour cette architecture précise. Ce choix explique à la fois les gains de mémoire et la rigidité du résultat.

Architecture : cœur résident, experts en streaming, routeur 8 bits

La quantification est décrite précisément dans le README : poids en MLX affine 4 bits avec un groupe de 64, routeur en 8 bits, experts partagés et routés en 4 bits. Le découpage est cohérent avec le mécanisme de streaming. Ce qui est lu à chaque token doit rester petit et rapide à charger, d'où les 4 bits sur les experts. Ce qui décide quels experts lire doit rester précis, d'où les 8 bits sur le routeur. Le cache KV est conservé en FP16 pour 4K de contexte, et l'ensemble poids plus cache tient dans environ 2 Go. Six produits Swift composent le paquet : la bibliothèque TurboFieldfare avec le runtime et les noyaux Metal, l'application TurboFieldfareMac, le service TurboFieldfareDecodeService qui possède le modèle et le contexte Metal, la CLI TurboFieldfareCLI, le serveur loopback TurboFieldfareServer, et l'installateur TurboFieldfareRepack. Le README précise qu'un seul produit propriétaire du modèle doit tourner à la fois. Cette contrainte n'est pas anodine : elle signifie que l'application et le serveur ne peuvent pas se partager le modèle, et que toute intégration doit prévoir un arbitrage explicite entre les deux.

Installation : build SPM, repack du modèle, premier lancement

Les commandes du README sont directes. On clone le dépôt, on compile en release, on lance l'application :

git clone https://github.com/drumih/turbo-fieldfare.git cd turbo-fieldfare swift build -c release .build/release/TurboFieldfareMac

Au premier build, Swift Package Manager télécharge et compile les paquets requis par le tokenizer. Le README insiste sur un point : il faut construire le paquet complet pour que l'application et son exécutable frère de décodage soient tous deux disponibles. Une fois l'application ouverte, on choisit Download et le projet récupère puis repacke le modèle épinglé, environ 15 Go. Ensuite Load Model, saisie du prompt, Generate. Les prérequis sont stricts : macOS 26 avec Metal 4, Xcode 26 et Swift 6.2 ou plus récent, un Mac Apple Silicon, et assez d'espace libre pour les 14,3 Go du modèle texte. Le paquet est arm64 uniquement, et les versions antérieures de macOS et de Metal ne sont pas prises en charge. Les valeurs par défaut de génération sont temperature 0.2, Top-K 64 et Top-P 0.95. Le README note qu'une temperature de 0 donne une sortie gloutonne déterministe, et que le modèle peut malgré tout se répéter ou se tromper.

Le serveur loopback et la question des outils

TurboFieldfareServer expose une API Chat Completions compatible OpenAI, mais uniquement en loopback. La différence avec l'application et la CLI se situe au niveau des outils : l'application et la CLI gèrent les messages utilisateur et modèle plus des consignes système optionnelles, et n'exposent ni n'exécutent d'outils. Le serveur, lui, accepte des déclarations de fonctions et renvoie des appels d'outils produits par le modèle, que le client doit autoriser et exécuter. C'est une séparation de responsabilité correcte : le runtime ne prend jamais l'initiative d'appeler quoi que ce soit. Elle a un coût, en revanche. Toute intégration qui attend un comportement d'agent doit implémenter elle-même la boucle d'autorisation et d'exécution. L'audio et la vidéo ne sont pas pris en charge. Les images passent par une tour de vision installée comme pack compagnon à côté du modèle texte, une installation unique qui sert ensuite à l'application, à la CLI et au serveur. Sans ce pack, les trois produits signalent que le support image est indisponible, sans toucher au runtime texte. La tour image exige un M2 ou plus récent : sur M1, l'inférence texte reste possible, mais pas les images.

Ce que le projet ne fait pas, et à quel prix

La limite principale est structurelle : le débit dépend du SSD. Les experts sont lus à chaque token, ce qui place le disque sur le chemin critique. Le README le reconnaît à sa manière en listant les facteurs qui influencent le débit : longueur du prompt, longueur générée, état du cache de pages, matériel. Le cache de pages est justement le point instable. Un modèle qui vient d'être utilisé peut rester partiellement en mémoire et accélérer les tokens suivants ; après un redémarrage ou une pression mémoire, les mêmes requêtes peuvent ralentir. Le projet est également mono-modèle par construction. Si vous devez servir plusieurs modèles, ou changer de modèle selon la tâche, l'architecture de streaming des experts ne vous aidera pas : elle est taillée pour Gemma 4 26B-A4B et pour lui seul. La plateforme est un autre verrou. macOS 26 et Metal 4 ne sont pas des choix par défaut sur un parc existant, et le paquet arm64 uniquement exclut toute machine Intel. Enfin, la multimodalité est réservée au M2 et au-delà, ce qui contredit partiellement la promesse d'un projet qui tourne sur du matériel d'entrée de gamme.

Face à llama.cpp et MLX : deux philosophies opposées

La comparaison utile n'est pas celle des débits, mais celle de la stratégie mémoire. llama.cpp et MLX chargent les poids du modèle en mémoire unifiée, avec quantification et offload partiel sur le GPU. Leur approche est générale : un même binaire sert des dizaines d'architectures, et le débit dépend surtout de la bande passante mémoire et du nombre de couches déchargées. TurboFieldfare fait l'inverse. Il ne charge pas les poids, il les streame depuis le SSD, et il n'implémente qu'un modèle. Le bénéfice est net sur une machine à 8 Go, où aucune des deux autres solutions ne peut tenir un modèle de 26 milliards de paramètres sans pagination agressive. Le coût est tout aussi net : vous héritez d'une base de code qui ne servira jamais à autre chose, et dont la performance est liée à un composant matériel que vous ne contrôlez pas. Le README mentionne un enregistrement d'expériences documentant 103 résultats mesurés sur les noyaux, le cache, les E/S, le prefill et le decode. C'est le signe d'un travail d'optimisation sérieux, mais aussi d'un projet dont la valeur est concentrée dans un seul modèle.

Maintenance, licence et vérifications avant adoption

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'état des modifications. Ce n'est pas un avis juridique : si vous redistribuez le paquet ou l'application, faites vérifier les mentions et les conditions de redistribution du modèle Gemma lui-même, qui relèvent de Google et non d'Apache-2.0. Le rythme de publication est soutenu : 0.7.1 le 28 août 2026, 0.7.2 le 4 septembre 2026, 0.8.0 le 8 septembre 2026. Trois versions en une douzaine de jours, sur une base Swift et Metal, cela implique des reconstructions fréquentes et une API qui n'est pas encore figée. Le projet n'est pas archivé. Pour une adoption, la question n'est pas la stabilité du code mais la stabilité de la plateforme : Swift 6.2, Metal 4 et macOS 26 sont récents, et chaque montée de version d'Xcode peut demander une recompilation complète. Le point à vérifier en premier n'est pas une métrique de popularité, mais votre propre débit : lancez le build, installez le modèle, et mesurez sur votre machine. Les chiffres documentés vont de 5,1-6,3 tok/s sur un M2 8 Go à 31-35 tok/s sur un M5 Pro 24 Go, et cet écart de cinq à six fois est la donnée la plus utile pour décider si l'expérience vous convient.

Conclusion éditoriale

Adoptez TurboFieldfare si vous voulez faire tourner Gemma 4 26B-A4B sur un Mac Apple Silicon à 8 Go de RAM et que vous acceptez macOS 26, Metal 4 et Swift 6.2. Passez votre chemin si vous avez besoin de plusieurs modèles, de multimodalité sur M1 ou d'un débit garanti : le projet est mono-modèle et le débit dépend de l'état du cache disque. Avant de vous engager, vérifiez trois choses concrètes : que swift build -c release produit bien TurboFieldfareMac et TurboFieldfareDecodeService, que vous disposez des 14,3 Go de stockage libre plus 1,1 Go si vous voulez le pack image, et que le débit mesuré sur votre machine se situe entre les 5,1-6,3 tok/s du M2 et les 31-35 tok/s du M5 Pro documentés dans docs/BENCHMARKS.md.

Sources officielles

1. drumih/turbo-fieldfare on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases