Magnitude、エージェント推論をllama.cppより最大2倍高速化

llama.cppの2倍って、何で？M3 Maxで？llama.cppのmetalカーネルはすでにメモリ帯域を飽和させてるよ。実際のエージェントのボトルネックはシングルストリームのtok/sじゃない——24GBのVRAMで5つ以上の同時128kコンテキストを扱うKVキャッシュだ。実際にローカルでマルチエージェントを動かしてる人ってどれくらいいる？A) シングルセッションのみ B) 2〜3エージェント C) 5以上 D) 諦めた

自分のローカル推論ボックスでは、llama.cppのチェックアウトの中で常時codexスレッドを開いていて、定期的に現在保留中のllama.cppのPRを見てみたり、最新のMTP、Dflash、その他の予測やアテンションの最適化について調べたり、最新のモデルの量子化やファインチューニングについて調べたり、localLlamaのRedditスレッドを眺めたりして、要するにフロンティアを一通りスイープしている。

その後、最新のllama.cppをリビルドし、テストすべき関連PRを拾ってきて、ベンチマークを実行し、アップグレードを確定させ、どのモデル、バリアント、あるいは別のファインチューニングを動かすべきかを検証する。

時折、自分自身で最適化を行ってコミットすることもあるが、それは後にPRやマージされたコードに取って代わられ、結局モデル自身の最適化の方向性が正しかったことが裏付けられる。

これは良いアイデアだと思う。ただ、速度でllama.cppを打ち負かすのはハードルが低い :)

良いベースラインだとは思うけど、少なくともMacではいつも何かずっと速いものや、メモリ要件がより良いものがあって——君が言ったようにds4、omlx、mtplxなどだ。ローカルLLMを本気で使うなら、より最適化されたエンジンのどれかを使わない理由はほとんどないように思える。

エンジンで観察した主な失敗モードは3つ：

* 利用可能な最良のspec decodingを使っていない

* KVキャッシュにVRAMを使いすぎている（例えば、ds4ではKVキャッシュがほとんど何も使わなかったのに、deepseekモデルではunsloth/llama.cppで大量のVRAMを消費していた）

* 大きなコンテキストサイズでの性能低下——4Kや32Kでのベンチマークは素晴らしいが、現実的な100〜200Kでは、いくつかの馬鹿げたベースラインよりも遅い

これが実際のエージェントワークロードで、合成ベンチマークと比べてどう機能するのか気になります。自分の経験では、ツール使用のループが関わるとエージェントのコストとレイテンシのプロファイルは大きく変わります。というのも、トークン分布が単一プロンプトよりもずっとバースト的になるからです。マルチステップのツール呼び出しトレースで評価しましたか、それとも主にシングルターンですか？