자체 GPU에서 대규모 언어 모델을 호스팅하려고 시도한 적이 있는데, 마치 매우 배고픈 다마고치를 입양한 것처럼 느껴졌나요? VRAM을 공급하고, 커널을 달래고, 마침내 답변을 요청하면... 5초 동안 깜박거리다가 사라집니다. '바닐라' LLM 서버를 사용한 제 주말이 그랬습니다. 그러다가 vLLM을 설치했습니다.
스포일러: vLLM은 LLM 추론을 마치 세발자전거를 Tesla로 바꾼 것처럼 느끼게 해주는 오픈 소스 엔진입니다. 이 vLLM 리뷰에서는 vLLM이 무엇인지, 하드웨어 예산으로 어떻게 더 많은 토큰을 짜내는지, 어디에서 빛을 발하고 어디에서 넘어지는지, 그리고 누가 카트, 클러스터 또는 '나중에' 더미에 넣어야 하는지를 자세히 살펴봅니다.
쉬운 영어로 (그리고 GPU 눈물은 적게) vLLM이란 무엇인가요?
vLLM은 대규모 언어 모델을 위한 오픈 소스 추론 및 서비스 엔진입니다. 요청을 예약하고, 토큰을 GPU 메모리에 압축하고, 좌석(VRAM)을 비워두지 않고 효율적으로 이륙하는 항공 교통 관제관, 수하물 처리 담당자, 할인 항공사를 하나로 합쳐놓은 것이라고 생각하세요. Llama, Mistral, Mixtral, Phi, Qwen, Gemma와 같이 친숙한 모델을 친숙한 API(OpenAI 스타일, OpenAI 호환) 뒤에 래핑한 다음, 영리한 메모리 트릭과 스케줄링으로 터보차지합니다.
단순한 루프 또는 범용 서비스 프레임워크로 LLM을 실행하려고 시도한 적이 있다면 가장 큰 속도 저해 요인인 낭비되는 메모리를 만났을 것입니다. vLLM의 대표적인 기능은 운영 체제의 페이지처럼 키/값 어텐션 캐시를 취급하는 동적 메모리 관리자인 PagedAttention입니다. 다시 말해, 모든 대화에 VRAM에 있는 개인 펜트하우스를 제공하는 대신 펜트하우스를 공동 작업 공간으로 바꿉니다. 더 많은 사람(요청)이 들어갈 수 있습니다. 모두가 더 빨리 입력합니다.
이 vLLM 리뷰는 누구를 위한 것인가요?
- 짧은 대기 시간 채팅과 높은 처리량의 배치 작업을 원하는 AI 앱을 구축하는 팀.
- 상용 LLM 엔드포인트에 대한 오픈 소스 대안을 찾는 인프라 담당자.
- 성능 저하 없이 빠른 모델 교체가 필요한 연구원.
- 자체 호스팅을 통해 토큰 비용을 절감하려는 스타트업 실용주의자.
'프롬프트 상자와 분위기만 있으면 돼'라고 생각한다면 관리형 API를 선호할 수 있습니다. '예산은 10배 늘리지 않고 처리량을 10배 늘리고 싶다'면 계속 읽으세요.
vLLM의 주요 기능 (그리고 왜 신경 써야 하는가)
- PagedAttention: 어텐션 KV 캐시를 위한 메모리 페이징. vLLM이 프레임을 드롭하지 않고 많은 요청을 처리할 수 있는 이유입니다.
- Continuous batching: 새로운 요청이 진행 중인 배치에 합류하므로 GPU가 계속 작동하고 대기 시간이 정상적으로 유지됩니다.
- OpenAI 호환 API: 최소한의 코드 변경으로 OpenAI용으로 구축된 도구 및 SDK에 연결하세요.
- Tensor/양자화 지원: FP16, BF16 및 널리 사용되는 양자화된 가중치(예: AWQ, GPTQ (해당하는 경우))를 지원하므로 더 큰 두뇌를 더 작은 GPU에 맞출 수 있습니다.
- Multi-GPU 및 분산 서비스: 단일 A100이 땀을 흘리기 시작하면 확장하세요.
- 스트리밍 토큰: 사용자는 할리우드 해킹 장면처럼 단어가 입력되는 것을 보게 되는데, 왠지 모르게 모든 것이 더 빠르게 느껴집니다.
- LoRA/어댑터 지원 (모델에 따라 다름): 동일한 기본 모델에서 미세 조정된 변형을 제공하는 경우에 유용합니다.
빠른 설정 스토리 (일명: 첫 번째 토큰까지 얼마나 빨리 도달할 수 있나?)
- pip를 통해 vLLM을 설치합니다. 소환 의식은 필요하지 않습니다:
pip install vllm
- Hugging Face 또는 로컬 가중치에서 모델을 지정합니다.
- OpenAI 호환 엔드포인트로 서버를 시작합니다.
- 컬하거나 기존 OpenAI 클라이언트에 연결합니다.
소비자 GPU와 데이터 센터 카드가 있는 워크스테이션에서 테스트한 결과, 특히 부하가 걸린 상태에서 첫 번째 토큰까지 걸리는 시간이 스톡 트랜스포머 서버 설정보다 눈에 띄게 빨랐습니다. 여러 사용자(또는 자체 배치 작업)가 서버에 몰릴 때 마법이 나타납니다. vLLM은 GPU에 계속 공급합니다.
벤치마크, 대기 시간 및 실제 분위기
vLLM 리뷰에서 눈에 띄었던 점은 다음과 같습니다.
- 처리량: 지속적인 배치 처리를 통해 vLLM은 GPU를 타원만 인쇄하는 우주 히터로 바꾸지 않고도 초당 많은 요청을 처리할 수 있습니다. 더 많은 동시 요청을 (합리적인 범위 내에서) 던질수록 더 많이 유연해집니다.
- 대기 시간: 첫 번째 토큰까지 걸리는 시간은 경쟁력이 있으며, 특히 스트리밍이 활성화되고 프롬프트가 짧거나 중간 정도인 경우 다른 오픈 소스 서버보다 나은 경우가 있습니다.
- 긴 출력: 지속적인 생성은 꾸준합니다. 매우 긴 생성의 경우 VRAM을 편안하게 유지하기 위해 max_tokens, 빔 설정 (필요한 경우) 및 온도를 조정해야 합니다.
- 혼합 워크로드: 채팅, 도구 사용 프롬프트 및 가벼운 배치 점수 매기기를 동시에 처리하는 데 이상하게 좋습니다. 마치 아무도 중독시키지 않고 팬케이크와 팟타이를 제공하는 식당 같습니다.
수치는 GPU 클래스, 양자화, 시퀀스 길이 및 모델 선택에 따라 달라집니다. 그러나 패턴은 일관적입니다. 동시성이 증가함에 따라 vLLM이 앞서갑니다.
다른 LLM 서버와 비교하여 vLLM이 빛나는 곳
- 우선 순위가 대기 시간 저하를 최소화하면서 많은 대화형 사용자를 처리하는 것이라면 vLLM의 스케줄러와 PagedAttention이 돋보입니다.
- 기존 앱에 연결할 OpenAI 호환 엔드포인트가 필요한 경우 플러그 앤 플레이가 용이합니다.
- 비용을 최적화하는 경우 약간 더 작은 GPU 클래스로 다운시프트하거나 동일한 하드웨어에서 더 많은 req/sec를 짜낼 수 있습니다. 전 세계 CFO들이 막 귀를 쫑긋 세웠습니다.
vLLM이 좌절감을 줄 수 있는 곳 (마법의 요정이 아님)
- 모델 호환성이 보편적이지 않습니다. 가장 인기 있는 오픈 가중치는 잘 실행되지만 이국적인 아키텍처 또는 최첨단 양자화 형식은 조정이 필요하거나 아직 지원되지 않을 수 있습니다.
- 메모리는 여전히 물리학입니다. PagedAttention이 도움이 되지만 100명의 동시 사용자가 있는 6GB GPU의 7B 모델은 여전히 시트콤이지 서버가 아닙니다.
- 고급 다중 테넌트 및 보호 장치는 다른 도구와 페어링하거나 글루 코드를 작성해야 할 수 있습니다.
- 업데이트가 빠르게 진행됩니다. 기능에는 플러스이고 정체된 안정성을 원하면 마이너스입니다.
일반적인 용의자와 vLLM (친근한 대결)
- Text Generation Inference (TGI): TGI는 세련되고 기업에서 인기가 있습니다. vLLM은 특히 채팅 워크로드의 경우 동적 배치 처리 및 PagedAttention으로 처리량에서 종종 앞섭니다. TGI는 강력한 Hugging Face 통합 및 견고한 프로덕션 인체 공학을 제공합니다. 원시 서비스 속도와 OpenAI와 유사한 API를 위해 vLLM을 선택하고, HF 도구에 깊숙이 들어가 있고 해당 운영 패턴을 원하는 경우 TGI를 선택하세요.
- OpenLLM/FastChat/기타: 많은 것들이 실험에 좋습니다. vLLM은 일반적으로 동시성 및 메모리 효율성에서 승리합니다. 트래픽이 급증하는 소비자 앱을 구축하는 경우 vLLM의 스케줄링은 꼬리를 짧게 유지하는 데 도움이 됩니다.
- 사용자 정의 Triton/Transformers 스택: 평균 서버를 직접 만들 수 있지만 vLLM은 어쨌든 구축할 트릭을 패키지화하고 작은 도시의 커널을 유지 관리할 필요가 없습니다.
심층 분석: PagedAttention이 중요한 이유
모델의 어텐션 사고 공간을 거대한 화이트보드라고 상상해 보세요. 모든 대화가 그것을 활용합니다. 대부분의 서버는 낙서 두 개와 스마일리조차도 전체 섹션을 할당합니다. PagedAttention은 해당 화이트보드를 스티커 메모로 분할하고 안팎으로 섞습니다. 더 많은 사람들이 동시에 그릴 수 있고 간격이 줄어들고 낭비되는 공간이 줄어듭니다. 이것이 vLLM이 실제 세계, 즉 많은 사용자가 임의의 것을 요구할 때 성능을 유지하는 이유입니다.
개발자 경험: 아늑한가요, 아니면 바삭바삭한가요?
- API 편의성: OpenAI를 모방한 REST 엔드포인트를 얻을 수 있습니다. 기존 클라이언트, 프롬프트 템플릿 및 로거를 가져오세요.
- 구성: 배치 크기, 텐서 병렬 처리, 양자화 및 스케줄러 노브에 대한 충분한 플래그가 있는 합리적인 기본값입니다.
- 관찰 가능성: 메트릭 엔드포인트, 로그 및 Prometheus 후크가 있지만 자체 추적을 추가해야 할 것입니다.
- 확장성: 토크나이저, 어댑터 및 백엔드에 대한 플러그인 스타일 지원이 개선되고 있습니다. 자정에 코드를 읽는 것을 좋아한다면 리포지토리가 활성 상태이고 접근하기 쉽습니다.
비용 계산: vLLM이 GPU 청구서를 변경하는 방법
- 더 나은 활용률 = 유휴 주기가 줄어듭니다. 시간당 (클라우드) 지불하거나 상각 (온프레미스)하는 경우 vLLM의 처리량 증가는 달러당 더 많은 토큰으로 변환됩니다.
- 양자화 이득: 지원되는 AWQ/GPTQ/INT8을 실행하면 VRAM 공간을 줄이고 GPU 티어를 낮추거나 카드당 더 많은 동시 작업을 맞출 수 있습니다.
- 수평 확장: 더 많은 성능이 필요한 경우 vLLM은 여러 GPU 및 노드에서 작동합니다. 아키텍처를 믹서기에 던지지 않고도 선형적으로 성장할 수 있습니다.
경험 법칙: 서비스에 소수의 동시 사용자보다 많거나 배치 작업을 파도처럼 실행하는 경우 vLLM의 효율성이 빠르게 나타납니다. 프롬프트를 테스트하는 경우에만 있으면 좋습니다.
실제 시나리오: vLLM이 제 역할을 하는 곳
- 동시에 많은 사용자가 있는 채팅 어시스턴트: 고객 지원, 내부 IT 도움말 또는 학생들이 자정 5분 전에 에세이를 브레인스토밍하는 데 도움이 되는 앱.
- 콘텐츠 생성 파이프라인: 블로그 개요, 이메일 초안, 코드 주석 - DMV처럼 보이는 대기열 없이 병렬로 생성됩니다.
- 도구 기반 에이전트: 모델이 도구 호출을 위해 일시 중지되면 vLLM의 배치 처리는 GPU를 다른 요청으로 계속 사용 중입니다.
- RAG 시스템: vLLM은 리트리버가 다른 곳에서 책벌레 작업을 수행하는 동안 생성 계층으로 잘 작동합니다.
vLLM 설정 팁 (재미있는 방법으로 배움)
- 실제로 제공할 모델부터 시작하세요. 작은 3B를 벤치마킹한 다음 70B를 배포하고 GPU가 왜 소리치는지 궁금해하지 마세요.
- 최대 컨텍스트 길이를 조정합니다. 컨텍스트 크기를 과도하게 늘리면 VRAM이 날아가고 크기를 올바르게 조정하면 동시성이 높아집니다.
- 스트리밍을 활성화합니다. 사용자는 더 빠른 응답을 느끼고 UI 토큰을 일찍 플러시할 수 있습니다.
- 실제 트래픽 패턴으로 테스트합니다. 급증? 꾸준함? 혼합? vLLM의 스케줄러는 모양에 따라 다르게 빛납니다.
- 모든 것을 기록합니다. 대기 시간 p50, p95, 토큰 처리량 및 OOM 이벤트는 다음에 어디를 압착해야 하는지 알려줍니다.
보안 및 거버넌스: 자신의 성인용 바지를 가져오세요.
vLLM은 도덕적 나침반이 아닌 서비스 엔진입니다. 조정, PII 스크러빙, 속도 제한, 테넌트 격리 또는 감사 추적이 필요한 경우 게이트웨이 또는 앱 계층에서 볼트로 고정하세요. 좋은 소식은 OpenAI 호환 인터페이스를 통해 좋아하는 정책과 미들웨어를 더 쉽게 교체할 수 있다는 것입니다.
세부 사항: 이 vLLM 리뷰의 호환성 및 주의 사항
- 모든 모델 아키텍처 또는 양자화 가중치가 플러그 앤 고가 되는 것은 아닙니다. 문서와 커뮤니티 문제를 확인하세요. 지원 속도는 빠르지만 참신함은 항상 안정성보다 빠릅니다.
- CPU 폴백? vLLM은 GPU에서 가장 행복합니다. CPU에서 실험할 수 있지만 스키 부츠를 신고 마라톤을 뛰는 것과 같습니다.
- 다중 GPU 샤딩은 강력하지만 신중한 구성이 필요합니다. 특히 프로덕션 SLA의 경우 장애 조치 및 웜 스타트를 테스트합니다.
빠른 시작: 정신적 체크리스트
- 하드웨어: 대상 모델에 충분한 VRAM과 동시성을 위한 헤드룸이 있는 GPU.
- 모델: 잘 지원되는 제품군 (Llama, Mistral, Mixtral, Qwen, Gemma)을 선택하고 토크나이저/양자화 호환성을 확인합니다.
- 서비스: OpenAI API를 켜고 vLLM을 실행하고, 응답을 스트리밍하고, 컨텍스트 및 max_tokens를 합리적으로 설정합니다.
- 규모: GPU 또는 노드를 추가합니다. 라우팅, 속도 제한 및 인증을 위해 게이트웨이를 사용합니다. 클라우드인 경우 자동 확장을 고려하세요.
- 비용: 초당 토큰 수, 동시성 및 평균 출력 길이를 측정합니다. 각 변경 후 다시 실행합니다.
주목할 가치: Sider.AI가 이 그림에 적합한 위치
빌더에게 알림: 모델을 선택하고, 프롬프트 간의 속도를 비교하고, 일반적으로 반복하는 동안 정신을 잃지 않으려고 노력하는 경우 Sider.AI는 훌륭한 건전성 검사가 될 수 있습니다. 다양한 백엔드에서 프롬프트를 초안 작성, 테스트 및 개선한 다음 비용 또는 제어를 위해 자체 호스팅할 때가 되면 vLLM으로 이동할 수 있습니다. Sider.AI를 피트 크루로 생각하고 트랙이 열리면 운전하는 경주용 자동차로 vLLM을 생각하세요. 지금 vLLM을 선택해야 하는 사람은 누구인가요?
- 예: 사용자 기반이 증가하는 스타트업, 여러 팀을 지원하는 내부 플랫폼, 유료 API에서 자체 호스팅으로 이동하는 제품 팀.
- 아마도: 옵션을 탐색하는 솔로 개발자. 트래픽이 매우 적은 경우 관리형 API가 지금은 더 간단하고 저렴할 수 있습니다.
- 아직 아님: 서비스 계층에서 턴키 규정 준수 및 격리가 필요한 고도로 규제되는 조직. 먼저 더 많은 보호 장치가 필요합니다.
vLLM 장단점 (미화 없음)
장점
- OpenAI 호환 API로 간단하게 마이그레이션
- PagedAttention으로 강력한 메모리 효율성
- 인기 있는 오픈 모델 및 양자화에 대한 우수한 지원
단점
- 보편적인 모델/양자화 지원이 아님; 약간의 조정이 필요함
- GPU에서 가장 좋음; CPU 사용은 주로 과학 실험용임
- 프로덕션급 다중 테넌트 및 거버넌스에는 추가 기능이 필요함
- 빠른 변경은 때때로 업그레이드 충돌을 의미할 수 있음
이 vLLM 리뷰의 평결
vLLM은 학문적으로 똑똑하고 프로덕션 실용적인 드문 오픈 소스 프로젝트입니다. 사우나로 두 배가 되는 GPU 팜을 가동하지 않고 대규모로 LLM을 실행하는 데 진지하다면 최우선 순위 목록에 있어야 합니다. 아마도 맨 위에 있을 것입니다. 모델을 제공하는 유일한 방법은 아니지만 지금은 가장 빠르고 유연하며 개발자 친화적인 방법 중 하나입니다.
달리 말하면 현재 설정으로 인해 사용자가 인생 선택을 재고할 만큼 오래 기다리게 된다면 vLLM은 사용자가 재고하기 전에 답변을 제공하는 데 도움이 될 것입니다. 그리고 그것이 요점이지 않습니까?
실행 계획: 이번 주에 LLM 속도 향상
- 1일차: 대상 모델로 vLLM을 설정합니다. 스트리밍을 켭니다. 실제 프롬프트로 공격하세요.
- 2일차: 컨텍스트 창과 배치 설정을 조정합니다. 더 많은 요청을 맞추기 위해 지원되는 양자화를 시도합니다.
- 3일차: 게이트웨이와 로그를 추가합니다. p95 대기 시간과 달러당 토큰 수를 측정합니다.
- 4~5일차: 카나리아를 실제 사용자에게 푸시합니다. 필요한 경우 확장합니다. 거품이 있는 것으로 축하합니다 (셀처 계산).
그리고 상사가 비용을 두 배로 늘리지 않고 처리량을 두 배로 늘린 방법을 물으면 두 단어만 말하세요. '페이지된 주의력'. 그런 다음 이 vLLM 리뷰를 전달하고 마치 모든 것을 계획한 것처럼 고개를 끄덕이는 것을 즐기세요.
FAQ
Q1: vLLM은 소규모 팀에 적합합니까 아니면 대규모 기업에만 적합합니까?
둘 다. 비용을 절감하기 위해 관리형 API에서 자체 호스팅으로 이동하는 경우 vLLM의 OpenAI 호환 엔드포인트를 통해 쉽게 전환할 수 있습니다. 대규모 팀의 경우 트래픽이 급증할 때 처리량 및 동시성 승리가 빛을 발합니다.
Q2: vLLM에서 어떤 모델이 가장 잘 실행됩니까?
Llama, Mistral, Mixtral, Qwen, Gemma 및 Phi와 같은 인기 있는 오픈 모델은 잘 밟혀진 경로입니다. 양자화된 변형에 대한 호환성 참고 사항을 확인하세요. 가장 일반적인 형식이 작동하지만 이국적인 조합에는 조정이 필요할 수 있습니다.
Q3: vLLM을 실행하는 데 얼마나 많은 GPU가 필요합니까?
VRAM을 모델 크기 및 컨텍스트 창과 일치시킨 다음 동시성을 위한 헤드룸을 추가합니다. 단일 고메모리 GPU는 7B–13B 모델을 잘 제공할 수 있습니다. 더 큰 모델 또는 과도한 트래픽은 다중 GPU 설정의 이점을 얻습니다.
Q4: vLLM은 대기 시간을 줄입니까 아니면 처리량만 늘립니까?
워크로드에 따라 둘 다 줄입니다. 지속적인 배치 처리는 GPU 활용률을 향상시켜 처리량을 개선하는 반면 스트리밍 및 효율적인 스케줄링은 수다스러운 앱에서 첫 번째 토큰까지 걸리는 시간과 꼬리 대기 시간을 줄이는 데 도움이 됩니다.
Q5: vLLM은 Text Generation Inference (TGI)와 어떻게 비교됩니까?
vLLM은 특히 대화형 채팅의 경우 PagedAttention 및 동적 배치 처리를 통해 처리량에서 TGI를 종종 앞섭니다. TGI는 Hugging Face 통합 및 엔터프라이즈 광택에 기울어져 있습니다. 스택과 우선 순위에 따라 결정해야 합니다.
