向量索引冷啟動：為什么首次查詢要8秒

凌晨三點，新部署的RAG服務上線。測試全綠，p99檢索耗時40毫秒，儀表盤一片健康。然后第一個用戶查詢來了——8秒后才返回。第二個同樣查詢：38毫秒。代碼沒變，索引沒變，查詢語句一模一樣。Grafana上每次滾動部署都出現一道尖刺，值班工程師聳聳肩說"反正很快恢復"。

這不是"很快恢復"能糊弄過去的事。這道尖刺是索引在逐頁從磁盤讀取數據，用戶就盯著加載動畫干等。安靜的早晨是一個 frustrated 用戶，黑五促銷時就是幾千個用戶同時命中剛重啟的Pod，排隊等待同樣的頁錯誤。

這篇文章拆解冷啟動稅的本質：HNSW索引為何等到首次查詢才真正加載，pgvector、Qdrant、Pinecone的真實數據表現，以及四種預熱模式如何讓用戶永遠看不到這道尖刺。

HNSW（分層可導航小世界）索引本質上是一張圖。每個向量是一個節點，節點在多層有鄰居鏈接，查詢從頂層入口點逐層向下遍歷，k=10搜索通常訪問幾百個節點。圖數據以內存映射文件或分段形式存于磁盤，向量數據通常緊鄰圖存儲。

進程啟動時不會把整個索引讀入內存。它打開文件，請求內核做內存映射，啟動工作就此結束。頁面只在被訪問時才讀入，而"被訪問"的時刻就是首次查詢。

首次查詢遍歷圖結構。每條鄰居指針觸發一次頁錯誤，每個向量評分再觸發向量數據的頁錯誤。現代NVMe很快，但頁錯誤仍需50-150微秒（典型NVMe隨機讀取延遲），單次HNSW搜索可能觸及數百個頁面：圖頁面、向量頁面、載荷頁面。簡單乘法：幾百次頁錯誤×約100微秒，僅查找就耗去數十毫秒，再加上實際計算和嵌入端的額外冷路徑開銷。

這是單次查詢的賬。首次查詢還要支付幾項一次性設置成本：線程池預熱、JIT內核選擇、分配器初始化。單獨看都不貴，堆在同一條請求上就難看了。

標題里的8秒是上限值，來自500萬向量pgvector索引配合冷頁緩存和較慢SATA SSD的場景；下一節的基準測試在更快NVMe上復現了4.8秒的數據點。新鮮容器加冷頁緩存，首次查詢通常落在3-10秒區間，取決于磁盤速度和數據集規模。Qdrant的磁盤分段架構文檔顯示類似區間，Pinecone Serverless的冷啟動則因層級而異。模式一致：工作被推遲了，總得有人買單。