LLM WikiAccess-protected knowledge portal

WIKI

Bullet: 웨이브 양자화와 Attention 병목을 진단하고 동적 SM 분할로 LLM 서빙 처리량을 1.55배 높이는 방법 (ASPLOS 2026)

요약 LLM 서빙 GPU의 SM Streaming Multiprocessor 활성 사이클은 왜 85%를 넘기기 어려울까? ASPLOS 2026에서 발표된 Bullet 은 이 한계의 근본 원인으로 두 가지를 지목한다. Prefill 단계에서 발생하는 웨이브 양자화 Wave Quantization 손실과, Prefill Decode 혼합 배치에서 발생하는 자원 비대칭 낭비 다. Bullet은 이 두 원인을 분석적 모델로 정량화하고

경로human/study/content/ai-frontier/96-bullet-spatial-temporal-gpu-orchestration-llm-serving-asplos-2026.md
카테고리Study
태그#ai-review #asplos #llm #orchestration #serving #study

요약

LLM 서빙 GPU의 SM(Streaming Multiprocessor) 활성 사이클은 왜 85%를 넘기기 어려울까? ASPLOS 2026에서 발표된 Bullet은 이 한계의 근본 원인으로 두 가지를 지목한다. Prefill 단계에서 발생하는 웨이브 양자화(Wave Quantization) 손실과, Prefill-Decode 혼합 배치에서 발생하는 자원 비대칭 낭비다.

Bullet은 이 두 원인을 분석적 모델로 정량화하고, GPU의 SM을 동적 비율로 분할해 Prefill과 Decode를 물리적으로 격리하면서 동시에 실행한다. 웨이브 꼬리 구간에서 유휴 SM을 Decode에 넘기는 시간적 오케스트레이션을 더해 GPU 활용률을 86.2% 까지 끌어올린다.


배경: GPU 활용률의 구조적 한계

Prefill과 Decode의 자원 충돌

LLM 서빙 요청은 두 단계로 처리된다.

단계특성GPU 병목
Prefill입력 토큰 전체를 한 번에 처리해 KV 캐시 생성Tensor Core 연산 집약
DecodeKV 캐시를 반복 읽어 토큰 하나씩 생성HBM 메모리 대역폭 집약

두 단계는 GPU를 사용하는 방식이 근본적으로 다르다. 순차 실행하면 한 단계가 활성인 동안 다른 단계가 필요로 하는 자원은 놀게 된다. 기존 시스템들이 채택한 해법은 Chunked Prefill(Prefill을 잘게 쪼개 Decode와 섞어 배치)이었지만, 이는 대기 시간을 낮추는 대신 Prefill 처리량을 희생하는 트레이드오프를 피하지 못한다.

Bullet이 진단한 두 가지 낭비

① 웨이브 양자화(Wave Quantization)

NVIDIA GPU는 스레드 블록(Thread Block) 단위로 SM에 커널을 배치한다. 예를 들어 A100에는 SM이 108개다. Prefill 배치를 처리할 때 총 스레드 블록이 108의 정수 배가 아니면 마지막 "웨이브"에서 일부 SM이 비게 된다.

총 블록 500개, SM 108개 → 4웨이브 432블록 + 마지막 68블록
마지막 웨이브에서 SM 40개 유휴

요청 길이와 배치 크기가 매 요청마다 달라지는 실제 환경에서 이 손실은 피할 수 없다. Bullet의 분석에 따르면 이 웨이브 양자화 손실이 Prefill GPU 활용률 저하의 주된 원인이다.

② Attention 병목

Prefill 전체를 "연산 집약"으로 분류하면 Attention 연산의 특수성을 놓친다. FlashAttention 이후에도 긴 시퀀스의 Attention은 KV 캐시 접근 패턴이 복잡해 Tensor Core 활용률이 낮다. 이 구간에서는 GPU가 연산보다 메모리 접근에 묶이기 때문에, Prefill 중 Attention 구간을 별도로 인식하지 않으면 자원 배분 판단이 틀어진다.


Bullet의 핵심 아이디어

Bullet: 동적 SM 분할과 시간적 오케스트레이션 Performance Estimator 웨이브 양자화 모델링 SM 분할 비율 결정 커널 경합 예측 비율 k libsmctrl SM 마스킹 라이브러리 CUDA 커널 레벨 분할 단일 GPU (A100 · H100 · H20) Prefill 파티션 SM 0 ~ SM k-1 (동적) 웨이브 1: 모든 SM 사용 웨이브 2: 모든 SM 사용 웨이브 3: 모든 SM 사용 마지막 웨이브 (일부 빈 SM) ↑ 웨이브 양자화 손실 Attention 병목 구간 메모리 집약 / 연산 저활용 Decode 파티션 SM k ~ SM N-1 (동적) Decode 배치 토큰 생성 · HBM 집약 KV 캐시 읽기 HBM ↔ 공유 유휴 SM 동적 양도 시간축: Temporal Orchestration Prefill 웨이브 1-3 꼬리 P Decode (기본 파티션) 확장 D Bullet: 86.2% SM 활성 사이클 SGLang 대비 +11.2%p
Bullet 공간·시간 이중 분할 아키텍처

공간 분할: SM 마스킹

Bullet은 libsmctrl 라이브러리를 통해 CUDA 커널을 SM 서브셋에만 배치한다. SM 0~k-1은 Prefill 커널에, SM k~N-1은 Decode 커널에 배타적으로 할당된다. 두 커널은 물리적으로 분리된 SM 위에서 진정한 병렬 실행된다.

분할 비율 k는 정적 50:50이 아니다. Performance Estimator가 배치마다 웨이브 양자화 손실과 Attention 비중을 분석해 최적 k를 실시간으로 계산한다.

시간 분할: 유휴 SM 재활용

Prefill의 마지막 웨이브(꼬리 구간)나 Attention 병목 구간에서는 Prefill 파티션의 SM 일부가 유휴 상태에 놓인다. Bullet은 이 구간을 감지해 해당 SM을 일시적으로 Decode 파티션으로 편입시키고, 다음 Prefill 웨이브가 시작되면 복귀시킨다.

이 시간적 오케스트레이션은 공간 분할만으로 달성할 수 없는 추가 처리량을 제공한다.


Performance Estimator: 분석적 예측 모델

Performance Estimator는 두 종류의 정보를 결합한다.

프로파일링 기반 룩업: GPU 아키텍처(SM 수, CUDA 코어 수, 메모리 대역폭)와 배치 설정(시퀀스 길이, 배치 크기, 헤드 수)을 오프라인으로 프로파일링해 테이블로 구축한다.

분석 모델: 프로파일 데이터를 토대로 임의의 SM 분할 비율 k와 배치 조합에 대해 Prefill/Decode 실행 시간을 추정한다. 웨이브 양자화 손실(마지막 웨이브의 SM 빈도)과 커널 간 메모리 대역폭 경합을 수식으로 모델링해 k를 탐색 없이 직접 계산한다.

이 설계 덕분에 요청마다 수백 가지 k 후보를 시뮬레이션하지 않고도 수 밀리초 안에 최적 분할 비율을 결정할 수 있다.


구현: SGLang 기반

Bullet은 SGLang 서빙 엔진 위에 구현됐다. 저장소 구조는 다음 세 모듈로 나뉜다.

모듈역할
sgl-kernellibsmctrl 기반 SM 마스킹 CUDA 커널
sgl-pdlb스케줄링·부하 분산 로직 (Estimator 포함)
sgl-router요청 라우팅·오케스트레이션

기존 SGLang 추론 파이프라인을 최소 수정으로 교체할 수 있도록 설계됐으며, CUDA 12.6 이하, Python 3.12.9 이상 환경을 요구한다.


성능 평가

평가 환경: Llama3.1-70B, Qwen3-235B-A22B, Splitwise 실세계 워크로드 데이터셋, NVIDIA A800·H100·H20.

처리량

비교 대상평균 처리량 향상최대
최첨단 서빙(종합)1.26×1.55×
SGLang-10241.09× (평균)1.20×

지연

지표SGLang-1024 대비
Prefill 지연13.5배 감소
종단 지연1.86배 감소

GPU 활용률

시스템SM 활성 사이클
SGLang~75%
Bullet86.2% (+11.2%p)

H100은 HBM 대역폭이 높아 Chunked Prefill 오버헤드가 줄어드는데도, Bullet은 H100에서도 SGLang과 vLLM을 일관되게 앞선다. 이는 웨이브 양자화 손실이 메모리 대역폭과 무관한 독립적인 병목임을 보여준다.


다른 접근법과 비교

시스템핵심 아이디어주요 한계
Chunked PrefillPrefill을 잘게 쪼개 Decode와 배치 혼합순차 실행, 웨이브 양자화 잔존
Disaggregated Serving (DistServe 등)P/D 노드 분리, 네트워크로 KV 전송KV 전송 지연, GPU 수 배증
MuxWise단일 GPU 내 고정 50:50 SM 파티션고정 비율, 웨이브 꼬리 최적화 미흡
Bullet동적 SM 비율 + 시간적 유휴 SM 재활용단일 GPU에 모델이 올라가는 규모 필요

MuxWise(ASPLOS 2026, 동일 학회)도 SM 파티셔닝을 사용하지만 고정 50:50 비율을 쓴다. Bullet은 Performance Estimator로 배치마다 최적 비율을 동적으로 계산한다는 점이 핵심 차별점이다.

운영 체크리스트

□ CUDA ≤ 12.6, Python ≥ 3.12.9 확인
□ libsmctrl 지원 GPU (A100, H100, H20 계열)
□ 단일 GPU에 모델이 올라가는 크기 (모델이 여러 GPU에 걸치면 SM 파티셔닝 범위가 제한)
□ SGLang 기반 서빙 스택 사용 시 최소 수정으로 적용 가능
□ 배치 크기와 시퀀스 길이가 다양한 실제 워크로드에서 더 큰 이득
□ 단조로운 고정 길이 배치 워크로드에서는 이득이 줄어들 수 있음

요점 정리


References