Qwen 3.8 27B 跑遍各種顯示卡。最慢到最快差八倍。

今日漫畫 出演・水無瀨 澪

今天沒有大公司開發表會。有意思的東西全部在開發者社群裡，而且集中得驚人：一邊是把同一顆開源模型塞進手上任何一張顯示卡，一邊是替同一個影片模型寫工具。兩邊都在解同一種問題，就是怎麼讓一個跑得動的東西真的變成能用的東西。

同一顆模型，八倍的速度差

Qwen 3.8 27B 在社群裡被拆開來測了一整天，而且測的人各自拿的卡差距極大。把數字排起來，會得到一條完整的光譜。

• RTX 5090 32GB：NVFP4 GGUF 搭 MTP 推測解碼，最高 203 tok/s；換成約 70K token 的真實長文件，仍有 112.6 tok/s
• RTX 4090：Windows 版 ninfer 移植，實測 log 落在 132.6 到 163.4 tok/s，視 context 可裝 100K 到 150K token
• RTX 3090 24GB：IQ4_XS、131072 context、KV cache 用 Q4_0，平均約 50 tok/s
• 雙 RTX 4060Ti：同樣 IQ4_XS，一次生成 61,815 個 token 花了 23 分 16 秒，換算 44.26 tok/s
• MacBook Pro 48GB：GGUF 4-bit 與 MLX 8-bit 都是 9 到 15 TPS，MLX 4-bit 拉到 19 TPS
• Quadro RTX 6000 24GB，2019 年的 Turing 卡，二手價 830 到 950 美元：Q4_K_M 得 24.36 tok/s

最後那一台是整組數字裡最有用的。發文者自己講得很白：如果你只讀那些 119 到 200 tok/s 的討論串，你會以為 27B 是 5090 的玩具，但它不是，它是一顆 24GB 的稠密模型。

同一張卡上 Q6_K 可以到 17.95 tok/s、佔 20.56 GiB，Q8 則直接裝不進去。他的建議是 24GB 就停在 Q4 或 Q6，別去硬扛 Q8，因為一旦開始 offload，解碼速度會直接掉下懸崖，然後人會怪到模型頭上。

另一端則是把模型當工作機器用。有人在 opencode 裡丟了一句「加這個功能」，Q6_KXL 跑了 35 分鐘自己做完，157 個測試全過。也有人用 BF16 權重配 BF16 KV cache 撐到 250k context，說單張 RTX 6000 Pro 就夠。

真正值得記下來的是同一篇 Quadro 測試裡的一段自我糾正。那張卡跑 ngram 推測解碼可以顯示 110 到 201 tok/s，作者查了自己的 prompt 之後發現那是重複前綴的快取命中，等於是 benchmark 在跟自己核對答案。

如果你把那個當 tok/s 貼出來，你在騙下一個買 6000 的人。

他接著寫，自己差點就貼了，然後回頭看了 prompt。沒有人要求他做這件事，社群也不會有人去驗。

量化研究撞到的意外

同一天另一位在量化 Qwen3.8-27B 之前，先做了一輪逐群組測試，方法是一次只量化一組權重，量測它對原模型的 KL 散度，藉此找出安全底線落在哪裡。

Qwen3.8 是混合架構，多數 block 是處理狀態空間序列混合的 DeltaNet，每第四個 block 才換成完整的 attention block，兩種 block 的權重群組不一樣，加上所有 token 都會經過的 token_embd 與 output_weight，總共分出 14 個類別分開測。

結果跟隔離測試的直覺完全對不上。

• attn_v 在隔離測試裡 KLD 最差，是全部群組中最糟的；但在組合模型裡保護它完全沒有效果，數字跟不保護一模一樣
• ssm_alpha 是隔離測試中最早崩壞的；在組合模型裡保護它反而讓結果更差
• 真正有效的兩個槓桿是 attn_qkv 與 ffn_down，兩者在隔離測試時都很不起眼

還原 attn_qkv 一步就補回 55% 的 toolcalling 落差與 13% 的一般能力落差，再疊上 ffn_down 又補了 24%。換句話說，先挑出「單獨壞得最兇的那一個」去保護，方向可能整個是錯的。

KV cache 的量化選擇也有類似的取捨。在 5090 上跑 Q8_0 模型時，KV cache 用不同精度會直接決定最大穩定 context：

• Q8_0：105,216 tokens
• Q5_1：137,984 tokens
• Q4_0：169,984 tokens

同一位實測者踩到 llama.cpp 的一個已知問題，Q5_1 一度顯示可以吃到 180k 以上，但吞吐從 100 掉到 25，花了不少時間才定位出原因不在模型。

H3 的工具在一天內冒出六套

MiniMax H3 那邊的節奏完全不同。沒有人在測速度，所有人都在寫工具，而且一天內就冒出六套以上。

• MiniMax-H3-Longvideos：一個 prompt 進去，出來約兩分鐘的含音訊影片
• ComfyUI_MiniMax_H3_Extender：串接多段影片，帶 motion context、磁碟快取、動態圖片參考與音訊參考
• ComfyUI-Fantastic-MiniMaxH3-PromptBuilder：在 ComfyUI 內建 prompt，不需要另外掛 LLM
• HARMON3：透過 ComfyUI API 做場景與專案管理，含 pose generation
• ComfyUI-Hillobar：漸進式解析度，早期步驟用低解析度 latent 再逐步拉高
• MiniMax H3 Motion Director：把四個既有專案縫在一起的多段時間軸控制器

PromptBuilder 那條說明透露了 H3 的脾氣。它不接受隨口一句話，要的是帶章節名稱、鏡頭時間、講者 ID，以及指向參考素材標籤的結構化 prompt。

Motion Director 的作者則很誠實地把自己的東西叫做 Frankenstein node。他沒有假裝一切都是自己發明的，直接列出縫進去的四個來源專案，把有用的部分接起來、改過，再包一層多段 Director 上去。

他寫下的動機比功能清單有意思：產一個 5 到 10 秒的 clip 很容易，難的是第一鏡接到第四鏡的時候，角色外觀、動作、顏色、音訊與參考素材還要維持一致，工作流會迅速膨脹成巨大的 graph。所以 Director 才會有「只重跑失敗的片段」這種功能。

六套工具解的其實是同一件事。單鏡頭生成已經不是問題了，問題在鏡頭與鏡頭之間。

至於品質，有人拿 H3 當單圖編輯模型用，在 5090 上 8 到 10 秒出一張，能組合多個參考素材、對三維空間的理解也不錯，但同一位實測者說細節還可以更好，印象派風格化那組大致是失敗的。要把工作流用滿還得 monkey patch 繞過 ComfyUI 的 5-frame 限制，相關 issue 正在集氣。

低 VRAM 的另一條路

低 VRAM 的解法長期以來幾乎等同於量化，也就是拿精度換空間。今天出現一個走反方向的做法。

WeeLLM 完全不量化。它一次只從 HF safetensors 檔案串流一層 transformer 進 VRAM，算完就丟掉，換下一層，全程維持 bf16。在一張 RTX 3050 4GB 筆電卡上的實測：

• FLUX.1-dev 約 12B 參數，峰值 VRAM 1.51 GB
• SDXL 約 6.6B，峰值 2.98 GB，1024x1024 跑 20 步約 120 秒
• SD 3.5 Medium 約 8B，峰值 3.48 GB，20 步約 219 秒
• Z-Image-Turbo 約 10B，峰值 1.60 GB，4 步約 167 秒
• Qwen-Image 約 20B，峰值 2.47 GB，10 步約 795 秒

代價寫得很清楚，這個方法受磁碟 I/O 綁定，設計給本機的 NVMe SSD，不適合儲存慢的雲端執行個體，而且目前只做 text-to-image，img2img 與 inpainting 都還沒有。

另一條路仍然是量化加 offload。有人整理出 RTX 3060 12GB 搭 24GB 系統記憶體的 H3 文字轉影片工作流，實測推到 2.0 megapixels 沒有失敗。也有人手上是 RTX 4060 Ti 8GB 配 32GB DDR4，在問 5 秒低解析度影片到底做不做得出來。

兩條路的取捨很不一樣。串流層保住了精度但吃磁碟速度，量化保住了速度但動到權重本身。

用 KL 散度量對齊有多厚

有人提出一個不需要拿到 base model 就能量測 RLHF 約束強度的做法。

方法是在查詢前插入一段約 3000 token 的良性、非指令性前綴，然後量測有前綴與沒前綴時，模型輸出分布之間的 KL 散度。

三種查詢的反應差很多。安全查詢的 KL 散度很低，代表 RLHF 幾乎沒有介入。政治或爭議話題這類灰色地帶，KL 散度中等，而且前綴可以把它壓低，模型會回答得比較放鬆。明確有害的查詢則不同，加了前綴 KL 散度依然維持得很高。

作者的解讀是 RLHF 不是一層均勻的約束，而是強度會隨題目變動的浮動層。這個方法的實用之處在於它不需要對照組，拿不到 base model 也能標出對齊在哪裡厚、哪裡薄。

WordPress 登入頁的那道縫

WordPress 發布 7.0.3 修補了登入頁面的高風險跨站指令碼漏洞 CVE-2026-64638，別名 XSS2Shell。

漏洞的成因在錯誤訊息。用不存在的帳號名稱嘗試登入時，輸入內容會被帶進錯誤訊息，而前後兩道 HTML 過濾機制對異常標記的判讀方式不一致，導致原本應該被移除的內容留在頁面上，被瀏覽器解析成有效的 HTML 元素。

單靠這個漏洞還控制不了伺服器。攻擊者需要接著利用登入頁既有的 JavaScript、REST API，以及瀏覽器允許同網站來源頁面互相存取的機制，在受害網站的網域下執行指令。如果受害者當下正以管理員身分登入，攻擊者就能借用那個登入狀態取得應用程式密碼、建立含惡意 JavaScript 的頁面，再上傳含 PHP 程式碼的外掛，最後在伺服器端執行。

完整攻擊鏈仍需要社交工程配合，得先誘使一位已登入且權限足夠的使用者去操作惡意內容。

規模已經不小。資安廠商 Imperva 觀測到相關活動鎖定超過 1.1 萬個網站、累積數十萬個請求，分布在 67 個國家，呈現大規模自動化的特徵。

漏洞影響所有版本。7.0 系列要升到 7.0.3，安全修補也回補到仍接受更新的 6.9.6、6.8.7 與 6.7.6。除了確認正式環境已更新，站方也該回頭檢查有沒有出現異常的管理員帳號、應用程式密碼或外掛安裝紀錄。