Jag hade samma tanke så jag har lekt med det i nanochat. Till exempel, här är 8 agenter (4 claude, 4 codex), med 1 GPU som kör nanochat-experiment (försöker ta bort logit softcap utan regression). Sammanfattningen är att det inte fungerar och det är ett kaos... Men det är ändå väldigt vackert att se på :) Jag testade några upplägg: 8 oberoende soloforskare, 1 chefsforskare som ger arbete till 8 juniora forskare, osv. Varje forskningsprogram är en git-gren, varje forskare förgrenar den till en funktions-gren, git-arbetsträd för isolering, enkla filer för kommunikation, hoppa över Docker/VM:er för enkelhetens skull uttagsautomat (jag tycker att instruktioner räcker för att förhindra störningar). Forskningsorganisationen körs i tmux-fönsterrutnät av interaktiva sessioner (som Teams) så att det är snyggt att titta på, se deras individuella arbete och "ta över" vid behov, alltså ingen -p. Men okej, anledningen till att det inte fungerar hittills är att agenternas idéer är ganska dåliga direkt från början, även på högsta intelligensnivå. De tänker inte noga på experimentdesign, de kör lite meningslösa variationer, de skapar inte starka baslinjer och ablater saker ordentligt, de kontrollerar inte noggrant för körtid eller floppar. (Bara som ett exempel, en agent "upptäckte" igår att en ökning av nätverkets dolda storlek förbättrar valideringsförlusten, vilket är ett helt tveksamt resultat eftersom ett större nätverk har en lägre valideringsförlust i det oändliga datasystemet, men det tränar också mycket längre, det är oklart varför jag var tvungen att påpeka det). De är väldigt bra på att implementera vilken väl genomtänkt och beskriven idé som helst, men de genererar dem inte kreativt. Men målet är att du nu programmerar en organisation (t.ex. en "forskningsorganisation") och dess individuella agenter, så "källkoden" är samlingen av prompts, färdigheter, verktyg osv. och processer som utgör den. Till exempel är en daglig standup på morgonen nu en del av "org-koden". Och att optimera nanochat-förträning är bara en av många uppgifter (nästan som en utvärdering). Sedan – givet en godtycklig uppgift, hur snabbt genererar din forskningsorganisation framsteg på den?

Med den kommande tsunamin av efterfrågan på tokens finns det betydande möjligheter att orkestrera den underliggande minne+beräkningen *precis rätt* för LLM:er. Den grundläggande och icke-uppenbara begränsningen är att på grund av chiptillverkningsprocessen får du två helt separata minnespooler (av olika fysiska implementationer också): 1) on-chip SRAM som ligger direkt intill beräkningsenheterna och är otroligt snabb men med mycket låg kapacitet, och 2) off-chip DRAM som har extremt hög kapacitet, men vars innehåll kan du bara suga genom ett långt sugrör. Utöver detta finns många detaljer i arkitekturen (t.ex. systoliska arrayer), numerik, etc. Designen av det optimala fysiska substratet och sedan orkestreringen av minne+beräkning över de främsta volymarbetsflödena i LLM:er (inferensprefill/avkodning, träning/finjustering, etc.) med bästa genomströmning/latens/$ är förmodligen dagens mest intressanta intellektuella pussel med högst belöning (citer 4,6T av NVDA). Allt detta för att få många tokens, snabbt och billigt. Man kan hävda att det arbetsflöde som kan vara viktigast (inferensavkodning *och* över långa token-kontexter i täta agentiska loopar) är det svåraste att uppnå samtidigt för ~båda lägren av det som finns idag (HBM-först, NVIDIA-angränsande och SRAM-först, Cerebras-angränsande). Hur som helst, MatX-teamet är A++-klass så det är ett nöje att få ett litet engagemang och grattis till löneförhöjningen!