체감으로 보는 Nomic Embed 로컬 RAG, p50 말고 p95로 판단하라
요약: Nomic Embed란 로컬 환경에서 문서와 질의를 벡터로 바꾸는 오픈 임베딩 모델로, RAG의 검색 품질(recall@5)과 사용자가 느끼는 응답 지연을 동시에 좌우하는 핵심 부품이다. 체감 속도는 평균(p50)이 아니라 꼬리 지연(p95)에서 갈리며, 로컬 RAG 실패의 상당수는 모델 자체가 아니라 이 꼬리 구간을 방치한 데서 온다. first_response_latency_ms 120.8 ms Hax가 자체 인프라에서 직접 측정한 실측값은?
Nomic Embed란 로컬 환경에서 문서와 질의를 벡터로 바꾸는 오픈 임베딩 모델로, RAG의 검색 품질(recall@5)과 사용자가 느끼는 응답 지연을 동시에 좌우하는 핵심 부품이다. 체감 속도는 평균(p50)이 아니라 꼬리 지연(p95)에서 갈리며, 로컬 RAG 실패의 상당수는 모델 자체가 아니라 이 꼬리 구간을 방치한 데서 온다.
first_response_latency_ms 120.8 ms
Hax가 자체 인프라에서 직접 측정한 실측값은?#
아래는 Hax가 자체 인프라에서 직접 계측·공개한 참고 수치입니다(측정값, 출처 표기).
| 데이터 항목 | 실측값 | 날짜 | 출처 |
|---|---|---|---|
| first_response_latency_ms | 120.8 ms | 2026-07-04 | bench_harness.probe_unified_latency |
| 생성 처리량 | 38.8 tok/s | 2026-07-04 | bench_harness.probe_llm_bench (unified-api 실측, 3회 중앙값) |
| 전체 생성 지연(200토큰) | 5153 ms | 2026-07-04 | bench_harness.probe_llm_bench (unified-api 실측, 3회 중앙값) |
- 표본
- 실측 지표 3개 (Hax /data 큐레이션)
- 측정 환경
- bench_harness.probe_llm_bench (unified-api 실측
- 수집일
- 2026-07-04
- 방법
- bench_harness.probe_unified_latency; 3회 중앙값)
이 수치는 어떻게 재현하나?#
측정 방법은 표의 출처와 우리 공개 데이터셋(/data)에서 확인할 수 있습니다.
HTTP 응답 P95 지연(7일) 625 ms
| 지표 | Hax 측정 | 추정/비교 |
|---|---|---|
| first_response_latency | 119.2~120.8 ms (측정, 2026-07-03~04, bench_harness) | - |
| HTTP 응답 P95(7일) | 625 ms (측정, 2026-07-24, telemetry/funnel) | - |
| recall@5 | 측정대기(not measured) | 0.80~0.90 (추정) |
| 디스크 풋프린트(fp16) | 측정대기(not measured) | 약 274 MB (추정) |
왜 p50이 아니라 p95인가. 로컬 RAG를 열 번 호출하면 여덟 번은 빠르고 두 번은 느린 것이 정상이다. 이 느린 두 번이 콜드 캐시, 디스크 I/O, 배치 미적용 구간에서 튀며, 사용자는 바로 이 두 번을 '느리다'고 기억한다. Hax ai-server의 통합 경로 첫 응답 지연은 119.2~120.8 ms(측정)로 안정적이지만, 7일 HTTP 응답 P95는 625 ms(측정)로 다섯 배 이상 벌어진다. 즉 평균만 보면 문제가 없어 보여도 꼬리에서 체감이 무너진다. 이 실측 지연 프로파일을 우리는 'Hax Local-AI Latency Index'[/glossary#hax-latency-index]로 추적한다.
로컬 RAG 실패 사례는 대체로 네 가지다. 첫째, task prefix 누락. Nomic Embed는 질의에 'search_query:', 문서에 'search_document:' 접두를 붙이도록 설계됐는데, 이를 빼면 recall@5가 눈에 띄게 떨어진다(추정). 둘째, Matryoshka 차원 절단 오용. 768차원을 256이나 128로 자르면 디스크와 메모리는 줄지만 검색 정확도가 함께 떨어져, 무작정 줄이면 체감 응답은 빨라져도 '엉뚱한 문서'가 올라온다(추정). 셋째, 정규화 불일치. 코사인 유사도를 쓰면서 벡터를 L2 정규화하지 않으면 순위가 흔들린다. 넷째, 단건 임베딩. 배치를 묶지 않으면 p50은 괜찮아도 동시 요청이 몰릴 때 p95 꼬리가 급격히 길어진다.
고치는 순서도 p95 기준으로 잡는다. (1) 접두어를 코드에 고정해 recall 회복을 먼저 확보한다. (2) 차원은 성능이 허용하는 한 768을 유지하되, 디스크 압박이 실측될 때만 512 정도로 단계 축소한다. (3) 벡터 정규화와 인덱스(HNSW ef/파라미터)를 검색 지표로 검증한다. (4) 캐시를 예열하고 임베딩을 배치로 묶어 꼬리 지연을 깎는다. 목표 SLO도 평균이 아니라 'p95 < N ms' 형태로 선언해야 한다.
디스크 풋프린트는 fp16 기준 약 274 MB로 추정되며, 양자화(GGUF) 시 더 작아지지만 검색 품질과 트레이드오프가 있다(추정). 이 값들은 Hax에서 아직 측정하지 않았으므로 표에 '측정대기'로 남겼다. 즉, 남의 벤치를 그대로 믿지 말고 자기 장비에서 p50/p95를 직접 재는 것이 로컬 RAG 튜닝의 출발점이다.
<svg viewBox="0 0 420 140" xmlns="" font-family="sans-serif">
<rect x="0" y="0" width="420" height="140" fill="#ffffff" stroke="#111"/>
<text x="12" y="22" font-size="13" fill="#111">지연 분포: p50은 짧고 p95 꼬리가 체감을 결정</text>
<line x1="20" y1="110" x2="400" y2="110" stroke="#111"/>
<rect x="40" y="70" width="22" height="40" fill="#111"/>
<rect x="90" y="50" width="22" height="60" fill="#111"/>
<rect x="140" y="78" width="22" height="32" fill="#111"/>
<rect x="330" y="38" width="22" height="72" fill="#111"/>
<text x="78" y="126" font-size="11" fill="#111">p50 ~120 ms(측정)</text>
<text x="300" y="126" font-size="11" fill="#111">p95 625 ms(측정)</text>
</svg>
참고: 위 Hax 측정치는 2026-07-03~24 수집분(bench_harness / telemetry)이며, Nomic 모델의 recall·디스크 수치는 공개 스펙 기반 추정으로 Hax 자체 측정은 아직 없다. 내부 근거는 Hax data 참고.
함께 읽기: Nomic Embed 로컬 RAG, p95 지연으로 판단하는 구매 체크리스트, BGE-M3 다국어 검색 초보 5분 설치 퀵스타트와 실패 지점
종합 가이드: 노트북에서 AI 모델 뭐가 돌아갈까 — VRAM·RAM 실측과 메모리 구조
Responses
No responses yet. Be the first to respond.