RTX A6000でQLoRAファインチューニング実測: VRAM・学習時間・コスト
なぜ自社GPUでファインチューニングするのか
現場の点検写真や図面、業務文書には個人情報や取引先の機密が含まれることが多く、外部のクラウドAPIにそのまま投げるわけにはいかないケースが少なくありません。加えて、ファインチューニングは一度で終わらず、データセットを調整しては再学習する試行錯誤の繰り返しになります。API課金モデルだと「何度も回す」こと自体がコストに直結しますが、自社にGPUがあれば、電気代以外の追加コストを気にせず何度でも試せるのが大きな利点です。
このメリットを活かすには、まず「そもそも自社のGPU1枚でLLMのファインチューニングが現実的に回るのか」を見極める必要があります。この記事では、その判断材料としてQLoRAという手法の考え方と、RTX A6000というGPUを選ぶ際の観点を整理します。
QLoRAの仕組み（概要）
QLoRAは、LoRA（Low-Rank Adaptation）と量子化を組み合わせたファインチューニング手法です。ポイントは大きく2つあります。
- ベースモデルは4bitに量子化して凍結する: 学習対象にはせず、重みを4bit（NF4など）に圧縮したまま保持することで、モデル本体が消費するVRAMを大きく削減します。
- 学習するのはLoRAアダプタのみ: Attention層などに低ランクの小さな行列（アダプタ）を追加し、その部分だけを学習します。ベースモデルの重み自体は変更しないため、フルファインチューニングに比べて学習対象のパラメータ数が桁違いに少なくなります。
この2つの組み合わせにより、フルファインチューニングでは載らないサイズのモデルでも、限られたVRAMの中で学習を試せるようになる、というのがQLoRAの基本的な考え方です。学習時は量子化された重みをその都度デクオンタイズ（復元）して計算するため、相応の計算オーバーヘッドは発生します。
QLoRAが向いているケース
ベースモデルの汎用的な知識はそのまま活かしつつ、特定ドメインの語彙や文体、タスクの型に適応させたい場合に向いています。ゼロから知識を教え込むような用途（フルスクラッチ学習）には向きません。
RTX A6000という選択
RTX A6000はNVIDIAのワークステーション向けGPUで、コンシューマー向けのGeForceシリーズよりも大きなVRAM容量とECC（誤り訂正）メモリを備えているのが特徴です（詳細なスペックはNVIDIA公式の製品情報を参照してください）。学習ジョブが長時間に及ぶファインチューニングでは、VRAM容量に余裕があるほどバッチサイズやシーケンス長の選択肢が広がり、ECCメモリはメモリエラーによる学習中断のリスクを下げてくれます。
自社に1枚だけGPUを置くという運用を考えたとき、「複数枚のコンシューマーGPUを束ねる」よりも「大容量VRAMを1枚で確保する」方が、分散学習の実装コストを避けられるぶんシンプルになる、という判断もあります。
実測データ(準備中)
進捗（2026-07-13時点）: 本プロジェクトではQLoRA学習に使う合成データセットの生成（RTX A6000上でollama経由のLLM推論により実行）が完了しました。12,000件を生成し、品質フィルタ通過後11,227件を採用（採用率93.56%）。一方、LoRAアダプタ本体の学習ジョブはまだ実行前のため、本記事が扱うVRAM使用量・学習時間・コストの実測値はまだ計測できていません（※未測定・後日追加）。学習を実施次第、この記事に追記します。
※参考: 同じRTX A6000でのLLM推論（学習ではなく応答生成）のVRAM・速度の実測データは「ollamaで社内オフラインLLM運用」に掲載しています。ただしQLoRA学習中のVRAM使用量は、勾配・オプティマイザ状態・活性化の保持が追加で必要になるため、推論時より大きくなる点にご注意ください。
今後このセクションでは、実際に手元のA6000環境で計測した、モデルサイズ・バッチサイズ・シーケンス長ごとのVRAM使用量、データ量・エポック数ごとの学習時間、クラウドGPUを都度借りた場合との概算コスト比較を掲載する予定です。
VRAMが足りない時にまず試すこと
QLoRAで学習していても、モデルサイズやシーケンス長次第ではVRAM不足（Out of Memory）に当たることがあります。一般的に効果があるとされている調整は次の通りです。
- バッチサイズを下げる: もっとも単純で即効性のある対処です。
- 勾配チェックポイント（gradient checkpointing）を有効にする: 計算時間と引き換えにメモリ使用量を抑えられます。
- 最大シーケンス長を短くする: 扱うテキストの長さを絞れるなら効果があります。
- LoRAのランクを下げる: アダプタのサイズそのものを小さくします。
- Paged Optimizer（bitsandbytesのPaged AdamWなど）を使う: オプティマイザの状態管理をページング方式にし、メモリスパイクを抑えます。
どれも「精度と引き換えにメモリを節約する」トレードオフを含むため、まずは小さいデータセットで動作確認をしてから、精度を見ながら調整していくのが安全です。
クラウドGPUとの使い分けの判断軸
自社GPUとクラウドGPUは対立するものではなく、用途で使い分けるのが現実的です。
- 試行錯誤のイテレーションが多い開発初期: 自社GPUで何度も気軽に回せる方が向いています。
- モデルサイズが大きく、A6000のVRAMでも厳しい大規模学習: A100/H100などのクラウドGPUを一時的に借りる方が現実的です。
- 完成したモデルの推論・運用フェーズ: 学習ほどの計算資源は不要なことが多く、A6000や、さらに小型のGPUでも十分な場合があります。
固定費（自社GPUの導入コスト）と従量費（クラウドの時間課金）のどちらが有利かは、学習頻度とデータの機密度次第で変わります。この判断軸を整理したうえで、実際のコスト感は準備中の実測データとあわせて後日更新します。
まとめ
QLoRAは「ベースモデルを4bit量子化して凍結し、LoRAアダプタだけを学習する」ことで、限られたVRAMでもファインチューニングを試せるようにする手法です。RTX A6000のような大容量VRAM・ECCメモリを備えたワークステーションGPUは、自社完結でこの試行錯誤を回す環境の選択肢になります。VRAM使用量や学習時間の具体的な数値は、今後実測して本記事に追記していきます。