RTX SparkはWindowsノートにもCUDA対応GPUを載せる一方、CPUはArmです。従来のx64向けCUDAアプリを使う開発者には、「アプリが起動するか」「GPU側のコードが動くか」「メモリをどう数えるか」という別の確認項目があります。NVIDIAの移植ガイドとMicrosoftのArm64EC資料をもとに、最初に押さえたい手順を整理します。

x64アプリの互換性とCUDAの実行は別に確認する

NVIDIAのWindows on Arm移植ガイドによると、多くのx86・x64アプリはMicrosoft Prismのエミュレーションを通じて動作できます。ただしアプリと依存ライブラリごとに互換性は異なります。Prismが変換するのはCPU命令で、GPUのデバイスコードはRTX Sparkの統合GPU上でネイティブに実行されます。x64の実行ファイルが立ち上がることと、必要なCUDAライブラリや拡張機能がそろい、期待する速度で動くことは別の確認です。

まず既存アプリの実行ファイル、Python環境、CUDAを使うライブラリ、プラグインを列挙します。各要素にWindows on Arm向けの配布物があるか、x64版をPrism上で使う必要があるかを調べます。GPU機能を使う短い推論や計算を実機で通し、CPU側の前処理も計測すれば、互換性と速度の問題を分けられます。NVIDIAもエミュレーションで動くことを前提にするだけでなく、対象構成の検証を勧めています。

ARM64とARM64EC、ビルド先の選び方

MicrosoftのArm64EC資料では、Arm64ECで作ったコードは同一プロセス内のエミュレーションされたx64コードと共存できます。Arm64EC部分はArm上でネイティブに動き、移行前のx64依存部分を残せる仕組みです。対して通常のARM64ビルドは、純粋なArmネイティブ構成を目指す選択肢です。Arm64ECと通常のARM64はABIが異なるため、同じプロセスへ無条件に混ぜて使うものではありません。

NVIDIAのビルド手順は、CMakeのVisual Studioジェネレーターで対象を明示する例を挙げています。ネイティブARM64なら cmake .. -A ARM64、x64コードと共存するArm64ECなら cmake .. -A ARM64EC です。明示しない場合、開発用ホストのx64がビルド対象に選ばれることがあります。Visual Studio 2026からクロスコンパイルする手順では、Windows 11 SDKとARM64/ARM64ECのMSVCビルドツールを用意します。

NVIDIAのガイドには、CUDAサンプルのvectorAddやcuBLASサンプルをx64ホストからARM64向けにビルドし、Arm実機へコピーして動かす例もあります。既存の大きなアプリ全体を一度に移す前に、これらの小さな計算でコンパイラ、ランタイム、GPUドライバーの組み合わせを確かめる進め方ができます。Pythonなど上位の環境を使う場合も、下で読み込むバイナリのアーキテクチャまで追うことが大切です。

128GBの統合メモリはすべてをGPUへ割り当てられるか

RTX SparkはCPUとGPUが同じ物理メモリを使う統合メモリ設計です。ただし、NVIDIAのCUDA APIガイドは、Windows上でGPU専用の領域とCPU・GPUが共有する領域に予算が分かれることを説明しています。GPU専用領域も独立したVRAMチップではなくシステムDRAMの一部です。製品に128GBを搭載していても、モデル重み、作業領域、OS、アプリへ同時に好きなだけ割り当てられるわけではありません。

GPUが主に使う重みや中間バッファには、ガイドは cudaMalloc または cudaMallocAsync を推奨します。割り当てはまずGPU専用領域を使い、空きがなくなると共有領域へ移ります。CPUとGPUが同じ入力・出力を参照する場面には cudaMallocHost が選択肢です。キャッシュの条件まで調整する場合は、Windowsの VirtualAlloc2 と cudaHostRegister を組み合わせる方法も示されています。名称に「Unified」が入るからといって、既存コードの cudaMallocManaged を標準手段にするのは適切ではありません。NVIDIAはこの機種では互換経路となり性能が落ち得るため、使用を避けるよう記しています。

残量表示にも違いがあります。cudaMemGetInfo は専用領域と共有領域を通じて、cudaMalloc に使える予算の目安を返します。CPU・GPUが共用するバッファは共有領域に制約されるため、この返り値をすべて使えるとは解釈できません。一方、NVMLの nvmlDeviceGetMemoryInfo_v2 は専用領域だけを示し、共有領域は含みません。Windowsの QueryVideoMemoryInfo では統合GPUの両領域がローカル側に入るため、従来の独立GPUで使っていた「共有は非ローカル」という前提も見直します。

メモリ予算はWindowsの状態や他アプリの使用量で変わります。NVIDIAは予算を使い切らず、変化を受け取る通知を利用する設計も案内しています。大きなLLMを載せるときは、重みだけでなくKVキャッシュ、作業領域、ホスト側の余白を含めて実機で測ります。モデル規模とメモリの見方はローカルLLMの記事にまとめました。

まとめ

RTX SparkでCUDAを使う準備は、CPU側のWindows on Arm互換性、ARM64またはArm64ECのビルド、GPUと共有メモリの予算確認という順に進めると整理しやすくなります。Prism下でもGPUコードはネイティブに動きますが、アプリ全体の動作と速度は依存部品を含めた実機確認が必要です。まず小さなCUDAサンプルで環境を確かめ、実際のモデルや制作アプリへ広げるのが現実的です。