로컬 AI에 VRAM이 필요한 이유: 라즈베리파이 벡터 임베딩이 느린 원인과 GPU 활용 도구

라즈베리파이5에 qmd를 설치하고 Google Drive 문서 1,574개를 벡터 임베딩해 보니 최종 33,996개 청크가 생성됐습니다. GPU 가속 없이 4코어 CPU로 진행했고, 첫 시도부터 최종 완료까지의 전체 경과 시간은 47시간 32분 9초였습니다.

처음에는 “벡터DB가 원래 느린가?”라고 생각하기 쉽습니다. 하지만 벡터DB 저장과 벡터 임베딩 계산은 서로 다른 작업입니다. SQLite에 벡터를 기록하는 것보다, 임베딩 모델을 반복 실행해 각 문서 조각을 숫자 배열로 바꾸는 과정이 훨씬 무거울 수 있습니다.

이 차이를 이해하면 로컬 AI 머신을 고르는 기준도 달라집니다. 라즈베리파이가 쓸모없는 것이 아니라, 라즈베리파이가 맡을 작업과 GPU·VRAM이 있는 머신이 맡을 작업을 나누는 것이 핵심입니다.

아직 문서 수집과 qmd RAG 구성이 낯설다면 아래 글에서 전체 흐름을 먼저 확인할 수 있습니다.

먼저 읽기 · 로컬 RAG 구성 코딩 없이 벡터DB 기반 RAG 시스템 구축하기 Google Drive·PDF를 수집하고 OCR·임베딩·MCP 검색까지 연결하는 전체 과정을 설명합니다. 벡터DB 글 먼저 보기 →

라즈베리파이 벡터 임베딩이 느린 이유

문서를 RAG 검색에 넣는 과정은 한 덩어리처럼 보이지만 내부에서는 여러 작업으로 나뉩니다.

원본 파일 수집
→ PDF·DOCX·Google Docs를 텍스트로 변환
→ 긴 문서를 작은 조각으로 분할
→ 임베딩 모델로 각 조각을 벡터화
→ 벡터와 출처 정보를 데이터베이스에 저장
→ 질문과 가까운 벡터를 검색
→ 필요하면 재랭킹과 LLM 답변 생성

이 가운데 모든 단계가 GPU를 필요로 하지는 않습니다.

처리 단계	주로 사용하는 자원	GPU·VRAM 효과
파일 다운로드·동기화	네트워크·디스크	거의 없음
PDF·Office 문서 변환	CPU·RAM	도구에 따라 제한적
Tesseract OCR	CPU·RAM	기본 구성에서는 거의 없음
문서 분할·메타데이터 처리	CPU·RAM	거의 없음
임베딩 모델 추론	CPU 또는 GPU	지원 백엔드가 있으면 큼
SQLite·sqlite-vec 저장	CPU·RAM·디스크	필수 아님
BM25 키워드 검색	CPU·RAM	필수 아님
검색어 임베딩	CPU 또는 GPU	의미 검색마다 모델 추론이 필요하며 지원 백엔드의 영향을 받음
벡터 인덱스 유사도 계산	CPU·RAM, 구현에 따라 GPU	소규모 로컬 색인에서는 GPU가 필수 아님
재랭킹·로컬 LLM 답변	CPU 또는 GPU	모델이 클수록 큼

따라서 “벡터DB가 느리다”보다 “임베딩 모델이 CPU에서 실행되고 있다”가 더 정확한 진단일 수 있습니다. 문서가 많아지고 조각 수가 늘어날수록 모델 호출도 반복되므로, 작은 문서로 시험할 때보다 전체 폴더를 처리할 때 차이가 크게 느껴집니다.

라즈베리파이 qmd 임베딩 실제 측정 결과

이번 작업은 Google Drive 원본 전체를 그대로 임베딩한 것이 아닙니다. 먼저 폴더를 재귀적으로 탐색하고, 현재 변환 파이프라인에서 처리할 수 있는 PDF·Office·텍스트 문서만 검색용 Markdown으로 바꾼 뒤 qmd에 입력했습니다.

Google Drive 원본과 qmd 입력 범위

측정 항목	결과
재귀 탐색한 Google Drive 폴더	1,284개
Markdown으로 변환한 Google Drive 문서	1,574개
테스트 문서를 포함한 최종 qmd 문서	1,575개
qmd 입력 Markdown 파일 용량	25.67MB(24.48MiB)
Markdown 중 본문 데이터	24.85MB(23.70MiB)
최종 벡터 청크	33,996개
최종 qmd 인덱스	180.9MB
모델·인덱스를 포함한 qmd 캐시	약 2.3GB

Google Drive 변환 폴더가 파일시스템에서 차지한 공간은 디렉터리와 Manifest 등을 포함해 약 34MB입니다. 이 값과 qmd가 실제로 읽은 Markdown 파일 본체 25.67MB는 구분해야 합니다. Manifest에 원본 Drive 파일의 전체 바이트 용량을 저장하지 않았고, 제외한 CAD·이미지·영상 파일은 다운로드하지 않았기 때문에 원본 Drive 전체 용량은 이번 결과만으로 계산할 수 없습니다.

qmd에 입력한 문서 형식

원본 형식	문서 수	Markdown 변환 방식
PDF	983개	텍스트 레이어 추출, 일부 OCR·Vision 보강
XLSX	375개	시트명과 셀 값을 Markdown 표로 변환
PPTX	131개	슬라이드별 텍스트 추출
DOCX	40개	문단과 표 추출
텍스트 계열	37개	원문 텍스트 유지
Google Sheets	7개	XLSX로 내보낸 뒤 시트·셀 추출
0바이트 파일 메타데이터	1개	제목·경로·원본 URL만 저장
합계	1,574개	전부 Markdown 사이드카로 변환

텍스트 계열 37개에는 TXT, CSV, Markdown, XML, HTML, C 헤더 파일과 일부 텍스트로 판별된 파일이 포함됐습니다. 각 Markdown에는 본문과 함께 다음 메타데이터를 저장했습니다.

title: "문서 제목"
source: "google-drive"
source_id: "Drive 파일 ID"
source_url: "Google Drive 원본 URL"
source_path: "Drive 내부 경로"
mime_type: "원본 형식"
modified_time: "수정 시각"
converter: "변환 방식"

이 메타데이터도 변환 Markdown 안에 들어가므로 파일명, Drive 내부 경로, 문서 내용과 원본 링크를 함께 찾는 검색 단서가 됩니다.

임베딩에서 제외한 파일

선택한 Drive 폴더에는 CAD, 이미지, 영상처럼 현재 파이프라인에서 처리하지 않는 형식도 많았습니다. 제외된 파일은 7,232개입니다.

대표 제외 형식	파일 수
SolidWorks	3,533개
일반 바이너리	1,170개
JPEG	1,050개
STL	557개
PNG	246개
DWG	124개
구형 XLS	84개
DXF	43개
ZIP·영상·Visio·Illustrator 등 나머지 형식	425개

따라서 “Google Drive의 파일 1만여 개를 모두 임베딩했다”라고 쓰면 부정확합니다. 정확한 범위는 폴더 1,284개를 탐색하고, 지원 가능한 문서 1,574개를 Markdown으로 변환해 임베딩했다입니다.

첫 실행부터 최종 완료까지 47시간 32분

첫 실행은 2026년 7월 22일 18시 52분 12초에 시작했고, 최종 완료 시각은 7월 24일 18시 24분 21초였습니다. 두 시각 사이의 전체 작업 경과 시간은 47시간 32분 9초였습니다.

구분	시각·시간
최초 임베딩 시작	2026년 7월 22일 18시 52분 12초
최종 완료	2026년 7월 24일 18시 24분 21초
첫 시도부터 최종 완료까지 총 경과 시간	47시간 32분 9초

이 시간에는 첫 시도, 30분 세션 만료, 배치 크기 변경, 실행 환경 재시작, systemd 서비스 전환, 미완료 문서 재처리가 모두 포함됩니다. 최종 qmd 상태는 문서 1,575개, 벡터 33,996개, 임베딩 대기 0개였습니다.

CPU 4코어를 거의 모두 사용한 임베딩

실행 조건	측정 환경
장비	Raspberry Pi ARM64, 약 8GB RAM
CPU	4코어, 실행 중 사용률 약 398%
GPU 가속	사용하지 않음
임베딩 모델	embeddinggemma-300M-Q8_0
처음 배치 설정	100문서 / 32MB
최종 배치 설정	25문서 / 8MB

CPU 사용률 약 398%는 4개 코어가 거의 모두 바쁘게 동작했다는 의미입니다. 입력 파일은 1,574개였지만, 큰 표가 들어 있는 XLSX가 Markdown으로 변환되면서 문서 하나가 수십~수백 개 청크로 나뉜 경우가 많았습니다. 최종 벡터가 33,996개까지 늘어난 이유입니다.

측정 당시 사용한 qmd 2.5.3 소스에는 임베딩 세션을 30분으로 제한하는 maxDuration 값이 있었습니다. 대량 CPU 임베딩이 이 제한에 걸려 중간에 끝났고, 해당 환경에서는 제한을 48시간으로 늘린 뒤 배치를 100문서·32MB에서 25문서·8MB로 줄여 완료했습니다. 이 내용은 qmd 2.5.3에서 실행한 당시 환경의 기록이며, 현재 버전에도 같은 설정이 적용된다고 단정하면 안 됩니다. 실행 전 qmd embed --help로 현재 버전의 시간·배치 옵션을 확인해야 합니다.

이번에는 동일한 문서 묶음을 GPU 머신에서 처리한 비교 기록이 없으므로 “GPU에서 몇 배 빨라진다”는 수치는 아직 제시할 수 없습니다. 다음 비교에서는 입력·모델·청크·배치 조건을 고정하고 아래 명령으로 총시간과 최대 메모리를 함께 기록해야 합니다.

/usr/bin/time -v qmd embed
qmd doctor

VRAM 뜻과 RAM의 차이

VRAM(Video Random Access Memory)은 GPU 연산에 사용하는 메모리 영역을 가리킵니다. 외장 GPU에서는 보통 별도의 고속 메모리 칩이지만, Raspberry Pi 같은 통합 GPU는 시스템 메모리를 공유하고 Apple Silicon은 통합 메모리 구조를 사용합니다. 따라서 모든 GPU에 물리적으로 분리된 VRAM이 있는 것은 아닙니다.

로컬 AI에서는 실행 백엔드와 오프로딩 설정에 따라 다음 데이터의 일부 또는 전부가 GPU가 사용할 수 있는 메모리 영역을 차지합니다. 모델 가중치와 KV 캐시가 시스템 RAM과 GPU 메모리 중 어디에 배치되는지는 런타임과 CPU·GPU 분할 설정에 따라 달라집니다.

• 모델 가중치
• 입력 토큰과 임베딩 배치
• 계산 중간값
• 로컬 LLM의 KV 캐시
• 이미지 생성의 latent와 텐서
• Vision·음성 모델의 입력 특징과 출력 버퍼

일반 RAM은 CPU가 사용하는 주 메모리입니다. 외장 GPU가 있는 PC에서는 RAM과 VRAM이 물리적으로 분리된 경우가 많고, 둘 사이로 데이터를 옮기는 데도 비용이 듭니다. 모델이 VRAM 안에 충분히 들어가면 GPU가 가까운 메모리에서 연산을 이어갈 수 있습니다.

VRAM이 부족하면 선택지는 보통 네 가지입니다.

1. 더 작은 모델을 선택한다.
2. FP16 대신 8비트·4비트 양자화 모델을 사용한다.
3. 배치 크기나 컨텍스트 길이, 이미지 해상도를 줄인다.
4. llama.cpp처럼 부분 GPU 오프로딩을 지원하는 런타임에서는 일부 레이어만 GPU에 올리고 나머지는 시스템 RAM과 CPU에 둔다.

네 번째 방법은 CPU·GPU 혼합 추론 또는 부분 GPU 오프로딩입니다. 실행 범위를 넓힐 수 있지만 CPU 계산과 메모리 이동이 늘어 속도가 낮아질 수 있습니다. 모든 AI 도구가 이 방식을 지원하는 것은 아니며, 지원하지 않는 도구는 VRAM 부족 시 실행에 실패할 수 있습니다. 그래서 VRAM 용량은 단순히 “조금 더 빠른가”가 아니라, 원하는 모델과 작업 조건을 GPU 안에 올릴 수 있는가를 가르는 기준이 됩니다.

주의: VRAM이 많다고 무조건 빠른 것은 아닙니다. 같은 용량이라도 GPU 연산 성능과 메모리 대역폭이 다르고, 프로그램이 해당 GPU 백엔드를 지원하지 않으면 VRAM을 제대로 사용하지 못합니다.

라즈베리파이5 GPU는 외장 GPU의 VRAM과 다름

라즈베리파이 공식 사양에서 Raspberry Pi 5는 2.4GHz 쿼드코어 Arm Cortex-A76 CPU와 VideoCore VII GPU를 탑재하며, OpenGL ES 3.1과 Vulkan 1.2를 지원합니다. 하지만 일반 데스크톱의 NVIDIA·AMD 외장 그래픽카드처럼 별도의 고속 전용 VRAM이 장착된 구조는 아닙니다.

이 차이 때문에 “GPU가 있다”는 사양 한 줄만 보고 로컬 AI 가속을 기대하면 안 됩니다. 확인할 것은 세 가지입니다.

1. 사용하려는 프로그램에 ARM64 빌드가 있는가
2. VideoCore VII를 사용할 수 있는 Vulkan 등 가속 백엔드가 있는가
3. 그 백엔드가 임베딩·LLM 모델에서 실제로 선택됐는가

qmd는 현재 llama.cpp GPU 백엔드를 자동 탐지하며 CUDA·Vulkan·Metal을 지정하는 설정과 CPU 강제 실행 옵션을 제공합니다. 그렇다고 Raspberry Pi의 Vulkan 지원만으로 데스크톱 GPU와 같은 성능이 보장되는 것은 아닙니다. 모델·드라이버·빌드 조합이 맞지 않으면 CPU 모드로 실행될 수 있습니다.

로컬 LLM에 VRAM이 필요한 이유

로컬 LLM은 답변을 만들기 전에 모델 가중치를 메모리에 올립니다. 그다음 입력 문맥을 처리하고 토큰을 하나씩 생성하면서 KV 캐시와 중간 계산값을 사용합니다. 모델이 커질수록, 양자화 정밀도가 높을수록, 컨텍스트가 길수록 필요한 메모리도 늘어납니다.

Ollama는 NVIDIA GPU, AMD ROCm, Apple Metal과 Windows·Linux의 Vulkan GPU 지원을 문서화하고 있습니다. 현재 공식 문서에서 Vulkan은 백엔드가 설치돼 있으면 기본 활성화되는 추가 지원 경로로 안내됩니다. GPU가 여러 개라면 사용할 장치를 제한할 수 있고, 스케줄러는 GPU 라이브러리가 보고한 가용 VRAM을 참고합니다. 실행 뒤에는 다음처럼 실제 배치를 확인합니다.

ollama ps

여기서 모델이 CPU에만 올라갔는지, GPU에 올라갔는지, 일부만 GPU로 처리되는지 확인합니다. 모델 다운로드가 성공했다는 사실과 GPU 가속이 적용됐다는 사실은 같지 않습니다.

llama.cpp는 CUDA·HIP·Metal·Vulkan 등 여러 백엔드와 CPU·GPU 혼합 추론을 지원합니다. VRAM보다 큰 모델도 일부 레이어를 CPU에 남겨 실행할 수 있지만, “실행 가능”과 “기다릴 만한 속도”는 구분해야 합니다.

벡터 임베딩·재랭킹의 VRAM 사용 방식

임베딩 모델은 문장이나 문서 조각을 고정 길이 숫자 벡터로 바꿉니다. 한 번의 계산은 로컬 LLM 답변 생성보다 작아 보여도, 문서 조각이 수천 개라면 같은 모델 추론이 반복됩니다.

GPU 머신에서는 여러 조각을 배치로 묶어 병렬 계산할 수 있습니다. 이때 VRAM에는 모델과 입력 배치, 중간 계산값이 함께 올라갑니다. VRAM이 충분하면 배치를 키워 처리량을 높일 여지가 있지만, 너무 크게 잡으면 메모리 부족 오류가 납니다.

qmd에는 임베딩·재랭킹 병렬도를 조정하는 설정이 있고, llama.cpp 백엔드를 통해 GPU를 탐지할 수 있습니다. GPU 머신으로 옮긴 뒤에도 무작정 병렬도를 최대화하기보다 작은 값에서 시작해 VRAM 사용량과 안정성을 확인하는 편이 안전합니다.

qmd doctor
qmd status
/usr/bin/time -v qmd embed

NVIDIA 머신이라면 다른 터미널에서 사용량을 관찰합니다.

nvidia-smi --query-gpu=name,memory.total,memory.used,utilization.gpu \
  --format=csv -l 2

비교할 때는 다음 조건을 고정합니다.

• 동일한 원본 문서와 파일 수
• 동일한 변환 결과
• 동일한 임베딩 모델과 양자화
• 동일한 청크 크기와 중첩
• 동일한 병렬도·배치 크기
• 기존 임베딩 캐시 제거 여부

이 조건이 다르면 라즈베리파이와 GPU 머신의 차이가 아니라 설정 차이를 측정하게 됩니다.

VRAM을 활용하는 로컬 AI 기능과 도구

Ollama·llama.cpp: 로컬 LLM과 Vision 모델

문서 요약, 코드 설명, 채팅, RAG 답변 생성은 로컬 LLM의 대표 작업입니다. 이미지 입력을 지원하는 모델이라면 Vision 분석도 같은 실행 환경에서 처리할 수 있습니다.

VRAM은 모델 크기뿐 아니라 긴 문맥과 동시 요청 수에도 영향을 줍니다. 작은 4비트 양자화 모델부터 시작하고, 실제 GPU 배치와 응답 속도를 확인한 뒤 모델이나 컨텍스트를 늘립니다.

qmd·임베딩 모델: 대량 문서 벡터화와 재랭킹

qmd에서 BM25 검색과 SQLite 저장은 GPU 없이도 동작합니다. 반면 벡터 임베딩, 쿼리 확장, LLM 재랭킹은 모델 추론이 포함되므로 GPU 백엔드의 영향을 받을 수 있습니다.

qmd의 기본 동작은 다른 장비에 벡터 계산만 맡기는 원격 워커 방식이 아닙니다. qmd embed를 실행한 머신의 qmd 색인에 결과가 저장됩니다. 따라서 GPU 머신에 문서 컬렉션과 색인을 함께 두고 qmd HTTP MCP 서버로 검색까지 제공하는 구성이 가장 단순합니다. 라즈베리파이는 새 원문을 동기화하고 Hermes Gateway에서 이 서버를 호출합니다.

qmd 공식 문서는 서로 다른 머신 사이의 색인 복제·동기화를 지원 기능으로 안내하지 않습니다. 색인 파일 복사는 사용자 정의 백업·복원 작업으로 취급해야 하며, qmd를 중지한 뒤 SQLite 색인과 index.yml, 컬렉션 경로, 모델 조건을 함께 맞추고 목적지에서 qmd status와 qmd doctor로 정합성을 검증해야 합니다. 공식 문서에 나온 경로는 원문 컬렉션을 목적지에 동기화한 뒤 qmd update와 qmd embed를 실행하거나, GPU 머신의 HTTP MCP 서버를 그대로 이용하는 방식입니다. GPU 머신을 끈 뒤 라즈베리파이에서 벡터 질의를 실행하려면 원문 컬렉션과 로컬 qmd 색인을 별도로 유지해야 하며, 질문 임베딩은 라즈베리파이 CPU에서 계산됩니다. 단순히 “변경 문서만 보내고 벡터만 돌려받는 기능”이 qmd에 기본 제공된다고 이해하면 안 됩니다.

ComfyUI: 이미지 생성과 업스케일

ComfyUI는 PyTorch 기반 이미지 생성 워크플로우를 실행합니다. 공식 시스템 요구사항에는 NVIDIA CUDA, AMD ROCm, Intel XPU, Apple Metal 등 지원 경로와 CPU 모드가 안내돼 있습니다. CPU 모드는 가능하지만 더 느리다고 명시합니다.

이미지 모델, 해상도, 배치 수, ControlNet·업스케일러 같은 추가 노드가 VRAM을 함께 사용합니다. 메모리 부족이 나면 저VRAM 모드만 찾기 전에 해상도와 배치, 동시에 올린 모델부터 줄이는 편이 원인 파악에 도움이 됩니다.

faster-whisper: 음성 인식과 자막 생성

faster-whisper는 CTranslate2를 사용하며 CPU와 NVIDIA CUDA GPU 실행을 지원합니다. 공식 저장소는 GPU FP16·INT8과 CPU INT8 예제를 구분하고, GPU 벤치마크에는 VRAM 사용량도 함께 제시합니다. 현재 최신 CTranslate2의 GPU 실행 조건은 CUDA 12용 cuBLAS와 CUDA 12용 cuDNN 9이며, 이전 CUDA·cuDNN 조합은 호환되는 CTranslate2 버전을 따로 확인해야 합니다.

공식 GPU 벤치마크는 CUDA 12.4와 NVIDIA RTX 3070 Ti 8GB에서 측정한 특정 조건의 결과입니다. 긴 녹음을 반복 처리할 때 GPU로 처리량을 높일 여지는 있지만, 실제 차이는 모델·배치·빔 크기·하드웨어를 고정해 측정해야 합니다. 짧은 음성 메모 몇 개만 변환한다면 라즈베리파이의 예약 작업이나 외부 API가 운영상 더 단순할 수 있습니다.

로컬 Vision·영상 생성 도구

Vision 모델은 이미지 입력과 모델 가중치를 함께 처리합니다. 영상 생성은 여러 프레임과 큰 중간 텐서를 다루므로 이미지 생성보다도 높은 VRAM 요구가 생기기 쉽습니다. 이 영역은 라즈베리파이에서 억지로 실행하기보다 GPU 머신이나 허용된 클라우드 API로 분리하는 편이 현실적입니다.

VRAM이 없어도 라즈베리파이에서 가능한 작업

이 절에서 VRAM이 없다는 표현은 외장 GPU의 전용 VRAM이 없다는 뜻입니다. VideoCore VII가 시스템 메모리를 공유하는 라즈베리파이5도 AI 자동화 머신으로서 의미를 잃는 것은 아닙니다. 오히려 저전력으로 계속 켜 두기 좋은 장점을 살릴 수 있습니다.

라즈베리파이에 남길 작업	이유
Hermes Gateway와 Discord 연결	상시 대기와 메시지 라우팅이 중심
Google Drive·Notion 동기화	네트워크·API·파일 처리 비중이 큼
PDF·Office 문서 변환	CPU 작업이며 예약 실행 가능
Tesseract OCR	GPU 없이 동작하고 실패 페이지를 선별하는 데 유용
BM25 키워드 검색	빠르고 GPU가 필수 아님
SQLite·메타데이터 저장	데이터 정합성과 디스크 I/O가 중심
예약 작업·백업·상태 감시	항상 켜진 저전력 장치에 적합
외부 AI API 오케스트레이션	무거운 추론은 원격 제공자가 수행

여기에 GPU 머신을 작업 노드로 붙입니다.

라즈베리파이5
- Hermes Gateway
- 파일 수집·변환
- 권한·출처 메타데이터 관리
- 예약 동기화와 로컬 BM25 검색
        ↓ 원문 동기화·qmd HTTP MCP 요청
GPU AI 머신
- qmd 문서 컬렉션·색인
- 대량 임베딩
- 로컬 LLM·재랭킹
- Vision·Whisper
- 이미지 생성
        ↓ 검색·추론 결과 반환
라즈베리파이5
- Discord로 결과와 원문 링크 전달

GPU 머신을 24시간 켜 두지 않아도 됩니다. 새 문서가 많이 쌓였을 때나 벡터 검색이 필요할 때만 켜거나, 야간 배치 시간에 실행할 수 있습니다. 다만 GPU 머신의 qmd HTTP MCP 서버를 끄면 그 서버를 이용한 qmd 검색도 사용할 수 없습니다. 라즈베리파이에 원문과 로컬 색인을 별도로 구성해 둔 경우에만 그동안 BM25나 CPU 기반 검색을 계속할 수 있습니다.

qmd HTTP MCP는 기본적으로 localhost:8181에 바인딩됩니다. 다른 장비에서 호출하려면 --host로 바인딩 주소를 바꿔야 합니다. 이때 qmd 자체 인증을 전제로 인터넷에 그대로 공개하지 말고, 방화벽·Tailscale ACL처럼 신뢰할 수 있는 네트워크 계층에서 접근을 제한해야 합니다. 개인정보나 회사 문서를 외부로 보낼 수 없다면 GPU 머신을 같은 로컬 네트워크에 두는 구성이 의미가 있습니다.

GPU AI 머신을 고를 때 VRAM 외에 볼 것

VRAM 16GB라는 숫자만으로 제품을 고르면 실제 도구에서 예상과 다른 결과가 나올 수 있습니다.

1. 사용할 도구의 가속 백엔드

• NVIDIA: CUDA 지원이 가장 넓은 편인지 확인
• AMD: 운영체제와 GPU 세대가 ROCm 지원 목록에 들어가는지 확인
• Apple Silicon: Metal과 통합 메모리를 지원하는 도구인지 확인
• 기타 GPU: Vulkan·XPU 등 실험 또는 공식 지원 수준 확인

2. 모델과 작업 크기

로컬 LLM 모델 크기, 양자화, 컨텍스트 길이, 이미지 해상도, 임베딩 배치 크기를 먼저 정합니다. “AI를 한다”는 말만으로 필요한 VRAM을 하나의 숫자로 정할 수는 없습니다.

3. 시스템 RAM과 저장장치

모델 파일 다운로드, 문서 변환, CPU·GPU 혼합 추론, 캐시에는 시스템 RAM과 SSD가 필요합니다. VRAM만 넉넉하고 RAM·디스크가 부족하면 전체 파이프라인이 다시 막힙니다.

4. 전력과 발열

대량 임베딩과 이미지 생성은 GPU를 오랫동안 사용합니다. 전원 용량, 냉각, 소음, 24시간 운영 여부를 함께 봅니다. 라즈베리파이와 GPU 머신을 분리하면 상시 대기 장치의 전력은 낮추고, 무거운 작업 때만 GPU를 사용할 수 있습니다.

GPU 가속 여부를 확인하는 요청문

설치와 설정을 AI 에이전트에게 맡길 때는 다음처럼 검증 조건을 함께 전달합니다.

이 머신에서 qmd 임베딩을 실행하기 전에 CPU, RAM, GPU, VRAM과
qmd가 사용할 수 있는 CUDA·Metal·Vulkan 백엔드를 확인해 줘.

qmd doctor 결과로 실제 선택된 백엔드를 보여 주고,
동일한 테스트 문서로 임베딩 시간을 측정해 줘.

NVIDIA GPU라면 nvidia-smi로 VRAM 사용량과 GPU 사용률을 함께 기록하고,
CPU 모드로 실행됐다면 성공으로 보고하지 말고 원인을 설명해 줘.

이 요청의 목적은 무조건 GPU를 쓰게 만드는 것이 아닙니다. 지원되지 않는 하드웨어에서 GPU 가속이 적용됐다고 오판하지 않는 것이 먼저입니다.

라즈베리파이와 GPU 머신의 역할 분담

라즈베리파이에서 임베딩이 오래 걸렸다는 경험은 실패라기보다 장비 역할을 구분하는 기준이 됩니다. 파일 수집, 문서 변환, 출처 관리, BM25 검색, Gateway와 예약 작업은 라즈베리파이가 계속 맡을 수 있습니다.

반면 대량 벡터 임베딩, 로컬 LLM, 재랭킹, Vision, 음성 인식, 이미지 생성은 GPU와 VRAM의 효과가 큰 영역입니다. qmd를 사용한다면 GPU 머신에 문서 컬렉션과 색인을 함께 두고 HTTP MCP 서버로 제공하는 방식처럼, 도구가 실제로 지원하는 경계를 기준으로 분리해야 합니다. 그러면 기존 라즈베리파이 자동화 구성을 버리지 않고도 무거운 추론을 GPU 머신에 배치할 수 있습니다.

다음 비교에서는 동일한 문서와 모델을 사용해 라즈베리파이 CPU 실행과 GPU 머신 실행의 총 소요시간, 처리 조각 수, 최대 RAM·VRAM, 실패·재시도 횟수를 함께 기록할 계획입니다. 그 수치가 있어야 “GPU가 빠르다”를 넘어, 어떤 작업을 어느 장비에 배치할지 판단할 수 있습니다.

참고한 공식 문서

• Raspberry Pi 5 소개와 VideoCore VII 사양
• qmd 저장소: GPU 탐지·임베딩·재랭킹 설정
• qmd 2.5.3 임베딩 세션의 30분 제한 소스
• Ollama 하드웨어 및 GPU 지원
• Ollama CPU·GPU 모델 배치 확인
• llama.cpp GPU 백엔드와 CPU·GPU 혼합 추론
• ComfyUI 시스템 요구사항
• faster-whisper CPU·GPU 실행과 메모리 벤치마크