Key Takeaways

  • 欠陥のある抽象化にパッチを当てるのではなく、本物の技術的フラストレーションからアーキテクチャを生み出し、問題の根本原因を解決するべきです。上に複雑さを重ねるのではなく。
  • コンテナ分離のためのモノリシックなLinuxカーネルへの依存は、セキュリティのボトルネックとなっています。カーネルメモリが共有されているため、namespaceやcgroupの抽象化は真のマルチテナンシーには不十分な場合が多く、より優れた仮想化/分離モデルへの移行が必要です。
  • LLMを共生的に活用して迅速なプロトタイピングを行うべきですが、技術的な謙虚さを保つ必要があります。AIの出力を盲目的に信頼すると技術的負債が生じます。AIが必然的に失敗した際にデバッグできる程度には、基盤となるシステムを理解しておく必要があります。
  • レンダリング最適化されたGPUをセキュアなAIアクセラレータとして使用することは、根本的に非効率的で安全ではありません。長期的には、TPUやカスタムカーネルドライバなどの専用ハードウェアが不可欠です。
  • 規制は必要な「後押し」ですが、真のセキュリティは競争優位性であるべきです。技術者はソフトウェア主権をコンプライアンスの負担ではなく、積極的に追求する必要があります。

Transcript

Olimpiu Pop: 皆さんこんにちは、私はOlimpiu Popです。今回は、目的を持って何かを成し遂げたいと考える刺激的な若手技術者の一人をお迎えしています。EderaのCTO兼共同創業者のAlex Zenlaです。Alex、まずはあなたの目的と、Ederaが私たちをより安全にするために目指していることを少し教えていただけますか？

Alex Zenla: はい、もちろんです。お招きいただきありがとうございます。私はAlexです。これまで約12年間、ソフトウェアを開発してきました。重要な背景として、私はかなり若くから始めました。おそらく10歳頃にプログラミング関連のことに初めて触れたと思います。父は大学のIT部門で働いていて、一緒に出勤した際にコンピュータ室などで遊んでいました。それが6〜7歳の頃だったと思います。その後、徐々に興味を持つようになりました。

手に入れた中古のノートPCにUbuntuをインストールしたことが、私の型にはまらない考え方の始まりだったと思います。14歳でテックキャリアをスタートし、IoT分野で働き始めました。それだけでもう一つのポッドキャストエピソードになるかもしれませんが、ある日、インターネット上の見知らぬ人から、私が取り組んでいたオープンソースプロジェクトを気に入ったというメールが届き、それが14歳の誕生日に有給の仕事へとつながりました。

それ以来、基本的に12年間フルタイムで働いてきました。約10年間はIoT分野で働き、2023年末にIoTから退き、他のことに取り組もうと考えていました。私は常に開発ツールやソフトウェアシステム、オペレーティングシステムに情熱を持っていました。Ariadne ConillはAlpine Linuxのメンテナーの一人で、APK-toolsやAudaciousなどのソフトウェアプロジェクトを生み出しました。彼女は友人であり、私はGoogleでコンテナをネイティブに実行できるハイパーバイザーのアイデアに取り組んでいました。

Ariadneはこのアイデアに非常に興味を持ち、ChainguardでWolfiの作成者の一人として働いていました。その後、Wolfiは独立したプロジェクトとなりました。彼女も何か違うことをやりたいと思っていたので、私たちは一緒に会社を立ち上げ、それがEderaへと発展しました。私たちはコンテナやVM、システムイメージを相互に分離するEderaという技術を構築しています。「ゾーン」という概念があり、安全な仮想マシン内で分離されたワークロードを実行できます。エンタープライズのニーズとユースケースに強く焦点を当てており、パフォーマンスを重視し、速度とエンタープライズでの使いやすさに注力しています。

欠陥のある現状を受け入れない - 改善せよ！ [03:46]

Olimpiu Pop: Ariadneのことを話されましたが、QConでのプレゼンテーションでも彼女に触れられ、特に哲学的な理由からでした。これはとても重要だと思います。あなたがおっしゃったように、すべては怒りから生まれるものであり、それがspite（反発心）なのです。

Alex Zenla: はい、これは私がソフトウェア開発の基本哲学として最も信じている部分です。スライドでは特にspite-driven developmentについて触れました。Googleで働いていた頃、Ederaの技術の基盤となる問題を解決することが目標でしたが、正直に言うと、その問題がまだ解決されていないことに少し苛立ちを感じていました。

Ariadneの過去の多くも、フラストレーションやより良い方法があるはずだという思いから来ています。世界を見て「これでは満足できない、このような仕組みは少し苛立たしい」と感じるような開発です。ソフトウェアの世界では、物事を複雑にすることに慣れ親しんでいますが、物事をシンプルにするのはあまり得意ではありません。

spite-driven developmentは、世界の見方を変える私の考え方です。何かの仕組みに苛立ちを感じたとき、「not invented here」症候群を推奨しているわけではありませんが、言いたいのは、物事がうまくいっていないとわかったとき、それをそのままで済ませる必要はないということです。

トークで挙げた最大の例はオペレーティングシステムについてです。誰もがLinuxを使っています。しかし、Linuxは完璧ではなく、Linuxカーネルで開発をしたことがある人なら、誰もLinuxが完璧だとは主張しないでしょう。さまざまな問題やエッジケースがあり、優れたカーネルではありますが、その根本的な仕組みには壊れかけている部分があります。私たちはそれを根本的に受け入れ、異なる開発方法を考える必要があります。

それはすべてを捨てるということではなく、アーキテクチャを変え、スタックの異なるレイヤーに親しみ、本当に理解していない領域の問題を解決しようとすることです。私がカーネルレベルや仮想化関連の作業を始めた頃は、何もわかっていませんでした。しかし、止まらずに、壁にぶつかったら理解しようとしました。

Ederaが最初に設立された頃は、LLMは存在していましたが、まだ初期段階で、壁にぶつかったときに聞けるようなアシスタントはありませんでした。文字通り、自分でハッキングを続け、ハイパーバイザーを動作させるために力ずくで問題を解決していました。これはソフトウェア開発で過小評価されている部分だと思います。何かを理解していなくても、ただ前に進むということです。今では、AI支援のコーディングで、知らない分野にも簡単に取り組めるようになりました。

保守性など多くの疑問がありますが、最終的には、理解したことのない分野でも動作するものを作ることができます。しかし、もう一つの過小評価されている部分は、私がLLMを個人的に使う方法でもあります。ある種の仕様をClaudeに入力し、必要な情報をすべて説明してもらい、それを実際に吸収します。今日のvibe codingの問題、そしてそれがspite codingと相容れないと思う理由は、最終的に自分が何をしたかを理解する必要があるということです。それがspite-driven developmentから得られる充足感の重要な部分だと思います。

LLMで理解を加速する [08:09]

Olimpiu Pop: この部分のモットーは、おそらく「vibeするかしないか」でしょうね。...しかし、あなたの言うことは正しいと思います。私も同じ感覚を持っています。階段を上るにつれ、責任が増え、特に急速に進化している分野では、ハッキングすることが難しくなります。今、クラウドネイティブの成長を考えています。すべてがネイティブになっています。JavaScriptエコシステムについては触れませんが、目を閉じている間に4つも新しいライブラリが出てきて、すべてが「最高」だと言われています。

しかし、支援開発の利点は、vibe codingなどと呼ばずとも、あなたが言ったように、問題を修正することから始める場合、自分自身やより広いコミュニティのために、より迅速な充足感が得られるということです。ただいろいろなことをして、何が起こっているかわからなくなり、それを理解する必要があり、すべてを忘れてしまうという部分がありません。そのため、特に適切に文書化されている部分では、先に進む可能性が高くなります。

最近、複数の人と話しました。例えば、Gunnar Morlingとの会話です。彼はJavaでほぼゼロ依存のParquet用ライブラリを最初に開発しました。これは私の知る限り、LLMの助けを借りてゼロから始めた最初のオープンソースライブラリの一つです。これにより、適切な増分を迅速に行うことができ、それはParquetが非常に良く文書化されており、どこに向かうべきかを見通せるようになったからです。それぞれが設計文書から始め、そこにあるものと起こっていることをすべて理解できるようにしたので、これは非常に重要だと思います。

もう一つの懸念は、App Storeの初期のようなものです。人々はただどこかに行ってすべてをダクトテープでつなぎ合わせ、「これには穴があるけど、そこにいなければならないから気にしない」というものでした。それが私たちが注意すべきことだと思います。

しかし、全体として、これは非常に良い時期だと思います。例えば、先日、オンラインスクレイピングと通知を行うものを組み立てることができました。使ったことのないクラウドプロバイダーを使いました。すべてが短時間で起こりましたが、その後、「高レベルではほとんどのことを知っているので、詳細を説明して、挑戦して、厳しく問い詰めて、何があるかを見てほしい」と言いました。これは二重の充足感がありました。

一方では、素早く仕上げたというドーパミン効果がありましたが、概念も理解し、どのように構築するかも知っています。システム設計の面接を考えると、今では1〜2時間で物を作ることができ、それはかなり達成可能です。あなたが言ったように、問題を見て、Girl ScoutやBoy Scoutのルールを拡張し、コードをより良い場所にするのは素晴らしいことです。しかし、あなたが言ったように、必要から始まりました。QConでのプレゼンテーションでは、一部のインスピレーションやセキュリティ哲学がMinecraftから来ていることに触れました。特に、異なるポイントのレイヤリングと、それを見る方法についてです。現在、クラウドネイティブスタックはどのような状況にあるのでしょうか？

抽象化レイヤーが多すぎる [11:21]

Alex Zenla: はい、もちろんです。自己紹介で触れなかったことの一つは、Minecraftが私の子供時代の大きな部分を占め、実際のプログラミングへの興味の触媒となったということです。シェルスクリプトやシステム管理ではなく、本物のソフトウェアを構築したいと思うようになった転換点です。MinecraftがJavaで書かれ、JVMアプリケーションであることも、多くの理由でイントロスペクションや分析、修正に適しているという利点がありました。多くの興味深いことを学びました。

最大のものは、システムのレイヤーとシステムレイヤリングの考え方です。トークではあまり触れませんでしたが、Minecraftのゲームアーキテクチャにもレイヤーがあります。示したスタックのレイヤーを取り、顕微鏡を当てると、そこに何千もの他のレイヤーが見えると思いますが、どこかで分解する必要があります。

主な焦点はシステムレイヤーについてで、ハードウェアがファームウェアの上に構築され、ファームウェアがカーネル、または実際にはほとんどのシステムで何らかの仮想化スタックの上に構築されるという考え方です。そしてカーネルがあり、runc、Docker、containerdなど、実際のコンテナを実行するさまざまなレイヤーがあり、これらはカーネルと通信します。そしてKubernetesがあり、アプリケーションや他のオーケストレーションがあります。これを始めると、システムの下位レイヤーにあるものを本当に忘れてしまいます。

このポッドキャストを聞く人の大半は、私がアプリケーションまたはアプリケーションオーケストレーションレイヤーと考えるところに squarely 集中していると思います。これはクラウドネイティブが位置する場所です。クラウドネイティブのすべてはAPIです。クラウドネイティブのすべては、「あなたのHTTP APIを呼び出せるか？gRPC APIを呼び出せるか？データを通信したり、スクレイプしたり、ある場所から別の場所にデータを移動したりできるか？」ということです。そして明確に言っておきますが、このレイヤーで開発することは何も間違っていません。それはシステムの非常に重要で重要なレイヤーです。

残念ながら、私たちのシステムにはレイヤーが多すぎると私は思います。それは、クラウドネイティブ開発者がここにいて、カーネルとシステムがずっと下にあることを意味します。これは大きな問題です。なぜなら、カーネルとカーネルサブシステムを提供するシステムは、その上のすべてのレイヤーに非常に明確で重要な影響を与えるからです。Linuxカーネルがひどければ、他のすべてがひどくなります。

そしてこれは現実の問題です。トークで焦点を当てようとしたのは、このセキュリティ問題についてです。Linuxが壊れ、Linuxのセキュリティが壊れると、その上のすべてが完全に無意味になります。カーネルCVEがあれば、Kubernetesクラスターがどれだけ安全であっても関係ありません。なぜなら、カーネルはKubernetesノード全体で共有されているからです。突然、セキュリティは完全に崩壊します。

そして根本的に、私たちはこれがどれほど重要かを忘れ、抽象化レイヤーを作成することに非常に慣れ親しんでいます。しかし、本当に最善で最も安全な方法を見ると、通常はレイヤーを減らし、攻撃対象領域を減らし、それらの可能性を減らすことです。

そしてこれが、私のシステムに対する根本的な考え方です。トークでは、クラウドネイティブエンジニアがLinuxカーネルで理解していないことを回避する例をたくさん挙げました。彼らは、実際にやろうとしていることに完璧ではないかもしれない高レベルの抽象化を使います。それは、システムのそのレイヤーにいるとき、カーネルを非常に基本的なレベルで理解していないと、ソフトウェアの開発方法に本当の問題になるからです。

特に制約について話しました。追加するシステムの各レイヤーは、その上のレイヤーに制約を課します。カーネルとLinuxカーネルの仕組みは、その上のアプリケーションの動作を大きく制限します。コンテナが現在の形で動作する理由は、Linuxカーネルをコンテナのようなシステムに適したものにするために、私たちが組み合わせることができた技術だからです。しかし、異なる側面と異なる考え方を持つ異なるカーネルを完全に設計することができ、コンテナの実行方法を根本的に改善または変更することができます。それが私たちがEderaでやろうとしていることで、コンテナをネイティブに理解する仮想化システムを開発することです。「マイクロVMをただ実行する」というような無理やりな方法ではなく、コンテナとは何かを本当に根本的に掘り下げ、そのために直接技術を構築することです。

モノリシックLinuxカーネルのセキュリティリスク [17:01]

Olimpiu Pop: つまり、ある時点で批判的に見る必要があり、揺るがしい基盤の上に構築するのではなく、ステップバックすることが多くの場合に非常に有益かもしれません。たくさんありますが、現在のスタックを見た場合、システムエンジニア、アーキテクト、またはこれらのことを気にする必要がある人々が知っておくべき主な重大な問題点は何でしょうか。

Alex Zenla: 今日、Mythosのようなものでは、カーネルをこれまで以上に意識する必要があります。トークを少し変えて、戻って改善できるとしたら、少し違う点は、人々がカーネルを完全に無視していないことを認めることです。人々がカーネルとやり取りする方法は、例えばeBPFを通じてかもしれません。LinuxデスクトップやLinuxラップトップの愛好家であれば、センサーやファン制御などを管理する必要があるかもしれません。人々は私が思っていた以上にカーネルとやり取りしています。

しかし、それらの基盤を理解することは、それとやり取りすることとは全く異なることです。セキュアなシステムを構築するには、プロセスが根本的に安全ではなく、他のプロセス間で物をリークする可能性がある理由を理解する必要があります。私たちは非常に基本的なレベルで考えますが、Linuxカーネルがそれについて何もできない理由を本当に考えていません。

ネタバレになりますが、Linuxカーネルが現在の振る舞いをする主な理由は、それが完全にモノリシックなカーネルだからです。Linuxカーネルでは、カーネルレベルに到達すると、すべてが事実上1つの共有プロセスになります。多くの注意点や例外はありますが、重要なのは、ほとんどの場合、カーネルメモリが他のプロセスのメモリをリークする可能性があることは事実だということです。システムを完全に制御する能力があり、システムコールを通じた侵害は非常に深刻な問題です。なぜなら、文字通りすべてに影響を与える可能性があるからです。

そしてこれは批判的に理解する必要があることだと思います。単に「ファイルディスクリプタがリークする可能性がある」という些細なレベルではなく、私たちが持っているシステムが本当に役に立たない無数の方法を理解することです。例えば、Linux namespaceは、あるプロセスから別のプロセスへのファイルディスクリプタのリークを防ぎません。Linux cgroupsは、プロセスが使用するリソースを完全に制御しません。特定のシステムコールを行うと、カーネル内の別のタスクに異なる振る舞いをさせることができ、その結果、消費したCPUとメモリリソースが完全に考慮されない可能性があるからです。

したがって、これらをセキュリティモデルで設計されていない完全なマルチテナンシーに使用しようとすると、大量の問題に直面します。カーネルについてもっと多くの人が知る必要があると思いますし、ほとんどの場合、それよりずっと下に行く必要はないと思います。AIの議論に戻ると、カーネルを理解することはこれまで以上に簡単です。特にClaude（Codexや他のモデルもそうですが）は、Linuxカーネルのソースコード全体をモデル内に持っていると思います。カーネルコードを取得してカーネルについて質問する必要すらありません。ただ知っているのです。もちろん、ソースを確認してください。AIは間違いを犯す可能性があります。もちろん、しかし90%正しいとしても、あなたが知らなかったことを90%多く学んだことになります。そして、これらのレイヤーで作業する上で非常に重要な部分は、以前にやり取りしたことがなくても、それらを研究することを恐れないことです。

LLMと共生的に働く [21:33]

Olimpiu Pop: そうですね、私が言及したように、それは簡単な部分だと思います。5、6年前の私の調査を思い浮かべてみると、大量のタブを開き、あちこちにメモを取り、それらをまとめてノートを作ろうとしていました。今は非常に線形的になり、うさぎの穴を下るのが簡単になりました。エレベーターが上下に連れて行ってくれるので、非常に簡単に試すことができます。

しかし、2つの議論をまとめて戻ると、あなたが言ったように、概念を理解することは簡単ですが、たとえ大学レベルの知識や基本的なことだけで現在取り組んでいるとしても、把握するのが難しいです。私の観点からすると、人々が本来行くべきでない領域に進むとき、それを完全に理解せず、これらのすべての視点を見る忍耐力がなく、Redditが「コーディングの仕方がわからないけど、その金額を生み出す会社を立ち上げた」というもので溢れていて、5週間後に「助けを求めて、すべてが爆発した」というのを見るようになります。このようなことをどのように軽減するようアドバイスしますか？あなたに聞いているのは、あなたがそのレベルにいて、カーネルで遊ぶのは良くない、つまりカーネルで遊ぶとすぐに暗い場所に行ってしまうからです。

Alex Zenla: はい、自分が実際に理解していることと、理解していると思っていることを区別するには、少し謙虚さが必要です。vibe codingなどの人々の最初の本能は、「AIで何かvibe codeする」や「AIを使って金持ちになる」というものです。Redditの例のように、それが人々の使い方の多くであり、それは物事を見るには非常に悪い方法だと思います。get-rich-quickスキームをしようとしているなら、それは以前から問題であり、通常は詐欺であり、今日も同じです。

したがって、物事をして、何かを知っていると思い、それを成功させて実行することはできないことを理解する必要があります。謙虚さの部分は、自分が実際に何を知っているかを理解することです。これはClaudeやAI全般の大きな問題です。何かを知らないとき、受け取った情報が正しいかどうかを知るのは非常に難しいです。だからこそ、AIで盲目的にコードを書かないことが重要だと思います。

私は、人々がカーネルの知識がないのにAIでカーネルモジュールを構築すべきだとは提案していません。実際、one-shottingやそのような概念は非常にばかげたアイデアだと思います。なぜなら、AIはアシスタントでなければならないからです。その根本的な理由は、それと一緒に学習できる必要があるからです。

one-shottingと、何かを一度開発してその後の利益を享受するというアイデアの問題は、多くの「クールなものを作って、これだけの収益を上げていて、次の日に爆発する」という事例の原因だと思います。違いは、時間の経過とともに物事がどのように機能するかをプロンプトして理解できる必要があるということです。Claudeをアシスタントのような方法で実際に実行したことがあるなら、20%または30%の確率で間違えることに気づくでしょう。

しかし、常に興味深いと思うのは、その間違いから学べるということです。AIはあなたに嘘をつくことができますが、正しくない場合もあります。しかし、実際にエージェントで言われたことを適用して実行してみて、うまくいかない場合、それはそれが間違っていたことを証明します。

数時間前に実際に起こった非常に面白い例を挙げます。macOSで、システム全体の開く/保存ダイアログを壊してしまいました。これはmacOSのすべてのアプリケーション間で共有されるXPCサービスであることがわかりました。これはセキュリティ上の理由からです。どういうわけか、このプロセスで無限ループを引き起こしました。分析用のアプリをClaudeで構築していて、「開くダイアログが機能しないので、修正してみて」と伝えました。Claudeはこのようなことが起こる可能性をまったく考えられず、完全に暴走し、保存パネルと開く保存パネルの読み込みを別のスレッドにオフロードし、読み込みダイアログを表示するなど、本当にクレイジーなことをしていました。実際には読み込まれることはありませんでした。なぜなら、本当の問題はmacOSのサービスが壊れていたからです。

macOSがXPCサービスであることを知り、それを検査すべきだとわかっていなければ、「すべてが壊れていて、すべてが台無しだ」と座っていることになったでしょう。ClaudeはmacOSがこのような方法で壊れることを想像できませんでした。XPCサービスであることを知る程度のmacOSの知識を持っていなければ、この問題に深く入り込んで実際にシステムを検査し、デバッグすることはできません。Claudeが間違っているとき、それが何が間違っているかを伝えることができなければなりません。だからこそ、すべてを盲目的に信じることはできず、共生関係だと考えるのです。あなたが情報を与え、それがあなたに情報を与える。Claudeに何かを伝えて、それが間違っていると思うと、それがあなたに伝えます。新しいモデルではそうします。古いモデルは嘘をついていました。それが彼らの主張です。あなたがそうするなら、Claudeがあなたの仮定をチェックするように、あなたもその仮定をチェックできる必要があります。つまり、Claudeが何かを言って、それが正しくないように聞こえるなら、それを問い詰めるのです。ただ盲目的にそこに座らせる必要はありません。それが、これらを効果的に使うための最善の方法だと思います。

GPUのボトルネック: AIハードウェアとマルチテナンシーの再考 [28:08]

Olimpiu Pop: わかりました。つまり、自分のしていることに責任を持ち、チェックし、その周りにガードレールを作成するということです。しかし、AIに触れたので、2年前か3年前だったと思います。Linux Foundationの基調講演で、AIネイティブとKubernetesの間に大きな愛のサインを置きました。Kubernetesは多くのワークロードのオーケストレーションを提供することで知られているので、当然AIも恩恵を受けるでしょう。しかし、あなたがカーネルより深く行けないと言ったので、当然、ベアメタルまで行くことはでき、GPUはこれらのことを考慮して作られたことはないのは明らかです。コンピューティングのほとんどのものと同様に、何か他の目的のために作られたもので、特に大量の視覚計算などを行うために作られました。そして何人かの天才が、それが機械学習にも使えることに気づき、使い始めました。AIネイティブがクラウドネイティブを抱きしめることで、どのような問題がテーブルにもたらされるのでしょうか？

Alex Zenla: はい、これはEderaでGPUについて多くの時間を費やしている非常に興味深いことです。私がいつも話すのは、ゲームをするためにLinuxカーネルで使っている同じGPUドライバが、人々がGPUワークロードやトレーニングなどを行うためにデプロイしているものと同じだということです。これは私にとって狂っています。まず第一に、同じである必要はありません。GPUのレンダリングシステムをLLM関連のものと共有する理由はたくさんあり、GPUの複雑なアーキテクチャは、多くの点で根本的に異なります。その一つは、GPUにロードされるデータが非常に機密性が高いということです。GPUにロードされるデータの大部分は、Claudeのような独自モデルか、ユーザーデータであり、私有であるべきものです。現実的には、多くのシナリオで実際にはプライベートではありませんが、Anthropicはこの点で非常に良い仕事をしていると言えます。

そして、何年も前に私のMinecraftをレンダリングしていた同じものがこの仕事をしているというのは、私にとって非常に興味深いことです。レンダリングについて誰かと本当に興味深い議論をしました。Minecraftの背景が示すように、私の友人の多くはゲームの人々、主にゲーム開発者です。私が少し取り組んだプロジェクトの一つはSDL3で、ご存知かもしれませんが、これは本当にクールなグラフィックス関連のもので、基本的にLinuxや他のオペレーティングシステム向けのDirectXのようなものです。

根本的なことは、セキュリティはゲームではまったく懸念されないということです。より速くレンダリングされるなら、セキュリティはまったくない方がいいでしょう。高性能ゲーマーに会ったことがあるかどうかわかりませんが、彼らはゲームのセキュリティを少しも気にしません。実際、ゲームではDRMに対する大きな反発があり、正当な理由があります。また、アンチチートなども、パフォーマンスを大幅に低下させる場合があります。これがLLMの非常に複雑な計算を行うために使われているという事実は狂っています。

実際、GoogleのTPUアプローチやそのような他のシステムが長期的には勝者になると思います。なぜなら、それらはタスクのために根本的に構築されているからです。AIネイティブとKubernetesについて触れましたが、KubernetesはGPU分野で非常に多く使われており、論理的には理にかなっています。なぜなら、GPUは根本的にスケジューリングの問題であり、Kubernetesはスケジューリングを簡単にすることを意図しているからです。Kubernetesの内部を知っている人なら、少し顔をしかめるかもしれません。なぜなら、必ずしもきれいではないからです。

実際、Kubernetesには動的リソース割り当てがあり、Kubernetesがデバイスの複雑なトポロジーやGPUの複雑さを認識していなかったという事実を基本的に解決するために設計されています。クラウドネイティブは、このAIネイティブの領域にとって素晴らしいものだと思いますが、レイヤーの問題に戻ると、カーネルのレイヤーはそれに本当に適していないかもしれません。

良い例として、GPUは基本的にシングルテナンシーシステムです。すべてのメモリが共有されています。CUDAを使って複数のCUDAを同時に実行しようとしたことがあるなら、それは基本的に幻想です。プロセスや何らかの分離の概念を本当に理解していません。MIGのような技術でも、それほど多くのことはできません。したがって、KubernetesクラスターでGPUにアクセスできる1つのテナントが、GPUでフォールトを引き起こし、他の人が使用しているGPUを壊す可能性があり、実際に頻繁に起こります。したがって、ワークロードは、実際にGPUを共有できないため、非効率的に実行されることがよくあります。

その上、コンテナベースのシステムで実行する場合、EderaやKata Containersのようなもので各コンテナを分離されたセキュアゾーンに実際に分離していない場合、大きな問題は、GPUの侵害が他の顧客にも影響を与える可能性があることです。これらは、あるものを別の用途に転用し、それがあまり意味をなさない領域で起こる問題のタイプです。だからこそ、TPUのようなシステムや、完全に異なるレイヤーで動作するシステムが、この分野でより成功すると思います。なぜなら、それらはこの種のシナリオにより良く設計されているからです。私がいつも使う表現は、「GPUはレンダリングのために作られたもので、LLMのためではない」ということであり、それが真実であり、それは変わっていません。

私の希望は、「GPUがLLMにまだ使われている」ことを続けるなら、少なくともカスタムカーネルドライバ、カスタムソフトウェア、GPU自体で実行されること、GPUタスクのオーケストレーションなど、さらにはハードウェアに組み込んでマルチテナントにすることを検討する必要があるかもしれないということです。さもなければ、私たちは大きな間違いを犯していることになります。最近、AppleがGeminiの使用のためにNvidiaを採用することを検討しているという噂があり、AppleがNvidia GPUでの機密コンピューティングの使用に同意したという噂があります。Appleはプライバシーを非常に意識しており、ユーザーデータのプライバシーを非常に重視しています。彼らがプライベートクラウドを構築した方法を見ればわかります。彼らが機密コンピューティングを要求しているのは本当に興味深いことで、これは実際のニュースです。このポッドキャストが公開されるとき、それが事実だったかどうかがわかるでしょう。

技術主権と規制 [35:48]

Olimpiu Pop: つまり、TPUとGPUの例は、あなたが言ったように、現状を当然のこととせず、それを挑戦し、改善する良い例だと思います。それは良い例です。Amazonには独自のプロジェクトがあり、他の企業にもありますが、私の観点からすると、AmazonとGoogleはこの分野で最高の成果を出していると思います。ハードウェアについて議論しているので、これらのポイントを見ることができ、特にそれらの多くがAnthropicのような企業によって使用されていることを嬉しく思います。

GoogleはAnthropicと大きなパートナーシップを結んでいるので、それは実際にエコシステム全体を改善するでしょう。それは非常に幸運です。あなたのプレゼンテーションを見ていて非常に驚いたのは、例えばVictor Petersenが、欧州のルールと規制が私たちにより良いソフトウェアをもたらそうとしている方法について話していたことです。大西洋の向こう側、正確には米国の西海岸から来た誰かが、欧州で私たちが達成したことにかなり満足していることに驚きました。これは非常に重要なことです。なぜなら、今は欧州と米国の間の闘争、闘争と呼べないまでも、少しの闘争のように感じられるからです。そして、あなたのような技術者、そして他にも同じ感覚を持っている人々がいるのは素晴らしいことです。CTOとして、共同創業者として、規制と欧州の見方について、その観点からどのように見ていますか？

Alex Zenla: はい、本当に興味深いことです。私は、社会に影響を与えるものの適切な規制を信じる人であり、人々の個人の自由を認識しています。これは非常に自然な米国の言い方です。私はサイバーセキュリティの規制が非常に重要であると根本的に信じています。なぜなら、サイバーセキュリティは特に、人々にやらせる必要があるものの一つだからです。私は多くのscrappyなスタートアップで働いてきました。Ederaはこの点でトラブルメーカーになるカテゴリにはあまり当てはまりません。なぜなら、私はそれに対してより多くのコントロールを持っているからです。しかし、セキュリティをまったく気にしないスタートアップがたくさんあります。

そして、私がIoT分野で個人的に目撃したのは、多くの企業が、一部の業界ではどれだけ小さくても、非常に重要で重要なデータとシステムを制御する可能性があるということです。だからこそ、この種の規制は非常に重要だと思います。また、欧州の規制全般についてですが、微妙なバランスがあります。EUの規制で私が同意しないものもありますが、同意するものがかなり多いです。同意しないもの、例えば暗号化反対に関連するものは通過しなかったと思いますが、人々が素晴らしいとは思わないことを提案した例です。

しかし、企業にすでにすべきだったことをさせることは、人々が一歩を踏み出して行う非常に自然なことです。ソフトウェア主権全般について話すと、ユーロ圏が全体として、A. 機能し、うまく提供するスタートアップを作成し、人々のために機能するソフトウェアを提供する能力を持つことが非常に重要だと思います。それはすべての国に当てはまります。米国も同様に、人々のために機能するソフトウェアを作成する能力を持つべきだと思います。米国の税制を見れば、それが実際に起こっていないことがわかります。だからこそ、これらの種類のものが通過し、実際に社会を保護し、助けることは、政治的にも社会的にも大きな勝利だと思います。

Olimpiu Pop: わかりました。つまり、自分のしていることに責任を持ち、チェックし、その周りにガードレールを作成し、学ぶということです。しかし、AIに触れたので...大西洋を横断するこの非常に細い橋で議論を締めくくり、より多くの橋を築けることを願っています。なぜなら、私たちは結局同じ空の下に住んでいるからです。Alex、ありがとうございました。

Alex Zenla: はい、本当にありがとうございました。会話は本当に楽しかったです。

言及されたもの:

著者について

Alex Zenla

ポッドキャストの最新情報はRSSフィードで確認でき、 SoundCloud、 Apple Podcasts、 Spotify、 Overcast、 YouTubeで利用できます。 このページでは、録音されたショーノートにもアクセスできます。すべてにクリック可能なリンクがあり、オーディオの該当部分に直接移動できます。