AI 워크로드 스케줄링과 양자 컴퓨팅 OS 튜닝: 이기종 자원을 다루는 실무 원칙

GPU 스케줄러와 양자 프로세서가 같은 문제를 풀어야 하는 이유

GPU·TPU·NPU 같은 가속기와 CPU·메모리·스토리지·네트워크가 뒤섞인 이기종 자원 환경에서는 성능·비용·신뢰성의 균형을 잡는 일이 곧 스케줄링 문제다. 여기에 양자 컴퓨팅이 실무에 들어오면서 문제가 하나 더 겹쳤다 — QPU는 큐 타임과 데코히런스, 교정(calibration) 주기라는 물리적 제약을 스케줄링 정책에 직접 반영해야 한다. 이 글은 AI 워크로드 스케줄링과 양자 워크로드를 위한 OS 최적화를 하나의 공동 설계(co-design) 관점에서 정리하고, 실무에서 바로 적용할 수 있는 절차와 트레이드오프를 짚는다.

정의와 설계 원칙

AI Workload Scheduling은 GPU/TPU/NPU 등 가속기와 CPU/메모리/스토리지/네트워크를 자원 모델로 추상화하고, SLO·비용·우선순위에 따라 작업을 배치하는 운영 메커니즘이다. Kubernetes 같은 컨테이너 오케스트레이션과 Slurm 같은 배치 스케줄러의 정책 엔진을 통해 공정성·선점·백필(backfill)·갱 스케줄링(gang scheduling)을 구현한다.

OS Optimization for Quantum Computing은 클래식-양자 하이브리드 워크플로우에서 QPU 호출 지연·지터를 최소화하고, 제어 펄스 타이밍·교정 윈도우를 만족하도록 커널·드라이버·런타임을 조정하는 최적화 기법이다. 실시간 스케줄링(PREEMPT_RT), CPU 격리, 고해상도 타이머, IRQ/NUMA 친화도 최적화가 여기 포함된다. 다만 AWS Braket이나 IBM Qiskit Runtime 같은 상용·클라우드 런타임의 세부 사양은 빠르게 바뀌므로 최신 정보를 별도로 확인해야 한다.

두 영역을 관통하는 설계 원칙은 결국 하나다. 아키텍처(토폴로지, 캐시/NUMA, 가속기 격리)와 OS 정책(스케줄러, 메모리, I/O)이 서로 제약하고 강화하는 관계이기 때문에 공동 설계가 필요하다는 것. 지연의 예측 가능성, 처리량 극대화, 비용-성능 곡선 최적화, 실패 격리와 자동 복구가 이 공동 설계가 겨냥하는 네 가지 목표다.

스케줄러가 실제로 다루는 다섯 겹의 문제

실무 스케줄러를 뜯어보면 다섯 겹의 문제가 쌓여 있다.

가장 아래는 자원 모델과 토폴로지 인지다. GPU 파티셔닝(MIG), HBM/NUMA 인접성, PCIe 토폴로지, 로컬 NVMe·원격 스토리지 대역폭을 모델링하고, QPU는 큐 타임·데코히런스·교정 주기 같은 물리 제약을 일정·배치 제약으로 반영한다. 그 위에 정책 엔진과 SLO 기반 의사결정이 올라간다 — 공정성 대 처리량, 비용 상한, 데이터 지역성, 선점·재시작 허용 여부를 가중치로 표현하고, 학습형(RL) 스케줄러는 텔레메트리 기반 정책 업데이트로 비용·SLA 준수 같은 장기 보상을 최적화한다.

세 번째 층은 큐잉·어드미션·갱 스케줄링이다. 우선순위 클래스, 리소스 보장·버스트, 백필로 자원 공백을 최소화하고, 분산 학습이나 동시 시작이 필요한 작업은 PodGroup·JobGroup 기반 갱 스케줄링으로 처리한다. 네 번째는 피드백 제어와 자동화다. 큐 지연·GPU 활용도·실패율 같은 메트릭이 정책 업데이트와 오토스케일(노드·파드)로 이어지는 폐루프를 이루고, 비정상이 감지되면 재시도·격리·롤백이 표준화된 절차로 작동한다. 마지막은 신뢰성·보안·격리다. 커널·드라이버 버전을 고정하고 cgroups v2·device plugin·SR-IOV로 강한 격리를 확보하며, QPU 접근에는 테넌트 격리와 예약·인증 토큰, 저지연 네트워크 경로 보호가 적용된다.

실무 시나리오

K8s에서 MIG로 GPU를 쪼개 파인튜닝 SLA를 지키는 경우

엔터프라이즈 MLOps 환경에서 흔한 목표는 비용 한도 안에서 학습 처리량을 극대화하면서 실패 시 자동 복구하고 데이터 지역성을 유지하는 것이다. Kubernetes 1.27 이상, NVIDIA Device Plugin v0.14 이상, MIG가 활성화된 환경을 전제로, 리소스 요청을 명시하고 우선순위·선점 정책을 설정한 뒤 백필·HPA를 연동하고 드라이버·런타임 버전을 고정하는 순서로 진행한다.

apiVersion: batch/v1
kind: Job
metadata:
  name: finetune-llm
spec:
  completions: 1
  backoffLimit: 2
  template:
    spec:
      priorityClassName: high-priority
      restartPolicy: OnFailure
      containers:
        - name: trainer
          image: nvcr.io/nvidia/pytorch:23.10-py3
          resources:
            requests:
              nvidia.com/mig-1g.10gb: "2"
              cpu: "8"
              memory: "32Gi"
            limits:
              nvidia.com/mig-1g.10gb: "2"
          env:
            - name: NCCL_NET_GDR_LEVEL
              value: PHB
      nodeSelector:
        nvidia.com/mig.config: "all-1g.10gb"
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: finetune

MIG로 자원을 분할하고, 우선순위·선점으로 SLA를 보호하고, 토폴로지 스프레드로 핫스팟을 완화하는 세 가지가 이 예제의 핵심 운영 포인트다.

Slurm 갱 스케줄링으로 분산 학습의 동시 시작을 보장하는 경우

노드 여러 대에 걸친 분산 학습에서는 통신 바운드를 줄이는 게 관건이다. Slurm 22.x와 NVSwitch·InfiniBand 환경을 전제로, PodGroup·Slurm gang-alloc으로 자원을 동시에 확보한 뒤 NCCL·OFED를 튜닝하고 실패 시 재큐잉하는 흐름을 따른다.

#!/bin/bash
#SBATCH -J ddp-train
#SBATCH -N 2
#SBATCH --ntasks-per-node=4
#SBATCH --gpus-per-node=4
#SBATCH -p gpu
#SBATCH --exclusive
srun --cpu_bind=cores --accel-bind=gn ./train.sh

exclusive 할당으로 다른 작업과의 간섭을 없애고, 백필을 허용해 자원 공백을 줄이는 것이 이 패턴의 운영 포인트다.

양자-클래식 하이브리드에서 QPU 호출 지터를 잡는 경우

양자 워크로드는 앞의 두 경우와 성격이 다르다. 목표는 처리량이 아니라 QPU 호출 지연·지터를 최소화해 교정 윈도우 안에 배치를 맞추는 것이다. CPU에서 전처리한 뒤 QPU에 배치(예약·슬롯)하고, 결과를 수집해 에러를 완화하고 피드백을 반복하는 절차를 따른다. Linux 6.x + PREEMPT_RT 환경을 전제로 RT 커널, CPU·IRQ 격리, 고해상도 타이머가 운영 포인트다. 다만 클라우드 런타임의 파라미터·슬롯 정책은 계속 바뀌므로 최신 정보를 확인해야 한다.

# /etc/default/grub
GRUB_CMDLINE_LINUX="isolcpus=2-7 nohz_full=2-7 rcu_nocbs=2-7 intel_pstate=disable idle=poll"
# IRQ affinity 예시
echo 0xFC > /proc/irq/XX/smp_affinity  # CPU0 제외

어드미션부터 피드백까지, 한 요청이 지나는 경로

워크로드 스펙(CPU/GPU/QPU)과 SLO, 우선순위를 담은 요청 하나가 스케줄러를 통과하는 경로를 그리면 아래와 같다.

⤢✕

정상 경로에서는 어드미션 통과 후 정책 엔진이 자원 요청을 만들고 잠금을 획득해 배치·실행으로 이어지지만, 자원이 부족하거나 잠금에 실패하면 대기열 재배치를 거쳐 정책 엔진으로 되먹임된다는 점이 이 흐름의 핵심이다. 실행 이후에도 모니터링 결과가 다시 정책 엔진으로 들어가는 폐루프 구조다.

접근법별 성능·확장성 비교

다섯 가지 접근법은 저마다 다른 트레이드오프를 갖는다.

접근	성능(처리량/지연)	확장성	일관성/예측 가능성	운영 편의
규칙 기반	튜닝 수준에 따라 중간	높음(단순)	높음(결정적)	높음(이해 용이)
우선순위/선점	긴급 작업 지연 최적	높음	중간(선점 오버헤드)	중간(정책 충돌 관리 필요)
RL/학습형	장기 보상 최적화 우수	높음	중간(학습 수렴 의존)	낮음(관측/학습 파이프 필요)
갱 스케줄링	동기 워크로드 성능 우수	중간(자원 파편화)	높음(동시 시작 보장)	중간(큐 관리 복잡)
양자 런타임	지연·지터 최소화	중간(슬롯 제약)	높음(창구 예약)	낮음(전용 튜닝·슬롯 관리)

규칙 기반이 이해하기 쉽고 결정적인 대신, RL 기반은 장기 보상 최적화에서는 우수하지만 학습 수렴에 의존해 예측 가능성이 떨어지고 관측·학습 파이프라인 구축 부담도 크다. 갱 스케줄링은 동기 워크로드에서 강하지만 자원 파편화 위험을 안고, 양자 런타임은 지연·지터를 최소화하는 대신 슬롯 제약으로 확장성이 제한된다.

도입 효과와 그 편차

백필·갱 스케줄링·MIG 병렬화를 도입하면 학습·추론 처리량이 무정책 FIFO 대비 15~~40% 향상되는 것으로 보고된다. RT 커널과 CPU 격리를 적용하면 QPU 호출 지연 p95가 20~~50% 감소하고 지터 표준편차는 30% 이상 줄어든다. 선점·비용 가중 정책을 쓰면 유휴 자원이 1025% 절감되고, 스팟·온디맨드를 혼합하면 20% 추가 절감이 가능하다. 우선순위·어드미션 제어를 갖추면 마감 준수율이 95%에서 99% 수준으로 개선되고, 버전 고정과 격리 강화로 장애 전파율이 줄면서 MTTR이 2035% 단축되는 효과도 보고된다.

다만 이 수치들은 워크로드 특성(분산성, 체크포인트 가능성), 클러스터 규모(100 GPU 초과 기준), 네트워크 패브릭 상태에 따라 편차가 있다는 전제를 깔고 있다.

도입 순서와 남는 리스크

핵심은 이기종 자원 토폴로지를 인지하고, SLO 기반 정책 엔진과 큐잉·선점·갱 스케줄링, 피드백 폐루프를 갖추는 것이다. 양자 워크로드는 여기에 RT·지터 관리와 슬롯·교정 윈도우 제약을 OS 수준에서 흡수해야 한다는 조건이 하나 더 붙는다.

도입은 단계적으로 가는 게 안전하다. 자원·성능 텔레메트리를 표준화하고, 정책 가중치를 설정하며 캐너리 실험을 거치고, 드라이버·커널 버전을 고정한 뒤, 선점·백필을 단계적으로 활성화하고, 양자 워크로드는 RT 커널·CPU/IRQ 격리부터 시작하는 순서다. 다만 학습형 정책은 설명 가능성과 운영 복잡도가 함께 늘고, 갱 스케줄링은 파편화 위험을, RT 튜닝은 일반 워크로드와의 자원 경쟁을 감수해야 한다. 점진 도입과 A/B 검증을 권장하는 이유다.