Qwen3.6-27B-FP8 を自作 agent の worker として1日使いました。単発は約100 tok/s、2並列の合算は160〜180 tok/s、EAGLE の accept rate は0.8を超えました。体感では Qwen3-Coder-Next 80B より扱いやすかったものの、長期の品質比較はこれからです。

この結果をもとに、ロール別の LoRA worker を作る計画を立てています。

動画では、普段使う専用 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.py がありません。Qwen3_5ForConditionalGeneration に fallback し、Qwen3.6 の Gated Delta Networks（GDN）を正しく扱えず、最初の thinking から繰り返しが発生しました。

「weak weak 弱的 弱的 weakest」「atomic atomicAtomic atomicatomic」などを繰り返しました。engine は生成を続けますが、有効な回答にはなりません。

nightly-dev-cu13-20260424 に更新すると解消しました。この build は qwen3_6.py を含みます。

Blackwell では DeepGemm の scale_fmt 警告（not ue8m0）も出ます。checkpoint の scale が最適化パスと合っていないことを示します。観測した範囲では精度への実害は確認していません。

ロール別LoRAの計画

agent は、専用 system prompt、tool policy、期待する動作を持つロールに task を割り当てます。coder、reviewer、tester の違いを、prompt と LoRA の両方で扱う計画です。

実行ログと結果を構造化して保存し、ロール別 LoRA の学習サンプルに使います。judge の合否を DPO の候補データにする方針です。

4つのコアロールごとにデータを選び、専用 adapter を学習する計画です。SGLang の動的 LoRA load でリクエストごとに切り替えますが、切り替えコストは今回測っていません。

DPOデータの評価案

ローカルの MIT モデルを judge、外部 frontier モデルを一部の評価の校正に使う案です。一致した出力を SFT 候補にし、不一致では採用・不採用を比較して DPO pair を作る予定です。

adapter、出力、学習データを繰り返し改善する狙いです。改善効果は未検証です。

学習環境

27B の LoRA と小規模探索は96GB GPU 2枚で試す予定です。full-parameter fine-tuning は必要なメモリと時間が増えるため、まずローカルで確認し、必要なら cloud GPU に広げます。

学習は Axolotl、ログのデータセット化と評価の管理は Dagster を使う計画です。

モデルを選ぶ理由

推論容量。 FP8 の27Bで、KV cache、Mamba state、MTP weights を含めても96GBに収まります。4 worker 並列も候補ですが、今回の計測は2並列までです。

構造。 GDN の hybrid 構成で、tool call、多段階推論、コード生成を確認しました。LoRA はこれらをロールごとに調整するための案です。

ライセンス。 Apache 2.0です。商用を含む LLM導入で独自ツールや adapter を使う構成の候補になります。

今後の計画

次は4ロールの pipeline、小バッチ学習、base model との A/B 比較を行う予定です。結果に応じて cloud GPU の使用も検討します。

長期的には、実行データを継続して学習に回し、専門ロールの品質を改善する構想です。外部 API の価格と可用性への依存を減らす狙いがあります。

初期は Claude CLI subprocess（claude -p -r）を使いました。2026年4月の Anthropic の利用ガイダンス更新を受け、OSS モデル中心に切り替えています。

agent の改修と LoRA の継続作成、大きい学習への拡張は今後の作業です。