ハクソク

世界を動かす技術を、日本語で。

データセンター用GPUをゲーミングPCに搭載しました

6時間前原文(blog.tymscar.com)

概要

  • RTX 4080の16GB VRAMではローカルLLM運用に不足
  • 安価なTesla V100 SXM2 16GBをアダプタで増設しVRAM合計32GBを実現
  • ファン騒音の制御やNixOSでのドライバ調整が課題
  • llama.cppによる2GPU分散推論で高性能モデル運用が可能
  • 最新クラウドモデルに匹敵するローカルAI環境を低コストで構築

格安データセンターGPUによるVRAM拡張術

  • RTX 4080（16GB VRAM）では大規模LLM運用にVRAM不足
  • より大容量VRAMのGPUは高価なため、 中古データセンターGPU でコスト削減
  • Tesla V100 SXM2 16GB （PCIe非対応、NVLink専用）をアダプタ経由で増設
  • eBayで約£150 で入手、アダプタは£50、合計£200で16GB VRAM追加
  • HBM2メモリ（4096bit、900GB/s帯域）搭載、 RTX 4080より22%高いメモリ帯域
  • MacBook M3/M4/M5 MaxやAMD RX 7900 XTXよりも帯域効率が高い
  • RTX 5090（32GB、1,792GB/s帯域）は£2,000超、コスパで圧倒

SXM2-PCIeアダプタと冷却ファン問題

  • SXM2-PCIeアダプタ は非公式製品、NVIDIA未サポート、£50前後
  • アダプタ搭載ファンは 騒音（82dB） が大きな課題
  • 標準12V→9V動作で騒音低減を確認、PWM制御も可能
  • JST PH2.0（4ピン）→2.54mm変換ケーブル でマザボからファン制御
  • これにより静音化と冷却両立を実現

2GPUによるVRAM倍増と分散推論

  • RTX 4080（Ada）＋Tesla V100（Volta）で 合計32GB VRAM
  • llama.cppの tensor splitting 機能でモデルを2GPUに分割ロード
    • PCIe経由でレイヤーをパイプライン化
  • 単一32GB GPUほど高速ではないが、 コスト1/10で同等VRAM
  • V100の消費電力は最大150W程度、家庭運用も現実的
  • さらにV100 32GB版や2枚運用で 64GB VRAM 構成も可能

NixOSでのドライバ・CUDA環境構築

  • V100はVolta世代、 NVIDIAドライバ550.x（legacy_535） が最後の両対応
  • CUDAは 12.2 まで対応、nixpkgsから12.2をピンポイント導入
  • カーネルは 6.6系 限定、Xサーバ有効化必須
  • NixOSの柔軟な設定で 再現性・安定性 を確保
  • llama.cppサービスやCUDA環境も dotfilesで管理

実際のモデル運用と性能

  • Qwen3.6-27B-MTP Q5_K_M（約19GB） を完全VRAM内で運用
  • 2GPU分散（tensor split）で 32 tok/s の推論速度
  • プロンプト処理は 133-160 tok/s、クラウドAPIより高速
  • 99レイヤー全オフロード、128kトークンの長文文脈 にも対応

最新クラウドAIに迫る実力

  • Qwen3.6-27Bは Claude Sonnet 4.6 と同等のAgentic Index
  • MMMU-ProやTerminal-Bench 2.0でクラウドモデルを上回る性能
  • 中古GPU＋オープンソースLLM で最先端AIに迫る環境
  • Opus 4.8等の最上位クラウドAIと比べても差は縮小傾向

Multi-Token Prediction（MTP）による高速化

  • MTP（Multi-Token Prediction） で複数トークン同時予測
  • 正解トークンは「無料」、誤答のみ通常推論に戻る
  • 推論速度は 1.5～2倍 に向上、特にコード生成等で効果大
  • llama.cppの最新版でのみ対応、NixOSで ソースビルド＆バージョン管理

画像入力対応（Vision機能）

  • Qwen3.6-27Bは 画像入力（Vision） にも対応
  • mmproj（約928MB） を追加ロード、GPUオフロード可能
  • 画像はベクトル化され、テキストトークンと同一空間で処理
  • 画像URL＋テキストプロンプト で画像認識・解析が可能
  • llama.cppでは --mmproj と --mmproj-offload フラグで簡単設定

OpenCode等との連携運用

  • OpenCode 等のローカルAIコーディングアシスタントと連携
  • LLMサーバはデスクトップ上で稼働、他PCからも利用可能
  • ローカルで 高性能AIを自由に活用 できる環境を構築

このように、 中古データセンターGPU＋オープンソースLLM＋NixOS環境 の組み合わせで、数万円規模の投資で クラウドAIに匹敵するローカルAI環境 を構築可能。ファン制御やドライバ調整の工夫で、静音性・安定性も確保。 自作好き・AIエンジニア にとって、コストパフォーマンス抜群の選択肢。

Hackerたちの意見

おめでとう！ほとんどの人はドライバーやカーネル、ACPI、アダプター、ファンヘッダーのデバッグなんてやりたがらないけど、やる気がある人にはコストパフォーマンスがめちゃくちゃいいね。

AMDのMI250X GPUも面白いよね。128GBのHBM2Eで3TB/sの速度、たまに中古で1,000ドル以下で見かけるけど、もちろんOAMソケットが必要なのがネック。普通のマザーボードに簡単に接続する方法は見たことないな。

└

これは面白いし、かなりのスループットを提供するね。でも、PCIレーンに適応する意味はないかな、スロットバスのボトルネックに引っかかっちゃうし。

└

追加の問題は、MI250Xは1つのパッケージに2つのGPUが入っているから、最初と最後のx16 SERDESグループをホストに接続しないと、1つのGPUしか見えないってことだね（もしくは全く動かないかも、よくわからんけど）。それに、eBayで売ってる安いHPEは、動かすために独自のHPEマジックが必要で、まだそれを解明した人は見たことないな。

└

ああ、幸いこのOAMソケットのおかげでお金を使わずに済むわ。

└

この人はOAMソケット用のコンバーターを作ったけど、今のところNVIDIAカードでしか動作が確認されてないみたい（https://www.reddit.com/r/NVIDIA_SXM2PCIE/comments/1d076cn/oa...）。MI250Xにフィットするし、システムはそれを認識するけど、ドライバーが動かないんだ。HPE MI250Xをテストしたらしい。スレッドには、MI250Xには2種類あるって噂があるよ：HPEのやつと他のメーカーのやつ。HPEのは特別なファームウェアが必要だけど、普通のは必要ない。ただ、セカンドハンド市場のMI250Xの大半はHPE製だから、注意が必要だね。

いい記事だね。プロジェクトのためにこのDCカードを考えてたけど、これで買う気になったよ。トークンにかかるコストとユニットの価格を比べてくれて、納得できた。

└

だからやったんだよ。こういうことを視野に入れるのは大事だと思う。

テスラのV100 SXM2 16GBは、著者が書いてるようにDGXクラスじゃないよ。HGXクラスだよ。V100はSXM2とSXM4の2つのクラスがあって、後者は最大80GBのオンボードメモリがある。通常、HGXライザーに8×A100 80GB SXM4をインストールするんだけど、これでNVSwitchファブリックと640GBのプールされたHBM2e（パッケージスタックメモリで約2TB/sのメモリ帯域幅）が得られる。2Uの標準ラックサイズでもあるしね。

└

何を言いたいのか全然わからないんだけど。V100はsxm2とsxm3で出てきたし、16GBと32GBがあったよ。HGXはDGXにちょっとしたトッピングが加わった感じ。

└

一体何を言ってるの？君のコメントは意味不明だよ。V100とA100は全然違う世代なんだから。V100は2TB/sの速度は持ってないよ。

すごい仕事だね。でも問題は30トークン/sじゃなくて、エージェントコーディングやチャットには十分だけど、プリフィルが遅いとエージェントのワークロードが完全に死んじゃう。もしOPが言ってるように100,000トークンを約150トークン/sで処理するなら、計算すると：100000 / (150/s) で、11分6.6666667秒待つことになる。これはかなりの待ち時間だね。

└

ほとんどの人が一度に100Kトークンを投入することはないけど、セッション中に積み重なるプリフィルの時間はかなりのものになるのは同意するよ。これ、MacのローカルLLMにも共通の問題だね。Macは高帯域幅メモリをたくさん得るのにいいけど、計算能力は現在の専用GPUにはかなり遅れをとってる。高価なMac Studioのセットアップの中には、使えるトークン/sで非常に大きなモデルを動かせるものもあるけど、そのトークンを生成するまでにかなりの時間がかかることもあるよね。

└

プロンプト（プレフィックス）キャッシングと、プロンプトプレフィックスを制御できるエージェントの組み合わせでうまく緩和できるかも。目標は、一度だけ遅いプリフィルを発生させてプロンプトキャッシュを構築し、その後のプロンプトはほとんどこの固定プレフィックスと特定の指示から成るようにすること。C++のようにモジュールが定義（.h）と実装（.cpp）に分かれている言語では、プレフィックスの選択肢はプロジェクトのすべてのヘッダーファイルになるだろう（あまり変わらないだろうし）。もっと一般的には、キャッシュされたプレフィックスの再利用を主なコンテキスト管理の目標にしたエージェントがあればいいなと思う。変更されたファイルのキャッシングをサポートするためには、エージェントがセッション開始時の状態を反映した固定プレフィックスを構築し、その後に変更を追加する形になるかな。関数の最新の定義だけを使うように適切にプロンプトを促す感じで。例えば、ファイルAが最初に関数X、Y、Zを含んでいて、プロンプトプレフィックスがX Y Zを含むように構築されるとする。もしユーザーがYをY'に変更したら、その変更をコンテキストに追加して、キャッシュされたプレフィックスはそのままにしておく。つまり、X Y Z Y'になるってわけ。

└

ちょっと検索したら、これは標準機能で、プリフィルをキャッシュしてPCIe帯域幅で読み込むから、だいたい0.2秒くらいになるはず。

そして、もし絶対に最高のものが欲しいなら、Opus 4.8があるよ。それは、このGPUとアダプターのセットアップ全体にかかった費用よりも、20分の重い使用でのコストが高い。でも、その差は驚くほど小さい。これは状況を公平に表現しているとは思わないな。私は毎日APIのプリペイドトークンを使ってフロンティアモデルを利用してるけど、月に100ドルも使うことはほとんどない。20分でそれを倍消費する方法を見つけたのはすごいけど、今多くの人が経験している現実を反映しているとは思わない。LLMを活用するための非常に貪欲なアプローチがあって、これが議論の中で便利なストローマンになっていると思う。APIに支払う方が、同等のインフラを自己ホスティングするよりもほぼ常に経済的だよ。自己ホスティングには反対しないけど、この記事はこの取り組みの主な動機が経済的だと示唆している。もし月に10^9トークン未満を消費しているなら、ハイパースケーラーと競争するために時間を使う価値は本当にないと思う。お金はこの技術を既存のビジネスと統合するところにこそあるんだ。

└

自分もホスティングプロバイダーを使ってるけど、Deepseekみたいな安いモデルでも、半日で$100分のトークンを使い切っちゃうよ。もし誰かの使い方が君みたいに軽いなら、サブスクリプションを取ればもっと節約できるだろうね。使用量が多い場合は、電気代がどれくらい安いかによって、少しでもオフロードする価値があるかどうかが決まるよ（自分には価値がないけど、参考までに）。

└

Claudeは百万トークンあたり約$35だよ。APIの価格で使ってたら、1時間のコーディングセッションで簡単に$100使っちゃうし、/fastをオンにしたら10分くらいで終わるよ。みんなはどうやって使ってるの？

└

毎日APIのプリペイドトークンでフロンティアモデルを使ってるけど、月に100ドルも使わないよ。ccusageによると（https://github.com/ryoppippi/ccusage）、100ドルのマックスサブスクリプションがなかったら、5月はAnthropicに約4173ドル払わなきゃいけなかった。入力 │ 出力 │ キャッシュ作成 │ キャッシュ読み込み │ トータルトークン │ コスト（USD） 1,948,016 │ 19,435,081 │ 103,626,350 │ 6,244,194,278 │ 6,369,203,725 │ $4173.09 編集: 最新の数字を引っ張ってきたけど、ファストモードは全く使ってないし、ほとんどのタスクはOpusでやってる。使用パターンは特にひどくないよ。通常はClaude Codeで1-2プロジェクトを同時に回してて、時には寝てる間にやってるけど、週の上限の60-80%には大体達してる。

タイトルを見て、ゲームでの使い方を期待してたんだけど、結局LLMを動かしてただけだったね。

└

同じく。今年は新しいNVIDIAのゲーミングGPUが出ないから、面白い問題を解決するチャンスだね。

└

それは無理だと思うよ。そのチップ上のゲームに必要なシリコンの部分は、もっと計算コアを増やすために全部取り除かれてるから。

└

最初に言ってたけど、ビデオ出力すらないから、ゲームはできないらしいよ。

これについて調べてたんだけど、ファンのセットアップが心配だったんだ。いい結果が出せたのは興味深いね。もし誰か興味があれば、FreeBSDホストからLinuxゲストに古いPascalカードを使ってPCIEパススルーしてるんだけど、すごくうまくいってるよ。もうちょっといいカードを入れようかなって考えてる。SXMのルートは良さそうだけど、DCコンポーネントには前に熱でやられたことがあるからちょっと怖い。

最近、データセンター用のGPUを買ってシステムに取り付けることにしたんだ。著者が記事で触れてない経験からのメモをいくつか：廃止されたNVIDIA V100やAMD MI50は結構安くて、16GBが200ドル、32GBが400-500ドルくらいで、ローカルで実験するにはいい感じ。かなり古いけどね。これらのカードを現行のプラットフォームやモデルで使い続けている熱心なコミュニティもあるよ。細かいことだけど、V100はbfloat16をサポートしてない。ローカルモデルをいじる分には性能の低下は大したことないけど、ハードウェア機能的にはもう限界に近い。MI50はbf16をサポートしてるけど、現在のAMD ROCmの版ではサポートされてない。Vulkanのサポートは良好で、MI50は主要なプラットフォーム（llama.cpp、vllmなど）で動くけど、手動で再コンパイルしなきゃいけないなどの痛点もある。幸い、オープンソースコミュニティがほとんどの道を開いてくれてるよ。このカードの冷却要件は軽視できない。コンシューマーグレードのGPUは小さいケースに追加ファンなしだとサーマルスロットリングするかもしれないけど、同じ条件でデータセンター用のGPUはアイドル状態でもオーバーヒートしちゃう。これを防ぐためには、少なくとも decentな120mmファンをいくつか買うか、水冷に投資する必要があるよ。最終的に、AMD MI100 32GB（950ドル）を選んだ。AMDファンだし、現在のROCm版もサポートしてるし、設定も楽だったから。もっと大きなモデル、例えばqwen3-coder-nextを試すために、もう一枚買うかどうか悩んでる。

└

MI100を選ぶときにR9700やB70を考えた？もしそうなら、MI100を選んだ理由は何だったの？このクラスのカードを手に入れようか悩んでるんだけど、Qwen3.6 MOEモデルを6800xtで動かすのが許容範囲だから、正当化できてないんだよね。

└

同じ扱いを受けると、データセンターのGPUはアイドル状態でもオーバーヒートしちゃうよ。友達が何年もサーバーグレードのカードでこれを学んだんだ。そう、君のIntel 10G NICは安かったね。でも、デスクトップにそのまま刺すのは無理だよ。サーバーレベルのエアフローを期待してるから、たぶん冷たい吸気側が必要なんだ。彼はファンマウントを印刷して取り付けたら、うまくいってるみたい。

└

qwen3-coder-nextは、私のコンシューマーグレードのNVIDIA 4070で問題なく動いてるよ。パフォーマンスは特別良くはないけど、ちゃんとしたモデルよりちょっと遅いだけ。

これいいね！ローカルモデルにずっと興味があって、ローカルモデルが最終的にはフロンティアモデルを使わなくても良くなるって思ってる（もしかしたらもうそうなってる？）。でも、コンピュータを作ったことが全くないから、どこから始めればいいのか分からない。ブログ記事に書いてあること以外で、何かアドバイスある？