だいぶ、EVO-X2の調整ができるようになった。Linuxで常時稼働させることになったが、美味しい設定を調べることに。ようやく答えが出た。
EVO-X2では、BIOSでVRAMを大きく固定するだけでは最適にならない。
画像生成、動画生成、Ollama、Agent AI、ComfyUIでは、それぞれ必要とするメモリの性質が違う。
VRAM固定は高速だが、予約領域としてメインメモリを削る。
GTTはやや遅いが、未使用時にメインメモリとして使えるため柔軟性が高い。
Ollamaでは、GTTを大きく取ることで複数モデルを100% GPUとして扱える場合があり、Agent AI用途ではVRAM固定より実用的な場面がある。
つまり、EVO-X2の128GB RAMは「全部をVRAMにする」のではなく、
用途に応じてVRAM/GTT/通常RAMの配分を調整してこそ活きる。
ことがわかった。。。
EVO-X2 (Strix Halo) の VRAM / GTT のまとめ
VRAM と GTT がある
Strix Halo (Ryzen AI MAX+ 395 / Radeon 8060S) は UMA (Unified Memory Architecture) 構成であり、GPU専用メモリを持たず、システムRAMをGPUと共有して使う。
Linux + ROCm 環境では、大きく分けて以下の2種類がある。
|
項目
|
内容
|
|---|---|
|
VRAM
|
BIOSで固定確保されるGPU専用領域
|
|
GTT
|
GPUが必要時に使う共有メモリ領域（システムRAM側）
|
イメージとしては、
VRAM:
最初からGPU専用として予約される固定領域
GTT:
GPUが必要時にOS側RAMを借りる共有領域
に近い。
EVO-X2が販売開始されたときには、VRAMの設定が96GBまで設定できる！で一世風靡した。
VRAMをメインで使う場合
BIOSでVRAMを64GBに設定
画像生成特化なら、VRAMをメインに考える。
ComfyUIで確認すると、VRAM利用の方がGTT利用より約11%高速だった。
そのため、
-
画像生成専用機
-
動画生成専用機
なら、VRAM固定はかなり有効。
ただし、LTX Video 2.3のような動画生成では、VRAMを64GB程度にしておかないと動かない。ただし、動画生成ではGPUメモリだけではなく、通常RAM側もかなり消費する。これはWIndowsでも同じだった。
Ollama側の問題
ただし、Ollamaでは事情が異なる。
Ollamaは、VRAM内でのみモデルを動かそうとする傾向が強く、VRAM 64GBなら、64GB内でしかモデルをロードできないような挙動になる。
そのため、
-
qwen3.6:35b-a3b
-
gpt-oss:20b
のような大型モデル複数ロードでは、使っていないモデルがアンロードされるという動きになりやすい。
いわば、
「囚われのVRAM領域」
に近い。
VRAM固定は高速だが、その領域は完全にGPU専用予約となるため、使っていない時でも通常RAMとしては使えないというデメリットもある。
GTTをメインで使う場合
BIOSでVRAMを2GBに設定
VRAMはBIOSで最小限にすると、GTTをメインで使うことができる。
GTTはBIOSではなく、Linux側のカーネルパラメータで設定する。よって変更時は再起動が必要なのはVRAM設定と同じ。
ComfyUI側
画像生成でもGTTは使える。
ただし、LTX Video 2.3のような動画生成では、GTTも64GB程度必要だった。
つまり、VRAMでもGTTでも、動画生成では結局大容量GPUメモリ空間が必要
という点は同じ。
ただし速度は、VRAM > GTTであり、実測ではVRAMの方が約11%高速だった。
-
速度最優先ならVRAM固定
-
柔軟性重視ならGTT
という関係になる。
OllamaではGTTが非常に有効
ここがかなり重要。
Ollamaでは、VRAM 64GB固定より、VRAM 2GB + GTT巨大化(84GB)の方が、大型モデル複数ロードに向いていた。
例えば、GTT 84GBにすると、
-
qwen3.6:35b-a3b-agent-32k
-
gpt-oss:20b-main-32k
-
qwen3.5:9b-main-32k
のような32Kモデル複数ロードも可能だった。
しかも、ComfyUI Z-image Turbo程度なら、Ollama 2モデル同時稼働も可能だった。かなりギリギリではあるが、成立する。
このケースの場合、VRAMで固定するのと違って、使っていない、あるいは空いたGTTの領域は、普通のRAMとしても使うことができる。
ちょっとだけスピードを犠牲にしてもGTTとメインメモリの間仕切りが自由に動かせるのはいい。
CPUオフロードについて
一般的な NVIDIA + dGPU 環境では、
VRAM不足
↓
CPU offload
という動きになりやすい。
しかし、Strix Halo + ROCm + UMA 環境では、GTT込みの巨大GPU memory poolとして扱われるような挙動になっていた。
つまり、CPU/GPU分離というより、巨大UMA GPUに近い。
少なくとも今回の Linux + ROCm + Ollama 環境では、
-
VRAM 2GB
-
GTT巨大化
でも、
-
100% GPU
として複数モデルが動作した。これは従来の dGPU 的な感覚とはかなり違う。
Ollamaのモデル共有について
さらに、
-
qwen3.6:35b-a3b-agent-32k
-
qwen3.6:35b-a3b-main-32k
のように、
-
同一ベースモデル
-
同一コンテキスト長
なら、完全に別モデルとして巨大追加ロードされない可能性が高い。
このため、
-
Agent
-
Main
-
Code
を同一ベースモデルで揃えると、メモリ効率がかなり良くなり、多数のモデルをロードしてもGTTを使われない。VRAMでも同じ挙動。
Agent AI用途では、ここもかなり重要。
GTTのメリット
VRAM固定と違い、GTTは、未使用時は通常RAMとして利用可能なのが非常に大きい。
VRAM固定64GBだと、その領域は常にGPU専用予約になる。
しかしGTTでは、使っていない分はOS側RAMとして利用可能になる。
この違いはかなり大きい。
特に、
-
Ollama
-
Open WebUI
-
OpenClaw
-
ComfyUI
-
Qdrant
-
Docling
などのように、複数サービスを常時動かす Linux 環境では、この柔軟性がかなり効いてくる。
結論
現時点では、EVO-X2 (Strix Halo) を Linux + ROCm + Ollama + ComfyUI で使う場合、
BIOS設定でVRAM 2GB
カーネルパラメーターでGTT 64GB〜84GB
がかなりバランスが良かった。
特に、
-
Agent AI
-
Open WebUI
-
OpenClaw
-
複数LLM常駐
を重視するなら、VRAM大量固定より、GTT巨大化の方が実用的だった。
最後に
2025年までの、「VRAM容量至上主義」の感覚で Strix Halo を見ると、EVO-X2 の本当の強みを見誤る。
Strix Halo世代では、固定VRAM容量ではなく、VRAM / GTT / 通常RAMをどう配分するか、そのものが性能設計になっている。
特にAgent AIでは、単純なVRAM容量より、巨大コンテキストを複数モデルでどう保持し、周辺サービスと共存させるかが重要になる。
EVO-X2は、単なる“小型GPUマシン”ではなく、「巨大UMAメモリマシン」として使うと、本領を発揮する。
というわけで、Linuxなら、BIOSでVRAM 2GBにして、GTTをカーネルパラメータで64-84GBに設定する。それだけで巨大UMAマシンとして体験できると思う。