正面對決的吞吐量
在 HotKV Ltd 對 HotKV、Redis、Valkey 與 Dragonfly 於同一個雲端執行個體上所做的測試中，HotKV 在 12 個指令中的 11 個記錄到最高的中位數吞吐量。在 PING 上，Dragonfly 的測量值高出 0.6%，但這在負載產生器的上限範圍內，因此我們視為持平。這些結果僅適用於所測試的版本與設定。請參閱下方的測試方法。
- 同一台機器每台伺服器都在同一個執行個體上，一次運行一台。
- 獨立的負載產生器負載由專用的用戶端機器產生，絕不由伺服器本身產生。
- 相同的設定每台伺服器的執行緒數相同，且不做其他調校。
- 3 次執行的中位數每個指令執行三次，顯示中位數。
- 標示限制受網路或負載產生器所限的結果會加以標註。
- 完整的方法每項設定、限制與但書，都寫在結果下方。
- CPU:
- AMD EPYC 9V45 (Turin)
- vCPU:
- 160
- 架構:
- x86_64
- RAM:
- 314.8 GB
- 網路:
- 輸出 78 Gbps，輸入 132+ Gbps
- 執行緒:
- 每台伺服器 160 個（Redis 為 128，即其上限）
- 測量於:
- 2026年10月9日
每秒操作數，取 3 次執行的中位數。每個長條都以該指令中最快的伺服器為基準按比例繪製。
- 該指令的最高結果。
- 受網路限制：此結果受執行個體的網路所限，因此伺服器本身的上限更高。
- 受負載產生器限制：負載產生器機器的 CPU 使用率超過 85%，因此這是它們的上限，而不是伺服器的上限。
- Azure 會對輸出流量計量：以三台用戶端機器進行 iperf3 測量，輸出為 78 Gbps，輸入至少 132 Gbps。GET 與 MGET 會將值送出。HotKV 的 GET 用掉輸出上限的 88%，因此那是由執行個體決定的下限，而不是伺服器的上限，而 MGET 為 83%，也相去不遠。Dragonfly 的讀取最多用掉上限的 44%。
- 寫入屬於輸入流量，因此寫入結果反映的是伺服器本身的數字。最吃重的 SETNX 約 106 Gbps，用掉輸入上限的約 80%，因此請將 HotKV 的寫入數字視為略偏保守的下限。
- 在 PING 上，負載產生器在 HotKV 時達到 86% 的 CPU，在 Dragonfly 時為 82%。兩者之間 0.6% 的差距落在該上限之內，因此 PING 視為持平。
Azure D160alds_v7 的精確數字
| 指令 | HotKV | Redis | Valkey | Dragonfly | HotKV 對 Redis | HotKV 對 Valkey | HotKV 對 Dragonfly |
|---|---|---|---|---|---|---|---|
| SET | 最高： 50,480,621 | 3,409,794 | 2,882,486 | 15,042,258 | 14.80x | 17.51x | 3.36x |
| GET | 最高： 36,643,656(受網路限制) | 1,132,934 | 1,631,573 | 13,446,228 | 32.34x | 22.46x | 2.73x |
| MGET | 最高： 4,617,382 | 277,956 | 536,872 | 2,348,137 | 16.61x | 8.60x | 1.97x |
| SETNX | 最高： 55,333,360 | 1,397,967 | 1,860,919 | 14,442,422 | 39.58x | 29.73x | 3.83x |
| APPEND | 最高： 25,050,648 | 1,530,680 | 1,290,421 | 8,858,165 | 16.37x | 19.41x | 2.83x |
| INCR | 最高： 90,783,545 | 2,104,069 | 1,918,073 | 20,603,259 | 43.15x | 47.33x | 4.41x |
| LPUSH | 最高： 31,617,779 | 1,247,914 | 842,106 | 10,579,641 | 25.34x | 37.55x | 2.99x |
| RPUSH | 最高： 43,776,706 | 628,324 | 878,476 | 11,014,977 | 69.67x | 49.83x | 3.97x |
| SADD | 最高： 50,626,647 | 2,053,737 | 894,438 | 12,044,417 | 24.65x | 56.60x | 4.20x |
| HSET | 最高： 28,997,514 | 536,527 | 781,768 | 9,797,534 | 54.05x | 37.09x | 2.96x |
| MSET | 最高： 11,275,369 | 378,641 | 464,801 | 2,941,342 | 29.78x | 24.26x | 3.83x |
| PING | 125,232,520(受負載產生器限制) | 3,235,600 | 3,480,446 | 最高： 126,033,542 | 38.70x | 35.98x | 0.99x |
在我們的測試中比 Redis 8 向量集合更快
我們將相同的 OpenAI 嵌入載入 HotKV 與 Redis 8，在同一台機器上，以 1 至 100 個同時連線的用戶端，對兩者執行相同的 1,000 個查詢。兩者都儲存完整精度的向量，且索引設定相同。
相同召回率下的每秒查詢數
兩個引擎都儲存完整精度的 float32 向量。載入 999,000 個向量後，HotKV 行程占用 6.77 GB，Redis 占用 7.01 GB。
未測量的項目：Redis 預設的 8 位元量化模式、Redis Query Engine、其他資料集與其他硬體。所測的 HotKV 建置為尚未發布的開發版本。Redis 載入時固定使用四個 vCPU，並在重新載入的索引上搜尋（詳見文章）。
完整數據：999,000 個向量，50 個用戶端
| ef | HotKV 召回率 | Redis 召回率 | HotKV 查詢/秒 | Redis 查詢/秒 | 比率 |
|---|---|---|---|---|---|
| 40 | 0.940 | 0.923 | 63,897 | 8,061 | 7.9x |
| 80 | 0.970 | 0.962 | 37,508 | 6,825 | 5.5x |
| 150 | 0.987 | 0.980 | 21,912 | 5,241 | 4.2x |
| 300 | 0.993 | 0.990 | 12,393 | 3,454 | 3.6x |
| 500 | 0.997 | 0.994 | 7,688 | 2,483 | 3.1x |
HotKV 建置 c8dafd37 與 Redis 8.10.2，餘弦相似度，兩者皆使用 HNSW，M=16、ef_construction=200，兩者皆為 float32（Redis NOQUANT）。召回率為相對於精確暴力搜尋結果的 recall@10。為 3 次執行的中位數，於 Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs 上進行。兩台伺服器共用 128 個 vCPU，負載產生器則在另外 32 個上運行，兩者使用相同的用戶端程式碼。
資料集：Kumar Shivendu and Nirant Kasliwal 的 dbpedia-entities-openai-1M 嵌入（OpenAI text-embedding-ada-002，1,536 維），授權為 MIT，另加 1,000 個保留的查詢。完整方法、腳本與原始結果。 測量日期：2026年10月14日。