Un écosystème entier sur un modèle 3B

5 agents qui s'échangent des biens, spéculent, thésaurisent et paniquent. Le tout sur un modèle de 3Md de paramètres. Et la vraie leçon n'est pas celle que vous croyez.

C'est quoi ce projet au juste

Un dev a construit un truc qu'il appelle Thousand Token Wood pour un hackathon orienté petits modèles.

L'idée tient en une phrase. C'est une mini économie peuplée de 5 créatures de la forêt.

Chaque créature est un agent autonome. Chacune tourne sur Qwen2.5-3B, le même petit modèle pour tout le monde.

Elles produisent et s'échangent cinq biens contre des cailloux qui font office de monnaie. Vous secouez la forêt, et vous regardez les bulles, les krachs et les inégalités apparaître tout seuls.

Côté technique, rien d'exotique. Le modèle est servi avec vLLM sur Modal, et une appli Gradio sert de fenêtre sur la forêt.

Et c'est tout. Pas de GPT-5, pas de cluster monstrueux, pas de budget API à 6 chiffres.

Pourquoi un petit modèle, et pas un gros

Là est le premier point intéressant. Le choix du petit modèle n'est pas une contrainte subie, c'est une décision de design.

Une économie vivante, ça veut dire beaucoup d'agents qui réfléchissent beaucoup de fois par partie. À chaque tour, chaque créature doit prendre une décision.

Et c'est exactement le terrain où un modèle frontier est le mauvais outil. Trop lent et trop cher pour faire délibérer un conseil de marchands à chaque tick.

Le petit modèle, lui, rend la simu temps réel possible. Chaque créature décide en un seul appel GPU batché par tour.

Je le répète parce que c'est important. Ce n'est pas "j'aurais voulu un gros modèle mais je n'avais pas les moyens". C'est "le petit modèle est ce qui rend le projet faisable tout court".

La première version était morte née

La version naïve ne faisait rien. Le marché s'ouvrait, se vidait une fois, et plus rien.

La raison est bête. La production dépassait la consommation, donc chaque créature était autosuffisante.

Et une créature autosuffisante n'a aucune raison d'échanger quoi que ce soit. Pas de besoin, pas de commerce, pas de simu.

Le fix n'a pas été de toucher au modèle. Le fix a été de fabriquer de la rareté à la main.

Concrètement, 3 mécaniques :

• Variété alimentaire : une créature ne peut manger qu'une seule unité d'un aliment donné par repas, donc survivre l'oblige à acheter ce qu'elle ne produit pas.
• Péremption : la nourriture périssable pourrit si on la stocke, ce qui force à vendre le surplus tant qu'il vaut quelque chose.
• Crise du chauffage en hiver : chaque créature doit brûler du bois à chaque tour, le besoin augmente avec le temps, et une seule créature produit du bois.

C'est cette dernière mécanique qui crée tout le drame. Un seul fournisseur face à une demande qui grimpe.

Donc le bûcheron s'enrichit pendant que les autres se battent pour avoir chaud. Vous voyez le tableau.

Du JSON parfait, un jugement pourri

On arrive au moment qui devrait vous parler si vous codez avec des LLM.

Une fois la rareté en place, la vérité sur les petits modèles est apparue. Le 3B sortait du JSON valide sur 100% des appels.

Donc côté format, zéro problème. La machine recrache une structure propre à tous les coups.

Mais son jugement économique était mauvais. Le genre de mauvais qui fait mal aux yeux.

Exemple concret donné par l'auteur: une créature qui produit des glands postait un ordre pour acheter des glands.

C'est à dire le seul truc dont elle avait déjà plein les poches.

Le réflexe normal, quand un agent déraille comme ça, c'est de prendre un modèle plus gros. C'est presque toujours une erreur.

Le fix ici n'a pas été plus de paramètres. Le fix a été un prompt plus tranchant.

L'auteur a fait trois choses dans le prompt de chaque agent :

• Lui dire explicitement ce qu'il produit et ce qu'il ne doit jamais acheter.
• Lui calculer à l'avance la liste exacte des biens qui lui manquent.
• Lui filer un exemple travaillé, une décision modèle.

Et la qualité des décisions a bondi: les créatures se sont mises à commercer selon leur rôle.

Et ça c'est un truc que je dis souvent:

Quand il y a une anomalie dans l'output c'est le meilleur moment pour refaire les prompts. Parce qu'en plus un prompt est agnostique du model sur lequel il tourne.

Toute la boucle est ensuite enveloppée dans une couche de parsing JSON tolérante, qui répare ou ignore. Donc une réponse mal formée dégrade en non-action au lieu de faire planter la simu.

C'est le pattern à retenir. Vous ne luttez pas contre la bêtise du petit modèle avec de la taille, vous la cadrez avec de la structure.

Le détail sur le bien-être que je trouve malin

Il y a un autre arbitrage de design que je veux souligner, parce qu'il est facile à rater.

L'auteur a d'abord modélisé le bien-être des créatures comme un accumulateur. Un compteur qui monte ou descend.

Problème. La moindre pénurie chronique faisait chuter une créature à zéro sur la durée.

Donc spirale de la mort: un agent qui optimise mal finit par crever, et regarder ça n'a aucun intérêt.

Le bien-être est devenu une humeur qui revient vers la moyenne, qui remonte dès qu'une créature est nourrie et au chaud, et qui ne tombe jamais à zéro.

Quand la simu s'est mise à raconter des histoires

C'est la partie dont l'auteur est le plus fier, et je comprends pourquoi.

Le joueur peut tirer une Légende de la Forêt. C'est un épisode célèbre de l'histoire des marchés, parodié en folklore forestier.

Quelques exemples :

• La Tulipomanie devient la Grande Manie des Glands.
• La bulle des mers du Sud devient la Compagnie de Commerce du Tronc Creux.
• Les paniques bancaires de 1929 deviennent la Ruée sur le Trésor d'Oona.

Chaque légende déclenche de vrais chocs, et les agents réagissent pour de vrai.

Sur une partie, l'auteur tire la Ruée sur le Trésor d'Oona, la rumeur que le coffre de la chouette est vide.

Oona se met à liquider son miel pour récupérer des cailloux. Et le flux de miel d'un coup sur le marché fait chuter le prix de 10 à 3 sur les tours suivants.

Donc une panique bancaire a poussé un agent à brader ses actifs, ce qui a bougé un vrai prix de marché. Rien de tout ça n'était scripté.

Pour que ce soit visible, il a fallu débloquer un dernier truc. Les prix étaient figés, parce que les agents recrachaient bêtement le prix de référence qu'on leur montrait.

Le fix a été de laisser la référence de marché dériver selon l'offre et la demande résiduelles après chaque round. Trop d'achats non servis fait monter, un excès fait baisser.

Ce que ça donne en vrai

Voici une partie représentative sur 15 tours, avec une sécheresse et une rumeur d'hiver injectées en cours de route.

Métrique	Résultat
Actions JSON valides	100% (75 appels sur 75)
Échanges par tour	entre 3 et 9, jamais zéro
Prix du miel	krach de 10 à 3 pendant la légende de la panique bancaire
Prix du bois	monte de 4 à 7 quand l'hiver mord
Écart de richesse (Gini)	s'élargit de 0,14 à 0,38
Issue	le bûcheron finit le plus riche, le thésauriseur ruiné

Et le détail qui me plaît le plus. Le raisonnement derrière chacun de ces mouvements est disponible en open data.

Chaque ligne, c'est le prompt complet d'une créature, sa réponse brute, les actions parsées et sa pensée privée. Vous pouvez littéralement lire pourquoi un agent a paniqué.

Ce que j'en retiens pour mes propres projets

Cet article est un field report d'ingénierie, pas une démo marketing. Donc il y a des choses à comprendre.

3 leçons que je garde sous le coude :

• L'essentiel du boulot avec un petit modèle, c'est de combler l'écart entre un format fiable et un raisonnement pas fiable. Et on comble cet écart avec de la structure et du prompt, pas avec de la taille.
• Un système émergent a besoin de rareté conçue. L'abondance, c'est ennuyeux. Si tout le monde a tout, il ne se passe rien, dans une simu comme dans un produit.
• Les meilleures démos de petits modèles n'ont pas besoin de drame inventé. Trois siècles d'histoire des marchés étaient déjà prêts à servir, et un conseil d'agents 3B a suffi à le rejouer.

Car au fond, le message stratégique est limpide. Pendant qu'une partie de l'industrie vend du toujours plus gros, un dev tout seul prouve qu'un modèle 3B bien cadré fait tourner une économie entière en temps réel.

Et la question que je me pose, c'est combien de produits agentiques tournent aujourd'hui sur un gros modèle hors de prix, alors que plusieurs petits modèles plus un bon prompt feraient le job pour 10 fois moins cher.

Est-ce déjà l'ère des model refactor ?