Intel iGPU（Iris Xe、PyTorch公式のtorch.xpu非サポート対象）上で、PyTorchネイティブ実装のモデル（拡散/Flow Matching系TTS）を動かそうとしたところ、以下の症状が出た。 単純な行列積(matmul, float32)は正常動作（90ms/回程度） しかしtensor.sum(dim=N)等のreduction演算がlevel_zero backend failed with error: 45 (UR_RESULT_ERROR_INVALID_ARGUMENT)で確実にクラッシュする tensor[:, None, :].float()のようなインデクシング+dtype変換の組み合わせも同じエラーでクラッシュする 該当演算をCPUにroundtripしてから戻すモンキーパッチで個別には回避できるが、モデル内の別箇所で同種の新しいクラッシュが次々発生し「1つ直すと次が出る」状態 さらに別条件下では、エラーも出さずにGPU使用率0%のまま無限にハングする現象も確認（straceでメインスレッドがsched_yield()を無限スピン） この状況で、「未サポートiGPU上でPyTorchモデルを個別演算パッチで動かし続ける」ことに見切りをつけるべき技術的な判断基準は何か。また、モグラ叩きを続ける以外に、この特定の症状（reduction/indexing系カーネルの欠落 + 同期プリミティブのハング）に対して有効な対処法はあるか。

GPT-5.6 Sol

Answer: 基本reductionの確定的失敗と、捕捉不能な同期ハングが一度でも再現した時点で撤退基準は満たされており、モデルへの個別パッチは打ち切って、短時間のスタック整合性検証後にOpenVINOなどIris Xe対応ランタイム、CPU実行、または公式対応GPUへ移行すべきです。

他モデルの回答は、私の結論を変えるものではなく、特に「失敗集合を列挙できない」「CPU往復後に性能上の利益が残らない」「fail-stopしないハング」という三つの判定軸は、撤退判断をより明確にする有用な整理です。 matmulの成功はバックエンドの健全性を保証しません。matmulはoneDNN等の別実装を通り得る一方、reduction、strided indexing、cast、イベント同期は別のATen/SYCL/URカーネル経路です。最小のsumまで落ちるなら、問題はモデル固有の演算一個ではなく、モデルが頻繁に使う演算クラスのカバレッジ不足です。 なお、error 45だけから「work-groupサイズまたはSLM上限超過」と断定することはできません。不正なカーネル引数、unsupportedなsub-group条件、ランタイム／ドライバのABI不整合などでもUR_RESULT_ERROR_INVALID_ARGUMENTになり得ます。原因の確定にはUR・Level Zeroのトレースが必要ですが、原因を確定できなくても、サポート外デバイスで基本演算と同期が壊れているという撤退判断自体は変わりません。 実務上の打ち切り基準は次のとおりです。 ・小さなcontiguousテンソルでもsum等が再現率100%で失敗する。 ・castの分離、contiguous化、形状変更でも演算カテゴリ全体の失敗が残る。 ・新しい失敗箇所の発見速度が修正速度以上で、失敗集合を事前列挙できない。 ・エラーを返さない無期限ハング、または数値一致を保証できない挙動がある。 ・CPU roundtripによる同期と転送を含めたE2E速度が、最適化CPU実行を上回らない。 ・公式サポート、回帰テスト、修正見込みのいずれもない。 特に無期限ハングは単独でも強い撤退条件です。例外時CPUフォールバックは、非同期キューやイベント待ちで止まる故障を捕捉できません。TorchDispatch等で全演算をtry/catchする方式も、ハングや非同期に遅延したエラーには対応できず、恒久策にはなりません。 ただし移行前に、時間を限定した診断を一度だけ行う価値はあります。最小再現コードを作り、PyTorch XPUビルド、Intel compute-runtime、Level Zero loader、Unified Runtime、oneAPI関連ライブラリの版と実際にロードされた共有ライブラリを確認します。公式に想定された組み合わせへ揃え、LD_LIBRARY_PATH等による新旧ライブラリ混在を排除します。同期起動、UR/L0トレース、immediate command-list設定の切り替えは、ハング箇所の特定や既知のランタイム不具合の回避に役立つ可能性があります。OpenCLバックエンドへの切り替えは、そのtorch.xpuビルドが当該経路を実際に提供する場合に限る診断候補であり、一般に利用可能とは仮定すべきではありません。これらは例えば半日以内と期限を決め、最小のsumが完全に通らなければ終了します。 恒久策の優先順位は、①OpenVINO GPUへ変換可能なdenoiser／DiT／ボコーダー等の大きな部分を載せ、反復ループをホスト側に残す、②モデル全体をOpenVINO CPUやPyTorch CPUで最適化する、③変換困難なら大きなサブグラフ単位でCPUに固定してデバイス境界を最小化する、④torch.xpuが必須なら公式対応GPUへ交換する、です。WindowsではDirectMLも比較候補になります。 結論として、ここで必要なのは個々のクラッシュをさらに塞ぐことではなく、対応済み実行基盤へ境界を引き直すことです。今回の症状は、性能調整の問題ではなく、実行の正当性と終了性を保証できないプラットフォーム問題です。

Claude Fable 5

Answer: 障害がLevel Zeroランタイム層で演算カテゴリ横断的に発生し、かつfail-stopしないハングまで確認された時点で個別パッチは原理的に完遂不可能であり、見切り基準は「失敗集合の開集合性」「サイレント障害の有無」「CPU roundtrip込みの期待性能がCPU単体を上回るか」の3点、有効な対処はONEAPI_DEVICE_SELECTOR=opencl:gpuでのバックエンド切替という低コスト実験を挟んだ上で、本命はOpenVINO（Iris Xe公式サポート）への移行または最適化済みCPU実行への割り切りである。

3モデルの結論はほぼ完全に収束しました。「matmulはoneDNN経路だから動くが、reduction/indexing系はATen-XPUのSYCLカーネルでIris Xe（Xe-LP）のケイパビリティで検証されておらず、error 45はwork-group/SLMパラメータのデバイス不一致」「失敗は演算単位ではなく演算クラス単位で、モグラ叩きは構造的に収束しない」「sched_yield()スピンのハングは、エラーを返さない故障モードとして単独で撤退基準を満たす」——この診断と判断基準に異論は出ておらず、私の立場を維持します。 その上で、他モデルの回答から採り入れるべき実務的な精緻化が2点ありました。 第一に、Kimi K3が挙げたONEAPI_DEVICE_SELECTOR=opencl:gpuによるSYCLバックエンドのLevel Zero→OpenCL切り替えは、私の前回回答（immediate command listsの切り替え）より筋の良い分単位の実験です。error 45がL0のzeKernelLaunch/setArg層固有の問題である場合、OpenCLパスで消える実績があり、移行判断の前に試す価値があります。ただしこれは診断的価値が主であり、通っても「非サポートデバイスで未検証パスを踏み続ける」構造は変わらないため、恒久解とはみなすべきではありません。 第二に、GPT-5.6 Solの「GPU処理を別プロセスに隔離しタイムアウト監視で強制終了」は、ハングという非fail-stop障害に対する唯一の実務的防御であり、移行までの暫定運用や実験フェーズで必須の構えです。同様にKimiのTorchDispatchModeによる一括CPUフォールバックshimも、個別モンキーパッチを一般化した安全網として実験用途では有効ですが、両者ともハングと無言の誤計算を根本的には防げない点で、撤退基準の判定を変えるものではありません。 改めて見切りの判断基準を統合すると：(1) 障害レイヤー——Pythonから修正可能な層より下（UR/L0）で壊れている、(2) 障害の横断性——reduction・indexing+cast・同期の3系統以上で発生＝デバイスケイパビリティ不一致確定、(3) fail-stop性の喪失——エラーなしハングの確認は監視・リトライ設計を不可能にし、単独で撤退十分条件、(4) 経済性——patch-to-progress比が収束せず、roundtrip込みE2E性能がCPU単体を下回るならGPU化の目的自体が消滅。本件は4つすべてを満たしています。 対処の優先順位：(a) 30分以内——opencl:gpu切替とドライバ/ランタイムのバージョン整合確認（直れば儲けもの、直らなければ確証）、(b) 本命——openvino.convert_modelまたはONNX経由でdenoiser本体をOpenVINO GPU pluginに載せ、Flow MatchingのstepループはPython側に残す構成、(c) 並行評価——AVX-512/BF16対応CPUならIPEX-CPU/OpenVINO-CPU+量子化でバッチ1のTTSは実用圏に入ることが多い、(d) Kimiの指摘通り、torch.xpuネイティブが本当に必要なら公式サポート対象のArc A310等を調達する方がエンジニアリング工数より圧倒的に安いという経済判断も、サンクコスト回避のため明示的に選択肢に含めるべきです。

Final Summary

the AI Roundtable は、未サポートのIntel iGPU上で個別パッチをあて続ける運用は構造的に破綻しており直ちに断念すべきという結論で全会一致しました。Claude Fable 5、GPT-5.6 Sol、Kimi K3 の3モデルは、Level Zeroランタイム層での演算クラス横断エラーと無期限ハングの発生を絶対的な撤退基準として挙げました。各モデルは環境変数を用いたわずかな診断テストを除き、モグラ叩きを打ち切ってIris Xeを公式サポートするOpenVINOへの移行かCPU最適化実行を選択するよう一致して勧告しています。

All 3 models agreed