新闻、仓库与研究，按时间排列。
GitHub 新仓库 realtime-drama-test-log 是互动剧“观众自由输入 → 实时生成男主回应视频”的测试记录板，按剧集分区、每条记录一张卡片，包含完整视频、对话内容、各段计时及画面硬错误、是否左右她、时延、关键节拍是否落在她身上四个标记。仓库含 720p 视频目录 v/、附外挂中英字幕 .vtt 的成片目录 film/，数据集中存于 data.js，由 build_log.py 生成，更新后需修改 index.html 中的版本号避免缓存。
GitHub 上一个名为 G-llm-benchmark 的项目正在构建编码智能体的成本×质量基准，对比本地运行的 Strata（独立运行或由 Opus 驱动）与 Haiku、Sonnet 和 Opus 的表现。目前四个任务已全部写好，所有参赛者通过了 smoke runs，validate、plan、run、collect 和 smoke 等状态命令可用，依赖包括 Linux、uv、Claude Code、Firejail 和 jq。作者将手动比较各交付物，完整报告尚未出炉。
/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
推荐理由：作者实测同一款卡上两个模型的功耗超频收益差异，给出具体功率与频率参数，并坦承样本量与量化设置的局限。
beatspy 以协议 v2 对 17 个决策模型进行基准测试：模型读取相同的冻结市场状态（新增 RSI-14、30 天已实现波动率等特征），回答概率问题并按校准度与相对 SPY 的收益评分。三窗口（各 6 个月）结果中最佳平均超额仅 +0.48pp，无模型 Brier skill 为正，仅 jev-latest 和 subq-snap-1.1 在两个窗口跑赢 SPY 且优势落在 bootstrap 区间内；整个 16 模型评测仅花费约 $0.19。
一位 SillyTavern 用户分享了 Argon 模型管理复杂高奇幻世界观设定的体验：约 80 条 lorebook，涵盖货币、地理、历史、虚构语言、历法和魔法系统，Argon 是首个能保持这些细节连贯性的模型，配合 Megumin suite v10 使用，表现连 Claude 等 SOTA 模型都未能达到，只是它总爱把所有人叫成"Vance"。
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 改版适配、抓取体检、行尾差异等实测踩坑。
推荐理由：作者解释了为何不合成跨源总分、分歧度如何计算，以及四层自检守卫的实测踩坑，方法可直接迁移到类似数据管道。
Reddit 用户 /u/Individual_Page9676 让云端 Agent 通过 Tailscale + LM Studio 调用本地 Mac 上的 Qwen3.6-35B-A3B，构建了一套验证式数据管线：模型自编 800 道数学题后在新会话中盲解，分歧交由 Qwopus 3.5 122B 仲裁，Agent 用 Python 暴力核算，最终得到 793 道可用题。盲解者在仲裁分歧中 56 次正确、作者 12 次，说明出题写官方答案比解题更易出错；第三轮复验中 793 个答案有 774 个被直接确认，甚至抓出 Agent 自己暴力核算写错的一道题。
legal-eye-eval 是希伯来语法律 RAG 系统 Legal Eye 的公开质量评测仓库，其答案逐字引用真实以色列判例，不接外部 LLM，最新 50 题评测中幻觉引文率为 0%、5/5 超范围问题全部拒答。评测由 GitHub Actions 每周日自动重跑，但按 2026-10-24 起的 strict verdict 仅 24/50（48%）通过，未达到 85% 的发布门槛。语料仅覆盖以色列最高法院 2022 年快照共 751,194 份文档，冻结测试集上法律题通过率为 19/30。
r/LocalLLaMA 网友发帖质疑 AA 等基准测试无法反映模型真实能力，指出部分在编程基准上接近前沿的 benchmaxxed 模型除写诗外几乎不可用。楼主征求编程、智能体研究和办公工作方面最贴近实际使用的基准测试推荐。
Reddit r/LocalLLaMA 用户分享了发布 9 天后测试 Beam 1.0（501B 参数、23B 激活）的体验：借助第三方 provider 运行速度很快，能轻松浏览大型代码库，在 Rust、PHP、Python 和 JS 上表现良好，回答简洁有度且会使用技能。缺点是偶尔循环、部分 toolcall 失败，3D 能力弱且无视觉功能。
/u/yehyakar 在 RTX 5080 16GB、Core Ultra 9 285K、62GB DDR5-6800 环境下用 Basalt 测试 Qwen3.8-Flash-Next IQ3_S，262K 上下文、int8 KV。上下文扫描（15K-207K）平均 prompt 处理 5,475 tok/s、峰值 5,662 tok/s，生成平均 154.9 tok/s、峰值 186.6 tok/s；Agent 编码会话（opencode 103 次请求、最高 130K ctx）生成平均 153.0 tok/s、峰值 262 tok/s，99.5% 的 prompt token 来自缓存，首 token 中位时间 0.2 秒，显存占用 15.7GB。
作者发布 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 质量常比模型大小更关键。
/u/mesolimbic-bliss 用三套 harness 实测 unsloth/flint-GGUF 的 flint-UD-Q3_K_XL.gguf，成绩差异很大：OMP 完成 12 个任务得 71.2/100（仅 7 个解决），AtomicAgent 得 39.2/100（仅 3 个解决），Hermes 在任务 7 中途停止，因在文件系统上做了大量无谓的广度搜索并陷入循环。DeepSeek 版因此前 harness 失败和低分未运行。完整榜单见 https://shortbench.vercel.app/，目前已有模型达到 100/100。
ds-ml-bench 是一个用于评测大语言模型在数据科学与机器学习任务上表现的 benchmark 测试框架。每个任务是 tasks/ 下的独立 Python 模块，通过适配器层接入模型，由 Claude 作为 judge 按评分标准打分，覆盖数据清洗、EDA、特征工程、建模、统计、排序推荐（如 MovieLens 和 Recall@k）及 ML 系统设计等类别。用户复制 config.example.yaml 并通过环境变量配置 MOONSHOT_API_KEY 与 ANTHROPROPIC_API_KEY 即可运行。
作者在 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 上五个推理引擎用统一协议实测，还标明各引擎权重与投机配置差异，数字可直接对照自家硬件选型。
一位 r/LocalLLaMA 用户发布了自己在 16GB VRAM、32GB RAM 环境下进行的 5 项算法任务模型测试 V2，相比上一版收紧了任务设置并更换了参测模型阵容，同时开源了 GitHub 仓库供他人复现。结果显示 CyberTiel 和 Ornith 表现意外出色，而 LFM 和 Mellum 在真实负载下表现不佳。
Reddit 用户实测 Spark X2.6 4B，称其工具调用能力在同级模型中表现出色。在 pi cli 测试中，它能编写 Blender Python 脚本生成并渲染红色立方体，理解复杂 Rust 代码库，12 次工具调用即完成任务，还能读取全局 agents.md 并在每轮后列出变更文件。模型小、速度快、KV cache 占用小，temp 1.0 下思考精准，但缺少视觉能力，MTP 支持即将跟进。
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 和可复算测试，读者可以按需核对每个数字而不是直接信任结论。
GitHub 上的 video-llm-evaluation-harness 项目是一个视频大语言模型评测框架，涵盖数据集集成、评测指标与训练模块，为评估视频类 LLM 提供完整工具链。
Reddit r/LocalLLaMA 用户 EmilPi 发布近期测试模型的量化版本初步 benchmark 结果，DeepSeek-V4-Flash-Vision-Exp（MXFP4）以 Delta score 2.86 居首，Qwen3.8-Flash-Next-Q4KXL-STRATA 得 2.38。测试覆盖智能体编程、推理、空间推理等任务，作者在 2xRTX3090+128GB RAM 上发现没有新模型超越数月前的 DeepSeek/Qwen 老模型，并意外发现 Qwen3.8-Flash-Next 加 Strata 无质量损失且更快。
GitHub 上的 MCP-Universe-Research 仓库提供一个评测框架，用于评估 LLM 使用 MCP 这一新技术的表现。仓库目前处于早期阶段，尚无 star、fork 或 release。
作者让 Kimi K3.1 与 GPT-6 Astra 各跑一次相同的 Three.js 3D 飞行 Agent 任务并对比数据。K3.1 用时 12:28、20 步、读 725K prompt tokens、输出 49.2K tokens，Astra 用时 9:17、35 步、读 1.2M prompt tokens、输出 22.2K tokens；K3.1 推理占比 56%、成本约 $1.1-1.4（估算），Astra 约 $2.63。作者指出步数少可减少 prefill 负担但 decode 更重，并提醒本地部署需在所有子调用中固定 temperature 为 1；K3.1 因图像审查工具参数错误盲跑，Astra 首跑因工具参数问题被拒 29 次调用。各仅一次运行，成本为估算。
一个进行中的 GitHub 项目审计 Chatbot Arena 人类偏好标签，测量长度偏差（更长的回答更容易胜出）和位置偏差，并检验 Claude Haiku 等零样本 LLM 裁判及 LightGBM、DeBERTa-v3 微调、Gemma / Qwen LoRA 等训练模型是否会复现或放大这些偏差。评估采用按 prompt hash 分组的锁定 10% 测试集加 5 折交叉验证，指标为 winner_model_a / winner_model_b / winner_tie 的多分类 log loss。
该仓库收录了一系列大模型本地与云端实测报告：最新一篇对比 Claude Opus 5.5（Claude Code）与 GPT 6.1 sol（Codex）在同一 WebGL 任务上的表现；其余测试集中在 Qwen3.8-27B 8-bit（MLX affine8 / MLTF q8c / GGUF Q8_0）上，覆盖 256K 上下文压力测试、128K vision 性能、MLTF 与 mlx-vlm 对比，以及 DeepSeek V4.1 Flash 的 AI Werewolf 十局游戏测试等场景。
用户用“生成鹈鹕骑自行车的高保真场景”提示词测试 Kimi K3.1 Pro，默认思考（max）模式下上下文占用约 160k tokens，经 Pi.dev harness 运行。结果优于发布时的 Opus 5.5，但与 Opus 5.5 和 astra 6 仍有明显差距，作者认为即将发布的开源权重模型在 3D 理解上进步巨大。
作者在单张 RTX 5090（400 W）加 128GB 内存的 Linux 机器上，对 Strata、Infernix、capy-flash、ninfer-ext、ninfer、llama.cpp 和 Basalt 七个 Qwen 3.8 FN 推理引擎做了基准测试，每个引擎各自转换 NVIDIA NVFP4 权重后跑相同的七个 greedy 请求，每个请求独立冷启动。
作者实测 DeepSeek-V4.1-Flash-1017 后认为不如 Qwen3.8-Flash-Next：DSF 坚称 Broadwell-EP 有 AVX-512、拒绝从 libgen 下载论文，而 QFN 20 分钟完成同样任务。让四个模型对比 AI 泡沫与历史泡沫后，Opus 5.5 评审发现 DSF 与 Opus 5.5 报告最相似：TF-IDF 相似度 0.572、共享 200 个四词短语，分析方法几乎一致。
一位 Reddit r/LocalLLaMA 用户在本地以 2-bit 量化运行 ds4.1-flash-1017，与 opencode 通过 DeepSeek API 调用的 ds4.1 进行同一提示词对比，测试耗时约 1.5 小时，使用 450k 上下文（开启自动压缩）并以 headless chrome 替代 playwright 完成测试。测得的 KDL 差距较明显：original 到 oQ2e 为 0.4259 nats，original 到 oQ2.5e 为 0.2821，困惑度分别为 3.7315、4.1190 和 4.6333，2-bit 版本的 top-1 agreement 为 78.43%。
GitHub 上的 z440-ollama-benchmarking 项目发布面向本地运行 Ollama 模型的交互式基准测试结果看板。看板提供可排序、可筛选的模型对比表、基于 `ollama ps` 实测内存的 VRAM 可行性指示、生成速度与内存占用图表，以及质量分级热力图和指标术语表。通过主仓库运行 Publish-Website.ps1 -Push 即可重新生成 data.js 并推送最新结果。
Tajima（Shumei University）公开了预部署评估研究的数据、分析脚本和图表代码，研究考察 GPT-4o、Claude Opus 4.5 与 Gemini 2.5 Flash-Lite 在护理临床判断题上的输出一致性何时不再对应正确率。主分析（Study 2）基于日本国家护理考试 2018–2026 年间公开的 90 道题，90 题 × 11 个模型-温度条件 × 30 次 = 29,700 条响应；修订版将受并列项顺序影响的分诊 AUC 修正为 GPT-4o 0.77、Claude 0.50、Gemini 0.68。
作者在相同的 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 用户用修改版 BenchKit 对比 Qwen3.8-Flash-Next-W4A16-FP8PLE（129 GB）与 DeepSeek-V4.1-Flash-1017 2.6 bit 量化版（187 GB + 203 GB Engram），Qwen 以 25/25 满分胜过 DeepSeek 的 23/25。HumanEval 第 22 题上 Qwen 18.8 秒答对，DeepSeek 思考 127.9 秒后陷入循环被终止；第 24 题 DeepSeek 等待 297.7 秒未答出，Qwen 34.5 秒给出正确答案。作者表示将继续使用 Qwen。
基于 Artificial Analysis 数据绘制的 11 个开源权重模型得分与总参数量（log 轴）对比图。Muse Spark Open（816B，42B active）得 39 分，Qwen3.8-Flash-Next（180B，6B active）得 40 分；最高为 MiMo-V2.6-Pro（1T）的 46 分，DeepSeek V4.1 Flash 1017（552B）和 GLM-5.3（753B）均为 45 分。该指数是 AA 自评的单一综合分，不反映速度、长上下文或视觉能力。
作者发布塞尔维亚语大语言模型基准 serbeval，基于 lm-evaluation-harness 0.4.12，官方集 v1.2 共 351 题，其中 61 题经人工核验、214 题由四模型共识确认、76 题由其派生，重点考查翻译无法覆盖的语法现象如格支配、动词体、aorist/imperfect、正字法与西里尔/拉丁字母一致性。30 个模型经 OpenRouter 零样本评测显示 openai_gpt-6-sol 以 99% 居首，gemini-3.8-flash、claude-opus-5.5、gpt-6.1-sol 98%，前沿模型差距很小，剩余错误多为有争议的正字规范；DeepSeek V4 Pro 达 95% 超过 Sonnet 5.5（94%），Kimi K3 92%。
作者在单张 RTX 5090 上对 Qwen3.8-Flash-Next NVFP4 的 basalt、capy-flash、ninfer-ext 三个引擎做了 262,144 token 全上下文对照测试，统一开启 MTP 推测与 int8 KV。结果 basalt 在所有上下文深度最快，prefill 8.1k-9.2k tok/s、greedy decode 176-265 tok/s；decode 排名与 MTP draft 接受率一致（0.74/0.57/0.56），采样解码使各引擎 decode 下降 7-10%。
Shinzuu 发布 free-model-bakeoff 评测，六个免费模型在 126 次评分尝试、14 个对抗性问题上跑生产级 tool-calling 流程。openai/gpt-oss-20b 答对 88%、工具路由正确率 95%，超过比它大六倍的模型（64%/76%）；同一权重换托管方降到 64%、中位延迟 28 秒。关键发现包括每日 20 万 token 的隐性限额（约等于全团队每天 60 个问题）、一句补充 'open' 定义的系统提示词带来最大准确率提升，以及评测中发现并修复的六个 harness bug。
推荐理由：实测给出六个免费模型的准确率与工具路由数据，并指出同权重不同托管方的表现差异可能比模型间差距更大。
在 17 分 29 秒的 AMI 四人会议音频上，MOSS-Transcribe-Diarize 0.9B 在 M5 Pro MacBook（64 GB、mps）上以 fp32 单次完成转写、说话人标注和时间戳，耗时 714 秒，约 0.68x 实时。四个说话人全部识别，0.25 s collar 下说话人混淆率 0.08%，整体 DER 15.4%；317 段中 87 段为重叠语音且均标注了不同说话人。
Sierra 发布 𝜏-Entity 基准，测量语音智能体能否正确采集姓名、电话号码、地址和邮箱等细节，并识别与修复错误。该基准包含 10 种实体类型共 200 个任务，与 𝜏-i18n 一样覆盖六种语言。
作者 /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 模式开关的量化代价，方法可复用。