연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
T13. 엣지 AI, 스트리밍 추론, 자원 스케줄링
- T13-9후보
INFaaS
한국어 검토 보기
해결 문제
- 사용자가 모델 종류, 하드웨어, 최적화 옵션을 직접 고르기 어렵다.
- 같은 작업이라도 정확도와 지연과 비용 조합이 수없이 많다.
핵심 구조
- 사용자는 목표 정확도와 목표 지연만 적는다.
- 시스템이 학습된 모델에서 여러 변형(정밀도 낮춤, 다른 백엔드 등)을 만든다.
- 질의마다 모델, 하드웨어, 최적화를 골라 배정하고 자동으로 확장한다.
주요 결과
- 처리량 1.3배 향상.
- 지연 목표 위반 횟수 1.6배 감소.
- 비용 평균 8.5배, 최대 21.6배 절감(AWS EC2 기준 비교).
한계
- 모델 변형을 미리 만들고 프로파일링하는 준비 비용이 크다.
- 클라우드 환경을 전제해 자원이 고정된 현장 엣지에는 그대로 맞지 않는다.
검토 메모
- 제목(학회본): INFaaS: Automated Model-less Inference Serving
- 제목(arXiv판): INFaaS: A Model-less and Managed Inference Serving System
- 제목 주의: 같은 연구인데 학회본과 arXiv판의 제목이 다르다. 인용할 때 어느 쪽을 쓰는지 밝혀야 한다.
우리 기능과의 관계
- 업무 실행 에이전트와 AI 보고서에서 작업마다 알맞은 모델과 하드웨어를 자동으로 고르는 향후 적용 후보다.
- T13-10후보
Orca: A Distributed Serving System for Transformer-Based Generative Models
Orca
한국어 검토 보기
해결 문제
- 생성형 모델은 토큰을 한 개씩 이어서 만든다. 요청 하나를 처리하려면 모델을 여러 번 돌려야 한다.
- 기존 서빙 시스템은 한 번 묶은 요청 묶음을 도중에 바꾸지 못한다.
- 그래서 먼저 끝난 요청도 묶음이 다 끝날 때까지 응답을 못 내보낸다. 새로 온 요청도 계속 기다린다.
핵심 구조
- 스케줄링 단위를 요청이 아니라 모델 실행 1회(iteration)로 바꾼다. 이것이 반복 단위 스케줄링이다.
- 토큰 한 개를 만들 때마다 끝난 요청을 빼고 새 요청을 넣는다. 흔히 연속 배칭이라 부르는 방식이다.
- 요청마다 문장 길이가 달라 전부 한 덩어리로 묶을 수 없다. 그래서 묶을 수 있는 연산에만 배칭을 적용한다(선택적 배칭).
주요 결과
- GPT-3 175B 모델 평가 기준이다.
- NVIDIA FasterTransformer 대비 같은 지연 수준에서 처리량 36.9배 향상.
한계
- 트랜스포머 계열 생성형 모델을 전제한다.
- 키값 캐시 메모리를 어떻게 관리할지는 다루지 않는다. 그 문제는 아래 11번 vLLM이 맡는다.
우리 기능과의 관계
- 위 8번 Clockwork가 "생성형 모델에는 그대로 적용하기 어렵다"고 남긴 자리를 이 논문이 채운다. 생성형 모델 스트리밍 추론의 기준점이다.
- AI 보고서와 업무 실행 에이전트에서 생성형 모델 응답을 여러 사용자에게 동시에 흘려보낼 때의 향후 적용 후보다.
- T13-11후보
Efficient Memory Management for Large Language Model Serving with PagedAttention
vLLM
한국어 검토 보기
해결 문제
- 생성형 모델 서빙에서 키값 캐시가 GPU 메모리를 크게 먹는다.
- 요청마다 길이가 다른데 메모리를 이어진 한 덩어리로 미리 잡으면 조각이 남아 낭비된다.
- 메모리가 모자라면 한 번에 묶을 수 있는 요청 수가 줄고 처리량이 떨어진다.
핵심 구조
- 운영체제의 가상 메모리와 페이징 방식을 키값 캐시에 가져온다. 이것이 PagedAttention이다.
- 캐시를 작은 블록으로 쪼개 흩어진 자리에 넣는다. 이어진 공간이 필요 없다.
- 요청끼리 같은 앞부분을 쓰면 블록을 공유한다.
주요 결과
- 같은 지연 수준에서 처리량이 기존 최신 시스템 대비 2~4배 향상.
- 문장이 길수록, 모델이 클수록, 디코딩 알고리즘이 복잡할수록 이득이 커진다.
한계
- 생성형 모델 서빙 전용이다. 일반 추론 서비스에 그대로 옮겨지지 않는다.
- 블록 관리 계층이 추가되므로 구현 복잡도가 올라간다.
우리 기능과의 관계
- 위 10번 Orca와 한 묶음으로 읽어야 한다. Orca는 스케줄링, vLLM은 메모리를 맡는다.
- AI 보고서와 업무 실행 에이전트를 사내 GPU 한정된 대수로 돌릴 때의 향후 적용 후보다.
- T13-12후보
Gandiva: Introspective Cluster Scheduling for Deep Learning
Gandiva
한국어 검토 보기
해결 문제
- 딥러닝 클러스터를 빅데이터용 스케줄러(Kubernetes, YARN)로 돌리면 안 맞는다.
- 학습 작업은 시작할 때 GPU를 잡고 끝날 때까지 안 놓는다. 그래서 대기가 길어진다.
- 사용자는 설정을 여러 개 동시에 돌려보고 빨리 걸러내고 싶어 한다.
핵심 구조
- 딥러닝 학습이 같은 계산(미니배치 반복)을 되풀이한다는 점을 쓴다.
- 그래서 GPU를 시간 단위로 쪼개 여러 작업이 번갈아 쓰게 한다.
- 실행 중 성능을 들여다보고, 더 잘 맞는 GPU로 작업을 옮긴다.
주요 결과
- 하이퍼파라미터 탐색 속도를 최대 10배 수준까지 끌어올렸다.
- GPU 180대 실제 작업 부하에서 클러스터 전체 활용률을 26% 개선했다.
한계
- 작업을 옮기고 시간 분할하려면 프레임워크 쪽 지원이 필요하다.
- 학습 작업 대상이다. 실시간 추론 서비스에는 그대로 안 맞는다.
우리 기능과의 관계
- GPU 자원 스케줄링 축의 대표 선행 연구다. 아래 Tiresias, AntMan, Gavel, Pollux와 계보가 이어진다.
- 제조 AI 분석 모델을 여러 고객사 몫으로 동시에 학습시킬 때의 향후 적용 후보다.
- T13-13후보
Tiresias: A GPU Cluster Manager for Distributed Deep Learning
Tiresias
한국어 검토 보기
해결 문제
- 학습 작업이 얼마나 걸릴지 미리 모른다. 그래서 짧은 것 먼저 돌리는 방법을 못 쓴다.
- 학습은 전부 아니면 전무 방식이라 GPU를 다 잡아야 시작한다.
- 기존 빅데이터 스케줄러를 쓰면 작은 작업도 몇 시간씩 대기한다.
핵심 구조
- 실행 시간을 몰라도 되는 스케줄링 규칙 두 가지를 제안한다.
- 하나는 부분 정보만 쓰는 방식(2차원 Gittins index), 다른 하나는 정보를 아예 안 쓰는 방식(2차원 LAS)이다.
- 둘 다 작업마다 우선순위를 계속 갱신해 평균 완료 시간을 줄인다.
- GPU를 한군데 몰아 배치해야 하는 조건을 언제 풀어도 되는지 밝히고, 그에 맞는 배치 알고리즘을 붙인다.
주요 결과
- P100 GPU 60대(미시간대 ConFlux 클러스터)와 대규모 추적 시뮬레이션으로 평가했다.
- 실제 운영에 쓰이던 Apache YARN 기반 관리자 대비 평균 작업 완료 시간을 최대 5.5배 단축했다.
- 실행 시간을 완벽히 안다고 가정한 방식과 비슷한 성능을 냈다.
한계
- 학습 작업 대상이다. 추론 서비스에는 그대로 안 맞는다.
- 선점(작업 중단 후 재개)이 가능한 환경을 전제한다.
우리 기능과의 관계
- 위 Gandiva와 같은 축이다. 자원 스케줄링을 말하려면 이 논문이 빠지면 안 된다.
- 고객사별 학습 요청이 언제 끝날지 모르는 상태에서 GPU 순서를 정하는 문제와 구조가 대응한다.
- T13-14후보
AntMan: Dynamic Scaling on GPU Clusters for Deep Learning
AntMan
한국어 검토 보기
해결 문제
- 여러 사용자가 같이 쓰는 GPU 클러스터에서 GPU 활용률이 낮았다.
- 그런데도 자원을 못 받아 줄 서 있는 작업이 많았다.
- 학습 작업의 자원 요구량이 시간에 따라 오르내리는데 기존 스케줄러는 이를 못 따라간다.
핵심 구조
- 클러스터 스케줄러와 딥러닝 프레임워크를 같이 설계한다.
- 남는 GPU 자원으로 여러 작업을 한 GPU 위에서 같이 돌린다.
- 프레임워크 안에서 메모리와 연산량을 실행 중에 늘리고 줄인다(동적 확장).
- 그래서 우선순위가 높은 작업이 낮은 작업 때문에 느려지는 일을 막는다.
주요 결과
- 알리바바 실제 운영 환경에 배포했다. GPU 수천 대에서 하루 수만 건 작업을 돌린다.
- 여러 사용자가 공유하는 클러스터에서 GPU 메모리 활용률 42% 개선.
- 연산 활용률 34% 개선. 공평성은 해치지 않았다.
한계
- 프레임워크 내부를 고쳐야 한다. 쓰던 프레임워크를 그대로 두고는 못 쓴다.
- 학습 작업 중심이다. 지연 약속이 걸린 추론 서비스는 별도 검토가 필요하다.
우리 기능과의 관계
- 위 6번 Ekya가 말하는 "추론과 재학습이 같은 GPU를 나눠 쓰는 문제"에 가장 가까운 시스템 논문이다.
- 우선순위가 다른 작업을 한 GPU에 같이 올리는 구조와 대응한다. 현장 서버 한 대로 여러 일을 감당해야 하는 상황에 맞는다.
- T13-15후보
Heterogeneity-Aware Cluster Scheduling Policies for Deep Learning Workloads
Gavel
한국어 검토 보기
해결 문제
- 클러스터에 GPU, TPU, FPGA 등 종류가 섞여 있다. 세대도 다르다.
- 같은 가속기라도 모델 구조에 따라 성능 차이가 크다.
- 기존 스케줄러는 이 차이를 거의 고려하지 않는다. 그래서 느린 하드웨어에 무거운 작업이 붙는 일이 생긴다.
핵심 구조
- 기존 스케줄링 정책들을 최적화 문제 형태로 다시 쓴다.
- 유효 처리량(effective throughput)이라는 개념을 도입한다. 가속기 종류별 성능 차이를 여기에 담는다.
- 그 개념을 써서 기존 정책을 하드웨어 차이를 아는 버전으로 자동 변환한다.
- 라운드 단위로 돌려가며 각 작업이 정책이 정한 몫을 실제로 받게 한다.
주요 결과
- 하드웨어 차이를 모르는 정책 대비 전체 완료 시각(makespan) 1.4배 개선.
- 평균 작업 완료 시간 3.5배 개선.
- 같은 클러스터로 더 높은 입력 부하를 감당했다.
한계
- 작업별 가속기 성능 측정치가 있어야 한다. 새 모델은 다시 재야 한다.
- 학습 작업 대상이다. 추론 서비스는 다루지 않는다.
우리 기능과의 관계
- 자원 스케줄링 축에서 하드웨어가 섞인 경우를 다루는 자리다. Gandiva, Tiresias, AntMan, Pollux와 같은 축이다.
- 고객사마다 다른 세대 GPU가 깔린 현장에서 어디에 어떤 학습을 붙일지 정하는 향후 적용 후보다.
- T13-16후보
Pollux: Co-adaptive Cluster Scheduling for Goodput-Optimized Deep Learning
Pollux
한국어 검토 보기
해결 문제
- 딥러닝 클러스터에서 자원 배분과 학습 설정(배치 크기, 학습률)은 서로 얽혀 있다.
- 따로 정하면 자원을 줘도 실제 학습 진척이 안 는다.
핵심 구조
- 처리량과 통계적 효율을 합친 지표(goodput)를 정의한다.
- 작업마다 자원을 더 주거나 뺐을 때 이 지표가 어떻게 변할지 실시간으로 모델링한다.
- 클러스터 전체 관점에서 자원을 재배분하고 학습 설정도 같이 바꾼다.
주요 결과
- 평균 작업 완료 시간 37~50% 단축.
- 비교 대상에 이상적인 설정을 미리 준 경우에도 우위를 유지했다.
한계
- 학습 작업 대상이다. 추론 서비스에 그대로 적용되지 않는다.
- 작업 도중 자원을 바꿀 수 있는(탄력적인) 학습 프레임워크를 전제한다.
우리 기능과의 관계
- 제조 AI 분석 모델을 여러 고객사 몫으로 동시에 학습시킬 때 GPU 배분을 정하는 향후 적용 후보다.
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기