5회차 받아쓰기

Attendees 1 00:00 네 이제 시작하도록 하겠습니다. 일단 오늘 오프라인 미팅을 못 하게 돼서 일단 죄송하고요. 그리고 제가 좀 다른 일들이 바빠서 강연 자료 준비도 조금 지연이 돼서 제가 시작하기 바로 전에 일단 배포하게 된 것도 죄송합니다. 다음 번에는 좀 더 빠르게 배포할 수 있도록 해보겠습니다. 오늘은 다섯 번째 시간으로 파이토치의 이제 분산 프로그래밍에 대해서 이야기를 좀 나눠보려고 합니다. 일단 저희가 지금 어디 있는지 잠깐 리캡을 하고 시작을 해보면 좋을 것 같은데 지금 첫 번째 주에는 저희가 기술적인 배경에 대해서 좀 이야기를 나눴고 그리고 이제 두 번째 주에는 이거 모드 그다음에 세 번째 주에 이 그래프 모드에 대해서 저희가 좀 이야기를 나누고 바로 지난주에는 오토메틱 디시션 오토 그라드에 대해서 저희가 이제 이야기를 나눴었고 그리고 이번 주에는 분산 프로그래밍에 대해서 이야기를 나누려고 하는데요. 이렇게 하면 저희가 원래 이제 계획을 했던 파이토치의 기본적인

Attendees 1 01:09 기능들 걔네들이 그리고 어떻게 파이토치 안에서 구현이 되어 있나라고 하는 것들은 커버를 하는 것 같거든요 이렇게 해서 일단 파이토치 안에 있는 이야기들은 제 생각에는 어느 정도 된 것 같아서 마무리를 하려고 하고 그리고 다음 주에는 파이토치 비온드 파이토치라고 해서 실제로 사람들이 파이토치를 가지고 뭔가 모델을 개발을 할 때 특히나 인퍼런스를 한다라고 생각을 하면 LA 특히나 LM 같은 경우에 거의 대부분의 기능은 파이토치가 커버를 하지만 파이토치만 가지고 하는 경우는 최근에는 많이 없는 것 같아요. 그 이제 큰 팩터 중에 하나가 커스텀 커널들이 필요한 거 그리고 이제 다른 큰 팩터가 물론 VLM 같은 상위 레벨 최적화가 필요해서 그래서 파이토치와 커스텀 커널 그다음에 VLM 이렇게 세 개를 묶어서 제 생각에는 특히 인플런스 같은 경우에는 해 주시면 좋을 것 같아서 그럼 커스텀 커널 그다음에 VLM 이 정도의 타픽을 다루면

Attendees 1 02:11 저희가 이제 소프트웨어적으로 거의 대부분 저희가 커버하고 싶은 내용들은 커버를 하지 않을까 생각을 하고요. 그러면 이제 저희가 그다음 주 일곱 번째 주부터는 약간 초점을 맞춰서 이제 하드웨어적인 부분에 대한 이야기들을 시작을 해볼까 하고요. 일곱째 주는 그 대회에 좀 해당할 것 같고 여덟 번째 주는 특히 좀 리벨리언에 관련되어 있는 내용들로 커버를 해보면 어떨까 싶습니다. 그 이후의 계획은 아직 없기는 한데 이렇게 강의 형식으로 진행을 하는 거는 그 정도면 충분하지 않을까 그런 지금 생각이 들긴 하지만 그 이후의 계획에 대해서는 제가 좀 더 고민을 하고 다음 번 강의를 할 때 좀 더 자세히 계획을 한번 공유를 해 드리도록 하겠습니다. 혹시 저희 지금 현재 계획이나 이런 것들에 대해서 코멘트나 질문하고 싶은 거 있으신가요?

Attendees 1 03:08 네 그러면 이제 시작을 하도록 하겠습니다. 일단 저희가 기술 분류로 나눠서 봤을 때 파이토치2에 제가 가장 중요한 특성으로 여기 나와 있는 그런 내용들을 제가 제시를 했었는데요. 그중에서 오늘은 mpi와 비슷한 파이토치의 디스트리뷰티드 프로그램 모델에 대해서 이야기를 나눠보도록 할 거고요. 일단 크게 네 부분으로 나눠서 말씀을 드리려고 해요. 하나는 전반적인 오버뷰 그리고 두 번째는 실제 이제 어떻게 동작하는지를 토치론이라고 하는 스크립트를 활용을 해서 좀 설명을 했으면 하고 그리고 디바이스와 어떻게 연결되는지라고 하는 부분 그리고 파이토치가 제공하는 격렬한 패키지들 이렇게 네 가지 정도 탑픽을 다루고 오늘은 마무리를 하게 될 것 같습니다. 가장 대표적인 이런 병렬 프로그래밍 모델로 하면 딱 떠오르는 게 mpi 하고 오픈 MP 이렇게 두 가지가 있는데 이 두 개가 가장 크게 다른 점은 이제 가정하고 있는 밑에 있는 메모리 시스템이 다른 것 같아요. 오픈 엠페 같은 경우에는

Attendees 1 04:23 CPU들이 약간 타이트하게 커플 되어 있다라고 생각을 하고 얘네들이 셰어드 메모리 그러니까 모든 프로세서들이 모든 메모리에 다 접근이 가능하다라고 이제 가정을 하고 있고요. 일단 최장님께서 스터디 이기는 어떻게 진행되는가 질문을 하셨는데 그건 아직 제가 깊게 생각을 해보지 못해서 좀 더 구체화가 되면은 좀 말씀을 나눠보면 어떨까 싶습니다. 있고 그다음에 mpi 같은 경우에는 그 메모리들이 직접적으로 접근은 되지 않고 익스프리스하게 CPU 간에 프로세서 간에 메시지를 보내고 보내고 주고받고 하는 형태로 커뮤니케이션이 이루어지는 것을 가정을 하고 있어요. 이렇게 mpi랑 open AI가 구분이 되고 파이토치는 이 둘 중에서는 mpi 스타일을 따르고 있다라고 생각을 하시면 되고요. mpi와 오픈 AI는 그 밑에 있는 메모리 시스템이 어떻게 생겼는지 가정하는 것뿐만이 아니라 실제 이런 이런 테스크들이 어떻게 구성이 되어 있는가라고 하는 거에 있어서도 조금 차이가 나는데 이게 메모리

Attendees 1 05:29 시스템에 대한 과정이 다르기 때문에 이렇게 차이가 나는 건가라고 하는 거는 저도 확실하게 잘 모르겠습니다. mpi 같은 경우에는 정말 단독적으로 동작을 하는 프로세스들이 그냥 묶음이라고 생각을 하면 되는 거고 그냥 모든 프로세스들은 사실 다른 프로세스들과 상관없이 각자 이제 시작을 하게 되고요. 그리고 메세지 패싱을 하는 것 말고는 또 마찬가지로 각자 자기가 할 일을 하면 되는데 예를 들어서 리덕션 같은 걸 하기 위해서 모든 애들이 다 끝날 때까지 기다려야 된다라고 한다면은 배려 같은 이제 만들 수가 있고 그 배려를 만날 때까지는 모든 애들이 다 기다리고 있다가 다 만나면 다시 시작을 하는 이런 방식으로 동작을 하게 됩니다. 그렇게 이제 배려라든지 아니면은 메시지 패싱에 의해서 메시지를 주고 주고 받는다든지 하는 것 외에는 별다른 관계가 없고요.

Attendees 1 06:24 open API 같은 경우에는 뭐 비슷하다고도 할 수 있긴 하지만 일단 메스터에 해당하는 그런 어떤 테스크가 있어서 메스터에 해당하는 테스크가 일단 뭔가 시작을 한 다음에 그 메스터로부터 여러 가지 패러하게 돌 수 있는 일들이 이제 포크가 되고 마찬가지로 끝나면 조인이 되고 다시 메스터가 뭔가 일을 한 다음에 또다시 이제 포크를 하고 조인을 하고 이런 식으로 이제 패러럴 테스크를 구성을 하도록 되어 있습니다. mpi는 대충 mpi 프로그램 같은 경우에는 이런 식으로 짜져 있는데요. 근데 이제 많은 경우에 mpi를 하더라도 같은 프로그램을 돌리는 경우가 많거든요. 특히 파이토치로 짠 분사 모델 같은 경우에는 특히 이제 그런 경우가 아마 대부분일 것 같아서 실제로는 이런 식으로 구성되어 있는 코드가 각각의 다른 프로세스에서 돌게 된다라고 생각을 하시면 될 것 같고 그 각자의 프로세스가 일단은 뭔가 이니셜라이제이션을 수행을 하고

Attendees 1 07:21 실제로 패럴하게 잡을 수행을 하는 부분인데 그 잡에 특히 이 테스크가 이 프로세스가 해야 되는 부분들에 대한 기술들이 들어있게 되고요. 이게 이제 싱글 프로그램이다라고 한다면은 같은 잡을 그 대신에 다른 뭔가 랭크에 의해서 다르게 동작을 하도록 아마 짜게 되겠죠 내지는 이프문 같은 걸 써가지고 내 랭크에 따라서 사실은 실제로는 다른 일을 하게 할 수도 있는 것 같아요. 그리고 이제 실제 다 모든 일이 끝나면 파이널라이즈를 하고 전체적으로 패스트를 종료를 하게 됩니다. 다음에 좀 보시겠지만 파이토치도 거의 비슷한 구조를 따르고 있어요. 이게 이제 파이토치의 분산 프로그래밍 모델이라고 할 수 있는데 일단 mpi에 있는 프로세스랑 그 컨셉이랑 거의 저는 같은 것 같거든요. 노드라는 개념이 있고 이 노드라고 하는 거에는 여러 개의 프로세스가 돌 수가 있고 그리고 이런 노드들 프로세스들이 다 모여서 월드라고 하는 전체 계산 전체 범위가 계산의 범위가 되는

Attendees 1 08:24 개념을 이제 구성을 하는 거고 이 랭크는 글로벌한 랭크도 있긴 하지만 로컬라는 랭크도 있어서 한 노드 내에서 다른 프로세스들을 구분을 할 수도 있고요. 이런 것들을 이제 구성을 하기 위해서는 어떤 머신들이 이 테스크에 참여를 하는지라고 하는 것들을 판별을 하고 구성을 해야 되는데 그거를 이제 파이토치에서는 랑데뷰라고 표시를 하고요. 맨 처음에 시작하자마자 일단 랑데뷰를 만들어서 이 일에 참여를 할 모든 그런 머신들을 파악을 한 다음에 그다음에 그 잡을 이렇게 뿌려가지고 실행을 하게 됩니다. 조금 더 자세히 살펴보기 시작을 할 텐데요. 보면은 일단 랑제비라고 하는 게 여러 노드들을 묶어서 이제 구성을 하면 그 노드들 안에 각자 여러 개의 프로세스가 있을 수 있고 그 하나하나 프로세스마다 이제 다른 링크들을 부여를 하고

Attendees 1 09:17 글로벌 랭크가 있고 로컬 랭크가 있고 뭐 이런 개념들은 바로 전장에서 제가 좀 말씀을 드렸고요. 이 각각 하나하나 이 프로세스를 크게 다시 확대를 해 보면 그 안에 파이토치가 돌고 있겠죠 파이토치가 돌고 있는데 가장 맨 아랫단에서 보면은 실제 커뮤니케이션을 하기 위한 그런 백엔드가 붙어 있어서 예를 들어서 푸다라든지 아니면 mpi라든지 하는 이런 다른 라이브러리를 활용을 해서 CPU 또는 GPU의 커뮤니케이션 안에 이제 커뮤니케이션을 관장을 하게 되고요. 그럼 백엔드가 CD라고 하는 이게 스텐드가 커뮤니케이션 제가 정확하게 까먹었어요 스텐디가 뭔지는 스텐디라고 하는 그런 레이어가 있어서 이게 실제 파이토티의 디스트리뷰트의 이제 코어에 해당하는 부분이 되고요. 여기에 이제 실제 백엔드라고 하는 것들이 이제 붙게 되고 콜렉티브 API들의 인터페이스도 여기에 다 정의가 되어 있습니다.

Attendees 1 10:17 또 이런 걸 가정을 한 뒤에 거기에 이제 하이레벨 패키지들 특히나 이제 모델을 병렬화를 할 수 있는 이런 패키지들이 붙어서 이런 것들을 이제 활용을 해서 파이토치에서는 모델을 병렬로 여러 머신들에서 돌리게 됩니다. 네 프로세스 그룹이라고 하는 개념들도 있는데요. 이것들은 실제로 이제 커뮤니케이션을 하기 위해서 만든 그런 어떤 구성 단위라고 생각을 하면 되고 이게 전체 월드를 표현을 할 수도 있기는 하지만은 프로세스 그룹이 또 하나의 다른 프로세스 그룹을 안에 가지고 있을 수 있어서 어떻게 보면 이렇게 하이라키컬하게 프로세스 그룹을 구성을 하고 커뮤니케이션 할 때 그런 단위로도 커뮤니케이션을 할 수가 있습니다. 네 디스트리티드 커뮤니케이션 레이어네요. 시트니 아까 이제 중간 부분에 그러니까 실제 각각의 프로세스에서 돌아가는 테스크를 마우스 마우스 있는

Attendees 1 11:15 아웃을 했을 때 이제 들어 있는 가운데에 있는 100본에 해당하는 게 이 시디라고 하는 게 있고 이 시디에 실제 디스트리뷰티드 커뮤니케이션 API가 정의가 되어 있고요. 파이토트 내에는 콜렉티브 커뮤니케이션과 P2P 커뮤니케이션 이렇게 두 개로 나눠져 있는데 저는 대부분의 패키지들이 다 콜렉티브 커뮤니케이션을 쓸 것 같기는 하거든요. 근데 P2P도 아마 쓰긴 하겠지만 하이라이벨 패키지들이 P2P 커뮤니케이션도 지원을 하는지는 잘 나가보겠습니다. 여기에 들어 있는 컬렉티브 커뮤니케이션의 스케터 그다음에 개더 스케터 같은 경우에는 데이터를 여러 다른 그런 프로세스들을 이제 분산을 하는 배포를 하는 과정이고 그다음에 배더라고 하는 것들은 그런 것들로부터 데이터를 다시 취합을 하는 과정이라고 생각을 할 수가 있고요. 그리고 이제 리듀스 그다음에 올 리듀스 같은 이런 패턴들도 다 지원을 하고

Attendees 1 12:06 몇 개인지는 아마 제가 잘 기억은 안 나는데 꽤 많은 그런 보편적으로 쓰이는 콜렉티브 커뮤니케이션 API들이 기본적으로 뒤에 정의가 되어 있습니다. 네 보드 캐스트 올 개더 이런 것들도 있고요. 아까 말씀드린 것처럼 시디 자체는 그 안에 특별한 구현이 들어가 있지는 않고요. 그러니까 이런 인터페이스 그런 커뮤니케이션 API들에 대한 구현이 들어가 있지는 않고 그 구현은 실제 이제 저희가 커뮤니케이션 백엔드라고 부르는 부분들에 들어가 있는데 파이토치에서 기본적으로 제공을 하고 있는 거는 글루 그다음에 엠비디아에서 이제 만든 NCL 그다음에 mpi 이렇게 세 개 정도가 있는 것 같고 npi는 잘 제대로 동작을 하는지는 잘 모르겠어요. API는 제대로 잘 동작하는지 모르겠고 글루하고 NCL을 주로 사용을 하는 것 같은데 글루 같은 경우에는 주로 CPU 용으로 많이 사용을 하고 있는 것 같고 그런데 이제 디퓨드 GPU도 같이 사용을 할 수가 있고요.

Attendees 1 13:03 MB디어 지표를 쓴다라고 한다면 대부분 아마 NCL을 배경지로 선택을 해서 사용을 할 거라고 생각을 합니다. 이런 이제 백엔드 같은 경우에는 시디 디렉터리 안에 들어 있는 b 백엔드 제가 슬레스를 잘못 넣었네요. 이제 백엔드 점 HPP에 들어있는 버털 펑션들을 다 구현을 해야 되는데 여기 한 22개 정도의 버털 펑션이 들어 있다라고 하네요. 지금까지 대충 파이토치의 디스트립티드 패키지가 어떻게 구성되어 있는지 그러니까 디스크리트 프로그램 모델이 어떻게 구성되어 있는지에 대해서 말씀을 드렸고요. 실제 사례로 그 구체적으로 이게 어떻게 동작하는지를 저희가 스크립트를 하나 보면서 같이 살펴보면 좋을 것 같습니다. 치 토치 토치 런이라고 하는 게 이제 파이토치에서 기본적인 들어있는 이런 분산 프로그램을 하기 위한 뭐라고 해야 될까요?

Attendees 1 14:00 탑 레벨 스크립트라고 생각을 하면 되는데 이걸 꼭 써야 되는 건 아니고요. 이제 여기에 있는 재료들을 다시 조합해서 각자 나름대로 비슷한 거를 만든다든지 하는 것들도 충분히 가능하고요. 이 각각에 있는 노드들이 이제 토치 런을 돌리면 그 토치 런에서 같이 물고 들어간 이런 테스크들을 그 노드들이 모여서 같이 일을 한다라고 생각을 하시면 되고요. 이제 각 모드에서 실행을 할 때 여러 개의 이제 파라미터를 넘기게 돼 있는데 일단은 전체 월드가 어떻게 구성되어야 하는지에 대한 정보도 같이 전달을 해야 되고 그리고 실제 이 토치 런이 몇 번째 프로세스에 해당하는지라고 하는 것들 그리고 실제로 사용할 백엔드는 어떤 건지 그리고 랑데뷰를 할 머신의 앤드 포인트들은 어떤 게 있는지 돌려야 될 테스트는 무엇인지 이런 것들이 이제 토츠런이 받아들이는 가장 중요한 파라미터라고 생각을 하면 될 것 같아요.

Attendees 1 14:58 그래서 이렇게 토치 런에 이런 파라미터를 돌려서 돌아야 되는 모든 프로세스들이 다 이제 이렇게 이걸 띄우면 여러 가지 이니셜라이제이션 하고 결국에는 이제 토치 파이토치가 실행이 되면서 이 모델 이 프로세스에 할당된 부분의 모델을 이제 수행을 하게 되는 거죠. 이제 토치 을 이제 시작을 하기 전에 그 수행을 하기 전에 일단은 먼저 준비를 해야 될 것들이 있는데 일단은 전체적인 클러스터를 먼저 이제 설정을 해야 되고요. 그냥 단순하게 SSH를 가지고 이제 설정을 해도 되고 아니면 웨이라든지 슬럼이나 호로보 같은 그런 분산 프로그래밍을 분산 클러스터를 구성하고 관리하도록 해주는 이런 패키지들을 사용을 해서 클러스터를 설정을 할 수도 있을 거고요. 이렇게 해서 일단은 클러스터가 이제 준비가 되면 그러면 각 노드에서 다음과 같이

Attendees 1 16:00 이 넣는 이제 수행을 하면 되는데 만약에 여기에서 갓 노드에서 8개의 프로세스를 돌린다라고 하면 이런 거를 랭크를 바꿔서 8개를 이제 수행을 8번을 이제 수행을 하면 되겠죠 아까 말씀드린 것처럼 중요한 파라미터들을 다 이제 세팅을 해서 이제 토치 점 럼이라고 하는 스크립트를 각 노드에서 이제 실행을 하면은 그런 프로세스들이 이제 뜨면서 전체적인 엑스큐션이 이제 시작이 됩니다. 토치 런에서는 그럼 어떤 일이 일어나냐라고 하는 거를 이제 여기 좀 적어놨는데 일단은 명령을 먼저 처리 명령을 어떤 명령을 받았는지라고 하는 것들을 처리를 하고 초기화하는 그런 과정에서 거 그리고 이제 파이썬 프로세스를 띄워야 되고 그리고 이제 랑데뷰 아까 제가 말씀드린 랑데뷰를 초기화 한다든지 하는 이런 랑데뷰를 이제 실행을 하고 그리고 랑데뷰에 의해서 클러스터가 구성이 됐으면은 그때부터 이제 각 프로세스별로 파이토치를 이제 실행을 하게 되겠죠 파이토치 실행을 마 파이토치 스크립트는

Attendees 1 17:03 각자 이제 알아서 짜면 되는데 거기에도 대충 어떤 식으로 이제 진행이 돼야 되는지를 한 번 하는 것들은 아까 제가 살짝 보여드렸던 API의 각 프로그램이 어떻게 구성됐는지와 이제 유사하게 비슷한 패턴들을 가지고 있거든요. 하나는 일단 커뮤니케이션 백엔드를 일단 선택을 하고요. 파이토치에서 사용할 커뮤니케이션 베겐디를 이제 생성을 하고 그리고 데이터를 로딩을 하고 쪼개고 그다음에 계산을 하고 필요하면 이제 동기화를 하고 전체적으로 이제 계산이 끝나면은 이제 프로세스 그룹을 제거를 하면서 계산을 마치게 되죠. 거기에 이제 추가적으로 2 지점 론에서 예를 들어서 폴트 털런스를 위한 그런 기능들을 수행을 해야 된다라고 하면은 이런 추가적인 작업도 마찬가지로 투지점에서 실행을 할 수가 있습니다. 랑데뷰 같은 경우가 아까 제가 말씀드렸던 것처럼 이 하나의 분산 계산에 포함할 그런 모션들의 이제 셋을 구성을 하고 그 정보들을 이제 알려주는 그런 과정이라고 생각을 할 수가 있고요.

Attendees 1 18:05 이거는 이제 파이토치를 돌리기 전에 투치점 론에서 이제 수행이 됩니다. 이 과정에서 IPC를 사용을 할 그런 시스템 백엔드를 일단은 초기화를 한다든지 그다음에 왕대의 엔드 포인트에 저희가 연결을 한다든지 그래서 이제 실제 모든 다른 프로세스가 다 조인 할 때까지 기다린다든지 링크를 제 할당을 받는다든지 하는 이런 실제 내가 내 태스크를 시작하기 전에 전체 분산 환경 측면에서 필요한 그런 작업들이 각각 로드에서 각각의 프로세스 내에서 이 과정에서 이제 세팅이 되게 됩니다. 이렇게 이제 일단은 랑데뷰가 다 셋업이 돼서 정말로 내가 해야 될 일을 시작을 하게 되면 토치 런에 주어진 이 스크립트를 이제 파이토치를 열어서 수행을 하면서 이제 시작을 하게 되는데요. 예를 들어서 간단하게 맨몰 같은 것들을 수행을 한다라고 한다면 다음과 같은 과정을 통해서 한번 구현을 해볼 수가 있을 것 같아요. 일단은 맨 처음에 보면은 랭크가 0인지 아닌지에 따라서 다르게 계산을 할 수가 있고요.

Attendees 1 19:11 예를 들어서 과정 자체가 랭크 제로에 일단은 전체적인 이니셜 데이터를 가지고 오고 다른 곳으로 뿌린다라고 한다면은 그런 과정들은 랭크 별로 다르게 셋업을 할 수가 있을 것 같습니다. 일단 그런 초기 과정을 끝난 다음에 실제 이제 계산은 여기에서는 디스트 언더스코어 맨멀 언더스코어 올리디스라고 하는 함수로 호출을 하게 되고 그리고 그 결과들이 다 랭크 제로에 모인다고 가정을 했을 때 랭크 제로면은 그 결과도 추격을 하겠죠 이게 탑 레벨에서 실제 이제 할 테스크를 한번 구성을 해 보는 거고요. 여기에서 이제 가장 중요한 일은 여기 제가 볼드로 해 놓은 디스트리뷰트 언더스코어 맨멀 언더스코 올리스트라고 하는 함수에서 처리를 하게 되고 다음 페이지에서 그걸 좀 더 자세히 살펴보도록 하겠습니다. 이 함수에서는 일단 처음에 필요한 그런 세팅을 하고요. 예를 들어서 한 로컬 디바이스에

Attendees 1 20:07 여러 개의 그런 프로세스가 뜰 수가 있고 각 프로세스마다 다른 디바이스를 쓴다라고 한다면은 내가 어떤 디바이스를 써야 될지 설정을 해야 될 거 아니에요. 이런 걸 이제 로컬 랭크를 활용을 해서 이제 소팅을 할 수가 있고 그리고 내가 어떤 베개드를 쓸지라고 하는 것들도 여기서 이제 셋업을 하게 되고요. 그리고 실제 이제 계산에 필요한 데이터를 받는 과정 그리고 그거를 실제로 이제 계산을 하는 과정 수행을 하게 되고 그리고 이제 그 계산이 다 끝났으면은 그걸 다시 모아서 최종 결과를 만들어야 되니까 리덕션 같은 것들을 할 수가 있겠죠 이런 과정들이 다 끝나게 되면은 해야 될 모든 계산이 끝났고 이제 정리를 하게 되죠. 디스트로이를 디스트로이 인더스코어 프로세서 인더스코 그룹이라고 하는 상태를 끝나서 내가 이제 계산이 다 끝났으니까 필요한 리소스들을 리턴을 하고 이제 정리를 하는 과정을 거치게 되고 이 결과를 리턴을 하면 이 함수가 종료가 되게 됩니다.

Attendees 1 21:05 여기 이제 디스트립트 덤스코 데이터 그다음에 로컬 맨멀 이제 이런 것들이 실제 일을 하는 애들이고 여기에서 보면은 distributed on스oor 데이터 같은 경우에는 실제 이제 데이터를 긁어와서 로컬 a 로컬비로 이제 셋업을 하는 그런 과정이고요. 그래서 여기서 보면은 봅시다.

Attendees 1 21:33 네 여기서 지금 어떻게 가정을 하고 있는 거지?

Attendees 1 21:55 a와 b를 이제 보드캐스트를 해서 이제 받을 거고요. 그다음에 그 받은 부분들을 이제 나의 그런 실제 나의 랭크에 따라서 실제 받은 데이터가 해당하는 부분들이 다르니까 그런 부분들을 이 조정을 해서 다시 한 번 로컬 a 로컬비를 준비를 하게 되는 과정이 디스트리뷰티 언겨 스코어 이제 데이터고요. 그리고 실제 이제 로컬 멤버에서 그런 걸 가지고 계산을 해서 그 결과를 전원 하면 최종적으로 리덕처를 하면서 다 모여가지고 최종 결과물이 완성이 되겠죠 여기서 세빈 님께서 아까 NCL과 다른 베겐들은 CPU말 쓸 건지 GPU말 쓸 건지 CPU 플러스 GPU말 쓸 건지에 대해서를 보여주는 거라고 할 수가 있을까요? 네 그렇죠. 만약에 여기서 이제 NCL을 썼다 라고 한다면은 이 실제 이제 계산을 그리고 이제 연결되어 있는 노래를 다 엠비디아 머신을 써가지고 구성을 한다라고 생각을 할 수가 있겠죠 한 왕대부의 노드들이 다른 백엔드로 동작할 수가 있나요?

Attendees 1 22:56 확실하진 않지만 저희가 실험을 해본 걸로는 다 같아야 되는 것 같아요. 이게 다르면은 뭔가 에러가 나면서 동작을 잘 안 했던 걸로 제가 들었거든요 네 확실하진 않지만 아마 그래야 되는 걸로 생각을 합니다. 다음 페이지로 넘어가겠습니다. 지금까지 이제 저희가 전반적으로 파이토치 점 디스트리뷰티드라고 하는 패키지가 어떻게 생겼고 이런 것들을 통해서 전체적인 프로그램 레기지가 mpi 개념과 거의 비슷하게 어떻게 파이토치에서는 구성이 돼 있나라고 하는 것들을 좀 살펴봤고요. 그리고 실제 그게 어떻게 동작하는지라고 하는 거를 토치 런이라고 하는 예제를 통해서 저희가 좀 살펴봤고요. 지금부터는 그러면 실제 이게 쿠다 예를 들어서 NCL을 쓴다라고 한다면은 쿠다와 어떻게 연결되어 있나라고 하는 것들에 대해서 알아보도록 하겠습니다. 김혜리 님께서 토치 점 NN 점 페러럴 점 디스트리뷰티드 데이터 패러럴과 토치 런이 어떤 차이가 있나요? 말씀을 해 주셨는데요.

Attendees 1 23:59 두 개가 하는 역할이 다르죠. 그러니까 토치 런이라고 하는 거는 그 디스트리뷰티 데이터 패러럴이라고 하는 거는 모델 병렬 모델 병렬화라고 하는 거를 이제 해주는 그런 패키지라고 생각을 하면 되고요. DDP 같은 경우에는 특히나 이 데이터 패러럴 하게 예를 들어서 트레이닝을 한다든지 할 때 이런 것들을 쓰면 되고 이런 것들 이거는 파이토치 안에서 실제 모델을 수행을 할 이런 벽렬 계산이 관용이 되어서 모델이 수행을 할 수 있도록 처리를 해주는 파이토치 내에서 이제 일어나는 일이라고 생각을 하시면 되는 거고요. 토치 런이라고 하는 거는 파이토치가 그렇게 동작을 하기 위한 환경을 프로세스 안에서 셋업을 해주는 애라고 생각을 하시면 되죠. 그니까 토치 원이 어떤 더 큰 셜이고 그 셀 안에 특정 과정이 파이토치를 실제로 활용을 해서 모델을 수행을 하는 과정이 있는데 그 파이토치가 모델을 수행하는 과정에서 원래 있는 모델을 이제 분산

Attendees 1 25:04 트레이닝이라든지 하는 그런 테스크 안에 있는 특정 테스크를 수행을 하도록 변환을 시켜서 해 주는 그런 패키지가 디스트리트 데이터 패러다이라고 생각을 하시면 됩니다. 혹시 답이 됐을까요?

Attendees 1 25:22 네 넘어가도록 하겠습니다. 아까 저희가 살펴봤던 그 디스트리뷰티드 언더스코어 맨멀 언더스코어 올 뉴스라고 한 함수로 다시 돌아가서 여기에서 실제 디바이스와 이렇게 인게이지가 되는 포인트들을 지금 제가 여기서 파란색으로 하이라이트를 해봤는데요. 아까 좀 설명을 드렸지만은 이제 내가 어떤 GPU를 쓸 건가라고 설정을 하는 그런 부분이 아까 하나 있었고요. 그다음에 내가 어떤 베겐드를 쓸 건가라고 하는 게 또한 다른 부분들이 있었고요. 이디스트리티드 멤멀리스라고 하는 거는 한번 혹시나 놀라서 말씀드리지만 파이토트가 실행이 된 이후에 이제 불려지는 그런 함수라고 생각을 하시면 되고요. 그 컨텍스트 안에서 이런 과정들을 하게 되고 그리고 디스트루티드 브로드캐스트라고 하는 것도 실제 안에 보면 스템을 통해서 NC의 백엔드를 통해서 이런 콜렉티브 커뮤니케이션 API들이 수용이 될 거기 때문에 제가 빼먹었지만 사실은 파란색으로 색출이 되어 있어야 될 부분인 것 같고요.

Attendees 1 26:33 그리고 이제 밑으로 가면은 올리디스라고 하는 디스트 콜렉티브 커뮤니케이션도 마찬가지로 이제 코다 인터페이스를 통해서 되게 되고 실제 모든 작업이 다 끝난 다음에 프로세스를 동료하는 이런 과정에서도 이제 푸다와 같이 연결이 돼서 수용이 됩니다. 굉장히 많은 부분들의 이제 푸다 그다음에 그 커뮤니케이션 시스템 뒤에 붙어 있는 니클 베겐드를 통해서 작업이 이루어지게 된다라는 생각을 하시면 됩니다. 네 이제 쿠다 디바이스 선택은 네 이 부분은 사실 저희 디스트리뷰티드 프로그램과는 직접적으로 상관이 있는 부분이 아니어서 일단 좀 넘어가도록 하고 이런 부분들은 약간 디테일한 그런 부분이어서 지금은 스킵을 하고 궁금하신 부분들은 좀 디테일한 것들을 읽어주시면 감사하겠습니다. 네 어쨌든 이렇게 해서 이제 쿠다 백엔드가 이제 이렇게 디바이스 이제 시스템 디에 이렇게 붙게 되면은 그런 것들을 활용해서 디바이스가 다른 디바이스들과 같이 병결해서 큰 모델을 처리를 할 수 있게 되고요.

Attendees 1 27:46 그리고 병렬 패키지들을 어떻게 그럼 어떤 것들을 제공하는지라고 하는 것을 좀 간단하게 살펴보고 오늘은 마무리를 하게 될 것 같은데요. 일단 파이토치가 제공하는 모델 병렬화 패키지들이 여러 가지가 있는데 그중에서 이제 많이 쓰는 게 아까 예리님께서 언급하셨던 디스트리트 데이터 페러롤도 굉장히 많이 쓰이는 택이 중에 하나고요. 이것들은 실제 모델을 잘라서 수행을 한다라기 보다는 똑같은 그 하나의 모델을 여러 벌 만들어 가지고 다른 이제 전반적으로 봤을 때 트루풋이 트레이닝의 트루풋이 올라가도록 만들어주는 그런 패키지라고 생각을 하시면 될 것 같고요. 풀리 샤드드 데이터 패러럴 같은 경우에는 큰 모델을 이제 잘 수행을 하기 위해서 큰 모델을 잘 수행을 하기 위해서 만든 그런 패키지인데 텐서 펠러도 마찬가지고요. 두 개가 동작하는 방식은 조금 다릅니다. 풀리 샤드드 데이터 패럴 같은 경우에는 실제 계산 자체가 쪼개지지는 않고요 그 대신에 모델이 굉장히 크기 때문에 모든

Attendees 1 28:52 웨이트들을 한 머신이 다 들고 있기 어려운 그런 상황에 일단은 그 모델들의 웨이트를 샤딩을 해서 쪼개놓고 그 쪼개진 거에 일부분들만 일단 맨 처음에 모델이 수행할 때는 각 디바이스들이 가지고 있긴 하지만 실제 옷을 수행하는 과정이 되면 그러면 그 옷에 필요한 웨이트들은 다른 머신들로부터 다 받아서 완결 그러니까 완결의 그런 웨이트를 구성을 한 다음에 실제 연산을 하고 그리고 다른 프로세스들로부터 불러서 받은 것들은 다시 다 버리고 그다음에 그다음 옷 그다음 옷을 실행을 할 때 다시 다른 디바이스들로부터 나머지 조각들에 해당하는 웨이트들을 다시 다 불러서 수행을 하고 하는 과정을 반복을 하는 거고요. 이렇게 하면은 굉장히 간단하게 weight들을 쪼개가지고 수행을 할 수가 있고요. 하지만 계산 자체가 나눠지지는 않고요 그래서 계산 자체가 한 레이어의 계산 자체가 굉장히 커가지고

Attendees 1 29:58 한 머신 안에 돌아갈 수 없다라고 한다면 그럴 때는 펜서 페러럴을 해야 됩니다. 그 펜서 페널럴 같은 경우에는 웨이트 뿐만이 아니라 필요하면 계산까지 이제 쪼개가지고 한 오퍼레이션의 계산을 여러 개로 쪼갠 다음에 그런 것들을 각 디바이스들이 분산 처리를 한 다음에 그걸 다시 합치는 그런 과정들이 포함이 되어 있는 좀 더 복잡한 그런 벽화를 만들어주는 그런 패키지라고 생각을 하시면 됩니다. 한 가지 재미있는 거는 솔리샤디즈 데이터 페러럴이나 텐서 페러롤이나 어떻게 생각해 보면은 모델을 바꾸는 거니까 일종의 컴파일러가 하는 일과 비슷한 일을 한다고 생각을 할 수도 있긴 한데 그렇다고 해서 실제 컴파일 과정이 구현이 되어 있지는 않아요. 그 대신에 인풋은 NN 모듈이고요. 이런 패키지들이 리턴을 하는 것도 이제 n 모듈인데 파이토치가 그러니까 파이톤이 가지고 있는 굉장히

Attendees 1 30:57 장점 유연성 중의 하나가 이런 클래스들을 동적으로 만들 수가 있잖아요. 그래서 실제로 이런 풀리 샤드 데이터 패러럴이 반영되어 있는 클래스가 해야 될 일을 함수로 정의를 해서 그걸 다시 한 번 어떤 새로운 클래스로 웹을 한 다음에 이제 그거를 리턴을 해서 새로운 모델을 돌리는 방식으로 어떻게 보면 컴팔레이션의 효과를 그런 방식으로 이제 구현을 해 놓은 것 같습니다. 저는 네 파이스톤에 아주 그렇게 익숙하진 않은데 이제 그런 방식들이 파이썬 프로그램을 하시는 분들께서는 굉장히 익숙한 방법인지 모르겠지만 저희가 이제 팀원들하고 이거 분명히 컴파일러 비슷한 일을 하기 때문에 뭔가 그래프를 만들고 뭔가 이렇게 프로그램을 트랜슬레이션을 하고 하는 그런 과정 비슷한 게 있는 거 아니야라고 해서 그런 부분들을 굉장히 열심히 찾았는데 그런 것들은 없었고요. 제가 방금 말씀드린 그런 방법대로 그렇게 트랜슬레이션이 되는 것 같은 그런 효과를 그냥

Attendees 1 31:58 네 팔점에 있는 기본적인 기능을 가지고 구현을 했더라고요. 그래서 저는 개인적으로는 굉장히 신선한 부분이었고요. 세컨셜 패러럴 파이프라인 패러럴, 디스트레드 패러럴 설명을 하지 않고 일단 스크립트을 하겠습니다. 궁금하신 분들은 참아서 한번 살펴보시면 될 것 같습니다. 세님께서 질문해 주셨는데 저렇게 돌리게 된다면 잘 골고루 들어가서 학습이 잘 되어야 할 텐데 그렇게 GPU 4대를 저렇게 100라 패키지를 쓴다면 어떻게 결과값이 한 곳으로 정확하게 보여지게 할 수가 있을 거예요. 이게 이 토치 점 디스트립티드 패키지가 제공을 하는 가장 중요한 기능이라고 생각하시면 될 것 같아요. 일단은 어떻게 분산이 되어야 되는가라고 하는 것에 대해서는 저희가 랑데뷰를 구성을 하잖아요 그 랑데뷰를 구성을 해서 월드를 구성을 하고 그 월드에서

Attendees 1 32:51 어떤 프로세스들이 몇 개가 있는지라고 하는 것들은 이제 파악이 되기 때문에 이렇게 예를 들어서 풀리 샤드 데이터 패널을 써서 저희가 웨이트를 샤딩을 한다라고 하면은 weight가 몇 개 머신에 어떻게 대표가 되어야 되는지라고 하는 것들은 그런 정보를 통해서 이제 파악을 할 수가 있고요. 그리고 실제로 제가 어떤 옥을 실행을 하기 바로 전에 그러면 분산 흩어져 있는 샤딩이 되어 있는 웨이트를 다시 한 번 모아야 된다 라고 했을 때는 제가 랭크가 몇 인지 알고 있을 거고 그다음에 그랬을 때는 그러면은 어떤 다른 조각들을 누구한테 받아야 할지도 아는 거고요. 그다음에 걔네들이 실제 어떻게 접근할 수 있을지라고 하는 거는 랑대을 하면서 저희가 티스피 스토어라고 하는 일종의 리모트로 접근 가능한 네트워크 키 밸류 스토어가 있거든요 걔한테 그런 로드들의 정보라든지 하는 것들은 다 인마 받아서 패싱을 해놓고

Attendees 1 33:51 그 정보를 이용해서 이 패키지 안에서 그 옷 자체 디스트리뷰티드 API에 있는 콜렉티브 프리페이션 옷 자체가 제 이런 동작들을 해주는 거죠. 그래서 그런 머신들에 대해서 머신들에게 메시지를 보내서 데이터를 달라라고 하면 그런 데이터들을 다 받으면 그것들을 다시 합쳐서 원본 웨이트를 이제 구성을 하게 되죠. 네 이 결과 값이 어떻게 한 것을 정확하게 모여지냐라고 하는 부분에 대해서는 텐서 페럴을 같은 경우에는 이제 그렇게 이제 리덕션을 하는 과정이 있을 거고요. 하지만 풀리 샤드드 데이터 패럴 같은 경우에는 제가 아까 말씀드렸지만은 계산 자체는 온전하게 머신 별로 그 오를 온전하게 다 계산을 하기 때문에 그런 경우에는 다시 결과 값을 한 60곳으로 모이는 것 자체는 이루어지지 않습니다. 네 두 번째로 그 부분을 잘 파악하지 못했기 때문에 로스가 올라가고 학습 향상이 안 되었던 문제가 있었던 거네요. 이거는 제가 어떤 말씀인지 잘 모르겠고요.

Attendees 1 34:54 JM 프로젝트님께서 랑대비 역할을 하는 디바이스가 따로 필요한 걸까요? 연산 요청을 받는 노드와 연산 수행을 하는 노드가 나눠진 것인지 궁금합니다. 이거는 일단 나눠져 있기는 네 합니다. 예를 들어서 이 품문을 가지고 랭크가 제로면은 랑데를 구성하고 한다든지 하는 그런 식으로 해서 따로 나눠져 있기는 하지만은 그게 어떤 머신인지 사실 상관이 없고요. 예를 들어서 랭크 제로 머신들이 그걸 하도록 설정을 해놨으면 랭크 제로가 아마 하게 되겠죠

Attendees 1 35:33 네 알겠습니다. 감사합니다. 네 실제 예제를 좀 약간 넣어두었는데 여기서 보면은 그 net이라고 하는 클래스를 정의를 해서 이렇게 이제 포드라고 하는 함수를 정의를 해서 실제 이 계산을 이렇게 하겠다라고 한다면 이걸 이제 FSD를 이제 적용을 하기 위해서는 죄송합니다. 실제 이제 랭크나 그다음에 월드 사이즈를 통해서 셋업을 하게 되고요. 그다음에 그 모델을 이렇게 할당되어 있는 뱅크의 디바이스로 이제 이렇게 설정을 하게 되고 그다음에 아까 제가 말씀드린 것처럼 FS DB라고 하는 패키지를 사용을 해서 모델을 새로운 게 반영되어 있는 모델로 만들어낸 다음에 그 모델을 실행을 하면 되죠. 이렇게 되게 간단하게 수행을 하도록 되어 있고요. 여기 이제 피겨 원의 이제 그림이 들어 있는 부분들은 제가 아까 이런 플리샤p라고 하는 것들이 오 단위로 수행을 했을 때 어떻게 동작을 하는가라고 하는 걸 말씀드렸는데

Attendees 1 36:43 그것들을 꼭 옷 단위로 할 필요는 없고 이렇게 옷을 묶어 가지고도 할 수가 있어요. 만약에 weight가 물론 한 디바이스에 넣기에는 충분하지 않긴 하지만 그렇다고 해서 매 옷별로 쪼갤 필요가 없다라고 한다면은 이거를 이제 의 그룹별로 만약에 샤딩을 하게 되면은 그러면 이렇게 커뮤니케이션을 해야 되는 빈도스가 떨어지게 돼서 전체적으로 성능이 더 향상이 되겠죠 플리샤드 데이터 패럴은 대충 이런 식으로 동작을 하고요. 그리고 그렇습니다. 네 이제 텐서 패널 같은 경우에는 이것보다는 양상이 좀 더 복잡한 게 이제 실제 계산 자체가 이렇게 쪼개져야 되는 건데 그 계산을 쪼개는 과정을 실제로 이제 자동으로 해줄 수는 없고 특정 이제 모델 레이어들에 대해서 이런 플랜이라고 하는 걸 만들 수 있고 그 플랜을 실제 이제 개발자가 설계를 한 다음에 이렇게 자를 때 플랜을 같이 이제 던져주게 되면 그 플랜대로 모델도 같이 잘라주는 과정은 이 패키지가 같이 해주도록 되어 있습니다.

Attendees 1 37:47 아마 메가트론에서 했던 그런 것들을 잘 활용을 해서 그런 것들을 이렇게 좀 더 쉽게 쓸 수 있도록 출상화를 해서 제공을 하는 게 아닌가 싶습니다. 네 지난주에는 거의 1시간 반 정도 저희가 했던 것 같은데 사실 이 디스트립티드 부분은 그렇게 내용이 많지 않아서 실제 트레이닝을 하고 하는 과정에서 일어나는 복잡함이 굉장히 크긴 하지만 실제 디스트 패키지 자체가 해주는 기능들은 비교적 간단해서 오늘은 좀 비교적 좀 빨리 끝나는 것 같고요. 네 마무리하기 전에 옹주님께서 할 때는 순서가 중요할까요?

Attendees 1 38:32 이게 순서 네 순서라기보다는 그냥 어떻게 보면은 레이어의 개념인 것 같거든요 아까 말씀드렸듯이 데이터 패러럴이라고 하는 거는 모델이 쪼개지는 건 아니기 때문에 어떻게 보면 텐서 페럴이라든지 파이프라인 같은 게 먼저 이루어진 상태에서 그렇게 쪼개져서 분산으로 처리를 하는 하나의 모델들이 여러 개열이 있다고 생각을 하시면 되기 때문에 데이터 패러럴은 그냥 기본적으로 가장 상위에 있는 거라고 제 생각에는 생각을 할 수가 있는 것 같고 그다음에 텐서 페러럴과 파이프라인 같은 경우에는 제 생각에는 어떻게 보면은 텐서 페럴을 먼저 적용을 하고 파이프라인을 하나 아니면은 파이프라인을 먼저 하고 텐서 페럴을 하나 어떻게 보면은 결과는 똑같을 수도 있을 것 같긴 하거든요. 실제 구현이 어떻게 돼 있는지 모르겠지만 왜냐하면 자르는 디멘전이 다르기 때문에 이거는

Attendees 1 39:27 좀 다를 수도 있지 않을까 생각이 들긴 합니다. 하지만 그거를 둘 다 쓰게 되면 그렇긴 하겠지만 예를 들어서 파이프라이닝만으로도 충분히 분산 처리가 효과를 다 봤다라고 한다면은 그런 센서 패러돌을 쓰지 않을 거고 해서 패러멜로 충분히 그런 효과를 봤다라고 한다면 또 파이프라이징 하지 않을 거야. 둘 중에 선택을 하긴 하겠지만 제 생각에는 자르고 하는 그런 디멘전 자체가 달라서 그 두 개 같은 경우에는 어쩌면 순수하게 상관이 없는 오퍼레이션들이 아닐까 저는 그렇게 생각하는데 혹시 다른 더 정확하게 아시는 분들이 있으면 답을 해 주시면 좋을 것 같고요. 우머님께서 봅시다. 양님께서 네 노드가 GPU라고 하면 맹크를 특정 GPU에 부여된 어떤 서브 잡이라고 보면 될까요? 노드가 지표는 아니고요 노드는 서버라고 생각하시면 돼. 코스트라고 생각하시면 될 것 같고요. 네 그리고 그 호스트 내에 예를 들어서 GPU가 4개가 꼽혀 있다

Attendees 1 40:31 라고 한다면은 그 보통 일반적으로 특히나 mbdi GPU를 쓸 때에는 GPU 하나가 랭크 하나에 해당을 하기 때문에 이 노드에 4개의 랭크가 4개의 프로세스가 생성이 되겠죠 그래서 프로세스 당 하나의 GPU가 할당이 되고 그게 랭크가 특정 GPU가 아니라 그렇게 선택된 하나의 GPU에 할당이 되어 있는 서브 잡이라고 생각을 하면 될 것 같습니다. 혹시 양님 대답이 됐나 모르겠습니다. 그리고 응원 님 많은 옷을 병렬 하는 것도 중요하지만 결국엔 데이터 디멘전이 충분히 모델을 처리하는 경우에는 디바이스 간의 데이터 전송의 오버레이드가 더 중요한 이슈가 되지 않나요? 그렇죠 네 그래서 오블 벽률화 하는 거 예를 들어서 파이프라이닝이라든지 아니면은 텐서 페러블 같은 경우가 어떻게 보면 오을 병렬화하는 그런 방식이라고도 생각을 할 수가 있는데 이런 경우에는 실제 벽렬화를 통해서 얻는 이득도 있긴 하지만은

Attendees 1 41:32 이런 데이터 전송에 대한 오버드 때문에 오히려 속도가 더 느려지는 경우가 있을 수도 있죠.

Attendees 1 41:43 그래서 예를 들어서 풀리샤디드 데이터 패럴럴하고 제 생각에 텐서 페러럴 같은 경우에는 그런 트레이드오프가 좀 있을 것 같아요. 그러니까 계산이 되게 엄청나게 커서 그걸 한 디바이스에서 하는 것보다는 여러 개 나눠서 하는 것이 더 좋다라고 할 때에는 이제 텐서 페러럴을 쓰면 되기는 하는데 그때 이제 고려를 해야 될 거는 아까 말씀드린 것처럼 그런 데이터 전송에 대한 오버레이드까지 고려를 했을 때 텐서 페럴하게 계산을 여러 개의 멋시에 나눠서 쪼개서 하는 것들이 과연 좋은지 라고 하는 거는 판단을 해야 될 것 같고 그렇지 않다라고 한다면은 그냥 풀리 샤리드 데이터 패럴을 써서 하는 것만으로도 충분한 그런 경우들이 있을 수가 있겠죠. 주님께서 서정돼서 연설을 해주는 프로그램에 대한 컴파일러가 distribute라고 하는 특성을 고려하게 되면 어떤 부분이 달라지나요? 제 생각에는 되게 중요한 질문인 것 같은데 일단 제가 한번 확인을 해볼게요. 이게

Attendees 1 42:47 예를 들어서 저희가 토치 점 컴파일을 토치 점 디스트립트와 같이 쓰는 그런 상황을 가정하고 있다고 생각을 하면 될까요? 은주

Attendees 1 43:07 아 네 그렇다고 한다면 그렇다고 한다면 일단은 토치 점 디스트리뷰트가 적용이 된 후에 그다음에 토치 점 컴파일이 된다고 생각을 하시면 돼요. 그래서 일단은 모델들이 실제 내가 돌 머신에서 돌 형태로 만들어져야 그다음에 컴파일을 해야 될 거 아니에요 그러니까 저희가 이제 토치 런을 해서 그런 것들을 다 셋업을 한 다음에 실제 파이토치가 시작을 하게 되면 그러면은 쪼개 모델을 이제 분산이 된 모델을 돌려야 되는데 그 분산이 된 모델이라고 하는 게 실제 모델의 인포스를 받아서 아까 말씀드린 이런 패키지를 가지고 변환을 해야 제가 진짜 돌릴 모델이 되는 거고 그거를 이제 토치정 컴파일을 하면 되겠죠 그럼 토치 점 컴파일을 그렇게 하게 되면 투치 점 컴파일 입장에서는 사실 콜렉티브 커뮤니케이션 옵이 들어 있는 것 자체가 그렇게 대수는 아니거든요. 그냥 특수정 품 파일이 처리를 해야 될 옷 중에 하나인 셈인 거죠. 데 실제로 이제 보면은 만약에 그런 콜렉티브 커뮤니케이션 곡들이

Attendees 1 44:17 그래프 브레이크를 만들지 않고 트레이싱이 된다라고 한다면은 이제 포함이 돼서 특정 컴파일 안에 있는 이제 FX 그래프 안에 포함이 돼서 백엔드 컴파일러로 넘어갈 거고요. 데 만약에 그게 그래프 브레이크를 일으킨다라고 한다면 그런 컬리티 커뮤니케이션 읍은 그냥 호스트에서 이거 모드로 수행이 될 거고 그리고 에플렉스 그래프는 그전에 그다음에 그 이후로 끊겨지기 때문에 그런 옷 자체를 컴파일 할 때는 보지는 않겠죠. 저희 팀에서 한번 둘러봤을 때에는 그런 커뮤니케이션 컬렉트 룩들이 그래프 안으로 들어가는 것 같고 그럴 경우에는 백엔드 컴파일러에서 걔를 어떻게 처리할까라고 하는 것들은 고민을 해야 되긴 하겠지만 그게 이제 다른 옷들을 처리하는 거 하고 제 생각에는 크게 다르지는 않은 것 같습니다. 네 용주님께서 하신 질문이었고요. 그다음에 차주영 님께서 하신 질문이

Attendees 1 45:13 글루나 NCL mpi와 같은 통신 라이브러리들은 노드에 있는 GPU 스피유 간 데이터 통신을 위한 라이브러리인가요 아니면 노드 간 통신도 모두 포함되어 있는지 궁금합니다. 네 되게 좋은 질문인 것 같아요. 이거는 둘 다 포함을 하는 거죠. 그러니까 콜렉티브 커뮤니케이션 오이 불러주는 입장에서는 내가 다른 프로세스들과 통신을 해야 된다라고 하는 것만 알고 있지 그것들이 같은 머신에 있는 다른 프로세스인지 아니면 그 다른 노드로 가야 되는 건지는 사실 모르거든요. 하지만 실제 콜렉티브 커뮤니케이션 API가 제 호출이 되면 그 안에서 내가 지금 타겟으로 하고 있는 다른 프로세스가 같은 노드 안에 있는 건지 아니면 밖에 있는 건지라고 하는 것들은 판별을 할 수 있고 그런 경우에는 다른 방식을 통해서 통신을 할 수도 있겠죠. 다에 선원님께서 FSD 동작에 대해서 더 질문을 드려도 될까요? 분사 처리 목적 자체는

Attendees 1 46:16 큰 연산을 나눠서 따로 동시에 처리하는 것 같은데 FSDP의 경우에는 연산 전에 결국 언차이징을 한다는 점이 이해가 되지 않습니다. 그 이런 경우에는 어떻게 생각을 하시면 되냐면 예를 들어서 HBM을 쓰고 있는 각 GPU마다 메모리가 10기가밖에 없다고 생각을 해 봅시다. 네 10기가밖에 없는 그런 상황이고 그런데 전체적으로 모델 자체는 웨이트가 40기가바이트예요. 그러면 그 웨이트가 DP 안으로 들어갈 수가 없잖아요. 그쵸? 네 그런 경우에는 방법이 몇 가지가 있는데 하나는 그냥 호스트가 그걸 다 들고 있어도 괜찮아요. 호스트가 40기가바이트의 웨이트를 다 들고 있고 필요할 경우에는 호스트가 이제 지표한테 이런 것들을 나눠주는 것도 가능하겠죠 네 또 다른 방법은 그런 것들을 호스트가 가지고 있는 게 아니라 각 GPU들이 다 분산해서 가지고 있는 거죠 네 가지고 있고 예를 들어서 GPU에서 GPU로 가는 커뮤니케이션이 훨씬 더 효율적이다라고 한다면은 그 데이터를

Attendees 1 47:30 호스에서 들고 오는 것보다는 더 빠르게 수행을 할 수가 있겠죠. 에스피 같은 경우에는 이제 그런 경우에 실제 웨이트 자체를 더 빠르게 컬렉트를 하는 이제 방법으로 이 하다가 한 머신 안에 다 차지 않으면 어쨌든 외부에서 들고 와야 되는데 그런 경우에는 이제 그렇게 GPU들로 예를 들어서 이 분산을 시켜 놓은 상태에서 갖고 오는 게 더 빠른 경우에는 방금 제가 말씀드린 방식으로는 활용을 하면 됩니다. 네 해찬 님께서 질문하셨는데 토치점 컴파일과 디스트리뷰트가 따로따로 일어남으로 해서 노츠는 옵티마이제이션 오픈 스트트에 대해서 아는 바가 있을까요? 제 생각에는 분명히 그런 일이 있을 것 같기는 한데 일단 뭐 어쩔 수 없는 것 같고요. 그러니까 만약에 그렇게 되지 않기 위해서는 컴파일과 그다음에 게 분산 모델을 표기는 것들을 다 하나의 프레임으로 다 넣어서 하나의 문제를 만들어서 풀어야 되는데 과연 그럴 필요가 있을까 생각이 좀 들긴 하거든요

Attendees 1 48:33 네 딱히 떠오르지 않고 저는 그냥 너무 문제가 커서 그걸 그냥 따로 풀어야 될 것 같긴 한데 이게 이제 문제가 되는 경우가 어떤 게 있을까라고 하는 거는 사실 깊게 고민을 해 보지 않아서 지금 생각이 나지 않습니다. 석수님께서 많은 서비스들의 대용량 제 분산 처리를 하드 리스트 같은 것을 하고 있는데 파이토치에서는 mpi 형태를 선택을 한 이유가 있을까요?

Attendees 1 49:04 하드비나 맵 미디스 같은 경우에도 저는 mpi랑 크게 다른 것 같진 않거든요 그 미디스니까 그리고 그런 머신들이 키워드 메모리를 가정을 하고 있지는 않은 거고 근데 뭐 굉장히 많은 종류의 다른 커뮤니케이션 컬렉티브를 이제 구현을 했다라고 하기보다는 거기서 이제 필요한 몇 가지만 구현을 했고 그 형태는 저는 크게 봤을 때는 mpi에서 구현을 한 거랑 크게 다르지 않을 것 같다는 생각이 들기는 하거든요. 제가 하드비나 멜 리비스가 실제 어떻게 구현되어 있는지는 잘 모르겠지만은 저는 그렇게 생각합니다. 혹시 답을 아시는 분 계신가요? 그러니까 제가 그렇지 않게 생각을 한다라고 하는 이유는 카드비나 맵 리듀스에서도 어떤 데이터를 처리를 하는 데 있어서 이런 크로스트에 포함이 되어 있는 모든 머신들이 다 똑같은 메모리 스페이스 안에 이제 접근할 수 있는 쉐어드 메모리에 되어 있다라고 가정을 하고 뭐 하는 것 같지는 않거든요

Attendees 1 50:06 하드 메모리 뉴스에서 사실 이렇게 분살 처리를 하는 데이터들은 온 메모리 데이터가 아니라 아마 스토리지에 저장되어 있는 가상 일 가능성도 크고 해서 제 생각에는 정확하게 매핑은 되진 않긴 하지만 실제 mpi 회어체랑 크게 다르다고 생각할 필요는 없는 것 같긴 합니다. 네 이 정도까지 일단은 질문은 제 생각에 받도록 하고 이렇게 해서 오늘 일단 디스트리드는 간단하게 좀 다뤄봤고요. 네 그리고 여기 준나 님께서 손을 들고 계신데 혹시

Attendees 1 50:46 그래서 제가 아까 말씀드렸던 것처럼 이렇게 파이토치 안에 이제 기본적으로 들어 있는 주요한 기능들에 대해서는 저희가 5주에 걸쳐서 다시 한번 확인을 해 봤던 것 같고 이제 다음 주에는 제가 아까 말씀드린 것처럼 파이토치만으로 해결되지 않는 그런 규제는 그럼 어떻게 하느냐라고 하는 부분들을 한 시간 정도 해서 다루게 될 것 같습니다. 여러 가지가 있긴 하겠지만 제 생각에 파이토치랑 가장 직접적으로 관련이 있는 부분이 밑으로 보면은 커스텀 코널들 예를 들어서 기존 오브로 커버가 되지 않는 그런 새로운 오이 필요한 경우에 커스텀 커너를 추가를 할 수도 있고 아니면 파이토치에서 제공하고 있는 오의 성능이 부족해서 오의 인터페이스는 그대로 유지를 하지만 새로 하고 싶다 라고 한다면은 뭐 그런 경우에도 실제로 커피 코너를 사용할 수 있긴 하겠죠 네 뭐 이런 그런 경우들이 있을 거고요. 그다음에 이제 그거를 작성을 하는 그런 방법들에 대해서도 일단 엠비디아 지표를 가정을 했을

Attendees 1 51:48 후다나 이런 미디어가 제공하는 그런 방법들을 사용할 수도 있고 아니면은 이제 트리트도 커스텀 코너를 작성하기 위한 렌지지를 또 활용을 할 수 있어서 이런 것들에 대해서 한번 살펴보면 좋을 것 같다는 생각이 들었고요. 또 이제 다른 하나는 어떻게 보면은 8조치보다 더 윈 레벨에 있는 그런 프로젝트라고 할 수 있는 VLM을 한번 다뤄보고 싶었어요. LM이라고 하는 컨텍스트 내에서 이제 VLM이 굉장히 중요한 그런 인플런스용 서빙용 백스로 자리를 잡고 있는데 VLM이 가지고 있는 전체적인 구조 그리고 VLM이 제공하고 있는 그런 최적화 기능들 그리고 그런 최적화 기능들을 구현을 하기 위해서 이 파이토치에 있는 기본적인 옷만으로는 커버가 되지 않기 때문에 VLM에서 이제 이런 식으로 커스텀들을 구성을 하면 이런 최적화 기능들을 할 수 있어라고 하는 셋을 정의를 해놓은 게 있거든요. 그러니까 그런 셋이 어떤 것들이 있는지 이런 것들에 대해서 한번 살펴보면 좋을 것 같습니다. 네 이렇게 해서

Attendees 1 52:50 오늘 준비한 것들은 다 끝났고요. 지금 아까 어느 분께서 질문을 하신 것 같아서 질문을 이것만 답을 하고 오늘 마치도록 하겠습니다. MVCC 같은 컴파일러는 디스트리뷰티드를 고려해서 설계가 됐나요?

Attendees 1 53:14 제가 아주 확신 없긴 한데요 제 생각에는 아닌 것 같아요. 그러니까 그러니까 MVCC로 컴파일 되어서 나온 커널은 파이토치 수준에서 봤을 때는 그냥 커널 하나거든요 근데 그 커널이 5배에 해당한다라고 생각하면 그냥 그거는 특정 GPU 디바이스를 하나를 써서 해야 되는 계산인 거고요. 근데 그런 것들이 컬렉티브 커뮤니케이션에 의해서 배포가 된다든지 아니면은 이제 다시 합쳐지는 과정이라고 하는 거는 아까 제가 말씀드린 스탠디에 있는 옷들을 이용해서 하는 거고요. 그 스탠디에 있는 옷들은 그 하나하나가 어떻게 보면 또 어쩌면 만약에 GPU를 통해서 뭔가 이루어져야 한다고 하면 그 하나 하나가 또 다른 커널이라고 생각을 할 수가 있을 것 같거든요. 그래서 그거는 제 생각에는 분리가 되어 있는 거라고 저는 생각이 듭니다. 근데 제가 100% 확신은 없습니다. 그리고 그다음에 선호 님은 대용장 데이터 처리에 초점을 뒀습니다.

Attendees 1 54:29 네 그렇긴 한데 하드 하드분 제 생각에는 그 키 디스트리뷰션 포인트가 메모리는 아니지 않나요? 저는 디스크에 있는 데이터를 들고 와서 계산을 하는 게 하드웨어 전체적인 계산 플로라고 생각을 했는데 틀릴 수도 있어요. 그런데 mpi는 시작점이 디스크는 아니고요. 이제 메모리에 다 데이터가 일단 로딩이 되어 있는 상황에서 수행을 하도록 되어 네 그런 의미에서 봤을 때에는 뭔가 이렇게 쉬어드 메모리를 가정을 하고 있지 않기 때문에 오픈 MP보다는 사드은 mpi에 더 가까운 것 같고 그리고 하드에서 하고 있는 맵 리즈스 같은 게 제 생각에는 mpi의 올 리즈스랑 어떤 점이 다를지는 그러니까 개념적으로 봤을 때 어떤 점이 다른 모델적인 측면에서는 어떻게 다를지는 잘 모르겠습니다. 이 부분은 제가 알고 있는 게 사실 좀 제한적이어서 제가 선생님께 더 좋은 대답을 해드리기는 어려울 것 같고 요것만 하고 마지막으로 끝낼게요. 이제 은수 님께서 AMD나 리벨리온 같은 mfu나 GPU의 컴파일러도

Attendees 1 55:36 디스트리뷰트를 고려하지 않을까요? 제가 ED는 잘 모르겠고요. 이 리벨리온 같은 경우에는 저희 컴파일러 자체가 샤딩을 할 수 있는 기능들이 있어요. 그래서 샤딩을 할 수 있고 그런데 저희가 그 샤딩 기능을 예를 들어서 실제 다른 노드로 넘어가는 계산까지 활용할 건가라고 하는 거에 대해서는 아마 그렇지 않을 것 같다는 생각이 좀 들기는 하거든요. 다른 디바이스 같은 경우에는 AMD 같은 경우에는 어떻게 하고 있는지는 잘은 모르겠습니다. 네 오늘 이제 해주신 질문은 이 정도로 제 생각에는 마무리를 하면 좋을 것 같고 맞습니다. 오늘 제가 오프라인 모임을 못 하게 된 거는 네 다른 질문 하나가 하나만 더 여쭤봐도 될까요? 최근 모델 구조가 트랜스폼으로 구조되고 있는데 그럼에도 불구하고 커스텀 코너에 대한 수요가 계속 있지 이게 되게 굉장히 재미있는 질문인데 이 특히나 어텐션 같은 경우가

Attendees 1 56:35 꽤 오보이드가 있거든요 어텐션이라고 하는 것들이 실제 이 컨텍스트 랭스가 점점 길어지면 길어질수록 가장 시간이 오래 걸리고 복잡한 부분이 이제 어텐션이고요. 네 그래서 이제 어텐션을 어떻게 가속을 할까라고 하는 기술만 해도 굉장히 다양하게 나오고 있어요. 네 그런 측면에서는 일단 커스텀 코널 작성에 대한 수요는 제 생각에는 d램 어세스를 줄이기 위한 부분들도 있고요. 그다음에 특히 이제 MB디아 DP 같은 경우에는 특히나 최근에 엠비디아가 굉장히 공격적으로 최적화를 위한 새로운 하드 피처들을 넣고 있고 그런 게 나올 때마다 그런 것들을 이제 잘 활용을 하려면 커널이 계속해서 바뀌어야 되긴 하거든요. 그래서 똑같은 기능을 하는 커널도 새로운 버전의 GP가 나올 때마다 다시 작성을 해야 되는 니즈가 있을 수 있어요.

Attendees 1 57:25 예를 들어서 이제 프레시 어텐션 같은 경우에도 버전 원이 있고 버전 2가 있고 버전 3가 있지만 이들 이제 어떻게 보면은 실제 이제 계속 엠비디어 뷰가 업그레이드가 되면서 거기에 맞춰가지고 다시 작성했던 측면들이 있기는 하거든요. 정말로 제 생각에는 이제 질문을 금방 받아야 될 것 같고 네 오늘 다들 잘 유익한 시간이 됐으면 좋을 것 같고요. 또 다음 주에 다시 한 번 만나면 좋겠습니다. 다들 한 주 잘 보내시고 다음 주에 또 뵙도록 할게요. 감사합니다.