AI快取的效能收益，應在隔離邊界內計算

Cloudflare於2026年10月26日披露，其GLM-5.3部署在8月27日至9月9日期間出現跨請求資料暴露；公司稱其他Workers AI模型未受影響。公司報告。

這是一宗具體事件，並不證明所有共享推理服務都會洩漏資訊。不過，它提出了一個更廣泛的採購問題：供應商報告推理變快時，測試保留了哪些邊界？只有服務仍在完成客戶授權的工作，速度才有實際價值。

客戶之間的隔離，也是工作負載的一部分

設想一個假設性的文件助手，由兩家公司分別使用。雙方都讓它總結合約，也都採用同一套公開指令，但私有文件並不相同。如果效能測試把這些任務合併成一個方便排程的資源池，結果可能很漂亮，卻沒有代表客戶真正需要的保密條件。

我們的分析建議是，把允許共享的群體寫入工作負載定義。一次測試中的任務，究竟屬於同一個人、一個團隊、一家機構，還是彼此無關的機構？這些描述不能互換。即使在同一家公司，法務調查與普通客服對話也可能需要不同的存取邊界。

這會改變採購方閱讀效能比較的方式。假如一組測試允許廣泛複用，另一組把各部門分開，前者的延遲更低，並不能單獨證明實作更優秀。兩者可能在提供不同的服務。應先對齊允許共享的範圍，再比較這個範圍以內的表現。

這裡並不是說共享本身有錯。所有參與者都有權看見的公開指令，允許複用可以是合理的設計選擇。問題在於，方便的技術分組容易變成未經審視的授權決定。使用相同模型、掛在同一個計費帳戶下，或者提問措辭相近，都不能獨自回答哪些任務應該共享衍生狀態。

對客戶來說，購買的也不只是一次回答。客戶通常希望同一套邊界在繁忙時、任務結束時和使用方式改變時仍然成立。因此，隔離條件不應作為效能報告角落裡的附註；它應與任務類型、輸入規模和驗收方式一起，成為解釋結果的前提。

生成成功，不是驗收的全部

SGLang的10月26日披露描述了被拒絕的請求繼續進入分離式處理交接、讀取未為該請求填充的快取頁，並另行討論生命週期防護。維護者報告。

這一區分對我們的分析很重要：有意的計算複用，與意外接觸另一請求的狀態，是兩類問題。管理前者的規則，不能被預設視為能夠阻止後者。採購方既需要知道系統允許什麼安排，也需要看到任務未正常推進時，實作是否仍然守住這種安排。

可以設想一次受控的驗收演練：使用虛構文件，而不是真實客戶資料。一組測試材料帶有獨特的專案標記，另一組沒有權限讀取它。評估者檢查回答是否帶入了錯誤群體的資訊，同時檢查合法摘要是否仍然有用。這是對授權測試的設計建議，不是在估計任何生產服務的故障發生率。

演練還應涵蓋被拒絕、中途停止和重試的任務，因為這些都屬於客戶實際經歷的服務。只包含順利完成、格式正確的任務，會在測試結論與營運問題之間留下空隙。但通過這些測試也不能證明所有洩漏可能性都已排除；它只能為特定配置、場景與觀察時段提供證據。

因此，一份有用的報告應區分三種結果：獲得授權且有用的回答、明確拒絕或失敗，以及在現有權限下根本不應產生的回答。把所有返回內容平均成一個成功率，會掩蓋最重要的差別。一個清楚說明失敗的服務，有時比流暢卻來源錯誤的回答更符合客戶利益。

這種區分還會影響最佳化團隊的誘因。如果唯一目標是減少報錯，團隊可能傾向於讓更多任務返回內容；如果目標是交付得到授權的有效結果，明確終止某些任務就可能是正確行為。這裡討論的是應如何設定驗收目標，並非認定任何供應商存在這種誘因失當。

先固定邊界，再比較效率

作為另一種設計例子，vLLM文件介紹了可選的請求鹽值，用於把前綴快取複用限制在鹽值相符的請求之間；它不是所有快取生命週期缺陷的通用修復。vLLM文件。

採購上的啟示不是強制採用某一種實作，而是要求共享規則能夠被採購方說清楚，也能由營運方檢驗。應用負責人可能允許同一專案內複用，同時把無關客戶分開；另一位負責人可能願意接受稍慢的服務，以減少共享的請求衍生狀態。只看每秒詞元數，無法評價這兩種選擇。

合理的反對意見是：隔離範圍越窄，共同平台的經濟收益可能越小，複雜測試也會延遲採用。這種取捨應當明確呈現，而不是隱藏起來。正確的比較對象，是滿足同一隔離要求的不同方案，以及它們各自的延遲、容量和營運負擔；不是把隔離服務與不受同樣限制的測試當成等價產品。

當團隊後來修改存取模型時，同一原則仍然適用。合併兩個工作區，可能創造新的共享機會；移除一個參與者，可能縮小共享範圍。在我們提出的治理方式中，這些變化應觸發對效能假設的複核，而不只是修改使用者目錄。快速配置的價值，取決於它的權限是否仍然適合當前工作。

這些披露沒有證明哪一種架構適合所有客戶。它們促使評估者提出一個更準確的問題：在所需的隔離條件已經明確、並經過檢驗之後，還剩下多少有用的吞吐能力？與脫離信任邊界的速度數字相比，這才是選擇推理服務更有意義的依據。