Fine-Tuning — モデルを自分の仕事に合わせる

これは何か

Fine-Tuning(ファインチューニング、以下「学習」)は、汎用のベースモデルに自分のデータを学習させて、フォーマット・トーン・ツールの使い方・エッジケースへの対応をプロンプト指示に頼らず身につけさせる機能だ。コンソールではapp.fireworks.ai/dashboard/fine-tuningから学習ジョブの作成・監視ができる。学習データセットは第10章で扱ったのと同じ Datasets 機能を使うので、データセットの作成・アップロード手順が曖昧なら先にそちらを確認してほしい。

学習には3つの「面」(surface)がある。Managed TrainingはFireworksがスケジューリング・学習・チェックポイント保存まで全部面倒を見る標準ジョブで、Fireworks UI・firectl(FireworksのCLI)・REST APIのどれからでも同じジョブを作れる。もう一段上に、学習ループそのものをPythonで自分で書くTraining APIがある。Serverless Training API(共有プールでLoRAのみ、トークン課金。2026-09時点でprivate preview、アクセス申請が必要)とDedicated Training API(専有GPUでLoRA+フルパラメータ、GPU時間課金)の2種類があり、これはPython SDK経由でしか触れない。Managed TrainingとTraining APIの両方を横断して触れるインターフェースは、コーディングエージェント向けの Agent Skill だけだ(UI・firectl・RESTはmanaged専用、Python SDKはTraining API専用)。本章は初心者が最初に触るManaged Trainingに絞り、Training APIは「こういう上級者向けの面がある」という位置づけだけ押さえる。

いつ使うのか

学習が効くのは、①プロンプトで頑張ってきた分類・抽出・書式遵守をモデル自体に覚えさせて品質を上げたいとき、②長いシステムプロンプトやfew-shot例を毎回送るコストをやめて小さく安いモデルに置き換えたいとき、③スタイル・親切さ・安全性のように「唯一の正解」が無い挙動を望ましい方向に寄せたいとき、④正解ラベルは無いが良し悪しは判定できるタスク(推論・エージェント系)でモデルを最先端より先に伸ばしたいとき、の4つだ。ただしどれも「まずプロンプト・few-shot・RAGで解けないかを試し、それでも足りない」場合の話であり、学習は最初の一手ではない。

どの手法を使うかは、次の節で説明する通り「手元のデータの形」で決まる。逆に「その手法の代わりに何を検討すべきか」も手法ごとに違うので、次節の表の「代わりに検討すべきとき」列を判断材料にしてほしい(多くは別の学習手法への切り替えだが、RFTの行のように「まずシンプルな手法をまだ試していない」に戻るものもある)。

手法を選ぶ — データの形で決める

Fireworksの学習ドキュメントが最初に置いている問いは「どのモデルを学習するか」ではなく「手元のデータはどんな形をしているか」だ。検証済みの正解ペアがあるならSFT、2つの応答のどちらが良いか比較できるならDPO/ORPO、正解は無いが良し悪しを判定できる評価器を用意できるならRFT、という順で決まる。この判断フローを先に固めてから、その手法に対応するベースモデルを選ぶのが正しい順序になる。

RFTの対応モデル数はSFT/DPOの倍以上ある(85対32/32、2026-09時点)。たとえばqwen3-4bはmanagedカタログ上RFTのみに対応し、SFT・DPOでは学習できない。こうしたRFT専用モデルが多数あるため、「このモデルを学習したい」から入ると行き止まりになりやすい。「このデータならこの手法」で入ると、対応モデルの探し方に迷わなくなる。DPOとORPOは同じpreferenceデータセットを共有できるが、DPOは参照モデルと比較する方式、ORPOは別の参照モデルを持たず教師あり目的とpreference目的を統合する方式だ。データセットのスキーマも手法ごとに別物で、SFTはmessages配列をトップレベルに置くのに対し、DPO/ORPOはinput(messagesを含む)・preferred_output・non_preferred_outputの3フィールド構成になる。SFTの学習データはOpenAI互換のchat completion形式なので、既存のOpenAI SFTデータセットは無変換でそのまま使える。

LoRAの仕組みとハイパーパラメータ

Managed Trainingの標準はLoRA(Low-Rank Adaptation)で、本ガイドもLoRAを前提に進める。ベースモデルの重みは完全に凍結したまま、そこに小さな「差分アダプタ」を追加で学習する方式だ。フルパラメータ学習(重み全体を更新する方式)については、firectlの--full-parameterフラグや料金表のFull Param列が存在する一方、概念ページ・UIはManaged TrainingをLoRA専用と記しており、公式ドキュメント内で記載が食い違っている。フルパラメータが必要な場合は、docsの最新を確認するか、上級者向けのTraining APIを検討するのが安全だ。

LoRA rankは、このA・Bがどれだけ多くの情報を捉えられるかを決めるパラメータで、2の冪乗で最大32まで設定できる(既定値は8、2026-09時点。Fireworksで学習する場合の値。外部で学習したLoRAをアップロードするときの許容範囲は別で、第9章を参照)。ハイパーパラメータは基本的にすべて任意設定で、まともな既定値が付いている。公式も「品質に効くepochsとlearning_rateは、まず既定のまま試し、結果が明確に必要性を示したときだけ変える」姿勢を推奨している。

特にMax context lengthは見落としやすい。SFTガイドは学習例が既定で32,768トークンのところで打ち切られると明記している一方、firectlのコマンドリファレンスは未指定時に検証済みtraining shapeの最大コンテキスト長が既定になると書いており、記述が割れている(2026-09時点)。長い会話を含むデータセットを使うなら、いずれの解釈でも安全なように--max-context-lengthを明示するのが安全だ。

学習ジョブのライフサイクルと料金

Managed Trainingのジョブは、データセットのアップロードから始まり、学習完了後にLoRAアダプタ(チェックポイント。学習途中・完了時点の重みの保存物)を生成し、それを評価用の一時デプロイで試してから、問題なければ本番用のデプロイに昇格させる、という流れをたどる。

SFT・DPOの学習料金はトークン単価で決まり、ベースモデルの規模ごとに4段階に分かれている(2026-09時点)。

「学習トークン数」は「データセットのトークン数 × epoch数」が基本の見積もり方だが、そのまま鵜呑みにできない補正が2つある。ひとつは中間の思考トレース(reasoning_content)を含めて学習するとき、平均会話ターン数 ÷ 2を掛けて見積もる必要がある点。もうひとつは、モデルによっては1行の会話データが複数の学習datum(モデルに1件として渡される学習単位)に「unroll」され、その結果チューニング対象トークン数が生データセットのトークン数を上回りうる点だ。thinking-historyのモード(Interleaved/Preserved)がモデルごとに違い、ほとんどのモデルは既定がInterleavedでuser発話の境界ごとにunrollする。reasoning_contentを含むデータセットで学習コストを見積もるときは、この上振れを織り込んでおくとよい。

一方RFTはトークン課金ではなくGPU時間課金(秒単位)で、Fireworksのon-demandデプロイと同じ単価が適用される。2026-09時点の時間単価はH100/H200が$8.00、B200が$13.00、B300が$15.00、GB300が$20.00。ロールアウト(学習中にモデルが実際に生成してみる1回の試行)推論・学習時間・候補数・応答長によって総額が変わり、無料枠は前提にできない。

RFTのループ — プロンプトと評価器から学ぶ

RFT(Reinforcement Fine-Tuning)はSFTと発想が逆だ。SFTは「良い出力の正解例」を渡すのに対し、RFTは「プロンプト」と、モデルの出力を0〜1でスコアする「評価器(evaluator、報酬関数)」を渡す。学習はそのスコアを最大化する方向に出力を反復改善していく。

「verifiable」(検証可能)とは、ルール・単体テスト・プログラム的チェックでモデル出力の良否を確実に判定できることを指す。RFTは正解ラベルを書きにくい推論・エージェント系のタスクに向いている。評価器は登録前に、満点・部分点・0点・不正形式出力・エッジケースをローカルで試し、小さなプローブでスコアが偏らない(non-flat)ことを確認しておくべきだ。RFTの細かい起動フラグ・既定値はドキュメント本文ではなくFireworksが提供するtraining skill(コーディングエージェント向け)に外出しされており、公式ドキュメント自体は経路選択とクイックスタートまでしか持たない。

学習済みモデルの配信 — on-demandデプロイのみ

学習が終わった後の配信先は一択だ。Fireworks製・外部インポート問わず、学習済みLoRAはon-demand(専有)デプロイにしか置けない。Serverless上での配信は提供されていない。評価用に使うpreemptibleデプロイ(idle状態の予約GPUを間借りする方式で、いつでも回収されうる)を本番トラフィックに使ってはいけないのは、これとは別の理由からだ。リクエストの途中でも予告なく回収されうるため、本番の可用性を保証できない。

本番配信の方式は2通りある。

1つのモデルだけを配信するなら、公式もlive mergeを推奨している(この場合modelフィールドはモデル名をそのまま指定するだけでよい)。multi-LoRAデプロイ上の特定アダプタへルーティングするときは、modelフィールドに<モデル名>#<デプロイ名>形式で#区切りを指定する。以前使われていたdeployedModelリクエストキーは非推奨で、新規デプロイでは使えない。

ハンズオン

firectl model get -a fireworks llama-v3p1-8b-instruct

{"messages": [{"role": "system", "content": "あなたはFireworksの使い方に詳しいアシスタントです。"}, {"role": "user", "content": "LoRA rankの既定値は?"}, {"role": "assistant", "content": "既定値は8です。2の冪乗で最大32まで設定できます。"}]}
{"messages": [{"role": "user", "content": "学習例のトークン長の上限はどう指定しますか?"}, {"role": "assistant", "content": "--max-context-lengthで明示します。既定の扱いは公式ドキュメント内で記述が割れているため、長いデータでは明示指定が安全です。"}]}
{"messages": [{"role": "user", "content": "学習済みLoRAはServerlessで配信できますか?"}, {"role": "assistant", "content": "できません。on-demandデプロイのみが対応しています。"}]}

firectl dataset create sa-support-qa ./sa-support-qa.jsonl
firectl dataset get sa-support-qa

firectl sftj create \
  --base-model accounts/fireworks/models/llama-v3p1-8b-instruct \
  --dataset sa-support-qa \
  --output-model sa-support-lora

firectl sftj get <job-id>
firectl model list

firectl deployment-shape-version list --base-model accounts/your-account/models/sa-support-lora

firectl deployment create accounts/your-account/models/sa-support-lora \
  --deployment-id sa-support-lora-eval \
  --display-name sa-support-lora-eval \
  --deployment-shape <DEPLOYMENT_SHAPE> \
  --min-replica-count 1 \
  --max-replica-count 1 \
  --preemptible

curl https://api.fireworks.ai/inference/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $FIREWORKS_API_KEY" \
  -d '{
    "model": "accounts/your-account/models/sa-support-lora",
    "messages": [{"role": "user", "content": "LoRA rankの既定値は?"}]
  }'

firectl deployment delete sa-support-lora-eval -a your-account

git clone https://github.com/eval-protocol/quickstart-gsm8k.git
cd quickstart-gsm8k
pip install -r requirements.txt

mkdir -p gsm8k_artifacts/tests/pytest/gsm8k
mkdir -p gsm8k_artifacts/development
cp evaluation.py gsm8k_artifacts/tests/pytest/gsm8k/test_pytest_math_example.py
cp gsm8k_sample.jsonl gsm8k_artifacts/development/gsm8k_sample.jsonl

cd quickstart-gsm8k
ep logs

cd gsm8k_artifacts
ep local-test

export FIREWORKS_API_KEY="your-fireworks-key"
cd ..
eval-protocol create rft \
  --base-model accounts/fireworks/models/qwen3-4b

つまずきポイント

理解度チェック

まとめ

• 学習手法はモデルではなくデータの形で選ぶ。正解ペア→SFT、比較ペア→DPO/ORPO、判定基準のみ→RFT(managed対応はRFT 85・SFT/DPOそれぞれ32モデル)。
• Managed Trainingの標準はLoRA(本ガイドもLoRA前提)。フルパラメータの扱いは公式docs内で記載が食い違うため、必要ならdocs最新かTraining APIを確認する。
• ハイパーパラメータ(epoch・LoRA rank・batch size・context長・learning rate)はまず既定値のまま使う。
• 学習GPUクォータは支払いティア次第で、未登録アカウントは全ティア0。429/403は設定ではなくティアの問題として切り分ける。
• 学習済みLoRAの配信はon-demandのみ。live merge(単一モデル向け)とmulti-LoRA(複数バリアントの実験向け)を用途で使い分ける。

次章(第12章)では、この章で学習したモデルの出来をどう測るか、Evaluationsの仕組みを扱う。

参考リンク

• Training Overview
• Managed Training Overview
• Supervised Fine-Tuning - Text
• Preference Optimization with DPO or ORPO
• Reinforcement Fine-Tuning
• Single-Turn Training Quickstart(GSM8K)
• Deploying Trained Models
• Models(学習可能ベースモデルのカタログ)
• Fireworks AI Pricing
• LoRA: Low-Rank Adaptation of Large Language Models