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 またすぐに会おう。