James O'Brien の SOTA LLM をローカルで実行するガイド（12 分読）

jamesob's によるローカル環境で SOTA LLM を動かすガイド

*注：この README の記述のうち、表以外の部分は AI が作成したものではありません。*

ポケットの中で燃えるように熱い $2,000 を持っていて、ローカルで動作する最先端の機械知能を手に入れたいですか？

それとも $40,000 ならどうでしょう？

Dario や Altman の動向に胸が痛む（そうあるべきです）という方は、この新しい計算形態をローカル環境で動かす方法を以下でご覧ください。

このリポジトリには以下の内容が含まれています。

• SOTA LLM をローカルで動作させるために私が使用しているハードウェアと購入理由、そして設定に関するあまり知られていない*秘訣*
• ローカルで音声認識（STT）を動かす方法
• 良質だと判断したモデルを Docker コンテナ内ですぐに実行するための構成ファイル

自作環境の紹介

私は運良く（あるいは無謀にも）、まだ価格が安かった頃に RTX Pro 6000 を 4 枚購入しました。現在はメモリが高騰しているため、これらの GPU を搭載するシステムには前世代の DDR4 を採用し、パーツは eBay で調達しました。これにより、ベースシステムの費用を抑えつつ、十分な VRAM を確保することができました。

また、私が行ったもう一つの珍しい工夫が PCIe4 スイッチの使用です（詳細は c-payne.com）。これにより、テンソル並列処理における allreduce 手順で GPU 同士が PCI ルート複合体を経由せず、有線速度で「直接」通信できるようになります。その結果、カード間のレイテンシが低下し、高価な PCIe5 ハードウェアへの依存も減ります。

つまり、私は今や 2026 年 7 月時点で極めて高額になっている PCIe5/DDR5 ベースシステムにお金をかけるのではなく、重要な VRAM に投資しているのです。

私の具体的なパーツ構成は以下の通りです。

予算はいくらまで？

およそ 2,000 ドル

最もコストパフォーマンスに優れた選択肢の一つが、RTX 3090 を 2 枚使用して合計 48GB の VRAM を確保する方法です。これにより、素晴らしいモデルである Qwen3.6-27B を動作させることができます。

また、SOTA（最新技術）の音声認識 (STT) モデル `whisper-large-v3` も利用可能です。私はこのモデルを非常に有用だと感じています。このモデルを実際に使うには、私が開発したクロスプラットフォーム対応の `stt` ハーネス を使用します。

ローカルでの音声認識 (STT) の有用性に気づき、ホスト型サービスを使うよりも安心して利用できるようになりました。Nvidia GPU で約11GBのVRAMがあれば動作する、すぐに使える設定ファイルは `./runners/stt` に用意されています。

約4万ドル

この価格帯になると、モデルの知能レベルが一段階向上します。Claude Opus に匹敵する性能が得られるでしょう。

RTX 6000 Pro を4枚購入し、合計384GB の VRAMを確保するのが一般的です。

4x RTX6kPRO向け現在の最良モデル

その他のアプローチ

※あくまで私の推奨事項ですが、他にも十分に有効な資金の使い道は存在します。例えば、RTX 6000 Pro を 4 枚購入するのではなく、予算の大半を リンクされた 4x DGX Spark クラスター の構築に充て、VRAM を合計 512GB に拡張して「遅いが巨大な頭脳」として活用し、Qwen3.7-27b が単純作業を高速で処理するよう駆動させるという運用も可能です。

ハードウェア

私が実際に 4 枚の RTX 6000 Pro を搭載したマシンに投入したハードウェアの詳細は以下の通りです。

ベースシステム

中古市場（eBay）から部品をほぼすべて調達し、組み立てた昨世代の EPYC システムです。コストパフォーマンスを重視した控えめな構成となっています。

GPU

GPU が必要だ。

c-payne 社の PCIe Gen4 スイッチ用サブ BOM（c-payne.com）

GPU マウント

PCI スイッチと GPU を収める木製の筐体を自作する必要があり、完成までに約 1 日かかりました。

PCI スイッチに内蔵されたファンが非常にうるさく、効果も感じられなかったため、基板からケーブルを抜いて使用していません。

モデル重みの保管

すべてのモデルの重みは、~/storage にマウントされた ZFS ファイルシステム上に保存しています。このストレージは 8TB ドライブ 2 台間でレプリケーションされており、冗長性を確保しています。

実行したいモデルがある場合、まずは以下のコマンドでダウンロードします。

hf download <model-name> --local-dir ~/storage/<model-name>

モデルの実行

モデルの重みをローカルにキャッシュしたら、各モデルごとに専用のディレクトリを用意し、そこに docker-compose.yml ファイルを配置して、それぞれのモデルを独立した Docker コンテナ内で実行するようにしています。

これらの設定は `./runners/` で確認できます。

各コンテナは、ローカルにキャッシュした重みを読み取るために、~/storage/models に読み取り専用でマウントされます。

その後、別のマシン上の仮想マシンでホストされた opencode を使用し、モデルが http://clank.j.co:5000 でサービスを開始した後にアクセスします。

私はネットワーク内の DNS サーバーを使って、clank.j.co を LLM 専用マシンに割り当てていますが、単純に http://<llm-machine-ip>:5000 とアクセスしても問題ありません。

ハーネスそのもの

VM を作成し、その ~/src ディレクトリツリー内の各フォルダごとに tmux セッションを自動生成するアプリケーションを構築しました。このセッションでは、推論マシン上の HTTP API（http://clank.j.co:5000）にバックアップする opencode インスタンスが起動します。

オープンソースモデルを十分に活用するための鍵は、適切なツールを整備することです。私が構築した skills/ の構成要素を以下にまとめます。

• ウェブブラウジングと検索には camofox、kagi.com API キー、そして searXNG を使用します。
• 通信やアラート通知には Telegram ボットを活用しています。
• ソースコードでの共同作業には、ローカルで構築したプライベートな Gitea インスタンスを運用しています。

この「クランカー」は、対話形式のセッションを通じて私と連携することもあれば、Gitea の課題解決やプルリクエスト作成といったタスクを任せて実行させることも可能です。

これらすべての処理は、隔離された仮想マシン（VM）内で行われます。ホストシステムとの通信経路は共有ファイルシステムのマウントポイントに限定されているため、この環境内で何らかの動作を行っても、外部への影響を最小限に抑えつつ、必要なパッケージやツールのインストールも自由に行えます。

PCI スイッチの正常動作に向けた設定

マザーボードが PCI スイッチの速度を意図せず低下させないよう、BIOS での細やかな調整が必要でした。

BIOS 設定（ROMED8-2T）

Redriver のゲイン調整

c-payne 氏のアドバイスに従い、彼のツール を使ってゲインを「lvl 3」に下げました。これが今回の作業の中で最も厄介な部分でした。

ゲインレベルは、SAS コネクタケーブルの長さに依存します。

適切な SAS ケーブルの選定

私は c-payne 公式サイトから必要な数のケーブルを発注するのを間違えてしまい、不足してしまいました。そのため、Amazon で「同じ SAS ケーブル」だと思って購入したのですが、実際にはわずかな違いがあり問題が発生しました。結局、再度ケーブルを注文する必要があったので、必ず正しい製品が手に入っているか確認してください。

カーネル / GRUB パラメータ

# /etc/default/grub
GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub

# nvidia_uvm P2P fix
echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u

iommu=off を指定しないと、マルチ GPU の P2P 通信で NCCL がハングアップします。

ACS Disable（スイッチ P2P に必須）

ACS を有効化すると（デフォルト設定）、P2P 通信がスイッチ内部を流れるのではなく、CPU のルートポートを経由して迂回されてしまいます。これではスイッチの存在意義が失われてしまいます。

pcie_acs_override パラメータはパッチ済みカーネルが必要となるため、ここでは setpci コマンドを使ってランタイムで無効化します。

# /usr/local/bin/disable-acs.sh
#!/bin/bash
if [ "$EUID" -ne 0 ]; then
  echo "ERROR: must be run as root"
  exit 1
fi

for BDF in $(lspci -d "*:*:*" | awk '{print $1}'); do
  setpci -v -s ${BDF} ECAP_ACS+0x6.w > /dev/null 2>&1
  if [ $? -ne 0 ]; then
    continue
  fi
  echo "Disabling ACS on $(lspci -s ${BDF})"
  setpci -v -s ${BDF} ECAP_ACS+0x6.w=0000
done

systemd の oneshot として設定すれば、起動時に自動的に実行されます。

# /etc/systemd/system/disable-acs.service
[Unit]
Description=Disable PCIe ACS for GPU P2P
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/disable-acs.sh

[Install]
WantedBy=multi-user.target

確認事項：lspci -vvv | grep ACSCtl を実行すると、すべての行にマイナス記号（-）が表示されるはずです。また、nvidia-smi topo -m で確認すると、4 つの GPU 間の接続が PIX（PCIe Switch）である必要があります。PHB や NODE ではありません。

これらを簡単に測定するには、`./tools/measure-gpu-speed.sh` を使用してください。

GPU の電力制限

220V の回路を新たに設置するのは避けたいため、私は（おそらく無謀にも）このマシンを単一の 110V 回路で稼働させています。ただし、GPU カードには電源レギュレーターを追加して安定化を図っています。

ブート時に systemd を介してパージステンスモードと電力制限を適用する

(install-gpu-power-limit.sh):

sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350    # 350W per GPU (default 600W)

GPU 1 基あたり 350W、合計 1,400W の GPU 負荷は電源ユニットの予算に合わせて設定されています。240V 回路への移行前の中間段階では、単一の 1700W PSU を使用していましたが、その際カードは約 260W で動作していました（4×260 = 1,040W の GPU 負荷にシステム側で約 280W を加えた合計約 1,320W）。

確認コマンド：nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv

結果

アップストリーム（CPU との直接接続）では Gen4 x16 で約 30 GB/s。スイッチを介した P2P 通信では、双方向で最大 50.4 GB/s、単方向で 27.5 GB/s を達成し、レイテンシは 0.37–0.45 µs です。これは Gen4 のラインレートに匹敵する性能です。

なお、ASPM がどこかで有効になっている場合、アイドル時に lspci で確認すると GPU リンクが「2.5GT/s（ダウングレード済み）」と表示されることがありますが、これは見た目の問題に過ぎません。負荷がかかるとリンクは再訓練されて Gen4 に復帰します。

リソース

• 4 枚、6 枚、8 枚の RTX 6000 Pro を最大限活用する方法をまとめた、頻繁に更新されるリポジトリ：https://github.com/local-inference-lab/rtx6kpro

• 私が使用しているインディペンデントな PCI スイッチ：https://c-payne.com

• RTX6kPRO の Discord サーバー。多くのユーザーがベンチマークや新モデルのテストを行っています：https://discord.gg/QMNvFkuDN