cuGraph는 모든 기능을 갖춘 강력한 그래프 분석 라이브러리 제품군입니다. 핵심 cuGraph 라이브러리에는 약 30개의 알고리즘이 포함되어 있으며, 대부분의 알고리즘은 대규모 GPU 클러스터로의 확장을 지원합니다. 예를 들어, cuGraph PageRank 알고리즘은 2,048개의 GPU에 분산된 4조 4천억 개의 에지 그래프에서 테스트되었습니다. 그 규모에서도 단일 PageRank 반복은 1.5초밖에 걸리지 않았습니다. 최근 cuGraph는 가속화된 애그리게이터, 가속화된 모델, 그리고 DGL과 PyG에 대한 확장을 통해 GNN에 대한 지원을 추가했습니다.
한국어 또는 영어 등 원하는 언어로 아래 댓글 섹션에 있는 “forums.developer.nvidia.com 에서 토론을 시작하세요.” 텍스트를 클릭 후 cuGraph에 관한 질문을 남겨주시면 엔지니어링 팀과 함께 하는 AMA(Ask Me Anything)에 참여할 수 있습니다. 이번 블로그에서는 16개의 cuGraph :그래프 분석 및 GNN 카테고리 관련 Q&A를 살펴볼 수 있습니다.
Q : cuGraph는 GNN을 어떻게 지원하나요?
A: cuGraph는 최대 수조 개의 에지에 이르는 다양한 그래프 알고리즘에서 확장 가능한 성능을 제공합니다. cuGraph-DGL 및 cuGraph-PyG 패키지를 사용하면 최소한의 코드 변경으로 DGL 또는 PyG의 백엔드 역할을 할 수 있습니다. 또한, cuGraph-ops 모델(예: CuGraphSAGEConv, CuGraphGATConv)은 DGL과 PyG에 직접 통합되어 기본 DGL 및 PyG 모델보다 빠른 성능을 제공합니다. 또한, cuGraph는 그래프 샘플링을 가속화하여 여러 노드와 여러 GPU에서 대규모 그래프를 훈련할 수 있습니다.
Q : 데이터 구조는 어떻게 되나요?
A: 저희는 cuGraph 내에서 CSR 및 COO 입력 형식을 지원합니다. 내부적으로는 그래프 프리미티브와 알고리즘 사용에 최적화된 DCSR 하이브리드 형식으로 데이터를 다시 포맷합니다. 또한 버텍스/에지 마스킹/삽입/삭제와 같은 기능을 지원하기 위해 그래프 데이터 구조를 업데이트할 계획입니다.
Q: cugraph-dgl는 무엇인가요?
A: cugraph-dgl은 노드 분류, 링크 예측, 그래프 분류와 같이 그래프 연산과 GNN 모델링이 모두 필요한 그래프 분석 작업에 특히 유용합니다. cuGraph의 효율적인 그래프 연산과 DGL의 확장 가능한 GNN 모델링이 결합되어 대규모 그래프 데이터에 대해 빠르고 정확하게 GNN을 훈련할 수 있습니다.
전반적으로 cugraph-dgl은 GPU 가속 하드웨어에서 그래프 분석 및 GNN 모델링을 위한 강력한 도구로, 그래프 기반 머신 러닝 애플리케이션을 위한 포괄적인 솔루션을 제공합니다.
Q: 그래프 파티셔닝 – 오프라인, 온라인 기술?
그래프 분할은 어떻게 하나요? 오프라인(시간이 무한한 경우) 기법과 온라인(그래프를 처음 보는 경우, 빠르게 수행해야 하는 경우) 기법이 있나요?
A: 저희는 정점 무작위화(해시 함수 사용) 기반의 2D 파티셔닝을 사용합니다. 이는 그래프 업데이트에 빠르고 강력합니다. 현재 더 정교한 파티셔닝 방식을 사용하지는 않지만, 필요하다면 기본 파티셔닝을 더 복잡한 전략으로 대체할 수 있습니다(아직 그럴 필요는 없다고 생각합니다). 또는 그래프 파티셔닝이 기능으로 필요한 경우 알려주시기 바랍니다.
Q: cuGraph 와 Sparse Matrices
cuGraph와 다른 CUDA 라이브러리의 관계에 대해 궁금합니다. 현재 제 작업은 지오메트리 서피스 메쉬를 위해 cuSparse와 cuSolver에 크게 의존하고 있습니다. cuGraph가 스파스 인접 행렬을 입력으로 수용할 수 있나요? cuSparse의 확장으로 사용할 수 있나요?
A: cuGraph는 cuSparse 및 cuSolver와 호환이 가능합니다. COO 및 CSR/CSC 입력을 받아 해당 구조에 대해 그래프 알고리즘을 실행할 수 있습니다. 하지만 해당 패키지와 직접 통합되지는 않습니다. 내부 형식은 그래프 프리미티브 라이브러리에 최적화되어 있으므로 이러한 알고리즘을 실행하기 위해 cuSparse 및 cuSolver 입력의 복사본을 만듭니다. 마찬가지로, (적절한 경우) 출력을 COO 또는 CSR 구조로 변환하여 cuSparse와 cuSolver로 다시 전달할 수 있습니다.
Q: 그래프에 부착된 데이터 관련
범위는 매우 다양하겠지만, 정점(Vertices)과 가장자리(Edges)에 첨부되는 데이터의 종류와 크기는 어느 정도인가요? 학계에서는 에지당 가중치(float)와 같은 것 이상을 거의 사용하지 않지만, 실제로는 훨씬 더 크고 흥미로운 보조 데이터(Auxiliary data)가 있을 수 있다고 상상할 수 있습니다. 이러한 데이터는 연결 정보와 별도로 저장되나요? 첨부 데이터에는 어떤 종류의 데이터 구조를 사용하나요?
A: 단순한 정수부터 전체 텐서까지 모든 유형의 데이터를 지원합니다.
저희 알고리즘은 모든 종류의 에지 및 노드 속성과 여러 속성을 동시에 지원할 수 있을 만큼 충분히 범용적입니다. 일반적인 경우, 데이터는 일반적으로 cudf 또는 dask_cudf와 같은 데이터 프레임에 저장됩니다. 이것이 엣지 데이터인 경우, 일반적으로 익숙한 “SRO” 모델(소스, 관계, 객체)을 따르는 src id와 dst id로 연결성이 제공됩니다. cuGraph는 기본적으로 가중치, 엣지 ID, 엣지 유형과 같은 추가 엣지 프로퍼티도 지원합니다. 또한, 다양한 알고리즘을 실행할 수 있는 구조적 cuGraph 그래프를 추출하기 전에 특징과 연결성을 모두 저장할 수 있는 속성 그래프도 제공합니다.
특히 GNN의 경우 텐서를 효율적으로 저장할 수 있는 기능 저장소(feature store)을 사용하는 것이 좋습니다.
Q: UVM 지원이 가능한가요?
A: 예, RMM(래피드 메모리 매니저)을 통해 단일 GPU 및 멀티 GPU 워크플로 모두에 관리형 메모리 사용을 지원합니다. 물론 관리형 메모리를 사용한 성능은 디바이스 메모리를 사용한 성능만큼 높지는 않습니다. 또한 cuDF에는 미리 할당된 메모리 청크인 RMM 풀로 작업할 때 매우 유용할 수 있는 스필링(Spilling) 기능이 있습니다. 마지막으로 멀티 GPU 워크플로우의 경우 dask에는 구성할 수 있는 자체 스필링 기능이 있습니다. GPU 워크플로우에서 호스트 메모리 사용을 더욱 확대하기 위한 추가 연구도 진행 중입니다.
Q: Runtime Decisions
cuGraph는 특정 작업을 처리하기 위한 최적의 병렬화 전략을 결정하기 위해 다양한 그래프/입력 속성을 기반으로 런타임 결정을 내리나요, 아니면 사용자가 결정해야 하나요?
A: 예, 주로 평균 버텍스 도(vertex degree)와 GPU 수를 고려하여 엣지 소스/대상 속성 값을 인접한 배열 또는 (키, 값) 쌍으로 캐시할지 여부를 결정합니다. 보다 자세한 답변은 Analyzing Multi-trillion Edge Graphs on Large GPU Clusters: A Case Study with PageRank | IEEE Conference Publication | IEEE Xplore에서 확인할 수 있습니다. 핵심 아이디어를 간단히 요약하면, 2D 파티셔닝을 사용하고 V개의 정점과 P개의 GPU를 가정할 때 에지 소스/대상 값의 범위는 V/sqrt(P)로 확장됩니다. 에지가 E개라고 가정하면 파티션당 에지 수는 E/P입니다. 그리고 E/P 이하의 소스/대상 속성 값에 액세스합니다. E/P가 V/sqrt(P)보다 작으면 에지 소스/대상 속성 값을 (키, 값) 쌍으로 저장하면 메모리를 절약할 수 있습니다. 그렇지 않으면 연속된 메모리에 저장하는 것이 공간과 시간 모두에서 더 효율적입니다. 또한 여러 곳에서 동시성/메모리 풋프린트 절충점을 찾습니다.
Q: cuGraph 와 엔티티 정렬 모델
안녕하세요, 그래프에 대한 일부 엔티티 정렬 모델(Entity alignment models, 예: RDGCN)을 cuGraph에서 구현할 수 있는지 알고 싶습니다.
A: 현재로서는 엔티티 정렬 모델을 지원하지 않지만, 사용자/고객이 요청하는 대부분의 모델을 점진적으로 추가하고 있습니다.
Q: cuGraph는 그래프 컨볼루션 네트워크(GCN)를 지원하나요?
A: 예, cuGraph는 GNN을 지원하며, GPU 샘플링 메서드와 메시지 전달/집계 기능도 지원합니다.
저희는 pylibcugraphops(cugraph-ops)라는 별도의 패키지를 통해 가속화된 GNN conv 레이어를 제공합니다. 지금까지 GraphSAGE, GAT, RGCN 모델을 지원합니다.
Q: 작은 그래프에서 분석을 만들었는데, 분석을 큰 그래프로 확장하는 것이 얼마나 쉬운가요?
A: 파이썬 레이어에서 cuGraph는 작업/데이터를 여러 GPU에 분산하기 위해 dask를 활용합니다. 이러한 전환을 위해서는 dask 클러스터를 설정해야 하며 MG API는 SG API와 거의 일치합니다. 자세한 내용은 여기에서 확인하세요 – cugraph 23.02.00 documentation.
Q: 다이나믹 그래프 ?
사용자가 그래프를 동적으로 변경해야 하는 시나리오를 접한 적이 있나요? 어떤 시나리오인가요? 예를 들어, 사용자가 기존 그래프가 큰데 에지 삽입 또는 삭제와 같은 수정 사항이 스트리밍되는 경우인가요? 어떤 애플리케이션 및/또는 어떤 알고리즘이 실행되고 있나요?
A: 많은 고객들이 동적 그래프(dynamic graph)의 개념에 대해 논의해 왔습니다. 크게 두 가지 경향이 있습니다:
– 시간 속성이 있는 고정 그래프로, 다양한 시간 창에 따라 데이터를 필터링하는 알고리즘을 실행합니다.
– 시간이 지남에 따라 그래프가 실제로 업데이트되는 그래프. 즉, 그래프를 만들고 해당 그래프에 대해 몇 가지 알고리즘을 실행한 다음 더 많은 알고리즘을 실행하기 전에 그래프에서 에지를 추가/업데이트/삭제하고자 합니다. 동적 그래프에 관심을 갖고 있는 금융 분야와 사이버 보안 분야의 고객들이 있습니다. 이들 대부분은 추론을 수행하고, 새로운 금융 또는 사이버 거래를 추가한 다음, 더 많은 추론을 수행하는 GNN 워크플로우를 실행하기 위한 것입니다.
저희는 이를 구현하기 위한 옵션을 찾고 있습니다.
Q: 그래프 특성 및 분류?
고객은 반드시 모든 종류의 입력 그래프를 요청할 것으로 생각됩니다. 실제로 현장에서 확인하고 있으신 그래프의 종류에 대해 대략적인 분류법을 알려주실 수 있나요? 예를 들어, 한 범주에는 스케일이 없고 입력 정도가 광범위하고 편차가 큰 소셜 네트워크 그래프가 있고, 다른 범주에는 평면적이고 정도가 작고 편차가 거의 없는 도로 네트워크 그래프가 있다고 말할 수 있습니다. 표시되는 그래프의 종류를 어떻게 특징짓나요? bi/N-partite 그래프와 멀티 그래프의 사용 사례에 대해 개략적으로 설명해 주시겠어요? 예를 들어, 사람들이 그래프를 어떻게 보나요? Partite 그래프를 위한 데이터 구조가 특화되어 있나요? 멀티 그래프에 대해 “에지 ID를 지원하기 위해 데이터 구조를 증강(augment)”할 수 있나요? COO/CSR을 확장하고 있나요, 아니면 이것이 차단된 데이터 구조에 포함되나요?
A: 저희는 다양한 고객과 협력하고 있기 때문에 다양한 그래프 유형을 볼 수 있습니다. 대부분의 그래프는 속성이 있든 없든 power-law 그래프로 분류할 수 있습니다. 하지만 bipartite 그래프와 N-partite 그래프도 많이 볼 수 있습니다. 도로망처럼 보이는 그래프, 지름이 크고 평균 정도가 낮은 그래프를 말합니다. 또한 multi 그래프의 수가 증가하고 있으며, 에지 ID를 지원하기 위해 데이터 구조를 보강해야 했습니다.
다양한 그래프 유형을 일일이 세어보지는 못했지만, 이는 매우 좋은 일입니다.
Bipartite 그래프는 리테일과 사이버 분야에서 많이 등장합니다. 소매업에서는 고객과 제품을 매핑하는 것입니다(실제로는 고객과 매장, 제품 유형과 제품, 제품 유형과 제품, 제품과 제품 등
항목 등…N-partite입니다.). 사이버에서는 일반적으로 방화벽 외부의 컴퓨터와 방화벽 내부의 컴퓨터입니다.
Multi 그래프의 경우, 이는 거래가 많아 매 분/시간/일 마다 많은 트랜잭션(엣지)이 발생하는 리테일 및 금융 분야에서 발생합니다. C/CUDA 계층에서는 단일 구조만 있습니다. Python 계층에서는 사용자가 데이터와 상호작용할 수 있도록 도와주는 함수를 추가하여 사용자가 다양한 유형의 그래프와 상호 작용할 수 있도록 지원합니다.
CSR을 증강하는 것과 관련하여, 에지를 반환하는 샘플링 또는 경로 찾기 유형을 실행하면 어떤 에지가 선택되었는지 결정할 수 없다는 문제에 직면했습니다. 그래서 CSR의 심플 가중치 값에서 튜플(tuple)을 지원하도록 확장하여 엣지 ID가 통과할 수 있도록 확장했습니다(엣지 Type 통과도 지원).
Q: cuGraph의 문제점은 무엇인가요?
cuGraph 사용자가 문제를 겪거나 어려움을 겪고 있는 부분은 어디인가요? 예를 들어 “X를 하는 것이 느리다” 또는 “Y를 정말 하고 싶은데 할 수 없다”. 그 X와 Y는 무엇인가요?
A: 다양한 목표와 목적을 가진 다양한 사용자들이 있습니다. 저희가 관찰한 몇 가지 문제점은 다음과 같습니다:
– GPU 메모리 부족. 그래프 알고리즘에는 보조 메모리(auxiliary memory)가 필요한 경우가 많으며, 때때로 충분한 GPU 메모리가 있는지 미리 알 수 없는 경우가 있습니다.
– 멀티 노드-멀티 GPU에서 실행하는 것은 복잡할 수 있습니다. C++ 레이어에서는 mpirun을 사용하여 여러 프로세스를 실행합니다. 파이썬에서 멀티 노드-멀티 GPU에서 실행하는 것은 dask를 통해 이루어집니다. 이러한 도구를 실행할 수 있는 적절한 환경을 만드는 것은 어려운 일입니다.
특히 클라우드 환경에서 실행하는 고객에게는 IB/NVLINK와 같은 멀티 노드 간 빠른 상호 연결에 액세스하는 것이 쉽지 않은 과제입니다.
Q: Dense graph?
Dense Graph의 흥미로운 예(예: 높은 에지 대 버텍스 비율: 대부분의 vertices가 서로 연결되어 있음)를 본 적이 있나요?
A: 저희의 구현은 주로 Sparse 그래프에 맞춰져 있으므로, 대신 고밀도 행렬 라이브러리를 사용하는 것이 좋습니다. 실제로 저희의 구현은 Low degree vertice와 그 속성을 처리하고 저장할 때 추가적인 오버헤드가 발생합니다. 한때 Dense Graph를 위한 Hungarian을 지원하기도 했지만, 더 적합한 패키지(raft)로 이동되었습니다.
Q: cuGrpah는 얼마나 잘 확장되나요?
A: 1000개 이상의 GPU에서 PageRank와 Louvain을 테스트했습니다. 모든 알고리즘을 1000개 이상의 GPU에서 테스트하지는 않았지만, 레거시 구현이 있는 몇 가지 알고리즘을 제외한 다른 많은 알고리즘도 확장할 수 있습니다. 매우 큰 그래프 분석을 실행해야 하는데 관심 있는 알고리즘이 충분히 확장되지 않는 경우, cuGraph 깃허브 페이지에 문제를 제출해 주세요. 더 많은 학술적 참조는 다음 논문 링크를 참조하세요: Analyzing Multi-trillion Edge Graphs on Large GPU Clusters: A Case Study with PageRank | IEEE Conference Publication | IEEE Xplore 3.
이 블로그를 읽어주셔서 감사합니다. 지금 AMA cuGraph에 참여하여 질문을 남겨주시고 cuGraph를 더 쉽게 활용하실 수 있기를 바랍니다! 한국어 또는 영어 등 원하는 언어로 아래 댓글 섹션에 있는 “forums.developer.nvidia.com 에서 토론을 시작하세요.” 텍스트를 클릭 후 질문을 남겨주시면 됩니다!
다음 AMA 주제는 Get3D를 다룰 예정이니 기대해 주세요.
