- ローカルで最新水準のLLMと音声テキスト変換を動かすためのハードウェア構成、PCIeスイッチ設定、Docker実行構成を1つのリポジトリに整理
- 約**$2k**の予算では、2× RTX 3090で48GB VRAMを確保し、Qwen3.6-27Bと
whisper-large-v3ベースのローカルSTTを実行する構成を目標とする
- 約**$40k**の予算では、4× RTX PRO 6000 Blackwell Workstationで384GB VRAMを確保し、Claude Opusにかなり近いモデル知能を得る構成を前提とする
- 実際の4× RTX 6000 Proシステムは、中古のEPYC/DDR4ベース本体とc-payne PCIe Gen4スイッチを組み合わせ、GPU間P2P通信をCPUルートコンプレックスではなくスイッチファブリック内で処理
- BIOS、GRUB、ACS、電力制限設定まで調整した結果、P2Pは27.5GB/s単方向、50.4GB/s双方向、0.37–0.45µsの遅延でGen4ラインレートに到達
ローカルLLM実行のための予算帯
- この構成は、ローカルで最新水準のモデルと音声テキスト変換を実行したいユーザーを対象としている
- リポジトリには、使用中のハードウェア、購入理由、設定のコツ、ローカルSTTの実行方法、Dockerコンテナベースのモデル実行構成が含まれる
- READMEの表を除く内容はAIが書いたものではないという注記がある
-
約$2k構成
-
約$40k構成
- 4× RTX 6000 Proで合計384GB VRAMを確保する構成を前提とする
- この価格帯では、Claude Opusにかなり近いレベルのモデル知能が得られる段階として表現されている
- 2026-07時点で4× RTX6kPRO向けの現時点で最良のモデルとして
GLM-5.2-Int8Mix-NVFP4-REAP-594B が挙げられている
- 実行構成は
runners/GLM-5.2-594B にある
- 別のアプローチとして、4× DGX Sparkクラスタを接続して512GB VRAMを確保し、遅い大きな頭脳としてQwen3.7-27Bに反復作業を素早く処理させる方法にも言及している
実際の4× RTX 6000 Proハードウェア
- 実際のシステムは、4× RTX PRO 6000 Blackwell Workstationを中心に構成されている
- GPUは各96GB、合計384GB VRAMで、価格は約**$46,000**
- 本体は前世代のEPYCとeBayのDDR4部品を活用して基本システム費用を抑え、VRAMに費用を集中させている
- 2026年7月時点ではPCIe5/DDR5ベースのシステムが非常に高価なため、PCIe Gen4スイッチとDDR4ベース本体を選択している
-
基本システムBOM
- 基本システムは大半がeBayで入手した前世代EPYC部品で構成される
- 主要部品と価格は以下のとおり
- ASRock Rack ROMED8-2Tマザーボード: $715
- AMD EPYC Milan 7313P 16コア 3.0GHz CPU: $504
- 8× 16GB Crucial DDR4 ECC RDIMM、合計128GB RAM: $642
- 2× Super Flower 1700W PSU: $750
- c-payne Microchip Switchtec PM40100 Gen4 PCIeスイッチ: 約**$1,330**
- 4TBブート用NVMe: $291
- 2× 8TBモデル重み用NVMe: $1,200
- 基本システム合計は**$5,587**
-
PCIe Gen4スイッチ
- c-payneのPCIe4スイッチを使ってGPU間通信をほぼ直接処理する
- テンソル並列化のallreduce段階で、GPU間データはPCIルートコンプレックスを経由せずスイッチファブリック内を移動する
- スイッチのサブBOMは約**€1,220**、約**$1,330 USD**
- Microchip Switchtec PM40100ベースのPCIe Gen4 5× x16スイッチ
- SlimSAS PCIe Gen4 Host Adapter x16
- SlimSAS SFF-8654 8iケーブル2本
- GPUとPCIスイッチ用の木製エンクロージャを自作しており、約1日かかった
- PCIスイッチ内蔵ファンは非常にうるさく役に立たないように見えたため、基板から取り外した
モデル重みの保存と実行方式
- すべてのモデル重みは、2本の8TBドライブに複製されたZFSファイルシステムにローカル保存される
- ファイルシステムは
~/storage にマウントされる
- 実行するモデルはまず次のコマンドでローカルにダウンロードする
hf download <model-name> --local-dir ~/storage/<model-name>
エージェントハーネスとツール構成
- 別のVM内で
~/src ツリーの各ディレクトリごとにtmuxセッションを作り、各セッションで opencode インスタンスを実行するアプリケーションを使っている
- 各
opencode インスタンスは、推論マシンのHTTP APIである http://clank.j.co:5000 をバックエンドとして使う
- オープンソースモデルをうまく使うための鍵はツール構成だとされている
skills/ の要約には次のツールが含まれる
- camofox、kagi.com APIキー、searXNGによるWebブラウジングと検索
- Telegramボットによるコミュニケーションと通知
- ソースコード共同作業用のローカル非公開Giteaインスタンス
- エージェントには、セッション内で対話的に一緒に作業させることも、Gitea issueを処理してPRを出させる形で任せることもできる
- この作業はサンドボックスVM内で実行され、ホストとの通信は共有ファイルシステムマウント経由でのみ行われる
PCIeスイッチとマルチGPU設定
-
BIOS設定
- ROMED8-2TマザーボードでPCIスイッチ速度が低下しないようにBIOS設定を調整している
AMD PCIE Link Width はスイッチスロットに対してx16に設定する- 従来のx8/x8分岐設定ではスロットが分割され、upstreamリンクがGen4 x8としてトレーニングされる
- SlimSAS 8iケーブルは2本とも接続する必要があり、各ケーブルがx8を担当する
- PCIe Link SpeedはGen4に固定する
- Blackwell Gen5デバイスがGen4スイッチ経由で自動ネゴシエーションすると、トレーニングに失敗してGen1に落ちることがある
- ASPMはDisabledに設定する
- ASPM L1はアイドル時リンクを2.5GT/sまで下げる
lspci でGen1にダウングレードされたように見える原因だったが、負荷中はGen4で動作する- Re-Size BARはEnabledに設定する
- 96GB VRAM全体のBAR公開とGPU P2Pに必要となる
- SR-IOVはDisabledに設定する
- ベアメタル推論環境でIOMMUオーバーヘッドとP2P干渉を避けるための設定である
- Preferred IOはAutoのままにする
- c-payneスイッチのバス
81 を手動指定するとわずかな遅延改善の余地はあるが、修正ではなく最適化であり、BIOS変更後にバス番号が変わる可能性がある
-
Redriverとケーブル
- c-payneの助言に従い、c-payne tool でredriver gainを
lvl 3 に下げている
- gainレベルはSASコネクタケーブルの長さによって変わる
- c-payneでケーブルを少なめに注文してしまい、Amazonで似たSASケーブルを買ったが、わずかな違いで問題が起きたため再注文した
カーネル、ACS、電力制限
-
GRUBとNVIDIA UVM
/etc/default/grub に次のカーネルパラメータを設定する
GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
iommu=off がないと、マルチGPU P2PでNCCLが停止する- NVIDIA UVM P2P修正のため、次の設定を適用する
echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u
-
ACS無効化
- ACSがデフォルトで有効だと、P2Pトラフィックはスイッチファブリック内に留まらずCPUルートポートを通ってしまう
- この状態ではPCIeスイッチの効果が失われる
pcie_acs_override にはパッチ済みカーネルが必要なため、ランタイムで setpci を使ってACSを無効化している- 起動ごとにsystemd oneshotサービスで
/usr/local/bin/disable-acs.sh を実行する
- 検証方法は次のとおり
lspci -vvv | grep ACSCtl ですべてminus sign表示になっていることnvidia-smi topo -m で4基のGPU間がPIXと表示され、PHB/NODEではないこと./tools/measure-gpu-speed.sh でP2P帯域幅と遅延を簡単に測定できる
-
GPU電力制限
- 220V回路の設置を避けるため、単一の110V回路で動かしつつGPU電力を制限する
- systemdで起動時にpersistence modeと電力制限を適用する
sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
- GPU電力制限はGPUあたり350Wで、デフォルトは600W
- 4×350WはGPU負荷1,400Wで、PSU予算に合わせた値である
- 240V回路導入前の単一1700W PSU段階では、GPUを約260Wで運用していた
- 4×260W = 1,040W GPU
- システム約280Wを加えて合計約1,320W
- 検証は
nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv で行う
測定結果と参考資料
- CPU方向のupstreamはGen4 x16で、約30GB/s
- スイッチ経由のP2Pは27.5GB/s単方向、50.4GB/s双方向
- 遅延は0.37–0.45µsで、Gen4ラインレート水準
- どこかでASPMが有効になっていると、
lspci がアイドル状態のdownstream GPUリンクを 2.5GT/s (downgraded) と表示することがある
- この表示は見た目上のもので、リンクは負荷がかかるとGen4に再トレーニングされる
-
Resources
1件のコメント
Hacker Newsのコメント
ローカルLLMをかなり使ってきて、ハードウェアにも過剰なくらいお金をかけたが、期待値を下げて細かい条件をよく読む必要がある
記事中の大型ビルドは予算が4万ドルから始まるが、1枚1.2万ドルのGPUを4枚含むため、実際には5万〜5.5万ドルに近い
ローカル構成では、モデルをハードウェアに合わせるために量子化やREAPのような手法に頼ることが多い。4ビット量子化はロスレスだという主張も多いが、それは小さなコーパスでのKLダイバージェンス測定から出た話で、長いコンテキストのコーディング作業に使うと品質低下ははっきり見える。データセット分析のような非コーディング作業でも、4ビット、8ビット量子化、ときには16ビットの元モデルとの品質差はかなり測定できる
この記事ではREAPモデルの使用も勧めているが、これは誰かがモデルを小さくするために一部の重みを切り落としたという意味だ。特定のタスクにあまり役立たない重みを取り除くという発想だが、全体の出力品質はまた下がる
落とし穴は、人々が「GLM-5.2をローカルで動かしている」と言うと、ベンチマークを見てすごく見える一方で、実際にはGLM-5.2ではなく、ほとんどのビットを捨て、一部のエキスパートを取り除いた派生モデルを動かしていることだ。ごく小さな作業やチャットでは量子化/REAPモデルと元モデルの差は見えにくいが、小さな誤りが積み重なる長期作業ではその差がつらくなる
そして、すでに5万ドルを使っているのだから、品質をもう少し上げて投資価値を出すには1.2万ドルのGPUをあと1〜2枚買えばいい、というような滑りやすい坂に陥る
コーディング作業は複数の呼び出しにセッションを分ける必要がある。https://github.com/aka-rider/orqestraを作ったが、最近のツール実行環境なら、ほぼどこでも自分で同じようなことができる
核心は、コードを読んでツールを呼び出すことでコンテキストを消費するセッションを別に用意し、「関連するコードとドキュメントはここにあり、根拠はこれ」というMarkdownレポートを作らせてハルシネーションを減らすことだ。計画セッションは別に置き、小さいモデルは詳細を飛ばしがちなので、批評役と設計役を1〜3回往復させ、作業者と検証者も同じ理由で往復させる
Qwen3.6は読み取り専用モードで複雑なバグを何時間も探すことができ、たいてい見つける。提案する修正はおそらくハックっぽいだろうが、Sonnetも同じだ
Qwen3.6はOpusが作った計画に従って機械的にコードを書くことができる。その後は「自分の変更を自分でレビューして。バグはあるか？ 元の計画と照合して抜けはあるか？ CLAUDE.md違反はあるか？」のようにプロンプトする必要がある。ただし、これはSonnetにもまったく同じことをする必要がある
ローカルLLMはナレッジベースの再インデックスにも使っている。チケット整理では「エラー表示用の単一パネル、すべてのエラーメッセージを移動」のような生メモだけ残しても、目標とコンテキストが付いた90%くらい完成した仕様として返ってくる
小さな作業には本当に良いが、初めて大きな作業をさせたとき、エージェント実行環境が何かを忘れて、ツール呼び出しの形式を間違って使い始めた。Pi上で動いていたのに、自分はClaude上で動いていると信じ込み、存在しないClaudeツールを呼び出そうとした
単独でアプリケーション全体を書くわけではないが、自分で把握する時間も意欲もなかったtailnetの厄介なネットワーク問題を解決してくれたし、簡単ではあるものの調査コストが大きくてやっていなかった作業にもよく手が伸びる。Opusではないが有用で、サブスク料金やAPI費用に見合う価値を得ているか心配しなくて済む
自然言語処理、音声合成、画像処理、オーディオエンジニアリング、信号処理、Krita用の拡散プラグインのような小さなツールは、ローカル構成にとても向いている。数日前に短く書いた記事もある[1]
[1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...
「約4万ドルでモデルの知能が一段上がり、Claude Opusにかなり近いレベルになる」というのは、月200ドル基準で Claude Opus 4.8 や Codex GPT 5.5 を16.8年使う費用と同じ
ローカルモデル実行は本当に好きだが、それでもなお法外に高く、品質は低く、バックドアがあれば危険にもなり得る。心からそうでなければいいと思う
ただしローカル機材が実際に月4,000ドル分のAPI利用量と同等に処理できるかは疑わしい。ローカル機材ではAnthropicの複数データセンターほど、プロンプトを並列に効率よく回しにくいからだ
OpenAIやAnthropicのような企業は、まだベンチャーキャピタルの力で補助された価格でプランを売っており、その資本はいずれリターンを求めるはず
OEM sparkで最初の月に10億トークンを使ったが、Opus基準では1,000ドルを超える量だ。トークンのパターンが違うので公平な比較ではないが、その後vLLMの改善、主にMTPのおかげで速度も2〜3倍向上した。DiffusionGemmaは通常のGemmaより約4倍速い
光ファイバー回線すら所有していないのに、なぜ急速に減価償却し、高価で面倒な資産をまた所有しようとするのかと思う
クラウドGPUを借りれば、巨大な趣味用フランケンシュタイン箱を作らなくても、所有文化、データ統制、価格統制、ハッキング文化に参加できる。その箱は高価で、蒸留されて実質的な有用性が下がり、保守も厄介だ
「4万ドルでほぼOpus」と言うが、GLM 5.2 が「ほぼOpus」なら、快適な推論には少なくとも8xH200が必要で、4万ドルより 40万ドル に近い
記事では修正済みモデルを使うよう提案している：「REAPでプルーニングされ、エキスパートの約22%が削除され、Int8-mix NVFP4で量子化されたGLM-5.2、約594Bパラメータ」
ベンチマーク外で実際にどう動くのか気になる。Qwen3.6も6ビット量子化では推論中にループへ陥ることが多いが、ここではエキスパートまで一部削除している。時には8ビットや16ビットの小さなモデルのほうが、脳を切除された大型モデルより賢いこともある。コーディングでは8ビット未満に落とさないほうがよいという合意があるようだ
また、脳を切除されたモデルをRTX 6000 4枚に収めるとき、利用可能なコンテキストがどれだけ残るのかも不明だ。100k未満では必要なコンテキストを集める前に圧縮に引っかかることが多く、ほぼ使いにくい。リポジトリで確認するとコンテキストは240kだった
そもそも実行できないのか、それとも遅すぎて使い物にならないのか知りたい。ローカルで最新級モデルのビルドと概念を検証したうえで、18〜24か月後にGPU価格が大きく下がったら残りを埋めたい
それならプロンプト数百個を同時に回せるのかと思う
llamacppに入っている。hereticを作った人が、最新レベルのループ防止と多様化戦略も作った
ただそうしたいだけでないなら、8x H200を動かす実質的な必要はない。定期的に同時ユーザーやエージェントを多数サービスする必要がある場合は例外だ
中間の選択肢もある。128GB VRAM を確保すれば、統合メモリ構成でその程度の容量を得られる選択肢が今はいくつもあり、DwarfStarを通じてDeepSeek V4 flashを良い速度で動かせる
自分ならお金は出さないが、多くの人にとってはこの程度が適切な妥協点のように思う
ただしPiを使う必要がある。claude codeはブートストラップコンテキストが多すぎて、すべてがずっと遅くなる
「RTX 3090を2枚で合計48GBのVRAMを用意すればQwen3.6-27Bを動かせるし、素晴らしいモデルだ」と言うが、3,000ドルあれば共有メモリ48GBのM5 MacBook Proを買えるし、巨大な箱でもない
あるいは、そのお金をクラウドホスティング業者に使うことも検討に値する。少なくともある程度は、もしかするとかなり安くなるかもしれない。もちろんモデルをローカルで動かせるのは素晴らしいことだ
ところがGemma 4 31BやQwen 3.6 27Bのようなまともなものを一度使ってみて、ようやくどれほど有用か分かった
機密情報を共有しているのではないかという心配をしなくて済み、トークンが尽きる心配もなくなり、リモートAIの可用性も気にしなくてよくなる。ローカルLLMには大きな価値がある
3090を2枚なら合計1.87 TB/s、1枚あたり0.936 TB/sのメモリ帯域幅があるが、M5 MacBook Proは0.3 TB/sしかない。Maxチップは最大0.63 TB/sだが、その構成は1万ドルのマシンだ
だからQwen 27Bは3090を2枚なら実作業に十分な速さで動くが、MacBook Proでは苦痛なほど遅く感じる。またMacBook Proで大きなモデルを動かすとUIがもたつき、キーボードが熱くなる。地下室に3090を2枚置いて、MacBookから接続するほうがはるかに良い
トークン生成速度だけでなく、最初のトークンまでの時間、つまりプロンプト処理時間が違う。M5ハードウェアはそれ自体としては素晴らしいが、GPUのほうがやはりずっと速い
モデルをGPUボックスで動かせば、ノートPCを熱い皿にせず膝の上で使えるという利点もある
したがってFLOPSに縛られるプリフィルも、帯域幅に縛られるデコードも、どちらも遅くなるはずだ
今週ローカルLLMを構築したばかりなので、自分の経験も参考までに。IntelのArc B70という32GBカードを選んだ。3090より安く、RAMは多いが、メモリバスは遅い
これを選んだ理由は、使いたいモデルが24GBに余裕で収まるには少し大きく、オートコンプリートや音声認識用の小さなモデルをいくつか載せる余地も必要だったからだ。また、すでに安価なサーバーがあり、デュアルGPUにするにはマザーボードと電源、おそらくケースまで交換する必要があった
設定はかなり厄介だった。IntelのラインはSYCL、ざっくり言えばIntel版CUDAのようなものをサポートするために「level zero」というドライバーパッケージが必要で、これをきちんと動かすのが難しかった。llama.cppをDockerコンテナで動かしているが、コンテナにカードを認識させるのにも少し手間がかかった。ここ数か月以内のカーネルも必要だ
いったん動き出すと、1,000ドルの投資としては結果は非常に印象的だ。Qwen 3.6 35Bをq4量子化で動かすとRAMの約3/4を使い、88トークン/秒ほど出る。安価にほどよいサイズのモデルが欲しいなら一つの方法だ
B70は256ビットバスで2375MHz、608 GB/s、3090は384ビットバスで2438MHz、936 GB/sだ。遅いのではなく、チャネル数が少ない、つまり幅が狭いのだ
qwen3.6-27bはq4変種を3090 1枚で、全体約250Kコンテキストでも動かせる
もどかしくない程度には十分速いので、3090を2枚にして得られる速度向上は自分には価値がない。2枚でq6を半分の速度とより小さいコンテキストで動かす選択肢もあるが、いずれにせよ最新級モデルとは競えないので、すでに3090を2枚持っているのでなければ、現在の価格では1枚が最善の投資だと思う。よく構成された実行環境があれば、多くのことをするには十分だ
自分の経験では、その精度だと長いコンテキストの想起精度が大きく落ちる。KVキャッシュはq8にして120kコンテキストで作業するほうが良かった
関連して、今使える最高の隔離システムは何なのか気になっています。完全な厚いVMまで行くべきなのか、Firecrackerのようなもので十分なのか分かりません
可能な選択肢のどれにも、足を吹き飛ばしやすい微妙な落とし穴があり、実質的にまったくセキュリティがない状態になりがちに見えます。VMを使うのは、セキュリティがこの技術の基本原則だと実際に信頼できるからであって、「この20個のフラグを使って目を細めれば大丈夫」といった方式ではありません
まず攻撃ベクトルをモデル化する必要があります。
rm -rfは書き込み制限で防ぎ、curl malware.sh | shは書き込み可能なディレクトリでの実行を制限すればよいです（seatbelt/SELinux）。機密ディレクトリへの書き込み制限だけでも、ほとんどのマルウェアはかなり無力化される可能性が高いです認証情報の流出は、環境変数を整理し、.ssh、.awsなどの読み取りを禁止し、LLMを運用システムの近くに置かなければよいです
MacOS用の小さなユーティリティ https://github.com/aka-rider/leash を作りましたが、bashスクリプトでも可能です
軽いものが欲しければ bubblewrap[1] のようなものを使うか、libkrun[2] のようなmicroVMを使えますし、関連ツールまで欲しければ完全なDockerまで行けます
[1] https://github.com/containers/bubblewrap
[2] https://github.com/libkrun/libkrun
すべてがしっかりロックされていると実際にどう分かるのか、という不確実さには共感します
個人的にはVMやmicroVMが正しい道だと思います。コンテナと違い、これらは実際のセキュリティ境界として設計されています。bubblewrapと比べても、エージェントにファイルシステム全体を渡してYOLOモードで動かせる一方、bubblewrapでは各開発ツールの可用性をいちいちブートストラップし、設定ディレクトリやパッケージキャッシュなどを安全にマウントする必要があり、それでも権限エラーに遭遇し続ける可能性が高いです。隔離もはるかに弱いです
実行環境のサポートは限られますが、ホストで実行環境プロセスを動かし、すべてのツール呼び出しとファイルシステム操作をVMに委任する方式はかなり妥当だと思います。そうすれば、セッションデータと認証キーをメインマシンに保持し、コンテキストの中に絶対に入らないようにできます。その代わり、実行環境自体がセキュリティ境界の一部になるので、そこがトレードオフです
VMの内外へデータをどう移すかも使い勝手の問題になります。ローカルのgitリポジトリをVMへ押し込み、リモートのように再び取り出すスクリプトを使っていますが、そうするとVMがホストへ接続を開始できず、git認証情報も持つ必要がありません。ただし、エージェントにGitHubへ直接pushしてほしい人にはやり過ぎかもしれません
VM自体で試した、または見た選択肢は qemu + libvirt、crun-vm、libkrun 系です。qemu + libvirtは合わせるのに手間がかかりますが、非常に検証されており設定可能性も高いです。crun-vmはpodmanとqemuの間の高レベル統合レイヤーのPoCで、放棄されたように見えますが、既存ツールと標準中心なので興味深いです。libkrunはより新しい参入者で、microsandbox、smolvm、krunvmのようなラッパーがあります。いずれもLinux基準です
ここまで苦労してLLMを使うのは妙に感じます。特にこのように最先端を追うのはなおさらです
Claudeのようなものが明日消えても、私は眉一つ動かさないでしょう
人々がなぜ自分の脳のしわをスロップ機械へのアクセス権と引き換えにするのか理解できません。いい比喩で言えば、熟練の大工にIkeaより一、二段低い品質の家具を吐き出す機械を渡すようなものかもしれません。仕事はこなせるのか？ たいていはそうです。大工はその過程を楽しむのか？ いいえ
私の経験では、q4のように大きく量子化された、あるいはある程度変形されたモデルを動かしてみて「わあ、本当にすごい」と感じたことはありません。むしろ数回プロンプトを入れた後、ゴミ箱行きになりました
96GBのRTX 6000 PROがありますが、快適に動かせるのはQwen 3.6 27BやMoE、Gemma 4 31Bあたりです。モデルを全精度かつ最大コンテキスト長で動かす場合は、ここまでが限界です
これらは性能が良く、コーディング、インターネット調査などさまざまな用途に使えます。計算してみてAnthropicに年2,400ドルより多く使いそうなら、このようなカードを買うのは筋が通るかもしれませんが、品質低下は受け入れる必要があります。いずれにせよ、5年後にも人間がコーディングしているかどうかさえ疑問です