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.
 
 

430 lines
14 KiB

WEBVTT
00:00.350 --> 00:05.540
すべてを美しいユーザー・インターフェースにまとめる瞬間へ、 ようこそ。
00:05.540 --> 00:12.260
その前に、 もう一度Huggingfaceの推論エンドポイント画面を見てほしい。
00:12.260 --> 00:15.380
クワイン1 570億チャットの推論
00:15.680 --> 00:16.640
我々はできる。
00:16.670 --> 00:23.060
分析結果を見たり、 何が起こっているのかを見たり、
00:23.060 --> 00:32.090
リクエスト数を見たりすることができます。
00:32.210 --> 00:34.430
ええと、 レイテンシー、 CPU使用率。
00:34.460 --> 00:34.940
そうだ。
00:34.970 --> 00:38.930
CPUの使用率とGPUの使用率が少し上がっている。
00:38.960 --> 00:39.920
いいね。
00:40.010 --> 00:51.020
それと、 "コスト "を見て、 僕が3ドル使っていることがわかると思う。 これまでのところ、 この特定のモデルで64回。
00:51.380 --> 00:53.150
うーん、 わかった。
00:53.180 --> 01:00.770
さて、 それを念頭に置いて、 アナリティクスは置いておいて、 Jupyterラボに戻ろう。
01:01.010 --> 01:09.070
コード・クワンを呼び出すこのコードを、 GPT4やクロード・ストリーム・クエンですでにやった他のストリーム・メソッドと同じように、
01:09.070 --> 01:14.620
小さなストリーム・メソッドにまとめよう。
01:14.650 --> 01:17.200
同じような方法だが、 もちろん同じ機能だ。
01:17.200 --> 01:18.700
そのやり方はまったく違う。
01:18.910 --> 01:21.370
これはトークナイザーを作成する。
01:21.370 --> 01:27.700
もちろん、 Pythonを通常のメッセージリストに変えることになる。
01:27.700 --> 01:29.710
チャットのテンプレートが適用されます。
01:29.710 --> 01:34.420
これでトークン化の準備が整った。
01:34.420 --> 01:43.120
そして、 エンドポイントのURLとHuggingfaceトークンを使って推論クライアントを呼び出します。
01:43.120 --> 01:47.020
そして、 ここではクライアントのテキスト生成を行っている。
01:47.020 --> 01:49.570
ここにストリーミングしたいテキストがある。
01:49.570 --> 01:52.930
これが新しいトークンの最大値だ。
01:52.930 --> 01:55.900
そして結果が戻ってくる。
01:55.900 --> 02:05.740
各トークンをストリームバックする際に、 これまでの合計を返す。
02:05.740 --> 02:13.280
それは、 すべてのチャンクでこれまでに受信されたすべてのものの累積合計のようなものを期待している。
02:13.280 --> 02:23.030
つまり、 このストリーム・コレクションという関数は、 前に書いたストリームGPTのストリーム・クロードの関数と同じものなのだ。
02:23.030 --> 02:34.010
これで、 コードを最適化するための、 以前の最適化された方法に代わる最適化された方法を手に入れることができ、 3つのモデルGPTクロードかコード・クワンの間で反転することができる。
02:34.400 --> 02:34.910
うーん。
02:34.910 --> 02:41.900
そしてここに、 Gradioのユーザー・インターフェースのコードの合計がある。
02:41.930 --> 02:43.400
これを必ず実行する。
02:43.820 --> 02:46.520
ええと、 だから、 これがどれだけ簡単なことか思い出してほしい。
02:46.520 --> 02:47.720
クレイジーだよ。
02:47.960 --> 02:54.710
タイトルをつけて、 PythonのコードとC++のコードを並べます。
02:54.710 --> 02:57.140
モデルを選択する行がある。
02:57.140 --> 03:03.200
そして今回、 これまで選べた2つのモデルにコード・クォンが加わった。
03:03.320 --> 03:08.750
コードを変換するボタン、 Pythonを実行するボタン、 C plus plusを実行するボタン、
03:08.750 --> 03:13.600
そしてPythonの結果とcplusplusの結果の出力ボックスがあります。
03:13.600 --> 03:17.500
そして、 これが3つのアクションだ。
03:17.500 --> 03:22.870
ボタンがクリックされたら、 何らかのアクションを起こす3つの場所。
03:22.870 --> 03:26.290
そして、 単純に英語のように読めるところが好きだ。
03:26.290 --> 03:31.000
もし誰かがコンバートを望むなら、 コンバートボタンを押せば、 最適化機能が呼び出される。
03:31.000 --> 03:33.550
これがインプットで、 これがアウトプットだ。
03:33.550 --> 03:37.120
Pythonの実行ボタンを押すと、 Pythonが実行される。
03:37.120 --> 03:44.080
入力はPythonのコード、 出力はPythonのout、 C plus plusボタンも同様。
03:44.080 --> 03:47.020
超シンプルに見えるはずだ。
03:47.020 --> 03:48.880
それは超シンプルだからだ。
03:49.300 --> 03:51.310
そして、 私たちはそれを発表するつもりだ。
03:51.340 --> 03:54.730
これが僕らにとって見事に機能することを祈っているよ。
03:55.060 --> 03:58.840
さて、 これがユーザー・インターフェースだ。
03:59.080 --> 04:08.050
もちろん、 ここにあるのは単純な円周率計算のPythonコードだ。
04:08.050 --> 04:09.280
なぜダメなんだ?
04:09.280 --> 04:12.490
GPTでやってみよう。
04:14.750 --> 04:17.720
Cプラス・プラス相当と覚えておいてほしい。
04:17.750 --> 04:21.080
Pythonのバリエーションを実行してみよう。
04:21.110 --> 04:23.240
私の記憶が正しければ、 これは約8秒だ。
04:23.240 --> 04:25.220
だから、 これが8カウントになるのを待つしかない。
04:25.250 --> 04:27.140
そして、 パイソンの結果を得るべきだ。
04:27.170 --> 04:29.810
そこに8がある。 6秒。
04:29.810 --> 04:34.820
古き良き円周率は、 少なくとも小数点以下何桁まで存在する。
04:34.820 --> 04:36.410
そして今度はCプラスを走らせる。
04:36.410 --> 04:38.630
それにGPT4から戻ってきた。
04:38.630 --> 04:47.630
そして0点でも素晴らしい。 秒の06は100倍以上の向上だ。
04:47.810 --> 04:50.630
クロードのためにもう1度。
04:50.750 --> 04:55.340
Anthropicのクロードの好意でコードを変換した。
04:55.820 --> 04:57.380
あ、 あった。
04:57.410 --> 05:00.080
そして今度はクロードのCプラスを走らせる。
05:00.080 --> 05:00.680
それに
05:00.680 --> 05:05.480
そして、 またGPT4に僅差で勝った。
05:05.480 --> 05:10.940
でも、 このラインが入っていることで、 わずかに速くなったのかもしれない。
05:10.940 --> 05:13.610
クロードのコードの方が本当に速いのかもしれない。
05:13.790 --> 05:16.400
うーん、 あまりに似ているので疑ってしまう。
05:16.400 --> 05:16.810
これがそうだ。
05:16.840 --> 05:19.480
これはコンパイラによって最適化される。
05:19.600 --> 05:22.570
しかし、 一貫してわずかに速い可能性はある。
05:22.570 --> 05:24.880
だから、 あなたはCプラス・プラスの専門家かもしれない。
05:24.880 --> 05:25.540
それは私に教えてくれる。
05:25.540 --> 05:31.960
そして、 自分のアーキテクチャでそれが速いかどうか、 自分で試して納得できるかもしれない。
05:31.960 --> 05:33.880
しかし、 とにかく、 それは問題ではない。
05:33.910 --> 05:38.260
我々がここで見ているのは、 コードの品質がどの程度なのかということだ。
05:38.290 --> 05:39.220
コンバートは可能か?
05:39.250 --> 05:42.130
それは理にかなっていて、 何か違いがあるのだろうか?
05:42.160 --> 05:45.430
コード変換ボタンを押して、 何が起こるか見てみよう。
05:45.430 --> 05:49.780
だからまず第一に、 僕らが知っているように、 それはもっとおしゃべりなんだ。
05:49.810 --> 05:53.920
その説明を正しく取り除けていない。
05:53.920 --> 05:55.720
だから、 それを削除する必要がある。
05:55.720 --> 05:57.880
しかし、 私たちはそれを許す。
05:57.910 --> 06:03.790
そのような余計なものを加えたからといって、 コードモデルを非難するつもりはない。
06:05.320 --> 06:11.530
覚えておいてほしいのは、 これはすべてエンドポイントから見ている今現在のストリーミングだということだ。
06:11.560 --> 06:15.070
こっちに行ったら、 リフレッシュする必要があるかもしれない。
06:15.070 --> 06:17.290
私たちは、 私たちがそうであることを確認しなければならない。
06:17.320 --> 06:22.820
確かに、 結果をストリームバックするときにCPUとGPUが点滅するのが見える。
06:23.240 --> 06:29.990
ええと、 ではここで、 ええと、 グラデーションのスクリーンに降りてください。
06:29.990 --> 06:30.860
さあ、 始めよう。
06:30.860 --> 06:35.690
ええと、 私たちは、 ええと、 完全な解決策を持っています。
06:35.690 --> 06:46.400
だから、 これからやることは、 一番上にあるものを取り除き、 最後にある必要のない説明を取り除くことだ。
06:46.430 --> 06:51.980
そして、 このCプラスプラスのコードを実行し、 クインがどのような結果を残したかを確認する。
06:52.250 --> 06:53.780
試してみよう。
06:56.060 --> 06:58.670
そして走り、 速かった。
06:58.700 --> 07:00.140
GPT4とほぼ同じだった。
07:00.170 --> 07:02.720
同じぐらいだと思うよ。
07:02.900 --> 07:09.170
ええと、 プラグマは入っていないようですが、 素晴らしい仕事をしてくれているようです。
07:09.170 --> 07:10.640
同じ答えだ。
07:10.640 --> 07:15.290
そして、 それはコードにとって間違いなく成功だと思う。
07:15.290 --> 07:16.010
クインだ。
07:16.340 --> 07:24.130
そしてまた、 コード・クインがここで実行している70億のパラメーターと、
07:24.130 --> 07:37.660
GPT4やクロードが持っている2兆以上のパラメーターの違いを思い出してほしい。
07:38.170 --> 07:44.200
じゃあ、 ここに戻って、 ハードルを上げよう。
07:44.230 --> 07:46.000
チャレンジをもっと難しくしよう。
07:46.030 --> 07:57.580
この値をPythonのハード、 つまり最大部分配列和を計算するコードに変更してみよう。
07:57.580 --> 08:05.110
そして、 我々のオープンソースモデルがこの複雑なケースにどのように対処できるかをこれから見ていくことにしよう。
08:08.260 --> 08:11.590
それで何をやっているんだ。
08:13.240 --> 08:15.970
だからすでに問題がある。
08:15.970 --> 08:16.840
問題がある。
08:16.840 --> 08:24.790
そしてその問題とは、 乱数を生成するためのアプローチを再実装することを決定し、
08:24.790 --> 08:36.380
この、 LCGで設定したアプローチを変更したことだ。
08:36.410 --> 08:41.270
システム・プロンプトには、 乱数生成に関する機能を変更してはいけないとはっきりと書いておいたにもかかわらず、
08:41.270 --> 08:43.760
だ。
08:43.790 --> 08:50.990
だから今回も、 コエトケンにその戦略を変えるよう説得することはできなかった。
08:51.050 --> 08:53.960
ええと、 もっとうまくできるかどうか、 実験してみるといいよ。
08:53.960 --> 08:58.580
しかし、 私自身はいくつかの実験をしながらも、 そうすることはできなかった。
08:59.000 --> 09:00.950
もうすぐ終わるよ。
09:01.160 --> 09:01.940
これでよし。
09:01.940 --> 09:02.540
終わったよ。
09:02.570 --> 09:07.640
だから、 最後に来るものを取り除き、 最初に来るものを取り除く。
09:07.640 --> 09:09.680
そして今、 真実の瞬間が訪れる。
09:09.680 --> 09:15.230
コード・クワンのCプラス・プラス・コードを実行し、 下にスクロールする。
09:15.770 --> 09:21.380
それでわかったのは、 もちろん、 その数字が一致しないということだ。
09:21.410 --> 09:23.930
以前の結果を覚えているのなら。
09:23.930 --> 09:30.220
だから残念ながら、 コード・クワンはこの数字を再現することに成功していない。
09:30.220 --> 09:37.420
それはもちろん、 独自の乱数発生器を持っているからだ。
09:37.720 --> 09:42.850
ええと、 いくつか、 ええと、 興味深いことをやっているんだ。
09:42.850 --> 09:49.930
より効率的な方法を潜在的に認識しているように見えるが、 数字が一致しないため、 実際にすべてを正しく実行し、
09:49.930 --> 09:56.230
正しい数字を得たかどうかを検証することはできない。
09:56.230 --> 10:00.970
だから残念ながら、 残念ながら、 私はとても期待していたんだ。
10:00.970 --> 10:08.830
Codeclanは簡単なテストであるパイテストには合格したが、 Codeclanは難しいテストでつまずき、
10:08.830 --> 10:19.060
Pythonコードと同じ答えを再現できなかった。
10:19.060 --> 10:24.850
そういう観点からは、 残念ながらフロンティア・モデルが上位に来る。
10:24.850 --> 10:27.370
勝利のために再び爪を立てた。
10:27.370 --> 10:30.340
コーデクランは間に合わなかった。
10:31.240 --> 10:33.250
それではまた次回、 総括を。