멀티 GPU 커널은 보통 두 층으로 구성됩니다. 컴파일러가 텐서 연산을 나누고, 집단 통신 라이브러리가 각 GPU의 로컬 커널 사이에서 올개더, 리듀스스캐터 또는 올투올을 실행합니다. 구현은 단순하지만 통신이 장벽처럼 작동합니다. 모든 장치가 공유 입력을 복제하고 같은 집단 통신에 들어간 뒤 비슷한 시점에 다음 연산을 시작합니다. SOSP 2025의 Mercury 논문은 긴 문맥 LLM 연산에서 이 경계가 지나치게 거칠다고 봅니다[1].
Mercury는 다른 GPU의 HBM을 로컬 메모리 계층의 명시적인 확장으로 취급합니다. 공유 버퍼를 여러 GPU에 나눠 둔 채 GPU마다 다른 순서로 읽게 만들고, 전송에 복사 엔진, Tensor Memory Accelerator 또는 일반 로드·스토어 중 무엇을 쓸지 정합니다. 미리 고른 통신 커널을 연산 사이에 끼우는 것이 아니라, 루프 스케줄 안에 데이터 이동을 포함합니다.
동기식 연산에 숨은 비용
각 GPU가 행렬 A의 일부를 가지고 모든 GPU가 행렬 B를 필요로 하는 경우를 생각할 수 있습니다. 일반적인 텐서 병렬 스케줄은 B를 모두 복제하고 같은 루프를 실행한 뒤 부분 결과를 집단 통신으로 합칩니다. 복제는 로컬 HBM을 쓰고, 같은 시간에 발생한 통신은 특정 링크에 부하를 몰아줍니다. 더 큰 문제는 자원 사이의 교환을 선택할 수 없다는 점입니다. 집단 통신이 개별 버퍼의 수명과 이동을 숨기므로, 1번 GPU가 0번 GPU의 첫 타일을 읽는 동안 0번 GPU가 다음 타일로 진행하는 식의 스케줄을 표현하기 어렵습니다.
긴 문맥 어텐션에서는 이 한계가 분명합니다. KV 텐서는 GPU 한 장의 HBM을 넘을 수 있고, 그룹 쿼리 어텐션은 병렬화할 독립 헤드 수를 줄입니다. 서버 안의 NVLink는 노드 사이 RoCE보다 훨씬 빠릅니다. GPU 8장이 있는 한 서버에 잘 맞는 통신 템플릿을 두 서버로 늘리면 느린 계층으로 잘못된 양의 데이터를 보낼 수 있습니다. 수학적으로 같은 연산이어도 데이터 배치가 네트워크 스케줄을 결정합니다.
Mercury는 GPU별 실행 시점을 어긋나게 만듭니다. 순위에 따라 안쪽 루프의 시작을 이동하면 장치들이 공유 데이터를 차례로 소비합니다. 버퍼는 전체 HBM 풀에 나뉜 채 필요할 때만 이동합니다. 전송량이 늘 수 있지만 전체 복제를 없애고, 로컬 타일을 키우며, 통신이 한 시점에 몰리는 것을 줄입니다. 실제 메모리와 토폴로지 조건에서 어느 쪽이 빠른지는 컴파일러가 탐색합니다.
통신을 변환 대상으로 만든 CommIR
Mercury는 연산을 읽기, 쓰기와 반복 범위를 기록한 루프 기반 중간 표현 CommIR로 내립니다. 병렬화와 데이터 배치가 명시적인 변환으로 드러납니다. 버퍼는 복제하거나 분할하거나 이동할 수 있고, 루프는 순서를 바꾸거나 타일로 나눌 수 있으며, 리덕션에는 여러 통신 경로를 적용할 수 있습니다. 의존 관계가 남아 있으므로 비동기 스케줄이 올바른지 코드 생성 전에 검사할 수 있습니다.
모든 GPU 명령까지 탐색하면 경우의 수가 감당하기 어렵습니다. Mercury는 잘 조정된 로컬 커널을 패치 형태로 유지하고, 이 커널들을 연결하는 분산 스케줄을 탐색합니다. 공급사가 최적화한 GEMM이나 어텐션 구현은 보존하면서 분산 알고리즘만 바꾸는 방식입니다.
후보는 정적 분석, 비용 추정과 실제 프로파일링을 차례로 거칩니다. 버퍼 크기나 의존 관계가 맞지 않는 스케줄을 먼저 제거하고, 비용 모델로 범위를 줄인 뒤 남은 후보를 대상 장비에서 실행합니다. 링크 경합과 전송 엔진, 커널 중첩은 정확히 모델링하기 어렵기 때문입니다. 결과물은 어디서나 같은 성능을 내는 스케줄이 아니라, 이식 가능한 표현에서 특정 장비에 맞춰 찾은 실행 계획입니다.
연산 사이의 재분할도 비용에 포함합니다. 어텐션, 프로젝션과 피드포워드 레이어가 선호하는 배치가 다르면 변환 비용이 개별 커널의 이점을 지울 수 있습니다. Mercury는 그래프의 간선에 필요한 재분할을 계산해 모델 병렬화와 연산 스케줄을 함께 선택합니다.
고정 템플릿을 넘어선 스케줄
평가 장비는 H100, A100과 L4입니다. H100과 A100 서버 안에서는 NVLink를, L4는 PCIe를 사용합니다. 노드 사이는 50 또는 100 Gbps RoCE로 연결되며, 노드 안의 대역폭은 L4 PCIe 64 GB/s부터 H100 NVLink 900 GB/s까지 다릅니다. 노드당 GPU 수는 1~8장, 노드 수는 최대 4대입니다. 한 통신 템플릿이 모든 토폴로지에서 이기기 어려운 범위를 의도적으로 시험했습니다.
어텐션 비교 대상은 RingAttention, DeepSpeed Ulysses와 USP이며, GEMM 계열에는 cuBLAS 집단 통신, AsyncTP와 TorchInductor가 포함됩니다. 작업은 Llama-3 계열의 멀티헤드·그룹 쿼리 어텐션, 배치 1과 16, 문맥 4K부터 200만 토큰까지입니다. 구현은 CUDA 12.6, NCCL 2.26.2와 PyTorch 2.8 시기의 TorchInductor를 사용합니다.
H100의 멀티헤드 어텐션, 배치 16에서는 Mercury가 비교 스케줄보다 최대 4배 높은 결과를 냈습니다. A100의 올개더 GEMM, 같은 배치에서는 최대 1.9배입니다. 노드 수와 노드당 GPU 수를 바꾼 토폴로지 실험에서는 지연시간이 평균 2.91배 개선됐습니다. 2×4, 4×2처럼 빠른 노드 내부와 느린 노드 사이 링크를 구분해야 할 때 차이가 가장 큽니다.
반대로 링크 계층이 하나뿐인 1×4 또는 4×1 구성에서는 수작업 방식도 유일한 링크 특성에 맞추기 쉬워 격차가 줄어듭니다. Mercury의 복잡성은 선택지가 있는 장비에서 값을 만들며, 단순한 토폴로지에는 컴파일러가 활용할 계층도 적습니다.
성능 조건이 된 메모리 용량
문맥이 길어지면 목표는 가장 빠른 스케줄에서 실행 가능한 스케줄로 바뀝니다. H100 8장의 어텐션 실험에서 Mercury는 32K부터 200만 토큰까지 확장됩니다. 비교 방식은 가장 긴 문맥에서 메모리 부족으로 실패하지만, Mercury는 KV와 출력 버퍼를 더 많이 분할하고 통신을 늘려 실행을 이어갑니다.
원격 메모리 추상화가 단순한 대역폭 최적화가 아닌 이유입니다. Mercury는 지연시간과 메모리 사이의 여러 선택을 남깁니다. 용량이 충분하면 데이터를 복제한 빠른 스케줄을, 부족하면 전송 비용을 내고 버퍼를 나눈 스케줄을 선택할 수 있습니다. 인프라 소프트웨어는 최고 속도 하나뿐 아니라 실행 가능 범위를 함께 관리해야 합니다.
100만 토큰을 넘으면 연산 비중이 커져 통신 최적화의 상대 이점은 줄어듭니다. 각 GPU가 충분한 산술 작업을 받으면 통신 대기를 줄여도 전체 지연시간에서 차지하는 비율이 작아집니다. 일정한 배율을 주장하지 않고, 통신 스케줄이 임계 경로를 지배하는 구간을 구분한 결과입니다.
자동 탐색에 들어가는 운영 비용
탐색형 컴파일러는 전문가의 수작업을 프로파일링 인프라로 옮깁니다. 장치 세대, 드라이버, 토폴로지와 커널이 바뀌면 측정 비용이 달라집니다. 100 Gbps RoCE에서 찾은 스케줄은 혼잡이나 링크 장애 뒤에 최적이 아닐 수 있습니다. 운영 환경에서는 장비 토폴로지, 소프트웨어 버전과 모델 형태를 캐시 키에 포함하고, 기존 스케줄이 기대 성능을 못 내면 안전한 방식으로 돌아갈 수 있어야 합니다.
컴파일 시간도 서비스 비용입니다. 몇 달 동안 같은 모델을 서빙하면 긴 탐색을 나눠 부담할 수 있습니다. 어댑터와 모델 구조가 자주 바뀌는 다중 사용자 환경에서는 별도 스케줄이 너무 많이 필요할 수 있습니다. 최초 사용 가능한 스케줄까지 걸린 시간, 프로파일링에 사용한 GPU 시간과 독립적으로 조정해야 하는 형태 수를 함께 측정해야 합니다.
비동기 원격 읽기는 버퍼 수명과 동기화 오류를 만들 수 있습니다. CommIR의 의존성 분석과 공개 아티팩트의 수치 검사가 기반을 제공하지만, 운영 도입에는 임의 형태 시험, 장애 주입, 결정론적 재생과 버전 간 검증이 필요합니다. 드물게 잘못된 값을 내는 분산 커널은 느린 집단 통신보다 큰 위험입니다.
시스템 설계에서 달라지는 경계
Mercury는 집단 통신 라이브러리가 가속기 통신의 최종 추상화라는 전제를 약하게 만듭니다. NCCL은 여전히 백엔드로 유용하지만, 그 위의 의미 단위는 집단 통신보다 작고 개별 로드보다 클 수 있습니다. 이 중간 층이 연산의 루프 구조에 맞춰 버퍼 이동을 예약합니다.
인터커넥트 설계에도 의미가 있습니다. 빠른 링크만큼 계층과 독립 전송 자원을 소프트웨어에 드러내는 일이 중요합니다. 컴파일러가 복사 엔진, 로드·스토어 경로와 로컬·원격 링크를 구분하면 통신을 겹치고 데이터를 의도적으로 배치할 수 있습니다. 평평한 호환 인터페이스는 하드웨어의 차별점을 숨길 수 있습니다.
모델 구조도 분산 실행과 무관하지 않으며, 어텐션 헤드 수, KV 표현과 텐서 크기가 가능한 병렬 스케줄을 결정합니다. 헤드 수를 줄여 연산을 절약한 모델이 GPU별 병렬성을 제한할 수도 있으므로 컴파일러의 피드백은 모델이 확정된 뒤가 아니라 설계 단계에서 들어가야 합니다.
도입 여부를 가르는 세 가지 질문
Mercury의 중요한 결과는 하나의 4배 수치보다 서로 다른 장비와 링크 비율에서 꾸준히 우위를 보였다는 점입니다. 연산, 데이터 배치와 통신을 따로 결정하지 않았기 때문에 가능한 결과입니다. 토폴로지가 단순하면 차이가 줄고, 계층이나 메모리 한계가 선택을 만들면 차이가 커집니다.
도입 전에는 같은 연산 형태가 충분히 반복돼 탐색 비용을 나눌 수 있는지, 플랫폼이 토폴로지와 전송 엔진을 정확히 드러내는지, 스케줄의 정확성을 성능만큼 강하게 검사할 수 있는지를 확인해야 합니다. 모두 가능하면 원격 HBM은 컴파일러가 관리할 수 있는 메모리 계층이 되지만, 그렇지 않으면 고정 집단 통신이 덜 공격적이더라도 운영하기 쉬운 선택이며 Mercury의 가치는 이 비용까지 비교 대상으로 만들었다는 데 있습니다.
출처와 저작권 안내
이 글은 SOSP 2025 논문[1]과 공개 아티팩트를 우리 표현으로 다시 분석한 편집 다이제스트입니다. 논문의 문장·도판·표를 옮기지 않았으며, 본문 도판은 Silicon & Systems가 새로 제작했습니다. 원 논문은 CC BY-NC-SA 4.0으로 공개됐고 저작권은 저자에게 있습니다(2025).