로컬 LLM을 이야기할 때 대부분의 출발점은 Ollama입니다. 설치가 간단하고 바로 써볼 수 있기 때문입니다. 그런데 이번 영상은 질문 자체를 바꿉니다. 내 PC에서 모델이 돌아가느냐 가 아니라, 여러 요청을 계속 받아내는 서빙 엔진으로도 효율적인가 를 봐야 한다는 것입니다. 영상은 vLLM의 강점이 바로 그 지점, 즉 KV Cache 메모리 관리와 다중 요청 스케줄링에서 나온다고 설명합니다. 근거 영상

중요한 것은 숫자를 그대로 외우는 것이 아니라, 왜 어떤 환경에서는 차이가 거의 없고 어떤 환경에서는 크게 벌어지는지 를 이해하는 것입니다. 영상 도입부는 Red Hat의 2025년 8월 8일 벤치마크를 인용해 vLLM의 높은 TPS와 낮은 지연시간을 언급하지만, 뒤에서 보여주는 자체 테스트에서는 단일 요청에서는 큰 차이가 없고 동시 요청 환경에서 우위가 커진다고 정리합니다. 이 글은 바로 그 차이를 만든 구조를 따라가 보려는 글입니다. 근거 영상

Sources

1) vLLM은 로컬 앱보다 서빙 엔진 관점에서 봐야 한다

영상은 vLLM을 UC Berkeley Sky Computing Lab에서 만든 프로젝트로 소개하면서, 다수 요청을 처리할 때 Ollama보다 훨씬 강하다고 설명합니다. 이 관점은 Red Hat 벤치마크의 프레이밍과도 맞닿아 있습니다. Red Hat은 Ollama를 로컬 개발과 프로토타이핑에 잘 맞는 도구로, vLLM은 고성능 프로덕션 배포에 맞는 도구로 비교합니다. 즉 두 프로젝트를 “누가 더 좋다"로 단순 비교하기보다, 어떤 부하 모델을 상정하느냐 로 봐야 합니다. 근거 영상, Red Hat 벤치마크

이 구분이 중요한 이유는 체감 성능이 요청 패턴에 따라 완전히 달라지기 때문입니다. 한 명이 한 번씩 물어보는 환경에서는 설치 편의성, 실행 단순성, 초기 오버헤드가 크게 보입니다. 반대로 여러 요청이 줄을 서고 GPU 자원을 최대한 빼내야 하는 환경에서는 메모리를 얼마나 낭비 없이 쓰는지, 빈 슬롯이 생겼을 때 대기 요청을 얼마나 빨리 넣는지 가 성능을 좌우합니다. 영상 후반부의 단일 요청 vs 다중 요청 비교도 바로 이 차이를 보여주려는 장치입니다. 근거 영상

flowchart TD
    classDef ollama fill:#c5dcef,stroke:#5b8db8,color:#333
    classDef vllm fill:#c0ecd3,stroke:#58a36f,color:#333
    classDef focus fill:#fde8c0,stroke:#c89a3d,color:#333
    classDef note fill:#e0c8ef,stroke:#8b68a8,color:#333

    A["로컬 LLM 사용 목적은 무엇인가"]:::note --> B["한두 개 요청으로 빠르게 실험"]:::focus
    A --> C["여러 요청을 계속 처리"]:::focus

    B --> D["Ollama 강점
설치와 사용이 단순함"]:::ollama
    C --> E["vLLM 강점
메모리 관리와 스케줄링"]:::vllm

2) PagedAttention: KV Cache를 크게 예약하지 않고, 잘게 나눠서 쓴다

영상이 가장 먼저 설명하는 핵심은 KV Cache입니다. 자기회귀 방식의 LLM은 다음 토큰을 만들 때 이전 문맥 계산 결과를 다시 활용해야 하므로, 이전 key/value를 캐시에 보관해 중복 계산을 줄입니다. 이 부분은 PagedAttention 논문 초록과도 맞습니다. 논문은 LLM 서빙에서 KV cache가 크고, 요청마다 동적으로 늘었다 줄었다 하며, 이것이 비효율적으로 관리되면 배치 크기를 제한한다고 설명합니다. 근거 영상, PagedAttention 논문

문제는 요청이 시작되는 시점에 응답 길이를 정확히 알 수 없다는 점입니다. 영상의 설명대로 일반적인 방식은 “혹시 길어질지 모르니 넉넉하게” 큰 공간을 먼저 잡아두는 쪽으로 흐르기 쉽습니다. 그런데 실제 답변이 짧게 끝나면 예약된 공간 상당 부분이 비어 버립니다. 결국 GPU VRAM 안에서 실제로 일하지 않는 빈 공간 이 늘어나고, 이 낭비가 누적되면 동시에 올릴 수 있는 요청 수 자체가 줄어듭니다. 근거 영상

flowchart TD
    classDef req fill:#c5dcef,stroke:#5b8db8,color:#333
    classDef alloc fill:#ffc8c4,stroke:#c96f66,color:#333
    classDef waste fill:#fde8c0,stroke:#c89a3d,color:#333

    A["요청 시작"]:::req --> B["큰 KV Cache 공간 선예약"]:::alloc
    B --> C["실제 답변은 짧게 종료"]:::req
    C --> D["뒤쪽 공간이 비어 남음"]:::waste
    D --> E["VRAM 활용률 하락"]:::waste

vLLM의 해법은 운영체제의 페이징 아이디어를 KV Cache에 가져오는 것입니다. 영상은 이를 “작은 블록을 필요할 때마다 동적으로 할당한다"는 식으로 설명하고, 흩어진 블록의 위치는 블록 테이블이 기억한다고 말합니다. 논문 초록도 같은 방향으로, PagedAttention이 가상 메모리와 페이징 기법에서 영감을 받았고, 그 위에 만든 vLLM이 KV cache 메모리 낭비를 거의 0에 가깝게 줄이며 같은 지연시간에서 2-4배 높은 처리량을 낸다고 요약합니다. 영상이 소개한 “60-80%에 가까운 낭비를 4% 미만으로 낮췄다"는 수치는 이 논문의 문제의식을 더 직관적으로 풀어낸 표현으로 이해하면 됩니다. 근거 영상, PagedAttention 논문

flowchart TD
    classDef req fill:#c5dcef,stroke:#5b8db8,color:#333
    classDef block fill:#c0ecd3,stroke:#58a36f,color:#333
    classDef table fill:#e0c8ef,stroke:#8b68a8,color:#333
    classDef gain fill:#fde8c0,stroke:#c89a3d,color:#333

    A["요청 시작"]:::req --> B["작은 블록 단위로 필요 시 할당"]:::block
    B --> C["블록 테이블이 위치 추적"]:::table
    C --> D["흩어진 빈 공간도 재사용"]:::block
    D --> E["더 많은 요청을 VRAM에 수용"]:::gain

3) Continuous Batching: 빈자리가 생길 때마다 새 요청을 즉시 태운다

두 번째 핵심은 Continuous Batching입니다. 영상은 이를 “기존 추론 시스템은 요청을 하나씩 차례대로 처리하지만, vLLM은 여러 개를 동시에 처리할 수 있게 만든 방식"으로 단순화해 설명합니다. 엄밀히 보면 포인트는 “배치를 한 번 만들고 끝내는가"가 아니라, 실행 도중 빈 슬롯이 생길 때마다 대기 중인 요청을 다시 태울 수 있는가 에 가깝습니다. 즉 배치를 정적인 묶음이 아니라, 계속 갱신되는 작업 집합으로 다루는 스케줄러라는 뜻입니다. 근거 영상

여기서 PagedAttention과 Continuous Batching은 따로 노는 기능이 아닙니다. 영상이 강조하듯, 먼저 PagedAttention이 메모리 낭비를 줄여야 VRAM에 여유가 생기고, 그래야 Continuous Batching이 그 여유를 즉시 새 요청으로 채워 넣을 수 있습니다. 다시 말해 vLLM의 강점은 “배치를 잘한다"보다, 메모리 관리와 스케줄링이 서로 맞물려 GPU가 쉬는 시간을 줄인다 는 데 있습니다. 그래서 동시 요청이 많아질수록 이 조합의 효과가 눈에 띄게 커집니다. 근거 영상

flowchart TD
    classDef queue fill:#c5dcef,stroke:#5b8db8,color:#333
    classDef sched fill:#e0c8ef,stroke:#8b68a8,color:#333
    classDef run fill:#c0ecd3,stroke:#58a36f,color:#333
    classDef gain fill:#fde8c0,stroke:#c89a3d,color:#333

    A["대기 요청 큐"]:::queue --> B["Continuous Batching 스케줄러"]:::sched
    B --> C["현재 배치에 요청 투입"]:::run
    C --> D["일부 요청 완료로 메모리 회수"]:::run
    D --> B
    B --> E["빈 슬롯 즉시 재활용"]:::gain
    E --> F["GPU 유휴 시간 감소"]:::gain

4) 그래서 벤치마크는 단일 요청과 동시 요청을 분리해서 읽어야 한다

영상의 자체 테스트는 이 구조를 꽤 솔직하게 보여줍니다. 단일 요청 환경에서는 두 엔진이 비슷비슷했고, 영상 화자는 오히려 vLLM 쪽에 부가 작업 오버헤드가 있어서 조금 느리게 보인다고 말합니다. 이 대목이 중요합니다. vLLM은 언제나 무조건 더 빠른 도구 라기보다, 구조적 강점이 드러나는 워크로드에서 더 빠른 도구에 가깝습니다. 근거 영상

하지만 다수 요청 테스트로 넘어가면 결론이 달라집니다. 영상은 요청 수를 늘려가며 반복 측정했고, 이 구간에서 vLLM이 압도적으로 빨라졌다고 정리합니다. Red Hat의 2025년 8월 8일 벤치마크도 같은 방향을 보여줍니다. 해당 글은 peak throughput 기준으로 vLLM이 793 TPS, Ollama가 41 TPS였고, P99 latency는 80ms 대 673ms였다고 적습니다. 이 숫자를 그대로 모든 환경에 일반화하면 과장일 수 있지만, 동시성 부하에서 vLLM 구조가 왜 강한지 를 보여주는 외부 근거로는 충분합니다. 근거 영상, Red Hat 벤치마크

flowchart TD
    classDef single fill:#c5dcef,stroke:#5b8db8,color:#333
    classDef multi fill:#c0ecd3,stroke:#58a36f,color:#333
    classDef note fill:#fde8c0,stroke:#c89a3d,color:#333

    A["벤치마크를 읽을 때 먼저 확인할 것"]:::note --> B["단일 요청 중심"]:::single
    A --> C["동시 요청 중심"]:::multi

    B --> D["초기 오버헤드가 더 잘 보임"]:::single
    D --> E["차이가 작거나 vLLM이 불리할 수 있음"]:::single

    C --> F["메모리 재사용과 동적 배치가 작동"]:::multi
    F --> G["vLLM 우위가 크게 나타남"]:::multi

5) 개인 사용자에게도 의미가 있는가: 병렬 작업이 있으면 답이 달라진다

영상 말미에서 흥미로운 지점은 “vLLM은 기업용"이라는 일반론을 그대로 받아들이지 않는다는 점입니다. 화자는 개인 사용자라도 로컬 에이전트를 여러 개 돌리거나, 병렬로 많은 작업을 처리하는 구조를 만든다면 vLLM의 이점을 체감할 수 있다고 봅니다. 이 해석은 꽤 설득력이 있습니다. 단순 채팅 UI 하나만 띄워서 단일 대화를 주고받는다면 Ollama의 간편함이 더 크게 느껴질 수 있지만, 여러 에이전트가 동시에 모델을 두드리는 순간 문제는 앱 사용성이 아니라 서빙 아키텍처가 되기 때문입니다. 근거 영상

물론 진입장벽은 있습니다. 영상도 Ollama처럼 GUI가 없어서 리눅스에 익숙하지 않은 사용자에게는 막막할 수 있다고 인정합니다. 다만 동시에 가이드 문서가 비교적 친절하고, 막상 써보면 사용법도 간단한 편이라고 덧붙입니다. 정리하면 선택 기준은 단순합니다. 설치해서 바로 대화할 것인가 아니면 내 GPU를 작은 추론 서버처럼 운영할 것인가 입니다. 앞의 질문이면 Ollama가, 뒤의 질문이면 vLLM이 더 자연스러운 선택지입니다. 근거 영상

flowchart TD
    classDef gui fill:#c5dcef,stroke:#5b8db8,color:#333
    classDef serve fill:#c0ecd3,stroke:#58a36f,color:#333
    classDef ask fill:#fde8c0,stroke:#c89a3d,color:#333

    A["내 사용 패턴은 무엇인가"]:::ask --> B["단일 대화와 빠른 체험"]:::gui
    A --> C["에이전트/배치/동시 요청"]:::serve

    B --> D["Ollama 쪽이 더 단순"]:::gui
    C --> E["vLLM 쪽이 더 효율적"]:::serve

핵심 요약

  • vLLM의 핵심 우위는 “모델이 더 똑똑해서"가 아니라, KV Cache 메모리 관리와 요청 스케줄링을 서빙 시스템 관점에서 다시 설계했다는 데 있습니다. 근거 영상
  • PagedAttention은 KV Cache를 큰 덩어리로 미리 예약하는 대신 작은 블록으로 동적 할당해 VRAM 낭비를 줄입니다. 근거 영상, PagedAttention 논문
  • Continuous Batching은 PagedAttention이 만들어낸 여유 메모리를 바탕으로, 빈 슬롯이 생길 때마다 새 요청을 투입해 GPU 활용률을 높입니다. 근거 영상
  • 단일 요청에서는 vLLM의 구조적 이점이 잘 드러나지 않을 수 있지만, 동시 요청이 늘어날수록 차이가 커집니다. 근거 영상
  • Red Hat의 2025-08-08 벤치마크가 보여주는 큰 폭의 throughput/latency 차이도 결국 이 메모리 관리와 스케줄링 설계에서 나옵니다. Red Hat 벤치마크

결론

영상 제목의 “9배"라는 숫자만 기억하면 본질을 놓치기 쉽습니다. 이 영상이 정말 보여주는 것은 로컬 LLM의 성능은 모델 이름보다도, 그 모델을 어떤 메모리 관리자와 어떤 스케줄러 위에 올려두느냐에 따라 크게 달라진다 는 사실입니다. 한 명이 잠깐 써보는 로컬 앱이라면 Ollama의 장점이 분명하지만, 여러 요청을 버티는 작은 추론 서버를 만들고 싶다면 vLLM을 이해하는 순간 선택 기준이 완전히 달라집니다. 근거 영상