Picchio 把 1,170 億參數搬上筆電。常駐記憶體只要 5GB。

今日漫畫 出演・水無瀨 澪

MoE 模型每產生一個 token 只會啟動少數幾位專家，這件事一直被當成訓練效率的優勢。這週有人把它當成記憶體管理的方法用。

而在同一批討論裡，一份論文指出經過重度對齊的大模型會在所有獨立取樣路徑上輸出完全相同的錯誤答案，讓一整類幻覺偵測方法的判別能力直接反過來。

1,170 億參數不必整份進記憶體

Picchio 是一個用純 C 語言寫成的小型推論引擎，不需要 Python 執行環境，專門用來跑 GPT-OSS 的 MoE 模型。

它的作法建立在一個被講了很久但很少被實作到底的觀察上：既然每個 token 只會啟動少數專家，那就沒有理由把整個模型都塞進記憶體。

• 只讓 5GB 的稠密部分常駐記憶體
• 其餘專家依需求從磁碟載入
• 搭配 LRU 快取與預先載入機制減少等待
• 結果是 GPT-OSS-120B（1,170 億參數）可以在一般筆電上執行，模型甚至能放在外接 SSD

作者自己把話說得很清楚：120B 版本很慢，但它能在原本記憶體完全裝不下的硬體上運作。真正實用的是 20B 版本，在內接 NVMe 上約 0.6 秒產生一個 token。

而且那份 120B 的數據是刻意用最壞情況跑的，模型放在外接 SSD 上。如果換成內接 NVMe 會快多少，目前還沒有人補上這個數字。

社群另一頭正在問一個相關的問題：手上只有 16GB VRAM 加 32GB 系統記憶體的人，該去找 MoE 模型還是稠密模型。提問者的直覺是，MoE 依任務載入不同的輕量專家，也許能在較低的 VRAM 上跑動比稠密模型更聰明的東西。Picchio 等於把這個直覺推到極限，代價是把等待從記憶體移到磁碟。

每秒幾個 token，現在有得比了

本機推論社群這週貼出的效能數字，第一次多到可以彼此對照。

Intel Arc Pro B70 跑 Qwen3.8-27B 的 MTP4 版本，512 token 時 81.24 tok/s，拉到 120K token 時掉到 50.31 tok/s。

雙 B70 跑 FP8 版本的數字更細，用 BetterBench 分五類各跑 20 次，解碼速度的中位數是：

• chat 80.5 tok/s
• code 99.7 tok/s
• file_edit 137.2 tok/s
• json 165.6 tok/s
• 首字延遲中位數落在 198 到 262 毫秒之間，每次更新的延遲則穩定在 43 毫秒附近

比速度更值得看的是穩定性。同一組測試的變異係數，json 只有 13.7%、file_edit 13.8%，chat 卻高達 35.6%。也就是說開放式對話的速度波動是結構化輸出的兩倍半以上，而多數人挑模型時只會看到一個平均值。

Mac 這邊也有人給出數字。一位使用者把 MTPLX 更新到 2.11.2、從 Qwen3.8-27b 換成完整的 125b Flash-Next，在 MacBook Pro M5 Max 128GB 上跑 Go 語言的狀態機開發，維持每秒 60 到 76 個 token，而且脈絡窗口擴展到超過 6 萬 token 時速度沒有掉。他另外提到這個模型在沒被提示的情況下自行找出並修復了四個錯誤。

反例同一週也出現了。有人在 RTX 5090 上啟用 nvfp4 的 turboquant_4bit、KV cache 開到 128K，跑 vLLM，結果只有 10 到 30 tok/s，他自己形容像糖蜜。這台機器的紙面規格遠優於前面幾個案例。

把這些數字放進同一個視野會發現，量化格式與推論框架的搭配造成的差距，已經大過顯卡本身的差距。另一位使用者正在為 5090 規劃無審查編碼代理的配置時，糾結的也是同一件事：NVFP4 加推測性解碼、EXL3、GGUF 還是 FP8，以及 WSL2 據說會吃掉 2 到 3GB VRAM 這種細節。

影片生成的等待時間變成可規劃的成本

影片模型這邊的討論，重心從「做不做得出來」移到「要等多久、在什麼硬體上」。

一位使用者用 MiniMax H3 搭配 SLA attention 與四步 LoRA 生成動漫風影片，全部先算 1.0 MP 再用 RTX video super resolution 放大。時間是 5 秒片段約 250 秒、10 秒片段約 600 秒，硬體是 3080 Ti 筆電、16GB VRAM。

另一位開發者則把 LTX-2.5 22B 的首尾影格轉影片流程壓進 8GB VRAM。他公開了完整配置：LTX-2.5 22B 蒸餾版、W4A8 ConvRot Transformer、Gemma 12B W4A8 文字編碼器、官方 BF16 Video VAE 與潛在空間放大器，並啟用 DynamicVRAM、非同步權重卸載與記憶體釘選。測試機是 RTX 4060 筆電版、16GB 系統記憶體。

品質的取捨也開始被具體描述。一位動畫創作者比較後認為 H3 比 LTX 2.5 更緊密遵循提示詞、視覺品質也更好，但 Turbo LoRA 為了速度犧牲的品質太多，所以他的第一階段固定跑 20 到 32 步。

不是每個嘗試都成立。有人根據社群傳言，試著用 H3 的參考模型把等距長方投影的 360 度全景圖轉成可重複使用的場景，結果發現模型並不真正理解這種投影，只有在鏡頭拉得夠近時畫面才碰巧對得上，一旦要求複雜運鏡就會扭曲變形。

而記憶體不足的代價，有人算到了硬體壽命上。一位使用者發現自己的 H3 R2V 工作流程配原版 Qwen 3.8 27b，在 32GB 系統記憶體加 16GB VRAM 的機器上一直在大量寫入磁碟，單一片段就可能寫掉數 GB。這筆成本不會出現在任何一份生成速度的報告裡，但 SSD 的寫入壽命是有限的。

評測方法自己成了被檢查的對象

一份新的預印本把幻覺偵測的標準作法拆開來看，結論比方法本身更值得記。

Farquhar 等人發表在 Nature 2024 的語意熵，長期被當成幻覺偵測的標竿，但它需要用 DeBERTa-v3 這類 cross-encoder 做成對的自然語言推論分群，10 條路徑在一般 CPU 上要跑約 136 秒。Spanda 這篇論文想知道，不做這些額外的神經網路前向傳遞，能不能得到同樣的診斷能力。

在 7B 到 27B 的模型上跑 GSM8K 推理，答案是可以：正規化後的詞彙自我一致性達到 AUROC 0.889，與神經語意熵相當，而執行時間約 1.5 毫秒，大約是 9 萬倍的加速。

真正的發現在後半段。在 120B 以上經過重度對齊的模型上，自我一致性整個垮掉。溫度取樣設在 0.7 時，RLHF 的對齊讓輸出分布過度尖峰，模型在所有獨立取樣路徑上吐出完全相同的那個錯誤答案。因為候選答案在錯誤回應上的變異降到零，AUROC 從 0.889 倒轉成 0.091。

這個數字的意思是：偵測器不只失效，它會在模型錯得最徹底的時候給出最高的信心。而這正是對齊做得越好的模型越容易出現的狀態。

同一週還有兩個社群動作指向同一個方向。RAGnarok-AI 的維護者不再假設自動評分是正確的，他正在建立人工標註的基準，用來檢查一件事：當評估者本身就是大型語言模型時，憑什麼相信它給的分數。另一位使用者則直接對排行榜開火，提議所有人用完全相同的幾道真實問題問自己慣用的模型、把原始回答貼出來，再由實際在用這些工具的人投票。他的說法是，當你凌晨兩點面對一個真實問題時，MMLU 跟 SWE-bench 的分數究竟代表什麼。

影像那邊的作法比較樸素但方向一致。有人乾脆自己寫了 50 個提示詞當基準，跑過 8 個模型並把所有輸出與統計數據公開在參考圖庫頁上，理由是他找不到好的比較方法。

把使用邊界寫進工具裡

兩個這週釋出的工具，處理的是同一件事的兩面：什麼東西該被機器讀到，以及讀到之後可以拿來做什麼。

Unveil 是一個掃描器，針對的是「對人類隱藏但對機器說話」的文字，也就是間接提示詞注入。這類攻擊不需要使用者做錯任何事，只要代理去讀了一份被動過手腳的文件或網頁就會生效。

另一邊是 facefusion-mobile，一款完全在 Android 手機上跑的即時換臉應用，不需要伺服器與帳號、不上傳任何資料。它跑在 Qualcomm Hexagon NPU 上，10 秒 720p 影片約需 13 秒處理，開啟 Fast video 可縮到 11 秒；沒有 Snapdragon 晶片的手機退回 GPU 與 CPU，結果相同但約慢四倍。APK 66 MB、模型 420 MB。

值得記的是作者怎麼收尾。這個專案移植自 Henry Ruhs 的 FaceFusion，授權選了帶有使用限制的 OpenRAIL-AS，而作者在功能清單的最後直接寫了一句：不要未經同意把這個用在真實的人身上。

工具越是完全本機、越是不需要帳號，能夠事後追責的手段就越少。把限制寫進授權條款與說明文件，是目前僅剩的幾種辦法之一。