DeepSeekをローカルで動かす｜Macで選ぶモデルの大きさと手順

deepseek ローカルで調べている人の多くは、手順そのものではなく「自分のMacでどの大きさまで動くのか」で止まっている。配布されている型はパラメータ数で7段に分かれていて、いちばん大きいものと小さいものでは配布容量が400倍近く違う。ここでは、モデルの大きさを先に決める考え方、導入に使う2つの道具の違い、動かしたあとに遅さの原因を切り分ける見方を順に整理する。

ローカルで動かす話が一気に広がった理由

DeepSeekが話題になったのは、性能の高さと同時に、重みが公開されて手元の機械に落とせる形で配られたからだ。クラウドの対話サービスを使う場合、入力した文章は提供元のサーバーへ送られる。契約書の下書き、まだ公表していない仕様、取引先の名前が入った資料を読ませたいとき、ここが引っかかる。手元で動かせば、通信そのものが発生しないため、その引っかかりが消える。

もう1つの理由は費用の形が変わることだ。クラウドのAPIは使った分だけ払う形で、長い文章を何度も読ませると積み上がる。ローカルは電気代と機械の投資だけで、回数を気にせず試せる。下書きの言い換えを20通り出すような、単価では割に合わない使い方が現実的になる。

Appleシリコンの機械が広く行き渡ったことも効いている。メインメモリとGPUのメモリが共通の作りなので、ゲーム向けのグラフィックボードを積んだWindows機のように「GPUのメモリに載りきらない」という壁が出にくい。裏返すと、OSやブラウザが使っている分と取り合うことになるため、空きの見積もりが重要になる。

実際に手元で動かした記録には、次のような一節が残っている。

実際に動かして体感してみないとよくわからないので、ローカルでDeepSeekを動かしてみました。 出典: zenn.dev

読む前に決めておくと楽なのは、何のために手元で動かすのかという1点だ。機密を外へ出さないことが目的なら小さい型で足りる場合が多い。込み入った推論をさせたいなら、そもそも手元では無理な大きさになることもある。

手元で動くものと、名前が似ていても動かないもの

最初に片づけておきたい区別がある。DeepSeekという名前の付いた型のうち、手元のMacに落とせるのは一部だけだ。配布の窓口として広く使われているOllamaの一覧を見ると、新しい世代の型には「cloud」という印が付いている。これは提供元のサーバーで動かす扱いで、手元に重みが落ちてくるわけではない。

手元に落として動かせる系統は、推論に強いDeepSeek-R1の一族と、DeepSeek-V3系の大きな型になる。V3系はパラメータ数が671億ではなく6,710億あり、配布容量が404GBに達するため、個人の机の上の機械では現実的ではない。個人で試す範囲は、実質的にR1の小さい型から中くらいの型に収まる。

この区別を知らないまま「最新の型をローカルで」と考えると、手順のどこかで必ず行き止まる。名前に付いた版の新しさではなく、その型が手元向けに配られているかどうかを先に見る。

モデルの大きさを配布容量から決める

R1は同じ名前のまま、7つの大きさで配られている。数字はパラメータ数の目安で、後ろに続く容量が実際に落ちてくるファイルの大きさだ。

型の指定	配布容量	扱える文脈の長さ
deepseek-r1:1.5b	1.1GB	128K
deepseek-r1:7b	4.7GB	128K
deepseek-r1:8b	5.2GB	128K
deepseek-r1:14b	9.0GB	128K
deepseek-r1:32b	20GB	128K
deepseek-r1:70b	43GB	128K
deepseek-r1:671b	404GB	160K

決め方の目安は単純で、配布容量がメモリの空きに収まるかどうかを見る。推論中は重みをメモリに載せたまま動くので、容量が空きを超えると、Mac側が使っていない部分をディスクへ追い出しながら進む形になり、応答が数十秒単位で待たされる。

16GBの機械なら、OSとブラウザとエディタが常に数GBを使っている前提で、7bか8bが無理のない線になる。32GBなら14bが常用でき、32bも試せる。64GB以上あれば32bが常用の範囲に入る。70bはメモリだけでは足りず、ディスクとのやり取りが増えるため、対話の道具としては使いづらい。

小さい型を軽く見ないほうがよい。1.5bは受け答えの質は落ちるが、文章の言い換え、箇条書きの整形、短い要約のような作業ならこなす。まず1.5bで動く経路を作り、道具の使い方に慣れてから大きい型に上げる順番が、つまずきが少ない。

OllamaとLM Studioを比べて入口を選ぶ

導入に使う道具は、大きく2つに分かれる。どちらもMacで動き、同じ重みを使う。違いは操作の入口と、後から何につなげやすいかにある。

Ollamaはコマンドで扱う道具だ。ターミナルで1行打てば重みを落として対話が始まり、同時に手元のポートでAPIが立つ。この形が効くのは、自分で書いたスクリプトや別のアプリから呼びたい場合だ。編集中のファイルを読ませて処理するような使い方なら、こちら側が扱いやすい。

LM Studioは画面で操作する道具で、モデルの検索、ダウンロード、対話までを窓の中で完結できる。内部ではllama.cppとMLXという2つの実行系を使い分ける作りになっている。MLXはAppleシリコン向けに書かれた仕組みで、同じ型でも手元の機械に合った形で動かせる。コマンドに慣れていない段階では、こちらのほうが引き返しやすい。

• ターミナルを日常的に使っていて、自分の処理につなげたい人はOllamaから入る
• 画面で選んで試したい人、量子化の違いを一覧で見比べたい人はLM Studioから入る
• どちらも入れて構わない。重みのファイルは別に持つので容量は倍かかる

初心者におすすめしやすいのは、まずLM Studioで小さい型を動かして手応えを掴み、処理を自動化したくなった時点でOllamaを足す順番だ。逆の順で入ると、コマンドの引数と量子化の記号を同時に覚えることになり、どこでつまずいたのか分からなくなる。

同じ大きさでも容量が違うのは丸め方の差

一覧を見ていると、同じパラメータ数の型に複数の候補が並ぶことがある。これは重みの数値をどこまで細かく持つかが違うためだ。元の精度のまま置くと容量が大きくなりすぎるので、配られている型はたいてい丸めた形になっている。7bの型が4.7GBに収まっているのは、この丸めが効いているからだ。

丸めを粗くすると容量が減り、読み込みも速くなる。代わりに、細かい指示への追従や数字の扱いが落ちやすい。逆に丸めを細かくすると容量が増え、メモリの空きを圧迫する。LM Studioは同じ型の複数の候補を容量つきで並べるので、どの線で妥協するかをその場で選べる。Ollamaは型の名前を指定するだけで標準の候補が落ちてくるため、迷わずに済む反面、細かく選びたいときは指定を足すことになる。

判断に迷ったら、先に粗い側を試すとよい。粗い型で用途に足りるなら、それ以上細かくしても体感は変わらないことが多い。足りないと感じた場面を書き出してから細かい型に移れば、容量を増やした分の見返りがあったかどうかを自分で確かめられる。

Macで動かすまでの手順

Ollamaを使う場合の流れは4段になる。どこで止まっても、前の段に戻れば原因が絞れる形にしておく。

1つめは道具の導入だ。公式サイトからMac向けの本体を落として入れる。入れた時点で常駐の仕組みが動き、ターミナルから呼べる状態になる。

2つめは重みの取得と対話の開始で、ollama run deepseek-r1:8b のように型を指定して実行する。手元に重みが無ければ自動で落としてくるので、回線の速さによっては数分から十数分かかる。落とし終わると、そのまま入力待ちになる。

3つめは動きの確認だ。日本語で短い質問を投げて、返答が始まるまでの時間と、1文字ずつ出てくる速さを見る。R1系は考えている過程を先に出す作りなので、答えが出るまでに間が空くことがある。これは詰まりではない。

4つめは呼び出し口の確認で、http://localhost:11434 に対してリクエストを送れば、自分のスクリプトから使える。ここまで通れば、あとは型を入れ替えるだけで大きさを変えられる。

LM Studioを使う場合は、アプリ内の検索でdeepseek-r1を探し、量子化の種類と容量を見て落とすだけになる。容量の横に、手元の機械で動くかどうかの目安が出るので、選ぶ時点で無理のない型が分かる。

遅い、途中で止まる、日本語が崩れるときの見どころ

動き始めたあとの相談は、ほぼ次の4つに分かれる。

• 応答が極端に遅い。配布容量がメモリの空きを超えている可能性が高い。1段小さい型に落として比べる
• 最初の1文字までが長い。文脈に長い文章を入れていると、読み込みの時間が先に掛かる。短い質問で比べ直す
• 途中で打ち切られる。扱える文脈の長さの上限に当たっている。指示と資料を分けて、資料側を削る
• 日本語の言い回しが不自然になる。小さい型ほど起きやすい。1段大きい型で同じ指示を試す

もう1つ気を付けたいのが、他のアプリとの取り合いだ。仮想マシン、動画の書き出し、ブラウザの大量のタブが動いているときは、空きメモリが数GB単位で削られる。同じ型が昨日は軽かったのに今日は重いという場合、モデル側ではなく机の上の状況が変わっている。

出力の質を上げたいときに、型を大きくする以外の手も残っている。指示の中に判断の基準を書く、出力の形を先に指定する、読ませる資料を必要な部分だけに絞る。この3つは型の大きさを変えずに効くので、先に試す価値がある。

処理を頼む相手を分けておくのも手だ。要約や整形のような軽い作業は小さい型に任せ、込み入った推論だけ大きい型に回す。型の入れ替えは指定を変えるだけなので、作業の種類ごとに使う型を決めておくと、毎回いちばん重い型を起こす必要がなくなる。

手元のAIとファイルの行き来をどこで減らすか

ローカルでモデルが動き始めると、次に出てくるのは別の詰まりだ。読ませたい資料はフォルダの中にあり、実行はターミナルで、結果の確認はまた別の窓になる。型の選び方で悩んでいた時間より、この往復に取られる時間のほうが長くなることも珍しくない。

ここを縮める考え方として、ファイルの一覧とターミナルとAIを1つの窓に置く形がある。どの操作が窓を移らずに終わるのかはできることに整理されている。フォルダとターミナルとAIが同じ窓にあると、モデルに渡した資料と、出てきた結果のファイルを同じ画面で並べて確かめられる。Finderや他のファイル管理アプリとの違いは他のファイル管理との比較で見比べられる。

ローカルのモデルは重い処理のあいだ机の前を離れることが多い。外出先から様子を見る方法はiPhone・iPadから続きをにまとまっている。日本語以外の資料を扱う場合の表示は対応言語で確かめられ、費用の考え方は料金、細かい疑問はよくある質問にある。

最初に決めることは1つに絞れる。手元の機械の空きメモリを見て、そこに収まる配布容量の型を1つ選ぶ。そこから上げ下げしていけば、どの大きさが自分の作業に釣り合うかは1日で分かる。