HN公開: TCP経由の仮想GPU接続

 (thundercompute.com)
2 ポイント 投稿者 GN⁺ 2024-08-10 | 1件のコメント | WhatsAppで共有
  • GPUはCPU・ストレージ・ネットワーキング・メモリと異なり、まだ豊富な資源として仮想化されておらず、Thunder Computeはこれをシステム層で解決しようとしている
  • 供給拡大の焦点はチップをより多く作ることだけでなく、すでに配備されたGPUをよりうまく使えるようにするソフトウェア活用にもある
  • 既存の最適化が推論バッチ処理や学習ジョブのキューイングのようなワークロード層にとどまっていた一方、GPU仮想化は比較的手つかずだったシステム領域を狙っている
  • NVIDIA H100を1時間あたり**$1.38から**VS Code、CLI、ブラウザで利用でき、AWS比80%削減・契約不要・egress費用なし・拡張型ストレージを訴求している
  • 4年間ステルス状態で研究プロトタイプを作っており、自社クラウドとエンタープライズパートナーを通じてデータセンターのGPU容量改善を展開しようとしている

GPU仮想化で低い利用率を改善

  • Thunder Computeは、コンピューティングにおけるさまざまな希少資源はいずれ豊富になった一方で、GPUはまだ同じ転換を経験していないと見ている
  • GPUを豊富にする方法は、より多くのチップ生産だけでなく、すでに配備されたチップをよりうまく使うソフトウェアにもかかっている
  • 現在のGPUは十分に活用されていない場合が多く、既存の解決策は主にワークロード層に集中している
    • 推論リクエストをバッチ処理する
    • 複数のサーバーフリートで学習ジョブをキューイングする
  • CPU、ストレージ、ネットワーキング、メモリでは仮想化が一般化したが、GPUにはまだ同等水準の仮想化が定着していない
  • この空白領域をシステム層で扱うことがThunder Computeの中核的アプローチである

製品アプローチと展開計画

  • Thunder Computeは商業的な焦点を持つシステムラボであり、最新のGPU仮想化研究を本番環境に適用しようとしている
  • チームはCitadel Securities、Aquatic、AWS出身のインフラ専門家とシステム研究者で構成されていると紹介している
  • 4年間ステルスモードで研究プロトタイプを構築し、現在は自社クラウドとエンタープライズパートナーを通じて成果を展開している
  • 製品説明によれば、NVIDIA H100は1時間あたり**$1.38から**利用可能である
    • VS Code、CLI、ブラウザからアクセスできる
    • AWS比80%削減を訴求している
    • 契約不要、egress費用なし、拡張型ストレージを提供する
  • 目標はデータセンターGPU容量を段階的に改善することである

関連記事

1件のコメント

 
GN⁺ 2024-08-10
Hacker News のコメント

  • かなり興味深い。以前、動画トランスコード用途だけに GPU-over-IP が必要だったことがある。
    ホームラボのサーバーには非力な AMD GPU があったが、動画エンコードを試すたびにカーネルをクラッシュさせていて、ゲーム用 PC には NVIDIA RTX 3080 があった。そこで https://github.com/steelbrain/ffmpeg-over-ip を作り、Windows マシンでサーバーを、メディアサーバー（Plex、Emby、Jellyfin など）でクライアントを動かしたところ、完璧に動作した。

    • まだ Show HN に投稿していないなら、検討してみるといい。
      https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
      https://news.ycombinator.com/showhn.html
      https://news.ycombinator.com/item?id=22336638
    • タイトルを見て期待していたのは、だいたいこういうものだった。実際の投稿内容は便利な汎用ツールではなく 有料クラウドサービス だったので残念で、やはり本当に面白いものはコメント欄にあった。
      動画エンコード以外に GPU-over-network の使いどころがあるのかも気になる。レイテンシが増えると、機械学習やグラフィック集約型の作業は難しいのではないかと思う。
    • 興味深い。HLS のように複数のタイムスライスファイルが生成される マルチファイル変換 もサポートしているのか気になる。

  • これが CPU/GPU 境界で動くのだとしたら、VRAM に収まらないデータセットでは大きな I/O ボトルネック が発生しないのか混乱している。
    動作方式を誤解しているのかもしれないが、GPU I/O を横取りするなら、各エポックごとにデータセット全体をリモートマシンへストリーミングすることになるので、無駄に聞こえる。

    • そのシステム理解で合っている。実用的にするため、I/O コスト を減らす最適化をいくつも実装した。
      BERT 推論性能はこちらで見られる: https://youtu.be/qsOBFQZtsFM?t=69
      学習は推論よりオーバーヘッドが大きく、ネイティブ性能に近づけるための追加最適化を実装中だ。

  • 実際にどう動くのか気になる人向けに見ると、プロセスにライブラリを注入してこれらの関数[1]を フック し、サービスへ転送する構造のように見える。
    [1] https://pastebin.com/raw/kCYmXr5A

    • これらの関数がフックされていることをどうやって突き止めたのか気になる。どのシンボルが再バインドされるかを教えてくれる ld/ldd フラグがあるのだろうと推測している。
      さらに、シンボルが再バインドされるには弱いシンボルである必要があると思っていたが、NVIDIA が弱いシンボルを公開するはずはないので、結局これは実質的に LD_PRELOAD 方式ということなのかと思う。
    • PCIe デバイス全体をパススルーする魔法のような方式があることを期待していた。

  • 興味深いが、もっと関心があるのは セルフホスティング だ。すでに GPU がたくさんあり、一部は稼働中で一部は遊んでいる。
    既存の GPU を使えるようなセルフホスティングの選択肢があるのか気になる。

    • まだセルフホスティングはサポートしていないが、同じ技術はかなり合いそうだ。
      効率的なジョブスケジューリング、GPU 共有、使いやすさといった利点は、セルフホスティング環境にもそのまま適用される。今後その可能性には十分にオープンだ。
    • 自前の GPU、固定機材でもクラウドでも、その上で PyTorch に近い使用感 が欲しいなら https://github.com/run-house/runhouse を見るといい。
    • 自前の GPU やクラウドアカウントを使いつつ、良い開発体験も欲しいなら SkyPilot を見るといい。
    • Akash Network のようなサービスで自分の GPU をクラウド上で貸し出せるし、thundercompute.com で GPU を借りることもできる。ほとんどセルフホスティングのように運用する管理者向けの経路に近い。

  • よく分からない。ECS で欲しい GPU インスタンスを直接立ち上げればいいのに、なぜ ECS でインスタンスを立ち上げて、あなたたちの GPU を ECS で使う必要があるのか分からない。
    それとは別に、本物の Nitro の代わりに 中途半端な Nitro を使いたい理由も分からない。

    • いい指摘だ。利点はいくつかある。
      GPU が必要な開発を継続している場合、通常はインスタンスが起動している全時間に対して料金を払う必要がある。Thunder を使えば、実際に GPU を使っている間だけ料金を払う。CPU コードだけを実行している時は GPU 時間の料金が発生しないということだ。代替策はインスタンスを手動で起動・停止することだが、面倒な場合がある。
      また、使う GPU の種類と数を簡単に拡張できる。たとえば安価な T4 インスタンスで開発していて、8 基の A100 で本格的なディープラーニング学習ジョブを回したくなった場合、インスタンスを変更して環境を再設定する必要なく、コマンドを 1 つ実行するだけで、より強力な GPU 上ですぐに実行できる。
    • システム側から見ると、より透過的に見える。たとえばシンクライアントで GPU アクセラレーションが必要な GUI アプリケーション（Matlab、SolidWorks、Blender）を使うなら、ECS を設定しなくても可能だ。
      GPU なしで開発し、シミュレーションを回す時だけ急に GPU を付けられるし、AWS よりずっと安そうだ。本質的には Ray（https://www.ray.io/）が解く問題を、より汎用的な方法で解いているように見える。半分の GPU のような、より細かな GPU 共有 も可能になり得るので、とても期待している。

  • ここに関心が多いので、T4 インスタンス を無料で開放することにした。実際に使ってみて感想を教えてほしい。

    • A100 と H100 の価格がどうなるのか気になる。

  • すばらしい。MIG や vGPU でも動作するようにできたのか気になる。

    • MIG や vGPU ではテストしていないが、本質的には GPU を物理的にパーティショニングする方式なので動作すると思う。
      近い将来の主要目標の 1 つは GPU 共有 を可能にすることだ。ユーザーを一部のメモリに制限せず、GPU メモリ全体を使えるようにするので、MIG や vGPU より良い可能性がある。

  • 意味のあるスループットで実際に使うとどんな感じなのか気になる。ハッシュクラック にも使えるのか？
    ネットワーク越しの仮想 GPU を考えるたびにボットネットを思い浮かべる。特に https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo... の「Gosney はまず、Mosix の共同創設者である Amnon Barak 教授に、自分が『世界を巨大なボットネットに変えようとしているわけではない』と納得させなければならなかった」というくだりを思い出す。

    • 興味深い思考実験ではあるが、実際には我々のシステムでは GPU が分散しているわけではないので、ボットネットより AWS に近い。
      この技術はデータセンター内で非常に柔軟なクラスターを作る方向で面白い応用が可能で、その部分を探っている。

  • glx を開発した元の SGI エンジニアたち は、GPU 転送に X11 の仕組みを使うよう非常に慎重に設計していたので、GL ストリームをネットワークで送り、自分のグラフィックカードでレンダリングするのはかなり簡単だった。
    「廊下の先にあるスーパーコンピューターで実行し、ワークステーションでレンダリングする」という感じだった。最近のドライバー開発にはそうした配慮が見られず、通常はもう不可能だ。実際どれほど有用だったのかは分からない。たいてい良いグラフィックカードがあれば CPU も良かったからだ。それでもいじって遊ぶには楽しかったし、マシンルームで実行中のプログラムがアクセラレートされたグラフィックを得るのは妙に魅力的だった。一度、この方法で glquake を動かすことに成功した。

  • これが可能だということ自体は印象的だが、ネットワーク接続が切れたり 100% 安定していない時 に何が起きるのか気になる。
    経験上、ドライバーはローカル GPU が少しでも奇妙な動きをすると、良くない反応をする。