RTX 4070 12GBに収まらない35B級MoEをik_llama.cppとRAMで動かす

はじめに

LLMをローカルのGPUで動かすときに、VRAMの制約で上限が決まってきます。量子化をしてもRTX4070 の12GBVRAMではどうあがいても35Bモデルは乗せることができません。。。

しかし、ik_llama.cppを使うと、VRAMに収まらない35B級MoEのweightをGPUとCPUへ振り分け、RTX 4070 12GBでもロードして生成できます。

今回使うQwen3.6-35B-A3B Q4_K_Mは、GGUFだけで約20.76GiBあります。

先に算数をします。

モデル: 22,285,080,192 bytes（約20.76GiB）
VRAM:   12GB

入りません。

CUDAを信じても、算数までは曲げてくれません。

ここで使うのが、ik_llama.cppの自動配置、CPU MoE、tensor overrideです。モデル全体をVRAMへ詰め込むのではなく、一部のtensor、特にMoE expertをCPU RAMへ置きます。

つまり今回は、

12GB VRAMへ無理に全部載せる
        ↓
GPUへ置くweightとRAMへ置くweightを分ける
        ↓
35B級MoEをローカルPCで生成可能にする

という実験です。

そして「ロードできました」で終わらせず、VRAM、RAM、swap、4K・8K contextの成立境界まで確認します。

この記事で確認すること

今回の目的は、RTX 4070 12GBで35B級MoEを「無理やり全部VRAMへ載せる」ことではありません。

見たいのは次の3点です。

ik_llama.cppのfit、CPU MoE、tensor overrideで、VRAMに収まらないQwen3.6-35B-A3B Q4_K_Mをロード・生成できるか。
4K contextでVRAM、RAM、swapがどこまで増えるか。
8K contextまで広げたとき、どの配置が安全基準を満たすか。

つまり、この記事は速度勝負ではなく、12GB VRAMの上限をRAM併用で越えるときの成立条件を見ます。

「12GB VRAMに35Bを載せた」というより、正確にはik_llama.cppで載らない分をRAMへ逃がし、GPUに収まらないモデルを動かせるかを検証する記事です。

ik_llama.cppとは何か

ik_llama.cppは、llama.cppを基に、追加の量子化方式や推論最適化を実験しているforkです。

今回重要なのは、名前よりも次の配置機能です。

機能	できること	今回の使い方
`--fit`	使用可能なVRAMに合わせて自動配置する	35B級モデルを手軽に起動
`--cpu-moe`	MoE expertをCPU側へ置く	VRAMを約3.2GiBまで削減
`-ot`	正規表現でtensorの配置先を指定する	expert層16～39をCPUへ固定

llama.cppにもCPU/GPUハイブリッド配置機能はあります。そのため、「ik_llama.cppだけが大きなモデルを動かせる」という話ではありません。

ik_llama.cppの面白さは、MoEのexpertをどこへ置くか試しながら、VRAM容量を超えるモデルの成立条件を探れることです。

12GB GPUだから20GiB超のGGUFを諦めるのではなく、VRAMを高速な作業場所、RAMを大容量のweight置き場として使います。

今回の主役は、モデルをVRAMへ「載せる」ことではなく、計算に参加させながら、どこへ置くかを制御することです。

使用したモデル

本命はQwen3.6-35B-A3Bです。

公式モデルカードでは、総parameter数は35B、1 tokenあたりにactivateされるparameterは3Bとされています。MoEは全expertを毎回計算せず、入力に応じて一部だけを使うためです。

項目	値
Model	Qwen3.6-35B-A3B
Model type	MoE、35B total / 3B activated
Experts	256
Activated experts	8 routed + 1 shared
Quant	Q4_K_M
GGUF	`Qwen_Qwen3.6-35B-A3B-Q4_K_M.gguf`
GGUF size	22,285,080,192 bytes（約20.76GiB）
License	Apache-2.0
今回の入力	text only

GGUFはbartowski/Qwen_Qwen3.6-35B-A3B-GGUFのQ4_K_Mを使用しました。

ここで注意したいのは、3B activatedだから3Bモデルと同じメモリ量になるわけではないことです。

計算時に呼ばれるexpertは一部でも、使われる可能性のある全weightには置き場所が必要です。

Active 3Bと聞くと軽そうですが、待機中のexpertも家賃は払います。

ik_llama.cppでweightをGPUとRAMへ分ける

今回の配置を単純化すると、次のようになります。

Qwen3.6 GGUF
  ├─ attention、shared tensor、一部expert → GPU VRAM
  └─ 一部または全部のMoE expert         → CPU RAM

GPUへ置けるtensorには12GBという上限があります。CPU RAMを併用すればweightの保持先を広げられますが、RAM使用量とswapにも注意が必要です。

今回は次の3方式を試しました。

配置	内容	狙い
`fit`	backendによる自動配置	手軽にVRAM内へ収める
`manual`	expert層16～39をCPUへ固定	配置を再現可能にする
`CPU MoE`	MoE expertをCPUへ置く	VRAM使用量を抑える

検証環境

項目	値
GPU	NVIDIA GeForce RTX 4070 12GB
Compute capability	8.9
CPU	Intel Core i7-14700F、20 cores / 28 threads
RAM / Swap	32GiB nominal（OS認識31GiB）/ 8GiB
OS	Ubuntu 24.04.4 LTS
Kernel	6.17.0-29-generic
NVIDIA driver	580.126.20
CUDA toolkit	12.8 / V12.8.93
llama.cpp	`c34b92235b2d6a07963f896085f9ca077ff400b4`
ik_llama.cpp	`5f917a64b391b7d31839845153a473a65f630458`

GPUはデスクトップ表示にも使っています。環境確認時点で777MiBのVRAMを使用していたため、12,282MiBすべてを推論へ使える条件ではありません。

また、更新の速いプロジェクトなので、llama.cppとik_llama.cppはcommitを固定しました。「同じコマンド名なら半年後も同じ動作」とは限らない世界です。

ビルド

llama.cppとik_llama.cppを取得し、検証時のcommitへ固定します。

サンプルコード（ビルド）

mkdir -p vendor build

git clone https://github.com/ggml-org/llama.cpp.git vendor/llama.cpp
git -C vendor/llama.cpp checkout --detach \
  c34b92235b2d6a07963f896085f9ca077ff400b4

git clone https://github.com/ikawrakow/ik_llama.cpp.git vendor/ik_llama.cpp
git -C vendor/ik_llama.cpp checkout --detach \
  5f917a64b391b7d31839845153a473a65f630458

RTX 4070のcompute capability 8.9に合わせ、CUDA architectureを89へ固定してRelease buildします。

cmake \
  -S vendor/llama.cpp \
  -B build/llama.cpp-cuda-sm89 \
  -DCMAKE_BUILD_TYPE=Release \
  -DGGML_CUDA=ON \
  -DGGML_NATIVE=ON \
  -DCMAKE_CUDA_ARCHITECTURES=89 \
  -DLLAMA_BUILD_UI=OFF \
  -DLLAMA_USE_PREBUILT_UI=OFF

cmake --build build/llama.cpp-cuda-sm89 \
  --target llama-cli llama-server llama-bench \
  --parallel 8

cmake \
  -S vendor/ik_llama.cpp \
  -B build/ik_llama.cpp-cuda-sm89 \
  -DCMAKE_BUILD_TYPE=Release \
  -DGGML_CUDA=ON \
  -DGGML_NATIVE=ON \
  -DCMAKE_CUDA_ARCHITECTURES=89

cmake --build build/ik_llama.cpp-cuda-sm89 \
  --target llama-cli llama-server llama-bench llama-sweep-bench \
  --parallel 8

llama.cppはWeb UIを使わないため、次の2項目を無効化しています。

-DLLAMA_BUILD_UI=OFF
-DLLAMA_USE_PREBUILT_UI=OFF

ビルド後は、version、CUDA Runtimeへのリンク、CMake設定を確認します。

サンプルコード（ビルド確認）

build/llama.cpp-cuda-sm89/bin/llama-cli --version
build/ik_llama.cpp-cuda-sm89/bin/llama-cli --version

ldd build/llama.cpp-cuda-sm89/bin/llama-cli | grep libcudart
ldd build/ik_llama.cpp-cuda-sm89/bin/llama-cli | grep libcudart

grep -E \
  'GGML_CUDA:BOOL=ON|GGML_NATIVE:BOOL=ON|CMAKE_CUDA_ARCHITECTURES.*=89' \
  build/llama.cpp-cuda-sm89/CMakeCache.txt

grep -E \
  'GGML_CUDA:BOOL=ON|GGML_NATIVE:BOOL=ON|CMAKE_CUDA_ARCHITECTURES.*=89' \
  build/ik_llama.cpp-cuda-sm89/CMakeCache.txt

確認できたversionは次の通りです。

llama.cpp:    version 1 (c34b922)
ik_llama.cpp: version 1 (5f917a6)

この環境では、初回クリーンビルドに約13分かかりました。

モデル取得

Q4_K_M GGUFを取得し、ファイルサイズとSHA-256を検証します。

サンプルコード（モデル取得と検証）

MODEL_FILE="Qwen_Qwen3.6-35B-A3B-Q4_K_M.gguf"

curl -L --fail --retry 5 --retry-delay 5 --continue-at - \
  --output "${MODEL_FILE}.part" \
  https://huggingface.co/bartowski/Qwen_Qwen3.6-35B-A3B-GGUF/resolve/5c2410d71524f4f72b023ce8daf7a80528226d5f/Qwen_Qwen3.6-35B-A3B-Q4_K_M.gguf

mv "${MODEL_FILE}.part" "${MODEL_FILE}"

stat -c '%s bytes' "${MODEL_FILE}"
sha256sum "${MODEL_FILE}"

期待値:

22285080192 bytes
b46fedd33e0bfb0cae308aa3c158d0a4b2c4a1d2185a1ed6f093cdaf39064772

量子化ファイルだけで約20.76GiBあるため、ダウンロード前にストレージ容量も確認したほうがよいです。VRAMの話をしていたら、先にSSDが困ることもあります。

測定条件

モデルのロードだけでなく、短い日本語応答の生成、VRAM、RAM、swapを確認しました。

text only
context: 4096
生成上限: 128 tokens
temperature: 0
single request
MTPなし
mmprojなし
--mlockなし

確認項目は次の4点です。

モデルをロードできる
128 tokens以内の生成を完了できる
VRAM、RAM、swapを記録できる
安全弁を作動させず終了できる

測定中は500ms間隔でVRAMとシステムメモリを記録しました。

また、PC全体を巻き込むベンチマークにしないため、次の条件で停止します。

安全弁	閾値
試行開始後のswap増加	2,048MiB超
`MemAvailable`	1GiB未満
stdout	64MiB超
timeout	15分

PCがベンチの下へ隠れたくなる状況を避けます。

VRAM・RAM監視と安全停止の実装

記事だけで測定方法を再現できるよう、実験で使った監視処理を1本のshell scriptにまとめると次のようになります。

サンプルコード（VRAM・RAM監視と安全停止）

#!/usr/bin/env bash
set -euo pipefail

if [[ $# -lt 2 ]]; then
  echo "usage: $0 <run-name> <command...>" >&2
  exit 2
fi

run_name="$1"
shift
gpu_log="$(mktemp)"
memory_log="$(mktemp)"
stdout_log="$(mktemp)"
stderr_log="$(mktemp)"

initial_swap_used_kib="$(
  awk '
    /^SwapTotal:/ { total = $2 }
    /^SwapFree:/  { free = $2 }
    END { print total - free }
  ' /proc/meminfo
)"

nvidia-smi \
  --query-gpu=timestamp,name,memory.used,memory.free,utilization.gpu,temperature.gpu,power.draw \
  --format=csv \
  -lms 500 > "${gpu_log}" &
gpu_monitor_pid=$!

(
  printf 'timestamp_epoch,mem_total_kib,mem_available_kib,swap_total_kib,swap_free_kib\n'
  while true; do
    awk -v now="$(date +%s.%N)" '
      /^MemTotal:/     { total = $2 }
      /^MemAvailable:/ { available = $2 }
      /^SwapTotal:/    { swap_total = $2 }
      /^SwapFree:/     { swap_free = $2 }
      END {
        printf "%s,%s,%s,%s,%s\n",
          now, total, available, swap_total, swap_free
      }
    ' /proc/meminfo
    sleep 0.5
  done
) > "${memory_log}" &
memory_monitor_pid=$!

cleanup() {
  kill "${gpu_monitor_pid}" "${memory_monitor_pid}" 2>/dev/null || true
  wait "${gpu_monitor_pid}" "${memory_monitor_pid}" 2>/dev/null || true
}
trap cleanup EXIT INT TERM

# setsidで独立したprocess groupにし、安全弁作動時に子processもまとめて止める。
setsid timeout --signal=TERM --kill-after=30s 15m \
  "$@" \
  > "${stdout_log}" \
  2> "${stderr_log}" &
command_pid=$!

abort_reason=""

while kill -0 "${command_pid}" 2>/dev/null; do
  read -r mem_available_kib swap_used_kib < <(
    awk '
      /^MemAvailable:/ { available = $2 }
      /^SwapTotal:/    { total = $2 }
      /^SwapFree:/     { free = $2 }
      END { print available, total - free }
    ' /proc/meminfo
  )

  swap_growth_kib=$((swap_used_kib - initial_swap_used_kib))
  stdout_bytes="$(stat -c '%s' "${stdout_log}")"

  if (( mem_available_kib < 1024 * 1024 )); then
    abort_reason="MemAvailable below 1024 MiB"
  elif (( swap_growth_kib > 2048 * 1024 )); then
    abort_reason="swap growth exceeded 2048 MiB"
  elif (( stdout_bytes > 64 * 1024 * 1024 )); then
    abort_reason="stdout exceeded 64 MiB"
  fi

  if [[ -n "${abort_reason}" ]]; then
    printf '%s\n' "${abort_reason}" >&2
    kill -TERM -- "-${command_pid}" 2>/dev/null || true
    break
  fi

  sleep 0.5
done

set +e
wait "${command_pid}"
status=$?
set -e

exit "${status}"

この監視処理では、推論プロセスと同時にGPUメモリ、system memory、swapを取り、安全弁を超えた場合はプロセスグループごと停止します。

4K contextを各3回測定

fit、CPU MoE、manualの実行順による偏りを抑えるため、試行ごとに順番を入れ替えて各3回測定しました。

最初に固定promptを作ります。

サンプルコード（固定prompt）

PROMPT_FILE="smoke-ja.txt"

printf '%s\n' \
  '次の質問に日本語で簡潔に答えてください。' \
  'CPUとGPUを併用して大きな言語モデルを動かす利点を、一文で説明してください。' \
  > "${PROMPT_FILE}"

共通変数:

サンプルコード（共通変数）

IK_CLI="<ik_llama.cppのllama-cli>"
MODEL="<Qwen3.6-35B-A3B Q4_K_M GGUF>"
PROMPT="<固定prompt>"

fitはbackendへ自動配置を任せます。

サンプルコード（4K fit）

./measure.sh 4k-fit-1 \
  "${IK_CLI}" \
  -m "${MODEL}" \
  -f "${PROMPT}" \
  -c 4096 \
  -n 128 \
  --temp 0 \
  --no-display-prompt \
  --simple-io \
  --fit

CPU MoEはMoE expertをCPU側へ置きます。

サンプルコード（4K CPU MoE）

./measure.sh 4k-cpu-moe-1 \
  "${IK_CLI}" \
  -m "${MODEL}" \
  -f "${PROMPT}" \
  -c 4096 \
  -n 128 \
  --temp 0 \
  --no-display-prompt \
  --simple-io \
  --cpu-moe \
  -ngl 999

manualはexpert層16～39をCPU側へ固定します。

サンプルコード（4K manual）

./measure.sh 4k-manual-1 \
  "${IK_CLI}" \
  -m "${MODEL}" \
  -f "${PROMPT}" \
  -c 4096 \
  -n 128 \
  --temp 0 \
  --no-display-prompt \
  --simple-io \
  -ngl 999 \
  -ot 'blk[.](1[6-9]|[23][0-9])[.]ffn_.*_exps.*=CPU'

同じ3コマンドを各3回実行しました。実際には順序をfit → CPU MoE → manual、CPU MoE → manual → fit、manual → fit → CPU MoEと巡回させています。

4Kでは3方式ともロード・生成に成功

以下は各3試行の中央値です。

配置	完走	Peak VRAM	Peak system RAM	Swap増加
`fit`	3/3	10,673MiB	19,554MiB	0MiB
`manual`	3/3	10,662MiB	19,817MiB	0MiB
`CPU MoE`	3/3	3,251MiB	27,410MiB	0MiB

3構成すべて、4K contextでロードと生成に成功しました。

fitとmanualは約10.7GiBのVRAMを使用し、RAM使用量は約19～20GiBに収まりました。

一方、CPU MoEではPeak VRAMが3,251MiBまで下がりました。約7.4GiBのVRAMを空けられるため、画面表示や別のGPU処理と共存しやすくなります。

ただし、Peak system RAMは27,410MiBまで増えました。

VRAMから消えたweightは蒸発していません。RAMが食べています。

RAM 32GiB環境では成立しましたが、ブラウザ、IDE、Dockerなどを同時に動かすなら余裕は大きくありません。

8K contextまで広げる

4Kが成立したため、同じ128 token生成でcontextを8,192へ拡大しました。

サンプルコード（8K fit）

./measure.sh 8k-fit \
  "${IK_CLI}" \
  -m "${MODEL}" \
  -f "${PROMPT}" \
  -c 8192 \
  -n 128 \
  --temp 0 \
  --no-display-prompt \
  --simple-io \
  --fit

manualもcontext以外は同じ条件です。

サンプルコード（8K manual）

./measure.sh 8k-manual \
  "${IK_CLI}" \
  -m "${MODEL}" \
  -f "${PROMPT}" \
  -c 8192 \
  -n 128 \
  --temp 0 \
  --no-display-prompt \
  --simple-io \
  -ngl 999 \
  -ot 'blk[.](1[6-9]|[23][0-9])[.]ffn_.*_exps.*=CPU'

結果:

配置	Peak VRAM	Peak system RAM	Swap増加	判定
`fit`	10,822MiB	20,381MiB	0MiB	成立
`manual`	10,581MiB	15,344MiB	4,176MiB	安全基準外
`CPU MoE`	-	-	-	未実施

fitは8Kでも成立

fitはPeak VRAM 10,822MiB、Peak system RAM 20,381MiB、swap増加0MiBで生成を完了しました。

今回の32GiB RAM環境では、8Kで安全基準を満たしたのはfitでした。

manualは生成できたが、不成立と判定

manualもモデルロードと生成までは完了しました。

ただし、試行開始時からswapが4,176MiB増加し、設定した2,048MiBの安全上限を超えました。ログでは約11.16GiBのpinned host memory確保も確認しています。

表のPeak system RAMが15,344MiBと低く見えるのは、必要メモリが減ったからではありません。大量のページがswapへ退避した後の観測値なので、むしろ危険側です。

返事は返ってきました。PCの応答性も一緒に持っていかれました。

そのため、今回は次のように区別します。

計算可能: yes
32GiB RAMで安全に常用可能: no

CPU MoEの8K試験は、manual試験後に約3.7GiBのswap使用が残っていたため実施しませんでした。結果を増やすために、次の測定条件を壊しては意味がありません。

チャット形式でも正常に返るか

固定promptによる成立確認とは別に、OpenAI互換のchat endpointからリクエストしました。

サーバー起動:

サンプルコード（chat server起動）

"<ik_llama.cppのllama-server>" \
  -m "<Qwen3.6-35B-A3B Q4_K_M GGUF>" \
  -c 4096 \
  --fit \
  --fit-margin 1024 \
  --jinja \
  --reasoning off \
  --reasoning-budget 0 \
  --host 127.0.0.1 \
  --port 18080

別terminalからリクエスト:

サンプルコード（chat request）

curl -N http://127.0.0.1:18080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "local",
    "messages": [
      {
        "role": "user",
        "content": "次の質問に日本語で簡潔に答えてください。\nCPUとGPUを併用して大きな言語モデルを動かす利点を、一文で説明してください。"
      }
    ],
    "temperature": 0,
    "max_tokens": 128,
    "stream": true,
    "chat_template_kwargs": {
      "enable_thinking": false
    }
  }'

質問:

CPUとGPUを併用して大きな言語モデルを動かす利点を、
一文で説明してください。

応答:

CPUがモデルの制御や前処理を担いGPUが並列演算に特化することで、
リソースを最適に分散させ、推論速度の向上やメモリ効率の改善を実現します。

文字化け、反復、途中終了、user-facing出力へのthinking channel混入はありませんでした。

ここでは回答品質の優劣までは評価しません。「chat templateを通した通常の日本語応答が成立する」ことだけを確認しています。

成立条件と安全上の境界

ik_llama.cppを使えば35B級MoEを12GB GPUで動かせますが、RAM容量まで無視できるわけではありません。

特に8K manualは回答生成まで完了しています。しかし、swapが4GiB以上増えたため、常用可能とは判定していません。

ローカルLLMでは、次の2つは別です。

出力が返った
安定して使える

また、CLIの会話モードや長いsynthetic promptでは、入力待ちの反復や配置条件の変化も起きました。そのため、用途ごとに測定方法を分けています。

確認内容	使用方法
4K / 8Kの成立性	監視付き短文生成
通常のチャット出力	`llama-server`のchat endpoint
VRAM、RAM、swap	`nvidia-smi`と`/proc/meminfo`

つまり、ik_llama.cppが広げるのは「VRAMだけで決まっていたモデル選択の上限」です。その代わり、RAM容量、swap、配置方法が新しい制約になります。

まとめ

今回の実測で伝えたいことは、次の3点です。

ik_llama.cppを使うと、12GB VRAMに収まらない35B級MoEをGPUとRAMへ分割して動かせる。
4Kではfit、manual、CPU MoEが各3/3でロードと生成を完了した。fitとmanualはPeak VRAM約10.7GiB、CPU MoEはPeak VRAM約3.2GiB、Peak RAM約27.4GiBだった。
8Kではfitがswap増加なしで成立した。manualは生成できたがswapが4,176MiB増加し、32GiB RAM環境の安全基準では不成立と判定した。

つまり、RTX 4070 12GBでも35B級MoEは動きます。

ただし勝負はVRAM容量だけではありません。

- 何をVRAMへ置くか
- 何をRAMへ逃がすか
- RAMとswapにどこまで余裕があるか
- contextをどこまで伸ばすか

で成立条件が変わります。

ik_llama.cppはVRAMを増やす魔法ではありません。

しかし、VRAMだけでは選べなかったモデルを、RAMとの分担で動作候補にするための道具にはなりました。

参考