У меня была такая же мысль, поэтому я экспериментировал с этим в nanochat. Например, вот 8 агентов (4 claude, 4 codex), каждый с 1 GPU, проводящих эксперименты в nanochat (пытаясь удалить логит softcap без регрессии). Кратко говоря, это не работает, и это беспорядок... но на это все равно приятно смотреть :) Я попробовал несколько настроек: 8 независимых исследователей, 1 главный ученый, который дает задания 8 младшим исследователям и т.д. Каждая исследовательская программа — это ветка git, каждый ученый создает ее в виде ветки функции, git worktrees для изоляции, простые файлы для связи, пропускаем Docker/VM для простоты на данный момент (я считаю, что инструкций достаточно, чтобы предотвратить вмешательство). Исследовательская организация работает в сетках окон tmux интерактивных сессий (как Teams), чтобы это было приятно смотреть, видеть их индивидуальную работу и "взять на себя" управление, если это необходимо, т.е. без -p. Но причина, по которой это пока не работает, в том, что идеи агентов просто плохи с самого начала, даже при самом высоком уровне интеллекта. Они не продумывают дизайн эксперимента, они запускают немного бессмысленные вариации, они не создают сильные базовые линии и не аблатируют вещи должным образом, они не контролируют время выполнения или flops. (например, агент вчера "обнаружил", что увеличение скрытого размера сети улучшает валидационную потерю, что является совершенно ложным результатом, учитывая, что большая сеть будет иметь более низкую валидационную потерю в режиме бесконечных данных, но затем она также обучается гораздо дольше, неясно, почему мне пришлось вмешаться, чтобы указать на это). Они очень хороши в реализации любой хорошо определенной и описанной идеи, но они не генерируют их креативно. Но цель в том, что вы теперь программируете организацию (например, "исследовательская организация") и ее отдельных агентов, так что "исходный код" — это набор подсказок, навыков, инструментов и т.д. и процессов, которые ее составляют. Например, ежедневная утренняя встреча теперь является частью "кода организации". А оптимизация предобучения nanochat — это всего лишь одна из многих задач (почти как оценка). Затем — учитывая произвольную задачу, как быстро ваша исследовательская организация генерирует прогресс в этом?

С учетом надвигающегося цунами спроса на токены, существуют значительные возможности для организации базовой памяти+вычислений *именно так*, как это нужно для LLM. Основное и неочевидное ограничение заключается в том, что из-за процесса производства чипов вы получаете два совершенно разных пула памяти (с различными физическими реализациями): 1) встроенная SRAM, которая находится непосредственно рядом с вычислительными блоками, она невероятно быстрая, но с очень низкой емкостью, и 2) внешняя DRAM, которая имеет чрезвычайно высокую емкость, но содержимое которой можно извлечь только через длинную соломинку. Кроме того, есть много деталей архитектуры (например, систолические массивы), численные методы и т.д. Проектирование оптимального физического субстрата, а затем организация памяти+вычислений по верхним объемным рабочим процессам LLM (инференс, предзаполнение/декодирование, обучение/донастройка и т.д.) с наилучшей пропускной способностью/задержкой/$ вероятно, является самой интересной интеллектуальной задачей сегодняшнего дня с наибольшими наградами (\cite 4.6T от NVDA). Все это для того, чтобы получить много токенов, быстро и дешево. Можно утверждать, что рабочий процесс, который может иметь наибольшее значение (декодирование инференса *и* по длинным контекстам токенов в плотных агентских циклах) является тем, который труднее всего достичь одновременно для ~обоих лагерей того, что существует сегодня (HBM-первый, соседний с NVIDIA, и SRAM-первый, соседний с Cerebras). В любом случае, команда MatX на уровне A++, поэтому мне приятно иметь небольшое участие и поздравляю с привлечением средств!