Qwen3.8-27Bを16GB Macで動かす排障法

最後に更新した日：2026年8月19日。Qwen公式資料、Ollama公式ドキュメント、Apple公式サポートを再確認しています。

Ollamaのモデルページでは、qwen3.8:27b と qwen3.8:27b-mlx がそれぞれ約18GBとして表示されています。Ollamaのモデル表示を基準にすると、16GB Macではモデルだけで物理メモリを上回ります。macOS、Ollama、コンテキストキャッシュ、ブラウザーやエディターも同じ統合メモリを使うため、ダウンロード成功と安定推論は別の問題です。Ollamaのコンテキスト長ガイド

症状：読み込み失敗、交換の増加、推論表示だけで終了。
最短解決：短い純テキストで基準値を取り、thinkingとコンテキストを下げても交換が続くなら、16GB Macでの常用をやめて小型モデルか高メモリMacへ切り替えます。

この排障記事が必要な人

対象は、Apple Silicon Macでqwen3.8:27bまたはqwen3.8:27b-mlxを取得済みなのに、最初の文字が出るまで長い、操作全体が重い、あるいは回答ではなく推論部分だけが表示される人です。

コードAgent、長文書の解析、画像入力、多輪の会話で使う予定がある場合も確認してください。自分のMacを買い替えるか、一時的に高メモリのMacをレンタルするか、小型モデルへ移るかを、感覚ではなく観察結果で決められます。

18GBのモデルと16GBの統合メモリは、設定変更だけでは逆転しません

16GB Macのメモリは、モデル専用のVRAMではありません。モデルの重み、推論ランタイム、KVキャッシュ、macOS、常駐アプリが同じ領域を分け合います。

そのため、num_ctxを下げても重みの容量そのものは消えません。設定変更で減らせるのは主にコンテキスト由来の追加負荷です。18GBの量子化パッケージを16GBの筐体で動かす場合、「一度起動した」状態を「継続して使える」と判断してはいけません。

判断の目安は次のとおりです。

• 起動直後に終了する：モデル形式、Ollamaの対応版、タグの不整合を疑います。
• 回答は出るが極端に遅い：統合メモリ不足によるCPU分担や交換の増加を確認します。
• 数回の会話後に固まる：長い履歴、thinkingの出力、画像やツール入力によるキャッシュ増加を疑います。

OllamaのPROCESSOR表示は、モデルがGPU側とCPU側のどちらに配置されたかを示す情報です。CPU/GPU混在だけで即失敗とは限りません。ただし、16GB Macで混在表示が出たうえ、交換メモリも増えるなら、速度低下の原因として優先的に調べます。OllamaのFAQでは、100% GPU、100% CPU、CPU/GPU混在の意味が整理されています。Ollama公式FAQ

第一歩：ollama psとアクティビティモニタで、遅さの正体を分けます

まずターミナルで次を実行します。

ollama ps

確認する項目は、モデル名、SIZE、PROCESSORです。モデルが一覧に残らない場合は、読み込み自体が完了していません。CPU/GPUの割合が表示されても、それだけで故障と断定せず、次にメモリ状態を確認します。

macOSのアクティビティモニタでは「メモリ」タブを開き、次を同時に見ます。

• メモリプレッシャー
• 圧縮メモリ
• スワップ使用量
• Ollama関連プロセスのメモリ使用量

Appleは、メモリプレッシャーが空きメモリだけでなく、スワップ率、圧縮メモリ、システムが固定的に使うメモリなどから判断されると説明しています。Apple公式のメモリ使用状況ガイド

黄色や赤が一瞬出ただけでは判断しません。同じ短いプロンプトを複数回送り、交換使用量が増え続けるか、Finderやエディターの操作まで遅くなるかを見ます。継続的な交換とシステム全体の反応低下が同時に起きるなら、単なる出力設定の問題ではありません。

推論だけ表示される場合は、モデル破損より出力上限を疑います

Qwen系モデルはthinkingを既定で有効にし、推論ブロックを生成した後に最終回答を出す構成を取ります。Qwen公式のモデル資料では、enable_thinking=Falseによる無効化や、/think、/no_thinkによる切り替えが説明されています。Qwen公式のthinking切り替え資料

出力上限が短い状態で難しい質問を送ると、推論中に生成枠を使い切ります。その結果、画面には推論らしき内容だけが残り、回答がないように見えます。

切り分けは次の順番です。

1. 「3行で要点だけ答えてください」と指定します。
2. 画像、ツール呼び出し、長い会話履歴を外します。
3. プロンプト末尾に/no_thinkを付けて反応を見ます。
4. APIや独自チャット画面を使う場合は、対応するインターフェースの公式仕様でenable_thinking=Falseまたは推論深度の指定方法を確認します。
5. 変更後に、同じ短い質問を複数回実行します。

OllamaのテンプレートがQwen3.8-27Bの切り替え方法に対応していない場合、/no_thinkを書くだけでは完全に無効にならないことがあります。表示だけを見て「モデルが壊れた」と判断せず、利用中のOllama版とチャット画面の実装を確認してください。

num_ctxを下げる効果と、下げても解決しない境界

コンテキスト長は、モデルがメモリ上で参照できるトークン量です。大きくするほど追加メモリが必要になります。Ollama公式ドキュメントでは、ollama run中の/set parameter num_ctx、環境変数、Modelfileによる指定方法が案内されています。Ollamaのコンテキスト設定

対話画面では、例えば次のように設定できます。

/set parameter num_ctx 2048

API経由なら、利用しているAPIの仕様に合わせてoptions.num_ctxを指定します。OpenAI互換APIでは、モデルを作成するModelfileにPARAMETER num_ctxを記述する方式が案内されています。

ただし、16GB Macに適した固定値を保証することはできません。コードAgent、会話履歴、画像、過去のthinking、並列リクエストで必要量が変わるためです。まず短い純テキストと単一リクエストで基準を作り、そこから少しずつ増やしてください。

注意：num_ctxを下げて一度回答できても、モデルの重みが約18GBである事実は変わりません。長時間の常用や多輪処理で交換が再発するなら、設定をさらに削るより環境を変える方が安全です。

第二歩：16GB Macで試すなら、可逆性の高い順に止血します

次のチェックリストを上から実行します。途中でメモリプレッシャーが悪化する場合は、下の項目へ進まず停止してください。

• [ ] ブラウザー、IDE、仮想環境、別のモデルを終了する
• [ ] Ollamaで同時に読み込むモデルを1つにする
• [ ] 画像入力と長い会話履歴を外す
• [ ] num_ctxを小さくして単発の短文で試す
• [ ] /no_think、または利用中のAPIでthinking無効化を試す
• [ ] 短い出力上限で同じ質問を複数回送る
• [ ] ollama psの読み込み状態を記録する
• [ ] アクティビティモニタで交換使用量の増加を確認する
• [ ] 2回目、3回目もMac全体が操作可能か確認する
• [ ] 交換が続く、画面操作が重い、回答が完了しない場合は中止する

評価基準は「1回生成できたか」ではありません。同じモデルタグ、同じ質問、同じコンテキストで繰り返し、完全読み込みに近い状態を維持できるか、交換が増えないか、タスクを最後まで完了できるかで判断します。

小型モデルと高メモリMacは、用途で選び分けます

短い要約、軽い質問、プロンプト確認が中心なら、小型モデルへの変更が合理的です。16GB Macのまま使える可能性が高く、交換によるシステム全体の遅延も避けやすくなります。

一方、Qwen3.8-27Bのコード処理、画像理解、長いタスクを試したいものの、毎日使うわけではない場合は、高い統合メモリを持つMacを一時的にレンタルして比較する方が、いきなり買い替えるより判断しやすいです。MacHTMLのコンソール利用方法や利用ガイドを確認し、同じモデルタグと同じプロンプトで検証してください。

比較時は、次の条件を固定します。

• qwen3.8:27bまたはqwen3.8:27b-mlxの同一タグ
• 同じプロンプト
• 同じnum_ctx
• 同じthinking設定
• 同じ入力形式
• 1回目だけでなく複数回の実行

見るべき項目は、ollama psの読み込み状態、交換使用量の推移、最初の文字が出るまでの時間、タスク完了率です。単発の生成速度だけでは、長時間運用の安定性を比較できません。

16GB Macの現在の構成には、3つの弱点があります。約18GBのモデルを統合メモリで受ける余裕がないこと、交換が始まるとMac全体の操作性まで落ちること、thinkingや長いコンテキストを削っても本来の使い方から遠ざかることです。短い検証だけなら設定変更で試せますが、開発作業を止めずに使うなら、高メモリのMacをレンタルして同条件で一度検証する方が、買い替え判断を誤りにくいです。

必要な期間だけMacHTMLの利用プランを確認し、16GB Macで記録したログと同じ条件で対照テストを行ってください。継続負荷が高く、データを手元から出せない場合は固定設備の増設が向いています。逆に、検証、短期開発、チーム内の評価環境が目的なら、まずレンタルで「安定して最後まで完了するか」を確認するのが現実的です。