カーネル最適化は長年、GPUプログラミングの深い知識を持つ一握りの専門家が支配してきた領域だ。NVIDIAのCUDAでAttentionカーネルを書けば数千行に及び、2019年にOpenAIが発表したTritonで約120行まで圧縮されても、手動チューニングの壁はほとんど変わらなかった。Metaが開発したPython DSL（ドメイン固有言語）「Helion」は、同じカーネルを約30行で記述し、チューニング作業まで自動化する。2026年4月7日、パリで開催されたPyTorch Conference EUにてHelionはPyTorch Foundationの公式プロジェクトに採択された——DeepSpeed・PyTorch・Ray・vLLMに続く5番目のfoundation-hosted projectとして。この採択はAIカーネル開発のアクセシビリティとポータビリティをオープンスタックの標準として担保しようという産業界の意志表明だ。
オートチューニングが生み出すTriton比6.22倍の正体
Helionの核心はオートチューニング機構にある。開発者が単一のカーネル定義を記述すると、Helionはそこから数千のTriton設定候補を自動生成し、実際のハードウェア上で評価する。典型的なセッションでは586秒間に1,520の設定を探索し、対象環境に最適な実装を選択する。
NVIDIA B200上でのベンチマーク結果がその効果を数値で示している。全体的にはEager実行比3.27倍・torch.compile比1.21倍・手書きTritonカーネル比1.85倍の速度を達成した。特定のjsdカーネルではTriton比6.22倍という数値が計測されているが、これはケース依存の最大値だ。AMD MI350X上でのgeomean（幾何平均）は2.37倍（torch.compile比1.05倍、Triton比1.44倍）で、ワークロードとハードウェアによって差が生じる。
経験豊富なエンジニアでも、タイルサイズ・ループ順序・メモリアクセスパターンの組み合わせを手作業で全探索するのは不可能に近い。実行可能な選択肢が数千を超えた時点で、人間のチューニングは必然的に経験則による近似になる。Helionのオートチューナーはその制約を持たず、ハードウェアの特性に応じて最適解を機械的に収束させる。Matt White（Linux Foundation、Global CTO of AI）が「数百の候補実装にわたるオートチューニングを含む、カーネル記述へのより生産的な経路」と表現したのはこのメカニズムを指している。
30行で書けるAttentionカーネルが示すDSL設計の論理
CUDA数千行→Triton約120行→Helion約30行という圧縮の系列は、抽象化の層をどこに置くかという設計上の選択の積み重ねだ。どの詳細をフレームワークに隠蔽し、どの詳細を開発者に露出するかの判断が、最終的なコード量に直接表れる。
HelionはTritonの上位に位置する抽象化層として設計されており、TritonだけでなくTileIR等の複数バックエンドにコンパイルできる。開発者はタイル分割やメモリ階層の詳細を直接制御するのではなく、計算の意図をPythonの自然な構文で記述し、最適化の判断をHelionとオートチューナーに委ねる。Jana van Greunen（Meta、Director of PyTorch Engineering）が「より簡潔で、ポータブルで、すべての開発者がアクセスできる」と説明した方向性はここに集約される。
副次効果として、コードの保守性が大幅に向上する。120行のTritonカーネルに対してアーキテクチャの変更を適用するのと、30行のHelionカーネルに変更を加えるのでは、レビューコストも修正リスクも桁違いだ。新しいGPUアーキテクチャへの追従が組織的な負債になりやすい現在の環境では、この差異は無視できない。また、Helionは計算カーネルの記述に集中できるため、フレームワーク統合のためのボイラープレートも大幅に削減される。
NVIDIA・AMD・Blackwellへの対応が解く「ベンダーロックイン」の呪縛
CUDAで書かれたカーネルはNVIDIA GPU専用であり、AMDへの移行やクラウドベンダー間の移植には相応のコストが生じる。AWS Trainium・Google TPU・各社スタートアップが台頭し、アクセラレータ選択肢が増えた今も、このポータビリティの壁が組織の意思決定を縛り続けている。Helionがハードウェアポータビリティを設計の中心に据えた背景には、この現実がある。
HelionはNVIDIA CUDA対応GPU・AMD GPU・Blackwellアーキテクチャへの対応を実装しており、Hopper以降のTMA（Tensor Memory Accelerator）も利用可能とされる（公式GitHubリポジトリによる）。単一のHelionカーネルから各バックエンド向けの最適実装が生成されるアーキテクチャは、ハードウェア選択の自由度を実質的に拡大する。モデルの推論コストとクラウドベンダー交渉力が直接連動する規模の組織にとって、これは経済的なインパクトを持つ変化だ。
CUDAエコシステムの優位性は技術的な性能だけでなく、それを前提として積み上げられてきたツール・知識・人材のロックインにも依存してきた。Helionのような抽象化層が普及することで、その前提の一部が崩れ始める。AMD MI350Xでのgeomean 2.37倍という数値は、ベンダー最適化の恩恵をオープンなオートチューニング機構が部分的に引き受けられることを裏づけている。
PyTorch Foundation採択が示す「標準化」の政治的意味
Helionが5番目のfoundation-hosted projectになったことは、PyTorch Foundationの戦略的な拡張を読み解く手がかりになる。DeepSpeed（分散学習）・Ray（分散処理）・vLLM（推論サービング）に続く採択パターンを見ると、Foundationがカバーしようとしている範囲が学習の周辺からインフラ全体に広がっていることがわかる。
Mark Collier氏（PyTorch Foundation、Executive Director）が「本番グレードのAIを形成し推進するための不可欠な追加」と表現したことは、カーネル最適化レイヤーまで含めたオープンスタックの完全性を整備しようという意図を示している。HelionがFoundation管理下に置かれることで、特定の企業の製品ロードマップに左右されない中立的なガバナンスが担保される。これはMetaが技術的優位性を保ちつつも、エコシステムの発展を業界全体に開放するという選択でもある。
同日、ExecuTorch（エッジAI推論フレームワーク）がPyTorch Core統合を発表したことで、サーバーでの学習・推論からエッジデバイスへの展開まで、PyTorchの管理下で最適化された実行環境が連続してつながった。AIの競争軸が学習コストから推論コストへ移る中、Foundation管理のカーネルDSLとエッジ推論フレームワークが揃ったことは、次の標準化争いにおける先手となる。
Sources