안녕하세요 pytorch.kr 여러분.
정이태 입니다.
작년 2025년 9월 AMD 이벤트에 선정이 되었고,MI300X를 사용해볼 수 있는 기회를 얻게되었는데요. 그때 제가 무엇을 했으며, 어떤 배움이 있었는지 여러분들과 공유해보려고 합니다.
글에서 다루는 스펙트럼이 넓습니다. 작성하다보니 하드웨어, 그래프 워크로드, 그래프 데이터베이스, 그래프 분석, 그래프 딥러닝, 그래프 RAG 등 여러 콘텐츠들이 포함되어 있더라구요. 넓은 만큼 내용이 얕겠죠?
덕분에, 간단히 읽어보시면서 하드웨어부터 시스템 그리고 애플리케이션까지 어떻게 현재 GraphRAG 씬이 흘러가고 있는지 흐름 파악하시기에 용이할 거 같습니다. 감히 말씀드리지만, 이 모두를 고려한 글은 아직 발견하지 못했기에, 서베이 처럼 읽어보시기에 좋을거 같습니다.
GraphRAG 트렌드부터 워크로드, 실증 분석 및 실험까지 내용이 방대합니다. 단일 포스팅으로는 이를 다 못 담을거란 생각에 총 3부작으로 나누어 매 주 여러분들에게 전달드릴 예정입니다. 3부작 글 구성은 그간 GraphRAG하며 '왜' 라며 계속 반문하던 내용들을 풀어보는 형태로 이루어져 있습니다. 그 중 첫 포스팅인 본 글은 '왜 MI300X?' 라는 큰 물음을 해소해나가는 과정을 그렸습니다. 재밌게 봐주시길 바랍니다.
좋은 경험을 하게 기회를 만들어 주신 Pytorch.kr 운영진 여러분 특히, 박정환님 그리고 AMD 관계자 분들에게 감사 인사드리며, 내용 이어가겠습니다.
MI300X 하드웨어 '잘' 사용하기 위한 최적의 파라미터가 있을텐데...? 어떻게 썼나요?
- Digital Ocean, 번거로운 작업인 환경 셋팅이 GUI로 구성되어 있어, 접근성이 편리했습니다. 몇 가지 옵션을 선택하고 배포 버튼을 누르면 MI300X에 최적화된 vllm 도커 컨테이너가 올라옵니다. 이후, 제공된 포트에 접속하면 주피터 노트북 환경이 기본 설정되어 있어서 자잘한 환경 구성 설정에 어려움을 겪지 않았습니다. 스트레스 없이 바로 MI300X를 활용할 수 있었습니다. 또한, offline, online inference 튜토리얼이 포함되어 있어서 실험해보고 싶은 워크로드가 있다면 Latency, Throughput 테스트하기에도 편리했습니다.
- GraphRAG 파이프라인을 분해해보면 대다수가 LLM 추론 워크로드입니다. 추론 엔진 프레임워크 대명사인 vLLM에 익숙치 않았던 저였기에, 이벤트 선정 이후에 어떻게 셋업을 해야할지 고민이였습니다. 앞서 언급한 바와 같이, 간단히 배포 및 구현할 수 있었습니다.
- 또한, 즉시 결과를 볼 수 있는 주피터 노트북 환경에서 vLLM 사용 스크립트도 구성되어 있어서 온보딩하는데 시간 절약할 수 있었습니다. 참고로, 이때 당시 openai-oss-120B 모델이 나왔던터라 이 모델을 단일 GPU에 올릴 수 있는 디바이스들이 얼마되지 않았습니다. 그 중 하나가 MI300X 였구요.
- 이때, 좋은 디바이스라고 하더라도 모델 가중치와 KVCache 적절한 배분이 있어야만 '잘' 활용할 수 있기에 파라미터 셋업이 고민이였으나, 그 걱정또한 사라졌습니다.
NVIDIA GTC 세션으로부터 시작된 궁금증.
- 우선 정이태라는 사람이 왜 이 이벤트에 신청을 했을까? 를 잠깐 이야기하려고합니다. 다짜고짜, Lesson Leanred 이야기하면 재미도 덜 할거 같고 제가 어떤 호기심이 있었고 이 호기심으로부터 무슨 챌린지를 해결해보려고 했는지 서두에 언급하면 독자분들로 하여금 글 재미가 더하지 않을까 싶어서요.
- Subgraph, Path 그리고 Triplet 등 그래프를 텍스트로 프롬프트에 주입하는 GraphRAG 아키텍쳐 세션들과 다르게 Structure From Chaos: Accelerate GraphRAG With cuGraph and NVIDIA NIM세션에선 Completing a Knowledge Graph 라는 포인트로 GNN(Graph Neural Network)를 직접 언급했습니다.
To verify this, we calculated the ratio of answer entities present in the constructed KG. We found that only around 65.8% of answer entities exist in the constructed KG for the Hotpot dataset and 65.5% for the NQ dataset. These findings highlight a key limitation in KG-based retrieval and suggest the need for improved KG construction methods to enhance graph completeness for QA.
- 또한 RAG vs. GraphRAG: A Systematic Evaluation and Key Insights 에서 언급한 바와 같이 Incompleteness Knowledge graph 는 GraphRAG 의 성능 저하 원인들 중 하나이며 여전히 명확한 해결책이 나와있지 않은 분야입니다.
- NVIDIA에서는 그를 위한 해결책 중 하나로써 열린 세계(Open World) 닫힌 세계(Close World)와 Translation models까지 언급했습니다. 그간, CS224w-Lecture16-Large Language Models and GNNs 와 같은 강의에서 Gretrieval 을 언급했던 행보와 다르게, Triplet 기반 GNN을 이야기했다는게 색다르게 다가왔습니다. 물론 비즈니스 관점에서는 "NIM 플랫폼 위에서 E2E GraphRAG를 모두 할 수 있다."를 간접적으로 암시하는 플랫폼 활성화 유도를 위한 전략 중 하나겠지만요.
- 아무래도 산업계에서 임팩트가 큰 NVIDIA이고, 여기에서 해당 모델을 언급했다는 것만으로도 향후 무슨 일을 내겠다 라는 생각에 이 경험을 가지고 있으면 추후 도움될 거 같다라는 생각이 들더군요. 또한, 예전에 Triplet 기반 GNN을 활용했을때 매번 OOM(Out of memory)를 마주했었어서 정상적인 활용을 해보지 못했었거든요. 이런저런 생각이 겹치던 순간 때마침 이 이벤트를 알게 되었고, 운명이다 싶어 신청합니다.
GraphRAG 텍스트가 아닌, 벡터 형태로 LLM에게 제공하면 어떨까?
- GNN은 그래프 데이터를 벡터 공간에 임베딩하는 기술입니다. 벡터하면 어떤 생각이 떠오르실까요? '컴퓨터'가 이해할 수 있는 언어입니다. 단순 숫자로 구성되어 있지만 속에 그들의 체계가 담겨 있어서 이를 통해 소통하는거죠. 벡터로 변환한 이후부터 이제 저희는 LLM 에게 그래프 정보를 인간의 언어인 자연어가 아닌 숫자로 제공할 수 있게 됩니다.
- 그럼 이를 적극 활용해야 겠죠? 어떤식으로 활용하면 좋을까 하며 여러 선례들을 찾아보던 도중 G-Retrieval 아이디어가 제가 생각하는 방향성과 가장 유사했습니다.
1.Attention Layer 에 그래프 문맥이 담긴 벡터를 직접 주입한다.
2.그래프 데이터 선별과정이 포함되어 있다.
3.Retrieval 과 Storage 가 언급되어 있다.
-> 한 문장으로 요약하면, '잘 보관된 데이터를 잘 선별하여 가져오고 이를 LLM에게 직접 주입하자' 라는 핵심이 담겨있습니다.
- 그래프의 장점은 '연결' 입니다. 데이터간 연결이 되어있으니, 이 연결만 따라간다면 다른 데이터 탐색보다 '연결 따라감'을 기준으로 탐색하기에 상대적으로 비용이 저렴합니다. 하지만 이 '연결'을 만드는게 어렵습니다.
- 소셜 네트워크나 약물과 같이 '연결'이 자연스러운 데이터와 다르게, 실제 조직에서 데이터들은 연결을 가공하는데 어려움이 있습니다. 조직별 연결을 가공하는 사람별로 각자 데이터를 해석하는게 다르기 때문이죠. 때문에, 데이터 거버넌스 도구, 데이터 문맥 보완재인 '온톨로지'를 통해 체계를 만들고 이에 기반하여 연결을 만듭니다.
- 이 온톨로지 기반으로 만들어진 연결로 저희는 데이터간 연관성을 얻게됩니다. 이를 그래프 자료 구조로 변환한게 바로 지식그래프이구요. 그럼 이를 어떻게 활용할 수 있을까요? 여러 방식들이 있겠지만, 저는 LLM 의 어텐션(Attention) 과 주로 대조하며 이야기합니다.
- 좌->우 토큰의 흐름에 따라 정보량이 결정되는 Auto Regressive 어텐션과 다르게, GNN은 앞서 언급한 것처럼 각 조직에서 가지고 있는 문맥인 '온톨로지'를 기반으로 지식그래프를 만들었고, 이를 벡터 공간에 임베딩할 때의 인코더 아키텍쳐에 따라 정보량이 결정됩니다. 때문에, 우리가 만든 연결에 집중하여 정보량이 결정되기에 특정 문맥에 잘못 집중하여 발생하는 환각현상 해소에 도움이 됩니다.
- 이러한, 내용들을 저뿐만아니라 NVIDIA 관계자들 또한 공감하고 해결하고자 시도하고 있으며 그에 부합한 아키텍쳐로써 G-retrieval이 적당하다고 생각하여, 선정했습니다. 우연의 일치인지 마침 NVIDIA 에서도 진행했구요. 때문에,이를 모티브로 삼아서 진행해보자라는 액션 플랜을 세우게 됩니다.
경쟁 구도속에 연달아 제품을 내놓았던 그때, AMD MI300X, NVIDIA H100 Series 차이는 무엇일까?
- Memory Capacity 가 2배 가까이 많고, Memory Bandwidth 또한 2.5배 가까이 좋다는건 Memory bound task 대명사인 그래프에서 함의하는 바가 큽니다. 192TB 과 80TB VRAM에 통상적으로 활용하는 CSR(Compressed Seperated Row) 압축 포멧으로 그래프를 담는다고 가정해보겠습니다.
CSR 포멧에서 row_ptr 을 4 bytes, col_idx 를 4bytes 로, power-law 그래프 분포를 가정하여 |E| ≈ 10 × |V| 계산해보면 대략적으로 개당 84 bytes 라고 잡겠습니다. 이때, H100 은 9.5억개 MI300X 는 22.8억개를 수용할 수 있네요.
만일, H100 에서 수용 공간 이상의 그래프 데이터를 담는다고 할 때, 추가 GPU를 사용해야합니다. 이때 생각되는 worst case 는 Device to Device 통신 비용이 발생하는 case입니다.
- 곱셈을 통해 그래프 탐색을 하는 GraphBLAS 프레임워크 기반 플랫폼을 운영 (Falrkordb) 하고 있는 상황을 가정하고, A와 B 사이에 Shortest Path 유저 질의가 왔을때를 생각해보겠습니다.
- Shortest Path 질의는 GraphBLAS 관점에서 frontier vector와 adjacency matrix 간의 반복적인 sparse multiplication입니다. 이때 frontier가 서로 다른 디바이스에 분산되어 있다면, 매 iteration마다 frontier synchronization이 발생하며 이는 NVLink 혹은 PCIe bandwidth에 의해 병목됩니다.
- MI300X의 경우, 192GB의 대용량 HBM을 통해 더 큰 그래프를 단일 디바이스에 수용할 수 있으므로 이러한 cross-device synchronization 자체를 회피할 가능성이 높습니다. 이는 단순히 메모리 용량의 차이를 넘어, multi-GPU partitioning 비용과 frontier 교환 오버헤드를 구조적으로 줄여줍니다.
- 또한 GraphBLAS 기반 연산은 전형적인 memory-bound workload이기 때문에, 5.3TB/s에 달하는 높은 memory bandwidth는 반복적인 SpMV 수행에서 직접적인 성능 이점을 제공합니다. 결과적으로 MI300X는 대규모 그래프 탐색에서 용량 측면과 대역폭 측면 모두에서 구조적 우위를 갖습니다.
GraphRAG Task 중 LLM Inference workload 에 속하는 Entity Extraction & Linking. Memory와 연관성
- 지식그래프를 생성하는 Entity Extraction & Linking 단계는 본질적으로 LLM 기반의 추론(Inference) 워크로드에 해당합니다. 이때 vLLM 환경에서는 GPU 메모리가 곧 최대 context window를 결정합니다. H100 기준으로는 약 128K 토큰 수준이 현실적인 한계라면, MI300X에서는 약 320K 토큰 이상까지 확장할 수 있습니다. 이 차이는 단순히 더 긴 문장을 처리할 수 있다는 의미를 넘어, 지식그래프의 품질과 직접적으로 연결됩니다.
- LLM을 활용한 Entity Extraction 프롬프트는 보통 시스템 프롬프트, 온톨로지, 출력 구조 예시, 입력 문서의 네 가지 요소로 구성됩니다. 중요한 점은 이 네 요소가 동일한 context window를 공유한다는 사실입니다. 즉, 메모리가 제한되면 온톨로지를 줄이거나 입력 문서를 분할해야 합니다. 이 과정에서 필연적으로 문맥 손실이 발생하거나 타입 제약이 약화됩니다.
- 온톨로지는 지식그래프의 노드와 엣지를 정의하는 일종의 지침판 역할을 합니다. 기업 도메인 기반으로 추출해야 할 엔티티가 많아질수록 온톨로지는 커질 수밖에 없습니다. 동시에 문서 구조가 문단, 표, 다시 문단처럼 분리되어 있는 경우, 이들을 하나의 프롬프트 안에 포함시키지 않으면 청크 간 문맥이 끊겨 관계 추출 정확도가 떨어질 가능성이 높습니다. 결국 작은 메모리 환경에서는 온톨로지를 축소하거나 입력을 잘게 나누는 선택을 해야 하고, 이는 지식그래프의 구조적 완성도를 저하시킬 수 있습니다.
- 반대로 메모리가 충분하다면, 온톨로지를 유지한 채 더 많은 문맥을 하나의 프롬프트에 포함할 수 있습니다. 이는 타입 제약과 문맥 보존을 동시에 만족시킬 수 있음을 의미합니다. 결과적으로 엔티티 정확도와 관계 일관성이 높아지고, 이는 곧 GraphRAG의 Generation 단계 품질로 이어집니다.
- 이해를 돕기 위해 제가 활용한 Entity Extraction & Linking 프롬프트 및 결과물을 첨부합니다. 저는 온톨로지 사이즈를 S,M,L 로 나누어, LLM에게 ALLOW_TYPE을 제한하는 방식을 사용합니다. 위에 언급한 바와 같이 '제한'과 '지식그래프' 품질은 직결되어 있고, MAX TOKEN 에 따라 인풋 데이터를 배분해야하기 때문입니다.
- 제가 온톨로지에 특히 집중하게 된 이유는, 이전에 수행했던 온톨로지 실험 Lesson Learned 경험 때문입니다. 당시 실험을 통해 온톨로지의 포함 여부와 설계 방식에 따라 지식 그래프의 품질이 유의미하게 달라졌고, 이는 곧 GraphRAG Generation 단계의 성능 차이로 이어짐을 확인했습니다.
- 결국 MI300X의 큰 메모리는 단순히 더 많은 토큰을 처리할 수 있다는 의미에 그치지 않습니다. 온톨로지와 입력 문맥 사이의 트레이드오프를 완화하고, 구조적으로 더 정교한 지식그래프를 생성할 수 있게 한다는 점에서 의미가 있습니다. GraphRAG 맥락에서 메모리는 추론 확장의 문제가 아니라, 지식그래프 품질을 결정하는 기반 자원에 가깝습니다.
ROCm 환경에서의 그래프 딥러닝 스택 선택기
- ROCm 생태계에서 그래프 딥러닝을 수행하려면 자연스럽게 두 가지 선택지가 떠오릅니다: PyTorch Geometric (PyG) 와 DGL. 처음에는 PyG를 사용하려 했습니다. PyG는 연구 커뮤니티에서 가장 널리 쓰이고 있고, API도 직관적이며 생태계가 활발하기 때문입니다.
- 다만 PyG는 내부적으로 CUDA 커널 최적화에 많이 의존하고 있어, ROCm 환경에서는 빌드 및 커스텀 extension 레벨에서 예상보다 많은 제약을 마주하게 되었습니다. 결론적으로, ROCm 환경에서는 DGL 쪽이 더 현실적인 선택이었습니다.
- ROCm용 공식 Docker 이미지와 가이드가 존재
- HIP 기반 빌드 경로가 비교적 정리되어 있음
- PyTorch backend 기반이라 코드 수정은 최소화 가능
- 특히 .cuda() 호출이 NVIDIA 전용이라는 오해와 달리, ROCm 빌드의 PyTorch에서는 해당 API가 HIP 디바이스로 매핑되므로 동일 코드가 AMD GPU에서 동작합니다. 즉, 프레임워크 레벨에서는 CUDA 종속처럼 보이지만, 실제로는 PyTorch 디바이스 추상화 덕분에 큰 코드 수정 없이 ROCm 전환이 가능합니다.
Knowledge Graph Representation Learning. 주로 어떤 연산이 담겨 있을까?
- 위에서 ROCm 기반 DGL 환경을 구성했다면, 이제 본격적으로 Graph Encoder를 실험할 수 있습니다. 그래프 딥러닝을 접해본 분들은 보통 message-passing 기반 GNN에 익숙할텐데요. 하지만 지식그래프(Knowledge Graph) 환경에서는 또 다른 접근이 존재합니다. GNN은 크게 Message passing / Triplet 기반 두 계열로 나뉘는데요. 잠깐 비교를 해보자면 다음과 같습니다.
- Message Passing 기반 GNN에는 대표적으로 GCN, GAT(G-retrieval 에서 사용한 그래프 인코더) 등이 있습니다.
- node/edge property를 embedding
- 이웃 노드 feature를 aggregation
- feature table 기반 dense 연산 중심
- GPU workload는 주로 SpMM / gather-scatter
- Triplet 기반 Knowledge Graph Embedding 에는 대표적으로 TransE, DistMult, RotatE 등이 있습니다.
- (head, relation, tail) 구조의 triplet을 score function으로 학습
- graph 구조보다는 relation scoring 중심
- negative sampling 필수
- lookup + scoring 연산 중심
두 모델 모두 “그래프를 벡터로 정량화한다”는 공통점이 있지만:
| 구분 | Message Passing GNN | Triplet 기반 KGE |
|---|---|---|
| 목적 | node representation 학습 | relation semantics 학습 |
| 연산 특성 | neighborhood aggregation | embedding lookup + scoring |
| 병목 | SpMM / memory bandwidth | sampling / edge lookup |
| 워크로드 성격 | dense-sparse 혼합 | index-heavy / memory lookup |
즉, 같은 “GNN”이라도 워크로드 특성과 병목 지점이 완전히 다릅니다.
- 여기에서 전 Knowledge Graph Embedding 기반 그래프 인코더를 선택했고 이를 기반으로 학습했습니다. workload 를 Perfetto trace를 통해 확인한 결과, TransEModel의 forward/backward 연산보다 find_edges 구간이 더 넓은 시간 영역을 차지하고 있었습니다.
- 이는 모델 연산 자체가 병목이 아니라, 그래프 구조에서 학습에 필요한 triplet을 찾고 negative sample을 구성하는 과정이 더 큰 비용을 유발하고 있음을 의미합니다.
- 특히 TransE의 연산은 단순한 벡터 연산이기 때문에 GPU에서 매우 빠르게 처리되지만, find_edges는 sparse adjacency 접근과 random memory lookup이 포함된 memory-bound 작업입니다. 결과적으로 Knowledge Graph Embedding 학습에서는 모델 최적화보다 데이터 접근 구조와 sampling 전략이 전체 성능을 좌우할 수 있음을 확인했습니다.
끝으로
여기까지가 Part1 입니다. 정리해보면, 이번 경험을 통해 얻은 핵심 인사이트는 다음과 같습니다.
- GraphRAG는 본질적으로 메모리 집약적 파이프라인이다.
- 메모리는 단순한 확장 자원이 아니라 그래프 품질과 직결되는 구조적 요소다.
- GNN과 Knowledge Graph Embedding을 실제로 사용해보면 병목은 모델이 아니라 데이터 접근 계층에서 발생한다.
- 하드웨어 선택은 단순 성능 비교가 아니라, 어떤 워크로드 구조를 전제로 할 것인가에 대한 선택이다.
그래서 “왜 MI300X인가?”라는 질문에 대한 제 답은 이렇게 정리할 수 있을 것 같습니다. 단순히 더 큰 GPU이기 때문이 아니라, GraphRAG처럼 그래프와 추론이 얽힌 워크로드에서 메모리와 대역폭이 구조적인 차이를 만들어내기 때문입니다.
글 재밌게 보셨는지요? 다음 시간에는 단순히 넘어갈 수 있는 부분인 RAG 시에, Text, LPG, RDF 중 어느 데이터를 Retrieval 하면 좋을지 그리고 LPG, RDF 표현했을때 그래프 특성 차이는 어떻게 달라질까? 라는 정보량, 그래프 분석 위주의 이야기로 찾아 뵙겠습니다. 긴 글 읽어주심에 감사합니다.
