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

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
そこで会おう