本記事は 2025/11/24 に公開された “ Running NVIDIA Cosmos world foundation models on AWS” を翻訳したものです。 自律走行車、ロボティクス、スマートファクトリー向けのフィジカル AI システムの開発においては、高品質かつ十分なトレーニングデータを生成するということが非常に重要な課題となります。このブログでは、Amazon Web Services (AWS) 上で NVIDIA Cosmos TM ワールドファウンデーションモデル（WFM）をデプロイして、大規模に高品質の合成データを生成する方法を示します。また、異なるユースケースに最適化された 2 つの本番環境向けアーキテクチャを紹介します。 フィジカル AI により、システムは複雑かつ動的な環境で知覚、感知、推論、および自律的な行動ができます。しかし、これらのモデルの事前トレーニングと事後トレーニングには、膨大な量の高品質な実演例が必要です。ビデオからの既存の実演例や、人間が作成する新しい実演例は限られており、十分なデータを提供できません。合成データの生成は、このデータギャップの課題を克服し、フィジカル AI を進化させて、業界全体でビジネスを変革する高度な新しい行動を可能にするために重要です。 Cosmos オープン WFM はこのギャップを埋め、シナリオの合成、ドメインのランダム化、および空間推論を通じて、自律走行車、ヒューマノイドロボット、スマートファクトリー、およびビデオ分析 AI エージェント向けのフィジカル AI の開発を可能にします。Cosmos モデルを最大限に活用するには、慎重に設計され、構成された管理インフラストラクチャが必要です。このインフラストラクチャは、スケーラブルでコスト効率が高い必要があります。 このブログでは、AWS インフラストラクチャ上で Cosmos WFM をデプロイするためのシステムアーキテクチャと実装のベストプラクティスを紹介します。これにより、エンタープライズグレードのスケーラビリティ、セキュリティ、パフォーマンスを実現します。また、コスト効率性、簡単な管理、および再現可能なデプロイメントも提供します。 フィジカル AI データパイプラインの課題 大規模言語モデル（LLM）は、インターネット上の何十年にもわたるデジタル化されたテキスト、書籍、ウェブサイト、ビデオ、会話などの事実上無制限のトレーニングデータを利用しています。この膨大なコーパスにより、モデルはスケールで言語パターン、推論、および知識表現を学習できます。しかし、フィジカル AI システムは根本的に異なる課題に直面しています：「データ不足問題」です。 図 1: フィジカル AI のための合成データ生成の進化 インターネット上のテキストとは異なり、物理的相互作用のデータは不足しています。オブジェクトを操作したり、環境をナビゲートしたり、器用なタスクを実行したりするには、行動をクローンする模倣学習などの現在の技術が必要です。これには、実際の物理的相互作用で取得された現実のセンサーデータ（カメラ映像、力の測定、感覚フィードバックなど）が必要です。このデータを収集するにはコストや時間がかかり、しばしば危険です。 そこで合成データの生成が不可欠になります。Cosmos WFM は物理的に妥当性のあるシナリオを合成します。これには、写実的な光の変化、オブジェクトのテクスチャ、カメラアングル、および動きの軌跡が含まれます。これにより、開発サイクルが加速し、モデルの堅牢性が向上し、フィジカル AI が経済的に実行可能になります。 Cosmos WFM 概要 Cosmos は、WFM を活用してフィジカル AI を進化させるために設計されたプラットフォームです。その中核には、事前トレーニングされたマルチモーダルモデルである Cosmos オープン WFM があり、開発者が世界の状態をビデオとして生成し、フィジカル AI の推論や事後トレーニングを行い、特殊なフィジカル AI モデルを開発できます。Cosmos プラットフォームは 3 つのモデルで構成されています： Cosmos Predict 画像、深度マップ、センサーデータ、テキストプロンプトなどの初期条件から、物理的・時間的に正しい未来の状態を動画で生成するモデルです。 Cosmos Transfer テキストプロンプトと実世界のデータ、シミュレーションから得られた複数の空間制御入力を使用して、フィジカル AI 開発のための物理学を意識した世界状態の映像を生成します。Transfer は、照明、背景、天候、色、テクスチャなどの多様性を追加することで、与えられたデータセットを拡張および増殖させることができます。 Cosmos Reason Cosmos Reason は、物理 AI のためのオープンでカスタマイズ可能な推論ビジョン言語モデル（VLM）です。この VLM により、ロボットやビジョン AI エージェントは、事前知識、物理学、常識を使用して現実世界を理解し、行動できます。このモデルは 物理的 推論 リーダーボード でトップを獲得し、データアノテーションや批評、ロボット計画とトレーニング、業界全体でのビデオ分析 AI エージェントの作成など、さまざまなユースケースに適用できます。Cosmos Reason は、 NVIDIA Blueprint for Video Search and Summarization（VSS） でビデオ分析 AI エージェントの開発に使用されています。 これらのモデルを特定のドメイン向けに構築、カスタマイズ、デプロイするには、開発者は NVIDIA Cosmos Cookbook を活用できます。推論、事後トレーニング、ファインチューニングのためのステップバイステップのワークフロー、技術的なレシピ、具体的な例を提供します。 AWS 上で Cosmos WFM を実行するためのアーキテクチャ AWS は次の 2 つのデプロイメントオプションがあります： – リアルタイム推論： NVIDIA NIM マイクロサービスを Amazon Elastic Kubernetes Service (Amazon EKS) で低遅延のインタラクティブアプリケーション用に使用できます。NVIDIA NIM マイクロサービスは、組織が NVIDIA GPU 上で AI モデルを実行できる一連の高速化されたされた推論マイクロサービスです。 – バッチ推論： コンテナ化されたモデルを AWS Batch で高スループットのオフラインワークロード用に使用できます。 NIM-on-EKS パターンは、常時稼働する GPU 対応 Pods で応答遅延と可用性を優先します。一方、AWS Batch パターンは、ジョブの投入をトリガーとしたコンピューティングプロビジョニングを通じて、コスト効率と弾力的なスループットを最適化します。これらのアーキテクチャを選択する際は、レイテンシー要件、推論量パターン、コスト制約、および物理 AI 開発パイプラインの統合ポイントを考慮する必要があります。 オプション 1：ライブ推論の実行– Amazon EKS 上の Cosmos NIM マイクロサービス Amazon EKS 上の Cosmos NIM マイクロサービスオプションは、エンタープライズグレードのオーケストレーション、自動スケーリング、および簡素化された運用を提供します。これは、高可用性、動的スケーリング、およびクラウドネイティブな統合を必要とする本番環境のデプロイメントに推奨されるアプローチです。Cosmos NIM マイクロサービスは、最適化された推論エンジンを備えた Cosmos モデルをパッケージ化し、手動構成の複雑さを解消します。このパターンのデプロイメントのステップバイステップガイドについては、 “Deploying generative AI applications with NVIDIA NIMs on Amazon EKS” ブログ投稿 を参照してください。 アーキテクチャ図 図 2: Amazon EKS 上での Cosmos NIM マイクロサービスを使用したライブ推論の実行のアーキテクチャ 利点 – エンタープライズグレードのオーケストレーション : Kubernetes は宣言型構成、自動ロールアウトとロールバック、ポッド再起動による自己修復、および手動構成なしのサービスディスカバリーを提供します。 – 高可用性 : マルチポッドデプロイメントにより、単一障害点がなくなります。クロス AZ ノード配置により、アベイラビリティーゾーンの障害を回避できます。ローリングアップデートにより、デプロイメント中のサービス可用性が維持されます。 – 運用の簡素化 : マネージドコントロールプレーンにより、ノードのメンテナンスが不要になります。自動アップグレードにより、クラスターのコンポーネントが最新の状態に保たれます。AWS サービスとの統合により、統一されたモニタリングとセキュリティが提供されます。 オプション 2: バッチ推論の実行 – AWS Batch 上の Cosmos コンテナ AWS Batch は、大規模なバッチコンピューティングワークロードを実行するためのフルマネージドサービスを提供し、オフライン推論シナリオのための Cosmos WFM のデプロイメントに理想的なプラットフォームとなります。このアーキテクチャにより、軌跡データの合成、シーンバリエーション、または環境予測の生成など、大量の物理 AI データを処理できます。常時インフラストラクチャを維持する必要なく、AWS Batch によってオーケストレーションされるコンテナ化された Cosmos モデルを活用します。ジョブキューの需要に基づいて、自動的に最適なコンピュートリソース（GPU 対応 EC2 インスタンス）をプロビジョニングします。また、Amazon S3 または Amazon EFS からの入力データを元に、バッチジョブを開始することができます。これらのジョブは、ビデオ生成、シーン補完、または物理シミュレーションなどの推論タスクを実行します。この結果は、ロボットトレーニングパイプラインや自律システム開発ワークフローといった後段の処理のために EFS に書き戻されます。Amazon CloudWatch との統合は包括的なモニタリングを提供し、AWS IAM ポリシーはモデルアーティファクトとデータリポジトリへの安全な最小特権アクセスを保証します。このパターンのデプロイメントのステップバイステップガイドについては、この ワークショップ を参照してください。 アーキテクチャ図 図 3: AWS Batch で Cosmos コンテナを使用してバッチ推論を実行するためのリファレンスアーキテクチャ 利点 – コスト最適化 : 動的スケーリングにより、AWS Batch は推論ジョブが実行される時のみ GPU コンピュートリソースをプロビジョニングし、完了時にインスタンスを終了します。この従量課金モデルにより、アイドルインフラストラクチャに関連するコストが排除され、特にデータセット拡張や夜間の合成データ生成などの断続的なワークロードに有効です。さらに、スポットインスタンスの活用によってコンピュートコストを削減することも可能です。 – 運用管理の簡素化 : マネージドサービスにより、自動ジョブスケジューリング、リソースプロビジョニング、依存関係管理、再試行ロジックにより、インフラストラクチャの複雑さが軽減され、クラスターの操作ではなくモデルの最適化に集中できます。 – 大規模データ生成のための弾力的なスループット : AWS Batch は、単一ジョブから数千の並列推論タスクまで、フィジカル AI トレーニングのための大規模なデータセットを処理します。この弾力的な演算能力により、価値実現までの時間を加速し、ロボットポリシー開発と自律システム検証における繰り返しを高速化できます。 まとめ AWS で Cosmos WFM を実行すると、大規模な物理 AI 機能を利用できます。このブログでは、異なる組織のニーズと制約に最適化された 2 つの本番環境向けアーキテクチャを紹介しました。 AWS モデルマーケットプレイス上で提供されている Cosmos Reason 推論ビジョン言語モデル を導入し、高度な空間-時間的理解と物理的常識を活用して AI プロジェクトを強化し、よりスマートなロボット計画、ビデオ分析、および最先端の効率性と推論機能を備えた自動データ注釈を可能にするかをご確認ください。 著者注: この技術ガイドは、Cosmos プラットフォームの機能、AWS のベストプラクティス、および大規模モデルデプロイメントの一般原則に基づいています。具体的な実装の詳細は、お客様の要件、最新の NVIDIA NIM マイクロサービスリリース、AWS サービスの更新、および組織のポリシーと制約によって異なる場合があります。最新の情報については、常に NVIDIA と AWS の最新のドキュメントを参照してください。 翻訳は、ソリューションアーキテクトの山本が担当しました。 Abhishek Srivastav Abhishek Srivastav は Amazon Web Services のプリンシパルソリューションアーキテクトで、クラウド採用戦略の加速を通じて顧客の成功を推進しています。AI/ML 技術、ハイパフォーマンスコンピューティング、シミュレーション、物理 AI など、幅広い技術的専門知識を持ち、複雑な企業の課題に対するソリューションの設計を専門としています。現在の役割では、CIO、CTO、その他の技術幹部と協力して、デジタルトランスフォーメーションと生成 AI イニシアチブのロードマップを開発しています。 Brett Hamilton Brett Hamilton は NVIDIA の Developer Relations マネージャーで、フィジカル AI とワールドファウンデーションモデルに取り組んでいます。彼は ISV との協力、新技術の採用拡大、現実世界の課題解決に特化しています。Brett の AI との関わりは 2015 年に B2B チャットボットの開発から始まりました。その後、音声アシスタント、NLP と言語アプリケーション、そしてビジュアル AI にまで及びました。彼は Cisco、AWS、そして NVIDIA で製品リーダーシップ、ビジネス開発、そして開発者関係の役割を担ってきました。 Diego Garzon Diego Garzon は NVIDIA の AI/AV シニアソリューションアーキテクトで、フィジカル AI とシミュレーションに取り組んでいます。以前は Microsoft のプロシージャルコンテンツディレクターとして Xbox Game Studios のプロシージャルグラフィックスをリードしていました。キャリアの初期には、Blizzard Entertainment と Blue Sky Studios で働き、アニー賞にノミネートされました。また、ピクサーの WALL·E にも貢献しました。Diego は SIGGRAPH で流体シミュレーションと水の効果に関する研究を発表しました。また、GDC でグローバルイルミネーションとプロシージャルライティングプローブについて発表しました。さらに、ビジュアルエフェクトソサイエティの理事を務めたこともあります。 Jathavan Sriram Jathavan Sriram は NVIDIA のシニアソリューションアーキテクトで、AI とロボティクスソリューションを専門としています。彼の専門分野はクラウドインフラストラクチャ、Kubernetes、AI 技術で、ワールドファウンデーションモデルとフィジカル AI アプリケーションに注目しています。彼はクラウドネイティブプラットフォーム上で顧客が生成 AI を大規模に展開できるようにすることに情熱を注いでいます。 Shaun Kirby Shaun Kirby は AWS のプリンシパルエンタープライズアーキテクトで、自動車および製造業向けの Internet of Things (IoT) とロボティクスを専門としています。彼は顧客がクラウド技術で卓越するのを助け、ゲームチェンジングなソリューションを先駆けています。AWS に入る前は、Cisco でラピッドプロトタイピングと IoT ショーケースをリードし、大規模システム統合の経験がありました。

MathJax={tex:{inlineMath:[['$','$']],displayMath:[['$$','$$']],processEscapes:true}}; こんにちは、Insight Edgeでデータサイエンティストをしている新見です。 cuTile Pythonとは 背景 特徴 従来のCUDA（SIMT）との違い 文法 TileGymで行列積ベンチマーク 倍精度行列積エミュレーション Ozaki Schemeについて 分解(Split) 行列積の計算 素朴な実装と初回結果 最適化 Fast Mode（GEMMの削減） Fused Split Kernel（分割の融合） 最適化後の結果 dによる精度/速度トレードオフ まとめ 参考文献 今回はNVIDIAが発表したばかりの「cuTile Python」を試してみました。普段は、GPUカーネルを業務で書くことはありませんが、cuTileはPythonで書かれていて、文法もシンプルなようなので、GPUプログラミングの勉強の意味も含めて記事にしました。 cuTile Pythonとは cuTile Pythonは、NVIDIA GPU向けの新しい並列プログラミングモデル「cuTile」をPythonから使うためのDSL（ドメイン固有言語）です。 背景 GPU上で高速に動作する処理を自前で記述したい場面は増えていますが、CUDA C++の習得コストは依然として高いのが実情です。 PyTorchやcuBLASといった高レベルAPIで日常的な開発は十分カバーできるものの、LLM推論の最適化など低レイヤへの介入が求められる局面も増えてきました。NVIDIA Ampere世代以降のGPUではTensor CoreやTMA（Tensor Memory Accelerator）といったハードウェア機能が追加されており、これらを十分に活用するにはより踏み込んだプログラミングが必要になります。 しかし、ハードウェアを意識したコードを書く難易度は上がり続けています。メモリ階層ひとつ取っても、共有メモリ、レジスタ、Blackwell世代で追加されたTensor Memoryなど、用途に応じて使い分ける必要があり、それぞれの特性に合わせたデータ配置や転送の制御が求められます。 さらに、特定のアーキテクチャに最適化したコードは新しい世代のGPUが登場した途端に書き直しが必要になることも多く、保守コストも無視できません。 こうした背景から、ハードウェアの詳細を抽象化しつつ高い性能を引き出すDSLへの需要が高まっています。OpenAIの gpt-oss リポジトリでもTritonという同様のDSLが採用されており、この手のアプローチは業界でも広く注目されています。 特徴 GPUプログラミングには、cuBLASやPyTorchのような高レベルライブラリか、CUDA C++やPTXといった低レベルなスレッド制御か、という二極化がありました。cuTileはこの中間に位置する「Tileレベル」のプログラミングモデルです。 抽象レベルについて（動画[1]より） 以下、動画[1]で紹介されていた特徴になります。 CUDAプラットフォームにネイティブ統合 : OpenAI Tritonなどサードパーティ製DSLとは異なり、cuTile（Tile IR）はCUDAドライバに組み込まれています。既存のプロファイラやデバッガがそのまま使えます。 Tile IRへのコンパイル : Pythonで書いたカーネルは「Tile IR」という仮想ISAに変換され、ドライバが実行時にターゲットGPUに合わせた最適なマシンコード（SASS）を生成します。 技術スタックの階層構造、TileIRはPTXを置き換えるのではなく共存する（動画[1]より） 従来のCUDA（SIMT）との違い 従来のCUDA（SIMT: Single Instruction, Multiple Threads）とcuTileでは、プログラマが何を書いて何をシステムに任せるかが大きく異なります。 特徴 従来のCUDA (SIMT) cuTile (Tile-based) 実行単位 スレッド単位でデータ処理を記述。WarpやBlockの構成を意識する必要がある データの塊（タイル）と単一の実行単位（ブロック）で思考。スレッドへの分解はシステムが行う データ処理 個々のスレッドへのデータ分配（ストライディングなど）を手動で計算・管理 タイル（配列全体の一部）を一つの単位としてロード・演算・ストア メモリ管理 共有メモリの確保、同期（バリア）、バンクコンフリクト回避などをユーザーが管理 システムが管理。共有メモリの利用や同期は自動化され、ユーザーからは隠蔽 ハードウェア活用 Tensor Coreなどを使うには複雑なPTX命令や特定のレイアウトを意識する必要がある ct.load や演算子を書くだけでTMAやTensor Coreを自動的に活用 文法 cuTile Pythonは、Pythonのデコレータと専用の型システムを使って記述します。詳しくは公式ドキュメント[2]を参照してください。 主な特徴: @ct.kernel デコレータ : Python関数をGPUカーネルとしてマーク。関数内ではcuTile Pythonの文法に従う。 イミュータブルなタイル : カーネル内では、タイルが操作対象となる。タイルは「値」として扱われ、変更不可。演算すると新しいタイルが生成されます Array (Global Memory): 引数から取得、ミュータブル。 ct.load / ct.store でアクセス Tile (Local/Register): イミュータブルで演算対象 以下、ベクトル加算のコード例です。 import cuda.tile as ct # タイルサイズはコンパイル時定数 TILE_SIZE = 16 @ ct.kernel def vector_add_kernel (a, b, result): # 1. 現在のブロックIDを取得 (スレッドIDではない！) block_id = ct.bid( 0 ) # 2. グローバルメモリ(Array)からタイルとしてデータをロード # システムが自動的に最適なメモリ転送(TMA等)を行う a_tile = ct.load(a, index=(block_id,), shape=(TILE_SIZE,)) b_tile = ct.load(b, index=(block_id,), shape=(TILE_SIZE,)) # 3. タイル同士の演算 (要素ごとの加算が一括で行われる) result_tile = a_tile + b_tile # 4. 結果をグローバルメモリにストア ct.store(result, index=(block_id,), tile=result_tile) # ホスト側からの実行 # ct.launch(stream, grid_dim, kernel_func, args) ブロックごとに同一のカーネルが実行され、各ブロックはIDで指定されたデータを担当範囲として、処理を行います。タイル演算は、感覚としてはnumpyの処理に似ています。 TileGymで行列積ベンチマーク 実際に動かします。cuTileはCUDA Toolkit13.1以降が必要で、これはBlackwell世代以降の比較的最新のGPUでしか動かないようです。私は手元に最新のGPUがないので、クラウドサービスを利用したいと思います。今回は、 Modal と呼ばれるGPU特化のクラウドサービスを利用しました。 Modalは関数ベースでGPUインスタンスを立ち上げられるサービスになります。使い勝手がよく、便利です。実行時間に応じた従量課金制で、今回の検証のような少しGPUを試してみたい場合に適しています。 今回は、公式のサンプルレポジトリTileGym[3]をベースに、行列積のコードの実行をしてみます。Modalで走らせる実行コードを以下に示します。imageでDockerイメージを作成し、TileGymのレポジトリをクローン、ライブラリインストールを行います。Modalの詳細は ドキュメント を参照してください。今回対象のGPUはB200です。 # run-tilegym.py import modal image = ( modal.Image.from_registry( "nvidia/cuda:13.1.0-devel-ubuntu24.04" , add_python= "3.13" ) # CUDA 13.1開発環境イメージ .apt_install( "git" ) .run_commands( "pip install --pre torch --index-url https://download.pytorch.org/whl/cu130" ) # PyTorchインストール、比較のため .run_commands( "git clone https://github.com/NVIDIA/TileGym.git && cd TileGym && pip install -e ." ) # cuTile, TileGymインストール .entrypoint([]) ) app = modal.App( "tilegym-test" ) @ app.function (gpu= "B200" , image=image, timeout= 600 ) def run_mma_bench (): import os os.chdir( "/TileGym" ) os.system( "python tests/benchmark/bench_matrix_multiplication.py" ) @ app.local_entrypoint () def main (): run_mma_bench.remote() 上のコードをrun-tilegym.pyとして保存し、 modal run run-tilegym.py で実行します。問題なければ結果は、以下のように出力されるはずです。 matmul-performance-float16-TFLOPS: M N K CuTile PyTorch 0 1024.0 1024.0 1024.0 271.056760 473.522850 1 2048.0 2048.0 2048.0 1129.688506 1199.365877 2 4096.0 4096.0 4096.0 1235.696555 1401.341171 3 8192.0 8192.0 8192.0 1483.030888 1253.946946 4 16384.0 16384.0 16384.0 1356.600018 1536.098446 5 32768.0 32768.0 32768.0 1254.836929 1306.057063 matmul-performance-float8_e5m2-TFLOPS: M N K CuTile 0 1024.0 1024.0 1024.0 277.309352 1 2048.0 2048.0 2048.0 1154.454102 2 4096.0 4096.0 4096.0 2769.415226 3 8192.0 8192.0 8192.0 2981.168986 4 16384.0 16384.0 16384.0 2935.864636 5 32768.0 32768.0 32768.0 2658.604232 CuTileとPyTorchの行列積のベンチマークが出ています。float16とfloat8_e5m2の両方で行列積を実行していますが、PyTorchでは、後者の行列積が未対応のようです。PyTorchは裏側でcuBLASを呼び出しているので実質cuBLASとの比較です。float16では、CuTileはPyTorchに近い性能、一部のサイズでは、PyTorchを上回る性能が出ています。float8_e5m2では、行列サイズが4096以上でfloat16の約2倍の性能が出ています。 以下が TileGym/src/tilegym/ops/cutile/matmul.py の行列積のカーネルコードの抜粋です。 @ ct.kernel (num_ctas=ct.ByTarget(sm_100= 2 )) def matmul_kernel (A, B, C, TILE_SIZE_M: ConstInt, TILE_SIZE_N: ConstInt, TILE_SIZE_K: ConstInt): # 担当タイルのインデックス計算（L2キャッシュ局所性のためswizzle） bidx, bidy = swizzle_2d(A.shape[ 0 ], B.shape[ 1 ], TILE_SIZE_M, TILE_SIZE_N, GROUP_SIZE_M= 8 ) num_tiles_k = ct.num_tiles(A, axis= 1 , shape=(TILE_SIZE_M, TILE_SIZE_K)) # FP32アキュムレータの初期化（FP16入力でも精度維持のためFP32で累積） accumulator = ct.full((TILE_SIZE_M, TILE_SIZE_N), 0 , dtype=ct.float32) # FP32→TF32変換（Tensor Coreを利用するため） dtype = ct.tfloat32 if A.dtype == ct.float32 else A.dtype # K方向にタイル単位でループ for k in range (num_tiles_k): a = ct.load(A, index=(bidx, k), shape=(TILE_SIZE_M, TILE_SIZE_K), padding_mode=ct.PaddingMode.ZERO).astype(dtype) b = ct.load(B, index=(k, bidy), shape=(TILE_SIZE_K, TILE_SIZE_N), padding_mode=ct.PaddingMode.ZERO).astype(dtype) accumulator = ct.mma(a, b, accumulator) # 行列積計算・累積 # 出力型に変換して結果を書き出し ct.store(C, index=(bidx, bidy), tile=ct.astype(accumulator, C.dtype)) A:MxK @ B:KxN -> C:MxN の行列積で、M方向、N方向単位でバッチに切り分けCの部分タイルごとに並行して実行されます。K方向にも部分分割して、順次読み込み(load), 行列積計算(mma), 結果の保存(store)を行っています。cuTile側でメモリの種類やMMA命令の選択は書く必要がなく、コンパイル時に自動的に最適化されます。 このように簡潔に書いても、ゴリゴリにチューニングしているcuBLASに匹敵した性能を出しているというのがcuTileの売りなようです。 ベンチマークを動かしただけでは面白くないので、型の精度を少し上げて同様の計算をしてみます。F32演算の場合、上記コードでは行列をTF32に変換してから計算しています。それと合わせるため、PyTorch側も以下のようにTF32を有効化します。 # TileGym/tests/benchmark/bench_matrix_multiplication.py # Enable TF32 for PyTorch to match Tensor Core behavior torch.backends.cuda.matmul.allow_tf32 = True torch.backends.cudnn.allow_tf32 = True また、FP64演算にあたり、累積の型がFP32では精度が足りないため、cutileコード側で累積の型をFP64に変更する処理を追加しています。 # Initialize an accumulator for the current output tile (TILE_SIZE_M x TILE_SIZE_N). # Use float64 for float64 inputs, otherwise float32 for higher precision accumulation. acc_dtype = ct.float64 if A.dtype == ct.float64 else ct.float32 accumulator = ct.full((TILE_SIZE_M, TILE_SIZE_N), 0 , dtype=acc_dtype) 以下が修正後のベンチマーク結果です。 matmul-performance-float32-TFLOPS: M N K CuTile PyTorch 0 1024.0 1024.0 1024.0 208.295471 294.114105 1 2048.0 2048.0 2048.0 665.976324 648.103430 2 4096.0 4096.0 4096.0 698.961883 747.326296 3 8192.0 8192.0 8192.0 783.858756 761.237840 4 16384.0 16384.0 16384.0 856.688401 742.126004 matmul-performance-float64-TFLOPS: M N K CuTile PyTorch 0 1024.0 1024.0 1024.0 0.855789 26.687611 1 2048.0 2048.0 2048.0 1.063844 33.830530 2 4096.0 4096.0 4096.0 1.124713 35.400544 3 8192.0 8192.0 8192.0 1.124824 35.438650 FP32では、PyTorchに近い性能が出ています。一方、FP64では、cuTile側での最適化がまだ不十分なようで、PyTorchに大きく劣る結果となっています。TILE_SIZEをより小さく設定することで、1.6 TFLOPS程度には改善しましたが、まだ大きく劣っています。 原因としては、cuTileの ct.mma がFP64演算に対して効率的な命令へマッピングできていない可能性が高いです。cuBLAS（PyTorch）はFP64 Tensor Coreを含むハードウェアリソースを最大限に活用した成熟した実装を持っており、この差が性能差に直結しています。 ここで、FP64演算の性能を向上させるために、Ozaki Schemeと呼ばれる倍精度行列積エミュレーション手法を試してみます。 倍精度行列積エミュレーション Ozaki Schemeについて Ozaki Schemeは、FP64の行列積をFP64演算なしで高精度にエミュレートする手法です[4][5]。詳しくは元の論文を読んでほしいのですが、概要を説明します。基本的なアイデアは、FP64行列を複数の低精度行列に分解し、Tensor Coreで高速に行列積を計算するというものです。行列の分解、行列の計算、結果の累積の3段階で構成されます。 分解(Split) 論文に従い、以下の型を定義します。 Type1 (FP64): 元の行列の精度。仮数部 $m_{\text{Type1}} = 53$ ビット Type2 : 分解先の低精度型（BF16, FP16, FP8等）。仮数部 $m_{\text{Type2}}$ ビット（隠れビット含む） Type3 (FP32): Tensor Coreの累積精度。仮数部 $m_{\text{Type3}} = 24$ ビット Type1の行列 $\boldsymbol{x}$ を、残差 $\boldsymbol{x}^{(p)}$ がゼロになるまで再帰的にType2スライス $\bar{\boldsymbol{x}}^{(p)}$ に分解します。$\boldsymbol{x}^{(1)} = \boldsymbol{x}$ として、各ステップ $p$ で以下を行います。 $$c_x^{(p)} = \left\lceil \log_2 \left( \max_i \left| x_i^{(p)} \right| \right) \right\rceil \tag{1}$$ $$\sigma = 0.75 \cdot 2^{\rho + c_x^{(p)}} \tag{2}$$ $$v_i = \text{fl}_{\text{Type1}} \left( \left( x_i^{(p)} + \sigma \right) - \sigma \right) \tag{3}$$ $$x_i^{(p+1)} = \text{fl}_{\text{Type1}} \left( x_i^{(p)} - v_i \right) \tag{4}$$ $$\bar{x}_i^{(p)} = \text{cvt}_{\text{Type2}} \left( \text{fl}_{\text{Type1}} \left( 2^{-c_x^{(p)}} v_i \right) \right) \tag{5}$$ ここで $\rho$ は精度パラメータ（Type1, Type2, Type3の仮数部ビット数と内積次元 $k$ から決定）です。$\sigma$ を足して引く操作（式3）がVeltkamp分割の核心で、上位 $m_{\text{Type2}}$ ビットを正確に抽出します。式4で残差を更新し、式5で $2^{c_x^{(p)}}$ で正規化してType2スライスを得ます。 この結果、$\boldsymbol{x}$ は $s_x$ 個のスライスに分解されます。 $$\boldsymbol{x} = \sum_{p=1}^{s_x} 2^{c_x^{(p)}} \cdot \bar{\boldsymbol{x}}^{(p)} \tag{9}$$ $c_x^{(p)}$ が指数部、$\bar{\boldsymbol{x}}^{(p)}$ が仮数部に対応します。スライス数 $s_x$ は $\boldsymbol{x}^{(p)} = 0$ になるまでの反復回数で決まり、理論的には $\lceil m_{\text{Type1}} / m_{\text{Type2}} \rceil$ ステップですが、行列要素のスケールのばらつきにより多くなることがあります。 PyTorchでの実装は以下の通りです。 def ozaki_split_to_type2_slices (x, k, type2, max_slices= 20 ): # 仮数部ビット数（隠れビット含む） m_fp64, m_fp32 = 53 , 24 m_type2 = - int (math.log2(torch.finfo(type2).eps)) + 1 # 精度パラメータ ρ の計算 gamma = math.ceil(m_fp64 - (m_fp32 - math.log2(k)) / 2 ) xi = m_fp64 - m_type2 rho = max (gamma, xi) slices = [] residual = x.clone().to(torch.float64) for _ in range (max_slices): max_abs = residual.abs().max().item() if max_abs == 0 or max_abs < 1e-300 : break c_x = math.ceil(math.log2(max_abs)) # 式(1) sigma = 0.75 * math.ldexp( 1.0 , rho + c_x) # 式(2) v = (residual + sigma) - sigma # 式(3) Veltkamp分割 residual = residual - v # 式(4) 残差更新 scale = math.ldexp( 1.0 , c_x) slice_type2 = (v / scale).to(type2) # 式(5) 正規化 + Type2変換 slices.append((slice_type2, scale)) return slices # [(Type2スライス, 2^c_x), ...] 行列積の計算 行列 $\boldsymbol{x}$, $\boldsymbol{y}$ をそれぞれ分解すると、行列積は以下のように展開できます。 $$\boldsymbol{x}^T \boldsymbol{y} = \sum_{p=1}^{s_x} \sum_{q=1}^{s_y} 2^{c_x^{(p)} + c_y^{(q)}} \cdot \bar{\boldsymbol{x}}^{(p)T} \bar{\boldsymbol{y}}^{(q)} \tag{10}$$ 各 $\bar{\boldsymbol{x}}^{(p)T} \bar{\boldsymbol{y}}^{(q)}$ はType2行列同士の積であり、Tensor CoreのGEMMで計算できます。Ozaki Schemeではρパラメータにより、このGEMMのType3（FP32）での累積が丸め誤差なしで成立するよう設計されています。 $$\bar{\boldsymbol{x}}^{(p)T} \bar{\boldsymbol{y}}^{(q)} = \text{fl}_{\text{Type3}} \left( \bar{\boldsymbol{x}}^{(p)T} \bar{\boldsymbol{y}}^{(q)} \right) \tag{11}$$ 式10の分解自体は数学的な恒等式として厳密に成立します。実装上は、外側の累積（スケール乗算と加算）をType1算術で行うことでType1精度を達成できます。 cuTileでの行列積カーネルの実装は以下の通りです。tilegymのmatmulカーネルとベースは同じで２つのスライス分のouter-loopが追加されています。 @ ct.kernel (num_ctas=ct.ByTarget(sm_100= 2 )) def ozaki_matmul_fused_kernel ( A_slices, # (s_a, M, K) Type2スライス B_slices, # (s_b, K, N) Type2スライス Combined_scales, # (s_a, s_b) 2^{c_x(p)+c_y(q)} のスケール行列 C, # (M, N) FP64 出力 TILE_SIZE_M: ConstInt, TILE_SIZE_N: ConstInt, TILE_SIZE_K: ConstInt, ): # タイルインデックス計算（L2キャッシュ局所性のためswizzle） bidx, bidy = swizzle_2d(M, N, TILE_SIZE_M, TILE_SIZE_N, GROUP_SIZE_M= 8 ) num_tiles_k = ct.cdiv(K, TILE_SIZE_K) # FP64最終アキュムレータ（式10の外側の累積） accumulator = ct.full((TILE_SIZE_M, TILE_SIZE_N), 0.0 , dtype=ct.float64) # 全スライスペア (p, q) をループ for p in range (num_slices_a): for q in range (num_slices_b): # FP32中間アキュムレータ（式11: Type3での丸め誤差なし計算） slice_acc = ct.full((TILE_SIZE_M, TILE_SIZE_N), 0.0 , dtype=ct.float32) # K方向のタイルループ for k in range (num_tiles_k): a_tile = ct.load(A_slices, index=(p, bidx, k), ...) b_tile = ct.load(B_slices, index=(q, k, bidy), ...) slice_acc = ct.mma(a_tile, b_tile, slice_acc) # Type2 Tensor Core MMA # スケーリングしてFP64で累積（式10） scale = ct.load(Combined_scales, index=(p, q), shape=( 1 , 1 )) accumulator = accumulator + ct.astype(slice_acc, ct.float64) * scale ct.store(C, index=(bidx, bidy), tile=accumulator) 素朴な実装と初回結果 上記のようにOzaki Schemeを実装してみます。スライス分割はホスト側のpythonで行い、各ペアのGEMMを順次実行する方式です。以下、2種類のType2で行列積を計算した結果です。 スライス数はA・Bそれぞれの分割数（$s_a \times s_b$）、GEMMsはその組み合わせで実行したGEMM回数です。TFLOPSはFP64換算のスループット、Rel ErrorはPyTorch FP64結果を基準とした相対誤差です。 TYPE2 = FP16 行列サイズ スライス数 GEMMs Split(ms) Kernel(ms) 合計(ms) TFLOPS Rel Error 1024 10×10 100 1.48 0.62 2.64 0.81 1.58e-15 2048 12×12 144 2.57 2.66 5.75 2.99 1.98e-15 4096 12×12 144 8.69 21.59 30.70 4.48 6.31e-15 8192 14×14 196 36.00 192.32 231.76 4.74 7.28e-15 16384 14×14 196 135.21 1737.14 1884.24 4.67 3.35e-15 TYPE2 = FP8 (E4M3) 行列サイズ スライス数 GEMMs Split(ms) Kernel(ms) 合計(ms) TFLOPS Rel Error 1024 15×16 240 2.22 1.11 4.03 0.53 1.64e-15 2048 16×16 256 3.48 3.11 7.33 2.34 2.27e-15 4096 16×17 272 12.30 19.17 30.86 4.45 5.69e-15 8192 17×17 289 45.64 179.99 226.64 4.85 8.88e-15 FP16はスライス数が少ない分GEMMも少なくなりますが、FP8はTensor Coreのスループットが高いため、GEMMs数が多いにも関わらず類似の性能が出ています。いずれの型でもcuTile FP64直接計算（約1 TFLOPS）を上回っていますが、PyTorchの性能には大きく劣後しています。Split処理の時間も無視できず、特に小さな行列サイズでボトルネックになっています。また、参照した論文に記載されている必要なGEMM数(スライス数）よりも多くなっている点は気になりましたが、原因はわからずでした。 最適化 初回結果を踏まえ、いくつか改善を試みました。その中で効果があった方法が以下になります。 Fast Mode（GEMMの削減） スライス数が $s$ の場合、全組み合わせで $s^{2}$ 回のGEMMが必要です。しかし、スライスインデックスが大きい組み合わせ（$i + j \geq d$）は寄与が小さいため、スキップできます。 [5]で提案されたFast Mode（Algorithm 3）では、確率的誤差限界 $|fl(AB) - AB| \leq 2\sqrt{k} \cdot u_{\text{FP64}} \cdot |A||B|$ を満たす最小の閾値 $d$ を自動決定します。 BF16の場合、典型的には $d = 9$ 程度で、GEMMは49回から39回に削減できます。さらに max_d パラメータで手動上限を設定すれば、精度とのトレードオフで計算量を調整できます。 実装としては、前述の行列積カーネルのスライスペアループに i + j >= D の条件を追加するだけです。 for i in range (num_slices_a): for j in range (num_slices_b): if i + j >= D: # Fast Mode: 寄与の小さい組み合わせをスキップ continue # ... K方向ループでMMA計算 ... Fused Split Kernel（分割の融合） 元の実装では、各スライスの計算ごとに max().item() でGPU→CPU同期が発生していました（BF16で7スライス = 7回の同期）。 改善後は、初回の max_abs 計算で1回だけ同期し、全スライスの $\sigma$ と $2^{-c_i}$（逆スケール）をCPU側で事前計算します。その後、単一カーネルで全スライスを一括計算します。 @ ct.kernel (occupancy= 4 ) def _veltkamp_split_all_slices_kernel ( x_in, # (M, N) FP64 input slices_out, # (num_slices, M, N) TYPE2 output slices sigmas, # (num_slices,) FP64 pre-computed sigma values inv_scales, # (num_slices,) FP64 pre-computed 1/scale values num_slices: ConstInt, TILE_SIZE_M: ConstInt, TILE_SIZE_N: ConstInt, ): bid = ct.bid( 0 ) # ... (タイルインデックス計算) ... # 入力タイルをロード residual = ct.load(x_in, index=(tile_m, tile_n), shape=(TILE_SIZE_M, TILE_SIZE_N), padding_mode=ct.PaddingMode.ZERO) # 全スライスをループで計算 for i in range (num_slices): sigma_tile = ct.load(sigmas, index=(i,), shape=( 1 ,)) inv_scale_tile = ct.load(inv_scales, index=(i,), shape=( 1 ,)) # Veltkamp分割 v = (residual + sigma_tile) - sigma_tile slice_tile = ct.astype(v * inv_scale_tile, slices_out.dtype) ct.store(slices_out, index=(i, tile_m, tile_n), tile=ct.reshape(slice_tile, ( 1 , TILE_SIZE_M, TILE_SIZE_N))) residual = residual - v 最適化後の結果 Fast Mode + Fused Split Kernelを適用した結果です。 TYPE2 = BF16 行列サイズ スライス数 GEMMs Split(ms) Kernel(ms) 合計(ms) TFLOPS Rel Error 1024 7×7 39 0.20 0.25 1.57 1.37 5.75e-15 2048 7×7 39 0.24 0.75 2.16 7.94 1.30e-14 4096 7×7 39 0.43 5.32 7.22 19.04 1.16e-14 8192 7×7 39 1.16 38.93 42.60 25.81 2.39e-14 16384 7×7 39 3.96 323.10 327.78 26.84 2.21e-14 TYPE2 = FP8 (E4M3) 行列サイズ スライス数 GEMMs Split(ms) Kernel(ms) 合計(ms) TFLOPS Rel Error 1024 14×14 130 0.25 0.61 2.99 0.72 3.48e-13 2048 14×14 130 1.27 1.60 6.80 2.52 3.57e-13 4096 14×14 130 2.13 9.31 15.88 8.65 3.41e-13 FP8はスライス数が多く（14×14）GEMMsも130回と多いものの、Fast ModeによるGEMM削減とFused Splitの効果で素朴な実装（4096で4.45 TFLOPS）から改善が見られます。ただしBF16と比較すると、仮数部が4ビットと少ないためスライス数が増え、GEMMs数の差（130 vs 39）がFP8のスループット優位を打ち消しており、BF16の方が総合的に有利になりました。 素朴な実装と比較すると、最適化の効果は顕著です。 Fused Split Kernel : Split時間が大幅短縮（素朴なFP16版 8192: 36.00ms → BF16最適化版: 1.16ms、約31倍） Fast Mode : GEMMsを49→39に削減（BF16の全組み合わせ比） BF16がTYPE2として最適である理由は、Tensor CoreのFP32アキュムレータとの相性にあります。BF16の仮数部は8ビットなので、2つのBF16値の積は16ビットに収まります。FP32の仮数部は24ビットあるため、TILE_SIZE_K=128個の積和（16 + log2(128) = 23 ≤ 24）が 丸め誤差なし で正確に計算できます。一方FP16（11ビット仮数部）では積が22ビットとなり、128個の累積（22 + 7 = 29 > 24）でFP32精度を超えるため、丸め誤差が発生します。 この性質により、BF16では1e-14というFP64に近い精度を維持しつつ、Tensor Coreの高いスループットを活用できています。 上記以外にも、タイルサイズの調整や、カーネル内のsplitループ方向のCTA分散も試みましたが、効果はありませんでした。本来は、プロファイラ（NVIDIA Nsight Compute）を使って、メモリ利用等解析するのが効果的ですが、Modal上ではNsightは使えないようなので断念しました。 dによる精度/速度トレードオフ d パラメータを変えて、16384×16384行列での性能と精度の変化を測定しました。BF16の結果です。 d GEMMs 合計(ms) TFLOPS Rel Error vs PyTorch FP64 9 (default) 39 327.78 26.84 2.21e-14 0.75x 8 34 298.76 29.44 2.31e-14 0.83x 7 28 238.94 36.81 3.50e-13 1.03x 6 21 189.59 46.40 4.39e-11 1.30x 5 15 136.34 64.52 4.51e-09 1.81x PyTorch FP64（cuBLAS）は同サイズで35.62 TFLOPSです。Rel ErrorはPyTorch FP64の結果を基準として計算しています。 d=7 でcuBLASと同等の速度を精度1e-13で達成し、 d=5 では1.8倍の高速化を1e-9精度で実現しています。なお、FP64 GEMM自体も浮動小数点演算の性質上、行列サイズに応じた丸め誤差は避けられないため、 d=8 （2.31e-14）程度の偏差であれば実用上十分でしょう。 まとめ cuTile Pythonの簡単な紹介とOzaki Schemeの実装を通じて、FP64行列積の高速化を試みました。BF16 Ozaki Schemeの最適化後、16384×16384行列で最大26.84 TFLOPS（d=9）を達成しました。dを調整することで精度と速度のトレードオフが可能で、d=7ではcuBLAS FP64（35.62 TFLOPS）と同等の36.81 TFLOPSを精度1e-13で達成し、d=5では64.52 TFLOPS（cuBLASの1.8倍）を1e-9精度で実現しています。 CUDAカーネルをPythonライクに書ける点で、GPUプログラミングの敷居が低くなったと感じます。 一方で、より高度な最適化やチューニングが必要な場合は、cuTile Pythonは抽象化してハード側の詳細を隠蔽している分、制約があるように感じました。今回は、行列積の例でしたが、tilegymにはtransformerの実装例があるので、次回はそちらも試してみたいと思います。 参考文献 [1] Lecture 89: cuTile (from friends at NVIDIA) [2] NVIDIA cuTile Documentation . cuTile Python. [3] NVIDIA TileGym . GPU Tile kernel development examples using cuTile. [4] Markus Höhnerbach, Paolo Bientinesi (2025). "DGEMM without FP64 Arithmetic" . arXiv:2508.00441. [5] Daichi Mukunoki, Katsuhisa Ozaki, Takeshi Ogita, and Toshiyuki Imamura (2020). "DGEMM using Tensor Cores, and Its Accurate and Reproducible Versions". ISC High Performance 2020, Lecture Notes in Computer Science, Vol. 12151. Springer, 230–248. doi:10.1007/978-3-030-50743-5_12

本記事は 2026 年 2 月 10 日 に公開された「 Set up LucidLink with service managed fleet scripts for AWS Deadline Cloud 」を翻訳したものです。 最新のクリエイティブワークフローでは、インフラストラクチャ管理の負荷なくオンデマンドでスケールできる高性能レンダリング機能が求められます。この課題に対して AWS Deadline Cloud のサービスマネージドフリート（SMF）を使うことで、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス管理や、OS アップデート、Virtual Private Cloud (VPC) 設定、ネットワーク設定などの複雑な管理をAWS Deadline Cloud が代行してくれるため、現場担当者はインフラストラクチャ運用ではなく、レンダリングワークロードに集中できます。 その上で、LucidLink のクラウドネイティブなハイブリッドファイルシステムを組み合わせると、クラウドとオンプレミスの両方でインフラストラクチャ管理を不要とする強力なソリューションになります。クリエイティブチームは最小限のインフラストラクチャで大規模なレンダリングを実行しつつ、どこからでもプロジェクトファイルにすぐにアクセスできます。 本記事では、AWS Deadline Cloud の SMF に LucidLink を統合する方法を紹介し、スケーラブルで高性能なレンダリングワークフローを構築するソリューションを解説します。 AWS Deadline Cloud は SMF のConfig スクリプトに対応し、LucidLink などのサードパーティストレージソリューションをレンダリングワークフローに統合しやすくなりました。Deadline Cloud 環境に LucidLink を組み合わせ、高性能でスケールアウト可能なクラウドベースのレンダリング環境をセットアップする手順をご紹介します。 前提条件 開始する前に、以下を準備ください。 以下の権限を持つ AWS アカウント : AWS Deadline Cloud のファームとフリートの作成・管理 AWS Secrets Manager シークレットの作成・読み取り AWS Identity and Access Management (IAM) ロールとポリシーの変更 認証情報を設定済みの AWS Command Line Interface ( AWS CLI ) pip がインストールされた Python 3 (Deadline Cloud CLI ツール用) 以下を満たす LucidLink アカウント : 有効な認証情報 (ユーザー名とパスワード) 作成済みの Filespace と Workspace Filespace 名と Workspace 名の把握 AWS Deadline Cloud の基本的な概念と用語の理解 この例では、ジョブ実行フローで以下を行います。 ① 管理者権限で LucidLink をインストール ② ジョブ実行前にレンダーノードに適切な LucidLink Filespace をマウント ③ ジョブ完了時に LucidLink Filespace をアンマウント ④ Filespace への接続を検証するカスタムジョブを作成/実行 レンダリングライフサイクルにおいて、この 4 つのタッチポイントを使用します。 図 1. AWS Deadline Cloud と LucidLink の統合ワークフロー 構築する内容 このチュートリアルを完了すると、以下の環境が構築されます。 LucidLink 対応フリートを備えた Deadline Cloud ファーム SMF Config スクリプトによる LucidLink クライアントの自動インストール ジョブごとにファイルシステムを動的にマウントする OpenJD ジョブテンプレート ステップ 1: LucidLink の認証情報を AWS Secrets Manager に保存する AWS Secrets Manager を使用して LucidLink の認証情報を安全に保存します。その認証情報は、レンダリングジョブが LucidLink ファイルシステムをマウントする際に取得されます。 AWS Secrets Manager コンソールを開く [新しいシークレットを保存する] をクリック [その他のシークレットのタイプ] を選択 以下のキーと値のペアを追加: {   "username": "your-lucidlink-username",   "password": "your-lucidlink-password" } シークレット名: lucidlink-credentials 作成プロセスを完了 ステップ 2: Deadline Cloud ファームをセットアップする レンダリングワークロードをホストする Deadline Cloud ファームを作成します。 AWS Deadline Cloud コンソールに移動 ファームを作成 をクリック ファーム設定を構成: ファーム名: lucidlink-render-farm ファームを作成 をクリック ステップ 3: LucidLink 対応のSMFを作成する ステップ 3a: LucidLink インストール設定スクリプトを作成する フリートインスタンスに LucidLink クライアントをインストールする設定スクリプトを作成します。このスクリプトはインストールとデーモンのセットアップのみを行います。フリートにデプロイする前に、スタンドアロンの EC2 インスタンスでスクリプトが正しく動作することをテストしてください。 <p>#!/bin/bash # LucidLink Client Installation Script # This script only installs the LucidLink client and sets up the daemon service # Filesystem mounting is handled separately via OpenJD job templates set -ex # -----------------------------Install tree utility----------------------------- # Install tree for directory visualization yum install tree -y # ----------------------Install and configure LucidLink 3----------------------- echo "Installing LucidLink client..." # Download latest stable LucidLink RPM package wget -q https://www.lucidlink.com/download/new-ll-latest/linux-rpm/stable/ -O lucidinstaller.rpm<br />ls -l lucidinstaller.rpm # Install the LucidLink client yum install -y lucidinstaller.rpm # Create systemd service for persistent daemon echo "Creating systemd service for LucidLink daemon..." cat << EOF > /etc/systemd/system/lucidlink.service [Unit] Description=LucidLink Filespace Daemon After=network-online.target Wants=network-online.target [Service] Type=simple ExecStart=/usr/local/bin/lucid3 daemon ExecStop=/usr/local/bin/lucid3 exit Restart=on-failure RestartSec=5 User=root Group=root [Install] WantedBy=multi-user.target EOF # Enable and start the LucidLink daemon service echo "Enabling and starting LucidLink daemon service..." systemctl daemon-reload systemctl enable lucidlink systemctl start lucidlink # Create base mount directory with proper permissions echo "Creating mount point..." mkdir -p /mnt/lucid <br />chmod a+rwx /mnt/lucid # Verify installation echo "LucidLink client installation complete" lucid3 status 次に、LucidLink 設定スクリプトを使用してフリートを作成します。 Deadline Cloud ファームページのフリートタブへ移動して フリートを作成 をクリック フリートの詳細を定義 セクション: フリート名: lucidlink-render-fleet フリートタイプ: サービスマネージド 次へ をクリック ワーカー機能 セクション: CPU または GPU インスタンスを選択 オペレーティングシステム: Linux 次へ  をクリック 追加の設定を行う – オプション セクション: ワーカー設定スクリプトを有効化 にチェック スクリプト内容: LucidLink 設定スクリプトを貼り付け ステップ 4: LucidLink マウント用のキュー環境（Queue Environment ）を作成する ステップ 4a: LucidLink ジョブキューを作成する Deadline Cloud ファームページのキュータブへ移動して キューを作成 をクリック 基本設定を構成: 名前: lucidlink-queue ジョブアタッチメントのバケット名 : lucidlink-attachments フリートを関連付ける – オプション: lucidlink-render-fleet キューを作成 をクリック ユーザーがレンダリングジョブを送信できるジョブキューが作成され、先ほど作成したレンダーフリートが使用されます。 ステップ 4b: キューの IAM ロール権限を更新する キューが使用している IAM ロールを確認し、Secrets Manager のシークレットへのアクセス権限を追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:*:*:secret:lucidlink-credentials*" } ] } Queue Environment を使用すると、特定のキューでジョブが開始されるたびに Deadline Cloud でカスタムスクリプトを実行できます。この例では、ジョブ実行中の 2 つのタイミングで Bash スクリプトを実行します。 ジョブ開始時 (Queue Environment - Enter) ジョブ完了後 (Queue Environment - Exit) Queue Environment では、parameterDefinitions を通じてユーザーにパラメータを公開できます。ここでは、以下の設定を変更可能にし、デフォルト値も設定しています。 Lucid Secret Name (Secrets Manager に保存したシークレット名) LucidLink の Workspace と Filespace Open Job Description YAML では次のようになります。 parameterDefinitions: - name: LucidSecretName type: STRING description: AWS Secrets Manager secret name containing LucidLink credentials default: lucidlink-credentials - name: LucidWorkspace type: STRING description: LucidLink workspace name to mount userInterface: control: LINE_EDIT label: Workspace Name default: lucid-workspace - name: LucidFilespace type: STRING description: LucidLink filespace name to mount userInterface: control: LINE_EDIT label: Filespace Name default: lucid-filespace Queue Environment Enter 時 #!/bin/bash # Exit on error, undefined vars, pipe failures set -euo pipefail echo "Mounting LucidLink filesystem..." # Create mount point directory MOUNTPOINT="/mnt/lucid/{{Param.LucidWorkspace}}/{{Param.LucidFilespace}}" mkdir –p ${{MOUNTPOINT}} # Get credentials from AWS Secrets Manager SECRET=$(aws secretsmanager get-secret-value \ --secret-id "{{Param.LucidSecretName}}" \ --query 'SecretString' --output text) # Parse credentials from JSON LUCID_USERNAME=$(echo "$SECRET" | jq -r '.username') LUCID_PASSWORD=$(echo "$SECRET" | jq -r '.password') # Mount filesystem echo "${LUCID_PASSWORD}" | lucid3 link \ --fs "{{Param.LucidFilespace}}.{{Param.LucidWorkspace}}" \ --user "${LUCID_USERNAME}" \ --mount-point "${MOUNTPOINT}" \ --fuse-allow-other # Verify mount is accessible if [ -d "${MOUNTPOINT}" ] && [ "$(ls -A ${MOUNTPOINT})" ]; then echo "Mount verification successful" else echo "Warning: Mount point appears empty or inaccessible" exit 1 fi Queue Environment Exit 時 echo "Unmounting LucidLink filesystem..." lucid3 unlink --fs "{{Param.LucidFilespace}}.{{Param.LucidWorkspace}}" || true echo "LucidLink filesystem unmounted" これらをまとめて 1 つの Open Job Description 環境にすると、Deadline キュー で使用できます。 specificationVersion: 'environment-2023-09' parameterDefinitions: - name: LucidSecretName type: STRING description: AWS Secrets Manager secret name containing LucidLink credentials default: lucidlink-credentials - name: LucidWorkspace type: STRING description: LucidLink workspace name to mount userInterface: control: LINE_EDIT label: Workspace Name default: lucid-workspace - name: LucidFilespace type: STRING description: LucidLink filespace name to mount userInterface: control: LINE_EDIT label: Filespace Name default: lucid-filespace environment: name: LucidLinkMount description: Environment for mounting LucidLink filesystem script: actions: onEnter: command: "{{Env.File.MountLucidLink}}" onExit: command: "{{Env.File.UnmountLucidLink}}" embeddedFiles: - name: MountLucidLink type: TEXT runnable: true data: | #!/bin/bash # Exit on error, undefined variables, and pipe failures set -euo pipefail   echo "Mounting LucidLink filesystem..." # Create mount point directory MOUNTPOINT="/mnt/lucid/{{Param.LucidWorkspace}}/{{Param.LucidFilespace}}" mkdir -p "${MOUNTPOINT}"   # Get credentials from AWS Secrets Manager SECRET=$(aws secretsmanager get-secret-value \ --secret-id "{{Param.LucidSecretName}}" \ --query 'SecretString' --output text)   # Parse credentials from JSON LUCID_USERNAME=$(echo "$SECRET" | jq -r '.username') LUCID_PASSWORD=$(echo "$SECRET" | jq -r '.password')   # Mount filesystem echo "${LUCID_PASSWORD}" | lucid3 link \ --fs "{{Param.LucidFilespace}}.{{Param.LucidWorkspace}}" \ --user "${LUCID_USERNAME}" \ --mount-point "${MOUNTPOINT}" \ --fuse-allow-other   # Verify mount is accessible if [ -d "${MOUNTPOINT}" ] && [ "$(ls -A ${MOUNTPOINT})" ]; then echo "Mount verification successful" else echo "Warning: Mount point appears empty or inaccessible" exit 1 fi - name: UnmountLucidLink type: TEXT runnable: true data: | echo "Unmounting LucidLink filesystem..." lucid3 unlink --fs "{{Param.LucidFilespace}}.{{Param.LucidWorkspace}}" || true echo "LucidLink filesystem unmounted" AWS Deadline Cloud にロードするには、対象のキューを選択し、「Queue Environments」タブに移動します。 図 2. AWS Deadline Cloud のQueue Environmentsテーブル Actions から Create New from YAML を選択し、Queue Environmentsスクリプトを貼り付けます。 図 3. AWS Deadline Cloud のQueue Environments編集ページ ステップ 5: セットアップをテストする 図 4. 完了した AWS Deadline Cloud タスクの実行 LucidLink の統合を検証するため、AWS Deadline Cloud CLI でテストジョブを作成して送信します。 Deadline Cloud CLI のインストール まず、Deadline Cloud CLI ツールをインストールします: pip install 'deadline[gui]' Deadline Cloud Monitor のインストール Deadline Cloud Monitor はジョブの認証とモニタリングに必要です。AWS Deadline Cloud コンソールからダウンロードしてインストールします。 AWS Deadline Cloud コンソールに移動 サービスページに移動 お使いのオペレーティングシステム用の Deadline Cloud Monitor をダウンロード 表示される手順に従ってインストール テストジョブテンプレートの作成 LucidLink ファイルシステムが正しくマウントされアクセス可能であることを確認する基本的な OpenJD ジョブテンプレートを作成します。以下の内容を新しいディレクトリに template.yaml として保存します。 specificationVersion: 'jobtemplate-2023-09' name: Test LucidLink Mount steps: - name: Print Tree of LucidLink Mount script: actions: onRun: command: '{{Task.File.runScript}}' embeddedFiles: - name: runScript type: TEXT runnable: true data: | #!/usr/bin/env bash set -ex tree --du -h -L 6 /mnt/lucid テストジョブを送信してモニタリングします。 以下のいずれかの方法でテストジョブを送信します。 コマンドラインでの送信: deadline bundle submit --farm-id <farm-id> --queue-id <queue-id> <bundle-directory> GUI での送信 (パラメータのカスタマイズが可能): deadline bundle gui-submit <directory-name> 統合の検証 ジョブが完了したら、LucidLink ファイルシステムが正常にマウントされたことを確認します。 Deadline Cloud Monitor アプリケーションを開く ジョブリストからテストジョブを見つける ログを表示 をクリックしてジョブ出力を確認 ログに LucidLink マウントポイント /mnt/lucid のディレクトリツリー構造が表示されていることを確認 テストが成功すると、LucidLink Filespace の完全なディレクトリ階層が表示され、ジョブ実行中にファイルシステムが正しくマウントされアクセス可能であることが確認できます。 考慮事項 このモジュラーアーキテクチャはインストールとマウントを分離しており、ジョブごとに異なるファイルシステム設定を使用できます。LucidLink デーモンは systemd サービスとして実行されジョブ実行間で永続化されます。マウントポイントには chmod 755 権限と --fuse-allow-other フラグが必要です。認証情報は AWS Secrets Manager から安全に取得され、OpenJD テンプレートがマウントとアンマウントを自動的に処理してリソースを適切に管理します。フリートにデプロイする前に、必ずスタンドアロンの EC2 インスタンスで設定スクリプトをテストしてください。 トラブルシューティング セットアップやジョブ実行で問題が発生した場合は、まず AWS Deadline Cloud コンソールでフリート設定スクリプトのログを確認し、LucidLink クライアントが正しくインストールされたことを検証します。マウントの問題については、失敗したタスクを右クリックして「View Worker Logs」を選択し、デーモンが実行中であることを確認してから、ジョブ固有のログでファイルシステムアクセスエラーを確認します。権限の問題は通常、フリートの IAM ロールに Secrets Manager シークレットへのアクセス権がないか、マウントポイントの権限調整が必要であることを示しています。テンプレート関連の問題は、本番ワークロードを送信する前に、OpenJD YAML構文の検証とDeadline Cloud CLIによるジョブテンプレートのテストによって特定できます。 クリーンアップ Deadline Cloud と LucidLink の使用を中止する場合は、AWS Deadline Cloud コンソールでフリートとキューを削除します。テスト用の EC2 インスタンスを作成した場合は、EC2 コンソールから終了します。不要になった場合は、LucidLink の認証情報を含む AWS Secrets Manager シークレットも削除してください。 まとめ LucidLink のインストールとファイルシステムのマウントを分離することで、柔軟でメンテナンスしやすい構成を実現できます。サービスマネージドフリートが 1 回限りのクライアントインストールを処理し、OpenJD ジョブテンプレートがジョブごとのファイルシステムマウントを管理することで、以下のメリットが得られます。 モジュール性: ジョブごとに異なるファイルシステムや設定をマウント可能 リソース効率: ファイルシステムは必要なときだけマウントされ、自動的にアンマウント セキュリティ: 認証情報はジョブ環境内で安全に処理 信頼性: インストールとマウントの両フェーズで適切なエラー処理とクリーンアップ このアーキテクチャは、セキュリティのベストプラクティスを維持しつつ運用を効率化し、レンダリングワークフローに高性能な共有ストレージを提供します。LucidLink のグローバルファイルシステムと AWS Deadline Cloud のスケーラブルなレンダリングインフラストラクチャを組み合わせることで、クリエイティブチームは地理的な境界を越えてシームレスにコラボレーションできます。 AWS の担当者 に問い合わせて、ビジネスの加速を支援する方法をご確認ください。 関連情報 AWS Deadline Cloud のサービスマネージドフリートと設定スクリプトの詳細は、 AWS Deadline Cloud ドキュメント を参照してください。Open Job Description (OpenJD) の詳細は、 OpenJD specifications GitHub ページ または OpenJD ドキュメントページ を参照してください。 LucidLink について LucidLink は、クリエイティブチームがどこからでも協力して作業できるストレージコラボレーションプラットフォームです。ゼロ知識暗号化で保護された単一の共有 Filespace で、あらゆる規模のプロジェクトに即座に安全にアクセス、編集、共有できます。詳しくは LucidLink on AWS をご覧ください。 著者について Zach Willner AWS のメディア & エンターテインメント担当シニアパートナーソリューションアーキテクトです。AWS 上のメディア & エンターテインメント向けパートナーエコシステムの構築に取り組んでいます。 DJ Rahming AWS のビジュアルコンピューティング担当シニアソリューションアーキテクトです。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語)  AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。