Nomic Embed 로컬 RAG, p95 지연으로 판단하는 구매 체크리스트

Nomic Embed 로컬 RAG란 Nomic Embed 임베딩 모델로 문서를 벡터로 바꿔 로컬 장비에서 검색과 생성을 함께 수행하는 구성으로, 구매를 결정하기 전에 평균 지연(p50)이 아니라 꼬리 지연(p95)과 recall@5, 디스크 사용량을 한 화면에서 같이 확인해야 하는 시스템이다. 체감 속도는 평균이 아니라 상위 5퍼센트의 느린 응답에서 결정되므로, 벤치마크 표에 p50만 있고 p95가 없으면 그 표는 구매 판단 자료로 부족하다.

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

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

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

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

이 625 ms는 우리 운영 스택에서 7일 창으로 관측한 상위 5퍼센트 응답 시간이며, 우리는 이렇게 실측한 로컬 AI 지연을 'Hax Local-AI Latency Index'[/glossary#hax-latency-index]로 부른다. 같은 스택의 first-response 단건 지연은 119.2 ms(측정 2026-07-03), 120.8 ms(측정 2026-07-04)로 나왔다. 즉 잘 풀릴 때의 한 번(약 120 ms 측정)과 실제 트래픽의 꼬리(625 ms 측정) 사이에는 약 5배 차이가 있으며, 이 간극이 바로 사용자가 '느리다'고 느끼는 지점이다. 구매 전 벤치마크를 읽을 때 이 두 숫자를 분리해서 보라.

체크리스트는 네 갈래로 나눈다. 첫째 임베딩 품질이다. Nomic Embed Text 계열은 매트료시카 구조로 768차원을 64~256차원까지 줄여도 recall@5 하락이 작다고 알려져 있으나, 여기서 인용하는 차원 수와 recall 수치는 우리가 측정한 값이 아니라 추정이므로 반드시 본인 문서셋으로 재측정해야 한다. 둘째 디스크 발자국이다. 모델 가중치와 벡터 인덱스는 다른 항목인데, 문서 수에 비례해 커지는 쪽은 인덱스다. 활성 메모리 약 1만 개 수준(측정 2026-07-24, 10585개)에서 인덱스가 어느 정도로 불어나는지는 장비마다 달라 추정으로만 제시하고, 실제 값은 색인 후 파일 크기로 직접 재는 편이 정확하다.

셋째 지연 측정 방법이다. 콜드 스타트(모델 최초 로딩)와 웜 상태를 섞어 재면 p95가 오염된다. 로딩을 끝낸 뒤 동일 질의를 반복해 p50과 p95를 따로 뽑고, 배치 크기와 동시 요청 수를 고정하라. 넷째 저장소 성장 추세다. 우리 큐레이터 실측에서 저장 메모리는 2026-07-04 9147개에서 2026-07-24 10929개로 늘었고, 같은 기간 평균 신뢰도는 0.721에서 0.612로 내려갔다(모두 측정). 저장량이 늘수록 평균 신뢰도가 완만히 떨어지는 흐름은 인덱스가 커질 때 검색 품질 관리가 왜 필요한지를 보여준다.

결론은 단순하다. p50만 좋은 구성은 데모에서만 빠르고, 실제로는 p95에서 무너진다. 구매 전에는 반드시 본인 문서셋으로 recall@5, 디스크 발자국, p50/p95를 각각 측정해 표로 만들고, 남의 벤치마크 수치는 추정으로 취급하라.

참고: 위 측정값은 2026-07-03~2026-07-24 창의 Hax 운영·벤치 실측이며, Nomic Embed 관련 차원·recall·디스크 수치는 추정이다. 내부 근거는 Hax data에서 확인할 수 있다.

함께 읽기: 개인정보 안 보내는 Nomic Embed 로컬 RAG, 무엇으로 판단하나, 체감 응답속도로 판단하는 Nomic Embed 로컬 RAG 5분 퀵스타트

종합 가이드: 노트북에서 돌리는 AI 모델, 흔한 함정과 해결법

참고 링크#

• Hax 공개 실측 데이터셋