AI推理的規則不同：雲端儲存架構面臨代理式AI的巨大挑戰

輝達CEO黃仁勳近日宣佈，我們正進入“AI工廠”時代，全球科技經濟的主要產出不再是軟體，而是智慧。他說的沒錯。然而，當全世界都在關注GPU叢集和萬億引數模型時，一場巨大的潛危機正在AWS、Azure和Google Cloud環境的底層悄然醞釀。AI代理正在湧向你的資料基礎設施，它們將壓垮底層的儲存和資料訪問層。我們正站在AI資料海嘯的邊緣。

從簡單聊天機器人到自主多步AI代理的轉變，意味著推理不再是一個無狀態的計算問題。它成為一個大規模、不可預測且前所未有的資料問題。為人類速度應用構建的底層資料基礎設施，將難以應對接下來的變化。這是將AI從有趣的概念驗證遷移到企業級生產環境時面臨的殘酷現實。

推理是OLTP++：規劃前所未有的併發 過去20年，我們一直針對人類行為調整資料系統和儲存層。人類反應慢：點選按鈕，等待頁面載入，閱讀螢幕，30秒後可能再次點選。即使在高規模下，人類流量也遵循可預測的晝夜模式，可以快取並平均化。相比之下，AI代理不喝咖啡，也不花時間閱讀。當自主代理執行ReAct（推理與行動）迴圈時，它會在毫秒內發起查詢、獲取上下文，發現需要更多資訊，再並行發起三個查詢。現在，將這個場景乘以數千個在EC2叢集中執行的併發代理。我們的客戶親眼看到，AI推理的行為就像OLTP++：展現出前所未有的併發性、大規模讀取峰值和不可預測的訪問模式。如果你僅基於CloudWatch中管理層喜歡的平均值和歷史CPU利用率進行容量規劃，你就是在盲目飛行。你必須為突如其來的極端I/O需求高峰設計架構，因為在代理時代，峰值負載才是唯一重要的負載。

向量資料庫與RAG：設計資料路徑，而不僅僅是提示 目前，AI生態系統的焦點是提示工程和模型微調。但當你將檢索增強生成（RAG）應用從本地Jupyter筆記本遷移到AWS生產環境時，你會迅速發現一個嚴酷的現實：瓶頸不是Python，也不是LLM。瓶頸在於資料如何儲存、訪問和移動——包括索引掃描、嵌入獲取和分散-聚集延遲。當你執行像分層可導航小世界（HNSW）或帶平坦量化的倒排檔案（IVFFlat）這樣的向量相似性搜尋，並結合關係後設資料過濾時，你迫使資料訪問層執行高度複雜、記憶體密集型的操作。對於AWS託管的堆疊，你需要實現熱向量的亞毫秒讀取和隨著資料集增長到數億行時可預測的吞吐量。太多工程團隊將AWS關係型資料庫服務（RDS）的只讀副本作為主要擴充套件策略。需要明確的是：副本是最後的手段，不是戰略。更重要的是，在不解決底層儲存和資料訪問層的情況下擴充套件資料庫層，只會轉移瓶頸，而不是消除它。如果你的架構計劃歸結為“增加更多讀取器並祈禱”，那麼你離一次流量峰值導致的災難性事故只差一步之遙。你需要透過為現有應用新增無風險的向量搜尋來釋放AI創新，這要求設計一個能夠處理高維數學計算而不會崩潰的資料路徑。

AWS EBS的現實檢驗 AWS是一個卓越的平臺，彈性塊儲存（EBS）是現代雲的主力。但EBS受物理定律和雲經濟規律的約束。EBS卷依賴於突發儲存桶和嚴格的每卷IOPS和吞吐量上限。這些機制旨在保護多租戶雲環境，它們不會關心你的應用程式SLA。當AI代理失控或推理流量突然衝擊你的資料層時，它會在幾分鐘內消耗完你的EBS突發信用。一旦儲存桶耗盡，儲存效能就會急劇下降：延遲從1毫秒飆升至50毫秒，應用程式因等待儲存而停滯，應用伺服器執行緒耗盡，整個堆疊鎖定。你不能僅僅透過滑動滑塊來配置更多IOPS來解決這個問題。在某個點上，你會達到單個EC2例項及其附加儲存可物理推送的硬限制。

從AWS儲存限制中解耦 即使AWS是你的永久基地，AI推理也在重塑對企業架構的需求。推理工作負載要求極致的效能，如果你的資料架構與原生EBS SKU的硬限制緊密耦合，你就會陷入困境。要擺脫這個陷阱，你需要一個位於AWS基礎設施之上的軟體定義儲存抽象層，它能為你提供巨大的槓桿作用。透過將應用程式和資料效能與原生AWS儲存限制解耦，你可以保護應用免受EC2容量危機、IOPS價格飆升和例項型別鎖定。

唯一重要的KPI：混合負載下的p99/p999 停止關注平均延遲。平均值是我們對自己和領導層說的謊言，只是為了對基礎設施感覺更好。使用者和AI代理感受到的是異常值。如果1%的查詢耗時3秒並阻塞整個代理推理鏈，那麼2毫秒的平均延遲毫無意義。你必須將尾部延遲（p99和p999）作為硬性的釋出攔阻條件。你需要跟蹤故障發生時的尾部延遲——特別是在儲存和資料訪問層。對空閒系統進行基準測試毫無用處。你需要在真實世界的高壓力條件下測量p99：併發OLTP+推理+維護作業：當大規模批次更新或清理程序啟動時，你的向量搜尋會發生什麼？可用區之間的差異：在故障轉移事件或AWS調整你的放置組時，延遲如何惡化？自動縮放事件和快取預熱：當新的EC2節點啟動時，快取需要多長時間預熱，儲存層在此期間會受到多大影響？如果你的平臺無法在這些混合負載條件下保持緊緻的尾部延遲，那麼無論演示多麼精彩，它都沒有準備好用於推理。

客戶噩夢：成功的災難 讓我們看一個現在行業正在上演的場景。我們稱這家公司為“FinRetail”，一個擁有嵌入式金融科技的大型電商平臺。FinRetail構建了一個出色的AI購物助手。它使用RAG交叉引用使用者購買歷史、即時庫存和即時定價資料。概念驗證完美無缺，董事會非常滿意。他們在星期二上線。到了星期二下午，它經歷了一場“成功的災難”。AI代理太徹底了。為了回答一個簡單的問題如“最適合大學生的1000美元以下筆記型電腦是什麼？”，代理執行了40步推理迴圈，對其PostgreSQL資料庫發起數百次向量相似性搜尋，同時檢查即時庫存水平。併發性前所未有。15分鐘內，FinRetail耗盡了EBS突發信用，讀取延遲從0.8毫秒飆升至120毫秒。系統飽和，僅管理I/O等待狀態就讓整個網站宕機，連帶核心創收的OLTP系統一起崩潰。他們嘗試新增只讀副本，但底層儲存限制依然存在，AI代理開始根據過時的庫存資料產生幻覺，推薦幾個小時前就已售罄的產品。這是一場徹底的“事後分析”場景，完全是由無法處理現代推理工作負載的儲存層引起的。

Silk如何以不同方式解決這一風險 你不能透過投入更多託管磁碟來解決AI資料問題。你需要根本性的架構轉變。你需要解耦效能與容量。這正是Silk所做的。Silk是一個軟體定義的雲端儲存，位於你的EC2計算和底層基礎設施之間。它加速多個底層雲資源的效能，並將它們呈現為一個單一、極快、高彈性的資料層。當我說快時，不是指邊際改進，而是推動雲物理的絕對極限。最近，資料庫專家Tanel Poder對Silk進行了測試，結果令人震驚：實現了20 GiB/s的I/O吞吐量。使用Silk，你不會受單個EBS卷的IOPS上限束縛。Silk的對稱主動-主動架構和大型分散式快取層吸收了AI推理前所未有的併發性。它直接從記憶體提供熱向量，即使同時執行重負載OLTP和維護作業，也能提供一致的亞毫秒p99延遲。我們正在全球最 demanding 的資料密集型應用中證明這一點。無論你是在突破Postgres on Silk的高效能AI向量搜尋極限，還是透過Google AlloyDB進一步擴充套件Postgres AI工作負載，結果都是一樣的：極端規模下的企業級可預測性。Silk消除了為獲得更多儲存效能而過度配置EC2計算的需求，消除了依賴脆弱只讀副本的需求，讓你能夠在AWS上以企業級資料服務和效能保證執行AI工作負載。

停止祈禱，開始工程 AI推理海嘯已經來臨。能夠生存下來的系統將是那些建立在現代軟體定義雲端儲存架構之上的系統，這些架構針對暴力併發、大規模吞吐和毫不妥協的尾部延遲而設計。不要等到你自己的“成功災難”才意識到你的AWS儲存是瓶頸。是時候審視底層，看看一個AI就緒的資料平臺是什麼樣子了。準備好看到證據了嗎？聽取微軟首席資料與AI官Eduardo Kassner和Silk產品副總裁Tom O'Neill的見解，瞭解為什麼AI推理正在重塑系統行為，以及解決方案不僅僅是新增副本、採用新儲存系統或重寫應用程式。立即觀看網路研討會："AI Inference Didn’t Break Your Architecture - It Reveals What Comes Next"。由Silk貢獻。