RTX 3090 本地基准测试 - Qwen3.6 27b 对比 Ornith

大家好。我一直很苦恼，很难了解每个新模型（或微调模型）到底有多好，而且我对我们经常采用的那种一次性的‘画一只骑自行车的鹈鹕’风格的测试并不满意。能够在我的RTX 3090上本地运行的新模型或模型变体，几乎从未得到除制造商之外任何人的适当基准测试覆盖。最近，我想看看Ornith 35b与Qwen3.6 27b相比如何。所以我一直在摆弄inspect-ai和他们inspect-evals包中提供的一系列标准基准测试。我希望能够在一夜之间对新模型运行一套完整的基准测试，并在早上对它们的比较有一个大致的了解。我还没有达到那个目标，但我想分享一下到目前为止我已经运行的基准测试，比较Qwen3.6 27b (Q4_K_M)、Gemma4 26B A4B QAT (Q4_0) 和 Ornith1.0 35B MoE (Q4_K_M)。我目前仍然在LM Studio上运行，所以我在lmstudio-community提供的模型上运行了以下基准测试，除了Ornith，它来自deepreinforce-ai账户。TLDR：我在样本数量有限（100个）和严格限制的基准测试上对三者进行了测试。我预计Ornith在编码任务上几乎和Qwen3.6 27b一样好，但并非如此。作为微调模型，我预计它在通用知识和接地性方面会更差。但最终结果并不那么清晰。在略低于一半的情况下，它和Qwen 27b一样好或更好，其余时间则更差。不过它声称在代理任务上表现最好，但我还没有成功运行大多数代理基准测试。以下是每个基准测试的具体细节和一些说明。以及我对本地运行这些基准测试有多痛苦的想法。 通用知识与推理 Qwen在4/6的基准测试中取得最佳（或并列最佳）分数。Ornith在3/6的基准测试中取得最佳（或并列最佳）分数。MMLU基准测试对Gemma有些不利。它在很多情况下超时，但我尚未确定原因。可能是它陷入了无限循环，也可能是与我配置任务的方式有关。对Gemma在这些情况下的得分要持保留态度。 # 静态知识与推理 success, logs = eval_set( tasks=[ gsm8k(), ifeval(), arc_easy(), arc_challenge(), mmlu_0_shot(cot=True), mmlu_5_shot(cot=True) ], log_dir="logs-know", **default_config, max_tokens=20000, ) 基准测试 | Gemma4 26b | Qwen3.6 27b | Ornith1.0 35b --- | --- | --- | --- gsm8k | 0.93 | 0.96 | 0.9 ifeval | 0.93 | 0.95 | 0.91 arc_easy | 1.0 | 1.0 | 0.98 arc_challenge | 0.97 | 0.97 | 0.98 mmlu_0_shot | 0.54 | 0.88 | 0.91 mmlu_5_shot | 0.5 | 0.88 | 0.88 接地性与召回 Ornith在这些方面领先，但Needle in a haystack (NIAH)必须限制在最大上下文100000，因为Qwen的提示处理时间使得在更高上下文下进行公平测试耗时过长。我需要找到更适合本地测试的基准测试，或者干脆重新运行，花更多时间。 # 接地性与召回 success, logs = eval_set( tasks=[ drop(), niah(max_context=100000), ], log_dir="logs-ground", **default_config, max_tokens=40000, ) 基准测试 | Gemma4 26b | Qwen3.6 27b | Ornith1.0 35b drop | 0.932 | 0.947 | 0.952 niah | 10.0 | 10.0 | 10.0 代码生成与数据科学 这是我期望Ornith大放异彩的地方。它在四个任务中的两个与Qwen持平，但Qwen在每个案例中都取得了最佳分数。scicode的得分尤其令人失望。与Gemma相比的一个积极之处是，为了让scicode在Gemma上工作，我必须施加非常严格的限制，因为它在大多数样本上无限循环。Ornith没有这个问题。无限循环行为较少。 # 代码生成与数据科学 success, logs = eval_set( tasks=[ ds1000(), class_eval(), scicode(), ifevalcode(samples_per_language=tasks_limit_per_eval // 10), # 10种语言 ], log_dir="logs-code", **default_config, ) 基准测试 | Gemma4 26b | Qwen3.6 27b | Ornith1.0 35b DS-1000 | 0.34 | 0.66 | 0.48 class_eval | 0.97 | 0.97 | 0.97 scicode | 4.615 | 10.769 | 1.538 ifevalcode | 0.03 | 0.00 | 0.03 说明 说实话，运行这些基准测试有些噩梦。尤其是Gemma，容易无限循环。我不得不重新配置并重新运行基准测试，施加重重限制以防止它永远运行下去。此外，某些测试的提示处理时间特别糟糕。更改其中一些配置意味着必须重新运行所有基准测试，才能与其他模型进行公平比较。我的目标是能够在一夜之间运行全套测试，这样我就能在早上了解它的能力。实际上，ifevalcode 仅针对 Qwen3.6 27b 的 100 个样本就花了 18 个小时。以下是我配置的一些内容：每个基准测试最多 100 个样本。最大 token 限制以防止循环。这确实需要为每个基准测试设置不同的限制，因为有些测试似乎确实需要更大的推理块。最初我设置了超时，但这在我同时运行多个样本时把事情搞砸了。一个繁重的任务会耗尽所有资源，而另一个任务则会在没有尝试的情况下超时。一次一个任务，最多一个连接，一次一个沙箱（Docker 实例）。我将尝试切换这些设置，并对我的限制更加具体。我将添加样本打乱（在模型之间共享种子），并减少一些较棘手测试的样本数量。inspect-ai 中的 eval_sets 允许您继续已暂停或已取消的测试。但实际上，这通常意味着当我需要更改配置以使基准测试正常工作时，我必须重新运行整个集合。一旦我有更可靠的基准测试设置，我可能会再发布一些。希望你们中有人觉得这有用。