パソコンパーツが高くなったが、今はどうにか物はありそうな感じ。秋葉原も雰囲気がだいぶ変わってきて、もう、寄るべきジャンク屋（使えそうなものが売っている）のは、たまたま駅近く1箇所に集中しているわずかだけで、そのために秋葉原へいくというのはほぼなくなってしまった。それに欲しいものがあれば、今やネットで比較しながら買える。しかし、高いので、まず見ない。
売れる物がないと、ビジネスが動かないので商売が立ちいかない。
つまり、商売自体が成立しなければ、家賃、経費、人件費が払えないから事業ができない。単に売れていないのであれば、売る方法を考えればいい、ただ、今回のように、価格高騰、価格相応の物がないから売れないということは死に直結している。セールスマンや店員の能力とかの問題ではなく、状況が起こしている。カスタマイズ（オートクチュール）が売りにくいなら、手に入る吊るしの完成品（プレタポルテ）を売る。カスタマイズしないと売れないと言っている時代は、PC、PCパーツ高騰の今は多分成立しない。なのでパソコンショップが吊るしの完成品に舵を切らない限り存続が難しいかもしれない。カスタマイズができる（といっても全然できないが）BTOパソコンはかなり高い。そのせいで、中古パソコン屋さんが台頭してきたような気がする。ただ、多くの中古パソコン屋さんは、中古携帯ショップと見間違えるくらい、中古スマホの在庫が多い。中古といってもパソコンに関してはそれほど数がないような気がするし、普通の人はお古は買いずらい。
閑話休題
以下にホームラボ変遷
過去：仮想化
仮想化時代は、とにかくIntel NUCでノード数を稼ぐということをしていた。NASのHDDを使っていたのだが、1GbpsのLANでNASのHDDは、腹持ちのNVMEに敵わず。
NASの用途としては
- CIFS/NFSでISO共有
- iSCSI: テンプレートイメージ共有
- Minio (Object Storage):バックアップテスト用
という用途、王道NASの使い方しかしておらず、ホストには1TB NVME + 64GB DDR4 (当時はNVMEもメモリは安かった。）が搭載されていた。そこでは仮想マシンが動くという仕組み。
この時のDDR4メモリを合わせると480GBもあった。
パブリッククラウドには必要に応じてSite VPNで使う。
多分、今でもこんなLABがあれば、まぁ仕事によっては役にたつと思う。ただ、今からこれを揃えるとしたら、売却、廃棄に後で絶対悩む大型のサーバに集約してどうにかというところだが、いずれにしてもNVME,メモリが高い問題は残る。
しかし、後半から、大きい仮想マシンを立てて、そこでDockerを入れていたんだよなぁ。（別に仮想環境を消したら殺されるというわけではなかったんだけど。）
今：AI
仮想化の仕事は完全に辞めたので、AIの構成になった。多分時代の流れなのか、インプレスの西川さんのせいなのか？図にあるGPUクラウドはまだ構想状態。
LANネットワークも八丁のSwitchを導入して2.5Gbpsになった。実はこの時に、LAN内をフルでMTU9000にした。世間のベンチマークよりさらに10％高速に。
物理的な変化としては、
仮想環境がIncus（LXD)になった
俗にいう仮想環境の問題点は、OSごとのイメージを作らなきゃならない、それをメンテしなきゃならない。Incusなら、それらの面倒さから開放される。中身はほぼクラウドインスタンスと同じで、コマンドラインでさっと展開起動ができる。Linuxに限って言えば、過去の仮想環境しか知らないのは負け組といってもいい。もしProxmoxみたいな用途が必要なら、VMware Workstationで事が済む。本番環境でProxmoxというチャレンジャブルな環境を仕事にしていなければガチ仮想化環境はいらない。（VMware移行は、最終的には移行したところが負けというのが結論に）それにWindowsのVMに限っては未だイメージ作成など必要だが、今、それほどWindowsの環境を使わない。移行で地味に効果絶大だったのは、仮想化関連のファイル、イメージなどを全て消した。そのせいで劇的にHDDが増加した。ほんと仮想環境取っ払うだけでとりあえず、HDDがものすごく空く。OSイメージをまるまる保存していたのはアホみたいだ。今思えば、単なるディスクの肥やし以下だと思う。
フレームワークが完全にDockerになった
まぁ、これは当然なんだが、仮想環境は、それぞれのお作法をもつ環境が点在したが、AIの環境はDockerでまとめられた。別にネイティブで動かしてもよかったんだが、足元のOSが汚れる、依存を受けるのがいやだった。DGX Sparkのフォーラムを見ているとインストールのトラブルが散見されるのでやりたくない。まして、ゼロからの環境構築もやりたくない。何か結果が異なることで検証も一苦労。
Docker Registryの本格稼働
これは、NFS/CIFS/iSCSI、そしてオブジェクトストレージに次ぐ、ストレージインフラストラクチャだと思う。Dockerレジストリがあれば、いわばDockerの共有ディスク。中身はほぼオブジェクトストレージ。使わない手はない。これにすることで、速くなくてもいいものは、コンテナレジストリ、速いほうがいいもの（起動コンテナイメージやAIモデル）は、ローカルのNVMEで。今自分的にはおやすみ中のKubernetesでも役にたつのではと思う。
メモリの搭載量が減った
この環境は、総メモリ容量は、384GBしかない。それもGDX SparkとEVO-X2で2/3。去年の年末の時点でいえば、総額は結構するがメモリ単価が一番安いという状態。今でもそうかもしれないが大容量のメモリを入手して確実にホストを立ち上げるのであれば、この２台。しかし、これらはオンボードだったので、NUCに刺さっていたメモリが、NUCとともに余ってしまった。買取価格が高くなるのを待っている。これでだいぶ回収できる。（メモリに関しては12月だけで10倍になっている。）何度も言うが、オンボード巨大メモリのMINI PCは、メモリが高い報道と無縁になるので精神安定度は半端なく高い。
NVMEの搭載量も減った
実は、手元には、1TB NVMEしかない。唯一の大容量のNVMEは、EVO-X2の2TBのみ。これには訳があって、Docker主体になったので、Build Cacheをレジストリに押し付けるということで、ローカルでは、ビルドもしない、ただイメージ転送するだけという形にした。そうしないとAI モデルが置けない。なので、コンテナレジストリでのHDDの消費が増えた。増えたといっても共有化が進んでいるので、各ローカルのNVMEで消費していた領域は激減したが、NASのHDDは大したことはない。つまりデータ量もだいぶ減った。
ホスト稼働台数も激減
以前はIntel NUCでアイドルであればそれほど電気は食わなかったが、vCenterが動いている環境は、フル稼働だし、台数管理が面倒だった。IP管理やパッチ管理とか。以前は、VLANを使っていたんだが、今は、VLANそのままにしているが、もうVLANは使っていない。今は、GPUノードに関しては、ローカルストレージの消費が減ったおかげで共有で使うのも耐えられそう。逆にVRAMの容量管理が必要かもしれない。VRAMって、OSですら管理してくれないので。
ダウンロード量は激増
以前は、ISOイメージをダウンロードして貯めておく。コンテナイメージもそれほど大きくなかったが、AIインフラで目に見えて増えたのはダウンロード量。AIモデルは大きいのはもとより、GPU最適化イメージは、基本10GBオーバー。イメージを作ったり消したりしていたらものダウンロードのしまくり。まるで、家の中で、その手のサイトを閲覧している思春期の子供がいるのではというくらいエグい量。ComdyUIで不足しているモデルが表示されるが、ものすごくでかい。幸いNuro光がほぼほぼ1Gbpsでるからいいけど、マンションの共有回線とかだと、とりあえず夜中ダウンロードしておいて、次の日に使うという形になりそう。ここまで回線を酷使するとは思わなかった。
環境がスリムになったのだが、実は、GPUという視点を入れるとコンテナイメージの管理が半端ない。
GPUという視点でみると、NASにもGPUがついていて、Dockerもついていることを加味してリストしてみると
- Intel iGPU / AMD64 Linux:OneAPI
- AMD / AMD64 Linux: ROCm
- NVIDIA / AMD64 Linux:CUDA13
- NVIDIA / ARM64 Linux:CUDA13
となる。DGX Sparkなんて、ARM64なので、AMD64の資産が一切使えない。幸い、手元のNVIDIAがBlackwellだけだったから良かったものの、これにAdaとかAmpere世代が混じっていたらカオスだった。別にIntel iGPUはパフォーマンスがでないのは百も承知なのでいいけど。（どうやらIntel iGPUが悪いのではなく、iGPU自体、dGPUに大量に入っている回路が少しししか入っていない）
これ以外で起きることは
- ARM64は、AMD64なみの資産があるかというと、コンテナイメージにAMD64はあるけど、ARM64はないので、できるかどうかわからんけどDockerfileから作ってね！も
- Blackwellのパフォーマンスを出すには、NvidiaのNGCイメージではないとパフォーマンスが出ない。（自分のところでは）
- RAGのライブラリでありがちなのが、実は「ワタシニホンゴノファイルヨメテイルヨウニミエマスガジツハヨクワカリマセン」というのがいる。なので、日本語の設定足してコンテナ作り直し。
つまり、使うだけのDockerは全く通用しないわけで、何かとBuildをしなきゃいけないケースが出てくる。しかし、GPUサーバって、GPUにお金かけちゃうと、他がしょぼいことも。余っているPCIeに刺しちゃいましたというパターンは特に。ないと思うがストレージがHDDでしたならもう身動きが取れない。（なので、みんなNVMEを使っている）
さて、左下にM4 MackBook AIRがあるが、単に持っていることを自慢しているわけではない。よく見たら、MacはApple Silicon、つまりARM64だ。AMD64も速い。
最終系
MacをDocker Build環境にして、マルチアーキテクチャで作ればよくない？ということになった。
MACでマルチアーキテクチャビルド
- マルチアーキテクチャであれば、ビルド自体は、ARM64とかAMD64で考える必要はない。（悩むのはDockerfile作成時）
- 各ホストでビルドして、コンテナレジストリにPushするには、別途マニフェストを書くなどめんどくさい。
- イメージは、コンテナレジストリにPushすればいい。（というかPushする環境が必要）
- ローカルのホストは、コンテナレジストリからイメージをPullしてコンテナを起動するだけ。docker clientから接続すれば、sshでログインも不要。
一気にMACの位置付けが上がった。別にWindowsでも全く同じことができるのだが、DGX SparkがARM64だったのでMACに白羽の矢がたった。なので、DGX SparkのビルドはMACが一番おすすめ。
WindowsのDockerは、WSL2(Hyper-V)で、その上でQemuを動かすという仮想＋エミュレーションなのがMACより若干不利かもしれない。（あくまでも予想）
NASはコンテナ用ストレージサーバに
- 大きいコンテナイメージは、一旦、NASのコンテナレジストリに保存しておく。（個別でPullしない。事前にしておけばあとは速い）
- ビルド環境のストレージ領域は、コンテナレジストリのビルドキャッシュ領域を使う。これで、GPUローカル、MAC/Windowsのビルド端末の消費容量も削減
- AIモデルは、NASからHugging Faceにダウンロードして後で配布。（モデルのツリーを作って保存して、Rsyncで同期）Ollamaなどのフレームワークも同じ
NASでもDockerが動くので、ダウンロードレベルであれば全然動く。集約してダウンロードすれば、帯域が爆増というのもある程度抑えることができる。
AIでの利用からすると、NFS/CIFSは完全に保存していあるモデルの転送とRAGのデータの転送、出力データの保存がメインになり、なきゃ困るが、AI本体に影響も依存もしなくなった。iSCSIに限っては、よほど高速NIC＋高速NVMEでないと、完全に足手纏い。NFS/CIFSで間に合う。
よく考えたらほんと、決断したときが人より少し速かったので、今より安く買えたのは大きいかった。もう数年は何も買わないというか、買うお金がない。
NASに関しては、この用途なら、HDDさえあれば、メモリの追加はいらない程度しか使っていない。何をいいたいかというと、
NASは、ファイルシステムがExt4かZFSでコンテナが動くNASを買った方がいい。NASをアンボックスしたら、迷わずExt4かZFSを選択して、Dockerを動かしてコンテナレジストリを入れる。少なくともこの構成は組めるはず。NAS、HDDがまだ手に入るうちに急げ。いずれHDDはもっと高くなると思う。高いNVMEやメモリに投資する何倍も感動が大きい。
ということ。