VDBBench 把成本納入主指標
Zilliz 更新開源 VDBBench，把向量資料庫評測從只看速度，改成同時看成本。這讓團隊能用每美元效能比較不同方案，也更貼近實際採購與上線需求。
Zilliz 更新了開源 VDBBench，把向量資料庫評測從只看速度，改成同時看成本。
Zilliz 這次動的是評測邏輯，不是包裝詞。VectorDBBench 原本偏重速度與吞吐，現在把成本拉進同一張表。對做 RAG、語意搜尋、推薦系統的人來說，這很實際，因為雲端帳單才是最後會被財務盯上的數字。
這次更新也很符合現在的採購現場。很多團隊在 demo 裡看到漂亮的延遲數字，到了正式上線才發現記憶體、複本、儲存和維運人力一起把費用拉高。VDBBench 把成本放進評分，等於逼大家正視「跑得快」和「跑得貴」之間的差距。
| 指標 | 更新內容 | 實際意義 |
|---|---|---|
| 評測重點 | 成本納入核心評分 | 可直接比每美元效能 |
| 專案性質 | 開源、供應商中立 | 降低單一廠商的話術偏差 |
| 主要場景 | 向量資料庫評測 | 對 RAG 與語意搜尋很有用 |
| 決策用途 | 從技術比較走向採購判斷 | 更貼近真實上線需求 |
為什麼向量資料庫不能只看速度
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
向量資料庫在 AI 堆疊裡的位置很尷尬。它常常不是最吸睛的那層，卻是最容易燒錢的那層。你可以在小測試裡看到很漂亮的 QPS，但一旦資料量放大、查詢並發升高、還要維持高可用，成本就會開始翻臉。
這也是成本評分有價值的地方。它讓團隊不只問「快不快」，而是直接問「這個速度值不值這個錢」。如果答案不漂亮，架構會議就會少掉很多自我感動。
對產品團隊來說，這件事更直接。你要的是可上線的方案，不是簡報上好看的圖。當 benchmark 開始把成本算進去，選型討論就會更接近真實世界。
- 低延遲不代表低總成本。
- 高吞吐不代表適合長期營運。
- 成本評分能把雲端、記憶體和複本差異攤開。
- 同一組資料，跑法不同，帳單也會差很多。
VDBBench 想修正什麼問題
VDBBench 的定位很清楚，就是做向量資料庫的基準測試，而且盡量保持中立。這點很重要，因為 benchmark 一旦被廠商話術帶著走，結果就只剩宣傳稿功能。開源工具至少讓大家能看方法、改參數、重跑測試。
把成本放進來之後，VDBBench 的用途也變了。以前它比較像排行榜，現在更像選型工具。平台團隊可以拿它來比預算，應用團隊可以拿它來看延遲與召回是否值得那個價錢。
這種轉向其實很符合 AI 基礎設施的現況。大家早就不太相信只講吞吐、不講花費的圖表。真正要簽約時，大家看的都是每月花多少、擴容難不難、維運會不會把工程師拖垮。
“Benchmarks should measure what users actually pay for, not just what vendors want to show,” said Zilliz founder and CEO Charles Xie.
這句話很直白，也很到位。評測如果只量速度，常常會把昂貴方案包裝得很好看。把成本拉進來後，很多看起來漂亮的數字就沒那麼神了。
這會怎麼改變供應商比較
向量資料庫的比較，從來都不是單看一個數字。兩套系統可能延遲差不多，召回也差不多，但其中一套需要更多 RAM、更多副本，或更貴的雲端配置。只看 throughput，這些差異很容易被藏起來。
成本評分的作用，就是把這些差異攤平。這對採購很重要，因為最後拿到預算的人，不會因為你的 benchmark 圖很好看就多給錢。對工程團隊來說，也能少踩一些「測得過、養不起」的坑。
如果你現在在比較方案，下面這幾個名字大概都會出現在名單上。每個產品的部署方式、定價邏輯、維運成本都不一樣，拿同一把尺量才有意義。
- Milvus：Zilliz 自家的向量資料庫，常被拿來和其他引擎一起比較。
- Pinecone：託管型方案，很多團隊會先拿它當基準。
- Weaviate：語意搜尋場景常見的比較對象。
- FAISS：研究和自建系統常用，彈性高，但整合成本也要算。
我覺得這次更新最有意思的地方，在於它把 benchmark 從「誰最快」拉回「誰最划算」。這種變化看起來不華麗，卻很接近真實世界。畢竟 AI 系統不是跑一次 demo 就結束，是真金白銀每天在花。
產業裡為什麼開始重視每美元效能
這幾年 AI 基礎設施的問題很一致。模型越來越大，資料越來越多，查詢越來越密，成本也越來越難壓。團隊一開始可能只想把功能做出來，後來就會發現，真正難的是把服務穩穩養住。
所以現在很多基礎設施工具都在往「真實工作負載」靠。大家不太想再看只適合實驗室的數字，因為那種數字對上線幫助有限。VDBBench 加入成本評分，正好踩在這個方向上。
這也提醒一件事：AI 軟體選型不能只看技術白皮書。你要看資料量、查詢型態、延遲目標、部署環境，還要看團隊有沒有能力自己維運。少掉任何一項，成本都可能失真。
接下來該怎麼用這個更新
如果你現在正在評估向量資料庫，我會建議直接改測法。把 latency、recall、throughput 和成本放在同一個 workload 裡看。不要用 1 萬筆資料的測試去推 1 億筆資料的結論，那樣很容易自欺欺人。
更實際的做法，是先定義你的上線條件，再回頭跑 benchmark。你的查詢峰值是多少，容忍延遲是多少，資料更新頻率多高，這些都要先寫清楚。只要條件不同，排名就可能整個翻盤。
我會把這次更新看成一個提醒。AI 基礎設施的評測，正在從炫技走向算帳。下一次你看到某個資料庫宣稱自己最快，先問一句：每月帳單是多少。這個問題通常比跑分更有用。