10分で最初のモデル

有能なモデルをローカルで動かすのは今や10分の仕事で、週末プロジェクトではない。2つの経路がほぼ全員をカバーする。コマンドが好きな人にはターミナル(Ollama)、プログレスバーが好きな人にはGUI(LM Studio)。どちらも同じ場所に着く——自分のディスク上の量子化GGUFが、対話速度で応答し、何も外へ通信しない。1つの道を選び、実行し、最後にヘルスチェックを。

始める前に

マシンについて3つの数値を知ること。

VRAM(またはユニファイドメモリ):8 GBならQ4の7〜9Bが動き、16 GBなら13〜14B、24 GBなら30B級に届く。完全なサイジング計算はVRAM計算。
メモリ帯域幅:tok/sを決めるのはこれであって計算性能ではない——速度を参照。
空きディスク:複数のモデルを試すつもりなら50〜100 GBを予算化。

経路A:ターミナルルート(Ollama)

Ollamaをインストール。Linux/macOSでは1行のインストールスクリプト、Windowsではインストーラ。ローカルサービスを起動し、ollamaコマンドを与える。アカウントなし、キーなし。

中サイズのオープンモデルを選ぶ。執筆時点では7〜9B級——qwen3:8bかLlama 3.1 8B級モデル——が正しい最初のモデル。本当に有用で、8 GB GPUに収まるかCPUに耐える。韓国語を書くなら、QwenとGemmaのファミリーが歴史的に韓国語テキストをうまく扱ってきた——ただしトークナイザは異なるので、自分の実際の段落でテストすること(トークンを参照)。

# 取得(約5 GB)と会話開始を1ステップで
ollama run qwen3:8b

これでチャットループにいる。メッセージを打ち、Enterを押し、トークンが流れるのを見る。初日用スラッシュコマンド。

/bye          # チャットを終了
/show info    # 使用中の量子化、コンテキスト長、テンプレート

シェルに戻って、あと2つ。

ollama list   # ディスク上にあるものと、それぞれのサイズ
ollama ps     # 今メモリにロードされているものと、その場所

ollama psが最初の本物の計器。常駐サイズと、100% GPUや48%/52% CPU/GPUのようなCPU/GPU分割を報告する。分割にCPUが含まれていれば、モデルはGPUに完全に載っていない——直せる設定問題であってハードウェアの限界ではない。エンジンノブを参照。

健全な表示の例。

NAME         ID           SIZE     PROCESSOR    UNTIL
qwen3:8b     a1b2c3d4...  5.7 GB   100% GPU     4 minutes from now

SIZEがディスク上のファイルより大きいのは正常。常駐サイズは重み+計算バッファであって、2つ目のコピーではない。

経路B:GUIルート(LM Studio)

LM Studioをインストール。検索タブを開き、ファミリー名——Qwen3、Llama 3、Gemma 3——を打つと、サイズと量子化の壁が現れる。シンプルに保つ2つのルール。

まずパラメータ数をメモリに合わせる:Q4の8BはKVキャッシュの前でおよそ4〜5 GB。
ダウンロードごとのサイズヒントを信じる——余裕を含むので、「収まる」は実際に収まる。Q4_K_M級の量子化を優先。詳細は量子化。

ダウンロードはプログレスバー。チャットタブでモデルをロードして話しかける。下部の表示が生成中のトークン毎秒を示す——ヘルスチェックのためにその数値を覚えておく。LM StudioはOpenAI互換のローカルサーバも公開でき、後のサービングで役立つ。

tok/sの表示が低く見えても、まだ何もアンインストールしないこと——壊れていると結論する前に、下のヘルスチェックを完了させる。

「プル」で実際に起きること

魔法はない。このエコシステムでのモデルは1つのGGUFファイル(モデルフォーマットを参照)。全レイヤー、トークナイザ、メタデータを含む単一のblob。ollama pullとLM Studioのダウンローダは、そのblobをチャンクで取得し——それが見えている階層的なプログレス——ダイジェストを検証し、ローカルインデックスにファイルを登録する。中断されたダウンロードは停止位置から再開。「モデルのインストール」とは、文字通り大きなファイルをダウンロードして居場所を覚えること。アカウントなし、ライセンスサーバなし、外部通信なし。

初回ヘルスチェック

3つの数値が構成が健全かを教える。

確認項目	見る場所	健全な状態
デコード速度	tok/s表示(LM Studio)またはOllamaログのタイミング	最近のディスクリートGPUで30+ tok/s。物理は速度
初回トークンまでの時間	返信が始まるまでの長さ	短いプロンプトならウォーム時に約1秒未満。長い貼り付けはより長く(プリフィル——速度を参照)
メモリの収まり	`ollama ps`、GPUメーター、システムモニタ	モデル+KVキャッシュが完全に常駐。計算はVRAM計算

3つすべて通れば、チューニングを止めてモデルを使いに行くこと。この段階ではプロンプトの品質が他のすべてに優る——プロンプトを参照。

3大初回失敗

症状	本当の原因	修正
ロード失敗またはメモリ不足でクラッシュ	モデルが収まらない	量子化を1段下げる(Q4 → Q3)かモデルサイズを下げる(8B → 4B)。量子化を参照
流暢なゴミ、誤った言語、反響ループ	モデルに合わないチャットテンプレート	ランナーはモデル自身のテンプレートを使う必要がある。プロンプトとトラブルシューティングを参照
GPUがあるのに1〜2 tok/s	大半のレイヤーがまだCPUにある	フルGPUオフロードを強制。エンジンノブを参照

3つすべて設定の問題で、ハードウェアではない。どれも「このマシンには無理」を意味しない。

ファイルの居場所とディスク衛生

Ollamaはすべてを~/.ollamaの下に置く——モデルは~/.ollama/modelsの下にコンテンツアドレス方式のblobとして保存される。LM Studioは~/.lmstudio(旧ビルド:~/.cache/lm-studio)。両者とも警戒すべき速さで膨らむ。1回のプルは2〜20 GBで、UIからの削除がディスクにblobを残すことがある。

報われる習慣。

毎月ollama listを実行し、触っていないものはollama rm。
ディスクが一杯になる前にモデルディレクトリを知っておく。後からの移動は環境変数1つ(OLLAMA_MODELS)+ファイルコピーであって、再ダウンロードではない。
実際のタスクに1つのモデルが、「念のため」の5ダウンロードに勝る——コールドストレージも帯域幅の代金を要求する。
LM Studioもインデックスから削除するが、モデルフォルダが実際に縮んだか確認すること——信じて、それから検証。

関連: 推論エンジン · エンジンノブ · 速度 · モデル選択