이번에는 딥러닝 프레임워크의 선두주자인 Pytorch와 Tensorflow를 비교해보려고 한다.
다양한 관점에서 둘을 비교해볼 수 있지만, 나는 그 중 중요하게 비교해볼 만한 점들에 대해서만 다루려고 한다.
1. Computational Graph ( Generation and Definition )
대부분의 딥러닝 프레임워크들은 gradient descent optimization을 위해서 gradients를 계산하기 위한 Computational Graph를 생성한다. 이렇게 forward propagation computational graph를 만들면서 딥러닝 프레임워크는 backward differentiation을 할 수 있게 되기 때문이다. 그런데 단순히 계산뿐이 아니다. 추가적으로 이러한 computational graph를 얻어야 하는 이유는 이를 통해 학습과정에서 병렬성과 속도 향상을 얻을 수 있기 때문이다. 이렇게 다양한 관점에서 딥러닝 프레임워크는 computational graph를 사용한다. 여기에는 보통 2가지의 graph 타입이 있다. 바로
Dynamic VS Static
Static Computational Graph
- Define and Run : 먼저 neural network architecture를 정의한 후에 이 그래프를 실행하는 시점에 data를 feed한다.
- tf.session으로 부터 variable을 요청해야 하기 때문에 상대적으로 디버깅에 불리하다.
- Tensorflow의 경우 새롭게 TF Debugger를 공부해야 할 정도로, TF session으로부터 요청된 변수에 대해서 다룬다는 점이 파이토치에 비해 상대적으로 복잡하다.
Dynamic Computational Graph
- Define by Run : 일단 forward propogation이 실행되면 그 때 그래프가 정의된다. 즉, 모든 기능을 가진 상태에서 forward computation을 하면 computational graph가 동적으로 구축된다는 것이다. ( flexibility )
- 이러한 dynamical한 특성 덕분에 중간중간 값을 확인할 수 있다는 등의 아주 큰 장점이 있다. 이는 디버깅 또한 편하게 만들어준다. 즉, 바로바로 확인이 가능한 것이다. 이러한 점에서 약간 Pythonic하다고 볼 수 있다.
- Pytorch의 런타임 즉 실행 시점에서 computational graph를 정의하기 때문에, 대부분의 파이썬 라이브러리들이나 툴들을 사용하기에 용이하다. 그래서 기존의 파이썬 디버거를 이용해서 손쉽게 파이토치 코드를 디버깅할 수 있다. ( Pycharm, pdb, ipdb 등등 )
이렇게 파이토치는 dynamical하기 때문에 데이터를 feed해줄때마다 새롭게 graph가 정의된다. 반면에 텐서플로우의 경우 먼저 위와 같이 그래프를 정의한 후에 그걸 여러 번 실행하게 된다. 각 iteration에서 중간 값들을 확인하기에 dynamical한 특성을 가진 파이토치가 유용하다는 것이다.
2. Production의 관점
실제로 딥러닝 모델을 개발하고 학습시키는 것은 엔지니어링의 관점에서는 절반정도 완성되었다고 볼 수 있다. 이러한 모델을 production과 management의 영역으로 넣어주는 것 또한 중요하고 이 또한 쉽지 않다.
Tensorflow는 Serving의 관점에서 매우 유연하다. 다양한 Serving tool이 잘 마련되어 있다.(실제로 구글의 프로젝트들을 통해서 증명되었다. ) 또한, Tensorflow는 매우 완벽하게 Kubernetess와 Docker와 같은 컨테이너 tool들과 결합되어 있다. 이러한 Tensorflow의 Serving은 산업적인 측면에 맞게 설계되어 있으며, 성능이 아주 중요한 경우 매우 좋은 선택이 될 수 있다. 예를 들어보자. 어떤 기업과 어떤 대학의 연구실이 있다고 하자. 동일한 모델을 사용하고 Serving함에 있어서, 10% 더 빠른 시간을 얻을 수 있다는 것은 연구자들에게는 엄청나게 큰 의미는 아닐 것이다. 하지만, 기업의 관점에서 보면 기업의 규모에 따라서 이는 수백만 달러까지도 절감할 수 있는 매우 중요한 점인 것이다.
Pytorch의 경우 2020년 4월에 TorchServe라는 model deployment tool을 내놓았다. 이는 아직 Tensorflow의 Serving에 비해서는 초기이며 실험적인 단계에 있다. 하지만, 점차 HuggingFace, Nvidia Waveglow 등을 지원하는 등의 빠른 발전을 보이고 있다.
조금 더 나아가서 Device Management의 관점 또한 같이 살펴볼 수 있다. 딥러닝 모델은 이를 다루는 디바이스에 따라서 큰 성능 차이를 보이기도 한다. Tensorflow와 Pytorch는 neural network를 적용하는 것은 아주 잘하고 있다. 하지만, 이를 잘 실행함은 또 다른 이야기다.
Tensorflow의 경우 작업에 GPU와 CPU 모두 사용 가능하고 CPU를 위한 Tensorflow와 GPU를 위한 Tensorflow가 따로 구현되어 있다.(Tensor flow-gpu) 명시적으로 device를 설정하지 않는 이상, GPU에 우선 할당되어 작업이 되고, GPU 가속은 Tensorflow의 자동화되어 메모리 사용량을 제어할 수 없다. 실제로 텐서플로우에서는 하나의 GPU가 사용 중이더라도 사용 가능한 모든 GPU의 메모리를 소모한다. ( 이는 사용 중인 기기를 다운시키는 등의 단점으로 작용하기도 한다.)
반면 Pytorch의 경우 GPU 가속이 자동화되지 않으며 GPU 사용자를 위한 전용 라이브러리가 구현되어 있지는 않다.(별로 큰 문제로 작용하지는 않는다.) 이러한 Pytorch는 CPU나 GPU 사용을 위해서 CUDA가 반드시 존재해야 하고, Tensorflow에 비해서 사용자가 리소스 사용을 효과적으로 제어할 수 있어 훈련 과정에서 더 유용하다.
3. Visualization
우리가 이미 이미지 분류 모델을 열심히 학습시켜서 이미지를 분류하는 데에 98%의 정확도가 나왔다고 가정해보자. 우리는 매 에폭마다, 우리의 딥러닝 모델의 loss와 accuracy를 기록해야 할 것이다. ( 모델 수립과 시각화 등등 다양한 관점에서 성능의 변화를 tracking하는 것은 매우 중요하다.) 혹은 다양한 하이퍼파라미터들을 가진 다양한 모델들의 데이터 플로우를 확인해보고 싶을 수 있다.( 일종의 정리 - 더 나은 모델을 위한) 즉, 모델의 학습 결과를 시각화하고 모델의 전체적인 학습 과정을 관찰하는 것은 매우 중요하다는 것이다. 물론 print를 통해 확인할 수도 있지만, visualizaiton을 통해 확인하는 시각화의 중요성은 다양한 서적이나 자료에서 강조하고 있다. 시각화는 단순한 글자들보다 훨씬 더 많은 insight를 가져오기도 하기 때문이다.
이렇게 딥러닝 모델의 학습과정을 더 쉽게 관찰하고 분석하기 위해서 그리고 디버깅 과정을(여기서는 오류 때문이 아닌 모델의 성능을 위한 개선을 의미한다.) 위해서 visualization을 해야 하고 Pytorch와 Tensorflow는 각각 Visdom 그리고 Tensorboard라는 visualizaiton tool을 제공한다.
Tensorboard
텐서보드는 그래프, 스칼라, 오디오, 히스토그램, 이미지 등의 다른 시각화를 통해 딥러닝 모델을 이해할 수 있는 Web apps에 적합한 시각화 툴이다.
Visdom
Visdom은 유연하며, 가시성이 좋고, customized가 쉬우며, 가볍다는 점에서 유용한 시각화 툴이다.
하지만, Visdom의 경우 Interactive하지 못하며 데이터의 개요를 위한 매우 제한적이고 최소화된 기능을 가지고 있다. 하지만, 최근 Pytorch 1.2.0의 최신 Release에는 Pytorch built-in Tensorboard가 있기에 우리는 파이토치를 사용하더라도 텐서보드를 통해서 유연하고 확장성 있게 시각화를 할 수 있다.
References
- BoostCourse week2 최성철 교수님 강의교안
- https://www.projectpro.io/article/pytorch-vs-tensorflow-2021-a-head-to-head-comparison/416