2020. 3. 5. 16:02ㆍ관심있는 주제/분석 고려 사항
Tensorflow2.0 이냐 Pytorch 나에 대해서 갈림길에 놓여있는 필자와 연구자들을 위해 관련 자료들을 모아서 비교하는 자료를 만들고자 함. 개인적으로 현재 2020년 03월 05일 시점에서는 Tensorflow2.0이 아직 버그가 많아서 Pytorch가 더 좋아 보이는 게 개인적인 생각임(그러나 필자는 tensorflow 1.x 유저)
일단 현재 많은 연구자들의 논문에서 Tensorflow 보다 Pytorch 관련 논문의 비율이 앞도적으로 늘어나고 있음.
그리고 전체 논문에서도 Torch가 Tensorflow보다 많은 비율을 차지하고 있는 추세임.
그렇다면 연구자들은 tensorflow 대비 pytorch에 어떠한 장점으로 인해 이런 추세를 가지게 된 걸까? 필자는 사실 배포에 관한 문제로 인해 장기적으로 봤을 때 pytorch 보다 Tensorflow가 좋다고 생각하지만, 이러한 추세는 무시할 수 없기 때문에 어떤 특징들이 있는지 알아보고자 함.
그래서 왜 연구자들은 Pytorch를 좋아할까?
- Simplicity
- numpy와 유사하고 매우 pythonic하고 파이썬 환경 시스템과 쉽게 통합할 수 있다.
- Tensorflow에서는 debugging 하기 굉장히 까다롭다.
- Great API
- 대부분 Tensorflow보다 Pytorch를 더 선호한다.
- 왜냐하면 tensorflow에서는 많은 변경이 있었다.
- layers -> slim -> estimators -> tf.keras (개인적으로 이것이 짜증 나기는 한다.)
- Performance
- PyTorch의 동적 그래프는 최적화의 기회를 엄격히 줄여준다는 사실에도 불구하고, PyTorch가 TensorFlow보다 빠르지 않더라도 그만큼 빠르다는 보고가 많았다.
- 이것은 진짜로 사실이라고 할 수는 없지만 매우 빈번하게 나오는 이야기다. 그래서 Tensorflow가 이 부분에서 static graph를 써서 확실하게 더 좋은 성능을 낸다고 할 수는 없을 것 같다.
그러면 연구 분야에서 Tensorflwo의 미래는 무엇일까?
TensorFlow가 PyTorch 기능과 동등하다고 하더라도 PyTorch는 이미 커뮤니티에서 대다수를 차지하게 됐다.
이것은 Pytorch에 관련 코드를 찾기 쉬워짐을 의미하고, 저자들은 많은 사람들이 그것을 사용하기 때문에 Pytorch로 코드를 내는 것을 장려하게 될 것이다. 현재 내가 코드를 찾아봐도 최신 연구 분야는 pytorch 코드가 반드시 있고, Tensorflow은 없을 때가 많았다. 따라서 TensorFlow 2.0으로 다시 이동하는 것은 전혀 발생하지 않을 가능성이 있다.
TensorFlow는 항상 Google/DeepMind 내에 포로로 잡힌 청중들을 가지고 있을 것이지만, 구글이 결국 이것을 완화시킬 수 있을지 궁금하다. 지금도 구글이 모집하고자 하는 많은 연구자들은 이미 다양한 수준에서 PyTorch를 선호할 것이고, 나는 구글 내부의 많은 연구자들이 TensorFlow 이외의 프레임워크를 사용하고 싶어한다는 불평을 들었다.
게다가, PyTorch의 우세함은 구글 연구원들을 다른 연구 공동체로부터 차단하기 시작할지도 모른다. 외부 연구 외에도 외부 연구자들이 구글에 의해 나온 코드 위에 설계하는 것을 더 어렵게 할 뿐만 아니라, 외부 연구자들도 덜 하게 될 것이다. TensorFlow 2.0이 TensorFlow의 연구 대상자 일부를 회수할 수 있을지 지켜볼 일이다. 열성적인 모드가 분명 호소력이 있을 것이지만, 케라스 API에 대해서도 같은 말을 할 수는 없다.
최근에 내가 본 것으로는 google의 deepmind의 개발의 속도를 내기 위해 pytorch로 넘아간다는 소식을 듣긴 했다. 이것을 보더라고 연구자 입장에서는 충분히 매력적이라는 것을 알 수 있는 것 같다.
| Tensorflow | Pytorch |
| Google(2015) | Facebook(2017) |
| distributed training support, scalable production and deployment options, and support for various devices like Android |
simplicity, ease of use, dynamic computational graph and efficient memory usage |
| ## Top Project Magenta: An open source research project exploring the role of machine learning as a tool in the creative process. (https://magenta.tensorflow.org/) Sonnet: Sonnet is a library built on top of TensorFlow for building complex neural networks. (https://sonnet.dev/) Ludwig: Ludwig is a toolbox to train and test deep learning models without the need to write code. (https://uber.github.io/ludwig/) |
## Top Project CheXNet: Radiologist-level pneumonia detection on chest X-rays with deep learning. (https://stanfordmlgroup.github.io/projects/chexnet/) PYRO: Pyro is a universal probabilistic programming language (PPL) written in Python and supported by PyTorch on the backend. (https://pyro.ai/) Horizon: A platform for applied reinforcement learning (Applied RL) (https://horizonrl.com) |
일단 이것만 봤을 때 Tensorflow는 제품성에서 많은 칭찬을 받고 있고, Pytorch는 연구자에게 많은 호응을 받을 수 있는 특징을 가지고 있기 때문에 위와 같은 현상이 발생한 것 같다. 그러면, 2가지 서로 반대되는 질문을 할 수 있겠는데,
Pytorch는 얼마나 제품성에서 Tensorflow보다 안 좋은가?
Tensorflow는 분석하기에 자유도가 Pytorch보다 얼마나 떨어지는가?
큰 특징들을 비교해보자. 물론 Tensorflow2가 생기면서 해당 특징이 완벽하게 일치하지 않을 수도 있다.
그러나 현재 Tensorflow2가 버그가 많으므로 1로 생각을 주로 해보자.
| Tensorflow | Pytorch |
STATIC GRAPH
|
DYNAMIC GRAPH
|
Tensorflow는 정적 그래프를 사용하여, 코드를 실행하기 전에 그래프를 다 만들어야 한다. 이러한 방식은 다 만들어야 하는 단점도 있지만, parallelism, dependency driving scheduling를 하게 하여 더 빠르고 효율적으로 학습할 수 있게 한다.
Pytorch는 특별한 session을 열지 않고 python language와 더 잘 통합되었다. 그래서 Tensorflow보다 더 Pythonic 한 코딩을 할 수 있다.
DISTRIBUTED TRAINING
| Tensorflow | Pytorch |
| you'll have to manually code and fine tune every operation to be run on a specific device to allow distributed training However, you can replicate everything in TensorFlow from PyTorch but you need to put in more effort. |
PyTorch optimizes performance by taking advantage of native support for asynchronous execution from Python |
pytorch는 Tensorflow 보다 data parallelism에 있어서 더 쉽게 만들 수 있다는 장점이 있다.
VISUALIZATION
| Tensorflow | Pytorch |
| TensorBoard | TensorBoard |
현재는 둘 다 적용이 가능하다.
- Tracking and visualizing metrics such as loss and accuracy.
- Visualizing the computational graph (ops and layers).
- Viewing histograms of weights, biases or other tensors as they change over time.
- Displaying images, text and audio data.
- Profiling TensorFlow programs.
PRODUCTION DEPLOYMENT
| Tensorflow | Pytorch |
| TensorFlow serving using REST Client API | not exists framework to deploy models directly on the web (Flask, Django) |
Tensorflow는 REST Client API를 사용한 Tensorflow serving이 존재하지만 pytorch는 아직 그러한 것이 없고 flask나 django를 사용해야 모델을 배포할 수 있다.
아직은 Tensorflow가 이 부분에 대해서는 압도하고 잇다.
| 2018-2019 | Tensorflow | Pytorch |
| public job boards | 1541 | 1437 |
| Medium Artice | 3230 | 1200 |
| Github star | 13.7k | 7.2k |
그렇다면, 만약 PyTorch가 연구원들에게 그렇게 인기를 끌게 되었다면, 왜 그것은 산업에서 같은 성공을 거두지 못했을까? 분명한 첫 번째 대답은 단순히 타성이다. 텐서플로우(TensorFlow)는 PyTorch보다 몇 년 전에 나왔으며, 업계는 연구자보다 신기술 채택이 느리다. 다른 이유는 TensorFlow가 PyTorch보다 생산이 더 좋았기 때문이다. 하지만 그것은 무엇을 뜻할까?
이에 답하기 위해서는 연구자와 산업의 요구가 어떻게 다른지 알아야 한다.
연구자들은 그들의 연구를 얼마나 빨리 반복할 수 있는지에 대해 관심을 갖고 있는데, 이것은 일반적으로 비교적 작은 데이터셋(한 기계에 맞을 수 있는 데이터셋)에 있고 8 개의 GPU에서 실행된다.
이는 일반적으로 성과 고려사항에 의해 크게 언급되는 것이 아니라 새로운 아이디어를 신속하게 구현하는 능력에 의해 결정된다.
반면 업계는 실적을 최우선으로 보고 있다. 10% 더 빠른 런타임은 연구자에게 아무런 의미가 없지만, 이는 기업의 수백만 달러의 비용 절감으로 직결될 수 있다.
또 다른 차이점은 배포다. 연구자들은 자신의 기계나 연구업무를 수행하는 데 전념하는 서버 클러스터에서 실험을 할 것이다. 반면에, 산업은 제한/요구에 대해 터무니없이 많다.
- No Python.
- 일부 회사들은 파이썬 런타임의 오버헤드가 너무 많은 서버를 운영할 것이다.
- Mobile.
- 모바일에 Python interpreter를 내장할 수 없다.
- Serving.
- 모델의 다운타임 없는 업데이트, 모델 간 원활한 전환, 예측 시 일괄 처리 등과 같은 기능에 대한 캐치 올(katch-all) 기능.
TensorFlow는 이러한 요구사항을 중심으로 특별히 제작되었으며, 이러한 모든 문제에 대한 해결책이 있다. 즉, 그래프 형식과 실행 엔진은 기본적으로 Python이 필요하지 않으며, TensorFlow Lite와 TensorFlow는 각각 모바일 주소와 서비스 고려사항이다.
아직까지는 PyTorch는 이러한 고려사항에 부응하는 데 있어서 부족했고, 그 결과 대부분의 회사들은 현재 TensorFlow를 생산에 사용하고 있다.
DEFINING A SIMPLE NEURAL NETWORK IN PYTORCH AND TENSORFLOW
| Tensorflow | Pytorch |
TensorFlow as the backend was merged into TF Repository. From then on the syntax of declaring layers in TensorFlow was similar to the syntax of Keras. |
a class and using torch.nn package we import the necessary layers that are needed to build your architecture.  |
Tensorflow도 class로 짤 수 있지만, 문제는 Tensorflow 1.x 는 또 짜게 되면 keras랑 호환이 안되고 너무 high level이라서 바꾸기 어렵다 그래서 개인적으로 pytorch가 버전이 업그레이드가 되고 일관성을 가지는 것 같다.
| Tensorflow | Pytorch | |
| Pros |
|
|
| Cons |
|
|
| Recommendation | What I would recommend is if you want to make things faster and build AI-related products, TensorFlow is a good choice. | PyTorch is mostly recommended for research-oriented developers as it supports fast and dynamic training. |
Framework “Convergence”
2018년 말경, 두 개의 주요 사건이 나타났다.
| Tensorflow | Pytorch |
|
|
이것은 서로의 약점을 보완하기 위한 움직임이다. 그렇다면 이 특징들은 정확히 무엇이며, 무엇을 제공해야 하는가?
PyTorch TorchScript
PyTorch JIT는 TorchScript라고 불리는 PyTorch의 중간 표현(IR)이다. TorchScript는 PyTorch의 "그래프" 표현이다. 추적 모드나 스크립트 모드를 사용하여 일반 PyTorch 모델을 TorchScript로 변환할 수 있다. 추적은 기능과 입력을 취하고, 그 입력으로 실행된 작업을 기록하고, IR을 구성한다. 비록 간단하지만, 추적에는 단점이 있다. 예를 들어 실행되지 않은 제어 흐름을 캡처할 수 없다. 예를 들어, 실제 블록을 실행한 경우 조건부의 거짓 블록을 캡처할 수 없다.
스크립트 모드는 함수/클래스를 취하고, 파이썬 코드를 재해석하며, TorchScript IR을 직접 출력한다. 이것은 그것이 임의 코드를 지원할 수 있게 하지만 본질적으로 파이썬을 재해석할 필요가 있다.
이 기능을 통해서 결국 Python 의존성 없이 C++로 배포할 수 있게 된다!
Tensorflow Eager
API 수준에서 TensorFlow help 모드는 본질적으로 Chainer에 의해 만들어진 PyTorch의 gear 모드와 동일하다. 이것은 TensorFlow에게 PyTorch의 열망 모드의 장점을 대부분 제공한다. 그러나 이것은 또한 텐서플로우에게도 같은 불이익을 준다. TensorFlow 열성 모델은 Python이 아닌 환경으로 내보낼 수 없으며, 최적화될 수 없으며, 모바일에서 실행할 수 없는 등. 이것은 TensorFlow를 PyTorch와 같은 위치에 놓고, 그들은 본질적으로 같은 방식으로 해결한다 - 당신은 당신의 코드(tf.function)를 추적할 수 있다. 또는 Python 코드(Autograph)를 재해석한다.
그러므로 텐서플로우의 eager mode는 진정으로 당신에게 "두 세계 최고의best of both worlds" 를 주지 않는다.
비록 tf.function로 당신의 eager code를 정적 그래프로 바꿀 수 있다는 것은 좋았지만, 함수 주석, 이것은 결코 매끄러운 과정이 될 수 없다(PyTorch의 TorchScript도 이와 유사한 문제를 가지고 있다). 추적은 근본적으로 제한되며, 파이썬 코드를 재해석하는 것은 본질적으로 파이썬 컴파일러의 많은 부분을 다시 써야 한다. 물론 그 범위는 심층 학습에 사용되는 파이썬의 서브셋으로 제한함으로써 대량으로 단순화된다.
기본적으로 Eager 모드를 활성화할 때 TensorFlow는 사용자에게 선택을 강요한다. 즉, 사용 편의성을 위해 열렬한 실행을 사용하고 배포를 위해 다시 쓰기를 요구하거나, 긴급 실행을 전혀 사용하지 않는다. 이것은 PyTorch와 같은 상황이지만, PyTorch의 TorchScript의 선택적 성격은 TensorFlow의 "기본적으로 Eager mode"보다 더 입맛에 맞을 가능성이 있다.
Current State of ML Frameworks
Pytorch는 좀 더 산업적인 성공을 하기 위해 노력하고 있고, Tensorflow는 제품 능력의 손실 없이 연구 분야를 위해 노력하고 있다.
PyTorch가 산업에서 의미 있는 영향을 미치려면 분명히 오랜 시간이 걸릴 것이다 - TensorFlow는 너무 고착되어 있고 산업은 느리게 움직인다. 그러나 텐서플로우 1.0에서 2.0으로의 전환은 어려울 것이며 기업들이 PyTorch를 평가할 수 있는 자연스러운 포인트를 제공한다.
연구원 선호도가 산업에 얼마나 영향을 미칠까?
현재의 박사학위생들이 졸업하기 시작하면서, 그들은 PyTorch를 사용할 것이다. 이러한 선호도는 기업들이 고용 목적으로 PyTorch를 선택할 만큼 충분히 강한가? 졸업자들은 PyTorch 위에 세워진 창업들을 시작할 것인가?
TensorFlow의 eager mode가 사용성에 있어 PyTorch를 따라잡을 수 있는가?
이슈 트래커와 온라인 커뮤니티로부터 받은 나의 인상은 Tensorflow Eager가 성능/메모리 문제로 심하게 고통받고 있으며 오토그래프도 그 나름대로의 이슈를 가지고 있다는 것이다.
구글은 엄청난 양의 엔지니어링 노력을 할 것이지만 텐서플로우에는 기존에 남아있는 코드들(짐)을 가지고 있다.
PyTorch가 생산성 상태로 얼마나 빨리 갈 수 있는가?
PyTorch가 해결하지 못한 근본적인 문제들이 아직도 많이 있다. - good quantization story, no mobile, serving, and 등이 없다. 이것을 해결하기 전까지는 Pytorch는 많은 회사들에서 선택이 안될 것이다. PyTorch가 기업들이 전환을 할 수 있도록 충분히 설득력 있는 이야기를 제공할 수 있을까?
참고: 이 기사가 발표된 날, PyTorch는 정량화와 모바일에 대한 지원을 발표했다. 둘 다 아직 실험적이지만, PyTorch의 경우 이 전선에서 상당한 진전을 보이고 있다.
업계에서 구글의 고립이 이를 해칠까.
구글이 텐서플로우를 추진하는 주된 이유 중 하나는 급증하는 클라우드 서비스를 지원하기 위해서다. 구글은 전체 ML 수직선을 소유하려고 하기 때문에, 이것은 구글이 유일한 대안적인 기계 학습 프레임워크를 지원하기 위해 경쟁하고 있는 회사들(마이크로소프트, 아마존, 엔비디아)에게 인센티브를 준다.
기계 학습 프레임워크가 ML 연구를 얼마나 많이 형성하는지는 아마도 과소평가된 것 같다. 그들은 단지 기계 학습 연구를 가능하게 하는 것이 아니라, 연구자들이 쉽게 탐구할 수 있는 아이디어를 가능하게 하고 제한한다. 단지 그것을 골격으로 표현하기 위한 쉬운 방법이 없다는 이유만으로 얼마나 많은 초창기 아이디어들이 뭉개져 있는가?
PyTorch는 연구를 위해 local minima까지 도달했을지 모르지만, 다른 프레임워크가 제공하는 것이 무엇이며, 어떤 연구 기회를 노출시킬지 검토할 가치가 있다.
최종 정리표
| Pytorch | TensorFlow | |
| Developed by | ||
| Graphs | Dynamic graphs | Static graphs |
| Distributed Training | Torch enables performance optimization in research and production and scalable distributed training. | Difficult Control |
| Distinguish Feature | TensorBoard | TensorBoard |
| Learning curve | Easy to learn | Steep learning curve |
| Community | Comparatively small | Large |
| Serialization | simple API that saves all the weights of the model or pickle the entire class. TorchScript(supported by C++) or JTorch | significant advantage that the entire graph can be saved as a protocol buffer, including parameters and operations as well. (C++ , java) |
| Deployment | Comparatively less supportive (using Flask or Django) & or new-release about mobile |
Supportive REST Client API & mobile support |
| Debugging | Dynamic computational process. | Requires the TensorFlow debugger tool. |
| Projects | cheXNet, PYRO, Horizon | Magenta, Sonnet, Ludwig |
| Device Management |
GPU) automatically assumes if the user wants to on the GPU if one is available | GPU) requires the user to move everything onto the device if CUDA is enabled explicitly. |
2020년 03월 11일 Tensorflow 2 관련 Dev Summit이 나옴.
제대로 보지는 않았지만, 매력적인 것을 많이 제공하는 것 같음 (Profiling , Tensorboard, JAX, ...)
이 블로그에서 Tensorflow Dev Summit 영상 내용들을 코드와 함께 정리해주심
https://www.youtube.com/watch?v=6ovfZW8pepo
아래 브런치에서도 잘 정리해주셨음.
https://brunch.co.kr/@synabreu/54
텐서플로우 생태계: 책임성 있는 AI와 개발자 커뮤니티
TFDevSummit 2020 키노트 후기(2) | 텐서플로우 생태계: 머신러닝 개발부터 배포까지 편은 재미있게 잘 읽으셨나요? 페이스북의 TensorFlow KR 그룹에 공유했는데 정말 폭발적으로 조회수 및 공유수들이 넘어가서 깜짝 놀랐습니다. 너무 글이 길어질까 봐 두 부분이 나누었습니다. 오늘은 계속해서 텐서플로우 생태계: 책임성 AI와 커뮤니티 부분에서 TF Dev Summit 2020 기조연설에서
brunch.co.kr
Reference