8GB VRAM + 32GB RAMでQwen3.6-35B-A3Bを~190kコンテキストで実行 – セットアップとベンチマーク

Redditユーザーが、8GB VRAM(RTX 4060)と32GB DDR5 RAMを搭載したノートPCで、Qwen3.6-35B-A3B GGUFモデルを約190kコンテキストで実行する詳細な設定を投稿。デフォルトで37~43tok/sを報告し、調整により約51tok/sまで向上。
ハードウェアとモデル
- GPU: RTX 4060 8GB VRAM
- RAM: 32GB DDR5 5600MHz
- OS: Linux(Windowsよりパフォーマンスが良いとされる)
- テスト済みモデル(Q5量子化):
mudler/Qwen3.6-35B-A3B-APEX-GGUF– 約40tok/sから37tok/shesamation/Qwen3.6-35B-A3B-Claude-4.6-Opus-Reasoning-Distilled-GGUF– 約43tok/sから37tok/s
主要な設定
TurboQuantをサポートするllama.cppのフォーク(turboquant_plus)を使用し、ユーザーは以下のフラグでllama-serverを実行:
--model "<path>" \
--host 0.0.0.0 \
--port 8085 \
--ctx-size 192640 \
--n-gpu-layers 430 \
--n-cpu-moe 35 \
--cache-type-k "turbo4" \
--cache-type-v "turbo4" \
--flash-attn on \
--batch-size 2048 \
--parallel 1 \
--no-mmap \
--mlock \
--ubatch-size 512 \
--threads 6 \
--cont-batching \
--timeout 300 \
--temp 0.2 \
--top-p 0.95 \
--min-p 0.05 \
--top-k 20 \
--metrics \
--chat-template-kwargs '{"preserve_thinking": true}'
速度を約51tok/sに引き上げるには、3つのフラグを調整:--ctx-size 192640、--n-gpu-layers 430、--n-cpu-moe 35(安定性/メモリに応じて微調整)。
注意点
- Q4量子化は、長コンテキストの推論においてQ5に比べて明らかに劣る。
--no-mmap+--mlockで、スタッタリングによる速度低下を軽減。- TurboQuant KVキャッシュは、高コンテキストサイズで重要。
- 高速なRAM帯域幅(DDR5)は、これらの速度に重要。
- このワークロードでは、LinuxがWindowsを大幅に上回る。
対象ユーザー
コンシューマー向けハードウェア(特に8~12GB VRAMと高速システムRAM)で、非常に長いコンテキスト(17万トークン以上)のローカルLLMを実行する開発者向け。
📖 原文を読む: r/LocalLLaMA
👀 See Also

ローカルLLMとクラウドLLMの一貫したベンチマーク手法
開発者が、llama.cpp、vLLM、Ollamaなどのローカルモデルと、GPT-5.4、Claude Sonnet 4.6、Gemini 3.1 ProなどのクラウドAPIを、ZenMuxのような統一エンドポイントを通じて比較するために、順次リクエストとルールベースのスコアリングを使用した測定セットアップを共有しています。

Javaパフォーマンス最適化:コードを遅くする8つのアンチパターン
Javaの注文処理アプリケーションが、Java Flight Recordingプロファイリングで特定された8つの一般的なアンチパターンを修正することで、経過時間を1,198msから239msに、1秒あたりの注文処理数を85,000件から419,000件に、ヒープ使用量を1GBから139MBに改善しました。

クラウドAPIまたはローカルモデルを使用して無料でOpenClawエージェントを実行する方法
詳細なガイドでは、OpenRouter、Gemini、Groqの無料クラウドティアを利用するか、Ollamaでローカルモデルを実行することで、OpenClawエージェントを完全無料で運用する方法を解説しています。一般的な落とし穴を避けるための具体的な設定のコツも紹介されています。

タイトル:バグハント:GKEにおけるWireGuardクラッシュとMTU不一致
Lovableのエンジニアたちは、ユーザーエラーを調査したところ、GoogleのWireGuard統合における同時マップアクセスのパニックによるanetdのクラッシュを特定し、その後に暗号化を無効にした後の二次的なMTU不一致を発見しました。