128GB革命 #6 ベンチ職人たち——65.8 tok/sの122Bをコメント欄から掘り出した男
128GB革命 #6 ベンチ職人たち——65.8 tok/sの122Bをコメント欄から掘り出した男
大工さんのさしがねも腕時計の分解も、いちばん面白いのは設計図じゃなくて「実測記録」なんだよね。うちの近所に三十年やってる時計屋さんがいて、店には「このモデルはオーバーホールから何年で油が切れる」という手書きの記録ノートが積んである。カタログには載っていない、でも唯一役に立つ数字。ローカルLLMの世界にも同じノートがあって、それがRedditのコメント欄なんだよね。今日はその中から、数字だけを静かに投下していく「ベンチ職人」たちを紹介する。
前回までの振り返りと、今日の枠組み
前回はYouTubeの実測映像の話をした。映像は「過程」を見せるけど、今日取り上げるのは「記録」の人たちだ。映像がアイスの容器を開ける瞬間だとすれば、彼らの投稿は「同じ容器・同じスプーン・同じ気温で測った比較表」を店の片隅に貼り続ける作業に近い。主戦場はr/LocalLLaMAで、代表格がu/affenhodenとu/ConformalFuelTankの二人。共通しているのは、スペックの羅列じゃなくて測定条件ごと数字を置くことだよね。ベンチマークって、条件が書いてなければただの自慢なんだよね。
u/affenhoden:v1からv2へ、投稿自体が進化する男
まずu/affenhoden。自称「老いたIT男」で、Raspberry PiにHailo10Hを組み合わせた辺境からスタートしてM5 Maxにたどり着いた人だ。面白いのは、Claude Codeを「ITチーム」として運用していて、そのメモリやプラグインやサブエージェントの体制ごと新Macへ引っ越させてベンチを取っている点。ベンチ投稿なのに環境構築の記録まで含まれていて、まるで引っ越し業者の作業日報なんだよね。しかも投稿はv1で終わらない。v1へのコメントで「測り方が違う」「PP速度が見たい」という指摘を受けると、v2でllama-benchの標準的な測定に合わせて、PP速度を追加して、MoEモデル(35B-A3Bクラス)まで項目を増やして再投稿した。スコアは119。フィードバックを次の測定に吸収するこの姿勢、時計屋さんのノートに「お客さんの指摘で測り方を直した」と追記していくのにそっくりなんだよね。

u/ConformalFuelTank:コメント欄の金脈
そして今日の主役級、u/ConformalFuelTank。この人の実測はスレの本文じゃなくて、cryingnekoのスレ(あの2016票のスレだよね)のコメント欄に投下されている。M4 Max 128GBでllama-benchを回した記録がそれで、Qwen3.5-122B-A10Bを4bit量子化で載せて、4106トークンのプロンプトでdecode 65.85 tok/s、ピークメモリ71.9GB。さらにコンテキストを伸ばしたときの数字も残していて、16kで60.6 tok/s(73.8GB)、32kで54.9 tok/s(76.4GB)。おまけにQwen3-Coder-Nextを8bitで87.1GB載せた記録まである。研究データベース側はこのマシンを「M5同等帯域」と注釈している。M4 MaxとM5 Maxはどちらも約614 GB/sの帯域で、u/purealgoの実測でもdecode速度はM4→M5で+9〜16%にとどまる。つまり65.8という数字はM5 Maxでもほぼそのまま成立する水準なんだよね。
その意味を噛み砕こう。122BパラメータのMoEを、4bit量子化で71.9GBに収め、それを毎秒65.8トークンで読み進める。81GBのDeepSeek V4 Flashが34.1 tok/sだったkamo78の実測と並べると、「同じ128GB機でも何を載せるかで倍以上違う」ことが数字で確定する。さらに100kコンテキストという極限では、M3 Max 128GBでQwen3.5-122Bを5bitで回すと30 tok/sという記録が別の職人(u/Dumperandumper)から出ている。量子化・コンテキスト・世代の3軸が揃うと、同じ122Bでも速度が倍以上変わる。コメント欄に散らばった数字を条件付きで集めるだけで、一本の性能曲線が立ち上がるんだよね。

llama-benchの測定条件を読む
ここで道具の話。彼らが共通して使っているllama-benchは、llama.cppに同梱された公式ベンチツールで、プロンプト処理(PP)とテキスト生成(TG)を決まった手順で測る。u/affenhodenのv2が「llama-bench標準化」と評されるのは、ツールのデフォルト条件に合わせたからで、条件が合っていれば誰の数字でも表に並べられる。これが大事なんだよね。u/purealgoのM4→M5比較も「同一プロンプト512トークン上限、複数回平均」と条件を明記していて、GLM-4.7-FlashでPP+17.3%、Qwen3-Coder-NextでPP+45.5%という向上率を出している。逆に言うと、条件の書いてないベンチ数字は時計屋さんで言えば「たぶん油が切れた」レベルの証言で、比較対象にならない。u/ConformalFuelTankの記録が金脈と呼ばれるのは、トークン数・量子化・メモリ・コンテキスト長という条件が全部そろっていたからなんだよね。

MoEが速い理由を122Bで確かめる
65.8 tok/sという数字の物理をもう少し詰めよう。Qwen3.5-122B-A10Bの「A10B」は、122Bの全パラメータのうち1トークンあたり約10Bしか活性化しないという意味だ。decodeの速度はだいたい「帯域÷実効読み出しサイズ」で決まるから、4bitの122B(ファイルは約71.9GB)でも、1トークンあたりの実読み出しはずっと小さい。だから帯域614 GB/sクラスのマシンで60 tok/s超が出る。一方、31B全部を毎回読むDenseのGemma4は23 tok/sどまりだった。同じ122Bでも5bitで100kコンテキストのM3 Max記録は30 tok/s(u/Dumperandumper)で、量子化とコンテキストで速度が変わる様子も見える。
数字を並べて体感に翻訳してみる。65.8 tok/sは1時間で約23万7000トークン。日本語に換算すると毎秒100文字以上で、本一冊分の生成が40分しないで終わる計算だ。エージェントがコードを書くときも、この速度だと「返事を待っている」感覚がほぼ消える。逆にDenseの11 tok/s(Hermes3 70Bの実測)だと、返事の一行目が出るまでコーヒーを淹れたくなる。速度の差は快適さの差で、快適さの差は使い方の差になる。ここ、MoEの「詳しい仕組み」を図で見たい人には、専門チャンネルの可視化動画が分かりやすいんだよね。エキスパートにルーティングされる様子がアニメーションで追えるから、「なぜA10Bで速いのか」の直感がつかめる。

表示速度の罠——arthwareの警告
ただし、コメント欄の金脈には警告も混ざっている。u/arthwareは「MLXの表示で57 tok/s出ていても、prefill込みの実効速度は8.5kコンテキストで3 tok/sだった。時間の94%をprefillが食う」と報告している。長いコードや長文を食わせるとき、体感速度はカウンタの数字じゃなくて「最初の一字が出るまでの待ち時間込み」で決まるんだよね。時計屋さんに例えると、文字盤の針が正確でも、竜頭を巻くまで3分かかる時計は実用じゃない、という話。だからベンチを読むときはdecode(TG)とprefill(PP)を必ずペアで見る。u/affenhodenのv2がPP列を追加したのも、u/purealgoがPPの向上率を強調したのも、同じ理由に行き着く。122Bの65.8 tok/sが輝くのは4kコンテキストの条件で、32kでは54.9に落ちる。この下り勾配まで含めて「実測」なんだよね。
実践:読者が今日できること
読者が今日できることは3つ。
- llama-benchで自分の環境を測るときは、モデル名・量子化・コンテキスト長・PP/TG両方の数字をセットで記録する
- Redditのベンチを読むときは、本文よりコメント欄を漁る。u/ConformalFuelTankのように本文欄に金脈を埋める人がいる
- 数字を引用するときは条件ごと引用する。「65.8 tok/s」だけの引用は、容器の写真だけ載せて中身を報告しないのと同じ
そしてu/affenhodenとu/ConformalFuelTankは、研究データベース上で「実在✓・ベンチ職人」として検証済みのフォロー推奨枠に入っている。数字を条件付きで残す人を追いかけるのが、この世界での一番の近道だよね。
コメント欄という観測装置
最後に視点を一つ。メーカーの公式ベンチは「最良の条件」を出しがちだけど、Redditの実測は「その人の作業机」から出てくる。u/affenhodenのClaude Codeごと引っ越すベンチも、u/ConformalFuelTankのコメント欄投下も、教科書的な実験室じゃなくて生活のある場所の数字だ。だから面白い。カタログに載らない油切れの年数を三十年書き溜めた時計屋さんのノートみたいに、コメント欄の積み重ねだけが、128GBという特殊な器材の本当の性能表になりつつある。スレの本文は看板、コメント欄が厨房。職人は看板に飾られるより、厨房で数字を刻んでるほうが性に合うんだよね。
次回は「数字は嘘をつかない」——MoEとDenseで帯域使用率が15%と94%に分かれる実測DBを、kamo78のテレメトリと一緒に完全解説する。