소형 모델을 위한 대규모 클러스터 — 다니엘 스보나바(Daniel Svonava), 슈퍼링크드(Superlinked)
AAI Engineer
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00검토자: 드니스 RQ
00:00:12좋습니다.
00:00:14제 목소리 잘 들리실 겁니다.
00:00:15제 귀에도 아주 잘 들리네요.
00:00:19앞쪽에 앉으신 분께는 티셔츠를 드리겠습니다.
00:00:21진심입니다.
00:00:22이쪽에 티셔츠가 가득 든 가방이 있거든요.
00:00:25질문하시는 분들께도 드립니다.
00:00:26아마 강연 끝나고 질의응답 시간을 가질 텐데요.
00:00:28질문해 주시면 마찬가지로 티셔츠를 드립니다.
00:00:31그리고 이 슬라이드 배경이 무엇을 나타내는지 맞추신다면
00:00:35역시 티셔츠를 드리겠습니다.
00:00:39혹시 아시는 분 계신가요?
00:00:42저게 무엇을 시각화한 걸까요?
00:00:44이 배경에 있는 그림 말입니다.
00:00:49없나요?
00:00:50트랜스포머 모델을 보신 분이 없나요?
00:00:55네, 포지셔널 인코딩이요.
00:00:57아주 좋습니다.
00:00:58저기 선생님께서 티셔츠를 획득하셨네요.
00:00:59좋습니다.
00:01:00오늘은 작고 오픈 소스인 모델들이 얼마나 쓸만해졌는지, 그리고 이들을 자체 클라우드에서 다수 운영할 때 어떤 고유한 문제들이 발생하는지 주로 이야기해 보겠습니다.
00:01:15우리가 논의할 모든 내용은 오픈 소스 기반입니다.
00:01:19직접 해볼 수 있죠.
00:01:20명령어 몇 번만 실행해서 전체 스택을 온전히 소유할 수 있는 그런 부류의 기술입니다.
00:01:26따라서 여기에 독점적인 기술 조각 같은 건 전혀 없습니다.
00:01:31그럼 본격적으로 시작하겠습니다.
00:01:33좋습니다.
00:01:34좋아요.
00:01:35잘 작동하네요.
00:01:36자,
00:01:37소형 모델에 대해 이야기해 봅시다.
00:01:38소형 모델이란 과연 무엇을 의미할까요?
00:01:40누구에게 묻느냐에 따라 다르겠지만, 제가 생각하기에는 기본적으로 2~3세대 이전의 엔비디아 하드웨어에서도 구동할 수 있는 모델을 뜻합니다.
00:01:49모델 전체가 하나의 GPU에 들어가기 때문에 서비스하기가 매우 쉽습니다.
00:01:56그런 GPU는 구하기도 쉽고 비용도 부담 없죠.
00:02:01대부분은 소형 모델이라고 하면 결과물의 품질 측면에서 어느 정도 타협을 해야 할 거라고 생각합니다.
00:02:10하지만 이번 강연을 통해, 특정 작업에서는 최첨단(프론티어) 모델 수준이거나 그 이상의 성능을 내면서도 명백한 이점들을 모두 누릴 수 있다는 점을 잘 설득해 드릴 수 있기를 바랍니다.
00:02:22비용을 엄청나게 절감할 수 있으며, 지연 시간이나 처리량 면에서도 상당한 개선을 이뤄낼 잠재력이 있습니다.
00:02:35이 차트는 저희가 즐겨 보여드리는 자료 중 하나입니다.
00:02:38시간에 따른 인공지능 분석 지수를 나타낸 그래프죠.
00:02:42여기에 보통 잘 드러나지 않는 부분이 있는데, 바로 우리가 주목해야 할 오픈 소스 모델들의 세부 분류입니다.
00:02:49매개변수가 7,500억 개에 달하는 GLM 5.2 같은 최첨단 오픈 소스 모델들이 존재합니다.
00:02:57하지만 그 뒤를 쫓으며 최첨단 모델의 뒤를 바짝 쫓는 소형 오픈 소스 모델들도 있습니다.
00:03:04보시다시피 최첨단 모델은 요즘 성능 향상이 점차 정체되는 반면, 소형 모델들은 빠르게 따라붙고 있습니다.
00:03:10이러한 수렴 현상과 상단에서의 포화, 그리고 소형 모델들의 성장을 확인할 수 있죠.
00:03:16예를 들어 Qwen 3 627B 같은 모델은 GPT 5.1과 비슷한 수준의 성능을 보여줍니다.
00:03:23따라서 여러분이 GPT 5.1로 구동되는 워크플로어나 파이프라인을 가지고 있다면,
00:03:29이제 이를 소형 모델로 전환하여 앞서 논의한 모든 이점을 누릴 수 있습니다.
00:03:35소형 모델은 이제 무시할 수준이 아닙니다.
00:03:38동시에 소형 모델을 어떻게 활용하느냐의 문제이기도 합니다.
00:03:44270억 개의 매개변수를 가진 Qwen 3를 프롬프트 하나로 무엇이든 시킬 수 있는 완전 범용 모델처럼 무작정 쓸 수는 없습니다.
00:03:53대신 범용 모델의 작업 부하에서 특정 작업 조각들을 떼어내는 방식을 채택해야 합니다.
00:04:00그리고 각 작업에 가장 잘 맞는 오픈 소스 모델이 무엇인지 파악해야죠.
00:04:05성능 평가(Evals)도 좀 돌려보고, 뒤에서 다룰 적응(Adaptation) 과정도 거칩니다.
00:04:08그렇게 해야 올바른 품질을 확보하여 프로덕션 환경에 배포할 수 있습니다.
00:04:15여기에 9개의 서로 다른 모델을 사용하는 계약 검토 에이전트의 예시가 있습니다.
00:04:20소형 모델을 도입하기 위해 시스템을 구성하다 보면 여러분의 워크플로와 에이전트도 바로 이런 형태를 띠게 될 것입니다.
00:04:28하나의 API나 단일 모델에 수많은 서로 다른 요청을 무작정 쏟아붓는 대신,
00:04:36모델 군집(Fleet)을 활용하고 싶어질 것입니다.
00:04:38그러면 인프라 담당자들이 미치지 않도록 이 다양한 요소들을 어떻게 서비스할 것인가 하는 문제가 생깁니다.
00:04:45이것은 여러분이 구동하게 될 수많은 에이전트 중 단 하나일 뿐입니다.
00:04:48회사 내에 이런 에이전트가 10개쯤 더 있을 수도 있죠.
00:04:51결국 인프라의 범위가 그만큼 확장된다고 볼 수 있습니다.
00:04:57앞서 언급한 그 모든 다양한 작업들을 위해, 지금 이 순간에도 사용되기를 기다리는 오픈 소스 모델들이 존재합니다.
00:05:05OCR부터 문서 기반 질의응답, 이미지 라벨링, SQL 생성, 코드 검토에 이르기까지 말이죠.
00:05:14해당 작업들에 특화되어 미세 조정되고 훈련된 오픈 소스 모델들이 이미 있습니다.
00:05:19예를 들어 베트남어 영수증 OCR을 하도록 훈련된 오픈 소스 모델을 쓴다면, 그 프로젝트는 베트남어 영수증 데이터를 가장 많이 접해본 모델일 것입니다.
00:05:28누군가 시간을 들여 가능한 한 많은 데이터를 수집했기 때문이죠.
00:05:32해당 작업에서 그 모델은 거의 그 어떤 다른 모델보다 뛰어난 성능을 발휘할 것입니다.
00:05:35허깅페이스에는 이런 모델들이 수십만 개나 존재합니다.
00:05:41전부 거기에 있고 무료이며, 대부분 라이선스도 상당히 관대합니다.
00:05:46즉, 모델은 이미 존재하며 그것이 병목 현상의 원인은 아닙니다.
00:05:50우리는 2024년부터 오픈 소스 AI에 대해 이야기해 왔습니다.
00:05:56하지만 지금까지도 진정으로 대중화되지는 않았죠.
00:05:59기업에서 쓰인다고 해도 대개는 '오픈 소스 AI = AWS 베드록(Bedrock)'인 경우가 대부분입니다.
00:06:05하지만 베드록의 모델 카탈로그를 살펴보면 사용 가능한 모델 종류가 상당히 제한적이라는 것을 알 수 있습니다.
00:06:14이 모델들은 종종 최신 기술보다 2~3년 뒤쳐져 있는 낡은 모델들입니다.
00:06:19또한 베드록에서 미세 조정을 수행하더라도 미세 조정되거나 훈련된 아티팩트를 실제로 소유할 수는 없습니다.
00:06:25따라서 이를 비즈니스의 실질적인 경쟁력으로 활용하기 어렵습니다.
00:06:29결국 계속해서 베드록 인프라 위에서 서비스되는 형태에 머무르게 되죠.
00:06:32이제 독점 기술이 아닌 오픈 소스 인프라(VLLM, SGLang 및 기타 솔루션들)를 이용해 소형 모델 서비스를 구축한다고 해봅시다.
00:06:41이러한 도구들은 특정 모델이나 특정 하드웨어 조합에 미리 최적화되어 있지 않다는 점을 알아야 합니다.
00:06:48직접 튜닝을 해야 합니다. 이것이 바로 직접 만들기의 영역이죠.
00:06:51이러한 도구들은 모두 매개변수 탐색을 수행하고, 트래픽에 맞게 조정하는 등의 방법을 안내하는 가이드를 제공합니다.
00:07:00따라서 이런 도구를 도입하려고 할 때마다 일종의 개방형 연구 프로젝트를 진행하는 것과 같습니다.
00:07:05단순히 도구를 가져다가 가벼운 엔지니어링 작업으로 뚝딱 처리해서
00:07:10일주일 만에 고성능 서빙 인프라를 구축할 수 있는 그런 방식이 아닙니다.
00:07:14절대 그렇게 작동하지 않죠.
00:07:15이것이 바로 오픈 소스 도구들이 가진 전형적인 문제점입니다.
00:07:19지나치게 직접 해야 할 일이 많다는 점이죠.
00:07:21또한 소형 모델에 맞게 사전 튜닝되어 있지 않다는 문제 외에도, 수많은 서로 다른 모델을 사용하는 소형 모델 워크플로와 트래픽은
00:07:32추론 클러스터의 구도를 완전히 뒤집어 버립니다.
00:07:37일반적으로 커다란 단일 모델을 서비스할 때의 고민은 '어떻게 저 모델을 여러 GPU에 분산할 것인가'입니다.
00:07:44'모든 워커의 상태와 KV 캐시 상태 등을 파악하고 있는 라우터를 상단에 두고,
00:07:51이 요청은 이 워커나 저 워커 그룹으로 보낸다는 식의 하향식 라우팅 결정을 어떻게 내릴 것인가' 하는 것이죠.
00:07:59매우 하향식(Top-down) 구조입니다.
00:08:01하지만 작고 빠른 요청이 대량으로 들어오는 환경에서는 이러한 하향식 라우팅 방식이 병목 현상으로 작용합니다.
00:08:09라우터가 파악하고 있는 워커 상태 정보가 약간씩 최신 상태가 아니기 때문이며, 워커들의 로컬 큐를 균형 있게 조절하는 과정에서
00:08:16상단에서 완벽하게 맞는 사전 결정을 내려 워커들의 성능을 완전히 활용하기란 정말 어렵습니다.
00:08:26소형 요청이 너무 많이 몰리기 때문입니다.
00:08:29실제로 저희도 소형 모델과 이러한 트래픽 환경에서 vLLM 및 SGLang 라우터를 실험해 보았지만,
00:08:37상시 부하 상황에서 GPU 사용률을 20~30% 이상 끌어올리기가 매우 어렵습니다.
00:08:44라우팅 병목 현상 때문에 배치 크기가 제대로 조정되지 않기 때문입니다.
00:08:51그리고 세 번째 문제는 소형 모델을 쓸 때는 LoRA나 일반적인 모델 적응(Adaptation)의 혜택을 크게 누린다는 점입니다.
00:08:57따라서 우리가 서비스해야 할 트래픽에는 사람들이 찾아와 이런 요구를 하는 상황이 포함됩니다.
00:09:03“야, 나한테 LoRA가 10개 있는데 이걸 우리 서빙 스택에 어떻게 적용하지?”라거나 말이죠.
00:09:08“어젯밤에 커스텀 미세 조정을 마쳤는데, 이거 프로덕션 환경에서 서비스하고 싶어” 같은 요구 말입니다.
00:09:14AI 엔지니어와 인프라 담당자가 이러한 LoRA나 커스텀 모델들을 시스템에 올리기 위해 나누는 대화와 조율 과정이 바로 시간이 걸리는 부분입니다.
00:09:21결국 조직의 업무 속도(Velocity)를 갉아먹는 주범은 바로 이러한 소통 과정입니다.
00:09:24이상적으로라면 인프라 엔지니어는 자기 일을 하고, AI 엔지니어는 또 자기 일을 해야 하겠죠.
00:09:30일상적인 업무를 수행하는 데 서로 말을 섞을 일이 없어야 합니다.
00:09:37그래야 서로를 차단하거나 발목을 잡지 않으니까요.
00:09:41기본적으로 서로 방해가 되지 않아야 합니다.
00:09:45그런데 소형 모델 주변에서 발생하는 이러한 모델 적응 요구는 이 구조를 깨고 수많은 의견 교환을 유발합니다.
00:09:51문제는 바로 그거죠.
00:09:54이러한 소형 모델들이 많을 때 발생하는 과제들입니다.
00:09:58어떻게 클러스터를 구성하고 효율적으로 서빙할 것인가?
00:10:02우리는 이 문제를 한동안 다뤄왔습니다.
00:10:05저는 슈퍼링크드의 다니엘입니다. 사실 소개를 건너뛰었네요.
00:10:09샌프란시스코에 위치한 벤처 투자 지원 기업입니다.
00:10:13지난 몇 년간 AI 기반 검색, 문서 처리 시스템, 에이전트를 구축해 왔습니다.
00:10:20가장 큰 골칫거리는 항상 추론이었고, 특히 앞서 설명한 문제들이었습니다.
00:10:26그래서 다양한 환경에서 대규모 소형 모델 집단을 실행하기 위해 클러스터 토폴로지를 거듭 반복하며 탐색했습니다.
00:10:37무엇이 가용한지 알 수 없는 특정 환경의 플랫폼과 함께 배포해야 할 때가 있기 때문입니다.
00:10:44소형 모델을 사용하면 어떤 환경에서든 L4나 소규모 GPU 할당량을 확보하기가 훨씬 수월해집니다.
00:10:52제가 수렴해 온 클러스터의 토폴로지에 대해 조금 설명해 드리겠습니다.
00:10:58참고로 이 모든 것은 아파치 2.0 라이선스로 완전한 오픈소스입니다.
00:11:03그냥 가져다가 래핑만 하면 추론 스타트업이 되는 겁니다.
00:11:08컨트롤 플레인부터 GPU에서 실행되는 레이어까지 전부 오픈소스입니다.
00:11:14사정없이 전부 공개했습니다.
00:11:18토폴로지의 기본 구조는 게이트웨이가 존재한다는 점입니다.
00:11:21어디로 보낼지 사전에 결정하는 라우터 대신, 요청의 일부를 파싱하고 메타데이터를 첨부하는 게이트웨이가 있습니다.
00:11:30해당 요청을 공유 큐와 사이드 채널에 삽입합니다.
00:11:36이 부분에 대해서는 조금 더 다루겠습니다.
00:11:37그리고 워커들이 데이터를 워커 쪽으로 푸시하는 대신 중앙 집중식 큐에서 가져갑니다.
00:11:44이 방식으로 워커들은 스스로 부하를 더 잘 소화할 수 있습니다.
00:11:47그리고 워커 설정은 슬라이드가 있을 텐데요—다양한 모델 아키텍처의 복잡성을 일관된 워커 세트로 흡수하는 방법을 설명합니다.
00:11:57이 워커들은 서로 상충되는 파이썬 요구 사항 같은 문제를 겪지 않습니다.
00:12:03이것이 전반적인 토폴로지입니다.
00:12:06이것은 요청의 생애 주기 같은 것입니다.
00:12:11여기서 몇 가지 사항만 짚어보겠습니다.
00:12:15OpenAI 스타일의 API 표준에서 마음에 들지 않는 점 중 하나는 base64로 인코딩된 JSON 방식입니다.
00:12:25소형 모델에도 좋지 않고, 고성능 처리량에도 좋지 않습니다.
00:12:28그래서 저희는 바이너리 포맷인 메시지팩을 전반적으로 사용합니다.
00:12:31이를 통해 모든 멀티모달 데이터를 실제 API 게이트웨이를 통해 푸시할 수 있습니다.
00:12:37따라서 바이너리 데이터는 여기, 요청은 저기에 두는 식의 구조가 아닙니다.
00:12:42클러스터가 이미지나 비디오 같은 바이너리 데이터를 로드하기 위해 클라우드 스토리지에 접근할 필요도 없습니다.
00:12:48모두 인코딩하여 게이트웨이를 통해 전달합니다.
00:12:53게이트웨이는 내부 큐가 막히지 않도록 무거운 데이터 일부를 분리하고, 요청이 큐에 대기하는 동안 클라우드 스토리지로 오프로드합니다.
00:13:02예를 들어 1MB가 넘는 요청들은 분할한 뒤 백엔드에서 클라우드 스토리지를 사용합니다.
00:13:09하지만 사용자 입장에서는 모든 데이터를 API 레이어로 보내기만 하면 되므로 깔끔한 인터페이스가 유지됩니다.
00:13:19기본적으로 전체 스택은 REST입니다. 게이트웨이 REST, 워커 REST, 그리고 로컬 소켓을 통해 다양한 런타임에 연결됩니다.
00:13:30런타임으로는 PyTorch, Candle, SGLang을 사용하고 있습니다.
00:13:35최적화를 수행할 때, 어떤 런타임을 사용하든
00:13:43해당 런타임에서 실행되는 코드가 가장 효율적이도록 보장하는 방법에 대해서도 설명하겠습니다.
00:13:47이를 위해 자동 연구 루프(auto-research loop)를 갖추고 있습니다.
00:13:50아무튼 요청의 생애 주기는 대략 이런 식입니다.
00:13:54한 가지 팁은 요청이 가장 먼저 도달하는 게이트웨이가 너무 많은 작업을 처리하지 않도록 해야 한다는 점입니다.
00:14:05그렇지 않으면 병목 현상이 발생하기 때문입니다.
00:14:07요청 전체를 파싱조차 하고 싶지 않을 것입니다.
00:14:09패킷을 훑어보고 들어오는 데이터의 일반적인 형태를 파악한 뒤 어노테이션을 수행하고,
00:14:16수많은 워커들, 즉 큐 상태를 모니터링하며 그곳에서 작업을 가져가는 수백 개의 GPU가 처리하도록 하는 것입니다.
00:14:25큐는 NATS Jetstream을 사용하며, 초당 백만 개의 요청을 처리할 수 있습니다.
00:14:32따라서 이곳이 병목이 되기는 매우 어렵습니다.
00:14:35이러한 다양한 컴포넌트를 거칠 때마다 직렬화와 역직렬화를 반복하지 않는 것이 이상적입니다.
00:14:42그야 당연한 이야기입니다.
00:14:45이 애니메이션은 중앙 집중식 큐의 개념을 보여줍니다.
00:14:51하향식 라우터가 로컬 큐를 완벽하게 채우려고 애쓰는 방식은 기본적으로 불가능하므로,
00:15:01핵심 아이디어는 큐를 중앙 집중화하고, 워커들이 직접 배치 비용을 예측하여 자신의 배치를 형성하는 작업을 가져가게 하는 것입니다.
00:15:09그렇게 함으로써 훨씬 더 효율적으로 만드는 것입니다.
00:15:15여기서 한 가지 팁이자 부수적인 이야기로, 이런 작업을 시작해보면 공유 큐에서 얼마나 많은 항목을 가져와야 배치가 정말 최적의 크기가 될지 예측하기가 실제로 매우 어렵다는 것을 깨닫게 됩니다.
00:15:30그래서 일부 항목을 다시 큐에 돌려놓을 수 있는 메커니즘이 필요합니다.
00:15:35너무 많이 가져왔다는 것을 알게 되었을 때 말이죠.
00:15:37하지만 이건 네트워크 홉이기 때문에 문제가 됩니다.
00:15:39그래서 문제가 되죠.
00:15:40로컬에 여러 GPU가 있는 장치를 위해 이를 위한 특별한 최적화가 있습니다.
00:15:46한 장치의 여러 GPU에서 실행되는 로컬 프로세스들이 큐와 약간의 협상을 주고받을 수 있는 사실을 활용하는, 추가적인 머신 로컬 큐잉 요소가 존재합니다.
00:15:59네트워크를 통해서라면 밀리초 단위의 지연 시간이 추가될 텐데요.
00:16:03그래서 멀티 GPU 장치에 워커들을 공동 배치할 때만 네트워크를 통하지 않고 이 방식을 사용합니다.
00:16:11그리고 여기서 말하는 차이가 고작 5% 수준이 아닙니다.
00:16:16큐를 중앙 집중화하면 클러스터의 처리량이 두 배로 늘어납니다.
00:16:19따라서 이는 매우 유의미합니다.
00:16:22앞서 세 가지 다른 런타임을 언급했습니다.
00:16:25기본적으로 인코더 전용 모델의 경우, 저희가 직접 PyTorch 코드를 작성합니다.
00:16:33그리고 이를 최적화하며, 자동 연구 루프를 통해 최적화를 진행합니다.
00:16:38Candle도 마찬가지입니다.
00:16:39Candle을 다뤄본 지는 그리 오래되지 않았습니다.
00:16:42아직도 PyTorch 성능에 근접한 수준을 내지 못하고 있습니다.
00:16:45그래서 조금 더 연구 프로젝트에 가깝습니다.
00:16:47다만 의존성 문제로, PyTorch가 포함된 워커 도커 이미지는 약 12기가바이트에 달합니다.
00:16:54반면에 Candle을 사용하는 정적 링크된 바이너리 워커는 그 크기의 10% 정도밖에 되지 않습니다.
00:17:01콜드 상태에서 깨어나 여러 대의 기기에 이 이미지들을 로드해야 하는 상황을 중요하게 생각한다면,
00:17:0812기가에서 1기가 이하로 줄이는 것은 엄청난 차이를 만듭니다.
00:17:13이것이 바로 Candle 뒤에 있는 동기입니다.
00:17:15다만 PyTorch와 동일한 성능을 얻기가 정말 어렵다는 점입니다.
00:17:20그리고 SG-Lang은 기본(baseline) 용도로 두고 있습니다.
00:17:25앞서 언급했던 모든 매개변수들을 최적으로 튜닝했을 때 적어도 SG-Lang만큼의 성능은 나와야 한다는 것입니다.
00:17:34여기에 몇 가지 수치가 있습니다.
00:17:37예를 들어, 소켓과 저희의 Rust 사이드카로 SG-Lang을 래핑하면
00:17:43SG-Lang 단독 성능보다 오히려 향상될 수 있습니다. 순수 SG-Lang에는 없는 배치 처리 관련 기능을 수행하기 때문입니다.
00:17:54물론 그쪽도 그렇게 만들 수는 있겠지만요.
00:17:57SG-Lang에 커스텀 플러그인을 개발하는 등의 방식으로 말입니다.
00:18:00그렇게 하면 저희 성능과 맞출 수 있을지도 모릅니다.
00:18:04동일한 로직을 SG-Lang 코어 서버에 집어넣으면 되니까요.
00:18:07하지만 이제 SG-Lang에서만 작동하는 커스텀 코드를 개발하고 있는 셈입니다.
00:18:11소형 모델에서 얻는 전체적인 교훈은 런타임이 매우 다양하다는 점입니다.
00:18:16특정 런타임 하나에만 갇혀 지내고 싶지는 않을 것입니다.
00:18:22다양한 모델을 위해 매개변수화된 어댑터가 현재 대략 50개 정도 되기 때문입니다.
00:18:28따라서 이러한 기저의 복잡성을 어떻게든 다루어야 합니다.
00:18:32그 방법은 특정 런타임용 플러그인을 잔뜩 만드는 것은 아닐 겁니다.
00:18:36아마도 어떤 종류의 추상화일 것이며, 저희의 경우는 이 Rust 사이드카 개념과 소켓이 바로 그것입니다.
00:18:47이제 몇 가지 다른 수치에 대해 이야기하겠습니다만, 벤치마킹 관련 용어로서,
00:18:53변곡점(knee)은 서버의 트래픽을 늘려갈 때,
00:18:57즉 더 많은 처리량을 요구할 때의 개념입니다.
00:19:01요청에 따라 처리량이 선형적으로 증가하는 지점이죠.
00:19:05그러다 어느 순간 더 요구해도 처리량이 늘어나지 않는 지점에 도달하게 됩니다.
00:19:09그래서 처리량은 평탄화되고 지연 시간은 치솟게 됩니다.
00:19:12우리는 이를 '변곡점'이라고 부르며, 벤치마킹에서 유용한 개념입니다.
00:19:17포화 상태가 되는 지점이기 때문입니다.
00:19:20지연 시간을 해치지 않는 선에서의 최대 성능 지점이죠.
00:19:23비교적 소규모 하드웨어에서 무엇이 가능한지 몇 가지 아이디어를 제공해 드리겠습니다.
00:19:32그리고 다양한 유형의 소형 모델들에 대해서요.
00:19:34이 수치는 RTX Pro 6000에서 측정된 것입니다.
00:19:37NVIDIA L4, A100, RTX Pro 6000, H100 같은 대역의 하드웨어와 함께 작업하고 있습니다.
00:19:46다시 말씀드리지만, 이 GPU들은 어떤 클라우드에서든 온디맨드로 훨씬 쉽게 구할 수 있습니다.
00:19:52대부분의 대륙에서 할당량을 확보할 수 있죠.
00:19:56이런 장비를 사용하면 임베딩 모델의 경우,
00:20:01수억 개의 파라미터에 달하는 규모에서도
00:20:05초당 수십만 개의 토큰을 임베딩으로 인코딩할 수 있습니다.
00:20:12OpenAI API에 텍스트 임베딩을 요청하며 앉아 있는 모습을 상상해 보세요.
00:20:17대신 GPU 한 대를 두고 초당 50만 개의 토큰을 밀어 넣고 벡터를 얻어낼 수도 있죠.
00:20:26그렇지 않나요?
00:20:28다시 말해, 이게 와닿으시나요?
00:20:31그렇게 크지도 않은 단일 GPU에 초당 50만 개의 토큰을 밀어 넣으면서
00:20:38그 모든 걸 어딘가의 관리형 임베딩 엔드포인트에 보내고 훨씬 더 많은 비용을 지불하는 것과 달리, 검색 시스템용 벡터 임베딩을 얻을 수 있습니다.
00:20:49맞죠?
00:20:50그리고 이런 호출에 대해 수십 밀리초 정도의 지연 시간을 얻을 수 있습니다.
00:20:55Cohere나 OpenAI API 등을 사용하면 수백 밀리초가 걸리지만요.
00:21:02이건 로켓 과학이 아닙니다.
00:21:03소수의 GPU와 그 주변의 약간의 인프라만 있으면 엄청난 비용 절감과 지연 시간 개선을 이룰 수 있고 비교적 쉽게 운영할 수 있습니다.
00:21:17따라서 오픈소스 모델이나 소형 모델을 어디서부터 시작하든 임베딩은 가장 손쉬운 저열매(식은 죽 먹기)입니다.
00:21:26하지만 여기서 끝나지 않습니다.
00:21:27개체명 인식(NER)을 살펴보고 싶다고 해봅시다.
00:21:33다중 벡터 검색이나, 텍스트 생성 또는 구조화된 출력 생성 같은 작업도 살펴보고 싶을 겁니다.
00:21:42작업별 생성 모델로부터 초당 수천 개의 토큰 출력을 얻을 수 있습니다. 맨 아래에 있는 GPU 한 대당 초당 약 500개 정도를 얻을 수 있죠.
00:21:58합성 데이터를 생성하거나 파인튜닝 및 평가를 위한 주석을 생성할 때, 관리형 엔드포인트에서 그런 작업을 하지 마세요.
00:22:11우리가 통제할 수 있기 때문에 완벽한 작업입니다.
00:22:14품질을 검수할 수 있죠.
00:22:16자체 인프라에서 실행하는 오픈소스 모델에 완벽한 작업입니다.
00:22:20그리고 GPU 주변의 인프라가 합리적이라면, GPU 수에 비례하여 선형적으로 확장될 것입니다.
00:22:31소형 모델 서빙에 관심이 있다면 알아두어야 할 또 다른 아이디어는, 보통 모델당 워커 풀을 하나씩 둔다는 점입니다.
00:22:44일련의 워커와 노드가 있고, GPU가 있으며, 그것들을 띄우고 모델을 미리 로드하죠.
00:22:51모델 파라미터가 수백억 개에 달하기 때문에 로드하는 데 수십 분이 걸립니다.
00:22:55그러다 마침내 로드가 끝나면 안도하며 워커 풀을 갖게 됩니다.
00:22:59이러한 사고방식은 소형 모델에는 잘 통하지 않습니다.
00:23:02네, 네, 빨리요.
00:23:04남은 시간이 얼마나 되죠?
00:23:066분 초과요.
00:23:07아, 6분 초과요.
00:23:08알겠습니다.
00:23:09좋습니다.
00:23:10동일한 GPU에 모델들을 패킹하는 것이 더 빠릅니다.
00:23:12여전히 일부 모델은 고정(pin)하고 싶겠지만, 메모리 압박에 따라 지연 로딩(lazy loading)과 축출(eviction)을 수행하는 방식에 대한 이야기입니다.
00:23:26이 둘을 결합하는 방법을 찾아내야 합니다.
00:23:28자동 연구(auto research)에 대한 내용도 약간 있습니다.
00:23:32저희는 새로운 모델에 대한 지원과 성능을 추가하기 위한 자동 연구 루프를 운영하고 있습니다.
00:23:39측정 작업을 수행하여 자동 연구 루프에 피드백을 주고 수치를 향상시키는 내부 도구를 많이 구축했습니다.
00:23:47그리고 아마 가장 중요하게도, 저희가 모델 지원을 배포할 때는 모든 튜닝이 완료된 상태입니다.
00:23:53따라서 “좋아, 파라미터 스윕을 해보자” 같은 과정이 필요 없죠.
00:23:55전체 클러스터를 위한 엔드투엔드 설정 파일을 기본적으로 함께 번들링합니다.
00:24:00이것이 자동 연구 루프를 위한 설정입니다.
00:24:03하네스를 구축하고 루프를 실행하는 메타 루프 같은 것이 있습니다.
00:24:08그리고 작동 방식을 이해하는 데 도움을 주는 상단의 대시보드가 있죠.
00:24:12이를 위해 커스텀 UI를 갖추고 있습니다.
00:24:15그 산출물 중 하나는 훈련 비용이 80센트밖에 들지 않았고 개념 증명으로서 독일어 법률 문서의 검색 품질을 18% 향상시킨 LoRA였습니다.
00:24:27이게 전부입니다.
00:24:29따라서 소형 모델은 좋습니다.
00:24:30서빙하기도 비교적 쉽습니다.
00:24:32실제로 훨씬 저렴하고 빠릅니다.
00:24:35똑똑하기도 하죠.
00:24:36그리고 저 QR 코드는 방금 설명해 드린 저희 클러스터의 GitHub 저장소로 연결됩니다.
00:24:43스타(Star)도 눌러주세요.
00:24:44즐거운 셀프 호스팅 되시길 바랍니다.
00:24:45감사합니다.
00:24:46감사합니다.
00:24:47감사합니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video