吞吐量正面对比
在 HotKV Ltd 于一个云实例上对 HotKV、Redis、Valkey 和 Dragonfly 进行的测试中，HotKV 在 12 条命令中的 11 条上取得了最高的中位吞吐量。在 PING 上，Dragonfly 高出 0.6%，这在负载生成器的限制范围之内，因此我们视为打平。这些结果仅适用于所测试的构建版本和设置。请参阅下方的测试方法。
- 同一台机器每个服务器都在同一实例上运行，一次只运行一个。
- 独立的负载生成器由专用客户端机器施加负载，绝不使用服务器自身的机器。
- 相同设置每个服务器都使用相同的线程数，未做其他调优。
- 3 次运行的中位数每条命令运行 3 次。展示中位数。
- 标注限制由网络或负载生成器决定的结果均已标注。
- 完整方法所有设置、限制和注意事项均在结果下方详细列出。
- CPU:
- AMD EPYC 9V45 (Turin)
- vCPU:
- 160
- 架构:
- x86_64
- 内存:
- 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 时 CPU 达到 86%，测试 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 在固定到 4 个 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，余弦相似度，两者均使用 M=16、ef_construction=200 的 HNSW，两者均为 float32（Redis NOQUANT）。召回率为相对于精确暴力搜索结果的 recall@10。在 Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs 上取 3 次运行的中位数。服务器共享 128 个 vCPU，负载生成器运行在另外 32 个 vCPU 上，对两者使用相同的客户端代码。
数据集：Kumar Shivendu and Nirant Kasliwal 提供的 dbpedia-entities-openai-1M 嵌入（OpenAI text-embedding-ada-002，1,536 维），采用 MIT 许可，另加 1,000 条留出查询。完整方法、脚本和原始结果。 测量日期：2026年10月14日。