AI 워크로드의 I/O 수요 이해

비디오 대본

본 대본은 명확한 이해를 돕기 위해 편집되었습니다.

Roger Corell: 안녕하세요, 저는 Roger Corell입니다. 저는 솔루션 마케팅 및 기업 커뮤니케이션 이사입니다. 그리고 오늘 저와 함께 Kartik 박사를 모셨습니다. 먼저 인공 지능에 대한 스토리지의 중요성에 대한 토론에 솔리다임에 참여하고 AI 파이프라인의 5가지 개별 단계(수집, 데이터 준비, 모델 훈련, 모델 체크포인트 및 추론.)에 대한 VAST 데이터 관점을 파악한 Dr. Kartik에게 감사드립니다. 각 단계, 각 단계의 I/O 특성 및 각 단계에서 이러한 I/O 특성이 수행하는 스토리지 문제를 몇 분 동안 살펴볼 수 있습니까?

Subramanian Kartik: 물론입니다. 상상할 수 있듯이 완전히 쓰기 가능한 데이터의 실제 수집은 다음과 같습니다. 외부 소스에서 데이터를 가져올 것입니다. 일반적으로 공개된 초기 훈련 세트로 시작하는 경우 클라우드 리소스에서 가져올 수 있습니다. 또한 회사 내부 출처에서 나온 것일 수도 있습니다. 이는 보다 전통적인 ETL과 같은 프로세스¹ 입니다. 이는 순차적인 경향이 있고 여러분 ²가 매우 능숙한 인바운드 쓰기입니다. 또한 우리는 그것을 매우 잘합니다. 그러나 실제 데이터 준비는 실제로 고통스럽습니다. 데이터는 더러워지는 경향이 있고 어떤 종류의 정규화를 거쳐야 하기 때문입니다. 잘못된 데이터를 확인해야 합니다. 여기를 통과하는 매우 복잡한 파이프라인이 있습니다. 이 파이프라인은 CPU에 크게 의존합니다. 따라서 읽기와 쓰기가 엄청나지만 실제로는 I/O에 바인딩된 것이 아니라 일반적으로 CPU에 바인딩됩니다. 그리고 종종 협력 작업을 수행합니다. 따라서 워크로드는 뷰 클러스터라기보다 HPC 클러스터처럼 보입니다. 

Corell: 데이터 준비 단계에서 읽기와 쓰기에 대해 언급하셨는데요. 물론 어느 정도의 쓰기가 있습니다. 하지만 이전에 우리가 많은 양의 데이터를 읽고 있지만 ETL, 데이터 정리, 정규화 등의 프로세스를 통해 궁극적으로 읽고 있는 양보다 훨씬 더 적은 양의 데이터를 다시 쓰게 된다고 이야기를 했던 것 같습니다.

Kartik: 정확합니다. 읽는 것만큼 쓰지 않습니다. 그리고 이러한 것들은 주로 읽기 위주인 경향이 있는데, 이것은 의심의 여지가 없습니다. 하지만 처리 과정에서도 어느 정도 순차적인 경향이 있습니다. 특히 이 단계에서는 더욱 그렇습니다. 이는 훈련에서 볼 수 있는 것과 매우 대조적입니다.  훈련에서 I/O 패턴은 랜덤입니다. 데이터가 모델에 표시되는 방식을 무작위로 처리해야 하기 때문에 I/O를 랜덤화하죠. 그 이유는 매우 간단합니다. 모델은 꽤 똑똑합니다. 동일한 데이터를 동일한 순서대로 보여주면 어떻게 될까요? 데이터의 순서를 기억합니다.  GPU에 매우 의존적이죠. 그 이유는 모델이 커서 여러 GPU에 분산되어야 하며, 그에 따른 파이프라인이 깊기 때문입니다. 따라서 이를 병렬화하는 데 사용되는 매우 흥미로운 기술입니다. GPU에서 모델을 병렬화하는 것은 여러 GPU 서버에서 파이프라인을 병렬화하고 궁극적으로 데이터 액세스를 병렬화하여, 이러한 파이프라인과 모델 세트의 각 클러스터가 데이터의 일부를 처리할 수 있도록 하는 것입니다.  매우 읽기 집약적이죠. GPU로 빨려 들어가는 데이터의 엄청난 소리가 들립니다. 솔직히 데이터가 GPU에 들어가면 여기에서 처리해야 하는 GPU 작업이 엄청나게 많기 때문에, 그러니까 GPU에 의존하는 경향이 있기 때문에 I/O 관점에서 보면 놀라운 일은 아닙니다.  훈련 단계의 결과물은 모델 자체일 뿐입니다. 그저 숫자의 집합이죠. 배치를 수행하는 방법은 앞서 언급한 하이퍼 파라미터 중 하나입니다. 배치 크기가 얼마나 커야 하는지가 중요하죠. 이것은 일반적으로 모델 크기와 보유한 GPU의 수, 모델 배포와 모델 배포 방식에 따라 달라집니다. 그리고 그에 따른 최적의 배치 크기가 있습니다. 512개의 토큰만큼 작을 수 있습니다. 여기서는 수천 개의 토큰이 될 수 있습니다. 하지만 본질적으로는 데이터를 청크로 가져오는 것입니다. 그런 뒤에 이를 처리하고 다음 세트를 청크로 가져옵니다. 따라서 작업 중인 프레임워크인 경우, 일반적으로 이것을 데이터 로더와 PyTorch 수준에서 설정합니다.  그리고 이것은 대규모 언어 모델 트레이너가 다른 어떤 것보다 더 많이 최적화하는 매개 변수입니다. 따라서 스토리지에 실질적인 영향을 미치지 않는다는 것을 명심하십시오. 체크포인팅은 GPU당 하나의 스레드인 대규모 블록 순차 쓰기이기 때문에 스토리지의 읽기 패턴은 체크포인트 중이 아니라 훈련이 진행되는 동안 작동됩니다.  훈련에서는 시스템으로 들어가는 읽기가 폭발적으로 증가하는 것을 볼 수 있습니다. 때로는 시스템이 그중 일부를 프리페치하고 메모리에 저장하여 다음 배치와 메모리를 미리 준비시킵니다. 그러나 그것이 무엇이든 간에 초당 10기가바이트 또는 초당 50기가바이트의 지속적인 읽기가 발생하는 경우는 거의 없습니다. 산발적인 읽기 덩어리를 볼 수 있죠. 

Corell: 체크포인팅으로 넘어가겠습니다.

Kartik:. 네, 체크포인팅으로 넘어가서 체크포인팅이 무엇인지에 대해 논의해 보겠습니다. Roger, 여기 난감한 진실이 있습니다. 모든 것이 항상 제대로 되는 것은 아닙니다. 

Corell: 그렇죠. (웃음)

Kartik:. 나쁜 일이 일어나죠. 어떤 나쁜 일이 일어날 수 있을까요? 나에게 2000개의 GPU가 있는데 GPU가 고장이 났습니다. 오, 이런. 또는 메모리 오류가 발생했다고 하죠. 우와. 알겠죠? 정말 나쁘군요. 뭔가 문제가 생깁니다. 소프트웨어 문제가 있습니다. 버그가 있어요. 음, 엉망이 되었습니다. 이런 일이 발생하면 전체 훈련이 중단될 뿐만 아니라, 전체 GPU 클러스터 자체에서 하나 이상의 구성원이 사라지는 것이기 때문에 모든 것을 잃은 셈입니다. 현시점에서 이러한 작업은 오래 걸립니다. 한국의 한 기업에서 2000개 이상의 V100 GPU를 사용해 한글 스크립트로 GPT 3을 훈련하는 데 6개월이 걸렸습니다. 하나의 작업을 6개월 동안 지속적으로 훈련해야 합니다.

Corell: 그리고 체크포인팅은 전에도 이야기했던 것 같은데 자주 일어납니다. 그렇지 않나요? NVIDIA는 4시간 간격을 권장하지 않나요? 그 정도죠?

Kartik: 그것이 그들이 권장하는 방식이었습니다. 조금 더 공격적으로 변하기 시작했지만, 실제로는 최종 사용자에게 달려 있습니다. 아마 4시간에 한 번씩일 것입니다. 어쩌면 매 시간일 수도 있습니다. 30분마다 일 수도 있죠. 얼마이든 가장 중요한 것은 체크포인트가 기본적으로 모델과 파이프라인의 전체 실행 상태를 디스크 파일에 캡처한다는 점입니다.  그리고 어떤 종류의 치명적인 이벤트에서 돌아와야 하거나 때때로 이전 단계로 돌아가야 할 때, 모델 훈련이 계획대로 진행되지 않고 모델이 수렴하도록 앞에서 언급한 하이퍼 파라미터 중 하나를 조정해야 하기 때문에 처리를 다시 실행할 수 있습니다. 그런 다음 반드시 체크포인트를 가져야 합니다.  이러한 체크포인트와 관련하여, 경험상 좋은 방법인 매개 변수당 14바이트로 체크포인트의 크기, 즉 체크포인트 상태를 알 수 있습니다. 따라서 GPT 3과 같은 1,750억 개의 매개 변수 모델을 사용하는 경우, 해당 모델의 체크포인트 상태는 2.4테라바이트입니다. 5,000억 개의 매개 변수 모델이 있는 경우, 체크포인트 상태는 7테라바이트입니다. 이런 식이죠. 관계는 선형적입니다. 따라서 체크포인트를 할 때마다 그만큼 많은 데이터를 덤프해야 합니다. 따라서 GPT 3의 체크포인트는 2.4테라바이트이며, 이를 디스크에 기록해야 합니다. 그리고 저는 이 작업을 빠르게 하고 싶습니다.

Corell: 그렇죠. 쓰기 중에는 GPU가 유휴 상태이기 때문입니다. 

Kartik: 맞습니다, 유휴 상태이죠. 그리고 NVIDIA가 선호하는 특정 배포 모델에만 해당합니다. 하지만 일반적으로 비동기 체크포인트로 시작하는 사람들이 있지만 이러한 것은 동기식 체크포인트이며, 데이터를 덤프할 때 작업을 일시 중지합니다. 따라서 가능한 빨리 이 작업을 수행하는 것이 모두의 관심사입니다. 이것은 많은 용량을 생성하므로 체크포인트의 빈도에 주의해야 합니다. 하지만 체크포인트를 할 때는 최대한 효율적으로 하고 싶겠죠. NVIDIA가 제공하는 기본적인 경험 법칙은 체크포인팅 시간이 전체 체크포인트 빈도 시간의 5%를 넘지 않아야 한다는 것입니다. 따라서 한 시간에 한 번 체크포인트를 하는 경우, 한 시간의 5%만 수행하면 됩니다. 이것은 기본적으로 얼마나 될까요?  Corell: 3분입니다.

Kartik: 3분, 좋아요. 3분 내에 체크포인트를 할 수 있어야 합니다. 그리고 계산은 간단하죠. 3분에 2.4테라바이트를 기록해야 합니다. 우와. 숫자가 나오는군요. 이것이 제가 필요로 하는 대역폭입니다. 

Corell: 처리량이 있습니다.

Kartik: 당신의 처리량이죠.

Corell: 네. 좋은 설명입니다. 계속 진행하기 전에 체크포인팅에 대해 더 알아야 할 것이 있을까요? 

Kartik: 네. 중요한 것은 체크포인트뿐만이 아니기 때문입니다. 복원할 수 없다면 체크포인트가 무슨 소용이 있을까요? 

Corell: 이제 읽기에 대해 이야기하겠습니다.

Kartik: 네. 체크포인팅은 훈련에 참여하는 GPU의 하위 집합에서만 수행되기 때문에 읽기는 쓰기보다 훨씬 더 강력합니다. 복원은 모든 GPU에 대해 100%로 수행됩니다. 이 수치는 모델의 크기와 일부 매개 변수에 따라 다르지만, 일반적으로 계산해 본 결과, 읽기와 쓰기 간의 비율이 약 8:1이라는 것을 알 수 있습니다.  따라서 3분 내에 글을 쓰는 경우, 2.4테라바이트입니다. 여전히 3분 내에 복원하려면 그것의 8배를 읽어야 합니다. 따라서 읽기는 매우 강력합니다.  이제, 읽기 성능이 쓰기 성능보다 훨씬 더 우수하기 때문에 VAST 아키텍처에 매우 적합합니다. 따라서 쓰기 성능이 나쁘다는 것이 아니라 읽기 성능이 매우 좋다는 것입니다.  그리고 다시 한번 말하지만, 읽기에는 내구성이 영향을 주지 않기 때문에 솔리다임의 도움을 많이 받았습니다. NAND의 내구성 기능을 건드리지 않고도 원하는 만큼의 읽기를 제공할 수 있기 때문에 정말 멋진 일입니다.  또 한 가지 알아야 할 점은 체크포인팅과 복원에 있어서 그것이 매우 비대칭적이라는 것입니다. 복원은 체크포인트보다 훨씬 더 강력합니다. 체크포인트의 경우 적절한 대역폭이 필요하지만, 체크포인트 빈도에 따라 매우 달라집니다. 자세히 살펴보고 계산해 보세요. 정말 작은 크기가 있는데, 원하신다면 기꺼이 공유하겠습니다.

Corell: 체크포인팅에 대한 설명에 다시 한번 감사드립니다. 마지막 단계인 추론으로 넘어가겠습니다. 

Kartik:. 추론은 GPU에 의존하지 않기 때문에 여러 가지 면에서 흥미롭습니다. 이유는 무엇일까요? 훈련을 위해서는 데이터가 신경망과 모델을 거쳐 정방향 전파 패스라고 하는 것을 통해 이동한 다음, 모델을 통해 다시 이동시켜 가중치를 재조정해야 하기 때문입니다. 이를 역방향 전파 패스라고 합니다.  추론은 정방향 패스일 뿐입니다. 따라서 매우 빠르고 간단합니다. I/O에 크게 의존하는 경향이 있죠. 사실, CPU와 GPU가 포화될 때까지 원하는 만큼의 데이터를 계속 펌핑할 수 있지만 GPU를 기다리는 것은 아닙니다. GPU는 스토리지에서 대기 중입니다.  다시 한번 말하지만, 특성은 동일하게 유지됩니다. 추론은 거의 100%의 읽기입니다. 그리고 높은 처리량의 읽기는 일반적으로 발생하는 데, 특히 큰 이미지의 경우에 더욱 그렇습니다. 드물기는 하지만, 모델 자체가 이미지를 출력하는 경우가 있습니다. 예를 들어 안정적인 확산 모델이 이미지나 동영상 등을 생성하는 경우죠. GPU는 기록할 이미지를 구성해야 하기 때문에 어느 정도 GPU에 의존하는 경향이 있습니다. 따라서 여전히 쓰기가 있지만, 실제로 쓰기에 의존하지는 않습니다. 읽기는 많은 것을 할 수 있는데, 이것은 여러분과 저에게 정말 맞습니다. 왜냐하면 우리는 이 작업에 매우 능숙하기 때문이죠. 

Corell: 다시 한번 감사드립니다. 오늘 하루도 즐겁게 보내시고, 정말 감사합니다.

Kartik: 정말 영광스러운 시간이었습니다. 초대해 주셔서 정말 감사합니다.

참고

[1] ETL은 여러 소스의 데이터를 데이터 웨어하우스 리포지토리로 결합하는 프로세스를 나타냅니다. 약어 ETL은 Extract(추출), Transform(변환), Load(로드)를 의미합니다.  이 프로세스는 일련의 규칙을 사용하여 원시 데이터를 정리 및 구성하고 저장, 데이터 분석, 머신 러닝을 준비합니다.

[2] 이 참조는 회사로서의 솔리다임이며, AI 응용 프로그램에서 VAST Data가 사용하는 솔리다임 SSD를 의미합니다.