【レビュー】5年前の6GB VRAMノートPCでQwen3.6-35Bを33t/sで動かしたReddit投稿の分析と、M4 Macでの再現レポート
6GBのVRAMしかない5年前のノートPCで、35Bパラメータの大規模言語モデルを実用的な速度で動かす——一見不可能に思えるこの挑戦を、Redditユーザーabhinand05氏が実際にやってのけた。その投稿とブログ記事が非常に高いクオリティだったので、詳細に分析しつつ、実際にApple M4 Macでも再現してみた結果をレポートする。
投稿の概要
投稿者abhinand05氏は、ASUS ROG Zephyrus G14（2020年モデル）という5年前のゲーミングノートPCを使っている。スペックは以下の通り：
- CPU: Ryzen 7 4900HS（8コア16スレッド）
- メモリ: 24GB DDR4-3200
- GPU: RTX 2060 Max-Q 6GB VRAM
- モデル: Qwen3.6-35B-A3B（MoE、アクティブパラメータ約3B）
- 量子化: APEX-I-Compact（独自の適応型量子化）
- 達成速度: 22〜33 t/s（バッテリー駆動時でも10+ t/s）
35Bパラメータのモデルを6GB VRAMで動かすには、MoE（Mixture of Experts）アーキテクチャの性質を最大限に活用する必要がある。アクティブなパラメータがトークンあたり約3Bしかないため、VRAMに収まらない重みをCPU RAMにオフロードし、PCIe経由で逐次読み込む方式を取っている。
この投稿が優れている5つの理由
1. コピペ可能な完全な実行コマンド
投稿にはllama-serverの起動コマンドが全文掲載されており、単なる自慢で終わっていない。--cpu-rangeによるCPU affinityの設定、--numa isolateによるNUMA最適化、--prio 2によるプロセス優先度設定まで、細かいチューニングの跡が見える。
2. 通常構成とLong Context構成の分離
通常の32Kコンテキスト版に加えて、Tom’s fork（lm-server-tq）を使った128Kコンテキスト版も同時に公開。キャッシュにturbo3/turbo4という特殊な量子化を使う工夫も紹介されている。
3. 68回の自動実験による検証
ブログ記事では、異なる設定を自動で68回もループ実行し、最適な構成を探した結果「元の設定が最も良かった」という誠実な結論を出している。memeや誇張が多いこの分野では稀有な姿勢だ。
4. 制約に対する深い理解
単に「動いた」で終わらず、「なぜ動くのか」をアーキテクチャレベルで説明。「DDR4の読み取りがボトルネック」「PCIe帯域が速度の上限を決める」といった制約を正直に説明している点が信頼性を高めている。
5. コミュニティの建設的な反応
コメント欄では--fit offの是非（Danmoreng氏）や、speculative decodingの効果（OsmanthusBloom氏）など、建設的な技術的議論が交わされている。またEll2509氏が同様の構成で再現に成功しており、再現性が確認されている。
惜しい点
- –fit off の理由説明不足: コメントでも話題になっているが、なぜfitモードをオフにしているのかの説明がない
- Speculative decodingの検証不足: ngram-modによる投機的復号が実際に効果を発揮しているかのデータがない
- 文体: ブログの文体が「sloppily written」と評される通り、読みやすさに改善の余地がある
実機検証：Apple M4 Mac（24GB）で再現してみた
この投稿に触発されて、手持ちのMacBook Air（Apple M4, 24GB 統一メモリ）でも同じQwen3.6-35B-A3Bを動かしてみた。
環境
- マシン: MacBook Air (M4, 2025)
- メモリ: 24GB 統一メモリ
- フレームワーク: llama.cpp b9010（Homebrew + Metalバックエンド）
- モデル: Qwen3.6-35B-A3B-Q3_K_M（約15GB、bartowski版GGUF）
- 起動コマンド:
llama-server -m [model] -ngl 99 -fa on --ctx-size 8192 --no-warmup
結果
| 指標 | abhinand05氏（RTX 2060 6GB） | 本検証（M4 24GB） |
|---|---|---|
| プロンプト処理速度 | 非公開 | 45〜76 t/s |
| 生成速度（テキスト生成） | 22〜33 t/s | 28〜30 t/s |
| コンテキスト長 | 32K（標準）/ 128K（Tom’s fork） | 8K（今回） |
| 量子化 | APEX-I-Compact | Q3_K_M |
| モデルサイズ | 約16GB | 約15GB |
| メモリ使用量 | 6GB VRAM + CPU RAMオフロード | 統一メモリ約15GB |
考察
Apple Silicon（M4）の統一メモリアーキテクチャは、この種のMoEモデルと非常に相性が良い。元投稿がGPU⇄CPU間のPCIe転送に悩まされていたのに対し、Apple Siliconではモデル全体を高速な統一メモリに置けるため、オフロードのオーバーヘッドが原理的に発生しない。
実際、プロンプト処理では76 t/sと非常に高速で、生成速度も28〜30 t/sと元投稿の23 t/sを上回った。ただし今回はQ3_K_M量子化（15GB）を使用しており、APEX-I-Compact（16GB）とは量子化方式が異なるため、単純比較はできない。
なお、今回使用したGGUFではQwen3.6の推論モード（思考トークン）が強制有効になっており、テキスト生成のcontentが空になる問題が発生した。これはGGUFのバリエーションによって挙動が異なる可能性があり、今後の課題として残っている。
この投稿の価値
この投稿が特別なのは、「6GB VRAMのレガシーマシンでも35Bモデルが実用的速度で動く」という、多くの人が諦めていたユースケースに具体的なロードマップを提供した点にある。
示唆に富むポイント：
- MoE + 適切な量子化 + CPUオフロードにより、8GB未満のVRAMでも35BクラスのLLMが実用になる
- 2020年製のミドルレンジノートPCでも再現可能（コミュニティで確認済み）
- pi-agentとの組み合わせでエージェント用途にも使える
- AutoRound版Q2_K_MIXEDを使えば30+ t/sまで伸びる可能性（コメントより）
Apple Siliconユーザーにとっては、統一メモリのアドバンテージにより、より少ない手間で同等以上のパフォーマンスを得られる可能性が高い。llama.cpp + Qwen3.6-35B-A3Bの組み合わせは、MacでローカルLLMを試す有力な選択肢の一つと言える。
まとめ
localmaxxing（低予算ローカルLLM運用）の分野において、2026年5月時点で最も実用的で再現性の高いケーススタディの一つ。技術的に深く、コミュニティの改善提案も活発で、Redditらしい理想的な投稿だ。
この記事をきっかけに、手持ちのマシンでQwen3.6-35B-A3Bに挑戦してみてはいかがだろうか。きっと思っているよりずっと「動く」はずだ。
Photo by Daniil Komov from Pexels
