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

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

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

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

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

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

위 표에서 측정값은 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 공개 실측 데이터셋