Zedでローカルモデルを実行する理由と方法

多くのタスクにおいて、私はローカルモデルを使うことを好みます。最良のモデルが必要なときは依然として最先端のものを利用しますが、多くの場合そこまでの性能は必要ありません。自分のマシンで動作し、データを自分が管理するハードウェアに保持し、プロバイダーが価格や制限を変更しても消えないものを好みます。

オープンウェイトモデルも向上しています。LM Studio、Ollama、llama.cppなどのツールは使いやすくなり続けており、過去10週間でZedのエージェントにおけるローカルモデルの使用は3倍に増加しました。

Zedでは、AI機能を金儲けのために構築しているわけではなく、開発者を一つのAI利用方法に縛るビジネスもしません。ACPを介したCodex、自身のAPIキー、Zed Proへの直接サブスクリプションなど、好みのプロバイダーを簡単に使えるようにしています。

この記事では、ローカルモデルの優れた点、不足している点、そしてZedでの設定方法を説明します。

なぜローカルか？

ローカルモデルにはクラウドホスト型モデルに比べていくつかの利点があります。

• **完全なプライバシー**：ほとんどのクラウドプロバイダーはデータ無保持ポリシーを提供していますが、ローカルモデルは絶対的な確実性を提供します。データはネットワーク外に出ることはなく、必要ならマシンからも出ません。
• **低コスト**：初期のハードウェアコストはかかりますが、現在の開発者用ノートPCでも十分なモデルを実行できることが多いです。予期せぬ価格変更を心配する必要もありません。価格は一貫性があり、透明で、低コストです。
• **より高い制御性**：システムプロンプトの設定、機能の有効化/無効化（例：画像サポート）、コンテキストウィンドウの変更などが可能です。ユースケースに合わせて微調整された人気モデルのバージョンを見つけることもできます。パイプライン全体を所有しているため、同じ名前で低コストのモデルが密かに提供されている心配がありません。
• **常時利用可能**：多くの開発者と同様、SaaSプラットフォームのように動作するプロバイダーへの過度な依存を懸念しています。価格や設定の変更で利用不可能になる可能性があります。ローカルモデルなら常にアクセスできます。

ローカルモデルの欠点

ローカルモデルが完璧なら、クラウドプロバイダーは存在しないでしょう（少なくとも現在の規模では）。

最先端モデルを許容可能な速度で実行するために必要なハードウェアは、消費者には手が届きません。ローカルで実行できるモデルは、トップAIラボのモデルほど高性能ではありません。また、毎秒のトークン数も少なくなるでしょう。

とはいえ、開発者用ノートPCでも良い結果を得ることは可能です。ただし、最先端レベルの結果は期待しないでください。

ローカルモデルの実行方法

ローカルでモデルを実行するための無料のオープンソースプロジェクトが多数あります。私はLM Studioで最も成功していますが、Ollamaとllama.cppも人気があります。Zedはこれらすべてを標準でサポートしています。

ランタイムを用意したら、モデルを選びます。私はQwen 3.6 35B A3Bを使用しています。この名前は少々長いですが、各部分に意味があります。

• **Qwen 3.6**：モデルファミリー。Alibaba製で、3.6が最新リリースです。同じファミリーのモデルでもサイズ、速度、機能サポートなどが異なります。
• **35B**：350億のパラメータを持つことを示します。パラメータはトレーニング中に学習された値で、実行時にはメモリに読み込む必要があります。
• **A3B**：「アクティブ30億」の略。これはMixture of Experts（MoE）モデルで、合計350億のパラメータを持ちますが、生成されるトークンごとにアクティブなのは約30億のみです。高密度モデルとは異なり、すべての重みが常にアクティブになるわけではありません。実用的には、MoEモデルは少量の知能を犠牲にして性能を大幅に向上させます。大まかな経験則として、トークンの生成時間はアクティブなパラメータ数に比例します。Qwen 3.6 35B A3Bのようなモデルではアクティブパラメータが30億であるため、高密度35Bモデルより約10倍高速に動作します。

Apple MシリーズやAMD Strix Haloなどの一部のチップはユニファイドメモリをサポートしています。ユニファイドメモリではGPUがシステムメモリに直接アクセスできますが、専用GPUのメモリよりもかなり低速です。MoEモデルはこれらのシステムで特に魅力的です。アクティブなパラメータが少ないため、低メモリ帯域幅の影響が少ないからです。

最後に、量子化を検討してください。量子化は各パラメータをより少ないビットで保存することでモデルを小さくする方法です。350億パラメータをメモリに保持するにはどれだけのVRAMが必要か？それは各パラメータのサイズによります。モデルは通常16ビット浮動小数点パラメータでトレーニングされますが、それらは圧縮できます。私がテストしたQwen 3.6モデルはQ4モデルで、各パラメータは4ビットです。350億パラメータなので、約17.5GBのVRAMが必要です（コンテキストやその他のオーバーヘッドを除く）。LM StudioにはモデルがGPUに収まるかどうかを示す便利なUIがあります。

Zedの設定

プロバイダーを設定したら、Zedをその場所に向けます。LM Studioを使用しているので、LM Studio設定を追加し、http://localhost:1234/api/v0 を指すようにし、LM Studioサーバーがlms server startで実行されていることを確認します。

Ollama、llama.cpp、または他のOpenAI互換システムを使用している場合は、組み込みのOllamaプロバイダーを使用できます。

その後、Zedエージェント内のモデルセレクターでダウンロードしたモデルが表示されるはずです。

非最先端モデルの扱い

そこからはおなじみの体験です。プロンプトを送信すると、モデルが応答し、コードを編集し、ツールを使用できます。

ただし、最先端モデルに慣れている場合、ローカルモデルを使用する際に特に注意すべき点が2つあります。

• **最先端モデルほど「賢く」ない**。
• **通常、コンテキストウィンドウが小さい**。

そのため、効果的に使用するにはより注意と規律が必要です。ベストプラクティスがより重要になります。

たとえば、モデルが誤った方向に進んだりループに陥ったりした場合、新しいメッセージで訂正するよりも、以前のメッセージを編集して悪い方向を避けるように導く方が効果的です。これによりコンテキストウィンドウが無駄な情報で埋め尽くされるのを防ぎます。

また、サブエージェントをより多く使うように促すのも良いでしょう。サブエージェントは、小さな変更がコンテキストウィンドウに与える影響を制限する強力なツールです。

最後に、実験してみましょう！さまざまなプロバイダーのさまざまなモデルをテストしてみてください。コンテキストウィンドウのサイズや温度を調整してみてください。専用GPUを搭載した高性能ゲーミングPCをお持ちなら、高密度モデルを試してみてください。自分に合った組み合わせを見つけたら、Discordで共有してください。

ハッピーハッキング！