4-bit・8-bit量子化のメモリ品質検証設計

先に結論

bitsandbytes比較で必要なのは「4-bit対8-bit」という一列の順位ではなく、weight保存bit、4-bit compute dtype、量子化形式、double quant、device配置を分離した実験matrixです。full precisionまたは収容可能な基準構成を先に固定し、一度に一変数だけ変えます。model object、CUDA allocator、host processを別々に観測し、load時間、TTFT、decode速度、固定task品質、errorを同じrun IDへ結び付けると、memory節約を品質やCPU offloadの費用と取り違えずに判断できます。

確認日時: 2026年8月11日（Asia/Tokyo）
対象version: Transformers v5.15.0、commit 5eddc12。bitsandbytesは評価時に実install版を固定し、現行公式文書を2026年8月11日に確認。
検証区分: 公式文書に基づく机上調査・実験計画です。model、CUDA、bitsandbytesを実行しておらず、memory、速度、品質の実測値や優劣は示しません。
適用外: Apple Silicon、AMD ROCm preview、Intel XPU／Gaudi／CPU backendの性能、量子化済みcheckpoint固有の再量子化、training全体、複数node serving。

前提：再現単位をmodel名より細かくする

同じmodel名でもrevision、weight dtype、custom code、tokenizerが変われば比較は成立しません。評価開始時に次を一つのmanifestへ保存します。

区分	固定する値	主に防ぐ混同
software	Transformers、bitsandbytes、Accelerate、PyTorch、CUDA runtime、driver	kernelとloader差
hardware	GPU名／枚数、VRAM、CPU、host RAM、PCIe、power mode	offloadと速度差
model	repository、commit hash、config、元weight dtype、tokenizer revision	artifact更新
workload	prompt ID、入力token数、生成上限、batch、同時数、seed	負荷とsampling差
execution	cold／warm、反復数、timeout、他process、device map	cacheと競合

Transformers v5.15.0は2026年8月10日公開です。bitsandbytesは現行stable版を評価環境へinstallした後、文字列の「latest」ではなく実versionをmanifestへ記録します。modelはrevisionへcommit hashを渡し、remote codeが必要な場合はcode revisionと許可範囲も固定します。

比較対象は次の順で増やします。

収容可能なら元weightを使うfull precision reference
load_in_8bit=Trueの8-bit baseline
4-bit FP4、既定compute dtype
4-bit NF4、既定compute dtype
採用候補だけcompute dtypeをfloat16／bfloat16へ変更
採用候補だけdouble quantを有効化
最後にdevice mapと8-bit CPU offloadを変更

full precisionが収まらなければ、8-bitを運用baselineにはできます。しかし「8-bitとの差が小さい」ことはfull precisionとの差が小さい証明ではありません。小型の同系architectureで品質傾向を確認する実験と、本番sizeで収容性を確認する実験を分けます。

変数を分ける設定matrix

公式BitsAndBytesConfigではload_in_8bitとload_in_4bitは別の入口です。4-bitではbnb_4bit_quant_type、bnb_4bit_compute_dtype、bnb_4bit_use_double_quantを分けて記録します。

import torch
from transformers import BitsAndBytesConfig

conditions = {
    "int8": BitsAndBytesConfig(
        load_in_8bit=True,
    ),
    "fp4_default_compute": BitsAndBytesConfig(
        load_in_4bit=True,
        bnb_4bit_quant_type="fp4",
    ),
    "nf4_default_compute": BitsAndBytesConfig(
        load_in_4bit=True,
        bnb_4bit_quant_type="nf4",
    ),
    "nf4_bf16": BitsAndBytesConfig(
        load_in_4bit=True,
        bnb_4bit_quant_type="nf4",
        bnb_4bit_compute_dtype=torch.bfloat16,
    ),
    "nf4_bf16_double": BitsAndBytesConfig(
        load_in_4bit=True,
        bnb_4bit_quant_type="nf4",
        bnb_4bit_compute_dtype=torch.bfloat16,
        bnb_4bit_use_double_quant=True,
    ),
}

これは全条件を一度に回す推奨ではなく、差分を明示する定義例です。GPUがbfloat16をsupportしない場合、nf4_bf16以降は適用外にします。公式文書はNF4を4-bit base modelのtrainingに適した形式として案内し、inferenceではquant typeの性能差は大きくないと説明しています。したがって、NF4を無条件のinference勝者とは置きません。

double quantは量子化済みweightへ二段目の量子化を行う変数です。公式文書は追加memoryを節約できると説明しますが、対象model、loader、hardwareでの実測なしに速度や品質が不変とは断定しません。まずNF4とcompute dtypeを固定し、double quantだけを切り替えます。

配置は最後に変えます。device_map=“auto”でlayerがCPUへ移ると、quantization差ではなくPCIe転送やhost RAMがlatencyを支配し得ます。8-bit CPU offloadではCPU weightがfloat32で保存されるため、GPU memoryだけを見て「最小memory」と判断しません。trainingでは公式文書どおりdevice_map=“auto”を推論用とみなし、別設計にします。

観測方法：三つのmemoryを混ぜない

各runは新しいprocessで始め、model load前、load直後、warm-up後、steady state、解放後を採時します。

Model object

model.get_memory_footprint()を保存します。これは配置されたmodelの比較入口ですが、process全体のmemoryを代表しません。moduleごとのclass、dtype、deviceも集計し、量子化対象外moduleとCPU配置を残します。

CUDA allocator

run開始前にpeak統計をresetし、torch.cuda.max_memory_allocated()とmax_memory_reserved()を別々に保存します。allocatedはtensorが使う量、reservedはallocatorが確保したpoolを含むため同じ値ではありません。nvidia-smiなどdevice全体の使用量も採りますが、同居processがあればrunを無効扱いにします。

Host process

process RSSとsystem空きRAMを外部observerで採ります。CPU offload、file mapping、download cache、tokenizer、Python runtimeはmodel footprintだけでは見えません。container limitとswap発生も保存し、swapしたrunをGPU-only runと同じ速度比較へ入れません。

記録schemaの最小例です。nullは未測定を意味し、架空値で埋めません。

{
  "runId": null,
  "modelCommit": null,
  "transformers": "5.15.0",
  "bitsandbytes": null,
  "weightMode": "int8",
  "computeDtype": null,
  "doubleQuant": false,
  "deviceMap": null,
  "modelFootprintBytes": null,
  "cudaPeakAllocatedBytes": null,
  "cudaPeakReservedBytes": null,
  "hostPeakRssBytes": null
}

時間と品質の測り方

時間は少なくとも次へ分解します。

load時間: from_pretrained開始からmodel利用可能まで
TTFT: request受付から最初の生成tokenを受け取るまで
decode速度: 最初のtoken後から終了までの生成token数／秒
end-to-end: tokenize、転送、queue、generation、decodeを含むwall time

一つのgenerate()終了時間だけではTTFTとdecodeを分けられません。streamerまたはgeneration loopのcallbackを使い、最初のtoken時刻を別に記録します。warm-up runを測定値へ混ぜず、cold load、最初の生成、steady-state反復を分けます。入力token数と実生成token数が違うrunは、単純な秒数だけで比較しません。

品質は固定したtask setで評価します。chat template、system prompt、stop条件、最大token、samplingを固定し、決定的比較ではdo_sample=Falseを使います。最低限、次を別列にします。

exact matchやunit testで判定できるcode／構造化出力
task固有の正答率または人手rubric
空出力、NaN、例外、反復、途中打切りのfailure率
referenceに対するtoken差と意味差。ただしreference自身を真実とみなさない

10件程度の都合のよいpromptだけで全domainへ一般化せず、短文／長文、言語、推論、code、tool形式を利用実態に合わせてstratifyします。量子化設定を見ながら評価者が採点すると期待biasが入るため、可能ならcondition名を伏せます。

Promotion gateとtrade-off

thresholdは記事側で捏造せず、serviceの既存SLOと品質基準へ結びます。最低限のpromotion gateは次です。

全必須taskがexception、NaN、空出力なしで完了する
固定quality setが許容下限を満たし、特定bucketだけ崩れていない
GPU peak、host RSS、load時間、TTFT、decodeが運用上限内にある
同じconditionの反復で結論が逆転しない
model、software、device map、測定raw recordから再現できる

8-bitは4-bitよりweight memoryを多く使い得る一方、outlierを高精度経路で扱うLLM.int8()の特性があり、modelとtaskによって品質・速度のtrade-offが変わります。4-bitはさらに収容性を高め得ますが、compute dtypeとquant typeの選択が増えます。double quantは追加節約の候補ですが、差が小さければ複雑さを増やす価値がない場合があります。CPU offloadはGPUへ収める手段であって、host RAMと転送latencyを消す機能ではありません。

ここで採用した設定を別model revision、別GPU、長いcontext、複数requestへそのまま広げません。continuous batchingのqueue、KV cache、同時requestによるpeakはmodel weight比較とは別の実験です。複数requestの設計はTransformers連続バッチング入門、単体modelの最初の成功はTransformersの4-bit・8-bit量子化入門へ分けています。

未検証範囲と判断基準

本稿はNVIDIA CUDA推論を中心にした机上計画です。Transformers main文書はNVIDIA、Intel XPU、Intel Gaudi、CPUを対応matrixへ掲げ、bitsandbytes installation guideはAMD ROCmとApple Siliconを追加platformとして扱いますが、backendごとにwheel、minimum version、feature成熟度が違います。未検証backendへCUDAの結果を移植しません。

4-bit／8-bitでのtrainingは公式文書上、追加parameterのtrainingに限定されます。full parameter training、optimizer state、gradient、activation memoryは本稿の推論matrixとは別です。量子化済みcheckpointをさらにon-load量子化する経路、Hubへpushするversion条件、model license、remote code、multi-GPU通信も個別gateが必要です。

導入判断は「最小bit」ではなく、品質gateを満たす条件の中でGPU／host memoryとlatencyの総費用が最小になる構成を選びます。差が測定noise内なら、設定が単純でrollbackしやすい方を採用します。

入門記事

最初の1回を安全に成立させる場合は、Transformersの4-bit・8-bit量子化入門で、対応環境、8-bit生成、4-bitへの切替、配置とmemory footprintの確認から始めてください。

参考資料

Transformers Bitsandbytes（2026年8月11日確認。hardware matrix、8-bit、4-bit、CPU offload、NF4、compute dtype、double quantを確認）
Transformers Quantization API（2026年8月11日確認。BitsAndBytesConfigのfieldと既定値を確認）
Bitsandbytes Installation Guide（2026年8月11日確認。Python／PyTorch、CUDA、XPU、Gaudi、CPU、preview backendの条件を確認）
bitsandbytes公式repository releases（2026年8月11日確認。stable／preview artifactの区別を確認）
Transformers v5.15.0 release（commit 5eddc12、2026年8月10日公開、2026年8月11日確認）