Quatre petits modèles, une économie vivante : le vrai défi de l'IA

Pourquoi quatre modèles, pas un ?

La première version de Thousand Token Wood tournait sur un seul modèle fine-tuné (0.5B). Cinq créatures forestières, une économie, des bulles et des crashs. C'était un jouet spectaculaire. v2 en a fait un jeu où tu es le financier de l'ombre, celui qui prête, chuchote des tuyaux (vrais ou faux), short le marché, corrompt et noue des alliances.

Le changement radical : chaque créature pense maintenant avec un modèle différent. OpenAI (gpt-oss-20b), OpenBMB (MiniCPM3-4B), NVIDIA (Nemotron-Mini-4B), et un Qwen 0.5B fine-tuné sur mesure. L'idée n'est pas de faire du spectaculaire pour du spectaculaire. C'est qu'un marché intéressant est un marché où les participants diffèrent vraiment. Le hibou thésaurise différemment que le renard spécule. La différence de formation, de tokenizer, de post-training crée une vraie diversité comportementale. Le code n'est pas un script, c'est une vraie dispute.

Le vrai problème : la couche de serveur

Voici le détail qui tue : la friction est presque entièrement au niveau de la couche de déploiement, pas à la modélisation.

vLLM 0.22.1 compile les kernels à la volée et demande le toolkit CUDA (nvcc). Une image légère ne le fournit pas. Résultat : les quatre modèles ont échoué identiquement avec "could not find nvcc"—pas un problème propre à OpenAI, pas un problème propre à Nemotron. Un problème universel vLLM. Une image de base CUDA devel a tout débloqué.

Après ça, chaque modèle a ses pièges à une ligne de config :

• ▸gpt-oss-20b : tourne en quantification native MXFP4, tient dans 24GB L4, mais enveloppe la réponse dans un préambule d'analyse—il faut l'extraire.
• ▸MiniCPM3 : réclame trust_remote_code.
• ▸Nemotron : se charge sans friction.

Le couteau suisse : une couche de réparation JSON

Ce qui a rendu quatre modèles hétérogènes gérables ? Une couche de traitement et réparation JSON tolérante. Chaque sortie y passe. Les tokenizers différents, les habitudes de formatage divergentes—tout produit des malformations différentes. Le parseur abandonne ce qu'il ne peut pas sauver, et la simulation ne plante jamais.

Construit ça une fois, et ajouter un modèle c'est une entrée de config. Pas une refactorisation.

Garder un secret secret

Le cœur dramatique de v2 : le tuyau d'initiateur. Tu chuchotes un tuyau à une créature. Vrai (tu as vu la vraie prochaine manie du deck, c'est ton avantage réel) ou faux (appât).

Profiter d'un vrai tuyau augmente ta chaleur. Dépasse un seuil et le magistrat enquête—amende, avoirs gelés, ou exil.

Pour que ce soit un vrai jeu, la vérité du tuyau doit rester cachée des créatures. Elles voient le texte de la rumeur. Jamais le drapeau caché.

C'est une propriété de sécurité, pas un détail d'interface. Et sur de petits modèles, c'est tranché : tout ce que le modèle peut répéter, tu l'as mis dans son prompt. Le secret vit hors du prompt, dans le registre du joueur. Retiré de l'enregistrement d'événements public. Un test parcourt chaque créature, chaque tour, pour les tokens interdits.

C'est le test le plus critique de la suite. Quand tu donnes à un agent une info secrète, suppose qu'elle fuira sauf si un test le prouve.

La mémoire bon marché : résumés bornés

Les créatures ont des relations persistantes : un sentiment signé vers toi et vers les autres, ajusté par les événements (tu as shorté ma récolte, tu as remboursé ton prêt, tu m'as allié à un rival).

Une créature qui devient hostile refuse tes prêts, te cite au pire. Les alliées arrêtent de se faire concurrence et se comportent comme un cartel.

Le piège : l'inflation de prompt. L'historique brut grandit sans limite, et un petit modèle s'y noie.

La solution : ne jamais mettre l'historique dans le prompt. Le modèle voit un résumé d'une ligne ("tu te sens chaud vers Oona, prudent vers le Patron"), plafonné aux quelques sentiments les plus forts, dérivé d'un entier sentiment. Les notes existent pour les traces, bornées, jamais montrées.

Le biais comportemental est moitié émergent (le résumé oriente le modèle), moitié mécanique (une créature franchement hostile refuse de façon déterministe). Donc observable et testable, pas un espoir.

Les trois leçons

1. ▸Un petit modèle est un générateur de format fiable et un raisonneur peu fiable. Tu fermes l'écart avec de la structure, du prompting, une petite fine-tune. Pas de mise à l'échelle.
2. ▸Un conseil hétérogène est plus intéressant qu'un conseil homogène et ne te coûte que de la configuration une fois la couche de serveur solide.
3. ▸Une info secrète donnée à un agent est un problème de pare-feu, et ce pare-feu appartient au flux de données, prouvé par un test, jamais une instruction de prompt.