SpaceX 和 Tesla 砸 168 億美元自己蓋晶片園區。他們算的是 1 太瓦。

今日漫畫 出演・水無瀨 澪

SpaceX 和 Tesla 要在德州蓋一座 1 億平方英尺的 AI 半導體園區。同一天在 Reddit 上，有人把 162GB 的模型塞進兩張消費級顯示卡加系統記憶體裡跑了六個小時。

把整條供應鏈搬進同一塊地

SpaceX 與 Tesla 宣布首期投資 168 億美元，在美國德州格萊姆斯郡興建 AI 半導體園區 Terafab。

規劃的內容比金額更值得看：

• 園區占地達 1 億平方英尺
• 先進邏輯晶片與記憶體的製造、封裝及測試放在同一個地點
• 至少創造 3,000 個工作機會，後續擴建可能再提高總投資額
• 鄰近 Gibbons Creek Reservoir，規劃直接用水庫供應工業用水
• 兩家公司預估未來數年所需的運算能力將超過 1 太瓦

最後那個數字是整件事的起點。1 太瓦不是一座資料中心的規模，是把 Optimus 人形機器人、Cybercab 自駕計程車和規劃中的太空資料中心加總之後推算出來的胃口。晶片供應缺口填不滿，就自己蓋。

這條路線他們今年已經走了一段。SpaceX 與 Intel 合作強化晶片製造能力，Tesla 則在 4 月為 Terafab 的先導研發設施動工。從長期採購與投資晶片業者，變成自己建立從製造到封裝測試的垂直整合產能。

同一天還有兩則消息落在同一個方向。NVIDIA 傳出砸 30 億美元投資電力，亞馬遜則在蓋離網資料中心。三家公司做的是不同的事，但要解的是同一個問題：算力的瓶頸已經不在能不能買到晶片。

162GB 的模型，三種塞進家裡的方式

DeepSeek-V4-Flash-0731 的全精度版本是 162GB。這個數字在一週前還是「租雲端」的意思，今天 Reddit 上出現了三種不同的解法。

第一種是硬湊。有人手上有 2 張 7900XTX 加 128GB 系統記憶體，總共 176GB，剛好比模型大 14GB。他把它塞進去了。

實際跑起來的數字是 prefill 約 52 tok/s、generation 約 10.5 tok/s。以互動速度來說不快，但他描述的使用情境是單一使用者拿一個困難的 coding 問題連續解五到六個小時，模型一路把問題圖走完。他自己標明這是「看能不能做到」的專案，不是可靠的生產環境。

第二種是換記憶體層級。另一人做了名為 DeepSeekV4SSD 的 macOS 原生 app，把共用的模型資料留在記憶體、把路由到的專家從 SSD 串流進來。

在 64GiB 的 M5 Pro MacBook Pro 上，14K token 的輸入跑出這樣的成績：

• prefill 180 tok/s
• decode 6.5 tok/s
• MLX 峰值記憶體約 30GB
• 主模型約 156GB，含 DSpark 模組完整安裝約 167GB

門檻寫得很清楚：Apple Silicon、macOS 15 以上、至少 64GiB 統一記憶體、約 160GiB 的 SSD 空間，而且要快的內接或 Thunderbolt SSD。作者說效能高度取決於 SSD 速度、提示長度與快取狀態，目前一次只處理一個生成請求。他正在徵求其他 M 系列機器的實測數字。

第三種是把老伺服器榨到底。有人搬出 2019 年的 Supermicro SYS-1028GQ-TR，配 4 張 Radeon Pro V620，跑 284B MoE 的 2-bit 版本。

一天的調校換來 prefill 提升 2.93 倍、decode 提升 11%，另外四種方法在量測後被否決。他把 GGUF metadata 攤開來解釋為什麼：expert_count 256、expert_used_count 6、expert_shared_count 1，也就是 284B 參數裡每個 token 只啟動 7 個專家，約 2.7%。另外 head_count_kv 等於 1，代表 K/V 被壓縮成單一 latent 而不是每個 head 各存一份。

這兩個數字解釋了為什麼一台 2019 年的機器還有機會。MoE 的啟動比例夠低，而 MLA 讓 KV cache 不隨 head 數線性膨脹。

H3 的討論從畫質變成顯存

MiniMax H3 上線一週多，r/comfyui 的討論重心已經換了位置。現在的熱門貼文不在比誰的成品好看，在比誰的顯存省得多。

一則貼文分享了一組量化元件的搭配，把 H3 的顯存佔用壓下來約 10GB：

• pruned_w4a8_mixed 主模型 11.6G
• qwen3vl_4b_int4_convrot 文字編碼器 2.6G
• video_vae_int8_convrot 影片 VAE 2.95G
• audio_vae_bf16 音訊 VAE 295M

發文者說他原本連 RTX 5090 都躲不掉共用 GPU 記憶體與 swapping，換成這組之後整條 pipeline 不再 swap。

另一則走的是反方向：把所有加速方法疊起來看極限在哪。作者租了一張 5090，32GB 顯存、56GB 系統記憶體，CUDA 13 配 SageAttn 2.2.0 與 Triton 3.6.0，跑出 10 秒 1MP 影片約 180 秒、0.5MP 約 60 秒。他很誠實地補了一句：這些加速節點的參數他一個也看不懂。

畫質那邊有人踩到天花板。有人拿固定的測試場景試 H3，推車上飛出的小物件會變形、形狀一路改變，把步數從 20 調到 30 反而更糟，換 beta sampler 又更糟。他懷疑是本地版量化太重造成的，也承認自己沒看過任何 AI 影片模型把這個場景做對。

至於該用哪一個，有人花了一週把 Seedance 2.5 和 H3 都跑過。兩者都在 7 月 31 日推出，結論是各有各贏的場合。Seedance 2.5 一次能產 30 秒連貫鏡頭不需接續、最高 4K、接受最多 50 個多模態參考來鎖定角色與風格，代價是走 BytePlus API，迭代時成本累積得快。H3 的權重開在 Hugging Face 可以正經接進 ComfyUI，而且同一次生成就產出原生立體聲，把音訊當主要輸入時影片會跟著聲音走。它的規格是 2K 24fps 的 5 到 15 秒，長度與解析度都比不上 Seedance。

在 12GB 顯存的 4070 上跑 H3 是可行的，但解析度受限、生成時間讓快速嘗試變得很痛苦。想在探索階段大量試錯的人，還是會回頭找算力。

不夠的話，就把模型攤到一群機器上

Colibrì 的作者推出了下一步，叫 Lumabri。它要做的事是把一群普通機器變成一個能服務同一個巨型 MoE 模型的 swarm。

運作方式是這樣：一台機器持有模型、當初始來源與永久後備，其他機器直接加入就能開始對話，不需要預先下載任何東西。跨網路傳的只有推論實際需要的位元組，這些區塊從 peer 那裡拿到之後留在本地鏡像，第二次提問就以本地磁碟全速服務，即使所有 peer 都離線也一樣。

設計規則只有一條：任何機器都能加入，有沒有 GPU 都行。引擎是為 CPU 與 SSD 先寫的，GPU 只會讓它更快、不會讓它變得不同，輸出逐位元組相同。一個零 GPU 的 swarm 仍然是可以運作的 swarm。

參與的方式有三種：只聊天、捐磁碟空間（tracker 會分配複製最少的切片）、或捐算力替別人跑專家。tracker 本身只是索引，實際工作由 peers 完成。

寫三分鐘，除錯一週

有一則貼文的標題就是全部內容：用 LLM 之前是寫 3 小時、除錯 1 小時；用了之後是寫 3 分鐘、除錯一週。

這種抱怨最近多了起來，而且開始長出比抱怨更有用的東西。

一則貼文主張 LLM 應該叫 Artificial CONFIDENCE 而不是 Intelligence。理由不是模型不夠聰明，是它不會辨識假商品，卻被設計成有足夠的信心去推薦它們。作者引的案例是一名行銷人員做了一個假的體香劑品牌，幾週之後模型就把它推薦在真實商品之上。他的說法是 Dunning-Kruger 效應現在適用於 LLM，也適用於所有稱它為智慧的使用者。

另一個角度更難防。有人在做法醫時間軸，他擔心的失敗模式是模型只用真實事件，但把事件之間的連結編出來。最後的敘事聽起來完全有根據，證據鏈卻是斷的。他問的是有沒有人測過本地模型在證據鏈斷裂時的表現，而不是只測捏造事實。

最實作的一則來自一個做了 harness 的人。他發現模型本身通常有能力完成編碼工作，失敗都發生在模型的周圍：沒問就做重要決定、帶了太多無關脈絡、忘記前一次 session 的決定、沒用對專長、模組各自能跑但整合就壞、驗證不足就宣稱完成。

他的做法不是把 prompt 寫得更長，而是在 agent 外面圍一圈系統，迴圈是 Specify、Route、Execute、Verify、Persist。目前的 v6.3.0 含 35 個原生 skill、58 項專長強度、143/143 單元測試通過、22/22 routing 評測通過。

真正有意思的是他做的移除實驗。他把 harness 的元件一個一個拿掉再重跑評測，其中一個拿掉之後 routing 從 22/22 掉到 13/22，另一個拿掉則沒有可量測的差異。他認為第二個結果同樣有價值：要嘛那個元件沒有幫助，要嘛 benchmark 沒有在測它該測的東西，兩件事都值得知道。

他的原則寫得比多數框架文件都乾淨：觀察到失敗、做出最小可用的機制、留下回歸證據。如果 agent 反覆忽略某件可以機械檢查的事，那就做一個確定性檢查，不要在 prompt 再加一段話。