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 それではまた次回、 総括を。