Shannon 3.1

La plupart des sorties de modèles vous demandent de croire une promesse de capacité sur parole et d'attendre qu'un tableau de benchmarks tranche le débat. Celle-ci est plus facile à vérifier : ouvrez deux onglets, envoyez la même requête à shannon-3 et à shannon-3.1, et observez. La différence de vitesse d'arrivée de la réponse n'est pas subtile, et ce n'est pas un artifice d'affichage. Shannon 3.0 était bridé volontairement. Shannon 3.1 ne l'est pas.

01Ce qui a réellement changé dans Shannon 3.1

Shannon 3.0 a introduit ce qui définit cette famille : une boucle de raisonnement itératif. Le modèle ne répond pas à sa première pensée. Il réfléchit, rédige un brouillon, relit ce brouillon à la lumière de la question, puis l'améliore. Lite exécute une passe de cette boucle ; Pro exécute la boucle complète, y compris une étape de collecte de connaissances avant la rédaction. Cette conception est décrite en détail dans l'article de recherche Shannon 3, et rien de tout cela n'a changé dans la 3.1.

Ce qui a changé, c'est la mécanique en dessous. Shannon 3.0 était servi via un hébergeur d'inférence tiers — une manière sensée de lancer un modèle, et une manière contraignante de l'exploiter. Vous héritez de la configuration de service de quelqu'un d'autre, de sa file d'attente, de son plafond de contexte et de son idée du nombre de tokens par seconde auquel vous avez droit. Shannon 3.1 tourne sur notre propre cluster GPU, sur une pile de service que nous configurons, et chaque chiffre annoncé dans cet article découle de cette seule décision.

	Shannon 3.0	Shannon 3.1
Lieu d'exécution	Hébergeur tiers	Notre propre cluster GPU
Fenêtre de contexte	32,768	196,608
Diffusion de la sortie	Cadencée / débit limité	Pleine vitesse moteur
Poids	Réglage par défaut de l'hôte	NVFP4 4 bits
Décodage	Standard	Spéculatif
Boucle de raisonnement	Penser → rédiger → relire → améliorer	Inchangée
Couche de refus	Aucune	Aucune
Identifiants de modèle	shannon-3, shannon-3-pro	shannon-3.1, shannon-3.1-pro

02Pourquoi Shannon 3.1 paraît 10-15x plus rapide

Le chiffre de vitesse est celui que l'on interroge en premier, il vaut donc la peine d'être précis sur son origine. Il y a deux contributions indépendantes, et la plus importante est la moins spectaculaire des deux.

Nous avons supprimé le limiteur de vitesse

La sortie de Shannon 3.0 passait par une couche de cadencement. Les tokens quittaient le moteur, étaient retenus, puis libérés vers votre connexion selon un calendrier. Ce n'était ni un accident ni un bug. Quand un hébergeur d'inférence partagé est le goulot d'étranglement, cadencer la sortie lisse la charge, empêche une longue génération de monopoliser un créneau et fait arriver le flux à un rythme prévisible et lisible plutôt qu'en rafales. C'est un choix d'ingénierie défendable, et il coûtait à chaque utilisateur du temps réel sur chacune de ses réponses.

Shannon 3.1 n'a ni limiteur de vitesse ni cadencement d'affichage. Les tokens sont écrits dans votre flux au fur et à mesure que le moteur les produit. Si le moteur génère vite, vous le voyez générer vite. Il n'y a aucun tampon de lissage entre le modèle et votre terminal, votre fenêtre de chat ou votre lecteur SSE. Pour une longue réponse — une analyse de 2 000 tokens, un fichier de code généré — cela explique à soi seul la majeure partie de l'amélioration que vous remarquerez.

Une conséquence à assumer : le flux est désormais irrégulier. Le décodage spéculatif (voir plus bas) émet les tokens acceptés par courtes séries, si bien que le texte peut arriver par blocs visibles plutôt qu'à une cadence métronomique d'un mot à la fois. Si vous avez construit une interface autour du rythme régulier de la 3.0, elle continuera de fonctionner — l'ordre et le contenu des tokens sont inchangés — mais vous voudrez peut-être réintroduire votre propre lissage côté client si vous préfériez l'effet machine à écrire. Nous pensons que la plupart des gens préfèrent récupérer les secondes.

Le moteur lui-même est devenu plus rapide

Supprimer la barrière n'aide que si ce qui se trouve derrière est rapide. La seconde contribution, c'est la pile de service décrite en section 03 : des poids NVFP4 en 4 bits et le décodage spéculatif sur des accélérateurs de génération actuelle, nativement FP4, dans notre propre cluster. Ensemble, ils relèvent le plafond que la suppression de la barrière met à nu.

Latence relative de réponse de bout en bout, évaluation interne de Shannon Lab, septembre 2026. La fourchette reflète la longueur de la requête et le palier : les requêtes courtes sur Lite se situent près du bas, les longues générations sur Pro près du haut.

03Ce que fait réellement le décodage spéculatif

« Inférence par décodage spéculatif » est devenu un mot marketing ; voici donc le mécanisme, simplement.

Un modèle de langage produit normalement un token par passe avant. Cette passe est dominée non pas par l'arithmétique mais par la bande passante mémoire — il faut lire les poids pour calculer quoi que ce soit, et cette lecture prend bien plus de temps que le calcul lui-même. Le GPU passe l'essentiel de son temps à attendre la mémoire, ses unités de calcul au repos. Générer 500 tokens revient à payer cette latence 500 fois, séquentiellement.

Le décodage spéculatif s'attaque à la partie séquentielle. Un petit modèle brouillon bon marché propose une courte série de tokens probables — disons quatre ou huit. Le modèle principal évalue ensuite toute cette série en une seule passe avant groupée, ce qui coûte à peine plus que d'évaluer un seul token, car la partie coûteuse (la lecture des poids) n'a lieu qu'une fois dans les deux cas. Chaque token proposé que le modèle principal approuve est accepté et émis immédiatement. Au premier désaccord, la série est tronquée et le décodage normal reprend à partir de là.

C'est le taux d'acceptation qui fait le travail. Sur du texte prévisible — du code passe-partout, une structure de programme, le tissu conjonctif d'un raisonnement — le modèle brouillon devine bien et de longues séries passent d'un coup. Sur des tokens réellement difficiles, l'acceptation chute et le système retombe gracieusement sur un décodage ordinaire, un token à la fois. C'est l'asymétrie que l'on veut : elle accélère les parties faciles et ne touche pas aux parties difficiles.

Pourquoi les poids 4 bits appartiennent au même paragraphe

Parce que le goulot d'étranglement est la bande passante mémoire, réduire la taille des poids est un levier de vitesse direct, et pas seulement une question d'empreinte mémoire. NVFP4 est un format flottant sur 4 bits doté d'une mise à l'échelle fine par blocs, ce qui lui permet de conserver la précision là où les anciens schémas de quantification entière 4 bits la perdaient. À peu près un quart d'octets à lire par passe avant signifie proportionnellement moins de temps d'attente sur la mémoire, et cela laisse bien plus de marge pour le cache KV de long contexte qu'exige une fenêtre de 196K.

Les deux effets se composent plutôt qu'ils ne s'additionnent : moins d'octets par passe, et moins de passes par token émis. C'est ce qui rend le streaming à pleine vitesse et sans bride économiquement viable à servir, au lieu d'un coût qu'il faudrait récupérer par du cadencement — ce que faisait précisément la couche de cadencement sur la 3.0.

04196,608 tokens : ce qu'ouvre une fenêtre 6x plus grande

Shannon 3.0 disposait d'une fenêtre de 32,768 tokens : une session de travail, pas un document. Environ 70-80 pages de prose, moins ce que la boucle de raisonnement consomme pour sa propre réflexion, moins votre invite système, moins la conversation en cours. Le travail réel se heurtait constamment à ce mur, et les contournements — découpage, résumé, recherche documentaire sur votre propre matériel — dégradent tous la chose même que vous cherchiez à préserver. 196,608 tokens, c'est une autre catégorie de problème.

Concrètement, cela représente de l'ordre de 400-500 pages de texte, ou une base de code de taille moyenne avec ses tests et son README, ou une année de comptes rendus de réunion d'un projet, ou un jeu de contrats complet avec toutes ses annexes — tenu dans une seule conversation, interrogeable en une seule question, sans couche de découpage entre vous et le matériel.

• Questions à l'échelle du dépôt entier. Chargez le code et demandez pourquoi un bug atteint la production, au lieu de coller les trois fichiers que vous suspectiez déjà. Le modèle peut trouver le fichier que vous n'aviez pas pensé à inclure.
• Analyse de longs documents sans recherche documentaire. La recherche documentaire est un préfiltre avec perte qui décide de ce que le modèle a le droit de voir. À 196K, vous pouvez souvent vous en passer et laisser le modèle tout lire, ce qui supprime toute une classe d'échecs où le bon passage n'a jamais été retrouvé.
• Des conversations qui restent cohérentes. Une longue session de travail ne perd plus silencieusement son propre début. Les contraintes posées au message trois s'appliquent encore au message quatre-vingt.
• De la place pour la boucle de raisonnement. La réflexion, la rédaction et la relecture de la boucle consomment du contexte. Sur la 3.0, ces étapes rivalisaient avec votre matériel pour un budget rare. Sur la 3.1, elles tiennent confortablement, ce qui explique en partie pourquoi le gain de qualité et l'agrandissement de la fenêtre sont arrivés ensemble.
• De grandes entrées mixtes. Images, texte extrait de documents et code dans un même tour, sans avoir à trier ce que vous pouvez vous permettre d'inclure.

Une réserve honnête qui vaut pour tout modèle à long contexte, le nôtre compris : une grande fenêtre est une capacité, pas une garantie d'attention uniforme sur toute son étendue. La structure aide toujours. Placer la question vers la fin, étiqueter vos documents et dire au modèle ce qu'il doit chercher améliorent tous les résultats de façon mesurable à 150K tokens, d'une manière qui n'a tout simplement pas cours à 5K.

05Lite et Pro : shannon-3.1 et shannon-3.1-pro

Les deux paliers diffèrent par la portion de la boucle de raisonnement qu'ils exécutent, et c'est la seule différence qui compte pour choisir entre eux.

	shannon-3.1 (Lite)	shannon-3.1-pro (Pro)
Raisonnement	Passe unique	Boucle complète + collecte de connaissances
Auto-relecture	Non	Oui
Fenêtre de contexte	196,608	196,608
Diffusion	Pleine vitesse, sans bride	Pleine vitesse, sans bride
Vision & documents	Oui	Oui
Outil de génération d'images	Oui	Oui
Idéal pour	La plupart des travaux, gros volumes	Questions difficiles, premier jet insuffisant

Utilisez Lite par défaut. Une passe d'un bon modèle de raisonnement traite la grande majorité des demandes réelles, et sur la 3.1 elle est assez rapide pour que la boucle ne soit plus une attente perceptible. Passez à Pro quand la question est de celles dont la première réponse est habituellement fausse d'une manière instructive : arbitrages d'architecture, analyse adverse, tout ce sur quoi vous voudriez qu'un collègue compétent prenne la nuit pour réfléchir. L'étape d'auto-relecture de Pro n'est pas décorative — c'est le modèle qui trouve ses propres erreurs avant que vous n'ayez à le faire.

06Le gain d'intelligence de 32 %, et comment le lire

L'évaluation interne de Shannon Lab situe Shannon 3.1 à une amélioration de 32 % de l'intelligence par rapport à Shannon 3.0. Nous tenons à être clairs sur ce que ce chiffre est et n'est pas.

C'est notre chiffre, issu de notre suite d'évaluation interne, mesuré sur des tâches que nous jugeons représentatives de ce que les gens apportent réellement à ces modèles. Ce n'est pas un benchmark tiers, et nous ne construisons pas un tableau de classement autour d'un unique agrégat interne, ni ne publions un détail benchmark par benchmark — un tel détail suggérerait un niveau de comparabilité externe qu'une suite interne n'a pas.

Ce que nous dirons, c'est d'où vient le gain, car cette partie n'a rien de mystérieux. Une fenêtre de contexte plus grande signifie que moins de matériel doit être écarté avant que le modèle ne raisonne dessus, et une bonne part de l'apparente bêtise des longues sessions n'est en réalité que de l'amnésie. Une pile de service que nous contrôlons signifie que le modèle tourne avec la configuration que nous avons voulue plutôt qu'avec un réglage par défaut d'hébergeur. Et la boucle de raisonnement — inchangée dans sa conception — a maintenant la place de vraiment se dérouler à l'intérieur de la fenêtre, au lieu d'être compressée contre un plafond de 32K qu'elle partageait avec votre entrée.

07Vision, documents et génération d'images

Shannon 3.1 lit les images et les documents. Captures d'écran, schémas, photographies, pages numérisées, PDF et documents texte peuvent entrer dans la conversation et faire l'objet d'un raisonnement au même titre que le reste. Combiné à la fenêtre de 196K, c'est ce qui rend praticables les flux de travail sur documents entiers : un long rapport et ses graphiques en un seul tour, sans décider à l'avance quelles pages le modèle a le droit de voir.

La génération et l'édition d'images sont disponibles dans le chat, sous forme d'outil. Demandez une image et le modèle appelle l'outil en ligne, dans la même conversation, avec le contexte de tout ce qui a été discuté jusque-là. L'édition fonctionne de la même façon — donnez-lui une image, décrivez la modification. Il n'y a aucun mode séparé où basculer, ni aucune interface distincte à apprendre.

08Appeler Shannon 3.1 depuis l'API

Shannon 3.1 est disponible sur les trois dialectes d'API, avec le streaming sur chacun. Mêmes modèles, trois formes de requête — choisissez celle qui correspond au SDK que vous avez déjà.

Point de terminaison	Forme	Streaming
/v1/chat/completions	Compatible OpenAI	Oui
/v1/messages	Compatible Anthropic	Oui
/v1/responses	Responses	Oui

{
  "model": "shannon-3.1",
  "stream": true,
  "messages": [
    { "role": "user", "content": "Summarize this contract set and flag anything unusual." }
  ]
}

Remplacez "shannon-3.1" par "shannon-3.1-pro" pour exécuter la boucle de raisonnement complète. Si vous appelez déjà shannon-3, la migration se résume à l'identifiant de modèle et à rien d'autre : les formes de requête et de réponse sont inchangées, et les clients de streaming existants continuent de fonctionner. La seule différence de comportement à prévoir est le flux plus irrégulier décrit en section 02 — mêmes tokens, même ordre, arrivant plus tôt et par blocs moins réguliers.

La référence complète des paramètres, l'authentification, la sémantique des erreurs et un terrain d'essai interactif se trouvent dans la documentation de l'API. Les autres fiches techniques et articles techniques sont dans Shannon research.

09Toujours sans censure, et inchangé sur ce point

Shannon 3.1 n'a aucune couche de refus ni aucun filtrage de contenu en sortie. C'est la même posture que le reste de la gamme Shannon et elle n'a pas changé avec le passage à notre propre cluster — au contraire, contrôler la pile de service rend la garantie plus facile, puisqu'il n'y a plus d'hébergeur intermédiaire avec sa propre politique entre le modèle et vous.

Cela mérite d'être dit clairement, car c'est la question évidente pour une version qui a changé tout le chemin de sortie : supprimer la couche de cadencement n'a pas signifié insérer une couche de modération à sa place. Rien n'inspecte, ne réécrit ni ne filtre le flux. Ce que le modèle produit est ce qui arrive. Shannon 3.1 est, à notre connaissance, le modèle d'IA sans censure le plus rapide disponible avec une fenêtre de contexte de cette taille — et les deux propriétés sont liées, puisqu'elles découlent toutes deux du fait d'exploiter notre propre infrastructure plutôt que de louer à quelqu'un d'autre une capacité taillée pour la conformité.

Sans censure ne veut pas dire sans responsabilité. L'usage est encadré par notre politique d'utilisation responsable, et l'obligation qui accompagne un modèle acceptant d'aborder des sujets difficiles, c'est de l'aborder de façon responsable.

10Faites la comparaison vous-même

Chaque affirmation ici est vérifiable en deux minutes environ, et nous préférons que vous vérifiiez plutôt que de nous croire.

1. Choisissez une requête tirée du travail que vous faites vraiment. Plus elle est longue, mieux c'est — elle sollicite à la fois la fenêtre et le streaming.
2. Exécutez-la sur shannon-3. Notez le délai jusqu'au premier token, puis jusqu'à la fin de la réponse.
3. Exécutez la requête identique sur shannon-3.1. Notez les deux mêmes chiffres.
4. Lisez ensuite les deux réponses, sans regarder l'horloge, et décidez laquelle vous auriez voulue.

La différence de vitesse sera immédiate et évidente. C'est la différence de qualité qui mérite qu'on s'y attarde — elle apparaît le plus nettement sur les longues entrées, là où la 3.0 travaillait discrètement avec moins de votre matériel que vous ne le pensiez.

11Questions fréquentes

---

Les chiffres de performance et d'intelligence de cet article proviennent des mesures internes de Shannon Lab, septembre 2026, et sont présentés comme des chiffres produit et non comme des résultats de benchmarks tiers. La fenêtre de contexte, les identifiants de modèle et la disponibilité de l'API sont des spécifications produit. Shannon AI est exploité par Shannon Lab LLC, Nouveau-Mexique, États-Unis. À lire également : Shannon 3 · index de recherche Shannon · documentation de l'API.