LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

Blog


【インターンレポート】量子化による大規模言語モデル軽量化の効果測定

この度、LINEの技術職 就業型コースのインターンシップに参加させていただきました、お茶の水女子大学修士課程1年の佐藤杏奈と申します。
インターンシップではNLP Platform Devチームに所属し、量子化による大規模言語モデル(LLM)の軽量化について検証を行いました。本レポートではその成果について、ご報告いたします。

0. 大規模言語モデルの量子化とは

量子化とは、重みなどのパラメータをより少ないビットで表現することで、モデルの軽量化、高速化を図る手法の一つです。
昨今活躍する大規模な言語モデルの多くは数十億、数百億以上のパラメータを持っており、これらの訓練には通常、多くのGPUで数ヶ月と、膨大なコストが必要になります。また、そのようにして訓練させたモデルは、別の特定の用途に合うようにチューニングすることはもちろん、モデルを動かすことも簡単ではありません。大きなモデルであるほどメモリが必要になり、生成・推論のコストがかかるため、モデルを扱うためにも充実した計算環境が求められます。

そこで今回は、そんな大規模言語モデルをよりコストを抑えて扱えるようにすることを目標に、モデルの軽量化について、二つのテーマで調査を行いました。

まず一つ目は、FP8を用いた言語モデルの高速化です。FP8とは8bitの浮動小数点のことを指し、通常32bitや16bitで計算されている言語モデルに対して、一部のレイヤで低い精度に落として計算を行うことで、速度や性能にどのような影響が出るかを検証します。結果として、FP16に比べて大きなモデルで最大1.2倍の推論高速化、ファインチューニングを行う実験ではFP32に比べて3.7倍の高速化が確認できました。

そして二つ目は、『GPTQによる量子化モデルの効果測定』です。GPTQという量子化手法を用いて言語モデルを再構築し、モデルの軽量化、性能の変化について評価を行います。この量子化による大きな性能低下はなく、モデルのサイズが1/3、VRAM使用量が半分ほどになることが確認できました。

1. FP8を用いた言語モデルの高速化

FP8について

昨年2022年、NVIDIA社からHopperアーキテクチャを採用した新しいGPU「H100」が発表されました。このH100に搭載されている第4世代のTensorコアは今までのGPUにはない8bit浮動小数点(FP8)の演算をサポートしており、新しく2種類のFP8が導入されました。(図:NVIDIA Blogより引用

最近の大規模言語モデルでは、精度とメモリ効率の良さを考慮して、単精度FP32ではなく、半精度FP16が多く採用されている印象があります。日本語言語モデルだと、LINEのjapanese-large-lm、CyberAgentのOpenCALM、rinnanの3.6B PPOモデルなどがその一例です。今回導入されたFP8は、FP16BF16と比較して、さらにメモリ要件を半分、スループットを2倍にすることができます。大規模言語モデルにFP8を採用できれば、大幅なコスト削減、また、推論の高速化が期待できます

実際に、FP8を使用して言語モデルを訓練したときのパフォーマンスを評価しているMosaicMLのtechブログでは、7B(70億パラメータを持つ)モデルの訓練にかかる時間と費用を見積もったところ、A100+BF16で訓練を行った場合と比較して、H100+FP8での訓練は3倍高速であり、訓練にかかる費用が77%ほどに削減したと報告しています。また、速度とトレードオフの関係にある性能について、NVIDIA、Arm、Intelが共同執筆したホワイトペーパーでは、深層学習モデルの訓練や推論において、FP8モデルはベースラインのFP16モデルと比べて同等の精度が得られることも報告されています。

言語モデルでFP8精度を使うには

TransformerモデルでのFP8精度をサポートをしてくれるのが、Transformer Engineです。Transformer Engineは、H100で新たに搭載されたソフトウェアエンジンで、高い数値精度と低い数値精度をレイヤによって使い分ける混合精度を用いて、モデルの性能低下をできるだけ抑えつつスピードアップを図ることができます。

本レポートの実験では、学習済みモデルで混合精度FP8を使うのにHuggingFaceAccelerateを使用しています。Accelerateは、Transformer Engineが統合されたライブラリの一つで、transformersのモデルを以下のように混合精度FP8のモデルに切り替えることができます。

from transformers import AutoModelForCausalLM
from accelerate import Accelerator
 
model_name = "line-corporation/japanese-large-lm-1.7b"
model = AutoModelForCausalLM.from_pretrained(model_name)
 
accelerator = Accelerator(mixed_precision="fp8")
model = accelerator.prepare_model(model)

今回は、そのTransformer EngineAccelerateを使用して、学習済み言語モデルをFP8精度で動かしたときの速度変化、性能変化について以下の3つの実験で調査しました。

(Ⅰ) 行列乗算の処理速度
(Ⅱ) 推論速度
(Ⅲ) ファインチューニングのパフォーマンス

本章の実験環境は以下の通りです。

・NVIDIA H100 80GB PCIe x 1
・TransformerEngine 0.9.0
・Accelerate 0.20.3

(Ⅰ) 行列乗算の処理速度

まず、深層学習モデルの主力である行列乗算のパフォーマンスをさまざまな次元で比較しました。下のグラフは、サイズ B x K の行列を K x K で乗算した場合の、FP32精度を使用したときに対する、FP16精度、FP8精度を使用したときの相対速度を示しています。

結果から、大きな行列乗算になるほど、より高速化につながることがわかり、FP32の処理速度に比べてFP16は最大12倍、FP8は最大21倍の高速化となりました。

NVIDIAのページに基づくとH100 PCIeのスペックは、FP3251TFLOPSFP16756TFLOPSFP81513TFLOPSであり、理論値はFP16FP32のおよそ15倍、FP830倍の高速化となります。どちらもそれまでには及ばなかったものの、FP8FP16と比較したときに倍のFLOPSの処理性能を持っており、その理論値に近い、1.8倍ほどの高速化が確認できました。

この結果は行列と行列の乗算、つまりLinearレイヤのみに限定された話です。LayerNorm、softmax、要素ごとの処理なども含まれる言語モデルの場合、どの程度の高速化になるのか、次の章で確認します。

(Ⅱ) 推論速度

上の実験より、FP8演算は大きな行列乗算になるほど高速になることが確認できたので、ここではパラメータ数の大きい以下の3つの日本語言語モデルを用いて、推論速度の比較を行います。(BはBilionを表しており、1Bモデル=10億のパラメータを持つモデルという意味になります。)

・6.8Bモデル(cyberagent/open-calm-7b
・3.6Bモデル(line-corporation/japanese-large-lm-3.6b
・2.7Bモデル(cyberagent/open-calm-3b

限られたメモリでバッチサイズを大きくすることに焦点を当てるため、出力長を16トークンに限定し、比較しました。下のグラフは、すべてのパラメータをFP16精度で持つモデルに対する、混合精度FP8を使用したモデル(FP16+FP8)の相対推論速度を示しています。

実線と破線はそれぞれ、生成方法として貪欲法とサンプリングを使用したときの速度を表していますが、重なっており、ここでは生成方法は重要ではないことがわかります。どのFP8モデルも、バッチサイズを大きくしていくとFP16モデルより速くなり、最大1.10~1.15倍ほどの高速化となりました。

本レポートの実験はすべて、H100(80G)1枚のみで行っているため、使用できるメモリに限りがあります。この中で最も大きい6.8Bモデルはバッチサイズ1024が試せる最大の値でしたが、バッチサイズをより大きくすることができれば、さらに高速化が見込めると考えられます。また、行列演算の実験で、K=16384のときに比較的小さいバッチサイズ(<1000)でもFP8の演算速度がFP16の演算速度を上回っていることから、より大きい行列乗算を行う、パラメータ数の大きいモデルになると、この実験ほどバッチサイズを上げずに高速化が見込めると期待されます。

一方で、学習済みモデルを混合精度FP8で扱うときの高速化について重要となるのは、モデルのパラメータ数だけではないようです。モデルのアーキテクチャと大きさが違う以下の4種類のモデルで比較をしてみます。

下のグラフは、すべてのパラメータをFP32精度で持つモデルに対する、混合精度FP16を使用したモデル(FP32+FP16)と混合精度FP8を使用したモデル(FP32+FP8)の相対推論速度を示しています。ここで、バッチサイズは4096、出力長は16トークンに固定しています。

GPT NeoXモデルである左の二つは、FP16モデルとFP8モデルであまり推論速度に違いはありませんが、GPT-2モデルである右の二つは、大きなモデルになるほど両者で大きく差が出ていることがわかります。この理由はモデル内部のTransformerブロックの実装が異なるためです。

以下で示すように、Transformer内部のAttentionMLPの実装にGPT-NeoXではLinear()が使われている一方、GPT-2ではConv1D()が使われています。本レポートの実験の設定では、混合精度FP8モデルとしたときに、LinearレイヤはFP8精度の演算対象となりますが、Conv1Dレイヤはそのままの高い数値精度(FP32、FP16)での演算となります。そのため、同程度のパラメータ数を持っていても、上記のような差がでてしまうようです

GPT-NeoX(OpenCalm-medium)
GPTNeoXLayer(
  (input_layernorm): LayerNorm((1024,), eps=1e-05, elementwise_affine=True)
  (attention): GPTNeoXAttention(
    (query_key_value): Linear(in_features=1024, out_features=3072, bias=True)
    (dense): Linear(in_features=1024, out_features=1024, bias=True)
    (attention_dropout): Dropout(p=0.0, inplace=False)
  )
  (post_attention_layernorm): LayerNorm((1024,), eps=1e-05, elementwise_affine=True)
  (mlp): GPTNeoXMLP(
    (dense_h_to_4h): Linear(in_features=1024, out_features=4096, bias=True)
    (dense_4h_to_h): Linear(in_features=4096, out_features=1024, bias=True)
    (act): GELUActivation()
    (post_mlp_dropout): Dropout(p=0.0, inplace=False)
   )
)
GPT-2(Rinna-medium)
GPT2Block(
  (ln_1): LayerNorm((1024,), eps=1e-05, elementwise_affine=True)
  (attn): GPT2Attention(
    (c_attn): Conv1D()
    (c_proj): Conv1D()
    (attn_dropout): Dropout(p=0.1, inplace=False)
  )
  (ln_2): LayerNorm((1024,), eps=1e-05, elementwise_affine=True)
  (mlp): GPT2MLP(
    (c_fc): Conv1D()
    (c_proj): Conv1D()
    (act): NewGELUActivation()
    (dropout): Dropout(p=0.1, inplace=False)
  )
)

(※見やすさのため、一部順番を入れ替えています。)

(Ⅲ) ファインチューニングのパフォーマンス

次に、FP8精度を採用することでの性能の変化について調査します。

ここでは、上の実験で使用したGPT-NeoX 1.7Bモデル(cyberagent/open-calm-1b)をJNLIというタスクに対してファインチューニングを行ないます。JNLIは、日本語理解ベンチマークJGLUEの一つで、2文が与えられたときに、それらの関係を「含意」「矛盾」「中立」の3つで分類するタスクです。

ここまでの実験から、FP16精度もFP8精度も、バッチサイズを大きくしたときにより効果的になることがわかったので、バッチサイズを64と少し大きめに設定して学習を行います。他のハイパーパラメータは以下の中でグリッドサーチを行いました。

・learning_rate = {1e-5, 5e-5, 1e-4, 5e-4}
・epoch = {1,2,3,4}
・optimizer = {Adam}

訓練・評価にはHuggingface datasetsのデータを用い、訓練/検証/評価データ数はそれぞれ 18048/1984/2434 です。

以下の表は、すべてFP32精度で訓練したモデル、混合精度FP16で訓練したモデル(FP32+FP16)、混合精度FP8で訓練したモデル(FP32+FP8)それぞれの、訓練の1ステップにかかる時間と訓練後のタスク正答率を示しています。

精度
ms/Training Step
Accuracy

FP32(base)

900
(1.00x)

89.4

FP32+FP16

234
(3.85x)

30.2

FP32+FP8

246
(3.66x)

87.8

まず速度の点では、FP32精度のみを使用したモデルに比べて、混合精度FP16やFP8を使用すると、3倍以上の高速化が見られました。一方気になるのは、モデルの性能の点です。タスクの正答率を見ると、混合精度FP8モデルは、ベースラインとなるFP32モデルに比べると2ポイントほどの低下に留まっていますが、混合精度FP16モデルでは遥かに下回る結果となりました。

実験コストの都合上、今回は一つのタスク、特定のデータでのみのファインチューニングを行っており、ハイパーパラメータの設定も限られています。今回の設定内に、混合精度FP16モデルの性能がベースラインほど高くなるハイパーパラメータがなかったという可能性も考えられるため、FP16精度での性能低下とFP8精度での性能低下を比べることはできません。

ですがこれらの結果は、FP32モデルに対して混合精度FP8を使用した場合、元のモデルと近い性能を保ちつつ、大幅な訓練時間削減が可能であることを示唆しています。またこの実験内では、FP8モデルはFP16モデルの速度を上回ることはできませんでしたが、より大きいモデルになるとFP16モデルを上回り、さらなる高速化を図れるのではないかと考えられます。

FP8による影響まとめ

ここまで、言語モデルで FP8精度を採用したときの速度、性能の変化について検証を行いました。

大きなモデルで最大1.2倍の推論高速化

FP16モデルと、混合精度FP8モデルの推論速度を比較したところ、大きなモデル、大きなバッチサイズで最大1.2倍ほどの高速化が見られました。行列乗算のみの処理速度では、FP16と比較するとFP8は最大1.8倍ほど高速でしたが、言語モデルに含まれる処理は行列乗算のみではないため、エンドツーエンドの推論はそれより小さい速度向上になってしまうのは当然の結果と言えます。

混合精度の場合、入力値の精度を下げる量子化の処理に加えて、次のレイヤに流すために圧縮前の精度に戻す逆量子化の処理も必要となります。小さいモデル、小さい設定だと、そのようなあらゆるオーバーヘッドが大きく、むしろ速度が下がってしまうことの方が多いというのは良い発見だと考えています。

よりFP8の恩恵を受けるには

本実験はすべてH100 1枚で行いましたが、より多くのGPUが使用できる場合、速度向上の肝となる行列乗算のサイズを大きくすることができ、さらなる高速化が期待できます。

また、今回の実験ではFP16+FP8の混合精度だと利点が感じにくかった一方で、実験では、FP32+FP8の混合精度はFP32と比較しておよそ3.7倍の速度向上が確認できました。また、ベースラインより大きく性能を落とさずに大幅な速度向上が見られたことから、小さいモデルでもFP32+FP8の混合精度を使う利点は十分にあり、今後新しい選択肢になりうると考えます。

続いて、二つ目のテーマです。

2. GPTQによる量子化モデルの効果測定

GPTQとは

量子化には、訓練後のモデルに対して量子化を行うPost-Training Quantization(PTQ)と、量子化に合わせてweightの値を学習するQuantization-Aware Training(QAT)がありますが、中でも今回扱うGPTQはPTQの一つです。

詳しい手法の説明は割愛いたしますが、GPTQGPU上で優れた性能を発揮する手法で、量子化前後の誤差が小さくなるように調節用のキャリブレーションデータを用い、One shotで高精度かつ効率的な量子化を可能にします。論文では、1,750億のパラメータを持つGPTモデルを量子化することで、圧縮前の元のモデルと比べて妥当な精度を維持しつつ、80GB GPU1枚でのモデルの推論を可能にしたと報告されました。

GPUQはAutoGPTQというライブラリで使用でき、モデルの量子化だけでなく、HuggingFace Hub上の量子化モデルのアップロード/ダウンロードも複雑な手続きなしに行うことができます。

ここでは、量子化モデルを構築し、その効果について検証していきます。

モデルの軽量化

現在LINEからは、3.6B1.7Bの基盤モデル、また、それらをInstruction TuningしたSupervised Fine-tuningSFT)モデルが公開されています。

line-corporation/japanese-large-lm-1.7b
line-corporation/japanese-large-lm-3.6b
line-corporation/japanese-large-lm-1.7b-instruction-sft
line-corporation/japanese-large-lm-3.6b-instruction-sft

同等の性能を持つ他の日本語モデルと比較するとこれらは大きいモデルではありませんが、3.6Bというサイズは特に、大半の個人ユーザーにとっては扱いやすいモデルとは言えません。そこで今回は、LINESFTモデルの量子化を行い、モデルの軽量化を試みます。

GPTQにはいくつかの量子化パラメータが存在し、それらは速度、性能などの点でトレードオフの関係にあります。以下はその一部です。

・Bits: 量子化モデルのビットサイズ。
・Group Size: 量子化を行うブロックのサイズ。-1は列ごとの量子化を意味する。大きいとVRAM使用量が下がるが、性能も低下する。
・Act Order: Activationの大きさが小さい順に量子化するかどうか。Trueだと速度が低下するが、性能が上がる。

量子化のためのキャリブレーションデータには、C4データセットの開発データを使用しました。特に、基盤モデルの訓練データにも使用されたHojiCharを用いてクリーニングされたデータから、GPTQの論文と同じ、2048トークン128文を抽出し、使用しました。

今回は、複数試した量子化モデルから特徴的だった設定のモデルに対して、元のモデルと比較を行います。以下の表は、それぞれのモデルの量子化パラメータ、モデルサイズ、推論速度、VRAM使用量を示しています。ここで、推論速度、VRAM使用量はそれぞれ、512トークン生成させたときの1トークンあたりの時間と、最大のVRAM使用量を指します。

LINE-3.6B SFT

モデル名

Bits

Group Size

Act Order

Model Size(GB)

Inference Speed(ms/token)

VRAM usage(GiB)

LINE-3.6b(Original) 16 - -

6.7

34.5

9.16

gptq-4bit-128g-actorder_False

4 128 False 2.3 32.9

4.62

gptq-4bit-32g-actorder_False

4 32 False 2.5

33.9

4.76

gptq-8bit--1g-actorder_True

8 -1 True 3.8

36.9

6.07

LINE-1.7B SFT

モデル名

Bits

Group Size

Act Order

Model Size(GB)

Inference Speed(ms/token)

VRAM usage(GiB)

LINE-1.7b(Original) 16 - -

3.1

13.7

5.39

gptq-4bit-128g-actorder_False

4 128 False 1.2

13.3

3.28

gptq-4bit-32g-actorder_False

4 32 False 1.3

13.3

3.31

gptq-8bit--1g-actorder_True

8 -1 True 1.9

16.1

3.93

結果から、3.6B1.7Bモデルも、元のモデルと比べて1/21/3程度のモデルサイズ圧縮となりました。推論速度は大きく変わらなかったものの、VRAMの使用量も半分ほどに減少しています。
3.6Bの量子化モデルと量子化前の1.7Bモデルを比較すると、モデルサイズ、VRAM使用量が下がっているのも興味深いです。

ただ軽量化したこれらのモデルが、全く使い物にならないのでは意味がありません。これらの量子化モデルは、元のモデルとどの程度異なる振る舞いをするのでしょうか。

量子化モデルの性能

3.6Bの量子化モデルで、最も軽量化できた設定のモデル(gptq-4bit-128g-actorder_False)と、パラメータの設定より最も性能低下が抑えられていると考えられるモデル(gptq-8bit--1g-actorder_True)を対象に、いくつかの質問に対する回答を掲載します。比較として、1.7B SFTと3.6B SFTの量子化前のモデルの回答も掲載します。

ここで、seed値は42に固定し、生成パラメータは以下の通りです。

・max_length = 128
・do_sample = True
・temperature = 0.7
・top_p = 0.9
・top_k = 0
・repetition_penalty = 1.1

四国の県名を全て列挙してください。

gptq-4bit-128g-actorder_False(3.6B)

高知県、徳島県、香川県

gptq-8bit--1g-actorder_True(3.6B)

香川県、愛媛県、徳島県、高知県

LINE-3.6B

四国は、徳島県、香川県、愛媛県、高知県の4つの県で構成されています。

LINE-1.7B

1.香川県
2.愛媛県
3.徳島県
4.高知県
5.福岡県
6.佐賀県
7.長崎県
8.熊本県

部屋をきれいに保つコツを教えて下さい

gptq-4bit-128g-actorder_False(3.6B)

きれいな部屋を維持するには、掃除をしやすくすることが大切です。まず、毎日家中の床の掃除機がけをしましょう。これは、リビングルーム、ベッドルーム、バスルームなど、すべての部屋の床に掃除機をかけることをお勧めする理由です。そうすることで、1日24時間のうち、少なくとも1時間は掃除機をかける時間を確保することができます。次に、週に3回、床の拭き掃除をします。この頻度であれば、他の家事とバッティングすることもないでしょうし、1日にわずか10分ほどの時間があれば可能です。最後に、家を出る前に必ず掃除機をかけてください。そうすれば、家で一日を過ごすときにも、清潔な状態を保てるのです。

gptq-8bit--1g-actorder_True(3.6B)

きれいに整頓された部屋は、きれいな状態で維持するために少しの努力が必要ですが、そうすることで、より良く維持することができます。まず、毎日掃除をすることから始めてみましょう。例えば、朝起きたときや、夜寝る前に掃除機をかけることができます。また、毎週末にまとめて掃除をする人もいますが、これはあまりおすすめできません。なぜなら、その週に汚れた場所を掃除するだけでいいからです。そのため、毎日少しずつ掃除をするのが理想的です。

掃除機をかけたら、床に何も置かないようにしましょう。床は、あなたの家を清潔に保つための出発点です。ラグやカーペットがある場合は、まずそれらを外します。ラグやカーペットは、それ自体に多くの汚れが集まるので、部屋が不潔に見える原因となります。そして、ラグやカーペットを取り除いたら、掃除機をかけてください。

最後に、部屋に物を置いている場合は、必ず定位置に戻すようにしましょう。使ったものをすぐに元の場所に戻さない人は、部屋を散らかしっぱなしにする傾向があります。また、使ったものは、できるだけ一箇所にまとめておくことで、探し物を探す時間を減らすことができます。

LINE-3.6B

部屋を清潔に保つには、いくつかのコツがあります。まず、毎日掃除する習慣を身につけることが必要ですが、部屋が汚れてきたと感じたら、すぐに掃除を始めましょう。床にはできるだけ物を置かないようにします。クローゼットに収まるだけしか服を持たないようにしましょう。食器洗い機があるなら、活用するとよいでしょう。このような基本的なルールを守ることで、部屋は清潔になり、維持しやすくなります。

LINE-1.7B

1.部屋をよりよくきれいにするために、あなたのニーズと好みに基づいて部屋を整理することを学ぶことが最善です。

2.定期的に掃除して清潔に保つことが重要です。これには、オブジェクトを移動するか、床を清潔できれいに保ち、きれいな表面を維持する必要があります。

3.スペースとリソースの合理的な使用を確保することも重要です。これは、タスクを実行するためにスペースを使用する必要があるため、タスクを実行できる場所を選択することを意味します。

4.定期的に換気し、空気の質を改善するために窓またはドアを開けることを忘れないでください。

5.快適に感じるように家具や装飾を配置します。

夜中にカップラーメンを食べてしまったときの自分を納得させる言い訳を教えてください。

gptq-4bit-128g-actorder_False(3.6B)

夜中にカップ麺を食べると太ると言いますが、実はそうではありません。なぜなら、麺の炭水化物は消化されにくいので、血糖値の上昇が緩やかで、脂肪を蓄積しにくいからです。さらに、タンパク質を多く含み、1日に必要な栄養素を摂取することができるため、健康的な選択肢と言えます。また、夜中に食べると太りやすいという人もいるかもしれませんが、これは都市伝説です!

gptq-8bit--1g-actorder_True(3.6B)

夜中にカップラーメンを食べてしまった時の言い訳として、次のようなものがあります。

1.カップ麺のカロリーは、標準的な白米茶碗一杯分のカロリーよりも少ない。

2.午後にコーヒーをたくさん飲んでいたので、カフェインが利尿作用を発揮してトイレに行きたくなっただけである。

LINE-3.6B

夜中にラーメンを食べたのは、私が自分自身に言い訳をするからです。

私はお腹が空いていたし、ラーメンを食べるのはいつも楽しい。

LINE-1.7B

夜にカップヌードルを食べることは、あなたをだましています。

Instruction Tuningモデル公開のブログを参考に、すべての質問は`ユーザー: `から始めて改行で終え、生成された回答は`システム: `の後を抜き出しています。)

量子化による明らかな性能低下は見られない印象がありますが、最も軽量化できた設定のモデル(gptq-4bit-128g-actorder_False)は、1つ目の質問で間違った回答をしてしまっていたり、2つ目の質問もよく見ると少し文章がおかしいようには見えます。一方で、多少量子化の効果は下がるが、最も性能低下が抑えられていると考えられるモデル(gptq-8bit--1g-actorder_True)は、上手に回答できているように見えます。

また、前の実験より、量子化前の1.7Bモデルと比較して、3.6Bの量子化モデルの方がモデルサイズ、VRAM使用量の点で優れていることがわかりましたが、1.7Bモデルの回答の日本語の不自然さと比較すると、どちらの量子化モデルも、より良い回答ができていると言えそうです。

最後に、元のモデルと量子化モデルの性能の違いを、Rakuda Benchmarkを用いて自動評価を行います。

Rakuda Benchmarkは、日本に関係する40個の質問に対して、各言語モデルの回答をGPT-4にどちらが良いか採点させることで、言語モデルの性能を評価します。

このRakuda BenchmarkInstruction Tuningモデル公開のブログでも用いられていますが、ここでは、複数のモデルの性能を評価するのではなく、量子化前の3.6B(STF)モデルと、量子化後の3.6B(SFT)モデル(gptq-4bit-128g-actorder_False)の回答を、GPT-4にどちらが良い回答か、もしくは同等かで評価をします。

Rakuda Benchmark40個の質問に加えて、Instruction Tuningモデルの人手評価の際に作成された、ChatGPTのような対話型のモデルに聞くような100個の質問も加えて、計140個の質問を使用しました。以下の表はそれぞれの回答が勝った割合、引き分けの割合を示しています。

元モデル
引き分け
量子化モデル
46% 19% 35%

10%ほど、元のモデルの勝率が高い結果となりました。ですが、モデルのサイズ、VRAM使用量が半分ほどになっていることから考えると、そこまで大きな差はなく、良い勝負をしていると言えるのではないでしょうか。

3. 終わりに

本レポートでは、量子化による大規模言語モデルの軽量化についての検証結果をご報告いたしました。

最近は言語モデルの大規模化が進んでいることから、量子化によって軽量化したモデルの需要は高まっており、多くの量子化手法が提案され、さらにパッケージ化が進んでいます。今回取り上げたものはそのわずか一部ですが、大規模言語モデルを利用する誰かにとって、新たな選択肢を増やせるような結果になったのではないかと考えています。

インターン期間中は、NLPチームの方々の知識、守備範囲の広さに日々驚かされていました。私自身新たな挑戦ばかりで、よくわからないことだらけの状態から始まったインターンシップでしたが、テーマ決めから評価の仕方まで多くのアドバイスをいただくことができ、非常に学びが深い期間でした。特にメンターの小林さんと、Massive LM開発ユニットの皆さんには何度もご相談をさせていただき、様々な面でサポートしていただきました。

気がついたら終わっていたくらい本当にあっという間でしたが、LINEならではの貴重な経験を沢山でき、心から嬉しく思っております。

本当にありがとうございました!