【Launch HN】GPUの無駄遣いを撲滅！HPCクラスターの運用効率を劇的に改善する「Expanse」が登場

Hacker Newsの皆さん、こんにちは。Ismaeel、Eren、Yafet、そしてNikodemです。私たちは、KubernetesやSLURMで運用されるHPC/GPUクラスターの有効稼働率を最大化するツール「Expanse（https://expanse.sh/ ）」を開発しました。Expanseは、ジョブが投入される前にソースコード、実行スクリプト、ハードウェア情報を解析し、必要なリソース量を正確に予測します。また、ジョブ失敗の予兆検知や、コードレベルでのパフォーマンス最適化提案も行います。現在のデータセンターの有効利用率はわずか30〜40％程度です。多くのユーザーはジョブ失敗を恐れてリソースを過剰に確保しがちですが、これが膨大なコストと機会損失を生んでいます。私たちは、ある国立HPCクラスターで調査を行ったところ、全計算リソースの59％が無駄になっていることを突き止めました。これは月間で約850万ドル分もの損失に相当します。Expanseは、ノードごとにインストールされ、SLURMやK8sスケジューラーにフックしてリアルタイムのテレメトリ（DCGM、CUPTI、Cgroups等）を収集・学習します。これにより、クラスター環境に最適化されたモデルを構築し、精度の高いリソース推奨を提供します。主な機能は3つ：(1) ジョブ投入時のリソース予測（GPU VRAMやCPU使用率など）、(2) ライブ監視によるハードウェア負荷の可視化、(3) 失敗時の根本原因診断とコードレベルの修正アドバイスです。既存の歴史的平均値に基づく手法やLLMベースの推論よりもはるかに高い精度（LLM比較で約8倍の性能）を達成しています。汎用的なLLMでは理解できないハードウェアトポロジーや実行時の動的パターンを深く理解できるのが強みです。現在は有料パイロット版の導入企業を募集しています。100台以上のGPUを持つHPC/K8sクラスターを運用されている方、ぜひお話を聞かせてください。まずは1週間限定の環境でどれだけ無駄を回収できるか診断レポートを作成します。この分野の課題感や、私たちが間違っていると思われる点など、皆さんのフィードバックを心待ちにしています。

データセンターの実効稼働率はだいたい30%から40%程度

なぜデータセンターは、この恩恵を還元してもっと最適化されたプランを出さないのか不思議。AWSのtシリーズのEC2インスタンスみたいなやつとかね。

エージェント向けのオープンソースのトラフィックシェイパーを開発してるんだ。リクエストが殺到してパニックになるような状況なら、予測の助けになるかもしれないよ。

https://www.linkedin.com/posts/rahmi-pruitt-a1bb4a127_agentnative-aiinfrastructure-opensource-share-7467036269139824640-QQ7n/?utm_source=share&utm_medium=member_ios&rcm=ACoAAB9QwTcBgFRB8PygBKd1VzzOTi87MQz6SFM

これ面白いアイデアだね。私が所属する機関のHPCで、サブミットスクリプトやノードの稼働状況を覗き見ると、ほとんどのジョブが計算リソースを余らせてるんだよね（中にはひどく非効率なやつもたくさんある）。全sbatchスクリプトをLLMに通すっていうのは賛成かも（他人の分はね、自分の使い方は自分でチューニングしたいから :) ）。

ここでの基盤モデルもLLMなのかな？どの程度「ファインチューン」されているのか、それともクラスターの使用状況を把握するためのツールセットが与えられているだけなんだろうか？

稼働率40%という従来の大企業的な目標は、DR（災害対策）やフェイルオーバーを見越してのことだったんだよね。あるリージョンが他のリージョンの負荷を100%引き受けられるように、20%の余力を残しておくみたいな。

余剰容量の提供や販売に関する契約の粒度が気になるところ。短期契約なのかな？オーナーは（ペナルティ付きで）そのワークロードを強制終了させられるのかな？

今、パフォーマンス最適化についての本を書いてるんだ。いつか質問させてもらえたら嬉しい。興味があったらメールして（バイオに載せてるよ）。よろしく！

[フラグ済み]

これすごくいいね、間違いなく需要があるよ。

ジョブの実行中のリソース消費を追跡したりはしてる？うちには、メモリを確保はしているけど実行時間の一部しか使っていないジョブがたくさんあって、それ以外は計算リソース待ちの状態なんだ。ジョブのリソース使用プロファイルを学習して、うまく重ね合わせることができれば、リソース稼働率がもっと上がると思うんだけど。

"OS Wastage Scanner" って文法的に間違ってるよ。正しくは "waste" ね。

セキュリティの観点から言うと、これは最初から論外だな。もしMongoDBインスタンスを開放したままにしていて、収集したテレメトリを盗まれたら、リバースエンジニアリングでクラスターのワークロードを特定されかねない。そうなると、国家機密を扱うような顧客や、IP保護が厳しい顧客（金融やバイオ系など）は即座に脱落するね。

まともなエンタープライズのリスク管理チームなら、オンプレミスの基幹業務のクリティカルパスにSaaSアプリケーションを組み込むなんて絶対にNOと言うだろう。Fortune 100も諦めないといけない。

もし成功してワークロードをうまくスケジュールできたとしても、それは結局アップグレードや拡張を先送りにしているだけだよね。DellやHPEの営業担当は青ざめるだろうし、重役たちはゴルフでもしながら対策を練るだろうし、高単価な優良顧客は契約を更新しなくなるはず。

結局手元に残るのは、特定の目的のために動いている「中小規模」のクラスターだけになるんじゃないかな。それらはおそらく、手作業でチューニング可能な限られたタスクを100%の負荷で回しているような環境だろうし。

技術的にはすごく面白いと思うけど、ビジネスとしてはどうかな。早めにオープンソース化してくれることを期待してるよ。