【爆速】ローカルLLM環境の常識が変わる!エージェント特化型の推論エンジン「Magnitude」が登場
Launch HN: Magnitude (YC S25) – Self-optimizing inference engine for agents
Launch HN: Magnitude (YC S25) – Self-optimizing inference engine for agents
HNの皆さん、こんにちは。AndersとTomです。私たちは、手元のハードウェアに合わせて自動最適化を行い、限界まで高速な推論を実現するエージェント向けエンジン「Magnitude」を開発しました。Mac、Linux、Windowsを問わず、llama.cppと比較して最大2倍の速度を叩き出します。私たちは以前、4,000以上のGitHubスターと10万ダウンロードを記録したオープンソースのブラウザエージェントを開発していました。その際、ローカルLLMを快適に動かしたいと考えていましたが、既存の推論エンジンでは用途に合うものがなかったのです。現在のエンジンには、いずれもトレードオフが存在します。データセンター向けのバッチ推論重視(vLLM, SGLang)、汎用性重視でハードウェア最適化が不十分(llama.cpp, Ollama)、あるいは特定のハードウェアに特化しすぎてエンジンとしての完成度が低いもの。また、エージェント特有の「長時間のセッション」「複数同時実行」「PCでの他の作業の共存」といったニーズに対応しているものもありませんでした。Magnitudeは以下の強みでこの問題を解決します:・デバイス内コンパイルとチューニング:モデル実行前に実機でカーネルをチューニングし、ハードウェア特化型と同等の性能を実現。・主要アーキテクチャへの集中:人気のオープンウェイトモデルに対して効率的なカーネルを実装。・動的メモリ割り当て:モデルウェイトに必要な分だけを確保し、使用状況に応じてメモリを動的に解放。・ハイブリッドPaged Attention:SGLangの知見を活かし、セッション間でプレフィックスキャッシュを共有しつつメモリ配置を最適化。Rustで開発されたMagnitudeはApache 2.0ライセンスで完全オープンソースです。ベンチマーク結果(Qwen 3.6 35B A3B 4bit / 64k context)では、Mac M4 Pro環境でデコード速度が92%向上、メモリ消費量も27%削減するなど、圧倒的なパフォーマンスを示しました。デスクトップアプリとして配布しており、既存のエージェントツールと簡単に接続可能です。詳細なデモはこちらをご覧ください:https://www.youtube.com/watch?v=0qE8BWEZu7o 今後は、メモリから溢れる巨大モデルをロードするエキスパートストリーミングや、独自カーネルコンパイラの実装、マルチデバイス最適化を予定しています。ぜひ試してみて、フィードバックを頂けると嬉しいです。一日中回答していますので、コメント欄でお待ちしています!
画像以外にベンチマークや手法のソースはある?llama.cppは設定次第でパフォーマンスがかなり変動するからね。あと、MLXとの比較ベンチマークも見てみたい。
良いアイデアだと思う。ただ、llama.cppの速度を超えるのはそんなに高いハードルじゃないよね :) ベンチマークとしては良い基準だとは思うけど、少なくともMac上だとds4、omlx、mtplxなど、もっと速かったりメモリ効率が良かったりする選択肢が常にあった。ローカルLLMを本気で使うなら、最適化されたエンジンを使わない理由がほとんどない気がする。
エンジンでよくある失敗パターンは3つかな:
ローカルの推論用マシンで、llama.cppのチェックアウト先に常にCodexスレッドを開いてるんだ。定期的に「今ペンディング中のllama.cppのPRをチェックして、最新のMTPやDflash、その他の予測やアテンションの最適化について調査して、モデルの量子化やファインチューニングの最新動向を調べて、RedditのlocalLlamaスレッドも見て、今の最前線を総ざらいして」と指示してるよ。
そうすると、最新のllama.cppをリビルドして、テストすべき関連PRを拾い上げて、ベンチマークを実行して、アップグレードを確定させて、どのモデルやバリアント、あるいは別のファインチューニングを使うべきかを検証してくれる。
たまに自分で最適化を施してコミットすることもあるんだけど、それは結局プルリクやマージされたコードで上書きされて、モデル自身の最適化の方向性が合ってたことが証明されるってわけ。
ローンチおめでとう!かなり印象的なプロダクトだしツールだね!
質問なんだけど、個人的な(ごく限られた!)理解だと、「推論エンジンの慣性」の一因って、新しいオープンウェイトモデルが出るたびに、そのモデル専用、あるいはアーキテクチャ専用のコードが必要になることじゃないかと思ってるんだけどどうかな。
もしそうだとすれば、MagnitudeをvLLMやllama.cppの代替として、(経済的に、あるいはパレート効率的に)可能な限り多くのモデルでドロップイン利用できるようにする予定?それとも、特定の少数のモデルやモデルクラスのサポートを極める方向に注力するつもり?
NVIDIAのGPUを2枚(16GB+16GB)積んでるんだけど、それぞれを2回検知して「GPUが4枚ある」って言われる。その上、ほとんどのモデルがサイズオーバー(8GB以上だと全部?)で、結局GPU1枚(5070ti)でしか動いてないみたいだ。
残念ながら、俺の5070ti環境でも、以下のコマンドで実行したllama.cppの方がデコード速度が20-30%速いんだよね。
set CUDA_VISIBLE_DEVICES=0
build\bin\Release\llama-server -hf google/gemma-4-12B-it-qat-q4_0-gguf -ngl 99 --no-mmproj-offload -mg 0 -c 262144 -fa on --host 0.0.0.0
参考までに、俺の個人的な悩みのトップリスト(一番目の項目にかけたダジャレのつもり)にはこれがある:
温度制御のための外部/ポリシーベースのサーマルスロットリングだ。制限をかけないと、ノートPCの底が火傷しそうなくらい熱くなる。かといって、固定の計算量キャップを設けると、場合によってはパフォーマンスが信じられないくらいガタ落ちする。今の計画は、ランタイム中に調整できるツマミを作って、手動設定の継ぎ接ぎだらけな制限を置き換えること。
VRAM+RAMにギリギリ収まるモデルを使うと、トークン/秒が1の桁になるくらい遅い。そうなるとツール呼び出しのオーバーヘッドがキツくて、『ls』コマンド打つだけで数十秒かかるような世界になっちゃう。計画としては、推論ループにハーネスプラグインを組み込んで、「停止しないで、呼び出し結果はもうあるからそのまま進めて」というような制御(あとlogit関連のテクニックも)ができるようにしたいね。
面白いアイデアだね!Strix Halo (AMD Ryzen AI Max+ 395) のベンチマークはある?Qwen3.8-Flash-Nextは未対応かな?
あと一般的な質問なんだけど、このエンジンはカスタム構成(複数の異なるGPUやeGPUなど)を検知して最適化してくれる?というのも、MacやDGX Sparkみたいなメジャーな既製品環境しか気にしないなら、長期的に勝つのは難しいと思うんだ。独自のSubredditを持たないようなカスタムシステムに自動で適応するエンジンがあれば、かなり隙間産業的なニーズを満たせるんじゃないかな。
UI上の速度予測はどれくらい正確なの?というのも、Qwen 3.8 (Q8) の速度数値がかなり低く見えるからなんだけど。
Estimated speed on your machine
Context tokens Tokens / sec
25 000 17
50 000 16
75 000 16
262 144 12
262Kの結果はいいとして、それ以下のコンテキストサイズ(<128K)だと、俺がMac M5 Maxで実測しているmtplxセッションの数値より2倍くらい遅いんだ。
最適化が足りないのか、数値が間違っているのか、それともベンチマークの特性(例えばエージェントセッションよりスペックデコーディングが難しい負荷とか)によるものなのかな?
これ、合成ベンチマークじゃなくて実際のエージェントワークロードでどう評価されるのか気になる。経験上、ツール利用のループが入ると、トークンの分布が単一プロンプトよりずっとバースト的になるから、エージェントのコストやレイテンシのプロファイルはガラッと変わるんだよね。評価はマルチステップのツール呼び出しトレースで行ったの?それともシングルターンがメイン?
「llama.cppの2倍」って、何で比較してるの?M3 Max?llama.cppのMetalカーネルはすでにメモリ帯域幅を使い切ってるはずだよ。実際のエージェントのボトルネックはシングルストリームのtok/sじゃなくて、24GB VRAMで128kのコンテキストを5つ以上同時に動かす時のKVキャッシュなんじゃないかな。実際、ローカルでマルチエージェントを動かしてる人ってどうなの? A) 単一セッションのみ B) 2-3エージェント C) 5エージェント以上 D) 諦めた