実際にどの量子化フォーマットを使うべきか。

ここから始める

このページの大部分は計算ですので、まず結論から述べます。形式を決めるのは4つの質問であり、それぞれが単独で結論を出せるため、この順番で尋ねます。

この先の内容はすべて、その4つの答えがなぜそうなるのかを説明し、当社のモデルではなくあなた自身のモデルに対して検証できる数値を示すものです。そもそも自分のモデルにどれだけのメモリが必要かをまだ把握していない場合、その計算は別のガイドにまとめてあり、そちらを先に読むべきです。

3つの形式、4つの名称

推論に一般的に使われる数値形式は3つしかなく、違いはただ1つ、パラメータ1つあたり何バイトかかるかです。それ以外のAWQ、GPTQ、GGUF、bitsandbytes—はすべて、この3つのいずれかを生成するための手法であり、4つ目の形式ではありません。

2つの数値列は対として読んでください。最初の2行では等しく、3行目では等しくありません。この1つの非対称性が、このページの後半で見られる意外な結果の大半の原因です。

モデルリポジトリで実際に目にする4つの名称は、この表に次のように対応します。

それぞれを指定するのはフラグ1つだけです。これらはvLLMガイドで詳しく扱っているのと同じオプションです。ここで言いたいのは、その違いがいかに小さいかということだけです。

# 1. Reference. The weights as published, nothing to prepare.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct --dtype bfloat16

# 2. FP8, quantised while it loads. No second download, no calibration.
#    --kv-cache-dtype is the half everyone forgets: it is what
#    halves the CACHE as well as the weights.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct \
    --quantization fp8 --kv-cache-dtype fp8

# 3. Four-bit AWQ. A DIFFERENT checkpoint, prepared by someone else.
$ vllm serve casperhansen/llama-3.3-70b-instruct-awq \
    --quantization awq_marlin

# 4. Four-bit GPTQ. Same idea, different repository and flag.
$ vllm serve TechxGenus/Llama-3.3-70B-Instruct-GPTQ \
    --quantization gptq_marlin

縮まらない半分

重みを4 bitに量子化しても、key/valueキャッシュは量子化されません。AWQとGPTQは重みだけを圧縮対象とし、キャッシュを別途FP8にするよう指定しない限り16 bitのままです。そして4-bitのチェックポイントでは、ほとんどの人がそれを行いません。これが上の表の3列目であり、以下の計算が誰の予想通りにもならない理由です。

その帰結が最もわかりやすいのは、1つのモデルで見た場合です。以下は、コンフィギュレーターが提供する各コンテキスト長における4-bitのLlama 3.3 70Bです—重みとキャッシュを対比しています。

重みの列は動きません—それこそが量子化する意味そのものです。キャッシュの列はコンテキストに比例して増え続け、最後の行では、そのモデル自体よりも大きくなります。

それを十分押し進めると、4-bitはまったく優位を保てなくなります。FP8は両方の半分を半減させますが、4-bitは一方の半分を4分の1にし、もう一方には手を付けません。そのため、どのモデルにも両者が逆転するコンテキスト長が存在し、モデルが小さいほどそれは早く訪れます—小さいモデルは節約できる重みが少ない一方で、トークンあたりのキャッシュの増え方は変わらないからです。

数値はギガバイト単位で、2つの形式のうち小さい方を示し、負けた方の形式は下に記載しています。左から右へ読み進めると、コンテキストが伸びるにつれて4-bit列の優位性が失われていく様子がわかります。

最後の行はどこでも優位を保ち続けます。700億パラメータともなれば、節約できる重みの量が非常に大きいからです。中央の行は互角に終わります。128kでは、Qwen 3 32Bはどちらの形式でも費用がまったく同じになり、品質を考えればFP8を選ぶことになります。そして最初の行は完全に逆転し at 128k、そこでは4-bitがFP8より多くのメモリを要求しながら、忠実度は2つのうち低い方になります。この組み合わせ—メモリは多く、出力は劣る—が、当社が目にする中で最もよくある量子化の失敗であり、重みファイルのサイズだけを見ていては気づけません。

お使いのカードが実際にできること

FP8は、ソフトウェアの機能である以前に、ハードウェアの機能です。テンソルコアがFP8に対応していないカードでも、FP8のチェックポイントを読み込むこと自体はできます—スタックが乗算の前に重みを16 bitに展開するからです—ですが、得られるのはダウンロード容量の節約だけで、速度面の恩恵はなく、FP8キャッシュもまったく使えません。4-bitはその逆で、どこでも動作します。演算の前にどのみち重みが16 bitに展開されるからです。

この列が説明しているのはシリコン側の話であり、FP8がどこで有効かという問いとは、実は少し違います。カタログ自身がこの形式に添えている注記はHopper and Blackwellを挙げていますが、これはテンソルコアではなく推論スタックについての言明です。つまり、FP8カーネルとFP8キャッシュが最も多く使われ、最も予想外の事態が少なかった世代だということです。Ada Lovelaceでも動作します。HopperとBlackwellは、それに依存するデプロイを置くべき世代です。

カードを選ぶ前に知っておく価値がある、もう1つの点です。Llama 3.3 70BをFP8で8kコンテキストにて動かすには81.9 GBが必要ですが、80 GBのカード—中でもNVIDIA A100 PCIe—はそれに1.9 GB足りません。表計算上は目立つほどの不足ではありませんが、実機では確実に失敗するだけの不足です。単独でこれをクリアできるカードは1つ上のクラスであり、コンフィギュレーターを使えば、支払う前にどのカードかがわかります。

速度面で得られるもの

1つのトークンを生成するとは、アクティブな重みをメモリから1回読み出すことを意味します。重み1つあたりのバイト数が少ないほど読み出すバイト数も少なくなり、毎秒のトークン数は増えます—1つの非バッチストリームでは、この関係はほぼ線形です。カードが他に何も待つ必要がないからです。これは、トークン単価ガイドが割り算に使っているのと同じメモリ帯域幅の上限であり、意図的に保守的な値です。以下では、当社が貸し出しているすべてのシングルカードマシンで動作するほど小さいモデルにこれを適用しており、形式とカードを同じ表から読み取れるようにしています。

Llama 3.1 8Bを1枚のカードで、同時に1ストリームずつ。掲載されているすべてのマシンが三つのフォーマットすべてに対応しているため、行は縦方向だけでなく横方向にも比較できます—そして三列の比率はどの行でも同じです。それは重みあたりのバイト数だけで決まるからです。

この表を読む際に注意すべき点が2つあります。1つ目は、この表が1度に1リクエストの場合を記述している点です。実際には1度に1リクエストだけを処理することはほとんどなく、連続バッチ処理のもとでは重みはバッチ全体につき1回しか読み出されないため、制約はメモリではなく演算能力になり、列間の比率は縮まります。2つ目は、逆量子化にはコストがかかるという点です。4-bitの重みは乗算の前に展開する必要があり、小さいモデルでバッチサイズが小さい場合、その展開処理が、読み出しが小さくなったことで得られた分の目に見える割合を食いつぶすことがあります。この表が示す方向性は信頼できますが、正確な倍率までは保証されません。

かかるコスト

この話題においては、自信満々な数値ほど疑ってかかるべき部分であり、それは当社の数値も例外ではありません。量子化による誤差は、手法よりもモデルにはるかに大きく左右され、公開されている比較結果同士が食い違うのは、異なるモデルを異なるタスクで測定しているからです。正直に言えるのは、その大まかな傾向だけです。

そこから導かれる、このページで唯一計算によらない推奨は「両方動かしてみる」ことです。rootアクセスがあり、従量課金も一切ないマシンを借りているのですから、同じモデルを2つのポートでそれぞれ立ち上げ、自分の手で百件のプロンプトを流し込んでも、かかるのは一晩だけです。それによって、他人ではなく自分のワークロードについて答えが出ます。これはどんな表よりも、この表を含めて、実質的に優れた答えです—だからこそ私たちは、スコアよりも計算式をお見せしたいのです。

それが意味するマシン

これらすべてが重要になるのは、結局のところ請求書のためです。以下は、当社のカタログの中で、8kコンテキストにおいて各モデルを3つの形式それぞれでまるごと収容できる最安のマシンです—「まるごと」とは1枚のカードに収まり、分割しないという意味です。カードをまたいで分割されたモデルはインターコネクトの話を持ち込むことになり、それは別のガイドの範囲です。

8kコンテキストにおいて、実際に当社が貸し出しているマシンでの数値です。セルにカードが複数記載されている場合、それはモデルの分割ではなく、そのカードが提供される最小のノード構成を意味します。最も大きなカードは4枚組や8枚組でしか販売されておらず、フル精度の70Bを分割せずに済ませる最も安い方法は、4枚組を1台買って1枚だけ使うことです。これはまさに、量子化が回避しようとしている出費そのものです。

この表を正しく使えるかどうかを分けるのは、二つの習慣です。モデルの最大値ではなく、実際に運用するコンテキストでサイズを決めること—このページの二番目の表は、両者を混同した人に何が起きるかを示しています。そしてフォーマットは注文前にカードと照合すること、後からではありません。NVIDIA RTX A6000, NVIDIA A100 PCIeとNVIDIA A100 SXM4は、どのフラグを渡してもFP8の数値を返しません。コンフィギュレーターは、支払いの前に、あらゆるノードとあらゆるフォーマットについて、必要なメモリ量と1枚のカードに収まるかどうかを教えます。そもそもレンタルするかトークン課金のAPIを使うかを比較しているなら、その損益分岐点は別途計算されており、量子化はそれをハードウェア側に大きく有利に動かします。