株式会社ずんだもん技術室AI放送局 podcast 20251021

youtube版(スライド付き) 関連リンク Build an AI Agent to Analyze IT Tickets with NVIDIA Nemotron 現代のIT運用では、インシデントや問い合わせから生まれる膨大なチケットデータがあります。しかし、これらのデータは単なる記録であり、そこからシステム全体の課題やチームのパフォーマンスに関する深い洞察を得るのは困難です。多くの場合、手作業での分析や複雑なクエリが必要となり、時間と労力がかかります。 NVIDIAのIT部門が開発したAIエージェント「ITelligence」は、この課題を解決するために作られました。このシステムは、NVIDIA Nemotronという先進的なAIモデルの推論能力と、データ間の関係性を明確にするグラフデータベースを組み合わせています。これにより、LLM（大規模言語モデル）で非構造化データから文脈を読み解き、グラフクエリでチケット間の関係性、異常、パターンを効率的に見つけ出すことを目指します。 AIエージェントの構築は、以下の主要なステップで行われます。 データ取り込みとグラフモデリング: ITSM（ITサービス管理）プラットフォームなどからチケットデータを収集し、ユーザー、インシデント、デバイスといった情報を「ノード」、関連性を「エッジ」としてグラフデータベースに格納。複雑なデータ間のつながりを可視化し、効率的なクエリを可能にします。 文脈のエンリッチメント: チケットに「新入社員の有無」「デバイスの種類」といった補助情報を追加し、分析の分類能力を高めます。 根本原因分析（RCA）: LLM（例: Llama 3）を使って、チケットの記述や解決メモから、具体的な根本原因キーワードを自動抽出。従来のカテゴリー分類では捉えきれない詳細な問題点を特定できます。 洞察の生成: LLMが、解決時間（MTTR）、顧客満足度（CSAT）、頻繁に発生する根本原因、新入社員のオンボーディング時の課題など、組織やチームレベルでのパターンや洞察を自動生成します。 アラートと自動配信: KPIトレンドを監視し、異常があれば担当者に自動でアラートを送信。また、AIが生成した要約レポートを定期的に自動配信し、部門ごとの具体的な情報共有と意思決定をサポートします。 インターフェースには、複雑な質問に対応できるインタラクティブなダッシュボード（Grafanaなど）が採用されました。RAG（検索拡張生成）ベースのチャットボットではなくダッシュボードを選んだのは、チャットボットではユーザーの複雑な意図を正確に解釈し、常に適切なクエリを生成するのが難しい場合があるためです。代わりに、ダッシュボードのフィルタリング結果と連携するカスタムの要約サービスAPIを介して、LLMがオンデマンドで要約を生成。これにより、手動でのチケットレビューを省き、共通の問題点や推奨事項を迅速に把握できるようになります。 このAIエージェントは、非構造化されたITチケットデータを実用的な洞察に変え、IT運用の意思決定と効率化を強力に支援します。 引用元: https://developer.nvidia.com/blog/build-an-ai-agent-to-analyze-it-tickets-with-nvidia-nemotron/ Scaling Large MoE Models with Wide Expert Parallelism on NVL72 Rack Scale Systems 最近のAI、特に大規模言語モデル（LLM）はますます巨大化しており、その中でも「MoE（Mixture-of-Experts）」という特殊な構造を持つモデルが注目されています。MoEモデルは、トークンごとに一部の「エキスパート」（専門家）だけを動かすことで、従来のモデルよりも効率的に計算できるのが特徴です。しかし、このMoEモデルを非常に大規模な環境で効率よく動かすには、いくつかの課題があります。 この記事では、NVIDIAが提案する「Wide Expert Parallelism（Wide-EP）」という技術と、その基盤となる「GB200 NVL72」というシステムが、これらの課題をどのように解決し、大規模MoEモデルの推論を高速化・効率化するのかを解説しています。 MoEモデルスケーリングの課題とWide-EPによる解決策 メモリと計算のボトルネック： MoEモデルでは、必要なエキスパートの「重み」（モデルの知識データ）をGPUに読み込む作業が頻繁に発生し、これが処理の遅延につながります。Wide-EPでは、エキスパートの処理を多数のGPUに分散させることで、1つのGPUが持つエキスパートの数を減らし、重みデータの読み込みを効率化します。これにより、GPUがより集中して計算に専念できるようになります。 GPU間の通信オーバーヘッド： エキスパートが複数のGPUに分散しているため、計算結果を集約する際に大量のデータ通信が必要になります。この通信が遅れると、全体の処理速度が低下します。GB200 NVL72システムは、超高速なNVLinkという技術でGPU間を接続しており、最大130TB/秒という圧倒的な帯域幅で、この通信のボトルネックを解消します。また、NVIDIAのNCCLライブラリが最適化された通信カーネルを提供し、効率的なデータ交換を可能にします。 負荷の偏り（ロードバランシング）： 特定のエキスパートが頻繁に使われる一方で、使われないエキスパートもあるため、一部のGPUばかりが忙しくなり、他のGPUが遊んでしまうことがあります。Wide-EPの「Expert Parallel Load Balancer (EPLB)」は、利用状況に応じてエキスパートのGPUへの割り当てをリアルタイムまたは事前に調整し、すべてのGPUが均等に働くように負荷を分散します。 これらの技術はNVIDIAのTensorRT-LLMに組み込まれており、さらに「NVIDIA Dynamo」と組み合わせることで、大規模なMoEモデル推論のオーケストレーション（全体の管理）と実行を最適化します。 性能と経済性へのインパクト Wide-EPをGB200 NVL72システムで活用することで、GPUあたりの処理能力が最大1.8倍向上することが確認されています。これは、モデルの推論コスト（TCO）を大幅に削減し、より多くのユーザーに対して高速なAIサービスを提供できることを意味します。新人エンジニアの皆さんにとっては、将来、巨大なAIモデルを扱う際に、このような分散処理と最適化技術が非常に重要になるということを理解する上で、この記事は良い学びになるでしょう。 引用元: https://developer.nvidia.com/blog/scaling-large-moe-models-with-wide-expert-parallelism-on-nvl72-rack-scale-systems/ AWSで障害–PerplexityやSlackなどグローバルサービスに支障 新人エンジニアの皆さん、今日の重要なITニュースについてお話しします。私たちが毎日使っているインターネットサービスは、巨大な「クラウドサービス」という基盤の上で動いていることが多いのですが、その代表格であるAmazonの「Amazon Web Services（AWS）」で、世界的な障害が発生しました。 AWSは、世界中の企業がウェブサイト、アプリケーション、データ保存、そして最近ではAIの複雑な計算処理など、様々なITシステムを動かすために利用している巨大なデータセンターの集合体です。今回の障害は、2025年10月20日17時30分頃、主にアメリカ東部の「US-EAST-1」というリージョン（物理的に離れた地域に設置された、独立したデータセンターのグループ）で発生しました。このUS-EAST-1は、AWSの中でも特に多くのサービスが利用する中心的なリージョンの一つであるため、ここで問題が起きると影響が非常に広範囲に及ぶのが特徴です。 具体的に影響を受けたサービスとしては、最新のAIチャットサービスである「Perplexity」や、多くの企業で使われているビジネスチャットツールの「Slack」の一部機能（例えば、音声会議機能のハドルなど）、ゲームプラットフォームの「EpicGames」などが挙げられています。これらのサービスが一時的に利用できなくなったり、動作が遅くなったりする事態が発生しました。この影響はアメリカだけでなく、日本のユーザーにも波及し、SNS上では「仕事で使っているSlackのハドルが使えなくて困った」「Perplexityで調べ物ができない」といった声が多数上がりました。 PerplexityのCEO、アラヴィンド・スリニヴァス氏も、自身のX（旧Twitter）アカウントで「Perplexityが現在ダウンしており、原因はAWS側の問題だ」とコメントし、復旧に向けて対応中であることを明らかにしました。AWS側も、ステータスページで問題が発生していることを公表し、原因の特定と復旧作業を進めている状況です。 今回のAWS障害は、普段当たり前のように利用しているインターネットサービスが、いかに一つの巨大なインフラに依存しているか、そして、そのインフラで障害が発生すると世界中に影響が及ぶという現実を改めて示しています。 新人エンジニアの皆さんにとって、これは非常に重要な学びの機会です。システムを設計する際には、たとえAWSのような信頼性の高いクラウドサービスを使うとしても、「障害は起こり得る」という前提で考えることが大切です。例えば、重要なデータは複数の場所にバックアップを取る、または、複数のリージョンにシステムを分散配置して、一つがダウンしても別の場所でサービスを継続できるようにする（ディザスタリカバリや高可用性の設計）といった対策が考えられます。普段から障害への備えを意識することで、いざという時にサービスを守ることができるのです。 引用元: https://japan.cnet.com/article/35239420/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

There are no comments yet.

Please log in to write the first comment.