Ik had dezelfde gedachte, dus ik ben ermee aan het spelen in nanochat. Bijv. hier zijn 8 agenten (4 claude, 4 codex), met elk 1 GPU die nanochat-experimenten uitvoeren (proberen de logit softcap te verwijderen zonder regressie). De TLDR is dat het niet werkt en het een rommel is... maar het is nog steeds heel mooi om naar te kijken :) Ik heb een paar opstellingen geprobeerd: 8 onafhankelijke solo-onderzoekers, 1 hoofdonderzoeker die werk geeft aan 8 junior onderzoekers, enz. Elk onderzoeksprogramma is een git-tak, elke wetenschapper forked het in een feature-tak, git worktrees voor isolatie, eenvoudige bestanden voor communicatie, skip Docker/VM's voor eenvoud op dit moment (ik vind dat instructies genoeg zijn om interferentie te voorkomen). De onderzoeksorganisatie draait in tmux-vensterroosters van interactieve sessies (zoals Teams) zodat het mooi is om naar te kijken, hun individuele werk te zien, en "over te nemen" indien nodig, d.w.z. geen -p. Maar goed, de reden dat het tot nu toe niet werkt, is dat de ideeën van de agenten gewoon erg slecht zijn uit de doos, zelfs bij de hoogste intelligentie. Ze denken niet zorgvuldig na over experimenteel ontwerp, ze voeren een beetje onsamenhangende variaties uit, ze creëren geen sterke baselines en ableren dingen niet goed, ze controleren runtime of flops niet zorgvuldig. (bijvoorbeeld, een agent ontdekte gisteren "dat het vergroten van de verborgen grootte van het netwerk de validatieverlies verbetert, wat een totaal spurious resultaat is gezien het feit dat een groter netwerk een lagere validatieverlies zal hebben in het oneindige dataregime, maar dan traint het ook veel langer, het is niet duidelijk waarom ik moest binnenkomen om dat aan te geven). Ze zijn erg goed in het implementeren van elk goed afgebakend en beschreven idee, maar ze genereren ze niet creatief. Maar het doel is dat je nu een organisatie programmeert (bijv. een "onderzoeksorganisatie") en zijn individuele agenten, dus de "broncodes" zijn de verzameling van prompts, vaardigheden, tools, enz. en processen die het vormen. Bijv. een dagelijkse stand-up in de ochtend is nu onderdeel van de "org-code". En het optimaliseren van nanochat pretraining is slechts een van de vele taken (bijna zoals een evaluatie). Dan - gegeven een willekeurige taak, hoe snel genereert jouw onderzoeksorganisatie vooruitgang daarop?

Met de komende tsunami van vraag naar tokens zijn er aanzienlijke kansen om het onderliggende geheugen+rekenkracht *precies goed* te orkestreren voor LLM's. De fundamentele en niet-voor-de-hand-liggende beperking is dat, vanwege het chipfabricageproces, je twee volledig verschillende geheugenpools krijgt (met ook verschillende fysieke implementaties): 1) on-chip SRAM die onmiddellijk naast de rekeneenheden ligt, die ongelooflijk snel is maar van zeer lage capaciteit, en 2) off-chip DRAM dat een extreem hoge capaciteit heeft, maar waarvan je de inhoud alleen door een lange rietje kunt zuigen. Bovenop dit alles zijn er veel details van de architectuur (bijv. systolische arrays), numeriek, enz. Het ontwerp van het optimale fysieke substraat en vervolgens de orkestratie van geheugen+rekenkracht over de top volumeworkflows van LLM's (inference prefill/decode, training/finetuning, enz.) met de beste doorvoer/latentie/$ is waarschijnlijk de meest interessante intellectuele puzzel van vandaag met de hoogste beloningen (\cite 4.6T van NVDA). Alles om veel tokens snel en goedkoop te krijgen. Arguably is de workflow die het belangrijkst kan zijn (inference decode *en* over lange tokencontexten in strakke agentische lussen) degene die het moeilijkst gelijktijdig te bereiken is door de ~beide kampen van wat er vandaag bestaat (HBM-eerst NVIDIA aangrenzend en SRAM-eerst Cerebras aangrenzend). Hoe dan ook, het MatX-team is van A++-kwaliteit, dus het is mijn genoegen om een kleine betrokkenheid te hebben en gefeliciteerd met de financiering!