量子化はビット数ではなく、その結果で選ぶ。

ビット数だけでバリアントを説明しない

手法、その実装、バージョン、アーティファクトの正確なリビジョンを明記してください。2つの4ビットの変種が、異なる表現、グループ、メタデータ、カーネルを使うことがあります。重みの保存フォーマットと計算演算のフォーマットを分けてください。また、別の精度で保持されるモジュールやCPUへのオフロードも記録してください。

bitsandbytesでは、量子化された線形層が一部の通常層を置き換えます。他のモジュールは設定されたdtypeに従います。したがって、この動作だけではプロセスのピークを説明できません。ロード後の実効設定を確認し、そのバリアントが別のソフトウェアフォールバックではなく、期待される処理を実際に行うことを検証してください。

技術的な出典: Hugging Face Transformers 5.17 — 量子化層とその他のdtype

キャリブレーションと評価を分ける

一部の手法は量子化の準備にサンプルを使用します。Transformersで文書化されているGPTQの手順では、特にキャリブレーションセットとtokenizerが必要です。このセットはアーティファクトの製作に関与するものであり、品質の独立した証拠にはなりません。他の手法は別の経路をたどります。同じキャリブレーションプロトコルがすべてのフォーマットに適用されると想定しないでください。

キャリブレーション用のサンプルは、許可されたデータ内でモデル準備用に確保し、識別子、出所、長さ、適用された変換を記録してください。検証は設定の選択に、最終テストは確認に取っておいてください。スコアを比較した後に複数のキャリブレーションセットを選ぶ場合、その探索は開発の一部であり、評価に記載する必要があります。

技術的な出典: Hugging Face Transformers 5.17 — GPTQ量子化のキャリブレーション · 役割に応じて分割を構築する

ピークとして売り込まずに重みの上限を計算する

3十億パラメータの架空のモデルを例に取ります。すべて同じビット数で保存されているとします。生のボリュームはパラメータ数 × ビット数 / 8 で計算できます。16ビットなら60億バイト、8ビットなら30億、4ビットなら15億です。これらの数値は説明のための算術であり、実際に観測されるアーティファクトのサイズや実行されるモデルの要件ではありません。

16ビットと4ビットの生の差は4.5GB、約4.191GiBです。これにはスケール、メタデータ、量子化されていないモジュール、キャッシュ、一時ファイルは含まれません。これは検証すべきメモリ仮説を立てることを可能にしますが、ピークが4分の1になると予測するものではありません。メモリのドシエでは、フェーズを分離し、カウンタを解釈する方法を説明しています。

技術的な出典: NIST — 2進接頭辞と10進接頭辞 · IteraGPU — メモリ見積もりとピーク

キャッシュを変える前に重みを変える

動作を把握している基準から始めてください。次に、同じキャッシュ、同じ長さ、同じバッチまたは同じ同時実行数で重みのバリアントを比較してください。これらのパラメータも変更する場合、完全な構成を比較していることになります。その旨を明示し、差異のすべてを重みの量子化に帰さないでください。

KV キャッシュ自体も、モデルとエンジンが許す場合には量子化できます。これは別個の選択です。Transformers のドキュメントは特に、量子化されたキャッシュが、メモリが十分に残っている場合の短いコンテキストではレイテンシを悪化させ得ると指摘しています。この 2 つ目の変更は別のシリーズでテストしてください。より多くのメモリを節約しても、より良い遅延が保証されるわけではありません。

技術的な出典: Hugging Face Transformers 5.17 — 量子化 KV キャッシュとレイテンシのトレードオフ

品質ルールの例：わずかな低下でも許容できないことがある

ここではモデルを実行せず、判断の一例を示します。あるプロジェクトが200件のドキュメントを評価し、試験の前に基準に対して最大1ポイントの損失と定義します。また、この200件に含まれる20件の重要ドキュメントで少なくとも90%の成功率を要求します。ドキュメントは、その必須フィールドがすべて正しい場合にのみ承認されます。

以下の架空の値により、Aはこの2つのルールで許容可能となります。95%ではなく94%、そして重要グループで18/20です。Bは両方で失敗します。まだAが勝者であるとは言えません。ピークメモリも所要時間も示されていないからです。さらに、合計値はどのドキュメントが変わったかを示していません。新たな重大なリグレッションを検出するには、対応するエラーを調べてください。

技術的な出典: 合計だけでなくエラーを調べる

差分を説明できる比較を実行する

まず比較の契約を用意し、次に結果ファイルを用意します。以下のプロトコルはご自身のワークロードで実施するものであり、前述の数値がそれを代替するものではありません。あるバリアントが読み込めない、または必要な演算子を備えていない場合は、その失敗を互換性の情報として残してください。

• コーパス、参照、モデル、tokenizer、prompt、出力ルールを固定し、長く難しいケースを識別可能なまま保ちます。
• キャリブレーション、エクスポートされたアーティファクト、実効構成を記録します。使用したデバイスと、起こり得る CPU/GPU 間の転送を確認します。
• 製造、読み込み、ウォームアップ、安定化した処理を分離します。同じ測定範囲を使い、生の繰り返しを保存します。
• デバイスごと、フェーズごとにピークを記録し、allocated と reserved は分けて保ちます。これらのカウンタを合計したり、それぞれの独立した最大値を差し引いたりしないでください。
• 合意した形式、内容、サブグループを評価し、識別子ごとにエラーを突き合わせます。
• 採用したアーティファクトを新しいプロセスで再読み込みし、定義済みのチェックを再実行します。エクスポート前に得た結果は、再読み込みを自動的に検証するものではありません。

技術的な出典: メモリを正しく測定する · 繰り返しと計測の定義

トレードオフを実際にかかったコストに結び付ける

メモリの節約は、検討できる構成を広げたり、より多くの並行処理を可能にしたり、単に余裕を残したりします。それは支出を自動的に減らすものではありません。期間、予約したロット、承認された成果物が同じままであれば、あるパスがより速くても、定額プランのコストは同じままです。

スケジュールには、必要に応じたキャリブレーション、量子化、評価、却下された試行、再読み込みを含めます。次に、基準を満たす選択肢間で 3 日、7 日、30 日の完全な定額プランを比較します。有用なコーパス当たりの比率は、実際に完了して承認されたコーパスでのみ計算できます。計測の繰り返しは新しい成果物を生みません。

1つのレンタルが複数の変種を比較するために使われる場合、その金額はキャンペーンの共通費用です。定額全体を各変種に頭の中で請求し、それらの金額を別々の実際の支出として合計しないでください。分析上の配分を行う場合は、規約を明示してください。それは確定済みの合計を変えるものではありません。

技術的な出典: IteraGPU — 一括プランと実験コスト

構成とその限界を添えて結論を出す

最終的な決定では、アーティファクト、環境、対象としたワークロード、達成した品質基準、改善した制約を明記します。バリアントが近い場合は、その不確実性を保持し、再読み込みして説明できると分かっている選択を優先してください。ビット数だけが優先順位ではありません。

短いコーパスでの結論が、そのまま長いコンテキスト、別の言語、より多くの同時リクエストに当てはまるわけではありません。推論用に採用した量子化が、ファインチューニングの学習可能なパラメータを定義するわけでもありません。これらの問いは分けて扱い、選択したバリアントをホールドアウトしたテストで確認してください。

実用的な質問