すべてを美しいユーザー・インターフェースにまとめる瞬間へ､ ようこそ｡
その前に､ もう一度Huggingfaceの推論エンドポイント画面を見てほしい｡
クワイン1 570億チャットの推論
我々はできる｡
分析結果を見たり､ 何が起こっているのかを見たり､
リクエスト数を見たりすることができます｡
ええと､ レイテンシー､ CPU使用率｡
そうだ｡
CPUの使用率とGPUの使用率が少し上がっている｡
いいね｡
それと､ "コスト "を見て､ 僕が3ドル使っていることがわかると思う｡ これまでのところ､ この特定のモデルで64回｡
うーん､ わかった｡
さて､ それを念頭に置いて､ アナリティクスは置いておいて､ Jupyterラボに戻ろう｡
コード・クワンを呼び出すこのコードを､ GPT4やクロード・ストリーム・クエンですでにやった他のストリーム・メソッドと同じように､
小さなストリーム・メソッドにまとめよう｡
同じような方法だが､ もちろん同じ機能だ｡
そのやり方はまったく違う｡
これはトークナイザーを作成する｡
もちろん､ Pythonを通常のメッセージリストに変えることになる｡
チャットのテンプレートが適用されます｡
これでトークン化の準備が整った｡
そして､ エンドポイントのURLとHuggingfaceトークンを使って推論クライアントを呼び出します｡
そして､ ここではクライアントのテキスト生成を行っている｡
ここにストリーミングしたいテキストがある｡
これが新しいトークンの最大値だ｡
そして結果が戻ってくる｡
各トークンをストリームバックする際に､ これまでの合計を返す｡
それは､ すべてのチャンクでこれまでに受信されたすべてのものの累積合計のようなものを期待している｡
つまり､ このストリーム・コレクションという関数は､ 前に書いたストリームGPTのストリーム・クロードの関数と同じものなのだ｡
これで､ コードを最適化するための､ 以前の最適化された方法に代わる最適化された方法を手に入れることができ､ 3つのモデルGPTクロードかコード・クワンの間で反転することができる｡
うーん｡
そしてここに､ Gradioのユーザー・インターフェースのコードの合計がある｡
これを必ず実行する｡
ええと､ だから､ これがどれだけ簡単なことか思い出してほしい｡
クレイジーだよ｡
タイトルをつけて､ PythonのコードとC＋＋のコードを並べます｡
モデルを選択する行がある｡
そして今回､ これまで選べた2つのモデルにコード・クォンが加わった｡
コードを変換するボタン､ Pythonを実行するボタン､ C plus plusを実行するボタン､
そしてPythonの結果とcplusplusの結果の出力ボックスがあります｡
そして､ これが3つのアクションだ｡
ボタンがクリックされたら､ 何らかのアクションを起こす3つの場所｡
そして､ 単純に英語のように読めるところが好きだ｡
もし誰かがコンバートを望むなら､ コンバートボタンを押せば､ 最適化機能が呼び出される｡
これがインプットで､ これがアウトプットだ｡
Pythonの実行ボタンを押すと､ Pythonが実行される｡
入力はPythonのコード､ 出力はPythonのout､ C plus plusボタンも同様｡
超シンプルに見えるはずだ｡
それは超シンプルだからだ｡
そして､ 私たちはそれを発表するつもりだ｡
これが僕らにとって見事に機能することを祈っているよ｡
さて､ これがユーザー・インターフェースだ｡
もちろん､ ここにあるのは単純な円周率計算のPythonコードだ｡
なぜダメなんだ？
GPTでやってみよう｡
Cプラス・プラス相当と覚えておいてほしい｡
Pythonのバリエーションを実行してみよう｡
私の記憶が正しければ､ これは約8秒だ｡
だから､ これが8カウントになるのを待つしかない｡
そして､ パイソンの結果を得るべきだ｡
そこに8がある｡ 6秒｡
古き良き円周率は､ 少なくとも小数点以下何桁まで存在する｡
そして今度はCプラスを走らせる｡
それにGPT4から戻ってきた｡
そして0点でも素晴らしい｡ 秒の06は100倍以上の向上だ｡
クロードのためにもう1度｡
Anthropicのクロードの好意でコードを変換した｡
あ､ あった｡
そして今度はクロードのCプラスを走らせる｡
それに
そして､ またGPT4に僅差で勝った｡
でも､ このラインが入っていることで､ わずかに速くなったのかもしれない｡
クロードのコードの方が本当に速いのかもしれない｡
うーん､ あまりに似ているので疑ってしまう｡
これがそうだ｡
これはコンパイラによって最適化される｡
しかし､ 一貫してわずかに速い可能性はある｡
だから､ あなたはCプラス・プラスの専門家かもしれない｡
それは私に教えてくれる｡
そして､ 自分のアーキテクチャでそれが速いかどうか､ 自分で試して納得できるかもしれない｡
しかし､ とにかく､ それは問題ではない｡
我々がここで見ているのは､ コードの品質がどの程度なのかということだ｡
コンバートは可能か？
それは理にかなっていて､ 何か違いがあるのだろうか？
コード変換ボタンを押して､ 何が起こるか見てみよう｡
だからまず第一に､ 僕らが知っているように､ それはもっとおしゃべりなんだ｡
その説明を正しく取り除けていない｡
だから､ それを削除する必要がある｡
しかし､ 私たちはそれを許す｡
そのような余計なものを加えたからといって､ コードモデルを非難するつもりはない｡
覚えておいてほしいのは､ これはすべてエンドポイントから見ている今現在のストリーミングだということだ｡
こっちに行ったら､ リフレッシュする必要があるかもしれない｡
私たちは､ 私たちがそうであることを確認しなければならない｡
確かに､ 結果をストリームバックするときにCPUとGPUが点滅するのが見える｡
ええと､ ではここで､ ええと､ グラデーションのスクリーンに降りてください｡
さあ､ 始めよう｡
ええと､ 私たちは､ ええと､ 完全な解決策を持っています｡
だから､ これからやることは､ 一番上にあるものを取り除き､ 最後にある必要のない説明を取り除くことだ｡
そして､ このCプラスプラスのコードを実行し､ クインがどのような結果を残したかを確認する｡
試してみよう｡
そして走り､ 速かった｡
GPT4とほぼ同じだった｡
同じぐらいだと思うよ｡
ええと､ プラグマは入っていないようですが､ 素晴らしい仕事をしてくれているようです｡
同じ答えだ｡
そして､ それはコードにとって間違いなく成功だと思う｡
クインだ｡
そしてまた､ コード・クインがここで実行している70億のパラメーターと､
GPT4やクロードが持っている2兆以上のパラメーターの違いを思い出してほしい｡
じゃあ､ ここに戻って､ ハードルを上げよう｡
チャレンジをもっと難しくしよう｡
この値をPythonのハード､ つまり最大部分配列和を計算するコードに変更してみよう｡
そして､ 我々のオープンソースモデルがこの複雑なケースにどのように対処できるかをこれから見ていくことにしよう｡
それで何をやっているんだ｡
だからすでに問題がある｡
問題がある｡
そしてその問題とは､ 乱数を生成するためのアプローチを再実装することを決定し､
この､ LCGで設定したアプローチを変更したことだ｡
システム・プロンプトには､ 乱数生成に関する機能を変更してはいけないとはっきりと書いておいたにもかかわらず､
だ｡
だから今回も､ コエトケンにその戦略を変えるよう説得することはできなかった｡
ええと､ もっとうまくできるかどうか､ 実験してみるといいよ｡
しかし､ 私自身はいくつかの実験をしながらも､ そうすることはできなかった｡
もうすぐ終わるよ｡
これでよし｡
終わったよ｡
だから､ 最後に来るものを取り除き､ 最初に来るものを取り除く｡
そして今､ 真実の瞬間が訪れる｡
コード・クワンのCプラス・プラス・コードを実行し､ 下にスクロールする｡
それでわかったのは､ もちろん､ その数字が一致しないということだ｡
以前の結果を覚えているのなら｡
だから残念ながら､ コード・クワンはこの数字を再現することに成功していない｡
それはもちろん､ 独自の乱数発生器を持っているからだ｡
ええと､ いくつか､ ええと､ 興味深いことをやっているんだ｡
より効率的な方法を潜在的に認識しているように見えるが､ 数字が一致しないため､ 実際にすべてを正しく実行し､
正しい数字を得たかどうかを検証することはできない｡
だから残念ながら､ 残念ながら､ 私はとても期待していたんだ｡
Codeclanは簡単なテストであるパイテストには合格したが､ Codeclanは難しいテストでつまずき､
Pythonコードと同じ答えを再現できなかった｡
そういう観点からは､ 残念ながらフロンティア・モデルが上位に来る｡
勝利のために再び爪を立てた｡
コーデクランは間に合わなかった｡
それではまた次回､ 総括を｡