turbovec와 Linux VRAM 관리 개선, 메모리 한계를 줄이는 두 접근

메모리 사용량은 벡터 검색과 그래픽 처리 모두에서 성능을 좌우한다. Rust로 작성된 벡터 인덱스 turbovec는 임베딩을 압축해 검색에 필요한 RAM을 줄이고, Linux 그래픽 개발자는 VRAM이 부족할 때 시스템 메모리를 더 안정적으로 활용하는 방법을 개선하고 있다.

TurboQuant를 구현한 Rust 벡터 인덱스

turbovec는 Google Research가 발표한 TurboQuant 알고리즘을 기반으로 만든 오픈소스 벡터 인덱스다. 핵심 엔진은 Rust로 작성됐으며 Python 바인딩도 제공한다. 별도의 학습 단계 없이 벡터를 추가할 수 있고, ARM의 NEON과 x86의 AVX-512·AVX2를 이용한 SIMD 검색 경로를 갖췄다.

프로젝트 설명에 따르면 FP32로 약 31GB가 필요한 1,000만 개 문서 벡터를 4GB 안에 저장할 수 있다. 자체 벤치마크에서는 10만 개 벡터와 1,000개 질의를 사용했으며, 4비트 설정에서 FAISS IndexPQFastScan보다 평균 3.4배 빠른 검색 결과를 제시했다.

다만 이 수치는 프로젝트 제작자가 정한 데이터셋·하드웨어·비트 폭에서 측정한 결과다. 2비트와 4비트 압축은 메모리를 크게 줄이는 대신 검색 정확도에 영향을 줄 수 있고, 낮은 차원의 벡터에서는 FAISS가 일부 구간에서 앞서는 결과도 공개돼 있다. 실제 도입 전에는 사용하는 임베딩과 질의 분포로 정확도와 속도를 다시 측정해야 한다.

Linux 7.3에 들어가는 VRAM 관리 패치

GPU 개발자 Natalie Vock은 앞서 작업한 VRAM 관리 패치가 업스트림에 병합돼 Linux 7.3에 포함될 예정이라고 밝혔다. 이 작업은 여러 프로세스가 VRAM을 놓고 경쟁할 때 중요한 작업의 메모리를 보호하고, 사용 빈도가 낮은 데이터를 시스템 RAM으로 옮기는 판단을 개선하는 데 초점을 맞춘다.

VRAM 사용량이 물리 용량을 넘으면 일부 데이터는 CPU의 시스템 메모리로 이동한다. GPU가 이 데이터를 읽으려면 PCIe를 거쳐야 하므로 성능 저하는 피할 수 없다. 다만 어떤 데이터를 내보내는지, 해당 데이터가 얼마나 자주 사용되는지, GPU 캐시에 얼마나 남는지에 따라 체감 속도 차이는 크게 달라진다.

Linux 7.3이 모든 개선을 포함하는 것은 아니다

원문은 Linux 7.3에 병합된 앞선 패치와, VRAM 오버커밋 상황을 더 개선하기 위해 뒤이어 개발한 작업을 함께 설명한다. 후자의 일부는 SteamOS에 먼저 적용됐지만 글 작성 시점에는 모두 메인라인 Linux에 병합된 상태가 아니었다. 개발자가 공개한 별도 커널·Mesa 브랜치도 충분한 검증을 거치지 않은 실험용으로 안내돼 있다.

따라서 Linux 7.3이 그래픽카드의 물리 VRAM을 늘리거나 모든 메모리 부족 문제를 해결한다고 볼 수는 없다. 이번 변화의 의미는 제한된 메모리에서 어떤 데이터를 우선 유지할지 더 합리적으로 결정해 급격한 성능 저하와 불안정성을 줄이려는 데 있다.