From the uDemy course on LLM engineering.
https://www.udemy.com/course/llm-engineering-master-ai-and-large-language-models
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
142 lines
5.1 KiB
142 lines
5.1 KiB
WEBVTT |
|
|
|
00:00.620 --> 00:08.330 |
|
そこで今回は、 4ビットの量子化について見ていくことにする。 |
|
|
|
00:08.330 --> 00:13.460 |
|
つまり、 ビットとバイトを使ってクオンツのコンフィグを作成する前とよく似ている。 |
|
|
|
00:13.700 --> 00:17.150 |
|
しかし、 今回は4ビット・イコールでロードするように頼んだ。 |
|
|
|
00:17.150 --> 00:17.750 |
|
その通りだ。 |
|
|
|
00:17.780 --> 00:19.370 |
|
他にもいくつかの設定がある。 |
|
|
|
00:19.370 --> 00:24.710 |
|
今回は "use double Quant "という、 これまたちょっと不思議なものがある。 |
|
|
|
00:24.710 --> 00:32.270 |
|
ここでの考え方は、 すべてのウエイトを量子化するパススルーを行い、 その後、 もう一度パススルーを行うというものだ。 |
|
|
|
00:32.270 --> 00:36.830 |
|
そうすることで、 さらに10~20%ほどメモリを減らすことができるんだ。 |
|
|
|
00:36.860 --> 00:38.990 |
|
ここからもう少し絞り出す。 |
|
|
|
00:39.080 --> 00:46.940 |
|
そしてこれは、 ニューラルネットワークのパワーにごくわずかな違いをもたらすことが実験的に示されている。 |
|
|
|
00:46.940 --> 00:48.470 |
|
だから、 ほとんどタダ同然だ。 |
|
|
|
00:48.500 --> 00:51.020 |
|
またケーキを食べているような状況だ。 |
|
|
|
00:51.020 --> 00:54.980 |
|
そのため、 ダブルクアントをトゥルーとして使用することを推奨する。 |
|
|
|
00:55.130 --> 01:01.280 |
|
このcompute dtypeは、 計算中に使用されるデータ型に関するものである。 |
|
|
|
01:01.490 --> 01:06.350 |
|
そして一般的に、 ここでは32ビットの浮動小数点数を使うことができる。 |
|
|
|
01:06.350 --> 01:14.240 |
|
しかし、 Bfloat16データ型バイナリフロート16を使用することは、 トレーニングの質をほんの少し犠牲にするだけで、 |
|
|
|
01:14.240 --> 01:20.480 |
|
トレーニングのスピードを向上させ、 より速くするものだと考えられている。 |
|
|
|
01:20.630 --> 01:30.470 |
|
確かに、 私がこれを試したとき、 より速く走るのを見たが、 最適化の速度に実際の変化を検出することはできなかった。 |
|
|
|
01:30.710 --> 01:32.750 |
|
だから、 これは絶対にお勧めだ。 |
|
|
|
01:32.750 --> 01:35.750 |
|
しかし、 繰り返すが、 これはハイパーパラメーターであり、 試してみることができる。 |
|
|
|
01:35.750 --> 01:40.220 |
|
そしてこれが4ビットのクオンツタイプ。 |
|
|
|
01:40.220 --> 01:46.730 |
|
これは、 精度を4ビットに落としたとき、 その4ビットをどう解釈すべきかということだ。 |
|
|
|
01:46.760 --> 01:55.790 |
|
4ビットが0000から1111までなら、 0から15までの整数を表していることになる。 |
|
|
|
01:55.820 --> 01:57.800 |
|
それも一つの方法かもしれない。 |
|
|
|
01:57.830 --> 02:02.690 |
|
それを解釈して、 浮動小数点数のようなものにマッピングするのが一般的だ。 |
|
|
|
02:02.810 --> 02:08.750 |
|
そして、 このnf4のアプローチは、 それを正規分布に対応させるものなんだ。 |
|
|
|
02:08.780 --> 02:11.540 |
|
そしてまた、 これは非常に一般的な設定でもある。 |
|
|
|
02:11.540 --> 02:13.550 |
|
僕が使ってきたものだよ。 |
|
|
|
02:13.580 --> 02:16.010 |
|
他のものを試したが、 それほど良くなかった。 |
|
|
|
02:16.040 --> 02:18.620 |
|
だから、 一般的にはこれが推奨されている。 |
|
|
|
02:18.620 --> 02:23.090 |
|
しかし、 これはハイパーパラメーターであり、 試行錯誤が可能であることを意味する。 |
|
|
|
02:23.600 --> 02:31.370 |
|
これを念頭に置いて、 4ビット量子化用のごく標準的なクオンツ・コンフィグを作成する。 |
|
|
|
02:31.370 --> 02:38.570 |
|
これでベースモデルを作り、 メモリのフットプリントを印刷する。 |
|
|
|
02:38.570 --> 02:43.010 |
|
そして驚くべきことに、 我々は5人になってしまった。 6GB。 |
|
|
|
02:43.040 --> 02:48.770 |
|
しかし、 ベースモデルの実物が32GBだったことを思い出すと、 |
|
|
|
02:48.770 --> 02:54.470 |
|
本当にずいぶん小さくなったものだ。 |
|
|
|
02:54.470 --> 03:01.580 |
|
これで、 この安いT4ボックスのGPUのメモリに余裕で収まるようになった。 |
|
|
|
03:01.580 --> 03:04.940 |
|
ベースモデルを見れば、 そのアーキテクチャがわかるだろう。 |
|
|
|
03:04.970 --> 03:07.580 |
|
もうあんな馬鹿げた冗談は言わないよ。 |
|
|
|
03:07.670 --> 03:15.920 |
|
もちろん、 80億リラマのオリジナルモデルのアーキテクチャと同一である。 |
|
|
|
03:16.280 --> 03:22.130 |
|
ただ、 この奥の奥では、 ウエイトの精度が低くなっている。 |
|
|
|
03:22.130 --> 03:23.150 |
|
4ビットだ。 |
|
|
|
03:23.960 --> 03:24.740 |
|
オーケー。 |
|
|
|
03:24.740 --> 03:28.160 |
|
次のビデオでは、 この時点でセッションを再開してはいけない。 |
|
|
|
03:28.160 --> 03:34.490 |
|
このセッションはこのままにしておいて、 次のビデオでは、 微調整されたモデルの例をロードして、 |
|
|
|
03:34.490 --> 03:40.160 |
|
ローラの適応がこのアーキテクチャにどのように適用されるかを見てみよう。 |
|
|
|
03:40.190 --> 03:41.030 |
|
そこで会おう
|
|
|