llama.cpp 在 WebGPU 後端為 fill/set_rows 操作加入 f16 支援（PR #29897），併發布 b11382 版本。該版本覆蓋 macOS Apple Silicon、iOS、Linux、Android、Windows 等平台，其中 macOS Apple Silicon 的 KleidiAI 建置被停用。對使用 WebGPU 推理的使用者，f16 支援可減少視訊記憶體佔用並提升相容性。
llama.cpp 發布 b11381 版本，修復了 mtmd 在 Windows 上觸發的 strdup 棄用警告（#29863），由 Hugging Face 的 Adrien Gallouët 提交。該版本繼續提供 macOS Apple Silicon（arm64）、Linux、Windows、Android 等多平台預編譯包，其中 macOS Apple Silicon 的 KleidiAI 加速版被標記為 DISABLED。
llama.cpp 發布 b11380 版本，將依賴庫 cpp-httplib 升級到 0.59.0。該版本繼續為 macOS Apple Silicon（arm64）、Linux、Windows、Android 等平台提供預編譯建置，其中 macOS Apple Silicon 的 KleidiAI 加速版本被標記為 DISABLED。
一位 Home Assistant 使用者用 DW3000 UWB 開發板和六個電池標籤搭出 BinRange，判斷垃圾桶是否被推到存放區外，從而確認有沒有真的把垃圾拿出去。實驗顯示，10.1 米距離下平均讀數約 10.09 米、標準差 3 釐米；天線從平放改為豎立後，約十米處的成功率從 37% 升到 100%。整個專案用 Codex 輔助開發，包含自製韌體、3D 列印外殼和無線更新，但邊界和精度都針對他自己的安裝環境。
Jeffy 是一個本地執行的簡單分類器集合，無需 GPU，在普通電腦上即可使用，自帶 13 個已訓練好的分類器，覆蓋垃圾郵件檢測、意圖路由、主題分類、情感分析，甚至能玩 Doom。使用者還可以用它訓練自己的分類器，作者表示這種架構上還能搭建更多應用，並希望瞭解大家覺得哪些任務有用、類似任務用什麼架構。
開源推理引擎 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 量化帶來輕微精度損失。
一批極窄用途的推理執行時正在出現，包括 Strata、ninfer、DwarfStar、Splash、llamAmpere、gufo 等。它們刻意放棄 llama.cpp 和 vLLM 擅長的通用性，只針對少數模型、有時甚至只針對一個硬體家族（如 Strix Halo）做最佳化。作者認為未來通用執行時負責相容性、一次性專精執行時負責最大效能將成為常態，這也有助於智慧的民主化與去中心化，並壓榨現有硬體的更多產出。
Vx 是一門面向異構計算的系統程式語言，把 CPU、GPU、NPU 與加速器記憶體納入型別系統，主機執行緒解引用裝置指標會直接編譯報錯。它要求跨記憶體空間顯式呼叫 transfer()，並用機器檔案描述 H100、H200、B200、A100、MI300X、Apple M4 等真實硬體的記憶體層級與互連，編譯期校驗放置是否可行。
開發者發布 repopedia，一個 MIT 許可的原生代碼知識圖譜工具，pip 安裝後即可在倉庫上執行，用 tree-sitter 解析並生成 SQLite 圖譜檔案，無需伺服器、Docker 或 API key，程式碼不上傳雲端。它支援查詢函式呼叫者與改動影響範圍，並可通過 MCP server 讓 Claude Code 直接查圖譜，一次拿到帶 file:line 的精確答案，而非多輪 grep。
Docker 工程師 Dave Scott 指出，Docker Desktop 自 2016 年起就一直基於 microVM 技術執行，而非傳統 Linux 容器。2015 年起 Docker 用 Mirage Unikernel 庫建置了可嵌入的 library VMM，首版名為 hyperkit，最新版為 Docker VMM，核心與根檔案系統基於 LinuxKit 專案。
llama.cpp 合併 PR #29903，通過把 n_batch 限制在 n_ubatch 以內，修復了 server 的 laya abort 崩潰（#29902）。該修復由 Claude 輔助完成，並移除了相關測試與 embeddings 條件。
作者自建了魔獸世界私服，並做了一個可在 PC 和手機瀏覽器免費玩的客戶端 jankcraft.xyz，再用自訂 MCP 與 agent harness 通過 websocket 控制瀏覽器客戶端讓 LLM 自動遊玩，agent 頁面已上線。目前雲端訂閱使用者可能遇到問題，本地模型只要服務端開啟 CORS 即可接入；作者提供的現成模型會隨用量增長撤下。
llama.cpp 合併 PR #29860，新增 common_is_tty() 輔助函式並修復 Windows 上的棄用警告，作者為 Hugging Face 的 Adrien Gallouët。該提交同時更新了各平台預編譯產物，macOS Apple Silicon（arm64）正常提供，但啟用 KleidiAI 的 arm64 版本被標記為 DISABLED，openEuler 也處於 DISABLED 狀態。
llama.cpp 合併 PR #29813，讓 Ling 3.0 解析器支援 inputs.json_schema，此前 response_format 請求不受約束。新邏輯為回應格式語法路徑優先於工具呼叫，啟用思考時要求 JSON 前有 think 塊，且 JSON 後不允許尾隨文字。該修復對應 issue #29652，由 Claude Opus 5.5 輔助完成。
一位只有 8GB 視訊記憶體和 16GB 記憶體的使用者在社群表示，只能期待 Qwen4 35B A3B 或類似模型，並希望藉助額外 n-gram 把 35B 擴充套件到 70B 以上。在此之前，他仍偏愛 Gemma 26B QAT，稱其速度穩定在 26 Tg/s。
基於 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（程式碼場景）。
llama.cpp 合併 PR #29904，通過改用融合 ADD 容差修復了 f16 精度下 ADD_ADD 測試偶發失敗的問題。該改動只涉及 CI 測試容差，不改變推理邏輯，但會隨下一次建置進入各平台發布包，包括 macOS Apple Silicon arm64、Ubuntu CUDA 12/13、Windows CUDA 12/13 等。
llama.cpp 合併 PR #29856，把 build_rs 中分散的 get_rows 合併為一次收集全部 n_rs 個 recurrent states，使預留空間按 n_rs 最大值計算，避免 ubatch 單元不連續時在節點數不變的情況下觸發圖重分配、進而在 GGML_SCHED_NO_REALLOC 下中止。
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 通常是多數模型的甜點區，困惑度曲線相對平坦、視訊記憶體佔用大幅下降且推理能力幾乎無損。
德國 Aleph Alpha 在 Hugging Face 發布 Kolibri-1，78B 總引數、3.46B 啟用引數，支援最高 100 萬 token 上下文，Apache 2.0 許可。模型用 768 張 B300 訓練 4 周、20T token，語料約 62.5% 英文、23.9% 德文、13.6% 程式碼。目前尚無量化版本，llama.cpp 是否支援該架構未知，社群評測認為效能接近 Qwen 3.5 35B。
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 日。
OpenAI 發布 GPT-6.1 Sol，定價 $2/$10 每百萬輸入/輸出 token，比 Astra 的 $10/$50 便宜約 80%，在 DeepSWE v1.1 上比 GPT-6 Sol 高 6.4 分。Sonnet 5.5 在 Agent Arena 首秀排第 3 並在 Chat 類別登頂，Anthropic 包攬前三；Sol 每任務中位成本 $0.56，比 GPT-6 Sol 便宜 39%。
llama.cpp 合併 PR #29831，為 clef 決策模型加入純文字推理支援，並更新 gguf-py 常量。該版本覆蓋 macOS Apple Silicon、Linux、Windows、Android 等平台，其中 Apple Silicon 的 KleidiAI 加速建置被停用。
一位使用者為給 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）來偽裝型號，導致系統識別為假規格，連索引文字檔案都吃力，更別說跑向量檢索。該使用者已發起信用卡拒付。
LiquidAI 發布 LFM2.5-Encoder，含 350M 與 230M 兩個版本，基於 LFM2 架構的雙向掩碼語言模型，支援 15 種語言、8k 上下文，可微呼叫於分類、檢索、重排與語義相似度任務。官方稱其吞吐量追平或超過 ModernBERT，CPU 長上下文更強，並可通過 WebGPU 在瀏覽器執行；GGUF 權重已發布，llama.cpp 支援 PR 已提交。
有人在 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 發布建置版本 b11370，CUDA 後端新增將共享專家（shared experts）融合進 MMVQ 的改動（#29184），並修復緩衝區空值檢查、把 stride_col_dst 移入融合引數。
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 也可執行但效能較低。
mlsubgen 是一個完全在本機執行的字幕生成工具，支援 45 種語言，但僅限 Linux 和 NVIDIA 顯示卡。它按語音片段而非整檔案檢測語言，可處理混合語言素材；同時執行兩個語音識別器並由本地 LLM 調和結果，且優先使用檔案內嵌字幕（包括藍光 PGS 點陣圖字幕的 OCR），無字幕可讀時才轉錄音訊。作者在 24 GB RTX A5000 上執行，提供 16、12、8 GB 視訊記憶體配置，需 16–32 GB 系統記憶體和 30–65 GB 模型儲存；
有使用者用 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 #27694，把 simple draft 與 MTP 的投機解碼改為機率取樣，目標模型用拒絕取樣驗證草稿 token。新增開關控制機率草稿取樣，預設仍為貪心；語法約束請求回退到 argmax，並支援在拒絕取樣中處理語法約束。同時修復了草稿取樣器與目標模型共用 rng 流、掩碼後分布未重歸一化等問題，並隨草稿一起截斷候選。
llama.cpp 合併 PR #29817，在 qkx3 量化級別送入 nearest_int 前先鉗制到 [0, nmax]，避免 imatrix 縮放搜尋產生無窮、NaN 或越界值時觸發 Debug 建置斷言。該問題由 #29804 報告，修復同時為 q2_K、q4_K、q5_K、q4_1、q5_1 的退化 imatrix 分組補充迴歸測試。合法範圍內的取值行為不變，macOS Apple Silicon（arm64）等預編譯包已隨本次發布更新。
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 許可，原始碼與權重建置器稍後發布。
llama.cpp 合併 PR #27096，修復 ggml-cpu 中 GGML_OP_SOFT_MAX_BACK 在 dst 與 src1（y）別名時輸出靜默錯誤的問題。原因是原實現先覆蓋 y 再讀取，改為單次融合迴圈先讀兩個源再寫，並新增迴歸測試強制觸發該別名。CUDA 核心因先完成歸約再寫入，不受影響。