VDBBench 把向量資料庫比法改掉

以前我只比向量資料庫誰快，現在我會一起看它到底燒多少錢。

我用向量資料庫做 benchmark 有一陣子了。流程都差不多：起兩套系統、丟同一份 workload、盯著 latency 圖看半天，最後還是卡在一個很煩的問題：這結果到底值多少錢？有些系統紙面上很快，但你得給它更多記憶體、更多副本、更多調校，還要多養幾台機器。另一套看起來慢一點，算進雲端帳單後反而比較正常。這種落差很常見，benchmark 告訴我誰跑得快，卻沒告訴我誰比較適合真的上線。

這次我注意到 HPCwire / BigDATAwire 上的 Zilliz VDBBench 更新，就是因為它把成本拉進來了。VDBBench 是 Zilliz 做的開源、偏中立的向量資料庫 benchmark，Zilliz 也是 Milvus 的背後團隊。這次更新把成本變成第一級指標，這種看起來很無聊、但其實很實用的改動，我一向很買單。VDBBench repo、Zilliz、Qdrant、Weaviate 這些工具我都看過，最後還是覺得：只看速度，根本不夠。

只看速度，等於只看一半

adding cost as a first-class benchmark dimension

翻譯一下就是，VDBBench 不再把效能當成單一賽跑。若我只看 throughput 或 latency，我會漏掉真正的運營成本：RAM、CPU、storage、node 數量，還有那些為了讓系統穩一點而被迫做的 overprovisioning。某個向量資料庫可能快 15%，但如果它要我多付 2 倍成本，那它不一定比較好，很多時候甚至更糟。

我之前碰過 retrieval-heavy 的專案，團隊很在意 recall 和 query latency，結果做到最後才發現，所謂「快」的方案其實要更大的機器，才能撐住我們的 SLA。圖表很好看，月費很難看。成本 benchmark 的價值，就是把這個落差直接攤開來，不讓它躲在單一指標後面。

實操上，我現在會先把完整 runtime profile 寫下來，不只寫 search latency。我要看 instance type、memory footprint、replication、為了達標需要幾台 node。然後我比的是「每個有用結果的成本」，不是單純的每小時價格。若你的 benchmark 連這件事都表達不了，那它多半只是在幫你吵架，不是在幫你選架構。

• 把你真正在意的部署形狀寫進 benchmark。
• 把 memory、replica、node 數一起算進去。
• 用你的 embedding size、query mix、update rate 來比，不要照著 demo 走。

中立這件事，只有在不漏算成本時才成立

VDBBench 主打 vendor-neutral，這點我覺得很重要，但很多人嘴上說中立，手上做的其實是產品簡報。挑一個對自己有利的 workload、把 tuning knobs 蓋起來、再把會影響帳單的東西省略掉，最後丟一張漂亮圖表。那不叫中立，那叫把 CSV 包裝成行銷。

這次更新真正補上的，是成本這塊缺口。若 benchmark 只看速度，它很容易獎勵那些靠吃資源換表現的系統。把成本放進 scorecard 之後，事情就沒那麼好騙了。問題不再是「誰衝刺比較快」，而是「誰衝刺得快，還不會把預算吃掉」。

我喜歡這種改法，因為它比較接近真正要上線的人在想的事。產品團隊買的從來不是單一 database，而是 database 加硬體、加 ops 時間、加 tuning 成本、加 scaling 風險。中立的 benchmark 應該幫我比較整包成本，不是只比較最漂亮的那一段。

• 先看 benchmark 有沒有用你會真的採用的 deployment 形狀。
• 確認 memory 和 replica overhead 有沒有算進去。
• 確認 workload 設定有沒有對齊你的向量尺寸、查詢比例、更新頻率。

實操寫法很簡單：看到 benchmark 結果先懷疑，尤其是那種沒寫清楚成本公式的。若它沒算 deployment cost，就先當真實成本更高。若它沒算 tuning effort，就先當你的團隊之後要補這筆錢。若它沒算 operational complexity，就先假設 pager 會替你補課。

成本一進來，才知道誰真的適合你的工作負載

這是我最在意的地方。成本一進 benchmark，「最好」這個詞才會開始變得有意義。最好對什麼？對小資料集最好？對寫入很多的 pipeline 最好？對可以整天盯著 index 調參的團隊最好？對想把 retrieval 成本壓住、但流量又會突然暴衝的公司最好？這些答案都不一樣。

向量資料庫特別容易被比歪，因為 workload 形狀一變，結果就全變。某個系統在靜態、讀多寫少的 corpus 上看起來很漂亮，但只要我加上頻繁更新、更大的 vectors、或更嚴格的 recall target，它可能就完全不是同一個東西。成本 benchmark 的價值，就是讓我可以直接說：這套 engine 不差，只是對這個預算來說不夠划算。

我看過太多團隊因為沒有成本模型，最後買了過頭的效能。看到 latency 低，就直覺以為值得加價。偶爾值得，多數時候不值得。若你的 app 已經在 SLA 範圍內，多花一大筆錢去省 20 毫秒，通常沒人會替你加薪。成本 benchmark 會逼我在下架構決策前，先把這件事想清楚。

實操寫法：在 benchmark 前先訂一條決策規則。像是「如果延遲改善不到 40%，我最多只願意多付 25% 成本」。這聽起來很土，但比靠感覺強太多。接著就照這條規則跑測試。重點不是選出冠軍，重點是選出一個你能在財務面前講得通的方案。

開源 benchmark 的價值，在於我能看懂它怎麼算錢

VDBBench 是開源的，這不是附註，是重點。因為只有我能看原始碼，我才知道成本是怎麼算出來的、裡面塞了哪些假設、以及它到底有沒有貼近我的環境。成本這東西很滑，今天可以指 cloud list price，明天可以指每次 query 的有效成本，後天又變成某種沒人能重現的估算值。

我對那種只寫「cost」卻不給公式的 benchmark 一向很警覺。假設藏起來，成本就可以被講成任何樣子。開源至少讓我有機會去 audit 它的邏輯。我可以追 inputs、換成自己的雲端價格、看結果還站不站得住。這就是能拿來決策的工具，跟只能拿來欣賞的工具差很多。

這也是為什麼 vendor-neutral 工具要有開源的底。若我能看懂 benchmark，我就能把它對回自己的部署現實。我可以 fork、可以 patch、至少可以知道它哪裡在簡化。這比看供應商簡報說自己比較便宜，因為他們挑了最有利的配置，實在多了。

• 先看成本公式，再決定信不信結果。
• 把預設假設換成你自己的 cloud pricing。
• 用你真的要買的硬體等級去跑，不要只看 demo 機器。

實操寫法：把 benchmark code 當成架構審查的一部分。若成本模型是黑箱，就去問。若假設太泛，就改。若它根本對不上你的部署，那它不是 decision tool，它只是 demo。

Milvus 使用者該在意，但原因不是大家以為的那個

Zilliz 是 Milvus 的背後團隊，所以 Milvus 使用者當然會直接受影響。但我覺得重點不是品牌親近，而是這種做法會把整個向量資料庫生態往更誠實的評估方向推。這對所有在 Qdrant、Weaviate、Milvus，或其他宣稱能扛大規模 retrieval 的系統之間做選擇的人都有幫助。

我已經受夠那種只看誰圖表最好看的 shortlist 方式。那不是買基礎設施，那是在買簡報。benchmark 應該回答商業問題，不只是技術問題。若 VDBBench 能把成本用可重現的方式攤出來，團隊就有更好的比較基準，也比較不會被選擇性指標牽著走。

在 AI app 裡，retrieval 成本常常是默默吃預算的那個。模型很搶戲，vector store 才是收帳單的人。若 benchmark 能讓我在真實的 spend constraints 下看出資料庫怎麼表現，我就能在 app 長大之前先做出比較穩的選擇。

實操寫法：把 VDBBench 當成其中一個輸入，不要把它當成全部。再加上自己的 workload traces、自己的 cloud pricing、自己的 operational constraints 一起看。若你已經在用 Milvus，這次更新一樣有用，因為它讓你更容易說服自己要不要留下來，或該不該搬家。

我現在會先看這四個數字，再決定要不要買

如果我今天要重新做一套 retrieval 系統，我不會先問「哪個 database 最快」。我會先問「哪個 database 能用最低的真實成本，穩穩達到我的 SLA，而且不要太多鳥事」。所以我至少要看到四個數字：latency、recall、基礎設施成本、operational overhead。若我拿不到這四個東西放在同一張表裡，我很容易在不知不覺中做錯決定。

這也是我覺得這次 VDBBench 更新有價值的原因。它把整個評估流程往更誠實的方向推了一點。我不需要一個會幫 engine 講好話的 benchmark，我需要的是一個會告訴我，這套系統在我真的跑起來之後，到底要付多少錢的工具。這才是它該做的事。

我的實際規則很簡單：用你預期的 workload 去 benchmark，不要拿 blog post 裡那種好看的 workload。把 embedding dimension、update rate、query mix、target recall 都換成你自己的版本。然後看哪套系統在達標前提下花最少。若兩套 performance 差不多，就讓成本決勝；若便宜的那套需要大量 tuning，那 tuning time 也要算錢。

可抄的模板

# Vector DB benchmark decision template

## Goal
Compare vector databases by performance and real operating cost for my workload.

## Workload
- Embedding dimension: [fill in]
- Dataset size: [fill in]
- Query mix: [fill in]
- Update rate: [fill in]
- Target recall: [fill in]
- Target latency: [fill in]

## Systems under test
- System A: [name]
- System B: [name]
- System C: [name]

## Environment
- Cloud/provider: [fill in]
- Instance type: [fill in]
- Storage type: [fill in]
- Replica count: [fill in]
- Region: [fill in]

## Metrics to record
- p50 latency
- p95 latency
- recall@k
- throughput
- memory footprint
- CPU usage
- node count required to meet SLA
- monthly infrastructure cost
- tuning time required
- operational complexity notes

## Cost rule
I will choose the system with the lowest total cost that meets my target SLA.
If two systems meet SLA, I will prefer the one with:
1. Lower monthly infrastructure cost
2. Lower tuning effort
3. Lower operational risk

## Decision table
| System | p95 latency | recall@k | Monthly cost | Tuning effort | Notes |
|---|---:|---:|---:|---:|---|
| A | [fill in] | [fill in] | [fill in] | [fill in] | [fill in] |
| B | [fill in] | [fill in] | [fill in] | [fill in] | [fill in] |
| C | [fill in] | [fill in] | [fill in] | [fill in] | [fill in] |

## Final decision
- Winner: [fill in]
- Why it won: [fill in]
- What I am still unsure about: [fill in]
- What I will verify in production: [fill in]

這段就是我會直接複製去用的版本。它把「哪個向量資料庫比較好」這種很空的問題，改成能拿去跟團隊討論、也能拿去跟財務解釋的表格。我寧願決策流程看起來有點無聊，也不要再來一次 benchmark theater。

來源致謝：原始更新來自 HPCwire / BigDATAwire。我上面的拆解、白話翻譯和模板是我自己整理的，底層消息與產品脈絡則來自 Zilliz 與原文。