NVIDIA GB200 NVL72 を用いた GPU アクセラレーション Presto による低遅延分析ワークロードの実行
NVIDIA は、GB200 NVL72 と Presto の組み合わせにより低遅延な分析ワークロードを実現する技術と、IBM Storage Scale System を活用した I/O 最適化の詳細を公開しました。
キーポイント
GPU アクセラレーションによるパフォーマンス向上
NVIDIA cuDF アルゴリズムと NVLink 5.0 を活用することで、CPU ベースの Presto よりもはるかに高速なクエリ実行を実現し、DGX B200 単体で 8-10 ノード分の Intel Xeon サーバーに匹敵する性能を発揮します。
GB200 NVL72 マルチノード環境での最適化
NVIDIA GPUDirect Storage (GDS) と IBM Storage Scale System を組み合わせることで、大規模データセットに対する高スループットな I/O 処理が可能となり、低遅延分析ワークロードの基盤が強化されます。
次世代アーキテクチャと通信プロトコルの活用
UcxExchange を介した GPU ワーカー間の高速通信や、TPC-H ベンチマークに基づく 22 クエリの検証により、大規模データ分析における実用的な性能向上が示されています。
ベンチマーク設定と手法
TPC-Hの22クエリをParquet形式で実行し、小数型を浮動小数点型に置換して評価しました。各クエリは5回実行し、最後の4回の平均値を採用しています。
1KスケールでのGPU加速効果
約1TBのデータセットにおいて、8 GPU構成のPresto GPUは8.2倍高速化され、単一GPUでも8ノードCPUクラスターより2.5倍高速でした。
3Kスケールでのパフォーマンス
約3TBのデータセットでは、10ノードCPUクラスターと比較して、Presto GPUは最大7.8倍の高速化を実現しました。
GPU-Accelerated Presto の性能向上
NVIDIA GB200 NVL72 環境における GPU アクセラレーションにより、TPC-H スケールファクター 1K および 3K で CPU マルチノード構成と比較して劇的なクエリ実行時間の短縮が実現されました。
影響分析・編集コメントを表示
影響分析
この記事は、大規模言語モデルやエージェントシステムにおけるリアルタイムデータ分析のボトルネックを解決する具体的なアーキテクチャを示しており、AI アプリケーションの実用化において不可欠な高速インフラの標準化に寄与します。特に NVIDIA と IBM の連携によるストレージ最適化は、企業が大規模データを即座に処理して意思決定や自律的なエージェント動作を可能にするための重要な指針となります。
編集コメント
本記事は、単なるハードウェアの性能比較を超え、AI エージェントがリアルタイムで大規模データを処理するための具体的なインフラ設計指針を提供しています。特に GDS と IBM ストレージの連携は、今後のハイブリッド AI インフラ構築において重要な参考事例となるでしょう。
Presto は、非常に大規模なデータセット上で高速かつ対照的なクエリを実行するためのオープンソースの分散 SQL エンジンです。NVIDIA GPU 上では、Presto は分析用クエリワークロードに対して最大限のパフォーマンスを発揮し、ユーザーやエージェントにとって低遅延を実現します。GPU アクセラレーションされた Presto を使用することで、分析ワークロードに低遅延をもたらすことができ、あなたやあなたのエージェントがブロックされることなく、可能な限り高速に反復処理を行えます。
本記事では、単一ノードの NVIDIA DGX B200 とマルチノード構成の NVIDIA GB200 NVL72 の両方を用いた、スケーリングされた分析ベンチマークにおける効率的なマルチ GPU Presto 実行の実証を行います。また、IBM Storage Scale System データソースと組み合わせた NVIDIA GB200 NVL72 において、高 I/O スループットを実現するために NVIDIA GPUDirect Storage (GDS)（GPU 直接ストレージ）が極めて重要である点についても強調します。
GPU ネイティブの Velox と NVIDIA cuDF を用いた大規模データ分析の加速に関する詳細、および GPU ワーカー間の高性能通信における UcxExchange の重要性については、Accelerating Large-Scale Data Analytics with GPU-Native Velox and NVIDIA cuDF をご覧ください。
GPU アクセラレーションされた Presto はどのようにして最大のパフォーマンスを発揮するのか？
GPU アクセラレーションされた Presto は、最高性能のために NVIDIA cuDF アルゴリズムを使用し、最速の GPU 間通信には NVIDIA NVLink を活用しています。8 つの GPU を備えた単一の DGX B200 ノードは、NVLink 5.0 を介して相互接続された 1,800 GB/s の双方向帯域幅を持つ 8 つの Presto GPU ワーカーをサポートします。DGX B200 上の GPU アクセラレーションされた Presto は、Intel Xeon 6642Y サーバーの 8〜10 ノード上で動作する CPU ベースの Presto と比較して明確なパフォーマンス上の優位性を示しています。
本稿では、TPC-H に由来するベンチマークに焦点を当てます。これらには 22 の分析クエリが含まれ、parquet ファイルデータソースを使用し、今回のデモンストレーションのために decimal タイプが float タイプに置き換えられています。測定されたクエリ実行時間は、SQL パース、プラン最適化、ワーカーの実行、および最終結果の返却を含みます。各クエリは 5 回実行され、最後の 4 回の値を平均して実行時間が計測されました。ベンチマークデータは、Presto、Velox、cuDF のソースビルドを使用して収集されました。包括的なビルド、デプロイメント、およびベンチマークスクリプトについては、rapidsai/velox-testing GitHub リポジトリを参照してください。
図 1 は、マルチノード CPU Presto とシングルノード多 GPU Presto のクエリ実行時間を比較しています。スケールファクター 1K における Presto CPU 構成では、Presto C++ ワーカー、2 ソケット Intel Xeon 6642Y サーバーを 8 ノード使用し、システムメモリは 250 GiB、Parquet ファイルを含む Lustre データソースを採用しました。スケールファクター 3K では、同様のサーバーを 10 ノード構成としました。Presto CPU 構成ではベンチマークをホット状態（ウォームアップ済み）で実行し、ワーカーは Velox 非同期データキャッシュ を使用し、コーディネーターは ソフトアフィニティによるキャッシュ利用率向上 を活用しました。一方、Presto GPU 構成では NVIDIA DGX B200 を 1 台使用し、アクティブな GPU の数を可変とし、ホット状態の Parquet データソースを参照しました。
スケールファクター 1K（約 1 TB のデータセット）において、GPU アクセラレーションされた Presto は、アクティブな GPU の数に応じて 2.5 倍から 8 倍のレイテンシ低減を実現しました。B200 GPU を 1 基で稼働させた Presto GPU は、8 ノード構成の Presto CPU クラスターと比較して 2.5 倍高速であり、B200 GPU を 8 基使用した Presto GPU は、同様に 8.2 倍の高速化を示しました。スケールファクター 3K（約 3 TB のデータセット）では、Presto GPU は 3 倍から 8 倍のレイテンシ低減を達成しました。B200 GPU を 3 基で稼働させた Presto GPU は 10 ノード構成の Presto CPU クラスターと比較して 3.6 倍高速であり、B200 GPU を 8 基使用した Presto GPU は 7.8 倍の高速化を示しました。
image*図 1. TPC-H に由来するスケールファクター 1K および 3K に対するクエリ実行時間の比較。Presto CPU マルチノード構成と Presto GPU マルチ GPU シングルノード構成を対照*
GPU アクセラレーションされた Presto は GB200 NVL72 でどのようにスケールアウトするのか？
GPU アクセラレーションされた Presto は、NVIDIA GB200 NVL72 などの NVLink 接続システムにおいて、複数のノードへのスケールアウトも優れたパフォーマンスで実現します。NVIDIA GB200 NVL72 システムは合計 18 ノードから構成され、各ノードには Grace CPU が 2 基、B200 GPU が 4 基、ConnectX-7 (CX7) 400 Gbps ネットワークインターフェースカードが 4 枚搭載されています。クラスター内のすべての GPU は NVLink で接続されており、計算とストレージ間のトラフィックのためのネットワークが開かれています。
GPU アクセラレーションされた Presto のベンチマークでは、NVL72 クラスターは IBM Storage Scale とペアリングされました。IBM Storage Scale は 20 ノードのストレージノードを備え、容量は 10 PB、ピーク帯域幅は約 4.5 TiB/s を誇るデータストレージシステムです。IBM Storage Scale（旧称：IBM Spectrum Scale または General Parallel File System (GPFS)）は、クラスター型で POSIX 準拠の並列ファイルシステムであり、InfiniBand/RoCE 上でネイティブなリモートダイレクトメモリアクセス (RDMA: Remote Direct Memory Access) トランスポートを提供します。NVIDIA GDS と IBM Storage Scale を組み合わせることで、ストレージデバイスから GPU メモリへ直接ファイルデータを転送でき、ホスト CPU やシステムメモリを介したバッファリング（バウンスバッファ）をバイパスできます。
図 2 は、NVL72 GB200 クラスターにおける TPC-H 派生スケールファクター 10K および 30K のクエリ実行時間全体を比較しており、クラスターの起動時に行われた最も重要な I/O および通信最適化を強調しています。図 2 に示されたクエリ実行時間のデータは、合計 18 ノードのうち 8 つのアクティブノードを使用し、分析ワークロードに参加する Presto GPU ワーカーが 32 台であることを示しています。
image*図 2. NVIDIA GB200 NVL72 を使用した TPC-H 派生スケールファクター 10K および 30K における Presto GPU のスケールアウトテスト。複数の最適化ラウンドにわたるパフォーマンス向上を示す*
最初の条件では、POSIX リード（POSIX reads）を IBM Storage Scale に使用し、未最適化の I/O パラメータと調整されていない UcxExchange 設定が採用されました。次の条件であるデバイスリードと 16 MiB の I/O タスクは、GDS を有効にし、IBM Storage Scale に対して推奨されるサイズである 4 MiB から 16 MiB に I/O タスクサイズを増やすことで、実行時間を約 30% 短縮しました。
さらに次の条件では、I/O スレッドを 4 つから 16 に増やすことにより NVLink の飽和状態が改善され、実行時間がさらに約 17% 短縮されました。最終的な条件では、再バッチ処理と Q11 の書き換えを追加したことで、大きな交換バッチサイズと GPU のアイドル時間の減少により、実行時間をさらに 35% 削減しました。全体として、I/O および通信の最適化によりクエリ実行時間が 64% 高速化されました。
Q11 の書き換えにより、SELECT ステートメントが INSERT INTO ステートメントに変更され、Q11 の実行時間が 50 秒から 2 秒に短縮されました。デフォルトの HttpExchange を介して GPU ワーカーからコーディネーターへクエリ結果を送信する際にボトルネックが生じていたため、SELECT ステートメントとして実行された Q11 ではクラスター内の GPU 利用時間が <5% に留まることを確認しました。一方、INSERT INTO ステートメントとして Q11 を実行することで、GPU ベースの Parquet Writer（原語：parquet writer）を活用し、IBM Storage Scale への結果保存を効率的に行うことができました。
今後は、クエリを変更せずに高い GPU 利用率を維持しつつ、Presto におけるワーカーからコーディネーターへの結果送信スループットを向上させる計画です。
GDS を用いた高速かつ軽量な I/O の実現方法
IBM Storage Scale を備えた NVL72 クラスターにおいて、GDS は、最高性能とコストパフォーマンスを実現するための重要なツールです。IBM Storage Scale では主に 2 つのデータパスが利用可能です。1 つ目は POSIX リードで、これはデータをクライアントのページプールにステージングしてから GPU メモリへコピーする方式です。2 つ目は GDS リードで、RMDA（Remote Memory Direct Access）を使用して GPU メモリを直接充満させる方式です。GDS はトポロジを認識しており、CX7 ネットワークカードから GPU メモリへのデータパスが同じ NUMA ノード内に留まることを保証します。本研究で使用した IBM Storage Scale のバージョンは POSIX リードに対してトポロジ認識機能を持っていないため、これらのリードでは追加のステージングバッファコピーが発生するだけでなく、NUMA 境界をまたぐことによるペナルティも受けます。
TPC-H ベースの 10K スケールファクタのパフォーマンスを、2 つの入出力構成で分析しました。1 つはページプールサイズを 50 GiB に設定した POSIX コールドモード、もう 1 つはキャッシュをバイパスする GDS コールドです。2 ノード（8 GPU）でスケールファクタ 10K を実行した結果、GDS リードは POSIX リードに比べて顕著な優位性を示しました。2 ノード・8 GPU の構成において、POSIX のバウンシングバッファコピーや NUMA バウンダリーをまたぐことによる遅延により、GDS コールドリードの実行時間は POSIX コールドリードの約 2 倍速いことが確認されました。効率的なデータパスとホストリソース消費量の削減により、IBM Storage Scale を使用する NVL72 環境では、パフォーマンスおよびコストパフォーマンスの観点から GDS リードが推奨されるアプローチになると考えられます。
image*図 3. NVIDIA GB200 NVL72 におけるスケールファクタ 10K の POSIX コールドおよび GDS コールドリード（2 ノード、8 GPU）*
GPU アクセラレーション対応 Presto の始め方
インタラクティブなダッシュボードの実行や夜間ジョブの実行を問わず、GPU アクセラレーション対応 Presto は分析ワークロードに低遅延と高スループットを提供します。
IBM watsonx.data プラットフォームとの統合により、GPU アクセラレーション対応 Presto は本番環境のワークロードでのテストが可能な状態になりました。watsonx.data 上の GPU アクセラレーション対応 Presto の技術プレビューへのアクセス登録は こちら です。
Presto のテストやデプロイに興味のある開発者やエンジニアの方は、Presto DockerHub 上の Presto Native gpu-nightly タグを参照してください。詳しくは、GPU アクセラレーション対応 Presto C++ の入門 をご覧ください。
原文を表示
Presto is an open source, distributed SQL engine for running fast, interactive queries on very large datasets. On NVIDIA GPUs, Presto delivers peak performance for analytical query workloads and provides low latency for users and agents. GPU-accelerated Presto brings low latency to your analytical workloads, keeping you and your agents unblocked and iterating as fast as possible.
This post demonstrates efficient multi-GPU Presto execution on scaled analytical benchmarks using both single-node NVIDIA DGX B200 and multinode NVIDIA GB200 NVL72. We also highlight the importance of NVIDIA GPUDirect Storage (GDS) for high I/O throughput on NVIDIA GB200 NVL72 when paired with an IBM Storage Scale System data source.
For more details about GPU-accelerated Presto and the importance of UcxExchange for high performance communications between GPU workers, see Accelerating Large-Scale Data Analytics with GPU-Native Velox and NVIDIA cuDF.
How does GPU-accelerated Presto deliver peak performance?
GPU-accelerated Presto uses NVIDIA cuDF algorithms for peak performance and NVIDIA NVLink for the fastest GPU-to-GPU communication. A single DGX B200 node with eight GPUs supports eight Presto GPU workers, all connected over NVLink 5.0 with 1,800 GB/s bidirectional bandwidth. GPU-accelerated Presto on DGX B200 shows clear performance advantages over Presto CPU running on 8-10 nodes of Intel Xeon 6642Y servers.
This post focuses on benchmarks derived from TPC-H, which include 22 analytical queries, use parquet file data sources, and replace decimal types with float types for this demonstration. The measured query runtime includes SQL parsing, plan optimization, worker execution, and returning final results. Runtimes were measured by running each query five times and averaging the last four values. Benchmarking data were collected using source builds of Presto, Velox and cuDF. For comprehensive build, deployment, and benchmarking scripts, see the rapidsai/velox-testing GitHub repo.
Figure 1 compares the query runtime for multinode CPU Presto and single-node multi-GPU Presto. The Presto CPU configuration for scale factor 1K used Presto C++ workers, eight nodes of two-socket Intel Xeon 6642Y servers with 250 GiB system memory, and a Lustre data source containing parquet files. At scale factor 3K, the Presto CPU configuration used 10 nodes of the same servers. The Presto CPU configuration ran the benchmarks hot, with the workers using Velox async data cache, and the coordinator using soft affinity to increase cache utilization. The Presto GPU configuration used one NVIDIA DGX B200 with varying number of active GPUs, and hot cache parquet data source.
At scale factor 1K (~1 TB data set), GPU-accelerated Presto delivered 2.5x-8x lower latency depending on the number of active GPUs. Presto GPU running with one B200 GPU showed 2.5x faster runtime compared to an eight-node Presto CPU cluster, and Presto GPU running with eight B200 GPUs showed 8.2x faster runtimes compared to an eight-node Presto CPU cluster. At scale factor 3K (~3 TB data set), Presto GPU delivered 3x-8x lower latency. Presto GPU running with three B200 GPUs showed 3.6x faster runtimes compared to a 10-node Presto CPU cluster, and Presto GPU running with eight B200 GPUs showed 7.8x faster runtime than a 10-node Presto CPU cluster.
How does GPU-accelerated Presto scale out on GB200 NVL72?
GPU-accelerated Presto also scales out to multiple nodes with excellent observed performance on NVLink-connected systems such as NVIDIA GB200 NVL72. The NVIDIA GB200 NVL72 system includes a total of 18 nodes, where each node includes two Grace CPUs, four B200 GPUs, and four ConnectX-7 (CX7) 400 Gbps network interface cards. The GPUs in the cluster are all connected by NVLink, opening the network for traffic between compute and storage.
For GPU-accelerated Presto benchmarking, the NVL72 cluster was paired with IBM Storage Scale, a data storage system with 20 storage nodes, 10 PB capacity and peak bandwidth of ~4.5 TiB/s. IBM Storage Scale, formerly IBM Spectrum Scale or General Parallel File System (GPFS), is a clustered, POSIX-compliant parallel file system, providing native remote direct memory access (RDMA) transport over InfiniBand/RoCE. Together, NVIDIA GDS and IBM Storage Scale allow file data to move directly from storage device to GPU memory, bypassing host CPU and system-memory bounce buffers.
Figure 2 compares the total query runtime for TPC-H-derived scale factors 10K and 30K for the NVL72 GB200 cluster, highlighting the most significant I/O and communication optimizations during cluster bring up. The query runtime data shown in Figure 2 used eight active nodes out of 18 total nodes, corresponding to 32 Presto GPU workers participating in the analytical workloads.
The first-run condition used POSIX reads to IBM Storage Scale, unoptimized I/O parameters, and untuned UcxExchange configuration. The next condition–device reads and 16 MiB I/O tasks–delivered ~30% faster runtime by enabling GDS and increasing I/O task size from 4 MiB to 16 MiB, the recommended size for IBM Storage Scale.
The next condition–plus 16 I/O threads–brought a further ~17% faster runtime due to better NVLink saturation when using 16 I/O threads instead of four I/O threads. The final condition–plus rebatching and Q11 rewrite–reduced runtime another 35% due to large exchange batch sizes and less GPU idle time. Overall the I/O and communication optimizations yielded 64% faster query runtimes.
Q11 rewrite modified the SELECT statement to an INSERT INTO statement, which reduced runtime on Q11 from 50 seconds to 2 seconds. We observed that Q11 as a SELECT statement resulted in <5% GPU utilization time in the cluster, due to a bottleneck in sending query results from a GPU worker to the coordinator over the default HttpExchange. Running Q11 as an INSERT INTO statement used the GPU-based parquet writer to efficiently store results in IBM Storage Scale.
Moving forward, we plan to improve the throughput of sending results in Presto from worker to coordinator, keeping high GPU utilization without adjusting queries.
How to achieve faster, lightweight I/O with GDS
On the NVL72 cluster with IBM Storage Scale, GDS is a critical tool for reaching peak performance and cost performance. IBM Storage Scale enables two main data paths: POSIX reads that stage data in a client page pool before copying to GPU memory, and GDS reads that populate GPU memory using RMDA. GDS is topology-aware, and ensures that the data path from the CX7 network card to GPU memory remains within the same NUMA node. The version of IBM Storage Scale in this study was not topology-aware for POSIX reads, so these reads incur both the extra staging buffer copy as well as penalties from NUMA boundary crossing.
We analyzed TPC-H-derived 10K performance in two I/O configurations: POSIX cold with a nominal page pool size of 50 GiB, and GDS cold, which bypasses caching. Running scale factor 10K with two nodes (eight GPUs), we observed that GDS reads demonstrate significant advantages over POSIX reads. At two nodes and eight GPUs, GDS cold reads showed ~2x faster runtimes than POSIX cold reads due to POSIX slowdowns from bounce buffer copying and NUMA boundary crossing. Due to the efficient data path and reduced consumption of host resources, we expect GDS reads to be the preferred approach for performance and cost-performance on NVL72 with IBM Storage Scale.
Get started with GPU-accelerated Presto
Whether you’re running interactive dashboards or nightly jobs, GPU-accelerated Presto provides your analytical workloads with low latency and high throughput.
With integration in the IBM watsonx.data platform, GPU-accelerated Presto is now ready for testing on your production workloads. Register for access to the technical preview of GPU-accelerated Presto on watsonx.data.
For developers and engineers interested in Presto testing and deployment, refer to the Presto Native gpu-nightly tag on the Presto DockerHub. To learn more, see Getting Started with GPU-Accelerated Presto C++.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み