GPUがないノートPCでローカルAIを動かす:CPUだけで現実的な使い方

まず確認すること:メモリと対応CPU

CPUだけで動かす場合、最初の壁は速度よりメモリです。モデルのファイルサイズに加えて、OSやブラウザが使う分も必要になります。ファイルサイズは実行時に必要なメモリ量そのものではありません。

LM Studioのシステム要件(2026年10月29日に閲覧)では、次のように案内されています。

• RAMは16GB以上を推奨。Apple Silicon搭載Macは8GBでも小さなモデルと控えめなコンテキスト長なら使える場合がある
• Windowsはx64とARMに対応。x64ではAVX2命令セットへの対応が必要
• MacはApple Silicon(M1/M2/M3/M4)が対象で、Intel Macは現在未対応
• Windowsでは4GB以上の専用VRAMを推奨

OllamaとLM Studioのどちらを使っても構いません。コマンドに抵抗がなければOllama、画面で選びたいならLM Studioが入りやすいでしょう。以下の手順はOllamaで書きますが、モデルの大きさの考え方は共通です。

小さいモデルから試す順序

Ollamaのライブラリページに載っているファイルサイズを目安にします。たとえばGemma 3は 1b が806MB、4b が3.4GB、12b が8.2GBです。Qwen3は 0.6b が523MB、1.7b が1.4GB、4b が2.5GB、8b が5.2GBです(いずれも2026年10月29日に確認したページ上の数値で、更新される可能性があります)。

試す順序の提案は次のとおりです。

1. 約1GB前後:gemma3:1b または qwen3:1.7b。まず「自分のPCで動く」ことと、待ち時間の感覚をつかみます。
2. 約2.5〜3.5GB:qwen3:4b または gemma3:4b。小型モデルの中では、実用的な文章が出やすい帯です。
3. 約5GB:qwen3:8b。ここは速度が落ちやすいので、手順3の判定で合格したときだけ進みます。
4. 8GB超:12b以上は、メモリ16GBでも他のアプリと両立しにくくなります。GPUなしのノートPCでは最初から狙わないほうが無難です。

どのモデルがどの日本語タスクに強いかは、この記事では比較していません。小さいモデルほど誤りや言い落としが増えるのは一般的な傾向なので、出力は必ず人が読んで確認してください。

実行コマンドの例

ollama run gemma3:1b

初回はモデルのダウンロードが入ります。動いたら、別のターミナルで次を実行します。

ollama ps

Processor列が「100% CPU」であれば、CPUだけで動いています。確認が終わったら ollama stop gemma3:1b で解放できます。Ollamaは既定で、使い終わったモデルを5分間メモリに残します(FAQの記載)。次のモデルを試す前に止めておくと、メモリ不足を避けやすくなります。

待ち時間を測る:3つの依頼文

速度の指標として、トークン毎秒のような専門的な数値は要りません。ストップウォッチ(スマホで可)で、次の2つを測ります。

• A:最初の文字が出るまでの秒数(入力が長いほど伸びやすい)
• B:出力が終わるまでの秒数と、出力された文字数

Bから「1分あたり何文字出るか」を計算します。測るための依頼文は、次の3つで足ります。以下は説明用の例です。人名・会社名はすべて架空で、手元の実データを使う場合は、機密情報を含まないよう置き換えてください(ローカル実行でも、画面の共有やログの保存で漏れることはあります)。

依頼文1(短い入力・短い出力)

次の一文を、丁寧なビジネスメールの言い方に直してください。候補は3つ。
「昨日の資料、まだ見てないので、あとで見ます」

依頼文2(中くらいの入力・要約)

次のメモを3点の箇条書きに要約してください。
(ここに、架空の会議メモを400〜600字程度貼る)

依頼文3(長めの出力)

新入社員向けに、社内チャットの使い方の注意点を、600字程度で説明してください。

依頼文1は日常の小回り、2は読み込みの重さ、3は長文生成の遅さを見る役割です。

判定表:この待ち時間なら使えるか

しきい値は私が提案する目安で、実測にもとづく基準ではありません。自分の作業に合わせて動かしてください。

• 一文の言い換え・分類、許容しやすい待ち：数秒〜10秒程度、目安の見方：依頼文1で、Aが数秒、Bが10秒前後なら日常で使える、向かないなら：1b→4bの順で、手を止めずに待てる上限を決める
• 短いメモの要約、許容しやすい待ち：20〜60秒、目安の見方：依頼文2のBが1分以内か。放置できる作業か、向かないなら：入力を短く切る、4bから1.7bに下げる
• 600字級の長文生成、許容しやすい待ち：1〜3分、目安の見方：依頼文3を別作業の合間に回せるか、向かないなら：目的を「下書きの骨子」に絞る
• 対話を重ねる相談、許容しやすい待ち：毎回の待ちが短いこと、目安の見方：往復のたびに待つので、最も不満が出やすい、向かないなら：無理にCPUで続けない

判定の手順は次のとおりです。

1. 同じ3つの依頼文を、1b級→4b級の順に実行して、A・Bと文字数をメモする。
2. 出力を読んで、直さないと使えない誤りが何割かを自分で見る。
3. 表の用途ごとに「待てる/待てない」を決める。待てた最大のモデルが、あなたの現実的なサイズです。
4. 4bまでで十分なら、そこで止めます。8bは「4bの出来に不満があり、待ち時間にも余裕があるとき」に限って試します。

遅いときに調整できること

コンテキスト長を絞る。 OllamaのFAQによると、並列リクエスト数が増えると、必要なRAMはコンテキスト長に応じて増えます。FAQでは既定のコンテキスト長を4096トークンとし、環境変数 OLLAMA_CONTEXT_LENGTH で変更する方法を案内しています。ノートPCで一人が使うなら、並列数を増やさず、コンテキスト長は必要な分だけにするのが現実的です。

入力を短く切る。 長い文書を丸ごと渡すとAの待ちが伸びます。章ごとに分けて要約してから、要約を要約する運用のほうが、小型モデルには扱いやすくなります。

常駐させるか決める。 頻繁に使うなら、APIの keep_alive を使えばモデルをメモリに保持できます(負の値で保持、0で直後にアンロード)。ただしメモリを占有するので、他のアプリが重くなるなら既定の5分のままにしてください。

他のアプリを閉じる。 ブラウザのタブが多いと、モデルがメモリに載り切らず極端に遅くなることがあります。

向いている仕事と、避けたい仕事

CPUだけで現実的なのは、次のような仕事です。

• 文の言い換え、敬語の調整、誤字の候補出し
• 短いメモの要約、見出し案の作成
• 問い合わせ文の分類(例:依頼/苦情/質問の3区分)

避けたほうがよいのは、長い資料の一括読解、複雑な推論や計算、事実の正確さが問われる調べものです。小型モデルは自信ありげに誤ることがあるため、事実関係は必ず一次資料で確認してください。

最初の一歩としては、gemma3:1b を入れて依頼文1を実行するだけで構いません。そこで待ち時間の感覚をつかめば、次に4b級へ進むかどうかは、上の判定表で決められます。