[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-vdbbench-cost-benchmark-vector-databases-zh":3,"article-related-vdbbench-cost-benchmark-vector-databases-zh":30,"series-tools-dda641de-50ed-419d-81dc-d8f8edc33084":75},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":23,"views":27,"created_at":28,"published_at":29,"topic_cluster_id":11},"dda641de-50ed-419d-81dc-d8f8edc33084","vdbbench-cost-benchmark-vector-databases-zh","VDBBench 把向量資料庫比法改掉","\u003Cp data-speakable=\"summary\">以前我只比向量資料庫誰快，現在我會一起看它到底燒多少錢。\u003C\u002Fp>\u003Cp>我用向量資料庫做 \u003Ca href=\"\u002Ftag\u002Fbenchmark\">benchmark\u003C\u002Fa> 有一陣子了。流程都差不多：起兩套系統、丟同一份 workload、盯著 latency 圖看半天，最後還是卡在一個很煩的問題：這結果到底值多少錢？有些系統紙面上很快，但你得給它更多記憶體、更多副本、更多調校，還要多養幾台機器。另一套看起來慢一點，算進雲端帳單後反而比較正常。這種落差很常見，benchmark 告訴我誰跑得快，卻沒告訴我誰比較適合真的上線。\u003C\u002Fp>\u003Cp>這次我注意到 \u003Ca href=\"https:\u002F\u002Fwww.hpcwire.com\u002Fbigdatawire\u002Fthis-just-in\u002Fzilliz-expands-vdbbench-with-cost-benchmarking-for-vector-databases\u002F\">HPCwire \u002F BigDATAwire 上的 Zilliz VDBBench 更新\u003C\u002Fa>，就是因為它把\u003Ca href=\"\u002Fnews\u002Fzilliz-cost-aware-vdbbench-benchmark-zh\">成本\u003C\u002Fa>拉進來了。VDBBench 是 Zilliz 做的開源、偏中立的向量資料庫 benchmark，Zilliz 也是 \u003Ca href=\"https:\u002F\u002Fmilvus.io\u002F\">Milvus\u003C\u002Fa> 的背後團隊。這次更新\u003Ca href=\"\u002Fnews\u002Fzilliz-cost-aware-scoring-vdbbench-zh\">把成本\u003C\u002Fa>變成第一級指標，這種看起來很無聊、但其實很實用的改動，我一向很買單。\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fzilliztech\u002FVDBBench\">VDBBench repo\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.zilliz.com\u002F\">Zilliz\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fqdrant.tech\u002F\">Qdrant\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fweaviate.io\u002F\">Weaviate\u003C\u002Fa> 這些工具我都看過，最後還是覺得：只看速度，根本不夠。\u003C\u002Fp>\u003Ch2>只看速度，等於只看一半\u003C\u002Fh2>\u003Cblockquote>adding cost as a first-class benchmark dimension\u003C\u002Fblockquote>\u003Cp>翻譯一下就是，VDBBench 不再把效能當成單一賽跑。若我只看 throughput 或 latency，我會漏掉真正的運營成本：RAM、CPU、storage、node 數量，還有那些為了讓系統穩一點而被迫做的 overprovisioning。某個向量資料庫可能快 15%，但如果它要我多付 2 倍成本，那它不一定比較好，很多時候甚至更糟。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786654993634-4al2.png\" alt=\"VDBBench 把向量資料庫比法改掉\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我之前碰過 retrieval-heavy 的專案，團隊很在意 recall 和 query latency，結果做到最後才發現，所謂「快」的方案其實要更大的機器，才能撐住我們的 SLA。圖表很好看，月費很難看。成本 benchmark 的價值，就是把這個落差直接攤開來，不讓它躲在單一指標後面。\u003C\u002Fp>\u003Cp>實操上，我現在會先把完整 runtime profile 寫下來，不只寫 search latency。我要看 instance type、memory footprint、replication、為了達標需要幾台 node。然後我比的是「每個有用結果的成本」，不是單純的每小時價格。若你的 benchmark 連這件事都表達不了，那它多半只是在幫你吵架，不是在幫你選架構。\u003C\u002Fp>\u003Cul>\u003Cli>把你真正在意的部署形狀寫進 benchmark。\u003C\u002Fli>\u003Cli>把 memory、replica、node 數一起算進去。\u003C\u002Fli>\u003Cli>用你的 embedding size、query mix、update rate 來比，不要照著 demo 走。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>中立這件事，只有在不漏算成本時才成立\u003C\u002Fh2>\u003Cp>VDBBench 主打 vendor-neutral，這點我覺得很重要，但很多人嘴上說中立，手上做的其實是產品簡報。挑一個對自己有利的 workload、把 tuning knobs 蓋起來、再把會影響帳單的東西省略掉，最後丟一張漂亮圖表。那不叫中立，那叫把 CSV 包裝成行銷。\u003C\u002Fp>\u003Cp>這次更新真正補上的，是成本這塊缺口。若 benchmark 只看速度，它很容易獎勵那些靠吃資源換表現的系統。把成本放進 scorecard 之後，事情就沒那麼好騙了。問題不再是「誰衝刺比較快」，而是「誰衝刺得快，還不會把預算吃掉」。\u003C\u002Fp>\u003Cp>我喜歡這種改法，因為它比較接近真正要上線的人在想的事。產品團隊買的從來不是單一 database，而是 database 加硬體、加 ops 時間、加 tuning 成本、加 scaling 風險。中立的 benchmark 應該幫我比較整包成本，不是只比較最漂亮的那一段。\u003C\u002Fp>\u003Cul>\u003Cli>先看 benchmark 有沒有用你會真的採用的 deployment 形狀。\u003C\u002Fli>\u003Cli>確認 memory 和 replica overhead 有沒有算進去。\u003C\u002Fli>\u003Cli>確認 workload 設定有沒有對齊你的向量尺寸、查詢比例、更新頻率。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>實操寫法很簡單：看到 benchmark 結果先懷疑，尤其是那種沒寫清楚成本公式的。若它沒算 deployment cost，就先當真實成本更高。若它沒算 tuning effort，就先當你的團隊之後要補這筆錢。若它沒算 operational complexity，就先假設 pager 會替你補課。\u003C\u002Fp>\u003Ch2>成本一進來，才知道誰真的適合你的工作負載\u003C\u002Fh2>\u003Cp>這是我最在意的地方。成本一進 benchmark，「最好」這個詞才會開始變得有意義。最好對什麼？對小資料集最好？對寫入很多的 pipeline 最好？對可以整天盯著 index 調參的團隊最好？對想把 retrieval 成本壓住、但流量又會突然暴衝的公司最好？這些答案都不一樣。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786654988740-fuf3.png\" alt=\"VDBBench 把向量資料庫比法改掉\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>向量資料庫特別容易被比歪，因為 workload 形狀一變，結果就全變。某個系統在靜態、讀多寫少的 corpus 上看起來很漂亮，但只要我加上頻繁更新、更大的 vectors、或更嚴格的 recall target，它可能就完全不是同一個東西。成本 benchmark 的價值，就是讓我可以直接說：這套 engine 不差，只是對這個預算來說不夠划算。\u003C\u002Fp>\u003Cp>我看過太多團隊因為沒有成本模型，最後買了過頭的效能。看到 latency 低，就直覺以為值得加價。偶爾值得，多數時候不值得。若你的 app 已經在 SLA 範圍內，多花一大筆錢去省 20 毫秒，通常沒人會替你加薪。成本 benchmark 會逼我在下架構決策前，先把這件事想清楚。\u003C\u002Fp>\u003Cp>實操寫法：在 benchmark 前先訂一條決策規則。像是「如果延遲改善不到 40%，我最多只願意多付 25% 成本」。這聽起來很土，但比靠感覺強太多。接著就照這條規則跑測試。\u003Ca href=\"\u002Fnews\u002Fpixel-11-launch-highlights-gemini-features-zh\">重點\u003C\u002Fa>不是選出冠軍，重點是選出一個你能在財務面前講得通的方案。\u003C\u002Fp>\u003Ch2>開源 benchmark 的價值，在於我能看懂它怎麼算錢\u003C\u002Fh2>\u003Cp>VDBBench 是開源的，這不是附註，是重點。因為只有我能看原始碼，我才知道成本是怎麼算出來的、裡面塞了哪些假設、以及它到底有沒有貼近我的環境。成本這東西很滑，今天可以指 cloud list price，明天可以指每次 query 的有效成本，後天又變成某種沒人能重現的估算值。\u003C\u002Fp>\u003Cp>我對那種只寫「cost」卻不給公式的 benchmark 一向很警覺。假設藏起來，成本就可以被講成任何樣子。開源至少讓我有機會去 audit 它的邏輯。我可以追 inputs、換成自己的雲端價格、看結果還站不站得住。這就是能拿來決策的工具，跟只能拿來欣賞的工具差很多。\u003C\u002Fp>\u003Cp>這也是為什麼 vendor-neutral 工具要有開源的底。若我能看懂 benchmark，我就能把它對回自己的部署現實。我可以 fork、可以 patch、至少可以知道它哪裡在簡化。這比看供應商簡報說自己比較便宜，因為他們挑了最有利的配置，實在多了。\u003C\u002Fp>\u003Cul>\u003Cli>先看成本公式，再決定信不信結果。\u003C\u002Fli>\u003Cli>把預設假設換成你自己的 cloud pricing。\u003C\u002Fli>\u003Cli>用你真的要買的硬體等級去跑，不要只看 demo 機器。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>實操寫法：把 benchmark code 當成架構審查的一部分。若成本模型是黑箱，就去問。若假設太泛，就改。若它根本對不上你的部署，那它不是 decision tool，它只是 demo。\u003C\u002Fp>\u003Ch2>Milvus 使用者該在意，但原因不是大家以為的那個\u003C\u002Fh2>\u003Cp>Zilliz 是 \u003Ca href=\"https:\u002F\u002Fmilvus.io\u002F\">Milvus\u003C\u002Fa> 的背後團隊，所以 Milvus 使用者當然會直接受影響。但我覺得重點不是品牌親近，而是這種做法會把整個向量資料庫生態往更誠實的評估方向推。這對所有在 \u003Ca href=\"https:\u002F\u002Fqdrant.tech\u002F\">Qdrant\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fweaviate.io\u002F\">Weaviate\u003C\u002Fa>、Milvus，或其他宣稱能扛大規模 retrieval 的系統之間做選擇的人都有幫助。\u003C\u002Fp>\u003Cp>我已經受夠那種只看誰圖表最好看的 shortlist 方式。那不是買基礎設施，那是在買簡報。benchmark 應該回答商業問題，不只是技術問題。若 VDBBench 能把成本用可重現的方式攤出來，團隊就有更好的比較基準，也比較不會被選擇性指標牽著走。\u003C\u002Fp>\u003Cp>在 AI app 裡，retrieval 成本常常是默默吃預算的那個。模型很搶戲，vector store 才是收帳單的人。若 benchmark 能讓我在真實的 spend constraints 下看出資料庫怎麼表現，我就能在 app 長大之前先做出比較穩的選擇。\u003C\u002Fp>\u003Cp>實操寫法：把 VDBBench 當成其中一個輸入，不要把它當成全部。再加上自己的 workload traces、自己的 cloud pricing、自己的 operational constraints 一起看。若你已經在用 Milvus，這次更新一樣有用，因為它讓你更容易說服自己要不要留下來，或該不該搬家。\u003C\u002Fp>\u003Ch2>我現在會先看這四個數字，再決定要不要買\u003C\u002Fh2>\u003Cp>如果我今天要重新做一套 retrieval 系統，我不會先問「哪個 database 最快」。我會先問「哪個 database 能用最低的真實成本，穩穩達到我的 SLA，而且不要太多鳥事」。所以我至少要看到四個數字：latency、recall、基礎設施成本、operational overhead。若我拿不到這四個東西放在同一張表裡，我很容易在不知不覺中做錯決定。\u003C\u002Fp>\u003Cp>這也是我覺得這次 VDBBench 更新有價值的原因。它把整個評估流程往更誠實的方向推了一點。我不需要一個會幫 engine 講好話的 benchmark，我需要的是一個會告訴我，這套系統在我真的跑起來之後，到底要付多少錢的工具。這才是它該做的事。\u003C\u002Fp>\u003Cp>我的實際規則很簡單：用你預期的 workload 去 benchmark，不要拿 blog post 裡那種好看的 workload。把 embedding dimension、update rate、query mix、target recall 都換成你自己的版本。然後看哪套系統在達標前提下花最少。若兩套 performance 差不多，就讓成本決勝；若便宜的那套需要大量 tuning，那 tuning time 也要算錢。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Vector DB benchmark decision template\n\n## Goal\nCompare vector databases by performance and real operating cost for my workload.\n\n## Workload\n- Embedding dimension: [fill in]\n- Dataset size: [fill in]\n- Query mix: [fill in]\n- Update rate: [fill in]\n- Target recall: [fill in]\n- Target latency: [fill in]\n\n## Systems under test\n- System A: [name]\n- System B: [name]\n- System C: [name]\n\n## Environment\n- Cloud\u002Fprovider: [fill in]\n- Instance type: [fill in]\n- Storage type: [fill in]\n- Replica count: [fill in]\n- Region: [fill in]\n\n## Metrics to record\n- p50 latency\n- p95 latency\n- recall@k\n- throughput\n- memory footprint\n- CPU usage\n- node count required to meet SLA\n- monthly infrastructure cost\n- tuning time required\n- operational complexity notes\n\n## Cost rule\nI will choose the system with the lowest total cost that meets my target SLA.\nIf two systems meet SLA, I will prefer the one with:\n1. Lower monthly infrastructure cost\n2. Lower tuning effort\n3. Lower operational risk\n\n## Decision table\n| System | p95 latency | recall@k | Monthly cost | Tuning effort | Notes |\n|---|---:|---:|---:|---:|---|\n| A | [fill in] | [fill in] | [fill in] | [fill in] | [fill in] |\n| B | [fill in] | [fill in] | [fill in] | [fill in] | [fill in] |\n| C | [fill in] | [fill in] | [fill in] | [fill in] | [fill in] |\n\n## Final decision\n- Winner: [fill in]\n- Why it won: [fill in]\n- What I am still unsure about: [fill in]\n- What I will verify in production: [fill in]\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這段就是我會直接複製去用的版本。它把「哪個向量資料庫比較好」這種很空的問題，改成能拿去跟團隊討論、也能拿去跟財務解釋的表格。我寧願決策流程看起來有點無聊，也不要再來一次 benchmark theater。\u003C\u002Fp>\u003Cp>來源致謝：原始更新來自 \u003Ca href=\"https:\u002F\u002Fwww.hpcwire.com\u002Fbigdatawire\u002Fthis-just-in\u002Fzilliz-expands-vdbbench-with-cost-benchmarking-for-vector-databases\u002F\">HPCwire \u002F BigDATAwire\u003C\u002Fa>。我上面的拆解、白話翻譯和模板是我自己整理的，底層消息與產品脈絡則來自 Zilliz 與原文。\u003C\u002Fp>","VDBBench 新增成本基準後，我可以把向量資料庫的比較從單看速度，改成速度加花費一起看。","www.hpcwire.com","https:\u002F\u002Fwww.hpcwire.com\u002Fbigdatawire\u002Fthis-just-in\u002Fzilliz-expands-vdbbench-with-cost-benchmarking-for-vector-databases\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786654993634-4al2.png","tools","zh","3e2d87af-b7df-4641-b685-902f1e5447c6",[17,18,19,20,21,22],"vector database","benchmarking","cost benchmarking","VDBBench","Milvus","infra cost",[24,25,26],"只看速度會漏掉真正的運營成本，成本指標能把比較拉回現實。","開源且可檢查公式的 benchmark，才值得拿來做架構決策。","把 SLA、成本、調校時間一起比，才能選出適合自己 workload 的向量資料庫。",1,"2026-08-13T21:02:47.275149+00:00","2026-08-13T21:02:47.268+00:00",{"tags":31,"relatedLang":34,"relatedPosts":38},[32],{"name":17,"slug":33},"vector-database",{"id":15,"slug":35,"title":36,"language":37},"vdbbench-cost-benchmark-vector-databases-en","VDBBench adds cost to vector DB comparisons","en",[39,45,51,57,63,69],{"id":40,"slug":41,"title":42,"cover_image":43,"image_url":43,"created_at":44,"category":13},"c55af4bc-dfce-4031-896d-89c6e76ba2c0","zilliz-cost-aware-vdbbench-benchmark-zh","Zilliz替VDBBench加入成本指標","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786653169746-xfnk.png","2026-08-13T20:32:26.208471+00:00",{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"dff07cae-e3a9-46e4-b069-c0ab3b7e18e3","zilliz-cost-aware-scoring-vdbbench-zh","VDBBench 把成本納入主指標","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786651373076-fihi.png","2026-08-13T20:02:30.752194+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"acd0364e-15cb-4a7c-b5d4-e670436ed521","pixel-11-launch-highlights-gemini-features-zh","Pixel 11 發表重點與 Gemini 新功能","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786649574526-g2vc.png","2026-08-13T19:32:23.509251+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"cad5997c-d40d-4fac-9b39-e1f86a326107","aws-continuum-turns-ai-coding-into-safer-fixes-zh","AWS Continuum 把修漏洞變安全建議","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786644251974-emsc.png","2026-08-13T18:03:30.983335+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"9cbd8e8a-df48-4e25-a950-2a8552a11c1e","open-generative-ai-github-studio-breakdown-zh","Open-Generative-AI 讓 GitHub 變工作室","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786622603725-o8ad.png","2026-08-13T12:02:47.120311+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"98e7c6dd-38f6-4740-bb79-20985bff3f9a","benchmark-scores-dont-predict-your-bill-zh","Benchmark 分數不等於帳單","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1786496578340-z656.png","2026-08-12T01:02:41.398372+00:00",[76,81,86,91,96,101,106,111,116,121],{"id":77,"slug":78,"title":79,"created_at":80},"855cd52f-6fab-46cc-a7c1-42195e8a0de4","surepath-real-time-mcp-policy-controls-zh","SurePath 推出即時 MCP 政策控管","2026-03-26T07:57:40.77233+00:00",{"id":82,"slug":83,"title":84,"created_at":85},"9b19ab54-edef-4dbd-9ce4-a51e4bae4ebb","mcp-in-2026-the-ai-tool-layer-teams-use-zh","2026 年 MCP：團隊真的在用的 AI 工具層","2026-03-26T08:01:46.589694+00:00",{"id":87,"slug":88,"title":89,"created_at":90},"af9c46c3-7a28-410b-9f04-32b3de30a68c","prompting-in-2026-what-actually-works-zh","2026 提示工程，真正有用的是什麼","2026-03-26T08:08:12.453028+00:00",{"id":92,"slug":93,"title":94,"created_at":95},"05553086-6ed0-4758-81fd-6cab24b575e0","garry-tan-open-sources-claude-code-toolkit-zh","Garry Tan 開源 Claude Code 工具包","2026-03-26T08:26:20.068737+00:00",{"id":97,"slug":98,"title":99,"created_at":100},"042a73a2-18a2-433d-9e8f-9802b9559aac","github-ai-projects-to-watch-in-2026-zh","2026 必看 20 個 GitHub AI 專案","2026-03-26T08:28:09.619964+00:00",{"id":102,"slug":103,"title":104,"created_at":105},"a5f94120-ac0d-4483-9a8b-63590071ac6a","claude-code-vs-cursor-2026-zh","Claude Code 與 Cursor 深度對比：202…","2026-03-26T13:27:14.279193+00:00",{"id":107,"slug":108,"title":109,"created_at":110},"0975afa1-e0c7-4130-a20d-d890eaed995e","practical-github-guide-learning-ml-2026-zh","2026 機器學習入門 GitHub 實用指南","2026-03-27T01:16:49.712576+00:00",{"id":112,"slug":113,"title":114,"created_at":115},"bfdb467a-290f-4a80-b3a9-6f081afb6dff","aiml-2026-student-ai-ml-lab-repo-review-zh","AIML-2026：像課綱的學生實驗 Repo","2026-03-27T01:21:51.467798+00:00",{"id":117,"slug":118,"title":119,"created_at":120},"80cabc3e-09fc-4ff5-8f07-b8d68f5ae545","ai-trending-github-repos-and-research-feeds-zh","AI Trending：把 AI 資源收成一張表","2026-03-27T01:31:35.262183+00:00",{"id":122,"slug":123,"title":124,"created_at":125},"3ce6e6e2-bac5-463e-9f8d-45caabcc61f7","awesome-ai-for-science-research-tools-map-zh","AI 科研工具清單，開始像地圖了","2026-03-27T01:46:50.521945+00:00"]