로컬 멀티모달(이미지+텍스트) 모델, 흔한 함정과 해결법

로컬 멀티모달(이미지+텍스트) 모델에서 2026년 가장 흔한 착각은 "이미지를 엉뚱하게 읽으면 모델이 멍청한 것"이라는 판단이다. 실제 원인은 대개 모델이 아니라 '비전 파이프라인'이다. VLM은 사진을 바로 이해하지 않는다 — 비전 인코더가 이미지를 '비전 토큰'으로 바꾸고, 프로젝터(mmproj)가 그걸 LLM이 읽는 형태로 옮긴 뒤에야 글자처럼 처리된다. 그래서 세 가지가 조용히 깨진다: 프로젝터 파일이 빠지거나 안 맞고, 해상도가 비전 토큰 수를 폭증시켜 VRAM이 터지고, 타일링이 디테일과 속도를 맞바꾼다. 이 글은 로컬 VLM 고유의 함정을 증상 → 원인 → 해결 순으로 수치와 함께 정리한다.

쉽게 말하면: VLM은 통역사를 낀 대화다. LLM은 이미지를 직접 못 보고, 비전 인코더+프로젝터라는 통역사가 그림을 '말'로 옮겨줘야 한다. 통역사(mmproj)를 빼먹으면 아예 대화가 안 되고, 그림이 너무 크면(고해상도) 통역사가 쏟아내는 단어가 너무 많아 책상(VRAM)이 넘친다. 요약하려 그림을 확 줄이면(고정 리사이즈) 작은 글씨를 놓친다.

이미지를 왜 아예 못 읽거나 헛것을 보나?

프로젝터(mmproj) 파일이 없거나 아키텍처가 안 맞기 때문이다. llama.cpp에서 VLM은 base 모델 + mmproj 두 파일이 짝이며, base 하나만 로드하면 이미지를 아예 처리 못 한다. 짝이 어긋나면(다른 모델의 프로젝터) 실패하거나 헛것을 본다 — 반드시 같은 모델의 매칭 프로젝터를 써라. 두 번째, 이미지 토큰이 마이크로배치를 넘겨 어설션으로 죽는다 — 사진 한 장이 수백 토큰이 되므로 --ubatch-size를 512 이상으로 올려야 한다. 세 번째, 최신 빌드는 프로젝터 메모리를 --fit 계산에 포함(PR 반영)하니, OOM이면 구버전·타 프로세스·프로젝터 없이 만든 배치를 의심하라. 즉 이미지가 안 읽히는 문제의 대부분은 '무게(모델 지능)'가 아니라 '배선(파일·배치)'이다.

해상도와 타일링은 왜 이렇게 위험한가?

고해상도 이미지가 로컬 VLM 최대의 VRAM 킬러이기 때문이다. 비전 인코더의 self-attention은 비전 토큰 수 N에 대해 O(N^2)로 score 텐서(KQ)를 만든다 — 고해상도에선 KQ 하나만 수 GB가 되어 단일 GPU에서 사실상 불가능해진다. 완화책은 비전 경로에도 FlashAttention 적용, Q 텐서 타일링(캐시 친화성을 깨 성능은 조금 손해지만 VRAM을 임의로 줄임), 또는 비전 가중치를 CPU로 오프로드(실행 시 CPU→GPU 스트리밍)다. 그리고 타일링 자체가 양날의 검이다: 옛 방식처럼 고정 해상도로 리사이즈하면 기하 왜곡·미세 디테일 손실(작은 글씨·표·차트 OCR이 무너짐), 반대로 동적 타일링은 이미지를 조각내 각각 인코딩해 화질은 지키지만 수천 개의 비전 토큰을 만들어 연산과 지연을 폭증시킨다. 그래서 실무는 해상도·타일 상한으로 토큰 수를 명시적으로 통제하는 게 정답이다.

어떤 로컬 VLM을, 어떤 VRAM에 얹나?

토큰 처리 방식이 모델 선택을 가른다. Gemma 3 계열은 이미지를 896x896으로 리사이즈해 256토큰 고정으로 인코딩한다 — VRAM이 예측 가능하지만 비표준 비율·고밀도 문서엔 약할 수 있다(단 문서 이해는 강해 DocVQA 27B가 85.6). 반대로 Qwen2.5/3-VL은 네이티브 해상도·가변 토큰이라 다양한 비율과 OCR·세밀 디테일에 강하지만 메모리가 이미지 크기에 따라 출렁인다. VRAM 티어(실측 가이드): 엣지(Jetson Orin Nano)는 moondream 1.8b·qwen2.5vl 3b·gemma3 4b, 8~16GB 단일 GPU는 qwen2.5vl 7b·gemma3 4b·llava 7b, 24GB+는 gemma3 12b/27b·qwen3-vl 32b가 기준이다. 메모리가 빠듯하면 Gemma 3 4B(약 4.2GB)가 좋고, QAT 변형 gemma3:size-it-qat는 저정밀로 훈련돼 같은 비트에서 일반 사후양자화보다 낫다. 핵심 교훈: VLM은 'LLM+눈'이 아니라 '두 개의 모델(비전+언어)이 프로젝터로 연결된 파이프라인'이며, 실패의 대부분은 언어가 아니라 그 연결부에서 난다.

그래서 안전한 로컬 VLM 세팅은?

핵심은 "프로젝터 짝을 맞추고, 해상도로 토큰·VRAM을 통제하고, 토큰 방식에 맞는 모델을 고르는 것"이다.

• 배선: base+매칭 mmproj 두 파일, --ubatch-size 512+로 이미지 토큰 어설션 방지, 최신 빌드로 프로젝터 메모리까지 --fit 반영.
• 해상도·VRAM: 고해상도는 비전 FlashAttn·Q타일·CPU오프로드, 해상도/타일 상한으로 비전 토큰 명시 통제(동적 타일 폭발 방지).
• 모델 선택: 문서·예측가능 VRAM이면 Gemma 3(고정 256), OCR·세밀·비표준 비율이면 Qwen-VL(네이티브 가변). 빠듯하면 QAT 변형. 모든 선택은 자기 이미지 세트로 A/B 후 고정.

함께 읽기: 로컬 코딩 보조 모델 2026: 직접 돌려보고 고른 현황과 추천, Ollama·LM Studio·llama.cpp 실행기, 2026년에는 무엇을 고를까?

함께 읽기: 로컬 멀티모달(VLM) 모델 VRAM·RAM 요구량 실측, 로컬 멀티모달(VLM) 모델, 5분 시작 가이드(초보자용)

참고 링크

• llama.cpp 멀티모달 문서(mmproj·비전)
• llama.cpp 저장소
• Qwen2.5-VL(네이티브 해상도·가변 토큰)
• InternVL(오픈 VLM 계열)
• 오픈소스 VLM 가이드(BentoML)

참고: mmproj 짝·--ubatch 512·비전 KQ의 O(N^2)·Gemma3 896->256·Qwen-VL 네이티브 가변·DocVQA 85.6·VRAM 티어·QAT 같은 수치·동작은 2026년 llama.cpp 공식 문서/PR·모델 카드·공개 벤치 기준이며 빌드·모델·버전·이미지에 따라 달라진다(영구 수치 아님, 모델 카드·llama.cpp 문서가 최종 근거). Gemma 3→Gemma 4, Qwen2.5-VL→Qwen3-VL로 세대가 넘어가니 새 빌드는 최신 세대를 확인하라. 반드시 자기 이미지·문서로 검증하라. 로컬 VLM 스택은 빠르게 바뀌니 분기별로 다시 본다.