MP3ファイルをダウンロード

内容紹介

Introducing CUDA Rust: Two Tracks for Writing GPU Kernels、When to Use Encode-Prefill-Decode Disaggregation to Accelerate Multimodal Model Serving、IBM releases SOTA Granite Time Series PatchTST-FM-r2 model with commercial-friendly license

出演者

ずんだもん

youtube版(スライド付き)

関連リンク

• Introducing CUDA Rust: Two Tracks for Writing GPU Kernels

NVIDIAは2026年9月、GPUカーネルをRust言語でネイティブに記述可能にする「CUDA Rust」を発表しました。近年、AIの推論エンジンやデバイスドライバなどのシステム開発において、コンパイル時にバグを検知できる高い安全性と、優れたパフォーマンスを両立するRustの採用が急速に進んでいます。しかし、GPUで直接実行される「GPUカーネル」の開発だけは、これまでC++などの他言語に頼る必要がありました。CUDA Rustはこのギャップを埋め、GPUカーネルをRustで直接記述し、ネイティブなGPU命令（PTX）へコンパイルできるようにします。

CUDA Rustには、開発スタイルに合わせて選べる2つのアプローチ（トラック）が用意されています。

1. SIMT（Single Instruction, Multiple Threads）トラック：cuda-oxide 従来のCUDA C++と同様に、「1つのスレッドが何を行うか」を記述し、数千のスレッドを同時に起動するお馴染みの並列処理モデルです。 独自のコンパイラバックエンドである「cuda-oxide」を使用し、ホスト側（CPU）とデバイス側（GPU）のコードを同一ファイルにまとめて記述できます。GPUでの並列処理で最も問題になりやすい「複数スレッドからの同時書き込み（データ競合）」を防ぐため、各スレッドに排他的なメモリアクセスを保証する専用の型（DisjointSlice）などが導入されています。これにより、配列の範囲外アクセスや意図しないデータ破損をコンパイル時に検知できます。なお、開発にはLinux環境やNightly版のRustツールチェーンが必要です。

2. Tile（タイル）トラック：cutile-rs より抽象度の高い新しいプログラミングモデルです。個々のスレッドではなく、データのかたまりである「タイル（部分テンソル）」単位で処理を記述します。 ホスト側でデータを「パーティショニング（分割）」すると、コンパイラがターゲットのGPUアーキテクチャに応じて、最適な実際のスレッド割り当てや共有メモリの配置を自動で決定します。開発者がハードウェアごとの微調整を意識する必要がないため、コードの可搬性が高まります。また、「cutile-rs」は安定版（Stable）のRustで動作するため、SIMTトラックに比べて環境構築の手間が少なく、手軽に始められます。

■ コンパイラが強力にバグを防ぐ「恐れなき並列性」 GPUプログラミングでは、大量のスレッドが同一のメモリ領域に不規則にアクセスするため、プログラムの挙動が不安定になるバグが発生しやすく、その原因究明も極めて困難です。CUDA RustはRust本来の「所有権・借用規則」を活用することで、例えば「読み込み専用のデータ」と「書き込み先のデータ」が重複するような危険なコードをコンパイルエラーとして弾きます。これにより、本番環境で突発的に発生するデータ競合のバグを未然に排除できます。

■ 現在の状況とこれから どちらのプロジェクトも現在は開発の初期段階（アルファ版）であり、本番環境での利用にはまだ適していません。しかし、Tileトラックの「cutile-rs」はすでに一部のLLM推論エンジンなどで採用され始めています。NVIDIAは今後、さらにツールチェーンの整備や他言語との相互運用のサポートを進め、エコシステムの成熟を図るとしています。

新人エンジニアにとって、従来のC++によるGPUプログラミングはメモリ管理の難しさからハードルが高いものでしたが、CUDA Rustの登場によって、Rustの安全性に守られながら安心してGPUの超並列処理に挑戦できる未来が近づいています。

引用元: https://developer.nvidia.com/blog/introducing-cuda-rust-two-tracks-for-writing-gpu-kernels/

• When to Use Encode-Prefill-Decode Disaggregation to Accelerate Multimodal Model Serving

マルチモーダルLLM（画像や動画を理解できるAI）の普及に伴い、その推論処理をいかに高速化するかが実務上の大きな課題となっています。本記事では、オープンソースの推論フレームワーク「NVIDIA Dynamo」を用いて、画像の変換処理（ビジョンエンコーダー）と、LLMの処理を物理的・論理的に分離する「EPD（Encode-Prefill-Decode）分離」という最新の最適化技術について、どのような場面で導入すべきかを解説しています。

1. なぜEPD分離が必要なのか？

マルチモーダルモデルの推論は、大きく以下の3つのフェーズで処理されます。

• Encode（符号化）: 画像や動画をビジョンエンコーダー（ViT）に入力し、LLMが理解できるベクトルデータ（埋め込み）に変換する。
• Prefill（事前充填）: 入力されたテキストと画像のベクトルをLLMに読み込ませ、最初の1文字（トークン）を出力する。
• Decode（生成）: 2文字目以降を1文字ずつ順番に生成する。

従来の一体型（Aggregated）構成では、1つのGPUでこれらすべての処理を順番に行います。しかし、画像や動画が多くなると「Encode」の処理に数百ミリ秒以上かかってしまい、同じGPUを使う「Prefill」や「Decode」の処理が待たされてしまいます。さらに、画像のないテキストのみの軽いリクエストまで、画像処理の順番待ちに巻き込まれて遅延するという課題が生じていました。

2. EPD分離の3つのアプローチ（配置トポロジー）

Dynamoは、エンコーダーとLLM（Prefill/Decode、以下PD）のワーカープロセスを分離し、独立して動作させることでこの課題を解決します。配置方法には以下の3つの選択肢があります。

• 一体型（Aggregated）: 1つのGPUで全ての処理をまかなう従来の方法。
• 同一GPU配置（Colocated）: 1つのGPU上で、エンコーダーワーカーとPDワーカーを別々に起動する。GPUの計算資源を共有しつつ、リクエストの整理やバッチ処理を独立して行えるため、同じ種類のGPUで構成された環境に最適です。
• 完全分離配置（Disaggregated）: エンコーダー専用の安価なGPU（例: RTX 6000D）と、PD専用の超高性能GPU（例: GB200）を分ける方法。作成されたベクトルデータは高速なネットワーク（NIXL）を介して転送されます。

3. EPD分離が効果を発揮する条件

EPD分離はいつでも性能が上がるわけではなく、データのやり取りにかかるオーバーヘッドを上回る効果が得られる「適材適所」の技術です。

• 画像・動画の枚数が多い場合: 入力メディアが増えるほどEncodeの負荷が高まるため、EPD分離による「最初の文字が出るまでの時間（TTFT）」の短縮効果（最大5倍）が顕著になります。
• 出力する文章が短い場合: 出力文字数が短い（OSLが小さい）ほど、全体の処理時間におけるEncodeの割合が高いため、システム全体の応答速度が最大7倍向上します。逆に出力文字数が長くなると、Decodeの時間が支配的になりEPDの効果は薄れます。
• LLMが軽量、または量子化されている場合: LLMの処理が軽い（4bit等に量子化されているなど）と、相対的にEncode処理の重さが際立つため、EPDの効果が大きくなります。
• テキストと画像のリクエストが混在する環境: エンコーダーを分離することで、テキストのみのリクエストが画像処理の完了を待つ必要がなくなり、テキストリクエストのTTFTを最大42.2%削減できます。

まとめとステップアップ

EPD分離は、画像が多く、出力が短めで、テキストと画像が混在するような本番環境のワークロードにおいて最大の成果を発揮します。 Dynamoには、他にも「メディアの並行デコード」や「一度計算した画像ベクトルを再利用するキャッシュ機能」など、フロントエンド側でボトルネックを解消する強力な機能が備わっており、これらを適切に組み合わせることで、さらにスマートで高速なAIシステムの構築が可能になります。

引用元: https://developer.nvidia.com/blog/when-to-use-encode-prefill-decode-disaggregation-to-accelerate-multimodal-model-serving/

• IBM releases SOTA Granite Time Series PatchTST-FM-r2 model with commercial-friendly license

1. 時系列予測に革新をもたらす基盤モデル

これまでの時系列予測は、データセットごとに専用の予測モデルを個別に学習・維持するのが一般的でした。しかし現在、テキスト分野のLLMのように、大量のデータであらかじめ事前学習させた「時系列基盤モデル」を用いて、追加学習なし（Zero-shot）で即座に予測を行うアプローチが主流になりつつあります。 IBMが新たにリリースした「Granite Time Series PatchTST-FM-r2」は、約3億8500万（385M）のパラメータを持つ最新の時系列基盤モデルです。需要、価格、電力負荷、トラフィック、システムのテレメトリといった、あらゆる時系列データの予測に対応します。

2. 商用利用可能なオープンモデルでトップの性能

本モデル最大の強みは、極めて高い予測精度と、ビジネスに導入しやすいライセンスの両立です。時系列予測の代表的なベンチマーク「GIFT-Eval」において、商用利用可能なオープンソースライセンス（Apache 2.0およびOpenMDW 1.0）のZero-shot部門でトップの性能を記録しました。 実務へのAI導入では「ライセンスの制約」や「学習データの不透明さ」が障壁になりがちですが、本モデルは学習に使用したデータソースが明確に開示されているため、企業のガバナンス基準をクリアしやすく、安心してプロダクション環境へ導入できます。

3. アーキテクチャの進化：Conformerの導入

前世代（r1）からの最大の大幅なアップデートは、音声処理分野などで実績のある「Conformer（コンフォーマー）」アーキテクチャの採用です。 従来のTransformerは「長期的な関係性」の把握が得意な反面、局所的な「短期の変動」を捉えるのが苦手でした。r2では、Self-Attention（自己アテンション）に「時間方向の畳み込み（Temporal Convolution）」を組み合わせたブロックを導入しました。これにより、畳み込みが短期的なローカルの動きをキャッチし、アテンションが長期的なトレンドの分析に集中できるようになり、予測精度が飛躍的に向上しました。 さらに、境界を滑らかにする50%重複パッチ処理、不確実性を評価できる99段階の分位数（Quantile）出力、最大8,192ステップの長いコンテキストへの対応など、実戦向けの機能が満載です。

4. 開発者フレンドリーな設計とリアルタイム対応

Hugging Face上でモデルの重みや推論パイプラインが公開されており、Pythonライブラリ granite-tsfm を使えば、数行のコードで手元のデータから未来の予測値を算出できます。面倒なファインチューニング（追加学習）は一切不要です。 さらに、Apache Flinkなどと連携し、Confluent Cloud上で稼働するストリーミングデータに対しても、データを別環境へ移動させることなくリアルタイムで予測や異常検知を実行できる仕組みが整っています。検証から本番システムへの組み込みまでをスムーズに行える、エンジニアにとって非常に魅力的な技術です。

引用元: https://huggingface.co/blog/ibm-research/ibm-releases-sota-granite-time-series

• お便り投稿フォーム

（株式会社ずんだもんは架空の登場組織です）