IBM 單機塞進 1000 億向量

IBM 這次丟出的數字很硬。單一伺服器，1000 億向量，平均查詢延遲 694 毫秒，召回率超過 90%。說真的，這不是一般簡報會拿來唬人的那種規格。

重點不只在向量數字大。它想做的是把 RAG 的一部分，直接塞進儲存層。講白了，就是少一層中介，少一些伺服器，也少一些整合地獄。

這個原型來自 IBM Research 的 content-aware storage，簡稱 CAS。它把文件切塊、嵌入、索引，盡量往儲存系統裡面放。這種做法，對企業資料量大的場景特別有感。

IBM 到底做了什麼

CAS 的核心概念很直接。資料進到儲存系統後，不是先丟到外部向量資料庫，再走一輪複雜管線。它想在儲存層就把文件轉成向量，讓檢索更靠近資料本體。

IBM 說，單一文件切成多段後，可能變成數百個向量。企業一旦有數十萬份文件，向量數量就會爆開。這時候還靠傳統 scale-out 架構，就會開始燒錢。

這套原型用了分層索引、GPU 加速，還把查詢運算和儲存拆開。硬體部分，IBM 是跟 Samsung Semiconductor 和 NVIDIA 合作，跑在 IBM Storage Scale System 6000 上。

• 向量規模：1000 億
• 向量維度：384，full precision float
• 儲存占用：153 TiB
• 平均查詢延遲：694 毫秒
• 召回率：超過 90%
• 建索引硬體：6 張 NVIDIA H200 GPU

為什麼 RAG 一直卡在儲存

現在很多企業做 AI，第一個想到的就是 RAG。原因很簡單。你不用把所有內部文件重新訓練進模型。你只要把文件嵌入後存起來，查詢時抓相關片段就好。

問題是，資料一大，這套流程就開始變重。索引要時間，重建索引更花時間。等你把資料、向量庫、搜尋層、模型服務全部串好，維運成本也跟著上來。

IBM 的說法是，現在很多向量資料庫要靠數十台，甚至數百台伺服器，才撐得住十億級向量。這對雲端預算很不友善。對內部 IT 團隊來說，也很像在養一隻越長越大的怪獸。

IBM 想把更多工作往儲存層下放，再用 GPU 做最吃重的部分。它說，如果只用 2-socket Intel CPU，建索引大概要 120 天。換成 6 張 NVIDIA H200 GPU，時間降到 4 天。前面還要先花 9 天做載入和分割。

• 傳統向量資料庫常要橫向擴到數十到數百台
• IBM 說 CPU 建索引要約 120 天
• 6 張 NVIDIA H200 GPU 可壓到 4 天
• 資料載入與分割還要 9 天

IBM 高層想講的故事

IBM 這次不是只在秀硬體數字。它也在講企業價值。IBM Storage GM Sam Werner 的意思很明白。很多文件早就躺在儲存系統裡，只是企業一直沒把它們吃乾抹淨。

Sam Werner 說：「Enterprises can derive unprecedented insights from all of their documents in storage systems.」這句話很像行銷稿，但意思很實際。資料都在那裡了，為什麼還要多搬一層？

IBM Storage CTO Vincent Hsu 則把焦點放在基礎設施。企業資料集變大很快，不能等到最後才想擴充策略。Daniel Waddington 也提到維運問題。系統不只要跑得動，還要能持續更新。

“Enterprises can derive unprecedented insights from all of their documents in storage systems,” said Sam Werner, GM IBM Storage.

IBM 還放了一句很直白的說法。它說安全性已經內建在向量資料庫裡，現在要做的是在不拉高基礎設施 footprint 的前提下擴大規模。這句話很像賣點，但也很像企業真實痛點。

跟一般做法比，差在哪

現在多數 RAG 架構都很碎。資料進來先做 ingestion，再丟向量資料庫，旁邊還有物件儲存、快取、模型服務。每一層都能出問題。每一層都要維運。

IBM 想做的是把這些層壓扁。儲存不再只是放資料。它也要參與檢索。這種設計很像把倉庫直接改造成半個搜尋引擎。

從數字看，IBM 這次的 demo 已經不是小打小鬧。1000 億向量、694 毫秒、90% 以上召回率，這組數字至少證明一件事。向量檢索的戰場，已經從「能不能做」變成「怎麼做得划算」。

• 一般大型向量 DB：十億級向量，常要數十到數百台
• IBM CAS 原型：單機 1000 億向量
• 常見 CPU 索引：可能拖到數月
• IBM GPU 索引：4 天完成，前置載入 9 天
• 傳統 RAG：切成多層管線
• IBM CAS：更多流程放進儲存層

IBM 和 NVIDIA 也在推 cuVS 相關的向量索引工作。它們的目標很明確。1000 億以上向量，索引時間壓到 1 天內，載入時間從 9 天壓到 1 天，搜尋延遲往 50 到 100 毫秒靠近，召回率維持 90%。

這組目標很誠實。它沒有說要把一切變魔法。它只是在告訴你，瓶頸在哪裡。現在不是向量檢索能不能用。是它能不能在企業裡面活得久、活得便宜。

這波對產業代表什麼

這件事不只是在比誰能塞更多向量。它也在改寫儲存廠商的角色。以前大家談 AI 基礎設施，主角常是 GPU、模型、API、向量資料庫。儲存廠商常站在後面。

現在 IBM 想把自己往前推。它的邏輯是，既然企業資料本來就放在儲存系統，那檢索也可以從那裡開始。這對有大量內部文件的公司，像金融、製造、醫療、法務，都很有吸引力。

我覺得這也會逼其他廠商重新想架構。像 Pinecone、Weaviate、Milvus 這類向量資料庫，強項還是在搜尋與索引。IBM 走的是另一條路，直接把儲存層拉進來打。

這裡的競爭點很清楚。不是誰的 ANN 演算法名字比較炫。是誰能把整體成本壓下來，還能維持可維運性。

如果你看企業採購，這件事更現實。很多團隊不是買不起 GPU，而是養不起一整套分散式檢索堆疊。少一層服務，就少一份故障點。少一份故障點，就少一次半夜被叫醒。

接下來該看什麼

IBM 這次的 demo，最有意思的地方不是 1000 億這個數字本身。是它把「向量檢索」從獨立服務，往儲存系統裡面推了一步。這件事如果做順，企業 RAG 的架構會簡單很多。

但我也不會把它說得太神。694 毫秒平均延遲，對某些即時互動場景還是偏慢。它比較像大規模企業檢索的工程解，而不是聊天機器人秒回的理想答案。

接下來最該盯的，是 IBM 能不能把索引時間從 4 天再壓下去，還有搜尋延遲能不能往 100 毫秒內靠攏。如果做得到，這套 CAS 才真的有機會進到正式部署清單。

我的判斷很直接。下一波企業 RAG 競爭，不會只看誰的 LLM 比較會講。會看誰能把資料、索引、儲存、GPU 串得更省錢。你如果正在規劃內部知識庫，現在就該問一句：你要再養一個向量叢集，還是讓儲存系統多做一點事？