Conditions de l’expérience OpenCode et Qwen RTX des 21–22 septembre 2026
Notice historique publiée le 15 octobre 2026.
Cette notice explique les conditions du lot Qwen RTX de septembre 2026 : ce qui était fourni au cluster, ce que le modèle générait et ce que les contrôles permettaient de conclure. Elle ne décrit pas les variantes Qwen Flash présentes ultérieurement dans la galerie. Publier cette documentation ne constitue pas une nouvelle construction des applications.
Le cluster a reçu davantage que des notebooks. Qwen local a généré et réparé des fichiers applicatifs dans un environnement préparé, avec du code d’appui, des données, des dépendances, des objectifs et des tests préexistants. La supervision Codex restait en ligne : l’expérience était hybride.
Schéma et résultats historiques
Voir le schéma détaillé des flux.
Les durées du poster décrivent les essais historiques. Les matériels, modèles et périmètres diffèrent entre Astra, Qwen Mac et Qwen RTX ; ces durées ne forment pas un benchmark contrôlé.
Qui faisait quoi ?
| Composant | Fonction dans le lot étudié |
|---|---|
| Codex en ligne, depuis le poste de supervision Mac | Préparer et superviser les opérations, examiner les résultats et organiser la livraison. |
| Tokki | Encadrer les commandes et conserver des éléments de preuve ; sur le cluster, lancer OpenCode et les opérations locales. |
| OpenCode | Exécuter l’agent de développement : conversation, lecture, édition, appels d’outils et itérations. |
| Qwen local | Produire les réponses, décisions et nouveaux fichiers applicatifs de cet agent. |
| AGILAB et les contrôleurs fournis | Fournir l’intégration et les vérifications indépendantes du notebook, de l’interface et du workflow. |
| Hugging Face | Héberger les fichiers sélectionnés lors d’une étape de publication ultérieure. |
L’agent initial est le mode build d’OpenCode, avec
Qwen3.8-27B Q4_K_M : un modèle de 27 milliards de paramètres sous une forme
quantifiée, qui réduit la précision de stockage de ses poids. Certaines phases
de réparation utilisent ensuite le mode OpenCode repair_patch.
OpenCode appelle le modèle par une interface HTTP — Hypertext Transfer
Protocol — compatible avec le format d’API OpenAI, à
127.0.0.1:11234/v1. Cette adresse désigne la boucle locale du nœud :
la compatibilité du protocole ne signifie pas que le modèle tourne dans le
cloud OpenAI. Le reçu Iris consulté situe effectivement son exécution sur le
nœud Linux rtx5, avec cette identité de modèle local.
Ce que le cluster recevait avant de générer
| Apport préexistant | Contenu et rôle |
|---|---|
| Chaîne de développement | Tokki, OpenCode, serveur Qwen et environnement AGILAB préparé. |
| Environnement d’exécution | Interpréteurs Python, composants AGILAB, bibliothèques de calcul et d’interface, outils de test et navigateur Chromium. |
| Entrées scientifiques | Notebooks de référence, fichiers de provenance et de licence, corpus texte local et modèle Chronos-2 Small mis en cache à une révision fixée pour Forecast. |
| Objectifs et consignes | Adaptation attendue, fichiers à produire, contraintes et retours des vérifications. |
| Code d’appui | agilab_pool.py fourni pour Threading et MILP, avec les licences applicables. |
| Qualification | Vérificateurs AGILAB préexistants, contrat d’entrée et contrôleur indépendant. |
L’orchestrateur extrait les cellules de code du notebook dans
source/code_only.txt. Cette représentation et les fichiers d’entrée
participent au contexte de Qwen. Les consignes interdisent d’exécuter le
notebook original, conservé comme référence ; la qualification exécute le
notebook nouvellement produit.
Selon l’application, les livrables demandés comprennent app.py, des modules
de calcul, solution.ipynb, les dépendances déclarées et un éventuel
tests.py. L’intégration AGILAB importe ensuite le notebook généré et produit
notebook_import.json et lab_stages.toml. Ces métadonnées sont créées par
l’orchestration ; leur présence ne prouve pas que Qwen les a écrites.
Code fourni, code généré et mesures
Le fichier agilab_pool.py est du code fourni, pas une création nouvelle de
Qwen dans cet essai. Sa présence dans un projet ou un téléchargement ne prouve
pas qu’il est importé, exécuté ou utilisé par la mesure affichée.
Le compte rendu final précise ainsi que MILP RTX mesure son lanceur de processus généré. Le moteur AGILAB fourni dans ce bundle reste une référence de source. Attribuer la mesure à ce moteur changerait le périmètre de l’essai.
Les comptages de code historique excluent les tests, les sources originales et les fichiers fournis. Un KLOC correspond à mille lignes de code selon la convention de comptage retenue ; cette quantité ne mesure ni la qualité ni la correction du programme.
Quels tests, et exécutés par qui ?
Les contrôles de qualification sont fournis par la préparation et l’orchestration de supervision, notamment à partir de vérificateurs AGILAB préexistants. Leurs empreintes et celles du contrat sont protégées ; Qwen reçoit l’interdiction de les modifier.
Un éventuel tests.py du projet généré est exécuté séparément. Il ne
remplace pas les vérifications indépendantes. On ne peut donc attribuer
l’ensemble des tests à Qwen, ni attribuer à Codex la rédaction initiale de
chaque test préexistant.
Les contrôleurs exécutent les vérifications et renvoient leurs échecs à Qwen
pour réparation. L’agent OpenCode peut également appeler les contrôles fournis
avec ses outils. Pour le run Iris observé et ses contrôles navigateur, les
preuves situent l’exécution sur rtx5. La préparation d’un test et son lieu
d’exécution sont deux informations distinctes.
Par quelles interfaces passaient les échanges ?
SSH signifie Secure Shell, l’interface d’administration à distance.
| Sens | Interface et contenu | Ce qui est établi |
|---|---|---|
| Supervision Mac → cluster | Administration SSH documentée et mise à disposition des scripts, objectifs, environnement, entrées et contrôles. | La configuration et la notice SSH existent ; le protocole exact de chaque transfert historique n’est pas reconstitué. |
| Contrôleur local → Tokki → OpenCode | Lancement du programme d’agent avec le projet, le modèle et les consignes. | Les scripts de lancement et des reçus de modèle sont conservés. |
| OpenCode ↔ Qwen | API HTTP locale pour les messages, réponses et demandes d’appels d’outils. | L’endpoint local est configuré ; le reçu Iris confirme le fournisseur et le modèle. |
| OpenCode → outils locaux | Lecture des entrées, édition des fichiers et exécution des contrôles, via les commandes encadrées par Tokki. | Les consignes et les traces examinées documentent cette boucle. |
| Cluster → supervision | Retour des résultats, erreurs, reçus et livrables. | Les artefacts récupérés existent ; ils ne constituent pas une capture réseau exhaustive. |
| Préparation de publication → Hugging Face | Publication de fichiers sélectionnés et validés. | Cette étape est distincte de la génération locale. |
Une configuration ne prouve pas chaque exécution. Un prompt ne prouve pas le respect de toutes ses consignes. La documentation disponible ne permet pas d’affirmer que chaque transfert a utilisé SCP ou rsync, ni que chaque octet a été retracé.
L’incident Threading et la version livrée
Le contrôleur de reconstruction désigne la tentative
20260922T091918Z-b680a442 comme remplacée pour copie d’une application
préexistante. Il exige ensuite l’absence des anciennes ressources de démos et
prévoit une reconstruction sur rtx1. Ce script décrit la décision et ses
garde-fous ; il ne prouve pas seul l’achèvement d’une reconstruction.
L’index de livraison associe la route threading_rtx à un run ultérieur,
20260922T161005Z-fb75e76b. Les empreintes de ses fichiers concordent avec
celles du reçu de publication. Une validation du bundle porte le même reçu et
rapporte l’exécution réussie du notebook, du démarrage de l’application, de
son interaction et du workflow.
Cette validation indique scientific_correctness_verified: false.
Son périmètre couvre l’exécution et l’interface, puis la concordance des
résultats du notebook et du workflow. Le statut passed doit être lu avec
ces limites ; il ne constitue pas une certification générale de correction
scientifique.
Le journal original de la copie rejetée n’a pas été retrouvé dans la sélection examinée. Elle ne permet pas de nommer précisément le fichier copié et son chemin d’origine, ni de certifier la filiation de chaque ligne entre les runs. L’audit de provenance cherche des empreintes identiques et des accès à un répertoire connu, en excluant les sources et le helper fourni : c’est un contrôle ciblé, pas une certification complète d’originalité.
Ce que cette expérience permet de conclure
Les éléments conservés documentent une génération et des réparations applicatives locales, accompagnées d’une préparation, de réutilisation de code et d’une qualification indépendante. Ils ne démontrent pas une construction intégrale à partir du seul notebook.
Les comparaisons restent non contrôlées. Elles n’établissent pas de gain général de performance, d’économie, de qualité ou de débit reçu. Les contrôles numériques particuliers d’autres applications doivent être interprétés dans leurs propres périmètres.
La supervision Codex en ligne et la publication ultérieure sont explicites. Un modèle local ne démontre ni une chaîne entièrement hors ligne, ni une absence de sortie de données, ni un environnement isolé de tout réseau.
Cette synthèse repose sur une sélection de reçus historiques, scripts et empreintes conservés par le mainteneur. Les pièces de travail ne sont pas jointes à cet export public ; les liens proposés ici donnent accès aux illustrations et au poster, pas à ces archives. Les conclusions et les lacunes de preuve sont conservées ensemble.