OpenAI Habitat 擴展透過共享儲存實現快 12 倍的讀取速度

OpenAI 表示，其 Habitat 儲存平台現時的全球讀取中位數約為 10 毫秒，較原來的 120 毫秒大幅下降。該公司於 10 月 23 日發表的工程技術文章指出，OpenAI Habitat 擴展是透過共享資料庫容量、區域快取，以及與 Microsoft 更緊密合作實現。核心矛盾在於營運層面：共享基礎設施能提升資源利用率，但要保障互不相關的工作負載，所需的控制措施不止是購買更多容量。

相關比較在於：為個別工作負載提供專屬儲存，與設有可強制執行邊界的共享儲存之間的取捨。Meta 在分散式快取方面的經驗提供了歷史參考。挑戰在於，既要讓常見操作保持快速，同時在更新、流量高峰及故障期間維持正確行為。

對開發者及企業採購者而言，這涉及 AI 模型周邊的應用程式基礎設施。當應用程式無法取回處理請求所需的資料時，模型能力的重要性便大打折扣。儲存效能亦須謹慎解讀：資料庫讀取加快，並不會直接等同 ChatGPT 回應以相同比例加快。

OpenAI Habitat 擴展重返共享容量

這項架構改動的重點，是讓共享資源切實可行，同時毋須將容量規劃交回每個產品團隊。

根據 OpenAI 的儲存擴展說明，Habitat 在嘗試專屬容器後，重新採用共享容器。容器是儲存記錄並設有相關容量設定的資料庫分組。該公司表示，熱鍵限流、請求優先級及 Azure 容量調整，都是支援這項回歸的保障措施。熱鍵限流會限制異常繁忙的記錄或識別碼，避免其壓垮共享資源。

這項轉變之所以重要，是因為隔離具備直觀吸引力。每個工作負載各有自己的配額，權責看似更容易理解。團隊可以檢視自身流量、調整設定，並分析直接依賴項。當工作負載位於獨立資源邊界時，問題亦似乎較易控制。

然而，專屬配額會帶來各自的規劃責任。每次推出新功能都需要可信的流量預測，而每個配額都要預留足夠空間應對需求變化。機構可能在眾多工作負載之間累積了閒置容量，卻仍令個別新功能準備不足。其他地方可用的資源，不會自動幫助受限的工作負載。

共享容量透過整合需求來處理這種不匹配。在平台控制措施的規限下，閒置的工作負載可騰出空間供另一個工作負載使用。這令請求的分佈與其總量同樣重要。核心營運問題變成：系統如何處理例外情況，同時不犧牲一般流量。

Microsoft 的多租戶資料庫指引描述了同樣的根本衝突：隔離與可持續資源使用之間的取捨。多租戶是指多個租戶或工作負載共用基礎設施。Microsoft 解釋，即使容器仍有未使用的吞吐量，不均勻的存取模式仍可能造成限流。限流是指當資源無法安全接收更多工作時，限制傳入工作量。

這項區分避免人們誤解雲端容量。資料庫整體可能仍有空間，但某個特定部分依然處於飽和狀態。若不了解流量分佈便增加容量，原有瓶頸可能依舊存在。相反，將所有東西分隔開來，可能只會分散瓶頸，卻不會令管理變得更簡單。

實際含意是，共享需要一套明確的競爭處理政策。產品團隊需要知道哪些請求會獲優先保障，哪些可以等待。平台團隊則需要有足夠可視性，在事故期間解釋這些決定。若缺少這些責任分工，共享資料庫便只是一份在需求仍屬舒適時才有效的協議。

因此，OpenAI Habitat 擴展除了技術改動外，亦提供了一項組織層面的啟示。儲存架構決定了誰必須預測需求、誰可以介入，以及誰要承擔錯誤預測的後果。

產品團隊承受資料庫邊界的成本

當儲存平台能減少推出產品所需的基礎設施決策時，它才真正發揮價值。

OpenAI 較早前的 Habitat 服務設計說明，提供了組織層面的背景。該文於 9 月 11 日發表，描述如何將資料庫邏輯由用戶端程式庫移至獨立服務。用戶端程式庫是嵌入應用程式內的程式碼；獨立服務則獨立運行，並透過網絡為這些應用程式提供服務。

該公司表示，跨產品服務協調程式庫變更會造成部署問題。將邏輯集中化，讓儲存團隊有一個統一位置管理變更、存取控制及可觀測性。可觀測性是指收集足夠營運資訊，以了解系統的行為方式。

這項選擇提供了評估新儲存改動的有用標準。集中化應減少應用程式團隊的工作，而不只是搬遷設定檔。若每項功能仍需要專門的容量規劃，服務便只是隱藏了實作細節，卻未有消除營運負擔。

試想一個假設的應用程式推出情境。內部測試期間，一項功能的使用量有限而且可預測。公開推出後，請求模式會有所不同，當中包括流量突增及客戶之間不均勻的活動。功能團隊了解預期使用體驗，但這些知識未必能產生準確的資料庫需求預測。

專屬配額會令該團隊的預測變得關鍵。共享平台只要具備足夠容量及合適控制措施，便能吸收部分預測誤差。這不會消除推出前的準備工作，而是改變哪些決定需要產品知識，以及哪些可由基礎設施團隊集中處理。

事故期間，同一種分工亦很重要。應用程式開發者應識別受影響的用戶流程，並評估可接受的服務降級程度。儲存營運人員則應判斷，責任在於資源競爭、資源配置，還是底層依賴項。若兩個群組都要各自重新理解資料庫架構，復原工作便更難協調。

對企業採購者而言，這影響基礎設施聲稱應如何納入採購決策。基準測試描述特定條件下的效能；營運模式則說明供應商在那些條件改變時如何應對。兩者都值得重視，尤其當應用程式服務多個優先次序不同的部門或客戶時。

背景報告工作與互動式用戶請求亦有不同容忍度。優先保護互動式請求或屬合理，但延遲的報告工作仍需要監察及明確責任。當低優先級工作最終能完成，且不會威脅高優先級工作時，優先級政策才算成功。

這些選擇應寫入團隊能在推出或故障期間找到的技術文件。維護一個可搜尋的知識庫，有助工程師保留資源邊界與例外處理背後的理據。

因此，產品團隊面對的壓力很具體：他們需要一份隨使用量變化仍然易於理解的基礎設施契約。平台團隊面對的壓力同樣具體：讓這份契約有用，同時毋須每位應用程式開發者都成為資料庫營運人員。

全球快取改變讀取耗時的位置

最顯著的效能改善，來自避免請求路徑中不必要的距離與工作。

OpenAI 將其公布的改善歸因於選擇性複寫、Valkey 快取及以 Rust 重寫。複寫會在多個位置維護資料副本。Valkey 是一種記憶體內資料儲存系統，在此用作快取副本。Rust 是用於重建 Habitat 服務的程式語言。

這些改動針對不同的延遲來源。將資料放置得更接近請求，可縮短傳輸時間。重用附近副本，可避免反覆取回相同資訊。減少服務開銷，則可降低應用程式與儲存資料之間的處理成本。若沒有獨立測量，無法將它們的綜合效果歸因於單一元件。

評估 ChatGPT 儲存效能時，這個區分十分重要。儲存請求可能花時間等待網絡、等待資源，或執行應用程式邏輯。某一類別有所改善，並不表示其他類別還剩下多少延遲。實用的分析會問：哪些等待已被消除，而哪些請求仍會遇到這些等待。

快取會保留可重用的資料副本以加快存取，從而改變頻繁重複讀取的成本結構。底層資料庫毋須再直接處理每次存取。不過，應用程式現在依賴一套機制，判斷附近副本是否仍然適用。

一個假設的設定查詢例子可令問題更具體。從附近快取讀取未變更的偏好設定，可以避免向遙遠資料庫發出請求。偏好設定更新後，相同的快取值便不再適用。基礎設施必須將寫入操作連結至仍保存舊值的位置。

Meta 的快取一致性分析解釋了為何這會變得困難。快取一致性關乎快取值是否與底層資料一致。Meta 描述快取填充與失效操作之間的競態情況；失效操作會移除過時副本。延遲的操作可能會以某種方式與較新的更新互動，令不正確的值仍可被取得。

更廣泛的教訓是，讀取最佳化會帶來寫入端的責任。一項看似簡單的讀取之所以快速，是因為其他程序維持了讓它安全的條件。只評估讀取路徑，便忽略了支撐這個結果的機制。

對 OpenAI 儲存架構而言，這是效能與正確性之間的重要邊界。只有在回傳資訊適合該操作時，更快的存取才有用。不同資料類型可容忍不同的新鮮度要求，因此即使是共用儲存介面，仍需要明確的行為保證。

所報告的中位數亦值得精確理解。中位數代表所測量分佈中位於中央的觀察值。它不描述每一項請求，也不代表每個地區的體驗。中位數大幅改善，仍可以與經過不同路徑的緩慢請求並存。

這使結果具有意義，卻不應將它演繹為通用的產品速度聲稱。它顯示常見的儲存路徑已大幅縮短，同時留下其他問題：不常見讀取的表現、更新的可見性，以及儲存對完整應用程式回應時間的貢獻。

Azure 與 AWS 面對同樣的需求不均問題

雲端資料庫比較在檢視工作負載行為，而非將容量視為單一數字時，才會變得有用。

Amazon DynamoDB 是 AWS 的受管資料庫服務，為共享資源管理提供了相關的比較案例。其 自適應容量文件說明，系統會自動提高流量較高分割區的容量。分割區是資料庫分散式儲存及處理工作的一部分。

AWS 亦指出，自適應容量仍受限於資料表容量及分割區限制。這項限定比一般的彈性承諾更為重要。彈性是指資源會隨需求變化而調整，但並不表示每種存取模式都可在不遇上局部限制的情況下無限擴展。

這是補充背景，而非 DynamoDB 對 Habitat 表現較佳或較差的證據。兩項服務採用不同設計、設定及運作關係。現有資料並未提供在相同工作負載下進行的受控比較。根據這些資料為供應商作排名，會超出證據所能支持的範圍。

共同的工程問題是需求不均。受歡迎的客戶、物件或工作流程，可能將請求集中在系統狹窄的一部分。整體流量看似可控，但這種集中情況仍可造成延遲。相關架構必須偵測這種失衡，並在失衡發生的層級作出回應。

不同應對方法亦有不同成本。重新分配工作可改善資源使用率，但需要安全的遷移機制。限制最繁忙的請求可保障其他使用者，但會改變受限制工作負載的體驗。維持備用容量可提升準備程度，卻會在資源真正需要前消耗資源。

專用設計令部分界線更清晰，但不會消除每項配置內的需求集中問題。共享設計提供更多整合備用容量的機會，但需要更強的協調能力。兩種方法都無法避開理解應用程式存取模式的需要。

對買家而言，有用的比較應由具代表性的工作負載開始。測試應包括集中需求、一般混合流量，以及中斷後的復原情況。平均分布於各記錄的穩定工作負載，所回答的問題比面對不可預測客戶活動的產品推出情境更為狹窄。

同一原則亦適用於自動擴展的說法。應詢問甚麼會觸發調整、調整生效期間會發生甚麼，以及哪些界線仍然固定。亦應詢問應用程式是否必須在已知事件前預備容量。這些細節決定自動化是否減少營運工作，還是只改變其發生時機。

AWS 的文件化應對方式支持對 OpenAI Habitat 擴展的更廣泛理解：管理需求不均是分散式資料庫的核心問題。它並非某一特定雲端供應商或 AI 產品獨有。

因此，有意義的競爭在於能否成功控制資源爭用的營運模式。供應商功能固然重要，但其價值取決於工作負載、周邊控制措施，以及負責使用它們的團隊。

更快的中位數仍留下資料新鮮度與復原疑問

這項效能數字由公司自行報告，單憑此數字不能證明正確性或韌性。

OpenAI 的說明屬工程披露，而非獨立重現的基準測試。讀者可評估其機制及報告結果，同時保留兩者之間的區別。較恰當的結論是，該公司報告其生產環境測量中出現重大改善，但若干重要面向仍需要獨立證據。

其中一個面向是中位數背後的分布。尾端延遲描述請求時間中較慢的一端。對於需要進行多次相互依賴查詢的應用程式，偶爾一次緩慢操作便可能主導使用者的等候時間。要理解這種體驗，不能只看中間數值。

另一個面向是更新可見性。變更資料擷取（change data capture，CDC）會將資料庫變更資訊分發至其他系統。OpenAI 表示，其利用 Cosmos DB 的變更摘要，在數秒內推動全球快取失效。這項機制帶來有關延遲傳送、復原，以及消費者落後時系統行為的問題。

Microsoft 的變更摘要模式文件說明了為何實作細節重要。最新版本模式會報告建立及更新，但不會將刪除擷取為變更。所有版本及刪除模式則有不同的涵蓋範圍及設定要求。

這些已記錄的差異並不證明 Habitat 存在缺陷。它們指出任何使用變更串流的系統都必須回答的問題。變更串流是持續發出的資料庫更新通知序列。其消費者需要採取符合所支援操作的行為。

例如，一個示例知識應用程式可能需要從搜尋結果及快取摘要中移除已刪除內容。單憑接收更新通知，並不能證明刪除處理有效。應用程式需要明確的刪除路徑，以及下游副本按預期作出回應的證據。

授權構成另一項重要界線。授權決定某個行動者可否執行某項操作。不應假設一般快取策略能為每項權限決定提供所需的新鮮度。讀者應尋找與相關操作相連的保證，而非由整體效能外推。

復原帶來另一項考驗。當所有相依服務均可用時，系統可以很快，但在中斷後可能難以還原。快取資料、待處理更新及底層儲存必須回復到一致的運作狀態。相關證據包括復原演練，以及相依服務失效期間觀察到的行為。

這些是分析問題，而非對未披露事件的指控。它們有助區分公告所量度的內容，以及企業使用者必須按自身要求評估的事項。它們亦可避免一項常見錯誤：讓一項解釋完善的效能提升，代替無關的保證。

因此，ChatGPT 儲存效能最好理解為一組特性。速度、新鮮度、可用性及復原能力會互相影響，但每項都需要合適的量度方式。可信的架構會讓這些互動足夠可見，讓營運人員可作管理，客戶可作評估。

留意尾端延遲、共享工作負載穩定性及儲存部署

下一批有用證據將顯示，這套營運模式能否在更困難的請求及不斷變化的工作負載下維持有效。

未來數月，首個值得留意的訊號是包含較慢請求的區域延遲細分資料。這類披露可顯示改善是否超越常見路徑。廣泛改善會加強架構對使用者體驗影響的論據。持續出現的區域異常值則會收窄這個結論，但不會抹去中位數結果。

有用的細節會把量度結果連繫至請求類別。快取及未快取讀取可能面對不同工作，因此合併兩者會掩蓋重要差異。區域量度亦有助區分服務本身的改善，以及資料放置方式的改善。

這個訊號對產品評估重要，因為使用者體驗的是完整工作流程。快速查詢固然有價值，但其實際影響取決於它在該流程中的位置。把儲存變更與應用程式行為連繫起來的證據，會令結果更易解讀。

第二個訊號是在混合工作負載及重大推出期間持續保持穩定。相關披露會說明，當其他活動增加時，互動流量是否仍受到保障。成功控制資源爭用的證據，將支持共享容量方法。不相關工作負載之間反覆互相干擾，則會暴露控制措施或其設定的限制。

最有力的說明應包括對延遲背景工作的處理。保護前台請求可能將壓力轉移至其他地方，因此穩定性應包括最終完成及可管理的積壓。積壓是等待處理的工作。其行為有助顯示優先次序系統是在解決爭用，還是在延後爭用。

產品團隊亦需要證據，證明營運模式可減少規劃工作。較少人手介入會支持集中化的組織論據。若需要頻繁作出應用程式專屬例外處理，則表示複雜性仍然分散，即使資料庫配置是共享的。

第三個訊號是 OpenAI 計劃中、用於大量資料的自訂儲存系統之生產證據。該公司形容系統仍在開發中，以降低快閃記憶體需求來換取較低的請求容量峰值。部署結果將釐清哪些工作負載適合這項取捨。單靠設計公告不能證明其生產影響。

評估這個訊號時，應着重工作負載適用性，而非自訂基礎設施的吸引力。較大的資料與小型、頻繁請求的記錄，可能有不同存取要求。成功部署會解釋這些界線，並顯示新系統如何與現有儲存系統一同運作。

綜合而言，這些訊號提供具體方法，讓人追蹤 OpenAI 儲存架構，而無須期待預定公告。它們是值得留意的證據，不是承諾會作出的披露。每項都檢驗核心主張的不同部分：更快的常見讀取、可管理的資源爭用，以及可持續的增長。

對開發者及企業買家而言，可利用這份說明深化下一次基礎設施檢討。詢問哪些操作需要最新資料、哪些工作負載共享容量，以及正常讀取路徑失效時會發生甚麼。要求提供能把資料庫行為連繫至使用者實際執行工作流程的量度結果。記錄例外情況，讓日後團隊明白特定界線存在的原因。OpenAI Habitat 擴展提供了一個有用案例，說明如何把營運責任轉移至平台，但複製其組件並不能重現其結果。請將所報告的機制與自身需求模式及復原要求比較。由延遲或錯誤結果影響最大的操作開始，然後檢視服務該操作的整條路徑。