ニュース一覧

【記事公開】GMOインターネットの「GMO GPUクラウド」GPUクラウド国際評価レポート「ClusterMAX™2.0」で「Silver」を獲得～世界200社超を対象とする調査で、国内初の評価～

　 GMOインターネットグループの、GMOインターネット株式会社（代表取締役 社長執行役員：伊藤 正　以下、GMOインターネット）が提供する生成AI向けGPUクラウドサービス「GMO GPUクラウド」は、米国SemiAnalysis社によるGPUクラウド国際評価レポート「ClusterMAX™2.0」（URL：https://newsletter.semianalysis.com/p/clustermax-20-the-industry-standard ）において、「Silver」評価を獲得いたしました。これは、世界200社超を対象とする調査で、国内GPUクラウド事業者として初の評価獲得となります。　「ClusterMAX™2.0」 は、世界のGPUクラウドプロバイダーを、セキュリティ・信頼性・ネットワーク性能・オーケストレーション技術・運用体制など10の評価軸から総合的に評価する、独立系の国際評価レポートです。 【ClusterMAX™2.0について】 「ClusterMAX™ 2.0」は、SemiAnalysis社が開発した独立評価システムで、世界のGPUクラウドプロバイダーを、セキュリティ・信頼性・ネットワーク性能・オーケストレーション技術・運用体制など10の評価軸から総合的に評価しています。2025年11月に発表された最新版では、追跡対象となる209社のうち、84社について評価が行われています。参照：ClusterMAX™ 2.0: The Industry Standard GPU Cloud Rating System（URL：https://newsletter.semianalysis.com/p/clustermax-20-the-industry-standard） 【ClusterMAX™2.0について】 　「GMO GPUクラウド」は、SemiAnalysis社による実測テストにおいて、主要GPUクラウドプロバイダーの中でPyTorch（※1）ライブラリの起動時間が約1秒と、最速クラス（※2）のパフォーマンス結果となりました。この結果は、適切なシステム構成と最適化された開発環境を示す重要な指標となります。 実測テスト参照：ClusterMAX testing for standalone VMs and slurm clusters（URL：https://substack-post-media.s3.amazonaws.com/public/images/478e9e22-7b9d-4259-bc7c-0e50cb208fce_2678x1212.png) 記事の続きはこちら

GMO GPUクラウドを活用し、Sakana AIとGMO AI＆ロボティクス商事が大規模言語モデルの共同研究開発を開始

 AIとロボティクスの社会実装を推進するGMO AI＆ロボティクス商事株式会社（本店所在地：東京都渋谷区、代表取締役社長：内田 朋宏、以下「GMO AIR」）は、Sakana AI株式会社（本社所在地：東京都港区、CEO：David Ha、以下「Sakana AI」）と共同で、日本語向け大規模言語モデルの研究開発を2025年10月1日（水）より開始いたします。 　本研究では、日本語に最適化された大規模言語モデルを開発し、日本国内における多様なAI利活用のニーズに対応できる大規模言語モデルの創出を進めます。GMO AIRは、この研究成果を、日本における介護・福祉領域をはじめとした人とのコミュニケーションを支える分野に展開し、社会課題の解決に寄与したいと考えております。　なお、本研究において、当サービス「GMO GPUクラウド」が活用されます。 公式リリース

業界特化AIプラットフォーマー ～AI民主化への道：なぜ「協調」が成功の鍵なのか（vol.1）～

近年、私たちの社会やビジネスに急速な変革をもたらしつつあるAI（人工知能）。その恩恵を一部の専門家や巨大企業だけでなく、誰もが享受できる「AIの民主化」への期待が、日増しに高まっています。しかし、その実現には乗り越えるべき壁も存在します。本記事では、まず「AIの民主化」の本質に迫り、その進展においてなぜ「協調」が不可欠となるのかを考察します。 「AIの民主化」をめぐる光と影 「AIの民主化」とは、一体どのような状態を指すのでしょうか。その進展を後押しする力と、逆に妨げとなる要因を整理してみましょう。 この両側面を鑑みると、社会全体がAIの価値を理解し、構成員一人ひとりがAIを利活用していく理想的な未来――すなわち「AIの民主化」が真に実現するためには、『人と人、そして企業や学術機関、政府といった組織間の「協調」「協力」「柔軟な情報共有」、そして何よりも「信頼」が鍵を握るのではないか』という仮説が浮かび上がってきます。 仮説：「協調」こそがAI民主化の原動力 この「協調と信頼がAI民主化の鍵となる」という仮説について、少し掘り下げてみましょう。検証のために、生成AIにこの仮説の妥当性を尋ねてみました。 【検証したい仮説】 「分断や悪用はAIの民主化の阻害要因であり、協調や共有はAIの民主化の促進要因である。」 【生成AIによる検証結果の要約】 ①分断や悪用が「阻害要因」となる理由 技術格差の拡大（分断） 特定の組織や個人にAI技術が集中すると、知識やリソースの格差が広がり、「民主化」とは逆行する「中央集権化」を招きます。 悪用による信頼の失墜 ディープフェイクや監視技術への悪用は、AIに対する社会全体の信頼を損ない、結果としてオープンな開発や利用を妨げる規制強化やアクセス制限につながりかねません。 ②協調や共有が「促進要因」となる理由 オープンソース文化と研究成果の共有 Hugging Faceのようなプラットフォームや、主要なAI研究機関による論文・コードの積極的な公開は、知識やリソースへのアクセスを平等にし、多様なプレイヤーの参入を促します。 国際的な倫理基準の策定と連携（協調） UNESCOやOECDといった国際機関が主導するAI倫理に関する国際的な協調は、安全かつ公平なAI活用のための土壌を育み、民主化された環境の整備を後押しします。 【結論】 生成AIは、この仮説が現代のAIをめぐる状況や実際の動向と照らし合わせても整合性が高く、妥当であると結論付けました。この考え方は、今後の政策立案、教育、さらには企業戦略においても応用可能な視点と言えるでしょう。 企業成長の新たな鍵としての「協調」 「AIの民主化は、個人や企業間の協調・協力が鍵となる」という視点は、個人の活動範囲を超え、AIビジネスに携わる企業に対しても、従来の競争原理一辺倒ではない、新たな連携の可能性を示唆しています。 AIが社会の隅々まで浸透し、その恩恵を最大限に引き出すための仕組み作りは、もはや一企業が単独で担えるものではありません。自社の専門領域だけでなく、他社が持つ知見や経験、技術を積極的に取り込み、協調・連携することで、より大きな社会的価値、そしてビジネス価値を生み出すことができるのです。 このようなオープンな姿勢で企業間連携を主導できる企業こそが、AI時代の成長を牽引していくのではないでしょうか。

GMO GPUクラウドで最新推論OSS『NVIDIA Dynamo』を動かしてみた ～Dynamo が推論パフォーマンスを向上させる仕組みとは？（Vol.3)～

皆さんこんにちは:-) GMOインターネットでGPUクラウドの開発・普及活動をしている大川です。  ここまで二回にわたって NVIDIA Dynamo を GMO GPUクラウド上で動作させ、前回は Dynamo Serve の最小構成を試しました。ここまで来るとマルチノード環境を構築してみたいところですが、一旦足を止めて、Dynamo がなぜ推論性能を向上すると謳われているのか、このソフトウェアが目指すところはどこなのか、改めて振り返りたいと思います。 アテンション機構におけるトークン処理 Tramsformer モデルを採用した LLM の推論において、その処理は大まかに「Prefill」と「Decode」と呼ばれる二つのフェーズに分けることができます。 出典：Introducing NVIDIA Dynamo, A Low-Latency Distributed Inference Framework for Scaling Reasoning AI Models まず「Prefill」フェーズでは入力トークン（=プロンプト）に対して「アテンション」呼ばれる“文章中のどの部分が重要なのか”の重みづけを行います。ここでは入力トークン全体に対する Key と Value の行列計算が並列で行われ、一度計算した結果を（冗長な再計算を避けるため）KV キャッシュとして貯めていきます。これによっていわば「入力された文章の全容把握」を行うわけですが、このプロセスには大量の行列計算が伴い、GPU の演算性能に負荷がかかります。即ち「どれくらい並列で重い計算ができるか」がとても重要です。 続く「Decode」フェーズでは「Prefill」フェーズで得た KV キャッシュをもとに出力トークン（=回答）を逐次生成していきます。ここではそれまでの累積 KV キャッシュを活用してトークンの生成処理を繰り返し行うため、特性上 並列での処理が難しく、どちらかといえば高速に情報を読み出してトークンをすばやく生成できる GPU メモリ性能（帯域）が重要になります。 既存のアーキテクチャにおける課題 前述のように実は推論中の各フェーズにおいて求められる性能特性は全く異なっているため、ひとつのノード上で双方の処理を行うと、どうしてもアサインされたリソースに最適ではない部分が生じてしまいます。 例えば（GPU メモリ帯域を生かし）Decode によって出力トークンを一定間隔で生成しているところ、他方から新たなクエリを受け付けて Prefill が実行されると（一時的に演算性能が高騰するので）応じて Decode 側のトークン出力レイテンシが不安定になり、ユーザの使用感に悪影響を及ぼしてしまうケースが挙げられます。 Dynamo のアーキテクチャ こういった課題を解決するため、それぞれの処理を行う実行ノード、即ち以前の記事で言うところの「ワーカー」を役割ごとに分けることでリソースの効率をより高め、結果的にトークン出力のスループット（Token Revenueと呼ばれる）を向上させることが Dynamo の狙いです。 出典：Introducing NVIDIA Dynamo, A Low-Latency Distributed Inference Framework for Scaling Reasoning AI Models この図にある通り、Dynamo ではフロントエンドからの入力に対して、まず Prefill ワーカーが処理を行い、後続トークンの生成は Decode ワーカーが KV キャッシュを引き継いで処理します。それぞれ自身の担当する作業に集中すればよいので、リソースの割り当て最適化が狙えるというわけです。これは Disaggerecated Serving と呼ばれています。ワーカーはそれぞれ台数を設定できますので、実際に実行される推論タスクの特性に合わせて増設を行うことも「従来のアーキテクチャ」に比べて容易であると考えられます。 キャッシュの効率利用 また「KV キャッシュヒット率の向上」も Dynamo の重要なキーワードの一つです。 前回ご紹介したように Dynamo には Router コンポーネントが含まれており、ワーカーへのルーティング機能を担っています。 数多の推論クエリが飛んでくる中で類似するプロンプト、即ち「過去に似たような計算したようなトークン」はすでにその KV キャッシュを抱えているノードに処理を依頼すれば冗長さが省かれて効率が良いわけであり、Router は極力キャッシュの再利用性を高めるような挙動をします。 出典：Introducing NVIDIA Dynamo, A Low-Latency Distributed Inference Framework for Scaling Reasoning AI Models さらにワーカーの GPU メモリ上に抱えている KVキャッシュをホストのメモリやオブジェクトストレージに退避させ、のちに再利用できる仕組みを有していることも示唆されています。 まとめ 以上のように Dynamo が目指す「Token Revenue最大化」を実現するための機構として、大きなところは以下二つです： ・Prefill/Decode という二つの処理を異なるワーカーに分けて分担させることでリソース利用の効率を高める ・KV キャッシュを効率的に利用することで演算量を削減し、リソース利用の効率を高める 如何でしょうか？これらの内容を踏まえ、次回以降は Dynamo マルチノード環境の構築、そして既存の LLM Serving との性能比較も行ってみたいと思います。乞うご期待ください。

クラウドセキュリティ ゼロトラストセキュリティ基本対策（Vol.2）

前回は、クラウド環境において境界防御型のセキュリティではサイバー攻撃の種類(脅威)に対抗できないため、必要になってきているゼロトラストセキュリティの概念についてお話しました。 今回は対象のシステムがサイバー攻撃の脅威にさらされているゼロトラスト環境において、セキュリティ保全を考えて対象システムを防御するために必要な3つの基本的考え方について、本ページで概要をご紹介します。 （詳細の仕組みに興味を持った方は、様々なセキュリティ製品での実装形態に照らし合わせて、さらに知識を拡げてみてください。） サイバー・ハイジーン サイバーセキュリティの脅威の多くは、システムの入り口（エンドポイント）から侵入したウィルスといわれるソフトウェアが引き起こします。そのためこのような脅威への対策として、エンドポイントで稼働しているOS/ミドルウェアなどのソフトウェアに脆弱性がないよう、事前のパッチ適用やバージョンアップを迅速で継続的に実施することで最新の状態を維持し、既知の攻撃に対する脆弱性をなくすことが重要です。 これはあたかも流行する病気のウィルスに感染しないように手洗いやマスク着用をすることに例えられるため、サイバー・ハイジーン（衛生状態を保つ）という用語で説明されています。ITシステムの各構成要素において、パッチ適用やSWのバージョンアップをタイムリーに行い、”衛生状態を保つ”ような運用保守を実施することが重要です。 広く解釈すると感染の入り口になるエンドポイントには、システムのユーザー（人間）自身が含まれると考えることができます。システムユーザーが騙されて新たな脅威を引き起こさないためにもユーザーへのセキュリティ教育の徹底（セキュリティリテラシー教育）することも、サイバー・ハイジ―ンの一環と考えることができます。 動的ポリシー ゼロトラスト環境におけるセキュリティを考える際に従来と異なるのは、一度安全な環境を構築しそれを守るという考え方ではなく、常に信頼できる状態を維持するためにシステムを左図のようなモデルとして捉えた上で、下記の3つを仕組みが回るように環境を整備する必要があります。 活動主体（サブジェクト）の信頼を毎回検証し、状態を確認 通信（トランザクション）を行うごとにポリシーに基づき、信用度レベルを評価 アクセス対象（オブジェクト）の信頼性を確認し、アクセス毎にポリシーに基づきアクセスの正当性を検証 例えば、ID・パスワードが合致して正当な活動主体（サブジェクト）であったとしてもそのユーザーがなりすましされている可能性があります。「いつもと異なるデバイスからアクセスしている」「様々な異なる地域からアクセスしている」このような検証結果により不審なことが起こっている場合には、信用度レベルを下げてさらなる検証を行うといったポリシーに基づく防衛ができるようになります。 パスワードレス ゼロトラスト環境での“認証基盤”についての要件を整理しましょう。 活動主体（サブジェクト）が誰かを確認 識別：Identification そのサブジェクトが本人であることを、何らかの方式で検証 認証：Authentication そのサブジェクトの属性によって、アクセスできるデータ（オブジェクト）の範囲を権限管理 認可：Authorization 　これらを正確にかつユーザーの負担を軽減して行うために様々な安全な認証方法が考えられ、組み合わされて活用(多要素認証）されるようになっています。(下図参照） 一方で、認証の安全性確保が複雑化し、正規のユーザーにとってセキュリティ機能が”厄介なもの”になっているという側面もあり、安全性の確保とユーザー利便性の両立を確保することが重要になっています。IDやパスワード（認証資格情報：クレデンシャル）をネットワーク通して送ると盗聴されるリスクがあることから、FEDO2が考案されています。これは機器の登録情報を保持し、ユーザーからシステムへの認証要求を受け一時的なキーを振りだす方式であり、クレデンシャルの送付を避けることとユーザーが複雑なパスワードを管理する負荷の軽減を両立させる手段として考案され、広がってきています。 このようなセキュリティの安全性と利便性の両立を享受するプロセスを、Security Orhestration(複数ツールの連携統合）、Automaton（インシデント対応や脅威分析の自動化)、Response(自動対応・自動応答）の頭文字を取って、SOAR技術として、ITセキュリティ業界のトレンドになっています。 2回にわたって、クラウドにおけるセキュリティ技術の概要を解説してきました。各企業が現在保持するITインフラは過去から積み上げてきた技術実装の集積であり、すべてをいきなり新しい技術でリプレースするというのは困難を伴いますが、今回説明してきたような概念を意識して新しい技術を積み上げていくことで、新しいセキュリティ体系にスムーズに移行していくことが可能になります。 セキュリティコラム第１弾

クラウドセキュリティ ～クラウド時代のセキュリティ変遷（Vol.1）～

昨今クラウドコンピューティングが広がり計算機リソースの利用においても、電気やガスのように従量制でいつでも使える時代になってきました。その結果、従来個社で所有していたIT資源と混在し、システム構成が複雑化しています。また、AI技術によるビッグデータ活用においてITで扱われるデータの信頼性も考慮すべき時代になりました。 従来のセキュリティは、ファイヤーウォールを用いて内側と外側に分け、内側の安全性を確保するための境界防衛型セキュリティ技術が、体系化され、使われてきました。 しかし、クラウドサービスの拡大により守るべき対象が内側にも外側にもあること（ネットワークがゼロトラスト）、さらに、悪意ある攻撃やなりすましなどによる情報漏洩などが拡大しており、ネットワークへの入り口や境目が脅威にさらされ（エンドポイントがゼロトラスト）、単純な境界防御方式では安全が確保できない状況が当たり前になっています。 このように、ネットワークもエンドポイントも信用しづらい状況下で通用するセキュリティを考えていく必要があり、クラウド活用時代において早期のゼロトラスト・セキュリティ確立が急がれています。 セキュリティの区分と脅威 システムのセキュリティを考えるとき、以下の3つの区分で考えていくことで、網羅的にセキュリティ脅威への対策を整理することができます。 物理セキュリティ施設や設備の保護を目的とし、人の不正侵入や盗難、災害から守るための物理的な対策を講じること例：監視カメラ、施錠など物理アクセス制御など 情報セキュリティ情報、データの機密性、完全性、可用性を保護するための対策を講じること例：暗号化、VPN,バックアップ、情報アクセス権管理。 サイバー・セキュリティ(NW＆ｴﾝﾄﾞﾎﾟｲﾝﾄ・セキュリティ)ネットワークやシステムをサイバー攻撃から守るための対策を講じること例：ファイアウォール、侵入検知システム、ウイルス対策 上記3つの基本切り口に加えて、以下の視点でのセキュリティ保全環境を強化することで、適用業務や人間系も含んだ全体システム系としてのセキュリティ施策を考慮し、より安全性の高いIT環境設計ができます。　　　 アプリケーション・セキュリティ 認証と権限管理（誰が利用可能かをチェック） コンプライアンス 事故対応 セキュリティリテラシー教育 本稿では、これらの中で、クラウド環境と最も密に関係するサイバー・セキュリティ(NW＆ｴﾝﾄﾞﾎﾟｲﾝﾄ・セキュリティ)について、掘り下げていきます。 出典：「ITビジネス・プレゼンテーションライブラリー/LiBRA」by　ネットコマース株式会社サービス斎藤昌義 サイバー攻撃の種類 サイバーセキュリティを考えるにあたり、最近では安全な範囲を定義してその範囲内を守るという境界防御の概念が破綻しており、広く第三者による悪意ある攻撃が起こる可能性があることを前提に考える必要があります。一般的なサイバー攻撃の種類（脅威）を確認していきましょう。 マルウェア悪意のあるソフトウェアで、意図せずシステムに侵入して、システム破壊や情報盗難をおこないます ランサムウェアデータを暗号化し、解除のための身代金要求を行う」攻撃 フィッシング詐欺偽装メールやSMSでユーザーに個人情報や認証情報を入力させて盗む 標的攻撃特定組織や個人を標的として狙うカストマイズされた攻撃 DoS/DDoS攻撃サーバーに大量のリクエストお送り、そのサーバーをパンクさせてサービス停止をさせる攻撃 ゼロデイ攻撃ソフトウェアの未知の脆弱性を狙って仕掛ける攻撃で、防御がで きていないため被害が大きい SQLインジェクションデータベースに不正な検索要求を送り、データを盗み取る 最近のAIシステムへの攻撃としては上記に加え、学習データに不正なものを送り込んで誤動作を誘発させる“ポイズニング攻撃”、AIに不正指示をして意図しない動作を引き起こす“プロンプト・インジェクション”など新種の攻撃が増え続けています。そのため未知の攻撃にも耐性のある防御の仕組みづくりがゼロトラスト環境には求められます。 ゼロトラストセキュリティ 昨今、複雑化したシステム構成においてセキュリティ系全体の保全を考えるにあたり、サイバー・セキュリティの比重が増してきており、様々な悪意のある攻撃に対する対応策として、ゼロトラストセキュリティの考え方が企業における脅威に向き合う基本姿勢になってきました。　経営者も、セキュリティ担当技術者に任せきりにするのではなく、その新しい概念を網羅的に把握し、リーダーシップを発揮してサイバー・セキュリティ強化へ舵を切る必要があります。 次回は、ゼロトラストセキュリティ基本対策について詳しく見ていこうと思います。

GMO GPUクラウドで最新推論OSS『NVIDIA Dynamo』を動かしてみた ～Dynamo Serve による Inference Grapsh のデプロイを試す（Vol.2)～

皆さんこんにちは:-) GMOインターネットでGPUクラウドの開発・普及活動をしている大川です。  前回、NVIDIA GTC2025 の参加レポートとともに「NVIDIA Dynamo」を GMO GPUクラウド上で動かしてみるという記事をお届けし、Dynamo の最も基本的な機能である「Dynamo Run」によるローカル推論を試しました。  しかしながら、Dynamo の目指すところはオーケストレーション含む推論プラットフォームを構築することにありますので、今回はもう少し踏み込んだ機能、具体的には Inferenece Graph のデプロイを試してみたいと思います。  Inference Graph とは？  Inference Graph とは、LLM 推論を処理する複数コンポーネントサービスの総称です。具体的には、以前も触れたとおり「フロントエンド」「プロセッサ」「ルーター」「ワーカー」といったサービスから構成され、Dynamo SDK に則って各サービスを実装・カスタムすることもできます。  また、Inference Graph の展開には nats/etcd/grafana/prometheus といった関連サービスのデプロイが前提となっており、メトリックなどを参照できるように設計されています。  Inferenece Graph を定義したら、Dynamo Serve(dynamo serve コマンド)を使用してそれらをローカル環境にデプロイします。 これにより、前述のコンポーネントがローカル環境に展開されますので、フロントエンドを経由したローカル推論が実行できるようになります。  $ dynamo serve <Graph Definition>:Frontend -f /path/to/<config>.yaml github には Dynamo Serve を用いた Inferenece Graph の Example が公開されていますので、GMO GPUクラウド（以下、GPUクラウド）上で試してみたいと思います。 ※注意※ なお、GPUクラウドではコンテナ実行環境としてSingularityを採用しているため、DockerやHelmをそのまま利用することができません。後続の手順では各プログラム類をGPUクラウド向けに変換して動作させていますので予めご了承ください。 関連コンポーネントのデプロイ  まずは Inference Graph の前提となる etcd などのコンポーネントをデプロイしていきます。   github には展開用の Composeファイル が提供されていますが、前述の通り GPUクラウドでは Docker がそのまま動作しませんので、工夫が必要です。 まずはそれぞれの Docker コンテナを Singularity コンテナ（.sif ファイル）へ変換します  $ mkdir $HOME/dynamo-test && cd $HOME/dynamo-test $ srun -p part-cpu singularity pull docker://nats $ srun -p part-cpu singularity pull docker://bitnami/etcd $ srun -p part-cpu singularity pull docker://prom/prometheus:latest $ srun -p part-cpu singularity pull docker://grafana/grafana-enterprise:latest その後、Docker Compose の Composeファイル に従ってそれぞれのコンテナを Singularity 向けに書き換えます。  ・run_nats.sh  #!/bin/bash #SBATCH -p part-group_xxxxxx #SBATCH -w aic-gh2x-xxxxxx #SBATCH --job-name nats-server #SBATCH --output logs/nats/%x-%j.log #SBATCH --error logs/nats/%x-%j.err module load singularitypro singularity exec images/nats_latest.sif nats-server -js --trace ・run_etcd.sh  #!/bin/bash #SBATCH -p part-group_xxxxxx #SBATCH -w aic-gh2x-xxxxxx #SBATCH --job-name etcd-server #SBATCH --output logs/etcd/%x-%j.log #SBATCH --error logs/etcd/%x-%j.err module load singularitypro singularity exec \ --env ALLOW_NONE_AUTHENTICATION=yes \ images/etcd_latest.sif \ etcd ・run_prometheus.sh  #!/bin/bash #SBATCH -p part-group_xxxxxx #SBATCH -w aic-gh2x-xxxxxx #SBATCH --job-name prometheus #SBATCH --output logs/prometheus/%x-%j.log #SBATCH --error logs/prometheus/%x-%j.err # Ref: https://github.com/ai-dynamo/dynamo/blob/main/deploy/metrics export PROMETHEUS_CONFIG=$HOME/dynamo-test/config/prometheus.yml export PROMETHEUS_DIR=$HOME/dynamo-test/mount/prometheus module load singularitypro singularity exec --bind $PROMETHEUS_DIR:/prometheus \ images/prometheus_latest.sif \ prometheus \ --config.file=$PROMETHEUS_CONFIG \ --storage.tsdb.path=/prometheus \ --web.console.libraries=/etc/prometheus/console_libraries \ --web.console.templates=/etc/prometheus/consoles \ --web.enable-lifecycle ・run_grafana.sh  #!/bin/bash #SBATCH -p part-group_xxxxxx #SBATCH -w aic-gh2x-xxxxxx #SBATCH --job-name grafana #SBATCH --output logs/grafana/%x-%j.log #SBATCH --error logs/grafana/%x-%j.err # Ref: https://github.com/ai-dynamo/dynamo/blob/main/deploy/metrics export GRAFANA_DASHBOARDS_CONFIG=$HOME/dynamo-test/metrics/dashboards export GRAFANA_DATASOURCE_CONFIG=$HOME/dynamo-test/metrics/datasources export GRAFANA_DIR=$HOME/dynamo-test/mount/grafana module load singularitypro singularity exec \ --bind $GRAFANA_DASHBOARDS_CONFIG:/etc/grafana/provisioning/dashboards \ --bind $GRAFANA_DATASOURCE_CONFIG:/etc/grafana/provisioning/datasources \ --bind $GRAFANA_DIR:/var/lib/grafana \ --env GF_SERVER_HTTP_PORT=3001 \ --env GF_SECURITY_ADMIN_USER=admin \ --env GF_SECURITY_ADMIN_PASSWORD=admin \ --env GF_USERS_ALLOW_SIGN_UP=false \ --env GF_INSTALL_PLUGINS=grafana-piechart-panel \ --env GF_DASHBOARDS_MIN_REFRESH_INTERVAL=2s \ images/grafana-enterprise_latest.sif \ grafana server \ --homepath /usr/share/grafana これらのコンテナをそれぞれ Slurm のジョブとして起動します。 $ sbatch run_etcd.sh $ sbatch run_nats.sh $ sbatch run_prometheus.sh $ sbatch run_grafana.sh これにより、当該ノード上で必要なコンポーネントを動作させることができました。   Dynamo Serve による Inferenece Graph のデプロイ  それでは Dynamo Serve を使用して Example の Inferenece Graph をデプロイしてみます。 まずは Example のプログラム類を任意のディレクトリへコピーし、前回の記事で作成した Dynamo 用コンテナ（dynamo.sif）も配置します。  $ git clone https://github.com/ai-dynamo/dynamo.git ... $ mkdir $HOME/llm && cd $HOME/llm $ cp –R $HOME/dynamo/examples/llm . $ cp /path/to/dynamo.sif . 続けて、Slurm ジョブ起動用のシェルスクリプトを書きます。  デプロイに必要な configs/agg.yaml は上記 github で提供されているもので、「フロントエンド」「プロセッサ」「ワーカー」のデプロイが含まれています。 ・run_dynamo.sh  #!/bin/bash #SBATCH -p part-group_xxxxxx #SBATCH -w aic-gh2x-xxxxxx #SBATCH --job-name dynamo #SBATCH --output logs/dynamo/%x-%j.log #SBATCH --error logs/dynamo/%x-%j.err module load singularitypro singularity exec --nv dynamo.sif \ dynamo serve graphs.agg:Frontend -f configs/agg.yaml ※デフォルトで指定されているモデルは Hugging Face の deepseek-ai/DeepSeek-R1-Distill-Llama-8B です。  なお、過去の推論リクエストの処理をメモリに保持する KV キャッシュ機能を有効にする場合は「ルーター」が必要で、その場合は configs/agg_router.yaml を指定し、グラフ定義もそれに準じたものに変更します。今回は最小構成なので、こちらは使用していません。   最後に作成したシェルスクリプトを Slurm ジョブとして起動し、Dynamo Serve によるデプロイを開始します。GPU 枚数に制限はかけていないので 1 ノード分の GPU（H200x8）が利用可能です。 $ sbatch run_dynamo.sh $ tail –f logs/dynamo/dynamo-xxxxxx.log ... INFO 04-07 16:43:26 cuda.py:230] Using Flash Attention backend. INFO 04-07 16:43:27 model_runner.py:1110] Starting to load model deepseek-ai/DeepSeek-R1-Distill-Llama-8B... INFO 04-07 16:43:29 weight_utils.py:252] Using model weights format ['*.safetensors'] INFO 04-07 16:43:41 model_runner.py:1115] Loading model weights took 14.9888 GB INFO 04-07 16:43:43 worker.py:269] Memory profiling takes 1.66 seconds INFO 04-07 16:43:43 worker.py:269] the current vLLM instance can use total_gpu_memory (139.72GiB) x gpu_memory_utilization (0.90) = 125.75GiB INFO 04-07 16:43:43 worker.py:269] model weights take 14.99GiB; non_torch_memory takes 0.15GiB; PyTorch activation peak memory takes 1.72GiB; the rest of the memory reserved for KV Cache is 108.89GiB. INFO 04-07 16:43:43 executor_base.py:110] # CUDA blocks: 13937, # CPU blocks: 512 INFO 04-07 16:43:43 executor_base.py:115] Maximum concurrency for 16384 tokens per request: 54.44x INFO 04-07 16:43:44 llm_engine.py:477] init engine (profile, create kv cache, warmup model) took 3.33 seconds Inferenece Graph の展開が完了したら、フロントエンドにサンプルのリクエストを投げてみます。 $ vim data.json { "model": "deepseek-ai/DeepSeek-R1-Distill-Llama-8B", "messages": [ { "role": "user", "content": "GMOインターネットについて日本語で教えてください。" } ], "stream":false, "max_tokens": 300 } $ curl -s -H "Content-Type: application/json" \ > -d @./data.json \ > aic-gh2x-xxxxxx:pppp/v1/chat/completions | \ > jq .choices[].message.content "まず、GMOインターネットの概要を説明します。GMOインターネットは、国内外の通信回線を活用して、高品質なネットサービスの提供を謟じている企業です。繰り返し盆地 Engineer を経て ... snip きちんと応答が得られました！ ＃日本語での追加学習を行ったモデルではないと思うので、日本語の精度は微妙ですね :-(   今回は少し工夫を凝らしたものの、GPUクラウド上で Inference Graph を展開しましたが、いかがでしたでしょうか。  ここまで試してみると、やはりオーケストレーション（= マルチノード）や性能という面での動作が気になるところです。今後より詳しい機能について深堀していきますので乞うご期待ください！  ■ GMO GPUクラウドについて  GMO GPUクラウド（https://gpucloud.gmo/）は、NVIDIA H200 GPU や NVIDIA Spectrum-X を搭載した、国内最速クラスの高性能GPUクラウドサービスです。生成AIや機械学習、HPC向けに最適化された構成となっており、研究・開発の効率化とコスト最適化を実現します。 また、SlurmやSingularityなど、業界標準のツールにも対応しており、先進的なAIワークロードをシームレスに実行できる環境を提供します。  【6月30日まで！】無料トライアルキャンペーン実施中！！ 詳細はこちら 本記事の内容は、NVIDIA GTC 2025で発表された「Dynamo」をGMO GPUクラウド上で実行した結果を基に記載しております。動作環境や設定によって結果が異なる可能性があり、すべての環境での動作を保証するものではありません。正式な仕様やサポートについては、各ソフトウェア・サービスの公式情報をご確認ください。

GTC2025で発表されたNVIDIA Dynamoとは？ -GMO GPUクラウド上で動かしてみた-

皆さんこんにちは！GMOインターネットでGPUクラウドの開発・普及活動をしている大川です。 ここ最近で AI に関するホットな話題と言えば、03/17 より米国カリフォルニア州・サンノゼで開催された 「NVIDIA GTC 2025」 です。GMOインターネットからも私を含めた数名で現地参加し、世界的な熱狂を感じてきました。詳細はまた別途記事でお知らせしますのでご期待ください！ 目玉となる Keynote（基調講演）では NVIDIA CEO のジェンスン・ファン氏から今後の NVIDIA プラットフォームのロードマップについて発表がありました。その中で LLM の推論を最適化する OSS（オープンソースソフトウェア）として「NVIDIA Dynamo」が公開され、より推論へ注力していく同社の方向性が示されました。 ジェンスン・ファン氏から直々に Dynamo が紹介された この「NVIDIA Dynamo」は、OSS ということもあって既に githubで公開されており、その目玉は推論の実行環境を展開し、推論処理の分散やKVキャッシュといった技術を用いることで処理を高速化できると謳っているところにあります。 公開されている guide によると、Dynamo の主な機能は以下の通りです。 Dynamo Run　　➤指定したLLMモデルをサーバとして起動できるコマンド。 Dynamo Serve　　➤inference graph と呼ばれる推論のためのコンポーネント（フロントエンド/プロセッサ/ルータ/ワーカ）を　　　構成するコマンド。推論における処理を階層化し、リクエストのルーティングなども担う。 Dynamo Build（ Experiemental）　　➤上述の inference graph をコンテナ化する。 Dynamo Deploy （ Experiemental）　　➤inference graph を helm や Operator を用いて kubernetes にデプロイする。 これらを見てもわかるように、Dynamo は推論における GPU 利用をオーケストレーションし、トークン収益性を高めることを狙った「ある種のAIプラットフォーム」である、と読み取れます。 最終的には Dynamo Deploy まで試してみたいところですが、いきなりフル活用するのは難しいため、まずは GMO GPUクラウドで Dynamo Run を使用したローカル推論を試してみることにしました。 サポートマトリクスによると、現時点（2025/03/26）では以下の環境をサポートしているようです。 x86_64 アーキテクチャの CPU NVIDIA Ampere/Ada Lovelace/Hopper/Blackwell アーキテクチャの GPU Ubuntu 24.04 ※記載はないが Python 3.12 系で動作する模様です HW 的な互換性はGMO GPUクラウドでは問題ありません。OS バージョンや Python 周りの互換を持たせるため、今回はコンテナベースで実行することにします。GMO GPUクラウドでは Singularity コンテナを採用していますので、まずはコンテナをビルドするための .def ファイル（Dockerfile と同義）を作成します。 Bootstrap: docker From: ubuntu:24.04 %post # 関連パッケージのインストール apt-get update && apt-get install -y \ software-properties-common \ wget \ && rm -rf /var/lib/apt/lists/* # Python のインストール add-apt-repository ppa:deadsnakes/ppa -y apt-get update apt-get install -y --no-install-recommends \ python3.12 \ python3.12-dev \ python3.12-venv \ python3-pip \ libucx0 # Python 仮想環境の作成 python3.12 -m venv /opt/venv . /opt/venv/bin/activate # NVIDIA Dynamo インストール pip install --upgrade pip pip install ai-dynamo[all] %environment source /opt/venv/bin/activate export PATH=/usr/bin/python3.12:$PATH 続けて、この .def ファイルをビルドしてコンテナイメージを作成します。 GMO GPUクラウドではジョブスケジューラとして Slurm を採用しているため、インタラクティブジョブである srun コマンドでビルドを実行します。  $ srun --partition part-cpu singularity build --fakeroot dynamo.sif dynamo.def これで Dynamo が動作するコンテナが完成しました。 Dynamo は Hugging Face からのモデルダウンロードに対応しているため、モデル名を指定するだけで簡単に起動することが可能です。  $ dynamo run in=<interface> out=<engine> --http-port=<port> <HUGGING_FACE_ORGANIZATION/MODEL_NAME> Slurm でバッチジョブとして dynamo run を実行するためのシェルスクリプトを作成します。フロントはhttp、バックエンドのライブラリはvllm、モデルは Llama3.1-8B Instruct モデルを使用しました。  #!/bin/bash MODEL_NAME="meta-llama/Llama-3.1-8B-Instruct" HF_TOKEN="hf_xxxxxxxxxxxxxxxxxxxxxxx" HTTP_PORT=11434 module load singularitypro cd $HOME/dynamo singularity exec --nv -B $HOME/dynamo:/workspace dynamo.sif bash -c "huggingface-cli login --token '$HF_TOKEN' && dynamo run in=http out=vllm --http-port=$HTTP_PORT $MODEL_NAME" ※ meta-llamaについては事前にHugging Faceで利用申請を行った後、トークンの払い出しが必要です。  上記シェルスクリプト（run.sh）を Slurm のバッチジョブ（sbatch）として実行し、計算ノード上に dynamo インスタンスを起動します。  今回はモデルサイズ的にも 1 ノード（H200 x1）を指定しています。  $ sbatch --partition part-group_xxxxxx --nodes 1 --gpus 1 run.sh curl コマンドでクエリを投げ、モデルが起動していることを確認します。  $ curl -s aic-gh2x-xxxxx:11434/v1/models | jq . { "object": "list", "data": [ { "id": "Llama-3.1-8B-Instruct", "object": "object", "created": 1742973712, "owned_by": "nvidia" } ] } Llama モデルが起動していることを確認できましたので、さっそくリクエストを投げてみましょう。クエリ用の json ファイルを作成します。  { "model": "Llama-3.1-8B-Instruct", "max_completion_tokens": 2049, "messages": [ { "role": "user", "content": "GMOインターネットグループについて簡潔に教えてください。" } ] } 先ほどのDynamoインスタンス宛てにHTTPリクエストを投げます。 $ curl -s -d @req.json -H 'Content-Type: application/json' http://aic-gh2x-xxxxx:11434/v1/chat/completions ... GMOインターネットグループは、日本のIT企業グループです。グループの中心となる会社はGMOインターネット株式会社で、199 1年に設立されました。主にインターネット関連のサービスやソフトウェアの開発、販売を行っています。\n\nグループの主な事業は次のとおりです。\n\n1. インターネットサービスプロバイダ（ISP）\n2. ホスティングサービス\n3. ドメイン名の販売\n4. ソフトウェアの開発と販売\n5. IT関連のコンサルティングサービス\n\nGMOインターネットグループは、世界的に活躍するIT企業の一つとして知られており、多くの国で事業を展開しています。... きちんと応答が得られました！  使い勝手は ollama に似てシンプルであり、ローカル環境での推論を手軽に実行できるツールだと思います。  以上、Dynamo Run を試しましたが、前述の通り Dynamo が目指すところは推論のオーケストレーションや性能の向上になります。今後 Dynamo による推論環境のビルドにもトライしていきたいと思います。GMO GPUクラウドにもぜひご注目ください！  GMO GPUクラウドで最新推論OSS『NVIDIA Dynamo』を動かしてみた～Dynamo Serve による Inference Grapsh のデプロイを試す（Vol.2)～ 第2弾記事はこちら ■ GMO GPUクラウドについて  GMO GPUクラウド（https://gpucloud.gmo/）は、NVIDIA H200 GPU や NVIDIA Spectrum-X を搭載した、国内最速クラスの高性能GPUクラウドサービスです。生成AIや機械学習、HPC向けに最適化された構成となっており、研究・開発の効率化とコスト最適化を実現します。 また、SlurmやSingularityなど、業界標準のツールにも対応しており、先進的なAIワークロードをシームレスに実行できる環境を提供します。  【6月30日まで！】無料トライアルキャンペーン実施中！！ 詳細はこちら 本記事の内容は、NVIDIA GTC 2025で発表された「Dynamo」をGMO GPUクラウド上で実行した結果を基に記載しております。動作環境や設定によって結果が異なる可能性があり、すべての環境での動作を保証するものではありません。正式な仕様やサポートについては、各ソフトウェア・サービスの公式情報をご確認ください。