既存のpandasパイプラインが40GBのCSVファイルでCPU上で動作が遅すぎる。
pandasをcuDFに置き換える。ほとんどのread/filter/groupby/join呼び出しは同じAPIを保持し、GPU上で実行される。
理由: cuDFは設計上pandas APIをミラーリングしているため、移行はほとんどの場合、書き換えではなくインポートの変更で済む。
最終確認：2026年6月
NCA-ADS 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
既存のpandasパイプラインが40GBのCSVファイルでCPU上で動作が遅すぎる。
pandasをcuDFに置き換える。ほとんどのread/filter/groupby/join呼び出しは同じAPIを保持し、GPU上で実行される。
理由: cuDFは設計上pandas APIをミラーリングしているため、移行はほとんどの場合、書き換えではなくインポートの変更で済む。
チームは既存のpandasコードに触れずにGPUの高速化を望んでいる。
cudf.pandasアクセラレータ（%load_ext cudf.pandas または python -m cudf.pandas）をロードする。これにより、GPUで操作が実行され、自動的にCPUにフォールバックする。
理由: コード変更なしの高速化と透過的なCPUフォールバックにより、サポートされていない操作も機能し続ける。
GPU上で大規模な分析データセットを最速で列指向ロードする必要がある。
Parquetとして保存し、cudf.read_parquetで読み込む。カラムプルーニングと述語プッシュダウンにより、デバイス転送が最小限に抑えられる。
理由: 列指向のParquetはArrowをバックエンドとするcuDFにきれいにマッピングされ、行指向のCSVよりもはるかに高速に読み込める。
50MBのファイルでcuDFがpandasよりも遅い。
小さなデータはCPU上に保持する。ホストからデバイスへの転送とカーネル起動のオーバーヘッドは、約1～2GB以下の場合は支配的になる。
理由: GPU高速化は大規模なデータで効果を発揮する。小さなデータの場合、コピーコストが計算による利点を上回る。
数十億行をキーで集約し、複数の統計量を計算する。
cuDFでdf.groupby(key).agg({...})を使用する。集約は並列GPUカーネルとして実行される。
GPUスケールでカーディナリティの高いテキストカラムをクリーンアップし、正規化する。
cuDFの.strアクセサ（lower, strip, replace, contains, split）を使用する。文字列操作はlibcudfを介してGPUで高速化される。
理由: cuDFには専用のGPU文字列レイヤーがあるため、テキストクリーニングがCPUにフォールバックする必要がない。
共有キーで2つの大規模なデバイスDataFrameを結合する。
cudf.merge / df.merge を結合キーと共に使用する。ハッシュ結合はGPU上で実行される。
理由: ラウンドトリップを避けるために、両方のフレームが既にデバイス上にある必要がある。pandasとcuDFを混ぜるとホストコピーが強制される。
データセットに欠損値があり、後続のcuMLトレーニングが失敗する。
適合前にcuDFのfillna/dropnaと明示的なdtypeキャストを使用する。cuMLはクリーンな数値デバイス配列を期待する。
混合/object dtypeがcuDFでエラーやメモリ肥大化を引き起こす。
GPUメモリフットプリントを削減するために、早い段階でコンパクトな数値またはカテゴリカルdtype（int32/float32, category）にキャストする。
理由: ダウンキャスティングはデバイスメモリの負荷を軽減し、これは単一GPUで最も一般的なボトルネックである。
トレーニング前にカテゴリカル特徴量にラベル/one-hotエンコーディングが必要。
cuDFのカテゴリカルdtypeを.cat.codesと共に使用するか、cuMLの前処理エンコーダを使用してデータをデバイス上に保持する。
cuDF DataFrame APIで公開されていない生の数値配列演算が必要。
df.valuesまたはto_cupy()を介して変換し、CuPy（NumPy互換のGPU配列）で操作した後、結果を戻す。
理由: cuDFとCuPyは__cuda_array_interface__を介してデバイスメモリを共有するため、変換はゼロコピーである。
scikit-learnのトレーニングスクリプトをGPUに移植する。
cuMLの推定量（LinearRegression, LogisticRegression, KMeans, RandomForest）を使用する。fit/predictはsklearn APIをミラーリングする。
理由: cuMLはsklearn API互換性を目標としているため、通常はインポートの置き換えで十分である。
大規模な表形式データセットでの勾配ブースティングツリーがCPU上でトレーニングが遅すぎる。
XGBoostをdevice="cuda"（tree_method="hist"）でトレーニングする。これはcuDF/CuPyデータを直接消費する。
理由: XGBoostのネイティブGPUヒストグラムメソッドは、大幅な高速化をもたらし、RAPIDSと緊密に統合される。
セグメンテーションのために数百万の点を高速にクラスタリングする。
cuML KMeans（または密度ベースの場合はDBSCAN）を使用する。どちらもGPU上で完全に実行される。
高次元データを大規模な可視化のために2Dに削減する。
cuML UMAPまたはt-SNEを使用する。GPU実装はCPUでは非現実的なデータセットを処理できる。
理由: UMAP/t-SNEは計算負荷が高い。GPUバージョンはインタラクティブスケールのembeddingを可能にする。
特徴量の重要度を持つ正確なアンサンブル分類器が必要。
cuML RandomForestClassifierを使用する。デバイス配列でトレーニングし、高速な推論のためにFILにエクスポートする。
高スループットのバッチスコアリングのためにツリーモデルをデプロイする。
モデルをForest Inference Library (FIL)にロードし、大規模バッチでGPU高速化された予測を実行する。
理由: FILは、XGBoost/LightGBM/cuMLフォレストの推論を、ツリーごとのCPUスコアリングをはるかに超えて高速化する。
必要なアルゴリズムにcuML GPU実装がない。
cuMLドキュメントでカバー範囲を確認する。もしなければ、そのステップはscikit-learnに残し、残りを高速化する。
理由: すべての推定量がGPUでサポートされているわけではない。完全な同等性を仮定するのではなく、サポートされているセットを把握しておく。
cuMLトレーニング中にサイレントホストコピーを回避する。
cuDF/CuPyデバイスデータを直接fit()に渡す。NumPy/pandasを混ぜるとホストからデバイスへの転送がトリガーされる。
データセットが単一GPUのメモリよりも大きい。
dask-cuDFを使用して、データを複数のGPU/ノードにパーティション分割し、パーティションを並列処理する。
理由: Daskは、単一のcuDFフレームでは不可能な、アウトオブコアおよびマルチGPU分散を処理する。
1つのマルチGPUマシン上のすべてのGPUを使用したい。
dask-cudaからLocalCUDAClusterを起動し、Clientを接続する。1つのワーカーがGPUごとにピン留めされる。
理由: LocalCUDAClusterは各Daskワーカーを個別のGPUに接続するため、スケジューラが作業を分散できる。
多段階のDaskパイプラインを構築しており、再計算が多すぎる。
遅延的に構成し、最後に一度.compute()を呼び出す。再利用される中間結果をGPUメモリにキャッシュするためにpersist()を使用する。
理由: Daskは遅延評価である。早すぎる、または繰り返し計算をトリガーすると、作業が再実行される。
スキューしたパーティションにより、一部のGPUワーカーが遅延する。
バランスの取れたサイズに再パーティション分割し、パーティションキーを下流の結合/グループ化と合わせる。
理由: 不均一なパーティションは、ジョブ全体をボトルネックにする遅延ワーカーを生み出す。
ETL → トレーニング → スコアリングのワークフローを完全にGPU上で実行する。
途中でpandasに変換することなく、cuDFの準備をcuML/XGBoostに連携させ、データをデバイス上に保持する。
理由: CPUへのラウンドトリップごとに転送コストが追加される。デバイス上にデータを保持することで、エンドツーエンドの高速化が維持される。
レビューのためにまったく同じように再実行できるワークフローが必要。
RAPIDS/CUDAのバージョンを固定し、乱数シードを設定し、入力値をパラメータ化することで、パイプラインを決定論的に再実行可能にする。
数十億行のテーブルに対して要約統計量を計算する。
cuDFのdescribe/mean/std/quantileとcorrを使用する。集約はGPUカーネルとして実行される。
1億点の散布図が重なりすぎて読みにくい。
Datashaderでレンダリングする。これは、各マーカーを描画する代わりに、GPU上で点を密度画像にラスタライズする。
理由: Datashaderはピクセルに集約するため、プロットコストは点数ではなく画像サイズによって制限される。
大規模なGPU DataFrame上でインタラクティブなクロスフィルタリングダッシュボードが必要。
cuxfilterを使用して、cuDFデータに対するGPU高速化されたクロスフィルタリングでグラフをリンクする。
理由: cuxfilterはデータをデバイス上に保持するため、ブラッシング/フィルタリングが大規模なデータでもインタラクティブに維持される。
大規模な数値列の分布を可視化する。
GPU上でcuDF/CuPyでビンニングし、その小さな集約結果をPlotlyまたはMatplotlibでプロットする。
理由: まずGPUで集約する。プロットライブラリに渡す必要があるのは小さな要約のみ。
モデリング前に特徴量間の関係を評価する。
GPU上でcuDFのdf.corr()を計算し、その小さな行列をヒートマップとしてレンダリングする。
GPUデータに裏打ちされた宣言的インタラクティブチャートが必要。
HoloViews/hvPlotをDatashaderおよびcuDFと組み合わせて、大量のインタラクティブな可視化を実現する。
データワークロードにGPUアクセラレーションを正当化する。
大規模なデータセットに対する大規模データ並列、スループットがボトルネックとなる操作にはGPUを使用し、小規模で分岐の多い、またはレイテンシに敏感な作業はCPUに保持する。
理由: GPUは多数の要素にわたるSIMT並列性で優位に立つが、小規模または制御重視のタスクでは劣る。
cuDF、CuPy、およびMLライブラリ間でRAPIDSがデータをコピーなしで共有する方法を説明する。
RAPIDSはApache Arrowの列指向メモリフォーマットに基づいて構築されており、GPUライブラリ間のゼロコピー交換を可能にする。
理由: 共有されたデバイス上の列指向レイアウトにより、コンポーネントがシリアル化なしでデータを引き渡すことができる。
パイプラインはGPUで高速化されているが、ほとんど速くならない。
データ移動をプロファイリングする。繰り返されるホスト↔デバイス間のコピーが支配的であることが多い。ステップ間でデータをGPU上に常駐させる。
理由: PCIe転送は隠れたコストである。コピーを最小限に抑えることが、通常、最大の単一の改善点となる。
GPUで何が作業を実行しているのかを理解する。
CUDAはSIMTモデルの下で、ブロック/グリッドにグループ化された数千のスレッドにわたってカーネルを起動する。RAPIDSライブラリはこれらをラップするため、自分でカーネルを書くことはめったにない。
単一GPUでメモリ不足のためワークロードがエラーになる。
dtypeサイズを削減するか、チャンクで処理するか、Daskでスケールアウトする。GPU VRAMはホストRAMよりもはるかに小さい。
理由: デバイスメモリはGPUデータサイエンスにおける最初の制約である。それに合わせて設計する。
CPUデータサイエンスタスクを適切なRAPIDSライブラリにマッピングする。
DataFrameにはcuDF、MLにはcuML、グラフにはcuGraph、地理空間データにはcuSpatial、スケールアウトにはDaskを使用する。
多くのトレーニング実行とそのメトリクスを比較する必要がある。
パラメーター、メトリクス、アーティファクトをMLflow Trackingにログ記録する。UIから実行をクエリして比較する。
理由: 集中型実験追跡により、結果が再現可能になり、異なる実行間で比較可能になる。
ライブダッシュボードとチームで共有できる実験ログが必要。
Weights & Biases (wandb.init/log)を使用して、メトリクスをストリームし、視覚的な実験ダッシュボードを共有する。
どのトレーニング済みモデルがステージングとプロダクションのどちらにあるかを追跡する。
MLflow Model Registryにバージョンを登録し、メタデータと共にステージを昇格させる。
理由: レジストリは、モデルの系統とプロモーションに関する唯一の真実のソースを提供する。
数ヶ月後にモデルが再現できない。
データ、コード、環境、シードをまとめてバージョン管理する。各実行で完全な構成をログ記録する。
理由: 再現性にはこれら4つすべてをキャプチャする必要がある。コードだけでは不十分。
トレーニング済みモデルをサービス提供に向けて移行する。
モデルと依存関係（例：コンテナイメージ）をパッケージ化し、バッチまたはREST推論を公開する。高速なGPUツリースコアリングにはFILを使用する。
大規模なグラフでノードを影響力によってランク付けする。
エッジリストからcuGraph Graphを構築し、GPU上でcugraph.pagerankを実行する。
理由: cuGraphは、CPUライブラリでは大きすぎるグラフに対してPageRank、BFS、および中心性分析を実行する。
ネットワークデータセット内のクラスター/コミュニティを見つける。
cuGraphのconnected-componentsまたはLouvainを使用する。cuDF DataFrameからエッジを取り込む。
データが高次元で、ほとんどがゼロである。
メモリに収め、計算を高速化するために、密な配列の代わりにGPU疎形式（CuPy sparseを介したCSR/COO）を使用する。
理由: 疎なストレージは、VRAMとカーネルをゼロエントリに無駄に消費するのを避ける。
動作するRAPIDS環境をセットアップする。
RAPIDS Release Selectorを使用して、CUDA/Pythonバージョンに一致するconda、pip、またはDocker経由でインストールする。
理由: セレクターは互換性のあるパッケージビルドを固定し、これはインストールの失敗の最も一般的な原因である。
インストール後、RAPIDSのインポートが失敗したり、GPUが認識されない。
NVIDIAドライバーとCUDAツールキットのバージョンがRAPIDSのビルド要件を満たしていることを確認する。nvidia-smiを実行してGPUを確認する。
理由: ドライバー/CUDAの不一致は、「CUDAデバイスなし」エラーの最大の原因である。
再現可能で事前に構成されたRAPIDS環境が必要。
NVIDIA NGCからRAPIDSコンテナをプルする。これには、一致するCUDA、ドライバー、およびライブラリが含まれている。
理由: NGCイメージは、バージョン一致の推測作業をなくし、マシン間で環境を標準化する。