大学の時いた研究室が、学内で有数の端末数を誇る研究室だった。理由は学生実験で使う測定基盤と連携していたLinux端末があったため。一度目の4年の時に、お手製7ビット出力をUARTを使ってデータをいれ、Forthという言語を使って解析できるようにした。とにかく台数が多くUARTの回路の量産化が鍵だった。
ある日、突然、普段は外出なんて滅多にしない教官が某大学にそそくさと出かけて行った。数時間後、ドヤ顔でもどってきたので理由を聞いてみると、その大学の高速回線の繋がるスイッチのポートの空きが出たので接続許可を貰いに行ったとのこと。他に取られないように速攻で行ったらしい。なので、研究質は、学内のルーターを通らずとして、学外に出れた。はっきり言って、ServerのHDDよりも速かった。ダウンロードしまくってパンクさせて、何度もアラートを出しまくった。今となってはいい思い出である。
閑話休題
ネットワーク編
― DGX Spark / EVO-X2 を使うと「回線」がボトルネックになる理由 ―
前回は DGX Spark（GB10）各社モデルの価格比較と、ストレージ設計の現実について書いた。今回はその続きとして ネットワーク編である。
内容は DGX Spark だけでなく EVO-X2 にもそのまま当てはまる話だ。ただし、ガチネットワークのジャンルではなく、ある意味しょうもない話なので、その道のプロからしたら物足りない話かもしれない。
DGX Spark は 128GB メモリ、EVO-X2 も 最大 96GB まで使える。
ここで一つ、ほぼ確実に起きる ”ありがち” “あるある” がある。
大容量VRAMマシン、あるある
メモリが大きい
→ 使うモデルも大きくなりがち
→ ネットワークが詰まりがち
モデルはどこから来るのか問題
使うモデルはどこから手に入れるか。答えはシンプルで、インターネットからダウンロードである。
-
LM Studio
-
Ollama
-
Hugging Face
-
NVIDIA NGC
量子化されているとはいえ、LLM や画像生成モデルは 数GB〜数十GB が当たり前。
さらに、
-
量子化されていないモデル
-
GPT-OSS のフルサイズ
-
NVIDIA の巨大コンテナイメージ（Docker Hub ではなく NGC）
こうしたものを 各自が勝手にダウンロードし始めると、ネットワーク帯域は一気に死ぬ。
また、新しいモデルが出ると、みんな一斉にダウンロードし出したらやはり帯域を消費する。使いたい欲望は恐ろしい。
こう言ったことが自宅で問題にならないのは、己の欲望と調整するかのように、家族に隠れてFXXZAあたりでこっそり動画を落としていたのがバレないようにしていたのではというもあるかもしれない。
DGX Spark のボトルネックは「GPU」ではなく「回線」
意外に思われるかもしれないが、DGX Spark を使う上で一番チューニングが必要なのは GPU でも NVMe でもない。
👉 インターネット回線、それも回線契約である
自宅環境の場合
-
理想：1Gbps クラス
-
フレッツ系で、収容局の外れポートを引かない限り十分現実的
-
マンション既設の回線／CATV はやや厳しいケースあり
ただし、
回線のためだけに引っ越す／引き直すというのは現実的ではない。引き直せなかったりするケースも多数ある。
オフィス・学校はもっと深刻
オフィスや学校だと、状況はさらに悪くなる。
過去にいた会社の話だが、コロナ禍で在宅勤務をしていたときは仕事がサクサク進んでいた、コロナ禍前には出先が多く、オフィスにいなかった。
「オフィスに来たら、ネットが遅い、遅い」
と顔を合わせるたびに文句を言う。
そりゃそうである。回線はフレッツ。導入した業者は誰かのお友達でMTU 設定をミスっていて直すには追加コストが発生。結局、端末側で MTU をいじって対応するように案内。
そのとき冗談半分・本音半分でこう言っていた。
「では今から、オフィスにいる人間全員があなたの家で仕事します。同じ回線になりますから体験できますよ？」
多分まだ、猿みたいに言っていると思う。回避するならテザリングを使ってといっているのに。（その会社、パケ放題の回線の経費が普通に落とせたので）
ほんといいお家で育った人が多くいた会社だった。
帯域を“人数分”出すという幻想から事実へ
仮に、
-
出社している社員：40人
-
各自が自宅並みの帯域を使う
とすると、
単純計算で 40Gbps 回線が必要になる。
さらに今どきは、
-
会議室が空いていない
-
同室で顔を合わせたくない
-
なぜか社内会議を Teams で実施
という 帯域泥棒がゴロゴロいる。
大容量VRAMが多くある環境だと、そんな悪気がなくても、普通に仕事をしているだけ帯域を食い尽くしてしまうことが発生することが予想される。
そんな頻繁にダウンロードをしないと言っても、見つからない、素性がわからないとなれば、ダウンロードをしていると思う。管理されていないから余計ダウンロードされやすい。
なので、ちょっと気が効く人は、自己防衛でどこかにモデルやイメージをストックしているかもしれない。ただし、それは管理されていない野良領域である。
解決策：代表してダウンロードしろ
ここで話は DGX Spark の本題に戻る。
モデルもコンテナイメージも、代表者がまとめてダウンロードして共有する。
これだけで、状況は一気に改善する。
代表ダウンロードのメリット
-
インターネット帯域の効率化
-
野良コンテナイメージを排除できる
-
セキュリティホールのあるコンテナイメージを使わせない、事前にチェックができる
-
モデルの素性が明確になる
-
ガードレールをブレイクしたような違法なモデルやライセンス的に利用できないモデルの利用を阻止できる。
よくある地獄がこれだ。
「GPT-OSS でこの結果が出た！」
→ その GPT-OSS、どのモデル？
→ 量子化レベルは？
→ 出所は？
→ いつの版？
これで 使える／使えないを議論しても、意味がない。
また、ガバナンスを効かせられてコンプライアンスも維持ができる。
それなら大容量VRAMのマシンなんか導入しないで、普通のノートPCでLM Studio / Ollama を各自勝手に使っていればよかったかもしれない。
ダウンロードサーバ＝NASが本気を出す場所
代表ダウンロードをやるなら、ダウンロードサーバを立てるのが正解だ。
ダウンロードサーバといっても、curlやhfコマンドが動けばいいレベルである。
ここで初めて、「スペックのいい NAS を使う意味」が生まれる。
-
大容量ストレージ
-
高速ネットワーク
-
24/7 稼働
-
管理された共有
さらに、
Registry サーバも同居させる
ことで、
-
モデル配布
-
コンテナ配布
-
ビルドキャッシュ
を 1台の NAS に集約できる。
ダウンロードサーバを建てた場合は、もう予算ができる限り、スペックのいいNASを使うといいと思う。
一般的なNASの要件が唯一当てはまるのはここかもしれない。
まとめ
DGX Spark / EVO-X2 の世界では、
-
GPU性能
-
VRAM容量
-
NVMe速度
よりも先に、
ネットワーク設計を誤ると全部が破綻する
個人でも、オフィスでも、学校でも同じだ。
代表してダウンロードする。管理された NAS に集約する。
これは単なる帯域対策ではない。
👉 運用と議論を成立させるための前提条件である。