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.
511 lines
20 KiB
511 lines
20 KiB
WEBVTT |
|
|
|
00:00.710 --> 00:06.830 |
|
そして私たちはGoogle Colabで、 モデルたちと楽しむ準備をしている。 |
|
|
|
00:07.100 --> 00:13.640 |
|
そこでまず、 いつものようにPipのインストールといくつかのインポートを行う。 |
|
|
|
00:13.940 --> 00:21.440 |
|
なぜなら、 録画する直前にズルをして、 もう少し早くできるようにすでに実行してあるからだ。 |
|
|
|
00:21.530 --> 00:26.240 |
|
ピップのインストールは、 おそらく30秒から1分程度ですべて完了する。 |
|
|
|
00:26.270 --> 00:29.450 |
|
ピップのインストールが終わったら、 ハグフェイスにサインインしよう。 |
|
|
|
00:29.450 --> 00:30.800 |
|
もう慣れていると思うよ。 |
|
|
|
00:30.830 --> 00:35.330 |
|
トークンが左のシークレットに設定されていることを祈る。 |
|
|
|
00:35.570 --> 00:42.950 |
|
ええと、 これからハギング・フェイス・ハブでプレーするモデルの名前に定数を設定します。 |
|
|
|
00:42.950 --> 00:48.350 |
|
いつものように、 会社のスラッシュ、 モデルの名前、 またはモデルのレポだ。 |
|
|
|
00:48.620 --> 00:52.370 |
|
だから、 3歳のファイと2歳のジェマと一緒にラマで遊ぶんだ。 |
|
|
|
00:52.370 --> 01:00.290 |
|
そして、 アリババクラウドのLLMのクアントと一緒に練習を繰り返してほしい。 |
|
|
|
01:00.290 --> 01:03.190 |
|
そして、 ミストラルもここにあげた。 |
|
|
|
01:03.220 --> 01:11.020 |
|
さて、 これはおそらく、 大きなGPUに大枚をはたかない限り、 大きすぎるモデルになると言わざるを得ない。 |
|
|
|
01:11.110 --> 01:19.450 |
|
その場合は、 Huggingfaceのハブに行って、 80億パラメータ以下のいいモデルを見つけて、 |
|
|
|
01:19.450 --> 01:23.110 |
|
それを代わりに使ってください。 |
|
|
|
01:23.110 --> 01:30.100 |
|
自分の好きなもの、 人気のあるもの、 現在好調なものを選んで、 それをどう評価するか見てみよう。 |
|
|
|
01:30.100 --> 01:34.840 |
|
ただし、 少なくとも5つのモデルを完成させておくこと。 |
|
|
|
01:34.930 --> 01:42.220 |
|
システム・メッセージとユーザー・メッセージを2つのディクテットにして、 |
|
|
|
01:42.220 --> 01:48.700 |
|
メッセージ・リストを作りましょう。 |
|
|
|
01:48.730 --> 01:51.640 |
|
これ以上の説明は必要ない。 |
|
|
|
01:51.910 --> 02:02.540 |
|
前回、 ラマ3に同意する必要があることを覚えているよね。 1 利用規約は、 モデルのページに行き、 |
|
|
|
02:02.690 --> 02:07.610 |
|
同意するを押してください。 |
|
|
|
02:07.610 --> 02:15.380 |
|
もし、 まだそうしていないのなら、 ラマ3にアクセスできるようにそうしてください。 1モデル。 |
|
|
|
02:16.370 --> 02:18.740 |
|
これは新しいことだ。 |
|
|
|
02:18.740 --> 02:23.180 |
|
量子化と呼ばれるものについて少しお話ししたいと思います。 |
|
|
|
02:23.180 --> 02:27.350 |
|
だから量子化というのは、 かなり意外なことなんだ。 |
|
|
|
02:27.440 --> 02:42.500 |
|
つまり、 このモデルをメモリにロードしたいが、 その際、 モデルを構成するウェイトの数値の精度を下げたい。 |
|
|
|
02:42.500 --> 02:46.130 |
|
これらのウェイトは通常32ビットの浮動小数点数である。 |
|
|
|
02:46.250 --> 02:51.650 |
|
このディープ・ニューラル・ネットワークの重みは、 32ビットの浮動小数点数で構成されている。 |
|
|
|
02:51.650 --> 02:55.490 |
|
もっと少ないビットで彼らを連れてきたらどうだろう? |
|
|
|
02:55.760 --> 02:59.320 |
|
32ビットはもちろん4バイトだ。 |
|
|
|
02:59.590 --> 03:08.350 |
|
そして、 より少ないメモリに、 より多くの数字を詰め込むことを試みるかもしれない。 |
|
|
|
03:08.650 --> 03:17.080 |
|
そして、 精度を下げることによって、 より粗い数をモデルに入れることを量子化と呼ぶんだ。 |
|
|
|
03:17.080 --> 03:19.930 |
|
そして、 それは私たちがやろうとしていることでもある。 |
|
|
|
03:19.930 --> 03:24.670 |
|
最初にこの話を聞いたとき、 とても驚いたことを覚えている。 |
|
|
|
03:24.700 --> 03:32.530 |
|
32ビットの数字を8ビットの数字に置き換えることで、 精度を大幅に下げるという話だった。 |
|
|
|
03:32.530 --> 03:41.320 |
|
そして考えたのは、 意外なことに、 もちろん精度は少し落ちるものの、 思ったほどは落ちないということだった。 |
|
|
|
03:41.320 --> 03:44.680 |
|
減るわけでもなく、 4倍悪くなるわけでもない。 |
|
|
|
03:44.860 --> 03:51.550 |
|
ちょっと悪くなるけど、 まあ我慢できる程度だし、 メモリを増やすというトレードオフの価値はある。 |
|
|
|
03:51.670 --> 03:56.800 |
|
それを聞いて驚いたし、 それ以上のことができると聞いてさらに驚いたよ。 |
|
|
|
03:56.800 --> 04:01.760 |
|
実際には、 8ビットではなく、 4ビットまで減らすことができる。 |
|
|
|
04:01.760 --> 04:03.950 |
|
数えてみれば半分のバイトだ。 |
|
|
|
04:04.220 --> 04:09.560 |
|
32ビットから4ビットに減らすことができる。 |
|
|
|
04:09.800 --> 04:17.600 |
|
また、 精度は確かに落ちているが、 期待するほどではない。 |
|
|
|
04:17.630 --> 04:21.500 |
|
しかし、 私はそれが大きく異なるものだとは思っていなかった。 |
|
|
|
04:21.500 --> 04:23.990 |
|
それに、 かなり我慢できるレベルじゃない。 |
|
|
|
04:23.990 --> 04:29.870 |
|
そして、 より大きなモデルをメモリに収め、 より速くロードし、 より速く実行することなどが可能になる。 |
|
|
|
04:29.870 --> 04:33.710 |
|
だから、 量子化はよく行われることなんだ。 |
|
|
|
04:33.710 --> 04:41.060 |
|
これは強力なツールで、 特にトレーニングに入ると、 これらのモデルを使ってより多くの仕事をこなさなければならなくなる。 |
|
|
|
04:41.060 --> 04:43.190 |
|
量子化は救世主だよ。 |
|
|
|
04:43.220 --> 04:53.150 |
|
数週間後のある時点で、 効率的な方法で微調整を行うQラウラと呼ばれるテクニックを紹介すると書いたのを覚えているだろうか。 |
|
|
|
04:53.150 --> 04:57.760 |
|
Q,ローラのQは量子化を意味する。 |
|
|
|
04:57.760 --> 05:01.720 |
|
だから、 これからも折に触れて訪れることになるだろう。 |
|
|
|
05:02.350 --> 05:10.480 |
|
その間に、 私たちはBits and Bytesというライブラリを使っている。 これは、 抱きつき顔のトランスフォーマーライブラリと相性がいい。 |
|
|
|
05:10.510 --> 05:18.670 |
|
これは素晴らしいライブラリで、 これから使用する新しいbits and bytesコンフィグ・オブジェクトを作成して、 |
|
|
|
05:18.760 --> 05:22.720 |
|
どのような量子化を行いたいかを記述することができる。 |
|
|
|
05:22.720 --> 05:27.490 |
|
そして、 4ビットのロードは真に等しいと言うつもりだ。 |
|
|
|
05:27.520 --> 05:29.020 |
|
我々は4ビットまでやるつもりだ。 |
|
|
|
05:29.020 --> 05:31.810 |
|
また、 ここでは8ビットのロードは真に等しいと言うこともできる。 |
|
|
|
05:31.810 --> 05:37.660 |
|
その代わり、 8ビットにしたいのであれば、 両方やってみて、 精度の違いがわかるかどうか試してみるのもいいかもしれない。 |
|
|
|
05:38.320 --> 05:41.260 |
|
そして今、 これまた非常に驚いている。 |
|
|
|
05:41.260 --> 05:46.510 |
|
しかし、 4ビットでdouble quant equals trueを使うこともできる。 |
|
|
|
05:46.510 --> 05:51.760 |
|
そしてこれは、 すべての重みを1度ではなく2度量子化することを意味する。 |
|
|
|
05:51.790 --> 05:54.190 |
|
ええと、 もう少しメモリを節約します。 |
|
|
|
05:54.190 --> 06:02.210 |
|
また、 これをやり直したからといって、 結果の精度に大きな影響はない。 |
|
|
|
06:02.210 --> 06:05.300 |
|
だから、 それはいいトレードだし、 みんなそうしている。 |
|
|
|
06:05.870 --> 06:17.270 |
|
ええと、 これは、 計算を行う際に、 このデータ型A、 B 16を使用することで、 パフォーマンスが多少向上するということです。 |
|
|
|
06:17.270 --> 06:19.280 |
|
だから、 これもよくあることだ。 |
|
|
|
06:19.400 --> 06:27.290 |
|
それから、 これは数字を4ビットに減らしたときに、 その4ビットの数字をどう解釈してどう扱うか、 |
|
|
|
06:27.320 --> 06:32.510 |
|
どう4ビットに圧縮するかということです。 |
|
|
|
06:32.510 --> 06:37.490 |
|
そして、 このNF4は4ビットの数値表現である。 |
|
|
|
06:37.490 --> 06:39.860 |
|
Nはノーマライズドを意味する。 |
|
|
|
06:39.860 --> 06:45.230 |
|
私は、 これらの数値が正規分布に従うと考えることで、 物事をわずか4ビットに圧縮する際に、 |
|
|
|
06:45.230 --> 06:51.200 |
|
より正確さを増すことができることに関係していると理解している。 |
|
|
|
06:51.230 --> 06:56.090 |
|
だから、 この2つはあまり重要ではないだろう。 |
|
|
|
06:56.110 --> 06:58.690 |
|
大差をつけることは期待されていない。 |
|
|
|
06:58.720 --> 06:59.170 |
|
そうなる運命なんだ。 |
|
|
|
06:59.200 --> 06:59.680 |
|
それは運命なんだ。 |
|
|
|
06:59.680 --> 07:01.030 |
|
しかし、 持っていて損はないセッティングだ。 |
|
|
|
07:01.030 --> 07:03.490 |
|
そして、 これは多少の違いがある。 |
|
|
|
07:03.490 --> 07:06.280 |
|
そして、 これはメモリという点で大きな違いを生む。 |
|
|
|
07:06.280 --> 07:11.500 |
|
そしてそのどれもが、 アウトプットの面ではそれほど悪くない。 |
|
|
|
07:11.530 --> 07:19.420 |
|
そんな雑談をしながら、 クォンツのコンフィグ、 ビット・アンド・バイトのコンフィグができあがった。 |
|
|
|
07:19.480 --> 07:21.370 |
|
これは私たちがよく知っていることだ。 |
|
|
|
07:21.400 --> 07:24.910 |
|
Lamaのトークナイザーを作成します。 |
|
|
|
07:25.450 --> 07:28.090 |
|
このラインは、 これまで話題にしたことのない新しいものだ。 |
|
|
|
07:28.090 --> 07:37.240 |
|
ええと、 パッドトークンと呼ばれるものがあって、 これはニューラルネットワークに入力されるときに、 プロンプトにさらに追加する必要がある場合に、 |
|
|
|
07:37.240 --> 07:43.090 |
|
プロンプトを埋めるために使われるトークンです。 |
|
|
|
07:43.180 --> 07:50.440 |
|
そして、 そのパッド・トークンは、 文末の特別なトークン、 つまりプロンプトの終わりのトークンと同じに設定するのが、 |
|
|
|
07:50.470 --> 07:54.220 |
|
ある種の一般的なやり方です。 |
|
|
|
07:54.370 --> 07:57.830 |
|
もしそうしなければ、 警告を受けることになる。 |
|
|
|
07:57.860 --> 07:59.840 |
|
警告を受けることは問題ではない。 |
|
|
|
07:59.840 --> 08:01.250 |
|
インパクトはないと思う。 |
|
|
|
08:01.250 --> 08:04.610 |
|
しかし、 警告を受けたくないのであれば、 このままにしておけばいいし、 |
|
|
|
08:04.640 --> 08:09.170 |
|
多くのコードで標準的に使われているのを見るだろう。 |
|
|
|
08:10.310 --> 08:10.970 |
|
オーケー。 |
|
|
|
08:10.970 --> 08:13.520 |
|
そしてトークナイザーを使う。 |
|
|
|
08:13.520 --> 08:17.390 |
|
ご存知のチャットテンプレート適用関数を呼び出します。 |
|
|
|
08:17.390 --> 08:23.930 |
|
メッセージを辞書のリストとして受け取り、 トークンに変換する。 |
|
|
|
08:24.260 --> 08:28.820 |
|
そしてそれをGPUに押し付ける。 |
|
|
|
08:28.850 --> 08:33.080 |
|
では、 これを実行すると、 トークナイザーが動き出す。 |
|
|
|
08:33.080 --> 08:37.520 |
|
次にすることは、 モデルをロードすることだ。 |
|
|
|
08:37.520 --> 08:39.950 |
|
では、 このセリフは何を意味するのか。 |
|
|
|
08:39.980 --> 08:44.900 |
|
だからまず、 このセリフにとても似ている。 |
|
|
|
08:44.900 --> 08:50.540 |
|
ここでは、 auto tokenizer dot frompretrainedと言って、 トークナイザーを作成しました。 |
|
|
|
08:50.570 --> 08:57.200 |
|
我々は、 因果LLMのための自動モデルを、 事前に訓練されたものから作成する。 |
|
|
|
08:57.290 --> 09:02.420 |
|
このクラスは、 LLMを作成するための一般的なクラスである。 |
|
|
|
09:02.450 --> 09:06.290 |
|
因果LLMは自己回帰LLMと同じである。 |
|
|
|
09:06.290 --> 09:13.760 |
|
そしてそれは、 過去のトークンのセットを受け取り、 未来のトークンを予測するLLMであることを意味する。 |
|
|
|
09:13.760 --> 09:18.170 |
|
そして基本的に、 私たちが話してきたすべてのLLMはそのようなLLMだった。 |
|
|
|
09:18.170 --> 09:24.200 |
|
このコースの後半では、 もう一つのLLMについて見ていく。 |
|
|
|
09:24.200 --> 09:34.130 |
|
しかし、 このような生成的AIのユースケースで話していることすべてにおいて、 我々は因果関係のあるLLMや自己回帰LLMを扱うことになる。 |
|
|
|
09:34.130 --> 09:39.650 |
|
そしてこれは、 事前に訓練されたものから作成する方法になる。 |
|
|
|
09:39.650 --> 09:42.560 |
|
トークナイザーと同じように、 モデルの名前を渡します。 |
|
|
|
09:42.560 --> 09:46.340 |
|
GPUがあれば、 そのGPUを使いたい。 |
|
|
|
09:46.370 --> 09:48.950 |
|
それがデバイス・マップ・オートだ。 |
|
|
|
09:48.980 --> 09:57.590 |
|
そして、 先ほど設定した量子化コンフィグ、 クオンツ・コンフィグを渡して、 モデルを構築する。 |
|
|
|
09:57.620 --> 10:09.440 |
|
モデルとは実際のコードのことで、 これは実際に我々の大規模な言語モデルをソフトウェアとして、 Pythonのコードとして実行できるようにしたものだ。 |
|
|
|
10:09.440 --> 10:11.720 |
|
そしてカバーの下にはPyTorchがある。 |
|
|
|
10:11.750 --> 10:20.390 |
|
これは一連のPyTorchレイヤーであり、 入力を入力し、 出力を得ることができるニューラルネットワークのレイヤーである。 |
|
|
|
10:20.390 --> 10:22.580 |
|
だから本物なんだ。 |
|
|
|
10:22.670 --> 10:32.330 |
|
今、 この作業をしたところだから、 おそらくもっと時間がかかるだろう。 |
|
|
|
10:32.360 --> 10:38.090 |
|
これを実行すると、 実際にダウンロードが行われる。 |
|
|
|
10:38.090 --> 10:39.650 |
|
ハグ顔につながる。 |
|
|
|
10:39.680 --> 10:46.190 |
|
これは、 Hugging face hubからモデルの重みをすべてダウンロードし、 |
|
|
|
10:46.190 --> 11:07.660 |
|
Google Colabインスタンスのディスク上の特別なファイルにキャッシュされます。 |
|
|
|
11:07.660 --> 11:12.940 |
|
メモリフットプリントの取得を呼び出すことで、 モデルがどれだけのメモリを使用しているかを尋ねることができる。 |
|
|
|
11:12.940 --> 11:15.100 |
|
その結果、 どうなるかはこれからだ。 |
|
|
|
11:15.100 --> 11:19.510 |
|
このモデルのメモリー・フットプリントは約5。 5GB。 |
|
|
|
11:19.840 --> 11:28.030 |
|
このボックスのリソースを見ると、 5つほど使っていることがわかる。 5GBの空き容量。 |
|
|
|
11:28.030 --> 11:31.210 |
|
そして、 すでにこれを実行しているので、 過去にバウンドしている。 |
|
|
|
11:31.450 --> 11:37.000 |
|
でも、 ここからスタートすると、 5.5メートルくらいに跳ね上がることは想像できると思う。 |
|
|
|
11:37.000 --> 11:42.700 |
|
そしてディスク上では、 ディスクのキャッシュにロードされているため、 十分なスペースを使用している。 |
|
|
|
11:43.690 --> 11:44.560 |
|
オーケー。 |
|
|
|
11:44.590 --> 11:47.350 |
|
プライムタイムの準備はほぼ整っている。 |
|
|
|
11:47.350 --> 11:51.250 |
|
まずはモデルそのものを見てみよう。 |
|
|
|
11:51.430 --> 11:54.210 |
|
そして、 私たちは単にモデルを印刷することでそれを行う。 |
|
|
|
11:54.990 --> 12:05.370 |
|
モデルをプリントすると出てくるのは、 このモデル・オブジェクトで表現される実際のディープ・ニューラル・ネットワークの説明である。 |
|
|
|
12:05.370 --> 12:06.990 |
|
これがここで見ているものだ。 |
|
|
|
12:06.990 --> 12:12.720 |
|
これは、 ディープ・ニューラル・ネットワークのレイヤーを表す、 実際のレイヤーのコードだ。 |
|
|
|
12:12.720 --> 12:20.730 |
|
そしてこれらはすべて、 モデルによって参照されるように設定されたPyTorchクラスを示している。 |
|
|
|
12:21.210 --> 12:26.460 |
|
ええと、 繰り返しになるけど、 このクラスは実践的なクラスで、 時折理論的なことを少し話すだけなんだ。 |
|
|
|
12:26.460 --> 12:31.320 |
|
しかし、 ディープ・ニューラル・ネットワークの内部やレイヤーに関する知識のレベルによっては、 |
|
|
|
12:31.320 --> 12:32.700 |
|
これを見る価値はある。 |
|
|
|
12:32.700 --> 12:34.740 |
|
この中には、 あなたにとって超お馴染みのものもあるかもしれない。 |
|
|
|
12:34.740 --> 12:41.820 |
|
トークンをニューラルネットワークに埋め込むエンベッディング層から始まることは、 おわかりいただけるだろう。 |
|
|
|
12:41.820 --> 12:49.170 |
|
そして、 この次元、 これは次元を示していて、 ボキャブラリーの次元性を示していることが想像できるだろう。 |
|
|
|
12:49.620 --> 12:56.680 |
|
そして、 ニューラルネットワークの各層に、 一連のモジュールがあることがわかるだろう。 |
|
|
|
12:56.710 --> 13:04.060 |
|
特にあなたは、 注目されることがすべてだと知っているのだから。 |
|
|
|
13:04.090 --> 13:11.350 |
|
論文にあるように、 必要なのは注意力だけであり、 それこそがトランスフォーマーをトランスフォーマーたらしめている核心である。 |
|
|
|
13:11.350 --> 13:17.230 |
|
そして多層パーセプトロン層がここにある。 |
|
|
|
13:17.230 --> 13:19.690 |
|
そして活性化関数がある。 |
|
|
|
13:19.690 --> 13:24.340 |
|
理論に詳しい人たちなら、 これを期待しているはずだ。 |
|
|
|
13:24.340 --> 13:32.860 |
|
このラマが使用する活性化関数 3. 1つのモデルはReLU活性化関数で、 シグモイド、 |
|
|
|
13:32.860 --> 13:40.570 |
|
つまり線形単位で、 Pytorchのドキュメントに記載されている。 |
|
|
|
13:40.750 --> 13:43.900 |
|
それと、 どうやらスウィッシュ機能としても知られているようだ。 |
|
|
|
13:44.080 --> 13:49.300 |
|
基本的にはxのロジスティック・シグモイドをx倍にしたものだ。 |
|
|
|
13:49.300 --> 13:52.190 |
|
これが活性化関数だ。 |
|
|
|
13:52.220 --> 13:57.020 |
|
繰り返しになるが、 ディープ・ニューラル・ネットワークの理論に詳しい人なら、 これが何なのかよくご存じだろう。 |
|
|
|
13:57.050 --> 13:59.300 |
|
もしそうでないなら、 心配はいらない。 |
|
|
|
13:59.300 --> 14:05.630 |
|
ここで何が起こっているのか、 一般的な感覚をつかむだけでいい。 このモデルや他のモデルを研究していくうちに、 |
|
|
|
14:05.630 --> 14:09.200 |
|
もっと詳しく見ることができるようになるだろう。 |
|
|
|
14:09.890 --> 14:20.360 |
|
その最後に、 いくつかの、 いくつかの、 いくつかの、 いくつかの、 レイヤーのようなものがあり、 そして最後に直線的なレイヤーがある。 |
|
|
|
14:21.170 --> 14:30.560 |
|
PyTorchニューラルネットワークの知識レベルによっては、 特に見る価値がある。 |
|
|
|
14:30.770 --> 14:35.060 |
|
でも、 後で他のモデルを見ても同じことができる。 |
|
|
|
14:35.060 --> 14:36.680 |
|
モデルの出力を見てください。 |
|
|
|
14:36.710 --> 14:42.320 |
|
見て、 模型を見て、 模型をプリントして、 どんな風に見えるか見て、 ラマ3と比べてみてください。 |
|
|
|
14:43.160 --> 14:49.040 |
|
次のビデオまでお休みしますが、 次のビデオでは、 これを実行し、 他のモデルも実行します。 |
|
|
|
14:49.070 --> 14:50.690 |
|
だからどこにも行くな。 |
|
|
|
14:50.720 --> 14:51.770 |
|
またすぐに会おう。
|
|
|