가속기는 애플리케이션이 경합을 알아채기 어려운 계층에서 공유된다. 긴급한 전경 요청과 여유 자원을 쓰려는 배경 작업이 서로 다른 소프트웨어 계층을 지나도 결국 장치 명령 큐에서 만난다. 그 큐가 먼저 들어온 명령부터 실행하면 긴급 작업은 이미 받아들인 낮은 우선순위 명령이 끝날 때까지 기다린다. XSched는 애초에 같은 제어 기능을 갖도록 설계되지 않은 여러 장치에 하나의 소프트웨어 스케줄러로 우선순위와 대역폭 정책을 적용할 수 있는지 묻는다[1].
평가 범위는 의도적으로 넓다. 일곱 소프트웨어 플랫폼을 통해 열 종류 XPU를 시험했다. NVIDIA, AMD, Intel GPU, Intel과 Ascend NPU, NVIDIA DLA, PVA, OFA 고정 기능 가속기, Xilinx FPGA가 포함된다. 스케줄링 기능이 거의 없는 구형 장치부터 실행 중 명령을 중단할 수 있는 Volta GPU까지 세대 차이도 크다. 이 다양성이 논문의 핵심이다. 최신 CUDA GPU 하나에서만 동작하는 스케줄러로는 AI PC, 임베디드 시스템, 이기종 서버의 경합을 함께 다룰 수 없다.
XQueue가 정책과 장치 queue를 분리한다
XSched는 애플리케이션에 선점 가능한 명령 큐인 XQueue를 제공한다. 명령은 먼저 소프트웨어 큐에 들어간다. 스케줄러는 어떤 XQueue가 장치의 기본 명령 큐에 작업을 보낼지 정하고, 작업 전체를 한꺼번에 넣지 않고 조금씩 전진시킨다. 애플리케이션이 XQueue를 직접 호출할 수도 있고, XShim이라는 가로채기 계층이 기존 런타임 API를 감쌀 수도 있다.
하드웨어 지원은 세 단계로 나눈다. Level 1은 낮은 우선순위 XQueue의 새 명령 제출을 막지만 이미 장치 큐에 들어간 명령은 모두 끝나기를 기다려야 한다. 대부분의 런타임이 명령 제출과 동기화를 제공하므로 적용 범위가 넓다. Level 2는 대기 중이거나 실행 직전인 명령의 시작도 막아 현재 실행 중인 명령 하나만 남긴다. Level 3은 그 실행 중 명령까지 중단한다. 단계가 높을수록 긴급 작업 앞에 남는 기존 작업이 줄어든다.
이 계층은 모든 장치가 같다고 가정하지 않으면서 정책 코드에 일정한 계약을 준다. 일곱 플랫폼의 기본 Level 1 이식에는 C++ 214~841줄이 필요했다. 고정 우선순위 정책은 104줄, 대역폭 분할은 200줄로 구현했다. Triton과 Paella 기준 구현에 XSched를 연결한 코드는 각각 10줄과 15줄이다. 장치별 차이는 큐 감싸기, 동기화, 드라이버 인터페이스 안에 남는다.
기존 명령을 치울 수 있어야 우선순위가 작동한다
첫 평가는 지연시간에 민감한 전경 프로세스 옆에서 배경 프로세스가 쉬지 않고 명령을 보내는 상황이다. 장치의 기본 스케줄링을 쓰면 전경 작업의 P99 latency가 단독 실행의 1.602.19배로 늘어난다. XSched는 이 범위를 1.021.30배로 낮추며 기본 스케줄링 대비 최대 2.11배 개선한다.
모든 장치에서 같은 방식으로 얻은 결과는 아니다. 점진적 제출 문턱을 명령 여덟 개로 두면 Level 1의 P99 선점 지연시간은 명령 실행시간 T의 약 여덟 배다. Level 2에서는 약 1T로 줄어든다. NVIDIA GV100의 Level 3은 32 microsecond에 도달하며 명령 실행시간의 영향을 받지 않는다. 추상화는 공통이지만 실제로 끊을 수 있는 지점은 hardware마다 다르다.
두 번째 평가는 foreground와 background에 처리량을 75:25로 나눠 달라고 요청한다. native scheduler는 대체로 두 작업을 비슷하게 나눈다. XSched는 평균 총처리량 overhead 1.5%로 목표 비율에 접근한다. AMD MI50, Ascend 910b, Xilinx VU9P에서는 두 process가 더 많은 병렬 작업을 드러내 native 총처리량이 단일 process의 단독 실행값보다 높아지기도 한다. 이런 장치에서는 정책으로 비율을 보장하는 데 측정 가능한 이용률 비용이 따른다.
서로 다른 가속기를 함께 조정할 수도 있다. NPU와 GPU에서 배경 작업이 동시에 돌면 두 장치의 기본 스케줄러는 전경 NPU 작업이 받은 전체 간섭을 보지 못한다. 공통 XSched 정책은 시험한 두 조합에서 P99를 단독 실행의 1.18배와 1.09배로 유지해 기본 스케줄러 대비 최대 2.63배 개선한다.
평균 overhead가 가리는 driver의 차이
Level 1 런타임 overhead는 열 종류 XPU 모두에서 3.4% 미만이다. 점진적 제출 문턱을 명령 열 개보다 크게 잡으면 1% 미만으로 줄지만, Level 1의 선점 대기 구간은 길어진다. Level 2는 시험한 GPU에서 guardian code의 비용을 더하고, Level 3은 장치별 드라이버 인터페이스를 쓴다.
CPU 비용은 대부분 단일 코어의 5% 미만이다. 평균만 보면 놓칠 예외가 두 개 있다. Ascend 910b는 18.3%, NVIDIA PVA는 11.9%까지 올라간다. 두 드라이버가 장치 큐를 동기화할 때 polling loop를 돌기 때문이다. XSched의 스케줄링 논리는 이식할 수 있어도 각 런타임의 대기 방식은 그대로 물려받는다.
세 사례는 애플리케이션에 맞는 정책이 필요한 이유를 보여준다
GPU 자원 회수 사례에서는 production 작업을 우선 처리하고 남은 GV100 용량을 opportunistic 작업이 쓴다. 딥러닝 학습 중 TGS는 GPU의 7.3%를 회수하지만 XSched는 20.0%를 쓴다. 2.74배 늘어난 값이며 production 성능 저하는 1.0%로 제한한다. quota 방식 vCUDA에서는 production 작업이 학습에서 15.1%, 금융 계산에서 80.0% 느려진다. TGS도 특정 제출 패턴에 의존해 금융 계산 성능이 70.0% 낮아진다. Level 1만 지원하는 AMD MI50에서도 XSched의 production 성능 저하는 학습 4.1%, 금융 계산 0.4%였다.
AI PC 사례는 정책 선택의 중요성을 더 잘 보여준다. Intel NPU 한 개에서 배경 흐림은 초당 25 frame으로 실행되고 음성 인식은 3초마다 동작한다. 먼저 들어온 명령을 처리하는 기본 방식에서는 배경 흐림의 P99 frame 간격이 880 ms, 단독 실행의 20.12배까지 늘어난다. 고정 우선순위만 적용하면 영상은 안정되지만 음성 인식이 지나치게 밀려 전사 내용을 잃는다. XSched의 여유시간(laxity) 기반 정책은 음성 인식을 3초 안에 끝내면서 영상 P99를 95 ms로 낮춘다. 기본 방식 대비 9.26배 개선이다.
Triton에서 BERT-large 모델 두 개를 함께 제공할 때 기본 방식과 Triton 우선순위 설정의 전경 P99는 단독 실행의 1.53배와 1.51배다. XSched는 1.07배로 줄여 기본 Triton보다 30% 낮춘다. GPU 전용 Paella와 비교하면 낮은 요청률에서는 비슷하고 초당 1,000개 요청에서는 1.3배 나은 결과를 보였다. 하나의 정책이 모든 서비스를 해결한다는 증거는 아니다. 고정 우선순위, 대역폭 몫, 여유시간을 장치 런타임을 다시 만들지 않고 바꿀 수 있다는 점이 중요하다.
공통 추상화가 하드웨어 한계를 없애지는 않는다
XSched는 CPU가 명령을 보내 수동적으로 동작하는 가속기에 적용된다. 일부 DPU와 FPGA처럼 스스로 작업을 시작하는 장치는 직접 제어하지 못한다. 작업 전체가 나눌 수 없는 명령 하나라면 Level 1과 2의 이득도 작다. Level 3을 지원하거나 모델 분할(model slicing)로 작은 명령 여러 개를 만들어야 한다. 현재 구현은 연산 스케줄링에 집중하며 모든 작업을 담을 장치 메모리가 충분하다고 가정한다. 메모리 초과 할당은 해결하지 않는다.
신뢰 경계도 남는다. 모든 장치 접근을 API remoting이나 하이퍼바이저에서 가로채지 않으면 악의적인 애플리케이션이 XQueue를 우회하거나 명령을 과도하게 넣을 수 있다. GV100의 Level 3에 쓴 드라이버 경로처럼 일부 고급 인터페이스는 문서화되지 않았거나 안정성이 낮다. 따라서 XSched는 모든 환경의 보장을 완성한 시스템이 아니다. 이 논문의 가장 강한 결과는 이기종 가속기가 하나의 정책 언어를 공유하면서도 하드웨어 지원이 끝나는 지점을 숨기지 않을 수 있다는 데 있다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약이다. OSDI 2025 논문의 주장과 결과를 우리 표현으로 다시 쓰고 각 수치에 붙은 평가 조건을 유지했다. 논문의 문장, 표, 도판은 옮기지 않았으며 본문의 두 도판은 이 글을 위해 새로 만들었다. 저작권 (c) 2025 원저자. 논문과 artifact 링크는 USENIX 학회 페이지에서 공개적으로 확인할 수 있다.