로컬 멀티모달(VLM) VRAM·RAM 실측: OOM 주범은 모델이 아니라 이미지 토큰
요약: 가중치 fp16: 약 14.5~17GB 가중치 INT4: 약 4~7GB KV 캐시: 약 0.125GB/1K토큰 로컬 VLM VRAM의 진짜 킬러는 모델이 아니라 이미지 토큰 — 7B VL 가중치 INT4 약 4~7GB, KV 캐시 약 0.125GB/1K토큰 로컬 멀티모달(이미지+텍스트, VLM)의 VRAM은 모델 가중치+비전 타워로 시작하지만, 진짜 킬러는 '이미지 토큰'이다.
로컬 VLM VRAM의 진짜 킬러는 모델이 아니라 이미지 토큰 — 7B VL 가중치 INT4 약 4~7GB, KV 캐시 약 0.125GB/1K토큰
로컬 멀티모달(이미지+텍스트, VLM)의 VRAM은 모델 가중치+비전 타워로 시작하지만, 진짜 킬러는 '이미지 토큰'이다. 실측 핵심 셋: ① 7B VL 가중치는 fp16 약 14.5~17GB, INT4로 4~7GB(비전 인코더 때문에 텍스트 전용보다 약간 더 든다). ② 진짜 폭탄은 이미지 한 장이 만드는 토큰이다 — Qwen2.5-VL은 동적 해상도라 이미지당 4~16384 토큰을 쓰고, 최대 해상도(전면 OCR 스캔)면 16K 토큰≈2GB KV 캐시가 한 장에 붙는다. ③ 그래서 OOM의 원인은 모델 크기가 아니라 이미지 크기다 — 3B 모델도 큰 이미지 한 장에 16GB GPU가 터진다. 레버는 모델 양자화가 아니라 max_pixels(해상도 캡)와 프레임 수다.
한 줄 요약: VLM 메모리는 책상 위 사진 더미다. 두뇌(모델)는 고정 크기지만, 큰 사진(고해상도)을 올리거나 여러 장·영상을 쌓으면 책상이 순식간에 꽉 찬다. 사진을 적당히 줄여 올리는 게(해상도 캡) 가장 강한 절약이다.
용어부터. KV 캐시는 모델이 이미 처리한 토큰의 중간 상태를 담아 두는 메모리(문맥이 길수록 커짐), 이미지 토큰은 그림을 잘게 쪼개 모델이 '읽는' 단위, max_pixels는 이미지를 몇 픽셀까지 볼지 상한(=토큰 예산)이다.
멀티모달 VRAM은 무엇으로 정해지나?#
가중치+비전 타워+이미지/텍스트 토큰의 KV 캐시다. 언어 백본(7B)이 고정 비용(fp16 14.5~17GB, INT4 4~7GB)이고, 비전 인코더(ViT)는 윈도우 어텐션으로 오버헤드가 작다. 진짜 변수는 KV 캐시로, 1,000토큰당 약 0.125GB(fp16)다. 그런데 VLM에선 그 토큰에 이미지 토큰이 합산된다 — 텍스트만 세던 LLM과 결정적으로 다르다. 그래서 "7B가 6GB니 6GB면 되겠지"가 아니라 이미지 해상도·장수·영상 프레임까지 넣어 계산해야 한다.
| 구성 | 비용 | 메모 |
|---|---|---|
| 가중치 fp16 | 약 14.5~17GB | 텍스트7B보다 약간↑ |
| 가중치 INT4 | 약 4~7GB | 8GB급 진입 |
| KV 캐시 | 약 0.125GB/1K토큰 | FP8 KV로 절반 |
| 이미지 1장(최대해상도) | 최대 16K토큰≈2GB | OOM 주범 |
| 영상 | 프레임×토큰 | 배수로 폭증 |
왜 이미지 한 장이 메모리를 터뜨리나?#
동적 해상도가 픽셀에 비례해 토큰을 만들기 때문이다. Qwen2.5-VL 기본 토큰 범위는 이미지당 4~16384로 생각보다 훨씬 넓어, 캡을 안 걸면 4K 스크린샷·문서 스캔 한 장이 16K 토큰을 먹고 KV 캐시 약 2GB를 더한다. 실제로 3B 모델도 T4(16GB)에서 "이미지가 너무 커서" 12GB 할당 실패로 OOM 났다(해결책: 이미지 크기 축소). 그래서 min_pixels·max_pixels로 토큰 예산을 캡하는 게 1번 레버다(256~1280 범위 권장). 문서 여러 장을 넣으면 2GB씩 곱해지니 한 번에 몇 장인지도 세라.
영상은 왜 더 위험한가?#
프레임 수만큼 토큰이 곱해지기 때문이다. Qwen2.5-VL은 동적 FPS 샘플링으로 영상을 보는데, 프레임 × 프레임당 토큰이 문맥에 쌓여 고해상도·장시간 영상은 순식간에 32K·128K 문맥을 넘긴다. 128K에선 KV 캐시가 가중치를 넘어 총 VRAM이 31GB+가 된다. 그래서 영상은 FPS를 낮추고 해상도를 줄여 토큰을 억제하고, FP8 KV 캐시(절반)·FlashAttention(32K+ 필수)을 함께 쓴다. 즉 영상 VLM은 '모델 선택'보다 토큰 예산 설계가 성패를 가른다.
어떻게 8GB에 얹나?#
핵심은 가중치는 양자화, 토큰은 캡이다.
- 가중치: INT4(4~7GB)로 7B를 8GB에 넣는다(비전 타워 포함).
- 토큰: max_pixels로 이미지 해상도를 캡하고 max-model-len을 줄인다(기본 32K는 과함). 문서는 페이지 수를 제한.
- KV: FP8 KV 캐시로 절반, 긴 문맥은 FlashAttention. 정확한 값은 내 이미지 해상도·장수로 직접 재라.
함께 읽기: 에이전트 브라우저 제어, 직접 써보고 느낀 점과 한계, ComfyUI로 이미지·영상 만들기: 우리가 직접 굴리며 잰 운영 회고
함께 읽기: 로컬 멀티모달(VLM) 모델, 직접 돌려본 속도·품질 비교, 로컬 음성합성(TTS) 오픈모델 — VRAM·RAM 요구량 실측
참고 링크#
- Qwen2.5-VL(비전언어 모델)
- vLLM(VLM 서빙·KV 양자화)
- Qwen2.5-VL-7B(모델카드·Hugging Face)
- llama.cpp(GGUF·비전·mmproj)
- Transformers(멀티모달 파이프라인)
참고: GB·토큰 수치는 2026년 공개 측정·벤더 추정이며 해상도·배치·어텐션 백엔드에 따라 달라진다(영구 수치 아님, 정밀 per-token 수치는 벤더 벤치 기반). 이미지 토큰은 max_pixels 설정에 크게 좌우되니, 정확한 메모리는 내 해상도·장수·영상 길이로 직접 재라(여기 수치는 출발점). VLM 스택은 빠르게 바뀌니 분기별로 다시 본다.
Responses
No responses yet. Be the first to respond.