Qwen3.6-27B-FP8を自作エージェント実行基盤のワーカーとして1日運用した。第一印象はかなり良い。単発で約100 tok/s、2並列で合算160〜180 tok/s、EAGLEの投機的デコーディングでもaccept rateは0.8を安定して超える。体感ではQwen3-Coder-Next 80Bより扱いやすく、現時点でかなり有力な選択肢だ。

ただし、本題は推論速度そのものではない。面白いのは、このモデルをロール別にファインチューニングしたワーカーへどう発展させるかにある。

なお、動画撮影時は普段の運用で入れている専用のsystem promptを載せていなかった。そのため、生成結果の揺らぎが普段より大きく、何度か修正ループに入りやすい条件だった可能性がある。

動画リンク: https://www.youtube.com/watch?v=H5w4zBDmv2g

ベンチマーク結果

項目値
TG 単発安定~100 tok/s
TG 2並列合算160–180 tok/s
PP chunked (8k)4.0k–5.3k tok/s
EAGLE accept rate0.80–1.00
EAGLE accept len3.0–4.0
VRAM内訳weights 28.5GB + KV/Mamba 28.5GB + MTP 7GB

ハードウェア構成

項目スペック
GPUNVIDIA RTX PRO 6000 Blackwell Max-Q 96GB
CPUAMD EPYC 9175F
RAM768GB DDR5-6400
推論エンジンSGLang nightly (CUDA 13)

SGLang起動構成 

  SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN=1 \
SGLANG_ENABLE_SPEC_V2=1 \
sglang serve \
  --model-path Qwen/Qwen3.6-27B-FP8 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --speculative-algorithm EAGLE \
  --speculative-num-steps 3 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 4 \
  --mamba-scheduler-strategy extra_buffer \
  --page-size 64 \
  --mem-fraction-static 0.9 \
  --context-length 262144 \
  --served-model-name frisky

ハマりポイント: SGLangのバージョン差分

SGLang 0.5.10.post1にはQwen3.6のモデルクラス（qwen3_6.py）が存在しない。代わりにQwen3.5のコードパス（Qwen3_5ForConditionalGeneration）へフォールバックするため、Qwen3.6固有のGated Delta Networks（GDN）レイヤーが正しく処理されず、thinkingが初手から崩壊する。

症状としては、thinking出力が「weak weak 弱的 弱的 weakest」や「atomic atomicAtomic atomicatomic」のような無限ループに陥る。エンジン自体は正常にトークンを生成し続けるが、中身は完全に破綻している。

これはnightly-dev-cu13-20260424ビルドへ更新することで解消した。qwen3_6.pyが追加されており、GDNレイヤーが正しくハンドリングされる。

また、Blackwell GPU上ではDeepGemmのscale_fmt警告（not ue8m0）が出る。これはFP8チェックポイントのscale formatがBlackwellのDeepGemm最適化パスと互換性がないことを示しているが、現時点では精度劣化の実害は確認できていない。ここは継続監視が必要だ。

ロール別LoRAアダプタ戦略

自作エージェント実行基盤では、タスクをロールベースのタレントに割り振る。各タレントは専用のシステムプロンプト、ツールポリシー、期待される振る舞いを持つ。コーダーとレビュアーでは思考パターンが異なるし、レビュアーとテスターでも違う。同じモデルにプロンプトだけを変えて渡すだけでは、引き出せる性能に限界がある。

方針はシンプルで、運用データからロール別のLoRAアダプタを作る。日々の実行ログと結果を構造化して蓄積し、それを学習サンプルとして再利用する。ジャッジの合否判定は、DPOの自然なシグナルとして使える。

4つのコアロールそれぞれに専用アダプタを作り、ロールごとにフィルタしたデータで学習する。SGLangは動的なLoRAロードに対応しているので、リクエスト単位でアダプタを切り替えるコストはほぼゼロ。

DPOシグナルの生成

品質シグナルは2つのソースから得る。ローカルで動くMITライセンスのモデルがジャッジとして機能し、外部のフロンティアモデルがキャリブレーション用のサブセット評価を担う。両者が一致すれば強いSFT候補になる。不一致があればDPOペアを構成し、採用と不採用の対比のなかで弱い出力をrejected側へ置く。

このサイクルが自然なPDCAを形成する。良いアダプタがより良い出力を生み、より良い出力がよりクリーンな学習データを生み、それがさらに良いアダプタを作るのではと考えている。

学習環境

27BモデルのLoRA学習や小規模な探索は、手元の96GB GPU 2枚構成で十分に回せる見込みがある。一方で、full-parameter fine-tuningまで踏み込むならメモリも学習時間も重くなるので、まずはhomelabでロール別アダプタの当たりを付け、必要に応じてクラウドGPUでスケールさせる方針だ。

学習実行はAxolotl、運用ログからデータセット化と評価までのパイプライン管理はDagsterで進める。

このモデルを選ぶ3つの理由

推論コスト。 27Bパラメータで、しかもFP8量子化のため単一GPUに余裕を持って載る。KVキャッシュ、Mamba state、MTPウェイトを含めても96GBに収まる。4ワーカー並列も現実的だ。

アーキテクチャ。 Gated Delta Networksのハイブリッド構成により、ツール呼び出し、マルチステップ推論、コード生成がファインチューニングなしでもしっかり動く。アダプタは欠点を埋めるためというより、既に高い性能をロール単位で研磨するためのものだ。

ライセンス。 Apache 2.0。全出力、アダプタ、派生物が商用利用可能で、独自ツールを積み上げていく前提と相性がいい。

今後の計画

直近は4ロールのアダプタパイプラインを安定させ、ローカルで小バッチ学習を回し、ベースモデルとのA/B比較で検証する。良い結果が出たものから、必要に応じてクラウドGPUも使いながらスケールさせるつもりだ。

長期的なゴールは、運用ループが自分自身の学習データを継続的に生成する自己改善型エージェントシステムだ。モデルがそれぞれの専門ロールで時間とともに賢くなり、外部APIの可用性や価格変動に依存しない形へ持っていきたい。

もともとはClaude CLIのサブプロセス（claude -p -r）をベースにした構成で 開発を始めたが、今年の4月にAnthropicからの利用ガイダンスの更新を受けて、OSSモデル中心の構成へ切り替える判断をした。移行はそれなりに大変だったものの、ようやく実運用に乗せられる型が見えてきた。

まずは自作エージェントの構成をこの前提で組み替え、LoRAアダプタの量産と、必要な部分ではより大きな学習まで進めていきたい。