Kyojin 引擎讓兩臺 300B MoE 模型各跑在單臺 128GB Strix Halo 上
基於 ExLlamaV3 的 Kyojin 引擎在 AMD Strix Halo（gfx1151、ROCm）上讓兩個 300B 級 MoE 模型各裝進一臺 128GB 迷你主機：GLM-5.3-Flash 佔 99.7GB，3.5K 上下文預填充 580 tok/s，解碼 26 到 30 tok/s；MiMo-V2.6-Flash 佔 105GB，解碼最高 44 tok/s（程式碼場景）。
你正打算買 Mac Studio 本地跑開源模型，這份 Strix Halo 上的實測資料（視訊記憶體佔用、預填充與解碼速度、量化精度損失）可作為對比 Apple Silicon 方案與 MLX、llama.cpp 的參考基準。
原標題：Two ~300B MoE models, each on ONE 128 GB mini PC (AMD Strix Halo): GLM-5.3-Flash at ~580 tok/s prefill, MiMo-V2.6-Flash up to 44 tok/s decode. EXL3 weights + open ROCm engine
閱讀原文
| 評分 | 62 / 82（平均 72，門檻 76） |
|---|---|
| 狀態 | 未入選 |
相關報導
TensorSharp 讓 176B MoE 模型跑在 16GB 視訊記憶體筆記本上
開源推理引擎 TensorSharp 在 RTX 3080 Laptop（16GB 視訊記憶體）、32GB 記憶體加 SSD 的普通筆記本上跑起了 Qwen3.8 Flash Next 176B，無需 128GB 以上記憶體工作站或多 GPU。它靠量化加 MoE 感知的統一排程，協調視訊記憶體、記憶體、SSD 與快取分層。
gufo 分支讓 Qwen3.6 35B A3B 在 Strix Halo 上跑出 3095tok/s 預填充
開發者 nubela 發布了 gufo 的分支 gufo-Qwen3.6-35B-A3B-Q6dense，在 Strix Halo 上實現 3095 tok/s 預填充和 190 tok/s 解碼，目標是 3000 tok/s 預填充與 150 tok/s 解碼。該分支為追求速度而非智慧的負載設計，作者自行量化了模型並以 Apache 2.0 許可發布，使用 unsloth 的 GGUF 也可執行但效能較低。
llama.cpp 的 OpenVINO 後端更新，MoE 推理大幅提速
ggml-openvino 後端更新至 2026.4.1，新增 MoE 路由融合與 GDN 歸一化融合，並預設在 GPU 上啟用 MoE 融合。在 Arc B390 上跑 gemma-4-26B-A4B，配合 q4_asym64 重新量化，pp512 從 66.16 t/s 提升到 1608.73 t/s，困惑度基本不變。同時修復了 stateful 執行下 rank-3 軸處理導致的 MoE 崩潰，並改進裝置列舉與記憶體上報。
Strata 搭配 Qwen3.8 Next 讓慢記憶體跑出 45-70t/s
有使用者用 Strata 加 Qwen3.8 Next 的 IQ3_XXS 權重（接近 80GB），在 DDR4 加 7900XTX 的慢速記憶體機器上穩定跑到 45-70t/s，編碼時偶爾更高；同樣配置下調優後的 llama.cpp 最高只有約 22.5t/s。12GB 和 16GB 顯示卡使用者反饋結果相近，DDR5 使用者則明顯更快。作者建議讓 LLM 按自己的硬體配置來設定，並提醒不要用 Q2 權重。
llama.cpp 新 PR 把共享專家融合進 CUDA MMVQ
llama.cpp 的 PR #29184（作者 am17an）提出在 CUDA 後端把 MoE 的共享專家融合進 MMVQ 運算元，為部分 MoE 架構（例如 Qwen 35B A3B）帶來推理加速。評論區給出的初步結論是 token 生成速度最多提升約 5%，屬於穩步積累而非革命性改動。該改動僅針對 CUDA 後端、且只對部分 MoE 架構生效，Metal 等其他後端不受影響。