AI・機械学習
PyTorch: リファレンス言語
PyTorch: A Reference Language (docs.pytorch.org)
要約
この記事では、PyTorchが「リファレンス言語」と「実装言語」という二重の役割を担っていると論じています。通常、リファレンス実装は本番環境にデプロイされませんが、PyTorchはパフォーマンスと明瞭さのバランスを取り、研究と本番の両方で使用されることがあります。カーネルDSLやAIコーディングエージェントの台頭により、PyTorchは最適化された実装の正確性を検証するための基準として、より重要になると述べています。
全文翻訳
PyTorch: リファレンス言語
Edward Z. Yang (@ezyang) · 2026年7月25日 · 4分読書
compiler
torch.compile
autograd
verification
llm
リファレンス実装とは、明瞭さのためにパフォーマンスを犠牲にした、簡略化された完全なシステムのバージョンです。リファレンス「言語」とは、これらの実装が切り取られるAPIと規約の構造であると言えるでしょう。一見すると、PyTorchは明らかにリファレンス言語です。結局のところ、現代のディープラーニングの共通言語として一般的に呼ばれています。しかし、よく見ると混乱があります。
リファレンス実装は通常、本番環境にデプロイされません。しかし、私はPyTorchでトレーニングジョブを実行しています!
誰もがカーネルDSLでカーネルを書いています。PyTorchが単にカーネルをまとめているだけなら、その役割は何でしょうか?
AIコーディングは最終的に、あらゆるスタックをゼロから書き直すことを意味するでしょう。PyTorchで書かれていることがなぜ重要なのでしょうか?
ですから、私にとって最近、異常に明確な視点は、PyTorchがリファレンス言語と実装言語の両方という二重の役割を担っていると考えることです。スケールがそれほど大きくない場合や、コンパイラがうまく機能している場合、リファレンス実装は本番環境に投入される可能性があります。しかし、ますます、リファレンス実装を実際のプロダクション実装から切り離されたソフトウェアアーティファクトと見なし、それによってプロダクション実装の正確性を検証できるようになることが、より自然になると私は考えています。研究するための1つの実装、スケールするための1つの実装、そして暗闇の中でそれらを束ねるための1つの検証器です。
カーネルDSLの現代的な使用法は、このことを最も明確に示しています。伝統的な、コンパイラ最大主義的な見解は、エンドユーザーは高レベルAPI(例えば、Numpy/PyTorchスタイルのAPI)を使用してニューラルネットワークモジュールの実装を書くべきであり、コンパイラがそれを最適化された形式にコンパイルする方法を決定すると主張します。しかし、行列乗算やアテンションのような最も重要な操作では、コンパイラが最高のパフォーマンスを保証することは容易ではありません。カーネルDSLの普及により、タイリングやデータ移動を明示的に記述することで、人々が最適なパフォーマンスを達成することが劇的に容易になりました。これは高レベルAPIを排除するのでしょうか?通常はそうではありません。プレーンなPyTorchでリファレンス実装を持つことは非常に便利であり、ほとんどのカーネル著者は最適化されたカーネルと並行してリファレンス実装を維持し、数値テストで正確性を検証します。
カーネルDSLがオペレーターの本番実装の書き方を変えたのと同じように、コーディングエージェントがトレーニングステップの本番実装の書き方を変えるだろうと私は考えています。伝統的に、我々は自動微分(autograd)をPyTorchの価値提案の中核部分と考えてきました。なぜなら、それは正確な導関数が得られることを保証するからです。しかし、スケールが大きくなると、暗黙的なバックワードグラフは首かせになります。計算の大部分は隠されており、通常のデバッグツールで操作したり、フォージョンを適用したりする機会がありません。コンパイラを使用すると、例えばパターンマッチングでバックワードグラフを変更することは可能ですが、これは壊れやすく、リファレンス実装から手書きカーネルへの呼び出しを切り替えるよりも悪い体験です。これは新しい観察ではありません。現在廃止されているTangentライブラリは、ソース・ツー・ソース自動微分の有用性という命題に基づいて構築されていました。
新しいレシピは次のようになります。リファレンス実装として、従来のPyTorchの自動微分フレンドリーなコードを維持します。LLMを使用して、コードの明示的なフォワード・バックワードバージョンを生成し、それをリファレンス実装とは別に最適化できるようにします。パターンマッチングとは異なり、最適化が適用されないことを心配する必要は決してありません。コストは、リファレンスと実際の С実装が乖離する可能性があることです。それらが等価であることを示す検証器が必要です。この検証器は、ビット単位の等価性テストとして、または翻訳検証の伝統に則ったグラフキャプチャと構造的等価性として簡単に実装できます。片方がフォージョンを持っていてもう片方が持っていない場合に検証器が機能することを確認するには、フォージョンのリファレンス実装(言い換えれば、逆パターンマッチ)を提供する必要があります。
私はこのレシピがすべての人に適していると主張するつもりはありません。PyTorch、リファレンス言語は、かなり優れた実行可能な仕様であり、結局のところ最も重要なのは、必要な実験結果をどれだけ早く得られるかということです。しかし、最近、PyTorchがフロンティアトレーニングで優れていること、特にスケーリングが続く中でPyTorchが自己破壊する必要があるかどうかについて多くの時間を費やしてきたので、この視点が古きものと新しきものを橋渡しするのに役立つと感じています。Horace Heが昨年提起した未解決の質問は、「グラフレベルの抽象化の利便性を持ちながら、イージモード実行のすべての制御をどのように得られるか?」というものでした。私はこのレシピがかなり有望な答えであり、PyTorchがその中心であり続けると考えています。