연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
T13. 엣지 AI, 스트리밍 추론, 자원 스케줄링
- T13-1구조대응
Neurosurgeon: Collaborative Intelligence Between the Cloud and Mobile Edge
Neurosurgeon
한국어 검토 보기
해결 문제
- 딥러닝 추론을 단말에서 다 돌리면 느리고 배터리를 먹는다.
- 전부 클라우드로 보내면 통신량이 커지고 지연이 늘어난다.
핵심 구조
- 신경망을 층 단위로 쪼갠다.
- 층마다 계산 시간과 데이터 크기를 미리 모델링한다.
- 네트워크 상태와 부하를 보고 어느 층에서 끊어 단말과 서버로 나눌지 자동으로 정한다.
주요 결과
- 지연 평균 3.1배 단축, 최대 40.7배.
- 단말 에너지 평균 59.5% 절감, 최대 94.7%.
- 데이터센터 처리량 평균 1.5배 향상.
한계
- 2017년 모델 기준이라 트랜스포머 계열은 다루지 않는다.
- 층 단위로 깔끔히 쪼개지는 구조를 전제한다.
- 네트워크 대역폭 예측이 틀리면 분할점 선택이 나빠진다.
우리 기능과의 관계
- 설비 데이터 수집 단에서 현장 장비와 서버 사이에 AI 연산을 어디까지 내릴지 정하는 문제와 구조가 대응한다.
- T13-2유사문제
Live Video Analytics at Scale with Approximation and Delay-Tolerance
VideoStorm
한국어 검토 보기
해결 문제
- 카메라 수천 대에서 들어오는 영상 질의를 한 클러스터에서 다 돌려야 한다.
- 질의마다 정확도 요구와 지연 허용치가 다른데, 자원을 똑같이 나눠 주면 둘 다 못 맞춘다.
핵심 구조
- 질의별로 설정값을 바꿔가며 자원과 품질의 관계를 미리 잰다(자원 품질 프로파일).
- 이 프로파일을 온라인 스케줄러에 넘긴다.
- 공평 분배 대신 품질과 지연 두 목표를 같이 최대화하도록 자원을 배분한다.
주요 결과
- Azure 101대 클러스터에 올려 실제 교통 카메라 영상을 처리했다.
- 실제 질의 품질을 최대 80% 개선했다.
- 지연(lag)은 7배 좋아졌다.
한계
- 사전 프로파일링이 필요하다. 질의가 새로 생기면 다시 재야 한다.
- 정확도 측정 기준을 만들려면 비교용 정답 데이터가 있어야 한다.
우리 기능과의 관계
- 영상 안전 판단을 여러 라인에서 동시에 돌릴 때 정확도와 자원을 한 저울에 놓고 배분하는 문제와 같은 문제다.
- 이 주제의 출발점 논문이다. 아래 AWStream, Chameleon, Reducto가 이 문제를 이어받는다.
- T13-3유사문제
AWStream: Adaptive Wide-Area Streaming Analytics
AWStream
한국어 검토 보기
해결 문제
- 공장이나 원격지에서 중앙으로 보내는 회선은 대역폭이 좁고 들쭉날쭉하다.
- 그냥 TCP로 보내면 지연이 쌓이고, UDP로 보내면 정확도가 떨어진다.
핵심 구조
- 해상도, 프레임 수, 품질 같은 조절 손잡이를 미리 프로파일링한다.
- 정확도와 대역폭의 맞바꿈 곡선을 만든다.
- 실행 중 대역폭 변화를 감지해 곡선 위에서 설정을 바꾼다.
주요 결과
- 같은 대역폭에서 정확도를 유지하면서 지연을 크게 줄였다.
- 비적응 방식 대비 지연과 정확도 양쪽에서 유리한 지점을 확보했다.
한계
- 사전 프로파일링 비용이 든다.
- 데이터 분포가 프로파일링 때와 달라지면 곡선이 어긋난다.
우리 기능과의 관계
- 영상 안전 판단과 설비 데이터를 현장에서 서버로 올릴 때 회선이 좁아도 정확도를 지키는 문제와 같은 문제다.
- T13-4유사문제
Chameleon: Scalable Adaptation of Video Analytics
Chameleon
한국어 검토 보기
해결 문제
- 영상 추론 설정값(해상도, 프레임 수, 모델 크기)의 최적값이 시간마다 바뀐다.
- 그렇다고 자주 다시 찾으면 탐색 비용이 절약분을 다 까먹는다.
핵심 구조
- 최적 설정을 좌우하는 요인(물체 속도, 크기 등)이 시간과 공간으로 이어져 있다는 점을 쓴다.
- 그래서 탐색 비용을 시간에 걸쳐, 그리고 여러 카메라에 걸쳐 나눠 부담시킨다.
- 그 위에서 설정값을 계속 바꿔가며 맞춘다.
주요 결과
- 교통 카메라 5대 영상으로 실험했다.
- 오프라인에서 고른 고정 최적 설정 대비, 같은 자원으로 정확도를 20~50% 높였다.
- 또는 같은 정확도를 자원 30~50%만으로 냈다(2~3배 속도 향상).
한계
- 장면 사이 상관성이 약하면 탐색 비용 분담 효과가 줄어든다.
- 설정 후보 공간을 미리 정해 둬야 한다.
우리 기능과의 관계
- 라인마다 조명과 속도가 다른 현장에서 영상 추론 설정을 계속 다시 맞추는 문제와 같은 문제다.
- AWStream, Reducto와 한 묶음으로 읽어야 한다.
- T13-5유사문제
Reducto: On-Camera Filtering for Resource-Efficient Real-Time Video Analytics
Reducto
한국어 검토 보기
해결 문제
- 영상 질의는 대부분의 프레임이 쓸모없는데도 전부 서버로 보내면 낭비가 크다.
- 실시간 응답을 지키려면 앞단에서 걸러야 한다.
핵심 구조
- 카메라에서 값싼 저수준 특징(픽셀 차이, 엣지 변화 등)만 계산한다.
- 질의 종류와 목표 정확도에 맞춰 필터 임계값을 동적으로 정한다.
- 변화가 없는 프레임은 아예 보내지 않는다.
주요 결과
- 목표 정확도를 지키면서 전송 프레임 수와 서버 연산을 크게 줄였다.
- 실시간 질의 응답 지연이 기존 방식보다 짧아졌다.
한계
- 값싼 특징으로 판별이 어려운 질의는 필터 효과가 떨어진다.
- 임계값 튜닝이 장면과 질의에 민감하다.
우리 기능과의 관계
- 영상 안전 판단에서 카메라 단에서 무의미한 프레임을 걸러 서버 비용을 줄이는 구조에 대응한다.
- T13-6구조대응
Ekya: Continuous Learning of Video Analytics Models on Edge Compute Servers
Ekya
한국어 검토 보기
해결 문제
- 엣지 서버에 올린 경량 모델은 현장 데이터가 바뀌면 정확도가 떨어진다(데이터 드리프트).
- 다시 학습하려면 GPU가 필요한데, 같은 GPU로 추론도 돌려야 한다.
핵심 구조
- 추론 작업과 재학습 작업이 GPU를 나눠 쓰도록 함께 스케줄링한다.
- 마이크로 프로파일러로 재학습 효과가 큰 모델을 먼저 고른다.
- 재학습 설정(에폭 수, 층 동결 범위)까지 같이 정한다.
주요 결과
- 기준 스케줄러 대비 정확도 이득이 29% 더 크다.
- 같은 정확도를 내려면 기준 방식은 GPU가 4배 더 필요했다.
- 수치 주의: arXiv 초록 원문은 "accuracy gain compared to a baseline scheduler is 29% higher"다. 백분율(%)이지 백분율포인트(%p)가 아니다. %p로 옮겨 적으면 안 된다.
한계
- 라벨을 만들어 줄 큰 모델(골든 모델)이 필요하다.
- 프로파일링 자체가 자원을 쓴다.
검토 메모
- 저자 순서 주의: 학회본과 arXiv판의 저자 순서가 다르다. 학회본은 Junchen Jiang 다음이 Yuanchao Shu, 그다음 Nikolaos Karianakis다. arXiv판은 Karianakis가 Shu보다 앞이고, Paramvir Bahl이 Victor Bahl로 적혀 있다. 학회본을 발표지로 적을 때는 학회본 순서를 따른다.
우리 기능과의 관계
- 제조 AI 분석 모델을 현장에 두고 운영하면서 재학습과 추론을 같은 자원으로 돌려야 하는 상황과 구조가 대응한다.
- 한 GPU 위에서 성격이 다른 작업을 같이 돌리는 문제는 아래 14번 AntMan이 시스템 쪽에서 다룬다. 같이 읽어야 한다.
- T13-7구조대응
Clipper: A Low-Latency Online Prediction Serving System
Clipper
한국어 검토 보기
해결 문제
- 학습 프레임워크는 많은데, 학습한 모델을 실제 서비스로 내놓는 부분은 비어 있었다.
- 프레임워크마다 배포 방식이 달라 응용 프로그램이 직접 감당해야 했다.
핵심 구조
- 응용과 학습 프레임워크 사이에 중간 계층을 하나 둔다.
- 캐싱, 배칭(여러 요청 묶어 처리), 적응형 모델 선택을 이 계층에서 처리한다.
- 아래 학습 프레임워크는 손대지 않는다.
주요 결과
- 대표 데이터셋 4개로 지연, 정확도, 처리량 요구를 만족함을 보였다.
- TensorFlow Serving과 처리량, 지연이 비슷한 수준이었다.
- 대신 모델 조합과 온라인 학습이 가능해 정확도와 견고함이 올라갔다.
한계
- 2017년 시점이라 GPU 여러 장 공유나 생성형 모델은 다루지 않는다.
- 중간 계층을 하나 더 두는 만큼 구조가 복잡해진다.
우리 기능과의 관계
- 추론 서빙 시스템 계보의 출발점이다. 아래 Clockwork, INFaaS가 이 문제를 이어받는다.
- AI 기준정보 생성과 제조 AI 분석을 서비스 형태로 내놓을 때의 기본 구조에 대응한다.
- T13-8구조대응
Serving DNNs like Clockwork: Performance Predictability from the Bottom Up
Clockwork
한국어 검토 보기
해결 문제
- 추론 서비스는 평균 지연이 아니라 꼬리 지연(가장 느린 몇 건)이 문제다.
- 시스템 아래층의 예측 불가능성이 위층으로 번진다.
핵심 구조
- DNN 추론 자체는 실행 시간이 거의 일정하다는 점을 이용한다.
- 아래층에서 선택지를 없애고 결정권을 중앙 스케줄러 한 곳에 모은다.
- 중앙에서 요청마다 실행 시점을 직접 정한다.
주요 결과
- GPU 한 장에 수천 개 모델을 올린 상태에서도 목표 지연을 지켰다.
- 100ms 목표를 99.9999% 요청에서 만족했다고 보고한다.
- 과부하와 급증 부하에서도 유효 처리량이 이상치에 가깝게 유지됐다.
한계
- 실행 시간이 일정한 모델을 전제한다. 입력 길이에 따라 시간이 변하는 생성형 모델에는 그대로 적용하기 어렵다.
- 중앙 스케줄러가 병목이자 단일 장애점이 될 수 있다.
우리 기능과의 관계
- AI 기준정보 생성과 제조 AI 분석을 서비스로 제공할 때 응답 시간 약속을 지키는 구조에 대응한다.
- 여기서 남긴 생성형 모델 문제는 아래 10번 Orca와 11번 vLLM이 이어받는다.
- 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 배분을 정하는 향후 적용 후보다.
- T13-17구조대응
MLPerf Inference Benchmark
한국어 검토 보기
해결 문제
- 추론 성능을 재는 방식이 회사마다 달라 숫자를 비교할 수 없었다.
- 하드웨어 구조가 크게 다른 시스템끼리 공정하게 겨루게 하려면 공통 규칙이 필요하다.
핵심 구조
- 30개 넘는 기관, 200명 넘는 실무자가 같이 만든 산업계 공통 벤치마크다.
- 비교 가능성을 지키기 위한 규칙과 권장 관행을 정한다.
- 부하 형태를 여러 시나리오로 나눠 잰다.
주요 결과
- 첫 제출 라운드에서 14개 기관, 30개 넘는 시스템으로부터 재현 가능한 측정치 600건 이상을 모았다.
- 서로 다른 하드웨어와 소프트웨어에서 같은 규칙으로 잴 수 있음을 보였다.
한계
- 벤치마크 규칙이라 특정 시스템의 설계 지침을 주지는 않는다.
- 실제 현장 데이터 분포와 벤치마크 데이터셋은 다르다.
우리 기능과의 관계
- 엣지 추론 성능 숫자를 말하려면 어떤 기준으로 쟀는지 밝혀야 한다. 그 기준선이 이것이다.
- 초저전력 기기 쪽은 아래 부록의 MLPerf Tiny를 같이 본다.
- T13-18유사문제
MillWheel: Fault-Tolerant Stream Processing at Internet Scale
MillWheel
한국어 검토 보기
해결 문제
- 끊임없이 들어오는 데이터를 지연 짧게 처리해야 한다.
- 그런데 장비는 고장 나고 데이터는 늦게 도착한다.
- 개발자가 상태 저장과 장애 복구를 매번 직접 짜면 감당이 안 된다.
핵심 구조
- 계산을 방향 그래프로 표현한다. 사용자는 노드마다 처리 코드만 쓴다.
- 상태 저장과 레코드 전달, 장애 복구는 프레임워크가 맡는다.
- 레코드마다 한 번만 처리되도록 보장한다.
- 워터마크(low watermark)로 어느 시각까지의 데이터가 다 들어왔는지 판단한다.
주요 결과
- 구글 사내에서 널리 쓰였다. 연속 이상 탐지기 사례로 쓰임새를 보였다.
- 워터마크 개념을 스트리밍 처리 시스템에 도입했다.
한계
- 2013년 사내 시스템 논문이다. 공개 구현체가 아니다.
- 이벤트 시각 기준 구간 처리와 결과 내보내는 시점의 의미론이 아직 정리되기 전이다. 그 정리는 아래 19번이 한다.
우리 기능과의 관계
- 아래 19번 Dataflow Model의 직계 선행 연구다. 워터마크 개념이 여기서 나왔다.
- 설비 데이터 수집에서 신호가 늦게 오거나 장비가 죽어도 집계를 빠뜨리지 않는 문제와 같은 문제다.
- T13-19유사문제
The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing
Dataflow Model
한국어 검토 보기
해결 문제
- 끝이 없는 데이터 흐름을 유한한 배치로 억지로 나누면 정확도가 깨진다.
- 데이터가 순서 없이 늦게 도착하는 상황을 다뤄야 한다.
핵심 구조
- 계산 내용, 이벤트 시각 기준 구간, 결과를 내보내는 시점, 늦게 온 데이터의 처리 방식을 네 축으로 분리한다.
- 워터마크로 늦은 데이터의 도착 여부를 판단한다.
- 트리거로 중간 결과를 먼저 내보내고 나중에 수정한다.
주요 결과
- 정확도, 지연, 비용을 상황별로 조절 가능한 하나의 모델로 통합했다.
- Apache Beam과 Flink 등 이후 스트리밍 엔진 설계의 기준이 됐다.
한계
- 모델과 의미론 제시가 중심이다. 성능 벤치마크 비교는 제한적이다.
- 워터마크를 잘못 잡으면 늦은 데이터를 놓치거나 지연이 늘어난다.
우리 기능과의 관계
- 설비 데이터 수집에서 신호가 늦게 오거나 순서가 뒤바뀌어도 집계 결과를 맞게 내는 문제와 같은 문제다.
- 위 18번 MillWheel과 이어서 읽어야 한다.
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기