Zuletzt überprüft: Juni 2026
Eine übersichtliche Referenz der Architekturmuster, die in der NCA-ADS-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Bestehende pandas-Pipeline auf einer 40 GB großen CSV-Datei ist auf der CPU zu langsam.
Ersetzen Sie pandas durch cuDF; die meisten Lese-/Filter-/Gruppierungs-/Join-Aufrufe behalten dieselbe API bei und laufen auf der GPU.
Warum: cuDF spiegelt die pandas-API im Design wider, sodass die Migration hauptsächlich eine Änderung des Imports und keine Neuschreibung ist.
Das Team möchte GPU-Beschleunigungen, ohne den bestehenden pandas-Code zu ändern.
Laden Sie den cudf.pandas-Beschleuniger (%load_ext cudf.pandas oder python -m cudf.pandas); er führt Operationen auf der GPU aus und greift automatisch auf die CPU zurück.
Warum: Die Beschleunigung ohne Codeänderung mit transparentem CPU-Fallback sorgt dafür, dass nicht unterstützte Operationen weiterhin funktionieren.
Benötigt den schnellsten spaltenorientierten Ladevorgang eines großen Analyse-Datasets auf der GPU.
Als Parquet speichern und mit cudf.read_parquet lesen; Spaltenbeschneidung und Prädikat-Pushdown minimieren die Geräteübertragung.
Warum: Spaltenorientiertes Parquet lässt sich sauber auf Arrow-gestütztes cuDF abbilden und liest weitaus schneller als zeilenorientierte CSV-Dateien.
cuDF ist bei einer 50 MB großen Datei langsamer als pandas.
Halten Sie kleine Daten auf der CPU; Host-zu-Gerät-Übertragung und Kernel-Start-Overhead dominieren unter ~1–2 GB.
Warum: GPU-Beschleunigung zahlt sich im großen Maßstab aus; bei winzigen Daten übersteigen die Kopierkosten den Rechengewinn.
Aggregieren Sie Milliarden von Zeilen nach Schlüssel mit mehreren Statistiken.
Verwenden Sie df.groupby(key).agg({...}) in cuDF; Aggregationen laufen als parallele GPU-Kernel.
Bereinigen und normalisieren Sie eine Textspalte mit hoher Kardinalität im GPU-Maßstab.
Verwenden Sie den .str-Accessor von cuDF (lower, strip, replace, contains, split); Zeichenkettenoperationen werden über libcudf auf der GPU beschleunigt.
Warum: cuDF verfügt über eine dedizierte GPU-Zeichenkettenebene, sodass die Textbereinigung nicht auf die CPU zurückfallen muss.
Verknüpfen Sie zwei große Geräte-DataFrames über einen gemeinsamen Schlüssel.
Verwenden Sie cudf.merge / df.merge mit dem Join-Schlüssel; Hash-Joins werden auf der GPU ausgeführt.
Warum: Beide Frames müssen sich bereits auf dem Gerät befinden, um einen Roundtrip zu vermeiden; das Mischen von pandas und cuDF erzwingt eine Host-Kopie.
Das Dataset enthält fehlende Werte, die das nachfolgende cuML-Training stören.
Verwenden Sie cuDF fillna/dropna und explizite dtype-Umwandlungen vor dem Fitten; cuML erwartet saubere numerische Geräte-Arrays.
Gemischte/Objekt-Dtypes verursachen Fehler oder Speicheraufblähungen in cuDF.
Frühzeitig in kompakte numerische oder kategoriale Dtypes (int32/float32, category) umwandeln, um den GPU-Speicherbedarf zu reduzieren.
Warum: Downcasting reduziert den Gerätespeicherdruck, den häufigsten Engpass bei einer einzelnen GPU.
Benötigt Label-/One-Hot-Encoding für kategoriale Merkmale vor dem Training.
Verwenden Sie cuDF categorical dtype mit .cat.codes oder cuML Vorverarbeitungs-Encodern, um Daten auf dem Gerät zu halten.
Benötigt reine numerische Array-Mathematik, die nicht durch die cuDF DataFrame API exponiert wird.
Konvertieren Sie über df.values oder to_cupy() und arbeiten Sie mit CuPy (NumPy-kompatible GPU-Arrays), dann bringen Sie die Ergebnisse zurück.
Warum: cuDF und CuPy teilen den Gerätespeicher über die __cuda_array_interface__, sodass die Konvertierung eine Nullkopie ist.
Portieren Sie ein scikit-learn-Trainingsskript auf die GPU.
Verwenden Sie cuML-Estimators (LinearRegression, LogisticRegression, KMeans, RandomForest); fit/predict spiegeln die sklearn-API wider.
Warum: cuML zielt auf sklearn-API-Kompatibilität ab, sodass der Austausch des Imports normalerweise ausreicht.
Gradient-Boosted Trees auf einem großen tabellarischen Datensatz, Training auf der CPU zu langsam.
Trainieren Sie XGBoost mit device="cuda" (tree_method="hist"); es verbraucht cuDF/CuPy-Daten direkt.
Warum: Die native GPU-Histogrammmethode von XGBoost bietet große Beschleunigungen und integriert sich eng mit RAPIDS.
Clustern Sie Millionen von Punkten schnell zur Segmentierung.
Verwenden Sie cuML KMeans (oder DBSCAN für dichte-basierte); beide laufen vollständig auf der GPU.
Reduzieren Sie hochdimensionale Daten auf 2D für die Visualisierung im großen Maßstab.
Verwenden Sie cuML UMAP oder t-SNE; GPU-Implementierungen verarbeiten Datensätze, die auf der CPU unpraktisch wären.
Warum: UMAP/t-SNE sind rechenintensiv; die GPU-Versionen machen interaktive Embeddings im großen Maßstab praktikabel.
Benötigt einen genauen Ensemble-Klassifikator mit Feature-Wichtigkeiten.
Verwenden Sie cuML RandomForestClassifier; trainieren Sie auf Geräte-Arrays und exportieren Sie nach FIL für schnelle Inferenz.
Bereitstellen eines Baummodells für hochdurchsatzstarkes Batch-Scoring.
Laden Sie das Modell in die Forest Inference Library (FIL), um GPU-beschleunigte Vorhersagen für große Batches auszuführen.
Warum: FIL beschleunigt die Inferenz für XGBoost-/LightGBM-/cuML-Wälder weit über die CPU-Bewertung pro Baum hinaus.
Ein von Ihnen benötigter Algorithmus hat keine cuML GPU-Implementierung.
Überprüfen Sie die Abdeckung in der cuML-Dokumentation; falls nicht vorhanden, behalten Sie diesen Schritt bei scikit-learn bei und beschleunigen Sie den Rest.
Warum: Nicht jeder Estimator wird von der GPU unterstützt – kennen Sie die unterstützten Sets, anstatt volle Parität anzunehmen.
Vermeiden Sie stille Host-Kopien während des cuML-Trainings.
Geben Sie cuDF/CuPy-Gerätedaten direkt an fit() weiter; das Mischen mit NumPy/pandas löst eine Host-zu-Gerät-Übertragung aus.
Der Datensatz ist größer als der Speicher einer einzelnen GPU.
Verwenden Sie dask-cuDF, um die Daten über mehrere GPUs/Knoten zu partitionieren und Partitionen parallel zu verarbeiten.
Warum: Dask verarbeitet Out-of-Core- und Multi-GPU-Verteilung, die ein einzelner cuDF-Frame nicht kann.
Möchte alle GPUs auf einer Multi-GPU-Maschine nutzen.
Starten Sie einen LocalCUDACluster von dask-cuda und verbinden Sie einen Client; ein Worker ist pro GPU fixiert.
Warum: LocalCUDACluster verbindet jeden Dask-Worker mit einer eigenen GPU, damit der Scheduler die Arbeit ausgleichen kann.
Erstellen einer mehrstufigen Dask-Pipeline, die zu oft neu berechnet wird.
Verfassen Sie "lazy" und rufen Sie .compute() einmal am Ende auf; verwenden Sie persist(), um wiederverwendete Zwischenergebnisse im GPU-Speicher zu cachen.
Warum: Dask ist "lazy" – das zu frühe oder wiederholte Auslösen von Berechnungen wiederholt die Arbeit.
Schiefe Partitionen führen dazu, dass einige GPU-Worker zurückbleiben.
Neu partitionieren Sie in ausgewogene Größen und richten Sie Partitions-Schlüssel an nachfolgenden Joins/Groupbys aus.
Warum: Ungleichmäßige Partitionen erzeugen Nachzügler, die den gesamten Job ausbremsen.
Halten Sie einen ETL → train → score Workflow vollständig auf der GPU.
Verketten Sie die cuDF-Vorbereitung mit cuML/XGBoost, ohne zwischendurch in pandas zu konvertieren, und halten Sie die Daten auf dem Gerät resident.
Warum: Jede CPU-Roundtrip verursacht Übertragungskosten; das Verbleiben auf dem Gerät bewahrt die Beschleunigung von Anfang bis Ende.
Benötigt einen Workflow, der zur Überprüfung identisch wiederholt wird.
Fixieren Sie RAPIDS-/CUDA-Versionen, setzen Sie Zufalls-Seeds und parametrieren Sie Eingaben, damit die Pipeline deterministisch und wieder ausführbar ist.
Berechnen Sie zusammenfassende Statistiken über eine Tabelle mit einer Milliarde Zeilen.
Verwenden Sie cuDF describe/mean/std/quantile und corr; Aggregationen laufen als GPU-Kernel.
Streudiagramm von 100 Millionen Punkten überlagert sich und ist unlesbar.
Rendern Sie mit Datashader, das die Punkte auf der GPU in ein Dichtebild rastert, anstatt jeden Marker zu zeichnen.
Warum: Datashader aggregiert zu Pixeln, sodass die Plot-Kosten durch die Bildgröße begrenzt sind, nicht durch die Punktanzahl.
Benötigt ein interaktives Cross-Filtering-Dashboard über einem riesigen GPU DataFrame.
Verwenden Sie cuxfilter, um Diagramme mit GPU-beschleunigtem Cross-Filtering auf cuDF-Daten zu verknüpfen.
Warum: cuxfilter hält die Daten auf dem Gerät, sodass Brushing/Filtering im großen Maßstab interaktiv bleibt.
Visualisieren Sie die Verteilung einer großen numerischen Spalte.
Binden Sie mit cuDF/CuPy auf der GPU, dann plotten Sie das kleine aggregierte Ergebnis mit Plotly oder Matplotlib.
Warum: Zuerst auf der GPU aggregieren; nur die winzige Zusammenfassung muss die Plot-Bibliothek erreichen.
Bewerten Sie Merkmalsbeziehungen vor der Modellierung.
Berechnen Sie df.corr() in cuDF auf der GPU, dann rendern Sie die kleine Matrix als Heatmap.
Möchte deklarative interaktive Diagramme, die auf GPU-Daten basieren.
Kombinieren Sie HoloViews/hvPlot mit Datashader und cuDF für interaktive Visualisierungen mit hohem Volumen.
Rechtfertigen Sie die GPU-Beschleunigung für eine Daten-Workload.
Verwenden Sie GPUs für massiv datenparallele, durchsatzgebundene Operationen über große Datensätze; halten Sie kleine, verzweigte oder latenzempfindliche Arbeiten auf der CPU.
Warum: GPUs gewinnen bei der SIMT-Parallelität über viele Elemente; sie verlieren bei kleinen oder kontrollintensiven Aufgaben.
Erklären Sie, wie RAPIDS Daten über cuDF, CuPy und ML-Bibliotheken hinweg ohne Kopien teilt.
RAPIDS basiert auf dem spaltenorientierten Apache Arrow-Speicherformat, das den Zero-Copy-Austausch zwischen GPU-Bibliotheken ermöglicht.
Warum: Ein gemeinsames spaltenorientiertes Layout auf dem Gerät ermöglicht es Komponenten, Daten ohne Serialisierung zu übergeben.
Eine Pipeline ist GPU-beschleunigt, aber kaum schneller.
Profilieren Sie die Datenbewegung; wiederholte Host↔Gerät-Kopien dominieren oft. Halten Sie Daten zwischen den Schritten auf der GPU resident.
Warum: PCIe-Übertragung ist die versteckte Steuer – das Minimieren von Kopien ist normalerweise der größte einzelne Gewinn.
Verstehen Sie, was Arbeit auf der GPU ausführt.
CUDA startet Kernel über Tausende von Threads, die unter dem SIMT-Modell in Blöcken/Grids gruppiert sind; RAPIDS-Bibliotheken umschließen diese, sodass Sie selbst selten Kernel schreiben.
Die Workload bricht mit "Out-of-Memory" auf einer einzelnen GPU ab.
Reduzieren Sie dtype-Größen, verarbeiten Sie in Blöcken oder skalieren Sie mit Dask; GPU VRAM ist weitaus kleiner als Host-RAM.
Warum: Gerätespeicher ist die erste Einschränkung in der GPU-Data-Science – planen Sie darum herum.
Ordnen Sie eine CPU-Data-Science-Aufgabe der richtigen RAPIDS-Bibliothek zu.
cuDF für DataFrames, cuML für ML, cuGraph für Graphen, cuSpatial für Geodaten, Dask für Skalierung.
Muss viele Trainingsläufe und deren Metriken vergleichen.
Protokollieren Sie Parameter, Metriken und Artefakte in MLflow Tracking; Abfragen und Vergleichen von Läufen über die UI.
Warum: Zentralisiertes Experiment-Tracking macht Ergebnisse über Läufe hinweg reproduzierbar und vergleichbar.
Möchte Live-Dashboards und teamübergreifend geteilte Experimentprotokolle.
Verwenden Sie Weights & Biases (wandb.init/log), um Metriken zu streamen und visuelle Experiment-Dashboards zu teilen.
Verfolgen Sie, welches trainierte Modell in Staging vs. Produktion ist.
Registrieren Sie Versionen in der MLflow Model Registry und fördern Sie sie mit Metadaten durch die Stufen.
Warum: Ein Register bietet eine einzige Quelle der Wahrheit für Modellherkunft und -förderung.
Ein Modell kann Monate später nicht reproduziert werden.
Versionieren Sie Daten, Code, Umgebung und Seeds zusammen; protokollieren Sie die vollständige Konfiguration mit jedem Lauf.
Warum: Reproduzierbarkeit erfordert die Erfassung aller vier – Code allein ist nicht ausreichend.
Bewegen Sie ein trainiertes Modell in Richtung Bereitstellung.
Verpacken Sie das Modell und die Abhängigkeiten (z. B. Container-Image) und stellen Sie dann Batch- oder REST-Inferenz bereit; verwenden Sie FIL für schnelles GPU-Baum-Scoring.
Ordnen Sie Knoten nach Einfluss in einem großen Graphen.
Erstellen Sie einen cuGraph-Graphen aus einer Kantenliste und führen Sie cugraph.pagerank auf der GPU aus.
Warum: cuGraph führt PageRank, BFS und Zentralität auf Graphen aus, die für CPU-Bibliotheken zu groß wären.
Finden Sie Cluster/Gemeinschaften in einem Netzwerkdatensatz.
Verwenden Sie cuGraph connected-components oder Louvain; nehmen Sie Kanten aus einem cuDF DataFrame auf.
Daten sind hochdimensional und größtenteils Nullen.
Verwenden Sie GPU-Sparse-Formate (CSR/COO über CuPy sparse) anstelle von dichten Arrays, um den Speicherbedarf zu reduzieren und die Berechnung zu beschleunigen.
Warum: Sparse-Speicherung vermeidet die Verschwendung von VRAM und Kernels für Nulleinträge.
Richten Sie eine funktionierende RAPIDS-Umgebung ein.
Installieren Sie über conda, pip oder Docker unter Verwendung des RAPIDS Release Selector, um Ihre CUDA-/Python-Versionen abzugleichen.
Warum: Der Selector fixiert kompatible Paket-Builds, die häufigste Ursache für Installationsfehler.
RAPIDS-Import schlägt fehl oder sieht nach der Installation keine GPU.
Verifizieren Sie, dass die NVIDIA-Treiber- und CUDA-Toolkit-Versionen die RAPIDS-Build-Anforderungen erfüllen; führen Sie nvidia-smi aus, um die GPU zu bestätigen.
Warum: Treiber-/CUDA-Diskrepanz ist die Hauptursache für "no CUDA device"-Fehler.
Möchte eine reproduzierbare, vorkonfigurierte RAPIDS-Umgebung.
Ziehen Sie den RAPIDS-Container von NVIDIA NGC; er enthält passende CUDA, Treiber und Bibliotheken.
Warum: NGC-Images eliminieren das Rätselraten bei der Versionsanpassung und standardisieren die Umgebung auf verschiedenen Maschinen.