11,750 文字
ネットワーキングの休憩をお楽しみください。必ずラマ・ショーケースをチェックしてください。
皆さん、またお会いできて嬉しいです。今日は楽しい一日だったでしょうか。たくさんのエキサイティングなことがありました。ここでサティア・ナデラと一緒にいられることを本当に感謝しています。彼は紹介の必要がありません。彼は歴史上最も偉大なテクノロジー企業の素晴らしい変革を率いた伝説的な人物です。
ありがとう、マーク。基本的に、AIやクラウドなどの重要な分野への推進を主導しています。そして、あなたは私にとって、私たちのオープンソース活動における友人であり、味方でした。この長年にわたるパートナーシップと、ラマ・エコシステムとその周辺のインフラストラクチャの構築について、あなたからいただいたアドバイスに感謝しています。
ここに来てくれてありがとう。
もちろん、マーク。喜んで。私の最も古い記憶の一つは、2008年に私がBingに携わっていた時にあなたに会ったことです。あなたから何か間違っていることについて大講義を受けましたが、それは今思えばさらに恥ずかしいことです。
そうですね、覚えています。
いつも覚えているでしょう。あなたは「ウェブには人が必要だ。人々を見る必要がある」と言いました。それは忘れられません。どこに行っても実際にプロフィールページを持つ能力について。それが私の記憶です。
それを許してくれたことに感謝します。しかし、ウェブには確かに人々が必要ですから、その点では正しかったと思います。あるいは今ではエージェントかもしれませんね。
そうですね、たぶん両方でしょう。ああ、そうですね。
ところで、あなたは何度か、AIの成長に関する現在のテクノロジーの瞬間が、クライアントサーバーへの移行やウェブの始まりなどの過去の重要な変革を思い起こさせると言っていますね。それについて興味があります。
私にとっては、クライアントが誕生しつつあった時代に育ちました。Windows 3の直後にMicrosoftに入社し、クライアントサーバーの誕生、そしてウェブ、モバイル、クラウドと見てきました。そして、これが数え方によって4番目か5番目と言えるでしょう。興味深いのは、このような移行があるたびに、スタックのすべてが再検討され、第一原理に戻って構築を始めることができるという点です。例えば、2007年頃から構築し始めたクラウドインフラの形は、あなたが構築したコアストレージシステムや、トレーニングのためのワークロードとは異なります。データ並列の同期ワークロードはHadoopなどとは全く異なるものです。このようなプラットフォームの移行ごとに、テクノロジースタックの上下すべてを再考する必要があるというのが、私たちが時折直面することだと思います。
それはあったものから成長します。ウェブはWindowsの上に生まれましたが、それを遥かに超えました。それが私の考え方です。
それは理にかなっていますね。あなたは何度も、物事がより効率的になるとその仕組みが変わり、人々はただ単にそのサービスをより多く消費するようになるという点を指摘していますね。私が興味を持っているのは、あなた方が素晴らしいエンタープライズビジネスを展開しており、私たちはそれほど可視性を持っていないので、これがすべてのAIモデルについてどのように展開されているかということです。世代から世代へと、それらは非常に効率的になり、前の世代よりもはるかに多くの知性を提供しています。そして、明らかにすべてが非常に速く起こっています。
そうですね、もし考えてみると、数年前は私たちは「ああ、ムーアの法則はどうなったのか、終わったのか、どうすればいいのか」と座り込んでいたのですが、今やムーアの法則の超ドライブ状態にいます。どのようなテクノロジープラットフォームの移行も、一つのS曲線だけでなく、複数のS曲線が組み合わさっています。チップが良くなっているという事実だけを取っても、JensenやLisaのような人々が素晴らしいイノベーションを行い、サイクルタイムが速くなっています。これがムーアの法則だとしましょう。しかし、その上に、フリート全体、システムソフトウェアの最適化、モデルアーキテクチャの最適化、推論のためのカーネル最適化、アプリサーバー、さらにはプロンプトキャッシングなど、すべてを合わせると、6ヶ月から12ヶ月ごとに10倍の改善が得られるかもしれません。能力の改善がそのようなペースで、価格もそのようなペースで下がるとき、根本的に消費は増加します。
だから私は、深いアプリケーションが構築できる段階にいることに非常に楽観的です。これらのエージェントを持つオーケストレーション層や複数のモデルを備えたもの、そのような場所にいると感じています。最初の世代のアプリケーションは、一つのモデルと非常に結合していましたが、私たちはついに、あるモデル上に構築されたアプリエージェントが別のエージェントと対話できるようなマルチモデルアプリケーションに到達しています。MCPやA2Nなどのプロトコルも役立っています。これらはすべて良いことであり、少し標準化できれば、そして能力を構築しながら柔軟性を持つアプリケーションを構築できます。これがオープンソースが果たす巨大な役割だと思います。
それは素晴らしいですね。複数のモデルを一緒に使用する方法について議論することを確認したいと思います。そこには「蒸留ファクトリー」と情報、そしてそれを取り巻くインフラストラクチャの概念があり、Microsoftが複数のモデルがある場合に提供するのに適した位置にあると考えていると思います。
それに戻りましょう。しかしその前に、Microsoftはオープンソースに関して興味深い旅をしてきましたね。これはあなたのリーダーシップの下で早い段階で行ったことの一つで、それを受け入れたことです。OpenAIとの初期のパートナーシップはありましたが、クローズドモデルと協力する一方で、Microsoftがオープンモデルもよく提供したいということも明確でした。
あなたはそれについてどう考えていますか？オープンソースエコシステムがどのように進化すると思いますか？なぜそれがあなたの顧客にとって重要なのですか？そして、構築しているすべてのインフラストラクチャについてどのように考えていますか？
興味深い質問ですね。私がMicrosoftで育った中で、形成的な仕事の一つは、NTと様々なUNIXの間の相互運用性を確保することでした。それが私に教えてくれたのは、相互運用性はまず顧客が要求するものであり、それをうまくやれば、ビジネスにとって良いということです。また、顧客がいるところで顧客のニーズに応えることになります。これがオープンに関する私の考え方を形作ってきたものです。私はクローズドソースかオープンソースかについて独断的ではありません。両方とも世界に必要なものです。実際、顧客はそれらを要求するでしょう。私たちの誰かが教条主義を持っていても、それは重要ではありません。なぜなら最終的に世界はそのように分かれるからです。それが必要になるでしょう。
例えば、SQL Serverがあり、MySQLやPostgresがあり、Linuxがあり、Windowsがあります。実際、WindowsにはLinuxがあります。私のお気に入りの一つはWindows上のWSLで、それを使うと多くの開発ツールを簡単にWindows上にデプロイできます。
全体として、これら二つのものを混合できるようなポスチャーを持つことは非常に役立つと思います。それはまた、あなたが話したこととも合致します。なぜなら、私の多くのエンタープライズ顧客は、多くの場合、彼ら自身が所有するモデル、つまり彼らのIPを蒸留できるようにしたいからです。その場所では、オープンレートのモデルはクローズドモデルと比較して大きな構造的な利点を持っています。
だから、私は世界が今、素晴らしいクローズドソースのフロンティアモデルと素晴らしいオープンソースのフロンティアモデルでより良く提供されていると感じています。そして、ハイパースケーラーとしての私たちにとって、これは素晴らしいことです。なぜなら、結局のところ、私たちの仕事はAzureに行けば素晴らしいPostgresやSQL Server、LinuxやWindows VMを手に入れられるようにサービスを提供することだからです。同様に、選択肢を利用可能にし、その周りに素晴らしいツールを持ちたいと思います。
では、基本的にAzureがオープンソースのために果たす役割や提案は何ですか？ただし、これらすべてに対して、それは排他的である必要はありません。開発者が始めるにあたって、どの分野で差別化を図り、最高になろうとしていますか？
まず第一に、AIワークロードはAIアクセラレーターとモデルだけではありません。なぜなら、実際、どんなAIワークロードの下にもストレージがあり、AIアクセラレーター以外の計算があり、ネットワークなどに大きく依存しています。これが中核のインフラストラクチャです。
だから、Azureでは、次世代のエージェントを構築したい人のために、コンピュート、ストレージ、ネットワークにAIアクセラレーターを加えた、世界クラスのインフラストラクチャサービスとして構築したいと思います。
その上に、Foundryとアプリサーバーを構築しています。例えば、私たちのプラットフォームのシフトごとに、アプリサーバーがありました。検索やメモリー、安全性、評価など、すべてのサービスをどのようにパッケージ化するか、これらはすべての開発者が試みていることなので、それらをすべてフレームワークにラップし、そのためのツールを提供することが中核だと思います。そして、もう一つは、GitHub Copilotをツールとして非常に重視していることです。素晴らしいツール、素晴らしいアプリサーバー、素晴らしいインフラストラクチャの組み合わせが、アプリケーション開発を加速するために必要だと思います。
エージェントと生産性の向上について言及されましたが、これはエコシステム全体とコミュニティにとって大きなテーマです。私が興味を持っているのは、それがMicrosoft内でどのように展開されているのか、そして開発者に見られる最も興味深い例は何かということです。
私たちにとって最も役立っていることは、ソフトウェア開発で何が起こったかを見ることです。例えば、GitHub Copilotの進化を見ると、コード補完から始まり、チャットを追加して、RedditやStack Overflowに行く必要がなく、フローの中に留まれるようにしました。それは良かった。そして、エージェントのワークフローを追加し、タスクを割り当てられるようになりました。これら三つのことを見ると、誰もがそれらを常に使っています。一つが他を代替するのではなく、今ではプロトエージェントさえもあります。文字通り、ハイレベルなプロンプトを使用したり、PRをSuiエージェントに割り当てたりできます。
そこから得られた最大の教訓は、現在のリポジトリや開発者ワークフローとすべてを統合する必要があるということです。新しいグリーンフィールドアプリを構築することと、完全なグリーンフィールドで作業することは別問題です。大規模なコードベースと一連のワークフローで作業しているので、ツールチェーンを統合する必要があります。それが工学チームが行わなければならないシステム作業です。そして、それが生産性を見るときです。
同じことが知識労働にも当てはまります。私たちの場合、知識労働のためのCopilotの展開において、例えば顧客との会議の準備をするワークフローは、1992年にMicrosoftに入社して以来変わっていません。基本的に、誰かがレポートを書き、それがメールで来るか文書で共有され、前の晩に読みます。今では、ResearcherとCopilotに行くだけで、ウェブ上やCRM内の情報をリアルタイムで組み合わせたものを得られます。しかし、それは誰かが何かを準備する必要がないという変化です。なぜなら、すべてがタップで利用可能だからです。それには作業成果物とワークフローを変える必要があり、それが多くの変化です。最初はゆっくりと変化し、その後突然変わります。PCで見たように、メールとExcelが登場する前の世界がどのように予測を行っていたかを考えると、FAXを送り回していた時代がありました。
世界ではFAXを送り回したり、オフィス内のメモを作成したりしていました。そして誰かが「メールでスプレッドシートを送りましょう」と言い、人々が数字を入力しました。それが予測の方法を変えました。それが今、私たちが始まりにいるところであり、カスタマーサービスやマーケティング資料の作成、コンテンツ作成で見られます。そこに私たちはいて、実際の進歩と生産性の向上が見られます。
コーディングの改善についてですが、Microsoftの中でどれくらいのコードがAIによって書かれていると感じていますか？エンジニアではなく。
私たちが追跡している二つのことがあります。一つは受け入れ率自体で、それは単調に増加しています。30%から40%ほどです。そして、それは言語によって異なります。長い間の大きな課題の一つは、私たちのコードの多くがまだC++であるということです。C#はかなり良いですが、C++はそれほど良くなく、Pythonは素晴らしいです。今では言語サポートが増えるにつれて、コード補完が良くなっています。エージェンティックコードがある場所では、新しいグリーンフィールドでは非常に高いですが、多くの場合、すべてがグリーンフィールドではありません。だから、この時点で、私たちのリポジトリ内のコードの20%から30%は、おそらくソフトウェアによって書かれているでしょう。
あなた方はどうですか？
実は数字を正確に覚えていないのですが、人々が言う多くの統計はまだこの種のオートコンプリートの範囲だと思います。しかし、私たちにはフィードランキング実験や広告ランキングなど、非常に限定された領域で働いているチームがあり、そこでは行われたすべての変更の履歴を研究し、変更を加えることができます。それは私たちにとって興味深い領域です。
しかし、私たちが注力しているのは、ラマ開発自体を進めるためのAIと機械学習エンジニアを構築することです。なぜなら、私たちの賭けは、来年おそらく開発の半分がAIによって行われ、人間ではないだろうということです。そしてそれからそれはそこから増えていくでしょう。あなたが何か違うものを見ているかどうか興味がありました。
私にとって、エージェントは最初の試みです。だから、私たちにとっての質問は、来年、カーネル最適化のようなことができるようになるかということです。それは可能性が高いと思いますが、おそらく新しいモデルアーキテクチャの変更を思いつくことはないでしょう。だから問題はどのタスクかということです。
最適化やセキュリティの改善など、そういった種類のものは非常に高い機会のように思えます。
私たちも異なる問題を解決しようとしています。あなた方は多くの開発者やエンジニアにサービスを提供しています。それがあなたの中核ビジネスです。一方、私たちはこれを内部開発を改善するためのもの、そしてラマモデルを改善するためのものと考えています。他の人々が使用できますが、あなたが行うような端から端までのワークフローではありません。あなたがどのように考えているかを聞くのはいつも興味深いです。
私たちにとって、もう一つのことは、Billが会社をツール会社として始めたということです。だから、今私たちが興味を持っているのは、おそらく私たちのツールやインフラストラクチャを再概念化する方法は、エージェントが使用するためのツールとインフラストラクチャとしてであるということです。なぜなら、スリーエージェントでさえ多くのツールを必要とし、それらはどのような形をしているべきか、そのインフラストラクチャやサンドボックスはどうあるべきかということだからです。私たちが行うことの多くは、基本的にGitHubリポジトリの構成がSuiエージェントにとってどのように見えるかを進化させることです。
それは非常に興味深い概念です。私は、将来的には、すべてのエンジニアが基本的に、彼らが一緒に働く小さなエンジニアリングエージェントの軍隊を持つテックリードのようになると考える傾向があります。
それを念頭に置いて、AIを使用するための個人的なワークフローがどのように変化したかについて興味があります。また、Microsoftがどのようにこれに取り組み始めたのか、そしてその遺産についても話していましたが、もし今日開発者として何かを構築し始めるとしたら、どのようなツールを使用するかについてどう考えますか？
Billが私たちに植え付けた最大の追求や疑問の一つは、彼が「ドキュメントとアプリケーションとウェブサイトの違いは何か」と話していたことです。今、Meta、ChatGPT、Copilotなどを使用すると、チャットセッションとの違いが不明確です。
文字通り、ラマ4やすべてのモデルについて調べていた時、基本的に多くのチャットセッションを行い、効果的にPagesのドキュメントに追加し、それを保持していました。そして、コード補完があるので、それをアプリにすることができます。このように、高レベルの意図から始めて、過去にアプリケーションと呼んでいたであろう生きた成果物になるという考えは、ワークフローに深い影響を与えるでしょう。私たちはその始まりにいると思います。
インフラストラクチャとツールの構築者として、そしてその使用者として、私の夢は、これらの人工的なカテゴリー境界、または主に私たちのソフトウェアの動作の制限のために作成されたカテゴリー境界を超越することです。
私たちがいつも考えていたもう一つのことは、なぜWordとExcelとPowerPointが異なるのかということです。なぜそれは一つのものではないのでしょうか？私たちは複数の試みをしてきました。しかし今、それを想像できます。Wordから始めて、Excelのようなものを視覚化し、それを提示することができ、それらはすべて一つのデータ構造として保持されるでしょう。私にとって、以前はそれほど堅牢ではなかったその可鍛性が今存在します。
長年の会話の中で印象に残っていることの一つは、テクノロジーのトレンドがどのように展開するかについて、あなたが非常に合理的な見方をしていると感じることです。AIに関するすべての誇大宣伝がありますが、あなたはそれを見通し、各ステップで非常に合理的な投資を行うことができたと感じています。
あなたが指摘した点の一つは、「すべてのこの誇大宣伝があるが、結局のところ、これが生産性の大幅な向上につながるのであれば、それはGDPの大幅な増加に反映される必要があり、これは複数年、何年もかかるだろう」ということです。
現在の見通しについて、この進歩を理解するために何を探すべきか、そして3年、5年、7年の期間でどのようになると予想しているかについて、興味があります。
これは重要な点です。世界には、多くの課題に対処できる新しい生産要素や入力が必要です。それを考える最良の方法は、「例えば、先進国が10%で成長するには何が必要か」ということです。これは産業革命中のピーク数値だったかもしれません。
そしてそれが起こるためには、医療、小売、広範な知識労働、あらゆる産業など、すべての機能で生産性の向上が必要です。そしてそれが起こるためにはAIが約束を持っていますが、今や本当に生産性の実質的な変化をもたらす必要があり、それにはソフトウェアと管理の変化が必要です。なぜなら、ある意味で人々はそれを異なる方法で使う必要があるからです。
人々は常に電気について引用します。電気は50年間存在していましたが、人々が電気を本当に異なる方法で使うために工場を変える必要があることを理解するのに50年かかりました。それが有名なフォードのケーススタディです。私にとって、私たちはその間のどこかにいます。50年かからないことを願っていますが、これを馬のない馬車と考えるだけでは、もう一方の側に到達する方法にはならないと感じています。それは単なる技術ではありません。技術は進歩しなければなりません。それを新しい作業成果物とワークフローを実際に提供するシステムに入れる必要があります。
私たちは皆、それが50年かからないと仮定して投資しています。だから50年かからないことを願っています。
さて、私たちは最初に技術的な質問を行い、その後、大きな絵に進んでいましたが、蒸留ファクトリーの話と、オープンソースのために構築されているすべての異なるAIモデルをどのように組み合わせるか、そしてそれを構築するために必要なインフラストラクチャについて掘り下げるのを忘れていました。これはあなたが話していたことであり、私はこれがオープンソースの最大の役割の一つだと思います。例えば、あなたのものや、ラマファミリー内でさえ、大きなモデルを取り、それを同じモデル形状を持つ小さなモデルに蒸留することができるということです。これは大きなユースケースだと思います。
そして、それからそのためのツールをサービスとして構築し、それへの障壁を下げる、すべての人がこれらの大きなモデルを立ち上げる必要はありませんが、それをクラウドとして行い、その周りにツールを提供し、結果が蒸留されたモデルであれば、例えばMicrosoft 365の各テナントが、エージェントまたはワークフローとして作成できる蒸留されたタスク固有のモデルを持ち、それをCopilotから呼び出すことができれば、それは私にとってブレークスルーのシナリオです。人々はすでにそれを多く行っており、私たちはそれをもっと簡単にしたいと思っています。
だから、蒸留ファクトリーと言うとき、それは一つの大きなモデルとこれらの蒸留されたモデルとの間の多対多または一対多の関係であり、それがそれからMCPサーバーなどですべてをサポートしているGitHub CopilotやCopilotのような製品内の多くの他のワークフローと構成されることになります。
私はこれに常に魅了されてきました。蒸留はオープンソースの最も強力な部分の一つだと思います。私たちはここでやっていることの観点から、私たちは初期のラマモデルをトレーニングしていますが、私たち自身は開発者のインフラストラクチャのほとんどを構築していません。あなたのような会社が、この複雑なインフラストラクチャを構築することができるということです。そして、私たちにはビヘモスのようなモデルがあり、それをどのように使用するかは、それをより合理的な形に蒸留する以外には本当に不明確です。
私たち自身がそれを使用するためにも、内部的にインフラストラクチャを構築する必要がありました。そして、推論用に実行する方法はありません。マーベリックは蒸留されています。マーベリックのパフォーマンスを現在のレベルに向上させる方法は、基本的にそれがマルチモーダルであるということです。テキストパフォーマンスでマルチモーダルをリードし、基本的に他の主要なテキストモデルと同等ですが、より小さいです。DeepSeekはそれよりも大きなモデルですが、テキストではほぼ同等で、画像やマルチモーダルでは存在し、他のものは存在しません。そのようにして得られたのは、基本的にビヘモスの事前トレーニングが完了し、現在ポストトレーニングに取り組んでいるということです。蒸留はまさに魔法のようなものです。基本的に、20倍大きなものの知能の90%か95%を、はるかに安価で効率的に使用できる形式にすることができます。
次の質問は、それをどのように、技術的に洗練されていない人々や独自のインフラストラクチャを構築することができない人々が利用できるようにするかということです。なぜなら現在、その種の蒸留を行えるか、またはその規模のモデルを操作できる研究所は、世界でも比較的少数だと思います。そしてあなたが持つこのビジョンが構築され、世界中の大部分の開発者がアクセスできるようになるまでには、単一のモデルから蒸留するだけでなく、時間の経過とともに異なるモデルからの異なる知能の側面を混合し、それらがより強い場所から取ることができるようになるでしょう。
これは、構築されると思われる最もクールなことの1つだと思います。
そうですね、それは正しいと思います。したがって、複数のモデルから蒸留していて、それから蒸留されたモデルの周りの評価があれば、それを認定できます。そこが私たちがたくさんのツール作業、インフラストラクチャ作業を行い、人々がその柔軟性を持つための障壁を減らすことができる場所だと思います。ここでの良いニュースは、すでに始まっていることです。人々はすでにこれの存在証明を持っています。問題はすべてを構築するための障壁を減らすことができるかということです。
もう一つの課題は、人々が移動できる速度です。現在までの課題の一つは、あるモデルで何かをして、それを微調整し、新しいサンプルが落ちてきたら、新しいサンプルに素早く移動する必要があることです。それが私たちが上手くなる必要があるもう一つのことです。なぜなら、世界があまりにも速く動いているので、あなたがしたことにとらわれていることはできません。
そうですね。また、開発者はさまざまな形状のものを必要としています。ラマ4の形状は、専門家あたり170億パラメータで設計されています。それは、メタで持っている原子単位がH100だからです。私たちはこれらのものをその上で非常に効率的に実行できるようにしたいのです。他の出てきたモデル、他のオープンソースモデルを見ると、それらは良い知能を持っていますが、規模の関係で推論するのにぎこちないです。そして多分彼らは異なる種類のインフラストラクチャをターゲットにしています。
私たちはこれをサーバー生産用に構築しましたが、オープンソースコミュニティの多くはさらに小さなモデルを望んでいます。最も人気のあるLlama 3モデルは8Bでした。私たちはより小さなバージョンに取り組むでしょう。先ほど話しましたが、内部では「Little Llama」と呼んでいますが、実際に何を出荷するかは見てみましょう。
しかし基本的に、より大きなモデルから持っている知能を取り、ラップトップやスマートフォン、または何でも実行したいものの形状に蒸留できるようにすることは、私にとって最も重要なことの一つだと思います。
そうですね、あなたたちもこれに取り組んでいることは明らかで、これを見るのは良いことだと思います。もしこれらのハイブリッドモデルを取得できれば、密なモデルと思考モデルが組み合わさり、望むレイテンシや考える時間を得ることができ、それが柔軟であれば、それは私たちが全員が到達したいと思うところだと思います。
良いでしょう、終わりに、すべてが起こっていることを見ると、次の期間に対して最も楽観的なことは何ですか？開発者が次の数年間で何をするかについて最も期待していることは何ですか？
そうですね、私はいつもボブ・ディランの言葉から刺激を受けています。「生まれる中にいるか、死ぬ中にいるか」というものです。生まれる中にいる方が良いです。特にこのような時代においては、あらゆる制約があっても、AIという新しい形のソフトウェアは、これらの難しい問題を解決するために使用できる最も可塑性のある資源であることが判明しています。それが私に楽観性を与えるものであり、それは部屋の人々と私たち全員にとっての行動の呼びかけだと思います。この機会を活かし、解決策を構築することができるようになることです。
企業のITバックログや実世界の未解決の問題を見るとき、両方とも何か新しいものを必要としています。それが、この技術の最大の利益だと思う場所です。それは特に開発者が恐れずにそれに取り組むことができるかどうかにかかっています。
素晴らしい。サティア、ありがとう。そしてみなさん、来てくれてありがとう。これは刺激的な一日でした。私たちが全員で構築しているものについて、とても興奮しています。
コメント