無印/mini/nanoぢゃなくなったのね
本日何気なくAI FoundryのAzure OpenAI Servicesに触れてみると、GPT-5.6が触れるようになってました。コンテキストサイズは1Mまでいけそうで、クォータサイズも初期値はいずれのモデルも2MTokになってました。あらまぁいいのかしら?+ (o゚・∀・) + ワクワクテカテカ +とか思いながら触れてみましたよ。

以前までこの手のモデルは Pro/無印/mini/nano の順に小さくなっていってましたが、今回は何やらかっこいい名前が。
- 元無印→Sol(Solar:太陽かな?)
- 元mini→Terra(Terra:地球)
- 元nano→Luna(Luna:月)
ってことで、その天体サイズに例えてラインナップされてるようでした。まだSolは触れてませんで、今回はTerraを使っています。金額的には、
- gpt-5.6-sol ⇒ gpt-5.5と同等のコスト
- gpt-5.6-terra ⇒ gpt-5.4と同等のコスト
- gpt-5.6-luna ⇒ gpt-5.4-miniと同等のコスト
って感じですかね?とりあえずは。
ちょうど現在、お仕事でファインチューニングのスクリプト書いたり、その説明を書いたりしているところで、その調べものに使ってみたんですが、んまぁその回答の長さに驚いた。そのうち一つを例として挙げてみます。
今回の使い方と感想
DifyのAgentアプリを使いました。ツールはGithub, Context-7, Google Search, Microsoft Docsを一通りMCP連携で与えていて、論文系データもナレッジに食わせた状態で、それを活用させるような指示命令を加えて実行させています。
今まで恒例的に Reasoning_effective=High, Verbosity=High 設定で出力したんですけど、とりあえず言えるのは・・・・な、なげぇよ・・・でした。あまりに長すぎるので、ちょっとそのやり取りは末尾に乗せることにしますです。
出力しているトークン量ですが、まさかまさかの 105,955 トークン。えぐいす。7ターンほどやり取りしてましたけど、ちょっとガクブルしそうなレベルのトークン出力量ですね。はい。ちょっとverbパラメータはmediumぐらいにしたほうがよさそうです。次ぐらいのやり取りでおそらく1MToks到達なんで、累積したら「これ何ドルかかるんや?」レベルにはなりそうに見えますね。
それでも学びなおしにはとてもいい感じの情報がそろってたんでものすごく役に立ちました。はい。エージェントとしてのツールの使い方についても、Context-7から情報を拾ってきて、それをベースにGithubやGoogleSearchから情報を並行して拾ってきてたりするので、そういうところはさすがAPI型だなって気がします。応答速度もびっくりするほど速かったし。
今年、せめて何回かはガチでファインチューニングをやりたい。
会社員勤め当時からそうだったんですが、一度推論エンジンを立ち上げてしまうと、サービス障害を気にしてなかなか学習処理ができなくなるんですね。以前からそういうリソースの壁的なものがあって、何度も学びなおしができずにいた中で、今回久々にLoRA使ったチューニングなんぞをやっておりますです。GRPOはQuickStart的なものをやって以来全く何もできずにいたので、今回はちゃんと学びなおしたいなーと思って必死こいて取り組んでます。はい。
引き続き頑張るのみなのであります。ああ、お金が欲しいぃぃ・・・そしてRTX PRO 4000が欲しい。あれは省電力仕様なくせにメモリバス速度が600GB/sぐらいあるので。なお、SFFはいらないす。でもめっちゃ高いんすよ。以前より10万ちょっと値段が上昇してるんすよね・・・(´ェ`)-3ハァ…
参考:試しに質問投げたらなんか分量すごくね?の件

通常のファインチューニングと異なり、Unslothを使用した場合(Fast Language ModelやFast Vision Modelなど)、どのようなメリットがあるか教えてください。また、その際通常のファインチューニングにどのような機能が追加されてファインチューニングが行われるのかも併せて教えて下さい。

結論
Unsloth の FastLanguageModel や FastVisionModel は、通常のファインチューニングの学習目的そのものを別物へ変える仕組みではありません。
主な役割は、Hugging Face Transformers と PyTorch を使う通常の学習経路に対して、モデル実装、カーネル、メモリ管理、量子化、LoRA の適用、長文脈学習、マルチモーダルのデータ整形を最適化して、同じ種類の学習をより少ない VRAM と短い時間で回せるようにすることです。
Unsloth は、対応モデルと設定によって、学習を最大 2 倍高速化し、VRAM 使用量を最大 70% 削減できると説明しています。
ただし、この数値はモデル、GPU、系列長、バッチサイズ、量子化の有無、LoRA かフルファインチューニングかによって変わるため、常に同じ倍率になるわけではありません。 (github.com)
まず、「通常のファインチューニング」という言葉には二つの比較対象が混ざりやすいので、分けて考えると理解しやすくなります。
- 学習方式:全パラメータを更新するフルファインチューニングか、LoRA や QLoRA のように一部の追加パラメータだけを更新するか。
- 実装経路:標準の Transformers と PyTorch をそのまま使うか、Unsloth が最適化したモデル実装とカーネルを使うか。
Unsloth は後者です。
Unsloth を使ったからといって自動的に LoRA になるわけでも、フルファインチューニングになるわけでもありません。load_in_4bit=True、get_peft_model(...)、full_finetuning=True などの設定によって、QLoRA、16 bit LoRA、フルファインチューニングを選びます。 (unsloth.ai)
学習の数式は基本的に同じ
通常の教師ありファインチューニングでは、入力トークン列 (x) に対し、正解トークン列 (y) の尤度を高めるように交差エントロピー損失を最小化します。
[ \mathcal{L} = -\sum_t \log p_\theta(y_t \mid x, y_{<t}) ]
Unsloth を使っても、SFT の基本形はこのままです。
つまり、Unsloth は「別の損失関数でモデルを賢くする」ものではありません。
同じ損失、同じデータ、同じ LoRA 設定であれば、目指す学習結果は通常の Transformers 学習と同じです。
変わるのは、主に次の部分です。
- forward と backward の計算方法。
- 活性化値をどの程度保持するか。
- 量子化済み重みをどのように読み込むか。
- LoRA 行列をどの層へどのように適用するか。
- パディングや長い系列をどのように処理するか。
- Vision Language Model の画像、画像トークン、損失マスクをどのように整えるか。
通常の Transformers 学習との違い
概念的には、通常の LoRA 学習は次のような流れです。
AutoModelForCausalLM.from_pretrained(...)
↓
PEFT の get_peft_model(...)
↓
TRL の SFTTrainer または Transformers の Trainer
↓
PyTorch の通常実装で forward / backward
Unsloth を使う場合は、次のようになります。
FastLanguageModel.from_pretrained(...)
↓
Unsloth が対応アーキテクチャを高速実装へ差し替え・最適化
↓
FastLanguageModel.get_peft_model(...)
↓
TRL の SFTTrainer または対応 Trainer
↓
最適化された forward / backward とメモリ管理で学習
したがって、FastLanguageModel は単なるモデルローダではありません。
対応する Llama、Qwen、Gemma、Mistral、Phi などの内部実装を、Unsloth 側で最適化された経路へ接続する入口です。
Unsloth は、独自の Triton カーネルと数式レベルの最適化を使うことで、学習の高速化と VRAM 削減を行うと説明しています。 (github.com)
Unsloth で追加される機能
1. 高速化されたモデル実装とカーネル
Unsloth の最も中心的な追加要素は、モデルごとの forward と backward を最適化することです。
標準的な PyTorch 実装では、attention、RoPE、MLP、LoRA の加算、正規化、逆伝播などを複数の汎用演算として実行します。
Unsloth は、対応する処理を専用カーネルや融合した計算経路へ置き換えます。
これにより、GPU カーネルの起動回数、不要な中間テンソル、メモリ帯域の使用を減らすことを狙います。
この最適化は、LoRA そのものの仕組みを変えるのではありません。
LoRA の (A)、(B) 行列を使う構造は保ったまま、その計算を効率良く実行します。
2. QLoRA を使いやすくする 4 bit ロード
Unsloth の典型的な利用では、ベースモデルを 4 bit で読み込みます。
from unsloth import FastLanguageModel
model, tokenizer = FastLanguageModel.from_pretrained(
model_name="unsloth/...",
max_seq_length=2048,
load_in_4bit=True,
)
この設定では、ベースモデルの重みを 4 bit 量子化して保持し、その上に LoRA アダプタを追加して学習します。
これは QLoRA です。
ベースモデル全体を 16 bit で保持する LoRA と比べて、4 bit QLoRA はベースモデルの重み保持に必要な VRAM を大きく減らせます。
Unsloth の公式ガイドでは、QLoRA は 16 bit LoRA より約 4 倍少ない VRAM で扱える一方、やや遅く、精度もわずかに不利になる可能性があると説明しています。 (unsloth.ai)
ただし、VRAM 削減の主因は「FastLanguageModel だから」だけではありません。
大きな部分は、ベースモデルを 4 bit 化し、ベース重みを凍結し、LoRA だけを学習することにあります。
Unsloth は、その QLoRA 学習をさらに効率良く動かす役割です。
3. LoRA と QLoRA の適用を簡潔にする
Unsloth では、get_peft_model を使って LoRA を追加します。
model = FastLanguageModel.get_peft_model(
model,
r=16,
lora_alpha=16,
target_modules=[
"q_proj",
"k_proj",
"v_proj",
"o_proj",
"gate_proj",
"up_proj",
"down_proj",
],
lora_dropout=0,
bias="none",
use_gradient_checkpointing="unsloth",
)
ここで追加されるものは、通常の PEFT における LoRA と同じく、各線形層に対する低ランク差分です。
[ W’ = W_0 + \frac{\alpha}{r}BA ]
r、lora_alpha、target_modules、lora_dropout、bias といった設定の意味も、基本的には通常の LoRA と同じです。
Unsloth のガイドでは、attention だけでなく MLP も含めた主要線形層、すなわち q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj、down_proj を対象にする構成を推奨しています。
これは、LoRA の表現力を確保し、フルファインチューニングに近い性能を狙うためです。 (unsloth.ai)
Unsloth は通常の LoRA に加え、次の手法も設定として扱えます。
- QLoRA:4 bit のベースモデルに LoRA を追加する。
- rsLoRA:(\alpha/r) ではなく (\alpha/\sqrt{r}) でスケールし、高 Rank での学習を安定化しやすくする。
- LoftQ:量子化誤差を考慮して LoRA 行列を初期化する。
- 16 bit LoRA:量子化せず、16 bit のベースモデルに LoRA を追加する。
- 8 bit 学習:8 bit モードで学習する。
- フルファインチューニング:ベースモデル本体の重みも更新する。 (unsloth.ai)
ただし、これらはすべてを同時に使う機能ではありません。
たとえば QLoRA とフルファインチューニングは、更新対象が根本的に異なるため、通常はどちらかを選びます。
4. Unsloth 独自の gradient checkpointing
通常の学習では、逆伝播のために各層の中間活性化値を GPU メモリへ保持します。
長い文脈を扱うと、この活性化値が大きな VRAM 消費要因になります。
gradient checkpointing は、一部の活性化値を保存せず、逆伝播時に forward を再計算することで VRAM を節約する方法です。
Unsloth では、次の設定を使えます。
use_gradient_checkpointing="unsloth"
Unsloth は、このモードで通常の gradient checkpointing より追加で約 30% のメモリ削減を狙い、非常に長いコンテキストの学習を支援すると説明しています。 (unsloth.ai)
この機能の代償は、一般に再計算が増えることです。
ただし Unsloth は、その再計算を含めても実用的な速度になるよう最適化することを狙っています。
したがって、Unsloth の大きな利点は、単に「小さい GPU で LoRA を回せる」ことではありません。
同じ GPU で、より長い系列、より大きなバッチ、より大きいモデルを試せる余地が増えることです。
5. 長文脈の学習を扱いやすくする
VRAM は、モデルサイズだけでなく系列長にも強く影響されます。
特に Transformer の attention は、系列長が増えると計算量とメモリ使用量が大きくなります。
Unsloth は、長いコンテキストのファインチューニングを主要な用途として挙げています。
公式ガイドでは、通常の試験設定より長い文脈を扱えることを利点として説明しています。 (unsloth.ai)
ただし、max_seq_length を大きく設定するだけで、モデルが長文脈に強くなるわけではありません。
長文脈のデータ、適切な RoPE 設定、GPU メモリ、attention 実装、学習目的が揃わなければ、単に学習が重くなるだけです。
Unsloth は「長い入力を回せる可能性」を増やしますが、「長文脈の理解を自動で獲得させる」機能ではありません。
6. gradient accumulation の扱い
GPU メモリが限られるとき、通常は小さな micro-batch を複数回処理し、勾配を蓄積してから一回だけ更新します。
[ \text{effective batch size} = \text{batch size} \times \text{gradient accumulation steps} ]
Unsloth は、同じ実効バッチサイズになる設定同士が、より一貫した学習結果になるよう gradient accumulation の実装上の問題を修正したと説明しています。
たとえば、次の設定は理論上、いずれも実効バッチサイズ 16 です。
batch_size = 16, gradient_accumulation_steps = 1
batch_size = 8, gradient_accumulation_steps = 2
batch_size = 4, gradient_accumulation_steps = 4
batch_size = 2, gradient_accumulation_steps = 8
batch_size = 1, gradient_accumulation_steps = 16
標準的な環境では、実装上の細部によって、これらが厳密に同じ学習挙動にならないことがあります。
Unsloth は、この差を抑えるための修正を入れていると説明しています。
これはモデルの表現力を増やす機能ではありませんが、少ない VRAM で小さい micro-batch を使うときの再現性と扱いやすさに関係します。 (unsloth.ai)
7. assistant 応答だけに損失を掛ける機能
会話形式の SFT では、入力となるユーザー文まで学習対象に含めるか、アシスタントの回答だけを学習対象にするかを選べます。
たとえば次の会話を考えます。
ユーザー: 日本の首都はどこですか。
アシスタント: 東京です。
通常の言語モデリング損失では、ユーザー発話もアシスタント発話もトークン予測の対象にできます。
一方で会話エージェントを作る場合、モデルに強く学習させたいのは「ユーザーの文を再現すること」ではなく、「ユーザーの文に対してアシスタントとして応答すること」です。
そこで、ユーザー側トークンのラベルを -100 にして損失計算から除外し、アシスタントの応答部分だけで損失を計算します。
[ \mathcal{L} = -\sum_{t \in \text{assistant tokens}} \log p_\theta(y_t \mid x, y_{<t}) ]
Unsloth には、train_on_responses_only を使ってこのマスキングを適用する仕組みがあります。
これは LoRA 固有の機能ではありませんが、会話 SFT で意図しない学習を減らすために有用です。 (unsloth.ai)
ただし、これも自動ではありません。
使用するチャットテンプレートに合わせて、ユーザー部分とアシスタント部分の境界トークンを正しく指定する必要があります。
8. packing とパディング削減
短い学習サンプルが多い場合、各サンプルを同じ長さまで padding すると、GPU は大量の pad token に対して計算することになります。
そこで複数の短いサンプルを一つの長い系列へ詰める packing を使うと、無駄な padding を減らせます。
packing=True
これは多くの場合、TRL の SFTTrainer 側の機能です。
Unsloth が学習器を完全に独自実装へ置き換えるというより、Unsloth で最適化されたモデルと TRL の Trainer を組み合わせて使う形です。
したがって、packing は「Unsloth を使えば必ず有効になる機能」ではありません。
データの平均長、会話境界の扱い、評価方法を踏まえて明示的に選びます。
FastVisionModel で追加されるもの
FastVisionModel は、画像とテキストを同時に扱う Vision Language Model 向けの入口です。
通常の言語モデル学習に対して、Vision Language Model では次の処理が追加で必要になります。
- 画像をモデル入力へ変換する。
- 画像の解像度やアスペクト比を扱う。
- 画像トークンとテキストトークンを正しい順序で並べる。
- 複数画像を含む会話形式を扱う。
- padding された画像領域や vision token を損失計算から除外する。
- vision encoder、language model、attention、MLP のどこへ LoRA を入れるか選ぶ。
Unsloth は、このために UnslothVisionDataCollator を提供しています。
この collator は、画像とテキストを含む会話データをバッチ化し、画像サイズ変更、パディング、vision token の損失除外、assistant 応答のみの学習などを扱います。 (unsloth.ai)
Vision Language Model 用の LoRA では、通常の LLM より更新対象を細かく指定できます。
model = FastVisionModel.get_peft_model(
model,
finetune_vision_layers=True,
finetune_language_layers=True,
finetune_attention_modules=True,
finetune_mlp_modules=True,
r=16,
lora_alpha=16,
target_modules="all-linear",
)
この設定で意味することは次のとおりです。
finetune_vision_layers=True:画像特徴を抽出する側にも LoRA を入れる。finetune_language_layers=True:言語モデル側にも LoRA を入れる。finetune_attention_modules=True:attention の線形層を対象にする。finetune_mlp_modules=True:MLP の線形層を対象にする。target_modules="all-linear":対応する主要な線形層を広く対象にする。
Unsloth の Vision ガイドでは、これらをすべて有効にする設定が既定として示されています。
ただし、画像理解をほとんど変えず言語的な回答形式だけを変えたい場合は、vision layers を凍結して language layers だけを学習する選択もできます。 (unsloth.ai)
Vision の場合にどこを学習するべきか
用途ごとに、更新対象は変わります。
- 画像から新しい視覚的特徴を読み取らせたい:vision layers も学習対象にする。
- 画像認識能力は既に十分で、専門用語や説明形式だけを変えたい:language layers を中心に学習する。
- 画像と質問の対応関係を改善したい:vision と language の両方を学習する。
- VRAM が厳しい:まず language layers のみ、または attention のみで試す。
- 画像分類に近い狭いタスクへ寄せたい:vision 側を含める価値がある。
たとえば、汎用 VLM を「医療画像に対して決められた所見フォーマットで回答するモデル」へ変えるだけなら、言語側の LoRA だけでも改善することがあります。
一方で、汎用 VLM が認識できない特有の所見、撮影条件、画像上の微細な特徴を扱わせるなら、vision encoder 側まで更新したほうがよい場合があります。
フルファインチューニングもできるが、別物として考える
Unsloth は LoRA と QLoRA だけでなく、フルファインチューニングもサポートしています。
フルファインチューニングでは、ベースモデルの重み (W_0) 自体を更新します。
[ W’ = W_0 + \Delta W ]
LoRA では、ベース重みを凍結し、低ランク差分だけを学習します。
[ W’ = W_0 + \frac{\alpha}{r}BA ]
この違いは大きいです。
フルファインチューニングでは、重み本体、勾配、Adam の一次モーメント、二次モーメント、活性化値などを多く保持する必要があります。
したがって、Unsloth が高速化やメモリ削減をしても、フルファインチューニングのコストは QLoRA より大幅に大きいままです。
Unsloth の公式ガイドも、フルファインチューニングは多くのリソースを要し、まず LoRA または QLoRA を試すことを勧めています。 (unsloth.ai)
ここで誤解しやすい点は、次のとおりです。
Unsloth を使えば、フルファインチューニングが QLoRA と同じ軽さになる。
これは意味しません。
Unsloth はフルファインチューニングも効率化できます。
しかし、更新するパラメータ数とオプティマイザ状態の規模が違うため、QLoRA の軽さをそのまま得られるわけではありません。
何が自動で入り、何を自分で選ぶのか
| 項目 | Unsloth 使用時の扱い |
|---|---|
| 高速なモデル実装 | FastLanguageModel、FastVisionModel のロード時に利用される |
| 専用カーネルと計算最適化 | 対応モデルと環境で利用される |
| QLoRA | load_in_4bit=True と LoRA 適用を選んだ場合に使う |
| LoRA の追加 | get_peft_model(...) を呼ぶ必要がある |
| フルファインチューニング | full_finetuning=True などで明示的に選ぶ |
| Gradient checkpointing | use_gradient_checkpointing="unsloth" などで選ぶ |
| rsLoRA | use_rslora=True で選ぶ |
| LoftQ | loftq_config を設定した場合に使う |
| assistant 応答だけの損失 | train_on_responses_only などで明示的に設定する |
| packing | Trainer 側で packing=True を設定する |
| Vision 用 data collator | UnslothVisionDataCollator を明示的に渡す |
| Vision と Language の学習範囲 | finetune_vision_layers などで選ぶ |
実務上の使い分け
通常のテキスト SFT なら、最初の設定としては次が扱いやすいです。
学習方式:QLoRA
LoRA Rank:r = 16
LoRA Alpha:alpha = 16 または 32
対象層:Attention と MLP の主要線形層
gradient checkpointing:"unsloth"
学習率:まず 2e-4 前後から検証
エポック数:1〜3
この設定は、「まず軽量に試し、VRAM と性能の両方を確認する」ための出発点です。
Unsloth の公式ガイドも、一般的な LoRA または QLoRA では r=16 または r=32 を候補とし、alpha=r または alpha=2r を目安として示しています。 (unsloth.ai)
Vision Language Model なら、最初は次の二段階に分けるほうが原因を追いやすくなります。
- language layers を中心に LoRA を入れ、出力形式、専門語彙、応答方針が改善するかを見る。
- 画像認識そのものが不足している場合に限り、vision layers も学習対象へ広げる。
最初から全層を学習対象にすると性能が伸びる場合もあります。
しかし、VRAM 消費、学習時間、過学習の余地も増えるため、どの能力を変えたいのかに応じて対象を決めるほうがよいです。
注意点
Unsloth を使うと、同じ GPU でも大きいモデルや長いコンテキストを扱いやすくなります。
しかし、データ品質、チャットテンプレート、ラベルマスキング、学習率、エポック数、評価設計の重要性は変わりません。
特に、次の誤解は避ける必要があります。
- 「Unsloth を使えば精度が自動で上がる」わけではない。
- 「4 bit なら必ず 16 bit と同じ精度になる」わけではない。
- 「長い系列長を設定すれば長文脈理解が身に付く」わけではない。
- 「Vision layers を学習すれば必ず画像理解が改善する」わけではない。
- 「QLoRA が失敗したならフルファインチューニングなら成功する」とは限らない。
Unsloth の価値は、主に実験可能な範囲を広げることにあります。
これまで VRAM 不足で試せなかったモデルサイズ、系列長、バッチサイズ、LoRA 適用範囲、Vision Language Model の学習を、より少ない計算資源で検証できるようになります。
そのうえで、最終的な品質は通常のファインチューニングと同じく、データセットと評価セットの設計で決まります。
参照資料
Unsloth の公式ファインチューニングガイド、LoRA ハイパーパラメータガイド、Vision Fine-tuning ガイド、公式 GitHub リポジトリを参照しました。 (unsloth.ai)



コメント