📍 真實場景
在小型新創擔任後端工程師的小宇，負責把客戶合約丟給雲端 AI 做摘要
他為了一次處理整份合約，把幾十萬字的內容塞進同一個提示詞，交給託管在雲端的開源模型
😖 卡住的地方：他一直以為雲端 AI 就像租了一間獨立的房間，沒想到在這次事故中，超長提示詞的回應可能夾帶其他客戶的內容
💡 讀完你能判斷自己有沒有踩到這次事故的條件，並做出三個今天就能做的防護動作
⚡ 一句話講清楚
Cloudflare 公布了一份事故報告：在它的 Workers AI 服務上，GLM-5.3 這個模型從 2026 年 8 月 27 日到 9 月 9 日之間，有少數客戶收到的回應裡混入了別人剛送出的請求內容。受影響的回應共 155 筆，而且全部發生在提示詞長度超過 681,280 個 token（模型處理文字的最小單位，約略可想成字詞碎片）的情況。一位資安研究員在 9 月 8 日通報，Cloudflare 隔天重現問題，並在宣告事故後 40 分鐘內把模型下線，當天修好後恢復服務。Cloudflare 表示，其他 Workers AI 模型沒有受影響，也沒有發現有人刻意利用這個漏洞。
原因有兩個疊在一起。第一個是設定落差：模型宣稱支援約 104 萬 token 的上下文長度，但負責預處理的 GPU 上的 KV cache模型讀完你的提示詞後，暫存在顯示卡記憶體裡的「記憶筆記」，讓它之後生成回答時不用重讀一遍，只裝得下 681,280 個 token。Cloudflare 上線前就知道有這個落差，但預期推論引擎會對放不下的提示詞回報錯誤，加上長文測試都回傳成功，所以沒有當成問題。
第二個是開源 推論引擎負責把模型真正跑起來、接收請求並產出回答的軟體，這次用的是 SGLang 的 bug：在把「讀提示詞」和「寫回答」拆給不同 GPU 的 prefill/decode 分離模式先由一批 GPU 讀完提示詞，再把筆記交給另一批 GPU 接著寫答案的部署方式 下，放不下的提示詞被標記為拒絕、換成一個只有一個 token 的佔位內容，卻沒有中止請求並回傳錯誤。引擎照樣替這個佔位內容產生快取並往下傳，最後回應混入了其他客戶的內容。報告節錄在這裡被截斷，更細的機制請看 Cloudflare 與 SGLang 同步發布的原文。
🏃 快速上手三步（今天就能做）
1
查自己有沒有中招先確認兩個條件是否同時成立：你有沒有在 2026-08-27 到 2026-09-09 之間呼叫過 @cf/zai-org/glm-5.3；單次提示詞是否超過 681,280 個 token。去 Cloudflare 後台看該模型的請求紀錄與用量，找輸入 token 數特別大的呼叫。兩個條件都不符，就不在已知受影響範圍內。符合的話，檢查那幾筆回應有沒有出現不屬於你資料的文字，並留存證據。
▼
2
收斂送進雲端的內容今天就在自己程式裡加一道檢查：送出前估算 token 數，超過你設定的上限就拒絕或分段處理，上限要低於服務商實際容量。另外，把密碼、API 金鑰、身分證字號、客戶個資這類內容在送出前遮蔽或移除。這樣即使雲端出狀況，外洩的也只是已遮蔽的版本。
▼
3
用超長輸入測試你的供應商在測試環境故意送一個超過標示上限的超長提示詞，判斷標準只有一個：服務應該明確回傳錯誤，而不是回傳看起來正常的成功結果。再追問你的服務商，文件上標示的上下文長度與實際能處理的容量是否一致。這次事故正是長文測試「回傳成功」而讓人誤以為沒問題。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 「上線前已知的設定落差」為什麼會變成安全事故？
Cloudflare 明說上線前就知道上下文長度 1,048,576 與快取容量 681,280 不一致，卻寄望引擎會自己報錯，而測試結果也沒反駁這個假設。這是典型的把安全依賴在下游元件行為上的權衡：省了調整容量的工作，卻讓錯誤處理成為唯一的防線。工程上比較穩的做法，是在入口自己把長度限制在實際容量內，不要仰賴引擎在超載時一定會失敗得很乾淨。
🔭 這件事對「用雲端 AI 處理敏感資料」的決策有什麼影響？
多租戶（多個客戶共用同一批機器）的隔離，在 AI 推論上多了一層以前少見的共享狀態：快取。這次的觸發條件相當窄（只有超長提示詞），受影響也只有 155 筆，Cloudflare 也沒有發現被刻意利用的跡象，所以不必過度恐慌。但它說明了隔離不是理所當然，風險評估時要把共享狀態的故障納入考量：敏感資料要先脫敏、盡量不要依賴極限規格，並在合約或審查時問清楚服務商如何處理這類隔離失敗與事後通報。