Electrosens R&D
Electrosens LLM auto hébergées · 8 November 2026

Strata : 125 milliards de paramètres sur une RTX 5070 de 12 Go — autopsie d’un moteur « overfit » qui défie (vraiment) le mur de la VRAM

Un développeur seul, un dépôt GitHub, et une promesse qui défie les lois de la bande passante mémoire : faire tourner un modèle Mixture-of-Experts de 125 milliards de paramètres sur une RTX 5070 de 12 Go à 60 tokens par seconde. En quelques jours, Strata est devenu le sujet le plus discuté de r/LocalLLaMA — avant que la communauté ne se déchire. Depuis, le projet a mué : version 0.2.12, support de DeepSeek-V4.1-Flash, de MiniMax M3.1 et de GLM-5.3 sur GPU NVIDIA. Voici ce que l’on peut réellement vérifier, ce qui relève de la physique, et ce que cela dit de la guerre de la mémoire qui se joue dans l’inférence locale.


125 milliards de paramètres sur une RTX 5070 : le buzz qui a mis le feu à r/LocalLLaMA

Il y a des annonces qui, dans le petit monde de l’inférence locale, ressemblent à des provocations. Celle de Strata en fait partie. Le projet, hébergé sur le dépôt GitHub Niko1221/Strata, revendique rien de moins que de faire tourner Qwen3.8-Flash-Next, un modèle Mixture-of-Experts (MoE) de 125 milliards de paramètres, sur des cartes graphiques grand public disposant de 12 Go de VRAM ou plus — RTX série 20, 30, 40 et 50 chez NVIDIA, Radeon RX 6000, 7000 et 9000 chez AMD. Le chiffre qui a mis le feu aux poudres : environ 60 tokens/seconde en génération sur une RTX 5070 (12 Go), et jusqu’à ~100 tokens/seconde sur une RTX 4090 selon des rapports communautaires relayés par AI-Stat.

Pour mesurer l’ampleur de la claque, il faut se souvenir de ce que représente un modèle de cette taille. Un 125B en quantification 4 bits pèse déjà une soixantaine de gigaoctets ; en quantification agressive de type Q2, on descend autour de 30 à 40 Go. Dans les deux cas, c’est deux à trois fois la VRAM d’une RTX 5070. La promesse de Strata n’est donc pas une optimisation marginale : c’est une affirmation qui, prise au pied de la lettre, contredit le mur de la bande passante mémoire auquel se heurtent tous les moteurs d’inférence depuis l’aube des LLM.

La viralité a suivi une trajectoire classique, mais intense. Un post fondateur sur r/LocalLLaMA, intitulé « The Rise of Overfit Inference Engines », a posé le cadre conceptuel — 322 upvotes, 201 commentaires. Puis le buzz a débordé le cercle des curieux : un second post, ouvertement sarcastique (« Oui, les bots, on a compris, Strata est bon, arrêtez »), a récolté 555 upvotes et 359 commentaires. Quand la satire d’un engouement dépasse l’engouement lui-même, c’est le signe qu’un phénomène a basculé dans la culture de masse d’une communauté.

Reste la question qui structure tout cet article : comment un moteur développé par un seul développeur sous pseudonyme peut-il défier les lois de la bande passante mémoire ? La réponse n’est ni magique ni scandaleuse. Elle tient en un mot que le post fondateur a eu l’intelligence de mettre en avant : overfit. Nous allons disséquer cette idée couche par couche, confronter les chiffres annoncés aux contraintes physiques, proposer une méthodologie de benchmark reproductible, et replacer ce buzz dans la guerre de la mémoire qui agite toute l’industrie de l’inférence locale.


Strata, mode d’emploi : un moteur taillé pour une seule paire modèle-machine

Commençons par les faits vérifiables. Strata est un moteur d’inférence open source, développé par un développeur unique opérant sous le pseudonyme Niko1221 (aussi identifié comme « coldniko » sur X). Le projet se présente comme « gratuit et open source », mais — et c’est une première zone d’ombre — la licence exacte n’est pas spécifiée dans les extraits disponibles du dépôt. Ni MIT, ni Apache 2.0, ni GPL : l’ambiguïté est totale, ce qui, pour un outil destiné à être intégré dans des pipelines de production, n’est pas un détail. Cette imprécision renvoie d’ailleurs à un problème plus large, celui de la taxonomie de l’« open » que nous détaillons dans notre dossier « Open weights, open source, open data : ce que « open » veut vraiment dire pour votre LLM local en 2026 ».

Strata : débits revendiqués et poids des modèlesRTX 5070 (12 Go) — déb60tok/s ou GoRTX 4090 — débit rappo100tok/s ou GoQwen3.8-Flash-Next 12560tok/s ou GoQwen3.8-Flash-Next 12535tok/s ou GoVRAM RTX 507012tok/s ou GoDeepSeek-V4.1-Flash se191tok/s ou GoDeepSeek-V4.1-Flash 2,274tok/s ou Go

La cible matérielle est, elle, clairement définie : GPU avec ≥12 Go de VRAM, que ce soit côté NVIDIA (RTX 20/30/40/50) ou AMD (Radeon RX 6000/7000/9000). La configuration minimale revendiquée inclut ≥32 Go de RAM système et ~80 Go d’espace disque, sous Windows 10/11 ou Linux. Les auteurs déclarent avoir testé sur deux machines : une RTX 5070 (12 Go) + Ryzen 5 7600 + 64 Go de RAM, et une RX 9070 XT (16 Go) + Ryzen 9 3900X + 47 Go de RAM.

Le point crucial, c’est le périmètre volontairement étroit du projet. À l’origine, Strata ne supportait qu’un seul modèle : Qwen3.8-Flash-Next. Il ne supportait qu’un ensemble restreint de GPU. La disposition mémoire, la quantification et l’ordre de chargement des experts sont optimisés spécifiquement pour ce couple modèle-machine. C’est exactement ce que le manifeste communautaire appelle un « overfit inference engine » : un moteur qui sacrifie délibérément la généralité pour extraire le maximum d’un cas d’usage unique.

Ce périmètre s’est depuis élargi — et c’est la principale évolution à intégrer. La version courante, Strata 0.2.12 (l’application et le Terminal ; les paquets moteurs sont en 0.1.58, le flux de mise à jour en séquence 122), ne se limite plus à Qwen. Le dépôt documente désormais :

  • Qwen3.8-Flash-Next (125B MoE) — toujours le modèle phare, avec des packs ISTA-DASLab (Q2_0, IQ2_XS, IQ3_XXS, IQ3_S, plus un IQ1_M pour le code), Unsloth (UD-IQ4_XS à Q8_0), Gyro (Gyro-S, Gyro-M, plus économe en mémoire mais plus lent), et des options Swift 1.5, NVFP4 et OrcaRouter ;
  • Qwen3.6-35B-A3B — packs Unsloth documentés (UD-Q4_K_XL, UD-Q6_K_XL, Q8_0) ;
  • DeepSeek-V4.1-Flash-1017 — dans l’application desktop et le Terminal, avec des sets ISTA-DAS de 1,75 à 2,25 bpw pesant de 239 à 274 Go sur disque (et un set « Coder » à 191 Go, moitié des experts retirés) ;
  • des guides dédiés à MiniMaxAI M3.1-Flash, KRAFTON/Raon-1-mini-preview, Flint-GGUF et DeepSeek-AI DeepInfer.

La matrice matérielle s’est également étendue : aux RTX 30/40/50 sous Windows et Linux s’ajoutent désormais l’AMD Radeon AI PRO R9700 (Linux), l’AMD Ryzen AI Max — Strix Halo (Windows) et les Mac Apple Silicon dotés de 64 Go ou plus (texte uniquement). Un portage DGX Spark (linux-aarch64) est livré en 0.2.12.

Caractéristique Strata (état 0.2.12)
Développeur Niko1221 / « coldniko » (développeur unique)
Modèles supportés Qwen3.8-Flash-Next (125B MoE), Qwen3.6-35B-A3B, DeepSeek-V4.1-Flash-1017, MiniMax M3.1-Flash, Raon-1-mini, Flint-GGUF — plus unique
VRAM minimale 12 Go
GPU supportés RTX 20/30/40/50, Radeon RX 6000/7000/9000, Radeon AI PRO R9700, Strix Halo, Apple Silicon ≥64 Go, DGX Spark
RAM système minimale 32 Go (64 Go recommandés)
Espace disque ~80 Go (jusqu’à ~280 Go pour DeepSeek-V4.1 en 2,25 bpw)
Contexte maximal annoncé jusqu’à 128K tokens
Quantifications IQ3_S, IQ2_0, IQ3_XXS, IQ1_M, UD-IQ4_XS…Q8_0, NVFP4, bpw 1,75–2,25
Licence « open source » revendiquée, non spécifiée
Débit revendiqué (RTX 5070) ~60 tok/s

Sur la chronologie, la prudence est de mise. La date du premier commit ou de la première annonce publique n’est pas documentée dans les sources disponibles. Ce que l’on sait, c’est que le pic de buzz se situe début octobre 2026, avec une couverture tierce datée du 5 octobre 2026. Les publications X de « coldniko » (« New release is out! », comparaisons Strix Halo) sont datées d’il y a environ 31-33 jours par rapport à la consultation, ce qui les place fin septembre 2026. Aucun soutien d’une entreprise ou d’une organisation n’est mentionné : Strata reste, à ce stade, un projet solo.


Sous le capot : offloading hiérarchisé, KV-cache et experts à la demande

Ici commence la partie la plus délicate de l’exercice, car il faut distinguer rigoureusement ce qui est documenté de ce qui est spéculatif. Le dépôt GitHub confirme les quantifications, le recours à un modèle MoE, et le support de contextes étendus. En revanche, aucune documentation technique d’architecture formelle n’est publiquement disponible : pas de whitepaper, pas de description exhaustive du pipeline exact, pas de détail chiffré sur la gestion du KV-cache. Ce qui suit relève donc de l’inférence technique — au sens propre — à partir des briques connues et des contraintes physiques, en s’appuyant sur les descriptions publiques du site officiel.

L’offloading hiérarchisé VRAM/RAM/SSD/NVMe est la première brique indispensable. Puisqu’un 125B en Q2 pèse 30 à 40 Go et que la VRAM disponible plafonne à 12 Go, il est mathématiquement impossible de loger le modèle entier sur le GPU. La stratégie consiste à garder en VRAM les couches les plus sollicitées (têtes d’attention critiques, experts fréquemment déclenchés) et à streamer les autres depuis la RAM système, voire le SSD/NVMe. Le site officiel décrit explicitement ce mécanisme : « Critical attention heads and frequently triggered experts reside permanently inside your 12GB GPU VRAM. The remaining 90GB of dormant weights stream through high-speed 64GB DDR5 memory. » Le mécanisme qui rend cela viable s’appelle le prefetch : pendant que le GPU calcule la couche N, le CPU prépare le transfert de la couche N+1. Strata revendique ici un « predictive sparse routing » : le moteur prédirait quelles couches d’experts seront appelées 1 à 2 tokens à l’avance, pour les mettre en file en vue d’un transfert DMA PCIe instantané. C’est une affirmation du projet, non validée par une source indépendante.

La gestion du KV-cache est la deuxième brique critique. La formule standard est impitoyable : Mémoire = batch × seq_len × n_layers × 2 × hidden_dim × bytes_precision. Pour donner un ordre de grandeur, un modèle 70B avec un contexte de 8K consomme ~20 Go de KV-cache par requête, et ~640 Go pour un batch de 32 en FP16 — des chiffres qui, comme le note Introl, font que le KV-cache dépasse désormais souvent la consommation mémoire des poids du modèle en production. Sur 12 Go de VRAM, un contexte de 128K est tout simplement impossible à tenir en FP16. Strata doit donc recourir à une quantization agressive du cache (probablement en int4 ou int3), éventuellement à une pagination de type PagedAttention — la technique popularisée par vLLM, qui réduit le gaspillage mémoire dû à la fragmentation de 60-80 % à moins de 4 %, avec un gain de débit de 2 à 4x — et à une politique d’eviction des tokens les plus anciens. Là encore, rien de tout cela n’est confirmé nommément pour Strata.

Le recours au MoE est, en revanche, documenté — et c’est probablement la clé de tout. Un modèle Mixture-of-Experts n’active qu’une fraction de ses paramètres par token. Le site officiel précise même le mécanisme : « In MoE models like Qwen 125B, only 2-8 out of 64 experts fire per token. » Si l’on prend cette fourchette au sérieux, le volume de données à lire par token chute drastiquement. Le routage des experts et le chargement à la demande deviennent alors l’optimisation centrale : ne charger que les experts effectivement sollicités. C’est cohérent avec la mention, dans le dépôt, d’un « ordre de chargement des experts » optimisé spécifiquement.

Le « zero-copy pinned memory » est la troisième brique revendiquée : les poids seraient transférés via des flux CUDA asynchrones sur PCIe 4.0/5.0 directement dans les tensor cores, « contournant complètement les cycles de calcul CPU et évitant les à-coups ». C’est une description crédible d’une technique connue (pinned host memory + DMA asynchrone), mais dont l’efficacité réelle dépend entièrement de l’implémentation — et n’a pas été auditée publiquement.

Le speculative decoding est désormais explicitement mentionné : la note de version 0.2.12 évoque « a tuned DFlash2 drafter ». Le principe — un petit modèle « draft » propose plusieurs tokens que le grand modèle valide en batch — repose sur deux piliers : le goulot mémoire GPU (bande passante < compute) et la précision du petit modèle sur les motifs linguistiques fréquents. Le gain potentiel est réel, mais le coût en complexité et en VRAM supplémentaire l’est aussi. Le fait que Strata l’intègre confirme que le moteur ne se contente pas d’offloader : il empile les leviers.

Brique Gain mémoire Coût en latence Statut pour Strata
Offloading VRAM/RAM/SSD Indispensable (modèle > VRAM) Élevé sans prefetch Décrit sur le site officiel
Prefetch / predictive sparse routing — Réduit le coût du transfert Revendiqué (1-2 tokens d’avance), non audité
Zero-copy pinned memory (PCIe 4.0/5.0) — Réduit le coût CPU Revendiqué, non audité
Quantization du KV-cache Fort (128K sinon impossible) Faible Probable, non documenté
PagedAttention Réduit fragmentation <4 % Faible, gain débit 2-4x Probable, non documenté
MoE (experts à la demande) Très fort (2-8 experts sur 64 actifs) Routage + chargement Documenté
Speculative decoding (DFlash2) Neutre à négatif Gain si bien calibré Mentionné en 0.2.12

60 tokens/s sur 12 Go : le calcul de plancher qui ne ment pas

Passons à l’épreuve du réel. La bande passante mémoire est le juge de paix de l’inférence : pour chaque token généré, il faut lire l’ensemble des paramètres actifs. Sur une RTX 4090, la bande passante avoisine ~1 To/s ; sur une RTX 5070, elle est d’environ 672 Go/s. Ces chiffres bornent le débit maximal théorique.

Source : youtube.com

Faisons le calcul pour un modèle dense de 125B en Q2 (environ 2 bits par paramètre, soit ~0,25 octet). Le volume à lire par token serait de l’ordre de 31 Go. Sur une RTX 5070 à 672 Go/s, cela donnerait un plancher théorique de ~21 tokens/seconde — et ce, en supposant que tout le modèle soit en VRAM, ce qui est impossible avec 12 Go. Avec l’offloading, il faut ajouter le coût des transferts PCIe/NVMe, qui plombe encore le débit.

Mais Qwen3.8-Flash-Next est un MoE. Si le nombre de paramètres actifs par token tombe à 10-15 milliards, le volume à lire par token chute à 2,5-4 Go en Q2. Le plancher théorique remonte alors à ~170-270 tokens/seconde en lecture pure — largement au-dessus des 60 tok/s annoncés. La promesse devient physiquement plausible, à condition que :

  1. le modèle soit bien un MoE à paramètres actifs réduits,
  2. les experts sollicités soient effectivement disponibles rapidement (en VRAM ou en RAM à haut débit),
  3. l’offloading soit suffisamment masqué par le prefetch.

C’est là que se concentrent les zones d’ombre. Le dépôt ne précise ni le nombre exact d’experts actifs (le site avance « 2-8 sur 64 », sans détailler par couche), ni la quantification utilisée pour atteindre les 60 tok/s, ni la taille réelle du modèle chargée en VRAM versus en RAM système. Le chiffre de 60 tok/s provient du site et du README officiels et n’a pas été reproduit par une source indépendante. L’estimation de ~100-140 tok/s sur RTX 3090 (24 Go) est présentée par les auteurs eux-mêmes comme une extrapolation, pas comme une mesure.

Un point de méthode capital : les chiffres de débit doivent toujours être lus avec la quantification et le matériel exacts. Le site officiel publie d’ailleurs des tableaux distincts par palier matériel, ce qui est plus honnête que le chiffre unique du buzz :

Palier matériel (site officiel) VRAM RAM Débit revendiqué
RTX 3060 / 4060 / 3070 12 Go 64 Go DDR4/DDR5 dual channel 12-18 tok/s
RTX 4070 Ti / 4080 / 3090 16-24 Go 64-128 Go DDR5 25-38 tok/s
RTX 4090 ou dual RTX 3090 24-48 Go 128 Go DDR5 quad channel 45-65 tok/s

On note immédiatement la tension interne : le tableau du site attribue 12-18 tok/s à une RTX 3070 (12 Go), tandis que la page de garde promet « 60+ tokens/s on a good GPU » et que la couverture presse évoque ~60 tok/s sur RTX 5070. La RTX 5070 est plus rapide qu’une 3070, mais pas d’un facteur 4 sur la seule bande passante. Le chiffre de 60 tok/s doit donc être considéré comme un meilleur cas, sur le palier haut de gamme, et non comme la norme sur 12 Go. C’est exactement le genre d’écart qu’un benchmark reproductible doit trancher.

Le site publie par ailleurs une comparaison directe, sur une RTX 4070 (12 Go) + 64 Go DDR5, entre moteurs :

Moteur Matériel Débit RAM allouée Statut
Strata LLM RTX 4070 12 Go + 64 Go 21,4 tok/s 52 Go Support natif, zéro OOM
Ollama (standard) RTX 4070 12 Go + 64 Go Échec / OOM Dépasse la limite Out of Memory
vLLM (CPU-offload) RTX 4070 12 Go + 64 Go 3,8 tok/s — Fonctionnel, lent

Ces chiffres sont auto-déclarés et n’ont pas été reproduits indépendamment. Ils ont le mérite de la cohérence interne (21,4 tok/s sur 12 Go est dans la fourchette 12-18 tok/s annoncée pour ce palier, légèrement au-dessus), mais ils illustrent surtout le vrai argument de Strata : ne pas planter. Là où Ollama échoue en OOM et où vLLM s’effondre à 3,8 tok/s, Strata revendique un débit utilisable. C’est moins spectaculaire que « 60 tok/s », mais c’est peut-être la promesse la plus solide du projet.


La méthodologie de benchmark qui manque à tout le monde

Le problème central de Strata n’est pas technique : il est épistémique. Personne, en dehors de l’auteur, n’a publié de protocole reproductible. Voici donc ce qu’un benchmark honnête devrait mesurer, et que nous recommandons à quiconque veut se faire un avis.

1. Fixer le triplet (modèle, quantification, matériel). Un débit sans quantification est un chiffre creux. Il faut préciser le pack exact (par exemple ISTA-DASLab IQ3_XXS vs Unsloth UD-Q4_K_XL), la version du moteur (0.2.12 vs 0.1.58 des paquets), et la configuration RAM (fréquence, canaux). Le site officiel distingue d’ailleurs Strix Halo en 0.2.7 pour la mesure DeepSeek — preuve que la version du moteur change le résultat.

2. Mesurer séparément prefill et decode. Le « prompt » (vitesse de lecture de l’entrée) et l’« output » (vitesse de génération) sont deux métriques distinctes. La note 0.2.12 mentionne d’ailleurs « faster prompts on 12 GB cards » : le prefill a été optimisé, ce qui ne dit rien du decode.

3. Tester la longueur de contexte. Un débit de 60 tok/s sur un prompt de 100 tokens n’a rien à voir avec le même débit sur 32K tokens de contexte. Le KV-cache grossit, la VRAM se sature, et le débit s’effondre. Il faut publier une courbe débit/contexte, pas un point unique.

4. Mesurer la première token latency (TTFT). Avec l’offloading, le chargement initial des experts est coûteux. Un moteur peut afficher 60 tok/s en régime établi et mettre 30 secondes à produire le premier token. Pour un usage interactif, c’est rédhibitoire.

5. Vérifier la stabilité thermique et mémoire. Un run de 10 minutes ne dit rien. Il faut un run d’une heure, avec surveillance de la RAM système (fuites), de la température GPU et du throttling.

6. Comparer à armes égales. Ollama, llama.cpp, vLLM, llm-d : chacun a ses forces. Un comparatif honnête doit utiliser la même quantification et le même prompt, et publier les commandes exactes.

C’est précisément le niveau de rigueur qu’exige le reste de l’écosystème. Le guide « Optimiser l’inférence LLM locale en 2026 » insiste sur la distinction prefill/decode et sur le fait que « les bancs d’essai disent rarement ce qu’ils ne mesurent pas ». Strata, à ce jour, ne fournit pas ce niveau de détail — ce qui ne l’invalide pas, mais interdit de le couronner.


La guerre de la mémoire : où Strata se situe vraiment dans l’écosystème 2026

Replaçons Strata dans le paysage. En 2026, l’inférence locale n’est plus un hobby de bidouilleur : c’est un champ de bataille industriel. Et Strata y occupe une niche très particulière — celle de l’optimisation extrême pour un couple modèle-machine, à l’opposé de la standardisation.

Source : lesnumeriques.com

D’un côté, la standardisation industrielle. Le 20 octobre 2026, les contributeurs du projet llm-d ont annoncé la version 1.0, avec IBM, Red Hat, Google Cloud, CoreWeave et NVIDIA dans le gouvernail (gouvernance Cloud Native Computing Foundation). Le communiqué de presse promet une inférence distribuée « production-scale », et IBM Research revendique un coût de 0,11 $ par million de tokens, soit environ 11,5 fois moins que les API commerciales. C’est un tout autre monde : celui du datacenter, du routage prefix-aware, de la désagrégation prefill/decode et du KV-cache distribué. Strata et llm-d ne jouent pas dans la même cour — mais ils répondent au même problème : comment faire tenir un grand modèle dans une mémoire insuffisante. llm-d le fait en distribuant sur un cluster ; Strata le fait en streamant sur un seul PC. Comme le note notre autopsie de llm-d 1.0, le chiffre de 11,5× circule d’ailleurs sans méthodologie publique complète — même prudence, même exigence.

De l’autre, la démocratisation matérielle. Le vrai basculement de 2026, c’est l’arrivée de la mémoire unifiée à grande capacité sur du matériel grand public : AMD Gorgon Halo viserait 192 Go de mémoire unifiée pour des modèles 200B+, l’Acer / AMD Ryzen AI Halo mini-PC annonce 128 Go pour 3 999 $ et jusqu’à 200B de paramètres. Face à ces machines, la promesse de Strata (« 125B sur 12 Go ») change de nature : elle ne concurrence plus les gros serveurs, elle concurrence les mini-PC à mémoire unifiée. Et là, l’argument économique est massif — une RTX 5070 + 64 Go de DDR5 coûte une fraction d’un mini-PC à 4 000 $. C’est exactement l’équation que développe notre dossier « Faire tourner des LLM open source chez soi sans se ruiner : iGPU, mémoire unifiée et le vrai basculement de 2026 ».

Et sur le plan des modèles, l’élargissement de Strata à DeepSeek-V4.1-Flash, MiniMax M3.1 ou GLM-5.3-Flash (321B MoE, via le projet tiers Project Maya construit sur Strata) montre que l’approche « overfit » peut se généraliser par accumulation de cas spécifiques. C’est une stratégie différente de celle de llama.cpp (généraliste, cf. llama.cpp v0.5.0) ou de vLLM (serveur). Strata ne cherche pas à tout faire : il cherche à faire quelques choses très bien, quitte à multiplier les packs.

Le contexte réglementaire et sémantique ajoute une couche. La licence de Strata n’étant pas spécifiée, l’utilisateur ne sait pas ce qu’il peut légalement faire du code — un problème que l’EU AI Act et les définitions OSAID 1.0 rendent de plus en plus sensible en 2026. Pour un usage personnel, l’enjeu est faible ; pour une PME, il est réel. Notre guide PME 2026 place d’ailleurs Strata dans la catégorie « à surveiller », pas « à déployer en production » — précisément à cause de cette ambiguïté.

Enfin, l’usage. Strata se positionne explicitement comme un outil de chat, de code et d’images, avec une API compatible OpenAI (« Paste one address and Cursor or Claude Code can use it »). C’est un choix pragmatique : s’insérer dans l’écosystème des assistants de code plutôt que de rivaliser avec les serveurs. Cela le rapproche d’AnythingLLM ou d’Ollama dans l’esprit, mais avec un moteur taillé pour les gros MoE.


Ce qu’il faut retenir (et ce qu’il faut vérifier soi-même)

Strata est un projet fascinant, et probablement important. Il démontre qu’avec un routage sparse prédictif, un cache hiérarchisé VRAM/RAM/SSD et une quantification agressive, on peut faire tourner un MoE de 125B sur une carte de 12 Go à un débit utilisable. Ce n’est pas de la magie : c’est de l’ingénierie de l’offloading poussée à son paroxysme, rendue possible par la nature creuse des MoE.

Mais il faut résister à deux tentations symétriques. La première est de croire le buzz : les 60 tok/s sont un meilleur cas, non reproduit indépendamment, et le tableau du site lui-même descend à 12-18 tok/s sur une 3070. La seconde est de rejeter le projet au motif qu’il est « overfit » : c’est précisément ce qui fait sa force, et l’élargissement à DeepSeek-V4.1, MiniMax M3.1 et GLM-5.3 montre que l’approche tient.

Ce que nous recommandons, concrètement :

  • Testez vous-même, avec votre matériel, votre quantification et votre prompt. Le dépôt fournit un START-HERE.bat et une commande strata launch --family deepseek41 --model ist-das-2.00bpw --plan qui facilite l’essai.
  • Méfiez-vous des chiffres uniques. Exigez la quantification, la longueur de contexte et la distinction prefill/decode.
  • Surveillez la licence. Tant qu’elle n’est pas explicite, considérez Strata comme un outil d’expérimentation, pas de production.
  • Comparez avec les alternatives : Ollama pour la simplicité, llama.cpp pour la généralité, vLLM pour le serveur, llm-d pour le cluster, et les mini-PC à mémoire unifiée pour l’achat neuf.

La vraie leçon de Strata n’est pas « 125B sur 12 Go ». C’est que la guerre de la mémoire est loin d’être terminée, et qu’un développeur seul, avec une bonne idée et beaucoup d’optimisation, peut encore secouer un écosystème entier. À condition, bien sûr, que quelqu’un finisse par publier les benchmarks.


Sources

Source : ai2face.com
Article recherché et rédigé automatiquement · Magazine Electrosens
📬 Restez à la pointe
Recevez chaque semaine les nouveautés de ce magazine par email.
💬 Une remarque, une correction ?
Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *