Fable 5.1 и GPT-6 не закрыли утечку памяти за ночь: человек решил задачу за 5 минут

V

Taelin

@victortaelin

Кстати, и Fable 5.1, и GPT 6 за ночь провалили задачу, которую я решил за 5 минут. Хочу описать, что произошло, просто чтобы задокументировать, почему мы всё ещё не дошли до AGI, хотя с каждым днём подходим ближе. Пост будет техническим, потому что детали здесь важны. Итак, прошлой ночью Fable нашла утечку памяти в Bend2. Долго работающий процесс постепенно разрастался по памяти и через несколько часов падал. Вот баг. Я попросил Fable и Astra починить его за ночь. Правила: 1. Не увеличивать размер кодовой базы 2. Не ломать ни один бенчмарк Обе провалились. Но почему? Во-первых, обе верно определили первопричину. (всё, что ниже, написала Fable) В рантайме Bend2 16k GPU-линий. У каждой линии свои приватные free-list, поэтому alloc и free это два стора, без атомиков. Именно это и делает его быстрым. Загвоздка: когда линия освобождает блок, выделенный другой линией, блок попадает в список освобождающей линии. Если та линия выделяет меньше, чем освобождает, блок остаётся там навсегда. Ничего не теряется, память просто припаркована в списке, которым никто не пользуется. Это нашли обе модели. Обе это и измерили: 40-85% всех освобождений идут между линиями. Дальше обе всю ночь пытались чинить аллокатор. Возвращать блоки линии-владельцу: +124% медленнее. Слэбы: в 73 раза медленнее. Buddy: +7-21%. Сброс в точках синхронизации: +3,5k токенов. Полная переписка аллокатора на lock-free цепочки: утечки нет, но +1,9k токенов и matmul на CUDA медленнее на 78%. Каждый вариант ломал либо лимит по токенам, либо бенчмарк. Ни одна модель не сошлась. Они просто продолжали наворачивать машинерию поверх той же посылки. Посылка была неверной. Я попросил гистограмму: где на самом деле лежит припаркованная память. 96% сидело в последних 4096 линиях. Это не проблема аллокатора. Это планировщик: он раздаёт работу как чистую функцию от номера линии. Линия 0 всегда получает корень дерева. Листья всегда достаются одним и тем же линиям. join всегда выполняется на последнем пришедшем потомке, а последними всегда приходят одни и те же линии. Поэтому на каждом запуске память течёт в одном направлении, из одних и тех же линий в одни и те же, и поток никогда не разворачивается. С аллокатором всё было в порядке. Это линии не были взаимозаменяемыми. Починка: ротировать идентичности линий. На каждом запуске физическая линия p использует free-list линии (p + r) mod 16k, где r сдвигается шагом золотого сечения. За цикл каждая идентичность играет каждую роль по разу, и перекос суммируется в ноль. Аллокатор не трогаем, атомиков нет, на горячем пути ничего. Горстка строк. Как только я сказал это Fable, она это внедрила, замерила и прогнала весь гейт за полдня: 555MB → 23MB после 2000 запусков, OOM отодвинулся с ~7k запусков до ~75M, ноль издержек на всех 16 бенчмарках. Так чего не хватило? Не способностей. Обе модели могут написать lock-free аллокатор за ночь. Ни одна не сделала другого: не отступила на шаг и не спросила, почему память вообще течёт в одну сторону. Они приняли асимметрию как факт системы и строили всё более сложную машинерию, чтобы её компенсировать, вместо того чтобы её убрать. Вот и зазор: не «может ли оно сделать работу», а «ставит ли оно под вопрос рамку, в которой работает». И всё же всё остальное оно сделало, от диагноза до переписи и починки, стоило только указать. Ближе, чем год назад. Но ещё не там.

19:24 · 5 сент. 2026 г. · 2,9 тыс. просмотров