按兴趣浏览，循来源深入。
作者在相同的 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 花费对比，显示编辑成功率比裸速度更影响实际耗时。
作者 /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/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 行正则归一化工具输出这一可复用的降噪方法。
作者在 RTX Pro 6000 Blackwell 上对比 Ninfer6000、vLLM（NVFP4）与 llama.cpp（Q4_K_XL）运行 Qwen3.8-Flash-Next 的表现。Ninfer6000 平均 decode 238 tok/s，约为 vLLM 的 1.59 倍、llama.cpp 的 2.21 倍，但 prefill 低于 vLLM（约 10k 对 16k tok/s）；BFCL v4、IFEval、MMLU-Pro、HumanEval+、MBPP+、Arena-Hard、RULER 等基准三者基本持平。
推荐理由：作者在 RTX Pro 6000 上实测三套引擎跑 Qwen3.8-Flash-Next 的吞吐与基准数据，并给出真实使用中工具调用异常的细节。
Reddit 用户 /u/FeydRowan 实测 Qwen3.8-27B 从 UD-Q4_K_XL 到 Q8_0 的五个量化版本，发现它们在 GSM8K、MMLU-Pro 和 IFEval 上差距均在 ±2 分内，而自建的 112 次运行 agentic 编码基准（隐藏测试、AST 注入 bug）拉开差距：27B NVFP4 解题 77%，Flash-Next NVFP4 达 98%。SWE-rebench 交叉验证趋势一致（69% vs 82%，McNemar p≈0.007），OpenCode 等测试框架的选择对结果影响也很大，Flash-Next 约 3-bit 的 Q3 版本可解决 12 项区分性任务中的 11 项。
推荐理由：作者用自建、无污染的 agentic 编码基准区分了标准评测拉不开的量化差距，方法与数据都可复用。
/u/dh7net 实测 Qwen3.8-Flash-Next 的 IQ3_S 量化版（ISTA-DASLab GSQ-RCO GGUF）在 RTX 5090 上经 Strata 服务、pi harness 运行 airbench 测试套件，11 分钟拿到 100% 得分，而 Claude Code 同任务同分但耗时 14 分钟；作者更正原标题未说明这是面向日常任务的基准，不是区分前沿模型的评测。复现需 24GB 以上显存、约 64GB 内存和 90GB 磁盘，IQ3_S 在 256k 上下文下约需 78GB 内存。同一服务器上 omp 18.4.2 得 48/49（16 分钟）、opencode 1.18.29 得 46/49（11 分钟）、dsh 0.2.0-rc.2 得 47/49（11 分钟）。
推荐理由：作者在 RTX 5090 上实测同一本地模型配不同 Agent 框架的 airbench 得分与耗时，并给出可复现的完整部署配置。
shi3z 在 GitHub 发布 npc-llm-bench，用于定量比较本地LLM作为日语游戏NPC的对话质量与速度，结果收录在 RESULTS.md。基准含73个测试，覆盖日语自然度、人格维持、知识边界、记忆一致性、状态反映、角色差异、诱导耐性和长期对话，并测量TTFT、并发吞吐与VRAM，最终输出加权NPC Score与7种排行榜。
推荐理由：作者给出了游戏NPC场景的73项测试、评分权重和RTX 4090等硬件上的11个模型实测结果，方法可复用。
reliable-era 发布 karpathy-jev，一个 Claude Code 技能，在首次编辑和声明完成前的固定检查点收集 diff、命令与真实 exit code，交由独立的 TypeSafe Jev 判定 proceed 或 revise。SWE-bench Verified 20 任务上，Claude Code + Sonnet 5 下该方案解决 20/20，虚假完成声明 0 次（原生 2 次），最后一次编辑后真正跑测试的比例 13/20（原生 1/20）；解决数差异在 n=20 下不显著，单任务中位耗时 +8%。实验还发现 Sonnet 在 112 次运行中从未主动打开自愿式技能，强制 hooks 是行为改变的关键。
推荐理由：原文同时给出方法和实测数据，读者可以对照三种方案看到强制钩子与提示词自评在行为上的真实差别。
luongnv89 在 GitHub 开源 m-bench，一套针对自己机器基准测试完整 LLM 配置（serving 参数、thinking 模式、编码代理）的工具，每个任务附参考解，validate 需 28/28 通过。当前最佳配方为 unsloth/Qwen3.6-35B-A3B-NVFP4（MoE，约 3B 激活）跑 vLLM，关 thinking，core16+hard12 达 82.1% pass@1，吞吐约 35-48 tok/s 单流。多轮实测显示 thinking 对一次性代码生成多耗约 13 倍输出 token 仅换 +1.7 分，但在工具循环中可把轮次从 6.8 降到 5.2；同一权重经四个不同代理得分相差最多 23 分。
推荐理由：原文用多轮实测数据说明同一模型在不同配置和代理下得分差异巨大，为本地部署选型提供了可复用的基准方法和结论。
marinsokol5 在 GitHub 发布 am-i-nerfed，一个本地逻辑谜题自测工具，以 CLI 和 Agent Skill 形式判断模型当天是否被降智。任务由随机种子在本地生成，默认中等难度限时 180 秒，支持 Claude Code 和 Codex。2026-10-05 的初步横评中 gpt-6-astra 以 85.0% 排名第一，claude-opus-4-6 因从未在截止前保存答案得 0 分；作者还观察 to Anthropic 模型难以遵循简单指令、Fable 5.1 因安全分类器误拦无法可靠测试，以及 Anthropic 推理速度比 OpenAI 快约 4-6 倍。
推荐理由：工具让用户在自己的订阅环境里用私有任务自测模型当日状态，作者还附上了十三款模型的初步横评结果。
Microsoft 与 Hugging Face 联合发布 ThinkingBox 及 ThinkingBox-Bench，通过隔离 MCP 会话检查 Agent 留下的终端数据库状态和副作用，而非只看工具调用或回复文本，覆盖 507 个有状态业务工作流，每任务独立运行 20 次，已通过 OpenEnv 上线 Hugging Face。
推荐理由：基准不看工具调用而看数据库终态，18 个模型在 507 任务上跑 20 次，区分了单次成功与可依赖性，并给出每次可靠任务的成本对比。