Naive-N0.5-Flash : le MoE open-weight de 309B sans aucune couche full-attention vise 2 000 tokens/s par utilisateur

Naive-N0.5-Flash : le MoE open-weight de 309B sans aucune couche full-attention vise 2 000 tokens/s par utilisateur

🔎 309 milliards de paramètres, zéro full-attention, et une révélation gênante

Le 27 septembre 2026, NaiveAI — startup pékinoise fondée par Jifeng Dai, chercheur issu de Tsinghua, valorisée 1,4 milliard de dollars — a publié sur Hugging Face les poids de Naive-N0.5-Flash, un MoE de 309 milliards de paramètres (15,5 milliards actifs), sous licence MIT. À l'ère des releases open-weight hebdomadaires, rien d'extraordinaire en apparence. Sauf un détail : sur ses 48 couches, aucune n'est une couche full-attention.

À la place : 39 couches sliding-window et 9 couches DeepSeek Sparse Attention, un contexte natif d'un million de tokens, et une stack d'inférence maison baptisée NaiveRT qui revendique jusqu'à 2 000 tokens/s par utilisateur. Selon AI Weekly, c'est la première release open-weight à échelle frontier sans aucune couche full-attention.

Et puis il y a la phrase la plus troublante du dossier : l'entreprise affirme que sa pipeline de R&D a été « substantiellement exécutée par des systèmes d'IA », les humains se contentant de fixer les objectifs et les standards d'évaluation. Ce lancement teste donc deux paris en même temps — l'un architectural, l'autre organisationnel. Les deux méritent qu'on s'y attarde.

L'essentiel

• Architecture radicale : MoE de 309 milliards de paramètres (15,5 milliards actifs), 48 couches — 39 SWA + 9 DSA — sans aucune full-attention, contexte natif de 1M tokens.
• Recette d'entraînement documentée : 3,25 T tokens en trois étapes, sur la base open-weight MiMo-V2.5 de Xiaomi ; poids et code d'inférence sous licence MIT.
• NaiveRT, la stack d'inférence maison : 50 tokens/s par utilisateur en mode Standard, jusqu'à 2 000 en Ultrafast (mega-kernel fusion, PDL, speculative decoding).
• API annoncée à $0,10 / $0,40 / $0,01 par million de tokens (entrée / sortie / cache reads) — mais pas encore live fin septembre 2026.
• La vraie story : une R&D « substantiellement exécutée par des systèmes d'IA », et une NaiveRT construite en six jours sur 151 essais d'optimisation documentés.
• Notre lecture : les chiffres de vitesse sont réels mais étroits (pics de décodage, pas benchmarks end-to-end). L'enjeu de fond est la vélocité R&D assistée par IA.

Outils recommandés

Zéro full-attention : ce que ça change vraiment (et ce que ça ne change pas)

En supprimant toute couche full-attention, NaiveAI réduit surtout le coût de calcul de l'attention — pas la croissance mémoire, qui continue de grimper avec le contexte. C'est toute la nuance, et elle est importante.

Concrètement, l'architecture tient en quelques chiffres, tous détaillés sur la model card Hugging Face : 48 couches, dont 39 en sliding-window attention avec une fenêtre de 128 tokens, et 9 en DeepSeek Sparse Attention légère (GQA4), selon un ratio d'environ 5:1. La DSA ne parcourt pas tout l'historique : un indexer léger de 16 têtes de requête sélectionne les 2 048 tokens les plus pertinents pour l'attention backbone, avec un sink bias appliqué aux deux types d'attention.

Le pari est clair : tenir 1M de tokens de contexte natif sans jamais payer le prix quadratique d'une full attention. La recette d'entraînement est elle aussi explicitée : 3,25 T tokens en trois étapes — 50B tokens d'Indexer Warmup (une loss KL aligne l'indexer sur l'attention des couches converties), 3T tokens de Sparse Attention Training en continued pretraining orienté code et R&D IA, puis 200B tokens de Learning Rate Decay. Le tout sur la base MiMo-V2.5 de Xiaomi, elle-même open-weight.

Mais lisons la note de bas de page que souligne l'analyse critique de canberk.me : « no full attention » ne veut pas dire mémoire plate. L'indexer continue de scanner l'historique, et le KV cache complet est retenu. La sparse attention réduit le compute d'attention et les accès mémoire — pas la quantité d'état à stocker. Si vous dimensionnez une infrastructure, c'est ce détail qui compte.

Ce mouvement n'est pas isolé. DeepSeek a ouvert la voie avec sa sparse attention — que NaiveAI crédite explicitement — et notre coverage de DeepSeek V4.1 Flash sous MIT montrait déjà un KV cache réduit d'un quart. Plus récemment, Subquadratic sort du stealth avec SubQ et 12 millions de tokens de contexte, poussant la logique jusqu'au bout. Mon avis : l'hybride SWA + DSA de NaiveAI est le compromis le plus pragmatique du moment — le sliding-window pour le contexte proche, la DSA pour le long terme, et plus aucune couche obligée de traverser intégralement un million de tokens.

NaiveRT : 2 000 tokens/s, oui — mais lisez la note de bas de page

Les chiffres de NaiveRT sont réels et documentés, mais ce sont des mesures de décodage étroites, pas des débits garantis en production. La distinction est essentielle avant tout dimensionnement.

La stack maison revendique 50 tokens/s par utilisateur en mode Standard et jusqu'à 2 000 tokens/s en Ultrafast, via trois leviers : mega-kernel fusion, Programmatic Dependent Launch (PDL) et speculative decoding. Le chiffre-peak mis en avant par naive.ai : 2 122 tokens/s en décodage single-stream sur 8 GPUs — meilleure fenêtre d'une seconde, thinking off, 41 requêtes de génération HTML/SVG, prefill exclu, température 0,4. Autant dire un sprint chronométré dans des conditions idéales, pas un marathon.

D'autres mesures sont plus parlantes pour les spécialistes : un tour spéculatif complet en 3,4 ms contre 12,3 ms pour SGLang sur le même système, et un indexer léger qui réduit le wall time de sélection de 44 % par rapport à l'implémentation DSA originale. Pandaily confirme la cohérence d'ensemble de la release.

Le cas d'usage qui justifie tout cela, c'est le RL. Avec des contextes de 1M tokens, le wall-clock d'un rollout est dominé par les tokens générés — 50 à 100 tokens/s en décodage conventionnel. D'où l'argument business de NaiveAI : un décodage single-stream rapide transforme directement le débit d'entraînement. Preuve à l'appui : avec la configuration contexte 1M, 1T tokens d'entraînement traités en ~4 jours sur 512 GPUs. Pour les équipes qui font du RL à grande échelle — un sujet qu'on détaille dans notre guide des meilleurs LLM pour les agents IA — c'est un argument qui tient la route.

RuntimeWire le note pourtant explicitement, et AI Weekly le relaie : les 2 000 tokens/s sont des chiffres de vitesse de décodage étroits, pas des benchmarks end-to-end. canberk.me ajoute que ce n'est ni un débit soutenu, ni une vitesse API générique.

Ma lecture : ne jugez pas le modèle sur ces chiffres, jugez la stack. Publier un code d'inférence sous MIT avec des conditions de mesure détaillées est plus honnête que la moyenne du secteur — et ça permet précisément ce type de lecture critique.

« Substantiellement exécutée par des systèmes d'IA » : la vraie story

Au-delà de l'architecture, la revendication la plus importante de NaiveAI est organisationnelle : sa R&D aurait été menée majoritairement par des systèmes d'IA. C'est peut-être le vrai produit de cette release.

La startup pékinoise, fondée par Jifeng Dai (Tsinghua) et valorisée 1,4 Md$, affirme que la R&D du modèle a été substantiellement exécutée par des systèmes d'IA, les humains fixant les objectifs et les standards d'évaluation. Plus concret encore : selon Cellcog, NaiveRT aurait été « built in six days by human researchers working with AI models, across 151 documented optimization trials ». Six jours. 151 essais tracés.

Ce qui distingue cette claim du marketing habituel, ce sont les chiffres documentés : essais d'optimisation tracés, délai de développement annoncé, conditions de benchmark publiées. Ce n'est pas un audit indépendant — loin de là — mais c'est infiniment plus vérifiable que les communiqués habituels sur « l'IA qui fait de la recherche ». RuntimeWire confirme que l'entreprise assume pleinement ce récit, en partant de la base open MiMo-V2.5 de Xiaomi et en créditant les travaux de sparse attention de DeepSeek.

AI Weekly résume bien le pari double : tenir 1M de contexte sans full attention, et prouver que l'outillage IA accélère matériellement la R&D d'un lab frontier. Avec 15,5 milliards de paramètres actifs, le compute par token se rapproche d'ailleurs d'un dense de taille intermédiaire — l'efficacité fait partie de la démonstration.

Si la seconde hypothèse se vérifie à l'échelle, l'avantage compétitif des labs ne sera plus la taille du cluster, mais la qualité de leur pipeline d'agents de recherche. C'est une course que la Chine semble avoir décidé de mener : Moonshot AI vient de lever 2 milliards de dollars avec Kimi K2.6 en tête de l'open-weight. Reste la prudence de rigueur : « substantiellement » n'a pas de définition précise, et aucun tiers n'a encore audité quoi que ce soit.

Prix, hardware, accès : ce qu'il faut pour y toucher

Le modèle est gratuit en théorie (MIT), mais le faire tourner demande un nœud multi-GPU ; l'API managée, elle, n'est pas encore disponible. Résumé sans détour.

Côté hardware, comptez environ 315 Go de poids en FP8, un GPU NVIDIA compatible FP8 obligatoire, et sachez que le pic de 2 122 tokens/s a été mesuré sur 8 GPUs. On est très loin du « LLM local sur PC gamer » — pour cet usage, notre guide d'installation d'un LLM local et notre sélection des meilleurs LLM à run en local restent les bons points de départ.

Côté API, voici les tarifs annoncés :

Au moment du check de Cellcog le 27 septembre 2026, l'API était annoncée mais non live, sans listing OpenRouter. Conséquence pratique : ne budgétisez rien de ferme avant la mise en ligne effective, et vérifiez les prix sur naive.ai au moment de décider. Si vous préparez déjà la couche applicative qui appellera cette API, un hébergement standard type Hostinger suffit largement — c'est le modèle qui est lourd, pas votre frontend.

Face à l'open-weight : Naive joue une autre partition

NaiveAI ne rivalise pas (encore) sur les benchmarks de qualité — elle rivalise sur l'architecture, la vitesse d'inférence et le récit de R&D automatisée. Le positionnement est différent de ses voisins chinois.

Point de journalisme important : aucune mesure publique indépendante de qualité n'accompagne la release. Le modèle est positionné code et R&D IA, ce qui le met théoriquement en concurrence avec Claude Opus 4.7, GPT-5.5 ou Gemini 3 Pro — notre comparatif des meilleurs LLM pour coder sera mis à jour dès que des évaluations communautaires tomberont. En attendant, toute affirmation de supériorité serait du puff.

Le paysage open-weight se diversifie en tout cas à vitesse record : Z.AI avec GLM-5.3 qui passe en open-weight sous licence anti-hyperscalers, MiniMax avec M3 et son million de tokens de contexte, et même des niches spécialisées comme le MoE open-weight de traduction de Cohere qui bat DeepL et Google Translate sur WMT26. NaiveAI apporte à cette vague une pièce que personne n'avait : une architecture sans full-attention à échelle frontier.

Mon avis : la valeur de cette release est d'abord stratégique. Elle force tout le monde à admettre que le consensus architectural — full attention, KV cache croissant, MoE — n'est pas un terminus. Ça, c'est bon pour tout l'écosystème.

Verdict : qui devrait s'y intéresser maintenant

Ingénieurs inférence, équipes RL et builders d'agents : oui, dès maintenant. Utilisateurs finaux : attendez l'API et les benchmarks, il n'y a pas d'urgence.

Pour qui c'est pertinent aujourd'hui :

• Équipes RL à long contexte : l'argument décodage single-stream rapide est le plus concret de toute la release, avec des chiffres de throughput d'entraînement à l'appui.
• Ingénieurs système : le code d'inférence sur GitHub est une mine — mega-kernels, PDL, speculative decoding mesurés contre SGLang, le tout sous MIT.
• Chercheurs en efficacité : 48 couches sans full attention, un indexer à 16 têtes, une recette d'entraînement multi-étapes entièrement documentée.

Pour qui ce n'est pas (encore) le bon moment : les développeurs qui veulent un modèle de code fiable au quotidien resteront sur les valeurs sûres de notre comparatif des meilleurs LLM pour coder, et l'usage général gratuit se règle très bien avec notre sélection des meilleurs LLM gratuits. Pour la vue d'ensemble du marché, notre comparatif mensuel des meilleurs LLM fait le tri.

À surveiller : la mise en ligne de l'API, un éventuel listing OpenRouter, et surtout les premiers retours communautaires sur la qualité réelle du modèle en code.

❌ Erreurs courantes

Erreur 1 : croire que « zéro full-attention » signifie une mémoire constante

C'est le malentendu le plus répandu. L'indexer continue de scanner l'historique et le KV cache complet est retenu : la mémoire croît toujours avec le contexte. La sparse attention réduit le compute d'attention et les accès mémoire, pas l'état à stocker. Solution : dimensionnez votre VRAM sur le KV cache à 1M tokens, pas sur les 315 Go de poids seuls.

Erreur 2 : prendre 2 122 tokens/s pour un débit garanti

Ce chiffre est un pic de décodage single-stream : meilleure fenêtre d'une seconde, prefill exclu, 8 GPUs, thinking off, température 0,4. Ce n'est ni un débit soutenu end-to-end, ni une vitesse API générique. Solution : attendez les mesures end-to-end et les débits API réels avant de dimensionner quoi que ce soit.

Erreur 3 : vouloir le lancer sur sa machine de dev

315 Go de poids en FP8, GPU NVIDIA compatible FP8 requis, benchmarks sur 8 GPUs : ce n'est pas un modèle grand public. Solution : passez par l'API quand elle sera live, ou choisissez un modèle réellement localisable via nos guides dédiés au local.

Erreur 4 : bâtir un produit sur une API qui n'existe pas encore

L'API était annoncée mais non live fin septembre 2026, sans listing OpenRouter. Construire dessus aujourd'hui, c'est bâtir sur du sable. Solution : abstrayez votre provider et prévoyez un fallback immédiat — DeepSeek V4 Pro ou Kimi K2.6 font très bien le travail en attendant.

❓ Questions fréquentes

Naive-N0.5-Flash est-il vraiment sans aucune couche full-attention ?

Oui. La model card Hugging Face détaille 48 couches : 39 en sliding-window attention (fenêtre de 128 tokens) et 9 en DeepSeek Sparse Attention, sans aucune full-attention. Selon AI Weekly, c'est la première release open-weight à échelle frontier avec cette caractéristique. Attention toutefois : la mémoire du KV cache continue de croître avec le contexte.

Peut-on l'exécuter en local ?

Techniquement oui — licence MIT, poids et code d'inférence ouverts. En pratique, comptez environ 315 Go de poids en FP8, des GPU NVIDIA compatibles FP8 et un nœud multi-GPU (les benchmarks de NaiveAI tournent sur 8 GPUs). Ce n'est pas un modèle « PC gamer » ; pour du local accessible, suivez notre guide d'installation LLM local.

Combien coûtera l'API ?

NaiveAI annonce $0,10 par million de tokens d'entrée, $0,40 en sortie et $0,01 pour les cache reads (septembre 2026, vérifiez sur naive.ai). Mais l'API n'était pas encore live au 27 septembre 2026, et sans listing OpenRouter. Attendez la mise en ligne effective avant de budgétiser un projet.

Que vaut-il pour le code face à Claude Opus 4.7 ou GPT-5.5 ?

Impossible à dire aujourd'hui : aucun benchmark public indépendant n'accompagne la release. Le modèle est positionné code et R&D IA, sur une base MiMo-V2.5 entraînée sur 3,25 T tokens, mais la qualité reste à démontrer. Notre comparatif des meilleurs LLM pour coder sera actualisé dès les premiers retours communautaires.

L'affirmation de R&D « exécutée par l'IA » est-elle crédible ?

Partiellement vérifiable. NaiveAI documente 151 essais d'optimisation et une NaiveRT construite en six jours, avec des conditions de benchmark publiées — plus de traçabilité que la moyenne du secteur. Mais « substantiellement exécutée par des systèmes d'IA » reste une affirmation d'entreprise, sans audit indépendant. À traiter comme une hypothèse sérieuse, pas comme un fait établi.

✅ Conclusion

Naive-N0.5-Flash ne changera peut-être pas votre quotidien de développeur cette semaine, mais il pourrait changer ce que les labs croient possible — architecturalement avec cette sortie de la full-attention, et organisationnellement avec une R&D menée par des systèmes d'IA. Surveillez la mise en ligne de l'API et, en attendant, notre comparatif mensuel des meilleurs LLM pour choisir un modèle réellement disponible aujourd'hui.