LM Studio から llama.cpp に切り替えましたが、肥大化したラッパーには戻れません

AI をローカルで実行することは簡単なことのように思えますが、それを簡単にしているアプリが実際に必要なリソースを静かに消費していることに気づきます。 LM Studio を使用するのに時間を費やしてから、ハードウェアがモデル自体を実行するよりもインターフェースを維持するために一生懸命働いていることに気づきました。ただし、Llamma.cpp ははるかに優れており、Raspberry Pi でも実行できます。

LM Studio は肥大化しすぎています

生の llama.cpp の重いラッパーを捨てました。

AI をローカルで実行し始めたとき、LM Studio のようなツールに引き寄せられました。モデルの検索、ダウンロード、チャット インターフェイスのおかげで非常に人気があるため、その理由は非常に簡単にわかります。操作感はコンピューター上で他のアプリを使用するのとあまり変わりませんし、NAS も必要ありません。

ただし、パッケージは実際に機能しているものを隠しているだけなので、その利便性には代償が伴います。 LM Studio、Ollama、GPT4All はすべて、同じコア エンジン (llama.cpp) を下で実行するローカル AI です。

異なるのは、そのエンジンを中心に構築されているすべての部分です。重い GUI マネージャーは、インターフェイスを維持するためだけに、OS にメモリと CPU サイクルを消費させます。私のハードウェアは、実際の AI 作業を実行する代わりに、視覚要素のレンダリングと API 変換レイヤーの維持に予算を費やしていました。 LM Studio は明らかにやりすぎだったので、私はあまり長くは使いませんでした。

主な原因は、これらのマネージャーのほとんどが Electron 上に構築されていることです。Electron には、Node.js ランタイムにバンドルされた完全な Chromium ブラウザ エンジンが同梱されています。 AIが何もしていないときでもコストがかかります。

実際には、LM Studio だけで 1.40 GB の RAM を搭載し、バックグラウンド オーバーヘッドとして最大 1.2 GB の GPU VRAM を引き出すことができます。 8 GB カードでは、これは小さな不便ではありません。どのモデルをロードできるかは直接決定されます。ラッパーが取得するすべてのメガバイトは、モデルが取得できないメガバイトです。

llama.cpp をネイティブ バイナリとして実行すると、そのような作業がすべてカットされます。他の AI は空の UI だけで PC にメモリを浪費させる可能性がありますが、llama.cpp はバックグラウンドのフットプリントを低く抑えます。実行中は、通常のブラウザ以上である必要はありません。ラッパーもレイテンシを追加します。プロンプト取り込みが行われます。これは、最初のトークンが表示されるまでの待ち時間にすぎません。 llama.cpp の実行と LM Studio の使用には顕著な違いがありました。

ラッパーをバイパスするとそれが修正されました。 llama.cpp の動きは速く、GUI ツールはリリース サイクルから常に数週間遅れるため、別の利点もあります。直接実行すると、マルチモーダルオーディオ入力などの新機能が出荷と同時に利用可能になります。

より短い学習曲線で実際のコントロールが可能になります

コマンドライン インターフェイスの学習は、GUI からすると怖く感じられる場合があります。コマンド ラインを使用するときはいつでも、PC 上で何かが壊れる可能性があると考えていたことを覚えています。ただし、生の llama.cpp に切り替える場合は、学ぶ価値があります。

PC 上で llama.cpp を実行するには、2 つの場所からファイルを取得し、両方を同じローカル フォルダーにプルするだけで、基本的には完了です。

llama.cpp GitHub リポジトリから開始します。最新リリースに移動し、ハードウェアに一致する事前にコンパイルされた zip をダウンロードします。適当な場所にフォルダーを作成し、その中にすべてを解凍します。

次に、Hugging Face に進み、GGUF 形式で必要なモデルを取得します。ただし、テストには軽いモデルの方が賢明です。そのファイルを同じフォルダーにドロップします。

実行するには、次のように入力します cd 次にフォルダーからのパス。次に、最初のプロンプトでスクリプト内で AI に名前を付けると、会話を開始できます。

最初のプロンプトの前に、必ずモデル ファイル名とともに起動文字列を使用してください。これが私が使用したものです llama-cli -m meta-llama-3-8b-instruct.Q4_K_M.gguf -ngl 99 -p "Why is running AI via raw llama.cpp better than a heavy GUI wrapper?"

パフォーマンスの違いは一度目にすると無視できません。アイドル状態の VRAM 使用量は、数ギガバイトから 1 分の 1 に減少します。プロンプトの処理速度が大幅に向上したため、最初のリクエストでそれに気づきました。 GUI を取り除いて自分でチューニングするのは複雑に思えますが、違いは間違いなくわかります。

トレードオフにはそれだけの価値がある

パフォーマンスの向上により、バックグラウンドでの動作が困難になります

初心者にとっては GUI の方が優れていると主張する人がいる理由は簡単にわかります。 LM Studio のようなアプリは、導入の煩雑な側面を隠し、快適な、すぐに手に取ってプレイできるエクスペリエンスを提供します。本当に GUI に興味がある場合は、PC に対する制限や負担が少ないため、LM Studio よりも GPT4All をお勧めします。

モデルを使用してコードを実行すると、これを通常のチャットボットのように見せることができます。 -ngl 99 URL は http://localhost:8080 です。それはうまくいきません。

ほとんどの人にとって、ターミナルを介して言語モデルを実行することは開発者の領域のように見えます。ディレクトリを調べて実行パラメータを設定する方法を学ぶには時間がかかり、それが人々を挫折させる可能性があります。利便性を求めるなら、重いラッパーを選ぶでしょう。ただし、ローカル AI をカジュアルなデスクトップ アプリのように扱うことは、グラフィックのオーバーヘッドすべてに対して実際のパフォーマンスの代償を支払うことを意味します。

インターフェイスを実行し続けるためだけに、1 GB を超える VRAM を放棄するつもりはありません。それは大変な無駄です。 llama.cpp インターフェースを学習すると、そのようなことはすべてなくなり、一度学習するだけで済みます。その後、マシンは実際の作業に集中できます。

スピードとコントロールに慣れた今、重いインターフェイスに戻るのは、まさに後退のように感じます。美しいインターフェイスのためにパフォーマンスを放棄しているように感じます。 llama.cpp には Web サーバーが組み込まれているため、端末を見つめ続ける必要もありません。いくつかのコマンドを少し学習するだけで、セットアップがより速く、よりクリーンになります。

---

端末は違いを生み出すものです

生の llama.cpp への切り替えは誰にでも適しているわけではありません。端末での作業にまだ慣れていない場合は、たとえ見た目よりも短くても、学習曲線は実際のものです。既存のハードウェアに負担をかけない GUI が必要な場合、GPT4All は LM Studio よりも合理的な出発点です。とはいえ、一度でもラッパー オーバーヘッドなしでモデルを実行すると、違いを見分けるのは困難です。多くのセットアップでは、実際に必要なモデルをロードするか、より小さいモデルに落ち着くかの違いです。