GeminiはSFTで精度64%→80%に改善、QwenのLoRAは横ばい — モデルによってはGPU不要なLLMファインチューニングの実態レポート

7月20日、Amir Davidoffが「Supervised fine-tuning of Gemini 3.5 Flash and Qwen on Agent Platform」と題した記事を公開した。Google CloudのAgent Platform上でGemini 3.5 FlashおよびQwen 3 32BをSFT（教師あり微調整）する方法を紹介しつつ、同一データで試した結果「Geminiは大幅に改善、Qwenはほぼ横ばい」という率直な比較レポートになっている。

最大の見どころ：Geminiの精度が64%→80%に向上、だがQwenは横ばい

この記事の核心は「ファインチューニングは万能ではない」という事実の提示にある。

著者はScale AIが公開するツール選択ベンチマーク「MCP Atlas」を題材に、同一データで2モデルをチューニングした結果を比較している。なお、MCPとはModel Context Protocolの略で、LLMが外部ツールやデータソースを呼び出す際のインターフェース規格だ。MCP Atlasはそのツール選択能力を測るベンチマークとして公開されている。

Gemini 3.5 Flash（SFT）：ベース精度64% → チューニング後**80%**に向上
Qwen 3 32B（LoRA）：ベース精度48% → チューニング後**47〜51%**とほぼ変化なし

Qwenが伸びなかった理由として、著者は以下の3点を挙げている。

カタストロフィック・フォーゲッティング（破滅的忘却）：ファインチューニングによって新しいタスクを学習する際、モデルが以前に獲得した汎用的な能力を失ってしまう現象。強い汎用モデルを狭いフォーマットに押し込もうとすると、獲得する能力と失う能力が相殺される。LoRAはベースの重みを凍結するため影響は軽減されるが、アダプターとモデルの既存のプリオール（事前分布）との綱引きは残る。
小データでのLoRAアンダーフィッティング：32Bパラメータのモデルに対してランク16のアダプターを50〜400サンプル程度で更新しても、ツール選択の習慣を上書きするシグナルとして不十分な可能性がある。
メトリクスとの不一致：評価スコアは「正解と完全一致するツール名かどうか」で判定する。モデルが「合理的だが別のツール」を選ぶ傾向を持つなら、フォーマットを整えるだけのLoRAでは上限に達せない。

著者は「オープンモデルが劣るのではなく、チューニング手法（フルSFT vs. 小さなLoRAアダプター）、ベースモデルの出発点、メトリクスが訓練した行動を正しく反映しているかどうか、この3つの組み合わせで結果が変わる」と結論づけている。

GPUを自前で用意しなくていい（モデルによる）

記事のもう一つのポイントは、ファインチューニングの実行環境だ。モデルによってインフラ要件が大きく異なる点が実務上の重要な差異となっている。

Gemini 3.5 Flashのチューニングはサーバーレスで完結する。google-genai SDKでジョブを投げると、マネージドエンドポイントが返ってくる。価格はベースモデルと同一で、インフラの調達は不要。SFTとはSupervised Fine-Tuning（教師あり微調整）の略で、正解付きの入出力ペアを使ってモデルの重みを直接更新する手法だ。コードは10行程度で済む：

from google import genai
from google.genai import types

client = genai.Client(vertexai=True, project="my-project", location="us-central1")
job = client.tunings.tune(
    base_model="gemini-3.5-flash",
    training_dataset=types.TuningDataset(gcs_uri="gs://my-bucket/train.jsonl"),
    config=types.CreateTuningJobConfig(
        tuned_model_display_name="gemini-sft-demo-v1",
        epoch_count=3,
    ),
)
# job.stateがSUCCEEDEDになるまでポーリングし、job.tuned_modelで推論

一方、Qwen 3 32B（LoRA）のチューニングはVertex AI SDKで行えるものの、チューニング後のモデルはエンドポイントなしのModel Registryアーティファクトとして返ってくる。推論にはGPUを備えたエンドポイントへの手動デプロイが必要で、記事ではNVIDIA RTX PRO 6000搭載マシン（g4-standard-48）を使用している。LoRAとはLow-Rank Adaptationの略で、モデルの重み全体を更新するのではなく、少数のパラメータからなる軽量アダプターのみを学習する手法だ。全パラメータを更新するSFTに比べ計算コストを抑えられる一方、今回の結果が示すように効果に限界が出るケースもある。評価が終わったらendpoint.undeploy_all()でGPU課金を止める設計だ。

from vertexai.tuning import SourceModel, sft

job = sft.train(
    source_model=SourceModel(base_model="qwen/qwen3@qwen3-32b"),
    train_dataset="gs://my-bucket/train.jsonl",
    tuning_mode="PEFT_ADAPTER",  # LoRA
    adapter_size=16,
    epochs=3,
)

データフォーマットと評価設計

学習データはJSONL形式で、1行1会話。ツール選択タスクの場合、ユーザーのリクエストと利用可能なツール一覧をユーザーターン、正解のツール呼び出しをモデルターンとして記述する。

評価は「最初に呼び出すツール名が正解と完全一致するか」という決定論的なスコアリングを採用している。公式のMCP Atlasベンチマークは36のMCPサーバーと複数ターンのツール呼び出し、LLMジャッジによる採点という重い構成だが、著者はコストと再現性を優先してシンプルな第一手のツール名一致に絞った。

ファインチューニングを始める前のチェックリスト

記事では、チューニングに入る前のプロセスとして以下を挙げている。

評価パイプラインを先に作る：モデルを切り替えて比較できる状態にすること。これがなければ今回のような「片方だけ改善した」事実を検出できない。
学習目的と手法を決める：SFT / RL / DPOのどれを使うか。レスポンスのフォーマット改善なのか、精度向上なのか、新しい知識の注入なのかによって選択が変わる。
ユーザーシグナルを収集する：サムズアップ/ダウン、回答の承認操作、「2つの回答からベストを選ぶ」といった信号が、独自モデルの"堀"になる。

記事に添付されているノートブック sftgeminidemo.ipynb を使えば、データ準備からチューニング、評価まで一通り再現できる。

詳細はSupervised fine-tuning of Gemini 3.5 Flash and Qwen on Agent Platformを参照していただきたい。