태그 : LLM
한국 문화를 담은 AI 이미지 생성 모델, KIMCHI 개발 이야기
By 권용근들어가며
래블업 리서치팀은 Backend.AI를 활용하여 다양한 사례를 만드는 일을 하고 있습니다. Backend.AI 내부의 CLI command를 사용자의 지시 사항에 맞도록 자동으로 생성하는 AI Agent를 개발하기도 하고, 각종 행사에 사용되는 간단한 데모를 만들기도 합니다. 예를 들어, 사용자 사진을 활용한 이미지 및 동화 생성 서비스 'VisuTale'도 저희 리서치팀의 작품입니다. VisuTale은 다양한 행사에서 Backend.AI를 이용하여 개발할 수 있는 AI 서비스의 예시로 관람객들의 시선을 한눈에 받았습니다.
최근 리서치팀 내부에서 연구를 진행하던 중, AI 기반 이미지 생성 모델이 특정 문화적 맥락이나 언어를 제대로 반영하지 못하는 경우가 많다는 사실을 확인했습니다. 이는 글로벌 AI 모델들이 대체로 영어 기반으로 학습되거나, 일반적인 범용 도메인 데이터에 기반하여 학습되는 경우가 많기 때문입니다. 프롬프트에 특정 지역, 혹은 문화에 대한 내용을 입력하면 고유한 특성이 제대로 표현되지 않는 경우가 많죠. 리서치팀에서 다양한 모델을 대상으로 실험해본 결과, 한국어 텍스트 프롬프트를 활용하여 이미지를 생성할 때 한국의 정체성이 이미지에 충분히 드러나지 않는 이슈가 있었습니다.
예를 들어, Stable Diffusion v1.5와 DALL-E 3와 같은 유명한 모델들은 한국어 텍스트 프롬프트를 제대로 해석하지 못하거나, 생성된 이미지에서 한국의 정체성을 충분히 반영하지 못한다는 문제를 보여줍니다.
- Stable Diffusion v1.5는 “한국의 라면을 그려줘”라는 한국어 프롬프트를 입력했을 때, 라면 대신 건물 이미지를 생성했습니다. 이는 해당 모델이 한국어 입력을 제대로 처리하지 못했음을 보여줍니다.
- DALL-E 3는 동일한 프롬프트로 면 요리 이미지를 생성하긴 했지만, 한국의 라면이 아니라 일본의 라멘에 가까운 이미지를 생성하며 한국적인 색채를 담아내지 못했습니다.
영어로 프롬프트를 입력하는 것 또한 해답은 아닙니다. 한국어 프롬프트를 영어로 번역하는 과정에서 일대일로 대응되는 단어가 없거나, 번역기가 문맥을 이해하지 못해 제대로 된 번역을 내놓지 못하기도 합니다. 예를 들어 "고추장진미채볶음" 이라는 음식을 번역기에 입력하면 "stir-fried vegetables with red pepper paste"라는, 다소 음식에 대한 정확하지 않은 번역을 내놓습니다.
이에 대한 해결책으로, 한국의 문화와 정체성을 온전히 반영하는 이미지 생성 모델 **KIMCHI (Korean dIffusion Model adapting Culture and HIstory)**가 탄생하게 되었습니다.
'KIMCHI' 담그기
Attached Image Source: Wikipedia & Lotte Group
래블업은 CES, MWC, GTC, SC 등 다양한 해외 행사 및 컨퍼런스에 참여하고 있기 때문에 다양한 데모를 선보일 기회가 정말 많습니다. 이런 상황에서 'KIMCHI'는 문화 특화형 AI 모델의 좋은 사례로 사용될 수 있을 것으로 생각합니다. 래블업의 'KIMCHI'가 문화적 특색을 반영한 맞춤형 이미지를 실시간으로 생성하는 모습을 보여준다면, 해외에서 이목을 끌고 브랜드의 차별성을 효과적으로 알릴 수 있을 것입니다. 더 나아가, KIMCHI는 각종 행사에서 마케팅 자료로도 활용하며 차별화된 콘텐츠를 제공할 수 있는 가능성 또한 열려 있습니다.
'KIMCHI'는 두 가지 목표를 가지고 개발되었습니다. 1. 한국어 프롬프트를 직접 이해하고 번역 과정을 거치지 않더라도 정확하게 이미지를 생성해내는 것. 2. 한국 문화와 정체성을 반영한 이미지를 생성하는 것. 이 두가지 목표를 모두 달성한다면, 위에서 예시로 사용한 "한국의 라면을 그려줘" 혹은 "한국의 롯데월드타워를 그려줘" 라는 프롬프트에 각각 한국적인 라면과 한국 도심지에 서 있는 롯데월드타워를 생성해낼 수 있을 것입니다.
이번 글에서는 이러한 'KIMCHI' 모델의 개발 과정과 함께 데이터셋 전처리 프레임워크 한계점을 소개합니다.
데이터셋 준비
'KIMCHI' 모델의 학습에는 AIHub에서 수집한 Korean Food Dataset, Korean Historical Building and Landmark Dataset, 한국형 이미지가 포함된 외부 지식 기반 멀티모달 질의응답 데이터와 같은 데이터셋이 사용되었습니다.
데이터 전처리 과정
1. VLM(Vision Language Model) Processing: 첫번째로, 준비한 이미지를 LLaVA라는 VLM의 Input으로 프롬프트와 함께 넣어주게 됩니다. 여기서 VLM은 이미지와 텍스트를 함께 이해할 수 있는 멀티모달 AI 모델입니다. 즉, 이미지 안에 담긴 정보를 분석하고, 그 내용을 사람이 이해할 수 있는 텍스트로 바꿔주는 역할을 합니다. 예를 들어, 한 장의 사진을 보고 "A plate of food with a red sauce and a green vegetable." 이라는 영어 캡션을 만들어내는 것입니다. 2. LLM(Large Language Model) Refinement: 그렇게 만들어진 영어 캡션은 언어 모델인 LLaMA에 전달됩니다. LLaMA는, 기존의 영어 캡션을 좀 더 자세하고 정확한 한국어 설명으로 바꿔주는 역할을 하게됩니다. 기존의 영어 캡션이 "A plate of food with a red sauce and a green vegetable."로 이미지에 대한 시각적 정보만을 담고 있었다면, LLaMA는 그것을 "흰색 접시에 놓인 빨간 소스로 버무려진 청갓으로 만든 한국의 전통 요리인 갓김치" 라는 한국어 문장으로 바꿔주게 됩니다.
이 두 과정을 통해, 기존의 이미지를 잘 설명할 수 있는 한국어 캡션이 만들어집니다. 이렇게 만들어진 캡션은 이후 이미지 생성 모델 학습에 사용됩니다.
모델 학습
이러한 과정에서 생성된 한국어 설명은 텍스트 프롬프트로 사용되며, Diffusion 모델의 학습에 활용되었습니다.
위 이미지에서는 갓김치 이미지에 대해 “흰색 접시에 놓인 빨간 소스로 버무려진 청갓으로 만든 한국의 전통 요리인 갓김치”라는 한국어 설명을 얻었습니다. Diffusion Model을 full finetuning 하는 것은 매우 비용이 많이 드는 작업이므로, 학습 효율성을 높이기 위해 LoRA(Low-Rank Adaptation) 기법을 적용하였고, 한국어 프롬프트를 인코딩 하기 위해 Korean-CLIP 모델의 텍스트 인코더를 사용하였습니다. 이때 Korean-CLIP 모델은 CLIP 모델을 Korean-English parallel 데이터에 추가로 학습한 모델입니다. 이러한 과정을 통해 모델을 추가로 학습시켜, 한국어 프롬프팅이 가능하고 한국의 문화를 자연스럽게 반영하여 이미지를 생성할 수 있는 'KIMCHI'를 개발할 수 있었습니다.
실험 및 성능 평가
이미지 생성 실험
Experiment (1) - 문화적 요소 표현
위의 비교 실험은 실제 이미지와 함께 DALL-E 3, ChatGPT-4o, Stable Diffusion 2.1(영어 번역 프롬프트 사용), 그리고 KIMCHI 모델이 동일한 한국어 프롬프트를 기반으로 이미지를 생성했을 때의 결과입니다.
다른 모델들 또한 우수한 성능을 보여주지만, KIMCHI는 부자연스러운 모습 없이 음식의 식감과 재료, 전통 건축물의 디테일 등을 잘 반영하고 있습니다. 이는 KIMCHI가 한국어 텍스트를 정확히 이해하고, 번역 과정 없이도 자연스러운 한국적 이미지를 생성할 수 있도록 학습되었다는 것을 의미합니다.
Experiment(2): 일반 이미지 생성 능력 보존
위의 이미지는 KIMCHI가 학습 이후에도 Pretrained model의 생성 능력을 유지하는지에 대한 검증에 대한 결과입니다. KIMCHI는 Stable Diffusion 1.5를 Base model로 활용하여 학습했기 때문에, 함께 비교했습니다.
성능 평가
Result(1): 문화적 요소 표현
실험 이후, 이미지 생성 결과에 대해 평가를 진행했습니다. 평가는 53명의 평가자에게 설문을 통해 진행되었고, 평가자들은 각 모델의 생성 이미지에 대해 위의 항목별로 [매우 그렇다 ~ 매우 그렇지 않다]의 5개 선지 중 하나를 선택했습니다. 이후 평가자의 응답을 1~5점으로 환산하여 각 항목별로 평균값을 측정했습니다.
위의 표는 Experiment(1)에 대한 실험 결과를 표로 나타낸 것입니다. KIMCHI는 Text-Image Alignment, Reality, Domain-Specific Suitability 에서 다른 모델들을 모두 앞서는 성능을 보여주었습니다. 이는 KIMCHI가 한국어 프롬프트를 잘 반영하여, 실제 이미지에 근접한 이미지를 잘 생성했다는 것을 의미하며 문화적 요소 또한 잘 반영하고 있다는 것을 의미합니다.
Result(2): 일반 이미지 생성 능력 보존
위의 표는 Experiment(2)에 대한 Human Evaluation을 통한 평가 결과입니다. Base model인 Stable Diffusion 1.5와 비교했을 때 근소한 차이이지만 Text-Image Alignment, Error Detection에서 뒤쳐지는 결과를 보였습니다. 이는 KIMCHI가 특정 도메인에 특화된 학습을 하는 과정에서 해당 도메인에 집중한 결과 일반적인 이미지에 대한 생성 능력이 다소 감소하였음을 나타냅니다. 하지만 Reality 성능은 잘 보존하고 있는 것을 확인할 수 있었습니다.
한계점 및 결론
한계점
KIMCHI는 Stable Diffusion v1.5를 Base model로 활용하여 fine-tuning된 모델입니다. Stable Diffusion v1.5는 2022년 10월 공개된 모델로, 지금으로부터 2년이 지난 오래된 모델입니다. 따라서 fine-tuning을 한다고 해도 이후에 나온 최신 버전의 모델에 비해 이미지 성능이 높지 않을 수 있습니다. 또한, 한국어 프롬프트를 이해할 수 있도록 이해 능력을 학습시킬 수는 있지만, Text-Image Alignment 능력은 Base model의 능력에 의존적이라는 점에서 한계를 가지고 있습니다.
결론
KIMCHI는 한국어 프롬프트를 직접 이해하고, 문화적 뉘앙스를 잘 반영하도록 이미지를 생성하는 모델로, 기존의 이미지 생성 모델들이 가지는 한계점에 도전해본 연구입니다. 아직 많은 한계점들이 존재하지만 본 연구는 다음과 같은 기여점을 가지고 있습니다.
- VLM과 LLM를 통한 문화적 맥락 반영 데이터셋 전처리 파이프라인 구축
- 별도의 번역을 거치지 않은 한국어 프롬프팅을 통한 이미지 생성
- 보다 사실적이고 문화적 맥락을 반영하는 이미지 생성
이러한 기여점을 바탕으로 특정 문화권의 이미지만 모을 수 있다면 KIMCHI에서 활용했던 데이터셋 생성 전처리 파이프라인을 활용하여 Diffusion model을 fine-tuning할 수 있는 데이터셋을 구축할 수 있고, 이를 통해 해당 언어와 문화에 특화된 생성 모델 개발도 가능할 것입니다.
본 연구는 한국 문화만을 정교하게 반영한 이미지를 생성하는 데에서 시작되었지만, 이후에는 다양한 문화권을 이해하는 AI 기술로 확장될 수 있습니다. 향후에도 관련 연구들이 계속 발전하여 KIMCHI와 같은 문화 특화 모델이 세계적으로 다양한 문화권에 기여하고, 또한 다양한 문화권을 이해하고 존중하는 AI 기술로 발전할 수 있기를 기대합니다.
26 December 2024
Model Variant: 손쉽게 대접하는 다양한 모델 서비스
By 강지현들어가며
어떠한 연구 목적으로 AI를 학습시켜 결과물을 만들어내야 하는 상황에 있다고 가정해봅시다. 우리가 해야 할 일은 AI에게 가르쳐 준 데이터를 AI가 올바르게 학습하길 기다리는 것뿐이죠. 하지만 AI를 '활용'하는 어떠한 서비스를 만든다고 가정하면 이야기가 복잡해집니다. 다양한 모델을 어떻게 시스템에 적용시킬 것인지, 부하 상황에서 어떤 기준에 의해 스케일링을 시켜야 할지 모든 요소 하나하나가 고민거리죠. 이런 고민에 대한 답을 얻기 위해 함부로 사용자가 존재하는 프로덕션 환경을 수정할 수도 없습니다. 프로덕션 환경을 늘렸다 줄였다 하다가 사고라도 난다면 끔찍한 일이 생길 수도 있거든요. 만약에 끔찍한 일이 벌어졌다면, 벌어진 일을 수습하기 위한 시간이 필요할 텐데, 우리 서비스를 사용하는 소비자에게는 모델 학습을 기다리는 연구자와 같은 참을성을 기대할 수 없을 겁니다. 엔지니어링 영역의 어려움 외에 비용에 대한 어려움도 있습니다. 모델을 서비스하는데에는 당연히 비용이 들고, 모델을 학습시키는 그 순간에도 자원을 소모하고 있는 만큼 사용자가 비용을 지출하고 있는 셈이니까요. 그러나 걱정하실 필요는 없습니다. 이미 세상에는 잘 만들어진 모델들이 많이 존재하고, 우리는 그러한 모델들을 가져다가 서비스하는 것으로 충분한 경우가 많거든요. 저희 솔루션에 관심이 있으셨던 분들이라면 다 아시는 내용이겠지만, Backend.AI는 이미 여러분이 모델을 서비스할 때 필요로 하는 기능들을 다양하게 지원하고 있습니다. 트래픽에 따라 서비스를 늘리는 것이나 줄이는 것도, 사용자의 입맛에 맞춘 다양한 모델을 서비스하는 것도 가능하죠.
그러나 여기서 멈출 Backend.AI 팀이 아닙니다. 저희는 Backend.AI의 23.09 버전부터 제공된 모델 서비스를 한 층 강화하였고, 다양한 모델을 손쉽게 서비스할 수 있도록 개선하였습니다. 이번 포스팅을 통해 어떤 방법으로 쉽고 간편하게 다양한 모델을 서비스할 수 있는지 알아봅니다.
이번 포스팅에서는 다양한 종류의 모델을 더욱 간편하게 서비스할 수 있는 기능을 소개합니다. 모델 서비스에 대한 설명은 23.09 버전 업데이트를 릴리즈하며 한 차례 드린 적이 있기 때문에, 자세한 설명은 생략하겠습니다. Backend.AI의 모델 서비스가 생소하시다면, 다음 포스팅을 먼저 읽어보시는 것을 추천합니다. Backend.AI Model Service 미리 보기
기존 방식
| | 필요조건 | 기존 방식 | 모델 배리언트(Model Variant) | |---|----------|------------|----------------------------------| | 1 | 모델 정의 파일(model-definitionl.yaml) 작성 | O | X | | 2 | 모델 정의 파일을 모델 폴더에 업로드 | O | X | | 3 | 모델 메타데이터 필요 | O | △* (일부는 자체 다운로드 가능) |
Backend.AI 모델 서비스는 실행하기 위한 모델 메타데이터 외에 모델을 서비스할 때 실행할 명령어를 일정한 형식으로 담아둔 모델 정의 파일 (model-definition.yaml)을 필요로 했습니다. 서비스를 실행하는 순서는 다음과 같습니다. 모델 정의 파일을 작성하고, 모델 정의 파일을 읽을 수 있도록 모델(model) 타입 폴더에 업로드한 뒤, 모델서비스 시작시 모델 폴더를 마운트하면 자동으로 모델 정의 파일에 따라 엔드유저의 입력을 받아 모델로 전달하고, 응답 값을 보내주는 API 서버 등이 실행되는 형태였습니다. 하지만 이 방식은 모델 정의 파일을 수정할 때마다 파일에 접근해야한다는 단점이 있었습니다. 또, 이미 모델 정의 파일에 모델 경로가 정해져있기 때문에 모델이 달라질 때마다 모델 정의 파일을 다르게 작성해야 하는 것도 귀찮은 부분이었습니다. 이번에 선보이는 모델 배리언트(Model Variant)는 모델 정의 파일이 없이 모델 메타데이터만을 가지고 몇 가지 설정값을 입력하거나, 또는 아예 입력할 필요없이 즉시 모델을 서비스할 수 있는 기능입니다. 모델 배리언트에서는 커맨드(command), vLLM, 그리고 NIM(NVIDIA Inference Microservice) 방식을 지원합니다. 서비스하는 방법과 모델 서비스 실행을 확인하는 방법은 다음과 같습니다.
이번에 선보이는 모델 배리언트(Model Variant)는 모델 정의 파일이 없이 모델 메타데이터만을 가지고 몇가지 설정값을 입력하거나, 또는 아예 입력할 필요없이 즉시 모델을 서비스 할 수 있는 기능입니다. 모델 배리언트에서는 커맨드(command) 방식, vLLM 방식, 그리고 NIM(NVIDIA Inference Microservice) 방식을 지원합니다. 서비스하는 방법과 모델 서비스 실행을 확인하는 방법은 다음과 같습니다.
기본적으로, 모델 서비스는 서빙할 모델 메타데이터를 필요로 합니다. 가장 손쉽게 접할 수 있는 모델 메타데이터를 받을 수 있는 Hugging Face 에서 서비스할 모델을 다운로드 받아보세요. 이번 예제에서는 Hugging Face 의 Llama-2-7b-hf 모델과 Calm3-22b-chat 모델을 사용했습니다. 모델 메타데이터를 모델 폴더에 업로드 하는 방법은 앞의 포스팅의 모델 스토리지 준비를 참고하십시오.
빌드된 이미지에서 자동으로 모델 서비스하기 (command 방식)
첫 번째로 소개하는 커맨드 방식은 모델 정의 파일에서 모델을 서비스하기 위해 실행하는 명령어 부분이 실행 이미지에 들어간 형태입니다.
CMD라는 환경변수에 실행할 명령어를 지정한 뒤, 이미지를 빌드해 실제 모델을 서비스할 때 다른 입력 없이 바로 실행하는 방식이죠. 커맨드 방식은 서비스가 제대로 실행되고 있는지 확인하는, 이른바 Health check를 지원하지 않습니다. 따라서 대규모의 서비스를 수행할 때보다는 프로토타입으로 바로 서비스를 띄워서 확인해 볼 때 적절합니다. 실행방법은 다음과 같습니다.- 시작화면에서 서비스할 모델 서비스에 해당하는 모델 메타데이터가 들어있는 모델 폴더를 마운트하도록 Model Storage To Mount 항목에서
Llama-2-7b-hf를 선택하고, Inference Runtime Variant 항목에서 Predefined Image Command 를 선택합니다.
모델 서비스를 별도의 토큰없이 접근할 수 있도록 제공할 경우 Open To Public 스위치 버튼을 활성화 해주세요.
- 서비스할 환경을 선택합니다. 여기서는
vllm:0.5.0를 사용하고, 자원은 CPU 4 Core, Memory 16 GiB, NVIDIA CUDA GPU 10 FGPU 를 할당하도록 설정했습니다.
- 마지막으로 클러스터 크기를 선택하고, 시작버튼을 클릭합니다. 클러스터 크기는 싱글노드, 싱글 컨테이너로 설정했습니다.
서비스가 성공적으로 띄워졌다면, 서비스 상태는
HEALTHY로 바뀌게 되고 엔드포인트 주소가 나오게 됩니다.
서비스 확인하기
서비스가 정상적으로 띄워졌다면,
cURL명령어로 서비스 모델명을 우선 확인합니다.curl https://cmd-model-service.asia03.app.backend.ai/v1/models \ -H "Content-Type: application/json"
이제 서비스에 보낼 입력을
cURL명령어로 보내고, 응답값을 확인해보겠습니다.CMD로 실행하는 모델 서비스는 이미지에 이미 모델명이 정의되어 있기 때문에 모델명을 확인후 요청을 보낼 때 모델명을
model키의 값으로 입력해야 합니다.curl https://cmd-model-service.asia03.app.backend.ai/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "image-model", "prompt": "San Francisco is a", "max_tokens": 7, "temperature": 0}'
vLLM 모드로 모델 서비스하기
vLLM 모드는 앞에서 소개한 커맨드 방식과 비슷하지만, vLLM 을 실행할 때 입력하는 여러가지 옵션들을 환경변수로 작성할 수 있습니다. 실행방법은 다음과 같습니다.
실행방법
- 시작화면에서 서비스할 모델 서비스에 모델 폴더를 마운트하고, Inference Runtime Variant 항목에서
vLLM을 선택합니다.
- 서비스할 환경을 선택합니다. 앞서 설명한 커맨드 방식과 동일하게
vllm:0.5.0으로 선택하고, (자원은 동일하게 설정해도 되지만) 이번에는 CPU 16 Core, Memory 64 GiB, NVIDIA CUDA GPU 10 fGPU를 할당하도록 하겠습니다.
- 마지막으로 클러스터 크기를 선택하고 환경 변수
BACKEND_MODEL_NAME을 입력합니다. 이 값은 vLLM에서--model-name옵션에 대응하는 값으로, 사용자가 서비스에 요청을 보낼 때 지정하는 model 값이 됩니다.
마찬가지로 서비스가 성공적으로 띄워졌다면, 서비스 상태는
HEALTHY로 바뀌게 되고, 서비스가 띄워진 엔드포인트 주소가 나오게 됩니다.
서비스 확인하기
서비스에 보낼 입력을
cURL명령어로 보내고, 응답값을 확인해보겠습니다. 이 때model값은 아까 설정한BACKEND_MODEL_NAME값으로 입력합니다. 입력이 끝났다면START버튼을 클릭해서 서비스를 생성합니다.curl https://vllm-calm3-22b-chat.asia03.app.backend.ai/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "vllm-model", "prompt": "初めて会う日本人ビジネスマンに渡す最高の挨拶は何でしょうか？", "max_tokens": 200, "temperature": 0 }'
NIM 모드로 모델 서비스하기
NIM 을 실행하기 위해서는 NGC의 NIM 모델 레지스트리에 접근할 수 있는 계정으로부터 발행된 API 키가 있어야 합니다. 키값을 얻는 방법은 다음 내용을 참고하시기 바랍니다. NVIDIA Docs Hub : How to get NGC API Key
NIM(NVIDIA Inference Microservice) 모드 역시 커맨드 모드와 유사하나, NVIDIA의 NIM을 지원하는 모델 서버가 내장된 이미지로 실행해야 합니다. 또, 모델을 불러올 때에, NGC API 키 값이 필요합니다. 모든 것이 준비되었다는 가정하에 모델 서비스를 시작해보겠습니다.
실행방법
- 시작화면에서 서비스할 NIM 에서 받아올 메타데이터를 캐싱할 비어있는 모델 타입 폴더를 선택하고, Inference Runtime Variant 항목에서
NIM을 선택합니다.
- 서비스할 환경을 선택합니다. 여기서는
ngc-nim:1.0.0-llama3.8b를 사용하고, 자원은 CPU 8 Core, Memory 32 GiB, NVIDIA CUDA GPU 15 FGPU 를 할당하도록 설정했습니다.
- 마지막으로 클러스터 크기를 선택하고 환경 변수
HF_HOME으로 기본 경로인/models경로를 입력합니다. 그리고NGC_API_KEY을 입력하고, 발급받은 키값을 입력합니다. 입력이 끝났다면CREATE버튼을 클릭해서 서비스를 생성합니다.
NIM 을 사용할 경우 모델 메타데이터를 저장소로부터 받아오기 때문에 처음 실행시에는 다소 시간이 소요될 수 있습니다. 세션 페이지에서 서비스중인 라우팅 세션에 대한 컨테이너 로그를 확인하여 진행상황을 확인할 수 있습니다.
커맨드, vLLM 모드와 같이 서비스가 성공적으로 띄워졌다면, 서비스 상태는
HEALTHY로 바뀌게 됩니다. 서비스가 띄워진 엔드포인트 주소를 활용해 서비스에 보낼 내용을 다음과 같이 입력하고, 응답값을 확인해보겠습니다.서비스 확인하기
from openai import OpenAI client = OpenAI( base_url = "https://nim-model-service.asia03.app.backend.ai/v1", api_key = "$YOUR_NGC_API_KEY" ) completion = client.chat.completions.create( model="meta/llama3-8b-instruct", messages=[ { "role":"user", "content":"Hello! How are you?" }, { "role":"assistant", "content":"Hi! I am quite well, how can I help you today?" }, { "role":"user", "content":"Can you write me a song?" }], temperature=0.5, top_p=1, max_tokens=1024, stream=True ) for chunk in completion: if chunk.choices[0].delta.content is not None: print(chunk.choices[0].delta.content, end="")
마치며
모델 배리언트 기능은 이미 학습된 모델로 실질적인 서비스를 제공하는 것을 목표로 하는 연구자와 기업에 많은 도움이 될 것입니다. 강력한 자원 관리 시스템과 NVIDIA GPU, AMD ROCm, TPU, Graphcore IPU, Furiosa Warboy, Rebellions ATOM, Hyperaccel LPU 등과 같이 다양한 AI 가속기 지원을 바탕으로 한 Backend.AI 는 이제 단순히 모델을 학습하는 것을 뛰어넘어 서비스까지 쉽게 배포할 수 있는 통합 환경을 제공하게 되었습니다. Backend.AI 와 함께 여러분이 원하는 AI 모델을 언제든 서비스해보세요.
11 July 2024
- 시작화면에서 서비스할 모델 서비스에 해당하는 모델 메타데이터가 들어있는 모델 폴더를 마운트하도록 Model Storage To Mount 항목에서
[특집] Scale entanglement
By 신정규이 글은 2023년 5월 Crossroads 에 기고된 글입니다.
원래 글 순서는 2023 > 2015 > 2020 > 2017 > 2018 > 2019 > 2021 > 2022 > 2023
으로 쓰인 글입니다. 감정적 흐름은 그 순서를 따라가지만, 독자의 이해를 위해 시간순으로 재편집했습니다.
2023년이 지나면 3월 14일은 파이의 날이 아니라 챗봇의 날이라고 불릴지도 모른다.
그동안 창고에 있었던 모든 언어모델 들이 세상에 동시에 뛰쳐나온 날이었다. 구글의 PaLM 파인 튜닝 + 생성 모델의 Vertex AI 공개부터 시작하여 OpenAI의 GPT-4 발표, 마이크로소프트의 Bing이 이미 GPT-4를 사용 중임을 공식화, Anthropic의 claude 봇 정식 공개까지 모두 12시간 안에 일어난 날이었다.
그날 오전 OpenAI에서 공개한 GPT-4 테크 리포트를 리뷰한 후, 기술적으로 인상적이었던 점에 대한 글을 페이스북[1] 글에 남겼다. 댓글이 달렸다. "내 생전에 이게 될까 하던 것들이 현실화하는 걸 보는 기쁨과 아픔이 있습니다.." 답글을 남겼다. "이젠 아무도 튜링 테스트에 관심이 없죠. 1년 사이에 와우포인트 없이 당연히 넘는 거 아니야? 가 되었어요."
막상 키보드를 마주하니 지식을 정리하는 일은 이미 사람의 손을 떠난 것 같다. 기록의 의미를 찾아 사람의 이야기를 두드려본다.
외계어가 안 되도록 인공 신경망에 대하여 이 글을 이해하는데 필요한 내용만 짚고 가자.
신경세포(뉴런) 사이의 연결을 모사한 프로그램을 인공 신경망이라고 부른다. 뉴런 들을 층으로 묶고, 이를 겹치면서 앞뒤 층의 뉴런들과 연결을 만드는 식으로 설계한다. 딥 러닝은 인공 신경망 내의 층 개수가 많을 때 붙이는 표현이다. 다양한 인공 신경망 결과물 들을 딥 러닝 모델이라고 하며, 좀 있어 보이도록 그냥 AI 모델이라고도 한다.
뉴런 간의 연결 강도들을 파라미터라고 한다.[2] 연결 강도의 개수를 파라미터 수라고 한다. 파라미터 수가 많을 수록 차지하는 메모리가 늘어나므로 모델이 커진다는 표현을 쓴다. 인공 뉴런들을 연결하고 입력 데이터에 대한 출력이 원하는 형태가 나오도록 뉴런 사이의 연결 강도를 조정하는 것을 모델 훈련이라고 부른다. 훈련이 끝난 인공 신경망은 엄청나게 높은 차원의 불연속 상태 공간을 흉내 낼 수 있게 된다.
여기 까지가 기본 용어이다. 그럼 언제 이야기부터 떠올려 볼까.
2015년.
래블업을 창업했다. "랩 을 업" 이자 "lab | up" 을 이용해 중의적 표현으로 지은 이름이다.
박사 과정 내내 고생을 사서 하던 사람들이, 다른 사람들은 고생을 덜 할 수 있도록 계산과학 분야의 연구 자동화 플랫폼을 만들자는 목표로 모였다. 베어 메탈[3]에 작업 관리자[4] 얹어 어설프게 클러스터를 돌리는 대신 재현성과 이식성이 보장되는 연산 환경이 필요하다고 생각했다. 시작은 용감했으나 연구 플랫폼은 수요가 없었다. 창업 2개월만에 대학도, 연구 기관도, 장비는 쉽게 사지만 소프트웨어엔 돈 쓰는게 인색하다는 것을 배웠다. 학교엔 돈이 없고 시키면 알아서 해오는 대학원생은 많았다. 업계엔 아직 대규모 과학 연산 수요가 없었다. 동시에 우리처럼 학교에만 있다가 밖에 나온 박사들은 사람처럼 말하기 위해 재사회화 과정을 거쳐야 함도 힘들게 배웠다.
재사회화가 덜 된 우리의 말재간만 문제가 아니었다. 말하는 내용이 문제였다. 기술 기반의 과학 발전 이야기나 연산 기반의 혁신 가속 이야기는 어디를 가도 SF 이야깃거리였다. 지쳐가고 있었다. 그래도 사람은 보는 것만 보인다고 했던가. 딥 러닝 모델의 가능성이 분명 태동하고 있었다. 심지어 딥 러닝 기술과 결과물이 자본에 종속 되는 것을 막자는 여러 움직임이 시작되었다. 그 중 대표적인 기관이 OpenAI[5] 였다. 그러한 변화들은 우리가 맞는 방향을 가고 있다는 증거로 보였다. 일 년만 하면 방향이 조금 더 뚜렷해 질 것 같았다.
창업 만 일 년을 목전에 둔 시점에 딥 러닝에 대해 사회적으로 큰 관심이 생겼다. 2015년 연말 즈음 TensorFlow[6]가 세상에 나왔다. 플랫폼 프로토타입으로 만든 코딩 플랫폼의 첫 강의 자료로 TensorFlow 메뉴얼을 통째로 번역해서 올렸다. 알파고의 2016년 3월 대국[7]때 처음 서비스가 다운될 정도로 사람들이 몰려왔다. 그 때 그 대국이 아니었다면 아마 이 뒷이야기는 없었을 지도 모른다. 그 덕에 다행히 회사는 살아남았다.
거대 규모 연산을 수행하는 연구 플랫폼 데모가 필요했다. 연산 자원을 엄청나게 필요로 하며, 박사과정부터 취미로 잡고 있어 바로 다뤄볼 수 있던 주제가 언어 모델이었다. 2016년 우리가 만들던 플랫폼 위에 언어 모델을 올려 만든 챗봇을 발표했다. 많은 사람들의 관심을 끌었다.[8][9] 챗봇은 금방 사내 프로젝트로 자리 잡았다. 하지만 일 년이 조금 넘은 시점에 챗봇 프로젝트는 창고로 들어갔다.
2017년.
그 해 가을 래블업은 사이드 프로젝트로 병행하던 언어 모델 개발을 접고 AI 클러스터 운영 플랫폼인 Backend.AI 에만 전념하기로 결정했다.
구글 초청으로 방문한 폴란드 크라쿠프에서 본 구글 어시스턴트 데모의 충격이 컸다. 열 분 남짓한 분들과 함께한 그 미팅의 주제는 언어 모델이 이제 자원 전쟁의 일부가 되었으며, 대규모 투자 없이는 이후의 변화를 따라갈 수 없음을 너무 확실하게 보여주었다. 구글 개발자 서밋에 함께 참석한 곽동현님과, 같은 시기 같은 장소에서 열린 학회 참석차 크라쿠프에 방문하셨던 이상훈님과 함께 저녁식사를 함께 하며 이야기를 나누었다. "여기서도 물리학 분야에서 봤던 그 미래가 시작될 것 같아요."
맨해튼 프로젝트는 팔십 여년 전 기술이 힘이 됨을 핵무기를 통해 전인류를 대상으로 강렬하게 어필했다. 물리학은 더이상 낭만의 대상이 아니라 투자의 대상이었다. 그렇게 시작된 생계형 물리학자의 시대는 우주 계획과 입자물리학으로 연결되는 거대 과학 분야로의 변화로 이어졌다. 그 날 밤 숙소로 귀가하며 함께하는 멤버들에게 메세지를 보냈다. "우리 이제 언어 모델 개발은 하지 말죠. 이제부턴 따라가려면 돈이 부족할 겁니다."
역사는 항상 반복된다. 그렇다면 앞으로 어떤 변화가 있을지 예상하는 것도 어렵지 않다. 단지 시점이 문제일 뿐이다. ‘아마도 변곡점은 2020년일것 같다’는[10] 의견을 동료들과 나누었다. 그 때 즈음이면 흑자가 가능하지 않을까? 회사의 목표가 되었다. 언어 모델은 LSTM 기반의 기계 번역을 넘어 한 걸음 발전하고 있었다. 알파고 쇼크는 사람들이 AI에 대해 지어내는 수많은 농담들의 아이디어가 되었다. 엄청나게 많은 "AI 기업" 들이 생겼다. 하지만 그 대부분은 2년 후 코인회사나 메타버스 회사가 되었다.
2018년.
트랜스포머[11]구조는 온갖 언어 모델의 다양한 부분에 적용되기 시작했다. ‘무엇’ 에 집중할지 알려준다는 점에서 트랜스포머는 모델의 컨텍스트 기억과 유지, 강조에 대한 많은 부분을 해결해주었다. 정보를 상태공간에 넣는 인코딩에 쓸 수도, 상태공간에서 정보를 추출하는 디코딩에 쓸 수도 있었다. 구글은 BERT[12]를, OpenAI는 GPT를 내 놓았다. 두 모델 모두 트랜스포머 기반의 언어 모델이었으나, 집중하는 포인트는 각각 인코더와 디코더로 달랐다. BERT은 인코더 부분에 집중하였으나 GPT는 디코더를 통해 출력을 입력으로 연계하는 식으로 인과 관계에 대한 메모리를 만드는 아키텍처를 구현하여, BERT와 구조적인 차이가 있다. BERT와 GPT, 이후 등장하는 T5는 더이상 라벨링된 말뭉치를 쓰지 않았다. 트랜스포머를 이용하여 말뭉치 자체에서 언어의 구조를 학습시킨 후, 이후 미세 조정하는 방식으로 언어모델을 만들 수 있었다. 데이터에 인간의 개입이 없는 AI 모델 개발 철학인 End-to-end 훈련과는 여전히 거리가 있었다. 하지만 데이터 확보에 대한 개념이 그 시점부터 달라졌다. 라벨링보다 양이 중요하다. 범용 언어 모델의 시작이었다.
BERT는 엄청나게 빠른 속도로 기존에 존재했던 대부분의 언어 모델을 대체할 수 있을 것으로 보였다. 압도적인 성능은 문서 작성, 챗봇, 문서 분석 등의 다양한 언어 작업들에 적용하여 큰 개선을 만드는 것에 대한 기대를 품게 했다. 하지만 BERT는 2018년 당시에는 훈련 과정을 상상할 수 없을 만큼 큰 모델이었다. 구글 밖에서는 아무도 못 만들 것 같은 모델 크기에 벽 구경하는 느낌을 받았다. 그것도 찰나였다. 페이스북이 BERT 논문을 바탕으로 사이즈를 더 키운 RoBERTa를 순식간에 발표했다.[13] TPU가 꼭 필요한 것이 아님을 알림과 동시에, 이 레이스엔 자본이 있는 누구나 참여가 가능함을 알리는 상징적인 행동이었다.
GPU를 사용해 모델 크기를 키우는 첫 병목은 GPU의 메모리에서 등장했다. 모델은 더이상 GPU 기기 한 장에 담거나, 한 장으로 시간 내에 훈련시킬 수 없었다. 경우에 따라 여러 대의 GPU에 모델을 나눠 담거나 여러 컴퓨팅 노드를 사용해 모델을 분산 훈련하는 것이 일반적이 되었다. Horovod, Distributed TensorFlow들이 빛을 발하기 시작했다.
기술은 계속 발전하고, 동일 연산 자원에 들어가는 비용은 계속 감소한다. 이런 발전이 지속된다면 결국 AI의 대중화가 진행 될 것이고, 그 시점에서 가장 중요한 포인트는 다른 모든 시장에서도 동일한 가격 경쟁력이 될 것이었다. "AI도 가격 경쟁력 시대가 올 것이다" 써 붙였다. 그 때 까지 망하지 않기를 기원하면서.
- BERT, 3억 4천만 파라미터
- GPT, 1억 1천만 파라미터
2019년.
몇 년 간 분산 처리 및 분산 훈련 플랫폼을 만들면서 가끔 ‘우리가 아무런 수요가 없는 플랫폼을 만들고 있는 것이 아닐까’ 하는 생각을 종종 했었다. 2019년 이후로는 그런 생각이 들지 않았다. 2020년부터는 그런 생각을 할 시간이 없었다.
연초가 되자마자 OpenAI는 GPT-2[14]를 발표했다. 위상공간에서 정보를 추출하는 디코딩 과정에 집중한 GPT 모델은 굉장히 안정적인 텍스트 생성 기능을 보여주었다. GPT-2는 누구나 언어모델을 만들어 볼 수 있는 기초 코드가 되었다. PyTorch, horovod와 Distributed TensorFlow 등과 함께 코드 접근의 어려움은 엄청난 속도로 줄어들고 있었다. 2019년 Google의 XLNet과 T5 (Text-To-Text Transfer Transformer) 언어 모델은 인류가 넘을 수 없다고 생각했던 모델 크기의 강을 (자본을 써서) 넘은 것처럼 보였다. 구글은 T5를 훈련하려면 TPU 급의 엄청난 연산 자원이 있어야 함을 강하게 어필하며, 시중에서 노력하면 살 수 있는 NVIDIA의 V100으로는 몇 백장이 필요함을 강조했다. (V100 한 장에 1500만원 정도의 비용이 들었다.) T5 또한 BERT처럼 논문만 공개하고 모델은 공개하지 않았다. 2017년 BERT 공개 때 (훈련이 덜 끝나서) 바로 모델을 함께 공개하지 않았는데 그 틈에 페이스북이 동일한 모델로 규모를 키워 훈련한 RoBERTa를 선제적으로 발표했던 아픈 경험이 있다. 그런데도 공개를 하지 않은 것에 비추어 보면, 구글에겐 구글 밖에서 그 모델 훈련을 재현하기 어려우리라는 자신감이 있었을 것이다.
2019년 말 우린 오랜 떠돌이 생활을 마치고 단독 사무실을 장만하여 거처를 옮겼다. 거대 딥 러닝 모델의 시대가 올 것이고 그러려면 우리도 그에 대응하여 더 많은 사람들과 함께해야 할 것이었다. 언어 모델의 크기는 해마다 열 배 씩 커지고 있었다. 그렇게 많지도 않은 짐들을 박스에 실어 나르며 스스로에게 반문해보았다. 이대로는 3년이면 모델 크기가 천 배가 커지는 것인데, 우리는 천 배의 워크로드를 감당할 준비가 되어 있을까?
- RoBERTA, 3억 5천만 파라미터
- Transfer ELMo, 4억 6천만 파라미터
- GPT-2, 15억 파라미터
- T5, 110억 파라미터
2020년.
사무실을 이전한지 두 달이 흘렀다. 겨울은 길었다.
2월이 끝나가도록 이사를 마친 새 사무실의 인테리어를 마무리하지 못했다. 2월 말에 온다던 사무실 벽체 마감재는 중국에서 끝내 건너오지 않았다. 회사의 모든 로드맵이 바뀌었다. 미국 출장은 전부 취소되었다. 인테리어가 덜 끝난 사무실은 그 후 2년동안 덜 끝난 채로 빈 공간을 지켰다.
COVID-19는 회사의 미래 뿐 아니라 사람들도 갈라놓았다. 첫째 아이는 마루에 비스듬히 기대 누워 EBS 방송 텔레비전에 나오는 호랑이 선생님을 보면서 초등학교 생활을 시작했다. 방바닥에서 굴러다니는 어린이 옆에서 함께 굴러다녔다. 그동안 얼마나 바빴던 걸까? 남매를 키우는데도 코로나로 한 집에 갇히고 나서야 아빠라는 실감을 했다. 슬프면서도 이상하게 안정되는 그 시간이 얼마나 갈 지 궁금했다.
그 해 OpenAI에서는 GPT-3를 공개했다. GPT-2와 이론적 토대는 크게 달라지지 않았다. 하나 크게 달라진 것이 있었으니, 크기였다. 1750억 파라미터의 크기를 가진 엄청난 규모의 모델이었다. 모델 훈련 뿐 아니라 단순히 GPU 위에 적재하는 것 만으로도 NVIDIA의 슈퍼컴퓨팅 노드인 DGX-2 한 대를 차지할 것으로 예상되었다. GPT-2와 달리 이번에는 언어 모델의 코드도, 훈련이 끝난 언어 모델도 공개하지 않았다. 와우. 딥 러닝 분야에 비공개라니. 무엇인가가 달라지고 있었다.
모델 크기 지상주의에 반발하는 움직임이 있었다. 딥 러닝 모델의 크기가 커질수록 성능이 따라서 커지는가? 구글의 연구진들과 메타의 연구진들 간의 논쟁이 시작되었다. 한 쪽에서는 그렇다, 다른 한 쪽에서는 아니다 로 나뉘어 논문의 형식을 빌린 말싸움이 벌어졌다. 그러나 2019년부터 2021년까지 이어진 이 논쟁은 오래가지 못했다. 언어 모델 크기를 키우면서 재미있는 현상들이 발견되었다. 딥 러닝 모델에는 스케일 법칙이 존재했다.[15] 1000억 파라미터를 전후하여 무엇인가가 일어났다. 모델의 구조와는 상관없이, 1천억 파라미터를 넘기는 어떤 시점부터 언어 모델은 말을 이어 지어내는 것을 넘어 기대하지 않았던 일을 하기 시작했다. 충분히 큰 모델들은 컨텍스트를 유지한채로 복잡한 일들을 처리할 수 있었다. 컨텍스트 내 학습 (in-context learning)이라고 부르는 현상은 모델 훈련 없이도 여러 지식을 즉석에서 학습하고, 논리적인 결론을 유도할 수 있었다. 거대 언어 모델 (Large Language Model) 과 이를 둘러싼 레이스의 시작이었다.
언어 모델이 크기 문제를 둘러싼 논쟁과 발견에 동시에 빠져 있는 동안, 의학 응용 분야의 딥 러닝 도입은 엄청난 속도로 시작되었다. 딥 마인드의 알파폴드2는 몬테카를로 시뮬레이션 없이 예측만으로 구조 예측을 높은 정확도로 해 냈다. 프로테오믹스 분야의 주요 난제였던 필요 계산 량을 거의 천분의 일 수준으로 줄였다. 코로나 바이러스의 변이 예측, 합성물질 중 백신 후보 물질 필터링, 새로운 합성 구조 예측 등의 미시적인 단계부터 전파 경로 예측과 감염자수 예상까지 AI 모델의 응용은 다양한 분야로 확장되었다. 모두가 이전 같으면 두들겨볼 돌다리들을 일단 밟고 건너기 시작했다. 자원 규모의 눈덩이는 엄청난 속도로 굴러갔다.
하반기가 되자 모델 훈련 속도를 올리기 위한 연산 자원 규모의 이야기가 오갔다. 연구 목표 달성을 위한 기존의 딥 러닝 연산 자원 확보 경쟁과는 달랐다. 규모는 운영과 최적화 수요를 낳았고, 그 덕에 우리는 2017년 예상했던 ‘2020년부터 흑자 달성’ 을 이룰 수 있었다. 플랫폼 수요가 늘었지만 동시에 강제로 재택 근무에 들어가야 했고, 대부분의 의사소통은 문자가 되었다. 이후 많은 사람들이 함께 하게 되었지만 그 중 몇몇은 2023년 초 워크샵 때 까지 서로 한 번도 만난 적이 없는 동료가 될 운명이었다.
연산 자원 규모가 커지고 있었고 모두 GPU에 주목했지만, 모델이 커지고 GPU 대수가 늘어나자 GPU가 발목을 잡는 부분이 적어졌다. 가장 발목을 잡는 부분은 데이터 저장소, 스토리지였다. 훈련시에는 몇 백대의 기기에 데이터를 공급해야 한다. 스토리지의 절대 속도가 GPU 개수의 증가를 충분히 따라잡지 못했다. 2020년 우리가 풀어야 했던 문제의 대부분은 스토리지에서 발생하는 병목에서 나왔다.
딥 러닝 분야의 속도전보다는 느릿했지만 더 깊은 다른 종류의 변화가 찾아왔다. 온라인에서만 만들어진 인간관계를 보통 인간관계와 같게 받아들이는 것이 세대를 불문하고 모든 사람들에게 자연스럽게 되었다. 그러다 보면 문득 생각이 드는 순간이 찾아온다. ‘반대쪽에 있는 것이 사람이든 아니든, 말만 잘하면 나에게 큰 차이가 있는 존재인가?’
- T-NLG, 170억 파라미터
- GPT-3, 1750억 파라미터
- Gshard, 6000억 파라미터
2021년.
T5에 이어 GPT-3가 불러온 거대 언어 모델 개발의 레이스는 점입가경이었다. 크기가 커져도 성능향상이 계속되는지 알아보려면 더 크게 만들어 보는게 가장 간단하기 때문이다. 거대 언어 모델이 왜 특이한 결과를 만들어내는가에 대한 다양한 이론들이 등장했지만 여전히 답은 오리무중이었다. 상태 공간이 충분히 크면 정보를 다루는 과정에 일종의 상전이가 생긴다는 가설이 등장했다. 트랜스포머가 어째서 이러한 작업을 잘 처리하는가에 대한 답의 후보로는, 트랜스포머 구조가 그래프 신경망 (Graph Neural Network)의 특수해이기 때문이라는 설명이 있었다.[16] 2018년부터 주목받은 그래프 신경망은 대상의 관계를 학습하는 신경망이고, 그래프 신경망이 시맨틱스나 텍소노미 처리에 매우 강력할 수 있음이 알려져 있다.
분산 모델 훈련을 위해 속도를 희생하는 대신 더 큰 모델을 훈련할 수 있게 하는 마이크로소프트의 DeepSpeed 프레임워크가[17] 점점 널리 쓰이기 시작했다. DeepSpeed의 특징인 ZeRo 최적화기는 CPU부터 GPU까지 다양한 하드웨어에 워크로드를 분배하고, 모델 상태를 분할 처리함으로써 이를 통해 GPU의 메모리 사용량을 줄이는 과정에 집중했다. 오픈소스 언어 모델들도 여럿 등장했다. OpenAI는 더이상 모델을 공개하지 않고, 모델 사용의 독점권을 팔고 있었다. 접근성이 낮아져 다양한 언어 모델들이 등장했지만, 규모의 면에서 거대 언어 모델에 미치지 못했기에 높은 기대치를 만족시킬 수 없었다.
사용자들이 다루는 GPU의 규모가 쉽게 세 자릿수를 넘기 시작했다. 기관에서 실제로 돌리는 워크로드에 맞는 거대 규모의 테스트가 다양하게 필요해졌다. 2017년 말 취미의 영역으로 보냈던 언어 모델을 시스템 테스트 용도로 다시 돌려보기 시작했다. 플랫폼 위에서 전세계에서 가장 큰 포르투갈어 언어 모델이 태어났고, NVIDIA GTC 컨퍼런스의 키노트에서 잠시 지나가며 소개되었다. 같은 컨퍼런스에서 "BERT를 60초만에 파인튜닝하기"라는 튜토리얼 세션이 열렸다. BERT는 더이상 거대 모델이 아닌 연습 대상이었다.
모델 크기가 급속도로 커지면서 풀어야 하는 문제도 바뀌었다. 여러 대의 GPU들에 모델을 나눠 적재해야 하는 상황이 되자 GPU간의 통신이 엄청나게 중요해졌다. GPU들은 한 노드 안에서 메모리 접근을 공유하는 것을 넘어 여러 노드에 걸쳐 통신하는 경우가 늘어났다. 초당 200Gb를 전송하는 인피니밴드를 GPU마다 하나씩 붙인 GPU 네트워크가 당연하게 쓰이기 시작했다.
복잡하고 정신 없는 변화속에 살며 생각거리가 하나 생겼다. 거대 언어 모델이 ‘언어’ 를 배우는 과정은 분류되지 않은 말뭉치를 대상으로 한다. 그 과정에서 거대 언어 모델이 ‘학습’ 하는 것은 무엇인가? 언어의 구조를 학습하기 위한 용도로 말뭉치를 쓰지만, 언어는 정보와 떼 놓을 수가 없다. 실제로 지식을 가르치지 않은 언어 모델들도 질문에 곧잘 대답하지 않는가? 애초에 언어는 인간이 정보를 서로 간에 전달하기 위한 프로토콜이다. 프로토콜로 전달된 데이터에 대한 답을 연산하여 다시 데이터로 답을 하는 것이 대화 과정이다. 그렇다면 우리가 ‘대화를 잘하는 AI’를 개발해 냈다고 느끼는 것은 정말 언어를 잘 만드는 AI 모델을 개발한 것일까, 그렇지 않으면 그 너머의 무언가를 만든 것인가?
내년은 기존의 서비스들을 AI로 개선한 서비스들이 아닌, AI로만 가능한 서비스들의 원년이 될 것이었다. 하지만 거대 언어 모델의 결과물들을 서비스하려는 생각은 아직 아무도 하지 않고 있었다. 그건 미래의 누군가가 할 일이었다.
- GPT-J, 60억 파라미터
- LaMDA, 1600억 파라미터
- PanGU-alpha, 2000억 파라미터
- Gopher, 2800억 파라미터
- Pathways, 5300억 파라미터
- Switch-C, 1.6조 파라미터
- Wudao 2, 1.75조 파라미터
2022년.
COVID-19 엔데믹은 엄청난 후폭풍을 만들어내고 있었다. 코로나로 인한 특수로 성장한 수많은 IT기업들과, 오프라인을 온라인으로 전사하려고 노력하던 수많은 회사들은 갑자기 신기루처럼 사라진 메타버스 수요에 망연자실했다. 딥 러닝 분야는 별다른 수익원을 만들어내지 못하고 있었다. 수없이 많은 회사에서 AI 팀의 크기를 줄이기 시작했다. 많은 연구자들이 밖으로 나왔다.
AI에 대한 기술적 발전이 필요가 없어진 것은 아니었다. AI 개발의 저변에 깔린 거대한 규모의 영향력이 다른 모든 발전을 압도했기 때문이었다. 거대 과학의 시대에는 장비가 가장 비쌌듯 말이다. 혁신이 규모에서 나오기 시작한지 3년이 흐른 결과였다. 거대 언어 모델에서 발생하는 특이점이 창발 현상의 일종으로 간주되기 시작했다.[18] 소규모의 연구들은 더이상 매력적이지 않았다. 딥 러닝 분야의 연구자들은 불안해했다. 줄어든 관심이 문제가 아니었다. GPU 달랑 몇 대로 어떤 연구를 할 수 있을지에 대한 가벼운 절망감 한 스푼이 더 문제였으리라.
그럼에도 불구하고 연초부터 등장한 여러 혁신들이 있었다. 잘 정의된 데이터로 훈련하는 것에 더해서, 답변들을 사람이 실제로 평가하여 더 나은 답변에 가중치를 주는 모델 튜닝 방식이다. 사람을 중간에 넣는 방식으로 강화학습을 언어 모델 훈련에 적용한 RLHF (Reinforcement Learning by Human Feedback) 방식은 2022년에 InstructGPT에 와서 같은 크기의 언어 모델 성능을 엄청나게 개선하는 결과를 보였다. 수많은 모델들이 RLHF를 적용하기 시작했다. 모델 크기에 스케일 법칙이 있다면 그걸 응용하지 못할 이유가 없을 것이었다. 3월에는 모델 훈련에 들어가는 비용을 엄청나게 줄일 수 있는 µ-Parametrization[19]이 발표되었다. 작은 모델에서 미리 큰 모델의 하이퍼파라미터를 예측하는 것이 가능하다는 연구의 결론은, 거대 모델을 만들 때 드는 파라미터 탐색 수고를 상대적으로 엄청나게 줄였다. 이 연구는 GPT-4 훈련의 기반이 되었다.
미국-중국 무역 갈등의 여파로 미국은 중국을 대상으로 한 엔비디아의 AI 훈련용 GPU 수출을 금지시켰다. 며칠 지나지 않아 중국은 자체 반도체만으로 훈련했다는 거대 언어 모델을 공개했다.[20] 얼마 후 엔비디아는 GPU 네트워킹 기능을 제거한 같은 GPU를 이름만 살짝 바꾸어 수출을 재시작 했다. DALL-E2와 Stable Diffusion 모델로 인해 AI 서비스 분야로의 관심사는 갈수록 커졌고, 이미지 등의 생성 AI 모델 시장은 격변하기 시작했다.
11월 말 OpenAI는 대중을 대상으로 챗봇 서비스를 열었다. GPT-3의 개선 버전인 GPT-3.5를 기반으로 한 모델이었다. 특이한 점은 인간 언어 모델에 프로그래밍 코드를 훈련시키는 방식으로 프로그래밍을 잘 하는 언어 모델을 만드는 대신, 프로그래밍 언어 데이터로 훈련된 모델에 인간 언어를 훈련시키는 방식으로 만들어진 모델이라는 점이었다. 거대 언어 모델의 논리 구조 훈련에 프로그래밍 코드 훈련이 어떤 식으로 영향을 주는 것이 분명해 보였다. 12월 초, ChatGPT로 이름 붙여진 서비스는[21] 대중 모두에게 열려 있는 엄청난 접근성을 바탕으로 거대 언어 모델에 대한 관심을 불러일으켰다.
연말이 되자 직장을 잃을 것 같던 AI 분야의 지인들이 실시간으로 갑자기 좋아지는 지원에 당황해 했다. 엔데믹의 감원 열풍을 타고 AI 조직 사이즈를 줄여 나가던 회사들의 움직임이 멎었다. 한 주 전까지 연구 조직 축소와 결과물 평가를 압박하던 수장들이 AI를 외쳤다. 모델 서비스 프레임웍에 필요한 요구조건들이 갑자기 바뀌기 시작했다. 거대 언어 모델들의 목표가 상용화가 되었다. 모델 크기가 너무 커서 더이상 훈련과 서비스용 연산 자원을 구분하는 의미가 없어졌다. 원래 서로 다른 영역에 있던 AI 모델 훈련과 서비스가 갑자기 하나로 합쳐졌다.
더 큰 규모의 문제들이 기다리고 있다. 거대 언어 모델은 엄청난 전력을 소모한다. GPU는 어마어마한 전력을 소모한다. CPU에 비하면 전력 대 성능비가 엄청나게 좋은 기기이지만, 절대 전력 소모량이 너무 크다. NVIDIA A100 8대가 내장된 노드[22]는 약 7kW를, 2023년 기준 가장 성능이 높은 H100 GPU 8대가 내장된 노드는 약 12kW를 소모한다.[23] 기기를 설치하려면 이제 건물부터 지어야 한다는 말이 2019년 이후로 농담이 아니게 되었다. 2021년 브라질에 위치한 슈퍼컴퓨팅 클러스터에서 전력 문제를 겪은 후, 우리는 플랫폼을 통째로 Arm기반으로 이식했다. 몇 년 후 전력 문제가 이슈가 될 것이란 생각에서 였다. 마이크로소프트의 경우 전력 비용을 고려하여 아예 GPU 센터를 수력발전소 옆에 지은 경험을 공유하기도 했다.[24]
주말이 줄어들었다. 할 일이 너무 많아졌다. 시간이 없었다. 우리만 그런 것이 아니었다.
이제 모두에게 시간이 없었다.
- Flan-T5, 1100억 파라미터
- GLM-130B, 1300억 파라미터
- OPT-175B, 1750억 파라미터
- BLOOM, 1760억 파라미터
- PaLM, 5400억 파라미터
2023년.
2월 8일, 17시간 간격으로 마이크로소프트와 구글이 각각 거대 언어 모델 기반의 서비스에 대한 발표를 진행했다. 마이크로소프트는 자사의 검색엔진인 Bing에도, 오피스 스위트에도, 윈도우 11에도 전부 GPT 모델을 도입하겠다는 계획을 발표했다. 구글은 LaMDA 기반의 Bard를 발표했다. 바이두는 어니봇을 공개했다. 두 회사는 만져지는 서비스 대신 미래를 먼저 홍보했다, 써 볼 수 없는 도구는 상대적으로 흥미를 끌지 못했다.
언젠가 올 것이라고 생각했던 "AI 가격 경쟁력 시대"가 왔다. 그런데 가격 자체의 허들이 너무 높았다. ChatGPT나 Bard는 경제논리로는 설명할 수 없을 정도로 고가의 서비스 비용을 소모한다.[25] 경쟁이 불러온 너무 빨리 당겨온 미래에 해당된다. 모든 사람들이 그 미래를 손으로 만져본 후였다. 기대치가 엄청나게 올라간 것이 문제였다.
갑자기 다가온 거대 언어 모델 서비스는 또 다른 병목을 만들고 있다. CPU 기반으로 인퍼런스하는 서비스는 CPU 코어당 램 대역폭이 크게 줄어든 여파를 받았다. 하나의 CPU에 올라가는 코어 개수가 급격하게 늘어났기 때문이다. GPU 기반으로 인퍼런스하는 서비스는 모델이 담기는 GPU 메모리의 용량과 속도가 모두 부족해졌다. 언젠가 올 것이라 여겨졌던 램의 병목이 거대 언어 모델 서비스의 상용화로 갑작스럽게 직접적인 문제가 되었다. 2021년부터 예상된 병목이었다. 인텔, AMD, 엔비디아 등의 CPU, GPU 개발사들은 이 상황을 미리 준비했다. 인텔의 Xeon Max, AMD의 MI200과 NVIDIA GraceHopper 등, 2022년말부터 2023년 초에 걸쳐 다양한 하드웨어를 발표했다.
AI 모델이 엄청 크면 연산 능력이 상대적으로 덜 중요해진다. NVIDIA A100은 첫 발표 때 40GB 모델을 공개했지만, 1년이 되는 시점에 80GB 메모리 모델을 다시 발표했다. 훈련 과정이든 인퍼런스 과정이든, 모델을 메모리에 올렸다 내렸다 하기엔 크기가 너무 컸다. 또한 거대 언어 모델을 "인퍼런스" 하는 과정은 GPU나 NPU에 대한 사고의 역전을 불러왔다. 끊임없이 가중치 행렬을 갱신해야 하는 훈련 과정과 달리, 인퍼런스 과정은 메모리에 올린 고정된 모델 구조를 따라 입력 데이터를 흘려 결과를 보는 식으로 동작한다. 따라서 연산의 비중이 엄청나게 줄어들고 메모리의 속도가 엄청나게 중요해지고 있다. NVIDIA는 2022년 하반기 80GB의 메모리 용량으로 H100을 발표했다. 그러나 반 년도 지나지 않아 실제 H100을 수령한 사람도 거의 없는 시점에 188GB 용량의 H100 NVL을 내놓았다.[26]
메타는 개인용 서버에서도 무리하면 돌려볼 수 있는 언어 모델인 LLaMA[27]를 내놓았다. LLaMA는 온갖 라이선스 제약이 붙어있음에도 불법 유출본으로 퍼졌고, 스탠포드에서 파인 튜닝한 Alpaca-LLaMA는 (상대적으로) 작은 모델로도 상당한 성능을 발휘할 수 있는 가능성을 보였다. 이후 라이선스 문제 없는 다양한 언어 모델들이 계속 공개되며[28] 오픈 언어 모델들의 가능성의 불을 지피고 있는 동시에 어느 정도 파라미터 크기의 모델이면 만족할 수 있는가에 대한 새로운 물음을 불러 일으켰다. 모델이 작으면 창발 현상이 발견되지 않고 멀티 모달 모델로 쓸 수가 없다. 모델이 크면 실제 운영에 너무 큰 돈이 든다.
거대 언어 모델은 어디까지 커질 수 있을까. 더 큰 모델에 대한 준비의 흔적은 사방에서 보인다. 분산 모델 훈련에서 가장 자주 쓰이는 마이크로소프트의 DeepSpeed 프레임워크는 2021년 NVMe SSD를 활용하여 1조~10조 파라미터를 훈련할 수 있는 확장인 ZeRO Infinity[29]를 추가했다. 그러나 이렇게 많은 파라미터를 가진 모델들은 실제 서비스가 불가능하다. 실질적으로는 서비스 가능한 모델 크기의 한계를 정해 두고 그 안에서 파인 튜닝하는 방식의 접근이 진행된다. ZeRO 등의 기술은 초거대 스케일의 모델을 훈련하기 위해 개발되었지만, 매우 적은 자원으로 파인 튜닝을 할 수 있게 하므로 다양하게 응용되고 있다.
- PaLM-e, 5600억 파라미터
- Pythia, 12억 파라미터
- LLaMA, 65억 파라미터
그 외 수많은 ~ 120억 파라미터의 모델들
20억~120억 파라미터 정도의 다양한 ‘말을 잘하는’ 모델들에 대한 다양한 시도들이 하루에 몇 개씩 등장하고 있다. LLaMA는 의도치 않게 개인이 만져볼 수 있는 파운데이션 모델을 널리 퍼뜨렸다. 보통 사람들이 만족할 만한 대화를 만들어내는 "말 잘하는 모델"의 수준은 예전에 달성했음을 수많은 사람들이 깨닫게 되었다. 어느정도 컴퓨터에 지식이 있고 돈을 쓸 수 있는 개인이나 조직, 단체들이 언어 모델 파인 튜닝을 다양한 방법으로 시도할 수 있는 용기가 생겼다.
동시에 말을 잘하는 정도를 넘어선 모델들의 연산 자원 요구량은 차원이 다르게 크다는 것도 함께 알려지는 중이다. 약 반 년 가까이 새로 등장하는 거대 언어 모델의 크기는 6000억 파라미터 미만으로 유지되고 있다. 더 이상의 크기 확장에 천착할 만큼의 결과가 등장 하지 않는 것일 수도 있고, 현재의 하드웨어 및 비용이 만들어낸 기술 장벽이 가로막고 있을 수도 있다. 또는 그 크기가 상용화가 불가능한 영역에 걸쳐 있기에 이제 적절한 크기 이하로 유지하려는 움직임일수도 있다.
2015년 GPU 4대를 운영하는 오픈소스로 시작한 Backend.AI는 2023년엔 몇 천 대 규모의 GPU를 다루며 곧 만 대를 바라본다. 우리를 포함한 모든 환경이 엄청나게 변했다. 문제들을 캐면 캘수록 마치 감자 줄기처럼 끝없이 다음 문제가 이어 나온다. 거대 언어 모델의 크기에 얽혀 수많은 문제들을 풀며 살아가다가, 이 문제의 끝은 어디에 다다를까 가끔 생각한다.
생각이 많은 밤이면, 모르는 사이에 관심에서 멀어져버린 튜링 테스트 마냥 우리 모두가 어떤 지점을 지나버렸을지도 모른다는 생각이 종종 든다. 풀어야 했던 문제를 풀었거나, 아직 풀면 안되는 문제를 풀어버렸을 것 같다. 설렘이 현기증이 되고 기대가 우울함이 되는 복잡한 감정이 오간다.
- [1] 페이스북 글
- [2] 뉴런 사이의 연결 뿐 아니라 다양한 파라미터들이 있으나 모델 크기가 크면 상대적으로 작으므로 편의상 엄청나게 단순화하였다.
- [3] 가상 머신 등이 아닌 날 것 그대로의 물리적 컴퓨터. 클라우드에서는 관리 소요 감소 및 유연한 자원 관리를 위해 베어 메탈에 하이퍼바이저를 올려 가상 머신을 운영하거나, 컨테이너 기반으로 관리하는 것이 일반적이다. 비용 문제로 인하여 소규모 연구소 및 대학 등에는 아직 대중화되지 않았다.
- [4] Job Scheduler. 프로세스들을 실행하고 관리하는 과정을 돕는 소프트웨어. Slurm 등이 보편적으로 쓰인다.
- [5] https://www.openai.com (2015). 2020년 이후 OpenAI는 구현체를 공개하지 않았으며, 2023년 이후에는 논문 대신 테크 리포트 정도만 제공하고 있다. OpenAI가 아직 Openness를 추구하는 AI 개발 조직인지에 대해서는 2023년 현재 여러 의견이 있다.
- [6] https://www.tensorflow.org, Google (2015)
- [7] "AlphaGo - The Movie" 당시 분위기를 느끼지 못한 분들은 다큐멘터리를 참고 (2018)
- [8] J.Shin "Creating AI chat bot with Python 3 and Tensorflow" PyCon APAC 2016 (Korean) / (English) (2016) 여러 나라에서 소개할 기회가 있어 동일 주제로 다양한 발표 영상이 있으나 이 두가지가 최초의 발표이다.
- [9] J.Shin "전자양의 꿈을 꾸는 안드로이드: Python과 NLTK, TensorFlow를 이용한 챗봇 감정모형 구현" PyCon KR 2017 (2017)
- [10] 구글 스타트업 캠퍼스에서 인터뷰한 기록이 유튜브에 남았다.
- [11] "Transformer (machine learning model)"
- [12] J. Devlin et al., "BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding" Arxiv:1810.04805 (2018)
- [13] Y. Liu et al., "RoBERTa: A Robustly Optimized BERT Pretraining Approach" Arxiv:1907.11692 (2019)
- [14] A. Radford et al., "Language Models are Unsupervised Multitask Learners", (2019)
- [15] J. Kaplan et al., "Scaling laws for neural language mod- els" Arxiv:2001.08361 (2020)
- [16] C K. Joshi, "Transformers are Graph Neural Networks", The Gradient (2020)
- [17] Microsoft, "DeepSpeed: Extreme Speed and Scale for DL Training and Inference", (2019)
- [18] J. Wei et al., "Emergent abilities of large language models" Arxiv:2206.07682 (2022)
- [19] E.Hu, G. Yang, J.Gao, "Tensor Programs V: Tuning Large Neural Networks via Zero-Shot Hyperparameter Transfer" Arxiv:203.03466 (2022)
- [20] A Zeng et al., "GLM-130B: An Open Bilingual Pre-trained Model" Arxiv:2210.02414 (2022)
- [21] OpenAI, "Introducing ChatGPT" (2023)
- [22] 랙 이라는 데이터센터용 가구에 설치하는 컴퓨터 한 대를 노드 하나로 간주하면 된다. A100 GPU 8대가 설치된 노드 하나는 보통 랙 안에서 6칸에서 8칸을 차지하며, 랙 하나에는 40칸 내외의 노드를 설치할 수 있다.
- [23] 일반적인 대학 건물의 한 개 층 전력이 100kW 내외이다.
- [24] "NVIDIA Teams With Microsoft to Build Massive Cloud AI Computer" (2022)
- [25] 개인적인 추산에 따르면 ChatGPT의 경우 GPT-3.5기준 원가는 월 42달러 이상이다. 계산 과정은 링크 참조. 페이스북 글
- [26] "NVIDIA H100 NVL for High-End AI Inference Launched" (2023)
- [27] H Touvron et al., "LLaMA: Open and Efficient Foundation Language Models" Arxiv:2302.13971 (2023)
- [28] 대표적으로는 ElutherAI의 Pythia-12B 모델에 자체 데이터를 결합한 Dolly 2 (2023) 등이 있다.
- [29] S. Rajbhandari et al, "ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning", Arxiv:2104.07857 (2021) 1조 파라미터 모델을 훈련을 위해 메모리 오프로드 없이 GPU에 올리려면 NVIDIA A100 GPU (80기가) 모델 기준으로 320장이 필요하다.
25 March 2024
