ローカルLLMの構築をMacだけで進める｜最初に決めておくこと

ローカルLLMの構築を調べ始めると、GPUを載せた自作機の話と、Macにアプリを入れるだけの話が同じ言葉で並んでいて、どちらが自分の話なのか分からなくなる。必要な出費も、かかる時間も、この2つでは桁が違う。ここでは、構築を始める前に決めておく項目を先に並べ、手元のMacで足りるのかどうかを見積もる方法から、組み終わった後に効いてくる設定までを順に確かめる。

同じ言葉で語られている2つの構築

ローカルLLMの構築という言葉は、少なくとも2つの違う作業を指している。1つは、推論用の機械そのものを組む作業である。GPUを選び、マザーボードの対応を確かめ、Linuxを入れ、ドライバを入れ、推論サーバを立てる。もう1つは、いま使っている作業用のMacにアプリを入れ、モデルを取得し、既存の作業に差し込む作業である。

読み手の多くが求めているのは後者だが、検索結果の上位には前者の記事が多く並ぶ。前者は写真が映え、書くことも多いためである。判断を誤らないために、最初に自分がどちらを求めているのかを決める。日々の仕事の合間に要約や整理を任せたいなら、機械を組む必要はない。専用機を立てて社内の全員で共有したい、あるいは常時稼働させたいという話になって初めて、前者の検討が意味を持つ。

見積もりの感覚を持つために、専用機を組む側の現実も知っておく価値はある。

そして気を付けないといけないのが、ほとんどのマザボは「x8 / x8」の動作をサポートしていないという点です。それなりのお値段以上のマザボでないとサポートしていないので、ここはしっかりと事前に確認してください。 出典: zenn.dev

GPUを2枚載せる構成では、マザーボードがレーンを分けて動かせるかどうかが先に来る。部品の相性を1つずつ確かめる作業が積み上がるため、費用だけでなく検証の時間も要る。この手間を引き受ける理由が自分の側にあるかどうかを、先に決めておく。

最初に決める4つの項目

構築を手順から始めると、途中で引き返す回数が増える。先に決める項目は4つである。

• どの規模のモデルを使うか: 数億パラメータの小さいものから、数千億のものまで幅がある。用途に対して過剰な規模を選ぶと、速度が落ちて日常の作業に使えなくなる
• どの実行環境を使うか: コマンド中心のものと、画面中心のものがある。併用もできる
• どこから呼ぶか: 用意された画面で使うのか、自分のスクリプトやエディタから呼ぶのか
• 何をローカルに寄せるか: 全部をローカルにする必要はない。定型の整理や要約だけを手元に寄せ、判断が要る作業はクラウド側に残す線引きが現実的である

ネットワークの向きも先に決めておく。1台の機械で作って使うのか、デスクトップ機に推論を任せてノート側から呼ぶのかで、必要な設定が変わる。前者なら初期設定のまま触らずに済み、後者なら待ち受け先を広げる設定と、公開範囲を絞る仕組みの両方が必要になる。認証の仕組みが本体に組み込まれていないため、社内ネットワークに限る、トンネルを通す、前段のプロキシで絞る、のいずれかを先に決めてから開ける。後から広げるのは簡単だが、開けたまま数週間置くと事故の種になる。

決め方に迷ったら、最初の構成は1台の中で完結させるのが無難である。使う頻度と、どの作業に効いたかが見えてから、共有する形へ広げればよい。最初から共有を前提に組むと、設定の数が増えて動かない原因の切り分けが難しくなる。

この4つのうち、後から変えにくいのは4つ目である。ローカルに寄せる範囲を広げすぎると、精度が足りずに結局手作業へ戻ることになる。狭く始めて、うまく回っているものから広げるほうが失敗が少ない。

手元のMacで足りるかどうかを見積もる

公式の資料では、macOS側の動作条件はSonoma、つまりバージョン14以降と示されている。Apple Mシリーズの機械ではCPUとGPUの両方が使われ、Intel系のMacではCPUのみとなる。統合メモリの構成では、システムメモリがそのまま推論に使われるため、搭載メモリの量が扱えるモデルの上限を決める。

見積もりの目安として、公式の入門用の案内では、ある小型モデルの取得量が約7.2GBで、推奨される空きは8GBとされている。この空きを下回っても動くが、システムメモリ側へはみ出して応答が遅くなる。文脈を長くとるとさらにメモリが要るため、余裕は多めに見ておく。

公開されているモデルの配布サイズを並べると、必要な容量の感覚がつかめる。80億パラメータ級で5.2GB、140億級で9.3GB、320億級で20GB、2350億級では142GBになる。手元の機械のメモリから、システムが使う分を引いた残りに収まる規模を選ぶ。

読み込んだモデルがどこに載ったかは、読み込み中のモデルを一覧するコマンドで確かめられる。表示が 100% GPU なら全部が載っており、48%/52% CPU/GPU のような表示なら分割されている。分割された状態は体感で分かるほど遅くなるので、そのときは1つ下の規模に落とす判断をする。

実行環境を選ぶときの分かれ目

実行環境は、コマンドで扱うものと、画面で扱うものに分かれる。コマンド中心のものは、HTTPサーバがローカルで待ち受ける形になっているため、自分のスクリプトから呼びやすい。画面中心のものは、チャットの履歴や設定の切り替えが用意されているので、使い始めが早い。

画面を用意する方向では、自分の機械の中で動かす形の選択肢がある。公式の手引きでは、コンテナで動かす場合はホスト側のポート3000を内部の8080に結び付ける例が示され、Pythonのパッケージとして入れた場合はポート8080で開く。専用のデスクトップアプリも配布されている。もう1つの選択肢は、モデルの取得から実行までを1つのアプリで完結させるもので、内部ではAppleの機械学習向けの実行基盤とllama.cppが使われている。

どれを選んでも、不安は同じところに残る。

ここまでローカルLLMの魅力や可能性について解説してきましたが、同時に「専門知識が必要そう…」「最適なPCを選ぶのが難しそう…」といった不安を感じた方もいらっしゃるのではないでしょうか。ローカルLLMの導入・開発には、環境構築、モデル選定、ファインチューニングといった専門知識が必要です。 出典: eques.co.jp

実行環境を2つ以上入れても構わない。コマンド側でサーバを動かし、画面側はその接続先を指すだけという構成が取れるため、同じモデルを2通りの入口から使える。使い始めは画面側で感触を確かめ、繰り返しの作業だと分かったものをスクリプトへ移すという進め方ができる。入れ直しの手間を心配して1つに絞る必要はない。

ファインチューニングまで踏み込むなら専門知識が要るが、既存のモデルを取得して使う範囲であれば、覚えることは数個の設定に収まる。全部を理解してから始めるのではなく、動く最小の形を作ってから広げるほうが早い。

どのモデルを最初に入れるかの決め方

規模を決めたら、次は具体的な銘柄を選ぶ段になる。ここで比較記事のベンチマークの数字を並べて悩み始めると、決まらないまま時間が過ぎる。判断の順番を先に固定しておくほうが早い。

第一に、搭載メモリから収まる規模を決める。第二に、その規模の中で日本語の応答が崩れないものを選ぶ。第三に、手元の作業に必要な機能があるかを確かめる。関数の呼び出しに対応しているか、思考の過程を出せるか、画像を読めるか、埋め込みの生成に使えるかといった部分である。この3段階で絞ると、候補はたいてい数個に収まる。

配布ページには、同じ銘柄の中に規模ごとの枝が並び、さらに精度を落として容量を圧縮した枝が並ぶ。たとえばある銘柄の6億パラメータ級では、4ビット相当の枝が523MB、8ビット相当が832MB、精度を落としていない枝が1.5GBと、同じ中身でも容量が3倍近く違う。容量が小さい枝は速く動くが、細かい指示の取りこぼしが増える。最初は既定の枝を入れ、精度に不満が出てから容量の大きい枝へ移るのが手戻りが少ない。

日本語で使うつもりなら、英語のベンチマークの順位をそのまま当てにしない。同じ規模でも、日本語の指示に対する素直さには差がある。候補を2つか3つ入れて、自分がふだん投げている指示をそのまま試すほうが、比較表を読むより早く決まる。モデルの取得は後から追加も削除もできるので、選び直す前提で始めてよい。

組み終わった後に効いてくる設定

構築が終わった直後は動いているように見えても、数日使うと引っかかる場所がいくつかある。

• 文脈の長さ: 既定は4096トークンで、長い文章を渡すと後半が落ちる。サーバ全体の既定を環境変数で広げるか、呼び出しごとに指定する
• 保存先: macOSでは ~/.ollama にモデルと設定がまとめて保存される。重みは数GBから数百GBまで積み上がるので、起動ディスクの空き容量を確かめる。空きが足りないときは保存先を変える指定がある
• 待ち受け先: 既定ではループバックにだけ結び付いている。別の機械から呼ぶ予定があるなら、環境変数で待ち受け先を変える。macOSでアプリとして動かしている場合は launchctl setenv で渡し、アプリを再起動する
• 外に出る経路を止めるか: 設定ファイルに指定を書くか、対応する環境変数を立てると、クラウド側のモデルとWeb検索が使えなくなる。顧客の資料を扱うなら、この指定を入れておくと説明しやすい
• ログの場所: macOSでは ~/.ollama/logs にアプリ側とサーバ側のログが分かれて保存される。不調の切り分けはここが最短である

この5つを最初に確かめておくと、後から「動いていたのに急に遅くなった」という状態で時間を使わずに済む。

構築の終わりを、作業に差し込めた時点に置く

モデルが応答したところで満足して止まると、数週間後には使わなくなっている。実際に効くのは、日々の作業のどこに差し込めたかである。要約したい書類を探し、パスを取り出し、ターミナルへ持っていき、返ってきた結果をフォルダの文脈に戻す。この往復が別々の窓で起きていると、推論そのものが数秒で終わっても前後の手作業が残る。フォルダとターミナルとAIが同じ窓にある状態にすると、この往復が消える。

差し込み先を考える材料として、ファイル管理側でできることの範囲はできることに整理されている。手元の機械に処理を任せたまま外出先から結果を受け取る使い方はiPhone・iPadから続きをにまとめられており、日本語を含む多言語の扱いは対応言語で確かめられる。

すでに別のファイル管理ツールを使っているなら、何がどう違うのかは他のファイル管理との比較にある。費用の考え方は料金にまとめられ、始める前に出やすい疑問はよくある質問に集まっている。

費用の線引きをするときは、クラウド側の相場も並べて見る。公式の料金表では、無料の範囲に加えて月額20ドルの段階に月60ドル相当の利用枠が付き、月額100ドルの段階では300ドル相当になる。手元で回す分は追加の費用がかからないため、定型の整理をローカルに寄せ、判断が要る処理だけクラウド側へ残す形が、費用と精度の折り合いとしては落ち着きやすい。