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

ローカルモデルをまだ動かしていない場合は、OllamaやLM Studioの案内から始められます。Macでモデルを使っているならoMLXやMTPLXが現在のファイルに対応するか確認し、Woof向けHuskyのような特定モデル専用の実行経路も区別します。別モデルの最高速度を、自分のモデルの高速化倍率として当てはめることはできません。

個人PDFから更新日を探したいなら、まずファイルを開いて質問できるアプリが必要です。LM Studioは画面でモデルと実行状態を確認しながらチャットしやすく、Ollamaはモデル名で管理してローカルAPIにつなぎやすいツールです。ただしPDFのテキスト抽出や関連箇所の検索は文書アプリの機能であり、エンジンを選ぶだけでは追加されません。

質問には日付と例外条件を含め、元の文書で回答の根拠を確認します。アプリが根拠となる段落をモデルに渡し、その位置を保持するか確認してください。この手順がなければ、エンジンが速くても欠けた出典は補えません。

別のプログラムから同じモデルを使う場合は、サーバーが応答することと、API のアドレスとポートがクライアント設定に一致することを確認します。「OpenAI 互換」は接続確認の手がかりです。クライアントが必要とする機能も対応しているか、別途確認してください。

同じQwenモデル名でも、一方はGGUF³、もう一方はApple Silicon向けMLX⁴変換版の場合があります。どちらも4-bitと表示されていても、量子化⁵方式や保持される重みが同じとは限りません。ファイルとアプリを同時に変えると差の原因が分かりにくいため、まずモデル形式を確認します。

MacのMLX経路ではoMLXやMTPLXを候補にできます。oMLXはモデル管理や反復入力キャッシュ、MTPLXは対応モデルにMTP⁶が含まれ生成待ちを減らせるか確認する場合に検討します。各案内でモデル形式と対応機能を照合します。現在のアプリでPDFの作業ができているなら、試さないランタイム⁷まで先に導入する必要はありません。

アプリの既定設定を超えてファイル別名・コンテキスト長・GPU⁸に載せるレイヤー・同時スロットを管理したい場合はllama.cppサーバーを検討できます。その代わり、通常アプリが担うモデルファイルとオプションの管理を自分で行います。GGUF一つと短い質問で応答を確認してから実際のPDFを試すと、段階的に検証できます。

ファイルとオプションを記録すると、PDF投入時のメモリ不足・初回出力の遅れ・生成時間を比較できます。GPUを使う構成なら、状態画面やログで実際に選ばれたbackendを確認します。一方がGPU、他方がCPU⁹で動いている場合、ランタイム名だけの比較にはなりません。

一人でPDFを読む場合は、一つの回答の開始と完了時刻が重要です。エディターと文書アプリが同時にサーバーを呼ぶと、一方の完了まで他方が待つことがあります。この場合はサーバーのリクエスト管理と総スループット¹⁰を見ます。継続的な複数リクエストにはvLLMやSGLangを検討できますが、個人チャットだけなら機能の多さだけを理由に複雑さを増やす必要はありません。

複数GPUでは、重みを複数デバイスに分割するのか、モデル複製を置いてリクエストを振り分けるのかを先に決めます。ランタイムと機器接続がその経路に対応する必要があります。DGX SparkはARM64のため、一般PC向けインストールコマンドをそのまま使えるとは考えないでください。短い例で接続を確認し、大規模モデルの形式と分散設定は機器別案内に従います。

現在のアプリと候補アプリに同じPDF・質問・出力長を与え、可能ならモデルファイルと量子化も揃えます。初回モデル読み込みは繰り返し会話の遅延と分け、文書を初めて開く場合と再度開く場合も別々に記録します。最初のトークン¹¹までと回答完了までを分けて測り、必要な条項と根拠が残っているかも確認します。

PDF根拠付き質問・短いチャット・エディターからの要求を一度に変えないでください。モデルが速くても根拠を省いたりツール呼び出し¹²に失敗したりすれば、元の作業を代替できません。文書チャットならLM StudioやOllama対応アプリ、他ソフトとの接続ならAPIサーバー、実行設定の直接管理ならllama.cpp、継続的な待ち行列ならvLLM・SGLangを検討します。必要な作業を完了できている構成を維持するのも選択肢です。