Surface Laptop Ultra の初期設定。ARM の Windows で GPU が使えるかは、道具ごとに入れる前に確かめる
!
先に、この記事の要約
ARM の CPU と NVIDIA の GPU が 1 つのチップに入った Windows のノート PC を、AI を動かす用に初期設定した。その手順と、それぞれを選んだ理由を書く
GPU に回すメモリーの量は設定で決まる。初期値は 62.5GB で、95.5GB にした
GPU が使えるかは、道具ごとに違った。Ollama は入れるだけで GPU で動き、35B のモデル（Qwen3.6-35B-A3B）も 1 秒に約 100 トークンで動いた。PyTorch は ARM の Windows 向けの GPU 版が公式には配られておらず、入るのは CPU だけで動く版だった
そこで PyTorch の GPU 版を、公開されている手順で自分でビルドした。約 1 時間で終わり、GPU で動いた。行列の掛け算は CPU の約 100 倍、小さい言語モデルの文の生成は約 7 倍の速さだった。途中で詰まった 4 か所と直し方も書く
WSL2 の中なら、公式の Linux 向けの PyTorch がそのまま入り、GPU で動いた。GPU の速さはビルドしたものと同じくらいだった。CPU は、行列積では WSL2 が約 4 倍速く、言語モデルの生成では逆に Windows が約 2 倍速かった
道具を入れる前に「ARM の Windows 向けの GPU 版があるか」を配布物の一覧で確かめ、入れたあとは GPU で動いているかをコマンドで確かめる。その確かめ方を最後にチェックリストにした
初期設定だけを知りたいなら 1 節、ARM の Windows で GPU が使えるかの確かめ方なら 2 節とチェックリストを読めば足りる。PyTorch を GPU で動かしたいが、ビルドはしたくないなら、3 節の終わりの「WSL2 なら、公式の PyTorch が GPU で動いた」へ進んでほしい。
いまの PC は Intel の内蔵 GPU（Arc 140V）で、メモリー 32GB を CPU と共有している。GPU に回す量は設定で変えられる。手元のプロジェクトの多くが「メモリーに載らない」「CUDA が無い」で止まっていた。新しい Surface Laptop Ultra は、ARM の CPU と NVIDIA の RTX Spark の GPU が、128GB のメモリーを共有すると聞いて買った。
届く前に、海外のレビューを読んでいた。たとえば StorageReview のレビューでは、gpt-oss:20b と Qwen3.6-35B-A3B が 1 秒に 58〜89 トークンで動いていた。一方で、CPU の全コアで倍精度の重い計算を続けると電源が落ちた、という報告もあった（同じレビューで 2 台とも）。
レビューの数字は、整った環境で測ったものである。自分の手元で、何もない状態からどこまで行けるかは別の話になる。届いてから翌日までに、AI を動かす用の初期設定をして、何が GPU で動くかを確かめた。いちばん長い負荷は、全コアで約 1 時間かかった PyTorch のビルドだったが、電源が落ちることはなかった（CPU の温度は高くなったので、途中で電源モードを下げた）。
1. 初期設定の手順と、選んだ理由
復元せず、新しい PC として設定する
初期設定では「PC バックアップからの復元」を勧められたが、新しい PC として設定した。復元で来るのは x64 の PC で使っていたアプリの一覧で、ARM では動かないものが混ざる。ARM64 版を 1 つずつ入れれば、どれが ARM のまま動いて、どれが動かないかを見分けやすい。
更新と電源
Windows Update を「最新の状態」になるまで繰り返した
電源モードを「最適なパフォーマンス」にした（以下の数字はこの設定で測った。PyTorch のビルドの途中だけ「バランス」に下げた）
NVIDIA App は最初から入っていた。アプリを更新し、ドライバーは Studio 617.42 を入れた（Game Ready も同じ番号だった）
GPU に回すメモリーを決める
CPU と GPU がメモリーを共有するので、そのうちどれだけを GPU 用にするかを決める。NVIDIA App の「システム」→「詳細設定」に「専用 GPU メモリ」の項目があり、初期値は 62.5GB だった。（上のレビューでは初期値を 64GB としていた。手元の表示は 62.5GB だった）
スライダーの最大は 96GB である。ただ、最大まで動かすと「最小値や最大値はシステムを不安定にするおそれがある」という趣旨の警告が出た。95.5GB にすると警告が消えたので、そこにした。
反映されたかは、2 か所で確かめた。
タスクマネージャー：専用 GPU メモリーが 95.5GB、Windows 側のメモリーが 31GB
nvidia-smi：GPU のメモリーが 97792MiB（＝95.5GB）
GPU を広く取るほど、Windows とふつうのアプリが使える分は減る。大きいモデルを載せたいなら広く、ふつうの作業が多いなら狭く、と用途で変えることになりそうだ。
何が届いたかを記録する
確かめるためのコマンドを PowerShell のスクリプト 1 本にまとめ、Windows の「近距離共有」で Surface へ送って実行した。
項目
値
OS
Windows 11 Pro、10.0.28000、ARM64
CPU の名前（Win32_Processor）
NVIDIA RTX Spark N1X (6144-core GPU, 20-core CPU)
論理プロセッサ
20
GPU
NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU)
NPU
NVIDIA NPU（GPU と同じドライバー）
nvidia-smi
617.42、CUDA UMD Version 13.4
Python
入っていない（出荷時）
WSL
入っていない（出荷時）
nvidia-smi は、x64 の PC と同じように動いた。出力の一部を載せる（Bus-Id は伏せた）。
| NVIDIA-SMI 617.42 KMD Version: 617.42 CUDA UMD Version: 13.4 |
| 0 NVIDIA RTX Spark N1X (61... WDDM | ... On | N/A |
| N/A 41C P8 1W / N/A | 956MiB / 97792MiB | 2% Default |
| 1 NVIDIA NPU MCDM | N/A Off | N/A |
| N/A 41C N/A 1W / N/A | Not Supported | 0% N/A |
見慣れた「CUDA Version」ではなく、「KMD Version」と「CUDA UMD Version」が並んでいる。NPU も別のデバイスとして出ていた。
このスクリプトは、最初は文字化けで止まった。コメントに日本語を入れて BOM なしの UTF-8 で保存していたのを、Windows PowerShell 5.1 が Shift-JIS として読み、改行ごと化けて「引数が null であるため、パラメーター FilePath にバインドできない」という趣旨のエラーになった。コメントを英数字だけにしたら通った。ARM とは関係なく、Windows PowerShell 5.1 で日本語入りのスクリプトを動かすと起きることである。調べた範囲では、BOM 付きで保存しても避けられるようだ。
Python は、winget のソースを指定して入れる
Python は出荷時に入っていなかった。winget で ARM64 版を入れようとしたら、Microsoft Store のソースで証明書のエラーになった。
0x8a15005e : サーバー証明書が、予期された値のいずれにも一致しませんでした。
-s winget を付けて winget のソースを指定したら入った（中身は python.org の ARM64 版のインストーラーだった）。
winget install Python.Python.3.13 -a arm64 -s winget
py -3.13 -c "import sys, platform; print(platform.machine(), sys.version)"
ARM64 3.13.15 ... [MSC v.1944 64 bit (ARM64)]
版を 3.13 にしたのは、次に入れる PyTorch の ARM の Windows 向けが 3.11〜3.13 しか無いからである。Python の版は、使いたいライブラリの配布物に合わせて決めた。 この PC で 3.14 以降を入れていたら、PyTorch は CPU 版も入らなかったことになる。
2. 入れる前に、GPU 版があるかを確かめる
PyTorch：配布物の一覧に win_arm64 があるか
pip で入れるライブラリは、配布物の一覧を見れば、どの OS と CPU 向けがあるかが分かる。PyTorch なら、CPU 版・CUDA 13.0 版のように、版ごとの一覧が公開されている。ファイル名の末尾が ARM の Windows 向けなら win_arm64、x64 の Windows 向けなら win_amd64 である。
一覧のページを取って数えれば足りる。
curl -s download.pytorch.org | grep -c win_arm64 # 27
curl -s download.pytorch.org | grep -c win_arm64 # 0
見た結果はこうだった。
ARM の Windows 向けの torch は、CPU 版だけだった。いちばん新しいのは 2.14.1+cpu で、Python は 3.11・3.12・3.13 の 3 つ。x64 の Windows 向けには 3.15 まである
CUDA 版の一覧（cu126・cu128・cu130・cu132）には、win_arm64 が 1 つも無かった。ARM 向けの CUDA 版は Linux（aarch64）向けだけだった（cu130・cu132 で確かめた）
入らない見込みだったが、実機でも確かめた。仮想環境を作り、その中で CUDA 版を指定すると、やはり見つからない。
> py -3.13 -m venv $env:USERPROFILE\surface-check
> & $env:USERPROFILE\surface-check\Scripts\Activate.ps1
> pip install torch --index-url download.pytorch.org
ERROR: Could not find a version that satisfies the requirement torch (from versions: none)
ERROR: No matching distribution found for torch
CPU 版は入り、GPU は見えない。
> python -c "import torch; print(torch.version, torch.cuda.is_available())"
2.14.1+cpu False
公式の配布物で、Windows のまま CUDA の PyTorch を入れることは、いまはできない。 GPU もドライバーも CUDA も揃っているのに、PyTorch の側が ARM の Windows 向けの CUDA 版を配っていない。PyTorch の本体には、ARM の Windows で CUDA を使えるようにする変更（#190448）が出ているが、まだ取り込まれていない。
No matching distribution found は、ネットワークや pip の設定の問題に見えることがある。この PC では、配っていないからそう出た。先に一覧を見ておけば、エラーの原因を探さずに済む。
なお、CPU 版で 4096×4096 の行列積を 10 回すると、8.26 秒かかった（1 回目の呼び出しも含む）。1 秒あたり約 0.17 兆回の計算になる。この数字は、3 節で GPU と比べる。
公式に無いときの道は 2 つある。WSL2 の中で Linux の ARM 版を使うか、自分でビルドするかである。まずビルドを試し、そのあと WSL2 も試した（3 節の終わり）。
Ollama：配布物の大きさでは判断できなかった
Ollama の Windows 向けの配布物（GitHub のリリース）を見ると、ARM64 版の zip は約 210MB で、x64 版（約 1.5GB）よりずっと小さい。x64 版との差は CUDA のライブラリの分ではないか、ARM64 版は GPU を使わないのではないか、と予想していた。
この予想は外れた。 winget で入れて（管理者ではない普通の権限で）、小さいモデルを動かした。
> winget install Ollama.Ollama -s winget
> ollama run gemma3:1b "こんにちは"
こんにちは！何かお手伝いできることはありますか？ 😊
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT RUNNER UNTIL
gemma3:1b 97558784bdc9 1.0 GB 100% GPU 32768 llamacpp 4 minutes from now
設定は何もしていないのに 100% GPU と出た。配布物の大きさのような間接の手がかりでは、GPU を使うかは分からなかった。入れられるものは、入れて確かめるほうが早い。
3. 公式に無ければ、自分でビルドする
使った手順
ai-toolkit-spark-wheels は、RTX Spark の ARM の Windows でそのまま動く CUDA 13.4 版の PyTorch などを、ソースからビルドする手順をまとめている。ビルド済みのファイルもリリースに置いてあるが、使わずに自分でビルドした。
手順のスクリプトを読むと、PyTorch には独自の差分を当てていなかった。上の #190448 の途中の版（コミットを固定してある）を、そのまま取ってきてビルドする。PyTorch の側は、PR のコードがそのままビルドされる。なお、PR はその後も更新されていて、固定されている版は最新ではない。
作ったのは PyTorch と、その前提の部品（libuv）だけにした。手順にはほかに flash-attention などがあるが、今回は使わない。
手で入れたもの
手順には足りないものを調べる build.py doctor があるが、これは調べるだけで、入れはしない。前提はすべて手で入れた。ビルドのスクリプトは入れる場所を決め打ちしているので、どれも既定の場所に入れた。
必要だったもの
版・入れ方
CUDA ツールキット（ARM64・開発者向けのプレビュー）
13.4。NVIDIA のサイトから手で入れる（利用規約に同意）。ドライバーは同梱されていない
ドライバー
617.42（Studio）のまま。条件の R616 以降を満たしていた
cuDNN（ARM64）
9.25.1。NVIDIA のインストーラー版。NVIDIA の配布の一覧では、9.25.0（開発者向けのプレビュー）に ARM64 版が無く、正式版の 9.25.1 からあった
VS2022 Build Tools
17.14 系。winget で、ARM64 の C++・CMake・Windows 11 SDK を選んで入れる
Arm Performance Libraries
26.01。winget（行列計算のライブラリとして使う）
uv
0.13.4（ARM64）。winget。ビルド用の Python 3.12 を、手順のスクリプトがこれで入れる
CUDA のインストーラーは「Nsight for Visual Studio」が入らなかったと出したが、Build Tools は IDE ではないためで、ビルドには関係なかった。
手順の説明には、ビルドはメモリーを多く使うとある。いまは GPU に 95.5GB を回していて、Windows 側は 31GB しかない。そこで、ビルドの間だけ GPU に回す量を初期値の 62.5GB に戻し、試す前に 95.5GB に戻した。
詰まった所
git clone ostris/ai-toolkit-spark-wheels C:\sw
cd C:\sw
py -3.13 build.py doctor
py -3.13 build.py libuv torch
これで済めばよかったが、4 か所で手を入れた（4 つ目はビルドのあと）。
止まった・気になった所
原因
直し方
Python 用の差分が当たらない（patch does not apply）
Git for Windows の既定 core.autocrlf=true で、LF の差分のファイルが CRLF で取り出された
そのリポジトリだけ core.autocrlf false にして取り直す
サブモジュールが取れない（unable to create file）
パスが長すぎる。手順のスクリプトは core.longpaths を PyTorch 本体にしか設定しない
git config --global core.longpaths true。Windows の LongPathsEnabled を 1 にしただけでは足りなかった
CPU の温度が 99℃ 前後に張り付く（ビルドは止まっていない）
全コアのコンパイル
電源モードを「バランス」に下げたら、すぐに 90℃ 前後になった
import torch で WinError 126（shm.dll）
CUDA・cuDNN・Arm Performance Libraries の DLL が、bin の直下ではなく下のフォルダーにあり、PATH に無い
3 つのフォルダーを PATH に足す（下）
1 つ目の差分は、PyTorch ではなく別の部品のためのものだが、手順のスクリプトはビルド用の Python に必ず当てる。2 つ目で取れなかったのは、AMD の GPU 向けの部品（composable_kernel）で、これも使わないが、サブモジュールとして必ず取ってくる。クローン先を C:\sw のように短くしたのも、パスを短くするためである。
1 つ目と 2 つ目を直した 3 回目で、ビルドが通った。始めてから wheel ができるまで約 1 時間だった（手順の説明の数時間より短かった）。ディスクは約 25GB を使い、wheel は約 848MB になった。電源は最後まで落ちなかった。
torch-2.14.0.dev20260727+cu134-cp312-cp312-win_arm64.whl
GPU で動いた
新しい仮想環境（ビルドに使った Python 3.12 の ARM64 版で、$HOME\torch-cuda に作った）に wheel を入れ、DLL のフォルダーを PATH に足して試した。
$env:PATH = "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.4\bin\arm64;" +
"C:\Program Files\NVIDIA\CUDNN\v9.25\bin\13.4\arm64;" +
"C:\Program Files\Arm Performance Libraries\armpl_26.01\bin;$env:PATH"
& "$HOME\torch-cuda\Scripts\python.exe" gpu_test.py
試したのは、4096×4096 の行列積を 10 回する時間を、CPU と GPU で比べるスクリプトである（1 回目は準備として計測から外す）。
import time, torch
print("torch", torch.version, "cuda", torch.cuda.is_available(), torch.version.cuda)
print("cudnn", torch.backends.cudnn.version())
print(torch.cuda.get_device_name(0), torch.cuda.get_device_capability(0))
def bench(device):
a = torch.randn(4096, 4096, device=device)
b = torch.randn(4096, 4096, device=device)
torch.matmul(a, b) # warm-up, not timed
if device == "cuda":
torch.cuda.synchronize()
t = time.perf_counter()
for _ in range(10):
c = torch.matmul(a, b)
if device == "cuda":
torch.cuda.synchronize()
return time.perf_counter() - t
print("threads", torch.get_num_threads())
print("CPU 10x (warm-up excluded): %.2f s" % bench("cpu"))
print("GPU 10x (warm-up excluded): %.4f s" % bench("cuda"))
torch 2.14.0.dev20260727+cu134 cuda True 13.4
cudnn 92501
NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU) (12, 1)
threads 20
CPU 10x (warm-up excluded): 8.15 s
GPU 10x (warm-up excluded): 0.0802 s
torch.cuda.is_available() が True になった。 GPU は 10 回で 0.0802 秒、1 秒あたり約 17 兆回の計算（float32）で、CPU の 8.15 秒の約 100 倍だった。スクリプトの最後には、nvidia-smi で見るために GPU を 20 秒回し続ける部分を足してある（上では省いた）。その間の nvidia-smi では、python.exe が Type C で出て、GPU の使用率は 96% だった。
CPU の 8.15 秒は、公式の CPU 版で測った 8.26 秒とほぼ同じである（測り方は少し違い、8.26 秒は 1 回目の呼び出しを含む）。このビルドは行列計算に Arm Performance Libraries を使っているが、CPU の速さは変わらなかった。20 コアの CPU にしては遅いのではないかと思っていたが、同じ PC の WSL2 で行列積を測ると約 4 倍速かった（3 節の終わり。ただし言語モデルの生成では逆になった）。
PyTorch から見た GPU のメモリーの合計は 110.2GiB で、nvidia-smi の 95.5GB より大きかった。理由は WSL2 を試したときに分かった（この節の終わり）。
PATH は、このときはそのターミナルだけで足した。毎回足すのは手間なので、仮想環境の site-packages に sitecustomize.py を置き、Python の起動時に 3 つのフォルダーを os.add_dll_directory と PATH に足す形にした。ほかの Python や Windows 全体には影響しない。PATH を足していない新しいターミナルでも、torch.cuda.is_available() は True になった。
言語モデルも GPU で動いた
行列積だけでは、実際に使えるかは分からない。そこで、同じ仮想環境に transformers を入れて、小さい言語モデル（Qwen2.5-0.5B-Instruct）で文を作らせた。
& "$HOME\torch-cuda\Scripts\python.exe" -m pip install transformers numpy
追加の部品は、どれも PyPI に ARM の Windows 向け（win_arm64）か、OS を問わない wheel があり、ビルドは要らなかった。自分でビルドした torch も、pip に置き換えられずにそのまま残った。
部品
版
配布物
transformers
5.20.2
OS を問わない（Python だけ）
tokenizers
0.23.3
win_arm64 あり
safetensors
0.8.0
win_arm64 あり
numpy
2.5.4
win_arm64 あり
モデルは safetensors の重みと設定だけで、trust_remote_code は使っていない。GPU は float16、CPU は float32 で、同じ質問に 128 トークンを作る時間を測った（準備の 1 回は計測から外す）。
import time, torch
from transformers import AutoModelForCausalLM, AutoTokenizer
name = 'Qwen/Qwen2.5-0.5B-Instruct'
tok = AutoTokenizer.from_pretrained(name)
msgs = [{'role': 'user', 'content': '日本の首都について3文で説明して'}]
enc = tok.apply_chat_template(msgs, add_generation_prompt=True, return_tensors='pt', return_dict=True)
for dev in ['cuda', 'cpu']:
model = AutoModelForCausalLM.from_pretrained(
name, dtype=torch.float16 if dev == 'cuda' else torch.float32).to(dev)
inp = {k: v.to(dev) for k, v in enc.items()}
n_in = inp['input_ids'].shape[1]
model.generate(inp, max_new_tokens=8) # warm-up
if dev == 'cuda':
torch.cuda.synchronize()
t = time.perf_counter()
out = model.generate(inp, max_new_tokens=128, do_sample=False)
if dev == 'cuda':
torch.cuda.synchronize()
sec = time.perf_counter() - t
n = out.shape[1] - n_in
print(dev, next(model.parameters()).device, next(model.parameters()).dtype,
n, 'tokens', round(sec, 2), 's', round(n / sec, 1), 'tok/s')
del model
cuda cuda:0 torch.float16 128 tokens 2.33 s 54.9 tok/s
cpu cpu torch.float32 128 tokens 16.87 s 7.6 tok/s
自分でビルドした PyTorch で、言語モデルが GPU で動いた。 1 秒に 54.9 トークンで、CPU の約 7 倍だった。作っている間の nvidia-smi では、python.exe が Type C で出ていた（このときは、生成を 20 秒回し続ける部分をスクリプトに足して見た）。
ただ、GPU の使用率は 35% で、行列積のとき（96%）より低かった。0.5B と小さいモデルを 1 トークンずつ作るので、GPU の計算より、そのたびの Python の側の処理に時間を取られているのではないかと見ている。54.9 トークン/秒は GPU の限界とは限らず、transformers の generate をそのまま使ったときの値である。Ollama の 151 トークン/秒（gemma3:1b）とは、モデルも仕組みも違うので、並べて比べられる数字ではない。
答えの中身は、0.5B のモデルらしく誤りが多かった（東京に無い「金沢区」が出てきた）。ここで見たのは、GPU で動くかと速さだけである。
途中で、Hugging Face のライブラリから 2 つ警告が出た。この PC ではキャッシュにシンボリックリンクを使えないので容量を多めに使う、というものと、トークン無しで取りに行っている、というものである。どちらもエラーではなく、公開されているモデルはそのまま取れた。
WSL2 なら、公式の PyTorch が GPU で動いた
公式に無いときのもう 1 つの道の WSL2 も、GPU が見えるかまで確かめた。NVIDIA の CUDA on WSL の手引きは、Windows のドライバーを入れれば WSL2 の中で CUDA が使える仕組みを説明しているが、書かれているのは x64 の話で、ARM64 には触れていなかった。
PowerShell で Ubuntu を入れた（管理者の権限は途中で求められた）。
wsl --install -d Ubuntu-24.04
1 回目は WSL 本体と仮想マシンの機能を入れたところで「再起動が必要」と出て終わり、Ubuntu はまだ入っていなかった。再起動のあとに wsl -d Ubuntu-24.04 を打つと WSL_E_DISTRO_NOT_FOUND になる。同じ wsl --install をもう一度打つと、Ubuntu が入った。
Ubuntu の中では、Linux 用の NVIDIA ドライバーを入れていないのに、/usr/lib/wsl/lib に libcuda.so や nvidia-smi が置かれていた。Windows のドライバーが用意したものである。nvidia-smi はフルパスで呼んだ（which nvidia-smi で見ると PATH も通っていた。Bus-Id は伏せた）。
$ uname -m
aarch64
$ /usr/lib/wsl/lib/nvidia-smi
| NVIDIA-SMI 615.78.05 KMD Version: 617.42 CUDA UMD Version: 13.4 |
| 0 NVIDIA RTX Spark N1X (61... On | ... On | N/A |
| N/A 43C P8 1W / N/A | 1220MiB / 97792MiB | 2% Default |
WSL の中の nvidia-smi は 615.78.05 と出るが、KMD Version は Windows のドライバーの 617.42 である。
CUDA のツールキットは入れずに、Ubuntu の python3 から libcuda.so.1 を直接呼んで、CUDA のコンテキストまで作れるかを見た。
Call the CUDA driver API directly (no toolkit needed) inside WSL2.
import ctypes
cuda = ctypes.CDLL('/usr/lib/wsl/lib/libcuda.so.1')
def check(name, rc):
print(f'{name}: {"OK" if rc == 0 else f"error {rc}"}')
if rc != 0:
raise SystemExit(1)
check('cuInit', cuda.cuInit(0))
ver = ctypes.c_int()
check('cuDriverGetVersion', cuda.cuDriverGetVersion(ctypes.byref(ver)))
print(' driver CUDA version:', f'{ver.value // 1000}.{ver.value % 1000 // 10}')
n = ctypes.c_int()
check('cuDeviceGetCount', cuda.cuDeviceGetCount(ctypes.byref(n)))
print(' devices:', n.value)
for i in range(n.value):
dev = ctypes.c_int()
check('cuDeviceGet', cuda.cuDeviceGet(ctypes.byref(dev), i))
name = ctypes.create_string_buffer(256)
cuda.cuDeviceGetName(name, 256, dev)
mem = ctypes.c_size_t()
cuda.cuDeviceTotalMem_v2(ctypes.byref(mem), dev)
major, minor = ctypes.c_int(), ctypes.c_int()
cuda.cuDeviceGetAttribute(ctypes.byref(major), 75, dev) # COMPUTE_CAPABILITY_MAJOR
cuda.cuDeviceGetAttribute(ctypes.byref(minor), 76, dev) # COMPUTE_CAPABILITY_MINOR
print(f' [{i}] {name.value.decode()} {mem.value / 230:.1f} GiB cc {major.value}.{minor.value}')
ctx = ctypes.c_void_p()
check('cuCtxCreate', cuda.cuCtxCreate_v2(ctypes.byref(ctx), 0, dev))
free, total = ctypes.c_size_t(), ctypes.c_size_t()
check('cuMemGetInfo', cuda.cuMemGetInfo_v2(ctypes.byref(free), ctypes.byref(total)))
print(f' free {free.value / 230:.1f} GiB / total {total.value / 2**30:.1f} GiB')
cuda.cuCtxDestroy_v2(ctx)
$ python3 wsl_cuinit.py
cuInit: OK
cuDriverGetVersion: OK
driver CUDA version: 13.4
cuDeviceGetCount: OK
devices: 1
cuDeviceGet: OK
[0] NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU) 110.2 GiB cc 12.1
cuCtxCreate: OK
cuMemGetInfo: OK
free 87.2 GiB / total 110.2 GiB
ARM の Windows の WSL2 からも、GPU が見えて CUDA を呼べた。 compute capability の 12.1 は、Windows で自分でビルドした PyTorch の (12, 1) と同じである。
次に、WSL2 の中に PyTorch を入れた。Linux の ARM 向け（aarch64）なら、公式の CUDA 版がある。2 節の一覧の調べ方で見ると、CUDA 13.2 版に torch-2.14.1+cu132-cp312-cp312-manylinux_2_28_aarch64.whl があった。
sudo apt update
sudo apt install -y python3-venv python3-pip
python3 -m venv ~/torch-cu
source ~/torch-cu/bin/activate
pip install torch --index-url download.pytorch.org
Windows と同じ、4096×4096 の行列積を 10 回する試験をした（スクリプトは Windows のものとほぼ同じ）。
torch 2.14.1+cu132 cuda 13.2 cudnn 92400
available True
arch list ['sm_80', 'sm_90', 'sm_100', 'sm_110', 'sm_120']
device NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU) (12, 1)
mem free 87.2 GiB / total 110.2 GiB
threads 20
CPU 10x (warm-up excluded): 1.93 s
GPU 10x (warm-up excluded): 0.0774 s
公式の配布物のまま、GPU で動いた。 一覧（arch list）には 12.1 向けのコードが無く 12.0 までだが、動いた。同じ 12 系のコードで動いているのだろうと見ているが、確かめてはいない。
WSL2（公式 2.14.1+cu132）
Windows（自分でビルド 2.14.0.dev+cu134）
CUDA / cuDNN
13.2 / 9.24.0
13.4 / 9.25.1
GPU の行列積 10 回
0.0774 秒
0.0802 秒
CPU の行列積 10 回
1.93 秒
8.15 秒（公式の CPU 版は 8.26 秒）
行列積の GPU の速さは、どちらもほぼ同じだった。違ったのは CPU で、この行列積では、同じ 20 スレッドなのに WSL2 のほうが約 4 倍速かった。Windows では、別の行列計算のライブラリを使う 2 つの版（公式の CPU 版と、自分でビルドした版）が、どちらも 8 秒台だった。Windows 側のどこが遅いのか（行列計算のライブラリか、OS の側か）は、まだ調べていない。
言語モデルの試験も、WSL2 で同じスクリプトを動かした（transformers などの版は Windows と同じ）。
Qwen2.5-0.5B・128 トークン
WSL2（公式 2.14.1+cu132）
Windows（自分でビルド）
GPU（float16）
66.2 トークン/秒（1.93 秒）
54.9 トークン/秒（2.33 秒）
CPU（float32）
4.1 トークン/秒（31.51 秒）
7.6 トークン/秒（16.87 秒）
GPU は WSL2 が約 2 割速かった。CPU は逆に、Windows のほうが約 2 倍速かった。 行列積とは向きが反対である。大きい行列の掛け算と、1 トークンずつ小さい計算を繰り返す生成とでは、速さを左右する所が違うのだろうと見ているが、原因は調べていない。「WSL2 のほうが CPU が速い」とは言えず、何で測ったかによって結論が逆になった。
手間で比べると、WSL2 はビルドが要らず、pip で入れるだけだった。この PC では、Windows のまま GPU で PyTorch を使いたいならビルドが要り、WSL2 の中でよければ公式の配布物で足りた。
ここでも合計は 110.2GiB だった。タスクマネージャーを見直すと、GPU のメモリーは「専用 95.5GB」と「共有 15.5GB」（Windows 側の 31GB の半分）に分かれていて、合計は 111GB と出ていた。CUDA が返す合計は、専用と共有を足した値に近く、nvidia-smi は専用だけを出していると考えると、数字が合う。
4. 入れたあと、GPU で動いているかを確かめる
GPU で動いているかは、道具の側の表示と、nvidia-smi の両方で見た。
見る所
GPU で動いているときの表示
PyTorch
torch.cuda.is_available() が True
Ollama
ollama ps の PROCESSOR が 100% GPU
nvidia-smi
プロセスの一覧に、その道具のプロセスが Type C（計算）で出る。GPU のメモリーの使用が増える
Ollama では、直後の nvidia-smi に llama-server.exe が Type C で出ていて、GPU のメモリーの使用は 956MiB から 2322MiB に増えていた。道具の表示と nvidia-smi が食い違わなければ、GPU で動いていると見てよさそうだ。ただ、どの仕組み（CUDA か、Vulkan などか）で GPU を使っているかは、これだけでは分からない。Ollama がどちらなのかは、まだ確かめていない。
速さも測った（モデルを読み込んだあとの 2 回目）。
> ollama run gemma3:1b "日本の首都について3文で説明して" --verbose
prompt eval count: 17 token(s)
prompt eval rate: 267.63 tokens/s
eval count: 81 token(s)
eval rate: 151.02 tokens/s
生成は 1 秒に約 151 トークンだった。プロンプトの処理は 268 トークン/秒だが、17 トークンと短いので参考の値である。答えの中身は 1B のモデルらしく怪しかった（東京の説明に浅草や渋谷が「世界一古い都市の一つ」として出てきた）。ここで見たのは速さだけである。
35B のモデルも、レビューと同じくらいか、それ以上の速さで動いた
書き出しのレビューで 1 秒に 58〜89 トークンと出ていた Qwen3.6-35B-A3B も、Ollama の公式のモデル（qwen3.6:35b-a3b、Q4_K_M、22GB）で動かした。質問は gemma3:1b と同じで、思考モードは既定のまま（オン）である。
> ollama run qwen3.6:35b-a3b "日本の首都について3文で説明して" --verbose
> ollama ps
NAME ID SIZE PROCESSOR CONTEXT RUNNER
qwen3.6:35b-a3b a7eb95c53bcf 22 GB 100% GPU 262144 llamacpp
回
生成（eval rate）
生成したトークン
1
101.89 トークン/秒
815
2
104.12 トークン/秒
1277
3
100.11 トークン/秒
1098
3 回とも 1 秒に約 100 トークンで、100% GPU だった。 nvidia-smi では、GPU のメモリーを約 29.4GB 使い、使用率は 69〜75% だった。モデルは 22GB なので、残りは文脈の長さ（262144 トークン）のぶんの作業領域ではないかと見ているが、確かめていない。95.5GB には、まだ余裕がある。
レビューの数字より速く出たが、質問の文や、Ollama の版、思考モードの扱いが同じとは限らない。レビューと同じくらいか、それ以上は出た、という程度に受け取っている。また、生成したトークンの大半は思考の部分で、この速さは思考も含めた値である。さらに、Ollama はこのモデルで、既定で先読み（モデルの中の MTP の層を使った投機的デコード、2 トークン先まで）をしている。約 100 トークンは先読みを含めた値で、先読みを切ると約 80 トークンだった。答えの中身は、0.5B や 1B と違って、まともだった。
なお、このときの Ollama は 0.40.7 だった。初日に入れたのは 0.40.6 で、いつの間にか自動で更新されていた。
結果のまとめ
試したこと
結果
GPU とドライバー
nvidia-smi が動く。617.42、CUDA UMD 13.4。GPU から 95.5GB が見える
Python
3.13.15 の ARM64 版が動く（出荷時は入っていない）
PyTorch（公式の配布物）
CUDA 版は入らない。CPU 版 2.14.1+cpu は動く（行列積 4096×4096 を 10 回で 8.26 秒）
PyTorch（自分でビルド）
GPU で動く。PR #190448 の途中の版、約 1 時間。行列積は GPU 0.0802 秒・CPU 8.15 秒。Qwen2.5-0.5B の生成は GPU 54.9・CPU 7.6 トークン/秒
Ollama
GPU で動く。入れるだけで 100% GPU、gemma3:1b で 151 トークン/秒、Qwen3.6-35B-A3B で約 100 トークン/秒（既定の先読みあり）
WSL2
Linux 用のドライバーなしで GPU が見えた。公式の PyTorch 2.14.1+cu132 がそのまま GPU で動く（行列積 GPU 0.0774 秒・CPU 1.93 秒、Qwen2.5-0.5B GPU 66.2・CPU 4.1 トークン/秒）
同じ PC でも、GPU を使えるかは道具によって分かれた。公式に無いものも、自分でビルドすれば GPU で動いた。
WSL2 で動かすもの、Windows で直接動かすもの
まだ全部は試していないが、今回の結果を受けて、この PC では次のように切り分けることにした。
どこで
動かすもの
理由
WSL2
画像・動画・音声の生成
PyTorch のまわりの部品が要る。GPU 版の torchvision・torchaudio、onnxruntime-gpu、opencv-python は、Linux の ARM 向けの配布物はあるが、ARM の Windows 向けは無かった（torchvision は CPU 版だけ）。WSL2 なら公式の PyTorch がそのまま GPU で動き、GPU の速さも同じか少し速かった
Windows で直接
LLM の推論
Ollama は入れるだけで GPU で動いた
Windows で直接
前の記事の MXC の箱で動かすエージェント
箱の仕組み（別のユーザー・MXC）が Windows のもの
Windows で直接
whisper.cpp などの自分でビルドするもの
ARM 版の CUDA 13.4 のツールキットがもう入っている
Windows で直接
USB や Bluetooth で実機をつなぐもの
WSL2 では USB の受け渡し（usbipd）が別に要る
この PC で動かしたのは、PyTorch（両方）・Ollama（Windows）・Qwen の生成（両方）までである。画像・動画・音声の生成、whisper.cpp、実機は、この切り分けで進めて、試したら書く。
切り分けは GPU を使う前提である。CPU だけの処理は、3 節のとおり、行列積では WSL2、言語モデルの生成では Windows が速く、どちらが有利とは決められなかった。また、WSL2 が使える CPU 側のメモリーは、既定では Windows 側の半分（この PC では約 15GB）なので、画像生成でモデルを読み込むなら .wslconfig で上げるつもりでいる。
チェックリスト
ARM の CPU と NVIDIA の GPU の Windows の PC を、AI を動かす用に設定するとき、この順で確かめた。
復元せず、新しい PC として設定する
Windows Update とドライバーを最新にする。電源モードを決める
NVIDIA App で、GPU に回すメモリーを決める。タスクマネージャーと nvidia-smi で反映を見る
使いたいライブラリの配布物の一覧で、win_arm64 の GPU 版があるかを見る。無ければ、自分でビルドする手順が公開されていないか、WSL2 で使えないかを探す。ビルドするなら、先に Git の core.longpaths と core.autocrlf を見ておき、終わったら DLL のフォルダーを PATH に足す
そのライブラリが対応する版に合わせて、Python を入れる（winget で Microsoft Store のソースのエラーが出たら -s winget）
入れたら、道具の表示（torch.cuda.is_available()・ollama ps）と nvidia-smi の両方で、GPU で動いているかを見る
2 台の間の受け渡しは、最初は近距離共有で、途中から PowerToys の Mouse Without Borders でマウスとクリップボードを共有した。コマンドの結果を手元の PC にそのまま貼れて、確かめながら進めるのに都合がよかった。
これから確かめること
次のどれかを、確かめられたら書くつもりでいる。
この PC そのものについて：
自分でビルドした PyTorch で、もっと大きいモデル（数 B〜数十 B）を、GPU のメモリーいっぱいまで載せて動かせるか
CPU の速さが、行列積では WSL2、言語モデルの生成では Windows のほうが速く、向きが逆になる理由
専用の 95.5GB を超えて、共有の分まで使うと、速さがどう変わるか
95.5GB を活かして、もっと大きいモデル（Qwen3.6-35B-A3B の q8_0 など）も載るか
nvidia-smi に別のデバイスとして出ている NPU は、何に使えるか
Ollama と Llama-Windows（llama.cpp の Windows 用のアプリ）の速さを、先読みなどの設定をそろえて比べる
前の記事で作った、MXC の箱と DNS の見張りをこの PC に移して、ローカル LLM のエージェントをできるだけ安全に使えるか
使ってみたい道具（ARM の Windows で動くかは、どれもまだ分からない。上のチェックリストの 4 と 6 で確かめ、動かなければ WSL2 か x64 のエミュレーションを試す）：
Microsoft の MAI のモデル：重みが公開されているのは 671B の MAI-DS-R1 だけで、この PC には載らない。ほかは主にクラウドで提供されている。手元に載る大きさで出たら試したい
NVIDIA の PAIR（Personal AI Router）：仕事で使っている RTX 2070 SUPER の PC や、いまの Intel Arc の PC（対応されれば）と、推論の処理を分け合えるか
Hy-Memory：エージェントに長期の記憶を持たせる
OpenComputer：ローカルの AI が画面を見て PC を操作する。上の MXC の箱の中で試したい
KohakuMossTrainer・ai-toolkit：画像のモデルの LoRA の学習（ai-toolkit は、上の手順の残りの部品（flash-attention など）のビルドも要る）
LTX-2.5・MiniMax H3：音声付きの動画の生成。いまの PC では載らないと見て、見送っていたもの
Irodori-TTS・mesh-avatar-studio：日本語の音声合成と、イラスト 1 枚から動く 2D のアバター。声と顔の付いた AI のキャラクターを作る
!
確かめたのは、届いてから翌日までの 1 台と、そのときの版のドライバー・配布物である（ドライバー 617.42、PyTorch 2.14.1（公式の CPU 版）と 2.14.0.dev20260727+cu134（自分でビルド）、transformers 5.20.2、CUDA 13.4、cuDNN 9.25.1、Ollama v0.40.6（Qwen3.6-35B-A3B は自動更新後の 0.40.7）、Python 3.13.15 と 3.12.15、WSL 3.0.3 と Ubuntu 24.04、WSL2 の中の PyTorch 2.14.1+cu132）。#190448 が取り込まれれば、公式の ARM の Windows 向けの CUDA 版が後から出る可能性はある。
Mentions
AI Toolkit now supports fine tuning P-H3-Image directly with a training adapter. github.com/ostris/ai-toolkit/commit/883d676b17c6b…
Ostris AI Toolkit now supports @bria_ai_ Fibo 2.0 github.com/ostris/ai-toolkit/commit/7cc9fef46927a…
Surface Laptop Ultra の初期設定。ARM の Windows で GPU が使えるかは、道具ごとに入れる前に確かめる ! 先に、この記事の要約 ARM の CPU と NVIDIA の GPU が 1 つのチップに入った Windows のノート PC を、AI を動かす用に初期設定した。その手順と、それぞれを選んだ理由を書く GPU に回すメモリーの量は設定で決まる。初期値は 62.5GB で、95.5GB にした GPU が使えるかは、道具ごとに違った。Ollama は入れるだけで GPU で動き、35B のモデル（Qwen3.6-35B-A3B）も 1 秒に約 100 トークンで動いた。PyTorch は ARM の Windows 向けの GPU 版が公式には配られておらず、入るのは CPU だけで動く版だった そこで PyTorch の GPU 版を、公開されている手順で自分でビルドした。約 1 時間で終わり、GPU で動いた。行列の掛け算は CPU の約 100 倍、小さい言語モデルの文の生成は約 7 倍の速さだった。途中で詰まった 4 か所と直し方も書く WSL2 の中なら、公式の Linux 向けの PyTorch がそのまま入り、GPU で動いた。GPU の速さはビルドしたものと同じくらいだった。CPU は、行列積では WSL2 が約 4 倍速く、言語モデルの生成では逆に Windows が約 2 倍速かった 道具を入れる前に「ARM の Windows 向けの GPU 版があるか」を配布物の一覧で確かめ、入れたあとは GPU で動いているかをコマンドで確かめる。その確かめ方を最後にチェックリストにした 初期設定だけを知りたいなら 1 節、ARM の Windows で GPU が使えるかの確かめ方なら 2 節とチェックリストを読めば足りる。PyTorch を GPU で動かしたいが、ビルドはしたくないなら、3 節の終わりの「WSL2 なら、公式の PyTorch が GPU で動いた」へ進んでほしい。 いまの PC は Intel の内蔵 GPU（Arc 140V）で、メモリー 32GB を CPU と共有している。GPU に回す量は設定で変えられる。手元のプロジェクトの多くが「メモリーに載らない」「CUDA が無い」で止まっていた。新しい Surface Laptop Ultra は、ARM の CPU と NVIDIA の RTX Spark の GPU が、128GB のメモリーを共有すると聞いて買った。 届く前に、海外のレビューを読んでいた。たとえば StorageReview のレビューでは、gpt-oss:20b と Qwen3.6-35B-A3B が 1 秒に 58〜89 トークンで動いていた。一方で、CPU の全コアで倍精度の重い計算を続けると電源が落ちた、という報告もあった（同じレビューで 2 台とも）。 レビューの数字は、整った環境で測ったものである。自分の手元で、何もない状態からどこまで行けるかは別の話になる。届いてから翌日までに、AI を動かす用の初期設定をして、何が GPU で動くかを確かめた。いちばん長い負荷は、全コアで約 1 時間かかった PyTorch のビルドだったが、電源が落ちることはなかった（CPU の温度は高くなったので、途中で電源モードを下げた）。 1. 初期設定の手順と、選んだ理由 復元せず、新しい PC として設定する 初期設定では「PC バックアップからの復元」を勧められたが、新しい PC として設定した。復元で来るのは x64 の PC で使っていたアプリの一覧で、ARM では動かないものが混ざる。ARM64 版を 1 つずつ入れれば、どれが ARM のまま動いて、どれが動かないかを見分けやすい。 更新と電源 Windows Update を「最新の状態」になるまで繰り返した 電源モードを「最適なパフォーマンス」にした（以下の数字はこの設定で測った。PyTorch のビルドの途中だけ「バランス」に下げた） NVIDIA App は最初から入っていた。アプリを更新し、ドライバーは Studio 617.42 を入れた（Game Ready も同じ番号だった） GPU に回すメモリーを決める CPU と GPU がメモリーを共有するので、そのうちどれだけを GPU 用にするかを決める。NVIDIA App の「システム」→「詳細設定」に「専用 GPU メモリ」の項目があり、初期値は 62.5GB だった。（上のレビューでは初期値を 64GB としていた。手元の表示は 62.5GB だった） スライダーの最大は 96GB である。ただ、最大まで動かすと「最小値や最大値はシステムを不安定にするおそれがある」という趣旨の警告が出た。95.5GB にすると警告が消えたので、そこにした。 反映されたかは、2 か所で確かめた。 タスクマネージャー：専用 GPU メモリーが 95.5GB、Windows 側のメモリーが 31GB nvidia-smi：GPU のメモリーが 97792MiB（＝95.5GB） GPU を広く取るほど、Windows とふつうのアプリが使える分は減る。大きいモデルを載せたいなら広く、ふつうの作業が多いなら狭く、と用途で変えることになりそうだ。 何が届いたかを記録する 確かめるためのコマンドを PowerShell のスクリプト 1 本にまとめ、Windows の「近距離共有」で Surface へ送って実行した。 項目 値 OS Windows 11 Pro、10.0.28000、ARM64 CPU の名前（Win32_Processor） NVIDIA RTX Spark N1X (6144-core GPU, 20-core CPU) 論理プロセッサ 20 GPU NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU) NPU NVIDIA NPU（GPU と同じドライバー） nvidia-smi 617.42、CUDA UMD Version 13.4 Python 入っていない（出荷時） WSL 入っていない（出荷時） nvidia-smi は、x64 の PC と同じように動いた。出力の一部を載せる（Bus-Id は伏せた）。 | NVIDIA-SMI 617.42 KMD Version: 617.42 CUDA UMD Version: 13.4 | | 0 NVIDIA RTX Spark N1X (61... WDDM | ... On | N/A | | N/A 41C P8 1W / N/A | 956MiB / 97792MiB | 2% Default | | 1 NVIDIA NPU MCDM | N/A Off | N/A | | N/A 41C N/A 1W / N/A | Not Supported | 0% N/A | 見慣れた「CUDA Version」ではなく、「KMD Version」と「CUDA UMD Version」が並んでいる。NPU も別のデバイスとして出ていた。 このスクリプトは、最初は文字化けで止まった。コメントに日本語を入れて BOM なしの UTF-8 で保存していたのを、Windows PowerShell 5.1 が Shift-JIS として読み、改行ごと化けて「引数が null であるため、パラメーター FilePath にバインドできない」という趣旨のエラーになった。コメントを英数字だけにしたら通った。ARM とは関係なく、Windows PowerShell 5.1 で日本語入りのスクリプトを動かすと起きることである。調べた範囲では、BOM 付きで保存しても避けられるようだ。 Python は、winget のソースを指定して入れる Python は出荷時に入っていなかった。winget で ARM64 版を入れようとしたら、Microsoft Store のソースで証明書のエラーになった。 0x8a15005e : サーバー証明書が、予期された値のいずれにも一致しませんでした。 -s winget を付けて winget のソースを指定したら入った（中身は python.org の ARM64 版のインストーラーだった）。 winget install Python.Python.3.13 -a arm64 -s winget py -3.13 -c "import sys, platform; print(platform.machine(), sys.version)" ARM64 3.13.15 ... [MSC v.1944 64 bit (ARM64)] 版を 3.13 にしたのは、次に入れる PyTorch の ARM の Windows 向けが 3.11〜3.13 しか無いからである。Python の版は、使いたいライブラリの配布物に合わせて決めた。 この PC で 3.14 以降を入れていたら、PyTorch は CPU 版も入らなかったことになる。 2. 入れる前に、GPU 版があるかを確かめる PyTorch：配布物の一覧に win_arm64 があるか pip で入れるライブラリは、配布物の一覧を見れば、どの OS と CPU 向けがあるかが分かる。PyTorch なら、CPU 版・CUDA 13.0 版のように、版ごとの一覧が公開されている。ファイル名の末尾が ARM の Windows 向けなら win_arm64、x64 の Windows 向けなら win_amd64 である。 一覧のページを取って数えれば足りる。 curl -s download.pytorch.org | grep -c win_arm64 # 27 curl -s download.pytorch.org | grep -c win_arm64 # 0 見た結果はこうだった。 ARM の Windows 向けの torch は、CPU 版だけだった。いちばん新しいのは 2.14.1+cpu で、Python は 3.11・3.12・3.13 の 3 つ。x64 の Windows 向けには 3.15 まである CUDA 版の一覧（cu126・cu128・cu130・cu132）には、win_arm64 が 1 つも無かった。ARM 向けの CUDA 版は Linux（aarch64）向けだけだった（cu130・cu132 で確かめた） 入らない見込みだったが、実機でも確かめた。仮想環境を作り、その中で CUDA 版を指定すると、やはり見つからない。 > py -3.13 -m venv $env:USERPROFILE\surface-check > & $env:USERPROFILE\surface-check\Scripts\Activate.ps1 > pip install torch --index-url download.pytorch.org ERROR: Could not find a version that satisfies the requirement torch (from versions: none) ERROR: No matching distribution found for torch CPU 版は入り、GPU は見えない。 > python -c "import torch; print(torch.version, torch.cuda.is_available())" 2.14.1+cpu False 公式の配布物で、Windows のまま CUDA の PyTorch を入れることは、いまはできない。 GPU もドライバーも CUDA も揃っているのに、PyTorch の側が ARM の Windows 向けの CUDA 版を配っていない。PyTorch の本体には、ARM の Windows で CUDA を使えるようにする変更（#190448）が出ているが、まだ取り込まれていない。 No matching distribution found は、ネットワークや pip の設定の問題に見えることがある。この PC では、配っていないからそう出た。先に一覧を見ておけば、エラーの原因を探さずに済む。 なお、CPU 版で 4096×4096 の行列積を 10 回すると、8.26 秒かかった（1 回目の呼び出しも含む）。1 秒あたり約 0.17 兆回の計算になる。この数字は、3 節で GPU と比べる。 公式に無いときの道は 2 つある。WSL2 の中で Linux の ARM 版を使うか、自分でビルドするかである。まずビルドを試し、そのあと WSL2 も試した（3 節の終わり）。 Ollama：配布物の大きさでは判断できなかった Ollama の Windows 向けの配布物（GitHub のリリース）を見ると、ARM64 版の zip は約 210MB で、x64 版（約 1.5GB）よりずっと小さい。x64 版との差は CUDA のライブラリの分ではないか、ARM64 版は GPU を使わないのではないか、と予想していた。 この予想は外れた。 winget で入れて（管理者ではない普通の権限で）、小さいモデルを動かした。 > winget install Ollama.Ollama -s winget > ollama run gemma3:1b "こんにちは" こんにちは！何かお手伝いできることはありますか？ 😊 > ollama ps NAME ID SIZE PROCESSOR CONTEXT RUNNER UNTIL gemma3:1b 97558784bdc9 1.0 GB 100% GPU 32768 llamacpp 4 minutes from now 設定は何もしていないのに 100% GPU と出た。配布物の大きさのような間接の手がかりでは、GPU を使うかは分からなかった。入れられるものは、入れて確かめるほうが早い。 3. 公式に無ければ、自分でビルドする 使った手順 ai-toolkit-spark-wheels は、RTX Spark の ARM の Windows でそのまま動く CUDA 13.4 版の PyTorch などを、ソースからビルドする手順をまとめている。ビルド済みのファイルもリリースに置いてあるが、使わずに自分でビルドした。 手順のスクリプトを読むと、PyTorch には独自の差分を当てていなかった。上の #190448 の途中の版（コミットを固定してある）を、そのまま取ってきてビルドする。PyTorch の側は、PR のコードがそのままビルドされる。なお、PR はその後も更新されていて、固定されている版は最新ではない。 作ったのは PyTorch と、その前提の部品（libuv）だけにした。手順にはほかに flash-attention などがあるが、今回は使わない。 手で入れたもの 手順には足りないものを調べる build.py doctor があるが、これは調べるだけで、入れはしない。前提はすべて手で入れた。ビルドのスクリプトは入れる場所を決め打ちしているので、どれも既定の場所に入れた。 必要だったもの 版・入れ方 CUDA ツールキット（ARM64・開発者向けのプレビュー） 13.4。NVIDIA のサイトから手で入れる（利用規約に同意）。ドライバーは同梱されていない ドライバー 617.42（Studio）のまま。条件の R616 以降を満たしていた cuDNN（ARM64） 9.25.1。NVIDIA のインストーラー版。NVIDIA の配布の一覧では、9.25.0（開発者向けのプレビュー）に ARM64 版が無く、正式版の 9.25.1 からあった VS2022 Build Tools 17.14 系。winget で、ARM64 の C++・CMake・Windows 11 SDK を選んで入れる Arm Performance Libraries 26.01。winget（行列計算のライブラリとして使う） uv 0.13.4（ARM64）。winget。ビルド用の Python 3.12 を、手順のスクリプトがこれで入れる CUDA のインストーラーは「Nsight for Visual Studio」が入らなかったと出したが、Build Tools は IDE ではないためで、ビルドには関係なかった。 手順の説明には、ビルドはメモリーを多く使うとある。いまは GPU に 95.5GB を回していて、Windows 側は 31GB しかない。そこで、ビルドの間だけ GPU に回す量を初期値の 62.5GB に戻し、試す前に 95.5GB に戻した。 詰まった所 git clone ostris/ai-toolkit-spark-wheels C:\sw cd C:\sw py -3.13 build.py doctor py -3.13 build.py libuv torch これで済めばよかったが、4 か所で手を入れた（4 つ目はビルドのあと）。 止まった・気になった所 原因 直し方 Python 用の差分が当たらない（patch does not apply） Git for Windows の既定 core.autocrlf=true で、LF の差分のファイルが CRLF で取り出された そのリポジトリだけ core.autocrlf false にして取り直す サブモジュールが取れない（unable to create file） パスが長すぎる。手順のスクリプトは core.longpaths を PyTorch 本体にしか設定しない git config --global core.longpaths true。Windows の LongPathsEnabled を 1 にしただけでは足りなかった CPU の温度が 99℃ 前後に張り付く（ビルドは止まっていない） 全コアのコンパイル 電源モードを「バランス」に下げたら、すぐに 90℃ 前後になった import torch で WinError 126（shm.dll） CUDA・cuDNN・Arm Performance Libraries の DLL が、bin の直下ではなく下のフォルダーにあり、PATH に無い 3 つのフォルダーを PATH に足す（下） 1 つ目の差分は、PyTorch ではなく別の部品のためのものだが、手順のスクリプトはビルド用の Python に必ず当てる。2 つ目で取れなかったのは、AMD の GPU 向けの部品（composable_kernel）で、これも使わないが、サブモジュールとして必ず取ってくる。クローン先を C:\sw のように短くしたのも、パスを短くするためである。 1 つ目と 2 つ目を直した 3 回目で、ビルドが通った。始めてから wheel ができるまで約 1 時間だった（手順の説明の数時間より短かった）。ディスクは約 25GB を使い、wheel は約 848MB になった。電源は最後まで落ちなかった。 torch-2.14.0.dev20260727+cu134-cp312-cp312-win_arm64.whl GPU で動いた 新しい仮想環境（ビルドに使った Python 3.12 の ARM64 版で、$HOME\torch-cuda に作った）に wheel を入れ、DLL のフォルダーを PATH に足して試した。 $env:PATH = "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.4\bin\arm64;" + "C:\Program Files\NVIDIA\CUDNN\v9.25\bin\13.4\arm64;" + "C:\Program Files\Arm Performance Libraries\armpl_26.01\bin;$env:PATH" & "$HOME\torch-cuda\Scripts\python.exe" gpu_test.py 試したのは、4096×4096 の行列積を 10 回する時間を、CPU と GPU で比べるスクリプトである（1 回目は準備として計測から外す）。 import time, torch print("torch", torch.version, "cuda", torch.cuda.is_available(), torch.version.cuda) print("cudnn", torch.backends.cudnn.version()) print(torch.cuda.get_device_name(0), torch.cuda.get_device_capability(0)) def bench(device): a = torch.randn(4096, 4096, device=device) b = torch.randn(4096, 4096, device=device) torch.matmul(a, b) # warm-up, not timed if device == "cuda": torch.cuda.synchronize() t = time.perf_counter() for _ in range(10): c = torch.matmul(a, b) if device == "cuda": torch.cuda.synchronize() return time.perf_counter() - t print("threads", torch.get_num_threads()) print("CPU 10x (warm-up excluded): %.2f s" % bench("cpu")) print("GPU 10x (warm-up excluded): %.4f s" % bench("cuda")) torch 2.14.0.dev20260727+cu134 cuda True 13.4 cudnn 92501 NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU) (12, 1) threads 20 CPU 10x (warm-up excluded): 8.15 s GPU 10x (warm-up excluded): 0.0802 s torch.cuda.is_available() が True になった。 GPU は 10 回で 0.0802 秒、1 秒あたり約 17 兆回の計算（float32）で、CPU の 8.15 秒の約 100 倍だった。スクリプトの最後には、nvidia-smi で見るために GPU を 20 秒回し続ける部分を足してある（上では省いた）。その間の nvidia-smi では、python.exe が Type C で出て、GPU の使用率は 96% だった。 CPU の 8.15 秒は、公式の CPU 版で測った 8.26 秒とほぼ同じである（測り方は少し違い、8.26 秒は 1 回目の呼び出しを含む）。このビルドは行列計算に Arm Performance Libraries を使っているが、CPU の速さは変わらなかった。20 コアの CPU にしては遅いのではないかと思っていたが、同じ PC の WSL2 で行列積を測ると約 4 倍速かった（3 節の終わり。ただし言語モデルの生成では逆になった）。 PyTorch から見た GPU のメモリーの合計は 110.2GiB で、nvidia-smi の 95.5GB より大きかった。理由は WSL2 を試したときに分かった（この節の終わり）。 PATH は、このときはそのターミナルだけで足した。毎回足すのは手間なので、仮想環境の site-packages に sitecustomize.py を置き、Python の起動時に 3 つのフォルダーを os.add_dll_directory と PATH に足す形にした。ほかの Python や Windows 全体には影響しない。PATH を足していない新しいターミナルでも、torch.cuda.is_available() は True になった。 言語モデルも GPU で動いた 行列積だけでは、実際に使えるかは分からない。そこで、同じ仮想環境に transformers を入れて、小さい言語モデル（Qwen2.5-0.5B-Instruct）で文を作らせた。 & "$HOME\torch-cuda\Scripts\python.exe" -m pip install transformers numpy 追加の部品は、どれも PyPI に ARM の Windows 向け（win_arm64）か、OS を問わない wheel があり、ビルドは要らなかった。自分でビルドした torch も、pip に置き換えられずにそのまま残った。 部品 版 配布物 transformers 5.20.2 OS を問わない（Python だけ） tokenizers 0.23.3 win_arm64 あり safetensors 0.8.0 win_arm64 あり numpy 2.5.4 win_arm64 あり モデルは safetensors の重みと設定だけで、trust_remote_code は使っていない。GPU は float16、CPU は float32 で、同じ質問に 128 トークンを作る時間を測った（準備の 1 回は計測から外す）。 import time, torch from transformers import AutoModelForCausalLM, AutoTokenizer name = 'Qwen/Qwen2.5-0.5B-Instruct' tok = AutoTokenizer.from_pretrained(name) msgs = [{'role': 'user', 'content': '日本の首都について3文で説明して'}] enc = tok.apply_chat_template(msgs, add_generation_prompt=True, return_tensors='pt', return_dict=True) for dev in ['cuda', 'cpu']: model = AutoModelForCausalLM.from_pretrained( name, dtype=torch.float16 if dev == 'cuda' else torch.float32).to(dev) inp = {k: v.to(dev) for k, v in enc.items()} n_in = inp['input_ids'].shape[1] model.generate(inp, max_new_tokens=8) # warm-up if dev == 'cuda': torch.cuda.synchronize() t = time.perf_counter() out = model.generate(inp, max_new_tokens=128, do_sample=False) if dev == 'cuda': torch.cuda.synchronize() sec = time.perf_counter() - t n = out.shape[1] - n_in print(dev, next(model.parameters()).device, next(model.parameters()).dtype, n, 'tokens', round(sec, 2), 's', round(n / sec, 1), 'tok/s') del model cuda cuda:0 torch.float16 128 tokens 2.33 s 54.9 tok/s cpu cpu torch.float32 128 tokens 16.87 s 7.6 tok/s 自分でビルドした PyTorch で、言語モデルが GPU で動いた。 1 秒に 54.9 トークンで、CPU の約 7 倍だった。作っている間の nvidia-smi では、python.exe が Type C で出ていた（このときは、生成を 20 秒回し続ける部分をスクリプトに足して見た）。 ただ、GPU の使用率は 35% で、行列積のとき（96%）より低かった。0.5B と小さいモデルを 1 トークンずつ作るので、GPU の計算より、そのたびの Python の側の処理に時間を取られているのではないかと見ている。54.9 トークン/秒は GPU の限界とは限らず、transformers の generate をそのまま使ったときの値である。Ollama の 151 トークン/秒（gemma3:1b）とは、モデルも仕組みも違うので、並べて比べられる数字ではない。 答えの中身は、0.5B のモデルらしく誤りが多かった（東京に無い「金沢区」が出てきた）。ここで見たのは、GPU で動くかと速さだけである。 途中で、Hugging Face のライブラリから 2 つ警告が出た。この PC ではキャッシュにシンボリックリンクを使えないので容量を多めに使う、というものと、トークン無しで取りに行っている、というものである。どちらもエラーではなく、公開されているモデルはそのまま取れた。 WSL2 なら、公式の PyTorch が GPU で動いた 公式に無いときのもう 1 つの道の WSL2 も、GPU が見えるかまで確かめた。NVIDIA の CUDA on WSL の手引きは、Windows のドライバーを入れれば WSL2 の中で CUDA が使える仕組みを説明しているが、書かれているのは x64 の話で、ARM64 には触れていなかった。 PowerShell で Ubuntu を入れた（管理者の権限は途中で求められた）。 wsl --install -d Ubuntu-24.04 1 回目は WSL 本体と仮想マシンの機能を入れたところで「再起動が必要」と出て終わり、Ubuntu はまだ入っていなかった。再起動のあとに wsl -d Ubuntu-24.04 を打つと WSL_E_DISTRO_NOT_FOUND になる。同じ wsl --install をもう一度打つと、Ubuntu が入った。 Ubuntu の中では、Linux 用の NVIDIA ドライバーを入れていないのに、/usr/lib/wsl/lib に libcuda.so や nvidia-smi が置かれていた。Windows のドライバーが用意したものである。nvidia-smi はフルパスで呼んだ（which nvidia-smi で見ると PATH も通っていた。Bus-Id は伏せた）。 $ uname -m aarch64 $ /usr/lib/wsl/lib/nvidia-smi | NVIDIA-SMI 615.78.05 KMD Version: 617.42 CUDA UMD Version: 13.4 | | 0 NVIDIA RTX Spark N1X (61... On | ... On | N/A | | N/A 43C P8 1W / N/A | 1220MiB / 97792MiB | 2% Default | WSL の中の nvidia-smi は 615.78.05 と出るが、KMD Version は Windows のドライバーの 617.42 である。 CUDA のツールキットは入れずに、Ubuntu の python3 から libcuda.so.1 を直接呼んで、CUDA のコンテキストまで作れるかを見た。 Call the CUDA driver API directly (no toolkit needed) inside WSL2. import ctypes cuda = ctypes.CDLL('/usr/lib/wsl/lib/libcuda.so.1') def check(name, rc): print(f'{name}: {"OK" if rc == 0 else f"error {rc}"}') if rc != 0: raise SystemExit(1) check('cuInit', cuda.cuInit(0)) ver = ctypes.c_int() check('cuDriverGetVersion', cuda.cuDriverGetVersion(ctypes.byref(ver))) print(' driver CUDA version:', f'{ver.value // 1000}.{ver.value % 1000 // 10}') n = ctypes.c_int() check('cuDeviceGetCount', cuda.cuDeviceGetCount(ctypes.byref(n))) print(' devices:', n.value) for i in range(n.value): dev = ctypes.c_int() check('cuDeviceGet', cuda.cuDeviceGet(ctypes.byref(dev), i)) name = ctypes.create_string_buffer(256) cuda.cuDeviceGetName(name, 256, dev) mem = ctypes.c_size_t() cuda.cuDeviceTotalMem_v2(ctypes.byref(mem), dev) major, minor = ctypes.c_int(), ctypes.c_int() cuda.cuDeviceGetAttribute(ctypes.byref(major), 75, dev) # COMPUTE_CAPABILITY_MAJOR cuda.cuDeviceGetAttribute(ctypes.byref(minor), 76, dev) # COMPUTE_CAPABILITY_MINOR print(f' [{i}] {name.value.decode()} {mem.value / 230:.1f} GiB cc {major.value}.{minor.value}') ctx = ctypes.c_void_p() check('cuCtxCreate', cuda.cuCtxCreate_v2(ctypes.byref(ctx), 0, dev)) free, total = ctypes.c_size_t(), ctypes.c_size_t() check('cuMemGetInfo', cuda.cuMemGetInfo_v2(ctypes.byref(free), ctypes.byref(total))) print(f' free {free.value / 230:.1f} GiB / total {total.value / 2**30:.1f} GiB') cuda.cuCtxDestroy_v2(ctx) $ python3 wsl_cuinit.py cuInit: OK cuDriverGetVersion: OK driver CUDA version: 13.4 cuDeviceGetCount: OK devices: 1 cuDeviceGet: OK [0] NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU) 110.2 GiB cc 12.1 cuCtxCreate: OK cuMemGetInfo: OK free 87.2 GiB / total 110.2 GiB ARM の Windows の WSL2 からも、GPU が見えて CUDA を呼べた。 compute capability の 12.1 は、Windows で自分でビルドした PyTorch の (12, 1) と同じである。 次に、WSL2 の中に PyTorch を入れた。Linux の ARM 向け（aarch64）なら、公式の CUDA 版がある。2 節の一覧の調べ方で見ると、CUDA 13.2 版に torch-2.14.1+cu132-cp312-cp312-manylinux_2_28_aarch64.whl があった。 sudo apt update sudo apt install -y python3-venv python3-pip python3 -m venv ~/torch-cu source ~/torch-cu/bin/activate pip install torch --index-url download.pytorch.org Windows と同じ、4096×4096 の行列積を 10 回する試験をした（スクリプトは Windows のものとほぼ同じ）。 torch 2.14.1+cu132 cuda 13.2 cudnn 92400 available True arch list ['sm_80', 'sm_90', 'sm_100', 'sm_110', 'sm_120'] device NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU) (12, 1) mem free 87.2 GiB / total 110.2 GiB threads 20 CPU 10x (warm-up excluded): 1.93 s GPU 10x (warm-up excluded): 0.0774 s 公式の配布物のまま、GPU で動いた。 一覧（arch list）には 12.1 向けのコードが無く 12.0 までだが、動いた。同じ 12 系のコードで動いているのだろうと見ているが、確かめてはいない。 WSL2（公式 2.14.1+cu132） Windows（自分でビルド 2.14.0.dev+cu134） CUDA / cuDNN 13.2 / 9.24.0 13.4 / 9.25.1 GPU の行列積 10 回 0.0774 秒 0.0802 秒 CPU の行列積 10 回 1.93 秒 8.15 秒（公式の CPU 版は 8.26 秒） 行列積の GPU の速さは、どちらもほぼ同じだった。違ったのは CPU で、この行列積では、同じ 20 スレッドなのに WSL2 のほうが約 4 倍速かった。Windows では、別の行列計算のライブラリを使う 2 つの版（公式の CPU 版と、自分でビルドした版）が、どちらも 8 秒台だった。Windows 側のどこが遅いのか（行列計算のライブラリか、OS の側か）は、まだ調べていない。 言語モデルの試験も、WSL2 で同じスクリプトを動かした（transformers などの版は Windows と同じ）。 Qwen2.5-0.5B・128 トークン WSL2（公式 2.14.1+cu132） Windows（自分でビルド） GPU（float16） 66.2 トークン/秒（1.93 秒） 54.9 トークン/秒（2.33 秒） CPU（float32） 4.1 トークン/秒（31.51 秒） 7.6 トークン/秒（16.87 秒） GPU は WSL2 が約 2 割速かった。CPU は逆に、Windows のほうが約 2 倍速かった。 行列積とは向きが反対である。大きい行列の掛け算と、1 トークンずつ小さい計算を繰り返す生成とでは、速さを左右する所が違うのだろうと見ているが、原因は調べていない。「WSL2 のほうが CPU が速い」とは言えず、何で測ったかによって結論が逆になった。 手間で比べると、WSL2 はビルドが要らず、pip で入れるだけだった。この PC では、Windows のまま GPU で PyTorch を使いたいならビルドが要り、WSL2 の中でよければ公式の配布物で足りた。 ここでも合計は 110.2GiB だった。タスクマネージャーを見直すと、GPU のメモリーは「専用 95.5GB」と「共有 15.5GB」（Windows 側の 31GB の半分）に分かれていて、合計は 111GB と出ていた。CUDA が返す合計は、専用と共有を足した値に近く、nvidia-smi は専用だけを出していると考えると、数字が合う。 4. 入れたあと、GPU で動いているかを確かめる GPU で動いているかは、道具の側の表示と、nvidia-smi の両方で見た。 見る所 GPU で動いているときの表示 PyTorch torch.cuda.is_available() が True Ollama ollama ps の PROCESSOR が 100% GPU nvidia-smi プロセスの一覧に、その道具のプロセスが Type C（計算）で出る。GPU のメモリーの使用が増える Ollama では、直後の nvidia-smi に llama-server.exe が Type C で出ていて、GPU のメモリーの使用は 956MiB から 2322MiB に増えていた。道具の表示と nvidia-smi が食い違わなければ、GPU で動いていると見てよさそうだ。ただ、どの仕組み（CUDA か、Vulkan などか）で GPU を使っているかは、これだけでは分からない。Ollama がどちらなのかは、まだ確かめていない。 速さも測った（モデルを読み込んだあとの 2 回目）。 > ollama run gemma3:1b "日本の首都について3文で説明して" --verbose prompt eval count: 17 token(s) prompt eval rate: 267.63 tokens/s eval count: 81 token(s) eval rate: 151.02 tokens/s 生成は 1 秒に約 151 トークンだった。プロンプトの処理は 268 トークン/秒だが、17 トークンと短いので参考の値である。答えの中身は 1B のモデルらしく怪しかった（東京の説明に浅草や渋谷が「世界一古い都市の一つ」として出てきた）。ここで見たのは速さだけである。 35B のモデルも、レビューと同じくらいか、それ以上の速さで動いた 書き出しのレビューで 1 秒に 58〜89 トークンと出ていた Qwen3.6-35B-A3B も、Ollama の公式のモデル（qwen3.6:35b-a3b、Q4_K_M、22GB）で動かした。質問は gemma3:1b と同じで、思考モードは既定のまま（オン）である。 > ollama run qwen3.6:35b-a3b "日本の首都について3文で説明して" --verbose > ollama ps NAME ID SIZE PROCESSOR CONTEXT RUNNER qwen3.6:35b-a3b a7eb95c53bcf 22 GB 100% GPU 262144 llamacpp 回 生成（eval rate） 生成したトークン 1 101.89 トークン/秒 815 2 104.12 トークン/秒 1277 3 100.11 トークン/秒 1098 3 回とも 1 秒に約 100 トークンで、100% GPU だった。 nvidia-smi では、GPU のメモリーを約 29.4GB 使い、使用率は 69〜75% だった。モデルは 22GB なので、残りは文脈の長さ（262144 トークン）のぶんの作業領域ではないかと見ているが、確かめていない。95.5GB には、まだ余裕がある。 レビューの数字より速く出たが、質問の文や、Ollama の版、思考モードの扱いが同じとは限らない。レビューと同じくらいか、それ以上は出た、という程度に受け取っている。また、生成したトークンの大半は思考の部分で、この速さは思考も含めた値である。さらに、Ollama はこのモデルで、既定で先読み（モデルの中の MTP の層を使った投機的デコード、2 トークン先まで）をしている。約 100 トークンは先読みを含めた値で、先読みを切ると約 80 トークンだった。答えの中身は、0.5B や 1B と違って、まともだった。 なお、このときの Ollama は 0.40.7 だった。初日に入れたのは 0.40.6 で、いつの間にか自動で更新されていた。 結果のまとめ 試したこと 結果 GPU とドライバー nvidia-smi が動く。617.42、CUDA UMD 13.4。GPU から 95.5GB が見える Python 3.13.15 の ARM64 版が動く（出荷時は入っていない） PyTorch（公式の配布物） CUDA 版は入らない。CPU 版 2.14.1+cpu は動く（行列積 4096×4096 を 10 回で 8.26 秒） PyTorch（自分でビルド） GPU で動く。PR #190448 の途中の版、約 1 時間。行列積は GPU 0.0802 秒・CPU 8.15 秒。Qwen2.5-0.5B の生成は GPU 54.9・CPU 7.6 トークン/秒 Ollama GPU で動く。入れるだけで 100% GPU、gemma3:1b で 151 トークン/秒、Qwen3.6-35B-A3B で約 100 トークン/秒（既定の先読みあり） WSL2 Linux 用のドライバーなしで GPU が見えた。公式の PyTorch 2.14.1+cu132 がそのまま GPU で動く（行列積 GPU 0.0774 秒・CPU 1.93 秒、Qwen2.5-0.5B GPU 66.2・CPU 4.1 トークン/秒） 同じ PC でも、GPU を使えるかは道具によって分かれた。公式に無いものも、自分でビルドすれば GPU で動いた。 WSL2 で動かすもの、Windows で直接動かすもの まだ全部は試していないが、今回の結果を受けて、この PC では次のように切り分けることにした。 どこで 動かすもの 理由 WSL2 画像・動画・音声の生成 PyTorch のまわりの部品が要る。GPU 版の torchvision・torchaudio、onnxruntime-gpu、opencv-python は、Linux の ARM 向けの配布物はあるが、ARM の Windows 向けは無かった（torchvision は CPU 版だけ）。WSL2 なら公式の PyTorch がそのまま GPU で動き、GPU の速さも同じか少し速かった Windows で直接 LLM の推論 Ollama は入れるだけで GPU で動いた Windows で直接 前の記事の MXC の箱で動かすエージェント 箱の仕組み（別のユーザー・MXC）が Windows のもの Windows で直接 whisper.cpp などの自分でビルドするもの ARM 版の CUDA 13.4 のツールキットがもう入っている Windows で直接 USB や Bluetooth で実機をつなぐもの WSL2 では USB の受け渡し（usbipd）が別に要る この PC で動かしたのは、PyTorch（両方）・Ollama（Windows）・Qwen の生成（両方）までである。画像・動画・音声の生成、whisper.cpp、実機は、この切り分けで進めて、試したら書く。 切り分けは GPU を使う前提である。CPU だけの処理は、3 節のとおり、行列積では WSL2、言語モデルの生成では Windows が速く、どちらが有利とは決められなかった。また、WSL2 が使える CPU 側のメモリーは、既定では Windows 側の半分（この PC では約 15GB）なので、画像生成でモデルを読み込むなら .wslconfig で上げるつもりでいる。 チェックリスト ARM の CPU と NVIDIA の GPU の Windows の PC を、AI を動かす用に設定するとき、この順で確かめた。 復元せず、新しい PC として設定する Windows Update とドライバーを最新にする。電源モードを決める NVIDIA App で、GPU に回すメモリーを決める。タスクマネージャーと nvidia-smi で反映を見る 使いたいライブラリの配布物の一覧で、win_arm64 の GPU 版があるかを見る。無ければ、自分でビルドする手順が公開されていないか、WSL2 で使えないかを探す。ビルドするなら、先に Git の core.longpaths と core.autocrlf を見ておき、終わったら DLL のフォルダーを PATH に足す そのライブラリが対応する版に合わせて、Python を入れる（winget で Microsoft Store のソースのエラーが出たら -s winget） 入れたら、道具の表示（torch.cuda.is_available()・ollama ps）と nvidia-smi の両方で、GPU で動いているかを見る 2 台の間の受け渡しは、最初は近距離共有で、途中から PowerToys の Mouse Without Borders でマウスとクリップボードを共有した。コマンドの結果を手元の PC にそのまま貼れて、確かめながら進めるのに都合がよかった。 これから確かめること 次のどれかを、確かめられたら書くつもりでいる。 この PC そのものについて： 自分でビルドした PyTorch で、もっと大きいモデル（数 B〜数十 B）を、GPU のメモリーいっぱいまで載せて動かせるか CPU の速さが、行列積では WSL2、言語モデルの生成では Windows のほうが速く、向きが逆になる理由 専用の 95.5GB を超えて、共有の分まで使うと、速さがどう変わるか 95.5GB を活かして、もっと大きいモデル（Qwen3.6-35B-A3B の q8_0 など）も載るか nvidia-smi に別のデバイスとして出ている NPU は、何に使えるか Ollama と Llama-Windows（llama.cpp の Windows 用のアプリ）の速さを、先読みなどの設定をそろえて比べる 前の記事で作った、MXC の箱と DNS の見張りをこの PC に移して、ローカル LLM のエージェントをできるだけ安全に使えるか 使ってみたい道具（ARM の Windows で動くかは、どれもまだ分からない。上のチェックリストの 4 と 6 で確かめ、動かなければ WSL2 か x64 のエミュレーションを試す）： Microsoft の MAI のモデル：重みが公開されているのは 671B の MAI-DS-R1 だけで、この PC には載らない。ほかは主にクラウドで提供されている。手元に載る大きさで出たら試したい NVIDIA の PAIR（Personal AI Router）：仕事で使っている RTX 2070 SUPER の PC や、いまの Intel Arc の PC（対応されれば）と、推論の処理を分け合えるか Hy-Memory：エージェントに長期の記憶を持たせる OpenComputer：ローカルの AI が画面を見て PC を操作する。上の MXC の箱の中で試したい KohakuMossTrainer・ai-toolkit：画像のモデルの LoRA の学習（ai-toolkit は、上の手順の残りの部品（flash-attention など）のビルドも要る） LTX-2.5・MiniMax H3：音声付きの動画の生成。いまの PC では載らないと見て、見送っていたもの Irodori-TTS・mesh-avatar-studio：日本語の音声合成と、イラスト 1 枚から動く 2D のアバター。声と顔の付いた AI のキャラクターを作る ! 確かめたのは、届いてから翌日までの 1 台と、そのときの版のドライバー・配布物である（ドライバー 617.42、PyTorch 2.14.1（公式の CPU 版）と 2.14.0.dev20260727+cu134（自分でビルド）、transformers 5.20.2、CUDA 13.4、cuDNN 9.25.1、Ollama v0.40.6（Qwen3.6-35B-A3B は自動更新後の 0.40.7）、Python 3.13.15 と 3.12.15、WSL 3.0.3 と Ubuntu 24.04、WSL2 の中の PyTorch 2.14.1+cu132）。#190448 が取り込まれれば、公式の ARM の Windows 向けの CUDA 版が後から出る可能性はある。
x.com MOSS-Image参照画像使えるようだ。 x.com ostris/ComfyUI-MOSS-Image-Ostris-Edit 具体的にはこの辺のノードを使うっぽい？
早速ai-toolkitがFLUX.3 Klein対応したので学習中。これで肌色改善されればそこそこ行けるかも！？ @ostrisai github.com/ostris/ai-toolkit/commit/12395a103fd0c… t.co
Ostris AI Toolkit has day 0 support for FLUX 3 Image Klein. Thank you @bfl_ai for the early access and the amazing model! ai-toolkit#1078
Ostris AI Toolkit now supports Iris 3B github.com/ostris/ai-toolkit/commit/2fa0bd87e6cd1…