最初に結果を出した後は、より大きなモデルを試してみたくなるのは自然です。0.5Bから7Bに変更できますが、元のマシンでは十分でなくなるかもしれません。
リソースを選択する際は、まずいくつかの要素を区別します。CPUとGPUは計算を担当し、メモリとビデオメモリは実行中のデータを保持し、ディスクはモデルファイルを保存します。モデルがダウンロードできることは、ディスクに収まることを意味するだけで、正常に実行できるかどうかは、メモリ、ビデオメモリ、計算能力次第です。同じモデルでも、どのような精度で読み込み、どの程度の長さの入力を処理し、同時にいくつのリクエストを処理するかによって、リソースの占有量が変わります。推論と訓練の要件も異なります。
以下ではまずCPUとGPUがそれぞれ何に向いているかを確認し、次にモデルパラメータがどの程度のスペースを占有するかを計算し、後でノートパソコンまたはクラウドインスタンスを選択する準備をします。
CPUとGPUには計算方式に明らかな違いがあります。
CPUは汎用計算を目的としており、各コアには比較的完全な制御と演算能力があり、プログラムの実行プロセスに応じて判断、ジャンプ、タスクスケジューリングを行うことができます。異なる種類の計算タスクを柔軟に処理できます。
GPUは並列計算アーキテクチャを採用しており、大量の計算ユニットを含み、同時に大量の計算タスクを実行できます。データ規模が大きく、計算プロセスの繰り返し度が高いタスクの処理に適しています。
CPUとGPUの処理速度はタスクの種類と計算規模に依存します。
大量の論理判断、プログラム制御、タスクスケジューリングを含むシナリオでは、CPUの実行効率がより高いです。オペレーティングシステムの実行、データベースクエリなどのタスクは、CPU上で完了させるのが適しています。
大規模な並列計算タスクについては、GPUがより高い計算スループットを提供できます。深層学習における行列乗算や畳み込み演算は、複数の並列サブタスクに分割でき、GPUの計算ユニットが同時に実行し、全体の計算効率を向上させます。
ただし、計算タスクの規模が大きい場合のみ、GPUの優位性がはっきりと現れます。データ量が小さい場合、GPUの計算リソースを十分に活用できず、CPUとGPU間のデータ転送やタスクスケジューリングによるオーバーヘッドが発生するため、CPUを使用した方が効率的な場合があります。
CPUとGPUのコストにはハードウェアの購入価格だけでなく、稼働中の電力消費、およびその後の使用と保守コストも含まれます。
ハードウェア購入方面では、CPUは標準装備であり、一般的なサーバーとパーソナルコンピュータにはCPUの構成が必要です。AI訓練と推論に使用される高性能GPUは通常高価で、GPU自体だけでなく、サーバー、ビデオメモリ、ストレージ、その他の付帯ハードウェアのコストも考慮する必要があります。
稼働中には、GPUの大規模計算時の電力消費が高く、サーバー内のGPU数が増えるほど、電力供給と冷却の圧力が増し、データセンターの電力費と冷却コストが大幅に増加します。
使用と保守では、CPUエコシステムは比較的成熟しており、通常のサーバー保守は比較的簡単です。GPUについては、ドライバ、計算フレームワーク、ハードウェア環境の互換性を考慮する必要があり、異なるバージョン間の衝突によりモデルが正常に実行できない場合があります。マルチGPU環境ではデバイス間のデータ通信も含まれ、ハードウェア接続とソフトウェア構成に一定の要件があります。
訓練と推論タスクのリソース要件は異なり、異なる規模と種類のモデルの計算リソース要件も大きく異なります。ハードウェアの選択は、モデル規模、データ量、性能要件、および訓練と推論の2つのシナリオでのリソース要件を総合的に考慮する必要があります。
モデルの訓練段階では、データ規模が比較的小さい場合、CPUはほとんどの従来の機械学習モデルの訓練ニーズを満たすことができます。例えば線形回帰、ロジスティック回帰、ランダムフォレストなどです。一部の軽量ニューラルネットワークもCPUで訓練を完了できますが、データ規模とモデル構造の複雑さが増すにつれ、訓練時間は明らかに長くなります。モデルのチューニングを頻繁に行う必要がある場合は、GPUを使用することで訓練時間を短縮できます。
大規模ニューラルネットワークと大規模言語モデルの訓練には大量の行列計算が必要であり、計算能力とビデオメモリ容量の要件は非常に高いです。Qwenのような数十億パラメータ規模の大規模言語モデルは、GPUなどの高性能加速デバイスに依存して訓練を完了する必要があります。
モデルは推論段階でのハードウェア要件は訓練段階とは異なります。パラメータ規模が小さく、アクセス量が低いシナリオでは、CPUで推論ニーズを満たすことができ、Quantizationなどの方法でリソース占有を低減することもできます。大規模モデル、高并发サービス、迅速な応答が必要なシナリオでは、GPUがより高い推論効率を提供できます。
CPUとGPUにはそれぞれ適用されるシナリオがあり、モデル規模、データ量、并发リクエスト、性能要件、デプロイコストを総合的に考慮する必要があります。
モデルの実行リソースニーズを評価するには、主に2つの指標を見ます：パラメータ規模とデータ精度です。
モデルパラメータ規模は通常Bで表され、1Bは10億パラメータを意味します。パラメータはモデルが訓練プロセスで学習した数値であり、推論時にはこれらのパラメータをメモリ（CPU）またはビデオメモリ（GPU）にロードする必要があります。パラメータ量が増えるほど、占有するリソースも大きくなります。
データ精度は、モデルパラメータがどのような数値形式で保存・計算されるかを指します。一般的な形式にはFP32、FP16、BF16、Quantization用のINT8、INT4などがあります。同じパラメータ量のモデルでも、データ精度が高いほど、占有するリソースは大きくなります。
ログイン ディスカッションに参加
異なる精度での1Bパラメータの保存占有量は以下のように推定されます：
| 精度 | 1Bパラメータあたりの占有スペース（約） | 一般的な用途 |
| FP32（単精度） | 4GB | 訓練、高精度推論 |
| FP16（半精度） | 2GB | 訓練、推論 |
| BF16 | 2GB | 訓練、推論 |
| INT8 | 1GB | Quantization推論 |
| INT4 | 0.5GB | 低精度Quantization推論 |
モデル重み = パラメータ量 × その精度での1Bパラメータの保存占有量。7Bモデル、FP16精度での推論为例にすると、モデル重みの占有は約：7 × 2GB ≈ 14GBです。
モデル推論段階では、モデル重みのロードに加え、KV Cache、ランタイムフレームワーク、一時計算用の追加リソースも必要です。
KV Cacheは、生成プロセスで既に計算されたTokenの関連情報を保存し、重複計算を避けるためのものです。占有量はモデル構造、コンテキスト長、并发リクエスト数に依存します。コンテキストが長いほど、保存する情報が多くなり、同時処理するリクエストが多いほど、KV Cacheの占有量も増加します。
推論リソース占有の推定式：
CPU推論に必要なメモリ ≈ モデル重み + フレームワークおよび一時コスト。
GPU推論に必要なビデオメモリ ≈ モデル重み + KV Cache + フレームワークおよび一時コスト。
ここで重みは静的であり、フレームワークコストは基本的に一定で、変数はすべてKV Cacheにあります。長シナリオシナリオでは、KV Cacheのスペースを確保する必要があります。
モデル訓練段階のリソースニーズは推論段階よりも高いです。モデル重みの保存に加え、勾配、最適化状態、訓練プロセス中の中間結果を保存する必要があり、より多くのリソースが必要です。訓練リソースニーズは最適化の種類と訓練戦略によります。
（1）完全モデル訓練
完全モデル訓練では、モデル重み、勾配、最適化状態、活性化値を同時に保存する必要があります。Adam最適化、FP16精度での完全訓練为例にすると、1Bパラメータあたり約：
| 構成要素 | 1Bパラメータあたりの占有 |
| モデル重み（FP16） | 2 GB |
| 勾配（FP16） | 2 GB |
| 最適化状態 | 8 GB |
| FP32重みコピー | 4 GB |
| 小計（活性化値を除く） | 16 GB |
注：Adam最適化は2つのFP32精度の状態（モメンタムと分散）を保存する必要があるため、最適化状態は8GBを占有します。FP32重みコピーは最適化パラメータ更新に使用されます。
完全訓練の初期推定式：
GPU訓練に必要なビデオメモリ ≈ パラメータ量 × 16 Byte + 活性化値コスト
CPU訓練に必要なメモリ ≈ パラメータ量 × 16 Byte + 活性化値コスト
GPU訓練はビデオメモリ容量に制限され、CPU上での訓練は計算速度に制限されます。7BモデルがFP16を使用してGPU上で完全訓練を行う場合、少なくとも7B × 16 Byte ≈ 112GBのビデオメモリが必要で、活性化値を加えると実際のニーズはさらに大きくなります。
（2）パラメータ効率的ファインチューニング（LoRAなど）
大規模モデルのファインチューニングでは、実際の応用ではLoRA（Low-Rank Adaptation）などのパラメータ効率的ファインチューニング方法がより一般的に使用されます。LoRAの訓練では元のモデルのすべてのパラメータを更新するのではなく、元のモデル重みを凍結し、新しく追加された低ランク適応パラメータのみを訓練し、ビデオメモリニーズが大幅に低減されます。
LoRA訓練ビデオメモリ ≈ ベースモデル重み + LoRAパラメータ + LoRAパラメータ勾配および最適化状態 + 活性化値。
ここで、ベースモデル重みはロードのみで更新には参加せず、LoRAの新規パラメータ量は元モデルの0.1%〜1%のみであり、その勾配と最適化コストはほぼ無視できます。実際のビデオメモリは主にモデル重み、コンテキスト長、バッチサイズ、訓練フレームワークの最適化方法に依存し、LoRAのファインチューニングは完全訓練と比較してビデオメモリニーズを大幅に低減できます。
例えば、FP16で7Bモデルをロードすると、モデル重みは4GBを占有します。24GBビデオメモリのGPU1枚では、LoRAのファインチューニングは通常実行可能（バッチサイズとコンテキスト長を適切に調整する必要があります）。QLoRAを使用する場合（ベースモデルをINT4にQuantization）、ビデオメモリ占有をさらに低減でき、より限られたハードウェア環境でファインチューニングを完了できます。