MedQA：CUDA を不要とする AMD ROCm での臨床 AI 微調整

[記事一覧に戻る](https://huggingface.co/blog) *AMD Developer Hackathon にて lablab.ai で開催されたイベント向けに、AMD MI300X を使用して MedMCQA で Qwen3-1.7B の LoRA（Low-Rank Adaptation）ファインチューニングを行う完全なガイド。 ## アイデア 医療用質問応答は、そのリスクが極めて高いタスクの一つです。臨床的な多肢選択問題で自信を持って間違った答えを選ぶモデルは、単に間違っているだけでなく、危険です。同時に、オープンソースの医療 AI 関連の取り組みのほとんどは、NVIDIA GPU を持っていることを前提としています。CUDA がデフォルトであり、それ以外の選択肢は後回しにされがちです。 このプロジェクトはその前提に挑戦するものです。 **MedQA** は、AMD ハードウェア上で ROCm（Radeon Open Compute Platform）のみを使用して完全に構築された、LoRA ファインチューニング済みの臨床用質問応答モデルです。多肢選択形式の医療問題を入力すると、正解の記号 *および* 推論根拠に関する臨床的な説明を返します。データ読み込みからアダプタのエクスポートに至るまでのトレーニングパイプライン全体が、CUDA の依存関係を一切持たずに AMD Instinct MI300X 上で実行されます。 - 🤗 HuggingFace Hub 上のモデル: HK2184/medqa-qwen3-lora - 🚀 ライブデモ: HuggingFace Spaces - 💻 GitHub: MedQA-Medical-AI-on-AMD-ROCm ## なぜ AMD ROCm か？ AMD Instinct MI300X は、1 つのデバイスに 192 GB の HBM3（High Bandwidth Memory）メモリを搭載した画期的なハードウェアです。LLM（大規模言語モデル）のファインチューニングにおいて、VRAM（ビデオメモリ）はしばしばボトルネックとなります。これはバッチサイズやシーケンス長を決定し、量子化が必要かどうかさえも左右します。192 GB の利用可能なメモリがあるため、4 ビットや 8 ビットの量子化といったハックは一切行わず、Qwen3-1.7B を LoRA でフル fp16（16 ビート浮動小数点）でトレーニングすることができました。 さらに重要なのは、HuggingFace エコシステム（Transformers, PEFT, TRL, Accelerate）が ROCm 上でシームレスに動作することを証明することでした。それは実際に可能です。CUDA で実行されるのと同じトレーニングコードを、3 つの環境変数を設定するだけで ROCm でも実行できます： os.environ["ROCR_VISIBLE_DEVICES"] = "0" os.environ["HIP_VISIBLE_DEVICES"] = "0" os.environ["HSA_OVERRIDE_GFX_VERSION"] = "9.4.2" これだけです。コードの変更も、カスタムカーネルの作成も、CUDA 互換性の shim（調整層）も不要です。 ## データセット：MedMCQA [MedMCQA](https://huggingface.co/datasets/openlifescienceai/medmcqa) は、インドの医学入学試験（AIIMS, USMLE スタイル）から派生した大規模な多肢選択式質問データセットです。各例には以下の要素が含まれます： - 臨床に関する質問 - 4 つの回答選択肢（A～D） - 正解のインデックス - オプションの自由記述による解説（exp フィールド） 本プロジェクトでは、2,000 のトレーニングサンプルを使用しました。これは、意味のあるファインチューニングが短期間でも達成可能であることを示すためにあえて小さく設定したスライスです。MI300X 上でのトレーニングには約 5 分かかりました。 ## モデル：Qwen3-1.7B ベースモデルは [Qwen/Qwen3-1.7B](https://huggingface.co/Qwen/Qwen3-1.7B) です。これはアリババ社の最新の小規模言語モデルです。17 億パラメータというコンパクトなサイズでありながら、低コストでファインチューニングが可能で、かつ一貫した臨床推論を生成する能力も備えています。trust_remote_code=True をサポートしており、HuggingFace Transformers でクリーンに読み込み可能です。 ## プロンプト形式 プロンプト形式の一貫性は、指示微調整において極めて重要です。すべてのトレーニング例と推論呼び出しは、同じテンプレートを使用します: ### 質問: {question} ### オプション: A) {opa} B) {opb} C) {opc} D) {opd} ### 回答: {answer_letter}) {answer_text} ### 解説: {explanation} トレーニング中は、モデルは回答と解説を含む完全なシーケンスを参照します。推論時には、「### Answer:\n」までのすべての情報を提供し、そこからモデルに完成させます。 ## LoRA を用いたトレーニング 15 億パラメータすべてを微調整するのではなく、PEFT ライブラリを通じて**LoRA (Low-Rank Adaptation: 低ランク適応)**を使用します。LoRA はアテンション層に小さな訓練可能なランク分解行列を注入し、ベースの重みは凍結したままに保ちます。 ## LoRA の設定 from peft import LoraConfig, get_peft_model, TaskType lora_config = LoraConfig( task_type=TaskType.CAUSAL_LM, r=8, lora_alpha=16, lora_dropout=0.05, target_modules=["q_proj", "v_proj"], bias="none", ) model = get_peft_model(model, lora_config) model.print_trainable_parameters() # trainable params: 2,228,224 || all params: 1,543,901,184 || trainable%: 0.1443 モデルの 15 億パラメータのうち、**約 220 万**のみが訓練されます。これによりメモリ使用量が低く抑えられ、トレーニングが高速化されます。 ## トレーニング引数 from transformers import TrainingArguments args = TrainingArguments( output_dir="./outputs", num_train_epochs=2, per_device_train_batch_size=4, gradient_accumulation_steps=4, # 実効バッチサイズ = 16 learning_rate=2e-4, fp16=True, bf16=False, eval_strategy="epoch", save_strategy="epoch", load_best_model_at_end=True, gradient_checkpointing=True, optim="adamw_torch", warmup_ratio=0.05, lr_scheduler_type="cosine", report_to="none", ) いくつか注目に値する点があります: - fp16=True, bf16=False — 標準的なfp16（半精度浮動小数点数）を使用しています。bfloat16（ブロード浮動小数点16ビット）での初期実験ではNaN（数値非該当）損失が発生しましたが、fp16に切り替えることで完全に解消されました。 - gradient_checkpointing=True — 計算資源とメモリをトレードオフします。MI300X では VRAM が 192 GB あるため厳密には必須ではありませんが、より小さな GPU での再現性を高めるための良いプラクティスです。 - gradient_accumulation_steps=4 — 物理バッチサイズ 4 で実効バッチサイズ 16 を実現します。 - ウォームアップ付きの余弦 LR スケジュール（学習率スケジューリング）— 短期間のトレーニングでは平坦なスケジュールよりも収束が滑らかになります。 ## 完全なトレーニングループ from transformers import DataCollatorForSeq2Seq, Trainer collator = DataCollatorForSeq2Seq( tokenizer, model=model, padding=True, pad_to_multiple_of=8, ) trainer = Trainer( model=model, args=args, train_dataset=train_ds, eval_dataset=val_ds, data_collator=collator, ) trainer.train() # アダプターとトークナイザーを保存 model.save_pretrained("./outputs") tokenizer.save_pretrained("./outputs") トレーニング完了後、./outputs ディレクトリには LoRA アダプタの重みが保存されます。これは数 MB のファイルであり、フルサイズの多 GB モデルチェックポイントとは異なります。 ## 推論 推論時にはベースモデルを読み込み、LoRA アダプタを接続し、必要に応じて重みをマージします: from transformers import AutoTokenizer, AutoModelForCausalLM from peft import PeftModel import torch tokenizer = AutoTokenizer.from_pretrained("./outputs", trust_remote_code=True) tokenizer.pad_token = tokenizer.eos_token base_model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen3-1.7B", torch_dtype=torch.float16, device_map="auto", trust_remote_code=True, ) model = PeftModel.from_pretrained(base_model, "./outputs") model.eval() 生成処理では、モデルがループするのを防ぐために反復ペナルティ（repetition penalty）を伴う貪欲デコーディング（greedy decoding: do_sample=False）を使用します: def generate(prompt, model, tokenizer): inputs = tokenizer(prompt, return_tensors="pt").to(model.device) with torch.no_grad(): output = model.generate( **inputs, max_new_tokens=200, do_sample=False, temperature=1.0, repetition_penalty=1.1, eos_token_id=tokenizer.eos_token_id, pad_token_id=tokenizer.eos_token_id, ) new_tokens = output[0][inputs["input_ids"].shape[-1]:] return tokenizer.decode(new_tokens, skip_special_tokens=True) ## 出力例 **質問:** 以下のうち、高血圧性緊急状態に対する第一選択治療はどれですか？ A) 経口アムロジピン B) 静注ラベタロールまたは静注ニトロプルシド C) 舌下ニフェジピン D) 筋注ヒドララジン **モデルの出力:** B) 静注ラベタロールまたは静注ニトロプルシド 解説: 静脈内投与されるラベタロール（β遮断薬）またはニトロプルシドは、緊急時において血圧を急速に低下させます。経口製剤は、臓器障害を防ぐために即座の血圧管理が必要な高血圧性緊急事態に対しては作用が遅すぎます。 このモデルは単に文字を出力するだけでなく、*なぜそうなのか*という理由も説明します。これこそが臨床的に有用である所以です。 ## HuggingFace Hub からの読み込み ファインチューニングされたアダプターは公衆に公開されています。リポジトリをクローンすることなく、直接読み込むことができます: from transformers import AutoTokenizer, AutoModelForCausalLM from peft import PeftModel import torch tokenizer = AutoTokenizer.from_pretrained( "Qwen/Qwen3-1.7B", trust_remote_code=True ) base = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen3-1.7B", torch_dtype=torch.bfloat16, device_map="auto", trust_remote_code=True, ) model = PeftModel.from_pretrained(base, "HK2184/medqa-qwen3-lora") model = model.merge_and_unload() model.eval() ## 課題と解決策 AMD ROCm プロジェクトに、戦争の物語（苦労話）セクションがないことなどあり得ません。私たちが直面した問題はこちらです: 課題 根本原因 対策 **NaN 損失 (NaN loss)** 混合精度計算の不安定性 bfloat16 から fp16 に切り替え **GPU が検出されない** ROCm の環境変数が不足している ROCR_VISIBLE_DEVICES、HIP_VISIBLE_DEVICES、HSA_OVERRIDE_GFX_VERSION を設定 **bitsandbytes の非対応** bitsandbytes の ROCm ビルドが存在しない 量子化は完全に廃止 — MI300X は十分な VRAM を備えているため **推論出力のゴミデータ** トークナイザーのパディング設定が誤っていた pad_token = eos_token とし、padding_side を修正した **Trainer の評価エラー** Transformers バージョンの不整合 transformers>=4.40.0 に固定した bitsandbytes の問題には注記が必要である：NVIDIA ハードウェア上では、モデルをメモリに収めるために 4 ビット量子化がしばしば*必須*となる。しかし、192 GB の HBM3 を搭載した MI300X では、それは単に不要である。これは真のハードウェア上の利点であり、トレーニングがクリーンになり、量子化によるアーティファクトが発生しない。 ## 結果 | Metric | Value | |---|---| | Trainable parameters | ~2.2M (全体の 0.15%) | | Training time on MI300X | ~5 分 | | Dataset size used | 2,000 サンプル | | Baseline MedMCQA accuracy | ~45% | | Framework | PyTorch + ROCm 6.1 | ## 実際に試す **GPU がなくても大丈夫。** ライブ Gradio デモは HuggingFace Spaces で動作している（CPU 推論）： 👉 [HuggingFace Spaces のライブデモ](https://huggingface.co/spaces/lablab-ai-amd-developer-hackathon/MedQA-Medical-AI-on-AMD-ROCm) **AMD ハードウェアをお持ちですか？** リポジトリをクローンしてネイティブで実行してください： ```bash git clone https://github.com/HK2184/MedQA-Medical-AI-on-AMD-ROCm.git cd MedQA-Medical-AI-on-AMD-ROCm pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.1 pip install transformers datasets peft accelerate trl gradio python train.py # 約 5 分 python infer.py # サンプル質問を実行 python app.py # Gradio UI を起動 ``` ## 次のステップ このプロジェクトは、パイプラインが機能することを証明しました。次のステップは、スケーリングと堅牢化に関するものです: - より大規模なデータセット — 完全な MedMCQA コーパス（約 180,000 問）および PubMedQA を用いてトレーニングを行う - 信頼性スコアリング — 回答とともに補正された信頼性推定値を追加する - RAG の統合 — リアルタイムの医療文献検索に基づき、回答を裏付ける - 評価ハーンネス — トレーニング分割を超えた、適切なホールドアウト精度ベンチマークを行う ## 結論 MedQA は、オープンソースの AMD ハードウェア上で能力があり説明可能な医療 AI を構築することが可能であるだけでなく、そのプロセスは単純であることを示しています。HuggingFace エコシステムの ROCm 互換性は実際に非常に良好です。MI300X のメモリ余裕により、エンジニアリング上の問題のカテゴリー全体が排除されました。また、LoRA（Low-Rank Adaptation）を用いれば、1.7B パラメータのモデルをファインチューニングする作業はわずか 5 分で完了します。 AMD ROCm で構築を進めていて壁にぶつかった場合、上記の対策で数時間を節約できるはずです。また、医療 AI を構築している場合は、単なる精度よりも説明可能性を重視する姿勢を真剣に受け止める価値があります。 *lablab.ai（https://lablab.ai/）で開催された AMD Developer Hackathon 向けに作成 · AMD ROCm と HuggingFace エコシステムによって駆動* — Harikrishna Sivanand Iyer および Srijan Sivaram A

MedQA：CUDA を不要とする AMD ROCm での臨床 AI 微調整

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト