스크립트
00:00:00안녕하십니까, 여러분. 코비(Corvi)의 시탄슈입니다. 저는 오늘 수직적
00:00:19모빌리티에 대해 말씀드리고자 합니다. 다소 거창한 제목을 정하긴 했습니다만, 기본적으로는
00:00:26소형 모델부터 대형 모델, 그리고 다양한 유형의 워크로드를 지원하기 위해
00:00:30코비에서 구축 중인 추론 플랫폼에 대해 이야기할 예정입니다. 제 소개를 간단히 하자면,
00:00:38약 4달 전에 코비에 합류하여 모든 추론 부문을 총괄하고 있습니다. 그전에는
00:00:44AWS 아나푸르나 랩스에서 학습 전반을 담당했고, 그 이전에는
00:00:49삼바노바에서 추론과 학습을 맡았습니다. 이 분야에서 제법 많은 경험을 쌓아왔죠.
00:00:56오늘 발표 진행 방식은 우선 우리가 보유한 소비 모델을 설명해 드린 뒤,
00:01:00플랫폼을 계속 변경할 필요가 없도록 어떤 형태의 플랫폼을 도출했는지,
00:01:04그리고 추론 서비스를 제공하는 기존 플랫폼을 어떻게 지속적으로 개선해 나가고 있는지,
00:01:09또한 그 과정에서 성능이 왜 그토록 중요한 역할을 하는지 말씀드리겠습니다.
00:01:14이 중 일부는 이전에 다룬 주제와 겹치는 부분이 있을 것 같네요.
00:01:20소비 모델에 대해 말씀드리겠습니다. 저희에게는 크게 두 가지 가장 핵심적인 소비 모델이 있습니다. 하나는 서버리스 형태로,
00:01:29고객 및 소비자가 직접 하드웨어를 관리할 필요가 없고,
00:01:35클러스터 관리나 오케스트레이션 등 그 어떤 것도 신경 쓸 필요가 없는 방식입니다.
00:01:40API와 UI가 제공되어, 접속하여 토큰당 비용을 지불하고 모델 서비스를 이용할 수 있습니다.
00:01:47여기서 가장 중요한 점은 카탈로그에서 제공하는 모델의 종류, 즉 고객이 이용 가능한
00:01:54모델의 폭입니다. 전용 서비스에 대해 먼저 말씀드린 뒤 서버리스로 돌아오겠습니다.
00:02:01서버리스 쪽에 매우 독특한 요소가 하나 있기 때문입니다. 저희가 제공하는 전용 추론 서비스는
00:02:05자신이 정확히 어떤 하드웨어를 사용하고 실행하는지 파악하고자 하는 고객에게 더 적합하지만,
00:02:11모델 배포 역시 고객의 몫입니다. 즉, 저희 서비스와 오케스트레이션 레이어를 사용하지만
00:02:18모델 배포는 고객에 달려 있습니다. 플랫폼에서 해당 기능을 제공하기 위한 기능과 제어 옵션을
00:02:25제공하는 한, 모델 성능 역시 고객에게 달려 있죠. 다시 서버리스로 돌아가서,
00:02:30흥미로운 점 중 하나는 일반적인 서버리스 모델의 경우 '시끄러운 이웃(noisy neighbor)' 문제가 존재한다는 것입니다.
00:02:38예를 들어 모든 사람이 완전히 동일한 모델에 몰리게 되면, 뒷단의 용량에 따라
00:02:43타임아웃이 꽤 빈번하게 발생할 수 있습니다. 그래서 저희가 서버리스 측면에 도입한 또 다른 기능은
00:02:48'프로비저닝된 처리량(provisioned throughput)'이라 부르는 개념입니다. 고객으로서 트래픽 프로필을 알고 계시고
00:02:55이를 저희에게 알려주시면, 내부 시스템상에서 해당 트래픽을
00:03:00고객 전용으로 할당해 드립니다. 여전히 정확히 어떤 하드웨어에서 실행되는지 신경 쓸 필요 없이,
00:03:04처리량과 SLA만 보장받으시면 됩니다.
00:03:07이것이 서버리스 측면의 또 다른 기능이며, 동일하게 토큰 단위로 과금되지만
00:03:12시끄러운 이웃 문제에 직면하지 않는다는 이점이 있습니다.
00:03:19저희가 다루고 관찰하고 있는 몇 가지 다양한 워크로드 유형과 그 형태에 대해 짚어보겠습니다.
00:03:27이들 간의 비율은 끊임없이 변하고 있지만, 에이전트 기반 워크로드가 매우 큰 비중을 차지하고 있습니다.
00:03:32에이전트 기반과 대화형은 유사한 면이 많은데, 입력 시퀀스 길이가 매우 길고
00:03:39일반적으로 출력 시퀀스 길이는 매우 짧습니다. 하지만 에이전트 기반과 대화형의 가장 큰 차이점은
00:03:43에이전트 기반의 멀티 턴은 지연 시간이 매우 짧은 반면, 대화형은 사용자의 응답을 받은 뒤
00:03:50답변을 읽고 다시 응답해야 한다는 점입니다. 그래서 상당한 차이가 존재합니다.
00:03:56그리고 이 큰 차이점은 결과적으로 KV 캐시 관리와 관련된
00:04:01부분으로 이어지게 됩니다. 이 두 가지는 모두 실시간 워크로드이며, 또 다른 실시간 워크로드로는
00:04:09안정적인 스트리밍이 필요하고 지연 시간에 매우 민감한 음성 및 비디오가 있습니다. 에이전트 및 대화형
00:04:16측면에서는 주로 처리량 관점의 요구사항이 크고 지연시간 민감도는 상대적으로 낮지만, 실시간
00:04:23음성 및 비디오는 지연 시간에 엄청나게 민감합니다. 배치 워크로드의 경우, SLA 조건이 매우
00:04:32유연합니다. 수 초에서 수 분, 일부 고객의 경우 수 시간 단위까지 허용하기도 하죠.
00:04:37'10시간에서 12시간 정도의 작업 시간만 주고 가능한 한 다 밀어 넣을 테니,
00:04:44가능할 때 처리해 달라'는 식입니다. 이러한 배치 워크로드는 스택 설계 시
00:04:52요구사항 결정 요소로 작용하게 됩니다. 죄송합니다. 기술 스택 설계 판단의 기준이 되는 것이죠.
00:04:59이 네 가지 형태의 워크로드를 상상해 보세요. 시간의 차원 안에서,
00:05:04하부 인프라 활용도를 극대화할 수 있도록 워크로드 특성을 잘 조합해야 합니다.
00:05:12현재 저희 스택이 어떻게 구성되어 있는지 개략적으로 말씀드리고, 요청 처리
00:05:19흐름에 대해 짧게 설명해 드리겠습니다. 서버리스와 전용 서비스 모두, 화면 우측을
00:05:24보시면 플랫폼 영역에서 컨트롤 플레인을 통해 권한 부여,
00:05:31속도 제한, 사용량 추적 등이 이루어지는 것을 확인하실 수 있습니다. 이에 맞춰 비용이 청구되는 구조죠.
00:05:37또한 관찰 가능성(Observability)을 확보하여 체결된 SLA를 위반하지 않도록 관리합니다.
00:05:45플랫폼 하단에는 매우 개략적인 수준으로 vLLM, SGLang, TensorRT-LLM 등
00:05:52다양한 추론 엔진을 제시해 두었습니다만, 이에 관해 더 자세히 다룰 내용들이 있습니다.
00:06:00그리고 그 하단에 초록색으로 표시된 부분은 다양한 하드웨어 구성 요소들을 나타냅니다.
00:06:09따라서 플랫폼은 다양한 세대의 GPU, 특히 저희가 사용하는
00:06:15NVIDIA GPU 전반에 걸쳐 워크로드를 분산시킬 수 있는 충분한 역량을 갖추어야 합니다.
00:06:21그럼 몇 가지 예를 들어보겠습니다. 클라이언트 측의 앱이나 노트북,
00:06:31혹은 에이전트를 통해 요청이 생성된다고 해봅시다. 이 요청은 게이트웨이에 도달합니다.
00:06:36게이트웨이에 도달하면, 앞서 컨트롤 플레인에 대해 말씀드린 것처럼 인증 등의
00:06:42절차를 거친 후 서버리스 또는 전용 서비스로 분기됩니다. 서버리스의 경우
00:06:48토큰당 과금이므로 토큰 사용량이 모니터링됩니다. 실제 토큰 내용이 아닌
00:06:53단순 사용량만 모니터링되는데, 저희는 제로 데이터 보존(ZDR) 정책을 준수하기 때문입니다.
00:06:59멀티 테넌시인지 또는 프로비저닝된 형태인지에 따라 결정되는데, 프로비저닝된 경우라면
00:07:05라우터 하단에서 프로비저닝된 처리량을 이용하는 고객을 위해 전용 배포 항목을
00:07:12명확히 타겟팅해야 함을 인식합니다. 멀티 테넌트 고객을 위한 별도의 배포 환경도 존재합니다.
00:07:17여기서 라우터가 매우 중요한데, 라우터는 KV 캐시를
00:07:26인지하여 라우팅 경로를 결정하는 역할을 담당하기 때문입니다. 왜 이것이 중요할까요? 워크로드
00:07:31프로필을 설명해 드릴 때 말씀드렸듯이, 에이전트 유스케이스는 일반적으로 입력 시퀀스 길이가
00:07:39매우 길며, 기업이나 고객 상황에 따라 다르지만 전체 입력 시퀀스 길이의
00:07:44약 80~90%는 서로 다른 여러 요청 간에 동일하게 유지됩니다.
00:07:51따라서 매번 프리필(pre-fill)을 재계산하거나 재수행할 필요가 전혀 없습니다.
00:07:57프리필 단계는 연산량이 매우 많아 비싸므로, 캐시 히트율을 높일수록
00:08:04비용을 절감할 수 있습니다. 어디서나 토큰 단가를 보면 일반 입력 토큰 단가와
00:08:11캐시된 입력 토큰 단가가 훨씬 저렴하게 책정되어 있는 이유가 바로 이 때문입니다. 따라서 캐싱은
00:08:18매우 중요해집니다. 하단에서 하드웨어를 분할하는 방식은 전적으로 플랫폼에서의
00:08:26선택에 달려 있으며, 저희는 두 가지 방식 모두 적용할 수 있는 기능을 제공합니다. 유스케이스가 원할 경우
00:08:31프리필과 디코드의 분리를 수행할 수도 있고, 분리가 모든 유스케이스에서 효율적이지는 않으므로 하지 않을 수도 있습니다.
00:08:41또 다른 요청 처리 흐름을 살펴보겠습니다. 전용 서비스 고객의 경우 어떻게 처리되는지 보겠습니다.
00:08:48전용 서비스 고객 역시 적절히 격리된 상태로 자신들을 위해 설정된 게이트웨이를 거치게 됩니다.
00:08:55과금은 토큰 기준이 아닌 GPU 당 시간당 사용량을 기준으로 이루어집니다.
00:09:03프라이빗 게이트웨이 형태이므로 시끄러운 이웃 문제가 없으며 타인이 접근할 수 없습니다.
00:09:09동일한 라우터 로직이 적용되어, 매우 유사한 요청이 들어올 경우 캐시 히트율을 최대한 높여줍니다.
00:09:18그리고 고객이 할당받은 전용 GPU에 구축한 배포 환경에 따라,
00:09:24프리필-디코드 분리를 적용할지 여부를 스스로 결정할 수 있습니다. 어떤
00:09:29엔진(vLLM, SGLang, TensorRT-LLM)을 사용할지도 선택 가능합니다. 또한 고객이 확보한
00:09:35용량의 규모에 따라, 전체 클러스터로 확장 가능한 단일 배포 환경만 운용할지,
00:09:42아니면 여러 다양한 모델과 다수의 배포 환경을 구성할지 직접 결정할 수 있습니다.
00:09:47여기서 라우터와 관련해 한 가지 짚고 넘어가고 싶은 점은
00:09:54서로 다른 영역(Zone) 및 리전(Region) 간의 이종 인프라 용량이
00:09:59지원된다는 사실입니다. 이러한 환경 전반에 걸쳐 로드 밸런싱을 수행하는 것은 상당히 까다로운 과제입니다.
00:10:04따라서 저희가 취하는 우선순위는 첫째로 KV 캐시 지역성(Locality)이며, 그다음이 부하가 가장 적은 곳으로의 폴백(Fallback)입니다.
00:10:16그 부분은 여기까지 하고요. 다루고 싶은 또 다른 요청 처리 흐름이 있는데,
00:10:21다이어그램에서는 잘 안 보일 수 있지만 배치 워크플로우를 살펴보겠습니다.
00:10:25배치 워크플로우의 경우 실제로 수행하는 방식은, 예컨대 동일한 전용 추론 고객이
00:10:31미국 낮 시간대에는 자신들의 실시간 워크로드를 실행하고
00:10:37저녁부터 밤 시간대에는 배치 워크로드를 실행하고 싶어 한다면, 해당 시간이 지난 후 동일한 인프라 용량을
00:10:43배치 워크로드 실행용으로 스케줄링할 수 있습니다. 그래서 저희는 스케일 업 및 스케일 다운 시점을
00:10:51지정할 수 있는 API 기능을 제공하며, 일정에 따라 고객이 축소 가능 여부를 알려주면
00:10:56용량을 축소한 뒤 밤새 배치 처리용으로 개방하게 됩니다.
00:11:05KV 캐시 측면의 최적화에 대해 꽤 많이 말씀드렸습니다만, 조금만 더 강조드리고 싶습니다.
00:11:10가장 흥미로운 부분 중 하나이기 때문입니다. 캐시 히트율을 높일수록
00:11:19가장 비용이 많이 드는 프리필(pre-fill) 비용을 절감할 수 있습니다.
00:11:26에이전트 워크로드의 여러 턴에 걸쳐 KV 캐시를 재사용하면, 턴 사이마다
00:11:31입력 시퀀스 길이에 중복되는 프리필이 많이 발생합니다.
00:11:38챗 워크로드를 예로 들면, KV 캐시 오프로딩이 매우 중요한 이유가
00:11:43사용자가 질문을 주고받는 여러 턴 사이에 대기 시간이 길어지기 때문입니다.
00:11:49하지만 해당 대화의 기존 캐시 내용을 완전히 비워버리면
00:11:57같은 채팅에서 다음 질문을 할 때 시간 대기 질 수밖에 없습니다.
00:12:02그래서 캐시를 완전히 축출하고 프리필을 다시 수행하는 대신
00:12:08자체 기술이나 외부의 LM Cache, Mooncakes 같은 기법들을 활용합니다.
00:12:17즉, KV 캐시를 고대역폭 스토리지로 오프로드하여
00:12:21이러한 프리필 데이터를 대량 저장해 두고, 해당 대화에 관한
00:12:28후속 요청이 들어올 때 HBM으로 즉시 로드할 수 있게 합니다.
00:12:37성능 레버 측면에서는, 앞서 언급했던 PD-DSAG 외에도
00:12:41양자화(Quantization) 및 추측적 디코딩(Speculative decoding)이 있으며,
00:12:48병렬화 정도와 전략을 신중하게 선택하는 것이 매우 중요합니다.
00:12:54저희가 집중적으로 활용해 온 핵심 레버는 NVFP4 양자화와 추측적 디코딩입니다.
00:13:01고객 데이터셋에 맞춰 수용 수용률(acceptance length)을 높이는 스펙큘레이터를 학습시켜
00:13:07결과적으로 출력 처리량을 획기적으로 개선할 수 있는
00:13:12기능도 제공하고 있습니다. 비동기로 데이터를 받아
00:13:20스펙큘레이터를 학습시킨 후 고객 배포 환경에 적용해 드립니다.
00:13:26여기 보이는 스크린샷 3개는 저희 팀에서
00:13:32지난 한 달간 작업한 결과물입니다. 보시다시피 저희는
00:13:39Kimi 2.6, 2.7 리더보드 상위권에 빠르게 진입했고, 이는 Artificial Analysis 기준입니다.
00:13:46이전 세션으로 돌아가서, 이 결과를 신뢰할 수 있을까요? 그래서 GLM의 경우 OpenRouter 결과를 준비했습니다.
00:13:52Artificial Analysis의 벤치마크는 매우 특정된 워크로드인 반면,
00:13:58OpenRouter는 실제 사용자 트래픽 기준입니다. OpenRouter 쪽에 표기된 Weights & Biases는
00:14:05브랜딩은 다르지만 저희 Cirrascale(Curvy)을 의미하며, 약 1년 전에 인수했습니다.
00:14:09저희 배포 환경의 처리 속도가 Fireworks에서 제공하는
00:14:16Fireworks Fast의 속도와 맞먹는 수준임을 확인할 수 있습니다.
00:14:21하지만 여기서 가장 강조하고 싶은 것은 성능 최적화에 사용된 기저 기술입니다.
00:14:27결국 고객에게 제공하고자 하는 핵심 가치는 가성비와 성능 혜택이기 때문입니다.
00:14:36요약하자면, 단일 플랫폼의 가치를 강조하고 보여드리고자 했습니다.
00:14:44고객을 위한 서버리스 및 전용(Dedicated)이라는 두 가지 소비 모델과 함께,
00:14:49서버리스 내에서도 종량제와 프로비저닝된 처리량 방식 두 가지를 설명해 드렸습니다.
00:14:53그리고 전체 스택의 성능 최적화를 통해 복리 효과로 이점을 극대화합니다.
00:15:01이상입니다. 감사드립니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기