실험은 적재·인덱스 빌드가 끝난 sealed 데이터의 CPU 검색을 대상으로 했으며, QueryNode의 자원 사용을 분석했다.
서버는 각각 Intel Xeon Silver 4516Y+ 2소켓·물리 코어 48개·메모리 512GB 구성이다. QueryNode 할당량은 48 vCPU·256GiB였다.
HNSW_SQ8·ef48 조건에서 자원 할당량과 검색 조건을 유지하고 CPU·메모리 위치만 조정했다. 원격 DRAM 읽기 비율은 약 50%에서 0.8%, IPC는 0.37에서 0.55로 바뀌었다.
검색 p99의 측정 구간 최댓값은 3.94초에서 2.04초로 줄었다. 전체 요청을 합친 지연시간 분포의 p99를 뜻하지 않는다.
별도 인덱스 비교에서 HNSW_SQ8은 recall@10 0.954·316 QPS·replica당 약 114GB를 기록했다. 비압축 HNSW는 약 335GB를 사용했으며, 각 구성의 검색 설정과 자원 할당량도 조정했으므로 인덱스만의 차이는 아니다.
Kubernetes 적용 조건: CPU Manager의 static 정책에서 전용 CPU를 받으려면 Guaranteed Pod와 컨테이너의 정수 CPU 요청이 필요하다. Memory Manager의 Static 정책에는 reservedMemory가 필요하며, kubeReserved·systemReserved·evictionHard의 메모리 예약량과 맞춰야 한다. Topology Manager의 single-numa-node는 자원을 한 NUMA 노드에 맞출 수 없으면 Pod 수용을 거부한다. 기본 scope는 container이므로 Pod의 모든 컨테이너가 같은 NUMA 노드에 놓인다고 볼 수 없다. CPU 번호와 예약량은 서버별 topology에 맞춰 정한다.