저희 부서는 컴퓨팅 시스템 연구 기업이라는 부서고요. 여기서 그 컴퓨팅 자원과 스토리지 자원을 가상화하고 성능 효율화하는 연구들을 지금 하고 있습니다. 저희가 그 AI GPU를 이용한 AI 플랫폼 기술을 연구한 거는 한 5년 정도 전부터 진행을 했었고요. 딥러닝이 생기고 나서 저희가 GPU 기술을 연구했고 그 뒤로 지속적으로 계속 딥러닝 기술 연구를 하고 있습니다. 관련해서 오늘 제가 조금 더 지표를 쥐어짜서 잘 쓸 수 있는 기술들을 소개시켜 드리려고 하는 거구요. 어 오늘 말씀드리는 부분들을 저희 회사에서 만든 제품들에 대해서 소개시켜 드리는 건 아니구요. 연구소의 그 200여 명의 AI 연구원들이 계신데, 그분들을 위한 플랫폼을 자체적으로 운영을 하고 있습니다. 그건 상품이랑은 상관없고 그냥 내부적인 AI 연구자들의 니즈만 반영한 예 내무용 클러스터라고 생각하시면 돼요. 그래서 오늘 사실은 저는 에메롭서로서 AI SCIENTIST들 분과의 트러블이나 이런 애환을 좀 소개시켜드리고 싶었는데, 녹화를 한다고 하셔가지구 그런 부분 제외라도 명백하게 진행하도록 하겠습니다. 네 저희 GPU 플랫폼에 대해서 대략적으로 소개시켜드리면, 그런 것 같습니다. 사실 처음 시작한 건 2018년이었는데요. 어느 정도 완성되고 나서 그때 저희 연구소를 돌아보니까 저희 연구소에서 GPU 운영을 이렇게 하고 있었습니다. 프로젝트당 지표 서버 4대 혹은 개인 당 1대 혹은 2명 당 1대 이런 식으로 운영을 하고 있었습니다. 그래서 몰래 AI 사이언티스는 몰래 에이전트를 깔고 사용률을 취합해서 느낄 수 없을 정도로 참혹한 CPU 사용률이 나왔습니다. 오래 해 보신 분들이 10% 이하의 GPU 사용률이 나왔습니다. 그래서 이걸 빌미로 AI 연구 하시는 분들의 모든 서버를 뺏어서 COVENTIS 클러스터로 연결을 했습니다. 단지 연결했다는 것만으로 GPU 사용률이 20%로 올라갔습니다. 왜냐면, 그전에 레지넷 1번 이거는 다승 거고, 레지넷 2번은 꽁지 거고, 이렇게 정해져 있었는데, 그거는 디스클러스터 하고 나니까 그냥 서버가 남았나 안 남았나만 보는 거지 어느 서버가 뜨는 건지 이런 거 없어진 겁니다. 자 그러면 아까 포스트 오퍼레이션 말씀하셨는데 포스트 오퍼레이션 입장에선 되게 좋은 거죠. 사용률이 2배 넘게 올라갔으니까 비용이 절반으로 줄어든 겁니다. 근데 AI 사이언티스트 입장에서는 자기 서버를 뺏긴 거고, 피크 타임에 내가 쓰고 싶은 만큼 쓸 수 없어지게 된 겁니다. 그래서 단지 그냥 포스트를 줄이기 위한 노력뿐만 아니라 AI 사이언티들이 쓰기 편하게 만들어 드려야 했습니다. AI 사이언티스트들이 제일 친해야 되는 게 도커지만 제일 못 쓰시는 게 도커입니다. 아직까지도 잘 못쓰고 계신데요. 당시에는 서버 20대가 있으면 저 같은 MLOPSER라는 사람들이 서버 1대에 1대의 파이썬 버전을 기억하고 있다가 필요한 패키지를 손으로 설치하고 분생 학습을 하는데 3번에서만 안 돌아요. 이런 일들이 되게 많았습니다. 그걸 저희가 도커라이즈를 다 지원을 해드렸고요. 사실 시스템을 통해서 도커 빌드하고 자체 도커 레지스티를 운영하고 이런 걸 했는데 결국 그 도커를 만든 능력이 안 되시는 분들이 많아서 커스텀하게 지원을 해 드리고 현재는 연구를 통해서 자동으로 빌드할 수 있는 시스템까지 갖췄습니다. 이게 저희 쪽 AI 사이언티스트리 플랫폼에 만족하게 된 계기가 아닌가라는 생각이 들고요. 특히 코벌 인티스 1.26 넘어오면서 도커 심리 EOS 되면서 코벌 인티스트에 더 이상 도커를 쓸 수는 없습니다. 그러면 에일 사이언티스들이 컨테이너 디라는 생소한 거에 적응을 해서 컨테이너 디 명령 너드 컨트롤 이런 거에 적응을 해야 되는데 그건 더 끔찍한 일이었거든요. 그런 부분에 대한 문제점들을 저희가 다 해결해 드린 거라고 볼 수 있습니다. 그리고 하나 더해서 여기 보시면 클러스터가 2개로 나눠져 있는데요. 인터렉티브 클러스터는 컴퓨터 노트북 실행할 수 있는 그 SSH나 GPTOMOT를 실행할 수 있는 개발 환경이라고 보시면 됩니다. 그래서 색깔도 연하고 GPU가 없는 노드들도 있죠. 근데 저희가 아까 말씀드린 것처럼 그 GPO 서버 점유율이 10프로 이하다 라고 말씀드린 제일 큰 원인이 저기에 있었습니다. 개발할 때는 GPO 쓰지 않습니다. 대부분 코드 보고 디버킹하고 이럴 때는 GPO 없어도 내 코드를 문법 체크하고 돌아가는지 확인까지는 가능합니다. 거기에 GPO 서브를 붙잡고 있어서 문제였던 거구요. 그걸 분리해서 인터렉티브 클러스터는 GPO가 없거나 아주 작은 GPO만을 쓸 수 있도록 구성을 했습니다. 밑에 보이는 것처럼 네트워크 고도 이더넷으로 저비용 이더넷으로 구성을 했고요. 반대로 V-BACK H100 이렇게 고성능 지표로 구성된 부분을 인피니베드 네트워크를 구성을 했습니다. 그 엔비디아 그러면 수퍼파드라고 하는 고성능 지표 클러스터가 있는데요. 그거와 동일한 수준으로 인피니 밴드를 4채널 플랜 채널 구성을 했습니다. 그럼 어떻게 되냐면 조직에서 큰 모델을 돌릴 필요가 생깁니다. 예를 들면 이번 주겠죠. 이번 주에 뭐 라마 쓰리 45비 모델이 발표가 된 건데 어느 높으신 분이 와서 우리도 그거 한번 돌려보자라고 했을 때 각각의 AI 사이코티스티 2대 4대 이렇게 점유하로 작동할 수가 없는 일이었습니다. 근데 인기 있는 클러스터를 구성하고 나서는 그런 것들을 해볼 수가 있게 된 겁니다. 거기에 저희 AI 사이언티스트 분들이 만족도가 되게 높아졌어요. 우리도 해볼 수 있다. 이런 생각들을 하기 시작했고, 진입 장벽을 좀 낮출 수 있지 않았나 그런 생각이 듭니다. 네 이런 히스토리 끝에 저희가 GPM 플랫폼을 구성을 했습니다. 쉽지는 않았습니다. 일단 그 저희 삼성 SPS가 리액터 센터를 많이 가지고 있는데, 하필 AI가 터지기 직전까진 친환경이 이슈가 되면서 충청 같은 데이터 센터의 경우는 랩 1대에 공급되는 전원이 GPU 1대에 필요한 전원의 반도 안 됐습니다. 그래서 그런 데이터 센터에다가 GPU 서버를 넣으려면 랩 2대 놓고 서버는 1대만 들어갑니다. 요렇게 해야 되는 상황이었습니다. 그래서 저희가 별도 공간에다가 전력공사를 하고 랩도 지표수업 되게 무겁거든요. 랩도 별도 랩 구매하고 그래서 하나하나 한땀 한땀 지표 클러스터를 구성을 했습니다. 그리고 그 위에 코모네티스 설치하고 코모네티스에서 인피니벤디 네트워크를 가능하게 하려면 별도의 CNI가 필요합니다. 위브 같은 걸 처음에 썼었는데 간편하니까 위브는 인피니밴드를 지원하지 않고 최소한 캘리코 이상의 CNI를 사용해야 되고 그다음에 스토리지 오케스테이션도 필요한데 스토리지를 대충 이제 많이 써보신 분들 아시겠지만, HDD용 HDD가 달려있는 NAS에서 학습을 하는 게 끔찍한 일이야 최소한 SSD나 FM의 NAS가 달려 있어야 GPU 시간은 오히려 줄여줄 수가 있습니다. 최근에 군산 스토리지나 레카 같은 것들도 성능을 굉장히 높일 수 있는 방법이고요. 그러면 방금 말씀드린 것만 해도 3가지에 해당하는 스토리지들이 있습니다. 이걸 호모네틱스해서 안정적으로 돌아가게 하려면 오케스트레션 기술들이 필요하고요. 그 외에 이제 스케줄러나 모니터링 같은 포메이션을 기본적으로 제공하는 기능 위해 저희가 쿠브플로 오픈 소스를 베이스로 플랫폼 새로 구축을 기회가 되면 다음에 또 기회가 되면 트레이닝 기능이나 이런 임퍼런스 기능에 대해서 잘하는 것들이 좀 있는데, 그건 다음에 설명드리기로 하고요. 오늘은 이 상황에서 저희가 GPU 자원을 최대한 아껴 쓰기 위한 스케줄링 관련 기법들을 소개해 드리려고 합니다. 네 저희 오늘 메인 주제는 AI 옵티마이즈드 스케줄러입니다. 일단 옵티마이즈 스케줄러가 왜 필요하냐라는 의문이 들 건데 오른쪽에 있는 GPU 그래프 2가지를 보시면 전통적인 IT를 하신 분들 저도 이제 기억력이 20년 좀 더 돼가는데 전통적인 IT를 하신 분들 아래쪽에 있는 그래프가 마음에 드실 거예요. 로드밸런싱이 괜찮네 잘되고있네 좋아서 앞두기를 집중 만들고 있고 하지만 GPU를 사용하는 경우는 다릅니다. 왜냐면, MVDI나 AMD가 만들어 놓은 아스텍처는 서버 내에 PCI나 MV 링크를 사용했을 때 네트워크 성능이 극대화되기 때문입니다. 그래서 한 서버 내에 최대한 많은 GPU를 사용하고 그게 불가능할 경우에 인피니 밴드의 같은 외부 네트워크를 통해서 다른 GPO 서버와 연결해야 됩니다. 그러니까 위에 보시는 것처럼 서버 내에 GPU를 풀로 다 쓰고 나서 그다음에 안 되면 다음 서버로 넘어가고 이런 스케줄링이 필요하구요. 그리고 그것 때문에 여기는 이제 6개씩 되어 있는데요. 6개의 작업을 던지면 제일 효율적이라고 했는데 BT 그래프에서 들어갈 자리가 없죠 1개 2개 3개 이런 것들을 차지하고 있기 때문에 그걸 다 모아서 실행하게 되면은 위에처럼 최소한 3~4개 이상의 서버가 남아있을 수 있게 됩니다. 그러면 고성능의 학습 작업을 구동할 수 있게 되는 것이죠. 그리고 지금 말씀드린 것처럼 저희는 뭐 200명 정도의 AI 사이언티를 동시에 사용하는 플랫폼입니다. 그러니까 사용자들이 정확히 알고 있습니다. 내가 먼저 실행했는데 옆에 사람의 작업이 먼저 실행됐네라는 걸 알고 있습니다. 근데 쿠버네틱스 기본 스케줄러 조직이 아까 말씀드린 것처럼 HA 구성을 매 5초마다 계산을 합니다. 그 노드 셀렉터에서 어떤 노드의 어떤 자원이 남아 있고 이 잡이 요구하는 자원을 계산해서 최적 모드로 할당하는 걸 하게 됩니다. 코보네틱스는 작업에 소중한 관심이 없습니다. 그러다 보니까 GPU를 1장 쓴 사람이 있고 8장 쓴 사람이 있는데, 8장 쓴 사람은 작업 그 작업이 계속 실행이 안 되고 있다가 한정센터는 먼저 실행되고 이런 경우가 발생을 하게 됩니다. 그래서 페어하게 모든 자원을 효율적으로 잘 사용하기 위해서 스케줄러 기술이 반드시 필요했었습니다. 저희는 2가지 방식으로 접근을 했습니다. 퓨리스틱하게 접근을 먼저 해봤습니다. 어 제일 먼저 그 뒤에서 조금 더 설명을 드리겠지만, 단순히 어떤 스케줄링이 되지 않으면 검사 마치 정확하게 실행도 안되는 경우가 있고요. 그다음에 쪼끔만 더 신경 쓰면은 전체 서버도 효율이 확 올라가는 스케줄링도 있습니다. 이런 것들을 저희가 개발하고 운영하면서 겪은 걸 바탕으로 휴리스틱 하게 만들어 놓은 알고리즘이라서 큐리스틱 페이스라고 말씀드렸구요. 근데 이러한 휴리스틱을 낭만 실행에도 더 이상 개선되지 않는 부분들이 있었습니다. 그래서 DJS나 솔로 같은 논문 기반으로 저희가 연구를 해서 강화 학습 기반의 스케줄러를 개발했습니다. 네 먼저 휴지스틱 스케줄러들에 대해서 설명을 드리겠습니다. 분산 학습 작업을 실행하다 보면 여기에 큐에 그 분산 학습 노드 4개가 필요한 잡시가 얘기를 하고 있습니다. 근데 기본적인 스케줄러로 이 작업을 실행하게 되면 스케줄러가 봤을 때 첫 번째 노드에 GPU 2개가 비어있고 두 번째 노드의 GPU 하나가 비어 있으니까 이 3개를 먼저 실행해 버립니다. 근데 분산을 해보신 분들은 아시겠지만, 워커 4개가 동시에 실행돼야 되는데 2개만 먼저 실행되면 이 작업보다 100% 실패합니다. 그래서 아래 그림과 같이 빈 공간이 있더라도 작업이 들어가지 않고 4개의 모든 작업이 들어갈 수 있는 상태에서만 실행해 주게 하는 게 갱 스케줄링이라는 기법입니다. 이건 사실 지금 너무 당연하실 수 있는 부분인데 모든 스케줄러가 가장 기초적으로 가져야 될 기법입니다. 네 다음은 P4입니다. 앞서 말씀드린 것처럼 페어니스 얘기를 말씀드렸었는데 가장 페어한 방법이 P4죠 먼저 실행한 거 먼저 구동할 수 있게 해주는 기법입니다. 가장 페어 하지만 보시는 것처럼 아래쪽에 붉은색으로 표시된 영역은 남아있는 GPU를 사용하지 못하고 있는 상태인 겁니다. 사용자들의 작업이 몇 개의 GPU를 요구하느냐에 따라서 잡 2는 4개를 그대로 하고 잡 쓰리는 1개밖에 요구하지 않지만 순서를 지키기 위해서 다 대기하고 있는 상태인 거죠. 네 그다음은 림페킹입니다. 여기 위에 기본 스케줄은 아까 우리가 흔히 알고 있는 HA 알고리즘처럼 최대한 노드의 분산을 시킨다고 말씀을 드렸죠 그러면은 그 잡시와 디가 지표 1개짜리 잡시와 디가 대비하고 있을 때 잡시는 지표가 제일 많이 남아있는 첫 번째 노트에 돌아갑니다. 그럼 D는 들어갈 데가 없어지는 것이죠. 혹은 아까 게임 스포셜링 알고리즘에서 말씀드린 것처럼 쪼개져서 들어가서 비효율이 발생을 하게 됩니다. 이때 빈티킹 스케줄링이 되게 되면 잡시는 HL을 위해서 널널한 서버에 들어가는 게 아니라 비어 있는 공간을 찾아가서 B 노드를 채우게 되고 그러면 나머지 A 노드 3칸에 남아 있는 잡 D가 실행될 수 있게 됩니다. 이 알고리즘도 되게 중요한 것이 아까 말씀드린 것처럼 우리가 에이백인 ID 시냅 지표를 쓰시게 되면 GPU 내에는 엔브레이크로 연결된 8장의 GPU들이 있습니다. 이 8장의 GPU들이 그 이미지 비전 모델들 레지넷 같은 비전 모델들이 1장씩 득표율을 차지해서 8장을 못 돌리는 것만큼 아쉬운 부분이 없거든요. 그래서 빅패킹 알고리즘을 저희가 적용을 했구요. 네 그리고 백필 알고리즘입니다. 아까 P4에서 아쉬웠던 부분이 앞에 남는 부분이 있는데도 실행이 안 되는 부분이 있다고 말씀드렸습니다. 최대한 공정성을 유지하면서 그러니까 잡초가 첫 번째 T1에 이제 남아있는 공간에 들어가더라도 잡 1의 원래 실행돼야 되는 시간에 대한 걸 지켜주는 방식이 백필이고 그래서 우선순위가 뒤에 있지만 다른 작업에 영향을 미치지 않는다면 먼저 실행시켜주는 기법을 백필이라고 합니다. 마지막 휴리스틱으로 멀티큐를 적용을 했습니다. 멀티큐를 적용한 이유는 앞에 리플과 목표에서 말씀드린 것과 좀 유사한데 저희는 되게 많은 작업들이 동시에 실행되다 보니까 GPU 1개가 필요한 작업과 8개가 필요한 작업이 섞여 있습니다. 근데 하나짜리가 돌고 있으면 8개짜리가 전체 Q를 블로킹하고 있죠. 그 뒤에 1개 2개짜리 작업들은 8개 때문에 실행이 되지 않습니다. 이때 1개 2개 4개 이렇게 적은 GPU가 필요한 Q를 별도로 만들고 8개짜리가 돌아간 Q를 따로 만들면 8개는 8개짜리끼리 경합하고 나머지 1개 2개 4개는 따로 경합을 해서 실제 주간 평균 대기 시간을 확인해 보면 32시간에서 5시간으로 확 줄어든 걸 확인할 수가 있습니다. 이렇게 저희가 히니스틱한 기법들을 적용해서 여기까지만 해도 되게 큰 개선을 했는데요. 사실 저희도 딥러닝의 시대가 금방 바뀔 줄 알았습니다. 패러다임이 LM이 나오고 하면서 버트가 나오구 버트 지나서 큰 LN형이 나오기 전까지만 해도 이제 분산 학습 안 되는 노드들은 필요가 없겠다라고 생각을 했었습니다. 근데 실제 LLLE 시대가 괜히 사실 더 복잡해졌습니다. 그전에는 우리가 흔히 알고 있는 이름의 모델들만 처리할 수 있으면 됐는데 지금 하루가 다르게 처음 보는 규모의 처음 보는 이름의 모델들이 쏟아져 나오고 있습니다. 그래서 저희는 연구소다 보니까 그런 모델들을 다 무시할 수가 없습니다. 알고는 있어야 됩니다. 그래서 다양한 모델들을 다양한 크기로 다양한 데이터셋에 적용해서 돌려봐야 됩니다. 그러다 보니까 LM 시대가 되고 나서 SN들과 엮이면 SLM들과 엮이면서 더 복잡한 시대가 돼서 더 효율적으로 아 그렇게 시대는 복잡해졌지만 GPU 개수는 늘려지지가 않습니다. 지금 구하기도 힘들거든요. 주문하면 6개월 정도 걸리고 그래서 남아있는 GPU를 최대한 쥐어 짜서 써야 되는 상황이 됐습니다. 그래서 여기에서 우리가 강화학습 기법을 적용해서 CESLING하면 성능이 올라가지 않을까? 하는 연구를 진행을 했습니다. 결과적으로 성능이 훨씬 많이 올라왔습니다. 강화학습이란 에이전트가 현재 엔바이러먼트의 상태를 보고 어떤 액션을 취하구 그 액션에 따라서 리워드를 받으면서 액션에 대한 개선을 학습하는 기법을 말합니다. 주로 게임이나 길 찾기 같은 어려운 독적 알고리즘을 해결하는 데 많이 사용되구요. 저희는 이런 학습 작업들 그리고 머신의 상태 스케줄링 문제를 해결하기 위해서 광화학습을 적용해 봤습니다. 강화학습 스케줄이 컴포넌트는 이었습니다. 여기 제일 왼쪽에 시뮬레이터 또는 머신이라고 돼 있는데요. 실제 환경에 있는 머신들이 가지고 있는 상태와 머신에 들어가 있는 작업 잡 리스트 학습잡 리스트가 있고 그리고 머신이 없어도 강화 학습을 할 수 있는 시뮬레이터가 있습니다. 이 시뮬레이터를 통해서 스케이트를 받으며 아래 스케줄러는 스케줄링 스팀을 결정하고 그 스케줄링을 실행한 이후에 이빌레이트를 통해서 우리가 최종으로 타겟팅 하는 슬로우 다운을 스코어링 합니다. 그리고 그 스토어링 결과에 따라서 추가로 아래 스케줄 학습을 진행합니다. 그래서 지금 이제 저희가 확정되지 않은 성능이 입증되지 않은 스케줄들을 바로 라이브에 투입할 수가 없기 때문에 시뮬레이터가 되게 중요했고 시뮬레이터는 이렇게 구성이 돼 있습니다. 지표에 대한 시뮬레이터 그러니까 스케줄링해야 되는 대상 작업에 대한 목록들을 관리하고 이것들의 대기시간이나 이런 정보들을 가지고 있는 데이터를 시뮬레이션 하는 시뮬레이터와 로드 정보 저희가 실제 지표 서버 10대밖에 없지만, 노드 시뮬레이터로 100개 있다고 가정하고 학습을 시킬 수가 있습니다. 그런 시뮬레이터를 가지고 작업을 구성해서 스케줄러로 스케줄링 한 다음에 결과를 컨트롤러가 확인하고 그다음에 개선할 부분들을 지시하는 형태로 시뮬레이터가 구성이 돼 있습니다. 네 그리고 실제로 방어학습을 한 에이전트는 3가지 피처를 주로 학습을 합니다. GPO 서버를 의미하는 로드 정보 그리고 사용자들의 작업을 의미하는 테스크 전체 클러스터의 Q나 대기 시간 같은 걸 확인하는 글로벌 3가지를 보고 있습니다. 오른쪽에 데이터 모델링한 걸 보시면 노드족에는 첫 번째 타임 스탬프의 타임 스텝의 2개 작업이 실행되고 있고 그게 다섯 번째 타임 스텝 이름이 0이 되면서 회색 부분은 남아있는 GPO 개수인데요. 이렇게 실행 중인 테스크와 5개 타임 스탬프에 따라서 줄어드는 자원량 늘어나는 자원량을 가지고 학습을 진행합니다. 그리고 지금 실행하고 있는 테스크의 정보 글로벌 리소스에 대한 정보들을 추가로 뉴럴렛에 학습을 해서 에이전트가 학습을 진행하구요. 오클로드를 제네레이션 하는데 저희가 운영을 오랫동안 했다고 말씀드렸는데 한 2~3년 정도의 분산 학습 작업 시행 데이터가 있습니다. 그 데이터를 분석을 해서 이런 데이터들을 제네레이션을 하고 있습니다. 우선 잡 익스큐션 타임입니다. 실제 작업이 실행되는 시간 그리고 오른쪽은 Q에서 대기하는 시 Q 웨이팅 타임 그 외에 실제 GP를 몇 장이나 쓰는지 지표 메모리 얼마나 사용하는지 이런 부분들을 시뮬레이션을 하고 있고요. 그리고 사용자별로 헤비하고 헤비 유저나 라이프 유저를 구분하고 워크 로드 별로도 헤비 유저와 라이트 유저를 구분을 했습니다. 그래서 그래프 위에 보시면은 왼쪽에 헤비 유저와 왼쪽에 라이트 유저와 오른쪽에 있는 헤비 유저 간의 관계를 그 펑션으로 만들어내서 오크로드 제너레이터가 이 그래프에 기반해서 오크로드를 생성할 수 있게 해놨고요. 그리고 사용자들이 실제 학습 작업을 실행하는 인터벌을 잡 어라이벌 인터벌이라고 하고 이것에 대한 데이터를 시뮬레이션 했고 실제 실행하는 작업들의 GPU 소요량에 대한 것도 모델링을 했습니다. 그래서 그 결과로 헤비한 헤비안 워크로드에 대한 인터벌을 계산했고요. 라이트한 워크로드에 대한 인터벌을 계산했습니다. 그래서 워크로드 레이시어에 따라서 워크로드 레이시어는 실제로 작업이 얼마나 많이 자주 들어오느냐에 대한 지표입니다. 그래서 워크로드 레이시어가 높으면 작업이 빨리빨리 들어오니까 어라이벌 인터벌이 짧아집니다. 근데 그러면은 Q에 대기하고 있는 작업들이 무한정 늘어날 수가 있기 때문에 오크로드 레시얼을 줄여 가면서 테스트를 했습니다. 네 결과입니다. 결과 정리할 때 저희가 레퍼런스한 모델들은 다 한 것 같습니다. 강화학습모델 중의 하나인 BTS와 솔로 모델 전용했고요. 그다음에 휴리스틱 아까 앞서서 말씀드린 휴리스틱 기법 중에 피포 포스터핏 랜덤 그리고 꽉꽉 끼워서 빌프킹처럼 꽉꽉 끼워서 스케이즈 운영하는 테크리스 기법을 적용 레스커시를 했습니다. 테스트해서 결과로 측정한 수치들은 다음과 같습니다. 슬로우드한 수치입니다. 작업이 실행된 시간과 웨이팅 타임을 실행된 시간에 대비해서 측정한 시간이고요. 메이츠페인은 사용자들이 실행하는 전체의 작업에 대한 소요시간을 측정한 겁니다. 워클로드레이션을 아까 설명드렸고요. 그리고 요거는 추가적으로 성능 외에 추가적으로 페어니스가 얼마나 확보가 되는지도 추가 테스트를 해봤습니다. 딥제이스 두 번째 보시면 그 강화 학습 모델 중에 딥 제이스를 적용했을 때 1.45라는 성능은 가장 좋았지만 아래 표에 보시면 하나씩 아웃라이어같이 보이는 부분이 대기하는 작업들입니다. 하나씩 하나씩 저렇게 엄청 오랜 시간을 대기하는 작업들이 발생을 합니다. 저게 페어하지 않다고 생각하는 거구요. 거기에서 저희가 저런 가장 대기 시간이 소요 시간이 오래 걸리는 작업들을 먼저 실행해 주는 렉 스페이스를 적용을 했더니, 성능은 조금 떨어졌지만 전체 페어니스는 아래에 있는 그래프 다른 색깔의 그래프들처럼 훨씬 좋아지는 것을 확인했습니다. 최종적으로 저희가 슬로우 다운 수치는 작업이 실행된 시간에 대기시간 대비해서 얼마나 되는지를 비교하는 거라고 말씀드렸구요. 슬로우 다운이 낮을수록 좋은 모델입니다. 그래서 휴리스틱한 기법 개포 튜트리스 이런 휴리스틱한 기법 대비해서 딥제이에스 같은 모델을 썼을 때 오프로드 레이시오가 높아질수록 그러니까 사용자의 작업들이 많이 들어올수록 좋은 성능을 보여줬고요. 그다음에 메이크 스페드 에이시어는 레이크 스펜 레이셔가 낮아지면 페어니스가 헤쳐진다는 얘기이기 때문에 저희가 광합성 모델들 즉 DDQA 같은 경우는 메이크 팬 레이시어도 크게 해치지 않으면서 슬로우다운 수치도 높아지는 것을 확인할 수 있었습니다. 네 이제 그 강화 학습 부분은 살짝 좀 재미없는 부분인데요. 조금 재미있을 수 있는 MRG 부분에 대해서 설명을 드리겠습니다. 아시는 분들도 있으시겠지만, MIC는 멀키 인스폰스 지큐어라고 해서 에이백부터 발표된 NBDI 아키텍처입니다. 기존에도 그 파이토치의 MPS나 스트림 같은 걸 이용해서 지필로 쪼개서 쓰는 기법들이 있었습니다. 근데 그거는 보안상으로 문제들이 있었고, 메모리를 나눠서 쓰는 거기 때문에 그런데 MRG의 경우에 물리적으로 완전히 분리된 7개의 GPU를 사용할 수 있는 형태의 MBD 아토픽처입니다. 프로파일은 5가지 정도가 있고요. 원시 프로파일은 80기가짜리 GPU를 10기가짜리로 7개 나눠 쓸 수 있는 프로파일입니다. 그리고 2G의 경우에는 3개로 나눠 쓸 수 있는 프로파일이구요. 이런 식으로 사용자가 필요한 사이즈에 따라서 NBDR CPU를 AV GPU를 7개 최대 7개까지 나눠 쓸 수 있는 기법입니다. 오른쪽에 보시면 이렇게 약간 단순화했지만, 저희가 쓰고 있는 화면의 일부인데요. 저 보시는 것처럼 CPU GPU 이외에 MIC 리소스도 별도로 분리해서 사용할 수 있습니다. 근데 이런 MIC를 에이백이 있는 데 굳이 필요하냐? 그래서 저희가 테스트를 좀 해봤습니다. MIC를 원지 프로파일과 2G 프로파일로 나누고 그 원지 2G에 들어갈 수 있는 10기가짜리 모델과 20기가짜리 모델들을 돌려봤습니다. 그래서 캔지에서 돌렸을 때 저희는 MIC가 약간 사실 코다 MPS나 스테이션 같은 걸 쓰면 성능이 일정하게 나오지가 않습니다. 동시에 실행하는 작업들의 영향을 받기 때문인데요. MIC의 경우에는 7번 실행을 했을 때 거의 균일한 성능을 확인할 수 있었습니다. 그리고 70짜리로 사용했을 때는 약 2배 가까이 성능이 올라가는 것을 확인할 수 있었구요. 그래서 저희는 사용자들한테 이렇게 얘기를 했습니다. 10지 이하의 작업을 돌릴 때는 MRG를 이용해서 돌리세요. 해서 보시는 것처럼 폴 GPU는 큰 모델로 돌리고 작은 GPU는 MRG 이용해서 돌리고 요렇게 구동을 할 수 있게 했습니다. 그리고 실험을 해 봤더니, 어 이런 점도 찾을 수 있었습니다. 인셉션 V3 같은 경우에 에이백 쿨 GPU를 사용한 경우에 7번 학습을 실행하면 7분 18초가 걸리는데요. MRG를 이용하는 경우에 2분 7초면 7개니까 GPU가 7개니까 2분 7초면 7번을 구동할 수가 있게 됩니다. 그래서 실제적으로 성능 비교했을 때 MIC를 분업을 많이 하는 프로젝트라면 MIC를 썼을 때 3배 정도의 성능 향상을 꾀할 수 있다. 라는 부분입니다. 네 그리고 여기는 MIC 프로파일 설정하는 방법이랑 그다음에 저희가 어떻게 MIC를 운영하고 있는지에 대해서 설명드리는 부분이구요. 그리고 주피터 노트북을 저희가 생성할 수 있게 아까 인터렉티브 풀에다 생성할 수 있게 해드리는데 풀 GPU를 사용하지 않고 여기 MRG를 이용해서 주로 초피터 노트북은 풀 GPU가 필요하지 않은 경우가 많기 때문에 초피터 노트북에는 MRG 리소스를 할당하도록 이렇게 적용이 돼 있습니다. MIC 리소스를 실행하면 여기 NBDI SMI를 쳤을 때 MIC 리소스에 맞는 별도의 CHPU인 것처럼 보여줍니다. 네 그리고 저희가 MIC를 적용하면서 앞서는 제가 만능인 것처럼 말씀드렸는데 단점들이 많이 있었습니다. 가장 심각한 단점은 MIC 디바이스들끼리는 통신이 되지 않습니다. MIC로 분산했을 때 그 MIC GPU 내에 MV 링크가 깔려 있음에도 불구하고, MV링크는 쓸 수가 없고요. MIC 디바이스를 2개 이상 도커에다가 할당을 했을 때도 실제 도커 내에서는 MIC가 1개만 구동이 됩니다. 그래서 그런 부분들이 MRG에 쓰기에 불편한 부분들이 있고요. 그리고 MRG를 GPU 하나를 MIC로 7개 나눴을 때 하나의 설정만 바꾸고 싶어도 나머지 작업들이 다 릴리즈 돼야만 MRG 설정을 바꿀 수가 있습니다. 그리고 서버가 재부팅될 때마다 지표 서버 운영해 보신 분들은 아시겠지만, 주 1회 정도는 리부팅이 필요합니다. 워낙 문제들이 많기 때문인데요. 근데 재부팅할 때마다 MRG 프로파를 다시 설정해야 됩니다. 앞서서 보여드렸던 요런 작업을 다시 진행을 해야 됩니다. 네 그런 문제점들이 있었고요. 그럼에도 불구하고, 앞서 말씀드린 저희 스케쥴링 기법들과 MIC 프로파일들을 잘 이용해서 그나마 얼마 안 되는 리소스들을 최대한 아껴서 아껴서 사용하고 있고요. 현재 저희는 VBACK A10 HBACK 클러스터들을 실제로 운영을 하고 있고 운영하면서 발생하는 문제들을 많이 해결을 해오고 있습니다. 시간이 조금 남은 것 같아서 제가 운영할 때 가장 힘들었던 부분들을 말씀드리면, 여기는 MLOPS 분들이 얼마나 되신지 모르겠지만, 현재 제가 다뤄야 되는 사용자 컨테이너가 100여 종이 넘습니다. 그런데 지금 에이베 그 드라이버는 470이 아직도 깔려 있습니다. 3년 전에 깔아놓은 드라이버죠 그래서 유지보수 업체들은 이미 손 들고 나갔고 그래서 드라이버를 업데이트할 방법은 사실상 제가 손으로 하는 방법밖에 없는데 컨테이너들은 계속 새 버전으로 나오고 있습니다. 그러다 보니까 사실 23년 컨테이너까지만 해도 드라이버 자치공사 잘 돌았는데 어느 날 어떤 사이언티스크가 들고 온 컨테이너는 돌질 않습니다. 그러면은 사이언티스들은 지표가 고장 났다 요렇게 얘기를 합니다. 그래서 오늘도 그 문제를 해결하려고 하는데 대부분 그런 경우는 대부분 쿠더와 드라이버의 호환성입니다. 쿠다의 호환성 패키지가 있습니다. 컴퓨터빌리티라는 패키지가 있는데, NGC 컨테이너 웬만큼 깔려있고요. 아니 그게 아니라 사용자가 어디서 주소 및 컨테이너를 사용하는 경우에는 이 쿠다와 컴퓨터빌리티 패키지를 버전에 맞춰서 깔아주면 웬만하면 해결이 됩니다. 그리고 GPU 서버의 드라이버 버전을 결정하실 때는 드라이버 버전에 대해서 여러 가지 타입이 있습니다. 그냥 에피에스비라고 해서 롱텀 서포트 드라이버는 4년 동안 서포트를 합니다. 그러면 엔비디아가 그 이후 4년 동안 만들어내는 CODA CUTIT이 그 드라이버와 호환이 됩니다. 1년짜리 버전이 있고요. 6개월 혹은 서포트 안 하는 버전들이 있습니다. 그래서 드라이버를 설치하실 때 꼭 LTSB 버전으로 설치를 하시거나 최소한 1년짜리 드라이버 버전을 설치하시는 것을 권장드립니다. 네 오늘 여기까지 제가 준비한 내용 다 말씀드렸고요. 시간이 되시면 질문을 받아들도록 아 네 발표 잘 들었고요. 그 SBS에서는 이거를 오프로미스에서도 제공을 상품으로 판매하실 계획인가요? 서두에 말씀드린 것처럼 오늘 설명드린 부분은 저희 연구소에서 연구 용도로 쓰고 있는 비상품이고요. 그 외에 어 SBS 그리고 SCP라는 클라우드 플랫폼이 있습니다. 흔히 아시는 AWS 뭐 에저 이런 거와 동일한 기능을 하는 부분이 있고 그 안에 보시면 AIMLOPS 라는 성분이 하나 있습니다. 고거를 거의 유사한 기능을 한다고 보시면 될 것 같습니다. 온프라니지 형태 가능하구요. 설치형이 그러니까 말씀드린 오프라이즈가 내 서버에 들어와서 설치해 줄 수 있느냐 그런 서비스는 하지 않지만 SCP의 고객만을 위한 프라이베이 클라우드 환경을 만들어 드리는 서비스는 하고 있습니다. 감사하단 말씀드립니다. 네 그 기술 외적인 질문일 것 같은데, 여러 종의 스케줄러들이 설치된 후배 클러스터를 여러 개를 운영해서 사용자가 그에 맞게 선택을 하는 그런 사용성 인지가 첫 번째 질문이고요. 두 번째 질문은 간혹 가다가 이제 뭐 저만의 로드그룹을 만들어주세요. 저만의 큐를 만들어주세요. 저 팬딩되고 싶지 않아요. 이런 얘기를 하는 사람도 있을 텐데 그 요청을 선택적으로 수용을 하시는지 아니면 철저하게 멀티페넌스를 고집 못하시는지 그런 삶의 지혜 좀 궁금해요. 먼저 질문하셨던 저런 다양한 폴리시들을 어떻게 해결하느냐라는 부분이신데, 저희가 만든 스케줄러에 폴리시를 추구할 수 있도록 설계가 되어있습니다. 근데 겹칠 수 있는 폴리시가 있고 공존할 수 없는 폴리시가 있습니다. 예를 들면 피퍼와 빈 패킹 앵 스케줄링은 동시에 사용할 수 있고요. 그다음에 강화학습이랑 멀티캐드를 동시에 사용할 수가 없습니다. 그런 경우에 제가 클러스터를 아까 말씀드린 것만 3개 정도 운영한다고 말씀드렸는데 용도가 조금 구분이 될 거 같구요. HDI 클러스터는 지표 환자짜리 작업이 실행되는 경우가 거의 없어서 거의 항상 분산 학습이 돌고 있기 때문에 HB 클러스터의 경우는 단순 피포큐만 해도 충분하구요. 다만 AB 클러스터는 정말 다양한 모큐로드들이 들어가 있기 때문에 여기에는 빈패킹 갱 강화학습 알고리즘 이런 것들이 멀티플래시로 적용이 돼 있습니다. 그래서 이어서 두 번째 물어보신 것까지 어느 정도 말씀드린 거 같은데, 완전히 용도에 따라서 명확히 구분된 건 아니지만, 어느 정도로 내부적으로 합의가 오랫동안 같이 일하면서 합의가 돼 있는 것이 LED 모델이 큰 거 큰 거라고 하시면 보통 60빌리언 이상 모델들을 구동할 때는 H100을 쓰도록 하고 그 외의 경우는 에이베 서브를 쓰자는 것이 어느 정도 합의가 돼 있구요. 그리고 그리고 코번 앤티스에서 퍼스터 리소스로 그룹이나 오가니제이션이라는 개념을 넣어서 그룹과 오가니제이션들이 포차 컨트롤을 하고 있습니다. 그래서 저희 AI 연구팀에 랩이 여러 개가 있는데, A 랩이라는 데서 GPU 20대의 그런 쿼터를 가져갔죠 비랩에 대해서 GPU 10개에 대한 포털을 가져가면 거기에 대해서 서로 침해하지 않도록 잘 컨트롤을 해주고 있고 가끔 노드를 명확히 구분해 달라는 요구사항이 나올 때도 있습니다. 잘 들어주진 않지만 그런 경우에도 토모네틱스 노드 셀렉터 같은 걸로 별도 큐를 구성을 해주고는 있습니다. 지금 MFCL의 환이라는 게 그런 거라고 네 오늘 발표 너무 감사드립니다. 저희로서 저희가 준비한 모든 세션이 다 마무리가 되었고요.