Vector Lakebase 把 Milvus 變成 AI 資料平台
5 種能力看 Zilliz Vector Lakebase 如何把即時服務、探索與批次分析整合到同一個 AI 資料底座。
Zilliz 的 Vector Lakebase 把向量搜尋、探索和批次分析放在同一個資料底座上，讓 AI 團隊少搬資料、多做決策。
這次 public preview 的重點，不是再多一個向量資料庫，而是把原本分散的 serving、discovery、analytics 收進同一套架構。對需要在成本、延遲和資料流轉之間取捨的團隊來說，讀完這 5 項後，你大致就能判斷自己該選哪種層級、哪種工作模式，避免把時間花在重複搬運向量資料上。
| 項目 | 延遲 | QPS | Recall | 儲存／運算模型 |
|---|---|---|---|---|
| Performance-Optimized | 單位數毫秒 | 1,000 以上 | 95-98%，可調到 99%+ | In-memory |
| Capacity-Optimized | 100ms 以下 | 100-500 | 95-98%，可調到 99%+ | Memory + NVMe |
| Tiered-Storage | 約 100ms | 10-50 | 95-98%，可調到 99%+ | Memory + NVMe + object storage |
| On-Demand Search | 依工作負載而定 | 依工作負載而定 | 未公開 | Compute 啟用時才付費 |
1. 三層即時服務，先把成本和速度分開看
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Vector Lakebase 仍然是以生產級向量搜尋為核心，但 Zilliz 把它拆成三個 serving 層，讓團隊按延遲與吞吐量選配置。這比單一規格更實際，因為不是每個 AI 應用都需要同樣的熱資料和同樣的速度。
如果你在做 agent memory、RAG 或面向使用者的語意搜尋，這種分層很有用。熱查詢可以買速度，穩定流量可以換成本，資料團隊不用為了少數高峰時段一直維持最高規格。
- Performance-Optimized：1,000+ QPS，單位數毫秒延遲
- Capacity-Optimized：100-500 QPS，100ms 以下延遲
- Tiered-Storage：10-50 QPS，約 100ms 延遲
2. 零拷貝語意資料平面，少一次搬運就少一次延遲
Zilliz 的主張很直接：不要把數十億筆向量在不同系統間來回複製。Vector Lakebase 讓 serving、探索和分析都對同一份邏輯資料操作，底層則共享 lake-native storage，減少多套管線之間的同步成本。
這種設計最有感的地方，是縮短從資料進入到模型改善的迴圈。同一份資料可以同時支援 production query、探索式分析和訓練資料準備，不必先 ETL 到另一個平台再重做一次。
- 一份邏輯資料，三種工作模式共用
- 共享 lake-native storage
- 適合 gigabytes 到 petabytes 規模
3. On-Demand Search，讓間歇性工作不用常駐開機
On-Demand Search 是這次最偏成本控制的功能。Zilliz 說，團隊可以直接在外部 data lake 上做搜尋，只在 object storage 和實際啟用的 compute 上付費，不必為了偶爾的查詢把基礎設施長時間維持在待命狀態。
對流量不均的工作很合適，例如離線 enrichment、一次性調查、夜間批次任務，或是需要查但不想搬資料的情境。這也讓資料可以留在原本的位置，平台只負責把搜尋能力接上去。
適用情境：ad hoc semantic search、overnight deduplication、periodic embedding refresh、lake query without data copies4. Interactive Discovery，把探索留在同一套底座上
Interactive Discovery 介於 production serving 和 offline analytics 之間。它的價值不是再做一個分析工具，而是讓資料科學家和 ML 工程師可以直接在同一份向量資料上做探索，不必先搬到另一個 stack。
如果團隊常要看 cluster 分布、比較 retrieval 行為，或在 retrain 前先找弱標籤，這個模式會比傳統切資料、匯出、再分析的流程順很多。探索和服務共用底座，也比較不容易出現資料版本不一致。
- 適合互動式分析
- 與 production search 使用同一份資料
- 減少分析團隊與 serving 團隊之間的交接成本
5. Batch Analytics，補上 AI 迴圈裡的資料整理段
Zilliz 把 AI 系統描述成一個循環：服務、學習、改善資料，再回到服務。Batch Analytics 就是負責「改善資料」的那一段，尤其適合處理大量語料、準備訓練集，或在規模上做離線加工。
真正的意義在於，批次作業不必再依賴另一套資料管線。若同一批向量同時支援即時搜尋與離線處理，團隊就能把 feedback loop 收得更緊，少做重複同步，也少一層故障點。
- Semantic deduplication
- Multi-petabyte training-data prep
- 大型離線處理可直接跑在同一底座上
怎麼挑，才不會買錯層級
如果你的應用吃的是即時回應和高查詢量，先看 Performance-Optimized。若你想在成本和反應速度之間找平衡，Capacity-Optimized 通常比較好落地；流量穩定、比較在意儲存成本時，Tiered-Storage 會更合理。
On-Demand Search 適合尖峰不固定的工作，Interactive Discovery 適合資料科學和分析團隊，Batch Analytics 則適合想把 serve-learn-improve 迴圈留在同一平台的 AI 團隊。多數情況下，真正該問的不是哪一項最強，而是哪一種組合能少掉最多重複基礎設施。