4台のGPUで235Bモデルをファインチューニング：失敗したデプロイからの教訓

Vertexcoverのエンジニアチームは、4台のH100 GPUを搭載した単一のマシンで2350億パラメータを持つQwen3モデルのファインチューニングに成功し、有料APIモデルと比較して大幅な精度向上を達成しました。技術的な成功とトークンあたりのコスト削減にもかかわらず、新しいオープンソースモデルの登場により複雑なインフラが不要になったため、チームはこのソリューションのデプロイを見送りました。

何が起きたか

チームは、顧客ドキュメント内のエンティティ分類で使用していた高価なOpenAIおよびGeminiのファインチューニング済みモデルを置き換えることを目指していました。初期ベンチマークテストで他のオープンモデルを上回ったため、Mixture of Experts（MoE）モデルであるQwen3-235B-A22B-Thinkingを選択しました。目標は、自社ホストのハードウェアを通じてコストを管理しつつ、精度を維持または向上させることでした。

約3,600件の例題に対する1エポックの訓練後、ファインチューニングされたモデルはすべてのテナントにおいて平均F1スコアを7.6ポイント改善しました。また、トークンあたりのコストを従来のAPIベースのソリューションの約3分の1に削減しました。訓練プロセスには、それぞれ80 GBのメモリを搭載したNVIDIA H100 GPU 4台を使用し、26時間かかりました。

これらのポジティブな指標にもかかわらず、プロジェクトは保留となりました。チームは、低遅延かつ合理的な運用コストで235B思考モデルを提供することが、ファインチューニングそのものよりも大きなエンジニアリング上の課題であることを発見しました。同時に、ファインチューニングなしで多くの分類タスクを処理できる新しいオープンソースモデルが登場し、カスタムインフラの必要性がなくなりました。

仕組み

Qwen3-235BはMoEモデルであり、任意のトークンに対してアクティブになるのは2350億パラメータのうち約220億のみです。各層には128個の小さなエキスパートネットワークが含まれており、ルーターがトークンを最も関連性の高いエキスパートへ振り分けます。このアーキテクチャにより、同規模の密な（dense）モデルと比較して推論の計算コストを抑えられますが、読み込みや訓練時のメモリ管理が複雑になります。

チームはモデルのファインチューニングにQLoRA（Quantized Low-Rank Adaptation）を使用しました。この手法では、ベースモデルを4ビット精度に圧縮し、メモリフットプリントを470 GBから約120 GBに削減します。その後、凍結されたベース重みの上に小さなアダプター層を訓練します。課題となるのは、圧縮ライブラリとシャーディングライブラリの調整であり、これらはモデル重みのメモリ内での保存およびアクセス方法について相反する要件を持っています。

成功する訓練には、CPUオフロード機能を備えたDeepSpeed ZeRO-3が必要でした。この設定により、120 GBの圧縮モデルの完全なコピーをGPUメモリではなくシステムRAMに保持しました。訓練中、レイヤーは必要に応じてRAMからGPUへ移動され、個々のメモリ制限にもかかわらず4台のH100がワークロードを処理できるようにしました。このアプローチは速度と実現可能性のトレードオフとなり、結果として26時間の訓練時間がかかりました。

主要な詳細

• モデルはすべてのテナントでF1スコアを改善し、+4.81から+11.96ポイントの向上が見られました。
• Qwen3は「思考」モデルであるため、推理トレースを含む3,600件の例題を使用して訓練が行われました。
• それぞれ80 GBのメモリを搭載したH100 GPU 4台と、960 GBのシステムRAMが必要でした。
• Axolotl、Unsloth、Answer.AIのFSDP+QLoRA実装は、メモリまたは互換性の問題により失敗しました。
• LlamaFactoryと標準的なFSDPの組み合わせは、Transformersが量子化中にメモリ節約設定をサイレントに無効化したため失敗しました。
• 最終的に機能したセットアップは、メモリ管理のためにLlamaFactoryとDeepSpeed ZeRO-3およびCPUオフロードを使用しました。

なぜ重要なのか

このケースは、限られたハードウェアで巨大なMoEモデルをファインチューニングすることに伴う隠れた複雑さを浮き彫りにしています。エンジニアはしばしば、量子化とシャーディングによって大規模モデルが利用可能なGPUメモリにシームレスに収まると想定しますが、ライブラリの非互換性やメモリ順序の問題により訓練が開始できないことがあります。1000億パラメータを超えるモデル向けのインフラを計画するには、これらの低レベルな制約を理解することが不可欠です。

また、これは技術的な能力が常にデプロイを正当化するわけではないという警告でもあります。235Bモデルの推論最適化にかかる労力は、特にベースモデルがすでに強力である場合、ファインチューニングによる利得を上回ることがあります。チームは、訓練精度だけでなく、提供遅延やハードウェア要件を含めた総所有コスト（TCO）を評価する必要があります。

最後に、オープンソース開発の急速なペースにより、今日の難しいエンジニアリング問題は明日のモデルリリースによって解決される可能性があります。汎用モデルがそのままタスクを処理できるほど十分に改善した場合、カスタムのファインチューニングパイプラインに数週間投資することはサンクコスト（埋没費用）のリスクを伴います。戦略的な忍耐が、即時のカスタマイズよりも良い結果をもたらすこともあります。

あなたができること

• ベースパフォーマンスが大きく異なるため、ファインチューニングにコミットする前に複数のオープンモデルをベンチマークしてください。
• 特に量子化とシャーディングの順序に関して、MoEモデルのライブラリ互換性を確認してください。
• 圧縮されたフルモデルに対してGPUメモリが不足している場合、CPUオフロード用に十分なシステムRAMを確保してください。
• 量子化プロセス中にメモリ管理設定がサイレントに変更されていないか、Transformersの設定を監視してください。
• 訓練の精度とコストだけでなく、推論コストと遅延要件も早期に評価してください。
• 新しいベースモデルがカスタマイズなしで性能ギャップを解消する可能性があるため、ファインチューニングの必要性を定期的に再評価してください。