SingleStore 9.1 Float16 벡터 타입 지원

 

안녕하세요 에이플랫폼입니다.

 

최근 LLM의 확산으로 머신러닝, 의미 기반 검색, 생성형 AI 애플리케이션에서 벡터 검색의 중요성이 크게 부각되고 있습니다. 하지만 벡터 데이터베이스에 저장되는 데이터가 많아질수록 메모리 사용량과 저장 공간은 곧 비용 문제로 이어집니다. 임베딩 벡터들은 수백 개에서 수천 개의 부동소수점 값으로 구성되기 때문에, 데이터 규모가 커질수록 필요한 리소스도 함께 커집니다.

 

이 문제를 줄이는 방법 중 하나는 벡터를 구성하는 각 요소(element)의 정밀도를 낮추는 것입니다.

벡터 유사도 검사의 경우 벡터 요소의 정밀도에 민감하지 않기 때문에, 32-bit float 대신 16-bit float로 벡터를 저장하고 처리하는 방식을 충분히 고려할 수 있습니다. 또한 Intel과 ARM 명령어 세트는 2022~2023년경부터 16비트 float 기반의 네이티브 수학 연산을 지원해 왔으며, Intel의 F16C 명령어는 2012년 Ivy Bridge 세대부터 제공되어, 16-bit float 변환을 빠르게 처리할 수 있습니다.

 

이를 지원하고자 SingleStore 9.1 버전에서는 Float 16 벡터 타입을 새롭게 도입했습니다.

Float 32와 비교했을 때 유사한 recall 성능을 유지하면서 저장 비용은 약 절반으로 줄이고, 컴퓨팅 비용은 거의 40% 절감했습니다. 이번 글에서는 SingleStore 9.1의 새로운 데이터 타입인 VECTOR(<N>, F16)이 벡터 저장 공간을 줄이고 검색 성능을 개선하는 데 어떻게 활용되는지 살펴보겠습니다.

---

 

F32와 F16 벡터 타입의 차이

텍스트 임베딩 모델을 포함한 벡터 임베딩을 다룰 때는 관련된 수치 값을 이해하는 것이 도움이 됩니다. 최신 임베딩 모델은 일반적으로 32비트 부동소수점 형식 또는 single precision으로 벡터를 생성합니다. 하지만 SingleStore에서는 이러한 벡터를 32비트 부동소수점(F32) 형식뿐만 아니라, 16비트 부동소수점(F16) 형식으로도 저장하고 인덱싱할 수 있습니다.

 

F32는 약 ±1.2 × 10⁻³⁸부터 ±3.4 × 10³⁸까지 매우 넓은 범위의 값을 표현할 수 있고, 7자리의 유효숫자 정밀도를 제공합니다. 반면 F16은 약 ±6.1 × 10⁻⁵부터 ±6.5 × 10⁴까지 표현할 수 있고, 3~4자리의 유효숫자 정밀도를 제공합니다. F32와 비교하면 F16은 정밀도가 낮아 약 3~4자리의 유효숫자 정밀도만 제공하지만, 메모리를 절반만 사용하고 처리 속도도 더 빠릅니다.

 

임베딩 벡터에서 F16을 사용할 수 있는 이유

대부분의 임베딩 모델은 출력 벡터를 단위 길이(length = 1)로 정규화합니다. 따라서 벡터 임베딩에서는 F32나 F16의 이론적 한계에 가까운 값을 거의 보지 못합니다.

(*정규화: 임베딩 벡터의 원점으로부터의 Euclidean distance, 즉 벡터의 길이가 1이 되도록 조정하는 과정입니다.)

 

이 정규화 때문에 임베딩 벡터의 개별 구성요소는 보통 -1에서 1 사이의 좁은 범위에 위치합니다. 실제로는 임베딩 차원이 높아질수록 각 벡터 요소의 값이 0에 더 가까워지는 경향이 있습니다. 전체 벡터의 길이는 1로 유지되어야 하는데, 차원이 많아질수록 이 길이를 더 많은 벡터 요소가 함께 나누어 표현하기 때문입니다.

 

F16은 F32보다 정밀도가 낮지만, 많은 벡터 검색 애플리케이션에서는 F16으로 충분합니다. 의미 기반 검색과 생성형 AI 검색 시스템 같은 벡터 검색 애플리케이션은 정확한 거리를 필요로 하지 않고 올바른 순위(correct ranking)만 필요하기 때문입니다. 즉 정밀도의 손실이 일부 있더라도, 벡터 검색 결과는 올바른 정렬 순서를 유지합니다. 또한 임베딩 벡터 자체도 정밀하지 않으며, 일부 noise와 정밀도 손실에 대해 허용 오차(tolerance)가 큽니다.

 

F16 벡터의 저장 공간 절감 효과

다음은 http://corpus-texmex.irisa.fr의 GIST 1M 데이터셋을 사용해 SingleStore 테이블에서 F16 벡터와 F32 벡터가 사용하는 저장 공간(storage)을 비교한 표입니다. 이 데이터 셋은 960차원의 벡터 100만 개를 포함합니다. 테스트 결과 F16이 F32보다 약 50%의 storage를 덜 쓰는 것으로 확인되었습니다.

Vector Type	Storage Size
F16	1.79GB
F32	3.57GB

 

F16 벡터의 검색 성능 비교

정규화된 벡터에서 F16 벡터는 DOT_PRODUCT, EUCLIDEAN_DISTANCE 연산에서 F32 벡터보다 더 빠른 검색과 인덱싱 성능을 제공합니다. 

 

storage 테스트도 마찬가지로 GIST 1M 데이터셋을 대상으로 수행했습니다. 

해당 테스트는 아래 조건을 기반으로 진행되었습니다.

• F16 벡터는 SingleStore의 데이터 타입 변환 기능을 사용해 F32 컬럼에서 변환합니다.
• VECTOR(960, F16) 컬럼을 가진 테이블
• VECTOR(960, F32) 컬럼을 가진 테이블

 

Exact k-NN 검색 성능

결과는 F16 벡터에서 DOT_PRODUCT를 사용하는 exact kNN(k-Nearest Neighbor) 검색이 F32를 사용할 때보다 38% 빠르며, EUCLIDEAN_DISTANCE를 사용하는 유사한 쿼리도 F16을 사용할 때 F32보다 37% 빠르다는 것을 보여줍니다.

Operation	F16	F32	Improvement
DOT_PRODUCT	491.8 ms	794.6 ms	38.1%
EUCLIDEAN_DISTANCE	500.6 ms	797.6 ms	37.2%

 

 

F16 벡터에서 DOT_PRODUCT 성능을 테스트하는 데 사용한 쿼리는 아래와 같습니다.

-- @vec_f16은 query vector를 보관하는 사용자 정의 변수입니다. 
SELECT DOT_PRODUCT (f16_col, @vec_f16) AS score 
FROM t_f16 
ORDER BY score DESC LIMIT 10;

---

ANN 인덱스 기반 검색 성능

ANN 인덱스는 F16과 F32 벡터 모두에서 지원됩니다. 결과는 F16과 F32 벡터의 인덱스 생성 시간과 검색 시간이 유사하다는 것을 보여줍니다. 즉 F16을 사용하면 벡터 storage 공간을 절약하면서 검색 성능을 유지하거나, 혹은 개선할 수도 있습니다.

 

인덱스는 SingleStore에서 권장하는 인덱스를 사용했습니다.

• IVF_PQFS: product quantization(PQ)을 사용해 storage 공간을 줄이고 더 작은 인덱스를 생성합니다.
• HNSW_FLAT: 벡터를 압축하지 않으며 높은 정확도(recall)를 제공하지만 더 큰 인덱스를 생성합니다.

SingleStore는 Faiss 라이브러리를 사용하며, Faiss는 F16 하드웨어 명령어를 지원하지 않습니다. 따라서 인덱스를 빌드하는 동안 F16 벡터는 F32로 up-cast 되고, 인덱스는 F32 벡터를 저장합니다. 벡터 인덱스 빌드 중 F16 벡터가 F32 벡터로 변환되기 때문에, F16과 F32의 벡터 인덱스 크기는 동일합니다. IVF_PQFS 인덱스의 경우 product quantization 사용으로 storage 공간이 크게 줄어듭니다.

 

ANN 인덱스 기반 검색 속도

인덱스 검색은 F16 벡터가 F32 벡터보다 약 4~8% 더 빠릅니다. 

이는 F16 벡터의 메모리 사용량이 적어 더 많은 작업 데이터(working set) 캐시에 적재될 수 있고, 결과적으로 캐시 활용도가 높아졌기 때문으로 보입니다.

Index	F16	F32	Improvement
IVF_PQFS	33.25 ms	34.73 ms	4.3%
HNSW_FLAT	30.71 ms	33.50 ms	8.3%

 

F16 ANN search time을 테스트하는 데 사용한 쿼리는 아래와 같습니다. 

SET @qvec = UNHEX('<gist_query_vector_hex>'):>VECTOR(960, F16); 

-- ANN search: find 100 approximate nearest neighbors
SELECT id, EUCLIDEAN_DISTANCE(f16_col, @qvec) AS dist 
FROM t_f16  
ORDER BY dist ASC
LIMIT 100;

 

ANN 기반 인덱스 생성 시간

인덱스 생성 시간은 F16 벡터가 F32 벡터보다 약 7~9% 더 느렸습니다.

이는 F16 벡터가 F32 벡터로 변환(typecasting)하는 오버헤드 때문에 추가적인 시간이 소요됩니다. 

Index	F16	F32	Improvement
IVF_PQFS	12.11 s	11.06 s	-9.5%
HNSW_FLAT	463.3 s	429.25 s	-7.3%

 

---

F16 벡터의 검색 품질 비교

지금까지의 테스트 결과를 보시면서 "결과적으로 검색 품질 자체가 F32보다 더 좋아지는 것은 아니지 않나?"라고 생각하셨을 수도 있습니다. 맞습니다. 검색 결과의 정확도(recall) 측면만 본다면 F16은 F32 벡터를 사용할 때와 본질적으로 동일하며, 더 뛰어나다고 할 수는 없습니다.

 

하지만 F16 벡터 검색은 F32 검색과 거의 비슷한 속도로 수행되면서도, 절반 수준의 하드웨어와 저장 공간만으로 동작할 수 있습니다. 또한 이번 테스트 데이터셋에서는 거의 동일한 recall을 제공했습니다. 즉, 절반 수준의 비용으로 유사한 검색 품질을 얻을 수 있습니다.

 

물론 F32는 과학, 의료 영상, 금융 애플리케이션과 같이 높은 수치 정밀도가 필요한 분야에서는 여전히 중요합니다. 다만 대부분의 사용 사례에서는 이번 실험 결과처럼 F16이 더 효율적인 선택이 될 수 있습니다. 특히 데이터셋 규모가 클수록 이러한 장점은 더 커집니다.

 

Recall 비교 결과

GIST 1M 데이터셋에는 평가용 정답이 포함되어 있습니다. Recall은 쿼리 결과와 평가용 정답을 비교하여 측정했습니다. 결과는 아래와 같습니다.

 

F16과 F32는 두 인덱스 타입에서 통계적으로 동등한 recall을 가집니다. 표에서 나타나는 1% 미만의 차이는 ANN 방식의 검색과 벤치마크 방법론과의 차이에 따른 오차로 인한 것이며 큰 차이는 없습니다. 결과적으로 F16은 F32와 동일한 검색 품질을 제공합니다.

	IVF_PQFS F16	IVF_PQFS F32	HNSW_FLAT F16	HNSW_FLAT F32
Recall	96.4%	95.8%	97.9%	98.0%

 

F16 벡터 타입 적용 방법 

벡터 검색을 이용하는 애플리케이션에서 높은 정밀도를 요구하지 않는다면, VECTOR(<N>, F16) 타입의 컬럼으로 테이블을 생성하여 위에서 말한 이점을 얻을 수 있습니다. 벡터 데이터를 다루는 구체적인 방법은 [Working with Vector Data · SingleStore Helios Documentation] 문서에서 확인할 수 있습니다.

 

F32 벡터를 사용하는 기존 애플리케이션을 F16 벡터로 마이그레이션 하는 경우, 테이블에 새로운 F16 벡터 컬럼을 추가하고 기존 F32 컬럼을 변환하도록 UPDATE 명령문을 사용합니다. 또는 새 테이블을 만들고 INSERT…SELECT를 사용해 필요한 경우 batch 단위로 데이터를 이동할 수도 있습니다. 이를 수행하는 예제 SQL은 뒤의 Migrating to F16 from F32 섹션에 제공되어 있습니다.

 

결론

SingleStore 9.1의 F16 vector support는 벡터의 저장 공간을 줄이면서, 기존 성능을 유지하거나 혹은 개선할 수 있습니다.   

 

벡터 검색은 중요하지만, 벡터만 분리해 별도의 Vector DB로 운영하면 데이터가 분리되고 운영 복잡성이 커질 수 있습니다. 벡터는 하나의 데이터 타입이자 검색 방식으로 SQL 데이터베이스 안에 통합되는 것이 더 자연스럽습니다. SingleStore는 벡터 검색과 함께 전체 데이터 플랫폼 기능을 함께 제공합니다.

---

 

벡터 검색은 생성형 AI와 의미 기반 검색의 핵심 기술로 자리 잡고 있지만, 데이터 규모가 커질수록 저장 공간과 메모리 사용량은 곧 비용 문제로 이어집니다. SingleStore 9.1에서 새롭게 도입된 F16 벡터 타입은 이러한 문제에 대한 현실적인 해답을 제시합니다. 기존 F32 대비 저장 공간을 약 절반으로 줄이면서도 유사한 recall 성능을 유지하고, 일부 검색에서는 더 빠른 성능까지 확인할 수 있었습니다.

 

SingleStore는 벡터를 별도 시스템이 아닌 SQL 데이터베이스 안에서 함께 처리할 수 있는 데이터 타입으로 바라봅니다. 이를 통해 벡터 검색뿐 아니라 트랜잭션, 분석, 전문 검색, 데이터 파이프라인 기능까지 하나의 플랫폼에서 활용할 수 있습니다. 에이플랫폼은 앞으로도 SingleStore의 최신 기능과 활용 방안을 통해 기업이 더 빠르고 안정적인 데이터 기반 AI 서비스를 구축할 수 있도록 함께하겠습니다.

원문: Float16 Vector Type Support in SingleStore: Cheaper, Faster, Better