ChatGPT 서비스 확장에서 겪은 현실적인 엔지니어링 문제들

안녕하세요 주간SaaS 입니다.

오늘은 Scaling ChatGPT: Five Real-World Engineering Challenges 라는 글을 소개 합니다. OpenAI에서 Applied 팀을 이끌고 있는 엔지니어의 인터뷰를 담은 글로 ChatGPT 를 서비스하며 겪은 확장성의 문제와 해결의 과정을 담고 있습니다. 내용이 길어서 인터뷰 내용 부분만을 옮겼습니다. (*원문의 전체 내용을 꼭 보시길 추천 드려요)

개인적으로 ChatGPT가 서비스 되는 방식의 일부를 이해하고, LLM 기반 서비스를 제공할 때 고려해야 하는 엔지니어링 관점의 요소를 배울 수 있었습니다. ChatGPT정도면 사실 어나더레벨의 서비스라 공감하기 어려운 규모지만🤣 그들이 고민하고 문제를 해결하려고 시도했던 접근 방식은 SaaS 엔지니어링 문제를 해결에도 활용될수 있을거라 생각합니다. 여러분들에게도 도움이 되면 좋겠습니다!

1. 어떻게 OpenAI에 합류하여 ChatGPT를 구축하는 Applied 엔지니어링 그룹을 이끌게 되셨나요?

OpenAI는 ChatGPT를 만든 회사이며, 이는 회사 제품 중 하나에 불과합니다. 다른 제품으로는 DALL-E 3(이미지 생성), GPT-4(고급 모델), 개발자와 기업이 AI를 프로세스에 통합하는 데 사용하는 OpenAI API 등이 있습니다. ChatGPT와 API는 각각 여러 클래스의 모델을 서비스 합니다. GPT-3, GPT-3.5 및 GPT-4.

이러한 제품을 만들고 확장하는 엔지니어링, 제품 및 디자인 조직을 "Applied"라고 하며, GPT-3가 출시될 때인 2020년에 설립되었습니다. 이 조직은 OpenAI의 연구를 전 세계에 안전하게 제공하는 것을 주요 임무로 삼고 있습니다. OpenAI 자체는 2015년에 설립되었으며, 오늘날에도 안전하고 정렬된 인공 일반 지능(AGI)을 만드는 것을 목표로 하는 연구소가 회사의 핵심입니다.

저는 2020년 10월 Applied가 막 출범했을 때 OpenAI에 입사했습니다. 저는 머신러닝 박사 학위가 없었지만 API와 엔지니어링 팀을 구축한다는 아이디어에 흥미를 느꼈습니다. 저는 초창기부터 ChatGPT의 출시와 확장에 이르기까지 Applied 엔지니어링 조직 전체를 관리했습니다. (*Evan의 이야기에 대한 자세한 내용= Inside OpenAI: ChatGPT는 어떻게 그렇게 빨리 출시될 수 있었나요?)

2. ChatGPT는 어떻게 작동하나요?

몇 가지 확장 주제를 소개하기 위해 이러한 AI 모델이 어떻게 작동하는지 간단히 소개해드리겠습니다. 기본 사항에 익숙하다면 섹션 3으로 건너뛰세요.

ChatGPT에 질문을 하면 여러 단계가 진행됩니다:

이 단계를 시각화 해보겠습니다. 처음 두 단계는 간단합니다:

토큰화는 반드시 텍스트를 단어로 분할하는 것을 의미하지는 않으며, 토큰은 단어의 하위 집합일 수도 있다는 점을 유의해야 합니다.

임베딩은 대규모 언어 모델(LLM)의 핵심이며, 다음 단계에서는 토큰으로 이를 생성합니다:

임베딩은 토큰을 다차원적으로 표현한 것입니다. 저희는 일부 모델을 명시적으로 훈련시켜 단어나 구문 사이의 의미론적 의미와 관계를 포착할 수 있도록 합니다. 예를 들어, '개'와 '강아지'에 대한 임베딩은 '개'와 '컴퓨터'보다 여러 차원에서 서로 더 가깝습니다. 이러한 다차원 임베딩은 기계가 인간의 언어를 더 효율적으로 이해하는 데 도움이 됩니다.

모델 가중치는 가중 임베딩 행렬을 계산하는 데 사용되며, 이 행렬은 다음 가능성이 있는 토큰을 예측하는 데 사용됩니다. 이 단계에서는 수천억 개의 가중치로 구성된 OpenAI의 가중치 행렬을 사용하고 임베딩을 통해 구축한 행렬을 곱해야 합니다. 이는 컴퓨팅 집약적인 곱셈입니다.

예측의 샘플링은 수십억 번의 곱셈을 수행한 후에 이루어집니다. 최종 벡터는 다음으로 가장 가능성이 높은 토큰의 확률을 나타냅니다. 샘플링은 다음으로 가장 가능성이 높은 토큰을 선택하여 사용자에게 다시 보내는 것을 말합니다. ChatGPT에서 뱉어내는 각 단어는 이 과정을 초당 여러 번 반복합니다.

사전 학습 및 추론

인간 지식의 대부분이 담겨 있는 복잡한 모델 가중치 집합을 어떻게 생성할 수 있을까요? 사전 학습이라는 프로세스를 통해 이를 수행합니다. 최종 목표는 인터넷의 모든 단어에 대해 다음 토큰(단어로 생각할 수 있는)을 예측할 수 있는 모델을 구축하는 것입니다.

사전 학습 과정에서 가중치는 수학적 최적화 방법인 경사 하강법을 통해 점진적으로 업데이트됩니다. 경사 하강버븐 산에 갇힌 등산객이 산을 내려오려고 하는 것에 비유할 수 있습니다. 하지만 짙은 안개 때문에 산 전체를 볼 수 없고 시야가 주변의 작은 영역으로 제한되어 있습니다. 경사 하강은 등산객의 현재 위치에서 경사의 가파른 정도를 보고 가장 가파른 하강 방향으로 진행하는 것을 의미합니다. 경사도는 단순 관찰로는 알 수 없지만 다행히도 이 등산객에게는 경사도를 측정할 수 있는 기기가 있습니다. 하지만 한 번 측정하는 데 시간이 걸리고 해가 지기 전에 내려가고 싶어합니다. 따라서 이 등산객은 일몰 전에 하산할 수 있도록 얼마나 자주 멈춰서 경사도를 측정할지 결정해야 합니다.

모델이 완성되면 모델에서 추론을 실행할 수 있는데, 이때 모델에 텍스트로 프롬프트를 보냅니다. 예를 들어 다음과 같은 프롬프트가 표시될 수 있습니다: "실용적인 엔지니어를 위한 게스트 게시물 작성". 그러면 이 프롬프트는 모델에 다음으로 가장 가능성이 높은 토큰(단어)을 예측하도록 요청합니다. 이 예측은 과거 입력을 기반으로 이루어지며, 토큰 하나하나, 단어 하나하나를 반복하여 게시물이 나올 때까지 반복적으로 이루어집니다!

Self-attention 사용에 따른 확장성 문제

저희는 내부적으로는 각 토큰이 다른 토큰을 인식하는 것이 핵심 특징인 트랜스포머 아키텍처를 사용합니다. 이러한 접근 방식을 Self-attention 라고 합니다. 결과적으로 텍스트가 길어질수록, 즉 문맥이 길어질수록 더 많은 연산이 필요합니다.

안타깝게도 self-attention은 4제곱으로 확장됩니다. 모델이 100번째 토큰을 예측하려면 약 10,000번의 연산을 수행해야 한다는 뜻입니다. 모델이 1,000번째 토큰을 예측하려면 약 1백만 번의 연산을 수행해야 합니다!

언뜻 들으면 나쁜 소식처럼 들립니다. 하지만 4제곱(Quadratic) 문제를 피하기 위해 사용할 수 있는 현명한 해결 방법이 있습니다. 이 문제를 해결하는 방법을 알아보기 전에 ChatGPT를 구동하는 인프라에 대해 먼저 살펴볼 필요가 있습니다.

3. GPU의 중요성

GPU(그래픽 처리 장치)는 ChatGPT와 이를 기반으로 하는 API의 매우 중요한 핵심 요소 입니다. 사실 GPU의 극도로 부족한 공급량과 고유의 특성, 그리고 비용이 우리의 운영 및 확장 방식을 결정합니다.

그 배경을 설명하기 위해 저희가 사용하는 GPU 중 하나를 소개하겠습니다.

이것이 바로 NVIDIA H100입니다. 각 GPU에는 특수 고대역폭 메모리(HBM) 메모리가 부착되어 있습니다. GPU는 NVLink라는 고대역폭 인터커넥트를 통해 서로 통신할 수 있으며, 인피니밴드라는 특수 이더넷 대안을 통해 외부와 통신할 수 있습니다. 이 중 8개를 단일 노드에 탑재합니다. Nvidia는 DGX H100이라는 유사한 구성을 판매합니다.

저희에게는 추가되는 모든 컴퓨팅 파워 또는 대역폭이 ChatGPT의 사용자 경험에 직접적으로 영향을 미칩니다.

4. 확장성을 위한 5가지 도전 과제

GPU의 확장 문제와 관련해서는 많은 부분을 커버해야 하지만 아래 5가지를 집중적으로 살펴보겠습니다:

#1: GPU RAM 및 KV 캐시

#2: 배치 크기, ops:바이트 및 산술 집약도

#3: 측정해야 할 올바른 지표

#4: 어디에 있든 GPU 찾기

#5: 오토스케일링, 자원의 부족함

ChatGPT 서비스를 확장하는 과정에서 위에서 언급한 5가지 문제를 이해하는 것이 매우 중요했습니다. 하나씩 자세히 알아봅시다!

도전 과제 #1: KV 캐시 및 GPU RAM

가장 큰 문제는 self-attention이 4제곱으로 확장되기 때문에 토큰이 늘어날수록 4제곱으로 더 많은 작업이 필요하다는 것입니다(100번째 토큰의 경우 약 10,000개의 작업이 필요하지만 1,000번째 토큰의 경우 약 1,000,000개의 작업이 필요함). 어떻게 성능을 개선할 수 있을까요?

초기 해결 방법은 모든 이전 토큰에 대해 수행한 연산을 캐시, 즉 KV 캐시에 저장하는 것입니다. 저희는 머신러닝(ML) 모델에서 attention mechanism을 사용합니다. 이 모델에서는 세 가지 벡터를 사용합니다:

K와 V를 모두 캐시할 수 있으므로 "KV 캐시"라는 이름이 붙습니다. 그러나 이 벡터는 매번 사용자 요청에 따라 변경되기 때문에 Q는 캐시할 수 없습니다.

따라서 KV 캐시를 GPU RAM에 저장해야 합니다. 이는 고대역폭 메모리(HBM)를 사용할 때 GPU RAM에서 데이터를 이동하는 속도가 초당 약 3TB이기 때문입니다. 그러나 PCIe bus (PCI Express: 마더보드에서 데이터를 전송하기 위해 일반적으로 사용되는 고속 버스 표준)를 통해 데이터를 전송하면 초당 약 30GB의 속도를 얻을 수 있습니다. HBM을 사용하면 PCIe보다 약 2배(약 100배) 더 빠릅니다!

HBM이 왜 그렇게 빠를까요? 수천 개의 핀으로 GPU에 물리적으로 스택형 레이어로 결합되어 있어 대규모 병렬 데이터 처리량을 제공합니다.

이 GPU HBM RAM은 매우 비싸고 상당히 제한적입니다. 또한 대부분의 HBM RAM은 모델 가중치를 유지하는 데 사용됩니다. 다른 캐시와 마찬가지로, 캐시가 가득 차면 가장 오래된 데이터를 '만료'하여 공간을 확보합니다.

"캐시 누락"은 우리의 서비스 케이스의 경우에는 비용이 많이 드는 상황입니다. 캐시 누락은 계산에 필요한 캐시 값을 찾지 못하는 것으로, 일반적으로 이 값을 '만료'하고 공간을 확보하기 위해 HBM 메모리에서 쫓아내야 하기 때문입니다. 캐시 누락이 발생하면 전체 ChatGPT 대화를 다시 계산해야 합니다! 그리고 현재 1,000번째 문자에 도달했으니 100만 번의 연산에 가까워질 수 있습니다!

저희 인프라는 사용자 간에 GPU RAM을 공유합니다. 즉, 다른 대화를 위한 공간을 확보해야 하기 때문에 사용자의 대화가 너무 오랫동안 유휴 상태인 경우 시스템(GPU 캐시)에서 퇴출될 수 있다는 뜻입니다.

이 캐싱 접근 방식에는 몇 가지 포인트를 암시하고 있습니다:

따라서, 저희가 ChatGPT를 확장을 결정할 때 단순히 CPU 사용률 메트릭만을 봐서는 안되고, KV 캐시 사용률과 GPU RAM 활용률을 최대화 하는 관점에서 고민해야 한다는 뜻이 됩니다.

도전 과제 #2: 배치 크기 최적화

배치 크기는 ChatGPT를 확장할 때 균형을 맞춰야 할 두 번째 지표입니다. 대략적으로 말하자면, 배치 크기는 GPU를 통해 동시에 실행되는 요청의 수입니다.

H100 GPU는 최대로 1초에 3.35TB의 RAM을 그것의 레지스터로 이동시킬 수 있습니다. GPU 레지스터는 컴퓨팅 코어가 이후에 실행할 연산의 피연산자를 저장하는 빠른 온칩 메모리입니다.

데이터가 레지스터로 이동하는 동안, H100은 1.98경 개의 8비트 부동 소수점 숫자를 곱할 수 있습니다. 이 1.98경 개의 연산을 3.35TB의 이동된 데이터로 나눠보면, H100은 1바이트를 이동하는 데 걸리는 시간동안 591개의 부동 소수점 연산을 할 수 있습니다.

H100은 연산과 데이터 양 사이에 591:1 비율을 가집니다. 즉, 1GB 데이터를 처리할 때, 최소한 초당 5910억 번의 계산을 해야 합니다. 이보다 적게 하면 GPU의 계산 능력이 낭비되고, 더 많이 하면 데이터를 옮기는 데 시간이 걸립니다. 우리 모델에서 데이터의 양은 대체로 모델의 크기와 비슷하게 고정되어 있습니다. 그래서 우리는 수학적 계산량을 바꾸면서, 배치 크기를 조절함으로써 이 과정을 조금 제어할 수 있습니다.

ChatGPT를 크게 확장할 때, 우리는 GPU를 최대한 활용해야 했습니다. 이는 우리가 우리의 배치 크기를 주의 깊게 조절해서, GPU가 너무 적게 사용되지 않도록 하면서도, 메모리 대기 시간 때문에 너무 많이 사용되지 않도록 조절해야 한다는 뜻입니다.

실제로, 계산된 flop 숫자대로 계속 연산 속도를 유지하는 것은 거의 불가능합니다. 그래서 우리는 수학적 계산으로 비슷하게 접근할 수는 있지만, 모든 것을 정교하게 조정하기 위해 실제 환경에서 많은 시험을 해야 했습니다.

도전 과제 #3: 적절한 지표 측정하기

배치 크기와 KV 캐시 활용도의 조합이 우리가 집중한 주요 지표였습니다. 이 두 숫자를 사용하여 서버의 부하 상태를 판단했습니다. 이 지표에 도달하기까지 바로 시작부터 가능했던 것은 아니며, 이것이 우리에게 가장 잘 맞는다는 것을 알아내는 데 시간이 걸렸습니다.

처음에는, 표준 CPU 활용도 지표와 유사한, 더 단순한 GPU 활용도 지표를 가지고 있었습니다. 그러나 이는 단순히 해당 시간 동안 GPU가 수학적 계산을 수행하고 있는지만 알려주었기 때문에 오해의 소지가 있었습니다. 이는 우리에게 다음을 알려주지 않았습니다:

KV 캐시와 배치 크기 외에도 다른 병목 현상이 있었습니다. 실제 환경에서 우리는 여러 병목 현상을 경험했습니다:

이것들은 단지 일부에 불과합니다!

더 복잡하게 만드는 요소는 병목 현상의 위치가 자주 바뀐다는 것입니다. 예를 들어, ChatGPT에게 에세이를 요약하라고 요청하는 것과 하나를 쓰라고 요청하는 것은 성능 특성이 크게 다릅니다. 우리는 LLM 트랜스포머 모델 아키텍처의 구체적인 세부 사항을 지속적으로 조정하고 있으며, 이러한 변경 사항은 병목 현상이 발생하는 위치에 영향을 미칩니다.

LLM을 개발하고 운영할때 겪게 되는 문제나 한계가 생각보다 훨씬 다양하고 예측하기 어렵습니다. 그래서 우리가 문제를 해결하는 것을 어렵게 만들며, 칩 제조업체가 최적의 균형을 달성하는 칩을 설계하기 어렵게 만듭니다.

예를 들어, NVidia의 새로운 H100 칩은 A100 칩의 다음 세대입니다. H100은 계산 능력(즉, FLOPs)을 약 6배 증가시키는 반면, 메모리 크기는 동일하게 유지되고 메모리 대역폭은 오직 1.6배만 증가합니다. 우리가 자주 메모리에 의해 병목 현상을 겪는 상황에서, FLOPs의 극적인 증가(그리고 비용)는 대부분 활용되지 못하는 경향이 있습니다.

현실은 오늘날 최고급 칩인 NVIDIA H100 같은 것도 몇 년 전에 설계가 확정되었다는 것입니다. NVIDIA는 H100 칩을 설계할 당시 메모리의 중요성에 대한 발견을 알 수 없었으며, 미래의 아키텍처도 예측하는 것이 어려울겁니다. 최근에 발표된 H200 칩은 메모리가 증가하긴했지만, 업계가 LLM을 대규모로 실행할 때 이러한 메모리와 관련된 독특한 병목 현상을 이해하는 데는 시간이 오래 걸리기도 했습니다.

도전 과제 #4: 사용 가능한 GPU 찾기

GPU와 관련된 또 다른 도전은 바로 그것들을 어디에서 찾느냐 였습니다! 우리 회사는 물론 AI 분야가 전반적으로 NVIDIA나 TSMC 공급 체인 같은 공급업체들이 GPU를 생산할 수 있는 속도보다 훨씬 빠르게 성장했습니다. 그래서 반도체와 데이터 센터와 같이 복잡한 공급망에서는 GPU 공급에 관한 병목 현상이 발생하고 있습니다.

한 가지 해결책은 최대한 구할수 있는 곳에서 GPU를 구하는 것이었습니다. 우리는 마이크로소프트 애저를 클라우드 제공업체로 사용하는데, 애저에는 다양한 지리적 지역과 데이터 센터에 걸쳐 GPU가 많이 있습니다. 그 결과, 우리는 전 세계 여러 지역에서 빠르게 확장할 수 있게 되었습니다.

첫날부터, 우리 작은 팀은 여러 지역, 여러 클러스터, 전 세계적으로 분산된 환경으로 나아갈 수밖에 없었습니다. 그에따라 우리의 쿠버네티스 클러스터는 개별적으로 관리 되기 보다는 표준화 되고 자동화된 방식으로 관리되기 시작했습니다.

균형 잡힌 GPU Fleet을 만드는것이 근처의 GPU를 할당하는 것보다 더 중요한 우선순위가 되었습니다. 이유는 이렇습니다. ChatGPT의 경우, 가장 큰 응답 시간 병목 현상은 GPU가 한 번에 하나의 토큰을 얼마나 빨리 처리할 수 있는가에 달려 있습니다. 즉, 이는 지리적으로 최종 사용자에게 더 가까운 GPU가 덜 중요하다는 것을 의미합니다. 왜냐하면 네트워크 요청이 왕복하는 데 걸리는 시간보다 GPU가 "준비된 상태"인 것이 더 중요하기 때문입니다. 제 경력은 저에게 지연 시간 때문에 엣지 컴퓨팅의 중요성을 가르쳤습니다. 하지만 특히 GPU가 매우 제한적인 상황에서는 이런 과거의 접근 방식이 필요하지 않게되었습니다.

도전 과제 #5: 자동 확장이 불가능함

마지막으로 가장 중요한 과제는 GPU fleet을 자동 확장(Auto Scale)할 수 없다는 것이었습니다. 더 이상 구매하거나 대여할 GPU가 없기 때문에 오토스케일링할 GPU도 없는 상황입니다. GPU 확보의 어려움은 오늘날까지도 계속되고 있으며 완화될 기미가 보이지 않습니다. 현재 GPU 수요가 공급보다 더 크게 나타나고 있습니다. 더 많은 사용자가 있을 뿐만 아니라 더 큰 모델은 더 많은 컴퓨팅을 필요로 하며 에이전트와 같은 새로운 기술은 사용자당 훨씬 더 많은 컴퓨팅을 필요로 하는 상황입니다.

따라서 ChatGPT에서 "우리는 용량이 초과되었습니다"라는 메시지를 본 적이 있다면, 이는 말그대로 입니다. 현재 모든 GPU를 활용하고 있었기 때문에 더 이상 확장할 곳이 없다는 뜻입니다.

안타깝게도 GPT-4와 같은 모델은 연산량이 너무 많아서 현재로서는 대규모 서비스를 제공하기 위해 GPU가 유일한 옵션입니다. 일반 CPU는 훨씬 더 느립니다.

5. 교훈

ChatGPT 확장은 일반적인 소프트웨어 엔지니어링 확장 문제와는 분명 다릅니다. 하지만 엔지니어링 관점에서 다른 상황에도 적용할 수 있는 많은 교훈을 얻을 수 있는 과정이었습니다. 다음은 우리가 배운 주요 교훈입니다.

초기 확장시 숲과 나무가 모두 중요합니다.

글로벌 데이터센터 전략과 같은 상위 수준의 시스템 세부 사항(포레스트)만큼이나 KV 캐시 최적화 및 CUDA 커널과 같은 하위 수준의 세부 사항(트리)도 중요했습니다. GPU의 가장 낮은 레벨부터 제품 결정에 이르기까지 스택 전반을 넘나들 수 있는 팀의 역량이 중요했습니다.

적응형 방식으로 시스템의 제약을 고려하세요.

OpenAI에 합류하기 전에는 다음과 같은 일을 하는 데 익숙했습니다:

OpenAI에서는 이러한 관행들 중 어느 것도 적용할수 없었습니다! 측정과 확장이 모두 실용적인 새로운 접근 방식이 필요했습니다.

그리고 효과가 있는 무언가를 알아낼 때쯤이되면, 모델 아키텍처가 바뀌거나 새로운 추론 아이디어가 제안되거나 제품 결정으로 인해 시스템 사용법이 바뀌곤 했습니다. 따라서 우리는 계속해서 새로운 환경과 도전에 적응해야 했습니다.

깊이 파고들기.

우리가 다루는 문제 영역에서는, 가장 낮은 수준의 구현 세부 사항이 정말 중요합니다. ChatGPT를 텍스트를 입력으로 받아 다른 쪽 끝에서 조금 더 똑똑한 텍스트를 뱉어내는 '블랙박스'로 생각하기 쉽습니다. 하지만 이 '블랙박스'가 정확히 어떻게 작동하는지에 대해 더 많은 사람들이 세세한 부분까지 들여다볼수록 저희 팀과 제품은 더 나은 제품이 되었습니다.

아직은 초기 단계입니다.

도전의 규모는 점점 더 커질 것입니다. GPT-2, 3, 4로 넘어갈 때마다 모델을 대규모로 훈련하고 실행하는 완전히 새로운 방법이 필요했습니다. 이는 향후 버전에서도 계속될 것입니다. 시각, 이미지, 음성 등 새로운 양식을 도입하려면 시스템을 재설계하는 동시에 새로운 사용 사례를 발굴해야 합니다.

OpenAI와 생태계 전반의 개발 속도는 점점 빨라지고 있습니다. 앞으로 10배의 규모에 어떤 도전이 기다리고 있을지 지켜보겠습니다!

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요