TensorSharp 讓 176B MoE 模型跑在 16GB 視訊記憶體筆記本上
開源推理引擎 TensorSharp 在 RTX 3080 Laptop(16GB 視訊記憶體)、32GB 記憶體加 SSD 的普通筆記本上跑起了 Qwen3.8 Flash Next 176B,無需 128GB 以上記憶體工作站或多 GPU。它靠量化加 MoE 感知的統一排程,協調視訊記憶體、記憶體、SSD 與快取分層。
開源推理引擎 TensorSharp 在 RTX 3080 Laptop(16GB 視訊記憶體)、32GB 記憶體加 SSD 的普通筆記本上跑起了 Qwen3.8 Flash Next 176B,無需 128GB 以上記憶體工作站或多 GPU。它靠量化加 MoE 感知的統一排程,協調視訊記憶體、記憶體、SSD 與快取分層。
開發者 roofkid 發布 Ninfer 4080,讓 RTX 4080 16GB 顯示卡以 100k 上下文執行 ISTA-DASLab-Qwen-3.8-27B-GSQ,最高預填充 2720 tok/s、生成 262 tok/s,程式碼已在 GitHub 開源並提供 Docker 映象。它採用 DFlash2 投機解碼,作者稱預填充與生成速度明顯優於 llama.cpp、vllm 等通用推理引擎,代價是 KV 量化帶來輕微精度損失。
作者自建了魔獸世界私服,並做了一個可在 PC 和手機瀏覽器免費玩的客戶端 jankcraft.xyz,再用自訂 MCP 與 agent harness 通過 websocket 控制瀏覽器客戶端讓 LLM 自動遊玩,agent 頁面已上線。目前雲端訂閱使用者可能遇到問題,本地模型只要服務端開啟 CORS 即可接入;作者提供的現成模型會隨用量增長撤下。
一位只有 8GB 視訊記憶體和 16GB 記憶體的使用者在社群表示,只能期待 Qwen4 35B A3B 或類似模型,並希望藉助額外 n-gram 把 35B 擴充套件到 70B 以上。在此之前,他仍偏愛 Gemma 26B QAT,稱其速度穩定在 26 Tg/s。
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 崩潰,並改進裝置列舉與記憶體上報。
r/LocalLLaMA 上一則帖子引發討論:FP8/BF16 使用者看到有人跑 IQ1_S 量化感到震驚。多位使用者指出,IQ1/IQ2 這類極端量化只適合創意寫作或閒聊,用於編碼、複雜邏輯推理或結構化 JSON 提取時困惑度飆升、語法和邏輯明顯崩壞;而 Q4_K_M 或 Q5_K_M 通常是多數模型的甜點區,困惑度曲線相對平坦、視訊記憶體佔用大幅下降且推理能力幾乎無損。
llama.cpp 合併了 qwen4exp 的 lightning indexer 最佳化,把索引器打分視訊記憶體減半:原先同時存在兩個 [n_pool, n_idx_h, n_tokens] f32 張量,現在每個 head 單獨計算並原地累加進一個 [n_pool, n_tokens] 分數。同時 CUDA 支援 4 heads、Metal 用函式常量傳 head 數、Vulkan 按 keys×tokens 分塊並向量化 fp16 點積。
Anyworld 是一個開源的瀏覽器多人文字冒險遊戲,由房主用 llama.cpp 本地跑模型充當 DM,也支援 OpenAI 等雲 API,玩家只需點連結加入。它支援整輪統一結算、Python 真實骰子、自訂劇本、隱藏觸發器和結構化記憶壓縮,但房主需要 Python 與網路配置能力,本地後端目前只輸出英文,重啟伺服器會丟失當前會話。作者推薦 Gemma 4-26B-A4B Q4、128k 上下文,在 RTX 5070 Ti 16GB 上每輪約 5 秒,採用 MIT 許可。
德國 Aleph Alpha 於 2026 年 10 月 3 日發布開源權重模型 Kolibri,Apache 2.0 許可,權重已上 Hugging Face。它是 78.1B 引數的 MoE 模型,每 token 僅啟用 3.46B,支援德語和英語,原生上下文 262,144 token,FP8 權重約 78 GB,知識截止 2026 年 6 月 18 日。
一位使用者為給 Qwen3.8 27B 搭建 RAG 搜尋節點,在 AliExpress 買了一臺標稱 Intel N150 的迷你主機,收到的卻是 2018 年的 Core i3-7020U(2 核 4 執行緒)加 DDR3 1600MHz 記憶體。賣家把 New_N150 寫進 BIOS 版本字串(HSHW_M6_DDR3_EC_Intel_Com_New_N150_K001)來偽裝型號,導致系統識別為假規格,連索引文字檔案都吃力,更別說跑向量檢索。該使用者已發起信用卡拒付。
有人在 Windows 上用 llama.cpp 的專家流式方案,在單張 RTX 5070 12GB 加 32GB DDR4-2400 記憶體上跑 Qwen3.8-Flash-Next 177B(UD-IQ3_XXS),基準約 11.5 tok/s,日常對話 14–15 tok/s,比原方案約 7 tok/s 提升明顯。一次長編碼提示以 10.15 tok/s 生成 4,892 個 token,產出一個可執行的單檔案貪吃蛇遊戲。
llama.cpp 的 PR #29825 把 Qwen Flash Next 的 indexer score 視訊記憶體佔用減半,例如 131072 上下文、ub 2048 時從 3.0 GiB 降到 1.5 GiB,262144 上下文、ub 4096 時從 11.7 GiB 降到 5.6 GiB。作者稱 logits 完全一致,僅分數因 fp32 舍入有差異,pp/tg 速度不變,test-llama-archs 通過。
開發者 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 也可執行但效能較低。
有使用者用 Strata 加 Qwen3.8 Next 的 IQ3_XXS 權重(接近 80GB),在 DDR4 加 7900XTX 的慢速記憶體機器上穩定跑到 45-70t/s,編碼時偶爾更高;同樣配置下調優後的 llama.cpp 最高只有約 22.5t/s。12GB 和 16GB 顯示卡使用者反饋結果相近,DDR5 使用者則明顯更快。作者建議讓 LLM 按自己的硬體配置來設定,並提醒不要用 Q2 權重。
r/LocalLLaMA 使用者 pmarsh 發帖稱自己已接近本地推理硬體投入的中間水平,評論區隨即給出多種低成本方案:2014 至 2018 年的 2 至 4 路 DDR3 CPU 伺服器可跑 qwen 3.8 flash 超 15 tok/s;雙 7900XTX 不到 2000 美元可跑 27B Q8 超 220k 上下文;CMP 170HX 視訊記憶體超頻可達 2TB/s,單流解碼約 60 tok/s。
MegaCapybara 是專為 RTX5090 打造的推理引擎,聚焦 Qwen3.8 27B,解碼速度約為此前 SOTA 引擎 Ninfer 的兩倍:單路編碼可達 500+ t/s,12 個 agent 併發、800k 上下文時可達 2000+ t/s。它自帶權重格式與後設資料,載入前會展示各量化設定相對 BF16 的 KL 與 top-1% 損失,並支援智慧 VRAM-RAM-DISC 快取、Loop Guard 與圖形介面。採用 MIT 許可,原始碼與權重建置器稍後發布。
宇樹機器人發布通用人形基礎模型 UnifoLM-WLA-1.0,6B 引數,用約 2500 小時真實機器人資料訓練,單個模型覆蓋 64 項任務(10 項全身 + 54 項桌面),支援平行夾爪和兩種靈巧手。架構上以基於 Qwen3-VL 的 UnifoLM-ER-1 具身推理器為起點,加入光流與 VQ-VAE 的未來動態區域預測,用殘差 VQ 離散化末端執行器、手和下肢動作,再疊加 MMDiT 動作專家做連續控制。
r/LocalLLaMA 使用者分享 jev 系列分類模型(classifier)的真實用例:有人用 jev-reviewer 定位論文證據、避免引用幻覺,有人用 is-malicious 掃描 GitHub 倉庫與 PR 的惡意行為,還有人用 decider 4b 替代 Gemma 雙階段流程,把語音 RPG 延遲從 4-8 秒降到 2-3 秒。
在單張 RTX PRO 6000 Blackwell 96GB 上,Qwen3.8-27B 用 DFlash2 草稿模型把 Spec-Bench 單使用者解碼從 75 tok/s 提到 210 tok/s,約 2.8 倍;NVFP4 比 BF16 快 2.2 倍。三款檢查點中 Flash-Next 預填充 22.4 秒、27B 為 97 秒,長上下文召回三者均滿分,BFCL 工具呼叫 27B 以 73.3% 領先。
Ai2 開源 AstaBrief 8B:一個把研究問題與檢索到的文獻片段轉成帶引用報告的模型,基於 Qwen3-8B 用 SFT 與 DPO 訓練,權重、訓練資料和一份可從自己 PDF 生成報告的範例工作流一併放出。它已作為 Asta 的 Generate a report 功能中的 Fast mode 上線,與 Claude 驅動的 Thinking mode 並存;
Kimi K2.6 已開源,可通過 Kimi.ai、Kimi App、API 和 Kimi Code 使用,主打長程編碼、長時間執行與 agent swarm。官方稱其在內部 Kimi Code Bench 上較 K2.5 顯著提升:一個案例是在 Mac 上用 Zig 實現並最佳化推理,4000+ 次工具呼叫、連續執行 12 小時、14 輪迭代後吞吐從約 15 升至約 193 tokens/sec,比 LM Studio 快約 20%;
微軟發布 FrogNano-4B-2609,一個面向算力有限開發者的 4B 智慧體模型,Hugging Face 上已有 GGUF 量化版本。它由 Qwen3.5-4B 派生,沿用 32 層混合 Gated DeltaNet 與門控注意力架構,後訓練為純文字、聚焦倉庫級軟體工程,用強化學習在約 1500 個 TaskPilot 生成的合成 SWE 環境上訓練,獎勵來自可執行測試,配套五工具的 Leaf harness。與行為蒸餾不同,它不訓練強模型的解題軌跡。
使用者 basnijholt 在 Reddit 發帖並附上部落格文章,論證自託管 AI 並不比用 API 更省錢,但他表示自己照樣會做。他提出兩點:把 200 美元的訂閱(如 Opus 5.5、Astra)與 Qwen 3.8 27B 這類本地模型直接比價並不對等;他也不會把 200 GB 的郵件、聊天記錄和位置歷史交給 API,哪怕對方承諾零資料保留。帖子發出後引發了不少爭議。
llama.cpp 的 PR #29184(作者 am17an)提出在 CUDA 後端把 MoE 的共享專家融合進 MMVQ 運算元,為部分 MoE 架構(例如 Qwen 35B A3B)帶來推理加速。評論區給出的初步結論是 token 生成速度最多提升約 5%,屬於穩步積累而非革命性改動。該改動僅針對 CUDA 後端、且只對部分 MoE 架構生效,Metal 等其他後端不受影響。
Ai2 開源了 8B 的科學報告生成模型 AstaBrief,可把研究問題和檢索到的文獻片段直接寫成帶引用的報告。它已在 Asta 的 Generate a report 功能中以 Fast mode 上線,與 Claude 驅動的 Thinking mode 並列:Fast mode 平均 51.1 秒生成一份報告,Thinking mode 為 178.5 秒,快約 3.5 倍。模型基於 Qwen3-8B,用 SFT 加 DPO 訓練,一次成稿,跳過了片段摘要與聚類環節。
llama.cpp 發布建置 b11346,本次改動是修復 qwen4exp 的測試(PR #29819)。該版本繼續提供 macOS Apple Silicon(arm64)與 Intel(x64)、iOS XCFramework 預編譯包,Linux 與 Windows 覆蓋 CPU、Vulkan、CUDA 12.8/13.4、ROCm 10.0、OpenVINO、SYCL 等後端,另有 Android arm64 與 openEuler 版本。
NVIDIA DGX Spark 將新增 64GB 統一記憶體版本,10 月 23 日由 Acer、ASUS、Dell、Gigabyte、HP、MSI 開賣,起價 4999 美元,保留 GB10 Grace Blackwell 晶片、DGX OS 與完整 NVIDIA AI 軟體棧,可完全本地執行最高 1000 億引數模型。兩臺機器可用 QSFP 線經 ConnectX-7 直連,記憶體池化到 128GB,模型上限提到 2000 億引數;
openJiuwen 首發 X-Router 自演進模型路由技術,按任務複雜度在本地與雲端模型池中動態選模型,實測減少 50%+ Token 消耗。該平台由華為 2012 實驗室、華為雲等團隊聯合高校與企業建置,主打昇騰親和,路由分三層:優於 1 分鐘重新整理的模型能力畫像、結合 KV 快取親和與即時負載的啟發式決策、用 Contextual Bandit 與輕量強化學習做反饋自演進,樣本不足時保留原判定。
阿里 Qwen 宣布 Qwen3.8-27B 已可通過 Nebius 訪問。這是一個 27B 稠密模型,官方稱適用於建置 agent 與深度研究等多步驟工作流。原文未給出定價、上下文長度或部署方式等細節。
Hugging Face 於 2026 年 9 月 30 日上線 Open TTS Leaderboard,用客觀指標評測開源與多語言 TTS 模型,單次評測從收集投票的數週縮短到數小時。指標包括 WER/CER(用 Qwen3 ASR 轉寫)、H200 批次離線推理的 RTFx、H200 與 CPU 上的流式首音訊延遲 TTFA,以及 WavLM 說話人嵌入的餘弦相似度 SIM。
v0.35.1-rc0 為 create 請求新增可疊加的 capabilities 欄位,Modelfile 也可直接寫 CAPABILITY 宣告,且這些宣告會在 GGUF 與 safetensors 的建立、繼承和 Modelfile 匯出中保留。排程 System One 請求前改為要求 decision capability,不再靠匹配 Qwen 的架構/renderer 後設資料。
Ollama 發布 v0.40.0,在 Apple Silicon 裝置上,MLX 執行時支援的模型架構會自動改用 MLX 執行,無需手動切換。用法與以往一致,例如 ollama pull qwen3.8 後 ollama run qwen3.8。該版本目前為預發布版(v0.40.0-rc0,變更範圍 v0.34.4 到 v0.40.0-rc0),官方稱預發布期間會測試並啟用更多模型,尚未說明具體支援清單與效能差異。
v0.34.4 發布,更新了 llama.cpp、MLX 和 XGrammar,Qwen 3.8 的提示處理在 Apple Silicon 上更快,Gemma 4 會為每張圖片自動選擇最佳解析度以保留更多高畫質細節。思考模型的結構化輸出改為單次推理完成,速度更快也更可靠;同時修復了本地模型庫很大時偶發的 model not found 報錯,以及 macOS 應用在檢測 ChatGPT 或 Codex 是否執行時無回應的問題。
阿里 Qwen 團隊在 2026 年 9 月 23 日發布了一套基準測試套件,但公開資訊僅有一句“Benchmark suite:”,沒有披露測試專案、覆蓋模型、評分方式或開源地址等細節。目前無法判斷它針對哪類模型、是否包含 coding agent 或本地推理場景。
阿里 Qwen 團隊公開了 Mobile-Use Agent 的效能表現,但正文未給出具體跑分、測試基準或對比物件。該 Agent 面向移動端操作場景,目前僅有效能這一項資訊,發布時間為 2026 年 9 月 23 日。
阿里 Qwen 在 2026 年 9 月 23 日公布了 Mobile Creative Agent 的效能表現,但公開內容只有標題式的一句話,未給出具體跑分、測試基準、模型規模或使用方式。目前無法判斷它是否開源、能否本地部署,也沒有涉及 MLX、llama.cpp 等推理框架的資訊。
阿里 Qwen 公布了 Mobile Planner Agent 的效能表現,但披露內容僅為標題式資訊,未給出具體基準、測試環境或對比物件。該 Agent 面向移動端規劃任務,目前尚不清楚其支援的模型、呼叫方式與可用時間。
LM Studio 與 inco_ai 合作,在發布當天(day 0)就把 Splash 推理引擎接入 LM Studio。官方給出的資料是:在 M5 Max 上執行 Qwen3.8-27B,速度最高可達 144 tok/sec。想試的話可通過 LM Studio 官方部落格的連結直接跑起來。
Inco AI 發布開源推理引擎 Splash,專為在 Apple Silicon 上本地執行 Qwen3.6-35B-A3B 與 Qwen3.8-27B 最佳化,已整合進 LM Studio Bionic 1.1.5 及以上版本。在 48GB M5 Pro 測試中,Qwen3.8-27B 短提示解碼約 74 tokens/s、32K 上下文 54 tokens/s,約為次快引擎的兩倍;四個併發請求合計吞吐 170 tokens/s,是次快引擎的 3.9 倍。
Awni Hannun 稱 Qwen 27B dense 模型在 M5 Max 上輸出速度達 105 tok/s,並形容這一表現相當驚人。他同時表示這是在“一塊磚一塊磚地”突破記憶體牆。原文未說明所用推理框架、量化精度與上下文長度。