Cloudflare 坦承 Workers AI 的 GLM-5.3 把別人的提示詞回給你：155 筆回應外洩，用雲端 API 跑長文件的台灣團隊該查什麼

台中一家做合約審閱系統的小團隊，九月初把一整包併購案的附件、往來信件和歷次修訂版本，一次塞進一個六、七十萬 token 的提示詞，丟給雲端上的開源模型做比對。他們選這條路的理由很實際：便宜、上下文夠長，而且服務條款寫得清清楚楚，客戶內容不會給其他客戶看到。這週工程師讀到 Cloudflare 的事故報告，第一個反應是去翻九月初的請求紀錄，看自己那幾次超長請求的長度落在哪裡。

這篇報告標題很技術，叫〈Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang〉。老實說，我讀完覺得它比很多「模型失控」新聞更值得開發者細看，因為出事的不是模型本身，而是每一家推論服務商都在用的那層基礎設施。

事件背景

Cloudflare 在 10 月 26 日（美國時間）發布這篇文章，隔天又修訂過一次。事故的主角是 Workers AI 上的 @cf/zai-org/glm-5.3，也就是智譜的 GLM 系列模型，由 Cloudflare 自己架在 GPU 上，對外以 API 計費提供。

GLM-5.3 在 8 月 27 日上線，對外宣稱的上下文長度是 1,048,576 個 token。問題在於，負責處理輸入（prefill）那一端的 KV 快取池，實際只裝得下 681,280 個 token。KV 快取可以想成模型讀完你的提示詞之後留下的「筆記」，生成每一個字時都要回頭翻。Cloudflare 在上線前其實知道兩個數字對不上，但它預期引擎遇到塞不下的提示詞會直接回錯誤；長上下文測試也都回 HTTP 200、串流正常，所以沒有當成問題處理。

9 月 8 日深夜（UTC 23:11），資安公司 Knostic 的研究員 Gadi Evron 透過 HackerOne 回報：送很長的提示詞時，偶爾會收到別人對話的文字。Cloudflare 隔天早上開始驗證，13:22 宣告資安事件，產品資安團隊在 25 分鐘內用兩個獨立帳號重現外洩；14:00 把模型設為私有，19:40 修好後重新開放。

本次重點

• 影響範圍：8 月 27 日到 9 月 9 日之間，共 155 筆回應受影響，全部來自長度超過 681,280 token 的提示詞。外洩的內容是「稍早其他使用者送給 GLM-5.3 的提示詞與部分生成內容」。Cloudflare 只說受影響的是「少數客戶」，沒有給確切家數。
• 兩個原因疊在一起：設定面是快取池比宣稱的上下文還小；引擎面是 SGLang 在「prefill 與 decode 分開跑」的部署模式下，遇到超長提示詞會先換成一個只有 1 個 token 的佔位請求，但排隊機制只檢查請求「做完沒」，沒檢查「是不是被拒絕」。結果 decode 端照預留的頁數去讀快取，例如預留 8 頁、實際只寫了 1 頁，剩下 7 頁裡還躺著前面別人的資料。客戶端拿到的是 HTTP 200，不是應該出現的 400。
• 快取頁不歸零：報告直說，KV 快取頁在請求之間不會清空，下一個請求拿到就直接覆寫。這是業界常見的效能取捨，前提是引擎要把每一頁的歸屬記得一清二楚。
• 警訊早就在：Cloudflare 調查時才發現，SGLang 的 GitHub 上早在 7 月 6 日就有人開了 #30233 號議題，描述「超長輸入被中止後，decode 用不完整的 KV 快取生成亂碼」。
• 修補：GLM-5.3 的快取池調成約 204 萬 token，大約是上下文長度的兩倍；Cloudflare 自寫引擎修補，讓帶著拒絕狀態的請求在交接前就被退回。上游 SGLang 在 9 月 16 日合併 #38935（在准入階段就擋掉超長請求），收進 10 月 2 日的 v0.5.21，10 月 19 日再出 v0.5.22。另外新增 --disaggregation-enable-kv-checksum 檢查碼選項。
• 官方結論：排除 Cloudflare 自己和研究員的測試後，請求時間與數量看起來是一般長文件用法，「沒有發現蓄意利用的證據」，其他 Workers AI 模型也沒受影響。

市場影響分析

台灣使用者

一般用聊天介面的人大可放心，這次只牽涉一個特定模型、在特定兩週內、而且提示詞要超過 68 萬 token 才會觸發，那大約是好幾本書的量。真正該注意的是把 GLM-5.3 接進自家產品的開發者，還有他們的終端客戶。

讓我比較在意的是 Workers AI 隱私說明裡那句話：Cloudflare 不會把客戶內容提供給其他 Cloudflare 客戶。這句承諾在法律文字上沒錯，但這次證明，承諾能不能兌現，取決於推論引擎底層一個佇列判斷式有沒有寫對。

企業應用

採購雲端 LLM API 的台灣企業，評估表可以多加幾題：多租戶共用 GPU 時，KV 快取怎麼隔離？宣稱的上下文長度跟實際快取容量有沒有對過？發生跨租戶外洩時，會不會主動通知受影響客戶？最後這題特別重要，因為 Cloudflare 這篇報告寫了大量技術細節，卻沒交代是否、以及如何通知那「少數客戶」。

如果你送出去的長提示詞裡有客戶個資，請法務評估是否涉及個資法的通報與告知義務（本文不構成法律意見，以主管機關與律師判斷為準）。也可以順手對照本站的〈AI 資料安全與隱私指南〉，把「送出去的資料最多能被誰看到」重新盤一次。

開發者

這段最實際，分兩種人講。

呼叫雲端 API 的人：

• 別把上限用到滿：服務商宣稱 100 萬 token，不代表 100 萬都穩。自己在閘道層設一個比官方低的輸入上限，例如用 LiteLLM 架的代理裡加一道長度檢查，超長文件改成切段處理。
• HTTP 200 不等於正常：這次的外洩請求全部回 200。對長文件任務加上輸出驗證，例如檢查回應裡有沒有出現你沒提供的人名、案號或文件標題，異常就丟棄並留存紀錄。
• 翻紀錄：8 月 27 日到 9 月 9 日間呼叫過 GLM-5.3、而且有超長請求的團隊，建議主動向 Cloudflare 詢問。

自架 SGLang 的人：Cloudflare 給的建議很具體。每次換權重、量化方式、平行度或記憶體比例後，都要從啟動紀錄核對 prefill 與 decode 兩端的 KV 快取池容量，小於上下文長度就把上下文調低；升到 v0.5.22 以上，或至少補上 #36988 與 #38935；模型支援的話開啟 KV 檢查碼與 --kv-canary。據 Unite.AI 引述 SGLang 團隊的說明，單機模式遇到超長提示詞會正常回錯誤，這次漏洞只出在拆開 prefill 與 decode 的部署；但核對快取容量這件事，單機一樣適用。

未來發展趨勢

我覺得這起事故會把「推論服務的租戶隔離」推成一個獨立的資安題目。過去大家談 LLM 安全，焦點多半在提示詞注入、模型會不會亂講話；這次證明，為了省記憶體而共用、重複使用的 KV 快取頁，本身就是一條資料可能流錯人的管道。前一天本站才寫過〈Cohere 抓到 Qwen 想把檔案傳去北京〉，那是模型的行為問題；這次則是平台的工程問題，兩者加起來，企業挑模型服務要看的清單只會越來越長。

Cloudflare 自己列了兩個長期方向。一是「設計上就保證完整」：替每一頁快取加上重新配置時會改變的標籤，讀取前先比對。它在 8 月中用 GLM-5.2 測過原型，吞吐量與尾端延遲的成本不到 1%，卻因為穩定性問題先關掉了。二是用形式化驗證證明 KV 傳輸協定的安全性。SGLang 也還有「釋放時把快取頁歸零」的草案（#46435）在審。我的看法是，歸零這種最直覺的做法到現在才排進議程，說明整個開源推論圈過去確實把效能擺在隔離前面。

TheAI學院 總結與評語

這次出事的不是模型，是模型底下那層大家都在用的推論引擎。服務條款保證不了隔離，只有你自己設的長度上限和輸出檢查保證得了。

回到開頭那個台中團隊，他們那天下午做的事就是重點：撈出九月初的超長請求、把文件改成分段送、在閘道層設長度上限，並寫信請服務商說明受影響名單。給台灣讀者的具體建議是：凡是用雲端 API 處理合約、病歷、判決書這類長文件，就別把宣稱的上下文長度用到極限；自架 SGLang 的團隊這週就排時間升級並核對快取容量。Cloudflare 願意把時間軸、PR 編號和設計失誤全攤開，這點值得肯定；但沒交代客戶怎麼被通知，是這份報告最大的缺口。

資料來源

• Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang（Cloudflare 官方，2026-10-26）
• SGLang PR #38935：Do not admit intake-rejected requests to a PD handoff（GitHub，2026-09-16 合併）
• Cloudflare Says GLM-5.3 Bug Leaked 155 Responses Across Tenant Sessions（Unite.AI，2026-10-26）

本文依公開資訊整理，另參考 Cloudflare Workers AI 隱私說明與 TokenPost 報導；受影響範圍、修補版本與後續處理以 Cloudflare 及 SGLang 官方說明為準。