Full Stack Deep Learning Bootcamp 정리

in MLOps on Basic


부트캠프 후기

  • 오프라인에서 참석한 것은 아니지만, 강의를 듣고 후기를 남김
  • 일단 강의가 매우 고퀄!!!!!!(감동)
  • 국내에선 이런 내공을 담은 강의를 거의 보지 못했음
  • 프로젝트를 어떻게 해야되는가, 프로젝트 우선순위를 선정하는 부분도 알려줘서 매우 좋았음. 실제 현업에서도 매번 고민하는 이슈들(Lecture 2)
  • 데이터를 어떻게 다룰까에 대해 말해주는 점이 좋았음. 단순 로컬/클라우드만 하는게 아니라 Database도 말해줌(lecture 6)
  • 팀 구성이 어떻게 되는지, 직군이 무엇이 있는지 알려준 점이 좋았음(lecture 7)
  • 딥러닝 트러블 슈팅에 대해 알려줘서 좋았음. 언더피팅, 오버피팅일 때의 전략을 제공함(lecture 10)
  • 모델의 성능 개선할 때 결과를 어떻게 봐야하는지에 대한 직관을 얻게 해줌(lecture 10)
  • 이 부트캠프는 단순히 강의만 듣는게 끝이 아니고, 꼭 Lab(실습)을 해야함!! 코드를 보면 현업에서 사용할 소재들이 꽤 많음(Lambda 배포라던가) => Github 참고
  • 앞으로 어떤 분야를 연구할 것인가에 대해 흥미로운 주제를 던져주는 부분도 좋았음(lecture 13)
  • 단, Serving하는 부분에 대해 엄청 깊게 알려주는건 아니고, 부트캠프답게 큰 그림을 그려주고 실습을 같이 하며 하나를 구현해봄 => 이 부분은 결국 키워드를 캐치해서 스스로 해보는게 좋을듯..!

어떤 사람에게 이 강의가 좋을까요?

  • 어느정도 머신러닝/딥러닝 공부를 한 후, 실제 서비스 구현에 흥미있는 분
  • 개발 베이스에서 머신러닝/딥러닝 공부를 하셨던 분
  • 프로젝트를 어떻게 하면 좋을지 고민되는 분
  • 딥러닝 프로젝트 트러블슈팅에 대해 고민되는 분
  • Production 과정 전반에 대해 관심있는 분

Bootcamp의 목적

  • 개발자가 딥러닝에 친숙해지기 위한 Hands-on 프로그램
  • 모델 학습은 딥러닝 Production의 일부분이고, 이 코스에선 Production화하기 위한 모든 것들을 가르칠 예정
    • Problem을 명확히하고 프로젝트의 cost를 측정
    • Data를 찾고, 전처리하고, 라벨링
    • 적절한 Framework와 Infra를 선정
    • 학습의 reproducibility 관련 트러블슈팅
    • 대규모 모델 Deploy
  • 컴퓨터 비전과 자연어 처리 시스템을 프러덕션 환경에 배포하는 프로젝트를 진행
    • 선택적 필기 시험으로 지식을 테스트

  • 프로젝트

Lecture 1 : Introduction

  • 발표 자료
  • Organizer
    • Pieter Abbeel : 버클리 교수님, Covariant.AI Scientist
    • Sergey Karayev : STEM AI Head
    • Josh Tobin : Research Scientist at OpenAI
  • Object Detection in Computer Vision
    • 2012년까지의 대세
      • Image => Hand-engineered features(SIFT, HOG, DAISY) => SVM => 분류
    • 딥러닝 이후
      • Image => 8 레이어 뉴럴넷 => 분류
  • 딥러닝이 발전한 예시를 보여줌(다양한 업계)
  • Google, OpenAI, Facebook, Uber 등 다양한 딥러닝 엔지니어와 리더들과 이야기해서 컨텐츠를 만듬

Lecture 2 : Machine Learning Projects

  • 목표
    • 머신러닝 프로젝트를 이해하기 위한 프레임워크 도입
    • 머신러닝 프로젝트 Best Practices
  • 머신러닝 프로젝트 Lifecycle
    • 1) Planning & Project setup
      • 어떤 프로젝트를 하기로 했는지
      • 요구사항, 목표 설정
      • 리소스 할당 등
    • 2) Data Collection & Labeling
      • 데이터 수집
      • 센서 설치
      • annotation 노가다 등
      • 그러나 데이터를 얻기 너무 어려움
    • 3) Training & debugging
      • OpenCV로 베이스라인 구현
      • SoTA 모델 찾고 구현
      • 구현체 디버깅
      • Task에 맞도록 모델 개선
      • 잘 안되면
        • 데이터를 더 수집
        • labeling이 신뢰할 수 없음을 깨달음
        • Task가 어려운 것을 깨닫고 각각의 trade off를 비교해 어떤 것이 제일 중요한가 고민
    • 4) Deploying & testing
      • 프로토타입
      • 테스트하고 프러덕션화
      • 그러나 프러덕션에서 작동 안될 수 있음
        • training data와 deployment의 데이터의 mismatching을 고치고
        • 데이터를 더 수집
    • Metric & Performance
      • 선택한 Metric이 사용자 행동을 유지하지 않음 => 다시 고민
      • 프러덕션시 Performance가 좋지 않음(더 빠르거나 정확해야 할까?
    • 더 알아야 하는 것
      • 도메인에서 SOTA가 뭔지 확인
        • 가능하면 이해하고
        • 다음에 무엇을 시도할지 알아야 함
  • 강의의 나머지 개요
    • 프로젝트 우선 순위 지정 및 목표 선택
    • 모델을 평가할 지표 선택
    • 비교의 기준이 될 베이스라인 선택
  • 프로젝트 우선 순위를 정하는 방법
    • 1) 영향력이 큰 ML 문제
      • 파이프라인의 복잡한 부분이 있는가
      • 간단한 예측이 가치가 있는가
      • Feasibility(실행 가능성)
        • 데이터 사용 유무, 정확도 요구사항, 문제의 어려움이 모여 Cost를 만듬
    • 2) ML 프로젝트의 Cost는 데이터의 가용성에 의해 결정되지만 정확성 요구도 큰 역할을 함(예 : 95%의 정확도는 가져야 해!)
      • Accuracy requirements가 중요한 이유
        • 높은 성능까지 가려면 cost가 지수함수처럼 증가함
        • 제품 설계로 이런 Accuracy 요구를 줄일 수 있음(=목적이나 활용 방법에 따라 다르게 할 수 있다는 뜻)
    • 정리
      • 1) 영향력이 큰 ML 문제를 찾으려면, 파이프라인의 복잡한 부분과 cheap prediction이 가치있는 곳을 찾아보기
      • 2) ML 프로젝트이 cost는 데이터의 가용성 + 정확도 요구사항에 의해 결정됨
  • 지표 선택의 핵심
    • 1) 현실 세계는 지저분하고, 일반적으로 많은 측정 항목에 관심있음
    • 2) 그러나 머신러닝 시스템은 단일 숫자를 최적화할 때 가장 잘 작동함
    • 3) 결과적으로 metric 결합해서 공식을 만들어야 함
    • 4) 공식은 변경될 수 있음
    • 어떤 Metric이 좋은가?
    • Metric Combine
      • Simple average, weighted average
      • threshold n-1 metric, n번째 평가 등
      • 복잡하고 도메인 특화된 공식
        • Average precision(AP) = curve의 아래 지역
        • mAP = mean AP
    • Pose estimation Metric 고르는 예시
      • Evaluate current performance
        • Train a few models
        • 현재 모델로 어떤 문제가 있는지 파악할 수 있음
  • 베이스라인 선택의 핵심
    • 1) 베이스라인은 모델 성능에 대한 하한선을 제공(최소한 이거 이상은 해야한다)
    • 2) 하한선이 엄격할수록 더 유용함(출판된 내용, 사람보다 좋다는 기준 등)
    • 베이스라인이 중요한 이유
      • 같은 모델이 다른 베이스라인을 가지면 다음 행동이 달라짐
    • 베이스라인을 찾을 수 있는 곳
      • Scripted baseline의 예시 : OpenCV 스크립트, Rule based 방법 등
      • Simple ML baseline의 예시 : 일반적인 feature based model(bag-of-words classifier), linear classifier, Basic neural network model(vgg without batch norm, weight norm) 등
    • 사람 관련 베이스라인을 어떻게 만들 수 있을까
  • 질문
    • 머신러닝 모델이 잘못되었다는 것을 어떻게 방지할 수 있을까?
      • 좋은 질문. 모델의 confidence를 사용
      • 그러나 머신러닝에서 여전히 어려운 문제. 모델은 자주 잘못되었는지 모름
      • 매우 적대적인 사례를 넣어서 어떻게 나오는지 보는 방법도 있고, 고민이 필요

Lecture 3 : Intro to the Text Reecognizer Project

  • 발표 자료
  • 프로젝트 Architecture
    • POST request => 이미지 Decode => Line Detector => Line Text Recognizer => Encode Response의 흐름
    • LineDetector와 LineTextRecognizer가 필요
  • 실습 개요
    • Lab 1: Codebase walkthrough
    • Lab 2: Single-character prediction. Before predicting full lines, try a simpler problem
    • Lab 3: LineTextRecognizer. Build a synthetic dataset. LSTM + CTC loss model
    • Lab 4: Tools for experimentation. Weights & Biases, parallel experiment running
    • Lab 5. Experimentation. Try some things and run some things overnight
    • Lab 6. LineDetector. Train the line detection model
    • Lab 7. Data. Managing data, including label and versioning
    • Lab 8. Continuous integration. Testing your model
    • Lab 9. Deployment. Put the model into production
  • Project Structure
    • Web backend : Serving predictions, provisioning
      api/                        # Code for serving predictions as a REST API.
      tests/test_app.py           # Test that predictions are working
      Dockerfile                  # Specificies Docker image that runs the web server.
      __init__.py
      app.py                      # Flask web server that serves predictions.
      serverless.yml              # Specifies AWS Lambda deployment of the REST API.
    • Data
      data/                            # Training data lives here
  	raw/
     	 emnist/metadata.toml     # Specifications for downloading data
    • Experimentation : 평가나 여러 노트북 파일
      evaluation/                     # Scripts for evaluating model on eval set.
      evaluate_character_predictor.py

  notebooks/                  # For snapshots of initial exploration, before solidfying code as proper Python files.
      01-look-at-emnist.ipynb
    • Convenience scripts
      tasks/
      # Deployment
      build_api_docker.sh
      deploy_api_to_lambda.sh

      # Code quality
      lint.sh

      # Tests
      run_prediction_tests.sh
      run_validation_tests.sh
      test_api.sh

      # Training
      train_character_predictor.sh
    • Main model and training code
      text_recognizer/                # Package that can be deployed as a self-contained prediction system
      __init__.py

      character_predictor.py      # Takes a raw image and obtains a prediction
      line_predictor.py

      datasets/                   # Code for loading datasets
          __init__.py
          dataset.py              # Base class for datasets - logic for downloading data
          emnist_dataset.py
          emnist_essentials.json
          dataset_sequence.py

      models/                     # Code for instantiating models, including data preprocessing and loss functions
          __init__.py
          base.py                 # Base class for models
          character_model.py

      networks/                   # Code for building neural networks (i.e., 'dumb' input->output mappings) used by models
          __init__.py
          mlp.py

      tests/
          support/                        # Raw data used by tests
          test_character_predictor.py     # Test model on a few key examples

      weights/                            # Weights for production model
          CharacterModel_EmnistDataset_mlp_weights.h5

      util.py

  training/                       # Code for running training experiments and selecting the best model.
      gpu_util_sampler.py
      run_experiment.py           # Parse experiment config and launch training.
      util.py                     # Logic for training a model with a given config
  • LineTextRecognizer Model architecture

Lecture 4 : Infrastructure and Tooling

  • 발표 자료
  • 이상과 현실
  • Hidden Technical Debt in Machine Learning Systems 이야기함
    • 논문 리뷰 링크 참고
  • 다양한 도구들
  • Deep Learning Frameworks
    • Tensorflow가 Production에 사용하기 편함
    • 특별한 이유가 없으면 Tensorflw/Keras or PyTorch 사용
    • 둘 다 동일한 포인트로 수렴
      • define by run으로 쉽게 개발
      • execution graph를 다양한 플랫폼에서 최적화
    • 일화로, 사람들이 파이토치로 바꿀때 행복해함
  • Development, Training/Evaluation
    • 하드웨어
    • GPU Basics
      • NVIDIA가 유일한 선택이였던 시절이 있음
        • Google TPU가 현재 제일 빠름
        • Intel, AMD가 곧 시작될 예정
      • NVIDIA가 매년 새로운 아키텍쳐를 공개함
    • Cloud Providers
      • AWS, GCP, Azure의 3파전
      • AWS가 제일 비쌈
        • Spot 요금을 사용하면 많이 할인되지만 갑자기 꺼질 수 있음
        • 하이퍼 파라미터 서치 실험엔 적합하지만, 실패를 처리하려면 인프라가 필요
      • GCP는 TPU도 사용할 수 있음
        • GCP도 Spot이 있음, 거의 AWS보다 저렴함
      • Azure
        • AWS와 꽤 비슷
        • Spot 없음
    • On-prem Options
      • 4개까진 꽤 쉬움
      • 사전 구축된 것을 구매
        • Lambda Labs, NVIDIA, Supermicro, Cirrascale etc
    • Cost Analysis도 했음
    • 다른 고려 사항
      • Data location
        • 클라우드에 데이터가 1TB 이상 있따면 compute하기 수월
      • Data privacy
        • 데이터를 클라우드에 올릴 수 없다면 on-prem
      • Security
    • 추천
  • Resource Management
    • 많은 사람들이 여러 GPU를 사용하고, 격리된 환경을 가져야 함
    • 바라는 것
      • 실험하기 쉽고, 적절한 의존성과 리소스 할당
    • Solutions
      • 스프레드시트
      • 파이썬 스크립트
      • SLURM
      • Docker + Kubernetes
      • Software specialized for ML use cases
  • Distributed Training
    • 모델을 학습할 때 여러 GPU를 사용해야할 경우가 있음
    • 단순히 병렬로 실행하는 것은 덜 유용했으나, 데이터가 커지며 프레임워크의 병렬화가 좋아지고 있음
    • Data vs Model Parallelism
      • Iteration time이 너무 길어지면, 데이터를 parallel하게 학습해야 함
      • 모델 병렬처리는 복잡성을 증가시키며 거의 가치가 없음
    • Tensorflow Distributed
      • 코드를 크게 재구성해야 함
      • 점점 좋아지고 있음
    • Horovod
      • Tensorflow, Keras, PyTorch 지원
      • MPI를 사용해 Tensorflow Distributed보다 덜 복잡함
  • Experiment Management
    • 실험할 때 코드, 매개변수, 데이터셋을 추적하기 어려움
    • 여러 실험을 하면 더 어려움
    • 모델을 자동으로 저장하는 것도 좋음
    • Tensorboard
      • 단일 실험에서 좋은 솔루션
      • 다양한 실험을 커버하진 못함
    • Losswise, Comet.ml 등
    • Weights & Biases : 실습때 활용할 예정, Document
    • Sacred도 좋아요
  • Hyperparameter Optimization
    • 하이퍼파라미터 서치할 때 유용
    • 간단하게 정의해서 사용할 수 있음
    • keras와 잘 맞는 것들
    • talos
    • Hyperas
    • Hyperopt
      • 머신러닝의 일반적 패키지와 다 맞음
      • Non-bayesian 알고리즘
    • SIGOPT : Hyperparameter 서비스 제공
    • Weights & Biases도 제공
    • Microsoft의 nni도 좋음
  • All-in-one Solutions
    • 최근 트렌드 : 하나의 시스템에 모두 넣음
    • 개발(hosted notebook)
    • AutoML을 사용해 실험을 여러 컴퓨터로 스케일링
    • 버전 관리 및 결과 review
    • 모델 배포
    • 성능 모니터링
    • FBLearner Flow
    • Michelangelo
    • Cloud ML Engine(AI Platform)
      • AI Platform의 일부가 됨
    • TFX
    • Kubeflow
    • Amazon SageMaker
    • Neptune
    • FLOYD
    • Paperspace

Lecture 5: Tooling and Experimentation Labs

  • 코드로 실습함
  • Weights & Biases

Lecture 6 : Data Management

  • 발표 자료
  • Introduction
    • 대부분 딥러닝은 레이블된 많은 데이터가 필요함
      • 스스로 플레이하는 RL이나 GAns은 제외하고 => 아직 실용적이지 않음
    • 공공 데이터셋은 경쟁 우위를 가질 수 없음
      • 그러나 스타트 포인트로는 괜찮음
  • Roadmap
    • 1) Data Labeling
    • 2) Data Storage
      • Data(images, sound) and metadata(labels, user activity)
    • 3) Data versioning
      • 데이터셋은 사용자 활동, 추가 레이블을 통해 업데이트되며 모델에 영향을 미침
    • 4) Data workflow
      • 원본 데이터와 메타 데이터를 학습 가능한 데이터로 집계 및 변환
  • Data Labeling
    • User Interfaces
      • HIVE 사이트를 통해 bounding box, segmentation, keypoints, cuboids 등을 뽑음
      • Annotator는 매우 중요하고, 퀄리티 보장이 되야함
    • Sources of labor
      • 사람을 고용함, 퀄리티 품질을 관리할 수 있음
        • 그러나 비싸고 스케일업이 느림
      • 크라우드 소싱
    • Service companies
      • 기간 선정
      • 좋은 사례(Godl standard)를 직접 라벨링
      • 여러 경쟁 업체와 샘플 요청
    • Software
      • 풀 서비스 데이터 라벨링은 비쌈
      • 일부 회사는 소프트웨어 제공, 오픈소스도 있음(Prodigy)
  • Data Storage
    • Filesystem
      • Storage의 기초 layer
      • 기본 단위는 텍스트나 binary가 가능한 “file”이고 버전이 지정되지 않고 쉽게 덮어씀
      • 네트워크로 연결 가능(ex: NFS) : 여러 머신이 네트워크를 통해 액세스
      • 분산 가능(ex: HDFS) : 여러 곳에 저장하고 액세스 가능
      • Access 패턴이 주의! 빠르지만 병렬을 아님
    • Objest Storage
      • S3, Google Storage
      • API로 파일에 접근 가능, 직접 데이터 저장하지 않아도 됨
      • 기본 단위는 “object”, 보통 binary, image, sound
      • versioning이나 redundancy가 서비스에서 가능함
      • parallel이 가능하지만 빠르지 않음
    • Database
      • 구조적인 데이터에 지속적이고, 빠르고, 확장 가능함
      • 실제로 모든 것이 RAM에 있지만, software가 디스크에 모든 것을 기록하고 유실되지 않도록 함
      • 기본 단위는 “row”, unique id, rows, columns
      • binary 데이터가 아님
      • Postgres가 거의 90% 이상 좋을 수 있음, 비정형 JSON도 지원
    • Data Lake
      • 다양한 소스에서 데이터를 가공해 저장
      • Redshift, BigQuery 등
    • 정리하면
  • Data versioning
    • DVC
      • Data versioning에 특화된 솔루션
  • Data workflows
    • Train시 아래와 같은 데이터를 가져와야 함
      • metadata : posting time, title, location
      • log
    • 그리고 classifiers를 돌려서 결과 도출
    • Task Dependencies
      • A가 끝나고 B 작업을 해야하고, B 작업 이후에 C, D, E를 하고 C, D, E가 완료되면 F 진행하는 이런 의존 관계가 있음
    • Makefiles
      • Makefile에서 파이프라인 연산 가능
    • Luigi and Airflow
    • Distributing work

Lecture 7 : ML Teams

  • 발표 자료
  • Job Role
    • ML DevOps
      • 주로 소프트웨어 개발자 Role이고, SWE 파이프라인을 구축
    • Data Engineer
      • ML Team과 적극적으로 SWE
    • ML Engineer(머신러닝 엔지니어)
      • ML 기술 + SWE 기술의 Mix
      • 보통 SWE로 일하시던 분들이나 공부하고 발전
    • ML Researcher
      • ML 전문가
  • ML team structures
    • 대부분 팀은 SWE + ML 스킬이 혼합됨
    • 팀의 모든 사람들이 어느정도 SWE 기술을 가져야 함
    • ML Researcher의 다른 견해
      • SWE와 통합하기 어려움
      • 빠르게 움직이기 위해 알아야 한다
    • Data Engineer의 다른 견해
      • 일부 조직은 ML팀과 같이함
      • 별도의 팀이어야 함
  • Managing ML Teams
    • Task가 쉬울지 어려울지 미리 말하는건 매우 어려움
    • ML progress는 nonlinear
      • 무엇이 효과있을지 불명확해 계획이 어렵긴 함
      • 프로젝트 타임라인 추정이 매우 어려움
      • Production ML은 research와 engineering 사이에 있음
    • research와 engineering의 문화 gap이 존재
  • 면접 질문의 큰 틀
    • Why does the Residual Block in the ResNet architecture help with the vanishing gradient problem?

Lecture 10 : Troubleshooting

  • 발표 자료
  • 딥러닝에서 디버깅은 매우 어렵지만, 중요한 주제
  • 왜 어려울까? 당신의 퍼포먼스가 좋지 않은 이유
    • 흔한 Dataset 구조 이슈
      • 충분하지 않은 데이터
      • Class imbalances
      • Noisy labels
      • Train / Test 데이터셋의 분포가 다름
  • Key mindset for DL troubleshooting
    • Pessimism(비관적으로 보자)
  • 트러블슈팅 전략
  • Start simple
    • 1) 간단한 아키텍쳐 선택
    • 2) 일반적으로 좋은 default 사용
    • 3) Input 정규화
    • 4) 문제를 간단히하기
  • Implement & debug
    • 자주 발생하는 실수
      • Tensor의 shape가 안맞는 경우
      • 전처리 실수(정규화를 잊거나 너무 많이하거나)
      • loss function의 부정확함
      • train/eval 모드 설정을 까먹음
      • 수치적 불안정 : inf, NaN
    • 모델 구현을 위한 일반적인 조언
      • 가벼운 구현
        • v1은 가능하면 간소하게
        • 200줄 미만
      • 이미 구현된 component 사용
        • tf.nn.relu(tf/matmul(W, x)) 대신 tf.layers.dense!
        • tf.losses.cross_entropy
      • 복잡한 데이터 파이프라인은 나중에! 일반 메모리에 올려서 진행
    • 1) 모델 Run
      • Debuggers for DL code
        • Pytorch : 쉬움, ipdb 사용
        • tensorflow : trick(허나 2.0이 나왔으니 이 방법은 안해도?)
          • graph session 만들고, training loop 갖고, tfdb 사용
      • Shape mismatch
        • 와 대박 꿀팁
      • Casting issue
      • OOM
        • Tensor가 너무 크거나, 데이터가 많거나, operation에 중복이 있거나 등
      • Other common errors
    • 2) single batch에 오버피팅
    • 3) 알고있던 결과와 비교
  • Evaluate
    • Test error = irreducible error + bias + variance + val overfitting
      • 이건 train, val, test가 모두 같은 분포를 가진다는 가정을 가짐. 진짜 그럴까?
      • 2개의 Validation 구성해보기
        • 하나는 Train에서 샘플링, 하나는 Test에서 샘플링
    • 결과 분석
    • 정리하면, Test error = irreducible error + bias + variance + distribution shift + val overfitting
  • Improve model/data
    • 1) 언더피팅인 경우
      • ConvNet, ResNet, 파라미터 튜닝 등을 함
    • 2) 오버피팅인 경우
      • H ~ J는 추천하지 않음
      • 데이터 추가하고, weight decay 추가, data augmentation도 했음
    • 3) 분포 이동
      • Error analysis
      • Domain adaptation
        • 레이블이 없는 데이터 또는 제한된 레이블이 있는 데이터가 있는 상황에서 source 분포를 학습해 또다른 target 데이터를 일반화하는 기술
        • 레이블된 test 데이터가 적을 경우, 유사 데이터가 존재할 경우 유용
    • 4) Re-balance datasets
      • test set보다 val이 더 좋아보이면, 오버피팅일 수 있음
      • 보통 작은 val set 또는 많은 하이퍼 파라미터 튜닝에서 발생함
      • 그렇다면, val data를 다시 수집해야 함
  • Tune hyper-parameters
    • 어떤 파라미터가 민감한지 작성해보고 조정
    • Method 1: manual 하이퍼파라미터 최적화
    • Method 2: grid search
    • Method 3: random search
    • Method 4: coarse-to-fine
    • Method 5: Bayesian hyperparam opt

Lecture 12 : Testing and Deployment

  • 발표 자료
  • ML Test Score
  • Testing / CI
    • Unit / Integration Tests
      • 각각의 모듈과 전체 시스템을 테스트
    • Continuous Integration
      • 테스트는 항상 모델이 deploy되기 전에 새로운 코드로 repository에 푸시되야 함
    • Saas for CI
      • CircleCI, Travis, Jenkins
    • Containerization(via docker)
      • 테스트를 위한 격리된 환경
    • CircleCI / Travis
      • Saas for continuous integration
      • repository와 통합되서 테스트
      • docker container의 command로 job을 정의할 수 있고, 리뷰 결과를 저장할 수 있음
      • No GPU
      • CircleCI has a free plan
    • Jenkins / Buidkite
      • 개인 하드웨어, 클라우드 등에서 CI하기에 좋은 옵션
      • GPU 사용하기 좋음
      • Very flexible
  • Docker
    • 도커에 이해하면 좋음
    • Docker vs VM
    • Dockerfile and layer-based images
    • Dockerhub and the ecosystem
    • Kubernetes and other orchestrators
  • Web Deployment
    • REST API
      • HTTP requests - response를 사용해 serving
      • 웹서버가 띄워져 있고, prediction system을 call
    • Option
      • VM에 deploy
      • Container에 deploy
      • Serverless function에 deploy
    • Cloud instance에 배포
      • 단점
        • 프로비저닝이 힘듬
        • 인스턴스는 사용하지 않는 경우에도 비용 지불
    • Container에 배포
      • 단점
        • 컴퓨팅 시간이 아닌 자체 서버 가동 시간에 비용 지불
    • Serverless function으로 배포
      • 단점
        • 전체 배포 패키지는 500MB, 5분 이내 실행, 3기가 메모리 이하 등을 만족해야 함(AWS Lambda)
        • CPU 연산만 가능
  • Model Serving
    • 머신러닝 모델에 특화된 Web development options
    • 종류
      • Tensorflow Serving(Google)
      • Model Server for MXNet(Amazon)
      • Clipper(Berkely RISE lab)
      • Saas solutions like ALgorithmia
    • Tensorflow Serving
    • MXNet Model Server
    • Clipper
    • Algorithmia
  • 핵심 정리
    • CPU inference를 수행할 경우, 더 많은 서버를 사용하거나 서버리스로 가는 방법이 있음
      • Dream : Lambda처럼 Docker를 쉽게 배포
      • 모델의 요구 사항에 따라 Lambda 또는 Docker가 제일 좋음
    • GPU inference를 수행할 경우, TF Serving 및 Clipper 같은 adaptive batching 방법이 유용함
  • Monitoring
    • 무언가 잘못되면 알람해줘야 함
    • Cloud provider는 최근에 모니터링 솔루션을 가짐
    • 기록할 수 있는 모든 것을 모니터링할 수 있어야 함(예 : Data Skew)
    • 실습에서 보여줌
  • Interchange
    • ONNX
  • Hardware / Mobile
    • Problems
      • 모바일 기기는 메모리가 작아서 연산하기 느림
        • network size를 줄이거나, trick, quantize weight해야 함
      • 모바일 딥러닝 프레임워크는 full version보다 덜 발전함
        • 네트워크 구조를 바꿔야할 수 있음
    • Tensorflow Options
      • Tensorflow Lite
        • 최근 솔루션으로 사용됨
        • operator가 제한되긴 함
      • Tensorflow Mobile
        • 더 많은(그러나 전체는 아닌) operator가 있음
    • Mobile
    • NVIDIA for Embedded

Lecture 13 : Research Directions

  • 발표 자료
  • 연구 방향성에 대해 알려주려는 시간
  • 다양한 연구 분야에 대해 쉽게 설명해주고, 참고하면 좋을 논문들을 제공했음
  • 이 부분은 정리하기보다, 키워드를 캐치하고 추후에 따로 정리하는게 더 좋을듯

Reference


카일스쿨 유튜브 채널을 만들었습니다. 데이터 사이언스, 성장, 리더십, BigQuery 등을 이야기할 예정이니, 관심 있으시면 구독 부탁드립니다 :)

PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 지표, 실험 설계, 문화 만들기, 로그 설계, 회고 등을 담은 강의입니다

이 글이 도움이 되셨거나 다양한 의견이 있다면 댓글 부탁드립니다 :)

Buy me a coffeeBuy me a coffee



© 2017. by Seongyun Byeon

Powered by zzsza