ファインチューニングのボトルネックはアルゴリズムではない

ファインチューニングのボトルネックはアルゴリズムではない

DeepSeek V4 Pro が公開されました → 今すぐ試す。

ブログ

ファインチューニングのボトルネック

ファインチューニングのボトルネックはアルゴリズムではない

公開日：2026年3月28日

目次

最終目的地は常にエージェント

毎回現れるボトルネック

統合とデータ主権

反復速度

仕事に適したツールを使う

管理から完全制御への階段

私たちの向かう先

今すぐファインチューニングを始める

チームは最新の訓練アルゴリズムを追いかけがちですが、実際のボトルネックは統合、反復速度、そしてSFT vs RFT vs DPOの使い分けです。

TL;DR：統合の摩擦と遅い反復サイクルがファインチューニングを実際に停滞させるボトルネックであり、アルゴリズムではありません。私たちは、さまざまなプロジェクトで見られるパターン、CursorやGensparkなどのチームがどのようにそれらを突破したか、そしてワークフローの将来（完全にエージェンティックなファインチューニングループ）を共有します。

ファインチューニングの支援を求めて私たちに来るほとんどのチームは、訓練アルゴリズムに苦労しているわけではありません。彼らはその周りのすべてに苦労しています：報酬関数を内部APIと連携させながらデータを漏洩させない方法、各ステップが異なるツールにあるために実験の間に何日も待つこと、そして問題がSFT、RFT、DPOのどれを必要とするかを判断すること。この1年間、最も革新的なスタートアップ、デジタルネイティブ企業、フォーチュン500企業との協力を通じて、これらのパターンがすべてのプロジェクトで繰り返されるのを見てきました。

最終目的地は常にエージェント

ファインチューニングの支援を求めるすべてのチームは、ドメイン固有のエージェントを構築しています。コード修正、カスタマーサポート、深層調査、金融業務 — ユースケースは異なりますが、形は同じです。汎用フロンティアモデルが品質の天井に達し、前進する道はモデルレベルのカスタマイズです。

天井は具体的です。Gensparkの深層調査エージェントは、クローズドフロンティアモデルで0.76の報酬スコアで行き詰まっていました。彼らはFireworksを介してオープンモデルでRFTに移行し、0.82を超えました — プロンプトエンジニアリングだけでは達成できない飛躍です。私たちが協力した大手デジタルネイティブ企業は、RFTでファインチューニングした後、タスク品質が30%向上し、レイテンシが2.5倍削減されました。プロンプトエンジニアリングには限界があり、新しい能力層に到達するにはファインチューニングが必要です。

単一のアカウント内で、エスカレーション検出から報酬モデリング、AI駆動の検索まで、すべて同時に実行されているユースケースが見られました。1つの組織内でのその幅広さは、ファインチューニングがエージェントシステムを構築するための継続的なインフラであり、一度行って終わりではないことを示しています。

エージェントの旅

すべてのチームは同じ弧を描きます：汎用モデルが品質の天井に達し、ファインチューニングがギャップを埋め、結果としてドメイン固有のエージェントが本番稼働します。

毎回現れるボトルネック

これらのプロジェクト全体で — 異なる業界、モデルサイズ、ユースケース — 同じ問題が繰り返し発生します。興味深いことに、それらのどれも訓練アルゴリズム自体に関するものではありません。すべてはその周囲に関するものです。

統合とデータ主権

最も一貫した障害は統合です。報酬関数、内部評価者、評価APIは顧客環境内に留まる必要があります。機密のビジネスロジックと専有データは、サードパーティのスコアリングのために外部に出ることはできません。

Fireworksはこれを2つのレベルで対処します。完全なデータ分離が必要なチームのために、Training APIを使用すると、データが環境から出ることなく訓練ループを実行できます — Pythonプロセスを制御し、データは自身の側に留まり、重み更新のみがプラットフォームを流れます。管理ファインチューニングのために、セキュアな持ち込みバケットストレージとリモート環境により、評価者が顧客のVPC内で実行されます。

あるチームは、コンプライアンスのために特定の非中国製オープンソースモデルに制限されていました。モデルの可用性と地政学的要件は、訓練アルゴリズムと同じくらいファインチューニングワークフローに影響を与えます。プラットフォームは幅広いベースモデルをサポートする必要があります。

データ主権アーキテクチャ

報酬関数、評価者、訓練データは顧客環境内に留まります。訓練プラットフォームは、データがVPCから出ることなく安全に接続します。

反復速度

訓練ジョブ自体がボトルネックになることはほとんどありません。サイクル時間が問題です。チームは訓練インフラのセットアップ、ノイズの多いデータセットのキュレーション、ジョブの実行に数週間を費やし、その後オフライン評価でモデルが品質にまだ達していないことを発見します。データを反復し、ハイパーパラメータを調整し、再訓練する頃には、さらに一週間が経過しています。実際のGPU時間は総サイクルのごく一部です。

最も速く動くチームは、そのギャップを数週間から数時間に縮めています。高頻度のジョブ提出、何が改善されたかに関する迅速なフィードバック、実験間の最小限の手動設定。あるチームは数週間で100以上のジョブを実行しました。別のチームは、ほぼ連続的な反復で数十のRFTジョブを提出しました。これらのペースはML実験というよりもCIパイプラインのように見えます。CursorとのComposer 2に関する協力は最も明確な例です — Fireworksは分散RL訓練インフラを支え、Composer 2がコーディングベンチマークでトップのフロンティアクローズドソースモデルを打ち負かすのに貢献し、密接な推論-訓練ループのおかげで約5時間ごとに新しいチェックポイントが出荷されました。

ファインチューニングとデプロイを単一プラットフォームに併置することがこれを可能にします。訓練されたLoRAアダプタは数分でデプロイされます — モデルのエクスポートも個別のサービングスタックも不要です。eval-protocol CLIはライブデプロイメントに対して評価を実行します。コスト見積もりツールにより、チームはGPU時間を費やす前に反復予算を計画できます。

ここには隠れた倍率もあります：ハイパーパラメータ最適化。訓練/テスト分割の規律、グリッドサーチ、学習率調整は、最終モデル品質に依然として大きな影響を与えます。エージェントを構築するほとんどの製品チームには、これを正しく行う専任のMLエンジニアがおらず、ずさんな実験設定はファインチューニングが「機能しない」最大の理由の1つです。これはツールが最も改善の余地がある分野の1つです — 実行間の評価メトリクスを監視し、自動的に訓練設定を調整するシステムを想像してみてください。MLの専門家が各実験を監視する必要はありません。私たちはまさにこれを構築しており、あなたが思うより近いです。

反復速度

出荷するチームと停滞するチームの違い：評価-訓練-デプロイサイクルを、断片化されたツールによる数日から、数時間で測定される緊密なループに縮めること。

仕事に適したツールを使う

最も速く反復するチームは、ファインチューニングを単一の技術として扱うのをやめました。単一のアカウント内で、同じ製品に対してSFT、RFT、DPOがすべて実行されているのを定期的に見かけます — 各メソッドは問題の異なる部分を対象としています。

メソッドの選択は問題に従い、その逆ではありません。高品質のデモデータと明確な出力形式がある場合はSFT — 蒸留、構造化抽出、スタイル変換。報酬信号が正しい出力よりも明確な場合はRFT — エージェントタスク、ツール使用、正しさのラベル付けが難しいが評価は簡単なもの（RFTの仕組み）。強い選好ペアがあり、報酬関数を書かずに行動を調整したい場合はDPO。

真の力は組み合わせにあります。よく見られるパターン：SFTでデモデータから強力なベースラインを蒸留し、次にRFTに切り替えてSFTだけでは捉えられないエージェント行動の品質を押し上げます。プラットフォームはこれを簡単にします。eval-protocolを使用すると、--warm-start-fromを使って以前のSFTアダプタから直接RFT実行をウォームスタートできるため、ファインチューニングされたPEFTチェックポイントが手動エクスポートなしで強化学習の開始点になります。より深い制御のために、Training APIは以前の訓練ジョブからジョブ境界を越えてチェックポイントをロードできます — SFT実行がRFT実行に流れ込み、完全なオプティマイザ状態が保持されます。

モデル選択も探索空間の一部です。チームが複数のスケールで同時に実験を実行しているのを見かけます — 高速反復のために1B未満、本番品質のために200B+ MoE、時には同じ週に両方。プラットフォームはメソッドとモデルの切り替えを摩擦なく行える必要があります。また、マルチモーダルユースケースのためのビジョンファインチューニングもサポートしています。

管理から完全制御への階段

一貫した成熟度パターンがあります。チームはほとんどの場合、管理ファインチューニングから始めます — APIを通じたSFT、DPO、またはRFT。これは正しい出発点です。インフラをクリティカルパスから取り除き、ファインチューニングが問題に有効であることを検証します。

その後、天井にぶつかります。深いドメイン適応、特に大規模MoEアーキテクチャでは、より多くの制御が必要です：カスタム損失関数、カスタムデータパイプライン、オプティマイザステップアクセス、LoRAでは到達できない全パラメータ更新。「管理で80%達成したが、残りの20%が必要」というギャップは、チームが停滞するか、スタックをゼロから再構築し始めるポイントです。

Training APIはそのギャップを埋めます。同じインフラ、同じデプロイターゲットですが、独自の訓練ループを持ち込めます。カスタムGRPO、DAPO、またはハイブリッド目的。200B+までのモデルに対する全パラメータ更新。ライブサービングチェックポイントを使用した推論インザループ評価。GPUクラスターをプロビジョニングする必要はありません。クイックスタートで数分で実行できます。

最も抽象度が高いところから始め、必要なときに下りる。重要なのは移行がシームレスであることです — より多くの制御を得るために再プラットフォーム化する必要はありません。

制御レベルの選択

完全管理ファインチューニングジョブから、レシピ風のSFT/DPO/GRPOワークフロー、カスタムPython訓練ループまで。すべて同じプラットフォームで。

私たちの向かう先

業界は手動ML実験からCI/CDスタイルのファインチューニングループへと移行しています — そして論理的な終点は自分自身で実行されるループです。

上記で説明した各ボトルネックは、手動である必要のない手動ステップです。統合に数週間のカスタムコネクタ作業を必要とするべきではありません — 訓練プラットフォームは顧客の評価インフラにネイティブに接続するべきです。反復は人間が再訓練のタイミングを決めることで停滞するべきではありません — プラットフォームは評価メトリクスを監視し、回帰を検出し、自動的に訓練実行を開始するべきです。そしてハイパーパラメータ調整は毎回ML専門家を必要とするべきではありません — システムは数千の過去実行から何が機能したかを観察し、収束しそうな設定を推奨するべきです。

これらを組み合わせると、それ自体がエージェンティックなファインチューニングワークフローが得られます。

評価から再訓練へのループが自動的に閉じます。システムはモデルが本番で何を間違えるかを観察し、適切な訓練方法を選択し、実行を設定し、保留データに対して結果を検証し、品質が向上した場合にデプロイします。人間は何が良いかを定義し、ガードレールを設定します。システムが残りを行います。

私たちが協力しているチームは、すでにこのループの断片を手動でつなぎ合わせています — 評価ダッシュボードを監視し、再訓練をトリガーし、デプロイをゲートするスクリプトを書いています。私たちはそのループを第一級のプリミティブにするインフラを構築しています。詳細は近日公開予定です。

エージェンティックファインチューニング

将来の状態：評価から再訓練へのループが自動的に閉じます。人間は目標とガードレールを設定し、システムは観察、訓練、検証、デプロイを処理します。

今すぐファインチューニングを始める

これに心当たりがあるなら、今すぐ始められます。

• 管理ファインチューニング — APIを通じたSFT、DPO、RFT。16B未満のモデルは無料でファインチューニング可能。ファインチューニングの概要から始めてください。

• より多くの制御が必要ですか？ — カスタム訓練ループ、全パラメータ更新、推論インザループ評価については、トレーニング製品の詳細についてお問い合わせください。

私たちは自動ハイパーパラメータ最適化、評価駆動の再訓練、エンドツーエンドでループを閉じるエージェンティックファインチューニングワークフローに取り組んでいます。早期アクセスを希望する場合、またはファインチューニングアーキテクチャについて話し合いたい場合は、お問い合わせページまたはDiscordからご連絡ください。