ローカルLLMの実行ソフト、何から使えばいい？

チャットしたいのか、別のソフトから呼び出したいのか

質問して回答を読むことが目的なら、モデルを探して読み込むまでの手順が短いソフトが便利です。LM Studioは画面でファイルや実行状態を確認しやすく、Ollamaはモデルを名前で管理しながらローカルAPIを使う流れが簡潔です。どちらも、最初から別のWebチャット画面を追加する必要はありません。

一方、エディターやコーディングエージェントから呼び出すには、サーバーのアドレスとモデル名を合わせる必要があります。チャットが動くことと、ツール呼び出しまで動くことは別です。使う予定のアプリで、短い質問、ストリーミング、ツール呼び出しの順に試せば、問題の場所を絞りやすくなります。API互換という表記は、この確認を省いてよいという意味ではありません。

• LM Studio：画面でモデルを選び、ローカルサーバーにつなぐ
• Ollama：手軽に始めて、実行状態を確認する

Macでは、エンジンより先にファイルを確認します

同じQwenという名前でも、片方はGGUF、もう片方はMLX変換版かもしれません。どちらも4ビットと書かれていても、量子化方式や含まれる重みが同じとは限りません。エンジンだけを比較するつもりでモデルファイルまで変えると、何が差を生んだのか分かりにくくなります。

Apple SiliconでMLXを使うなら、oMLXとMTPLXも候補になります。oMLXの記事ではモデル管理と繰り返し入力のキャッシュを、MTPLXの記事では対応モデルのMTPと自分のMacで深度を選ぶ方法を扱います。まず、手元のファイルをそのまま使えるかを読んでみてください。今の環境で必要な作業ができているなら、すべてをインストールする必要はありません。

• oMLX：モデルを管理し、長い入力の待ち時間を見直す
• MTPLX：自分のMacでMTPの効果を確かめる

設定を自分で調整したいときはllama.cpp

モデルの一部がCPUで動いているか、コンテキストをどれだけ確保するか、GPUにどれだけ載せるかを直接調整したいなら、llama.cppのサーバーが候補になります。その代わり、アプリが引き受けていたファイル管理や起動オプションを自分で確認します。他の記事の長いコマンドをコピーする前に、手元のファイル1つで短いリクエストを完了させるほうが近道です。

得られるのは、どの機材でも最速になるという保証ではなく、実行した設定を明確に残せることです。動いたコマンドを保存して1項目ずつ変えれば、メモリ不足や初回応答の遅さをたどり直せます。後で機材を比較するときにも、そろえるべき条件が分かります。

• llama.cpp：GGUFファイル1つでサーバーを起動する

リクエストが重なると、サーバーに求めるものが変わります

1人でチャットするときは、最初の文字が出るまでと、回答が終わるまでの時間が重要です。文書処理とコーディングエージェントが同時にリクエストするなら、待ち行列も重要になります。vLLMやSGLangを検討する理由は、このようにモデルを常時動かし、リクエストを管理したいときにはっきりしてきます。

複数GPUでも、1つのモデルを分割して載せるのか、各機材にモデルを複製してリクエストを振り分けるのかを先に決めます。SparkのARM64環境に一般的なPC向けのインストール手順をそのまま移せるとは限りません。以下の記事の短い例は接続確認用です。大きなモデルの量子化や分散設定は、機材別レシピで確認します。

• vLLM：1件の応答速度とサーバー処理量を分けて考える
• SGLang：繰り返しリクエストとモデル別の実行経路を確認する

変更前と後に、同じ仕事をさせてみます

普段使う質問と文書を1つずつ残しておきましょう。モデルファイル、入力の長さ、出力上限を記録し、初めて読む文書と再び読む文書を分けます。出力前の待ち時間、生成が続く速さ、受け取った回答で直す必要があった箇所まで比べると、数字1つで選ぶより判断しやすくなります。

新しいエンジンが早く終わっても、回答が短くなったりツール呼び出しが抜けたりしていれば、同じ仕事を終えたとは限りません。逆に速度が同程度でも、モデルの切り替えが楽になって使う頻度が増えるなら、選ぶ理由になります。エンジン選びは勝者を覚えることより、自分の作業から減らしたい不便を見つけることに近いのです。