按兴趣浏览，循来源深入。
/u/iam31337 在 RTX PRO 4000 Blackwell SFF（24 GB，工厂 70 W 无辅助供电）上用修改版 VBIOS 将功率提至 120 W，Qwen3.8 27B 生成从 35.04 提升到 58.53 tok/s（+67%），Qwen3.6 35B A3B 显存 +33.3% 时生成 +19.8%。158 次请求、每配置仅 1-3 次，两模型量化与投机解码设置不同，非严格受控对比；作者提醒 120 W 超出 PCIe 75 W 槽位预算，属实验性结果。全文与 CSV 见 https://piszczek.pl/blog/rtx-pro-4000-blackwell-sff-120w-qwen-benchmark
推荐理由：作者实测同一款卡上两个模型的功耗超频收益差异，给出具体功率与频率参数，并坦承样本量与量化设置的局限。
Lavie-purple 发布 llm-radar 开源项目，将 LMArena、Artificial Analysis、llm-stats、LiveBench 四个评测源按 6 大类 17 子类并排呈现，不合成总分，只展示源内名次与跨源分歧度。页面零依赖、双击 index.html 即可打开，数据管道仅用 Python 标准库；当前快照收录 195 个模型、矩阵 124×17 共 2108 格，填充率 18.1%。项目还内置 selftest.js（236 条断言）、visual_check.js（148 项）、falsify.py（17 条证伪用例）与 check_deploy.js 四层守卫，并记录了 LiveBench 2.0 改版适配、抓取体检、行尾差异等实测踩坑。
推荐理由：作者解释了为何不合成跨源总分、分歧度如何计算，以及四层自检守卫的实测踩坑，方法可直接迁移到类似数据管道。
作者发布 llm-deployment-benchmarks 项目，在 Fireworks AI 上做两组实验，比较开源模型与 Claude Opus 5.5 的准确率、延迟和成本。支持工单分诊任务中，GPT-OSS 120B 以 34–45 倍更低成本追平 Claude Opus 5.5，9B 模型响应快 4–7 倍也打平，而对含噪标签微调反而变差；国际象棋任务中，对 73k 局面的微调把合法走子率从 36% 提到 71%，但最佳走子准确率仍是 3%，只有前沿级开源模型 Ember-1 接近 Claude，约为每步 4 倍时间和成本。
推荐理由：作者用支持工单分诊和国际象棋两类任务实测开源模型与 Claude Opus 5.5 的差距，结论是 prompt 质量常比模型大小更关键。
作者在 3090 上用 Allganize 韩文 RAG 数据集（300 题、64 份 PDF）实测，qwen3.8 27B 开启 thinking 得 77.3%，Opus 5.5 得 76.6%，McNemar 检验 p=0.82 属于打平。Opus 5.5 的 70 次失败中仅 25 次是模型问题，22 次源于无文本层的扫描页，作者认为瓶颈在 PDF 解析而非模型；韩文形态学分词器把 BM25 的 hit@5 从 56% 提到 80%，gpt-oss 20B 在把 token 上限从 1024 提到 8192 后从 57.5% 升至 69.6%。
推荐理由：作者用带标准答案的韩文 RAG 数据集实测并给出 McNemar 检验和失败归因，还指出 PDF 解析而非模型才是瓶颈。
作者在 M3 Max 36GB 上用统一协议实测 Kapitsa 0.2.12、oMLX 0.7.2、Rapid-MLX 0.16.8、Splash 1.4.0、MTPLX 2.12.2 五个引擎。稠密 Qwen3.8-27B-4bit 上 Kapitsa 41.3 tok/s 领先，oMLX 34.1；MoE Qwen3.6-35B-A3B 上 oMLX 122.9 与 Kapitsa 122.7 打平；Flint 40B-A2.5B 在 36GB 上由 Kapitsa 跑出 134.2 tok/s。oMLX 稠密从 17.9 提到 34.1 主要归功于 oQ4e-mtp 检查点加 Lightning MTP 的投机配置而非引擎本身；MTP 接受率稠密 75-78%、MoE 81-85%。
推荐理由：同一台 Mac 上五个推理引擎用统一协议实测，还标明各引擎权重与投机配置差异，数字可直接对照自家硬件选型。
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 花费对比，显示编辑成功率比裸速度更影响实际耗时。
Shinzuu 发布 free-model-bakeoff 评测，六个免费模型在 126 次评分尝试、14 个对抗性问题上跑生产级 tool-calling 流程。openai/gpt-oss-20b 答对 88%、工具路由正确率 95%，超过比它大六倍的模型（64%/76%）；同一权重换托管方降到 64%、中位延迟 28 秒。关键发现包括每日 20 万 token 的隐性限额（约等于全团队每天 60 个问题）、一句补充 'open' 定义的系统提示词带来最大准确率提升，以及评测中发现并修复的六个 harness bug。
推荐理由：实测给出六个免费模型的准确率与工具路由数据，并指出同权重不同托管方的表现差异可能比模型间差距更大。
作者 /u/Joralk_ 自建 harness，在 2× RTX 5080 上以统一采样配置实测 8 个本地 GGUF 模型的工具调用、代码与 agent 任务，每任务跑 3 个种子并统计均值与标准差。结果显示 125B 的 Qwen3.8-Flash-Next 并非榜首，35B MiniCPM-V-4.7 与 27B Qwen3.8 在 agent 任务上与其持平，工具调用可靠性比模型规模更关键；开启 thinking 模式使 27B 代码分从 0.79 升至 0.93、agent 分从 0.90 升至 0.96，但延迟从 36 ms 增至 629 ms 且每调用多花约 253 个中位 token。
推荐理由：作者自建 harness 实测 8 个本地 GGUF 模型的工具调用与 agent 编码表现，还给出 thinking 模式开关的量化代价，方法可复用。
作者开源 agents-per-gpu 仓库，在单张 48 GB A40 上以 Agent 形态负载实测 vLLM 0.32.0、SGLang 0.5.9 和 TensorRT-LLM 1.2.1 服务 Qwen3-4B 的并发容量。开启 prefix caching 后三个引擎均能承载 6 个并发 Agent 会话，关闭时仅 2 到 3 个，且每任务成本降至原来的三分之一到五分之二；8 秒 step SLO 下 SGLang 以 4 个会话领先。INT4-AWQ 量化的 Qwen3-8B 在工具调用精度持平的情况下比 BF16 的 4B 承载更多 Agent。所有数字可用 apg report 从 results/ 复现，方法与细节见 reports/REPORT.md。
推荐理由：作者在单张 A40 上实测三种推理引擎的 Agent 并发容量，并给出 prefix caching 带来的容量差和每任务成本数据。
/u/Dodgy_Past 在 Reddit r/LocalLLaMA 发帖，自建包含 44 个真实 bug 的测试集，让 Qwen3.8 27B 与 Gemma 4 31B 在两张消费级显卡上多轮辩论修复方案，得分 38/44、5 个假通过，而两模型单独作答为 31 和 30 分，也超过了 Nemotron 3.5 Super VL 120B 等更大的 MoE。增益主要来自约六个两模型各自都解不对的案例，但假通过几乎未改善（从 6 降到 5）；作者还发现共享完整推理与只共享提案没有可测差异，每题约花 6 次模型调用和 5 分钟 GPU 时间。
推荐理由：作者自建44个真实bug的测试集，实测两个中型模型辩论修复比单独作答和更大的MoE都更准，并给出假通过率与成本数据。
/u/SamSausages 因 Intel B65 几乎没有公开跑分，自建 4x B65 平台，用 vLLM 对 Flash-Next W4A16 和 Qwen3.8-27B 的 INT4、FP8、BF16 等配置做长上下文吞吐扫描，覆盖 0 到 200K 上下文和 1 到 16 并发请求。数据显示 Flash-Next 开启 MTP-3 后单请求吞吐约翻倍（0 上下文 84.5 对 42.7 tokens/sec），200K 上下文下降到 45.8；Qwen3.8-27B INT4 在 4 卡下 8 并发可达 468.2 tokens/sec。
推荐理由：作者自建 4x Intel B65 平台，实测多款模型在 16K 到 200K 上下文下的吞吐数据，并给出 MTP 开关与不同精度的对照。
作者以 HF transformers 的 F16 参考输出为基准，在 Neoverse-N1 ARM 和 AVX2 x86 上实测低比特 GGUF 的正确性与速度。BitNet b1.58 2B4T 的 bitnet.cpp main（0b341e5）在 x86 上困惑度约为参考的 6 倍、ARM 上输出 ?，#588 激活函数修复加 isHuangXin/llama.cpp#2 可解决，#642 第三版已同时修复两个平台；Bonsai/Ternary-Bonsai 1.7B 在 llama.cpp、Prism fork 和 ik_llama.cpp 中均与参考一致，27B 在 Prism 与 ik_llama.cpp 结果一致。
推荐理由：作者用困惑度和 KL 对照参考实现逐项验证低比特模型输出正确性，并给出各运行时的实测速度数据，方法可复用。
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%。
推荐理由：作者在固定一台桌面机上实测本地模型的匹配度、速度和分数，并公开预测记录与纠错，方法可迁移到自己跑本地评测时参考。
/u/HauntingMoment 在 r/LocalLLaMA 报告，单工具的裸 IPython harness 在 Terminal-Bench Lite 上用 Qwen3.5-9B 追平了 QwenCode、OpenHands、opencode、Pi 等更重的生产级 harness。测试发现小模型 agent 的大部分随机性来自环境噪声而非模型本身，各 harness 约 25-30% 的调用用于读文件，工具使用更多反映系统提示词而非模型；OpenHands 因默认硬编码 temperature=0.0 最稳定，但同一任务 20 次试验的通过率仍在不同任务间大幅波动。
推荐理由：作者用多 harness 对照实测定位了小模型 agent 波动的来源，并给出约 40 行正则归一化工具输出这一可复用的降噪方法。
/u/FeydRowan 在 2× RTX 5070 Ti + 96 GB DDR5 上整理了可运行 Qwen3.8-27B 和 Flash-Next（125B MoE、6B 激活）的各推理引擎 decode 速度，区分了本人验证与作者自报数据，capy-flash（DFlash2）在 27B 上达 379 tok/s。文中指出 TP 比层切分更快、drafter 可带来 2–3× 加速、单模型内核在 batch 1 下比通用引擎快 2–6×；按本月欧盟含税价折算，两张中端卡每欧元性能比 5090 高 3–10×，且 96 GB DDR5 涨价后约占专家放内存方案成本的 40%。
推荐理由：作者在同一台机器上实测多款推理引擎并按欧元换算每千欧元的 tok/s，还指出 2026 年 RAM 涨价改变了性价比排序。
作者在一张 RX 9060 XT（16GB）上用五项编码任务实测十个模型，每轮只给 spec 文件，需自行产出 solution.py 和 test_solution.py 并跑测试，由模型看不到的 checker 评分，单格上限 1750 秒。deepseek-v4.1-flash 云端 API 与 Qwen3.8-27B UD-IQ4_XS+MTP（kvstream fork）均 5/5，前者 236 秒 43k tokens，后者 94 分钟 185k tokens；其余本地模型多在 4/5 或更低，c4、c5 是主要分水岭，失败集中在 tie-break 规则、嵌套组解析和用 re 回溯导致超时或内存暴涨。
推荐理由：作者自建带盲测 checker 和性能门槛的编码评测，在 16GB 显卡上实测十个模型，失败原因逐个拆到具体规则和实现细节。
PipeRoll 开源了 seismograph 仓库，一个独立模型行为观测站，自 2026-08-20 起每日对 43 个文本模型（16 家实验室，含 Anthropic、OpenAI、Google、DeepSeek 等）运行固定探针电池，发布行为漂移的 witnessed readings，实测已上线（seismo.piperoll.org）。设计上采用双层电池：Tier 1 固定探针累积基线，Tier 2 每次程序化生成新题用于检测评估作弊导致的固定分与新鲜分 divergence；每次读数经 cosign 签名锚定到 Rekor，附完整 provenance。
推荐理由：每日固定探针加冻结基线的设计，把模型行为漂移变成可追溯的观测记录，方法论与治理规则都公开可查。
Reddit 用户 /u/Sanbi_Ai 复盘 Kimi K3 发布三个月后的实际使用状况：全模型 1.56 TB，Unsloth 推荐的最小量化为 594 GB，需约 610 GB RAM+VRAM，装不进 512 GB；1-bit 量化与全模型下一 token 一致率 79%，2-bit 达 90% 但需 861 GB。其在 Artificial Analysis 指数已从 57 降至 44，GLM-5.3（753B）得 45，Step 5 Preview（600B）以 44 追平；自家 API 仅 43 tok/s，AA agentic 基准平均每任务近一小时、超 $10。许可证非 MIT，公司若 12 个月内总收入超 $20M 需与 Moonshot 另行签约。
推荐理由：作者用 Unsloth 量化文档和 AA 数据逐项核算了 Kimi K3 的本地运行门槛、API 速度和许可证限制，信息可直接用于部署决策。
Reddit 用户 /u/Aroochacha 在自己的 4x DGX Spark 上复测 DeepSeek-V4.1-Flash，并与 Wccftech 报道的 Patrick Moorhead 结果对比。他指出 Wccftech 所列 476 GB 内存占用实为磁盘上的 476 GiB（511 GB），模型权重本身 511 GB，实际只能用每台 Spark 约 80%-92% 的内存，模型无法完整驻留内存，需用 SGLang TP4 加从各节点本地 NVMe 流式读取的约 196 GB Engram 表（带约 4 GB row cache）才能跑起来。
推荐理由：作者在自建 4x DGX Spark 上复测 DeepSeek V4.1 Flash，给出逐档 prompt 的完整数据，并指出 Wccftech 把磁盘占用误报为内存需求。