跳到正文
NAVER / CLOVA 研究·· 2026-08-13AI 评分41

NAVER 如何解决多模态 AI 训练中的图像 token 不均衡问题

속도와 비용의 열쇠: 멀티모달 AI 학습을 갉아먹는 ‘이미지 토큰 불균형’ 이야기

AI 导读

NAVER 团队在 NVIDIA Megatron Bridge 上训练 HyperCLOVA X 多模态模型时,发现图像 token 分布不均导致 GPU 间负载失衡,拖慢整体训练。通过引入 2D 打包等优化,30B MoE 多模态模型训练吞吐量提升 50.2%,其中打包与重排单项贡献 13.3%,相关修改已贡献至 Megatron Bridge 开源项目。

正文 · 原文

구축을 넘어 활용으로: 인프라 효율의 중요성

소버린 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(낙오자) 문제‘가발생하고있었고, 이것이곧막대한비용낭비로이어지고있었습니다.  네이버클라우드는 이런 문제들을 프레임워크 레벨에서 NVIDIA와 함께 풀어왔습니다. 대규모 학습 프레임워크의 병렬화 전략은 그동안 텍스트 전용 LLM을 중심으로 발전해 왔는데요. 그래서 패킹된 멀티모달 시퀀스라는 새로운 워크로드에서는 지금도 최적화 연구가 활발히 진행되고 있습니다. 저희는 오픈소스 학습 프레임워크인 NVIDIA Megatron Bridge 위에서 HyperCLOVA X 멀티모달 모델들을 학습하며 쌓은 노하우로 학습 파이프라인의 최적화 방향을 도출했습니다. 그 결과 30B MoE 멀티모달 모델 기준 학습 처리량을 총 50.2% 향상시켰으며, 이 과정에서 나온 수정 사항들을 Megatron Bridge 오픈소스에 기여했습니다. 네 가지 최적화 영역 전체의 기술적 상세는 NVIDIA 개발자 블로그에서 확인하실 수 있습니다.

이 글에서는 그 중 패킹·재배치 영역, 즉 이미지 토큰 불균형 문제를 자세히 다룹니다. 이 작업만으로 학습 처리량이 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을 교환합니다.

배치계산은두단계로이루어집니다.

  1. Pack이처음에어디있었는지는무시하고연산량균형만고려한최적배치를계산
  2. 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 모델의진화에도많은관심부탁드립니다.

来源:NAVER / CLOVA 研究 · clova.ai