振り返り

Mac StudioでローカルLLMを回してみて、個人や少人数チームには「遅くても強いワーカー」という使い方が合っていました

AAnonymous
10分で読めます
#Mac Studio
#LM Studio
#ローカル LLM
#AIワークフロー

はじめに

ローカルでLLMを動かす話は、たいていインストール方法から始まります。どのランタイムを使うか、どのモデルを取得するか、どのポートを開けるか、といった説明から入ることが多いです。

ただ、しばらく使ってみると、もっと重要な問いが出てきます。ローカルで大規模LLMをどう実用的に使うかです。動くことと、使い続けられることは、まったく別の問題だからです。

私も最初は Ubuntu + vLLM + 3090 Ti 2枚 から始めました。今は Mac Studio M3 Ultra(512GB) と LM Studio に移行し、deepseek、qwen、glm 系の大きなモデルをローカルで動かしています。

この記事はインストールガイドではありません。3090を2枚使う構成でなぜ限界を感じたのか、なぜMac Studioに移ったのか、そして遅いローカルLLMを実作業でどう使っているのかを、軽く整理してみます。

最初は3090 Tiを2枚使う構成から始めました

初期構成はかなりシンプルでした。中古の 3090 Ti GPUを2枚、約220万ウォンで揃えて Ubuntu に載せ、ランタイムには vLLM を使っていました。

当時は gemma 3 が、ローカルでの体感が良かったモデルのひとつでした。とても単純な指示を処理するアシスタントや、小さなワークフローを作る程度であれば、十分に印象的でした。多言語性能も悪くなく、トークン生成速度も当時の基準ではかなり満足できるものでした。

実際にこの環境で、いくつものアシスタントを作って試しました。

  • チャットエージェント
  • タロットカードリーダー
  • 翻訳者タイプのアシスタント
  • シンプルなワークフロー型の作業エージェント

この段階で得た結論は明確でした。ローカルLLMは、もう おもちゃ の段階ではありませんでした。とはいえ、すぐに 意味のあるエージェント を作れる水準かというと、まだ足りない部分も多かったです。

問題はソフトウェアよりも、ハードウェアの現実でした

最初に vLLM を選んだ理由も単純でした。セットアップが比較的難しくなく、sglang よりずっと広く知られていたからです。

ただ、時間が経つにつれて気づいたのは、自宅で 3090 のマルチGPU環境を回すときのボトルネックは、ランタイム選びよりもっと現実的なところにある、ということでした。

  • 電気代が負担でした。
  • 発熱が大きすぎました。
  • 自宅で常時運用するのが難しかったです。
  • そして何より、本当に動かしたかった大規模モデルは、まだ無理がありました。

当時私がやりたかったのは、deepseek v3 級のモデルを、十分なコンテキストでローカル運用することでした。ですが、3090を2枚使っても、ここには明確な限界がありました。小さなモデルをうまく動かすことと、大きなモデルを継続的な作業資産として使うことは、まったく別の話でした。

結局私はGPUを手放し、Mac Studio M3 Ultra(512GB) を購入しました。この移行は単なる機材の入れ替えではなく、ローカルLLMの見方そのものを変える選択でした。

Mac Studioに移ってから可能になったこと

macOS + LM Studio に切り替えて最も大きく変わったのは、以前はそもそも視野に入れにくかったモデルが、現実的な選択肢として入ってきたことです。

deepseek、glm、Qwen3-235B-A22B のような大きなモデルを自分で載せて結果を確認できるようになると、性能そのものにはかなり驚きました。推論品質は想像以上に良かったです。少し複雑な指示を投げるだけでも、以前よりはるかに精密で安定した結果を返してくれることが多くなりました。

ただ同時に、限界も非常にはっきりしました。pp 性能は思ったより遅く、リアルタイムチャットのように即時の応答が必要な使い方には、明らかに向いていませんでした。調べている段階から「遅い」という話は知っていましたが、実際に毎日使ってみると、その限界はもっと鮮明に体感されます。

そこで私は判断基準を変えました。このモデルは速いか？ よりも、このモデルをどこに使うべきか？ を先に考えるようになったのです。

遅くても満足度が高かった作業

面白いことに、リアルタイム応答をあきらめると、ローカルLLMはずっと実用的になりました。

私が満足できた領域は、だいたい共通していました。

  • データ分析のように精密な結果が必要な作業
  • ゲームストーリー作成のように時間がかかってもよい作業
  • 複雑な分析ワークフローのように工程が多い作業
  • OpenHands系の自動開発のように、人の代わりに一晩中回しておける作業

たとえば、ストーリーを1本作るのに40分から60分以上かかることがあります。リアルタイムチャットの基準で見れば、ひどく遅い速度です。ですが、この作業を 寝る前に3件から5件ほどキューに入れておき、朝に結果を受け取る形へ変えると、話はまったく変わってきます。

遅い代わりに、結果はずっと大きく、ずっと精密です。人は一晩中待つ必要がなく、翌日に結果を確認して、次のキューを入れればよくなります。

OpenHandsの作業も同じでした。すぐ反応するコパイロットのように使うよりも、作業をキューに積んで自動で流し続ける形のほうが、ずっと合っていました。この見方でいえば、ローカルLLMは 遅いチャットボット ではなく、静かに長く働くワーカー に近いです。

ウサギのように速くなくても、カメのように勝てます

ローカルLLMを見ていると、私はよくウサギとカメの話を思い出します。

クラウドLLMは、たいていウサギに近い存在です。速くて即答性が高く、その場ですぐ使いやすいです。一方、ローカルの大規模モデルはカメに近いです。遅く、即時性の基準ではもどかしく、比較の仕方を間違えるとすぐ失望してしまいます。

ですが、評価基準を変えると結果も変わります。

リアルタイムチャットで勝負すると、ローカルLLMはよく負けます。ですが、キュー、反復作業、バッチ実行、夜間処理のように 粘り強さ が勝つ構造へ持っていくと、話は変わります。実際、私はこの使い方で高い満足度を得ました。しかも、消費電力もマルチGPU構成よりずっと安定していました。体感では、GPU構成の7分の1未満くらいの電力で、より大きなモデルを回せる点も大きかったです。

結局重要なのはモデルの速度ではなく、自分の作業をどんなリズムで設計するかでした。

私のコードも、結局はキュー中心に変わりました

これは単なる感想ではなく、実際の実装にもそのまま反映されました。

私の ai-service モジュールを見ると、ローカルLLMを リアルタイムチャット より バックグラウンドワーカー として捉えている痕跡がかなりはっきり見えます。

まず、モデル接続自体は思ったよりシンプルです。RunnableAiModel では vllm と lm studio をOpenAI互換プロバイダのように扱い、baseUrl だけ差し替えられるようにしてあります。つまり上位アプリケーションから見れば、OpenAI互換エンドポイントという形さえ合っていれば、ローカルバックエンドへ比較的自然に差し替えられます。

LM Studio 向けの別個の利用例もあります。LMStudioVisionClient は、実際に LM Studio の /v1 エンドポイントを前提にビジョンモデルをつなぐよう実装されています。ローカルVLMをつないで、画像解析まで流せるようにしたわけです。

もっと重要なのは、実行方式です。

AiAgentExecutor はワークフローをその場で実行せず、DTEジョブとしてキューに登録します。LoopJobService と LoopWorkflowExecutor は、繰り返し実行される長時間の作業をバックグラウンドで処理するよう設計されており、チェックポイントと復旧フローも備えています。WritingToolExecutor、マルチエージェントワークフロー、マーケティング生成パイプラインも、全体として即答型というより非同期実行型に近いです。

これは偶然ではありません。遅いモデルを無理やりリアルタイムのインターフェースに押し込むより、遅くても成立する作業をキューへ流すほうが、はるかに現実的だからです。

短く言えば、私はローカルLLMを次のように捉えるようになりました。

  • チャット応答器より、作業キューのほうに向いています。
  • 速度より、難度と精密さが重要な仕事に向いています。
  • 一晩回して朝にレビューするパターンと相性が良いです。
  • OpenAI互換APIさえ揃えば、既存サービス構造へ組み込むのもそれほど難しくありません。

では、ローカルLLMは誰に向いているのか

ここまで読んでくださったなら、たぶん同じような悩みがあるはずです。ローカルLLMは本当に使い物になるのか、そして大きなお金をかける価値があるのか、ということです。

私の基準はかなり明確です。

ローカルLLMは、次のような人によく合います。

  • リアルタイムチャットよりバッチ作業のほうが多い人
  • 複雑な生成や分析を一晩中回しておきたい人
  • 大きなモデルを低い運用コストで継続活用したい人
  • 自分の作業フローをキュー中心に再設計できる人

逆に、即時の対話体験が最優先なら、最初は間違いなくもどかしく感じるはずです。その場合、ローカルLLMは期待の置き方を誤った選択になりやすいです。

まとめ

ローカルで大規模LLMを動かす取り組みは、思った以上に早く「インストール成功」から「活用失敗」へ転びます。モデルが立ち上がったからといって、すぐ役に立つわけではないからです。

私は 3090 Ti 2枚 + Ubuntu + vLLM から始めて、今は Mac Studio M3 Ultra(512GB) と LM Studio へ移りました。この過程を通して出した結論はシンプルです。

エンタープライズの観点ではなく、個人や少人数チームの観点で見ると、ローカルLLMは高速チャットの代替というより、遅くても強いワーカーを作る方向でこそ大きく光ります。

もしすでにMacがあり、特にMac Studio級のマシンを持っているなら、一度はこういう形でローカルLLMを活用してみることをおすすめします。始め方は大げさである必要はありません。リアルタイムチャットではなく、今夜キューに入れておく1つの難しい作業から選べば十分です。

思っている以上に多くの可能性は、まさにそこから始まります。