PyTorch как эталонный язык: разделение спецификации и реализации

Эдвард Ян (@ezyang), один из разработчиков PyTorch, в заметке для DevLog размышляет о том, чем на самом деле является PyTorch в эпоху компиляторов, kernel-DSL и кодовых ИИ-агентов. Его отправная точка — понятие эталонной реализации: упрощённой, но полной версии системы, которая жертвует производительностью ради ясности. Тогда «эталонный язык» — это ткань из API и соглашений, из которой такие реализации выкраиваются.

PyTorch привычно называют lingua franca глубокого обучения, но, замечает автор, тут есть путаница. Эталонные реализации обычно не отправляют в продакшн — а на PyTorch люди ведут реальное обучение. Ядра всё чаще пишут на специализированных DSL — какова тогда роль фреймворка, если он лишь склеивает эти ядра? И если ИI рано или поздно позволит переписать любой стек с нуля, почему вообще важно, что код написан именно на PyTorch?

Одна реализация чтобы исследовать, другая — чтобы масштабировать

Ян предлагает видеть в PyTorch двойную роль: и эталонного языка, и языка реализации. Пока масштаб невелик или компилятор справляется, эталонная реализация может уходить прямо в продакшн. Но всё естественнее, считает он, воспринимать её как отдельный артефакт, по которому проверяется корректность боевой реализации. Перефразируя Толкина: одна реализация — чтобы исследовать, другая — чтобы масштабировать, и один верификатор, чтобы их связать.

Самый ясный пример — kernel-DSL. Компиляторный максимализм предполагал, что пользователь пишет модули на высокоуровневом API, а компилятор сам всё оптимизирует. Но для ключевых операций вроде перемножения матриц и внимания добиться пиковой производительности компилятору трудно, и авторы ядер вручную прописывают тайлинг и перемещение данных. При этом высокоуровневый API не исчезает: рядом с оптимизированным ядром держат эталонную реализацию на «обычном» PyTorch и сверяют результаты численными тестами.

Кодовые агенты и обратный проход

Автор переносит ту же логику на шаги обучения. Автоград — гордость PyTorch, гарантирующая верные производные, но на больших масштабах неявный обратный граф превращается в обузу: львиная доля вычислений спрятана, её не потрогать привычными отладчиками. Новый рецепт: оставить autograd-код как эталон, а с помощью LLM генерировать явную forward-backward версию, которую можно оптимизировать отдельно. В отличие от сопоставления с образцом, оптимизация никогда «не отвалится». Плата за это — возможное расхождение эталона и боевого кода, поэтому нужен верификатор: побитовое сравнение либо структурная эквивалентность графов в духе translation validation.

Ян не утверждает, что рецепт подходит всем: PyTorch как эталонный язык оказался неплохой исполняемой спецификацией, а в итоге важна лишь скорость получения нужных экспериментальных результатов. Но эта оптика, по его мнению, отвечает на давний вопрос Хораса Хэ — как получить весь контроль eager-режима вместе с удобствами графовых абстракций.

Источник: Lobsters