80 GB GPU 한 장이 LLM의 모든 연산자에 80 GB를 제공하는 것은 아닙니다. 긴 문맥의 어텐션은 중간 상태만 수백 GB가 될 수 있고, 여러 가속기로 나눈 선형 계층은 다음 연산을 시작하기 전에 부분 결과를 교환해야 합니다. 지금까지는 알려진 병렬화 방식을 먼저 선택하고, 그 방식에 맞게 버퍼를 배치한 뒤, 계산 사이에 collective 통신을 수작업으로 넣는 경우가 많았습니다. 한 모델과 연결 구조에서는 좋은 결과를 내도 헤드 수, 문맥 길이, 배치 크기, GPU 메모리나 로컬·원격 대역폭의 비율이 달라지면 다시 설계해야 합니다.
UC San Diego, Meta, George Mason University와 Rice University가 SOSP 2025에서 발표한 Mercury는 또 하나의 병렬화 방식을 추가하는 대신 추상화를 바꿉니다[1]. 컴파일러는 다른 GPU에 붙은 메모리를 명시적으로 스케줄하는 메모리 계층으로 다룹니다. CommIR이라는 반복문 기반 중간 표현은 계산 위치, 버퍼 소유 장치, 복제 범위와 랭크 사이의 데이터 이동 시점을 함께 기술합니다. 자동 튜너는 기존 collective 방식과 사람이 직접 만들기 어려운 비동기 스케줄을 한 탐색 공간에서 비교합니다.
결과는 넓지만 입증 범위를 구분해야 합니다. H100, A100과 L4의 어텐션·행렬곱 연산자에서 Mercury는 선택한 수작업 방식보다 평균 1.56× 높은 성능을 냈습니다. 여러 연결 구성을 비교한 실험에서는 평균 2.91×, H100 어텐션 한 조건에서는 4×에 이릅니다. 200만 토큰 조건에서는 비교 방식들이 메모리 부족으로 실패했지만 Mercury는 상태를 더 잘게 나눠 실행 가능한 계획을 찾았습니다. 다만 최대 4개 노드의 시험대에서 측정한 연산자와 한 계층 결과입니다. 표현과 탐색 공간의 가치는 보여 주지만 운영 장비군의 결과는 아닙니다.
멀티 GPU 연산자와 메모리 이동 스케줄
텐서 병렬화를 설명할 때는 보통 계산에서 시작합니다. 행렬의 한 차원을 나누어 부분곱을 계산하고 all-gather, all-reduce, reduce-scatter 또는 all-to-all로 결과를 모읍니다. 이 설명은 성능을 좌우하는 두 선택을 가립니다. 텐서를 반복문의 어느 지점에서 복제·분할·순환시킬지, 그리고 통신을 하나의 collective로 동기화할지 작은 단위로 앞당겨 다른 타일의 계산과 겹칠지입니다.
수작업 시스템은 이 가운데 일부 방식을 고정해 구현하며, Ulysses는 어텐션 헤드를 나눠 all-to-all을 사용하고[4], 링 계열 어텐션은 키와 값 블록을 장치 사이에서 순환시키며[3], 혼합 방식은 헤드 수와 문맥 길이에 따라 두 패턴을 결합합니다. 각 방식은 유효하지만 템플릿은 하드웨어와 작업을 보기 전에 중요한 선택지를 고정합니다. 예를 들어 그룹 질의 어텐션(GQA)은 키·값 헤드 수를 줄이므로 헤드 단위 분할이 기대한 균형을 잃을 수 있습니다.
Mercury는 연산자를 논리 차원의 반복문과 그 반복문이 접근하는 버퍼로 표현하며, 분산 실행의 의미는 네 변환에 담습니다. parallelize는 반복을 특정 연결 계층의 장치에 배정하고 shard는 버퍼의 서로 다른 부분을 각 랭크에 나누며, replicate는 참여 랭크마다 전체 사본을 두고 shift는 시간과 랭크에 따른 접근 순서를 어긋나게 해 원격 데이터를 비동기로 순환시킵니다. 일반 텐서 컴파일러가 쓰는 타일링, 순서 변경과 반복문 결합도 함께 사용합니다[6]. 메모리 위치와 통신이 같은 프로그램의 명시적 정보라는 점이 다릅니다.
따라서 원격 버퍼는 투명한 공유 메모리도, 이미 정해진 메시지도 아닙니다. 컴파일러는 현재 타일이 로컬에 있고 다음 타일은 다른 랭크에서 와야 하며, 복제 수를 줄이면 용량을 아끼는 대신 이동이 늘어난다는 사실을 압니다. 동기식 all-gather와, 로컬 계산 중에 작은 전송을 진행하는 계획을 비교할 수 있습니다. collective 선택 문제를 데이터 배치와 시간 순서의 문제로 넓힌 것입니다.
링을 이름 붙이지 않는 표현
네 랭크에 나눈 가중합을 생각할 수 있습니다. 동기식 방식은 입력 하나를 복제하고 다른 입력을 나눠 로컬에서 계산한 뒤 부분 결과를 all-reduce합니다. shift를 적용한 방식은 복제할 입력도 나누고 그 조각을 순환시킵니다. 각 반복에서 랭크는 로컬 또는 막 도착한 타일을 계산하면서 다른 타일을 다음 장치로 보냅니다. 전체 입력 사본이 없어 저장 공간이 줄고, 타일 시간이 맞으면 통신과 계산이 겹칩니다.
CommIR은 로컬 반복문을 병렬 반복문에 대해 이동시키는 방식으로 이 계획을 표현합니다. 컴파일러가 주석을 send, receive와 로컬 연산으로 내립니다. 서로 다른 반복 차원에 shift를 적용하면 링, 헤드 병렬화 또는 혼합 어텐션을 알고리즘별 수작업 코드 없이 만들 수 있습니다. 노드 안과 노드 사이에 서로 다른 패턴을 적용할 수도 있습니다. NVLink와 RoCE의 대역폭·지연 특성이 크게 다른 시스템에서 중요한 선택입니다.
탐색 공간은 빠르게 커집니다. Mercury는 실행 가능성, 메모리 한도와 실제 수행 시간을 이용해 후보를 줄이고 선택합니다. Python 안에서 쓰는 전용 언어로 텐서 연산자를 받고, 로컬 연산은 PyTorch와 TorchInductor 계층으로 내립니다. 논문의 구현은 CUDA 12.6과 NCCL 2.26.2를 사용했습니다. 이웃한 연산자 사이의 데이터 배치도 함께 보므로, 한 연산자를 빠르게 만든 배치가 다음 연산자 앞에서 비싼 재배치를 요구하는 상황을 피합니다.
이 범위가 시스템 판단에 중요합니다. 커널 벤치마크만 보면 다음 계층을 느리게 만드는 배치가 높은 점수를 받을 수 있습니다. Mercury의 Llama 실험은 QKV 투영, 어텐션, 출력 투영과 MLP를 포함한 한 Transformer 계층에서 연산자 사이의 재배치까지 탐색했습니다. 최선의 3D 병렬화 비교 기준보다 최대 1.62× 향상됐습니다. 전체 모델은 아니지만 고립된 어텐션 커널보다 넓은 경계를 최적화했습니다.
성능이 향상된 조건
평가는 L4, A100과 H100을 사용했습니다. L4는 노드 안에서 PCIe, A100과 H100은 NVLink를 쓰며, 노드 사이는 50 또는 100 Gbps로 구성했습니다. 노드는 1~4개, 노드당 GPU는 1~8개입니다. 어텐션은 MHA와 GQA, 배치 1과 16, 문맥 4K부터 200만 토큰까지를 포함합니다. 선형 연산자는 all-gather 뒤 GEMM과 GEMM 뒤 reduce-scatter를 측정했습니다.
논문의 연산자 비교에서는 모든 묶음에서 Mercury가 가장 높은 결과를 냈습니다. H100의 MHA 배치 16 한 조건은 비교 방식 대비 약 4×, A100의 all-gather GEMM 한 조건은 1.9×였습니다. 향상 폭은 일정하지 않습니다. 연결 계층이 하나뿐이고 수작업 방식이 이미 장비와 잘 맞는 구성에서는 차이가 줄었습니다. 문맥이 100만 토큰을 넘고 어텐션 계산이 통신보다 커질 때도 상대 이득이 작아졌습니다. 노드 안팎의 연결 특성이 다른 계층형 구성에서 컴파일러의 선택지가 가장 큰 효과를 냈습니다.
연결 구조 실험은 이 차이를 보여 줍니다. GPU당 작업량을 고정하면 노드 추가가 용량과 원격 통신을 함께 늘립니다. 전체 문맥을 32K로 고정하면 GPU를 늘릴수록 로컬 계산이 줄어 통신 비용이 드러납니다. H100과 A100의 여러 구성에서 Mercury는 평균 2.91×를 보고했지만, 완전히 노드 안에 있거나 같은 특성의 링크만 쓰는 경우에는 차이가 작았습니다. 하나의 전역 collective가 연결 구조에 맞지 않을 때 컴파일러의 가치가 커집니다.
메모리 축에서는 2개 노드의 H100 8장으로 200만 토큰을 처리한 조건에서 비교 스케줄이 메모리 한도를 넘었지만, Mercury는 KV 상태와 출력을 더 공격적으로 나눈 계획을 찾았습니다. 통신량은 늘 수 있어도 실행 불가를 실행 가능으로 바꿨다는 점에서 원격 HBM을 메모리 계층으로 부르는 이유가 가장 분명하게 드러납니다. 목표는 지연 단축뿐 아니라 용량 제약 안에 데이터를 배치하는 것입니다.
아직 입증하지 않은 범위
논문에는 운영 배치, 클러스터 단위 스케줄링과 다중 사용자 간섭 결과가 없습니다. 제어된 GPU 그룹과 제한된 연산자 모양을 평가했습니다. 네트워크 혼잡, 연결 변경, 실행 시간 변동, 장애와 동시 작업은 안정적인 마이크로벤치마크로 고른 계획을 흔들 수 있습니다. 원격 메모리 경로가 서비스 중 달라질 때도 안전한 계획이나 재튜닝 정책이 필요합니다.
컴파일과 튜닝 비용도 운영 항목입니다. Mercury는 후보를 실행해 좋은 스케줄을 찾지만, 논문은 빠른 결과에 초점을 두고 변화가 빠른 모델 목록의 프로파일을 유지하는 총비용은 자세히 제시하지 않습니다. 서빙 플랫폼은 어떤 구성이 충분히 자주 쓰여 튜닝할 가치가 있는지, 계획을 어떻게 캐시할지, 프로파일과 다른 모델이나 하드웨어가 들어오면 어떤 안전한 방식으로 되돌릴지 정해야 합니다.
모델 수준 실험은 계층마다 구성이 같다는 점을 이용해 Transformer 한 계층을 측정했습니다. 연산자와 재배치 효과를 분리하기에는 적절하지만 전체 요청의 파이프라인 버블, 토큰 사이의 KV 캐시 수명, 호스트 오버헤드, 수용 제어와 서비스 꼬리 지연은 포함하지 않습니다. 최대 4개 노드라는 범위도 랙과 포드 규모의 더 깊은 연결 계층에서 어떻게 동작할지는 남겨 둡니다.
원격 메모리는 로컬 HBM과 같지 않습니다. Mercury는 그 차이를 없애는 대신 컴파일러가 비용을 고려하도록 드러냅니다. 실제 전송은 NCCL 등의 명시적 통신으로 수행합니다. 기여는 다른 GPU의 메모리가 로컬 지연이나 일관성을 가진다는 주장이 아니라, 그 이동을 계산과 함께 표현하고 선택할 수 있게 했다는 점입니다.
원격 HBM이 바꾼 용량 계산 경계
컴파일러가 만든 스케줄이 커널을 실행 가능하게 해도, 빌린 메모리를 누가 소유하는지는 클러스터 운영자가 정해야 합니다. 작업 시작 시점의 빈 바이트만 세어서는 부족합니다. 커널이 끝날 때까지 원격 할당량, 이동에 필요한 통신 버퍼와 컴파일러가 가정한 중첩을 지킬 링크 서비스까지 예약해야 합니다. 그렇지 않으면 각각은 유효한 두 스케줄이 같은 제공 GPU를 중복 할당하거나, 두 작업이 감출 수 있다고 판단한 경로를 함께 포화시킬 수 있습니다.
장애 경계도 로컬 HBM 할당과 달라집니다. 메모리를 제공한 GPU가 초기화되거나 링크 경로가 바뀌고, 다른 사용자의 collective가 개입하면 계산 GPU가 정상이어도 스케줄의 전제가 무너집니다. 런타임은 실행 전에 계획을 거부하고 더 보수적인 후보를 선택하거나, 로컬 재계산과 더 작은 배치로 돌아갈 수 있어야 합니다. 대체 경로가 없는 고속 스케줄은 성능 최적화를 가용성 의존성으로 바꿉니다.
격리도 같은 수준으로 다뤄야 합니다. 원격 메모리의 내용, 접근 권한, 초기화와 수명은 로컬 장치 메모리와 같은 사용자 경계를 따라야 합니다. 운영 지표는 빌린 바이트의 점유 시간과 경로 사용량을 메모리를 보관한 GPU가 아니라 실제 사용한 작업에 귀속해야 합니다. 이 계산이 없으면 응용 지연은 줄어도 클러스터 사용률과 비용 배분을 이해하기 어려워집니다.
따라서 실제 인터페이스에는 링크 대역폭 지도보다 더 많은 정보가 필요합니다. 예약 가능한 용량, 예상 경합, 장애 영역과 전송 성능의 오차 범위를 제공해야 합니다. Mercury는 이러한 조건이 주어졌을 때 스케줄을 탐색하는 방법을 보였습니다. 운영 시스템은 배치나 경쟁 트래픽이 바뀌면 조건을 갱신하고 저장한 스케줄을 무효화해야 합니다. 유용한 추상화는 제한 없는 원격 HBM이 아니라, 컴파일러가 서비스 조건을 확인할 수 있는 제한적이고 회수 가능한 메모리 계층입니다.
컴파일러를 위한 연결 구조 계약
운영 도입의 핵심은 런타임이 컴파일러에 무엇을 보장할지입니다. 특정 NVLink와 RoCE 배치의 H100 8장에 맞춘 스케줄은 배치 위치가 바뀌면 느려질 수 있습니다. 컴파일러에는 대역폭, 지연, 혼잡 영역, 메모리 용량과 허용 통신을 담은 연결 구조 설명이 필요합니다. 스케줄러는 그 계약을 유지하거나 새 계획을 요청해야 합니다.
연산자는 하나의 최고 계획보다 안전한 계획들의 범위를 제공할 필요가 있습니다. 중앙 지연이 가장 낮은 계획, 메모리를 덜 쓰는 계획과 네트워크 변동을 더 잘 견디는 계획이 다를 수 있습니다. Mercury의 탐색 결과에도 지연과 메모리의 파레토 경계가 있습니다. 운영 환경에서는 컴파일 시간, 에너지와 링크 저하 민감도를 더해 서비스 목표에 따라 선택할 수 있습니다.
우리는 Mercury의 오래 남는 기여를 표현 방식에서 찾습니다. 멀티 GPU 최적화는 로컬 반복문을 아는 텐서 컴파일러와 collective를 아는 분산 라이브러리 사이에 나뉘어 있었습니다. CommIR은 원격 데이터의 소유와 이동을 반복문 프로그램에 넣어 그 경계 양쪽을 함께 탐색합니다. 측정 결과는 추가 선택지가 성능에 영향을 준다는 사실을 보여 줍니다. 다음 단계는 연결 구조, 트래픽과 모델 모양이 엔지니어의 수작업보다 빠르게 바뀌는 운영 환경에서도 이 이득을 유지하는 것입니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약으로, 인용한 논문의 작동 원리, 측정 결과와 한계를 우리 표현으로 재서술했습니다. 원문의 문장, 표와 도판은 재사용하지 않았으며, 본문 도판 두 장과 카드 이미지는 이 글을 위해 새로 만들었습니다. 확정 논문은 ACM Digital Library에서 CC BY-NC-SA 4.0으로 공개되어 있습니다. Copyright (c) 2025 the authors.