Эдвард Янг предложил новый взгляд на PyTorch — как на язык, который одновременно служит и эталонной, и продакшен-реализацией. Обычно эталонный код пишут ради ясности и в продакшен не пускают, он слишком медленный. PyTorch ломает этот шаблон: когда задача не слишком большая или компилятор отрабатывает хорошо, эталонный код на нём же и едет в прод. Но всё чаще эталонная реализация становится отдельным артефактом, по которому сверяют корректность боевой версии. Одна кодовая база для исследований, другая — для масштаба, и верификатор, который их связывает.
Лучше всего это видно в работе с kernel DSL. Раньше надеялись, что компилятор сам превратит высокоуровневый код в оптимальный, но для матричных умножений и attention-операций выжать пиковую производительность так и не вышло. Разработчики перешли к явному описанию тайлинга и перемещения данных через DSL, и это резко упростило получение быстрых ядер. Высокоуровневый API никуда не делся — авторы ядер почти всегда держат рядом эталон на чистом PyTorch и проверяют численную точность оптимизированной версии.
Та же логика, считает Янг, применима к целым шагам обучения с приходом coding agents. Раньше autograd был главной фичей PyTorch — он гарантировал правильные производные. Но на большом масштабе неявный граф обратного прохода превращается в проблему: основные вычисления спрятаны, их не поотлаживать обычными инструментами и не слить с прямым кодом. Можно патчить граф компилятором через pattern matching, но это хрупко и неудобно. Библиотека Tangent когда-то пыталась решить это через source-to-source дифференцирование, но заглохла.
Новый рецепт выглядит так: оставляем обычный PyTorch-код с autograd как эталон, а с помощью LLM генерируем явную forward-backward версию — её уже оптимизируем отдельно. В отличие от pattern matching, тут не нужно бояться, что оптимизация внезапно не применится. Но эталон и оптимизированная версия могут разойтись — значит, нужен верификатор. Его делают либо через побитовое сравнение, либо через захват графа и проверку структурной эквивалентности. Если одна сторона содержит слияние операций, достаточно дать эталонную реализацию этого же слияния — своего рода обратный pattern matching.
Янг не утверждает, что этот подход подходит всем. PyTorch как эталонный язык — отличная исполнимая спецификация, и в конечном счёте важна лишь скорость получения экспериментальных результатов. Год назад Хорас Хи спрашивал: «Как сохранить контроль eager-режима и добавить удобства графовых абстракций?» Новый рецепт, где PyTorch держит центр, выглядит многообещающим ответом.