SiliconBenchが示す、速度だけでは測れないローカルLLM推論

導入

Apple SiliconのローカルLLM推論は、毎秒何トークンを生成できるかという速度で比較されがちだ。しかし、複数のチャットやエージェント処理を同時に動かすデスクトップでは、統合メモリを使い切らないこと、そして出力品質を維持することも同じくらい重要になる。SiliconBenchは、この見落とされやすい条件を含め、速度、メモリ、出力忠実度の3つの観点からサービングエンジンを評価した。

主なポイント

• 9種類のエンジンを比較。 Apple Silicon側ではvllm-metal、omlx、llama.cpp、Ollama、mlx_lm、vllm-mlx、SGLang、Hugging Face Transformers、mistral.rsを対象とした。DGX Spark上のvLLM、SGLang、llama.cppは補助的な性能リファレンスとして使われている。
• 同時実行時の伸び方に差がある。 Qwen3-0.6Bでは、同時実行数を1から16に増やすと、vllm-metalのチャットおよびエージェント処理のスループットは2倍を超えて伸びた。ただし、同じプロンプトで比較すると、CUDA版vLLMとSGLangのほうが同時実行へのスケーリングは強かった。
• メモリ上限を設定しても余裕は残らない。 2つのスタックは全リクエストを完了できたものの、メモリ使用量が物理容量に近づき、スループットが低下した。統合メモリ環境では、モデル本体、KVキャッシュ、同時処理中のリクエストが同じ資源を奪い合うため、設定上の予算だけでは安全性を判断できない。
• モデル対応範囲も選定基準になる。 新しいQwen3.5とGemma 4は、利用できるエンジンの範囲が狭い。評価対象の実装はNVIDIA側の忠実度リファレンスと一致したが、リクエスト完了、忠実度、モデル対応範囲の3条件をすべて満たしたスタックは3つだけだった。
• 初回トークンの遅延が調整方式を映す。 より大きな密モデルとMoEモデルでは、vllm-metalのパック化されたprefill-decode経路が、同時負荷下でomlxより低い初回トークン遅延を維持した。入力処理と生成処理を並行して調整する重要性が分かる。
• ノード間通信が拡張性を決める。 評価された2台構成では、Thunderbolt RDMAによるテンソル並列はスケールした一方、TCP上のパイプライン並列は性能が低下した。

意義と影響

SiliconBenchは、どの環境でも通用する単一の勝者を決めたものではない。むしろ、ローカル推論エンジンは用途に応じて選ぶべきだと示している。単一リクエストの速度に優れたバックエンドでも、複数の会話やエージェント処理が同時に走れば、メモリ圧迫や初回応答の遅延が表面化する可能性がある。

利用者は、まず必要なモデルが動くかを確認し、次に現実的な同時実行数でメモリ余裕を測り、最後にタスク単位の品質を検証する必要がある。開発者にとっては、カーネルの高速化だけでなく、prefill-decodeのスケジューリング、メモリの可視化、新アーキテクチャへの対応、複数ノード通信までがサービングの成熟度を構成する。

Hugging Face Daily Papers