现有的 40 GB CSV 上的 pandas 管道在 CPU 上运行过慢。
用 cuDF 替换 pandas；大多数读取/过滤/分组/连接操作调用保持相同的 API 并在 GPU 上运行。
原因: cuDF 在设计上与 pandas API 保持一致，因此迁移主要是一个导入更改而非重写。
最后审核：2026年6月
NCA-ADS 考试涉及的架构模式快速参考。从头到尾阅读，或跳转到任意章节。
现有的 40 GB CSV 上的 pandas 管道在 CPU 上运行过慢。
用 cuDF 替换 pandas；大多数读取/过滤/分组/连接操作调用保持相同的 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 读取速度快得多。
cuDF 在处理 50 MB 文件时比 pandas 慢。
将小数据保留在 CPU 上；在数据量低于约 1-2 GB 时，主机到设备的传输和内核启动开销占主导地位。
原因: GPU 加速在大规模数据上才显示出优势；对于小数据，复制成本超过了计算收益。
按键聚合数十亿行数据，并计算多个统计量。
在 cuDF 中使用 df.groupby(key).agg({...})；聚合作为并行的 GPU 内核运行。
在 GPU 规模上清理和规范化高基数文本列。
使用 cuDF's .str 访问器（lower, strip, replace, contains, split）；字符串操作通过 libcudf 在 GPU 上加速。
原因: cuDF 具有专用的 GPU 字符串层，因此文本清理无需回退到 CPU。
在共享键上连接两个大型设备 DataFrame。
使用 cudf.merge / df.merge 和连接键；哈希连接在 GPU 上执行。
原因: 两个帧必须已经在设备上以避免往返；混合使用 pandas 和 cuDF 会强制进行主机复制。
数据集中存在缺失值，导致下游 cuML 训练中断。
在拟合之前使用 cuDF fillna/dropna 和显式 dtype 转换；cuML 期望干净的数值设备数组。
混合/对象 dtype 在 cuDF 中导致错误或内存膨胀。
尽早转换为紧凑的数值或分类 dtype (int32/float32, category)，以减小 GPU 内存占用。
原因: 降级类型可减少设备内存压力，这是单个 GPU 上最常见的瓶颈。
在训练前需要对分类特征进行标签/独热编码。
使用带有 .cat.codes 的 cuDF 分类 dtype 或 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 上训练过慢。
使用 device="cuda" (tree_method="hist") 训练 XGBoost；它直接消费 cuDF/CuPy 数据。
原因: XGBoost 的原生 GPU 直方图方法可大幅加速并与 RAPIDS 紧密集成。
快速聚类数百万个点用于分割。
使用 cuML KMeans（或用于基于密度的 DBSCAN）；两者都完全在 GPU 上运行。
将高维数据降维到 2D 以进行大规模可视化。
使用 cuML UMAP 或 t-SNE；GPU 实现可以处理在 CPU 上不切实际的数据集。
原因: UMAP/t-SNE 计算量大；GPU 版本使得交互式规模的嵌入成为可能。
需要一个带有特征重要性的精确集成分类器。
使用 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 分布。
想在一台多 GPU 机器上使用所有 GPU。
从 dask-cuda 启动一个 LocalCUDACluster 并连接一个 Client；每个 GPU 绑定一个 worker。
原因: LocalCUDACluster 将每个 Dask worker 连接到独立的 GPU，以便调度器可以平衡工作。
构建一个多步 Dask 管道，但它计算过于频繁。
惰性组合并在最后调用一次 .compute()；使用 persist() 将重复使用的中间结果缓存到 GPU 内存中。
原因: Dask 是惰性的 — 过早或重复触发计算会重复工作。
倾斜的分区导致某些 GPU worker 滞后。
重新分区为平衡大小，并将分区键与下游的连接/分组对齐。
原因: 不均匀的分区会产生滞后者，从而成为整个作业的瓶颈。
将 ETL → 训练 → 评分工作流完全保留在 GPU 上。
将 cuDF 准备工作链式连接到 cuML/XGBoost，期间不转换为 pandas，将数据保留在设备上。
原因: 每次 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 并行性方面表现出色；在小型或控制密集型任务上则不然。
解释 RAPIDS 如何在 cuDF、CuPy 和 ML 库之间无需复制地共享数据。
RAPIDS 基于 Apache Arrow 列式内存格式构建，实现了 GPU 库之间的零拷贝交换。
原因: 共享的设备上列式布局允许组件无需序列化即可传递数据。
一个管道经过 GPU 加速但速度提升微乎其微。
分析数据移动；重复的主机↔设备复制通常占据主导地位。在步骤之间将数据保留在 GPU 上。
原因: PCIe 传输是隐性成本 — 最小化复制通常是最大的单一收益。
理解在 GPU 上执行工作的方式。
CUDA 在 SIMT 模型下，将内核启动到成千上万个分组为块/网格的线程中；RAPIDS 库封装了这些，因此你很少需要自己编写内核。
工作负载在单个 GPU 上因内存不足而报错。
减小 dtype 大小，分块处理，或使用 Dask 进行扩展；GPU 显存远小于主机内存。
原因: 设备内存是 GPU 数据科学的首要限制 — 设计时需围绕其考虑。
将 CPU 数据科学任务映射到正确的 RAPIDS 库。
cuDF 用于 DataFrames，cuML 用于机器学习，cuGraph 用于图，cuSpatial 用于地理空间，Dask 用于横向扩展。
需要比较多个训练运行及其指标。
将参数、指标和工件记录到 MLflow Tracking；从 UI 查询和比较运行。
原因: 集中式实验跟踪使结果在不同运行之间可重现和可比较。
想要实时仪表板和团队共享的实验日志。
使用 Weights & Biases (wandb.init/log) 流式传输指标并共享可视化实验仪表板。
跟踪哪个训练模型是预生产版本还是生产版本。
在 MLflow 模型注册表中注册版本，并通过元数据在不同阶段进行推广。
原因: 注册表为模型沿袭和推广提供了单一的事实来源。
几个月后无法复现某个模型。
版本化数据、代码、环境和种子；每次运行时记录完整配置。
原因: 可重现性需要捕获所有四个要素 — 仅有代码是不够的。
将训练好的模型投入服务。
打包模型和依赖项（例如，容器镜像），然后暴露批量或 REST 推理；使用 FIL 进行快速 GPU 树评分。
在一个大型图中按影响力对节点进行排名。
从边列表构建一个 cuGraph Graph，并在 GPU 上运行 cugraph.pagerank。
原因: cuGraph 在对于 CPU 库来说过大的图上运行 PageRank、BFS 和中心性算法。
在网络数据集中查找集群/社区。
使用 cuGraph 连通分量或 Louvain 算法；从 cuDF DataFrame 摄取边。
数据是高维且大部分为零的。
使用 GPU 稀疏格式（通过 CuPy sparse 的 CSR/COO）而不是密集数组，以适应内存并加速计算。
原因: 稀疏存储避免了在零元素上浪费显存和内核。
设置一个可用的 RAPIDS 环境。
使用 RAPIDS 发布选择器通过 conda、pip 或 Docker 安装，以匹配你的 CUDA/Python 版本。
原因: 选择器会固定兼容的软件包构建版本，这是安装失败最常见的来源。
安装后 RAPIDS 导入失败或未检测到 GPU。
验证 NVIDIA 驱动程序和 CUDA 工具包版本是否满足 RAPIDS 构建要求；运行 nvidia-smi 确认 GPU。
原因: 驱动程序/CUDA 不匹配是导致“无 CUDA 设备”错误的首要原因。
想要一个可重现、预配置的 RAPIDS 环境。
从 NVIDIA NGC 拉取 RAPIDS 容器；它附带匹配的 CUDA、驱动程序和库。
原因: NGC 镜像消除了版本匹配的猜测工作，并标准化了跨机器的环境。