POLICY OVERVIEW

운영 정책 개요

JPU-Share는 제한된 GPU 자원을 여러 연구실이 공정하게 나누어 사용할 수 있도록 자동화된 배정 시스템을 운영합니다. 이 페이지에서는 GPU가 어떻게 할당되고, 어떤 기준으로 우선순위가 결정되며, 특수한 상황(메모리 부족, 작업 취소 등)에서 어떻게 동작하는지를 설명합니다.

핵심 원칙

GPU TIERS

GPU 티어 시스템

플랫폼의 GPU는 티어(Tier) 단위로 관리됩니다. 각 티어는 GPU 모델, VRAM, 연산 성능(TFLOPS)이 다르며, 성능 순위(sort_order)에 따라 높은 티어부터 배정됩니다.

현재 GPU 티어

배정 흐름

작업이 제출되면, 스케줄러가 5초 간격으로 다음을 수행합니다:

1. 모든 활성 티어를 성능 순(높은 순)으로 정렬
2. 각 티어의 Slurm 파티션에서 유휴 GPU 수를 조회
3. 유휴 GPU가 있는 티어 중 가장 좋은 티어에 배정
4. 모든 티어가 사용 중이면 대기열에서 대기

SCHEDULING

배정 정책

스케줄러는 풀 스캔(Pool-Scan) 방식으로 동작합니다. 매 주기(5초)마다 전체 GPU 풀을 확인하고, 대기 중인 작업 중 가장 우선순위가 높은 작업을 가장 좋은 GPU에 배정합니다.

작업 생명주기

스케줄러 주기

FAIR-SHARE

공정성 정책 (Fair-Share)

GPU 배정의 우선순위는 연구실(Lab) 단위 누적 사용량으로 결정됩니다. 같은 시점에 여러 연구실의 작업이 대기 중이라면, 누적 사용량이 가장 적은 연구실의 작업이 먼저 배정됩니다.

사용량 계산

사용량은 GPU를 점유한 시간 전체를 기준으로 계산됩니다 — 잡이 실제로 실행된 시간뿐만 아니라, 멀티 GPU 잡이 추가 GPU를 기다리며 일부 GPU를 선점하고 있던 시간도 포함됩니다.

사용량 = (점유 GPU 수) × (점유 시간 초) × (티어 TFLOPS)    [단위: TFLOP-seconds]

예를 들어, RTX 4090 (82.6 TFLOPS) 1장을 1시간 실행하면:

1 × 3,600 × 82.6 = 297,360 TFLOP-s

2장을 30분 실행 + 1장을 10분 선점했다면 총합 = 297,360 + 49,560 = 346,920 TFLOP-s.

반감기 소멸 (Half-Life Decay)

누적 사용량은 시간이 지나면 자동으로 감소합니다. 반감기는 1주일이며, 1주일이 지나면 사용량이 절반으로 줄어듭니다.

감쇠된 사용량 = 누적 사용량 × 0.5 ^ (경과 시간 / 1주일)

이 방식의 장점:

• 최근 GPU를 많이 쓴 연구실은 우선순위가 낮아짐
• 오랫동안 안 쓴 연구실은 자연스럽게 우선순위 회복
• 사용량이 무한히 누적되지 않아 장기 불이익 없음

배정 우선순위 결정 과정

1. 글로벌 대기열의 모든 대기 작업을 조회
2. 각 작업이 속한 연구실의 감쇠된 누적 사용량을 계산
3. 사용량이 가장 적은 연구실의 작업을 선택
4. 선택된 작업을 가장 좋은 유휴 GPU에 배정

QUEUE SYSTEM

대기열 시스템

대기열은 2단계 구조로 구성됩니다. 개인 대기열에서 동시 실행 한도를 관리하고, 글로벌 대기열에서 GPU 배정을 기다립니다.

2단계 대기열

동시 실행 슬롯

다음 상태의 작업이 동시 실행 슬롯을 차지합니다:

승격 (Promotion)

작업이 완료되면 슬롯이 하나 비게 됩니다. 시스템은 자동으로 해당 사용자의 개인 대기열에서 다음 작업을 글로벌 대기열로 승격시킵니다.

OOM HANDLING

GPU 메모리 부족 (OOM) 처리

작업이 GPU 메모리 부족(Out of Memory)으로 실패하면, 시스템이 자동으로 더 큰 GPU에서 재시도합니다. 사용자가 직접 재제출할 필요가 없습니다.

OOM 판정 기준

에스컬레이션 흐름

재시도 시 JOB_ATTEMPT 환경변수가 증가합니다. 이를 활용해 체크포인트에서 학습을 재개할 수 있습니다.

MULTI-GPU

멀티 GPU 할당 정책

분산 학습이나 큰 모델 학습처럼 여러 장의 GPU가 필요한 작업도 같은 큐에서 공정하게 처리됩니다. 이 섹션은 우리가 채택한 정책을 — 핵심 원칙부터 미묘한 케이스까지 — 빠짐없이 설명합니다. 정책 설계 과정에서 검토한 옵션과 트레이드오프 전체는 설계 노트(2026-04-10)에서 확인할 수 있습니다.

한 문장 요약

용어

placement는 별도 테이블이 아니라 gpu_resources를 (노드, 티어)로 GROUP BY 해서 자동 도출되는 derived view입니다. 노드를 추가/제거하면 자동 반영됩니다. 두 가지 속성 — capacity(정적 GPU 총수)와 idle(동적, 비어있는 GPU 수) — 을 가집니다. LLM 백필이 점유 중인 GPU도 idle로 봅니다(양보 가능하기 때문).

예시: gpu-4090x2 노드에 4090×2 → placement 1개 (capacity=2). 가상의 노드에 4090×4 + 5090×4 → placement 2개 (각각 capacity=4).

요청 가능 범위 — 모든 사용자에게 동일

잡 제출 시 num_gpus는 1~8 사이여야 합니다. 실제 배정은 매칭되는 placement의 capacity와 티어의 max_gpus를 넘지 못합니다. 현재 RTX 4090 / RTX 3080 Ti 모두 max_gpus = 2이므로 사실상 한 잡당 최대 2장입니다.

잡의 매칭 조건 (2단계)

잡 제출 시 fit한 placement가 하나도 없으면 즉시 거부합니다 (422 NO_FIT_PLACEMENT). 예를 들어 num_gpus=4를 요청했는데 모든 placement의 capacity가 2라면, 영원히 큐에서 못 빠져나오는 상황을 사전에 차단합니다.

큐 — 단일 전역, 매 주기 재계산

글로벌 대기열은 딱 하나입니다. GPU별/노드별/티어별/multi-single 분리 큐가 아닙니다. 모든 잡이 — num_gpus가 1이든 2든 8이든 — 같은 한 줄에 들어가서 fair-share로 정렬됩니다:

ORDER BY lab.cumulative_usage ASC, queue_entered_at ASC

이 정렬은 매 5초 dispatch 주기마다 다시 계산됩니다. 그래서 "1순위" 같은 표현은 잡의 고정 속성이 아니라 지금 이 주기에서의 위치를 의미합니다. 잡들이 들어오고 나가고, 사용량이 누적되면 다음 주기에 순위가 바뀔 수 있습니다.

[글로벌 대기열, 어느 한 주기]
  ├─ jobA  (lab=BCG, num_gpus=2,  cumulative=24k)   ← 1순위
  ├─ jobB  (lab=KDG, num_gpus=1,  cumulative=30k)
  ├─ jobC  (lab=OSL, num_gpus=2,  cumulative=116k)
  └─ jobD  (lab=OSL, num_gpus=1,  cumulative=116k)

핵심 원칙 — 큐 순서를 절대 어기지 않는다

JPU-Share의 매칭 정책은 한 줄로 요약됩니다: fair-share 1순위 잡은 절대 다음 차례를 양보하지 않는다. 1순위 잡이 멀티 GPU여서 가용한 placement가 부족해도, 뒤에 있는 싱글 잡이 새치기해서 먼저 들어오는 일은 없습니다. 대신 1순위 잡은 가용 GPU를 선점(reservation)해두고 나머지 GPU가 모일 때까지 기다립니다.

Dispatch 알고리즘 (매 5초)

1. placement별 (capacity, idle) 조사
   - 활성 reservation이 점유한 GPU는 idle에서 차감
2. 잡을 fair-share 키로 정렬
3. 1순위부터 잡을 차례로 검사:

   (a) 잡의 fit placement 중 available한 게 있으면:
       → 즉시 dispatch
       → 만약 이 잡이 다른 placement에서 reservation 보유 중이었으면
         그 reservation 해제 (★ swap — 더 빠른 경로로 점프)

   (b) available 없음 + 잡이 reservation 보유:
       → 같은 placement의 추가 idle을 reservation에 흡수
       → 충족되면 (a)로 복귀하여 dispatch

   (c) available 없음 + reservation 미보유 + 잡이 1순위 + num_gpus ≥ 2:
       → 새 reservation 시작
       → placement 선택: tier sort_order DESC, 같으면 idle DESC

4. 다음 순위 잡으로 진행 (이미 사용된 GPU는 빼고 계산)

핵심은 (a)의 swap입니다. 매 주기마다 "지금 즉시 dispatch 가능한 placement가 있는지"를 가장 먼저 확인합니다. 그래서 placement A에서 1장 reserve 중인데 placement B에서 갑자기 2장 동시에 free되는 시나리오가 자연스럽게 처리됩니다 — 다음 주기에 (a)가 B를 발견하고 그쪽으로 dispatch, A의 reservation은 자동 해제됩니다.

Reservation 규칙 5조

사용량 가산 — Lazy 정책

Reservation 진행 중에는 lab의 cumulative_usage에 아무것도 가산하지 않습니다. 가산은 잡이 어떤 형태로든 종료되는 시점에 한꺼번에 일어납니다. 이 정책을 "Lazy 가산"이라고 부릅니다.

선점 비용 = (선점 GPU 수) × (선점 시간 초) × (티어 TFLOPS)
실행 비용 = (실행 GPU 수) × (실행 시간 초) × (티어 TFLOPS)

핵심 invariant: 잡이 점유한 모든 GPU-second는 빠짐없이 lab usage로 가산됩니다. 다만 가산 시점이 lazy(잡 종료 시점)일 뿐입니다.

예시 — num_gpus=2 잡이 4090 1장을 10분 선점한 뒤 추가 1장이 들어와 30분간 정상 실행되었다면:

R3 시나리오 예시 — internal vs external trigger

가장 미묘한 케이스입니다. Lazy 가산의 핵심은 자기 잡의 reservation 비용으로 자기가 1순위에서 밀려나는 자살적 자기교정을 차단하는 것입니다. 1순위에서 밀리는 일은 오직 외부 사용량 변동에 의해서만 발생해야 합니다.

T+0:    잡X (BCG, num_gpus=2) reservation 시작. 1순위. 1/2장 선점.
        잡Y (BCG, num_gpus=1, 다른 사용자) 별도로 RUNNING 중.
        BCG.cumulative_usage = 24k

T+5분:  잡Y 정상 종료 → record_job_usage(Y) → BCG.cumulative_usage += 잡Y 비용
        → BCG = 32k. 다른 lab KDG (28k) < BCG. KDG가 1순위로 올라옴.

T+5분+ε: 다음 dispatch 주기. 잡X는 2순위로 강등.
        → R3 발동: 잡X reservation 강제 해제
        → 선점 비용 (1장 × 5분 × 82.6 ≈ 24,780) BCG에 가산
        → 잡X는 GLOBAL_QUEUE_WAIT로 복귀

T+15분: KDG 잡들 진행/종료로 다시 BCG가 1순위 됨
        → 잡X 다시 reservation 시작 가능 (처음부터)

이게 사용자 직관과 일치합니다 — 내가 한 일 때문에 밀리는 게 아니라 다른 사람들의 활동 때문에 밀립니다. Reservation 자체는 lab usage 변동을 만들지 않으므로, 자기 잡의 reservation 때문에 자기가 1순위에서 떨어지는 일은 발생하지 않습니다.

이 정책이 보장하는 것

• Starvation 없음 — 1순위 잡은 어떤 경우에도 양보하지 않으므로, 멀티 GPU 잡이 영원히 밀리는 상황이 발생하지 않습니다
• 남용 자기교정 — 같은 lab이 멀티 GPU 잡을 연속해서 던지면 잡 종료 시점마다 사용량이 lab에 누적되어 다른 lab에게 차례가 넘어갑니다
• Utilization 손실 없음 — 선점된 GPU에서 LLM 백필이 계속 추론을 처리합니다
• 큐 순서가 직관과 일치 — fair-share 점수가 낮은 lab의 잡이 먼저 처리되며, multi/single 구분으로 인한 새치기가 없습니다
• 이종 placement 자동 처리 — 한 노드에 여러 GPU 모델이 있어도 placement가 자동으로 분리되어 매칭됩니다

리소스 비례 할당 (CPU / RAM)

멀티 GPU 잡은 GPU 수에 비례해서 CPU와 RAM도 함께 점유합니다. GPU 1장당 충분한 데이터로더/메모리를 보장하기 위한 설계입니다.

의도된 한계

• 이종 placement 분산 학습 불가: 멀티 GPU 잡은 단일 placement 안에서만 실행됩니다. 한 노드에 4090×4 + 5090×4가 있어도 num_gpus=8은 받을 수 없습니다 (각 placement는 capacity=4). 분산 학습은 동종 GPU 한정입니다.
• 2순위 이하 멀티 GPU 잡의 latency: 1순위가 reservation 중이면 2순위 멀티 잡은 reservation 권한 없이 그냥 기다립니다. 1순위가 dispatch되어야 자기 차례가 옵니다. starvation은 아니지만 latency는 길 수 있습니다.

설계 노트 — 우리가 고민한 것들

이 정책은 단순히 떠올린 게 아니라 여러 트레이드오프를 거쳐 결정된 것입니다. 핵심 결정과 그 이유를 짧게 정리합니다 — 전체 논의 흐름은 설계 노트(2026-04-10)를 참고하세요.

핵심 가치: 단순함과 정직함. 새 enum 0개, 새 테이블 0개, 새 worker loop 0개로 구현됩니다. Job 테이블에 컬럼 4개만 추가하면 됩니다.

LLM BACKFILL

LLM 백필 (유휴 GPU 활용)

연구 작업이 없는 유휴 GPU에서는 LLM(대규모 언어 모델) 추론 서비스가 자동으로 배포됩니다. 이를 통해 GPU가 놀지 않고 항상 활용됩니다.

선점 (Preemption) 정책

연구 작업과 LLM의 관계는 명확합니다:

• 연구 작업이 항상 우선 — GPU가 필요하면 LLM이 즉시 양보합니다
• LLM 서비스는 Slurm의 preemptible 파티션에서 실행됩니다
• 연구 작업이 제출되면, 스케줄러가 LLM이 점유한 GPU를 회수하고 연구 작업에 배정합니다
• 연구 작업이 끝나면 LLM이 다시 자동 배포됩니다

ISOLATION & SECURITY

격리와 보안

모든 작업은 안전하게 격리된 환경에서 실행됩니다.

컨테이너 격리

• 모든 작업은 Apptainer(Singularity) 컨테이너 내부에서 실행됩니다
• 호스트 시스템에 직접 접근할 수 없습니다
• 각 사용자는 고유한 Unix UID로 실행되어, 다른 사용자의 프로세스나 파일에 접근할 수 없습니다

네트워크 격리

• 작업 실행 중 외부 네트워크가 완전히 차단됩니다
• pip install, wget, wandb 원격 로깅 등 불가
• 필요한 패키지는 워크스페이스 빌드 시 미리 설치 (빌드 시에만 네트워크 허용)
• 외부 데이터는 관리자에게 요청하여 공유 경로에 사전 배치

스토리지 격리

• 출력 디렉토리(JOB_OUTPUT_DIR)는 작업별로 분리됩니다
• NFS 공유 스토리지에서 UID 기반 파일 소유권 분리
• 다른 사용자의 출력 파일에 접근할 수 없습니다

작업 제한

작업 취소

사용자가 작업을 취소하면 다음 절차로 처리됩니다:

1. SIGTERM 신호 전송 (정상 종료 요청)
2. 30초 대기 (프로세스가 체크포인트를 저장할 시간)
3. 여전히 실행 중이면 5분 후 SIGKILL 강제 종료

MAINTENANCE MODE

점검 모드 (Maintenance Mode)

NFS 볼륨 교체, Slurm controller 점검 등 전역 운영 작업이 필요할 때 관리자가 시스템을 점검 모드로 전환합니다. 점검 중에는 새로운 작업 제출이 차단되고, 웹 콘솔 상단에 배너가 표시됩니다.

상태 단계

1. DRAINING: 새 작업 제출 차단. 실행 중인 사용자 작업은 정상 완료. LLM backfill은 계속 동작하여 유휴 GPU 활용.
2. BACKFILL_RECOVERY: 사용자 작업이 모두 종료된 후 LLM backfill 자동 회수.
3. ACTIVE: backfill 완료 후 진입. 이 시점부터 운영 작업 수행 가능.
4. NORMAL 복귀: 관리자가 점검 종료 시 이전 대기 작업이 우선순위대로 자동 실행됩니다.

사용자 영향

• 작업 제출 (POST /v1/jobs)은 점검 중 503 SERVICE_MAINTENANCE 응답을 반환합니다.
• 기존 작업 취소 (POST /v1/jobs/{id}/cancel)는 DRAINING 단계에서 허용됩니다.
• 작업·파일·워크스페이스 조회 등 모든 GET 요청은 점검 중에도 정상 동작합니다.
• 점검 창구: 웹 콘솔 상단 배너 + GET /v1/maintenance/status 엔드포인트 (익명 허용).