ハクソク

世界を動かす技術を、日本語で。

Qwen3.5 ファインチューニングガイド – Unsloth ドキュメンテーション

概要

  • Qwen3.5モデルファミリーがUnslothでファインチューニング可能に
  • Visionテキスト両方のファインチューニング対応
  • VRAM使用量削減と学習速度向上
  • 多言語対応GGUFエクスポートもサポート
  • MoEモデルや各種注意点も記載

Qwen3.5モデルのUnslothによるファインチューニング概要

  • Qwen3.5ファミリー(0.8B, 2B, 4B, 9B, 27B, 35B‑A3B, 122B‑A10B)をUnslothでファインチューニング可能
  • Visionテキストの両方でファインチューニング対応
  • Qwen3.5-35B-A3B(bf16 LoRA)74GB VRAMで動作
  • Unslothにより1.5倍速い学習FA2構成よりVRAM半減
  • bf16 LoRAのVRAM消費例
    • 0.8B:3GB
    • 2B:5GB
    • 4B:10GB
    • 9B:22GB
    • 27B:56GB

Google Colabノートブック・学習レシピ

  • 0.8B/2B/4Bモデル無料Google Colabノートブックでbf16 LoRAファインチューニング可能
  • 推論能力維持には推論型例を75%以上混ぜることを推奨
  • **Full fine-tuning (FFT)**も可能(VRAMは4倍必要)
  • 201言語対応の多言語ファインチューニング

モデルエクスポート・推論環境

  • GGUF形式でエクスポート可能(llama.cpp/Ollama/LM Studio等対応)
  • vLLMにもエクスポート対応
  • Colabやローカル環境ではUnsloth最新版へアップデート推奨
    • pip install --upgrade --force-reinstall --no-cache-dir unsloth unsloth_zoo
  • transformers v5必須(Unslothは自動でv5を利用、Colab除く)

カスタムカーネル・量子化・MoEモデル対応

  • Qwen3.5Mamba Tritonカーネルを利用し、初回コンパイルに時間がかかる場合あり(特にT4 GPU)
  • QLoRA(4bit)学習は非推奨(MoE・Dense問わず、量子化誤差大)
  • MoEモデル(35B, 122B, 397B)bf16構成推奨
    • MoE QLoRA 4bitはBitsandBytes制限で非推奨
  • UnslothのMoEカーネルはデフォルト有効、UNSLOTH_MOE_BACKENDで切替可能
  • Router-layerファインチューニングはデフォルト無効(安定性重視)

マルチGPU・バッチサイズ調整・OOM対策

  • Qwen3.5-122B-A10B(bf16 LoRA)256GB VRAMで動作
  • マルチGPU利用時は**device_map = "balanced"**指定またはマルチGPUガイド参照
  • OOM時per_device_train_batch_size=1max_seq_length短縮で対処

Visionファインチューニング・マルチモーダル対応

  • Qwen3.5Causal Language Model with Vision Encoder(統合型VLM)
  • torchvision/pillow等のVision依存パッケージ必須
  • Vision/テキスト/Attention/MLP層ごとにファインチューニング範囲を選択可能(デフォルト全ON)
  • マルチイメージ学習には専用ガイドあり
  • 推論/デプロイはllama.cpp, vLLM, Ollama, LM Studio, SGLang等に対応

モデル保存・エクスポート・Hugging Face連携

  • GGUF形式で直接保存・Hugging Faceへプッシュ可能
  • 推論時に挙動悪化した場合はチャットテンプレ/EOSトークン不一致が主因(学習時と同じテンプレ必須)
  • vLLM 0.16.0はQwen3.5未サポート、0.170以降またはNightly版推奨
  • 16bit保存LoRAアダプタのみ保存も対応

主要Pythonコード例

import os
import torch
from unsloth import FastModel

model, tokenizer = FastModel.from_pretrained(
    model_name = "unsloth/Qwen3.5-35B-A3B",
    max_seq_length = 2048,
    load_in_4bit = False,  # MoE QLoRA非推奨、Dense 27BはOK
    load_in_16bit = True,  # bf16/16bit LoRAまたはFull Fine-tuning用
    full_finetuning = False,
)

model.save_pretrained_gguf("directory", tokenizer, quantization_method = "q4_k_m")
model.save_pretrained_gguf("directory", tokenizer, quantization_method = "q8_0")
model.save_pretrained_gguf("directory", tokenizer, quantization_method = "f16")

model.push_to_hub_gguf("hf_username/directory", tokenizer, quantization_method = "q4_k_m")
model.push_to_hub_gguf("hf_username/directory", tokenizer, quantization_method = "q8_0")

model.save_pretrained_merged("finetuned_model", tokenizer, save_method = "merged_16bit")
# HuggingFaceにアップロードする場合
model.push_to_hub_merged("hf/model", tokenizer, save_method = "merged_16bit", token = "")

model.save_pretrained("finetuned_lora")
tokenizer.save_pretrained("finetuned_lora")

model.save_pretrained_merged("finetuned_model", tokenizer, save_method = "lora")
# HuggingFaceにアップロードする場合
model.push_to_hub_merged("hf/model", tokenizer, save_method = "lora", token = "")

参考リンク・追加情報

  • 詳細な推論・デプロイガイドは公式ドキュメント参照
  • Vision RL/GRPO等の高度な学習もUnslothで対応
  • 最終更新:44分前(記事執筆時点)

Qwen3.5モデルのUnslothによるファインチューニングは、速度・省メモリ・多機能性で先進的な選択肢

Hackerたちの意見

みんなが自分の小中規模モデルを微調整するために使ってる実際のケースってどんなのがある?
あ、これに関してXに投稿したことあるよ! https://x.com/danielhanchen/status/1979389893165060345?s=20 1. CursorはオンラインRLを使って+28%の承認率を得た: https://cursor.com/blog/tab-rl 2. VercelはV0のAutoFixモデルにRFTを使った: https://vercel.com/blog/v0-composite-model-family 3. PerplexityのSonar for Deep Research Reasoningは微調整されたモデルだと思う: https://docs.perplexity.ai/docs/getting-started/overview 4. Doordashは「一般化属性抽出モデル」にLoRA、QLoRAを使ってる: https://careersatdoordash.com/blog/unleashing-the-power-of-l... 5. NASAの洪水水検出: https://earthdata.nasa.gov/news/nasa-ibm- openly-release-geospatial-ai-foundation-model-nasa-earth-observation-data6 6. ロボティクスのオンラインRL - 将来的にロボットを教えるのを想像してみて、ミニ微調整を通じてね 7. OpenAIのRFTページにはもっと情報があるよ: https://developers.openai.com/api/docs/guides/rft-use-cases 8. 大きなモデルについては - https://www.mercor.com/blog/expert-data-drives-model-perform...
この具体的な質問について考えを促したいだけなんだけど、回答に興味がある: すごくシンプルな文書分類タスクに対してhaikuでベンチマークを取ったんだけど、今のところそれを並行してhaikuに依頼してるんだ。非常にナイーブな同じプロンプトシステムで、同じAPIのAWSベッドロックを使ってるんだけど、4bモデルのいくつかがかなり良いマッチをしてて、ローカルで簡単に実行できるか、ホスティングプロバイダーを通じて安価に実行できそうだ。データ量と改善度の「どれくらい」が、もう直感的にわからなくなってる。これらの2つの軸についても、どれくらいのオーダーで推測すればいいかもわからない。議論を促すための生データを以下に示す: | モデル | DocType% | Year% | Subject% | $/MTok | |---------------|----------|-------|----------|-----------| | llama-70b -----| 83 | 98 | 96 | $0.72 | | gpt-oss-20b --| 83 | 97 | 92 | $0.07 | | ministral-14b -| 84 | 100 | 90 | $0.20 | | gemma-4b ----| 75 | 93 | 91 | $0.04 | | glm-flash-30b -| 83 | 93 | 90 | $0.07 | | llama-1b ------| 47 | 90 | 58 | $0.10 | パーセントは文書タイプ(カテゴリカル)、年、主題名のマッチ率で、haikuに対してだよ。最初の4ページだけを使用してる。これが自分の社内モデルだった昔なら、トレーニングでその数字を上げられるか興味があったけど、新しいLLMではしばらくやってないんだ。もし可能なら、ちょっとでも感じを掴みたい。何万もの例を簡単に生成できるし、自分で試してみるかもしれないけど、意見を聞きたいな。 _テーブルのフォーマットを編集しました_
すごいガイドだね。でも、Qwenのリーダーが何人かクビになって、もっと「ビジネス寄り」のリーダーに代わっちゃったのは残念。これがQwenのオープンソース時代の終わりを意味しないといいけど。
あ、Xでちょっと前に見たんだけど: https://x.com/poezhao0605/status/2029151951167078454 - アリババのCEOとCTOが緊急全体会議を開いてるみたい!うまくいくといいね!
微調整って話は面白いけど、現代のLLMではあんまり意味がなくなってきてるよね。今のLLMはすごく強力だから、複雑なことを少しのショットで学べちゃうし、強いプロンプトと生成を増やすのが(Qwen3.5の大きなコンテキストウィンドウを考えると)通常は最良の選択肢だよ。微調整が効果的なモデルもあるけど、例えば画像モデルとかね。LoRaを使えばいろんな方法で良い結果が得られるし、過去のLLMにも意味があった。でも今は、なんで?LLMはすでに大量のデータセットを見て(事前学習後に)リリースされてるし、SFTやRLのためにね。検閲を取り除くのは他の技術でやった方が効率的だし。だから、微調整はどんどん relevancy が薄れていく気がするし、もうかなり無関係になってると思う。これはLLMに特有の話ね。他の基盤モデルにはまだ微調整が意味があって役立つ(画像、テキストから音声への変換、など)。
俺の意見では、微調整が意味を持つのは、モデルにすでに入ってない大量の情報を知っておく必要があるときだね。例えば、会社のナレッジベースやコードリポジトリ、専門的な法律文書の宝庫とか…その場合、毎回その情報でコンテキストウィンドウを詰め込むのは現実的じゃないよ。特に反応の良いチャットボットを作ろうとしてるならね。
微調整の最大の理由は、小さなモデルを使って、構造化された出力が必要なアプリケーションに微調整して、安価に大規模な推論を実行できることだと思う。「フロンティアLLMは十分なコンテキストでできる」ってのは、微調整に対する強い反論にはならないよ。だって、運用コストが高いから。
Doc-to-LoRAみたいなモデル適応アルゴリズムがもっと一般的になってほしいな。
確かに、LLMは毎週賢くなってるし、いいポイントだね。でも、ファインチューニングやRLの最大の利点はまだ実現されてないと思う。1. 家にロボットがいるなら、効率的な継続学習が必要で、小さなLoRAを使ったオンザゴーのファインチューニングやRLが考えられる。これはスパースな報酬信号を使ったマルチモーダルファインチューニングが必要になるし、データが匿名化された後に中央処理センターに集約されて、大きなモデルをより多くのデータとRLでトレーニングすることも考えられる。2. 確かに、画像や音声、動画などはLoRAが得意な分野だね。https://unsloth.ai/docs/models/qwen3.5/fine-tuneのガイドは実際にはビジョン+テキストのファインチューニングガイドだから、自分のユースケースに合わせてビジョン層をファインチューニングできるよ。3. モデルのルーティングは将来的にもっと一般的になると思う。つまり、ローカルで小さめのモデルをLoRAで継続的にファインチューニングしつつ、複雑なタスクはクラウドの大きなLLMにオフロードできるようになる。4. 下の投稿でも他のユースケースについて書いたけど、DoorDash、Vercel、Mercor、Stripe、NASA、Perplexity、Cursorなど、みんなファインチューニングをやってる。例えば、CursorやPerplexityは自分たちの特定の製品ラインのために大きなOSS LLMをファインチューニングしてるから、データがあれば確実に価値があるよ。
> でも、なんで?これらのモデルは一般的には良いけど、ラトビア語の出力は半分が意味不明なんだ。言葉のルーツはだいたい合ってるけど、残りがダメ。あと、EuroLLMは新しいモデルをリリースするのが本当に遅い。
専門的なユースケースにはすごく向いてるよね:(a) 問題がそれほど難しくない場合(推論が必要ない)、(b) 多様性がある場合(ワールドモデルが必要ない)、(c) 安価な推論が欲しい場合(ハードウェア的に実現できるなら)、(d) 十分なデータがあるか、データを蓄積するワークフローがある場合(十分なデータでファインチューニングすれば、時にはプレミアモデルを超えることもできるし、低遅延も確保できる - もちろん、(a)と(b)が当てはまる前提だけど)。ファインチューニングを正当化するためには珍しい完璧な状況が必要みたいに聞こえるけど、こういう状況は珍しくないよ。ある程度、(a)、(c)、(d)は従来のMLシステムを展開するための前提条件だったから。
コストや遅延に敏感なアプリケーションにはファインチューニングはまだ意味があるよ。大きなコンテキストウィンドウは生成を大幅に遅くするし、現代のモデルのパフォーマンスや指示に従う能力は、実際の応答よりも桁違いに多くのトークンを消費する推論ステップに大きく依存してる(アプリケーションによるけど)。一方で、ファインチューニングされたモデルはそのステップをスキップしたり、かなり減らしたりできる。君が言った技術を使って大きなモデルでオフラインで合成データを生成し、それを使って小さなモデルをファインチューニングするのは、あまり評価されてない技術だよ。
現在のLLMは強力だけど、タスクから簡単に気が散っちゃうことが多いんだ。生産規模で考えると、ファインチューニングは非常に特定のタスクをモデルに与えることで、もっと意味があると思う。
エージェント的なコーディングにはどっちが好き? a) qwen3-coder b) qwen3.5(一般)
私は「最高の日」のプローズを書くためにファインチューニングを試みると、80%以上の確率で受け入れられると思う。知識について話してるなら、君は正しいよ。でも、ハイパー個性的で gritty なスタイルの転送には苦手なんだ。この問題に気づいたのは、claude codeにメールの返信をドラフトさせたときだった。レジスターの選択がずれてたんだ。 ("レジスターとは、特定の聴衆、目的、文脈に合わせて選ばれる形式やトーンのレベルを指す。") それで、私のHNコメントを全部話して、いろんな悪いLLMのプローズに書き直してみて、DSPyを使ってインコンテキスト学習(ICL、HNコメントの例を10個与える)でプロンプトを最適化できるか試してみたけど、結果はひどかった。RHLFでファインチューニングされたフロンティアLLMは、私のコメントのターゲットスタイル分布に対して根深い嫌悪感を持ってるみたい。qwen3、llama、gemmaモデルをファインチューニングしようとしたけど、インストラクトモデルはすでに調整されすぎていて、ファインチューニングできなかった。これは数百のコメントをゴールドターゲットとして使い、ゴールドごとに5つの異なるLLMの劣化を入力として使った結果だよ。
ファインチューニングって、ドキュメントのコンテキストがたくさん必要なユースケースで、純粋なRAGアプローチよりも本当に改善されるの?
専門的なモデルは簡単にSOTAを超えるよ。例えば、これね: https://nehmeailabs.com/flashcheck
ファインチューニングされたQwenモデルは、NVIDIA Jetsonハードウェアで驚くほどよく動くよ。レイテンシが生の精度よりも重要なエッジAIタスク向けに、いくつかの7Bバリアントを展開したんだ。工業検査や、クラウド接続に頼れない小売分析みたいなところね。LoRAファインチューニングのおかげで、モデルが統一メモリに収まるくらい小さく保たれつつ、実用的な推論速度を達成できるのがポイント。最大の驚きは電力効率で、Jetson Orinは15W未満で連続推論ができるけど、クラウドの往復はスケールで考えるともっとエネルギーを消費するからね。
すごく興味深いね。精度が低くても許容される工業タスクの例を教えてもらえる?
> レイテンシが生の精度よりも重要なエッジAIタスク向けに、いくつかの7Bバリアントを展開したんだ。工業検査 え?なんで特に工業検査が、精度と引き換えに低レイテンシから恩恵を受けるの?ちょっと逆に聞こえるけど、もしかして何か明らかなことを見落としてるのかな。