WEBVTT NOTE Title: [2026-11-13] 黃仁勳閃辭震盪半導體、Apache 與 Postgres 雙爆史詩級 RCE 1 00:00:00.000 --> 00:00:35.140 歡迎收聽 DAVID888 Daily 每日放送，我是 Cordelia。今天科技圈迎來了一顆真正的核彈級震撼彈：NVIDIA 創辦人兼執行長黃仁勳無預警宣布辭職！在 AI 算力軍備競賽最白熱化的節骨眼上，帶領全球最具價值晶片帝國的靈魂人物竟然退場，瞬間引發華盛頓與科技巨頭們的劇烈震盪。 2 00:00:35.140 --> 00:01:18.530 我是 David。這起辭職案背後的時機點極其敏感。恰好在今天，一項針對中國頂尖 AI 模型的權重鑑識報告公開，指出 DeepSeek-V4、月之暗面 Kimi K3 等模型內部，帶有受到美國出口管制的 NVIDIA Blackwell 架構硬體指紋。在供應鏈外流疑雲與地緣政治審查的多重夾擊下，這場人事震盪對整個半導體與 AI 產業的衝擊，絕對是海嘯等級的。 3 00:01:18.530 --> 00:01:54.850 我們就先來深挖這份由 Unemployment Labs 釋出的模型鑑識報告。研究員 Will DePue 居然僅憑公開發布的模型權重，就推導出訓練初期所使用的 GPU 核心數！這在技術上到底是怎麼辦到的？不是常說神經網路經過數萬億個 Token 訓練後，初始化的痕跡早就被梯度更新給沖刷殆盡了嗎？ 4 00:01:54.850 --> 00:02:55.460 這正是這篇報告在工程上極其精彩的地方。在 PyTorch 架構下，張量初始化依賴 Philox 偽隨機數生成器，並透過 cuRAND 派發到 GPU 執行緒。每個串流多處理器（SM）會被指派固定數量的執行緒，比如 2048 個。當你初始化數十億參數的大矩陣時，執行緒是跨 SM 平行步進填入數值的。這意味著：132 個 SM 的 Hopper 架構，與 148 個 SM 的 Blackwell B200，或者 152 個 SM 的 GB200，其隨機數填入陣列的跨步（stride）和相對位置完全不同！ 5 00:02:55.460 --> 00:03:23.760 也就是說，只要找到模型中沒有被訓練更新到的死角，比如詞表裡極罕見的保留 Token，那些權重就宛如地質化石一樣，忠實記錄了當初填入時的隨機數分佈。研究員就是靠著暴力比對種子碼和 SM 數量，抓出了 Blackwell 的硬體配置！ 6 00:03:23.760 --> 00:04:24.130 沒錯，他們在 DeepSeek-V4-Flash 發現了 148 SM 的吻合，而在 Kimi K3 上比對到了 152 SM。甚至在兩者皆可模擬的 AMD MI300X 交叉驗證中，透過微小的浮點運算差異，排除了 AMD 的可能性。不過我們在工程推論上也必須保持客觀：硬體指紋僅證明模型是在 Blackwell 上執行『權重初始化』，無法直接定罪整個數月的大規模訓練都在這些受管制硬體上完成；況且中國企業也可能合法租用新加坡或馬來西亞的海外資料中心。但無論如何，這份技術證據在政治上已經足夠引爆風暴。 7 00:04:24.130 --> 00:05:08.470 地緣政治風暴還在延燒，但基礎設施層的資安世界今天也迎來兩記重錘。首先是老牌網頁伺服器 Apache HTTP Server 爆出嚴重的遠端程式碼執行漏洞 CVE-2026-119618，雲端安全廠商 Wiz 甚至警告全球超過六成的雲端環境都暴露在風險中！這是不是有點像我們在 10 月 25 號聊過的 http2shell 危機，問題又出在 HTTP/2 的實作上？ 8 00:05:08.470 --> 00:06:10.490 沒錯，又是 HTTP/2！如果聽眾想重溫當時的背景，可以回去聽 10 月 25 號那一集。這次 Apache 的致命傷在 mod_http2 模組的 `assign_headers()` 函式。HTTP/2 本質上是高度多工的二進位協議，多個 Stream 共用同一個 TCP 連線。當並行執行緒同時存取並指派標頭資源時，缺乏完善的同步鎖機制，導致了經典的競爭條件（Race Condition）。攻擊者可以藉由精心構造的並行標頭訊框引發堆疊損壞（Heap Corruption），進一步控制記憶體指標達成 RCE。 9 00:06:10.490 --> 00:06:40.920 更可怕的是社群有人回報，只要利用 AI 輔助分析，短短幾分鐘內就能重現出利用腳本。雖然官方在 2.4.71 修復了這個競爭條件，但很多運維人員在無法立刻停機重啟的情況下，唯一的緊急緩解措施就是直接在設定檔停用 HTTP/2，退回 HTTP/1.1。 10 00:06:40.920 --> 00:07:22.420 但退回 HTTP/1.1 又有連線重複建立與 Request Smuggling 的架構代價，這就是現實中的技術取捨。說到記憶體毀損，今天第二個資安震撼彈更加離奇：資安研究員 Mehmet Ince 居然把一個存在於 PostgreSQL 核心長達 22 年的複合型別錯誤，串成了一套完美的遠端程式碼執行鏈，編號 CVE-2026-6460！ 11 00:07:22.420 --> 00:07:41.050 22 年！這段程式碼比很多現代工程師的資歷還要老吧！他是怎麼把資料庫的型別機制玩弄於股掌之間，甚至連現代作業系統的 ASLR 防禦都能硬生生繞過的？ 12 00:07:41.050 --> 00:08:26.800 這套攻擊的底層原理極為優雅。Postgres 內部傳遞資料是用一個 8 位元組的萬能容器 `Datum`，但 Datum 本身是無型別的，它到底代表一個純數字還是指向外部結構的指標，完全取決於查詢樹解析當下的型別中繼資料。攻擊者先建立一個包含 UUID 的自訂複合型別，編譯一個 PREPARE 預備語句，此時記憶體中填入的是攻擊者完全可控的 16 位元組 UUID 原始資料。 13 00:08:26.800 --> 00:08:30.810 接著在執行前，偷天換日！ 14 00:08:30.810 --> 00:09:26.710 正是！攻擊者透過 `ALTER TYPE` 將該欄位動態改成 `bytea`，再呼叫 `EXECUTE`。Postgres 在輸出結果時呼叫 `byteaout()`，以為拿到了二進位資料，卻被開頭的特定位元組誤導，認為這是一個指向擴展物件的記憶體指標！攻擊者藉此偽造了包含虛擬函式表的物件，把回呼函式直接指向 `system()`，達成無授權提權的任意命令執行。這逼得 Postgres 核心團隊一次發布了 52 個 CVE，並對複合型別引進嚴格的版本控制機制。 15 00:09:26.710 --> 00:09:51.000 看到 C/C++ 寫的大型系統不斷在記憶體安全與型別混淆上踩坑，就讓人更加理解為什麼業界對記憶體安全語言如此渴望。正好，今天 Rust 正式迎來了歷史性的里程碑——Rust 1.100.0 發布！ 16 00:09:51.000 --> 00:10:41.460 歷經十年奮戰、五次穩定化失敗的 Never Type，也就是驚嘆號 `!`，終於正式進入 Stable 了！從型別論來看，`!` 是底層型別（Bottom Type），代表永不結束的發散運算，例如無窮迴圈、panic 或行程退出。過去你只能在函式回傳值寫 `-> !`，現在它成為一等公民，你可以寫 `Result` 來明確表達一個絕不可能失敗的操作，在編譯期直接省略錯誤處理分支，大幅提升了代碼的嚴謹度。 17 00:10:41.460 --> 00:11:20.380 不僅如此，這次 1.100 還穩定了自訂 Allocator API 的核心部分，允許 `Vec` 和 `Box` 掛載特定記憶體配置器，這對嵌入式系統、高頻交易與遊戲引擎簡直是天降甘霖。另外像 Cargo 的相依套件冷卻期機制 `min-publish-age`，以及自動警告未使用的依賴，都直接補強了軟體供應鏈安全。 18 00:11:20.380 --> 00:11:56.220 不過 Rust 陣營依然面臨工程師們最痛恨的宿疾：編譯時間太長。就算 1.100 改善了快取目錄碰撞，遇到龐大專案依然動輒幾十分鐘。而今天 Hacker News 上另一款黑科技專案『Relax』，就大膽向傳統 rustc 和 LLVM 宣戰！它居然為 Rust 打造了一套純 JIT 編譯器！ 19 00:11:56.220 --> 00:12:29.950 這專案太瘋狂了！43.8 萬行純 Rust 打造，完全拋棄 LLVM、rustc 和系統連結器。它宣稱大型 3D 遊戲從原始碼到第一幀渲染只要 11 秒，冷啟動直接縮減一個數量級，甚至支援儲存檔案時自動熱修補正在運行的程序！David，這真的能在生產環境取代 rustc 嗎？ 20 00:12:29.950 --> 00:13:27.730 冷靜一點，天下沒有白吃的午餐。Relax 的定位是『開發階段的即時回饋迴圈』，它的代價非常明確：最佳化後的程式碼執行效能，平均比 rustc 慢了 12% 到 25%，記憶體消耗也因為 JIT 編譯快取的常駐而大幅膨脹。更關鍵的是，它的借用檢查器（Borrow Checker）是放在背景異步執行的！也就是先跑再說，檢查出錯才在視窗跳出警告。對 AI Agent 或 UI 熱更新來說，這是用單核運算速度換取開發迭代速度的絕佳權衡；但發布正式版本時，你還是得乖乖換回 rustc。 21 00:13:27.730 --> 00:13:53.430 說到開發者迭代速度與 AI 工具的深度整合，Google Antigravity 團隊今天正式推播了 Gemini 4 Hydrogen 模型，並且祭出了名為『Orchestrator』的雙模型協作編排架構！ 22 00:13:53.430 --> 00:14:46.020 這正好擊中了當前 Agent 開發的痛點。過去業界要嘛是用最貴的旗艦模型從頭推到底，浪費昂貴 Quota；要嘛是用簡單的靜態路由，在任務一開始猜測難度並派發給便宜模型。但工程任務往往是在執行中才發現複雜度的。Orchestrator 讓 Gemini 4 Carbon 負責前端高難度的架構規劃與依賴分析，接著把具體的程式碼修訂與測試交給輕量高速的 Hydrogen 執行；一旦遇到非預期的報錯摩擦，再動態交回 Carbon 重新規劃。 23 00:14:46.020 --> 00:15:31.300 這讓 Terminal-Bench 的基準測試在維持旗艦級成功率的同時，節省了 24% 的 Token 配額並加快 19% 的反應速度。這也呼應了今天 DEV.to 上 Luke Liukonen 發表的熱門文章《收復開發者敏捷度：5 層 AI 最佳化架構》。他指出大家總愛盲目堆疊 Prompt 長度，但其實最關鍵的是 Harness（環境收束）與 Loop（迴圈治理）。 24 00:15:31.300 --> 00:16:09.510 Luke 的觀點非常務實。例如在 Agent 內部測試迴圈中，絕對不要把數兆位元組的完整 stderr 塞回 Context Window，而是在本機留下日誌檔，只回傳確定性的 Exit Code 和最後 10 行關鍵 Stack Trace。AI 優化的本質是『減少無效工作』，而不是讓模型在海量雜訊裡反覆空轉。 25 00:16:09.510 --> 00:16:47.480 而 OpenAI 顯然也想把這套程式碼掃描與自動修復的工程標準化，今天 GitHub Trending 榜首就是他們的 `codex-security` CLI 與 SDK，星星數直接突破一萬二！它直接整合進 CI/CD，支援從威脅建模、漏洞掃描到產生補丁的一條龍流程，甚至能橫跨多個 Repo 分析系統相依性。 26 00:16:47.480 --> 00:17:40.770 這其實是 DevSecOps 的必然進化。但工程師必須注意它的計費天花板與假陽性驗證成本。`codex-security` 支援將掃描匯出為 SARIF 格式對接 Jira 或 GitHub，這能有效防止安全團隊被 AI 產生的海量低風險警報給淹沒。說到多 Agent 同時在本地運行的資源瓶頸，Product Hunt 上今天有一款名為『Sluice』的工具吸引了不少目光，號稱能在 Mac 上流暢並行 20 個 Agent 進行建置工作。 27 00:17:40.770 --> 00:18:25.580 同時跑 20 個 Agent 對本機記憶體和磁碟 I/O 確實是極大負擔，這類資源排程工具正好填補了多工自主 Agent 的桌面痛點。而如果你的硬體更極端呢？GitHub 上另一個名為 `smolmaxxing` 的專案，竟然把 160 億參數的 MoE 大模型塞進了 2013 年的第一代 iPad Air 和小米電視盒！這些設備的可用 RAM 只有不到 1GB 啊！ 28 00:18:25.580 --> 00:19:16.290 這是我今天看到最硬核的底層調優專案。作者針對沒有向量點積指令的 Apple A7 晶片，手寫了極致的 1-bit 查找表核心；更關鍵的是架構取捨：MoE 專家模型每個 Token 只需要啟動少數專家，他把最常用的專家常駐在 1GB 的記憶體中，其餘冷門專家則是以快閃記憶體全速動態分頁（Paged from flash）載入！利用預取機制跑出每秒 5 個 Token 的推理速度，展現了邊緣裝置挖掘殘存算力的極致想像力。 29 00:19:16.290 --> 00:19:46.940 從老舊邊緣硬體的算力榨取，我們再轉頭看看現代晶片架構的巔峰。知名硬體評測網站 Chips and Cheese 專訪了 AMD 傳奇架構師、被譽為『Zen 之父』的 Mike Clark，深度揭露了次世代 Zen 6 與 Zen 6c 的微架構秘密！ 30 00:19:46.940 --> 00:20:44.490 這篇訪談含金量極高！Mike Clark 證實了 Zen 6c 不再只是 Zen 4/5 時代那種純粹為了節省晶片面積的縮減版，而是晉升為極致 IPC 性能核心，塞滿完整的 4MB L3 快取。為了克服 Zen 5 的前端雙解碼叢集同步瓶頸，Zen 6 重新梳理了 I-Cache 與 Op-Cache 的管線；整數乘法單元從三個退回兩個，換取分散式排程器更優秀的面積與能效比；同時在向量管線中硬塞了兩組 VNNI 單元，補強了 CPU 應對邊緣小模型與推論資料格式轉換的能力。 31 00:20:44.490 --> 00:21:20.810 在科技與硬體技術不斷演進的同時，版權巨獸的鐵鎚也毫不留情。任天堂近日發動了大規模 GitHub DMCA 掃蕩，一口氣抄掉了包括 Switch 模擬器 Yuzu、Citron Neo 以及 Picofly 晶片韌體在內的上百個儲存庫。特別是針對硬體防篡改措施（TPM）的繞過行為，法務攻勢極其猛烈。 32 00:21:20.810 --> 00:21:54.290 任天堂這次緊咬的是美國 DMCA 第 1201 條的『反規避條款』。雖然模擬器本身的原始碼在法律上有逆向工程的合理使用抗辯空間，但一旦涉及繞過金鑰認證或硬體 Modchip 韌體，法律邊界就徹底失守。在開源與專有硬體版權的漫長戰爭中，這場貓捉老鼠的遊戲短期內依舊看不到終點。 33 00:21:54.290 --> 00:22:20.000 今天從晶片帝國領導人的去留、底層核心的史詩級漏洞，一路聊到極致的編譯器革命與軟硬體極限調優，科技世界的變局正以令人窒息的速度推進。感謝大家的收聽，DAVID888 Daily 每日放送，我們明天同一時間再見！