新闻、仓库与研究，按时间排列。
matnum 发布 local-llm-benchmarks 仓库，在 128 GB 统一内存的 AMD Ryzen AI Max+ 395（Strix Halo）上用 llama.cpp 对 10 个 GGUF 模型/量化组合在 Vulkan 与 ROCm 两个后端测吞吐、延迟、内存、功耗与 tokens-per-watt。结果显示 Vulkan 在 10/10 单元生成更快（6 个领先 2.1–18.0%），ROCm 在 9/10 单元 prefill 更快（6.2–56.8%）；MoE 模型生成速度和每瓦效率是同体量稠密模型的 5–8 倍，gpt-oss-120b（MXFP4，约 59 GiB）达 55.3 tok/s。
推荐理由：原文公开了完整测试矩阵、固定 commit 和可复算测试，读者可以按需核对每个数字而不是直接信任结论。
作者在单张 RTX 5090（400 W）加 128GB 内存的 Linux 机器上，对 Strata、Infernix、capy-flash、ninfer-ext、ninfer、llama.cpp 和 Basalt 七个 Qwen 3.8 FN 推理引擎做了基准测试，每个引擎各自转换 NVIDIA NVFP4 权重后跑相同的七个 greedy 请求，每个请求独立冷启动。
作者在相同的 Opus 5.5 规划、3 worker 并行设置下，用 llama.cpp Q8_0 在 RTX PRO 6000 Blackwell 96GB 上实测三个小型 MoE 编码同一个 Three.js 万圣节连锁反应场景。Flint 40B-A2.5B 综合最优：墙钟 7:36、修复 6 次、Opus 花费 $0.41；Nemotron 3.5 Lightning 解码最快但生成约 5 倍 token、修复 16 次、花费 $0.95，其编辑成功率仅约 17%。作者指出换 worker 模型使规划者账单从 $0.41 涨到 $0.95，裸 tok/s 并不决定总耗时，且三者在单轮内都没产出完全可用的场景。
推荐理由：同一任务同机实测三个小型 MoE 当编码 worker，给出 token 消耗与 Opus 花费对比，显示编辑成功率比裸速度更影响实际耗时。
Reddit 用户 /u/GapNew4766 在 M5 MacBook Pro 32GB 上用 Qwen3.5-4B（Q4_K_M、64K 上下文、llama-server）对 Pi、goose、Crush、Cline、OpenClaw、OpenCode、Hermes、Qwen Code、Codex CLI、Atomic Agent 共 10 个 Agent 框架各跑 5 个小任务，10 个中 6 个全部通过。失败不来自工具调用解析，而是精确匹配编辑无法逐字节复现旧文本导致反复重发、只修可见测试用例、数错 ERROR 行（40 vs 43）、模糊指令被字面执行写错位置；相同硬件和模型下最快框架 1m36s、最慢 17m43s，快 11 倍。
kevinelong 在 GitHub 发布 local-llm-lab 仓库，记录在一台 64 GB DDR5、RTX 5070 12 GB 的 Windows 桌面机上对本地大模型的系统实测，并列出 693 项检查的九套基准。最佳配置为 Qwen3.6-35B-A3B Q4_K_M 经 llama.cpp 预配置（context 131,072、--cpu-moe），以及由 Strata 流式从磁盘服务的 Qwen3.8-Flash-Next Q2_0，两者在排名指标 414/414、全部九套 692/693 上逐格持平，后者的 1,100 项知识测试快 31%。
推荐理由：作者在固定一台桌面机上实测本地模型的匹配度、速度和分数，并公开预测记录与纠错，方法可迁移到自己跑本地评测时参考。
Reddit r/LocalLLaMA 用户以《Anno 1602》游戏规则等冷门知识（禁用联网搜索）对比 6 个模型，Nemotron 3.5 Super VL 120B-A12B 错误最少，仅出现少量幻觉，其余模型（Gemma 4 31B IT QAT、DeepSeek v4 Flash Vision Exp、Qwen3.5-122B-A12B、Qwen3.8-flash-next、GPT-OSS 120B）均幻觉出错误升级条件或游戏版本。该模型 NVFP4 量化版在双 RTX 5060 Ti 16GB + 双 48GB DDR5-6000MHz 上以 llama.cpp 运行，生成约 8-10 t/s、处理约 150-170 t/s。
用户在 16GB VRAM 上用 llama.cpp 测试 NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB-GGUF（IQ2_XSS 官方量化），20k 输入、贪心解码下 v0.7.0 达 168.8 tok/s，为各构建方案最佳，其余变体差异在噪声范围内。Strata 风格的专家路由 profiler 经 #30594 可用于 llama.cpp，但混合模式因 PCIe Gen5 x16 上传快于 CPU 计算而降至 89–98 tok/s；GPU 缓存预热后命中率约 82%。专家缓存 7.5 GB 为安全上限，draft 默认设置（每步 3 token、无置信阈值）最优。
LiquidAI 的 LFM2.5-24B-A2B 在 Pi Agent 中表现可靠，作者用它替换 Ornith 1.5-35B 后运行良好。在 AMD W7900 上经 llama.cpp（ROCm）实测持续约 95 tps，Q8 量化加 128k 上下文占用 30GB 显存，机械性长任务稳定通过。
作者用自写脚本在单张 Tesla V100-SXM2 32GB 上实测了 Ollama 与 llama.cpp 跑 llama3.2:1b、Qwen3-30B-A3B-Thinking、Gemma 4 31B、Qwen3-Coder-30B-A3B 等模型的生成与 prefill 速度，请求长度从 1K 到约 118K token。数据显示引擎加配置才是对比单位，如 Qwen3-30B 上 Ollama 生成随上下文增长快 17% 到 49%，而 llama.cpp 用 q8_0 KV 缓存才装下 131072 窗口；作者还发现 Ollama 对 gemma4-32k 报告的 56 tok/s 和 2.1GB 显存不可信，超过 31B 稠密模型约 44 tok/s 的物理上限。
推荐理由：作者在单卡 V100 上实测了多款模型在 Ollama 与 llama.cpp 的长上下文速度差异，并指出引擎配置和内存预算比引擎本身影响更大。
Reddit 用户在租用的 RTX 4090 上用同一任务对比了四款开源决策模型 Laya、d1 3B、Clef-Flash 9B 和 Lev 4B：逐词调用 /v1/systemone 判断 9,534 个词是否为蜈蚣名称。Laya 每词 p50 仅 3.9 ms、32 秒处理 7,980 词，是最快的选择；Lev 准确率最高（98.9%）但每词 51.0 ms，比 Laya 慢 13 倍。
作者开源了在 RTX 3060 12GB 与 RTX 3090 24GB 两套本地平台上、用 llama.cpp、ik-llama.cpp、moe-cache 分支、vLLM 0.29.0 容器栈和 Strata 引擎跑本地模型的基准报告，含量化档位、上下文长度、prefill/decode 速度表，以及一个基于 Shoko-WebUI 重写任务的 agentic 编码基准，附完整测量方法与逐引擎参数说明。
推荐理由：作者在两套消费级 GPU 配置上实测多个 llama.cpp 分支与引擎的本地推理速度，方法、参数和完整数据公开，结果可直接对比参考。
作者发布了本地 llama.cpp 模型基准测试套件，测试环境为 Tesla V100 32GB 加 RTX 3060 12GB 双 GPU，llama.cpp v9836（upstream-dflash 分支），统一 8K 上下文并开启 flash attention。结果显示 V100 上 MTP 推测解码带来明显收益，Qwopus3.6-27B-Coder-Compat 在 MTP n=3 下达 40.3 tok/s，比无推测快 29%；而 35B MoE 模型在 RTX 3060 上 MTP 反而拖慢速度（25.5 降至 16.9 tok/s），建议该卡用 no-spec 并开启 --cpu-moe。
推荐理由：作者在双 GPU 本地系统实测了 MTP 推测解码的适用边界，27B 密集模型受益而 35B MoE 反而变慢，结论可直接迁移到类似硬件选型。
作者在单张 RTX 2080 Ti 22GB 上用 Unsloth UD-IQ4_XS 4-bit 量化实测 Qwen3.6-35B-A3B，HumanEval 全部 164 题 pass@1 达 89.63%（147/164）。随后对自制的 MoE expansion 路由补丁做受控 A/B：在最后 15 层（25–39）每 token 激活 20 个专家而非原生 top-8，无需重训或改文件，pass@1 升至 90.85%（149/164），解码速度从 69 tok/s 降至 56 tok/s（约 -19%）。作者提示 +2 题在 164 题的统计噪声范围内，且用的是原始 HumanEval 而非 EvalPlus，不能与 EvalPlus 榜单直接对比。
推荐理由：作者给出了同机同量化下的受控 A/B 数据和解码速度代价，读者可以据此自行判断该路由补丁是否值得用。
halu-sys 在 GitHub 开源 llm-probes，为本地 llama.cpp/llama-swap 栈提供部署级评测探针，回答只有本机才能回答的问题，如 IQ3_S 量化下 262k 上下文是否真实、长上下文格式遵循、循环退化率、MTP 投机解码是否无损、跨上下文事实组合与多跳 Agent 委托链等。所有探针运行时程序化生成（可复现、无训练数据污染），由代码评分而非 LLM 评分。实测显示 Qwen3.8-Flash-Next IQ3_S 在 8k–256k 各探针多数通过，并总结了推理预算不足会静默吞掉答案、参数剥离使评测失效、探针自矛盾曾误导结论等六起生产事故复盘。
推荐理由：针对本地 llama.cpp/llama-swap 部署的实测探针，给出各探针的真实运行结果与踩坑复盘，方法可直接复用。
网友在 RTX 3060 12GB + RTX 3070 8GB 双卡、48GB DDR4 的 Windows llama.cpp 环境下，用 Glimmer 30B IQ4_XS 主模型搭配 Glimmer 30B DFlash Q4_0 草稿模型实测推理速度。
作者在 AMD Ryzen AI MAX+ 395（Radeon 8060S iGPU、128 GB LPDDR5X 统一内存）一台机器上汇总了 42 个模型的生成速度实测数据。
推荐理由：作者在同一台 AMD Strix Halo 机器上实测 42 个模型的生成速度，并给出各引擎配置和测量口径，便于横向比较本地部署方案。
该 GitHub 仓库测试在两张 Tesla P100-PCIE-16GB（共 32 GB VRAM、llama.cpp CUDA 12.6 sm_60 构建）上哪个本地 LLM 综合表现最佳，覆盖准确率、编辑、工具调用、速度与调优及 AIOS planner 测试，时间为 2026 年 9–10 月。
作者实测 Orange Pi 5 Plus（RK3588、16GB）运行本地大模型的表现，发现把 Ollama 限制到 4 个 A76 大核可带来最高 +318% 提速，Qwen 2.5 1.5B 达 14.5 tok/s，而 Llama 3.1 8B 受 LPDDR4x 带宽限制仅 2.3 tok/s 且裸片温度达 85°C。
推荐理由：作者用同一块板子实测了线程数、NPU 与散热的取舍，给出了各档模型的 tok/s 和温度数据，可迁移到其他 RK3588 部署场景。
ggml-org/llama.cpp 收到编号 #29869 的 Pull Request，为 Metal 后端加入 few-row MMA matmul 与批量拷贝以加速推测解码。
推荐理由：原文给出了同一环境下 PR 前后 DFlash2 推测解码的 decode tok/s 对照，读者可以据此评估该 Metal 优化在不同任务下的实际收益。
作者在双 AMD Radeon Instinct MI50（gfx906，合计 32GB 显存，功耗限制 145W）上对比了 llama.cpp 的 ROCm 10.2（TheRock tarball。
作者用 llama.cpp Vulkan 版在搭载 AMD Ryzen 7 6800H 与 Radeon 680M 核显、64GB DDR5 的 Acemagic miniPC 上，实测 GLM-4.7-Flash 的 MXFP4、Q4_K_M、Q4_K_XL 三种量化（内部 GGUF 头均报告为 deepseek2 30B.A3B MoE）。
推荐理由：作者在 AMD 680M 核显上实测三种量化的速度差异，给出了聊天与长上下文场景各自该选哪个格式的具体依据。