MacBook Air M5でlocal coding LLM 21個比較、LocalLLaMAが欲しかった実測値

r/LocalLLaMAに投稿されたMacBook Air M5 benchmarkは、このcommunityが好む「実際のconsumer hardwareで動かした」タイプの検証だ。投稿者は“bro trust me”式のcoding model recommendationを減らしたいとして、21個のlocal LLMを同じ条件でHumanEval+ pass@1、token speed、memory footprintで比較した。Medium writeup、GitHub repo、Hugging Face datasetも添えられている。

最大の数字はQwen 3.6 35B-A3Bである。投稿の表では、このMoE modelがHumanEval+ 89.6%、16.9 tok/s、20.1 GBで首位だった。投稿者は、total parameterがqualityに、active parameterがspeedに効くという意味で、このmodelがよいバランスを取っていると見ている。Qwen 2.5 Coder 32Bは87.2%と近いが2.5 tok/sと遅く、Qwen 2.5 Coder 7Bは84.2%、11.3 tok/s、4.5 GBでbest bang-for-RAMに近い結果だった。

コメント欄で議論になったのはGemma 4の低いscoreだ。Gemma 4 31Bは31.1%、Gemma 4 E4Bは14.6%、Gemma 4 26B-A4B MoEは12.2%にとどまった。投稿者はQ4_K_M quantizationがGemma 4 architectureに不利に働いている可能性や、HumanEval+のtask distributionが強みを反映していない可能性を挙げた。コメントでは、Gemma 4のtool-calling問題、tool call直前でのpremature stop、Googleやllama.cpp側のfixがどこまで効いているかという実務的な推測も出ていた。

この投稿の価値はleaderboardそのものではなく、constraint-awareな見方にある。MacBook Airのようなdeviceでは、speedとRAMを一緒に見なければdaily coding assistantとして使えるか判断できない。Phi 4 Mini 3.8Bが70.7%、19.6 tok/s、2.5 GBでsleeper pickのように見えた点も同じ文脈だ。

元の議論はReddit discussion、詳細は投稿内のMediumとGitHub repoで読める。LocalLLaMAが反応した理由ははっきりしている。local LLM選びは、どのmodelが一番賢いかだけでなく、自分のhardwareで十分に速く、十分に正確かという問題になっている。