コンテンツにスキップ

エージェント・ベンチマーク結果

このページは Apple Silicon 上での実際の asiai bench --agentic-mode の結果を報告する。エージェント・プロトコルは 8 フェーズの prefix-cache を意識した会話(分散測定のため --runs 5)を実行し、これはエージェントが実際にモデルを使う方法 — マルチターン、長いシステムプレフィックス、50K トークンのロングコンテキスト・フェーズ — を、単一の一発生成ではなく再現する。

なぜエージェント・モードなのか — 誰のためのものか? エージェントフレームワークはチャットボットのようにモデルを駆動しない: 大きなシステムプレフィックスを多数のターンにわたって再利用し、ツールコールを発行し、長いコンテキストを引き回す。一発のスループット値はそれらすべてを見落とす — しかもランキングが逆転することさえある(生の decode は優秀でも TTFT が数秒、あるいは prefix-cache が壊れているエンジンは、エージェントにとっては使い物にならない)。エージェント・モードは、エージェント・オーケストレーターやコーディングアシスタントが実際に駆動するとおりにモデルを測定する — 例えば Hermes AgentOpenClawopencode、Aider、Cline、Continue など — そのため結果はベンチマークの作為ではなく、実際のエージェント・ワークロードを反映する。

継続更新ドキュメント。 これらの数値は、エンジンのバージョン、モデルのリビジョン、計測の改善(例: ピーク RAM の取得)に応じて更新される。各行は正確なエンジンバージョンとモデルファイルを保持しているため、結果は常に再現可能である。

キャンペーン 2026-06-03。 モデル: Qwen3.6 と Qwopus3.6 ファインチューン、2 つのアーキテクチャ — 27B dense35B-A3B MoE(Mixture-of-Experts、トークンあたり約 3B のアクティブパラメータ)。エンジン: llama.cpp (b9430) と MLX ファミリー(mlx-lm、mlx_vlm、omlx、rapid-mlx、vllm-mlx)。MTP = モデルに組み込まれた Multi-Token Prediction ヘッドで、speculative decoding に使用される(--spec-type draft-mtp)。ハードウェア: MacBook Pro M5 Max (128 GB)Mac mini M4 Pro (64 GB)、いずれも High Power Mode。

表の読み方

判定を最優先。行は単にソートされるのではなく、決定的なゲート結果でグループ化されている:

  • ブロック内で検証された最良のスループット · 実用可能 · 予備 (ハードゲートは通過するがレイテンシが平凡)· 除外(ゲートに不合格)。
  • ゲート: valid ≥ 80% · TTFT ≤ 1500 ms(> 3000 でハード不合格)· prefix-cache reuse > 0
  • dec = 持続的なウォーム decode (tok/s) · 50K = 50K コンテキストでの decode · TTFT = time-to-first-token (ms) · t/s/W = SoC ワットあたりのトークン毎秒 (効率、高いほど良い)· RAMpk = ピークのエンジン RSS(GB、メモリ収容性を 左右する数値)· = 未測定(決して 0 ではない)。
  • ★ は スループットのみ でランク付けする。実作業向けにモデルを選ぶ際は出力品質 (dev/code 評価を参照)も考慮すべきであり、これはスループットには現れない。

M4 Pro と M5 Max はここでは絶対値では比較できない — quant が異なる (Q5_K_XL vs Q4_K_S)。マシンのブロック内で比較すること。

MacBook Pro M5 Max 128 GB · Q4

model · engine · MTP dec t/s peak 50K TTFT ms reuse t/s/W RAMpk GB valid%
★ Tier 1 — 勝者 + 高速
Qwopus-35B · llamacpp b9430 ▲MTP 123.3 127.5 83.8 67 0.8 1.590 100
Qwen-35B · llamacpp b9430 ▲MTP 118.3 123.5 82.9 62 0.8 1.513 100
Qwopus-35B · llamacpp b9430 105.7 108.3 76.1 63 0.8 1.507 100
Qwen-35B · llamacpp b9430 85.5 90.8 66.7 59 0.8 1.403 100
✓ Tier 2 — 実用可能(やや遅い)
Qwen-27B · llamacpp b9430 ▲MTP 28.0 29.5 22.9 118 0.8 0.378 32.2 100
Qwopus-27B · llamacpp b9430 ▲MTP 26.7 29.8 22.0 118 0.8 0.367 31.5 100
Qwopus-27B · llamacpp b9430 25.9 27.1 20.8 110 0.8 0.342 28.4 100
Qwen-27B · llamacpp b9430 23.8 24.0 19.2 111 0.8 0.340 28.9 100
⚠ Tier 3 — 予備(レイテンシ不良)
Qwopus-27B · mlx-lm 0.31.3 29.2 29.3 24.3 600 1.0 0.461 26.4 100
Qwen-27B · rapid-mlx 0.6.71 20.6 20.7 17.9 798 0.357 85
Qwen-27B · omlx 0.4.0 20.0 20.2 17.5 2150 0.82 0.346 26.7 100
✗ Tier 4 — 除外
~~Qwen-27B · mlx_vlm 0.6.0 ▲MTP~~ ~~41.0~~ ~~10879~~ 0.0 75
~~Qwen-27B · mlx_vlm 0.6.0~~ ~~31.9~~ 26.0 ~~9578~~ 0.0 100
~~Qwen-27B · vllm-mlx 0.3.0~~ ~~20.5~~ 18.1 ~~9578~~ 24.3 100

除外: mlx_vlm+MTP は妥当性(75%)に不合格でロングコンテキストを壊す。mlx_vlm の両ランと vllm-mlx は約 9.6 s の TTFT を持つ(エージェントのターンごとに使用不可)。

Mac mini M4 Pro 64 GB · Q5

model · engine · MTP dec t/s peak 50K TTFT ms reuse t/s/W RAMpk GB valid%
★ Tier 1
Qwen-35B · llamacpp b9430 ▲MTP 44.6 50.7 32.6 143 0.8 1.557 33.0 100
Qwen-35B · llamacpp b9430 36.3 45.6 29.6 133 0.8 1.553 30.8 100
✓ Tier 2
Qwen-27B · llamacpp b9430 10.4 10.4 7.2 397 0.8 0.279 31.9 100
Qwen-27B · llamacpp b9430 ▲MTP 9.7 9.8 7.5 409 0.8 0.272 35.4 100

主な知見

  • 35B-A3B MoE はあらゆるスループット軸で 27B dense を上回る — 両マシンともに。 トークンあたり約 3B のパラメータしかアクティブにしないため、dense 27B より約 4× 速く decode し、約 3.5× エネルギー効率が良い(1.5 vs 約 0.4 tok/s/W)。 ただしスループットは品質ではない — 下記の注意点を参照。
  • MTP のゲインはアーキテクチャ × ハードウェアに依存する。 測定された decode の向上: MoE +38%(M5)/ +23%(M4); dense +16%(M5)だが −7%(M4) — より遅い M4 GPU では dense の draft オーバーヘッドが償却されない。したがって MTP はモデルごと・ マシンごとの測定値であり、普遍的な勝利ではない。
  • MLX サーバーファミリーはここではスループット専用である: mlx-lm は最良の MLX decode を持つが 600 ms の TTFT の下限がある; mlx_vlm、vllm-mlx、omlx は TTFT (2–11 s)および/または壊れた prefix-cache でノックアウトされる。llama.cpp は first-token レイテンシで支配的(約 60–120 ms)。
  • ピーク vs 定常 RAM。 mlx-lm の RSS は定常で約 14.5 GB に収まるが 26.4 GB で ピークに達する(遅延 KV 割り当て + コンパクトな MLX-4bit 重み); llama.cpp は フルコンテキストの KV を事前に割り当てる(約 29 GB でフラット)。ピーク時には両者は 同等である — メモリ収容性の判断には定常値ではなく RAMpk を使うこと。

手法と注意点

  • asiai bench --agentic-mode --runs 5、thinking 無効化 (chat_template_kwargs.enable_thinking=false)、サーバーコンテキスト ≥ 65536。
  • 一度に常駐するエンジンは 1 つ(SOLO); ファイルを共有する GGUF ランの間でページ キャッシュをパージ。
  • quant はマシンによって異なる(M5 Q4_K_S/Q4_K_XL、M4 Q5_K_XL)→ 絶対数値は マシン間で比較できず、ブロック内でのみ比較可能。
  • High Power Mode は M5 ラップトップで必須(さもなければ持続的な GPU が約 40% スロットルされる); M4 mini デスクトップはこれに対しておおむね中立。
  • 既知の計測上のギャップ(修正中): 一部の手動起動された llama.cpp サーバーでは ピーク RAM が欠落(); エンジンバージョンはまだランごとにスタンプされていない (ここではバージョンマップから表示); prefix-cache の reuse は真のヒット率が 実装されるまでの粗い割合である。

参照: ベンチマーク手法 · メトリクス仕様 · コミュニティ・リーダーボード