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
AIエージェントが事前定義されたツールなしでRemotionを使用して自律的に動画を作成
ある開発者が、AIエージェントをテストし、Remotionのインストール、コンポジションコードの記述、問題のデバッグ、人間の介入なしにレンダリングファイルを提供することで、短いビデオリールを自律的に作成しました。
OctoArch v5.0：JSONベースのAIペルソナを備えたゼロトラストB2Bランタイム
OctoArch v5.0は、財務/請求書抽出などの厳格な企業ユースケース向けに構築されたゼロトラストB2B認知ランタイムです。テキストベースのプロンプティングをJSON定義のAIペルソナに置き換え、サーバー攻撃を防ぐためのパス監禁を実装しています。
Claude TimeTrack: macOSメニューバーアプリで、Claude CodeのJSONLファイルを読み取り、プロジェクトごとの開発時間を自動追跡
オープンソースのmacOSメニューバーアプリ。Claude CodeのセッションJSONLファイルとgit履歴を解析し、プロジェクトごとの作業時間を自動追跡。手動タイマーは不要。
Sandbox0: AIエージェントのためのオープンソースKubernetesネイティブサンドボックスインフラストラクチャ
Sandbox0は、JuiceFSによる永続ストレージと自動スケーリングを備えたKubernetes上に構築された、AIエージェント向けのオープンソースサンドボックスインフラストラクチャです。既存ソリューションに見られる同時実行数の制限や一時的な実行といった課題に対応しています。