`pip install torch`が1行で完結する — Pythonパッケージングの長年の宿題、ついに解けるのか

 (talkpython.fm)
21 ポイント 投稿者 darjeeling 16 일 전 | 2件のコメント | WhatsAppで共有

NVIDIA・Astral・Quansight連合が打ち出した Wheel Next: CPU・GPUを問わない次世代パッケージング標準

出典: Talk Python To Me, Episode #544 |

背景: 2009年で止まってしまった車輪

pip install numpyを実行すると、どのバイナリがインストールされるのだろうか。あなたのCPUが最新のAMD Zen 4でも、Apple M4でも関係ない。インストールされるwheelは、2009年水準のx86-64命令セットだけを使うようにビルドされたものだ。

SSE4やAVX2のような最新のSIMD命令を使いたくても、インストーラーにはその機能がサポートされているかを知る手段がない。その結果、PyTorchのようなパッケージでは900MB近い巨大なバイナリファイルが生まれ、さらに「パズル本」のように複雑なインストールガイドページへとつながっている。

NVIDIA、Astral、Quansight連合は、この問題を解決するために Wheel Next イニシアチブを推進している。パッケージが必要なハードウェアを宣言し、uvのようなインストーラーが自動で正しいビルドを選べるようにする一連のPEPが、その中核だ。

ゲスト紹介

今回のエピソードには、3人の中心人物が参加した。

Jonathan Dekhtiar (NVIDIA) — CUDA技術に魅了されてPhDまで修了し、NVIDIAに入社したエンジニア。この2年あまり、CUDAとPythonの接点を改善する仕事に取り組んでおり、Wheel Nextイニシアチブの中核的な推進者でもある。

Ralf Gommers (Quansight) — 物理学博士出身で、2004年からPythonを使ってきた開発者。NumPyとSciPyのリリースマネージャーであり、現在は公益法人Quansightの共同CEOだ。ネイティブPythonパッケージングの問題を体系的に整理した PyPackaging Nativeガイド の著者でもある。

Charlie Marsh (Astral) — uv、ruff、tyを作ったAstralの創業者兼CEO。2022年10月の創業以来、Pythonエコシステムの速度とユーザー体験の改善に注力してきた。

核心的な問題: 「最小公倍数の罠」

x86-64向けwheelをビルドすると、2009年以前のCPU機能しか使えない。SSE4、AVX2など、その後に登場した命令は、インストーラーがその機能の有無を把握できないため、そもそも使えない。

2009年基準のハードウェア機能と、2019〜2023年基準の機能との性能差は、場合によって 10〜20倍 に達する。

ARMの状況も同じだ。現在のARM向けデフォルトのビルドターゲットは、実質的に Raspberry Pi 水準である。M4 Maxチップを搭載したMacBook Proでも、Raspberry Pi向けにビルドされたバイナリが動いているわけだ。

JetBrainsのPython開発者調査によれば、Python開発者の約 40〜50% がデータサイエンスや科学技術計算の分野に従事している。この巨大なコミュニティが、体系的に莫大な性能を無駄にしていることになる。

NumPyはどう耐えてきたのか

NumPyはこの問題を独自に解決してきた。同じソースコードをHaswell、Skylakeなど複数のCPUアーキテクチャ向けに 何度もコンパイル した後、1つのPython拡張モジュールにまとめる方式だ。ランタイムでCPUを検出し、最適なコードパスへディスパッチする。

Intelは長年にわたりエンジニアを派遣してx86コードパスを最適化してきたし、ARMも専任のNumPyメンテナーを置いている。そのおかげで性能は高いが、この方式は 少数の大規模プロジェクトしか負担できない規模 でもある。

SciPy、scikit-learn、Pandas、Pillowは、コード自体にはSIMD最適化が実装されているが、それをwheelに載せて配布する方法がないため、実際には配布できていない。

PyTorchの場合: 900MBの「パズル本」

PyPIに上がっているPyTorch wheelは約900MBに達する。5〜6個のGPUアーキテクチャ向けCUDAライブラリが1つのバイナリにまとめられているためだ。PyTorchチームは1GBを超えないようにするため、並々ならぬ努力を払っている。

特定のCUDAバージョンが必要なユーザーは、別のインデックスURLを自分で設定しなければならず、vLLMのようなパッケージのインストールページは「パズル本」のように複雑になっている。

Wheel Nextが完成するとどうなるのか。

uv pip install torch

これ1行で済む。インストーラーが自動でGPUを検出し、適切なCUDAバージョンを把握して、そのハードウェアに最適化された約200〜250MBのスリムなwheelをダウンロードする。Astralはすでに、uvのバリアント対応（variant-enabled）ブランチで動くプロトタイプを構築済みだ。

Wheel Nextの設計思想: 固定リストではなく拡張可能なシステム

現在の方式では、プラットフォームタグをファイル名にハードコードする。新しい要件が生まれるたびにタグを追加しなければならず、それを繰り返せば、結局は終わりのない保守負担になる。

Wheel Nextは違う。パッケージが任意のvariantメタデータを宣言でき、プラグインインターフェースを通じてインストーラーが動的にプラットフォーム属性を検出し、最適なwheelを選択する。CUDAの各バージョンごとにタグを付ける代わりに、汎用的で拡張可能なシステム を作ったのだ。

設計には、スーパーコンピュータ向けパッケージマネージャー Spack のarchspec、Conda-forge、Nix から着想を得ている。

PEPの現状

今回のイニシアチブに関連する主なPEPは次のとおり。

PEP タイトル 状態
PEP 817 Wheel Variants Beyond Platform Tags Draft
PEP 825 Wheel Variants Package Format Draft

PEP 817は、歴代で最も長いPEPという記録を打ち立てた。PEPエディターのレビューだけで1か月以上かかったほどだ。その後、管理しやすい単位に分割され、インストーラー・ビルドバックエンド・インデックスサーバーそれぞれについて議論が個別に進められている。

Python Build Standalone: 静かなレバー

Charlie Marshが触れた興味深い点が1つある。Astralは Python Build Standalone プロジェクトを保守している。uvでPythonをインストールするとき、実際にダウンロードされるのはまさにこのプロジェクトのビルドだ。

Astralの目標は、CPythonのソースコードを変更せず、ビルド最適化だけで最速のPythonディストリビューションをリリースすることだ。Charlieは、現時点で最速のPythonを持っていると考えているが、厳密なベンチマーク手法をまだ公開していないため、公式にはそう主張しないとしている。

多くの開発者がすでにuvでPythonをブートストラップしていることを考えると、Astralのビルド選択はPython性能に非常に大きな影響を与えうるレバーになる。

前例のない産業横断の協業

2025年3月、およそ20社の代表が一堂に会するオフラインサミットが開かれた。MetaのPyTorchチーム、GoogleのJAXチームが、それぞれの課題を発表した。

現在、Wheel Nextイニシアチブに貢献している企業およびオープンソースプロジェクトは次のとおり。

企業: NVIDIA、Astral、Quansight、Meta、AMD、Intel、Google、Red Hat、Anaconda、Huawei、Preferred Networksなど14社以上

オープンソースプロジェクト: NumPy、SciPy、PyTorch、scikit-learn、JAXなど

プロトタイピングの過程では、pip、warehouse（PyPI）、setuptools、scikit-build-core、packagingライブラリなど、Pythonパッケージングエコシステムのほぼすべての構成要素をforkして作業した。もちろん最終目標は、それらを再び統合することだ。

今後のスケジュール

Ralfの見立てでは、2026年いっぱいはPEPレビューとプロトタイプ更新が続き、その後PyPI、Twine、メタデータ消費ツール群が更新される見込みだ。エコシステム全体の準備が整うのは、2026年以降になりそうだ。

ただしJonathanは楽観的だ。標準が利用可能になった瞬間、ML・科学技術計算エコシステムでの採用は速いと見ている。中核パッケージがすでにWheel Nextワーキンググループに参加しているからだ。

重要用語の整理

用語 説明
Wheel Pythonパッケージの標準バイナリ配布フォーマット (.whl)
Wheel Variants PEP 817/825で提案されている拡張。同一パッケージの複数ビルドをハードウェア属性によって区別する
SIMD 単一命令で複数データを同時処理するCPU命令（SSE4、AVX2、ARM Neonなど）
Fat Binary 複数のハードウェアターゲット向けコンパイル済みコードを1つにまとめたバイナリ。NumPy、PyTorchが現在利用中
Platform Tags wheelファイル名にエンコードされたOS、アーキテクチャ、Pythonバージョン情報
Python Build Standalone Astralが保守する再配布可能なCPythonビルドプロジェクト
Variant Provider Plugin インストーラーがハードウェア属性（GPUドライバーバージョンなど）を動的に検出し、正しいwheel variantを選ぶためのインターフェース

まとめ

> 「理想を言えば、一般ユーザーはこのすべてを気にする必要がありません。uvやpipを通じて自動的に手に入るようになるべきです。」 — Charlie Marsh

Pythonのパッケージングシステムは、もっと単純だった時代に設計された。しかし、データサイエンス・AIワークロードが爆発的に増加した今、その設計は性能・帯域幅・ユーザー体験のすべてにおいてボトルネックになっている。

Wheel Nextは、競合企業（NVIDIA、AMD、Intel、Google、Meta）が同じテーブルに着き、PEPを共同で書き、共有インフラに投資するという珍しい事例だ。uvのプロトタイプは、すでに技術的な実現可能性を証明している。エコシステム全体が追随するには時間がかかるだろうが、その未来は十分に待つ価値がある。

関連リンク

この記事は Talk Python To Me Episode #544 の内容を翻訳・編集したものです。

関連記事

2件のコメント

 
darjeeling 16 일 전

Wheel Next には、幸いにも韓国企業であるLablupが参加しています。
https://wheelnext.dev/who_are_we/

そのほかのすべてのAI企業は、スポンサー、支援、参加のいずれも行っていません。
 
roxie 15 일 전

レベルアップ、すごいですね!!