輝達拿 35 億美元認購聯發科可轉債，最想賣的不是 GPU

今日漫畫 出演・水無瀨 澪

輝達拿出 35 億美元認購聯發科的海外可轉債，占這筆 39 億美元募資的近九成。錢的用途不難猜，難猜的是黃仁勳為什麼歡迎客製化晶片進到自己的機櫃裡。

美國商務部那邊則在研擬另一件事：把 AI 出口管制從實體晶片延伸到遠端算力。社群現場，同一顆 Qwen 3.8 27B 這週被人榨出了差距好幾倍的速度。

輝達花 35 億美元，買的是 XPU 旁邊那些東西

聯發科 8 月 31 日宣布完成總額 39 億美元的海外可轉換公司債訂價，輝達認購其中 35 億美元。Alphabet 也參與了這次認購，但沒有揭露金額。

錢只是這件事的一半。兩家同步深化 AI 基礎建設合作，聯發科將採用 NVLink Fusion 平台，協助客戶開發客製化 XPU，再把這些晶片接進輝達以 NVLink 串連的機櫃級基礎設施。

為什麼客戶需要這一層？因為做出一顆 XPU 之後，還不能直接拿去蓋資料中心。

• 晶片必須和 HBM、CPU、交換器等設備連接
• 還要處理高速互連、先進封裝與整套系統驗證
• 這些工作若全由客戶自行完成，工程複雜、也會拉長產品推出時間

NVLink Fusion 提供的是一套預先建立並驗證過的架構，內含 NVLink Fusion Chiplet、NVLink-C2C 與 NVHBM 等技術，聯發科則依客戶需求調整記憶體、封裝、連接、效能與功耗。

真正有意思的是輝達的態度。客製化 XPU 有可能取代 AI 工廠裡的部分輝達晶片，它卻選擇把門打開。

「XPU 不是正要進入市場，它已經在市場裡了。」黃仁勳接受彭博專訪時這樣說。他反問，如果重要客戶希望把專用 XPU 放進資料中心，為什麼不讓他們更容易連上輝達的基礎設施。

他把算盤講得更直白：「當他們贏得專案，我們就有銷售的機會。」一座 AI 工廠需要的不只有 GPU，還有 CPU、scale-up 與 scale-out 交換器，以及多種網路設備。聯發科拿下 XPU 專案，即使一部分運算交給 XPU，輝達仍有機會供應其餘環節。

輝達高效能運算與 AI 超大規模基礎設施解決方案資深總監哈里斯（Dion Harris）在記者會被直接問到這會不會跟自家 GPU 打架，他回答不會，並強調輝達早已不只把自己定位為運算晶片公司，而是 AI 基礎設施公司。被追問長期目標是否要讓所有 AI 機櫃都建立在輝達架構上，他說這並非要擁有整套架構，而是希望扮演基礎設施供應商，就像 InfiniBand 與 Spectrum-X 也能服務非輝達的運算晶片。

35 億美元這個數字也引來另一種質疑。路透指出輝達近來持續以投資與融資支持圍繞其技術建構產品的業者，讓部分投資人擔心循環融資，也就是資金投入生態系後又形成對輝達產品的需求。

黃仁勳否認這項說法，強調聯發科與輝達各有獨立業務、聯發科本身已高度獲利，這筆投資建立在長期合作之上，是要展現輝達對這段關係的重視與信心。他還說相信這最終會是一筆非常出色的投資。

蔡力行這邊講的是節奏。他直接回答與輝達合作確實預期能加快聯發科 AI 晶片業務成長，但也說明目前才開始把最新版本的 NVLink 整合進系統，需要一些時間；在 AI 快速變動的情況下，產品上市速度格外重要，他借用黃仁勳常講的「光速」形容雙方要用什麼節奏協助客戶擴充運算能力。

黃仁勳透露已有客戶承諾採用 NVLink Fusion，蔡力行也證實正在與部分客戶接洽，部分市場開發工作會與輝達共同進行。名單與量產時程都還沒公布。

供應鏈是接下來的變數。蔡力行指出 HBM 與載板等環節仍有壓力，不過聯發科身處台灣這個生態系聚落，對協作很有幫助。8/31 報告寫過的那條 I/O 瓶頸，跟這裡講的是同一批環節。

雙方合作也不是從零開始。過去共同開發過 GB10 Grace Blackwell 超級晶片，PC 端今年推出 RTX Spark，首批搭載的 Windows 筆電與小型桌機預計今年秋季上市；車用方面聯發科 Dimensity Auto 已整合輝達 AI 與 RTX 圖形技術。這次是把合作往資料中心再推一層，時間尺度黃仁勳說得很清楚：不是一、兩年，而將延續十年。

管制的邊界從晶片移到算力

美國商務部正在研擬新規則，希望限制中國透過海外租用 NVIDIA 算力，鎖定的地區包括泰國與新加坡。

這件事的意義在於管制對象換了一層。過去出口管制盯的是實體晶片有沒有運進特定國家，現在要盯的是算力有沒有被特定對象使用，而算力本身可以跨境租借、也可以按小時計費。

同一天台積電在 SEMICON Taiwan 展前論壇給的數字，說明了為什麼算力會變成管制標的。它引用高盛預估，到 2030 年全球 AI Token 使用量將較 2026 年增加 24 倍。當使用量往這個方向走，算力的取得管道就成了實質的產業門檻。

台積電同場也提到一個容易被忽略的變化：隨著資料中心從單一機櫃擴展到跨機櫃，資料搬移的能耗比重已經超過運算本身。

同一顆 27B，跑出好幾種速度

Qwen 3.8 27B 這週在社群裡被反覆拆解，出現的數字差距很大，而差距幾乎都不在模型本身。

單張 3090 上，有人靠推測解碼把生成速度推到 66.6 tok/s。他公開的設定是模型用 Qwen3.8-27B-UD-Q4_K_S，spec-type 選 draft-mtp、spec-draft-n-max 設 5、spec-draft-p-min 設 0.8，context 開到 230400，KV cache 的 K 與 V 都量化成 q4_0。

推測解碼的效果在另一組實測上也看得到。有人把 DFlash2 量化成 q8_0 當草稿模型，在 7900XT 搭配 Vulkan 上跑 27B Q4_K_M，生成速度從 31.0 tok/s 升到 57.7 tok/s，提示詞處理從 257.0 升到 284.3，而測試提示詞的回答品質跟純 27B Q4_K_M 一樣好。代價是記憶體勉強塞得下，即使 context 很小也用掉 20239MB 的 20464MB VRAM。

換到 AMD 陣營的多卡配置，數字又不一樣。兩張 R9700 跑 27B 的 MXFP4 版本，10 個串流合計解碼速度達 710 t/s，發文者說這是 Launch80 AMD Discord 社群成員反覆調校的成果。

規模拉到工作站級的 RTX 6000 PRO，有人測了從純 CPU 到 96GB VRAM 的完整區間，Qwen3.8-Flash-Next 的速度從 8.5 tok/s 一路到 109 tok/s。另一端，5070 Ti 的 16GB 也能跑 27B 的 IQ4-XS 量化版，開 64k context 加上 MTP。

速度之外，另一條討論線的結論就沒那麼好看。

一位使用者抱怨 27B 連簡單專案都完成不了：會宣稱做完了但其實沒有、跳過驗證、留下半成品。他原本以為問題出在自己的 harness，換成 DeepSeek 的新 harness 與 Codex harness 之後，看到的是同樣行為。他的疑問很直接：是本地模型在多步驟專案工作上真的比大家講的差很多，還是工具鏈還不夠好？

有人給出了偏向後者的證據。一位有 40 年開發與架構經驗的使用者在 DGX Spark 上建了一套代理式編程基準，任務是照凍結的 PRD 與 OpenAPI 文件從零建出一個 .NET 10 的 REST 後端，含 EF Core、SQLite 與真實 migration，連線契約明確要求 camelCase JSON、小寫列舉字串與 RFC 9457 錯誤格式。約 30 次記錄在案的測試裡，沒有任何單一模型突破 12/61 分。

他後來停止測試單一模型加 harness 的組合，改成要求 harness 把不同類型的工作分派給不同模型，一個負責架構規劃、一個負責寫程式的苦工。這套異質雙模型設定拿到 56/61，同一份測驗 Claude Fable 拿 61/61。

還有一個更小的槓桿。有人過去每次都選非視覺版本以省 VRAM，換到 27B 的視覺版之後發現，模型做完會主動截圖確認，抓到很多不會反映在程式碼或測試上的靜默錯誤，並持續迭代到視覺上確認修好為止。同一顆模型，差別只在有沒有給它看到自己做出來的東西。

省 VRAM 的兩條路，和一個買卡前該知道的陷阱

第一條路是把權重壓得更密。有人為三元模型做了新的 GGUF 格式 Q2_B3，代號 B3S。

原理不複雜。BitNet-b1.58 這類三元模型的權重本來就只有 -1、0、+1 三種值乘上區塊縮放，一般的 Q2 表示法其實浪費了空間。B3S 直接用三進位打包，每 128 個權重佔 26 位元組的打包三進位數加一個 f16 縮放值，合計 28 位元組，等於每個權重 1.75 位元。

• 9B：約 2.5 GB Q2_0 降到約 2.0 GB
• 27B：約 7.6 GB Q2_0 降到約 5.9 GB
• 以上只算權重，context 與 KV 另計，還要多抓 1 到 2 GB

作者把限制講得很清楚：這不是通用的 2 位元量化器，餵一般 FP16 模型進去品質會崩掉，只有來源權重本來就是三元時才成立。實作是 llama.cpp 的小型分支，主要在 7900 XTX 的 ROCm 上建置調校，CPU 可用，CUDA 與 Metal 能編譯但作者沒有硬體驗證。

第二條路是加卡。有人規劃在 ThinkStation P520 上再加一張 RTX 3060 12GB，湊出 24GB 分散式 VRAM，把 17 到 18GB 的 Q4 模型完全放進 GPU，第二張卡約 300 歐元。

加卡到了高階顯卡就不只是預算問題。另一位使用者在買第二、三張 RTX PRO 6000 Blackwell 之前先去查了資料，發現這條路有硬體層的地雷。他的卡單張 BAR1 就是 128GB，三張會要求 384GB 的 MMIO 位址空間。

他整理的三個失敗案例都有記錄：

• 兩張 RTX 6000 Pro 在 ASUS WS W680-ACE 上無法 POST，錯誤是 PCI 資源分配失敗，開 Above 4G Decoding、關 CSM、拔記憶體都沒用，只有關掉 Resizable BAR 才行，代價是 BAR1 掉到每張 256MB
• 兩張 RTX 5090 在 WRX90E-SAGE SE 這種 MMIO 空間充裕的 Threadripper PRO 平台上，第二張卡開 ReBAR 就偵測不到，根因始終沒查明
• 三張 RTX 2080 Ti 在 X299 SAGE 上，第三張即使用 256MB 小 BAR 也分配失敗

最後那一例說明裝置數量與橋接拓撲會自己造成失敗，跟 BAR 大小是兩回事。想堆多張大 BAR 顯卡的人，主機板與韌體要先查清楚。

代理要執行指令之前，誰先看過

LM Studio 的 AI 代理應用 Bionic 新增了 Shell 指令自動審查功能 Auto Review，處理的是一個很實際的問題：代理每要執行一個指令就跳出來問，使用者很快就會全部按同意。

Auto Review 採兩階段設計，第一階段刻意不用大型語言模型。

Shell Judge 把指令解析成抽象語法樹，分析這個指令可能執行哪些程式、讀寫哪些檔案、帶了什麼參數，再與預先建立的安全規則比對，目前可分析 sh、bash、zsh 與 PowerShell。它不會只看指令名稱，因為同一個指令換個參數效果可能完全不同，所以也檢查參數、變數可能帶入的內容與檔案存取範圍。只有能完整判斷行為的操作才自動核准。

依開發團隊自身使用的觀察，Shell Judge 最高可直接核准約 82% 的代理指令，不必交給大型語言模型。官方也強調這是開發人員實際使用的觀察結果，不是正式效能測試。

剩下無法確認的才進第二階段，交給獨立的 Shell Reviewer 審查代理。它會分別評估操作風險與使用者授權狀態，高風險操作需要有明確授權依據；即使使用者曾經允許，被判定可能造成過度破壞的操作也不會自動執行。審查代理會參考先前的對話內容判斷使用者是否同意過，但不讀取工具執行後傳回的內容，用意是降低外部內容夾帶惡意指示的提示注入風險。

官方沒有把話說滿。他們明講這只能降低風險、無法完全阻止提示注入，而且 Shell Judge 的判斷建立在一個前提上：電腦環境與執行程式本身是可信的。如果系統裡的執行檔或軟體設定已經被竄改，光靠 Shell 指令分析仍然看不出來。

社群同一天在討論隔壁那個問題：事情做錯之後怎麼查。

有人指出現在很多 LLM 工具都能把發生過的事攤開給你看，提示詞、模型回應、工具呼叫、檢索、狀態、中間輸出樣樣都有，但當最終行為出錯，還是得有人翻過這一切、判斷哪個差異才是關鍵。他問的是大家實際怎麼做：直接讀完整段執行過程、從答案倒推、跟另一次執行比對、還是用 evals。他特別想知道那種所有資料都攤在眼前、卻仍然要花很久才找出行為從哪裡開始走偏的情況。

還有一則討論則回到最基本的信任問題。有人問，把雲端 LLM 那個「不要拿對話去訓練模型」的開關關掉之後，是不是就能安心輸入個資。發文者自己的類比是端對端加密：平台可以整天強調他們看不到你的訊息，但信不信任是另一回事。

如果 Shell Judge 那個 82% 的比例在更多人的環境裡站得住，代理工具的體驗會改變很多；如果它高度依賴特定的使用習慣，那個數字就只是開發團隊自己的日常。