본문으로 건너뛰기

여러 GPU로 수억 벡터 UMAP을 8분에 처리

cuML과 cuVS가 UMAP의 kNN 그래프 구축을 여러 H100 GPU로 분산해 MIRACL 106M 벡터를 8분에 처리했다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

NVIDIA cuML과 NVIDIA cuVS 25.06은 UMAP의 가장 비싼 all-neighbors kNN graph 구축을 여러 NVIDIA GPU에 분산해 단일 GPU 메모리를 넘는 수천만~수억 벡터 데이터셋을 처리합니다. 데이터는 균형 잡힌 cluster로 나뉘고, 인접 cluster의 벡터를 겹쳐 각 GPU가 로컬 그래프를 독립 계산한 뒤 전역 그래프로 합치므로 all-to-all 통신 부담을 피합니다. knn_n_clusters는 GPU별 메모리 사용량을 낮추고 knn_overlap_factor는 cluster 경계의 이웃 보존을 높이는 방식으로 시간·메모리·품질을 조절합니다. 8개 H100 기준 MIRACL 106M × 2048은 8분에 처리됐고 projected CPU 대비 74배, Wiki-all 88M × 768은 6.4분에 처리돼 41배의 속도 차이를 기록했습니다. GPU 수를 늘려도 Trustworthiness가 크게 하락하지 않아 대규모 시각화와 반복 분석에 필요한 처리 시간과 embedding 품질을 함께 유지했습니다.

빠른 이해

새로운 점

UMAP training의 all-neighbors kNN graph 구축까지 여러 GPU로 분산해 수백 GB 데이터셋을 단일 GPU 한계를 넘어 처리하는 NVIDIA cuML·cuVS 25.06 기능이다.

핵심 메커니즘

데이터셋을 균형 잡힌 cluster로 나누고 인접 cluster에 벡터를 중복 배정한 뒤, 여러 GPU가 각 cluster의 로컬 kNN graph를 독립적으로 계산한다. 각 로컬 graph는 global all-neighbors graph에 병합되며, cluster 간 all-to-all 통신 없이 UMAP embedding 계산에 사용된다. knn_n_clusters는 GPU별 데이터 크기를 낮추고 knn_overlap_factor는 경계 이웃 보존을 높여 메모리·시간·품질의 균형을 조절한다.

핵심 수치

  • MIRACL end-to-end 실행 시간: 8.0분- 106M × 2048 벡터, 8개 NVIDIA H100 GPU
  • MIRACL projected CPU 대비 속도 향상: 74배- projected CPU 590분 대 cuML multi-GPU 8.0분
  • Wiki-all projected CPU 대비 속도 향상: 41배- projected CPU 262분 대 cuML multi-GPU 6.4분
  • Wiki-all 데이터셋: 88M × 768- Figure 2와 Figure 3의 benchmark workload
  • MIRACL 데이터셋: 106M × 2048- Figure 1, Figure 2, Figure 3의 benchmark workload
  • 8 GPU all-neighbors speedup: Wiki-all 약 3.9배, MIRACL 약 4.9배- 1 GPU 대비 speedup

섹션별 상세

01

대규모 UMAP의 병목

UMAP은 탐색적 데이터 분석, topic modeling, single-cell analysis에서 고차원 벡터를 저차원 embedding으로 줄이는 과정에 반복적으로 사용되지만, 데이터가 수천만에서 수억 벡터로 커지면 전체 벡터의 k-nearest neighbors를 찾는 all-neighbors kNN graph 구축이 핵심 병목이 됩니다. 기존 NVIDIA cuML의 Out-of-Core 방식은 단일 GPU 메모리보다 큰 데이터를 처리했지만 training 단계는 단일 GPU에 묶였고 transform()만 여러 GPU를 사용할 수 있었습니다. NVIDIA cuML과 NVIDIA cuVS 25.06은 이 그래프 구축을 여러 GPU로 분산해 수백 GB 규모 작업을 시간이나 며칠이 아닌 몇 분 단위로 처리하는 경로를 추가했습니다.
02

Cluster 분할과 그래프 병합

전체 데이터셋을 GPU 메모리에 모두 올릴 수 없다는 문제가 balanced cluster 분할과 경계 영역 중복 처리로 바뀝니다. 각 GPU는 CPU 메모리에서 맡은 cluster와 인접 cluster의 벡터를 가져와 로컬 kNN graph를 독립적으로 계산하고, 이를 global all-neighbors graph에 병합합니다. cluster별 계산이 서로 독립적이어서 전역 all-to-all 통신이 필요하지 않으며, MIRACL 106M × 2048 embedding에서도 GPU로 계산한 그래프와 CPU reference UMAP의 전역 구조가 유사하게 유지됐습니다.
03

메모리와 품질을 조절하는 매개변수

cuML multi-GPU UMAP은 knn_n_clusters로 데이터를 나눌 개수를 정하고 knn_overlap_factor로 각 벡터를 가장 가까운 여러 cluster에 얼마나 중복 배정할지 조절합니다. cluster 수를 늘리면 GPU별 입력과 로컬 그래프가 작아지고, overlap factor를 높이면 cluster 경계의 이웃을 더 많이 보존해 kNN recall과 embedding 품질이 개선되지만 중복 처리 때문에 메모리와 시간이 늘어납니다. 문서는 시작값으로 knn_overlap_factor=2를 권장하며, 80 GB GPU에서 N=100M, D=1024 float32 데이터와 k=15인 사례에는 knn_overlap_factor=2와 knn_n_clusters=24를 선택해 cluster 데이터 약 34 GB와 그래프 약 1.5 GB, 합계 약 35.5 GB를 계산하도록 제시했습니다.
python
from cuvs.neighbors import all_neighborsfrom cuvs.common import MultiGpuResources params = all_neighbors.AllNeighborsParams( algo="nn_descent", n_clusters=32, overlap_factor=2) # Using all GPUs on the systemres = MultiGpuResources() indices, distances = all_neighbors.build( data, k, params, distances=cupy.empty((n_rows, k)) resources=res)

NVIDIA cuVS의 all-neighbors API로 32개 cluster와 overlap factor 2를 사용해 모든 GPU에서 kNN 그래프를 구축합니다.

04

cuVS와 cuML 사용 경로

all-neighbors graph는 NVIDIA cuVS에서 독립적으로 만들거나 NVIDIA cuML UMAP 내부 단계로 실행할 수 있습니다. cuVS API에서는 n_clusters=32와 overlap_factor=2를 설정하고 MultiGpuResources()로 시스템의 모든 GPU를 선택한 뒤 indices와 distances를 반환하며, cuML에서는 build_kwds에 같은 설정을 넣고 device_ids="all" 또는 [0, 4, 5]처럼 참여 GPU를 지정합니다. 이미 계산한 indices와 distances를 precomputed_knn에 전달하면 cuML UMAP이 그래프 구축을 반복하지 않으므로 별도 그래프 파이프라인과 UMAP embedding 단계를 연결할 수 있습니다.
python
from cuml.manifold import UMAP # Using all GPUs on the systemumap = UMAP(build_kwds={"knn_n_clusters": 32,"knn_overlap_factor": 2,},device_ids="all",)embedding = umap.fit_transform(data) # Using a subset of GPUsumap = UMAP(build_kwds={"knn_n_clusters": 32,"knn_overlap_factor": 2,},device_ids=[0, 4, 5],)embedding = umap.fit_transform(data)

NVIDIA cuML UMAP에서 모든 GPU를 사용하거나 device_ids로 0, 4, 5번 GPU만 선택해 embedding을 계산합니다.

python
from cuml.manifold.umap import UMAP as cuUMAP # Using indices, distances from Example 1 computed by cuVS all-neighborsgpu_umap = cuUMAP( precomputed_knn=(indices, distances),)gpu_embedding = gpu_umap.fit_transform(data)

cuVS에서 미리 계산한 indices와 distances를 cuML UMAP의 precomputed_knn 인자로 전달해 그래프 구축 단계를 재사용합니다.

05

CPU 대비 대규모 실행 시간

Wiki-all과 MIRACL의 전체 데이터셋은 CPU reference 구현이 2 TiB RAM 환경에서도 메모리 사용량 때문에 완료되지 않아, 작은 subsample에서 측정한 증가 추세로 CPU 시간을 추정했습니다. 8개의 NVIDIA H100에서 실제로 실행한 cuML multi-GPU UMAP은 Wiki-all 88M × 768을 6.4분에 처리해 추정 CPU 262분 대비 41배 빠르고, MIRACL 106M × 2048을 8.0분에 처리해 추정 CPU 590분 대비 74배 빠른 결과를 기록했습니다. CPU 값은 전체 실행 측정치가 아니라 subsample scaling을 외삽한 projected runtime이므로, GPU와의 비교는 이 산정 방식에 기반합니다.
Wiki-all과 MIRACL에서 CPU UMAP의 측정·추정 실행 시간과 8개 H100 기반 cuML UMAP의 전체 실행 시간을 비교한 차트입니다.
Chart상단 차트는 데이터셋 크기가 커질수록 CPU UMAP 실행 시간이 빠르게 증가하고, 전체 규모에서는 측정 대신 subsample scaling 외삽으로 시간을 추정했음을 나타냅니다. 하단 차트는 Wiki-all 88M × 768에서 추정 CPU 262분과 GPU 6.4분, MIRACL 106M × 2048에서 추정 CPU 590분과 GPU 8.0분을 비교하며 각각 41배와 74배의 차이를 표시합니다. GPU 시간은 8개 H100에서 전체 데이터셋을 실제 실행한 값이고 CPU 시간은 projected runtime이라는 점이 비교의 조건입니다.
06

GPU 수 증가와 embedding 품질

1개에서 8개의 H100으로 GPU 수를 늘리면 Wiki-all의 all-neighbors 단계 포함 end-to-end 시간은 약 1,070초에서 약 380초로, MIRACL은 약 1,800초에서 약 480초로 감소하는 흐름을 보였습니다. all-neighbors graph 자체의 1 GPU 대비 speedup은 8 GPU에서 Wiki-all 약 3.9배, MIRACL 약 4.9배까지 높아졌고, 두 데이터셋 모두 GPU 수 증가에 따라 Trustworthiness가 크게 무너지지 않았습니다. 따라서 이 구현은 단순히 그래프 계산만 빠르게 하는 것이 아니라, 수억 벡터의 시각화와 반복 분석에서 실행 가능한 시간과 embedding의 국소 이웃 보존을 함께 겨냥합니다.
MIRACL 데이터셋에서 CPU UMAP과 GPU all-neighbors graph를 사용한 UMAP, 그리고 cuML native GPU UMAP의 2차원 embedding을 나란히 비교한 산점도입니다.
Chart두 산점도는 회전, 이동, 크기 차이는 있지만 중앙의 밀집 영역과 주변 군집 등 전역 구조가 유사합니다. UMAP은 scale, translation, rotation에 불변이므로 시각적 좌표가 정확히 겹치지 않아도 이웃 구조가 보존되면 기능적으로 같은 embedding으로 판단할 수 있습니다. 이 결과는 GPU에서 미리 계산한 all-neighbors graph가 106M × 2048 MIRACL 데이터셋의 CPU reference UMAP에 필요한 이웃 관계를 유지했음을 뒷받침합니다.
Wiki-all과 MIRACL에서 GPU 수에 따른 UMAP end-to-end 시간, all-neighbors graph 비중, Trustworthiness, 그리고 1 GPU 대비 speedup을 묶어 나타낸 차트입니다.
Chart두 데이터셋 모두 GPU 수를 1개에서 8개로 늘릴수록 전체 실행 시간이 줄고, 초록색으로 표시된 all-neighbors graph 처리 시간이 주요 비중을 차지하면서 함께 감소합니다. 하단 speedup 차트에서는 8 GPU에서 Wiki-all이 약 3.9배, MIRACL이 약 4.9배의 all-neighbors speedup에 도달합니다. 주황색 Trustworthiness 선은 GPU 수가 늘어도 큰 폭으로 하락하지 않아 분산 계산이 embedding의 국소 이웃 보존을 심각하게 훼손하지 않았음을 나타냅니다.

용어 해설

UMAP 차원 축소(UMAP)
UMAP은 고차원 벡터의 이웃 관계를 저차원 공간에 보존해 시각화나 특징 추출에 활용하는 차원 축소 기법입니다. 먼저 각 벡터의 k-nearest neighbors 그래프를 만들고, 이 그래프를 바탕으로 저차원 embedding을 계산합니다. 데이터가 커질수록 그래프 구축 비용이 전체 실행 시간을 크게 좌우합니다.
전체 이웃 kNN 그래프(All-neighbors kNN Graph)
전체 데이터셋의 각 벡터에 대해 가장 가까운 k개 벡터를 연결한 그래프입니다. UMAP은 이 그래프에서 원래 공간의 국소 이웃 구조를 얻은 뒤 저차원 embedding을 계산합니다. 데이터셋을 여러 cluster로 나누고 경계 주변 벡터를 겹쳐 처리하면 GPU 메모리보다 큰 데이터도 분산 구축할 수 있습니다.
Out-of-Core 처리(Out-of-Core Computing)
전체 데이터가 GPU 메모리에 한 번에 들어가지 않을 때 데이터를 여러 cluster로 나누어 CPU 메모리에서 필요한 부분만 GPU로 가져오는 처리 방식입니다. 각 GPU가 일부 cluster의 로컬 그래프를 계산한 뒤 결과를 전역 그래프로 합칩니다. 이 구조는 대규모 데이터의 메모리 요구량을 낮추면서 계산을 병렬화합니다.
Trustworthiness 점수(Trustworthiness)
저차원 embedding이 원래 고차원 공간의 국소 이웃 관계를 얼마나 보존하는지 나타내는 평가 지표입니다. 값의 범위는 0에서 1이며 높을수록 원래 이웃 구조가 더 잘 유지됩니다. 다중 GPU 수를 늘릴 때 실행 시간뿐 아니라 이 점수도 함께 비교해 embedding 품질 저하 여부를 판단합니다.
knn_overlap_factor
데이터 포인트를 가장 가까운 cluster 몇 곳에 중복 배정할지 정하는 매개변수입니다. 값을 높이면 cluster 경계에 걸친 실제 이웃을 더 많이 보존해 kNN 그래프와 UMAP 품질을 높일 수 있지만, 중복 데이터 처리로 메모리 사용량과 계산 시간이 함께 증가합니다.
knn_n_clusters
데이터셋을 몇 개의 균형 잡힌 cluster로 나눌지 정하는 매개변수입니다. cluster 수를 늘리면 각 GPU가 처리할 벡터 수와 메모리 요구량이 줄어듭니다. 반면 overlap factor와 함께 설정해야 cluster 경계의 이웃 보존과 전체 계산 비용 사이의 균형을 맞출 수 있습니다.

기술

  • NVIDIA cuML
  • NVIDIA cuVS
  • UMAP
  • kNN
  • Python
  • CUDA-X
  • RAPIDS
  • H100
  • DGX
  • nn_descent
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

수집 2026. 08. 19.출처 타입 WEB

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.