Qwen 3.6 27B量子化ベンチマーク：実用的トレードオフでQ4_K_MがQ8_0を凌駕
Redditユーザーが、Qwen 3.6 27Bの3つのGGUF量子化バリアント（BF16、Q4_K_M、Q8_0）を、Neo AI Engineerフレームワークを介してllama-cpp-pythonでベンチマークしました。評価は3つのタスク（HumanEval：コード生成、164サンプル、HellaSwag：常識推論、100サンプル、BFCL：関数呼び出し、400サンプル）の合計664サンプルをカバーしています。
ベンチマーク結果
- BF16（モデルサイズ53.8 GB、ピークRAM 54 GB、スループット15.5 tok/s）：HumanEval 56.10%（92/164）、HellaSwag 90.00%（90/100）、BFCL 63.25%（253/400）。平均精度：69.78%。
- Q4_K_M（16.8 GB、28 GB RAM、22.5 tok/s）：HumanEval 50.61%（83/164）、HellaSwag 86.00%（86/100）、BFCL 63.00%（252/400）。平均：66.54%。
- Q8_0（28.6 GB、42 GB RAM、18.0 tok/s）：HumanEval 52.44%（86/164）、HellaSwag 83.00%（83/100）、BFCL 63.00%（252/400）。平均：66.15%。
主な考察
Q4_K_Mは卓越した実用的バリアントです。BFCLの精度を維持し（63.00% vs 63.25%）、HumanEvalでは約5.5ポイント、HellaSwagではBF16より約4ポイント低いだけです。トレードオフは、BF16より1.45倍高速、ピークRAMを48%削減、ファイルサイズ68.8%削減、関数呼び出し性能はほぼ同じです。Q8_0は期待外れで、HumanEvalでQ4_K_Mより約1.8ポイント向上したものの、RAMを28 GBではなく42 GB使用し、速度が遅く、HellaSwagでは低スコアでした。
ローカル/CPUデプロイでは、ワークロードがコード生成に重点を置いている場合を除き、Q4_K_Mをお勧めします。最大品質を求めるなら、BF16が依然として優位です。
評価設定
GGUFバリアントはllama-cpp-python経由で、n_ctx: 32768、チェックポイント付き評価を使用。Neo AI EngineerフレームワークがGGUF評価パイプラインを構築し、チェックポイント実行を処理し、結果を統合しました。コードスニペットを含む完全なケーススタディは、元のRedditコメントにリンクされています。
📖 全文ソースはこちら： r/LocalLLaMA
👀 See Also
オープンソースのClaudeスキルが、B2B SaaSの成長ナレッジを構造化し、一貫したAI推論を実現
ある開発者が、複雑なワークフローでClaudeを使用する際の一般的な問題である、整理されていないコンテキストが一般的な回答を引き起こすという課題に対処するClaude Skillをオープンソース化しました。この解決策は、Claudeが一貫して参照できる形式に知識を構造化することにあります。
Blip MCPサーバー：UI変更を説明する代わりにClaudeコードで描画する
Blipは、Claude Code用のMCPサーバーで、UI変更の口頭での説明を視覚的な注釈に置き換えます。実行中のアプリケーションに直接描画し、Claudeが注釈付きスクリーンショットに基づいて対応するコードを記述します。
audio-analyzer-rs: Claude 用の音声分析 MCP サーバー
開発者がaudio-analyzer-rsを構築しました。これはRustで実装されたMCPサーバーで、Claudeがスペクトル分析、倍音分析、リズム分析、LUFSラウドネス（EBU R128準拠）、ダイナミックレンジ測定などの音声ファイル分析機能に直接アクセスできるようにします。このツールはトークン効率が良く、Claudeは低解像度で分析を開始し、必要に応じて小さなチャンクにズームインします。
Pretticlaw: OpenClawよりも軽量でセットアップが高速な代替品
Pretticlawは、OpenClawの軽量な代替品で、セットアップに必要なコマンドはわずか2つ、30MBの容量で動作し、2〜3秒で応答し、ポート6767に組み込みダッシュボードを備えています。