10. ファインチューニングの選択肢！モデル、インフラ、フレームワークを理解しよう

モデルをファインチューニングすることを決めました。素晴らしい！でも、ちょっと待ってください。実際にどうやって始めればいいんでしょうか？

いくつかの大きな決定があなたを待っています。

API経由でフロンティアモデルをファインチューニングするか、完全に制御できるオープンウェイトモデルをファインチューニングするか？

ローカルまたはクラウドでトレーニングを実行するか？

そして最後に、カスタムコードを書くか、管理フレームワークを使用してプロセスをオーケストレーションするか？

これらは、マイナーなセットアップの詳細ではありません。それらは、あなたがどれだけの制御、透明性、スケーラビリティを持つかを決定します。

このレッスンでは、ファインチューニングにおける3つの主要な決定レイヤーを説明します。モデルアクセス、計算環境、そしてオーケストレーションアプローチです。

各選択がワークフローと結果にどのように影響するかをカバーします。そして次のレッスンでは、ベンチマークとリーダーボードを使用して、ファインチューニングする実際のベースモデルを選択する方法を学びますよ。

決定レイヤー1：モデルアクセス — フロンティアまたはオープンウェイト

最初の質問は、どの種類のモデルをファインチューニングしているかです。

フロンティアモデル（APIベース）

GPT-4、Claude、Geminiなどのフロンティアモデルは、プロバイダーのAPIを通じてファインチューニングされます。

データセット（通常はJSONL形式）をアップロードし、プロバイダーがバックグラウンドでモデルを再トレーニングします。モデルの重みを見たり、処理したりすることはありません。

シンプルでスケーラブルです。データを送信し、ファインチューニングされたエンドポイントを取得し、API呼び出しを開始します。

でもトレードオフがある

しかし、トレードオフがあります。

モデルアーキテクチャを検査または変更できません。

ファインチューニングプロセスを再現または監査できません。

リクエストごとに支払い、しばしばより高いレートで。

週3では、OpenAI Fine-Tuning、Gemini Studio、Anthropic Consoleなどの管理サービスを通じて、フロンティアモデルをAPIで直接ファインチューニングする方法を見ていきます。

オープンウェイトモデル（完全制御）

オープンウェイトモデル、LLaMA 3、Mistral、Phi-3、Qwen、DeepSeekは、ダウンロード可能でカスタマイズ可能です。

ローカルまたはレンタルGPUでトレーニングし、アーキテクチャを変更し、好きな方法で結果を評価できます。

この自由は責任をもたらします。計算の管理、実験の追跡、再現性の確保です。

しかし、透明性と独立性も可能にし、この認定プログラムがモジュール1と2を通じてオープンウェイトファインチューニングに焦点を当てる理由なんです。

決定レイヤー2：計算環境 — ローカルまたはクラウド

モデルタイプを選択したら、次の決定は、トレーニングがどこで実行されるかです。

同じコードが環境全体で機能します。独自のハードウェアで実行するか、他の場所でGPUをレンタルするかを決めるだけです。

ローカルトレーニング

ローカルで実行するということは、独自のワークステーションまたは内部サーバーでトレーニングすることを意味します。実験と小規模モデルに最適です。

メリットは、完全な制御とプライバシー、迅速な反復サイクルです。

デメリットは、限られたGPU容量です。

週2では、Google Colabを使用してオープンウェイトモデルをインタラクティブにファインチューニングするこのセットアップを実践的に探ります。

クラウドトレーニング

ローカルGPUが追いつかない場合、クラウドに移動します。

AWS EC2、RunPod、Vast.ai、Paperspace、Google Colab Pro+などのプラットフォームは、オンデマンドでスケーラブルなGPUリソースを提供します。

ここでキーポイント。同じHugging Faceトレーニングスクリプトを実行しています。ただしリモートハードウェアでね。

この柔軟性により、ローカルで小規模に開始し、シームレスにスケールアップできます。

このプログラム全体、特にモジュール2では、AWS SageMakerなどの管理クラウドSDKを活用して、大規模な分散トレーニング、監視、デプロイメントを学びます。

決定レイヤー3：オーケストレーション — カスタムコードまたは管理フレームワーク

モデルと計算セットアップを選択した後でも、ファインチューニングをどのようにオーケストレーションするかという質問があります。

カスタムコードアプローチ

ここでは、Transformers、Datasets、PEFT、TRL、Accelerateなどの基礎的なライブラリと直接作業します。

LoRAパラメータと学習率からチェックポイントと評価ロジックまで、すべての側面を制御します。

例えば、こんな感じです。

from transformers import AutoTokenizer, AutoModelForCausalLM
from trl import SFTTrainer
from peft import LoraConfig

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-2-7b-hf")
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf")

lora_config = LoraConfig(
 r=16,
 lora_alpha=32,
 target_modules=["q_proj", "v_proj"],
 lora_dropout=0.1,
)

trainer = SFTTrainer(
 model=model,
 train_dataset=my_dataset,
 peft_config=lora_config,
 max_seq_length=2048,
)

このパスは、研究と実験に最適です。細かい制御が必要な場合、または新しい技術が登場した瞬間に統合する必要がある場合です。

例えば、週3で探索するQLoRAまたはアダプター融合ですね。

管理フレームワークアプローチ

管理フレームワークは、オーケストレーションを抽象化して、データと設定に焦点を当てることができます。

YAMLファイルまたはシンプルなSDK呼び出しを定義します。プラットフォームがセットアップ、スケーリング、ロギングを管理します。

人気のあるオプションには、Axolotl、AWS SageMaker、Together.aiがあります。

例えば、Axolotl設定はこんな感じです。

base_model: meta-llama/Llama-2-7b-hf
datasets:
 - path: ./support_data.jsonl
 type: completion

adapter: lora
lora_r: 32
lora_alpha: 16
sequence_len: 2048
micro_batch_size: 2
num_epochs: 3

このアプローチは、エンタープライズまたは本番ワークフローに最適です。一貫した結果と自動スケーリングが必要な場合ですね。

週3ではAxolotl、週5ではBedrockを使った実践的な経験を得て、週6でこれらのモデルを評価して最適化する方法を学びます。

ワークフローに適したものを選択する

各決定、モデルアクセス、計算セットアップ、オーケストレーション、がワークフロー、コスト、長期的な柔軟性を形作ります。

多くのチームはハイブリッドアプローチを使用します。ローカルで実験し、クラウドGPUでスケールし、管理サービスを通じてデプロイします。

完璧な答えはありません。状況に応じて最適な選択は変わります。

重要なのは、各選択肢の特徴を理解して、自分のニーズに合ったものを選べることなんです。

次のステップ

ファインチューニング決定の3つのレイヤーを理解しました。アクセスできるモデルの種類、それが実行される場所、そしてそれがどのようにオーケストレーションされるか。

次のレッスンでは、LLMベンチマークとリーダーボードを使用してベースモデルを賢く選択する方法を学びます。

週6でファインチューニングされたパフォーマンスを評価し始めると、このスキルが重要になりますよ。

ファインチューニングの旅のための基盤を築きました。次は、構築するための適切な基盤を選択することです。

一歩ずつ、着実に進んでいきましょう。LLMエンジニアとしてのスキルは、こうした選択を重ねることで磨かれていくんです。

さあ、実践的な学習の旅を続けましょう！