按兴趣浏览，循来源深入。
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 和可复算测试，读者可以按需核对每个数字而不是直接信任结论。
作者在相同的 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 花费对比，显示编辑成功率比裸速度更影响实际耗时。
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%。
推荐理由：作者在固定一台桌面机上实测本地模型的匹配度、速度和分数，并公开预测记录与纠错，方法可迁移到自己跑本地评测时参考。
作者用自写脚本在单张 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 的长上下文速度差异，并指出引擎配置和内存预算比引擎本身影响更大。
作者开源了在 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 部署的实测探针，给出各探针的真实运行结果与踩坑复盘，方法可直接复用。
作者在 AMD Ryzen AI MAX+ 395（Radeon 8060S iGPU、128 GB LPDDR5X 统一内存）一台机器上汇总了 42 个模型的生成速度实测数据。
推荐理由：作者在同一台 AMD Strix Halo 机器上实测 42 个模型的生成速度，并给出各引擎配置和测量口径，便于横向比较本地部署方案。
作者实测 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 优化在不同任务下的实际收益。
作者用 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 核显上实测三种量化的速度差异，给出了聊天与长上下文场景各自该选哪个格式的具体依据。