구축을 넘어 활용으로: 인프라 효율의 중요성
소버린 AI를 개발하는 일은 막대한 비용을 감당해야 하는 승부입니다. Meta가 2025년 모델 카드에 공개한 자료에 따르면, Llama 4의 사전학습에는 H100 GPU 누적 738만 시간이 투입되었습니다. 이를 2026년 현재 클라우드 H100 임대 시세(시간당 약 2.5~3달러)로 단순히 환산하면 GPU 비용만 약 1,850만~2,200만 달러, 한화 250억~300억 원 규모인데요. GPU를 수백만 시간 가동하는 데만 수백억 원이 소요되는 시대에, 학습 속도를 단 1%라도 올리는 것은 기술적 성취를 넘어 수억 원을 절감하는 일입니다. 최고 사양의 인프라를 구축하는 것만큼이나, 그 인프라를 낭비 없이 활용하는 기술력은 팀네이버 소버린 AI 개발 역량의 중요한 경쟁력입니다. 최근 공개된 멀티모달 모델들의 사전학습 규모를 보면, 이 승부의 크기를 실감할 수 있습니다.
출처: 각 모델의 테크니컬 리포트 및 공식 모델 카드 기준
팀네이버는 자체 클러스터를 기반으로 대규모 LLM 학습 인프라를 운영하고 있습니다. 하지만 멀티모달 모델을 훈련할 때는 스케일을 확장하는 과정에서 예상치 못한 병목에 부딪혔습니다. 작은 모델에서는 탁월했던 훈련 속도가, 모델과 클러스터의 규모를 키울수록 기대만큼 빨라지지 않고 정체되는 현상이 나타난 것입니다. 인프라의 성능은 최상인데, 왜 정작 실전에서는 그 성능을 온전히 활용하지 못하는 것일까요?
원인은 뜻밖에도 GPU 간 연산 부하 불균형에 있었습니다. 한 대의 GPU가 늦어지면 나머지 수천 대가 하염없이 대기해야 하는 ‘Straggler(낙오자) 문제‘가 발생하고 있었고, 이것이 곧 막대한 비용 낭비로 이어지고 있었습니다. 저희는 이 문제를 포함한 학습 파이프라인 전반을 최적화해 30B MoE 멀티모달 모델 기준 학습 처리량을 총 50.2% 향상했습니다. 그중 이미지 토큰 불균형을 해결한 패킹·재분배 작업만으로 처리량이 13.3%가 향상되었습니다. 지금부터 이 보이지 않는 병목을 어떻게 찾아냈고, 모델의 품질 저하라는 기술적 타협 없이 해결했는지 그 여정을 공개합니다.
멀티모달 사전학습은 어떻게 이루어지는가: 순서를 바꿔도 결과는 같다
멀티모달 모델, 특히 시각과 언어를 연결하는 VLM(Vision-language Model)은 크게 두 가지 모듈로 구성됩니다. 첫째, 모델의 ‘사고‘를 담당하는 LLM입니다. LLM은 VLM은 물론 다양한 옴니모달 모델의 중추 역할을 하기에 백본(Backbone)이라고도 불리는데요 팀네이버는 국내 최초로 LLM을 오픈소싱한 바 있습니다. 둘째, 모델의 ‘눈‘ 역할을 하는 Vision Encoder입니다. 팀네이버는 이 역할을 하는 HyperCLOVA X CLIP 비전 인코더를 자체 개발해 멀티모달 모델에 적용하고 있습니다.
그림 1. VLM의 구조 (HyperCLOVA X 테크니컬 리포트에서 발췌). 이미지는 비전 인코더를 거쳐 이미지 토큰이 되고,
텍스트는 토크나이저를 거쳐 텍스트 토큰이 되어 하나의 시퀀스로 LLM에 입력됩니다.
이미지와 텍스트가 섞인 데이터가 입력되면, 이미지는 비전 인코더를 거쳐 이미지 임베딩으로, 텍스트는 토큰화 과정을 거쳐 텍스트 임베딩으로 변환됩니다. 여기서 이 글 전체를 관통하는 사실이 하나 나옵니다. 이미지 조각에 대응하는 토큰을 ‘이미지 토큰‘, 텍스트 조각에 대응하는 토큰을 ‘텍스트 토큰‘이라 부르는데, LLM의 연산량은 이 둘의 총합(전체 토큰 수)으로 결정되고, 비전 인코더의 연산량은 오직 이미지 토큰 수를 따라갑니다.
AI 모델을 대규모로 학습시킬 때는 데이터 병렬(Data Parallelism) 방식을 사용합니다. 학습 데이터를 수천 개의 조각으로 나누어 수천 대의 GPU가 동시에 계산하고, 각자 구한 결과(Gradient)를 모두 합산해 전 GPU가 동일한 값으로 모델을 업데이트하는 방식입니다. 이 합산 통신을 All-reduce라고 부르는데, 모든 GPU가 참여해야 끝나는 동기화 지점이기도 합니다. 특히 멀티모달 훈련에서는 읽어야 할 데이터가 텍스트보다 훨씬 크기 때문에, 각 GPU가 자신에게 할당된 데이터 조각을 연속적으로 읽도록 설계합니다. 같은 데이터를 중복해서 읽지 않고 연속된 파일을 읽으니 I/O가 빨라지는 설계인데, 뒤에서 보겠지만 이 설계에는 한 가지 함의가 있습니다. 어떤 GPU가 이미지가 많은 데이터를 맡게 될지는 순전히 운에 달려 있다는 점입니다.
여기에 Gradient Accumulation 기술이 더해집니다. GPU 메모리 한계로 한 번에 처리할 수 있는 데이터양이 제한적일 때, 전체 배치(Global Batch)를 여러 개의 작은 Micro-batch로 나누어 순차적으로 계산하고, 각 단계의 Gradient를 모아두었다가(Accumulate) 지정된 횟수만큼 쌓인 후 모델 가중치를 한 번에 업데이트하는 기법입니다. 쉽게 말해, 큰 그림을 한 번에 스캔할 스캐너가 없어 여러 조각으로 나눠 스캔한 뒤 이어 붙이는 것과 비슷합니다. 조각내 처리했을 뿐, 결과는 원본을 통째로 스캔한 것과 똑같습니다.
그림 2. 한 번의 가중치 업데이트는 GPU 수(DP) × 누적 횟수(GA) 개의 Micro-batch로 이루어지며,
모든 칸의 Gradient를 더해 한 번에 반영합니다.
그림 2에서 기억해 둘 점은 하나입니다. 한 번의 업데이트에 들어가는 계산은 결국 모든 칸의 Gradient를 더하는 것이고, 덧셈은 순서를 바꿔도 결과가 같다는 것입니다. 멀티모달 학습의 병목은 데이터 I/O, 비전 인코더 연산 효율 등 여러 곳에 있지만, 이 블로그에서는 그중 가장 발견하기 어렵고 최적화하기 어려웠던 병목, GPU 간 연산 부하 불균형에 집중합니다.
1. Sequence Packing: 상자에 빈틈없이 눌러 담기
본격적인 불균형 이야기에 앞서, LLM 백본 훈련 최적화를 위해 패킹을 사용하는 이유부터 짚고 가겠습니다. 패킹이란 길이가 제각각인 학습 데이터를 정해진 크기의 ‘상자(고정 길이 시퀀스)’에 빈틈없이 담아 GPU가 처리할 일감 단위로 만드는 과정입니다. 크기가 다른 짐을 상자에 요령껏 눌러 담아 빈 공간을 줄이는 것과 비슷하죠. 그렇다면 왜 굳이 이렇게 꽉꽉 채워야 할까요?
초거대 모델 학습에서 연산의 대부분은 LLM 백본에서 발생하기 때문인데요. 훈련 비용을 결정짓는 핵심은 결국 LLM이 얼마나 낭비 없이 꽉 찬 데이터를 계산하느냐에 달려 있고, 빈 공간을 최소화해 데이터 밀도를 높이는 Sequence Packing은 가장 기초적이면서도 강력한 최적화입니다.
문제는 학습 데이터의 길이가 제각각이라는 점인데요. 학습 데이터의 샘플 길이, 즉 하나의 학습 예시 길이는 수십 배까지 차이가 나지만, 훈련할 때는 같은 길이로 맞춰 주어야 합니다. 짧은 샘플을 고정 길이에 맞추려고 빈 공간, 즉 패딩을 넣으면 연산 낭비가 심합니다. 아래 그림 3의 예시처럼 길이가 1,200~4,200 토큰으로 제각각인 샘플들을 하나의 배치로 모으면, 패딩 비율은 약 40%에 이릅니다. 상자의 40%를 허공으로 채워 나르는 셈이죠. 한편 일반적인 LLM 학습 방식인 ‘스트림‘(샘플들을 이어 붙이고 시퀀스 길이대로 자르는 방식)을 쓰면 이미지가 시퀀스 경계에서 잘리는 문제가 생깁니다. 텍스트는 중간에서 잘라도 되지만, 이미지는 한 덩어리라 중간에서 자를 수 없기 때문입니다.
그래서 저희는 모든 실험에서 Greedy Bin-packing 방식을 사용합니다. 고정된 길이의 시퀀스를 온전한 샘플들로 채워 패딩을 최소화하는 방식인데요. 샘플 단위로 패킹이 수행되므로 이미지가 경계에서 잘리지 않고, 8K 시퀀스 길이에서 99.4%라는 매우 높은 패킹 효율(전체 토큰 중 실제 데이터가 차지하는 비율)을 달성합니다.
그림 3. 배치 내 최대 길이에 맞춰 패딩 해도 샘플 길이가 제각각이면 상당량이 낭비되고 배치마다 연산량이 달라지지만(위), 고정 길이 시퀀스에 Greedy Packing을 적용하면 99% 이상을 실제 데이터로 채우면서 연산량도 균일해집니다(아래).
텍스트만 학습하던 시절에는 이것으로 충분했습니다. 모든 GPU의 시퀀스가 같은 길이로 꽉 차 있으면 연산량도 같고 계산 시간도 같으니, 서로 기다릴 일이 없었으니까요.
2. 같은 상자, 다른 무게: 이미지가 만든 멀티모달의 복병
그런데 모델이 이미지를 함께 학습하기 시작하면서 비전 인코더 연산량의 불균형이 보이기 시작했습니다. 앞서 짚었듯 LLM의 연산량은 텍스트와 이미지를 합친 전체 시퀀스 길이로 정해지므로 Pack 길이가 같으면 모든 GPU가 동일한데요. 하지만 비전 인코더의 연산량은 Pack에 담긴 이미지 토큰 수를 따라갑니다. 즉 이미지 토큰이 많은 Pack을 받은 GPU는 비전 인코더 계산이 그만큼 오래 걸린다는 뜻이죠.
여기서 패킹의 맹점이 드러납니다. Greedy Packing은 전체 토큰 수만 보고 채울 뿐, 그 안에 이미지 토큰이 얼마나 들었는지는 전혀 고려하지 않습니다. 그 결과 어떤 GPU의 Pack에는 이미지(이미지 3,000 토큰)가 잔뜩, 어떤 GPU의 Pack에는 거의 텍스트(이미지 500 토큰)만 담기는 일이 생깁니다. 같은 크기의 상자라도, 하나엔 벽돌(이미지)이 가득하고 다른 하나엔 솜(텍스트)이 가득한 셈이죠. 부피는 똑같아도 실어 나르는 무게는 천차만별입니다.
그림 4. 두 Pack 모두 토큰 수는 꽉 차 있지만 이미지 토큰 양은 6배 차이가 납니다.
두 Pack의 길이는 8,192 토큰으로 완전히 같지만, 연산량은 전혀 다릅니다. 실제 측정에서 이미지 3,000 토큰짜리 Pack을 받은 GPU는 비전 인코더 Forward에만 900ms, 500 토큰짜리를 받은 GPU는 200ms가 걸렸습니다. 시작부터 이미 700ms 차이가 나는 거죠. 문제는 이 격차가 한 번 더 벌어진다는 점인데요. 한 번의 학습 스텝은 비전 인코더 Forward → LLM Forward → LLM Backward → 비전 인코더 Backward로 이어지고, 모든 GPU가 결과를 맞추려고 한자리에 모이는 지점인 Gradient 동기화 Barrier는 그 맨 끝에 있습니다. 이 중 LLM 구간은 길이가 같아 두 GPU가 동일한 반면, Backward 연산은 보통 Forward의 약 2배이므로 비전 인코더 Backward에서 같은 비율로 격차가 한 번 더 벌어집니다. 결국 Barrier에 먼저 도착한 GPU, 다시 말해 먼저 계산이 끝난 GPU는 이 누적 격차만큼 가장 느린 GPU가 도착할 때까지 하염없이 기다릴 수밖에 없는 것이죠.
그림 5. 비전 인코더 Forward에서만 700ms의 격차가 생깁니다(위).
동기화 Barrier는 LLM Forward, Backward와 비전 인코더 Backward까지 모두 마친 단계의 맨 끝에 있으며,
Backward에서 같은 비율로 격차가 한 번 더 벌어지므로 실제 대기는 이보다 큽니다(아래).
GPU가 2장이면 그나마 낫습니다. 1,024장이 함께 학습하면 이미지 토큰이 가장 많은 Pack을 받은 단 한 장이 전체의 속도를 결정합니다. GPU가 많아질수록 그중 한 장은 매우 무거운 Pack을 받을 확률이 올라가기 때문이죠. 실측 데이터 기반 시뮬레이션에서도 이 경향은 뚜렷했는데요. 느린 GPU를 기다리느라 낭비되는 시간은 LLM 모델 크기와 GPU 규모가 커질수록 전체 학습 시간의 50%에서 80% 가까이까지 치솟았습니다. 텍스트 기반 사전학습에서는 훈련 규모를 키워도(Scaling) 연산량 불균형이 크게 드러나지 않았지만, 멀티모달 훈련에서는 이 불균형이 훈련 규모를 키우는 것 자체를 가로막는 셈입니다.
3. 첫 번째 시도: 부피만 보던 상자에 ‘무게’도 더하기 (2D 패킹)
각 GPU, 정확히는 데이터를 나눠 맡은 Data Parallel Worker는 자신에게 할당된 데이터만 볼 수 있습니다. 이 상황에서 가장 먼저 떠오르는 해법은 각자의 패킹 단계에서 토큰 수뿐 아니라 이미지 토큰 수도 함께 검사하는 것입니다. 쉽게 말해 상자를 채울 때 부피뿐만 아니라 무게도 같이 보자는 것이죠.
기존 Greedy Packing이 ‘토큰 길이‘ 하나만 보고 채운다는 뜻에서 1D 패킹이라면, 여기에 ‘이미지 양‘이라는 축을 하나 더 얹은 것이 2D 패킹입니다. 방법은 단순한데요. Pack마다 이미지 토큰 ‘예산‘을 정해 두고, 예산을 넘기면 이미지가 많은 샘플은 그 Pack에 넣지 않는 방식입니다. 이 방식이 잘 작동한다면 Worker들이 서로 데이터를 교환하는 노력 없이도 불균형을 해결할 수 있다는 기대가 있었습니다. 효과를 검증하기 위해 실제 학습 데이터의 총길이와 이미지 토큰 수를 실측한 값으로 여러 방법을 시뮬레이션해 보았습니다.
그런데 이 방법에는 큰 문제가 있었습니다. 바로 시퀀스를 꽉 채우지 못한다는 점이었는데요. 이미지가 많은 샘플을 자꾸 배제하다 보니 빈 공간이 남기 시작한 것입니다. 패킹 효율이 99%에서 66%로 추락했습니다. 매 스텝 토큰 용량의 34%를 비워 둔 채 학습하게 된 셈이니, 패딩 낭비를 없애려고 도입한 패킹의 취지가 무색해집니다.
그럼 재료를 고를 후보(Buffer)를 수천 개로 늘리면 되지 않을까요? 패킹에 쓰는 버퍼를 수천 개 샘플로 키워도 이 문제는 사라지지 않았습니다. 각 Pack은 토큰 공간이 남아 있어도 이미지 예산이 먼저 바닥나기 때문인데요. 그 빈 공간을 채우려면 이미지가 거의 없는 샘플이 필요하지만, 멀티모달 학습 데이터의 대부분은 이미지를 포함하므로, 후보를 아무리 늘려도 조건에 맞는 샘플이 늘 부족했습니다.
그림 6. 이미지 예산을 추가하면 Pack 간 이미지 토큰은 균형을 이루지만,
토큰 공간보다 이미지 예산이 먼저 소진되어 패킹 효율이 66%로 떨어집니다.
버퍼를 수천 개로 키워도 빈 공간을 채울 이미지 없는 샘플이 부족해 이 문제는 사라지지 않습니다.
그렇다면 이미지 예산을 넉넉하게 키우면 되지 않을까요? 예산을 키우면 패킹 효율은 99%로 돌아오지만, 이미지가 많은 샘플들이 다시 한 Pack에 몰리면서 불균형도 함께 돌아옵니다. 예산을 무한히 키운 극한이 바로 앞서 본 1D Greedy Packing입니다. 결국 이미지 예산은 ‘균형은 좋지만 낭비가 큰 쪽‘과 ‘꽉 차지만 불균형한 쪽‘ 사이를 오가는 다이얼일 뿐, 두 목표를 동시에 만족하지 못합니다.
각 GPU가 자기 Pack의 계산 순서만 바꾸는 Local Reordering 등 다른 변형들도 시뮬레이션으로 비교해 봤지만, ‘각 GPU가 자기 데이터 안에서만 해결하려는 시도’에는 공통된 한계가 있었습니다. 학습 초반에는 효과가 있다가 스텝이 쌓일수록 GPU 간 균형이 어긋나며 효과가 사라졌고, GPU 수가 많아질수록 더 빨리 무력화됐습니다.
결론은 분명했습니다. 상자를 어떻게 구성하든, 계산 순서를 어떻게 바꾸든, 한 GPU가 자기 데이터 안에서만 해결하려는 접근에는 한계가 있다는 것이었습니다. 이제 시야를 여러 GPU ‘사이‘의 배치 문제로 넓혀야 했습니다.
4. 상자를 다시 만들지 말고, GPU끼리 바꿔 들자
해답은 딥러닝의 기본기에서 나왔습니다. 딥러닝 모델은 데이터 묶음(Batch)으로 Gradient를 계산하고, 각 데이터에서 나온 Gradient를 모두 더해 평균 낸 뒤 가중치를 한 번에 고칩니다. 앞서 그림 2에서 봤듯이, 이러한 계산은 더하는 순서를 바꿔도, 또 어느 GPU에서 계산하든 수학적으로 결과는 달라지지 않죠.
여기서 발상이 나옵니다. 굳이 패킹을 다시 할 필요가 없습니다. 각 GPU가 자기 상자를 새로 짜거나 순서를 바꾸는 대신, 이미 99% 꽉 채워 둔 상자들은 그대로 두고 계산 직전에 GPU끼리 상자만 서로 바꿔 드는 거죠. 그래서 계산 단위(Micro-batch) 전반에 걸쳐 무거운 상자(이미지 토큰이 많은 Pack)와 가벼운 상자(이미지 토큰이 적은 Pack)가 골고루 나뉘도록, 즉 Micro-step마다 GPU의 부하가 비슷해지도록 하는 것입니다.
동작 방식은 이렇습니다. Global Batch(가중치 업데이트 1회 분량)마다 각 GPU가 자신이 받은 Pack들의 이미지 토큰 수를 공유하고(All-gather), 모든 GPU가 동일한 규칙으로 최적의 배치를 계산한 뒤, 그 결과대로 Micro-batch 단위로 Pack을 교환합니다.
배치 계산은 두 단계로 이루어집니다.
- Pack이 처음에 어디 있었는지는 무시하고 연산량 균형만 고려한 최적 배치를 계산
- Pack들의 원래 위치를 고려해 같은 균형 효과를 내면서도 실제로 옮겨야 하는 데이터양을 최소화하는 배치를 찾기. 이미 제자리에 있는 Pack은 통신을 아예 생략함.
이 방식의 가장 큰 장점은 학습에 아무런 영향이 없다는 점입니다. 데이터도, 모델도, 학습 결과도 전혀 바뀌지 않습니다. 바뀌는 것은 오직 ‘누가 언제 무엇을 계산하느냐‘뿐이죠.
그림 7. 하나의 Global Batch 안에서 Pack을 GPU 간에 재배치하는 모습.
무거운 Pack은 무거운 것끼리 같은 Micro-step에 모으면서 GPU별 총 이미지 부하도 균등하게 나누므로,
계산 결과는 수학적으로 동일하고 스텝마다 발생하던 대기만 사라집니다.
5. 재배치도 무료는 아니다: 통신을 계산 시간 뒤에 숨기기 (Overlap)
다만 Pack 재배치에는 비용이 따릅니다. 각 GPU가 Pack의 이미지 토큰 수를 공유하는 All-gather는 Pack당 정수 몇 개, 전체를 합쳐도 킬로바이트 수준이라 매우 가볍지만, 재배치 결과에 따라 Pack 데이터 자체를 GPU 간에 주고받는 통신은 훨씬 무거운데요. 이 통신을 매번 계산이 끝난 뒤에 순서대로 처리하면, 애써 Straggler 대기를 줄여 번 시간을 고스란히 통신 시간으로 되돌려주는 셈이 됩니다.
해법은 이 통신을 GPU 계산 시간 뒤에 숨기는 것입니다. GPU가 현재 Micro-batch의 Forward/Backward를 계산하는 동안, 뒤에서는 별도의 일꾼인 백그라운드 스레드와 별도 통신 통로인 CUDA 스트림이 다음 Micro-batch에 쓸 Pack들의 재배치를 미리 진행합니다. GPU가 계산을 마치는 시점에는 균형 잡힌 다음 Pack이 이미 도착해 있으므로, 재배치 비용이 학습 시간에는 거의 드러나지 않죠. 이렇게 계산과 통신을 겹쳐 진행하는 기법을 Computation-communication Overlap이라고 부릅니다. 예를 들어 오븐이 돌아가는 동안 다음 재료를 미리 손질해 두면, 전체 조리 시간이 재료 손질 시간만큼 늘지 않는 것과 같은 이치입니다.
그림 8. 순차 실행에서는 GPU 간 Pack 재배치가 끝날 때까지 모든 GPU가 대기하지만(위),
오버랩을 적용하면 현재 Micro-batch를 계산하는 동안 다음 Micro-batch의 Pack 재배치(그림 7)가
백그라운드에서 진행되어, 통신 시간이 스텝 시간에서 사라집니다(아래).
이 오버랩이 얼마나 중요한지는 수치가 말해줍니다. 뒤에서 소개할 프로덕션 규모 실험에서 재배치를 동기 방식으로, 즉 통신이 끝날 때까지 기다리며 수행하면 개선 폭은 1.7%에 그쳤습니다. 같은 재배치를 오버랩과 함께 비동기로 수행하자 개선 폭은 13.3%까지 올라갔습니다. 균형을 맞추는 알고리즘 못지않게, 그 비용을 숨기는 엔지니어링이 이득의 대부분을 만든 것입니다.
물론 아이디어가 간단하다고 구현까지 쉬운 건 아니었습니다. 실제로 저희는 백그라운드 스레드가 작업을 마친 뒤 정리(Join)되지 않아 자원이 조금씩 쌓이는 Memory Leak을 겪었습니다. 이런 버그는 수백 스텝짜리 짧은 벤치마크에서는 전혀 드러나지 않았다가, 수천 스텝을 넘긴 장시간 학습에서야 서서히 속도 저하로 나타납니다. 장시간 스트레스 테스트로 원인을 찾아 패치한 뒤에야 학습 속도가 안정화되었습니다. 학습 최적화에서 아이디어는 절반이고, 나머지 절반은 이런 검증과 디버깅입니다.
6. 결과: 학습 결과는 그대로, 속도는 더 빠르게
오버랩까지 적용한 최종 구현을 작은 규모부터 실제 프로덕션 규모까지 단계적으로 검증했습니다.
- Loss 곡선은 완전히 동일: 계산 순서만 바꿨으니 당연한 결과이지만, 실험으로도 확인했습니다.
- 프로덕션규모 검증: 실제 사전학습에 쓰는 데이터(100여 개 소스, 2조 토큰 이상)와 30B MoE VLM, B200 멀티 노드 환경에서 패킹·재배치 최적화는 같은 시간에 처리하는 학습량인 Throughput를 13.3% 향상했습니다. 동기 방식 재배치만으로는 1.7%에 그쳤으니, 이득의 대부분은 오버랩에서 나온 셈입니다.
추가로 LLM이 커질수록 전체 연산에서 비전 인코더의 비중이 줄어들기 때문에 개선 폭 자체는 작아집니다. 그럼에도, 수백만 GPU 시간이 투입되는 대규모 사전학습에서 두 자릿수 개선은 결코 작은 숫자가 아닙니다. 무엇보다 이 개선은 모델 품질을 조금도 희생하지 않고 얻은 결과라는 점이 중요합니다.
마치며
멀티모달 시대의 학습 최적화는 텍스트 시대와는 다른 질문을 던집니다. 시퀀스를 얼마나 빈틈없이 채우느냐만이 아니라, 연산 부하가 GPU들에 어떻게 나뉘느냐까지 고민해야 하죠. 이 글에서 다룬 이미지 토큰 불균형 해소는 그 질문에 대한 저희의 답 중 하나입니다.
균형 재배치는 저희가 진행한 네 가지 최적화 영역(저장소 I/O, 시퀀스 패킹, 비전 인코더, 분산 학습) 가운데 시퀀스 패킹과 분산 학습에 걸쳐 있는 작업이기도 합니다. 네 영역을 합치면 30B MoE VLM 기준 학습 처리량이 총 50.2% 향상했습니다.
막대한 비용이 드는 대규모 학습에서, 최고 사양의 인프라를 갖추는 것만큼이나 그 인프라를 낭비 없이 끌어 쓰는 기술력이 점점 더 중요해지는 이유입니다. 이런 효율은 한 번의 개선으로 끝나지 않습니다. 이를 통해 절감한 비용과 시간은 다시 더 큰 모델과 더 다양한 실험에 투자되고, 그렇게 확보한 여력이 다음 도전의 출발선을 끌어올리죠. 그렇기 때문에 오늘 소개한 최적화들은 단순한 학습 속도 개선을 넘어, 같은 인프라로 더 크고 더 다양한 멀티모달 모델에 도전할 수 있는 토대를 마련했다는 데 의미가 있습니다. 네이버클라우드는 실제 대규모 학습 현장에서 마주하는 문제들과 그 해결 과정에서 얻은 인사이트를 앞으로도 꾸준히 공유하겠습니다. 앞으로도 네이버클라우드의 연구와 HyperCLOVA X 모델의 진화에도 많은 관심 부탁드립니다.