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


카일스쿨 유튜브 채널을 만들었습니다. 데이터 분석, 커리어에 대한 내용을 공유드릴 예정입니다.

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

이 글이 도움이 되셨거나 의견이 있으시면 댓글 남겨주셔요.

Buy me a coffeeBuy me a coffee



© 2017. by Seongyun Byeon

Powered by zzsza