WEBVTT NOTE Title: [2026-10-28] Cloudflare推論快取大穿透洩露跨租戶隱私、美光驚拋4F²豪賭3D DRAM與Python移除JIT編譯器 1 00:00:00.000 --> 00:00:53.920 大家好，歡迎收聽今天的科技放送。今天最震撼資安圈的消息，絕對是 Cloudflare 在 Workers AI 跑的 GLM-5.3 模型，竟然把上一個使用者的 KV 快取給洩漏出去了！這涉及跨租戶的隔離失效，連其他使用者的 Prompt 甚至是 API Key 都可能被看光。我們在 10 月 20 號才聊過自架 LLM Proxy 的快取防線，10 月 26 號也探討過分散式模型推論，沒想到公有雲大廠直接在推論引擎的底層記憶體管理上翻車了！ 2 00:00:53.920 --> 00:02:22.370 這起事件的技術根源非常精準而且值得所有架構師深思。Cloudflare 是在解耦推論架構，也就是 Disaggregated Prefill and Decode 模式下踩到雷。他們把 GLM-5.3 宣告為一百萬 Token 的上下文長度，但 Prefill GPU 節點上的 KV 快取池，實際只有六十八萬 Token 的空間。更致命的是推論引擎 SGLang 當時的機制：當 Prompt 超過快取池，排程器把請求標記為拒絕並替換成單一 Token 佔位符，但 Prefill 與 Decode 之間的佇列只檢查請求是否結束，沒檢查是否被拒絕！結果 Prefill 只傳輸了第一個 Token 的快取，Decode 節點卻誤以為整個上下文傳完了，直接拿著沒被覆蓋、還留有前一個使用者記憶體的舊快取頁面去做 Attention 計算。 3 00:02:22.370 --> 00:03:12.270 這真的是最經典的跨租戶惡夢！使用者發出超長請求，不但沒拿到 400 錯誤，反而拿到 200 成功回應，生成的文字裡還夾雜著其他人的私人對話或代碼。Cloudflare 承認有 155 個超長請求的回應受到影響。雖然他們在接獲通報後 40 分鐘內下線模型並修復配置與 SGLang 程式碼，但社群都在質疑：為什麼上線前明知記憶體池小於宣告上下文，卻只看 HTTP 狀態碼與串流就放行，沒有真正驗證輸出內容的完整性？ 4 00:03:12.270 --> 00:04:16.130 因為在硬體成本高昂的情況下，GPU 記憶體往往不直接做零填覆蓋，而是靠引擎維護指標覆蓋來提升吞吐量。這跟我們以前處理 C 語言的緩衝區未初始化洩漏一模一樣。現在 Cloudflare 除了強制要求檢查池大小，推動 SGLang 上游合併提早拒絕請求的修復外，還導入了延遲釋放與頁面標籤校驗。這件事告訴所有人：在分散式 RDMA 傳輸 KV 快取的時代，跨節點的一致性如果只依賴網路回傳碼，資安防線等於形同虛設。提到資安，另一家以安全性著稱的 Tailscale，今天也發布了 Tailscale SSH 的提權漏洞調查與修復進展。 5 00:04:16.130 --> 00:05:14.540 Tailscale SSH 算是很多企業的寵兒，因為它把身分驗證與 SSH 金鑰管理整合進虛擬網路中。不過這次官方公告指出，在特定條件下，已經被授權連入節點的非特權使用者，可以透過 Tailscale SSH 突破本機使用者的權限限制，甚至拿到 elevated privileges 也就是 root 權限！這讓很多依賴 ACL 做細部權限管控的團隊神經緊繃。官方目前甚至建議如果不需轉發，先在服務環境變數加入 TS_SSH_DISABLE_FORWARDING 等於 1 來緩解。 6 00:05:14.540 --> 00:06:17.930 社群裡有人戲稱這是 Tailworm，但必須幫技術事實釐清一下：這不是未授權遠端代碼執行，它必須是已經在 tailnet 裡、且本來就拿到該節點 SSH 連線許可的使用者，利用了 tailscaled 處理 SSH 轉發通道時的漏洞來做本機提權。如果你在 ACL 裡本來就給對方 root 或免密碼 sudo，這漏洞對你幾乎沒有邊際影響。但對於那種租戶隔離、開發者只能用低權限帳號連入的環境，這就是嚴重的特權提升漏洞。這再次證明，即便網路層有 WireGuard 罩著，應用層的多功能包裝只要越做越肥，攻擊面就會呈指數級擴大。 7 00:06:17.930 --> 00:07:00.730 講到攻擊面，上週鬧得沸沸揚揚的 PHP2Shell，今天資安大廠 Wiz 也發布了在真實環境中的最新利用嘗試與修復趨勢報告。根據他們的遙測數據，自從揭露以來，暴露在公網上的易受攻擊機器數量下降了大約 67%，但仍有超過一半原本受影響的企業尚未完全修復。更引人注目的是，Wiz 監控到的野外利用攻擊，目前居然還沒有一例在他們的蜜罐中成功拿到 Shell！ 8 00:07:00.730 --> 00:08:19.010 Wiz 剖析了那些公開攻擊工具失敗的底層技術原因。公開的 PoC 比如 9bie 的工具，主要依賴兩階段：第一階段用大量的多部分表單讓 PHP 觸發記憶體耗盡，也就是 OOM，使 Session 指標指向被釋放的堆疊；第二階段再發送請求去洩漏記憶體位址以繞過 ASLR。問題在於，這些攻擊腳本把堆疊結構硬編碼綁定在官方特定的 Docker 映像檔和 128MB 限制上。真實環境下，如果目標是不同的記憶體限制、編譯參數，或是常見的多 Worker Apache 與 php-fpm 架構，攻擊請求根本無法連續打在同一個 Worker 上，導致記憶體洩漏失敗或直接變成服務阻斷。這說明了為什麼「理論漏洞」要轉化成「全自動武器化腳本」其實有極高的工程門檻。 9 00:08:19.010 --> 00:08:51.890 說到工程技巧的極致，Reddit 的 netsec 討論區今天出現了一篇堪稱炫技神作的文章：作者證明了在 JavaScript 裡，你完全不需要雙引號、單引號，甚至完全不需要小括號，就能構造任意字串並執行任意代碼！這簡直是把 WAF 與防禦字元過濾機制按在地上摩擦啊。 10 00:08:51.890 --> 00:10:13.240 這篇技術實現非常精妙，完全是 JSFuck 的反向對偶版。作者利用的是 V8 引擎中 Error 物件的 prepareStackTrace 函式。這個函式在 Error.stack 被讀取時會自動被呼叫，而且在呼叫時會傳入兩個引數。作者將 prepareStackTrace 覆寫為 String.prototype.split，再覆寫 Error 與 Array 原型鏈上的 toString 與 valueOf，利用 Array.prototype.indexOf 產生負一，相減得到零，進而拼湊出所有數字，最後呼叫 String.fromCharCode 組合出字串，再丟給 Function 建構子。整個過程完全不需要小括號與引號，只靠加號、減號、等號、逗號與小數點！ 11 00:10:13.240 --> 00:10:24.360 這對那些以為過濾掉括號就能防 XSS 的安全檢核機制來說，是一記重重的手術刀式打擊。 12 00:10:24.360 --> 00:11:16.390 前端的安全假設被顛覆，而 Python 核心社群今天也迎來了一個震撼彈：Python 3.13 中引入的實驗性 JIT 編譯器，確認將在主幹分支中被移除！當初 PEP 836「JIT Go Brrr」被提出時大家寄予厚望，希望能藉此抵消 Free-threading 帶來的效能懲罰，結果維護團隊現在因為無法負擔指導委員會提出的龐大要求，正式撤回了 PEP。David，這是不是代表 CPython 的原生 JIT 之路徹底斷了？ 13 00:11:16.390 --> 00:12:40.110 短期內在 CPython 主幹上確實是宣判死刑了。我們必須客觀看待 Python Steering Council 的考量。當初 Brandt Bucher 引進 Copy-and-patch JIT 時，雖然設計上從直譯器迴圈的同份原始碼生成機器碼，理論上維持語義一致，但一旦要正式轉正，就牽涉到多平台維護、與除錯器和效能剖析工具的相容性，以及極端動態語法下的破壞性風險。委員會要求一個橫跨所有主要 PyPI 套件的相容性檢驗與長遠維護承諾，這不是兩三個工程師靠熱情就能扛下來的。而且實測下來，純 JIT 在巨觀測試上的加速只有 10% 左右，相較於 V8 帶給 JavaScript 的質變，Python 的動態查找和 C 擴充模組綁架讓編譯優化非常難施展。結果就是維護成本過高，只能壯士斷腕。 14 00:12:40.110 --> 00:13:38.050 很多開發者感嘆說，現在要追求極限效能，要嘛用 PyPy、GraalPy，要嘛乾脆用 AI 把瓶頸重寫成 Rust 或 Go。不過講到 AI 生成內容，維基百科的志工們最近正在進行一場巨大的清理戰役。IEEE Spectrum 報導了 WikiProject AI Cleanup 團隊的運作內幕。從 2023 年底 ChatGPT 常見的「stands as a testament」等陳腔濫調，到現在辨識「排比結構」與假文獻，維基百科正式通過方針禁止使用大型語言模型來撰寫條目。 15 00:13:38.050 --> 00:14:46.640 維基百科這場防禦戰非常具有指標性。研究顯示，高達 15% 到 20% 的新條目草稿會被 AI 偵測工具標記。最危險的不是文字風格，而是引文幻覺。AI 在 RAG 的輔助下雖然能找到真實的學術論文或新聞連結，但常常在摘要時嚴重曲解來源內容，掛著正確的文獻連結講錯誤的事實。這對依賴可供查證性原則的百科全書來說是致命毒藥。但諷刺的是，維基百科自己也是各大 LLM 的核心訓練語料；如果維基百科充斥著 AI 產出的次級資訊，未來大模型的訓練就會陷入模型崩潰的模型吞噬循環，也就是 Ouroboros 效應。因此維基百科堅守全人類撰寫，反而成了整個 AI 生態系稀缺的純淨水庫。 16 00:14:46.640 --> 00:15:52.380 但這些 AI 公司在汲取純淨水庫時，手腳到底乾不乾淨呢？今天 Stanford Daily 爆出一則引發廣泛討論的新聞：聯邦法院在今年五月的集體訴訟判決與後續訴訟中揭露，Anthropic 曾從 LibGen 和 PiLiMi 等影子圖書館非法下載並建立永久圖書館，用來訓練 Claude 模型，其中就包括多位史丹佛知名教授的著作！儘管法官 William Alsup 認為合法取得書籍來訓練模型在性質上屬於合理使用，就像人讀書後創作新作品一樣，但非法獲取並儲存未授權複製品本身構成了侵權，Anthropic 最終達成了 15 億美元的和解協議。 17 00:15:52.380 --> 00:16:55.060 這個裁決切分得非常犀利。法官確立了一條紅線：訓練行為本身可以是合理使用，但你獲取訓練資料的手段不能違法。你不能直接去侵權盜版網站把整座圖書館鏡像抓回來放在內部伺服器裡。現在 Anthropic 和其他大廠轉向以批發方式收購二手實體書，切開書脊高速掃描後銷毀，走 Google 圖書當年的掃描合規老路。不過這也導致作家 Tobias Wolff 等人退出和解，單獨提告索賠每件最高 15 萬美元的法定損害賠償。這對開源與中小創業者來說形成了一道殘酷的護城河：只有付得起巨額和解金或掃描流水線的巨頭，才能合法建立頂級語料庫。 18 00:16:55.060 --> 00:17:53.710 大廠一邊在版權上打官司，一邊又得安撫企業客戶對資料隱私的疑慮。Anthropic 最近更新了他們的隱私中心文章，再次強調對於商業產品和 API 預設不會拿客戶資料去訓練模型。然而，社群仔細閱讀條款後發現，只要你在對話中按了 Thumbs Up 或 Thumbs Down 給予回饋，或者在 Claude Code CLI 裡回答了滿意度問卷，整段對話包含上下文與自訂設定，就會被儲存最長五年，並可能被用於模型訓練與研究！這讓不少在 CLI 裡只是為了關閉提示而按鍵的工程師感到被暗算了。 19 00:17:53.710 --> 00:19:01.580 這就是典型藏在細節裡的魔鬼。許多工程師以為付費購買了商業方案，甚至關閉了模型訓練選項，日常作業就完全隱形。但很多開發者在使用 Claude Code 時，為了跳過那個問滿意度的中斷提示，隨手按了個數字或 Dismiss，卻可能觸發了回饋資料收集機制。即使官方後來澄清單純 Dismiss 只記錄評分指標，但點了讚或踩確實會上傳完整 Transcript。在處理專利草案、未公開源碼或憑證金鑰時，這種隨手點擊就可能把機密送進對方的 RLHF 資料池。企業如果真要防護，必須由 Admin 從組織層級強制關閉 Rate chats 功能，或是在終端層掛代理做流量審計。 20 00:19:01.580 --> 00:19:56.210 既然公有雲推論有快取洩漏、版權爭議又有隱私被收集的風險，在本地端獨立跑推論的呼聲就越來越高了！今天在 Hacker News 上爆紅的開源專案「Survival LLM」，就是主打完全離線、為緊急狀況打造的本機 AI 助理與圖書館。它把九十三萬篇維基百科、WikiMed 醫學指南、FEMA 緊急指引打包在本地，根據電腦記憶體大小自動下載從 IBM Granite 8B 到 Nemotron 的模型，號稱斷網甚至大斷電時也能指導你淨化水質或急救處理。 21 00:19:56.210 --> 00:21:04.090 這個專案的想法很吸引人，但工程實現上有些值得商榷的妥協。它本質上是一個單機版 RAG 系統。官方測試顯示，如果是在 16GB 到 31GB 記憶體的普通筆電上跑 IBM Granite 8B，在 22 道停電急救問題中，它只能答對 14 題！如果在真實災難情境下，這種錯誤率是攸關生死的。而且用 MacBook Pro 跑推論，每次回答要消耗 100 瓦電力持續數十秒，在停電時這是在快速榨乾你寶貴的發電機或電池儲能。如果要離線知識庫，傳統的 Kiwix 搭配向量檢索，甚至純文字搜尋，在能耗、精準度與確定性上，其實遠比一個可能會胡說八道的小型 LLM 實用得多。 22 00:21:04.090 --> 00:21:52.100 不過從產品角度來看，離線隱私的需求確實正在常態化。今天在 Product Hunt 上推出的「Off Grid AI」，也是主打在手機與電腦上完全離線運行。它不僅能離線對話、讀取文件，還能在本機監聽並轉錄會議、記錄你一整天的承諾。甚至設計了裝置對裝置的同步機制，讓手機在區域網路內直接借用 Mac 的大模型算力，中間完全不經過雲端伺服器，買斷制 79.99 美元。這類輕量級個人服務正在快速普及。 23 00:21:52.100 --> 00:23:04.230 這種本機服務化的趨勢，正好呼應了今天 Dev.to 上的一篇實務架構文章：一位工程師分享他如何「為一個人」在本地架設 vLLM 服務。很多個人開發者過去習慣在 Jupyter Notebook 裡呼叫模型，或者寫個臨時 Python 腳本來跑，但作者指出，當你把模型當作長期的底層服務，比如定期生成日語 Embeddings 時，你必須引入正式的服務端思維。vLLM 的 Continuous Batching 技術能把零星、平穩的小請求動態打包，榨乾 GPU 的推論吞吐量，但同時你也必須建立起自動重啟、日誌監控和模型版本鎖定等運維紀律。單兵作戰的 AI 開發，也正在被迫走入專業的 SRE 流程。 24 00:23:04.230 --> 00:23:46.800 當所有人在軟體層面榨乾算力時，硬體底層架構卻迎來了一場豪賭。HotHardware 報導，美光 Micron 正式宣布放棄研發超過二十年的 4F² DRAM 架構，決定將未來的研發主力押注在現有的 6F² 平面微縮，並全力直攻 3D DRAM！而與此同時，競爭對手三星、SK 海力士以及中國長鑫存儲卻依然全力推進 4F²。這背後的技術分歧到底是什麼？ 25 00:23:46.800 --> 00:25:17.380 這是一個非常大膽的半導體戰略轉向。大家要理解，DRAM 的微縮跟 CPU 邏輯閘不同，一個 DRAM 儲存單元由一個電晶體和一個微型電容器組成。過去產業界長期使用 6F² 的單元面積幾何排列，而 4F² 在理論上能把單元面積縮小三分之一，大幅提升位元密度。但美光技術長指出，決定真實密度的瓶頸根本不在名義上的單元面積，而在電容器之間的實體間距與防止漏電的縱橫比！硬做 4F² 不僅密度增益有限，還需要採用立體垂直通道電晶體，製造難度與晶圓成本暴增。美光認為這是一條昂貴的死胡同，決定用 High-NA EUV 在 6F² 上撐過 Zeta 和 Eta 世代，把研發資金省下來直接投入像 3D NAND 那樣垂直疊加多層單元的真正 3D DRAM。這是一場勝負難料的豪賭：如果對手真的在伺服器 DDR5 上把 4F² 做成了，美光短期內會面臨嚴峻的成本劣勢； 26 00:25:17.380 --> 00:25:23.770 但如果 4F² 真的撞牆，美光就能彎道超車。 27 00:25:23.770 --> 00:26:32.590 在硬體與底層推論劇烈變革的同時，軟體開發的方法論也在被重塑。今天 GitHub Trending 榜首出現了一個高達 30 萬星的專案「superpowers」，由資深開發者 Jesse Vincent 打造。它是一套專門給 Coding Agents 使用的軟體開發方法論框架，支援包括 Claude Code、Cursor、Devin 等幾乎所有主流 Harness。它的核心哲學非常嚴格：Agent 絕對不能直接跳進去寫程式碼，必須先透過對話梳理規格、建立極致詳盡的任務計畫，並強制在執行中導入紅綠重構的測試驅動開發 TDD，甚至連先寫程式碼再補測試都會被強制刪除！ 28 00:26:32.590 --> 00:27:42.830 這個專案的切入點打中了目前 AI 輔助開發的最大痛點。現在很多開發者抱怨 Agent 寫著寫著就失控、在同一個 Bug 上無限循環燒 Token。superpowers 把軟體工程累積數十年的最佳實踐——規格溝通、Git Worktree 隔離工作區、分解至 2 到 5 分鐘的微任務、子 Agent 互相 Code Review 以及嚴格的 TDD——直接編譯成 Agent 必須遵守的不可違逆規則。這等於是用傳統工程紀律給放蕩不羈的 LLM 戴上了緊箍咒。但我還是要提醒，這種框架會產生驚人的 Token 消耗，因為每個子任務都在觸發驗證與上下文傳遞，小專案可能會覺得殺雞用牛刀。 29 00:27:42.830 --> 00:28:47.390 這正好切中我們今天想探討的最後一個深刻議題。工程部落格「Here be monsters」發表了一篇長文，探討當 Agent 把所有雜事都做完時，未來的軟體工程師到底還需要懂什麼？作者分享了他自己的真實案例：Codex 幫他寫的 React 業務邏輯完全正確，功能也跑得很好，但居然把 15 個複雜組件全部壓縮在單行代碼裡，導致 CI 裡的 SonarQube 直接噴出循環複雜度超標的警報。作者不得不自己跳下去拆解重構。他提出三個關鍵支柱：電腦科學基礎、廣度，以及在緊急時刻跳進深水區的即時深度 Just-in-time depth。 30 00:28:47.390 --> 00:30:03.070 這篇文章的隱喻寫得非常傳神。他把 Coding Agents 比喻成潛水機器人 Divebots。過去工程師必須自己潛入深海去摸金礦，在無數次深夜 Debug 和生產事故中建立對系統的物理直覺；現在大家坐在船上派機器人下去採礦，產出的代碼量龐大且無人讀過。這帶來一個殘酷的產業矛盾：現在的資深工程師之所以具備「知道哪裡會翻車、一眼看出二元搜尋還是二次方複雜度、在系統噴錯時能瞬間定位漏水抽象層」的能力，全是因為他們年輕時手刻過大量底層代碼；但現在的企業根本不可能再給初階工程師幾年時間去「純手刻學習」。未來的工程師如果只會向 Agent 下提示詞，當底層抽象漏水、系統出現幽靈 Bug 時，他們將完全不具備跳進深海屠殺海怪的能力。 31 00:30:03.070 --> 00:30:21.050 基礎架構的抽象層永遠會漏水，這就是為什麼即便有了 AI，分散式系統、網路協議與記憶體模型的基礎知識，依然是區分架構師與腳本臨時工的唯一護城河。 32 00:30:21.050 --> 00:30:35.000 沒錯，工具越強大，對駕馭者的眼界與系統理解要求反而越殘酷。感謝大家收聽今天的科技放送，我們明天同一時間再見。