GMKtec EVO-X2を実機検証〜大容量メモリのミニPCで235Bを動かす、BIOS設定の落とし穴と正解

大容量メモリのミニPCを手に入れたら、まず試したくなるのが「クラウドに頼らず、手元で大きなAIモデルを動かす」ことでした。GMKtec EVO-X2、128GBのユニファイドメモリを積んだミニPCです（サイズはMac miniよりひと回り大きいくらい）。ところが、いざ巨大なモデルを読み込ませると、思ったように動いてくれません。原因を追ううちに、設定の落とし穴と、その正しい直し方が見えてきました。最終的には、235Bという桁違いに大きなモデルが、この小さな箱で実用的な速度で動くところまでたどり着きます。（実機での計測・2026年6月時点）

実機：GMKtec EVO-X2

実際にGMKtec EVO-X2を購入してみました。

購入は楽天のGMKtecのサイトより行いました。20%クーポンが発行されていたため、実売52万円程度でした。

持ってみるとひんやりとしており、金属筐体が使われていることがわかります。

大きさはMac mini M4を比べると一回り大きいサイズです。

更に、ACアダプタもついてくるため、それなりに場所は取る。

このACアダプタは230W相当のもの。GMKtec EVO-X2の定格は140Wなので、少し余裕を見た大きめのACアダプタが採用されていると考えられます。

筐体の裏の下側には、ラジエーター（放熱器）に使われるようなコルゲートフィン（波状に折り返した放熱ひだ）が見えます。これが見た目以上の重みを感じる所以なのでしょう。動作時にはここから熱気が逃げているのがわかります。触ると曲がってしまうはずなので、取り扱いには注意が必要です。

余談ですが、購入時には、黄色いテープでLANポートが防がれていました。アップデートで作業ができないとクレームでも入ったのでしょうか。

GMKtec EVO-X2 の主なスペック

この記事で動かしているEVO-X2の中身を、先にまとめておきます。中核はAMDのRyzen AI Max+ 395（開発コード名Strix Halo）というSoCで、CPU・GPU・NPUが一体になり、128GBのメモリをシステムとグラフィックスで共有するのが最大の特徴です。

項目内容
SoCAMD Ryzen AI Max+ 395（Strix Halo・Zen 5）
CPU16コア / 32スレッド（最大5.1GHz）
GPURadeon 8060S（RDNA 3.5・40コア）
NPUXDNA 2・最大50 TOPS（CPU/GPU含む合計 約126 TOPS）
メモリ128GB LPDDR5X-8000（256bit・帯域 約256GB/s・ユニファイド）
ストレージ2TB SSD（NVMe）
消費電力定格 約140W（45〜120Wで調整可）
OSWindows / Linux
サイズ感Mac mini よりひと回り大きい

※ スペックは公称値（確認日2026年6月）。生成速度を左右するのは、このうち「メモリ帯域 約256GB/s」と「128GBという容量」です。

細かな仕様や端子構成、最新の価格・クーポンについては、販売サイトや公式サイトをご覧ください。下のカードから確認できます。

[kimono_product id="16082″]

ここからが本題です。その128GBをどう活かすかで、さっそくつまずきました。

つまずき：「VRAMは大きいほど良い」という思い込み

最初にやったのは、BIOSで統合GPUの専用メモリ（VRAM）を最大の96GBに設定することでした。VRAMが大きいほど大きなモデルが載って有利だろう、という直感です。ところが、これが裏目に出ます。

128GBのうち96GBをVRAMに固定したことで、システムメモリは32GBまで痩せてしまいました。その状態で70Bクラス（約44GB）のモデルを読み込ませると、96GBもVRAMがあるのに、半分以上がCPU側へ追い出されてしまいます。生成速度は秒あたり3トークン台まで落ち込み、とても実用とは言えません。さらに、モデルのダウンロードと計測を同時に走らせると、システムメモリのキャッシュが奪い合いになり、ディスクから延々とモデルを読み続ける状態に陥りました。

原因：メモリの見積もりが、痩せたシステムメモリに引きずられていた

調べていくと、統合GPUの推論ソフトが「GPUの空きメモリ」をシステムメモリの空きに引きずられて低く見積もり、大きなモデルを「載りきらない」と判断してCPUへ逃がしていたことが分かりました。専用VRAMを大きく取るほどシステムメモリが痩せ、この誤判定がひどくなります。つまり、VRAMを最大化したことそのものが逆効果だったわけです。

正しい設計：専用VRAMは最小に、メモリは動的に渡す

ユニファイドメモリの機械では、メモリは物理的にひとつです。GPUは本来、メモリ全体を同じ帯域で触れるので、「VRAMから溢れてシステムメモリに落ちる崖」が原理的に存在しません。鍵は、専用VRAMを固定しないことでした。海外の先行ガイドが示す定石も同じで、要点は次の三つに集約されます。

項目誤り（最初）正しい設定
BIOSの専用VRAM96GBに固定最小（1GB）に
GPUの計算メモリ自動（小さい）カーネル設定で約115GBまで動的に許可
モデルの読み込み方式既定（mmap）メモリマップを無効化

専用VRAMを最小にしておけば、残りはシステムメモリとして見え、GPUは必要なぶんだけ動的に確保します。固定の囲い込みではないので、システムメモリも痩せません。これで「ユニファイドだから、大きなモデルでも崖がない」が、実機でようやく成立しました。なお、ここで足すのはBIOSとカーネルの設定だけで、追加のソフトを入れる必要はありませんでした。

最後の壁：メモリの上限は三層になっていた

設定を直しても、85GBを超えるモデルだけは、読み込みの途中でメモリ確保に失敗して落ちます。115GBまで広げたはずなのに、なぜか。掘っていくと、ユニファイドメモリのGPUが使えるメモリは三つの層で決まっていて、一番内側が効いていたことが分かりました。

  1. BIOSの専用VRAM枠（最小の1GB）
  2. カーネルが許すGPUメモリの空間（115GBに拡大済み）
  3. 実際に確保できるページの上限（既定でシステムメモリの50%が上限）

推論ソフトが見ていた「GPUメモリ総量」の正体は、この三層目でした。空間を115GBに広げても、もっと内側のメモリ管理層が「実際に渡せるのは半分まで」と頭打ちにしていたわけです。70Bは通るのに、それより大きいモデルだけ落ちる理由が、これで腑に落ちました。

対処はこの上限の引き上げで、起動時のカーネルパラメータとして指定するのが肝心でした。動作中に値だけ書き換えても、表示が変わるだけで実際の確保には反映されません。起動時に効かせて初めて、推論ソフトの認識が一気に広がります。

結果：235Bが、この小さな箱で実用速度で動いた

三層すべてを整えて再起動したところ、235Bという巨大なモデル（約87GB）が、全層GPUに載って動きました。生成は秒あたり約18.8トークン。これは文章を読む速さを超えていて、対話にもコード生成にも十分使える速度です。

モデルサイズEVO-X2（正しい設定）
70B（密モデル）約44GB5.0 トークン/秒（全層GPU・安定）
235B（MoE・Q2）約87GB18.8 トークン/秒

面白いのは、235Bのほうが70Bより速いことです。235Bは総数こそ巨大ですが、MoEという仕組みで一度に使うのは22B分だけ。だから、密な70Bより1トークンあたりの計算が軽く済みます。速度を決めるのは総数ではなく、一度に使う量とメモリの速さだ、という原則がよく見える結果でした。

持ち帰り：他の人にも役立つ三つの教訓

同じようにミニPCで大きなモデルを動かそうとしている方に、つまずきの近道を残しておきます。

  • 専用VRAMは大きいほど良い、は誤り。ユニファイドメモリでは、専用VRAMを最小にして、動的な割り当てを大きく取るのが正解でした。直感とは逆です。
  • 大きなモデルが「メモリは足りているのに載らない」ときは、上限が多層だと疑う。表示上のGPUメモリが実メモリの半分くらいなら、一番内側の上限を見直すと解けることがあります。
  • 計測とダウンロードは同時にやらない。キャッシュの奪い合いで、速度が三分の二まで落ちるのを実際に見ました。

この一台で見えてきたのは、「設定さえ正しければ、Mac miniよりひと回り大きい程度のミニPCでも、専用GPUでは載りきらない巨大モデルが動く」という事実でした。次回は、では動かせるとして“どれくらい賢いのか”、クラウドの最新モデルとどこまで肩を並べるのかを、実際に測って確かめていきます。

参考にしたサイト

ローカルAI