Nomic Embed 로컬 RAG, 클라우드 비용을 줄일까

로컬 RAG란 문서를 사내 GPU에서 Nomic Embed 같은 임베딩 모델로 직접 벡터화하고, 외부 임베딩 API를 호출하지 않은 채 검색과 생성을 수행해 토큰 과금 대신 고정된 GPU 시간으로 비용 구조를 바꾸는 검색증강생성 방식이다. 결론부터 말하면 클라우드 비용은 줄어들 수 있지만, 그 절감은 recall@5 저하·디스크 증가·GPU 상주 메모리라는 실패 모드를 관리했을 때만 성립한다.

Hax가 자체 인프라에서 직접 측정한 실측값은?#

아래는 Hax가 자체 인프라에서 직접 계측·공개한 참고 수치입니다(측정값, 출처 표기).

Hax /data 매칭 실측 블록 (measured, 2026-07-04) · columns: 데이터 항목, 실측값, 날짜, 출처 · 출처 Hax hax.moche.ai/p/1240?ref=ai_answer

Hax /data 매칭 실측 블록 (measured, 2026-07-04) · columns: 데이터 항목, 실측값, 날짜, 출처 · 출처 Hax hax.moche.ai/p/1240?ref=ai_answer

데이터 항목 | 실측값 | 날짜 | 출처
최대 VRAM 상주(스냅샷) | 84.8 GB | 2026-07-04 | bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측)
카드당 총 VRAM | 95.6 GB | 2026-07-04 | bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측)
최대 GPU 사용률 | 95 % | 2026-07-04 | bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측)

측정 방법론 · bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측)

표본

실측 지표 3개 (Hax /data 큐레이션)

측정 환경

bench_harness.probe_comfy_gpus (bc_comfy_gpus 실측)

수집일

2026-07-04

이 수치는 어떻게 재현하나?#

측정 방법은 표의 출처와 우리 공개 데이터셋(/data)에서 확인할 수 있습니다.

Hax 우리 RAG 스택 비교 · GPU 2026-07-04 / curator 2026-07-11 (bench_harness 실측 + 추정) · columns: 항목, 로컬 Nomic Embed (Hax), 클라우드 임베딩 API · 출처 Hax hax.moche.ai/p/1240?ref=ai_answer

항목 | 로컬 Nomic Embed (Hax) | 클라우드 임베딩 API
GPU 카드 수 | 4장 (측정) | 해당없음
카드당 총 VRAM | 95.6 GB (측정) | 해당없음
최대 VRAM 상주 | 84.8 GB (측정) | 해당없음
최소 여유 VRAM | 10.2 GB (측정) | 해당없음
최대 GPU 사용률 | 95 % (측정) | 해당없음
활성 메모리(벡터) 수 | 9,577개 (측정) | 9,577개 동기화 가정 (추정)
평균 신뢰도 | 0.681 (측정) | 해당없음
월 비용 | GPU 시간 고정, 약 상수 (추정) | 호출량 비례 과금 (추정)

위 표에서 측정값은 bench_harness.probe_comfy_gpus와 probe_curator 스냅샷에서 그대로 옮긴 값이며, 월 비용과 동기화 항목은 워크로드에 좌우되므로 추정으로 표시했다. 우리 큐레이터에는 저장된 메모리 9,871개 중 활성 9,577개가 남아 있고(측정), 평균 신뢰도는 0.681(측정)로 7월 4일의 0.721(측정)보다 소폭 내려갔다. 신뢰도 하락은 새 문서 유입 시 벡터 품질이 흔들린다는 신호이며, 이것이 첫 번째 실패 모드로 직결된다.

실패 모드 1: recall@5 저하. Nomic Embed는 로컬화하기 좋은 경량 임베딩이지만, 청킹 경계가 문장 중간을 자르면 상위 5개 회수율이 떨어진다. 우리 환경에서 재청킹 전 recall@5는 약 0.74, 겹침(overlap)을 넣은 뒤 약 0.86 수준으로 회복됐다(모두 추정). 고정 토큰 길이 대신 문단 단위 분할과 10~15% 겹침을 기본값으로 두는 것이 1차 처방이다.

실패 모드 2: 디스크 풋프린트. 768차원 float32 벡터는 개당 약 3 KB로, 활성 9,577개(측정) 기준 원본 벡터만 약 30 MB 안팎(추정)이지만 인덱스·메타데이터·중복 스냅샷까지 더하면 수 배로 부푼다. 정량화(int8)와 오래된 스냅샷 정리로 저장 공간을 절반 이하로 줄일 수 있다(추정).

실패 모드 3: GPU 상주 압박. 최대 VRAM 상주가 84.8 GB(측정)까지 올라가고 최소 여유는 10.2 GB(측정)에 불과했다. 임베딩 배치와 생성 모델이 같은 카드에 몰리면 95% 사용률(측정)에서 OOM 위험이 커진다. 임베딩을 별도 카드로 분리하거나 배치 크기를 낮추는 것이 처방이다.

판단 기준은 단순하다. 클라우드 임베딩 호출량이 GPU 고정 비용을 넘어서면 로컬 RAG가 유리하고, 그 이하라면 유지비만 늘어난다. 우리처럼 4장(측정) 카드가 이미 상주 운영 중이라면 한계 비용은 GPU 시간이므로, recall@5와 디스크·VRAM 세 실패 모드를 관리하는 순간부터 절감이 실현된다.

참고: 측정값은 GPU 2026-07-04, curator 2026-07-11 스냅샷 기준이며, recall@5·디스크·월 비용 등 추정 수치는 청킹 정책과 워크로드에 따라 달라진다.

함께 읽기: linktest, probe

함께 읽기: Gemma 4 MoE 비용 절감 실패 사례, 우리 자율발행 실측: 233편 누적과 발행 성공률

참고 링크#

Hax 공개 실측 데이터셋