Андрюша Карпатый снова навалил базы: nanochat miniseries v1 😮

Андрей Карпатый не перестаёт радовать нас годным контентом. Он выкатил жирный апдейт в своём репозитории nanochat - проекте, который учит создавать свой ChatLGBT с полного нуля.

Если раньше мы просто учились запускать пайплайн, чтобы оно работало, то теперь Андрюха погружает нас именно в сам процесс обучения. Главный вопрос апдейта: как тратить вычислительные ресурсы (бабосиксаны) максимально эффективно? 🤔

Разбираем, что там внутри:

1️⃣ Scaling Laws
Для многих новичков подбор параметров модели звучит как что-то непонятное, но Карпатый показывает, что это - строгая и понятная математика. Суть проста: хватит гадать на кофейной гуще, какую архитектуру выбрать и сколько данных скормить. Бро использует законы масштабирования.

Эксперимент: Карпатый запустил серию обучений (miniseries) с фиксированным бюджетом (~$100 на H100) и потратил его по-разному:
🟣 Одни модели были «маленькими», но учились долго (много токенов)
🟡 Другие были «жирными», но учились быстро (мало токенов)

Результат: Все модели стоили одинаково, но одна конкретная конфигурация дала лучшее качество

2️⃣ Предсказуемость - наше всё
Вы не играете в казик, когда запускаете обучение. Вы можете провести дешёвые эксперименты за сотку баксов, найти идеальную формулу, а затем просто увеличить масштаб (вложить $100k или $1M) и гарантированно получить ожидаемый прирост качества. Инженеры OpenAI/Anthropic не тыкают пальцем в небо, они так считает деньги и масштабы 🍗

3️⃣ Сдвиг фокуса на Pretraining
В первой версии nanochat фишкой был «полный цикл» до веб-интерфейса. В miniseries v1 акцент сместился на Pretraining. Запомните: именно здесь закладывается фундамент интеллекта. Если вы обосрались на претрейне, то никакой файн-тюн (SFT/RLHF) это уже не исправит 🍌

Что с этим делать? Если хотите реально понимать, как работают LLM , а не просто импортировать либы:
• Залетайте в обсуждение: github.com/karpathy/nanochat/discussions/420
• Смотрите на графики Loss vs Compute
• Ковыряйте код скрипта miniseries.sh - это эталон того, как нужно организовывать эксперименты

Итог 🏋️
Масштабирование - это сплошная инженерка. Андрюха дал вам песочницу, чтобы освоить её за копейки, прежде чем лезть в серьёзные бюджеты. Поэтому тыкаем это обсуждение с ЛЛМ-кой, чтобы понять его

Рекурсивные языковые модели

В последнее время всё чаще обсуждают проблему длинного контекста. Большое количество токенов просто физически не помещается в модели, а с увеличением контекста зачастую падает качество. Авторы сегодняшней статьи предлагают решение: дать моделям правильные инструменты.

Как это устроено: у модели есть промпт с описанием задачи и доступных тулов. Первый — это Python REPL. Модель может исполнить произвольный код, где в переменной prompt сохранён весь длинный промпт.

Второй тул — это вызов языковой модели на глубине 1 (depth=1) с поданным фрагментом длинного промпта. Это напоминает субагентов в агентах для написания кода (Claude Code, Codex), но есть важное отличие. Вызов llm_query живёт «внутри» REPL, а значит модель может встроить его в цикл, условие или любую другую программную конструкцию. В Claude Code или Codex субагент — это отдельный тул-колл, который модель вызывает из контекста напрямую, без программного контроля. Такая модель называется рекурсивной (RLM), и их может быть несколько в рамках одного цикла. RLM не обязательно должна быть идентична изначальной. Главное, что у неё пустой контекст.

Суть метода, предложенного авторами статьи, в том, чтобы дать модели возможность запускать себя рекурсивно в той же программной среде (изображение 1). Среди бейзлайнов авторы рассматривают вариант без самовызовов (только модель с большим промптом и REPL), summary agent (суммаризация контекста, не поместившегося в модель) и CodeAct (код плюс ретривал через BM25).

Нюансы разницы RLM и типичных кодовых агентов до сих пор вызывают дискуссии с авторами в твиттере, и хайп вокруг статьи и идеи только растёт. Примеры тут, тут и тут.

Эксперименты проводили на Qwen3 и GPT-5 (изображение 2). На бенчмарке BrowseComp+ (контекст 6–11 миллиона токенов, нужно найти один релевантный документ из тысячи и ответить на вопрос) базовые модели невозможно запустить — контекст просто не влезает. RLM здесь работает.

Но поиск по длинному контексту — не единственная задача, которую решают RLM. Бенчмарк OOLONG требует семантической обработки фрагментов текста и их агрегации. Сложность линейная относительно длины входа. Здесь RLM без самовызовов уступает даже базовой модели, потому что задача требует «видеть» весь контекст. RLM с самовызовами заметно выигрывает у всех бейзлайнов.

Самый показательный результат на OOLONG-Pairs. Здесь нужно сравнивать пары фрагментов, то есть сложность задачи квадратичная. Базовая модель и summary agent выдают результат около нуля. RLM с самовызовами решает эту задачу, программно организуя квадратичное число вызовов через код в REPL. Это класс задач, недоступный другим подходам.

По стоимости RLM с самовызовами зачастую сопоставима с базовой моделью, хотя со сложностью задачи стоимость растёт (изображение 3).

Разбор подготовил ❣ Иван Рубачёв

Душный NLP