@MikeBradleyAI：关于 @deepseek_ai 0731 V4 Flash 的 TLDR。对于190GB显存或统一内存系统，它妥妥是目前的最优（SOTA）。……

关于 @deepseek_ai 0731 V4 Flash 的 TLDR：对于 190GB VRAM 或统一内存系统，它目前是毫无疑问的 SOTA。在质量分数上与 @UnslothAI 的 Qwen3.5-397B 3bit 版本相当甚至更高，但运行速度快约 3 倍。基准测试如下：https://github.com/Osmantic/MMBT-Messy-Model-Bench-Tests/tree/main/benchmarks… — # Osmantic/MMBT-Messy-Model-Bench-Tests 来源：https://github.com/Osmantic/MMBT-Messy-Model-Bench-Tests # MMBT —— 混乱模型基准测试（Messy Model Bench Tests） 本仓库存储了我实验室中不同硬件与 LLM 测试产生的、杂乱的真实世界基准测试输出。这是我的“混乱”研究，主要用于个人用途，但我将其公开，以便其他人也能使用。 ## 五分钟速览 | 如果你想知道…… | 请阅读 | |—|—| | 首次阅读者：如何衡量这里的一切 | HOW-TO-READ.md —— 仓库结构、状态词汇表、阅读顺序 | | 本仓库中带状态标签的所有声明 | claims.yaml —— 强 / 暂定 / 维持 / 撤回 矩阵 | | 我们没有测量什么（以及欢迎 PR 的地方） | NOT-HERE-YET.md | | 这些证据能支持什么、不能支持什么 | KNOWN-LIMITATIONS.md —— 关于我们实际测量的内容的注意事项 | | 基准测试文件夹从哪里开始 | benchmarks/README.md —— 智能体任务基准测试的落地页 | | “我的任务该用 Coder-Next 还是 27B（还是 27B-no-think）？” | COMPARISON.md —— 头对头决策文档 | | 所有条目的完整单表对比 | SCORECARD.md | | Gemma 4 31B QAT Q4：完整已验证活动 | benchmarks/gemma4-31b-q4/ —— 原生 256K 上下文服务、规范 N=3/N=10、严格工件审计、以及与 Qwen3.6-27B 的对比 | | DeepSeek V4 Flash 0731：完整已验证活动 | benchmarks/deepseek-v4-flash-0731/ —— 部署、规范 N=3、扩展套件、严格工件审计、以及全上下文 75-PR 结果 | | 全部 12 族微基准测试结果（跨两棵树）+ 四个“27B” | MICROBENCH-INDEX.md —— 跨树微基准测试索引 + 量化消歧 | | 跨模型定性快速评分（暂定，非排名） | QUALITATIVE-SPOT-GRADES.md + tooling/QUALITATIVE-GRADING-PROTOCOL.md —— 单人暂定评分 + 评分者独立性规则 | | 仓库大小如何管理 | REPO-SPACE.md —— 存储热点和工件策略 | | 如何对新的本地模型进行基准测试 | tooling/ADDING-A-MODEL.md | | 如何重放过去的特定运行 | tooling/REPRODUCING.md | ## 运行工况（引用前请先阅读） 早期 benchmarks/ 下的大多数智能体任务基准测试使用 Cyankiwi 4-bit AWQ 量化，运行在 2× RTX PRO 6000 Blackwell（功率上限 500 W） 上。DeepSeek V4 Flash 0731 和 Gemma 4 31B 是明确例外：DeepSeek 使用官方 FP4 权重、FP8 KV，以及经过验证的 1,048,576 token 上下文；Gemma 使用 Google 官方 QAT Q4_0 GGUF、Q8 KV、llama.cpp，以及每槽位经过验证的原生 262,144 token 上下文。每个条目的 README 都标注了自己的运行工况。除非某个条目另有说明，否则其他量化方式、VRAM 档次、硬件类别以及 Python 之外的语言均未特征化。参见 COMPARISON.md 中“此基准测试未特征化什么”部分 了解模型-基准测试有效性边界，参见 ROADMAP.md 了解已排队填补这些空白的计划。 hardware-tests/ 下的硬件特征化研究有自己的运行工况范围。引用硬件相关声明前，请先阅读 hardware-tests/README.md。特别是 hardware-tests/qwen3.6-q8-fleet-2026-05-17/ 在 llama.cpp 下对 Q8_0 GGUF 密集与 MoE 工作负载的四个硬件类别进行排名，并附有 Tower2 vLLM-FP8 附录行，用于处理 llama.cpp/CUDA 路径会崩溃的 MoE 模型。 ## 布局 text benchmarks/ README.md 智能体任务基准测试落地页和导航图 gemma4-31b-q4/ 完整的 Gemma 活动，N=3/N=10，严格审计，对比 deepseek-v4-flash-0731/ 跨套件 DeepSeek 活动，严格审计，以及部署证据 dreamserver-75-pr-audit/ GPT-5.5/ 云端，完整审计 Opus-4.7/ 云端，完整审计 Qwen3.6-27B-AWQ/ 本地 30B 级，结构完整 + 内容部分完成 Qwen3-Coder-Next-AWQ/ 本地 MoE 80B/3B，无可交付物（故障模式条目） findings-2026-04-27-local-models.md 跨领域综述 dreamserver-1-pr-audit/ Qwen3-Coder-Next-AWQ/ 本地，单 PR 可交付物（裁决正确，但方差主导 —— 见条目 README） Qwen3.6-27B-AWQ/ 本地，部分可交付物（分析出色，未提交 verdict.md） Qwen3.6-35B-A3B-AWQ/ 本地，基础性失败（未产生任何工件） wallstreet-intern-test/ GPT-5.5/ 云端，完整备忘录仓库 + 顾问委员会演示文稿 Opus-4.7/ 云端，完整备忘录仓库 Qwen3.6-27B-AWQ/ 本地，完整备忘录仓库（GTLB 买入，3 次运行中 1 次交付） Qwen3-Coder-Next-AWQ/ 本地，完整备忘录仓库（DOCU 买入，3 次运行中 1 次交付 —— README 中有裁决可靠性注意事项） Qwen3.6-35B-A3B-AWQ/ 本地，无可用的可交付物（3 次运行中 0 次交付，作为故障模式条目保留） hardware-tests/ README.md 硬件测试落地页：覆盖矩阵、已定论 vs 保留问题 vllm-power-sweep-2026-04-29/ 硬件特征化：vLLM 吞吐量 vs GPU 功率上限，28 单元扫描，含原始 CSV + 审计说明 tower2-dual-qwen27-600w-2026-07-29/ 30 分钟双 GPU 600 W 热饱和运行 tower2-dual-qwen27-no-gap-2026-07-29/ 相邻显卡 600/400 W 瞬态与稳态热运行 qwen3.6-q8-fleet-2026-05-17/ 跨平台密集 + MoE Q8 硬件对比 local-ai-hardware-valuation-2026-05-17/ 可重新计算的买家估值工作表 ## 基准测试 | 基准测试 | 提示词形状 | 模型条目 | |—|—|—| | gemma4-31b-q4 | 跨套件发布：完整 12 族 N=3 和 N=10、单 PR N=3、投资研究、董事会演示、以及冻结的 75-PR N=3。 | Gemma-4-31B-it-QAT-Q4_0；包含不可变原始评分、狭义的修正覆盖层、严格实质性审计、以及与 Qwen3.6-27B 的对比。 | | deepseek-v4-flash-0731 | 跨套件发布：完整 12 族 N=3、单 PR N=3、投资研究、董事会演示、以及三个有效的全上下文冻结 75-PR 结果。 | DeepSeek-V4-Flash-0731；包含修正后的评分者覆盖层和紧凑的审计证据。 | | dreamserver-75-pr-audit | 审计实时仓库中的 75 个开放 PR，并生成可追溯的维护者分诊仓库。 | GPT-5.5、Opus-4.7、Qwen3.6-27B-AWQ、Qwen3-Coder-Next-AWQ（故障模式条目） | | dreamserver-1-pr-audit | 相同的任务规范，缩减到单个 PR。作为升级阶梯（1 → 2 → 4 → 8 → 16 → 32）的底座构建，用于找出每个模型的复杂度上限。 | Qwen3-Coder-Next-AWQ、Qwen3.6-27B-AWQ、Qwen3.6-35B-A3B-AWQ（基础性失败） | | wallstreet-intern-test | 构建一个可追溯的投资备忘录仓库，包含原始来源、提取的数据、三表财务模型、估值和建议。 | GPT-5.5、Opus-4.7、Qwen3.6-27B-AWQ、Qwen3-Coder-Next-AWQ、Qwen3.6-35B-A3B-AWQ（故障模式条目） | | microbench-2026-04-28 | 12 个较小范围的任务族（5-30 分钟可交付物），分 3 个阶段 —— 编码（阶段 1）、结构化业务任务（阶段 2）、无界业务/写作（阶段 3）。旨在揭示本地 30B 级量化之间特定任务类别上的差异。每单元 N=3。三个信号最强的任务族已作为完整逐模型条目发布：对抗性幻觉、市场研究、文档综合。 | Qwen3.6-27B-AWQ、Qwen3-Coder-Next-AWQ | | microbench-phase-b-2026-05-02 | 将 microbench-2026-04-28 中信号最强的四个单元从 N=3 提升到 N=10，以用正确的 Wilson 置信区间约束头条失败率；并添加 27B-no-think 作为横跨完整 12 族网格的第三臂（总计约 240 次运行）。确定了 p3_doc 27B 词数裁剪循环是稳定的约 40% 失败形态，并将 Coder-Next 的 p3_market 0/3 STRUCTURAL_FAIL 约束为 N=10 时的 0/10（Wilson 95% [0%, 27.8%]）。 | Qwen3.6-27B-AWQ（thinking）、Qwen3.6-27B-AWQ（no-think）、Qwen3-Coder-Next-AWQ | 基准测试落地页和逐文件夹导航图，请从 benchmarks/README.md 开始。 ## 硬件测试 hardware-tests/ 存放硬件特征化运行 —— 实验室硬件上的功耗、吞吐量和热扫描，与智能体任务基准测试分开。请从 hardware-tests/README.md 开始：它明确说明了密集 vs MoE 覆盖范围、后端异常以及“已定论 vs 保留”边界。 | 测试 | 形态 | 测量内容 | |—|—|—| | tower2-dual-qwen27-no-gap-2026-07-29 | 相邻的 RTX PRO 6000 Blackwell 显卡，无空槽位间隙；每张 GPU 上运行密集 Qwen3.6-27B AWQ-INT4；600/400 W、均衡 500/500 W、以及尝试的均衡 600/600 W 单元。 | 500/500 W 保持 100% 利用率，无明显降频。600/600 W 单元在约 5 分钟后达到 96°C 截止温度：GPU1 平均 589.7 W，风扇 99.4%，并记录了软件加硬件热降速。 | | tower2-dual-qwen27-600w-2026-07-29 | 两个独立的 Qwen3.6-27B AWQ-INT4 vLLM 引擎，每个 RTX PRO 6000 Blackwell 一个，在 2 分钟预热后保持 600 W 和 100% 利用率，持续测量 30 分钟。 | 双卡最坏情况热包络：每 GPU 平均 599.99 W，平均 85.1°C/89.0°C，最高 89°C/92°C，无热降速。还记录了主机侧的限制：CPU Tctl/CCD 峰值达 95.6°C/96.6°C。 | | vllm-power-sweep-2026-04-29 | 7 个 GPU 功率上限 × 5 分钟持续 vLLM 负载 × 2 种并发度（N=1、N=32）× 2 个 AWQ-INT4 模型（密集 Qwen3.6-27B、MoE Coder-Next），共 28 个单元，运行在 RTX PRO 6000 Blackwell 上。 | 吞吐量-功率上限曲线、无界上限时的原生功耗、以及各上限的热包络。验证了 500 W 生产上限（在所有场景中均在最优值的 3.3% 以内），并显示 Coder-Next 在每个上限下比密集 27B 快约 1.8 倍（批处理）/ 2.3 倍（单流）。发现文档带有“审计说明”部分，标记了两个每上限“赢家”标记，在重新阅读原始 CSV 后不成立（vLLM 容器预热瞬态和单窗口热时钟下降扭曲了各上限赢家，但不改变平台形态头条结论）。 | | qwen3.6-q8-fleet-2026-05-17 | 相同的 Qwen3.6 Q8 GGUF 模型字节，在固定 llama.cpp SHA 下，跨越 Blackwell 6000 Tower、DGX Spark、EVO X2 / Strix Halo 和 M5 Max MacBook Pro，并在 Tower2 上附加 vLLM 附录行。 | 跨平台单用户 prefill/decode/TTFT、后端故障模式、热现场记录、以及本地 AI 硬件讨论中的成本-吞吐量注意事项。多用户服务结论明确保留。 | | best-stack-followup-2026-05-17 | 后续捆绑：M5 Max 上的 MLX，以及 Strix Halo 上 ROCm 7 的 Dream-Server。 | 各平台最佳服务栈说明（MLX 在 M5 上优于 Metal；ROCm 7 在 Strix 上可用；无 prefill 提升）。 | | qwen3.5-397b-vs-step3.7-flash-2026-05-29 | 一个 12 族智能体微基准测试（模型行为），因需要双 Blackwell 硬件而归档于此。 397B-A17B（Q3 GGUF）no-think/think N=10，外加 Step-3.7-Flash、MiniMax-M2.7、以及 27B/Coder-Q4 参考。 | Thinking 净为负（397B 82→72）；小 N 误读单元；聚合平局约 7–8/12，跨越约 15 倍规模；MiniMax 临时服务陷阱。次要：双 GPU 功耗遥测。参见 MICROBENCH-INDEX.md。 | | local-ai-hardware-valuation-2026-05-17 | 由可编辑价格/规格输入以及 Qwen3.6 27B Q8 硬件测量得出的派生估值工作表。 | 可重新计算的买家指标：$/可用 AI GB、$/GB/s、$/实测 decode tok/s、$/实测 prefill tok/s、容量-带宽得分、以及粗略的 5 年能源/TCO 线。当市场价格变化且你希望同一心智模型在刷新后仍然有效时，请使用此表。 | | step3.7-flash-nvfp4-dual-blackwell-2026-05-28 | 设置/配置说明：在 2× RTX PRO 6000 Blackwell（sm_120，无 NVLink）、TP=2、原生 NVFP4 + FP8 KV 下，用 vLLM 服务 stepfun-ai/Step-3.7-Flash-NVFP4（201B MoE VLM，day-one）。 | 可用的启动命令以及为此所需的四个非明显标志，附完整诊断痕迹：--disable-custom-all-reduce（自定义 all-reduce 在没有 P2P/NVLink 时死锁）、--moe-backend cutlass（唯一支持该模型 SWIGLUSTEP 激活的原生 FP4 MoE 内核）、无专家并行、原生 max-model-len。上游不存在官方的 2×6000 配方。是 Step-3.7 微基准测试条目的配套材料。 | | qwen3.6-27b-fp8-microbench-2026-05-31 | Qwen3.6-27B 密集模型在 2× RTX PRO 6000 Blackwell 上以 vLLM FP8 形式服务（每 GPU 一个引擎），在完整 MMBT 12 族智能体微基准测试中以 N=5 运行，分别使用 --thinking on 和 --thinking off。这是对 397B 条目中因 Q8/FP8 服务失败而不得不排除的 27B 运行的干净的 FP8 重做。 | FP8 服务稳定（113/119 单元为干净的 done_signal；6 个错误是模型循环到上下文溢出，而非量化不稳定）。Thinking 在此处对 27B 净为负：no-think 35/60 vs think 29/60 —— 它破坏了封闭词汇表 p2_triage（0/5 vs 5/5）和 p3_writing（1/5 vs 5/5），仅在 p3_business 的篇幅纪律上胜出。人工评分维度尚未填写。 | ## 一览 两个综合文档位于本 README 和逐条目细节之间： - benchmarks/gemma4-31b-q4/GEMMA4_31B_Q4_VERIFIED_RESULTS.md —— 完整的 Gemma 结果、原生 256K 部署、N=3/N=10 质量、严格工件审计、以及与 Qwen3.6-27B 的直接对比。 - benchmarks/deepseek-v4-flash-0731/DEEPSEEK_V4_FLASH_0731_VERIFIED_RESULTS.md —— 完整已验证的 DeepSeek 结果，包括修正后与原始评分、严格工件审计、生产验证和注意事项。 - COMPARISON.md —— 三个本地模型臂（Coder-Next vs 27B-thinking vs 27B-no-think）的头对头决策文档。按任务类别组织，附单元级证据。如果你的问题是“我该用哪个？”请阅读此文档。 - SCORECARD.md —— 所有条目的单表总结（规范符合性、事实准确性、捏造声明数量、已运行测试、墙钟时间、成本上限、失败模式、“何时用哪个”指南）。如果你的问题是“全貌是什么？”请阅读此文档。 两者都链接回它们引用的逐条目工件。 ## 重现运行 tooling/ 文件夹是可重现包 —— 智能体框架、沙箱 Dockerfile、vLLM 启动命令、全部 12 个微基准测试任务提示词、输入起始文件、ground truth、评分脚本和批处理运行脚本。有了这些再加上一台支持 CUDA 的 Linux 机器和一个 HuggingFace 模型，外部读者可以重跑这里的任何本地模型条目。 - 重放已发布的运行：参见 tooling/REPRODUCING.md —— 基于收据的逐步演练。 - 对新的本地模型进行基准测试：参见 tooling/ADDING-A-MODEL.md —— 端到端指南，附四条命令说明。