新素材のナノスケールイメージングのための加速 X 線解析 (XANI)

大規模 X 線自由電子レーザー（XFEL）は、核融合材料、半導体、電池、触媒などを含む新規システムにおける構造および電子ダイナミクスの追跡を可能にし、原子や電子の動きを記録する超短パルス X 線を生成します。これらの装置は、欠陥やその他の影響によって生じる材料構造の最小の変化も検出できます。これらの明るい X 線バーストの高い反復周波数は、3500 万画素カメラを用いて毎秒最大 100 万ショットに達する可能性があります。 取得された多次元データセットには、電子や原子の最速の微視的運動に関する豊富な物理情報が含まれており、材料中の欠陥を特定するのに役立ちます。しかし、これらのデータセットから物理学を抽出して処理・分析するには、従来では 9 ヶ月以上の計算時間が必要でした。 XFEL 研究施設には、スイスの [SwissFEL](https://www.psi.ch/en/swissfel)、日本の Spring-8 Angstrom Compact free-electron Laser ([SACLA](https://www.riken.jp/en/collab/resources/sacla/))、SLAC の Linac Coherent Light Source ([LCLS-II](https://lcls.slac.stanford.edu/lcls-ii))、ドイツの [European XFEL](https://www.xfel.eu/)、韓国の Pohang Accelerator Laboratory ([PAL](https://lightsources.org/lightsources-of-the-world/asia-oceania/pohang-accelerator-laboratory-x-ray-free-electron-laser-pal-xfel/)) があります。 本記事では、ナノスケールイメージングのための加速 X 線解析（XANI）ワークフローにおける新たな技術的ブレークスルーについて取り上げます。NVIDIA チームは、量子材料の特性評価において、超高速フェムト秒レーザーポンプ/硬 X 線プローブ実験からフォノン分散を再構築する実証を行いました。 具体的には、チームは XANI ワークフローを加速し、取得したデータの精度を維持しつつ、42 テラバイト（TB）のデータを処理・分析するための計算時間を、32 台の [NVIDIA GB200 Grace Blackwell Superchips](https://docs.nvidia.com/multi-node-nvlink-systems/multi-node-tuning-guide/overview.html) で従来の 9 ヶ月から 4 時間未満に短縮しました。XANI プロジェクトは、量子物理学から材料化学に至るまで多様なコミュニティで採用されており、[CUDA Python](https://github.com/nvidia/cuda-python?tab=readme-ov-file#readme) と分散コンピューティングが科学発見を加速する能力を実証しています。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/x-ray-free-electron-laser-interaction-with-material-data.webp)*図 1. 3 キロメートルの直線加速器を用いた超高速微小運動の実時間ムービー* ## エクサスケール科学における単一ノード Python の課題とは？ 大規模 XFEL（自由電子レーザー）施設は、メガヘルツ (MHz) のレートで動作し、数百テラバイトからペタバイト (PBs) に及ぶデータを生成します。この膨大な量のデータは、科学実験を誘導し発見を加速するためにリアルタイムで処理・分析されなければなりません。 従来の CPU 依存型パイプラインでは、手動によるパラメータ調整やサンプリング削減が不可欠であり、実験中にデータセットのわずか 10% しか処理できないことが一般的です。量子材料における新相の高解像度イメージングにおいては、非線形フィッティングと 3D 再構成の計算コストが非常に高く、従来は分析が実験後の段階に持ち越されていました。単一の実験で計算に 9 ヶ月を要することさえありました。 ## XANI はどのようにして数値計算および I/O パフォーマンスを加速するのか？ もともとベクトル化された NumPy および SciPy から、NVIDIA チームは GB200 Grace Blackwell Superchip 上の単一 GPU で XANI ワークフローを 43 倍に、64 個の GPU を用いた環境では 1,000 倍に加速しました。その結果、42 TB のデータを処理・分析する計算時間が 4 時間未満に短縮されつつも、取得データの精度は維持されています。 この改善を実現するために、LMFIT や [multithreaded Hierarchical Data Format 5 (HDF5)](https://github.com/qkoziol/hdf5/tree/ts_funcwrap_1) を含む、新しい [cuPyNumeric](https://github.com/nv-legate/cupynumeric) ライブラリが開発されました。これらのライブラリは、数値計算における GPU の利用率をさらに向上させるとともに、[GPUDirect Storage (GDS)](https://docs.nvidia.com/gpudirect-storage/) とマルチスレッド対応の HDF5 を活用することで、I/O スループットにおいて 165 倍の加速を実現します。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/line-graph-xani-code-performance-comparison.webp)*Figure 2. XANI code performance shows strong scaling results on x86 CPUs compared to GPUs on GB200 Grace Blackwell Superchips * ## XANI アーキテクチャのメリットとは？ XANI は、cuPyNumeric を用いて CPU が主導するワークフローから GPU 中心の分散モデルへの移行を容易にします。このアプローチにより、高解像度 X 線材料特性評価における解決までの時間を最小化することで、ライブフィードバックと実験の自動制御を実現します。Figure 2 は XANI ワークフローのオーケストレーションを示しています。新しい非線形最小二乗法による最小化および曲線 fitting ベースの実装は、物理的に根拠のある減衰コサインモデルの最小二乗残差を直接最小化し、より低いフィット残差とピクセルごとの周波数微調整をもたらします。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/xani-workflow-orchestration.webp)*図 3. XANI ワークフローのオーケストレーションと対話型インターフェースにより、適合誤差が低減し、ピクセルごとの周波数補正が可能になる* ## GPUDirect Storage を用いた複雑な多次元データの高スループット I/O XANI アプリケーションは、HDF5 形式でデータを保存およびアクセスします。cuPyNumeric は、HDF5 データセットをメモリに読み込み、多数の GPU で実行される並列タスク間でデータを分散する機能をサポートしています。最新の GPU と高性能な Lustre ストレージシステムにおける広範な実験を通じて、ピーク I/O 性能を実現するために 3 つの重要な最適化が実施されました。それらは GDS（GPUDirect Storage）、マルチスレッド対応 HDF5、およびデータレイアウトです（詳細は後述）。 最大で 165 倍の高速化を達成しました。具体的には、1 ノードと 2 基の GB200 Grace Blackwell Superchips で 76 GB/秒、16 ノードと 32 基の GB200 Grace Blackwell Superchips で 700 GB/秒です。 例： ```python from legate.io.hdf5 import from_file data = from_file("/path/to/file.h5", "dataset_name") ``` 図4は、GDS対応クラスタにおける最適化結果と、同様のストレージ帯域を持つ非 GDS クラスタからの初期ベースラインを比較しています。読み取りスループットは 16 ノードにわたってスケーリングされ、2 つのクラスタ構成で評価されています：1 つ目は GDS を使用した最適化されたアクセラレーテッドコンピューティング設定（GB200 Grace Blackwell Superchips を 2 基、HBM3e を 186 GB、ストレージ用 NIC を 200 Gb/s で 4 本、計算用 NIC を 400 Gb/s で 4 本、RAM を 480 GB を 2 基搭載）、もう一つはベースラインとなる NVIDIA H100 設定（NVIDIA H100 80 GB GPU を 8 基、RAM を 2 TB、ストレージ用 NIC を 400 Gb/s で 2 本搭載し、GDS は使用しない）です。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/accelerated-i-o-throughput-gpudirect-storage-multithreaded-hdf5.webp)*図4。** **GPUDirect Storage とマルチスレッド HDF5 を用いたアクセラレーテッド I/O スループット。2 つのクラスタ構成における 16 ノードでの読み取りスループットのスケール* ## GDS GDS は、ホスト CPU やメモリを経由せずにデータを GPU に直接読み込むことを可能にする新しいストレージ技術を提供します。HDF5 は vfd-gds プラグインを通じて GDS をサポートしており、このプラグインは [GDS cuFile](https://docs.nvidia.com/gpudirect-storage/api-reference-guide/index.html) ライブラリを使用して、データをホストを経由せずに直接 GPU メモリに読み込みます。これにより、ホストメモリを介したデータのステージングや、別々のデバイスコピーを発行するオーバーヘッドが排除されます。GDS は、CPU ホストを経由する従来の POSIX 読み取りと比較して、一貫して高いスループットを示します。 現代のクラスター上で GDS を完全に活用するには、より高い読み取り並列性を有効にするために cuFile 設定パラメータを調整する必要があります。デフォルトの cuFile 設定は往々にして保守的であり、高性能な Lustre ファイルシステムを対象とする場合、利用可能な帯域幅の多くが未活用となっています。 ## マルチスレッド対応 HDF5 現時点において、HDF5 ライブラリはまだシングルスレッドです。アプリケーションが複数のスレッドから並列読み取り呼び出しを発行すると、ライブラリ内部でそれらが直列化されます。具体的には以下の通りです。 - cuFile は単一の HDF5 読み取りを複数のサブ要求に分割しますが、一度にアクティブになるのは 1 つの HDF5 読み取りのみであり、これが実効的な I/O 並行性を著しく制限します。 - その結果生じる直列化された読み取りストリームは、通常、数百 GB/s を維持できる高性能な Lustre ファイルシステムを飽和させるには不十分です。 このボトルネックに対処するため、私たちは HDF5 に対するマルチスレッド対応機能を開発し、cuPyNumeric と統合しました。この機能は現在、公開されているブランチで利用可能であり、HDF5 メインブランチへのマージに向けて積極的に準備が進められています。 ## データレイアウト データは、ディスク上の HDF5 レイアウトと整合性のある方法で読み取る必要があります。この整合性が欠如すると、多次元を持つデータセットにおいて読み取りが小規模かつ非連続なものとなり、スループットが著しく低下します。 cuPyNumeric は、最も変化の少ない次元に沿ってデータをタイル状に並べるように改善され、標準的な HDF5 データレイアウトを考慮した効率的な多次元読み込みが可能になりました。これには連続型、チャンク型、および仮想データセット（VDS）が含まれます。私たちは、より高い並列読み込みを実現するために、多くのソースファイルを持つ VDS データレイアウトの使用を選択しました。また、最適化された読み込みを妨げない形でディスク上のデータレイアウトを維持することも重要です。 ## cuPyNumeric を用いた分散計算 cuPyNumeric は、クラスターの集約メモリに配列を分割することで XANI の分散エンジンとして機能します。NumPy および SciPy API を提供するだけでなく、NumPy ベースのアプリケーションの大規模な分散処理のためのライブラリとしても機能します。 この設計により、高レベルのパイプラインコードはシンプルに保たれ、単一の関数呼び出しで数百の手動タスク提出が置き換えられる一方で、cuPyNumeric は GPU 間での自動スケジューリングと負荷分散のためにデータ依存関係について完全な可視性を獲得します。 ## 分散分割 import を numpy から cupynumeric に更新することで、ランタイムはプロアクティブにタスク依存グラフを構築し、ノード間で操作を並列化します。このライブラリは NumPy の呼び出しをタスクに変換し、データ移動とカーネル実行を非同期で処理します。計算ワークフローの詳細は以下のセクションに記載されており、暗黙的な並列性、データの分割、およびタスクのオーバーラップが含まれます（図 4）。 import cupynumeric as np from legate.io.hdf5 import from_file raw_frames = num.array(from_file("lcls_detector_data.h5", 'r')) intensity_map = np.sum(raw_frames, axis=0) ## 明示的な並列化：特殊なカーネル向けの tiled_task XANI パイプラインにおいて、信号検出には各検出器ピクセルに減衰振動をフィッティングする必要がある—a 非線形最小二乗問題である。私たちは逐次的な SciPy ベースのソルバーを置き換え、Levenberg-Marquardt (LM) アルゴリズム（レベンバーグ・マルカート法）を GPU 上で完全に実行し、タイル内のすべてのピクセルを単一のバッチ処理で同時にフィッティングするバッチ化された GPU 実装（JAXfit）を導入した。 これを cuPyNumeric と統合するには、tiled_task API を使用する。この API は利用可能な GPU に対して大規模な検出器配列を自動的に分割し、空間的なタイルごとに 1 つの GPU タスクをディスパッチする。各タスクは、検出器データのそのスライスをネイティブな CuPy アレイとして受け取る—明示的なデータ移動や手動のスキャッター/ギャザーは不要である。時間遅延軸はすべてのタイルにブロードキャストされる一方、空間的（高さ×幅）次元は分割される： @tiled_task(partitioned_dims=("i", "j"), primary_array="onn") def roi_task_cp( delay: Input(cupy.ndarray, partitioning=None), onn: Input( cupy.ndarray, partitioning=(None, "i", "j"), tile_dims=(None, 16, 16) ), amp_out: Output( cupy.ndarray, partitioning=("i", "j", None), tile_dims=(16, 16, None) ), ... ): fits, _, freq_lis, amp_lis, ... = jaxfit_linearpred( onn, delay, amp_threshold, ... ) roi_task_cp( onn=detector_on, delay=delay_axis, amp_out=amp_all, tile_shape=(16, 16) )Figure 5 は、暗黙的なデータ分割と通信に基づく**cuPyNumeric**の分散実行フローを示しています。データは非同期で NVMe/Lustre ストレージから GPU 固有のシャードに読み込まれます。その後、GPU を跨ぐデータ転送を伴う np.sum 集約処理が行われ、最終結果がすべてのノードへブロードキャストされます。なお、このプロセス全体を通じて、元のシャードデータは各 GPU 上に残存し、アクセス可能である点にご注意ください。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/image3-1.webp)*Figure 5.** **cuPyNumeric** **暗黙的なデータ分割と通信に基づく分散実行フロー* ## 材料データの処理および分析における XANI ワークフローのパフォーマンスと結果 [NVIDIA GB200 NVL72](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) クラスター上の分散 Python HPC スタックへの移行は、X 線科学のデータ計算規模を変革し、材料特性モデルの AI 学習のための大規模データセットの準備を可能にしました。主な技術的インパクトには、計算速度の向上、システムの拡張性、および I/O スループットの最適化が含まれます。 ## 計算速度の向上 32 個の NVIDIA GB200 Grace Blackwell Superchips を用いることで、処理時間を 1,000 倍短縮（6 ヶ月から 4 時間未満）することが可能になりました。この新しいバッチ処理 GPU 実装は、[大規模研究施設における科学実験をリアルタイムで制御するための加速コンピューティングの活用](https://developer.nvidia.com/blog/using-accelerated-computing-to-live-steer-scientific-experiments-at-massive-research-facilities/) で詳述されている通り、過去のいかなる結果よりも約 3 倍優れた GPU 利用率を実現しています。 新しい LM ベースの実装は、物理的根拠に基づいた減衰コサインモデルの最小二乗残差を直接最小化し、より低い適合残差とピクセルごとの周波数微調整をもたらします。このパイプラインでは、検出器を 760 の固定サイズタイルに分割し、各 GPU で独立して処理を行います。各タイルの計算（16 ピクセルのトレースの適合）は、現代の GPU を飽和させるには小さすぎるため、実行時間は固定的なタイルごとのオーバーヘッド（タスクディスパッチ、データ移動、セットアップ）によって支配されます。約 32 個の Superchips を超えると、GPU あたりのタイル数がこのオーバーヘッドを相殺できる点を下回り、追加の GPU は効果をもたらさなくなります。 ## システムのスケーリング NVIDIA GB200 および NVIDIA H100 アーキテクチャにおいて、専用のマルチノード/マルチ GPU 構成を用いることで、良好なスケーリングが確認されています。 ## I/O スループット最適化 GDS ベースの I/O にデータ配置を考慮した最適化と、現代の GPU および高性能ストレージを飽和させるように設計されたマルチストリーム読み込みを組み合わせています。 ## さらに詳しく知る XANI プロジェクトは、量子物理学から材料化学に至るまで Python が中心となっているコミュニティが、CUDA Python と分散コンピューティングを成功裏に導入できることを示しています。バッチ処理、明示的な Python タスク、GDS ベースの I/O に焦点を当てることで、科学者たちが低レベルの C++/MPI の専門家になる必要なく、次世代施設のペタバイト規模の需要に応えるために科学パイプラインを拡張することが可能になります。 始め方と詳細については以下のリソースをご覧ください: - ワークフローに新しいマルチスレッド対応 HDF5 ライブラリ（ベータ版）を試す - GTC セッション「Accelerated HPC+AI Workflow Enables Live-Steering of Vera C. Rubin Observatory and X-ray Free Electron Laser」を視聴する - 実験の制御や科学発見のための多次元データ処理・分析を加速させる XANI プロジェクトへの共同参加に興味がある場合は、ご連絡ください。 ## 謝辞 *NVIDIA の貢献者である **Malte Foester** と **Quincey Koziol** に感謝します。*

新素材のナノスケールイメージングのための加速 X 線解析 (XANI)

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト