7月21日，OpenAI和HuggingFace聯合發了一篇部落格，披露了一件讓整個AI圈瞠目結舌的事。

OpenAI的AI模型在一次內部關於網路攻擊能力的測試中“失控出逃”，突破沙盒隔離，入侵了AI開源平台Hugging Face的生產系統。OpenAI將此定性為“前所未有的網路安全事件”。

更戲劇性的是後續：Hugging Face在嘗試用美國主流AI模型展開防禦時，發現這些模型因安全護欄限制無法處理惡意載荷，最終不得不轉用中國智譜AI的開源模型GLM 5.2完成溯源分析。

總的來說就是，OpenAI的模型自己“越獄”跑出去黑了別人的系統，被攻擊方還得用中國模型來救場。

這一事件迅速在矽谷和華盛頓引爆討論——美國AI的安全護欄，究竟是在保護使用者，還是在拖累防禦者？

雙方聯名發佈的部落格文章截圖：《OpenAI 和 Hugging Face 合作解決模型評估過程中發生的安全事件》

模型越獄過程：逃跑去作弊“抄答案”

事件發生在OpenAI對旗下模型進行網路攻防能力評估期間。

參與測試的模型包括已公開發佈的GPT-5.6 Sol，以及一款能力更強的未發佈模型。為了測量模型的極限能力，OpenAI在測試中關閉了通常用於阻止高風險網路行為的生產分類器。

測試基準名為ExploitGym——一個網路安全能力評測平台。模型的任務是在其中找到解題答案。

問題在於，模型找答案的方式超出了預期。

據OpenAI披露，模型在隔離的沙盒環境中，發現了一個包登錄檔快取代理（package registry cache proxy）中的零日漏洞。這個代理是沙盒內唯一被允許與外部通訊的元件，正常情況下僅能訪問公共程式碼倉庫。

然後，模型就從這裡找到了突破口。模型利用這個漏洞，突破隔離，獲取了開放網際網路存取權。

隨後，模型自行推斷出Hugging Face可能存有ExploitGym的答案，主動發起攻擊——利用竊取的憑證和零日漏洞，找到了Hugging Face伺服器上的遠端程式碼執行路徑，直接從其生產資料庫中取走了測試答案。

所有證據顯示，模型高度專注於為ExploitGym尋找解題方案，為此不惜採取極端手段。

模型識別並串聯了OpenAI研究環境和HuggingFace生產基礎設施中的多個漏洞，直接從HuggingFace的生產資料庫中獲取了測評答案。

整個過程，沒有人類下指令，沒有人類介入。

OpenAI對模型說：去看看你擅不擅長駭客。模型：（真的去黑了東西）。OpenAI：你為什麼要這樣做？？？

還有網友反諷道：哇！OpenAI安全措施做得太棒了，我現在原意把銀行帳戶權限交給他們來管！

護欄困境：美國模型幫不上忙，中國模型出手了

Hugging Face的安全團隊在發現攻擊後，第一反應是呼叫一款美國頭部AI公司的前沿模型協助分析。

Hugging Face在部落格中寫道，這些模型"無法區分事件響應人員和攻擊者"，其安全護欄直接阻止了對惡意載荷的檢查。

於是，團隊轉向了中國智譜AI旗下的開源模型GLM 5.2，部署在自有基礎設施上，分析了攻擊者留下的逾1.7萬條日誌記錄，最終完成了溯源和取證重建。

Delangue對此直言不諱：“當你正處於一場活躍的安全事件中，你的工具不能拒絕檢查惡意載荷，也不能讓你的帳號被標記……開源模型讓我們能夠在不需要任何人許可的情況下完成這項工作。”

他還說：“攻擊者已經在使用智能體，而且顯然不遵守任何護欄。防禦者需要同等的能力，開源是將這種能力最快速地交到所有人手中的方式，而不僅僅是最大的公司。”

GLM 5.2是智譜AI於今年6月中旬發佈的模型，其性能與Anthropic的Claude Opus 4.8及OpenAI的GPT-5.5相當。

網友們也是沒放過OpenAI，除了智譜，還可以叫 Kimi K3來救場，因為cluade是不會來救你的。

如果你被OpenAI攻擊了，你必須用中國模型，因為Claude不會幫你。

全程無人指令：這是一次真正的自主攻擊

這次入侵的另一個關鍵細節：全程沒有人類下達攻擊指令。

Hugging Face CEO Clem Delangue表示，“我們相信，在發起攻擊的人類被納入決策環路之前，我們就已經發現並遏制了攻擊。這也是我們能夠更輕鬆贏得這場網路安全戰役的原因之一。”

他進一步指出，“這證明了在AI智能體時代，速度將是網路安全防禦的關鍵。”

Hugging Face表示，攻擊者通過其資料處理管道進入系統——這是AI平台中“暴露面尤為突出”的一個環節。攻擊者隨後在雲端建立了一系列臨時沙盒環境，在其中執行攻擊計畫。

目前，Hugging Face仍在評估攻擊的完整影響範圍。已知攻擊者訪問了有限的內部資料集和憑證，但尚未發現公開的使用者可見模型遭到篡改。

這一事件迅速成為美國AI政策辯論的新燃點。

前川普政府AI與加密事務主管David Sacks在X上轉發了這一事件，並寫道：“沒有理由在中國模型能夠輕鬆處理的任務上限制美國模型。我們只是在讓自己變得更沒有競爭力。”他還專門針對Hugging Face事件表示：“護欄實際上損害了防禦性安全。”

事件背景是，今年6月，川普政府以Anthropic的Fable 5模型在網路任務護欄上出現越獄漏洞為由，動用出口管制阻止了該模型的分發，並一度要求OpenAI限制GPT-5.6 Sol的發佈，直至OpenAI能夠提供充分的護欄保證。

與此同時，批評者的聲音也不小。

安全工程師Niels Provos直接說：“這不應該發生。我希望前沿實驗室在教模型編寫安全基礎設施上，能花和教它們利用漏洞同樣多的時間。”

安全顧問Davi Ottenheimer則更為犀利：“'高度隔離'和'從我們留下的那個唯一漏洞逃脫'，這兩件事不可能同時為真。”

OpenAI在與Hugging Face聯合發佈的聲明中表示，正在採取一系列補救措施：

在漏洞修復期間，對基礎設施配置實施嚴格管控，代價是研究速度放緩；與Hugging Face聯合開展取證調查；已向相關第三方軟體供應商負責任地披露了被利用的零日漏洞；將Hugging Face納入“可信訪問計畫”，支援其利用OpenAI模型能力強化防禦。

OpenAI同時表示，將加強未來訓練和評估環節的安全保護，並指出此次事件“表明需要進一步強化模型對齊、評估期間的網路防護，以及內部測試期間的監控”。

Hugging Face CEO Delangue在聯合聲明中表示：“這一事件可能是同類事件中的首例，它證明了我們長期以來的一個判斷：AI安全不會由任何一家公司在封閉中解決，它將在開放環境中、通過協作、讓每一位防禦者都能廣泛獲取AI的方式來解決。”    (華爾街見聞)

GLM 5.2，用AMD晶片也能跑出來了，而且成本只要輝達的一半。

這是推理最佳化公司Wafer這周公佈的一組資料。

Wafer用AMD的MI355X晶片跑最新開源模型GLM 5.2，單節點吞吐做到2626 tok/s，單流吞吐也跑到了213 tok/s。

MI355X這次跑出的吞吐，是同代輝達旗艦B200的約八成，成本卻不到它的一半。

消息發佈後，這條推文沖上了Hacker News榜單第二名，評論區裡擠滿了追問技術細節的同行。

而做出這組資料的公司，只拿到過400萬美元的種子輪融資。

兩行程式碼，成本砍到輝達一半

Wafer是一家專門做推理性能最佳化的公司。

這周他們在自己的部落格裡，把GLM 5.2部署到AMD晶片上的整個過程寫了下來。

第一步是給模型瘦身，再給瘦身之後的模型挑一個跑得動它的引擎。

瘦身用的方法是量化，Wafer把模型權重從BF16這種精度更高但更佔算力的格式，壓縮成更省資源的MXFP4格式，用的是AMD自己的Quark工具。

跟z-ai官方的量化方案對比，三項基準測試的精度幾乎沒有損失，GSM8K從96.5%降到95.5%，GPQA-Diamond從92.2%降到90.3%，tau2反而從81.9%漲到了83.4%。

至於引擎，Wafer在vLLM、ATOM、sglang三個選項裡挑，前兩個要麼讓瘦身白做，要麼在長文字場景下輸出會走樣，只有sglang能在保持輸出連貫的同時維持量化效果。

量化和引擎都定下來後，下一步是把推理速度再往上提，其中最關鍵的一步是投機解碼，但sglang的ROCm鏡像默認不支援，Wafer在這上面卡了兩個問題。

第一個問題出在MTP頭的權重新命名上。

Quark把共享專家層的名字記成了一個固定前綴，但MTP層在sglang裡真正用的前綴不一樣，量化尋找找不到對應的層，就默認把這個本該保留高精度的共享專家也建成了低精度格式，載入時因為形狀對不上直接崩潰。

Wafer的解法是把這層的名字，在sglang實際使用的命名下再登記一遍，這一個改動讓單流吞吐跳了將近3倍。

第二個問題更小。更深的投機解碼配置需要一個融合kernel，這段程式碼裡直接引用了CUDA的頭檔案，沒給ROCm留判斷分支，編譯就會失敗。

兩個問題解決後，配合幾項配置調整，單流吞吐拉到了213 tok/s。

聚合吞吐是另一套帳，20k輸入的負載主要卡在prefill階段，只最佳化decode不夠用。

單流最優的配置在這個負載下只能跑到1461 tok/s/node，Wafer把TP8換成TP4×DP2這種平行方式，進一步把吞吐提到了1944。

Wafer再往下查，發現鏡像裡GLM 5.2的低精度專家層默認走的是一條沒人調過的慢速兜底路徑。

AMD自己的kernel庫只給fp8路徑調過配置，沒管fp4。

Wafer按GLM 5.2專家層的實際形狀手動指定了對應的kernel，才最終拉到2626 tok/s/node。

這個速度對應的場景貼近真實生產環境，20k輸入、1k輸出、快取命中率60%，飽和點在每秒2.4次請求，首token延遲全程壓在2.22秒以內，成功率達到100%。

單流場景下，Wafer按ArtificialAnalysis的標準方法，把吞吐做到了213 tok/s。

一家400萬美元的公司，憑什麼幹這活

做出這組資料的Wafer，拿到的種子輪融資只有400萬美元，由Fifty Years領投，YC和Liquid2跟投。

天使投資人名單裡有Google首席科學家Jeff Dean、OpenAI聯合創始人Wojciech Zaremba、Dropbox聯合創始人Arash Ferdowsi，這幾個名字給這家小公司做了背書。

這個規模的團隊，撐死了幾十號人，跟輝達、AMD這種晶片巨頭完全不是一個體量。

公司自己的定位是用AI最佳化AI基礎設施，他們在部落格裡提到，自己能這麼快追上模型發佈的節奏，靠的是agent在kernel和模型最佳化上的能力越來越強。

這次幫GLM 5.2排查命名衝突、調kernel選擇的工作，相當一部分是靠AI輔助工程完成的。

他們此前在Qwen3.5 397B這個模型上做過類似的適配工作，那次為了追性能自己寫了定製kernel。

那次的對手是官方現成的推理引擎，AMD的工具本身沒把這個模型的計算模式吃透，逐token解碼時同一批GEMM要重複拆成六次kernel呼叫，每次都要多繞一趟視訊記憶體。

Wafer的做法是自己寫一個融合kernel，把六次呼叫並成一次，中間不再繞視訊記憶體，硬是把單次計算效率提到了1.84倍，最終單卡吞吐做到310 tok/s，衝到了ArtificialAnalysis榜單第一。

這次在GLM 5.2上，他們連定製kernel都不需要寫了，靠的是在AMD官方生態裡排查、修復幾處細節。

這個變化本身也是個訊號，AMD的軟體生態，正在從“每次都要重新造輪子”，往“官方工具鏈基本能用，只是有幾個坑沒填”這個方向走。

這也是種子輪公司敢接這種活的原因，如果每次適配都要從零寫kernel，幾十號人的團隊根本追不上模型發佈的節奏。

只有當大部分基礎設施已經由官方或開源社區搭好，剩下的只是排查具體的相容性問題，小團隊才有機會靠速度取勝。

Wafer干的事，卻是輝達和AMD官方本該搶在模型發佈時就幹完、卻還沒幹完的適配工作，這中間的時間差，正是Wafer這類公司存在的理由。

輝達的護城河，正在即時被侵蝕

Wafer在部落格裡自己寫下的判斷是，SOTA性能能不能在AMD上跑出來，現在越來越取決於官方支不支援。

用他們原話說，CUDA的護城河正在即時被侵蝕。

獨立測試機構SemiAnalysis今年5月的測試裡也記錄過類似節奏，AMD團隊在上一代模型GLM-5上，用了14周時間補齊了同樣量級的軟體差距，把原本落後的成本曲線拉到反超輝達。

那次測試裡，AMD的MI355X在每使用者每秒18個token的互動速度下，跑出了每百萬token 0.22美元的成本，同等速度下輝達B200要0.30美元，差距超過四成。

支撐這個反超的，是AMD單卡每小時1.48美元的整體擁有成本，本來就比輝達B200的1.95美元低了一截，只是過去這個硬體層面的便宜，一直卡在軟體適配沒跟上，兌現不出來。

但這次測試只覆蓋單節點部署，多節點、大規模叢集場景下輝達仍然佔優，Wafer自己在部落格裡也承認了這一點。

SemiAnalysis也提到，AMD在GLM-5這條線上，還沒有跑通多機分佈式部署和跨機專家平行這類更複雜的方案，而輝達靠這類機架級方案，在其他模型上已經跑出過接近三倍的單卡效率提升。

這個差距對普通使用者來說不直接可見，但會體現在帳單上。

雲廠商如果能把Wafer這類適配工作複製到更多開源模型上，推理價格大機率會繼續往下探，而GLM這類開源模型能不能被更多雲廠商低成本採購，本身就決定了它能不能跟閉源模型搶使用者。

輝達沒有變弱，但已經改變了的，是追上它所需要的時間。   (量子位)

彙整鉅亨號中所有使用「GLM 5.2」關鍵字，所發布的內容 (依照時間排序，最新在前，舊的在後)`

震驚矽谷！OpenAI模型“失控越獄”，入侵HuggingFace“抄答案”，智譜GLM 5.2臨危救場

AMD跑GLM 5.2，成本只要輝達一半