У мене була така сама думка, тому я експериментую з цим у nanochat. Наприклад, ось 8 агентів (4 claude, 4 codex), кожен з яких виконує по 1 GPU, що запускає експерименти з nanochat (спроба видалити logit softcap без регресії). Коротко: це не працює і це повний безлад... Але все одно дуже гарно дивитися на :) Я пробував кілька варіантів: 8 незалежних самостійних дослідників, 1 головний науковець, який дає роботу 8 молодшим дослідникам тощо. Кожна дослідницька програма — це гілка git, кожен науковець розділяє її на feature branch, git worktree для ізоляції, прості файли для зв'язку, пропускаю Docker/VM для простоти (я вважаю, що інструкції достатні, щоб уникнути перешкод). Дослідницька організація працює у tmux віконних сітках інтерактивних сесій (як у Teams), щоб було приємно дивитися, бачити їхню індивідуальну роботу і «взяти на себе», якщо потрібно, тобто без -p. Але добре, причина, чому це поки не працює, у тому, що ідеї агентів дуже погані з самого кінця, навіть на найвищому рівні інтелекту. Вони не замислюються над експериментальним дизайном, мають трохи безглузді варіації, не створюють сильних базових ліній і не аблюють, не контролюють час виконання чи флоп. (Наприклад, учора агент «виявив», що збільшення прихованого розміру мережі покращує втрати валідації, що є абсолютно хибним результатом, враховуючи, що більша мережа матиме менші втрати валідації в режимі нескінченних даних, але тоді вона тренується набагато довше, не зрозуміло, навіщо мені це вказати). Вони дуже добре реалізовують будь-яку чітко охоплену ідею, але не генерують її творчо. Але мета в тому, що ви зараз програмуєте організацію (наприклад, «дослідницьку організацію») та її окремих агентів, тож «вихідний код» — це збірка запитів, навичок, інструментів тощо та процесів, які його складають. Наприклад, щоденний стендап вранці тепер є частиною «організаційного коду». А оптимізація попереднього навчання наночату — це лише одне з багатьох завдань (майже як оцінка). Тоді — якщо ваша довільна задача, наскільки швидко ваша дослідницька організація досягає прогресу?

З наближенням хвилі попиту на токени з'являються значні можливості організувати базову пам'ять+обчислення *ідеально* для LLM. Фундаментальне і не очевидне обмеження полягає в тому, що через процес виготовлення чипа ви отримуєте два абсолютно різні пули пам'яті (різних фізичних реалізацій): 1) вбудована SRAM, яка знаходиться безпосередньо поруч із обчислювальними блоками, надзвичайно швидка, але з дуже низькою ємністю, і 2) позачипова DRAM з надзвичайно великою ємністю, але вміст якої можна лише висмоктати через довгу соломинку. Крім того, є багато деталей архітектури (наприклад, систолічні масиви), чисельна техніка тощо. Проєктування оптимального фізичного субстрату, а потім оркестрація пам'яті+обчислення між робочими процесами LLM з максимальним обсягом (inference, prefill/decode, training/finetuning тощо) з найкращою пропускною здатністю/затримкою/$ — це, мабуть, найцікавіша інтелектуальна головоломка сьогодні з найвищими винагородами (\cite 4.6T NVDA). Все це — щоб швидко і дешево отримати багато токенів. Можна стверджувати, що найважчий робочий процес, який має найбільше значення (декодування виведення *і* у довгих контекстах токенів у вузьких агентних циклах), є найскладнішим для одночасного виконання ~обома таборами, які існують сьогодні (HBM-перша сусідня NVIDIA та SRAM-перша Cerebras). У будь-якому разі, команда MatX має клас A++, тож мені приємно мати невелику участь і вітаю з підвищенням!