가속기는 애플리케이션이 경합을 알아채기 어려운 계층에서 공유됩니다. 긴급한 전경 요청과 여유 자원을 쓰려는 배경 작업이 서로 다른 소프트웨어 계층을 지나도 결국 장치 명령 큐에서 만납니다. 그 큐가 먼저 들어온 명령부터 실행하면 긴급 작업은 이미 받아들인 낮은 우선순위 명령이 끝날 때까지 기다립니다. XSched는 애초에 같은 제어 기능을 갖도록 설계되지 않은 여러 장치에 하나의 소프트웨어 스케줄러로 우선순위와 대역폭 정책을 적용할 수 있는지 묻습니다[1].
평가 범위는 의도적으로 넓습니다. 일곱 소프트웨어 플랫폼을 통해 열 종류 XPU를 시험했습니다. NVIDIA, AMD, Intel GPU, Intel과 Ascend NPU, NVIDIA DLA, PVA, OFA 고정 기능 가속기, Xilinx FPGA가 포함됩니다. 스케줄링 기능이 거의 없는 구형 장치부터 실행 중 명령을 중단할 수 있는 Volta GPU까지 세대 차이도 큽니다. 이 다양성이 논문의 핵심입니다. 최신 CUDA GPU 하나에서만 동작하는 스케줄러로는 AI PC, 임베디드 시스템, 이기종 서버의 경합을 함께 다룰 수 없습니다.
XQueue가 정책과 장치 큐를 분리하는 방식
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 지연시간이 단독 실행의 1.60~2.19배로 늘어납니다. XSched는 이 범위를 1.02~1.30배로 낮추며 기본 스케줄링 대비 최대 2.11배 개선합니다.
모든 장치에서 같은 방식으로 얻은 결과는 아닙니다. 점진적 제출 임곗값을 명령 여덟 개로 두면 Level 1의 P99 선점 지연시간은 명령 실행시간 T의 약 여덟 배입니다. Level 2에서는 약 1T로 줄어듭니다. NVIDIA GV100의 Level 3은 32 마이크로초에 도달하며 명령 실행시간의 영향을 받지 않습니다. 추상화는 공통이지만 실제로 끊을 수 있는 지점은 하드웨어마다 다릅니다.
두 번째 평가는 전경과 백그라운드 작업에 처리량을 75:25로 나눠 달라고 요청합니다. 기본 스케줄러는 대체로 두 작업을 비슷하게 나눕니다. XSched는 평균 총처리량 오버헤드 1.5%로 목표 비율에 접근합니다. AMD MI50, Ascend 910b, Xilinx VU9P에서는 두 프로세스가 더 많은 병렬 작업을 드러내 기본 총처리량이 단일 프로세스의 단독 실행값보다 높아지기도 합니다. 이런 장치에서는 정책으로 비율을 보장하는 데 측정 가능한 이용률 비용이 따릅니다.
서로 다른 가속기를 함께 조정할 수도 있습니다. NPU와 GPU에서 배경 작업이 동시에 돌면 두 장치의 기본 스케줄러는 전경 NPU 작업이 받은 전체 간섭을 보지 못합니다. 공통 XSched 정책은 시험한 두 조합에서 P99를 단독 실행의 1.18배와 1.09배로 유지해 기본 스케줄러 대비 최대 2.63배 개선합니다.
평균 오버헤드가 가리는 드라이버의 차이
Level 1 런타임 오버헤드는 열 종류 XPU 모두에서 3.4% 미만입니다. 점진적 제출 임곗값을 명령 열 개보다 크게 잡으면 1% 미만으로 줄지만, Level 1의 선점 대기 구간은 길어집니다. Level 2는 시험한 GPU에서 보호 코드(guardian code)의 비용을 더하고, Level 3은 장치별 드라이버 인터페이스를 씁니다.
CPU 비용은 대부분 단일 코어의 5% 미만입니다. 평균만 보면 놓칠 예외가 두 개 있습니다. Ascend 910b는 18.3%, NVIDIA PVA는 11.9%까지 올라갑니다. 두 드라이버가 장치 큐를 동기화할 때 폴링 순환 구조를 돌기 때문입니다. XSched의 스케줄링 논리는 이식할 수 있어도 각 런타임의 대기 방식은 그대로 물려받습니다.
세 사례는 애플리케이션에 맞는 정책이 필요한 이유를 보여 주는 효과
GPU 자원 회수 사례에서는 운영 환경 작업을 우선 처리하고 남은 GV100 용량을 유휴 자원 활용 작업이 씁니다. 딥러닝 학습 중 TGS는 GPU의 7.3%를 회수하지만 XSched는 20.0%를 씁니다. 2.74배 늘어난 값이며 운영 환경 성능 저하는 1.0%로 제한합니다. quota 방식 vCUDA에서는 운영 환경 작업이 학습에서 15.1%, 금융 계산에서 80.0% 느려집니다. TGS도 특정 제출 패턴에 의존해 금융 계산 성능이 70.0% 낮아집니다. Level 1만 지원하는 AMD MI50에서도 XSched의 운영 환경 성능 저하는 학습 4.1%, 금융 계산 0.4%였습니다.
AI PC 사례는 정책 선택의 중요성을 더 잘 보여 줍니다. Intel NPU 한 개에서 배경 흐림은 초당 25프레임으로 실행되고 음성 인식은 3초마다 동작합니다. 먼저 들어온 명령을 처리하는 기본 방식에서는 배경 흐림의 P99 프레임 간격이 880ms, 단독 실행의 20.12배까지 늘어납니다. 고정 우선순위만 적용하면 영상은 안정되지만 음성 인식이 지나치게 밀려 전사 내용을 잃습니다. XSched의 여유시간(laxity) 기반 정책은 음성 인식을 3초 안에 끝내면서 영상 P99를 95ms로 낮춥니다. 기본 방식 대비 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을 지원하거나 모델 분할(모델 slicing)로 작은 명령 여러 개를 만들어야 합니다. 현재 구현은 연산 스케줄링에 집중하며 모든 작업을 담을 장치 메모리가 충분하다고 가정합니다. 메모리 초과 할당은 해결하지 않습니다.
신뢰 경계도 남습니다. 모든 장치 접근을 API remoting이나 하이퍼바이저에서 가로채지 않으면 악의적인 애플리케이션이 XQueue를 우회하거나 명령을 과도하게 넣을 수 있습니다. GV100의 Level 3에 쓴 드라이버 경로처럼 일부 고급 인터페이스는 문서화되지 않았거나 안정성이 낮습니다. 따라서 XSched는 모든 환경의 보장을 완성한 시스템이 아닙니다. 이 논문의 가장 강한 결과는 이기종 가속기가 하나의 정책 언어를 공유하면서도 하드웨어 지원이 끝나는 지점을 숨기지 않을 수 있다는 데 있습니다.
선점 기능은 실행계의 문제이자 구매 사양
XSched는 일반적인 가속기 비교에서 빠지는 하드웨어 계약을 드러냅니다. 최고 처리량은 한 작업이 얼마나 빨리 실행되는지 말하고, 선점 수준은 긴급한 작업이 앞선 작업을 얼마나 기다려야 하는지 말합니다. 공유 시스템에서는 이 대기량이 지연시간의 하한을 정합니다. 처리량이 비슷한 두 장비도 하나는 명령 경계에서 멈출 수 있고 다른 하나는 이미 들어간 큐 전체를 기다려야 한다면 수용 가능한 서비스 밀도가 달라집니다.
구매 사양에는 메모리와 대역폭뿐 아니라 선점 특성이 필요합니다. 가장 작은 중단 단위, 최악의 명령 실행 시간, 큐 깊이 제어, 문맥 전환 비용, 메모리 격리, 인터페이스의 공개성과 안정성을 적어야 합니다. XSched는 공통 정책 언어를 제공하지만 Level 1 하드웨어에서 Level 3 동작을 만들어 낼 수는 없습니다. 공급자가 거친 큐만 제공한다면 플랫폼은 명령을 작게 나누거나 작업 수용을 보수적으로 하거나 전용 용량을 남겨 보상해야 합니다.
사업적으로는 커널 효율뿐 아니라 간섭을 견딜 수 있는 정도에 따라 이종 장비를 배정해야 합니다. 고정 기능 가속기는 예측 가능한 파이프라인에는 적합하지만 대화형 작업을 섞기 어려울 수 있습니다. 더 강한 중단 기능이 있는 GPU는 전면 서비스의 SLO를 지키면서 낮은 우선순위 작업을 수용할 수 있습니다. 전체 장비 최적화는 단독 성능과 안전한 공유가 만드는 선택 가치를 함께 가격에 넣어야 합니다. GV100에서 20% 용량을 회수한 결과는 스케줄러가 빨라졌다는 뜻만이 아닙니다. 더 나은 선점 계약이 실제 서비스 작업에 위험을 넘기지 않고 버려진 시간을 판매 가능한 자원으로 바꿀 수 있다는 근거입니다.
선점은 애플리케이션 의미를 보존해야 할 이유
장치 큐를 멈추는 일은 상태 없는 CPU 스레드를 잠시 멈추는 것과 다릅니다. 가속기에는 부분 결과, 로컬 메모리, 동기화 상태, 외부 부작용이 남을 수 있습니다. 어느 지점에서 멈추고, 어떤 상태가 유효하며, 이어서 실행할지 처음부터 다시 할지를 장치별로 정해야 합니다.
멱등 추론 커널은 다시 시작하기 쉽지만 긴 FPGA 파이프라인은 체크포인트가 필요할 수 있고, 공유 메모리나 다른 장치와 통신하는 명령은 함께 멈춰야 할 수 있습니다. 드라이버가 실행 중 명령을 끊지 못하면 우선순위는 명령이 끝날 때까지 작동하지 않습니다. 이 최악 시간을 측정하고 한 고객이 높은 우선순위 서비스를 무한정 기다리게 하지 못하도록 큐 범위를 제한해야 합니다.
공정성에 필요한 우선순위 이상의 정보
엄격한 우선순위는 긴급 작업을 보호하지만 배경 작업을 굶길 수 있고, 가중 공유는 진행을 보장해도 마감 시간을 놓칠 수 있습니다. 우선순위, 마감, 최소 몫, 선점 비용을 서비스 목표에 연결해야 합니다. 큰 상태를 가진 GPU 문맥이나 재프로그래밍이 필요한 장치는 기다리는 편이 더 쌀 수 있습니다.
버린 작업, 상태 이동, 캐시 준비, 큐 대기를 고객과 플랫폼 비용에 포함하고, 완료 요청이나 작업당 장치 시간과 SLO 충족률을 함께 보고해야 정책을 공정하게 비교할 수 있습니다.
이식성은 검증된 기능표에 달려 있는 구조
장치와 드라이버마다 큐 동작, 선점 단위, 상태 보존, 우선순위, 격리, 재설정, 장애 처리를 표로 관리해야 합니다. 지원하지 않는 기능은 다른 의미로 조용히 바꾸지 말고 명확히 실패해야 합니다. 드라이버와 펌웨어 갱신 뒤 최악 선점, 취소, 복구를 다시 시험하고 위반마다 백엔드 버전을 남겨야 합니다.
선점한 고객의 메모리와 큐 상태가 다음 고객에게 보이지 않는지도 검증해야 합니다. 강한 재설정이 필요한 장치는 늘어난 복구 시간을 스케줄러 비용에 넣어야 하며 격리를 생략해서는 안 됩니다.
하나의 실제 충돌부터 도입해야 할 이유
긴급 추론과 배치 작업의 경쟁처럼 구체적인 사례에서 현재 큐 대기, 마감 실패, 명령 길이, 상태 크기, 재설정을 측정한 뒤 적용하는 편이 좋습니다. 관찰 모드, 협력적 중단 지점, 실제 장치 선점 순으로 확대하면 정책의 가치와 하드웨어 기능을 분리할 수 있습니다.
XSched의 오래 남는 가치는 서로 다른 가속기가 같은 방식으로 멈춘다고 가정하지 않으면서 정책과 장치 큐를 분리한 데 있습니다. 최종 수용 주장은 지원 장치 수가 아니라 기능과 비용표를 붙인 상태에서 SLO와 격리 범위 안에 해결한 서비스 충돌이어야 합니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약입니다. OSDI 2025 논문의 주장과 결과를 우리 표현으로 다시 쓰고 각 수치에 붙은 평가 조건을 유지했습니다. 논문의 문장, 표, 도판은 옮기지 않았으며 본문의 두 도판은 이 글을 위해 새로 만들었습니다. 저작권 (c) 2025 원저자. 논문과 산출물 링크는 USENIX 학회 페이지에서 공개적으로 확인할 수 있습니다.