近況報告とスイスでの生活
はい、Lisaのみなさんこんにちは。London Tech TalkのKen Wakatomoです。
じゃあ、今日、Kazもよろしくお願いします。
お願いします。
はーい、ということで今日はゲストに、Asaiさんをお呼びしています。
ようこそ。
お久しぶりです。よろしくお願いします。
いぇーい。
なんか、この3人のメンツで話すの久々じゃない?
久しぶりですね。
ワクワクするメンツだよね、これ。
嬉しいわー。
楽しみにしてました。
うーん、あれ、大西が生まれてからポッドキャスト来てくれたよね?
えー、大西生まれてからは多分来てないですね。
生まれる前に何度か来てましたけど、多分初めてです。
そうだ、僕が大西生まれて忙しい時に何回か出てくれたので。
そうですね、はい。
前回は195回で、アツと畠山アツシさんと撮ってくれたやつだよ。
あ、そうですね。
最近どうですか?育児、仕事、スイス、もろもろ込みで元気にやってる?
まあ、大変ですね。いろいろと。
育児はもう子供が5ヶ月になったのでだいぶ落ち着いてきて、最初の3ヶ月はかなりきつかったですけど、
まあ、慣れてきたというか、ところがありますね。
仕事もあって、今一番大変なのは天気ですね、やっぱ。もう暑すぎて暑すぎて。
暑い。あれ何度くらい行ってたっけ?
ジネーブは最高36度行ったのが先週末ですね。今は涼しいんですけど。
やっぱり、エアコンが家にないので、夜も寝苦しいし、昼間も午後は特に暑いし、夜10時まで日が昇っているから、
もう無限に暑いっていう、全く冷えなかったからそれがきつかったです。
そうだよね。特にお子さんとか寝れてる?寝れてる?
暑いと、うちの子とかも夜起きる回数が3倍くらいになるんだけどさ。
いや、それは間違いないですね、本当に。めっちゃ起きますね。汗かいてるし、おしっこの量とかもすごい減ってちょっと心配になるみたいな。
脱水とかも気をつけなきゃいけないしね。
そうですね。なんか本当にヒートウェーブをどう乗り切るか、どう部屋を冷やすかみたいなことを本当に8割考えてるみたいな。
でもそれはそれで面白いというか、どうやって空気が循環してるんだろうみたいなことを考えるじゃないですか。
はいはいはい。
どういう風に熱がこもるみたいな。それはちょっと勉強になったような気がしますけど。
なるほど、面白い。なんか建築家っぽい発想ですね、それは。
建築家。
空気の循環を。それ、そっか。
やっぱりこっちの家は、冬向けというか、冬になるべく熱を閉じ込めるような設計になってるんじゃないかなっていうのはすごい思って。
なかなか熱も抜けないから、ヒートウェーブが終わってもちょっとまだ暑い。勝手に温度が上がっていくみたいなことがあったりして。
ないですか、そういうの。
でもなんか熱はこもりやすいよね、こっちはね。
どうしたらいいんですか、その空気の入れ替え循環を意識して。結局窓開けるしかない。
いやもう本当に朝起きたらすぐ窓開けるとか、というか窓開けたまま寝るとか、そういう感じですね。
窓開けたまま、そっか。
夜の涼しい空気を取り入れる。で、結局最終手段として僕はエアコンを買いまして。
買えたんだ、よかった。
昨日も届きました。
よかったね。あれなんか数買おうとしたけど買えなかった?
買えない買えない。
9月発送早くて。
夏終わってる。
どこも売り切れだよね、ロンドンは。
なんかでも僕も7月末くらいに来る予定だったのが、7月2日に届いたんで。
意外と注文しちゃえば来るかもしれない。
発送前ならキャンセルもできるんで。買っておくみたいなのもありかもしれないですけど。
昨日来た?今日来た?
昨日来ました。まだ付けてないですね、最近は涼しいんで。
そっかそっか。じゃあ次のヒートウェーブが楽しみだね。
こっちの役もめんどくさいんで、結局窓を開けてそこにホースを通してみたいなことするじゃないですか、フォータリーみたいな。
それはやっぱりあんまりやりたくないですけどね。
楽しみというかだいぶ気が楽になりました。
自社LLMのリリースと評価プロセス
良かった。大きさとしてはアサイくんの背丈の半分くらい?
そんなもんですかね、はい。重さが何キロだったかな、60とか多分あるんですよ。
だから車輪が付いてて、ポータブルなんで車輪で動かす。でも段ボールを自分じゃ持ち上げられないんで。
一生懸命開けて出して車輪で運んでみたいな感じですね。
子供とかが倒してたら怖いですよね、気を付けないと。
室外機のポンプをいつの間にか外から外してて、暑い空気が家の中に滞留してたってことはありましたけど。
ヘアコンの意味がないみたいな。
けんさん家のは何キロくらいあるんですか?
僕の家も大きくて、僕の背丈の半分くらいで、持とうと思ったら腰が痛くなる。
ポータブルとはいえ、結構大きいパワフルな分。
そうですよね。仕方ないですね。
なんとかサバイブしてるようで元気な顔が見れてよかったです。
本題に入る前にカズの方から聞きたいことがあれば。
大丈夫です。
今日浅井君を呼んだのは、僕が久々に話したいっていう理由はさておき、
彼がnote.comのほうに最近のSREを離れて、
AI ML関連のジョブチェンジにしたっていう話は、いろんなポッドキャストとかに出たり、
いろんなところを目にしたリスナーの方もいると思うんですけど、
そこで2つ記事を出されていて、
1つ目が2026年3月に出されていた移動のその後と自社LLMのリリースということで、
浅井君が携わったプロダクトのパブリックの情報が出されたということで、
これについて書かれていたんですね。
ここは詳しい説明はご本人から後で知ってもらおうと思ったんですけど、
これ読んですごい面白いな、技術的に面白いなと思ったので、
技術的な深掘りを3人でちょっとしていけたらいいかなと思って、
呼びたいなと思ったんですね。
もう1本ノート記事を5月30日に書かれていて、
これは多分同じプロジェクトとか同じチームの流れからだと思うんですけど、
もうちょっとキャリア面に深ぼった話で、
リサーチエンジニアというキャリアというタイトルでノートも書かれていたので、
そこのプロダクトの話から新しいチームでのキャリア感みたいなのを、
今日今のスナップショットとして浅井君と一緒に話せたらいいかなと思ってお呼びしました。
じゃあどうしよう、このLLMのリリースのところを
ご本人のお口からちょっと紹介してもらうというのは可能ですか?
ありがとうございます。興味を持っていただけて嬉しいです。
そうですね、この最初の記事のLLMのリリースというところで、
自分の会社でOpenAIが出したGPT-OSSというオープンウェイトのモデルがあるんですけど、
そのモデルをソナーキューブというサービスを使って、
ファインチューニングしたモデルをリリースしましたというのが去年末なんですけれども、
僕が移動したのが10月だったので、
僕はトレーニングに関わるというよりはそのモデルの評価に関わってきていて、
その話を記事に書いているという感じですね。
このファインチューニングは僕全然経験がないので、
その辺の詳細はあまり分からないんですけれども、
評価するというところは結構パイプラインとしてどうするかというのが分かってきて、
それを記事に書いたんですけれども、結構評価するのも大変というか難しいところがいっぱいあって、
勉強になったなというので、
まずモデルを評価するにはどうすればいいかというと、
まずモデルをデプロイする必要があります。
モデルというのはもちろんCPUで動く小さいモデルもあれば、
大きいモデルはGPUに乗っけて動かす必要があるというのがありまして、
まずGPUにモデルをデプロイするというところから始まって、
ようやくデプロイをしてからそれを動くか確認する、
ヘルスチェックとか実際にチェックをして、
その後に評価を始めていくという流れになるんですね。
評価をするといっても評価の仕方もいろいろあって、
主流なのはベンチマークを実行して、
他のモデルと比べてどうかみたいなことを測っていくというのがやり方の一つとしてあるので、
それを僕は主にベンチマークのパイプラインを実装するとか、
そういうところもやってきたという感じになります。
SREだったじゃないですか、前キャリアがね。
このLLMの評価パイプラインというのをやってみて、
エモい感想としてはどうでした?楽しかったですか?
どういうところに技術的チャレンジがあるのかなと思って。
そうですね。
SREでやってた頃の親和性とかでもいいし、
違いでもいいし、新しい発見とか。
デプロイというところで言うと、
クラウドのプラットフォームのことが結構分かっているので、
その辺、知識を横転できるところはかなり多かったので、
それは楽だったなというところもありつつ、
やっぱり全然既存のアプリケーションと違うところが多いので、
その辺、分からないことが多い。
例えばGPUのマシンにもいろいろ特徴があって、
なんとなく普通の汎用のCPUだったら、
メモリーに強いマシンとかいろいろあるのが分かるんですけど、
GPUの場合はいろんな、NVIDIAが思い出しているバージョンの違いがあって、
それと何が違うのかというのが全然分からない。
例えばL40というインスタンスがあったりとか、
A10というインスタンスがあったりとか、
その辺のどういう違いがあるんだろうみたいなのも、
詳しいことはよく分からないものを進めていたので、
その辺難しいなと思いましたね。
このモデルのサイズ感って、
こういうプロダクションのプロダクトとして出すレベルのものって、
どれぐらいのものになるんだろう。
例えば僕がこの前ローカルで遊んでいたのは、
クエンコードっていうモデルがあって、
僕はMacBook Pro 4の24GBが個人機なので、
16、KVキャッシュ1GB、2GB含めて18ぐらいで結構、
ほぼそのローカルのモデル回して、
なんかあんまりGPT5とか4とかと比べても、
そんなに大した結果じゃないなみたいなモデルを
動かしたんですけど、
このプロダクションにデプロイするレベルっていうのは、
50、60GBとか100GBとかそれぐらいのサイズ感になるんですか。
そうですね。
やっぱり僕が使ってたのは、
パラメータが20ビリオンのモデルなので、
大体30GBとかのもので、
展開すると多分40とかになるのかなみたいな感じだったんで、
結構でかいやつを使ってて、それでも遅かったんですけど、
最近やっぱりそういうクエンとかのモデルだと、
小さくても早いみたいなのは結構あるので、
プロダクションって言っても、
どの程度のクオリティかにもよりますし、
例えばクラウドのソネットとかそういうレベルのクオリティを出そうと思うと、
多分相当でかいモデルを使わないといけないのかなみたいなのを、
けんさんもおっしゃる通りになると思います。
なるほど。
この白いですね、プロダクトはハギングフェイスに、
オープンソースみたいな形でモデルとして出してるから、
使いたい人は誰でもダウンロードできるのかな?
はい、できます。
これ自体は何でしょう、一応、
ソナースウィープっていうサービスがありまして、
それ自体は、ガベージイン、ガベージアウトみたいな言葉があるんですけど、
ソナーの製品自体はコードをより良くするための製品なので、
そのソナーの製品にスキャンかけて、
ディータセットのコードをより良くしたものを使えばより良くなるんじゃないかみたいな、
出力もみたいなことを検証するためのモデルなので、
正直使った時に使いやすいかと言われたら多分そんなことはないんですけど、
実際にベンチマークを実行してみて、
実際にクオリティが上がっているかという研究をした結果のモデルになるので、
一応使えますけど、使いやすいものではないと思います。
なるほどね。
Javaを想定ユーザーとしてJavaをガリガリ書いている人がみんなこぞって使うっていうよりかは、
はい。
それこそソナーが中で使っているよってそれをオープンソースとして公開したみたいな感じ?
中でも使ってはないですね。
これ自体はそもそものコンセプトを検証するためのモデルなので、
モデル公開しましたけど、
興味があれば実際に触ってもらってもいいですしみたいな感じですかね。
なるほど。貴重なマイルストーンということなんですね。
ソナースウィップのページを見ていると成果として41%のバグのリダクションと
セキュリティバラナビリティがありましたみたいなのが書かれている。
この41%の結果を出す評価みたいなところは浅井君が手伝ったみたいな感じなのかな。
そうですね。
それもソナーキューブを使ってメトリクスを生成しているんですけど、
元々のモデルを使ったときに、
モデルにコード生成をさせるベンチマークを今回は使っているんですけども、
コード生成をさせて出してきたコードをそれぞれソナーキューブのスキャンにかけてみて、
バグの量とかセキュリティの問題の量とかを比較してみるというのがやってきたことですね。
実際にソナーキューブの、ソナースウィープのモデルを使うと
バグが実際少ないことが確認できました。
機能としても問題ないか、他の機能に何か劣化がないかみたいなのも
サニティチェックみたいなのを実行しました。
例えばジョークがちゃんと言えるかどうかみたいな。
元のモデルはちゃんと言えるんですけど、後のモデルでもちゃんとそういうジョークが言えるかどうかみたいなのを確認しました。
浅いジョークを突っ込んだんですか?
いや、ジョークはトレーニングにはちょっと打ち込んでないんですけど。
それは面白いですね。
ジョークのユーモアセンスがデグレデーションしてないかどうかを確認する。
軽くそれも冗談ですけど、
やっぱりトレーニングをかけた結果、忘却しちゃうこともあるんですよね。
必要なこと、そういうのが起きてないかみたいなのは確認するようにしてます。
面白いね。こういう開発プロセスって数的には経験したことある?ない?
いやー。
新鮮。
新鮮だね。
一応、ソフトウェアのテストと似てるのかな。
LLM評価における技術的課題とベンチマーク
でも、ゼロイチじゃないもんね、テストって。
テストはゼロイチじゃん。テスト書いて通ってますか通ってないかですけど。
だけどこっちはよりそれを検出できるかどうかでしょ?
しかも多分検出できるかどうかとかいろいろなメトリックスがあるはずだよね。
なんか速さとかもあるかもしれないし、あと誤検出が増えたか増えてないかみたいなとか。
確かに。
なんかいろんなパラメーターがあるような気がしてて。
こういうプロセスはやったことないかもね。
確かに。おっしゃるとおりですね。
やっぱりなんかLLMの挙動の内部をホワイトボックスでテストみたいなのはできないので、
基本的にはプロンプトを入れてその出力をチェックするとか、
最近だともう少しエージェンティックなベンチマークみたいなのがあって、
今僕がこの時やったベンチマークはワンショットでの高度出力のテストなんですけど、
それをもっとエージェントって今何往復もLLMとするじゃないですか、
その方が一般的なユースケースに近いので、
そういうエージェンティックなベンチマークを実行して結果を見るみたいなのもやります。
エージェンティックなベンチマークってちょっと聞いててあんまりピンとこなかったんですけど、
フレームワーク?ツールセット?コンセプト?
そうですね。
例えば有名なのだとSWEベンチみたいなのがあるんですけど、
フレームワークですかね。
最初に僕が言ってたベンチマークはワンショットで質問を与えて、
返ってきたコードに対してテストを実行したりするんですけど、
それは0,1で分かりますと。
エージェンティックな場合ももっと複雑な問題を与えて、
それは一回では返せないので何往復もした後の結果にテストをかけて確認するみたいな感じですかね。
結構これは僕もすごくややこしくて理解に時間がかかったんですけど、コンセプト自体は。
だから実行環境としてはどこかを立ち上げて、そこにリポジトリをクローンしてきて、
実際のコードを書く環境ってコード生成よりはコード修正とかが多いので、
例えばこのコードを直してくださいみたいなのを頼んだりすると、
そうするとまずはコードを読みます。
まずこのメソッドを理解しますみたいなのをエージェントがポンポンポンって実行していって、
最後にコードを直した結果がどうかみたいなのを確認するみたいな。
ちょっと微問いいですか。
ワンショットは0,1じゃないですか。
エージェンティックなやつはリアルなユースケースだと何往復も
エージェントとやり取りしますよねっていうのは分かるんですけど、
それって結構プロンプトの入力するプロンプトの質にもよるんじゃないかなと思ってて、
どこまでそれを人間のいいプロンプト、そもそもいいプロンプト、悪いプロンプトもあるんじゃないかなと思うんですよ、
そのテストするにあたってね。
それってまずプロンプトをどう生成するんですか。
かつそれがユーザーがこういうプロンプトを打つだろうっていうのをどうやって決めるのかなっていうのが疑問に思いました。
めちゃくちゃいいポイントですね。
これは誰もが頭を悩ませる問題みたいなところはあって、
例えばおっしゃる通り普段の開発のスタイルに近いようなプロンプトを作るっていうのはすごい難しくて、
ある方法としてはオープンソースのリポジトリとかのコミット履歴とかを見て、
PRディスクリプションとかコミットのメッセージから問題を作り出すみたいな、
リプレイするような形でLLMに同じように解かせるみたいな手法は一つありますね。
なのでLLMでも同じように問題解けるかどうかみたいなことを確認したりもしますし、
一方であるリポジトリに対してLLMに問題を作らせたりするみたいなパターンもあったりして、
LLMが例えばこのリポジトリに対してこういう問題を作ってくださいみたいなことをまずプロンプトを生成するパイプラインを作った上で質問を生成して、
大体の場合はLLMが作った問題って質が低いので、
いいベンチマークの場合は大体人の目を入れてレビューしていく。
良いプロンプトとか良いタスクだけを集めたものをリリースするみたいな形になるのかなという感じです。
なのでおっしゃる通り良いプロンプト、悪いプロンプト、良いタスク、悪いタスクみたいなのがすごいたくさんあって、
いろんな大学とかいろんな会社の研究チームがベンチマークを出してるんですけど、
本当に良いベンチマークっていうのはかなり限られてるんで、
すごいよく見極めてベンチマークを使わなきゃいけないみたいなところはあると思います。
なんかそれだけでもビジネスになりそうだと思う。
AI周りというか、この良いプロンプトを厳選して売りますよとか、
AIの会社に対してオープンAIとか、AI作ってるところに対して、
それだけでもビジネスになりそうだなと思いました今けど。
なると思いますし、多分それだけに集中してる研究チームとかもあると思うんで、
あるんじゃないんですかね実際に。
データベースの世界だとあるので、
それでお金を作ってるのもやっぱり業界標準的なベンチマークスクリプトとかもあって、
例えばイーコマース系のデータを元にやってますとか、
データモデリングがね、例えばショップとかプロダクトがあってとか、
あとはもう全然関係ない、いろんなドメインごとのベンチマーク準備したりとか、
あとはやっぱりこういうのって独立団体がベンチマークをすることが大事。
例えば会社AがプロダクトAを出して、
自分たちのベンチマークスクリプトでどうぞはすごいだろうって言っても、
でもそれってそのプロダクトAを盛り上げるためにちょっと改ざんされたスクリプトでしょっていうことはよくあるので、
そういった独立されたベンチマーク専門のフリーランサーみたいな人がいて、
いろんなデータベース会社に同じ標準でベンチマークして、
その評価結果を出すことでお金をやってる結構有名な人がいたりとかするので、
全然AIもありそうな気がする。
いや本当にあると思います、そういうのは。
なんか面白い例で言うと、
まあやっぱり、ああそうっすね、
いろんな問題があって、
例えばAIだと、
そうですね、もちろんベンチマークっていくらでも嘘がつけるなって思ったのが一つあるんですけど、
さらにAIだと、
AI自身が嘘をつけるというかっていう点もあって、
例えば最近のソネットファイブみたいなのをベンチマークした人がいるんですけど、
そのソネットファイブはこれまでのモデルよりも、
回答を盗み見せるっていうか、
要はベンチマーク、これはベンチマークだって分かってるから、
なんかチートして、
なんか答えがあるところにリポジトリアクセスして、
回答を持ってきちゃうみたいなことをする回数がめちゃくちゃ増えたみたいなこともあったりして、
なんか、
カンニングだね。
カンニングとかもできますし、
なんかそれこそちょっと環境の状態を変えれば、
全然気が利くときたりするんで、
もうおっしゃる通りなんか、
うまいこと操作することができるんじゃないかなって思います。
成績優秀だと思ってた子が実はカンニングしてたみたいなショック感が。
そうですね。
ベンチマーク難しいね。
難しいですね。
ベンチマーク対策とかもできちゃうんで、
ベンチマークをトレーニングに組み込んでおけば有名なベンチマーク、
そのベンチマークとかで結果が良くなるのでみたいな。
そういうのがありました。
GPUリソースの枯渇とキャリアの模索
あとそのノートでもう一つ書いてた面白い、難しかったポイントが、
GPUリソースの枯渇っていうことも書いてて、
これは結構いろんなところでニュースも聞いたりするし、
僕も肌で実感するところであるけれども、
今本当にマシンの値段が上がっているんですよね。
それを開発で肌に感じたというのが面白いんですけど、
ここも簡単に実際どうだったのか聞いてみてもいいですか。
結構フラストレーションポイントだったんじゃないかなと思うんですけど。
そうですね。
GPUの値段がすごい高くて、
例えばEC2のAWS上で動かすと、
例えばA10Gという片落ちのやつだと、
1時間で例えば10ドルとか、
メモリーがどのくらいだっけな。
忘れちゃいましたけど。
60何ギガとかのメモリーで1時間10ドルとかするわけですね。
それでかつ最新のもっと新しいモデルだと、
もう少し安くて早いみたいなところはあるんですけど、
やっぱり古いモデルと新しいモデルの性能が全然違うので、
コストが半分でも同じくらいのクオリティになったりするんですね。
なので新しいモデルができれば使いたいなというのはあるんですけど、
その新しい方は結構全然使えなくて使えない時があるみたいな。
ヨーロッパの朝の時間なら結構使えるけど、
午後になると使えないみたいなことがあったりして、
それは結構ストレスかと思います。
お金がいっぱいあれば古いモデルでバンバン建てて、
古いマシンを建てて使えばいいんですけど、
でもお金かかるんで、
なんていうかかなり体力がいるなと思いますし、
その辺多分企業ごとに力がある企業だったら、
その辺確保できるというか、
AWSとかクラウドプロバイラーとかと交渉して、
自分たちのマシンを確保している企業もあると思うんですけど、
僕らの場合は別にそんなリソースもあるわけでなかったので、
新しいモデルは手に入りづらかった、
新しいマシンは手に入りづらかったんですね。
アサイ君のレベルでは、
一、リサーチエンジニアのレベルでは、
その予算感とかってどこまで普段から意識する?
これどっちかというとチーム体制の質問になると思うんだけど、
例えば新しいインスタンスを使えません、
古いインスタンスでなきゃいけませんみたいな、
でも本当はお金があればよりいいインスタンスを使いたいみたいなのっていうのは、
個々人が予算管理をしている、
どういうフローなのかなと思って。
結構それは緩くて、
別に古いマシンでおたくさん立てても、
別に誰も文句を言わないような環境ではあるので、
別に今僕がちょっと気にしただけなんですけど、
なんでそんなにプロセスとしては複雑ではなかったですかね。
逆に言うとすごいお金を使ってたら、
月次のレポートで刺されるみたいなそういう感じなのかな。
少なくとも僕は刺されはしないですし、
今のところ研究チームということで、
そんなに厳しい予算はなかったので、
僕はあまり苦労はしなかったです、そこの点では。
一番キャッチアップが大変だったところとか、
時間をかけたところとかどこにありますか。
ベンチマークからちょっと距離を置いて、
全体のこのプロジェクトをどうして。
そうですね。
あまりこのトピックとは直接関係ないんですけど、
やっぱりバイブコーディングっていうか、
AIコーディングが始まってまだ一年経たないみたいなところだったので、
その距離感みたいなのが一番難しくて、
パイプラインとか作るのも全部コードで書くんですけど、
それをAIに書かせるとかじゃないですか。
世の中のトレーナーとしては、
どんどんAI使っていこうみたいな、
AIでネイブさせて、AIで書いてみたいな風潮も、
言うことを言う人もいましたし、
逆にAIにコードを書かせて安全じゃないみたいなことを言う人もいろんな人がいる中で、
僕は結構、例えばその時はAIをガンガン使って、
複数のエージェントを立ててそれをどんどん実行して、
なるべく早く仕事を終わらせていこうみたいなマインドでやってたんですよね。
でもやっぱりそれって結構今思うと普通に大変というか、
エージェントをいくつも立てるってすごい素晴らしいことに思えるけど、
その分自分のコンテキストも分散してしまって、
なかなかどれを進めているのか分からなくなるみたいな、
ちょっと頭が混乱されたこともあったりとか、
その書いたコードを一応レビューするというプロセスもあるので、
必ずしも周りの人が同じようにやっているわけじゃないですかね。
そういうところで足並みを合わせたりするというか、
スピードと質のバランスをどう取ればいいかみたいなので、
ちょっと難しいなと思うことはありますね。
そこら辺の悩みとか課題は僕らSREとかプラットフォームエンジニアとか、
バックエンドエンジニアでも感じているところではあるよね。
そうですね。
技術的な面でいうと、検索さっきおっしゃったような、
KBキャッシュとかそういうやっぱりLLM独特の技術の理解みたいなのは
すごい時間がかかるし、今でもキャッチアップしているところなので、
やっぱりこれまでLLMとかマシンラーニングとかしてきましたという人と比べてしまうと、
技術に全然知識量に差があるところはあるので、
そこは追いつくのもなかなか大変だなという感じはありますね。
そう、まさにそこもちょっと深掘りしてみたくて、
2つ目の記事、リサーチエンジニアというキャリアみたいなところにも
ちょっと繋がってくるのかなと思うんですけど、
アサイさんはね、いかに優秀だったとはいえSREじゃないですか、畑が。
はい。
そこでリサーチエンジニアとしてポーンって入ったじゃないですか。
だからキャリアの進め方って結構模索してるんじゃないかなと思っていて、
他の、例えばずっとペーパー書いてきたような人とか、
マシンラーニングのMLOpsやってきたような人と比べて、
どこで価値を発揮するのかみたいな、
自分のバリエーションポイント探すのってめっちゃ難しくないと思って、
そういうチャレンジを同じようなしてる人に結構いると思うんだけど、
どういう工夫してるのかな。
もしくはどういう今苦労してるのかなというのをちょっと聞いてみたいなと思って。
これは頭が痛い問題で、やっぱり何でしょうね。
おっしゃる通り全然違う分野でやってて、
僕のチームにも、さっき申し上げたようにMLOpsとか研究畑の人がいて、
難しいですね。
MLOps、これは僕も全然答えがないんですけど、
今僕としては新しいことを学んでる状態というか、
自分はたぶんLMの知識とかその辺でいうとチームの中でもかなり下の方なので、
苦しいですけど、そういう環境で学べることを楽しもうというスタンスでいこうかなと思ってて、
例えばチームで結構論文とかこういう論文があるよみたいな日々共有されるんですけど、
そういうの積極的に読んでいったりとかして、
ちょっと研究者感を味わうというか、味わいつつもっとその技術面で深掘りしていきたいなみたいなところは思っていますね。
だからそのどう立ち回るかみたいなところはちょっとあんまりまだ掴めてないところがあって、
それこそプラットフォーム寄りの仕事をすればできることはあるんですけども、
でもなんかもう少しデータセットを準備したりトレーニングに関わることをやってみたいなという風な思いもあったりとか、
評価ももっと深掘り、ベンチマーキングも深掘りする余地がたくさんあるので、
そっちの普段これまでやってこなかったことをもう少し深掘りしてみたいなみたいな思いはありますかね。
自分ができるからといってCICDの改善とかSREとかプラットフォーム的な動きずっとしてたら変わった意味ないもんね。
そうなんですよね。ちょっとその辺はバランスを取らないと、自分の成長としてはどうなんだろうなみたいなことはありますね。
なんかこう逆に自分ならではの強みみたいなのはあったりするんですか。
他のリサーチエンジニアと比べてSREとか、そこのこういうところが自分の得意というか他の人にはできないかなみたいな業務の中でリサーチエンジニアとしてはありますか。
やっぱり僕はそこはAWSとかの知識なのかなと思ってずっとAWSのプラットフォームを触ってきたので、
なんかそのAWS上でインフラ構築したいとか、それこそオブザバビリティを隠したいみたいなときは役に立てるかなっていうのはありまして、
この前もちょうどKubernetesクラスターを使ってモデルをデプロイしようみたいなタスクがあったんですけど、
久しぶりにKubernetesを触ってやってたらすごい楽しくて、
そういうところは電飾でも使ってたんで役に立てるところはあってよかったなと思いましたね。
あとは何ですか、意外と社内のプロセスの進め方みたいなところですかね。
今もう3年目なんで、その辺は意外と周りに新しい人が多くて、どうやって例えばこのセキュリティチームから承認をもらうかとか、
どうやってポジトリを設定するかみたいなところとか、そういうところはかなりスムーズに交渉を進めやすい、
新しい人に比べたら強いかなと思います。
今いろいろ学びたいことがあると思うんだけど、
PagedAttentionとLLMサービングの効率化
学ばなきゃいけないもの、学びたいもの、いろんなものがある。
キーワードとかテクノロジーとかで、今すごい気になってワクワクしてる、
それとも頭の中を閉めている技術とかフレームワークとか知識とかって何かあったりする?
読んでる本でもいいし。
でも最近興味があって読んでた論文がVLLMっていうサービスのPaged Attentionっていうやつで、
けんさんが今おっしゃってたようなKVキャッシュと関係あるんですけれども、
VLLMっていうのがサービングプラットフォームVLLMの、
このVLLMを使ってモデルをデプロイすると、
効率的にメモリを使えますよっていうのがオリなんですけど、
その論文が2023年くらいに出て、
そのPaged Attentionっていう技術を使って実装されたのがVLLMっていう本なんですけど、
これの何がすごいかっていうと、
これまでVLLMが出てくるまでのメモリ使用効率、
デプロイしたときのメモリ使用効率っていうのは結構悪くて、
KVキャッシュ、まずメモリがどう使われるかっていうのを説明してもいいですかね。
お願いします。
お願いします。
GPUにモデルをデプロイするときに、
例えば50GBのメモリを持ったGPUにモデルをデプロイしますと。
そのときに、まずモデルのウェイトだけで、
例えば25GB使いましたと。
GPUのモデルは全てメモリ上にデプロイされる必要があるんですよね、基本的には。
そのモデルを25GBメモリ上にデプロイして、
さらに残りの20GBを何に使うかというと、
その一部をKVキャッシュというふうに使って、
これまで来たプロンプトのトークンを保存しておいて、
すぐにアクセスできるようにするっていうのが、
KVキャッシュというものになります。
要はメモリ上に、
例えばNLMのリクエストリスポンスって、
いくつものトークンが連なってくるので、
トークンって例えば1つの単語あたり1トークンみたいな感じで思っておればいいんですけど、
そのトークンを例えば7単語のプロンプトになるときに、
トークンを1個1個処理していくんですけど、
それを7個を1個ずつメモリに置いていけば、
全部呼び込む必要がないみたいな、
そういう感じで理解してもらえればいいんですが、
じゃあPaged Attentionっていうのは何かっていうと、
これまでメモリの使用状況にめちゃくちゃ無駄があったのを、
ほぼ100%メモリを使えるようにしたっていうのがPaged Attentionなんです。
どこから来たかというと、OSのページングの技術を使って、
これまではOS、要はやってたページングの仮想メモリみたいな、
仮想ページみたいな、バーチャルメモリか、
っていうことすらできてなかったので、
それをできるようにしましたっていうだけなんですけど、
それが革新的ですごいっていう話ですね。
だからOSのバーチャルメモリ管理の、
あそこら辺のマッピングとかフラグメンテーションみたいな、
考え方を持ってきたってことでいいのか。
そうですね、まさに。
これまでだと、それまでのだと、
メモリ上の一つのプロンプトなけれども、
メモリとの連続したスペースを確保しないといけなかったので、
連続してないといけないとなると、
無駄がめっちゃ発生するみたいなところがあったんですけど、
それを分割できるように、
フラグメンテーション。
フラグメンテーションとおっしゃる通りですね。
分割してもいいようにしたっていうのが、
一つの改善点。
だから要はそのメモリの使用箇所をブロックごとに分けて、
それを別のテーブルで管理するみたいな。
DBじゃん。
そうだね。
おっしゃる通り。
なんかやったことあるね。
やったことあるやつなんですよね。
すっごい神話性のある話だね。
そうなんです。
DDR8じゃなくて、
データベースインターナルで読んだような話だったんですけど、
そういうのが今、
その2023年に出たVLMの技術で、
なんかサービングだと、
サービングの技術って結構プラットフォームとの関係が高くて、
なんか面白いなっていうのは個人的に。
そっか。
だからPaged Attentionが要するにやりたいことは、
メモリをもうすごい効率的に使いたかったってことだよね。
そうですね。
で、そのためにOSのバーチャルメモリの考え方を適用して、
メモリをギリギリまで効率的に使えるアルゴリズムを発表しましたと。
メモリを効率的に使えるということは、
それを売りにしたサービングシステムを使うと、
他の競合よりもコストをよくさばけるんで、
そうですね。
強いっていうことでVLMを出したよってことなのかな。
そうですね。
なぜメモリが大事かっていうのを説明したかったんですけど、
LLMモデルのリクエストの段階に2ステップあって、
1つがプリフィーリングっていう、
実際にトークン来たプロンプトを読み込む段階と、
ジェネレーションの段階ですね。
デコーディングって言うんですけど、
ジェネレーションの段階が2つあって、
プリフィーリングの読み込む段階は、
読み込んで警備機械所に保存するっていうところなんですけど、
それ自体はGPUが分散処理できるんで、
GPUにボトルネックがある。
でもその後デコーディングでトークンを出力する段階、
読み込んだ後次の単語を予測するっていう段階では、
1個1個やっていかなきゃいけないんで、
メモリ上で1個1個次の言葉を予測して、
みたいなのをやっていく必要があって、
メモリにボトルネックが来るんです。
なんでそこを改善すると、
GPUの使用効率も上がるみたいな、
そういう話でした。
なるほど。
ストリーミングサービスの話っぽい。
ウェブとプラットフォームの人間としては、
そういう考えで聞いてましたけど。
そういう既存の技術とマッピングできるのが
面白いなと思って、
とっつきやすさもあって、
かつそれを深掘りしていくと、
どうトレーニングされてるかみたいなところも
勉強できるので、個人的にはすごい好きなトピックでした。
なるほど。
面白いね。
ファンアウトとファンインみたいな。
でもこれはアルゴリズムというか、
アーキテクチャー自体だから、
別に他社も真似できるわけだよね。
そうです。今は多分類似のサービスが
たくさん出てきていると思います。
それを元にしたオープンソースなので、
そもそも誰でも使えるような感じになってます。
逆に知らなかったんだけど、
KVキャッシュの発祥がここなのかな。
いや、KVキャッシュはこれより前からあって、
多分それがAttention Is All You Needみたいな
もっと有名な論文がある
トランスフォーマーっていうやつを
開発した論文がそこからなんじゃないかなと思いますね。
なるほどなるほど。
その話は次回してくれるということで。
いや、ちょっと。
ちゃんと勉強しないといけないです。
そうなんだね。面白い。
ブッククラブとキャリアの展望
結構論文とかもみんなで読んだりするんだ。
楽しそうだね。
みんなで読むというよりは、
読んだやつを発表、
1週間に1回発表する機会があって、
それをゆるく読むっていう感じですけど、一緒に。
ブッククラブじゃないですか。
ブッククラブですね。
ロンドンテックトークのクラブのあれが生きてます。
DDIAとかの時に論文をちょっと読んだりしたので、
抵抗が少なかったというか、
全然スタイルは違うんで、
ロンドンテックトークのブッククラブの方が
もっと密度が濃いというか、
ちゃんと事前に読んだり、みんなで読むんですけど、
僕らの場合は1人が読んで発表するだけなんで、
全然スタイルが違うんですけど。
すごい、なんか動画内広告みたいな感じの
みたいな。
皆さんブッククラブに入りましょうみたいな。
ぜひロンドンテックトークのブッククラブに。
そうかそうか。
頑張ってるね。
なんかそのキャリアの話は
カズもちょっと深掘ってみたいということだったけど、
なんかキャリアのノート記事の方で
ここ深掘ってみたいとかありますか?
カズの方で。
はい、ありますね。
なんか、もちろんね、
まだリサーチエンジニアとして働いてて、
AI業界いろいろ早いんで、
変わるかもしれないですけど、
今のところのアサヒさんの長期的なキャリアの目標とかゴールとか、
長期的でもいいし、
今考えてる、今の時点での全然スナップショットでいいんで、
こうなりたいなとか、
あったら聞きたいなと思います。
いや、正直全然ないんですよね。
っていうのも、
リサーチもリサーチやってるんで、
リサーチエンジニアを続けていきたいというか、
みたいなのは思っていて、
ただその先に何があるのかって、
例えば、話になったらベンチマークをもっと深掘りして、
ベンチマークを作るような仕事をするのかとか、
もしくはトレーニング領域に行って、
モデル用のポストトレーニングとか、
そういうようなことをするのか、
いろいろあるんですけど、
正直何がしたいかは、
今のところ分からないですね。
他に言うと、
自分にとっては、
この後どこに住むのかみたいなのが大事で、
日本に帰るのかもしれないし、
ヨーロッパの中で、
移動するってことないので、
多分、
じゃあどこに行くかみたいな方で、
キャリアを考えていく必要があるかなと思って、
その場合、
日本に帰るとなったらやっぱり、
日本にそういうトレーニングの仕事とか、
あんまりない気がするので、
じゃあそうだとするなら、
例えばSREに戻るのかとか、
そういうことも考えられますし、
っていう感じです。
あんまりちょっとパッとした答えが出ないんですけど。
日本でモデルのトレーニングとかやってるよ、
知ってるよっていうリスナーの方がいたら、
とりあえずアサヤさんに連絡すればいいんですかね。
いやいや、僕はまだまだ何もやってないんで、
評価とかだったら手伝えるかもしれないです、
評価の回答に。
でもリアル。
最近、日本のMLエンジニアの方とも喋ったんですけど、
その方はやっぱり日本の中では本当に限らない、
AI自体を作るっていうところの職業っていうのは、
かなり限られてて、
やっぱり一から作るってなると、
やってるところはあるかもしれないけど、
やっぱり外国とかに比べると全然規模も違うし、
楽しさとかも違うからとは言ってたんで、
言ってましたね。
そこで勝負するのも大変だなっていう、
それこそやっぱり皆さんPhDとかまで行かれて、
勉強してきた積み重ねがあった上で、
さらに競争にも生まれた、
アメリカと中国の戦いの中でやってたりするので、
そこで戦っていくのはちょっと厳しいかなって思いますね。
なるほど。
でもそれこそそういう幅広く知識をつけていって、
っていうのは個人的にいいかなと思って、
また例えばSREとかプラットフォームとかの仕事に戻るときにも、
使える知識ではあるのかなとは思ってて、
そのSREとかの仕事は最近あんましてないんで、
多分だいぶ生まれてると思うんですけど、
とりあえず今は興味のあるとか、
プロジェクトに必要なことをいろいろ深掘っていけたらなっていうのは感じですかね。
なるほど。
でもさっきのキャッシュの話とか、
AIのメモリのキャッシュの管理とか、
結局発想としてはですよ、
AIの領域を知識を持ちつつも、
ファンダメンタルなコンピューターのメモリ管理の部分の知識を持ってないと、
多分そこにブレイクスルーは起きないような気がするんですよね。
AIリサーチャーでかつコンピューターサイエンスの基礎知識を持つ、
それはまさにアサイさんが持ってるところだと思うんですよね。
だから、全然可能性というかありそうだなとか。
ありがとうございます。
ありそうなのあるっていうのは、
期待させるわけじゃないんですけど、
すごいコンピューターサイエンスのDDIAとかで学んだ知識っていうのはすごい大事なんだなと。
AI時代においてもそこは枯れない知識で持っておくべきなんだなと改めて思ったし、
AIの領域に行こうと思っても、
その知識を持ってることっていうのはすごい大事なんだなって学びましたね。
本当にそうだと思います。
やっぱDDIA出てよかったなっていう。
また動画内広告みたいな感じ。
でも数の隅付きがついたということで。
そうですね。
でもアサイくんがキャリア編のノートで言ってたことに、
すごい良いこと言ってるなって感動したところは、
キャリアこういうこと言っていて、
ソフトウェアエンジニアの仕事が10、100をする仕事で、
SREが100を99にしないようにする仕事であるとするならば、
リサーチエンジニアは0.5を1にできれば万々歳な仕事と言ってもいいだろうと言っていて、
すごい分かりやすい比喩だなと思ったんですね。
ありがとうございます。
それ踏まえた上でアサイくんは全部やってるじゃないですか。
0.5から100。
はい、100。
次はそれを生かせばいいんじゃないですか、掛け算。
確かに。
そうですね、そういうのも。
これの引きはどっかから飛んできそうだなと思ったんですけど、
雑すぎるので。
確かに幅はいろいろ、いろんな仕事でしてきたので、
掛け合わせてできることはありそうなと思いますね。
どうですかね、SREって100を99にしないって言うと、
AIコーディングとSRE的アプローチ
どうですか、けんさんからツッコミ食らえそうだなと思ったんですけど。
いやでも、まあそうじゃない。
そうですね。
そうじゃない。
しかも100って自分が作った100じゃないからね。
他人が作った100を99にしないような仕事だからね。
99の方が正しいですね、Shopifyだと。
そうだね、僕がツッコムなり100を90にしないじゃなくて、
100を99.99…100じゃないね、99.99…
本当どうでもいいツッコミしてるんですけど。
言いたいことは分かりますけど。
最近のお二人のAIに対するキャッチアップとかはどういう感じなんですか?
結構ガンガンAIコーディングしてるのかとか、
もう少し内部を理解するためのキャッチアップとかもされてるのかとか、
ざっくりじゃすみません。
どっちからいきます?
一応答えると一応収録はして、
この収録の前に具体的な、
2人のAIの今の現状みたいなのを、
自分たちがどう使ってるのかっていうのを収録した回はあるんですよ。
で、どこまで話そうかっけ。
じゃあ別に。
いやいや。
アサヒさんと話すことに価値があるような気がしてて。
だから言いたいんだけど。
自分から言うとザクッと言うと、
AIでめちゃめちゃコーディングというかを使ってて、
基本的にはコードを書くことはなくなってるんですよ。
社内でもAIがレビューしたりとかみたいな風になってるんだけど、
自分はAIに対しては、
そうですね、使ってるだけ、あくまで使ってるだけで、
中身の理解までみたいなのはキャッチアップできてないなっていうのがあって、
あえて切り捨てるっていうのもあるところがあるかな。
最新のAI情報もそんなに気にしてないし、
多分自分の使い方は本当にターミナルで
コロードコードと話してコーディングしていくみたいなのがメイン。
そこにループエンジニングとか正直あんまりまだキャッチアップはできてないかなっていう感じが自分の現状ですね。
県はまた違うとは思うけど。
そうですね、僕はよくも悪くもSREなのでSRE的なアプローチをしてます。
意識的にとかも自然と。
SRE的なアプローチって何かというと、
西君なら伝わると思うけど、
自分が作ってないサービスのページを受けるわけじゃないですか。
ペイメントサービス。
エンビディットSREとかとは違うかもしれないけど、
今日はチェックアウトから来ました。
今日はモバイルアプリ関連から来ました。
今日はストリーミングサービスから来ましたみたいな感じなので、
いろんなサービスを毎週毎月のように触らなきゃいけないから、
どうしても何かの技術をとことん深掘るっていうアプローチより、
目の前のシステムをメタ的にハイレベルで、
本質的を抜き出してっていうとかっこいいんだけど、
要するに分かったふりして、
骨組みだけを理解して、
ちゃんとそれを知識として使っていくっていうことが求められるので、
SREの考え方をAIのツールとかでも、
例えばチャットGPTとクローデとか、
オープンコードとかパイとかいろいろなコーディングエージェントがあるけど、
それって共通してる部分は共通解は何なんだっけねとか、
今出てきた新しい技術、
それこそPaged AttentionでもKVCacheでもいいんだけど、
その裏側の仕組み、そもそもハルシネーションって何で起こるんだっけ、
それは確率論的なところからだよねみたいな、
大まかなロジックは理解しようとしている。
けれども、じゃあ自分で書けますか、
モデルのチューニングできますか、
ハンズオンのところは、
どうしてもやりたいことはいっぱいあるけど、
ハンズオンは全てできているわけではないので、
もうハンズオンはやらない、最小限にするみたいな線引きをして、
かっこいいと本質的に、悪いと表面的に、
理解するだけにとどめようとはしている。
時間がないからね。
ありがとうございます。
参考になりました。
ノイズが大きいというか、
というところもあるというか、
全部を理解しようとしても、
無駄になることもそもそも多いですし、
だからこそやっぱり、
その骨組みを理解してみたいなところがあるんですかね。
そうだね。
僕の専門分野ではないので、
専門分野ではないという、
謙虚な姿勢でと言ったらあれだけど、
専門分野ではないという付き合い方をしますね。
だからそこを専門にしようと頑張っている浅井君には励まされます。
すごく頑張ってください。
ありがとうございます。
そのところかな、
クロージングと今後の展望
ちょっと、
そろそろ終わりの時間も近づいてしまったので、
クロージングに入っていこうと思うんですが、
浅井君に最後にリスナーの方向けてでもいいし、
もし言い足りないこととかあれば。
なんだろう。
ノート読んでくださいでもいいし。
じゃあ、そうですね。
ノート読んでください。
リンクを貼っておきます。
お願いします。
次のノートも楽しみにしております。
何かしらアウトプットがあったら、
ぜひいつものようにリスコードで教えてください。
収録楽しみにしてます。
ありがとうございます。
今日は楽しかったです。
ありがとうございました。
