GTX 1060 で Qwen 35B を動かす実践：llama.cpp を 3 tok/s から 17 tok/s へ最適化する

Wed, 24 Jun 2026 10:07:45 +0800

6GB VRAM の GTX 1060 で、35B クラスの大規模モデルは動かせるのでしょうか。

一般的な感覚では、最初の答えは「かなり厳しい」になるはずです。35B は大きすぎますし、VRAM は 6GB しかありません。量子化済みのモデルでも、生成が遅い、メモリが足りない、コンテキストを伸ばせない、しばらく動かすと不安定になる、といった問題が出やすくなります。

ただしモデルが MoE アーキテクチャで、llama.cpp のレイヤーオフロード、CPU メモリ、パラメータ調整を組み合わせると話は変わります。ハイエンド GPU の体験にはなりませんが、「なんとか動く」状態から「ローカル実験には使える」状態まで持っていける可能性があります。

この記事では実践的な調整手順を整理します。GTX 1060 を過大評価するためではなく、低VRAM GPUで Qwen 35B のようなモデルを動かすときに、どこを見るべきか、何を調整するべきか、どうボトルネックを判断するかを説明します。

まず結論

低VRAM GPUで 35B モデルを動かすときの要点は、すべてをVRAMに押し込むことではありません。GPUには、加速効果が大きい部分だけを担当させるのが現実的です。

大まかな流れは次の通りです。

まず動かす
-> デフォルトが遅い理由を見る
-> GPU オフロードを調整する
-> MoE の特性で不要な負荷を減らす
-> メモリとキャッシュのボトルネックを直す
-> その後でコンテキスト長を伸ばす
-> 最後に安定性を確認する

最初から「VRAMにどう収めるか」だけを見ると、調整の方向を間違えやすくなります。より実用的な目標は、VRAM、システムメモリ、CPU、ディスク、コンテキストキャッシュをうまく連携させることです。

環境を準備する

この構成を試す前に、次の条件を用意しておくと安心です。

GTX 1060 6GB のような、6GB 前後のVRAMを持つ NVIDIA GPU;
十分なシステムメモリ。少ないほど swap や OOM に当たりやすい;
CUDA 対応でビルド済みの llama.cpp;
低VRAMで試しやすい量子化モデルファイル;
クラウド API のような速度は期待しない姿勢;
VRAM、RAM、プロセス使用量を確認できること。

まず次のコマンドで環境を確認します。

1
2
3

nvidia-smi
free -h
./llama-cli --help

nvidia-smi でGPUが見えない、または llama.cpp がCUDA対応でない場合、後からパラメータを調整しても期待した効果は出ません。

ステップ1：まずモデルを動かす

最初から 17 tok/s を狙わないでください。最初の目標は、モデルを正常に読み込み、出力できるかどうかです。

基本的なコマンドは次のようになります。

./llama-cli \
  -m /path/to/model.gguf \
  -p "用三句话解释什么是 MoE 模型" \
  -n 128

ここで失敗する場合、まだGPUオプションを追加しない方がよいです。先に確認することは次の通りです。

モデルファイルのパスが正しいか;
量子化形式が現在の llama.cpp でサポートされているか;
システムメモリが足りているか;
間違ったモデル版をダウンロードしていないか;
現在のバイナリがそのモデルアーキテクチャに対応しているか。

動くことを確認してから、速度の最適化に入ります。

デフォルト速度が 3 tok/s 程度になる理由

低VRAM環境でデフォルトが遅い場合、原因は一つではないことが多いです。

よくあるボトルネックは次の通りです。

ボトルネック	症状	対処方向
GPU オフロードが少なすぎる	GPU が暇で CPU が忙しい	可能な範囲で GPU offload を増やす
オフロードが攻めすぎ	VRAM が溢れる、エラーが出る	オフロード層数を下げる
メモリ帯域が足りない	CPU 使用率は高いが token が遅い	無駄を減らし、より合う量子化を試す
コンテキストが大きすぎる	起動直後から遅い、RAM が急増する	小さいコンテキストで先に試す
swap が使われている	システム全体が重い	RAM を増やすかパラメータを下げる
batch 設定が合わない	prompt 処理が遅い	batch 関連パラメータを調整する

調整時は tok/s だけを見ないでください。次を同時に開いておくと判断しやすくなります。

1
2

watch -n 1 nvidia-smi
htop

GPU VRAM、GPU 使用率、CPU 使用率、システムメモリをまとめて観察します。

ステップ2：GPU オフロードを調整する

llama.cpp で最も一般的な高速化方法は、モデルの一部の層をGPUへオフロードすることです。

よく使うパラメータは次の通りです。

-ngl 20

少し完全な例はこうです。

./llama-cli \
  -m /path/to/model.gguf \
  -p "写一个本地大模型调优 checklist" \
  -n 256 \
  -ngl 20

この 20 は固定の正解ではありません。低VRAM GPUでは少しずつ試します。

-ngl 10
-ngl 15
-ngl 20
-ngl 25

変更するたびに、次の三点を確認します。

正常に起動するか;
VRAM が上限に近づいていないか;
tok/s が本当に上がったか。

VRAM がすでに限界なら、さらに -ngl を増やしても速くなるとは限らず、不安定になる可能性が高いです。

ステップ3：MoE が重要な理由を理解する

MoE モデルは一般的な dense モデルとは少し違います。

MoE の特徴は、総パラメータ数は大きくても、各 token で必ずすべての expert が動くわけではないことです。つまり、35B と書かれていても、すべての token が 35B 全体の計算を必要とするとは限りません。

これが低VRAM GPUでも試せる余地がある理由です。

ただし注意点があります。

MoE は無料の魔法ではなく、モデルファイル自体は大きい;
VRAM が足りない場合、CPU メモリが大量のデータを受け持つ。

したがって MoE モデルを最適化するときは、本当に頻繁に使われ、加速効果が大きい部分をGPUに渡し、VRAMを最も効果的な場所に使うことが重要です。

ステップ4：メモリのボトルネックを処理する

低VRAMで動かない原因を、VRAMだけの問題だと思いがちです。実際には、VRAM、RAM、キャッシュが一緒に詰まることがよくあります。

実行時にシステムメモリがほぼ使い切られていたり、swap が大量に使われていたりすると、速度は大きく落ちます。次で確認できます。

free -h

または：

`1`	`vmstat 1`

頻繁な swap が出ていないかを見ます。

改善の方向は次の通りです。

より小さい量子化版に変える;
コンテキスト長を下げる;
batch を下げる;
並行タスクを減らす;
不要なバックグラウンドプロセスを閉じる;
モデルを高速な SSD に置く;
システムメモリに余裕を残す。

システムメモリ自体が小さすぎる場合、6GB GPUだけで快適にするのは難しいです。

ステップ5：最初からコンテキスト長を最大にしない

長いコンテキスト対応をうたうモデルは多いですが、低VRAMマシンでは最初から最大値を使わない方が安定します。

まず小さめのコンテキストから始めます。

-c 4096

安定したら次を試します。

-c 8192

さらに上げるときは、メモリと速度の変化を観察します。

コンテキストが長いほど KV cache の負荷は大きくなります。低VRAM環境では、短い回答の生成よりも長いコンテキストの方が問題を露出しやすいです。

ローカルQ&A、コード片の説明、短い要約が目的なら、最初から巨大なコンテキストを追う必要はありません。

ステップ6：batch パラメータを見る

llama.cpp の batch パラメータは prompt 処理や生成の挙動に影響します。バージョンによって名前が少し違う場合があるので、まずヘルプを確認します。

`1`	`./llama-cli --help`

基本的な考え方は次の通りです。

prompt が長い場合、batch 調整で処理速度が改善することがある;
VRAM が厳しい場合、batch が大きすぎると不安定になることがある;
他人の値をそのままコピーせず、自分の環境で試す。

調整するときは一度に一つのパラメータだけを変えるのがおすすめです。

たとえば、モデル、コンテキスト、-ngl を固定してから batch を試します。そうしないと、どの変更が効いたのか判断しづらくなります。

ステップ7：五つの重要パラメータを記録する

低VRAMのローカル推論で一番困るのは、「今日は動いたのに、明日どの設定だったか忘れる」ことです。

毎回、次の項目を記録しておくと便利です。

パラメータ	記録する内容
モデルファイル	モデル名、量子化版、ファイルサイズ
GPU オフロード	`-ngl` または関連するオフロード設定
コンテキスト長	`-c` の値
batch	batch / ubatch などの設定
結果	tok/s、VRAM、RAM、安定性

簡単には次のように書けます。

model: Qwen-xx-35B-xxx.gguf
gpu: GTX 1060 6GB
ngl: 20
ctx: 4096
batch: default
speed: about 17 tok/s
status: short text is stable, long context needs more testing

次にモデルやマシンを変えたとき、すぐに比較できます。

より安定したテスト手順

おすすめの順序は次の通りです。

GPU オフロードなしで、モデルが読み込めることを確認する;
低めの -ngl を追加して、出力できることを確認する;
-ngl を少しずつ上げ、VRAM の限界点を探す;
-ngl を固定して、コンテキスト長を調整する;
コンテキストを固定して、batch をテストする;
同じ prompt で tok/s を比較する;
10〜20分ほど動かして安定性を見る;
最終パラメータを記録する。

毎回違う prompt で速度を測らないでください。prompt が違うと結果を比較しづらくなります。

固定のテスト用 prompt を用意しておくとよいです。

`1`	`請用 800 字解釋 MoE 模型為什麼適合低顯存推理，並給出三個注意事項。`

毎回同じ prompt を使うことで、本当に最適化が効いたか判断しやすくなります。

よくある失敗

低VRAMで大きなモデルを調整するとき、次の操作は時間を無駄にしがちです。

1. GPU オフロード層数をむやみに上げる

-ngl で速度が上がったので、そのまま上げ続けるケースです。

GTX 1060 のVRAMは 6GB しかありません。限界を超えると、プログラムがエラーで落ちるか、起動しても不安定になります。

2. 最初から超長コンテキストにする

長いコンテキストはメモリと KV cache に大きな負荷をかけます。短いコンテキストで安定させてから伸ばす方が現実的です。

3. 平均 tok/s だけを見る

tok/s は重要ですが、それだけでは足りません。

次も見てください。

最初の token までの遅延;
prompt 処理速度;
VRAM が溢れていないか;
長時間実行して安定しているか;
システム全体が重すぎないか。

4. パラメータを記録しない

ローカル推論の調整は何度も試す作業です。記録がないと、「さっき動いた設定は何だったか」をすぐ忘れます。

GTX 1060 に期待できること

GTX 1060 のような古いGPUは何に向いているでしょうか。

向いていること：

llama.cpp の学習;
GGUF モデルのテスト;
短いローカルQ&A;
ローカルモデルのパラメータ実験;
MoE モデルの低リソース実行の体験;
より良いハードウェアに載せる価値があるモデルかを検証する。

向いていないこと：

高並行サービス;
長文コンテキストの多用;
複数ユーザーの同時推論;
大規模 RAG の本番運用;
遅延に非常に敏感なリアルタイム用途。

GTX 1060 を実験機として見れば価値があります。本番用LLMサーバーとして見ると、期待外れになりやすいです。

一言まとめ

6GB VRAMで Qwen 35B のようなモデルを動かす本当のポイントは、「GPUに無理やり詰め込む」ことではありません。llama.cpp の GPU オフロード、MoE の特性、システムメモリ、コンテキスト長、batch パラメータをうまく合わせることです。

手元に GTX 1060 のような古いGPUがあるなら、次の順で試してみてください。

`1`	`まず動かす -> -ngl を調整 -> VRAM を見る -> コンテキストを抑える -> RAM を確認 -> batch を試す -> tok/s を記録する`

3 tok/s から 17 tok/s へ上げるのは魔法ではありません。ボトルネックを一つずつ分解していく作業です。

GTX 1060 on KnightLiブログ