凌晨三點,新部署的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的冷啟動則因層級而異。模式一致:工作被推遲了,總得有人買單。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.