kirintropのブログ

はるか遠いミニマリストへの道です。

3台クラスタにDeepSeek-V4.1-Flashを載せて運用を試みる話。

3台クラスタにDeepSeek-V4.1-Flashを載せて運用を試みる話。

自宅の検証環境において、ThinkStation PGXおよびDPMを組み合わせた3ノード構成(合計384GB Unified Memory)を組み、大型モデルである「DeepSeek-V4.1-Flash」をテンソル並列(TP=3)で稼働させました。

結論から述べると、モデル自体はメモリ上に正常に乗り、1Mトークン(1,048,576トークン)のロングコンテキストでも実推論が通ることを確認できました。しかし、日常運用の常用インフラとして評価した場合、「実用として使い続けるのは難しい」という判断に至りました。

その理由と、クラスタ構築から運用検証までに判明した技術的な知見を整理します。

3台クラスタの構成と起動検証

まず、今回のクラスタ構成と各ノードの割り当ては以下の通りです。

ノード名 ハードウェア メモリ 役割
DPM ThinkStation PGX相当 (GB10) 128GB Unified Memory Headノード (vLLM Master)
PGX1 ThinkStation PGX (GB10) 128GB Unified Memory Worker 1
PGX2 ThinkStation PGX (GB10) 128GB Unified Memory Worker 2

合計メモリ容量は 384GB となり、テンソル並列数(Tensor Parallelism)を 3 に設定して vLLM を起動しました。

物理配線は PGX1 <=> DPM <=> PGX2 の直列トポロジーとなっており、中継ノード(DPM)を経由する構成です。ConnectX-7 NIC による RoCEv2(RDMA)通信は、直列ルーティング時のパケット転送仕様により制約があったため、200GbE ネットワーク上のカーネル TCP/IP ソケット経由で NCCL 通信を確立させました。

起動スクリプトを実行した結果、各ノードのメモリ消費量は以下の数値で安定しました。

DPM (Head) : 109,335 MiB
PGX1       : 109,297 MiB
PGX2       : 109,351 MiB

各ノード約110GBを占有し、vLLM の健全性チェックおよび API 経由での日本語チャットテスト(Reasoning 出力を含む)が正常に応答することを確認しました。

1Mコンテキストの成立とMLAの特性

DeepSeek-V4.1-Flash の特長として、MLA(Multi-head Latent Attention)アーキテクチャの採用が挙げられます。

従来の MHA(Multi-head Attention)と比較して KV キャッシュのフットプリントが非常に小さく抑えられます。そのため、コンテキスト長を 1M(1,048,576 トークン)に拡張した場合でも、追加で必要となる KV キャッシュ領域は約 2GB 程度にとどまります。

各ノードのメモリ空き容量(約18GB)の範囲内に余裕で収まり、長大なコンテキスト窓を指定した状態でもクラスタは問題なく稼働しました。スペックシートやベンチマークの観点では、「384GB 環境で DeepSeek-V4.1-Flash の 1M コンテキストが動作した」と言えます。

なぜ「使えない」のか

しかし、この環境を日々のローカル開発や常駐エージェントの基盤として運用しようとすると、複数の実用上の問題が生じます。

1. メモリ余力(ヘッドルーム)の枯渇

各マシンの搭載メモリは 128GB ですが、モデル重みだけで約 110GB を消費します。残りのメモリは約 18GB ですが、ここから OS の基本プロセス、バッファ、Docker デーモン等の基盤領域を差し引くと、実質的に利用可能な空き容量は 10GB 前後にまで狭まります。

また、モデル重みのサイズそのものはテンソル並列で分割してもこれ以上削減できないため、「設定でモデルのメモリ消費をさらに絞る」というアプローチが取れません。

2. 並行処理・別モデルとの共存不能

ローカル環境では、LLM 単体だけでなく、用途に応じた別モデル(軽量な補助モデルや各種推論タスク)やデータ処理ジョブを並行して実行したい場面が多々あります。

しかし、空きメモリが 10GB 前後しかない状態では、少しでも追加でメモリを要求する処理が走った瞬間に OOM(Out of Memory)が発生するか、プロセスが不安定になります。

「大型 LLM 単体は動いているが、そのマシン上で他のタスクや追加ジョブを並行稼働させる余裕が全くない」という極めて窮屈な状態に陥ります。

3. 3ノード占有によるクラスタ運用の硬直化

DPM、PGX1、PGX2 の 3 台すべてを単一モデルのテンソル並列に割り当てると、クラスタ全体がそのモデル専用にロックされます。一部のノードを別の軽量な推論やバッチ処理に柔軟に回すことができず、システム全体のリソース効率が低下します。

運用上の比較と結論

日常運用の観点から、2ノードで運用している GLM-5.3-Flash(TP=2)との比較を行いました。

項目 DeepSeek-V4.1-Flash (TP=3) GLM-5.3-Flash (TP=2)
稼働ノード数 3台 (DPM + PGX1 + PGX2) 2台 (DPM + PGX1)
ノードあたりメモリ消費 約 110GB / 128GB 約 60GB / 128GB
残余メモリ (ヘッドルーム) 約 10GB〜18GB(極小) 約 60GB以上(潤沢)
他タスク・別モデルの並行実行 OOM のリスクが高く不可 余裕をもって常時並行可能
運用実用性 実験・検証向き 実務・常駐運用に最適

GLM-5.3-Flash であれば、ノードあたり 60GB 以上の空きメモリが確保できるため、他の推論やバッチ処理を同時に走らせても何の影響も受けません。

結局のところ、巨大モデルを動作させること自体が目的であれば「3台クラスタで DS41 稼働」は成功ですが、日々のタスクを回す実用的なインフラとしては、メモリのヘッドルームが足りなすぎました。

まとめ

ハードウェアのスペック上限ギリギリまでモデル重みを詰め込むと、カタログ上の数字は満たせても、システム全体の柔軟性が損なわれます。

実運用においては、モデル自体の性能だけでなく、**「同じマシン上で他の処理や追加ジョブが同時に動けるだけのメモリ余白(ヘッドルーム)を残せているか」**が極めて重要であると再認識しました。

現在は、日常の常駐環境としてはメモリに余裕のあるモデル構成を基本とし、用途に応じてクラスタ構成を使い分けることで安定性を保っています。

じゃあね。

3台クラスタを組んだ直後に4台目のDGX Sparkを欲しがる話。

3台クラスタを組んだ直後に4台目のDGX Sparkを欲しがる話。

つい先日、3台目のDGX Sparkを調達し、卓上に3段スタックのクラスタ環境を構築したばかりである。

各ノードの背面にある200Gb/sポートを0.5mのパッシブDACケーブルで三角形に直結し、高価な外部スイッチを介さないスイッチレス・フルメッシュ構成が完成した。

ケーブル規格は200GのQSFP56(50Gbps PAM4 × 4レーン)。そもそもホスト側のPCIe内部バス(Gen5)の実効帯域が約112Gbpsで律速しているため、外部インターコネクトとしては200GのQSFP56で帯域の上限に完全に達している。

巨大なオープンモデルを手元の卓上環境だけで分散推論させ、トークンが生成される様子を端末上で確認した瞬間は、確かに一定の達成感があった。

しかし、その安定稼働を確認したわずか数日後、思考の片隅に湧き上がってきたのは「4台目が欲しい」という、極めて不可解な欲求だった。

言うまでもなく、このクラスタで何か事業を行っているわけでもなければ、受託案件を処理しているわけでもない。マネタイズの目処は完全にゼロである。それにもかかわらず、なぜ次のノードを求めてしまうのか、その心理と技術的な障壁について整理してみた。

3台構成という「奇跡的な均衡」

技術的な観点から見ると、DGX Sparkによる3台クラスタは、ハードウェアの幾何学およびネットワークトポロジにおいて極めて美しいスイートスポットに位置している。

DGX Sparkには背面に2つのQSFP56ポート(Port 0 / Port 1)が備わっている。3台あれば合計で6ポートとなり、次のように完全な閉ループ(三角形のフルメッシュ $K_3$)を構成できる。

Node 1 (Port 0) <---> (Port 1) Node 2
Node 2 (Port 0) <---> (Port 1) Node 3
Node 3 (Port 0) <---> (Port 1) Node 1

この構成の最大の強みは、200Gbpsという広帯域かつ超低レイテンシなインターコネクトを外部スイッチなしで完結できる点にある。全ノード間が1ホップの直結であり、遅延もボトルネックも存在しない。

また、物理的なフットプリントの面でも、段間に20mm厚の耐熱シリコンインシュレーターを挟んで縦積みにすることで、幅15cm×奥行15cm×高さ約20cmというコンパクトな卓上タワーに収まっている。電源管理も既存の家庭用配線の許容範囲内に収まっており、システム的にも環境的にもこれ以上ない均衡が保たれている。

4台目に立ちはだかるスイッチ問題と、MikroTikの悪魔

では、ここに「4台目」を追加するとどうなるのか。

4ノードの完全フルメッシュ(全対全の直結)を組もうとすれば各ノードに3ポートが必要になるが、Sparkには2ポートしかない。スター型で全ノードを束ねるなら外部スイッチが必要になる。

エンタープライズ向けのNVIDIA Quantum(QM8700等)やSpectrum-2スイッチは、中古市場ですら50万〜80万円コースであり、250W以上の消費電力と70dBを超える爆音ファンが家庭内環境を破壊する。

だが、ここでタチが悪いことにMikroTikの存在が浮上してくる。

400Gスイッチである「MikroTik CRS804-4DDQ-hRM」は、400G QSFP56-DDポートを4基備え、RoCEv2(PFC/ECN)に対応しながら、最大消費電力は約123Wと極めて大人しい。そして「QSFP-DD to 2xQSFP56 DAC」のブレークアウトケーブルを使えば、4ポート×2で最大8台までの200Gノードを収容可能なのである。

さらに、個人輸入(欧州免税+送料・消費税)での着地相場は約18万円前後。データセンター向けスイッチの数百万円という世界を見慣れた目には、「ちょっと背伸びすれば手が届いてしまう絶妙な価格設定」に見えてしまうのだ。

構成 トポロジ 必要機材 機材コスト 収容上限
3台構成(現在) フルメッシュ($K_3$) 200G DAC × 3本 0円(スイッチ不要) 3台まで(限界)
4台構成(リング直結) 双方向リング直結(Ring) 200G DAC × 4本 数万円(ケーブル代のみ) 4〜5台が実用限界
4〜8台構成(MikroTik) スター型(CRS804) CRS804 + ブレークアウトDAC 約18万円〜 最大8台(1024GB)

スイッチを導入しない現実解として、デュアルポートを活かした「4ノード双方向リング直結(Node 1 ⇄ 2 ⇄ 3 ⇄ 4 ⇄ 1)」も存在する。

PyTorchやvLLMがテンソル並列(TP)で行う通信アルゴリズムは隣接ノードへバケツリレーを行う「Ring AllReduce」であるため、物理リングでも実効スループットの落ち込みは小さく抑えられる。さらに、主要LLMのアテンションヘッド数はほぼ2の冪乗であるため、TP=3では分割しづらかったモデルがTP=4なら100%ネイティブに適合する。

「ケーブル追加だけで4台リング直結にするか」「いっそMikroTikを入れて最大8台(1TBメモリ)の拡張性まで手に入れるか」――どちらを選んでも技術的に美しく成立してしまう点が、物欲に次々とガソリンを注ぎ込んでくる。

何も回収できないのに、なぜ欲しくなるのか

メモリ容量で見ても、4台で合計512GB、もし8台までいけば1024GB(1TB)という途方もないUnified Memory空間が手に入る。

Llama-3.1-405B FP4(約230GB)を余裕で卓上に常駐させ、長大なコンテキストを食わせてもビクともしない環境が自宅に完成する。

……と、ここまでもっともらしい技術的理由を並べ立ててみたが、最大の問題は冒頭に述べた通り「1円も稼げていない」という現実である。

一般的な投資の論理に従うならば、ハードウェアの増設は需要の逼迫やキャパシティ不足、あるいは追加投資に見合う売上増が見込める段階で行われるべきものである。しかし、自宅の卓上で動かしているローカルクラスタには、顧客もいなければSLAも存在しない。

推論コストの観点だけで比較すれば、必要な時だけクラウドのAPIを呼び出す方が圧倒的に経済的である。毎月の電気代を垂れ流し、本体の減価償却を受け入れながらローカルで動かす行為に、経済的な合理性は1ミリも存在しない。

それにもかかわらず4台目が欲しくなる理由は、ひとえに「インフラの構築とパラメータ空間の拡張そのものが目的化している」からに他ならない。

「動かすタスクがあるからマシンを買う」のではなく、「マシンを増やしてトポロジの対称性を高め、512GB以上のメモリ空間を手に入れたいから理由を探す」という逆転現象が起きている。

結論として

4台目の購入ボタンを押す前に、客観的な事実をもう一度並べておく。

  • 3台クラスタの直結メッシュは現在最も効率的な状態で稼働している
  • 4台構成を組むならリング直結という安価な現実解があるが、卓上タワーの高さは約27cmに達し、電源の余裕も削られる
  • MikroTik CRS804による8台収容構想は魅力的だが、納期は約2ヶ月待ちであり、本体代に加えてスイッチ代(約18万円)が上乗せされる
  • 何より、投じた費用を回収する手立ては一切存在しない

どれだけ好意的に解釈しても、現時点で4台目を調達する合理的理由は見当たらない。

まずは構築したばかりの3台アレイを限界まで使い倒し、DeepSeek等のモデルを用いた分散推論の通信ボトルネックや並列化効率の測定を徹底的に行うべきである。

机の上の3段タワーを眺めながら、湧き上がる物欲が引いていくのを静かに待つことにしたい。

じゃあね。

DGX Sparkのインターコネクトに高価なQSFP112ではなくQSFP56 DACケーブルを選ぶ話。

NVIDIAの小型デスクトップAIスーパーコンピュータ「DGX Spark」の導入にあたり、複数台をクラスタ化するためのノード間インターコネクトケーブルの手配を進めた。

公式カタログや国内代理店の案内では、400G対応の最新規格である「QSFP112」パッシブDACケーブル(ELSA TS000111等)がクラスタリング用アクセサリーとして指定されている。しかし、国内の一般流通市場では在庫切れや極端な品薄が続いており、入手性が著しく悪い。

仕様書と物理層(PHY)の仕様を詳細に確認した結果、DGX Spark本体の通信上限は200Gb/sであり、前世代の「200G QSFP56」DACケーブルで帯域の損失なく完全に代替できることが確認できた。規格の混同による誤購入のリスクと、実用的なケーブル選定の記録。

1. 「QSFP112」の入手難と検索時の落とし穴

DGX Sparkを2台または3台直結(三角形のリングトポロジ)でクラスタ化する場合、背面にある2基のConnectX-7ポート同士をダイレクトアタッチ銅線(DAC)で直結する。

しかし、指定されている「QSFP112」規格で検索を行うと、一般のECサイトでは以下のような罠に直面する。

規格名 物理嵌合 結果と注意点
QSFP112 装着可 公式指定の400G規格。流通量が極めて少なく、国内在庫はほぼ全滅。
OSFP / OSFP-RHS 不可 DGX H100等の大型サーバー用。端子サイズが大きくヒートシンク形状も異なるため物理的に挿入不能。
QSFP-DD 不可 接点が前後2列(8レーン)の別規格。QSFP112ポート側には端子が奥まで入らず物理破損のリスクがある。

Amazonや一般通販で「400G DAC」「ConnectX-7 ケーブル」と検索すると、上位にヒットするのはほぼ全てOSFP-RHSやQSFP-DDであり、これらを購入すると物理的にポートに挿さらない事態に陥る。

2. QSFPファミリの物理寸法と電気的互換性

「QSFP112」という新しい型番名から別形状のコネクタと誤解されがちだが、外形寸法およびポートケージの物理構造は従来の4レーン系QSFPと完全に同一である。

規格 総帯域 レーン構成 外形寸法・ピン配列
QSFP28 100Gb/s 25G NRZ × 4 完全同一(SFF-8665準拠)
QSFP56 200Gb/s 50G PAM4 × 4 完全同一(SFF-8665準拠)
QSFP112 400Gb/s 112G PAM4 × 4 完全同一(SFF-8665準拠)

USB-A端子がUSB 2.0から3.0へ形状を変えずに高速化したのと同様に、QSFP112は内部の信号伝送レートを引き上げた規格であり、「QSFP112ポートにQSFP56ケーブルを挿入する」ことは物理的にも規格上も何ら問題がない。

3. DGX Sparkの帯域上限とケーブル選定の考え方

DGX Sparkに搭載されているConnectX-7インターフェースは、背面のクラスタポートにおいて最大200Gb/sで動作する設計となっている。

仕様上は200G上限であるのに対し、なぜ公式アクセサリーとして400G対応のQSFP112ケーブル(TS000111等)が案内されているのかについては、いくつか技術的・運用的な背景が考えられる。

  • コネクタケージ規格との整合性: 本体の物理ポートがConnectX-7の世代に合わせてQSFP112ケージを採用しているため、公式アクセサリーの型番としてもポート規格の表記に合わせたケーブルを用意している可能性。
  • シグナルマージンの確保: より高周波・低損失を前提とする400G基準のケーブルを指定することで、200G伝送における信号品質や接続信頼性のマージンを広く取る設計思想。
  • エコシステム側の世代移行: サーバー・データセンター向けネットワーク部材全体が400G以上へシフトしており、ベンダー側の検証済み部材ラインナップが最新規格側に揃えられている影響。

公式の推奨背景にはこうした品質や整合性の考慮があると考えられるが、内部バスやリンク速度の実効仕様が200Gb/sである以上、物理的・プロトコル的に下位互換を持つQSFP56パッシブDACを接続した場合でも、通信速度のボトルネックが生じるわけではない。

4. 結論と実用的な選定

以上の検証から、品薄なQSFP112を無理に探す必要はなく、市場に潤沢に流通している200G QSFP56 パッシブDACケーブル(0.5m)を採用するのが最も合理的であるという結論に至った。

型番としては、NVIDIA/Mellanox純正およびその互換品である`MCP1650-V00AE30`(0.5m / 30AWG)が確実である。卓上3段スタック時の高低差(約14cm)を考慮しても、0.5mが余長を最小限に抑えられる最適な長さとなる。

なお、DGX Sparkには独立した10GbE RJ-45管理ポートも搭載されているため、DACケーブルの手配が本体到着に遅れる場合でも、初日のOSセットアップや初期動作確認、10GbE経由での分散クラスタ構築は通常通り実施可能である。

じゃあね。

自宅の2台のGB10で320Bモデルを動かすまでの話。

自宅の2台のGB10で320Bモデルを動かすまでの話。**

環境は2台のGB10マシン(以下、ノードA・ノードB)をConnectX-7の200GbEで直結した2ノード構成。目標はNVIDIAのGLM-5.3-Flash(総パラメータ320B、アクティブ18BのMoE、FP4量子化でウェイト177.4GB)をtensor parallel 2でvLLMに載せること。結論から言うと、載せること自体は2日目で成功した。問題はその後だった。この記事は、起動に至るまでの試行錯誤を、Hermes(自作のCLIエージェント)とagy(Google Antigravity CLI)それぞれがどう関わったかを含めて淡々と記録したもの。

前提:まず177GBを2台に配る

10/20にモデルの仕様調査とダウンロードを開始した。ノードB側のHugging Faceキャッシュはコンテナ実行時代の権限残りで`.locks`への書き込みに失敗したので`sudo chown`で解消し、`hf download --max-workers 8`で約31MB/sを確認。177GBのダウンロードを開始して完了後に200GbEのraw TCPスクリプトでノードAへ同期、`recipes/glm-5.3-flash.yaml`というレシピ1枚で2ノード起動できる下準備を終えた。

この時点で1つだけ教訓があった。クラスター診断中にb12xカーネルコンパイルの負荷でノードAがOOMガード(`vm.panic_on_oom=1`)を検知してリブートしたこと。この「ロード中のメモリ圧迫」は後々まで付き合うことになる。

第1の壁:NVRM OOMとGB10の実用水位

初回起動試行は`gpu_memory_utilization: 0.87`で失敗した。`NVRM NV_ERR_NO_MEMORY`。GB10はunified memoryでドライバが実質確保できる水位が理論値より低く、実用水位は約101GB。177.4GBをTP2で89GBずつ載せる設計だと、0.87はOOM確定だった。安全値は0.82に落ち着いた。

もう1つの症状は「起動途中で落ちる」ように見える現象。dmesgを遡るとノードB側のカーネルOOMキルが残っていて、原因はb12xローダーの`io_threads=8`が作るbounce bufferだった。`io_threads=2`と`drop_caches`で対抗した。

ここで一番大事だったのは、ユーザーの観察「240秒で止まる」「GPUがスリープしてる」を追った結果、b12xローダーが3フェーズ構造(CPU側routing → GPU転送 → compile)で動いていて、序盤0〜4分はGPUがidle表示になるのが正常だと判明したこと。つまり「固まって見える」のは正常ロードで、ユーザーが何度か実施した手動リブートは正常なロードを処刑していた。朝の07:28に成功実績があったことで「載る」こと自体は証明済みだった。

第2の壁:30秒で「失敗」と言う監視スクリプト

起動を1コマンド化するにあたり、メイン端末側からSSHでノードAの検証済み起動スクリプトに委譲する薄いオーケストレータ(`launch.sh`)と、GLM単独起動の`glm`コマンドを新設した。設計方針は「判定の実体はノードA側の`start_vllm_cluster.sh`に委譲し、二重実装しない」。

で、いざ起動すると「qwenもglmも30秒でエラー表示を出して宛にならなくなった」。実推論プローブやコンテナの作成時刻を調べると、コンテナは生きていて起動も継続中。`/var/log/auth.log`でSSHセッションのフォレンジックをすると、起動スクリプトのセッションが40.5秒で消滅していて、fail-fastの初回チェック(elapsed=30)と一致した。

根本原因は、スクリプト内のworker死活判定が「SSH一発失敗=即dead」。b12xのフェーズ1でCPUが飽和している間はノードBのsshdやdockerdの応答が遅れるので、正常にロード中なのに「DPM worker died」と誤判定して起動処理を中断していた。さらに掘ると、進捗表示の`grep`が0一致のときexit 1になり、`set -e`+`pipefail`の下でパイプラインごとスクリプトが死ぬ地雷も見つかった(これもGLM試行で連続して踏んだ。Qwenは30秒時点で進捗行がヒットするので潜伏していた)。

対策は死活判定の4値化(running/dead/missing/unreachable)、ConnectTimeout延長、3回リトライ、初回チェック60秒、連続2ラウンド非生存で確定、という3点セット。真の死亡でもfail-fastは60〜100秒で維持できる。

第3の壁:人間側の「固まった」誤認

監視側を直しても、ロードが7〜10分かかるGLMでは待っている側の問題が残った。dotsの進捗表示が数秒止まるだけで「固まった」と誤認して手動リブートされる事故の再発を防ぐため、進捗表示を毎秒回るASCIIスピナー(`| / - \`)に変え、実進捗行の印字時にはスピナー行を`\r\033[K`で消して崩れを防ぐ実装にした。起動待ちのタイムアウトも1500秒から2400秒へ引き上げた。

加えて、静的コード監査(Hermes側のサブエージェントで実施)の段階で2つの潜在バグを未然に摘出した。1つはDS4(別の推論サーバー)が~110GBのGPUメモリを握ったままvLLMを起動する競合経路。こちらは全起動経路が通る単一関門側に既にガードが入っていたため、重複実装せず所有箇所をコメントで明文化するだけにした。もう1つは`hermes.sh`のSSH起動にPTY(`-t`)がなく、バッファリングで進捗出力が全詰まりしてハング誤認を招くリスク。`-t`を追加して解消した。

第4の壁:HF CDNへのハング

ツールが整った後の起動失敗は、意外な場所だった。ノードB(head)側のAPIServerがHugging FaceのCDN(CloudFront)へのsocket readで永久ストールし、分散学習のrendezvousポート(29501)が開かず、ノードA(worker)側が600秒タイムアウトで`DistNetworkError`でクラッシュ。`gdb`でメインスレッドを見ると`BIO_read()` -> `read()`で止まっていて、`ss -tp`でCDNへの接続がESTABLISHEDのまま凍結しているのを確認できた。

ウェイトは全部ローカルキャッシュにあるのだから外部に問い合わせる必要はゼロ。`HF_HUB_OFFLINE: "1"`をレシピに追加してCDNとの通信を遮断したところ、352秒で安定起動し実推論も確認できた。

付録:マルチモーダル版は載らなかった

最後にマルチモーダル版(vision tower付き)を試したが、これは起動に失敗した。177.4GB前後のギリギリ設計にvision分のweightが追加で載るためNVRM OOMが濃厚という推定で、テキスト版を正典として確定させた。使うならrecipeの再設計が前提になる。

エージェントの役割分担

この一連の作業を、Hermes(自作CLIエージェント、ローカルvLLMバックエンド)とagy(Google Antigravity CLI)の2つのエージェントで進めた。それぞれの関わり方は次の通り。

Hermes側(調査・恒久修正の実装)**

  • メモリ内訳・dmesg・auth.logのフォレンジック調査、死活判定の書き換え、スピナー実装、`-t`追加、レシピ調整など、診断とコード修正を一括で担当
  • 修正は毎回`git commit`で残し、`bash -n`や関数単体テストで検証してから適用

agy側(司令塔とクォータ事情)**

  • 作業の司令塔として使ったが、裏側でコストが発生していた。ある1セッションだけで534回のAPI通信・1,734ステップ・会話ログ1.8MBに肥大化し、週次クォータを1日で枯渇させた
  • ユーザー発言は82ターンなのに、エージェントが自律的にツールループを回して雪だるま式にコンテキストが膨らむのが大量消費の真因だった
  • この原因分析を受けて、多ステップ作業(5ステップ以上)やエラー修正ループはHermesへ下請け委託するラッパー(`hermes_worker`)を整備し、コード編集は最小差分原則(指示範囲外の改変禁止、完了前の`git diff`自己検証)をルール化した
  • また、常駐モデルを勝手に起動してメモリを食わないよう、vLLMのGLMが居ればそれを優先し、無ければOllamaの常駐モデルを使い、どちらも無ければ安全停止する`aider_local`ラッパーも整備。GLMロード中にOllamaが44GB掴んでいたのを検知して即アンロードし、空き111GBを確保して起動を守った実例もある

まとめ

起動に至るまでに潰した障害を振り返ると、次の5つに集約される。

  • GB10のドライバ実用水位が理論値より低く、util 0.87ではOOM → 0.82へ
  • b12xローダーのio_threads=8がカーネルOOMを招く → 2へ
  • SSH一発失敗を「worker死亡」と誤判定するfail-fast → 4値化+リトライ
  • 進捗grepの0一致でスクリプトが即終了する地雷 → `|| true`で恒久化
  • HF CDNへのsocket readハング → `HF_HUB_OFFLINE=1`で遮断

そして全部に共通するのは「正常に動いているのを、見え方の問題が壊していると誤認する」構造だった。GPUのスリープ表示、数秒止まる進捗、30秒の誤エラー。どれも実体は正常で、監視と表示側の嘘が手動リブートを誘発していた。起動は352秒で安定し、現在は512kコンテキストで常駐運用している。

終わってみれば1つずつは小さい修正だが、どれも放置すると「起動できないモデル」のままだった。ログが残っていることと、直感で「おかしい」と言い続けてくれるユーザーの2つがあったから、全部剥がせた。じゃあね。

Galaxy Z Fold 4でrootを取らずにTermuxを快適運用する話。

Galaxy Z Fold 4でrootを取らずにTermuxを快適運用する話。

Galaxy Z Fold 4を開いたときの大画面は、外出先やリビングでターミナルを叩いたり、AIと対話してコードを書かせたりする環境として非常に見通しが良い。

ただ、Android上で本格的なCLI環境を構築しようとすると、「root化しないと不便なのではないか」「画面のソフトウェアキーボードだとミスタイプが頻発してストレスが溜まる」「スリープで接続が切れる」といった実用上の壁に直面しやすい。

今回は、セキュリティや日常利用の利便性を損なわない完全「非root」環境を前提に、Termuxを母艦サーバー(ThinkStation PGX)直結の超快適ターミナルとして仕立て上げた。その構成と設定手順を記録しておく。

環境と全体構成

今回の構成は以下の通りである。

項目 構成 役割・備考
クライアント端末 Galaxy Z Fold 4(Android 14 / One UI 6) 完全非root。メイン機として通常運用
ターミナル環境 Termux(F-Droid版) Google Play版は更新停止のためF-Droid版が必須
ネットワーク Tailscale メッシュVPN経由で外出先からも母艦に直結
作業母艦サーバー ThinkStation PGX(Ubuntu Linux) LLM推論・開発環境・tmuxセッションのホスト

root化は一切行わない。F-Droid版のTermuxとTailscale、そして適切な設定を組み合わせるだけで、母艦との双方向接続や快適な操作感は十分に確立できる。

課題1:文字入力ストレスを根絶する「8×3完全整列キーバー」

スマートフォンでCLIを運用する際、最大のストレスになるのが「画面上のソフトウェアキーボード(Gboard等)でのタイピング」である。物理的な突起がないためミスタイプが多発し、特にAIエージェントとの対話で頻出する番号選択や定型指示を毎回手打ちするのは耐え難い。

そこで、Termuxの拡張キーバー(Extra Keys)を「8×3=24キー」の完全整列グリッドに再構築した。各行のキー数を8個に統一することで、幅の不揃いによる視認性の悪化を防ぎ、さらに右親指が最も自然に届く右端エリアに最重要アクションを集約している。

実際に運用している最終設定(`~/.termux/termux.properties`)は以下の通りである。

# ~/.termux/termux.properties on Galaxy Z Fold 4

allow-external-apps = true
bell-character = ignore

enforce-char-based-input = true
ctrl-space-workaround = true
disable-hardware-keyboard-shortcuts = true

# キーバー(Extra Keys)の高さスケーリング(誤タップ防止のため最大値)
terminal-toolbar-height = 3.0

# セッション操作ショートカット
shortcut.create-session = ctrl + t
shortcut.previous-session = ctrl + 1
shortcut.next-session = ctrl + 2

# 8×3 完全整列グリッド(実戦投入の最終レイアウト)
extra-keys = [ \
  [{macro: "1 ENTER", display: "1"}, {macro: "2 ENTER", display: "2"}, {macro: "3 ENTER", display: "3"}, {macro: "4 ENTER", display: "4"}, {macro: "agy ENTER", display: "agy"}, {macro: "ar ENTER", display: "ar"}, {key: ENTER, display: "Enter"}, {macro: "keepして次のセッション ENTER", display: "KEEP"}], \
  ["ESC", {macro: "CTRL 1", display: "◀"}, {macro: "CTRL t", display: "+"}, {macro: "CTRL 2", display: "▶"}, "HOME", "UP", "END", {macro: "ブログ記事にして ENTER", display: "BLOG"}], \
  [{key: PASTE, display: "PASTE"}, {macro: "CTRL e CTRL u", display: "CLR"}, {macro: "CTRL c", display: "C-c"}, {macro: "e ENTER", display: "EXIT"}, "LEFT", "DOWN", "RIGHT", {key: KEYBOARD, display: "KB"}] \
]

# URLタップで直接ブラウザを開く
terminal-onclick-url-open = true

このレイアウトにより、ガラス面にキーボードを広げることなく、親指タップだけで以下の操作が完結する。

  • 最上段(対話・起動・決定):

- `1` 〜 `4`: AIエージェントからの選択肢提示で頻出する1〜4をワンタップで番号送信。
- `AGY`: Antigravity CLIを即時起動(`agy` マクロ)。
- `AR`: CLIセッションの再開・リロード(`ar` マクロ)。
- `ENTER`: ソフトウェアキーボードを開かずにコマンドを即実行できる物理Enterキー。
- `[ KEEP ]`: 会話ログの永続化と引き継ぎマクロ(`keepして次のセッション`)を一発実行。

  • 右親指最強アクションゾーン(右端の縦3列):

- 右上 `[ KEEP ]`: セッション記録&引き継ぎ。
- 右中 `[ BLOG ]`: ブログ記事執筆マクロ(`ブログ記事にして`)。
- 右下 `[ KB ]`: 必要な時だけソフトウェアキーボードを開閉。

  • 中段・下段:

- タブ(ウィンドウ)の新規作成(`+`)や巡回(`◀` `▶`)、HOME / END / 十字キー、クリップボード貼り付け(`PASTE`)、行クリア(`CLR`)、シグナル中断(`C-c`)、セッション終了(`EXIT`)を網羅。

通常時はソフトウェアキーボードを完全に閉じ、キーバーのボタンをタップするだけで対話や運用が進むため、ガラス面タイピングによる疲労とミスタイプを物理的に根絶できる。

画面分割は不要。大画面は「1画面フル活用」と「タブ切り替え」が正解

大画面の折りたたみスマホを手に入れると、ついPCと同じようにtmuxで画面を縦横に分割(ペイン分割)したくなる。

しかし、実際に運用してみると画面分割は全く使わなくなった。

いくら大画面といってもスマートフォンである。画面を半分に割ってしまうと一行あたりの文字数が極端に減り、コードやログが激しく折り返されてかえって視認性が落ちる。

結論として、「1つの作業画面を画面いっぱいに広々と表示し、並行作業が必要な場合はtmuxのウィンドウ(タブ)を増やして切り替える」という運用が最も合理的だった。

キーバー中段にある `+`(新規タブ作成)、`◀`(前タブ)、`▶`(次タブ)を親指でポチポチ切り替えるだけで、大画面の視認性を100%活かしたまま快適にマルチタスクをこなすことができる。

課題2:WezTermライクな起動・終了ライフサイクル

PC上のWezTermのように、「アプリを開いた瞬間に母艦のtmuxセッションに直結し、画面は常にまっさらな新品状態から始まり、終了時はアプリごと綺麗に消える」という挙動をTermuxで実現した。

Termux側の `~/.bashrc` を以下のように記述している。

# ~/.bashrc on Galaxy Z Fold 4

# sshd の常時生存を保証
pgrep -f sshd >/dev/null || sshd

# スリープ中も切断されないよう常駐ロックを保証
termux-wake-lock 2>/dev/null || true

# 画面をクリアして、母艦側の古いセッションを破棄&新品作成
clear
ssh -t pgx "tmux kill-session -t zfold 2>/dev/null; tmux new-session -s zfold"

# SSHセッション終了時にTermuxアプリごと完全自動終了
exit

アプリをタップして起動した瞬間に画面がクリアされ、ThinkStation PGX上で `zfold` 専用のtmuxセッションが新規に立ち上がる。そして作業が終わったら `exit`(または下段キーバーの `EXIT` ボタン)を押すだけで、tmuxセッションが破棄され、SSHが閉じ、Termuxアプリ自体も自動で終了する。

課題3:クリップボード貼り付け時の書式崩れ対策

AndroidのTermux上で公開鍵や設定ファイルを投入する際、複数行テキストやヒアドキュメントをクリップボードから貼り付けると、改行が飛んで1行に結合されたり、スペースが欠落して文字列が破壊されるトラブルが起きやすい。

これを回避するため、初期設定や鍵の登録は「エスケープシーケンスを用いた単一行ワンライナー(printf)」で完結させる手法をとった。

# Termux側で実行:鍵登録とSSH config生成を1行で完結させる
printf "Host pgx\n  HostName <PGX_TAILSCALE_IP>\n  User <SERVER_USER>\n" > ~/.ssh/config && printf "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINgElS1KoYDMd/sU3RGBHK20uVNoAazKClpkjQQwjRBF <SERVER_USER>@<SERVER_HOST>\n" > ~/.ssh/authorized_keys && sshd

途中の改行判定や対話的プロンプトを挟まないため、貼り付け事故を決定論的に防止できる。

課題4:母艦からのスマホ遠隔操作と常駐の安定化

スマホから母艦に繋ぐだけでなく、母艦(PGX)側からもZ Fold 4のTermuxにいつでもSSHログインして設定変更やファイル同期ができるようにした。

1. TermuxのWake Lock確保:
`termux-wake-lock` を実行し、通知エリアに常駐させてスリープ時のCPU休止を防ぐ。
2. One UIのバッテリー最適化解除:
Androidの「設定」>「アプリ」>「Termux」>「バッテリー」を開き、「制限なし」に設定する。
3. 母艦側のSSH設定:
ThinkStation PGX側の `~/.ssh/config` に以下を登録する。Termuxのsshdはデフォルトでポート8022を使用する。

# ~/.ssh/config on ThinkStation PGX
Host zfold4 z-fold4
    HostName <ZFOLD4_TAILSCALE_IP>
    Port 8022
    User <ZFOLD4_USER>
    IdentityFile ~/.ssh/id_ed25519
    PreferredAuthentications publickey

これにより、母艦のターミナルから `ssh zfold4` を叩くだけで、スマホ内のTermuxシェルに直接入れるようになる。キーバー設定ファイル(`termux.properties`)の編集や更新もすべて母艦のキーボードから遠隔で行える。

タッチ操作・スクロール・URLタップの設定

画面分割は不要だが、大画面を活かしたタッチ操作やスクロールは非常に便利である。母艦側の `~/.tmux.conf` に以下の設定を追加した。

# ~/.tmux.conf on ThinkStation PGX

# タッチ・マウス操作の有効化(スクロール、コピー)
set -g mouse on
set -s set-clipboard on

# ウィンドウ(タブ)作成ショートカット
bind c new-window -c "#{pane_current_path}"

# 256色・TrueColor対応
set -g default-terminal "screen-256color"
set -ga terminal-overrides ",xterm-256color:Tc"

画面を指でスワイプするだけで過去ログのスクロールバックができる。また、ターミナル上に表示されたURLは、Termux側の `terminal-onclick-url-open = true` と組み合わせることで、タップするだけでAndroid標準のブラウザで開くことができる。

まとめ

Galaxy Z Fold 4のTermux環境を、root化を一切行わずに「母艦直結の快適ターミナル」として仕立て上げた。

  • 8×3完全整列キーバーにより、ソフトウェアキーボードを出さずにAI対話・選択肢送信を完結。
  • 画面分割はあえて使わず、大画面フル活用+タブ(ウィンドウ)切り替えに純化。
  • .bashrcの自動接続・終了スクリプトにより、起動時は即座に新品tmuxセッションへ直結し、終了時はTermuxごと自動消滅。
  • TailscaleとWake Lockにより、外出先からも双方向で安定したSSH接続を確保。

「大画面だからといってPCのようにペイン分割するのではなく、フルスクリーンの視認性とタブ切り替えを活かす」という割り切りを含め、実体験に基づく極めて合理的で実用的な開発環境に落ち着いた。

じゃあね。

単3電池駆動の多ボタンマウスとしてRazer Naga V2 HyperSpeedを使う話。

日常のPC作業やプログラミング、執筆作業において、多ボタンマウスは左手デバイスに並ぶ重要な入力デバイスである。

個人的なマウス選びの条件は昔から一貫している。
1. 無線接続(低遅延な専用USBレシーバー): Bluetoothの復帰ラグやスリープからの立ち上がり待ちを避けるため、2.4GHz帯の専用ドングルが必須。
2. 単3乾電池駆動(エネループ等の充電池運用): 内蔵リチウムイオンバッテリーは充電ケーブルの抜き差しが必要になり、数年でバッテリーの寿命(劣化・膨張)がマウスの寿命になってしまう。エネループを1本交換するだけで即座に100%復帰する運用が最も合理的である。
3. 親指で押せる豊富なサイドボタン: 最低でも6ボタン、できれば12ボタン前後のプログラマブルボタン。

かつてはLogicoolのG602を愛用し、その後に後継機であるG604を1個購入して運用していた。しかし、G604は生産終了(ディスコン)となり、市場から姿を消してしまった。

その後、Redragonやe-yooso(X-33)といった中華系の多ボタン無線マウスも試してみたものの、ビルドクオリティのチープさやレシーバー格納の甘さなど、常用するには惜しい点が散見された。

そうした「G604難民」の終着点として選んだのが、Razerの「Naga V2 HyperSpeed」である。実際に導入して使い込んでみたところ、懸念していたような癖もなく、意外なほど素直にちゃんと動き、非常に良い塩梅に落ち着いた。

G602・G604からNaga V2 HyperSpeedへの変遷

過去に運用してきた多ボタン無線マウスの系譜と、今回のNaga V2 HyperSpeedの仕様を整理すると下表のようになる。

機種名 発売元 電源方式 接続方式 サイドボタン数 現状・所感
G602 Logicool 単3電池×1〜2本 2.4GHz(専用レシーバー) 6ボタン 名機。長年愛用するもディスコン。
G604 Logicool 単3電池×1本 2.4GHz / Bluetooth 6ボタン 高速スクロール搭載。愛用したがこちらもディスコン。
X-33 e-yooso 内蔵バッテリー(Type-C) 2.4GHz / 有線 12ボタン 軽量で安価だが、ボタンの質感やレシーバーの出っ張りが気になる。
Naga V2 HyperSpeed Razer 単3または単4電池×1本 2.4GHz / Bluetooth 12ボタン 現行唯一の「乾電池駆動×サイド12ボタン」。ビルドクオリティ良好。

あえて「Pro」ではなく「HyperSpeed」を選ぶ理由

Razer Naga V2シリーズには、上位モデルである「Naga V2 Pro」と、本機「Naga V2 HyperSpeed」が存在する。

一般的なゲーミング用途では、充電ドック(Mouse Dock Pro)やQi充電に対応し、サイドプレートを2ボタン・6ボタン・12ボタンと物理的に交換できるProモデルがフラグシップとされる。しかし、作業用・道具としての合理性を突き詰めると、あえてHyperSpeedを選ぶ明確な理由がある。

1. バッテリー劣化からの解放:
Proモデルは内蔵バッテリー式のため、長期間の使用によるバッテリー寿命の低下を避けられない。HyperSpeedは単3形(または単4形)電池1本で駆動するため、エネループを使えば電池の寿命がマウス自体の寿命になることがない。
2. 充電ケーブル・ドックの排除:
机の上に充電ケーブルや専用ドックを配置する必要がなく、電池が切れたら予備のエネループと入れ替えるだけで数秒で満充電状態に戻る。
3. サイドプレート交換ギミックの排除による高剛性:
Proモデルのマグネット着脱式サイドプレートは柔軟な反面、経年による端子の接触不良や微妙なガタつきの原因になりうる。HyperSpeedはサイド12ボタンが完全に一体成型されており、剛性感が高く、強く握り込んでもきしみがない。

実際の使用感:意外とちゃんと動くし、これでいい

実際にデスクワークや日常の作業で使ってみて感じたポイントを挙げる。

オンボードメモリ内蔵でOSを選ばない

地味ながら決定的に使い勝手を左右するのが、オンボードメモリプロファイルを内蔵している点である。

あらかじめ設定ソフト(Razer Synapse)でサイドボタンのキー割り当てやDPIを設定しておけば、その構成がマウス本体側のメモリに保存される。設定後は常駐ソフトウェアを起動し続けておく必要がなく、設定ツールが存在しないLinux環境や別のPCにレシーバーを差し替えても、割り当てたキーやショートカットがそのまま完全に動作する。

専用の常駐プロセスに依存せず、ハードウェア単体で完結して自律動作してくれる安心感は、複数マシンを行き来するワークフローにおいて極めて大きい。

サイド12ボタンの配置とクリック感

12個のボタンはエルゴノミクス的に前後で傾斜がついており、親指の腹と先端の感覚だけでどの列のどのボタンかを識別しやすい。格安中華マウスのようなペコペコした安っぽいクリック感ではなく、しっかりとしたタクタイル感(クリック感)があり、誤爆しにくいチューニングになっている。

スクロールホイールとチルト機能

チルト(左右スクロール)に対応しているため、横スクロールやショートカットの割り当てにも便利である。また、スクロールモードの切り替えにも対応しており、カチカチとしたノッチ感のあるスクロールができる。

接続安定性と復帰ラグ

2.4GHz Razer HyperSpeed Wireless接続で使用しているが、PCのスリープ復帰時にも瞬時に追従する。Bluetooth接続特有の「スリープから復帰する際のワンテンポの引っ掛かり」がなく、有線と変わらない感覚で即座に入力を受け付ける。

重量バランス

単3形エネループを装填した状態での実測重量は約115g〜120g程度となる。超軽量(60g台など)がトレンドのFPS向けゲーミングマウスと比べればずっしりとした重みがあるが、作業用マウスとしては適度な安定感があり、カーソルがブレにくいため扱いやすい。さらに軽量化したい場合は、単4形エネループに単3変換スペーサーを噛ませることで数グラムの軽量化も可能である。

まとめ

Logicool G604が終売になって以降、「単3乾電池駆動」「2.4GHz低遅延無線」「多ボタン」という3拍子が揃ったマウスは事実上の絶滅危惧種となっていた。

Razer Naga V2 HyperSpeedは、その隙間を完璧に埋めてくれる現行唯一の選択肢である。奇をてらったギミックがなく、道具としての基本性能(センサー精度、接続安定性、ボタンの剛性感、そしてオンボードメモリによるポータビリティ)がしっかりしており、毎日使う仕事道具として「意外とちゃんと動くし、これでいい」という確かな満足感がある。

G602やG604の生産終了によって乗り換え先に悩んでいる多ボタン派には、有力な着地点としておすすめできる。

じゃあね。

NVIDIA DGX Spark各社の保証体系と修理リスクを比較検討する話。

NVIDIAのデスクトップAIスーパーコンピュータ「DGX Spark(GB10 Grace Blackwell Superchip搭載、128GB LPDDR5x)」。手元にある1台目のThinkStation PGX(128GB)に加え、200G直結クラスタによる合計256GB Unified Memory環境を構築するため、2台目の調達調査を進めていた。

国内・海外の各販売チャネルやメーカー製モデル(Lenovo、DELL、HP、ASUS、MSI等)を精査する中で、本体価格以上に購入判断を左右する決定的な要素となったのが各社の「長期保証の延長可否」と「修理リスク」、そして将来の「保証の譲渡性(リセール)」の違いだった。

超高額なAIワークステーションにおいて、なぜ「DELLかLenovoの二択」になり、次点がHPで、ASUSやMSIは敬遠せざるを得ないのか、その比較検討の経緯をまとめる。

一体型基板(BGA)が抱える構造的修理リスク

DGX Spark(GB10搭載マシン)を運用する上で、最も警戒しなければならないのがハードウェアの構造的制約である。

GB10プラットフォームは、極めて高い電力効率と広帯域を実現するため、以下の主要コンポーネントがすべて1枚のマザーボード上にBGA直付け(オンボード)されている。

  • Grace CPU(20コア ARM Neoverse V2)
  • Blackwell アーキテクチャ GPU
  • 128GB LPDDR5X ユニファイドメモリ
  • NVIDIA ConnectX-7 200GbE / InfiniBand NIC

ユーザーや保守員が物理的に交換できるパーツはM.2 SSDのみであり、CPU・GPU・メモリ・ネットワークコントローラのいずれか1箇所でも故障した場合、パーツ単位での修理や交換は一切行えない。すべて「マザーボード一式交換」となる。

もちろん、産業用・エンタープライズ品質のコンポーネントで固められているため「そう簡単に壊れるようなものではない」とは思う。しかし、万が一保証期間外にメインボード故障が発生した場合、主要パーツをすべて巻き込むため、実質的に本体を買い直すのと大差ない莫大な修理費用を請求されることになる。

本体は小型。重要なのは「修理形態」ではなく「長期延長と譲渡性」

ここで重要な前提がある。DGX Sparkは超高密度な卓上ミニPCサイズであり、巨大なタワー型ワークステーションやラックマウントサーバーとは根本的に異なる。

本体が非常にコンパクトであるため、故障時にわざわざ技術者が自宅に来る「オンサイト(訪問修理)」である必要性は薄く、箱に詰めて送る「センドバック(引き取り修理)」で全く困らない。

問題の本質はオンサイトかセンドバックかではなく、以下の2点に尽きる。

1. 長期保証(最長3〜5年)の延長手段が用意されているか:
1年が経過した瞬間に保証の梯子を外され、基板故障リスクを個人で丸抱えすることにならないか。
2. その保証が本体に紐づいて第三者へ譲渡できるか(リセール性):
将来手放す際、次のオーナーに保証を引き継ぐことで機材の資産価値を維持できるか。

各メーカー・販売チャネルの保証と譲渡性比較

主要各社からリリースされているGB10マシンの保証体系と、個人導入・リセールにおける条件を比較した。

なお、標準保証の年数や初期グレード(1年引取〜3年オンサイト等)は、購入ルート(メーカー直販CTO、特定代理店のパッケージ型番、量販店流通等)によって異なる場合が多い。そのため、ここでは初期保証の内容そのもの以上に、「後から最長3〜5年の長期保守を付加・延長できるか」、そして「その保証が本体に紐づいて他人に譲渡・継承できるか」を軸に整理している。

メーカー / モデル 標準保証の傾向(流通・型番依存) 長期保証(3〜5年)の延長可否 保証の譲渡性(リセール) 総合評価
DELL
Dell Pro Max with GB10
流通型番により3年 ProSupport(翌営業日オンサイト+SSD返却不要)が標準付帯する構成あり 出荷後5年以内であれば有償での延長・再契約が可能。 ◎ 所有者移転(Ownership Transfer)制度が公式に完備 本命(2強)
手厚い保守パッケージが存在し、リセール時も公式手続きで保証を引き継げる。
Lenovo
ThinkStation PGX
標準は1年〜3年保証等(構成依存) Webで即時購入可能
最長5年(2030年まで)+SSD返却不要へ手頃な追加費用でアップグレード可能
◎ シリアル番号紐付けで本体に保守が残存 本命(2強)
保守追加の手軽さと透明性は業界随一。本体紐付けで譲渡性も高い。
日本HP
HP ZGX Nano G1n
直販標準は1年引取修理等 本体購入後に窓口でCare Pack(5年保守)を安価に別契約可能。
※購入時CTOの長期保証は非常に高額。
× 規約上「第三者への譲渡不可(契約者固定)」 次点
Directplusで個人直販が買いやすい。使い倒すなら有力だがリセールに難あり。
ASUS
Ascent GX10
標準1年 センドバック修理 長期保証の延長不可
(DGX OS専用機のためASUS Premium Care対象外)
△ 1年経過後は無保証・リセール価値急落 敬遠
本体価格は安価だが、1年経過後は保証延長が一切効かずリスクを個人で抱え込む。
MSI
EdgeXpert
標準1年 センドバック修理 個人向け長期保証窓口なし △ 保証切れ後の引き継ぎ不可 敬遠
市場で放出品を見かけるが、長期保守の梯子が外れているためハイリスク。
NVIDIA純正
(DGX商流)
NVIDIA Enterprise Support(NVAIE込み) 年単位のエンタープライズ契約更新 × 法人契約に厳密に紐付け(個人譲渡不可) 別世界
代理店経由の完全法人向け。個人購入・ホビー運用は前提外。
海外並行輸入
(Acer / HP 米国版)
1年 US現地保証(現地持ち込み) 日本国内での保証適用は不可 × 国内保守なし 対象外
故障時に国際返送が必要となり、国内でのメーカー修理が受けられない。

比較検討から見えた選定のリアル

各社の保守体系と運用実態を突き詰めていくと、市場の力学と個人運用の現実が見えてきた。

1. DELLとLenovoしかありえない理由:保証が「本体」に紐づく譲渡性

個人が超高額な機材を運用する上で避けて通れないのが、「もし手放すことになったらどうするか」というリセール・資産価値の視点である。

基板交換で莫大な費用がかかるBGAマシンにおいて、保証が切れている個体や、保証が第三者に引き継げない個体は、中古市場での買い手がつきにくく価値が大きく損なわれる。つまり、買い方によって初期の標準保証年数がどうあれ、「長期保証が本体に紐づいて他人に譲渡できるかどうか」が決定的な差になる。

  • DELL: ハードウェア固有の「サービスタグ」で管理されており、公式に「所有者移転(Ownership Transfer)」の手続きが整備されている。中古流通品であっても正当な手続きで保証を新所有者へ移管でき、さらに出荷から5年以内なら有償でのProSupport延長・再契約の道も残されている。
  • Lenovo: 保守契約が個人の名義ではなく「本体のシリアル番号」に直接紐づいている。LenovoのサポートWebからシリアル番号を入れるだけで最長5年のPremier Support(SSD返却不要付き)をWeb即時追加でき、本体ごと長期保守が有効に機能し続ける。

この2社は長期にわたって修理保証の傘の下にいられる安心感に加え、将来の出口戦略(売却・譲渡)においても価値が担保されているため、個人導入では実質的に「DELLかLenovoの二択」という結論になる。

2. 次点としての日本HP:個人で買いやすいがCare Pack「譲渡不可」の壁

日本HPの「HP ZGX Nano G1n AI Station」も有力な候補として検討した。

HPの最大の魅力は「個人直販の買いやすさ」にある。法人オンラインストア(HP Directplus)でありながら、公式FAQで「個人名義・個人カードでの購入可能(屋号や登記不要)」と明記されており、誰でも新品を正規ルートで購入できる。

さらに、購入画面のCTO保証(非常に高額な価格設定)をスルーし、本体を標準保証で購入した後に窓口経由で「HP Care Pack(5年保守)」を後付け契約すれば、現実的な追加費用で5年保守を追加できる。

しかし、HP Care Packの規約には「第三者への譲渡不可(契約者固定)」という明確な規定がある。自分が手元で5年間使い倒す前提なら全く問題ないが、将来途中で機材を売却・譲渡した際に保守を新所有者に引き継げない。リセール時の資産価値という観点でDELLやLenovoに一歩及ばず、評価としては「次点」に落ち着いた。

3. ASUSとMSIは敬遠:中古市場で見かけるMSI放出品の甘い罠

一方で、ASUSとMSIについては明確に「敬遠」という判断を下した。

ASUS Ascent GX10などは本体価格が比較的安価に流通していたが、NVIDIA純正のDGX OS専用機という位置づけからコンシューマー向けの保証延長(ASUS Premium Care)の対象外。標準の1年センドバック固定となり、長期保証を組む手段がない。

また、中古市場やオークション等を見ていると、MSIの放出品がちょこちょこ出回っているのを目にする。一見すると手頃な価格でGB10機が手に入るように映るかもしれないが、これは非常にリスキーである。

冒頭で述べた通り、そう簡単に壊れるような華奢な作りではないとはいえ、万が一壊れた瞬間に莫大な基板交換費用が確定する。個人向け長期保守の梯子が外されているASUSやMSIの個体を個人で抱え込むのは、あまりにもリスクが大きすぎる。

4. そもそもNVIDIA純正はどうなのか?

「PCメーカー経由ではなく、NVIDIA直販や純正のDGXはどうなのか?」という疑問も当然浮かぶ。

結論から言えば、NVIDIA純正のDGX商流は個人運用の世界とは完全に切り離されている。

NVIDIAブランドの純正システムは、正規ディストリビュータ(菱洋エレクトロ、マクニカ、GDEPアドバンス等)を通じた完全な法人・研究機関向けエンタープライズ商流に限定される。個人名義や個人クレジットカードで直販購入することはできない。

また、そのサポート体系は「NVIDIA Enterprise Support(NVIDIA AI Enterpriseソフトウェアライセンス込み)」となっており、年間の保守更新費用だけでも企業向け価格となる。契約は法人組織に厳格に紐づくため、個人間での中古譲渡や保守の継承も想定されていない。

そのため、個人が現実的に購入・運用・維持できるのは、DELL、Lenovo、HPといった大手PCメーカーが自社の保守インフラ(ProSupport、Premier Support、Care Pack)を載せて提供しているワークステーション製品に限られる。

結論としての選定方針

以上の比較検討から、個人でDGX Spark(GB10マシン)を選ぶ際の方針は完全に定まった。

1. 本命(DELL または Lenovo):
長期保証の手厚さ、SSD返却不要、そして「本体に紐づいて第三者へ譲渡できる保証性」を最優先する。個人運用のリスク管理とリセール価値を両立できる唯一の解。
2. 次点(日本HP):
個人直販で新品を確実に手に入れ、5年間自分で使い倒す前提であれば「Directplus + 5年Care Pack後付け」は有力な選択肢。
3. 敬遠(ASUS・MSI・海外並行輸入):
放出品や初期価格の安さに惑わされず、長期保証の延長が効かないモデルは避ける。

DGX Sparkは超小型な卓上マシンであり、修理形態がオンサイトかセンドバックかは本質ではない。高額な機材だからこそ、「長期間メーカー保証の傘にいられるか」、そして「手放すときに保証を引き継げるか(リセール耐性)」まで見据えてメーカーを選ぶことが極めて重要である。

じゃあね。

kirintropは、Amazon.co.jpを宣伝しリンクすることによって
サイトが紹介料を獲得できる手段を提供することを目的に設定された
アフィリエイトプログラムである、Amazonアソシエイト・プログラムの参加者です。