Article
ローカルAI専用機としてASUS Ascent GX10を導入した
ASUS Ascent GX10を導入した。NVIDIA DGX Spark互換の、小型AIワークステーションとして使えるマシンだ。
買った理由はかなりはっきりしている。これまでMac StudioでローカルLLMを動かしていたが、Mac Studioは普段の開発や写真・動画まわりの作業にも使っている。そこにLLMを常時載せておくと、便利ではあるが、だんだんメインマシンの余白を食っていく。
ローカルLLMを「作業用Macの片隅で動くもの」から、「専用機で常時動いているもの」に移したかった。
もう一つ大きかったのは、CUDA/NVIDIA環境をちゃんと触りたかったことだ。OpenClawのような自分用AIシステムのバックエンドにしたいし、Gemma以外のモデルも試したい。将来的には、RAW現像や動画編集の補助など、自分の制作ワークフローに寄せた小さな機械学習も試してみたい。
本当はM5世代のMac Studioを待つつもりだった。ただ、待ちきれなかった。メモリ価格も上がっているし、ローカル実験用の大容量メモリ機を早めに確保しておく判断をした。
Codex Appと一緒にセットアップした
今回のセットアップで特徴的だったのは、ほぼ最初からCodex Appと一緒に進めたことだ。
箱から出して、電源とLANをつなぎ、初期セットアップ用のWi-Fiに接続する。規約同意とユーザー作成までは、普通の家電に近い。その直後に本体アップデートが始まり、初期セットアップ用のSSIDが消えた。
最初は少し焦ったが、更新中にホットスポットが止まるのは自然な挙動だった。ここから先は、LAN上でホストを探し、SSHで入り、Dashboardの状態を確認し、足りない更新を片付けていく作業になる。
このあたりをCodex Appに任せられたのがかなり大きかった。単に「このコマンドを打つとよい」と提案するだけではなく、実際に状態を見て、失敗したら原因を切り分け、次の確認コマンドを走らせ、修復まで進めてくれる。
今回で言えば、Codex Appは次のような作業を一緒に進めた。
- LAN上でGX10を見つける
- SSH鍵を作ってログイン経路を整える
- DGX Dashboardがどこで待ち受けているか確認する
- NVIDIAドライバやDGX関連パッケージの更新状態を見る
dpkg、apt、fwupdを順番に片付ける- DockerからGPUが見えるところまで確認する
自分は「こうしたい」と方向を出し、Codex Appが状態確認と具体的な実行を担当する。ローカルAI専用機のセットアップを、別のAIエージェントに手伝わせている感じがあり、これは今回の記事でも外せないポイントだと思う。
DashboardはLAN直ではなくSSH forwardingで開いた
最初に少し詰まったのはDGX Dashboardへのアクセスだった。
LAN上で本体は見えている。SSHも通る。ところが、ブラウザでそのまま http://<hostname>.local を開いてもDashboardは出てこない。
実際には、DGX DashboardとJupyterLabはGX10上のローカルループバック側に閉じていた。Mac側から見るにはSSHポートフォワードを使うのが素直だった。
ssh -L 11000:localhost:11000 -L 11002:localhost:11002 <hostname>
この状態でMac側から次を開く。
http://localhost:11000
これでDGX Dashboardが開いた。
構成を単純化すると、初期セットアップ時の見え方はこうだった。
flowchart LR
mac["Mac / Codex App"] -->|SSH key| gx10["ASUS Ascent GX10"]
mac -->|SSH port forward| dashboard["DGX Dashboard localhost:11000"]
gx10 --> dashboard
gx10 --> updates["apt / dpkg / fwupd"]
gx10 --> gpu["NVIDIA GB10 / Docker GPU check"]
gx10 --> tailnet["Tailnet route for later LLM API tests"]
この図で大事なのは、Dashboardが最初からLANに開いている前提で進めないことだ。手元ではSSH forwardingを使うのが確実だった。
SSH鍵とsudoを整える
セットアップ作業はMacからCodex App経由で進めたかったので、Codex用のSSH鍵を作り、GX10側の authorized_keys に追加した。Mac側にはSSH aliasも作り、以後は短いコマンドで入れるようにした。
ssh <hostname>
さらに、メンテナンスをCodex Appから進めやすくするため、専用ユーザーにはpasswordless sudoを許可した。
/etc/sudoers.d/<user>-nopasswd
これはかなり便利だが、どこでも雑に使っていい設定ではない。今回は家庭内の専用マシンとして、自分だけが触る前提だから採用した。共有環境や外部公開されたサーバーなら、ここはもっと慎重に設計する必要がある。
アップデートはaptだけでは終わらなかった
初期状態では、更新が途中で止まったような状態になっていた。
具体的には、nvidia-smi が失敗し、dpkg には未設定のパッケージが残り、NVIDIAドライバ関連パッケージも半端に入っていた。Dashboard上にもまだ Update Available が出ていた。
まずはLinuxマシンとしての基本的な修復を進める。
sudo dpkg --configure -a
sudo apt-get -f install
sudo apt update
sudo apt full-upgrade
途中でNVIDIA AI Workbenchのaptリポジトリキーが期限切れになっていて、apt update が止まる問題もあった。キーを更新したあと、通常のapt更新は通るようになった。
その後、NVIDIAドライバ、DGX Dashboard、DGX OOBE、DGX Spark OTA関連パッケージ、NVIDIA telemetry、Wi-Fi firmware関連パッケージまで更新した。
ここで終わりではなかった。Dashboard上の更新が消えたあとも、fwupdmgr にはUSB-C PD controllerのファームウェア更新が残っていた。
fwupdmgr get-updates
fwupdmgr update
これも適用して再起動し、更新状態が Success になっていること、追加のファームウェア更新がないことを確認した。
最終的な健康状態
セットアップ直後の健康診断としては、次の状態まで確認した。
OS: Ubuntu 24.04.4 LTS
kernel: 6.17.0-1018-nvidia
GPU: NVIDIA GB10
NVIDIA driver: 580.142
CUDA reported by nvidia-smi: 13.0
Docker: 29.2.1
nvidia-container-cli: 1.19.0
DGX OTA: 7.5.0
apt upgradable: 0
dpkg audit: clean
systemctl --failed: 0
reboot-required: no
fwupd updates: none
GPUも見えている。
GPU 0: NVIDIA GB10
最後に、NVIDIAのCUDAコンテナからもGPUを確認した。
sudo docker run --rm --gpus all \
nvcr.io/nvidia/cuda:13.0.0-base-ubuntu24.04 \
nvidia-smi
ここまで通れば、少なくとも「OSは上がっているがGPUコンテナが使えない」という状態ではない。ローカルLLMサーバーを立てる前の土台としては、かなり安心できる。
Tailscaleは後段のための常用経路
最初のセットアップだけならSSH forwardingで十分だった。ただ、このGX10は最終的にOpenClawのLLMバックエンド候補として使いたい。
OpenClawは別のMac miniで動いている。つまり、GX10上のローカルLLMサーバーを、Mac miniから安定して見えるようにする必要がある。
最初はMac Studioを経由したSSHトンネルでもつなげられる。ただ、常用する経路としては気持ち悪い。そこでGX10にもTailscaleを入れ、Tailnet経由で直接アクセスできるようにした。
公開記事なので実アドレスは伏せるが、考え方としては次のような形だ。
http://<gx10-tailnet-ip>:18081/v1
この経路に切り替えたあと、別マシンからGX10上のOpenAI互換APIに届くところまでは確認した。ただし、ここで注意がある。
モデルの /v1/models が見えることと、OpenClawのLLMバックエンドとして実用できることは別問題だ。下の接続経路が通っても、Telegram経由の表示、tool calling、実アプリ側のルーティングで別の問題が起きる。
この話は次以降の記事で分けて書く。第一回では、まず「専用機として起動し、更新し、GPUコンテナまで動かせる状態にした」までを区切りにする。
普通のLinuxマシンとNVIDIAアプライアンスの中間
触ってみた印象として、GX10の初期セットアップ自体は難しくない。
ただし、普通のUbuntuマシンとしてだけ見ていると取りこぼすところがある。Dashboardの更新表示、DGX関連パッケージ、NVIDIAドライバ、firmware更新、GPUコンテナ確認まで見る必要がある。
一方で、完全に家電として扱えるわけでもない。DashboardがLAN直で開くとは限らないし、アップデート途中の状態を dpkg や apt で直す場面もある。
つまり、普通のLinuxマシンとNVIDIAアプライアンスの中間のような扱いになる。
それでも、SSH、Dashboard、GPUコンテナまで確認できると、一気に触りやすくなる。ここから先は、いよいよローカルLLMサーバーやOpenAI互換APIの実験に入れる。
そして次の記事では、最初にかなり意外な結果が出た。GX10の方が明らかに速いと思っていたのに、Gemma 4 31B同士で比べるとMac Studioの方が速かった。
ローカルAI専用機としての評価は、単純に「NVIDIAだから速い」で終わらない。そのあたりを、次回は実測値込みで書く。
