Nomic Embed 로컬 RAG 설치, 실패 지점부터 실측으로 본다
요약: Nomic Embed란 오픈소스로 공개된 텍스트 임베딩 모델로, 로컬 RAG에서 문서를 벡터로 바꿔 검색 정확도(recall)를 좌우하며, 처음 설치하는 사람이 마주치는 진짜 난관은 성능이 아니라 파이썬 의존성 충돌·모델 다운로드·GPU/CPU 백엔드 선택 같은 '실패 지점'에 있다. 최대 VRAM 상주(스냅샷) 84.8 GB Hax가 자체 인프라에서 직접 측정한 실측값은? 아래는 Hax가 자체 인프라에서 직접 계측·공개한 참고 수치입니다(측정값, 출처 표기).
Nomic Embed란 오픈소스로 공개된 텍스트 임베딩 모델로, 로컬 RAG에서 문서를 벡터로 바꿔 검색 정확도(recall)를 좌우하며, 처음 설치하는 사람이 마주치는 진짜 난관은 성능이 아니라 파이썬 의존성 충돌·모델 다운로드·GPU/CPU 백엔드 선택 같은 '실패 지점'에 있다.
최대 VRAM 상주(스냅샷) 84.8 GB
Hax가 자체 인프라에서 직접 측정한 실측값은?#
아래는 Hax가 자체 인프라에서 직접 계측·공개한 참고 수치입니다(측정값, 출처 표기).
| 데이터 항목 | 실측값 | 날짜 | 출처 |
|---|---|---|---|
| 저장된 메모리 수 | 10839 개 | 2026-07-23 | bench_harness.probe_curator (curator stats 실측) |
| 최대 VRAM 상주(스냅샷) | 84.8 GB | 2026-07-04 | bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측) |
| first_response_latency_ms | 120.8 ms | 2026-07-04 | bench_harness.probe_unified_latency |
- 표본
- 실측 지표 3개 (Hax /data 큐레이션)
- 측정 환경
- bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측)
- 수집일
- 2026-07-04 ~ 2026-07-23
- 방법
- bench_harness.probe_unified_latency; bench_harness.probe_curator (curator stats 실측)
이 수치는 어떻게 재현하나?#
측정 방법은 표의 출처와 우리 공개 데이터셋(/data)에서 확인할 수 있습니다.
| 지표 | Hax 측정 (ai-server Curator, 2026-07-23) | Nomic Embed 추정 |
|---|---|---|
| 활성 벡터/메모리 수 | 10495 개 (측정) | 해당없음 |
| 평균 신뢰도 | 0.616 (측정) | 해당없음 |
| recall@5 | 측정대기 (not measured) | 상위권 추정 (추정) |
| 모델 디스크 풋프린트 | 측정대기 (not measured) | 약 0.26~0.55 GB 추정 (추정) |
| 임베딩 차원 | — | 768 추정 (Matryoshka 축소 가능, 추정) |
Hax 로컬 메모리 스토어 활성 10495개 · 평균 신뢰도 0.616
초보자가 Nomic Embed로 로컬 RAG를 처음 세울 때 넘어지는 자리는 대체로 세 곳이다. 첫째는 의존성이다. 임베딩 러너(예: sentence-transformers 계열 로더나 GGUF 러너)와 파이썬·CUDA 버전이 어긋나면 모델 로드 단계에서 바로 죽는다. 둘째는 모델 내려받기다. 가중치가 캐시에 다 떨어지기 전에 프로세스를 끊으면 반쯤 받은 파일이 남아 다음 실행이 조용히 실패한다. 셋째는 백엔드 선택이다. GPU가 없거나 VRAM이 모자라면 CPU로 강제 폴백해야 하는데, 이 스위치를 모르면 '느리다'가 아니라 '뜨지 않는다'로 겪는다. 즉 설치 난이도는 recall 숫자보다 이 세 실패 지점에서 결정된다.
recall@5와 디스크 풋프린트는 우리가 아직 이 하드웨어에서 직접 재지 않았다. 위 표에서 이 두 값은 '측정대기(not measured)'로 두고, 흔히 인용되는 상위권 recall·수백 MB급 모델 크기는 모두 '추정(estimated)'으로만 표기했다. 초보자에게 유용한 실측 기준선을 우리가 가진 것은 임베딩 벡터를 실제로 쌓아 운영 중인 로컬 메모리 스토어(Curator) 쪽이다. 여기서 나온 숫자가 RAG 설계에 직접적인 교훈을 준다.
측정된 추세를 보면, 저장된 항목 수는 2026-07-04 9147개에서 2026-07-23 10839개로 늘었고 활성 항목도 8919개에서 10495개로 증가했다(측정). 그런데 평균 신뢰도는 같은 기간 0.721에서 0.616으로 내려갔다(측정). 벡터를 계속 넣기만 하면 스토어는 커지지만 평균 품질은 희석된다는 뜻이다. 로컬 RAG를 처음 세우는 사람이 가져갈 실측 교훈은 분명하다. Nomic Embed로 인덱스를 채우는 것만큼, 오래되고 낮은 신뢰도의 청크를 솎아내는 정리(pruning) 루프를 처음부터 배선해야 recall이 유지된다.
처음 설치라면 순서는 이렇게 잡는 편이 실패를 줄인다. (1) 파이썬 가상환경을 격리하고 러너·CUDA 버전을 먼저 맞춘다. (2) 모델 가중치를 끝까지 받았는지 체크섬/크기로 확인한 뒤 인덱싱을 시작한다. (3) GPU가 없으면 CPU 백엔드를 명시적으로 켜고, 첫 문서 한 개만 임베딩해 벡터 차원과 로드가 정상인지 확인하고 나서 전체를 돌린다. (4) 인덱싱 파이프라인에 신뢰도/최신성 기반 정리 단계를 함께 넣는다. recall@5 목표치는 우리 하드웨어 실측이 나오기 전까지 추정으로만 다뤄야 하며, 실제 숫자는 여러분 문서·질의로 직접 재는 것이 가장 정확하다.
참고: 측정치는 2026-07-04~2026-07-23 우리 ai-server Curator 스냅샷(bench_harness.probe_curator) 기준이며, Nomic Embed의 recall@5·디스크 풋프린트·차원 수치는 공개 추정으로 이 환경에서는 실측 대기 상태다. 근거: Hax 측정 데이터.
함께 읽기: Nomic Embed 로컬 RAG, 클라우드 비용을 줄일까, Llama 3.3 70B 로컬 구축 전 필수 체크리스트와 실패 지점 분석
종합 가이드: 노트북에서 돌리는 AI 모델, 흔한 함정과 해결법
Responses
No responses yet. Be the first to respond.