J'ai eu la même pensée, donc j'ai joué avec dans nanochat. Par exemple, voici 8 agents (4 claude, 4 codex), chacun avec 1 GPU exécutant des expériences nanochat (essayant de supprimer le softcap logit sans régression). Le TLDR est que ça ne fonctionne pas et c'est un désordre... mais c'est toujours très joli à regarder :) J'ai essayé quelques configurations : 8 chercheurs indépendants, 1 scientifique en chef donnant du travail à 8 chercheurs juniors, etc. Chaque programme de recherche est une branche git, chaque scientifique la fork en une branche de fonctionnalité, des worktrees git pour l'isolation, des fichiers simples pour les communications, en évitant Docker/VMs pour la simplicité pour l'instant (je trouve que les instructions suffisent à prévenir les interférences). L'organisation de recherche fonctionne dans des grilles de fenêtres tmux de sessions interactives (comme Teams) afin que ce soit joli à regarder, voir leur travail individuel, et "prendre le relais" si nécessaire, c'est-à-dire pas de -p. Mais bon, la raison pour laquelle ça ne fonctionne pas jusqu'à présent est que les idées des agents sont tout simplement assez mauvaises dès le départ, même à la plus haute intelligence. Ils ne réfléchissent pas soigneusement à la conception des expériences, ils exécutent des variations un peu non-sensiques, ils ne créent pas de bases solides et n'ablatent pas les choses correctement, ils ne contrôlent pas soigneusement le temps d'exécution ou les flops. (juste comme exemple, un agent hier a "découvert" qu'augmenter la taille cachée du réseau améliore la perte de validation, ce qui est un résultat totalement spurié étant donné qu'un réseau plus grand aura une perte de validation plus faible dans le régime de données infinies, mais ensuite il s'entraîne aussi beaucoup plus longtemps, il n'est pas clair pourquoi j'ai dû intervenir pour le faire remarquer). Ils sont très bons pour mettre en œuvre n'importe quelle idée bien définie et décrite, mais ils ne les génèrent pas de manière créative. Mais l'objectif est que vous programmez maintenant une organisation (par exemple, une "organisation de recherche") et ses agents individuels, donc le "code source" est la collection de prompts, compétences, outils, etc. et processus qui la composent. Par exemple, un stand-up quotidien le matin fait maintenant partie du "code de l'organisation". Et optimiser le pré-entraînement de nanochat n'est qu'une des nombreuses tâches (presque comme une évaluation). Ensuite - étant donné une tâche arbitraire, à quelle vitesse votre organisation de recherche génère-t-elle des progrès dessus ?

Avec le tsunami de demande à venir pour les tokens, il existe d'importantes opportunités pour orchestrer la mémoire et le calcul sous-jacents *juste comme il faut* pour les LLMs. La contrainte fondamentale et non évidente est que, en raison du processus de fabrication des puces, vous obtenez deux pools de mémoire complètement distincts (avec des implémentations physiques différentes également) : 1) la SRAM sur puce qui est immédiatement à côté des unités de calcul, incroyablement rapide mais de très faible capacité, et 2) la DRAM hors puce qui a une capacité extrêmement élevée, mais dont le contenu ne peut être aspiré que par une longue paille. En plus de cela, il y a de nombreux détails de l'architecture (par exemple, les tableaux systoliques), les numériques, etc. La conception du substrat physique optimal et ensuite l'orchestration de la mémoire et du calcul à travers les flux de travail de volume supérieur des LLMs (pré-remplissage/décodage d'inférence, entraînement/ajustement fin, etc.) avec le meilleur débit/latence/$ est probablement le puzzle intellectuel le plus intéressant d'aujourd'hui avec les plus grandes récompenses (\cite 4.6T de NVDA). Tout cela pour obtenir de nombreux tokens, rapidement et à moindre coût. On peut dire que le flux de travail qui pourrait avoir le plus d'importance (décodage d'inférence *et* sur de longs contextes de tokens dans des boucles agentiques serrées) est celui qui est le plus difficile à réaliser simultanément par les ~deux camps de ce qui existe aujourd'hui (NVIDIA adjacent à HBM en premier et Cerebras adjacent à SRAM en premier). Quoi qu'il en soit, l'équipe MatX est de grade A++, donc c'est un plaisir pour moi d'avoir une petite implication et félicitations pour la levée de fonds !