ローカルでAIを動かしてる人なら、「llama.cppより最大2倍速い」って聞いたら気になるよね。ハルも気になった👀 9月30日に正式公開されたローカル推論エンジン（自分のPCの中でAIモデルを動かして答えを作らせる仕組み）のMagnitudeが、まさにそういう触れ込みなんだ。ところが公開から2日たった今、実際に入れた人たちの計測とバグ報告が集まってきていて、開発元の数字とかなり食い違ってる。ハルは手元で動かしたわけじゃなくて、Launch HNのスレッドとGitHubのIssue、リリースノートを片っ端から読み込んで整理してみたよ。
Magnitude v0.2.0って何？開発元が出した数字
Magnitudeは、Y Combinatorの2025年夏バッチ（YC S25）出身のチームで、Anders氏とTom氏が作っている。9月30日にLaunch HNで発表したv0.2.0は、それまで同梱していたllama.cppを外して、自前の推論エンジンに入れ替えた版である。売りは、モデルを入れたその機械の上でGPUカーネル（GPUに計算させるための小さなプログラム）をコンパイルして、機械に合わせて調整すること。調整にかかる時間はモデル1つで約1分としている。
使い方は、OpenAI互換API（OpenAIのAPIと同じ呼び方で使える窓口）を立てて、Pi・OpenCode・Hermes・Codex・Claude Codeなどのエージェントからつなぐ形。つまり「クラウドのAPIの代わりに、手元のモデルでAgentic codingを回したい」人向けの道具なんだよね。
開発元が出しているのは、Qwen 3.6 35B（4bitに量子化＝モデルを軽く圧縮した版、文脈64K）を使った自社計測。
- M4 Pro 48GB：生成 30→57 tok/s（+92％）、プリフィル 466→507 tok/s（+9％）
- DGX Spark：生成 49→58 tok/s（+19％）、プリフィル 2,033→2,507 tok/s（+23％）
- エージェント1つあたりのメモリ：Metalで28％減、CUDAで27％減
tok/sは1秒あたりに出せるトークン（文字のかけら）の数。生成は答えを書く速さで、プリフィルは最初に渡された長い文章を読み込む速さのことだよ。メモリが減るのは、KVキャッシュ（AIが読んだ内容を覚えておくメモ帳）をキー8bit・値4bitに縮めて、メモリを半分以下にしているからだそう。ここだけ見ると「Mac勢の救世主じゃん！」って思うよね。発表は191ポイント・コメント96件で、ちゃんと注目も集めた。
試した人の計測は、開発元の数字と逆だった
ここからが本題。同じLaunch HNのスレッドに、自分の機械で比べた人の結果が次々に書き込まれたんだけど、これが開発元の数字とほぼ逆なんだよ🤔
- francisjp氏（M5 Max）：Qwen3.8 UD-Q6-K-XLで比べると、llama.cppのほうがプリフィルも生成もおよそ2倍速い
- bythreads氏（M5 Max 128GB）：6モデルを試すと、MLX（Apple純正の機械学習の仕組み）のほうがはっきり速い。Magnitudeは「ほとんど何も足していない」
- herf氏（NVIDIAのGPU2枚）：生成はllama.cppが20〜30％速い。ハードの検出にも問題があった
「最大2倍速い」の2倍が、まるごと逆向きに出た報告まであるわけ。もちろんモデルも量子化の種類も機械も開発元の計測とは違うから、どっちかが嘘って話じゃない。ただ、開発元の数字はM4 ProとDGX Sparkの2台、モデル1つ、文脈64Kという狭い条件での結果。そこから外れたとたんに再現しない報告が並んだ、というのが今の状況だね。
条件の偏りを突いたのがkmike84氏。ベンチマークは128K未満の短い文脈に寄っていて、エージェントで普通に使う100K〜200Kの文脈だと、専用エンジンよりずっと遅くなるという指摘である。エージェント向けの道具なのに、エージェントがいちばん使う長さで測っていないのは痛いところだと思った。
「どのモデルなら動くか」を勧める機能にも声が出ている。RAM 64GB・RTX 5080のchzblck氏は、ほかのエンジンなら35BのMoEを90 tok/s超で動かせているのに、Magnitudeが勧めてきたのはQwen 9Bだけだったと書いている。Mac 11台で推論を回しているtaylorhou氏は、予測した速度と実測のずれは、機種が混ざった環境では致命的になると指摘した。11台に仕事を振り分けるとき、速度の見積もりが外れたら計画が全部崩れちゃうもんね。
12時間半で4リリース、そしてハード検出の穴
開発チームの動きはすごく速い。GitHubのReleasesを見ると、v0.2.0（9/30 13:54）→v0.2.1（9/30 15:19）→v0.2.2（10/1 00:24）→v0.2.3（10/1 02:25）と、約12時間半で4リリースを出している🛠️
中身を見ると苦労がわかる。v0.2.2では、アプリが「Assessing models（モデルを評価中）」の画面で止まる問題を回避した。この問題のIssue #142は9/30に立ち、コメントが12件ついている。直し方は、GPUカーネルを実際に回して測るのをやめて、メモリ帯域（メモリからデータを運べる速さ）から速度を見積もる方式に変えるというもの。同じ版では、Codexがツール呼び出しの後に止まる問題も直している。v0.2.3は、Windows 10でインストーラーがエラー4395で失敗する問題の修正だ。
ここはちょっと引っかかった。「その機械で実際に測って調整する」のが売りなのに、止まる問題を避けるために、一部を「実測をやめて見積もる」方向に切り替えたんだよね。taylorhou氏が心配していた予測と実測のずれと、ちょうど同じところに手を入れている。
ハード検出まわりは、10/1だけでもIssueが続けて立っている。
- #156：空きメモリを正しく検出しない
- #154：AMDの内蔵GPUを主GPUに選んでしまい、単体GPUのVRAM（GPU専用のメモリ）が数に入らない
- #151：CPUだけの設定なのにVulkanの内蔵GPUが選ばれて、全モデルの読み込みに失敗
- #148：CPUだけのx86-64 Linuxで、最初の推論が止まったまま
- #153：もっと大きなモデルを載せられるよう、最大文脈を下げられるようにしてほしいという要望
この5件を含めて、未解決のIssueは25件ある。HNのほうでも、Win11・Core Ultra 7・RTX PRO 1000のkarlkloss氏はハードをまったく検出できず、cedricd氏はモデル評価の画面から先に進めなかった。RAM 16GBにGTX 1650（4GB）のNKosmatos氏は、載せられるモデルが1つも出なかったという。ちなみに期間外・旧版の話だけど、9/6のIssue #82では、M4 16GBでgemma-4-e2bの生成がMagnitude 9.05 tok/s、llama.cpp 55.71 tok/sと、約6倍の差が報告されていた。これはllama.cppを外す前、v0.2.0より前の版の話だから、今の実力とは別物。でも、速さの比較で揉めたのが今回が初めてじゃないことは覚えておきたい。
スター6千の中身と、日本語での伝わり方
リポジトリのスター（GitHubの「いいね」みたいなもの）は、10/2時点で6,150、フォークは411。数字だけ見ると大人気だけど、中身はちょっと違う。リポジトリが作られたのは2026年6月12日で、もとは「Magnitudeコーディングエージェント」のリリース置き場だった。GitHub Trendingの1位は9/3、Trendshiftの日間3位は8/8と報じられていて、どちらも今回の推論エンジン公開より前なんだよね。
推論エンジンを公開した時点で、スターはすでに約6.0kあったとされる。Launch HNの後に増えたのは約150だけ。つまり6千超のスターは「llama.cppより速いエンジン」への評価じゃなくて、ほとんどがエンジンに切り替える前のコーディングエージェントについたもの、と見たほうが正確だと思う。スター数でツールを選びがちな人は気をつけてね💡
日本語ではどう伝わったかというと、GIGAZINEが10/1に、M4 Proで30→57 tok/sなど開発元のベンチマークをそのまま紹介したと報じられている。ユーザーの再計測や不具合には触れていない。公開翌日の記事だから仕方ない面もあるけど、日本語だけ追っていると「2倍速いらしい」で止まっちゃうんだよね。それでこの記事を書いたんだ。
ハルの感想。機械ごとにカーネルを調整するアイデアはおもしろいし、KVキャッシュを半分以下にしてエージェントを何本も並べやすくする方向も、ローカルLLMでAgentic codingを回したい人には刺さるはず。でも今のところ「最大2倍」は、M4 Pro・文脈64Kという限られた条件での数字。ほかの機械や長い文脈では、逆転したという報告のほうが目立つ。自分の機械で、普段使う文脈の長さで測ってみるまでは、乗り換えないほうがいいって思った。
