QwenおよびGemmaにおけるエージェンティックLLM推論パラメータの参照
エージェント型LLMのチューニングに関する参照資料
このページは、エージェント型LLM推論チューニングの実用的なリファレンス（temperature、top_p、top_k、ペナルティ、およびマルチステップやツール多用なワークフローにおけるそれらの相互作用）です。
より広範なLLMパフォーマンスエンジニアリングハブと併せて参照し、明確なLLMホスティングとサービングの概要と組み合わせることで、モデルがリソース不足に陥った際にはスループットとスケジューリングが依然として支配的ですが、不安定なサンプリングはGPUが処理を終える前にリトライと出力トークンを消費してしまうことがわかります。
このページでは以下をまとめます：
- ベンダー推奨パラメータ
- GGUFおよびAPIに組み込まれたデフォルト値
- 実世界のコミュニティの知見
- エージェント型ワークフローの最適化
現在、以下に焦点を当てています：
- Qwen 3.6（DenseおよびMoE）
- Gemma 4（DenseおよびMoE）
OpenCodeなどのターミナルエージェントを使用している場合は、このリファレンスをOpenCodeにおけるローカルLLMの動作と組み合わせて使用し、ワークロードレベルの結果とサンプリングデフォルト値が整合するよう調整してください。
目標はシンプルです：
エージェントループ、コーディング、およびマルチステップ推論用のモデル設定を一元管理する。
TLDR リファレンステーブル - すべてのモデル（エージェント用デフォルト）
| モデル | モード | temp | top_p | top_k | presence_penalty |
|---|---|---|---|---|---|
| Qwen 3.5 27B | 推論・一般 | 1.0 | 0.95 | 20 | 0.0 |
| Qwen 3.5 27B | コーディング | 0.6 | 0.95 | 20 | 0.0 |
| Qwen 3.5 35B MoE | 推論 | 1.0 | 0.95 | 20 | 1.5 |
| Qwen 3.5 35B MoE | コーディング | 0.6 | 0.95 | 20 | 0.0 |
| Gemma 4 31B | 一般 | 1.0 | 0.95 | 64 | 0.0 |
| Gemma 4 31B | コーディング | 1.2 | 0.95 | 65 | 0.0 |
| Gemma 4 26B MoE | 一般 | 1.0 | 0.95 | 64 | 0.0 |
| Gemma 4 26B MoE | コーディング | 1.2 | 0.95 | 65 | 0.0 |
「エージェント型推論」とは何か
多くのパラメータガイドは以下を前提としています：
- チャット
- シングルスロット完了
- 人間の対話
エージェントシステムはこれらとは異なります。
エージェントシステムには以下が求められます：
- マルチステップ推論
- ツール呼び出し
- 一貫した出力
- エラー伝播の最小化
これにより、チューニングの優先順位が変化します。
核心的な変化
| 使用ケース | 優先事項 |
|---|---|
| チャット | 自然言語の品質 |
| 創造的 | 多様性 |
| エージェント | 一貫性 + 推論の安定性 |
Qwen 3.6 のチューニング
DenseとMoEの違いは重要
Qwenは以下の点で唯一のモデルファミリーの一つです：
MoEは異なるペナルティを必要とする
Dense (27B)
- 安定
- 予測可能
- ルーティングの複雑さなし
推奨設定：
- presence_penalty = 0.0
MoE (35B-A3B)
- トークンごとのエキスパートルーティング
- 反復ループのリスク
推奨設定：
- presence_penalty = 1.5（一般用途）
- コーディングの場合は 0.0
なぜこれが重要か
MoEモデルは同じエキスパートを再利用し続けてしまうことがあります。
Presence penaltyは以下に役立ちます：
- トークンパスの多様化
- 推論探索の改善
Qwenのエージェント型コーディング設定
ここが多くの人が間違えるところです。
正しい設定
- temperature = 0.6
- top_p = 0.95
- top_k = 20
- presence_penalty = 0.0
なぜ低い温度が有効なのか
コーディングエージェントには以下が必要です：
- 決定論的な出力
- 再現可能なツール呼び出し
- 安定したフォーマット
温度が高いと：
- JSONが壊れる
- ハルシネーション（幻覚）によるAPIが導入される
- リトライが増加する
Gemma 4 のチューニング
Gemmaは異なる挙動を示します。
公式デフォルトの欠如
- モデルカードは空欄
- 設定は暗黙的
- 実用的なチューニングは以下から得られる：
- Google AI Studio
- GGUFデフォルト
- コミュニティベンチマーク
直感に反する発見
Gemma 4は高い温度でより良いパフォーマンスを発揮します。
観察された挙動
| 温度 | 結果 |
|---|---|
| 0.5 | 推論性能の低下 |
| 1.0 | 安定したベースライン |
| 1.2 to 1.5 | 最良のコーディングパフォーマンス |
これは一般的なアドバイスに反します。
なぜここで高い温度が有効なのか
仮説：
- 学習分布は探索を優先する
- 推論モードは多様性に依存する
- モデルは明示的なChain-of-Thought制御の欠如を補償する
結果：
高い温度は解決策の探索空間を改善する
Gemmaのエージェント型コーディング設定
推奨設定：
- temperature = 1.2
- top_p = 0.95
- top_k = 65
- penalties = 0.0
重要
従来の「コードには低い温度」のルールを盲目的に適用しないでください。
Gemmaは例外です。
推論モードとエージェントシステム
QwenとGemmaの両方が推論モードをサポートしています。
なぜこれが重要か
エージェントループには以下が必要です：
- 中間推論
- エラーリカバリ
- マルチステップ計画
実用的なルール
以下の場合は常に推論モードを有効にしてください：
- コーディングエージェント
- ツールの使用
- マルチステップタスク
使用ケースによるパラメータ戦略
コーディングエージェント
- 決定論性を優先
- ペナルティを最小化
- 安定したサンプリング
推論エージェント
- 中程度の温度
- 探索を許容
- 構造を保持
ツール呼び出し
- 厳格なフォーマット
- 低ランダム性
- 一貫したトークンパターン
スキーマとJSONツールはロジットとは独立しており、これらのサンプリングルールをOllamaとQwen3用構造化出力パターンと組み合わせることで、バリデーターがより少ないリトライで済むようになります。
ベンダーデフォルト vs 現実
ベンダーデフォルトは：
- 安全
- 汎用的
- 最適化されていない
コミュニティの知見はしばしば以下を示します：
- より良いパフォーマンス
- タスク固有のチューニング
- アーキテクチャを意識した調整
例
Gemma：
- 公式：ガイダンスなし
- コミュニティ：高い温度がコーディングを改善
Qwen：
- 公式：一貫性のないセクション
- コミュニティ：標準化された値が収束
実用的なデプロイメントノート
並行処理下では、キューイングとメモリ分割はサンプリングと同様にリトライと相互作用します—上記のプリセットと併せてOllamaが並列リクエストを処理する方法を参照してください。
Ollama
- 両方のファミリーで良好に動作
- GPU互換性を確認
- デフォルトはリファレンスと異なる場合あり
vLLM
- 高度なサンプリングをサポート
- 本番環境で安定
- 明示的なパラメータを使用
llama.cpp
- サンプリングの順序付けが必要
- モダンなモデルには常にjinjaを有効化
- 誤ったサンプリングチェーンは出力品質を低下させる
主な取りまとめ
- 普遍的なパラメータセットは存在しない
- アーキテクチャがモデルサイズよりも重要
- エージェントシステムはチャットとは異なるチューニングを必要とする
- コミュニティベンチマークはしばしばベンダーより先行している
最終的な意見
多くのパラメータガイドは時代遅れです。
それらは以下を前提としています：
- チャット利用
- コードには低い温度
- 静的な構成
モダンなモデルはこれらの前提を破ります。
エージェントシステムを構築している場合：
推論チューニングをファーストクラスのシステム設計問題として扱え
単なる設定ファイルではない。
今後の方向性
このリファレンスは以下へと発展していきます：
- モデル別の深掘り
- エージェント固有の設定
- ベンチマークに裏打ちされたチューニング
なぜなら：
推論こそがモデルの能力をシステムパフォーマンスに変える場所だから
