Ricerca vettoriale: HotKV contro i vector set di Redis 8, da 1 a 100 client

La ricerca vettoriale è alla base di molte funzionalità di IA: il retrieval per il RAG, la cache semantica, la memoria degli agenti. Redis 8 include i vector set, un tipo di dati in beta, direttamente nel server, quindi è il confronto più ovvio. Abbiamo caricato gli stessi embedding di OpenAI in HotKV e in Redis 8.10.2, eseguito le stesse 1.000 query su ciascuno con da 1 a 100 connessioni client simultanee, e misurato quanto fossero accurate le risposte, quante query al secondo serviva ciascun motore e quanto tempo richiedeva ogni query.

In breve. Su 999.000 vettori, con un recall minimo del 95%, HotKV ha servito 1,4 volte le query al secondo di Redis con un client e 7,9 volte con 100 client (51.146 contro 6.510). Con un recall del 99% i rapporti erano 1,8 e 5,4. La latenza mediana di HotKV è stata inferiore a ogni numero di client. Il throughput di Redis si era già stabilizzato a 32 client, mentre quello di HotKV ha continuato a crescere fino a 100. HotKV ha caricato i vettori circa 5 volte più velocemente e il suo recall era più alto a ogni profondità di ricerca. Si tratta di un solo dataset su una sola macchina, la build di HotKV è una build di sviluppo non ancora rilasciata e non abbiamo misurato il Query Engine di Redis né la sua modalità a 8 bit, quindi leggi il risultato come una misurazione, non come una classifica.

Cosa abbiamo testato

Dati

Le prime 999.000 righe di dbpedia-entities-openai-1M di Kumar Shivendu e Nirant Kasliwal (licenza MIT) e, per un indice più piccolo, le prime 100.000 righe. Le righe sono entità di DBpedia trasformate in embedding con text-embedding-ada-002 di OpenAI, a 1.536 dimensioni. Le ultime 1.000 righe sono le query, quindi nessuna riga compare in entrambi gli insiemi. Le risposte di riferimento sono i 10 vicini più prossimi esatti di ogni query, calcolati con una ricerca brute-force in virgola mobile a 64 bit in modo indipendente da entrambi i motori, così entrambi vengono valutati rispetto alla stessa ground truth.

Motori e impostazioni

• Motori. HotKV commit c8dafd37 (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH), una build di sviluppo non ancora rilasciata, compilata con i flag di release predefiniti, non con -march=native. Redis 8.10.2 compilato dal suo tag di release con un make standard (VADD, VSIM). Entrambi costruiscono grafi HNSW.
• Impostazioni dell'indice. Similarità coseno, HNSW con M=16 ed ef_construction=200 su entrambi, impostati esplicitamente. Sono anche i valori predefiniti di ciascun motore.
• Precisione. Vettori float32 a piena precisione su entrambi. Redis usa per impostazione predefinita la quantizzazione a 8 bit, quindi è stato eseguito con NOQUANT.
• Macchina. Una macchina Azure Standard_D160alds_v7 (AMD EPYC 9V45, 160 vCPU). Entrambi i server erano vincolati alle stesse 128 vCPU e i generatori di carico alle altre 32, tutto tramite loopback. HotKV ha usato 128 thread e Redis i suoi thread di I/O predefiniti. Abbiamo provato 1, 4, 8 e 16 e l'impostazione non ha prodotto alcuna differenza coerente.
• Generatore di carico. Un processo per ogni connessione client, ciascuno con una sola richiesta in sospeso alla volta, con le richieste costruite prima della fase cronometrata. Il processo del generatore di carico più impegnato ha usato l'8% di una CPU in qualsiasi esecuzione, quindi il client non è mai stato il fattore limitante.

Procedura

Per profondità di ricerca (ef) di 40, 80, 150 e 300, e 500 sull'indice più grande, abbiamo eseguito ripetutamente le 1.000 query con 1, 2, 4, 8, 16, 32, 50 e 100 client: un secondo di warm-up, poi quattro secondi conteggiati, tre volte ciascuno, alternando l'ordine dei due motori. Riportiamo la mediana. Il recall è stato misurato separatamente, su una sola connessione. HotKV è stato caricato su 32 connessioni in ogni esecuzione. Gli indici di Redis sono stati costruiti una sola volta, su 32 connessioni con VADD ... CAS, salvati e poi caricati per le misurazioni. Gli script e ogni prova sono nel repository del benchmark.

Risultati

Obiettivi di recall a parità

I due motori non raggiungono lo stesso recall allo stesso ef, quindi confrontiamo il throughput a obiettivi minimi di recall condivisi: per ciascun obiettivo, la profondità di ricerca misurata più veloce che lo raggiunge. Le profondità e i recall raggiunti sono nelle tabelle, perché differiscono leggermente. Si usano profondità misurate, non interpolazioni. Query al secondo su 999.000 vettori:

La latenza mediana è indicata come HotKV / Redis. Lo stesso andamento valeva per un obiettivo del 90%: 90.003 contro 7.973 query al secondo con 100 client (11,3 volte), entrambi a ef 40.

Ogni profondità di ricerca

Query al secondo su 999.000 vettori. Su 100.000 vettori l'andamento è lo stesso. Con un recall del 95% HotKV ha servito 1,5 volte le query al secondo di Redis con un client (1.816 contro 1.214) e 8,9 volte con 100 (63.247 contro 7.119).

Quanta parte di questo è rumore

Ogni cella è la mediana di tre prove. Metà delle celle aveva una dispersione tra la prova più bassa e quella più alta pari o inferiore all'1,3% della mediana, nove su dieci pari o inferiore al 7%, e la più ampia è stata del 26% (Redis, 100.000 vettori, ef 300, 50 client). Il report elenca ogni prova.

Il recall è stato misurato una volta per ogni costruzione dell'indice. Tre costruzioni indipendenti di ciascun motore su 100.000 vettori differivano fino a 0,013 alla stessa profondità, quindi il recall più alto di HotKV è evidente fino a ef 300 ed entra nella variazione tra una costruzione e l'altra a ef 500 sull'indice più piccolo.

Caricamento e memoria

Caricando su 32 connessioni ciascuno, HotKV ha impiegato 188 secondi per i 999.000 vettori (5.325 al secondo) e Redis 935 secondi (1.069 al secondo), incluso il tempo che il generatore di carico ha speso per formattare ogni vettore. Su 100.000 vettori sono stati 15 secondi contro 57. In una verifica su 20.000 vettori Redis ha caricato più velocemente con CAS che senza (2.279 contro 1.488 vettori al secondo), quindi lo abbiamo usato. Il caricamento di Redis è avvenuto in un passaggio precedente, con Redis vincolato a quattro vCPU mentre sulla macchina giravano altri controlli; HotKV ha caricato da solo su 128 vCPU. Il tempo di caricamento di Redis è quindi un limite inferiore della sua velocità, non un confronto a pari condizioni.

Dopo il caricamento di 999.000 vettori il processo HotKV occupava 6,77 GB e il processo Redis 7,01 GB.

Cosa limita Redis 8.10.2 in questo caso

I vector set di Redis eseguono ogni ricerca su un thread dedicato, ma il codice HNSW ha un numero fisso di slot di thread (32, stabilito quando Redis viene compilato), e i vettori vengono aggiunti sul thread principale. Nelle nostre esecuzioni, da 32 client in su, Redis ha tenuto occupate da 6 a 30 delle vCPU della macchina e il suo throughput si era stabilizzato. HotKV ha tenuto occupate circa 92 vCPU con 100 client a ef 80 e il suo throughput era ancora in crescita. È così che si comporta ciascun motore su questa macchina, non qualcosa che il benchmark ha configurato.

Limitazioni

Queste sono misurazioni di HotKV Ltd sulle versioni e sulla configurazione indicate sopra, non un'affermazione su ogni deployment di Redis.

La configurazione del test

• Una build di sviluppo. Il commit c8dafd37 è una build di sviluppo, non una release.
• Un dataset, una macchina. Embedding di OpenAI a 1.536 dimensioni, solo i primi 10 risultati, float32, coseno. Altre dimensioni, altri dati o altro hardware possono dare rapporti diversi.
• Il client condivide la macchina. I generatori di carico giravano su vCPU separate ma condividevano con i server il sistema di memoria e la cache di ultimo livello.
• Persistenza disattivata. Nessuno dei due server ha scritto snapshot né un append-only file.

Cosa non è stato misurato

• La modalità a 8 bit di Redis. Redis memorizza per impostazione predefinita vettori quantizzati a 8 bit, il che usa meno memoria. Abbiamo confrontato float32 con float32.
• Il Query Engine di Redis. Redis offre la ricerca vettoriale anche tramite FT.CREATE e FT.SEARCH. Abbiamo testato solo i vector set, quindi i risultati non dicono nulla sul Query Engine.
• Caricamento e ricaricamento di Redis. Gli indici di Redis sono stati costruiti in un'esecuzione precedente con Redis vincolato a quattro vCPU, salvati e ricaricati per le misurazioni, quindi i tempi di caricamento di Redis sono un limite inferiore e non sono confrontabili a pari condizioni con quelli di HotKV. La ricerca su un indice ricaricato è stata circa il 10 per cento più lenta che su uno appena costruito in un controllo su 20.000 vettori, perciò le cifre delle query di Redis potrebbero essere basse di circa altrettanto.

Provalo tu stesso

La ricerca vettoriale è integrata nello stesso server della cache dei prompt di HotKV, e lo stesso indice vettoriale sostiene la sua cache semantica e la memoria degli agenti. La ricerca vettoriale è inclusa in ogni piano HotKV Cloud. La cache dei prompt, la cache semantica e la memoria degli agenti sono disponibili con il piano Performance e superiori. Inizia su HotKV Cloud, oppure contatta le vendite per eseguire il benchmark con i tuoi embedding.