8月17日、AMD ROCm Blogが「Bring Claude Code On‑Prem with AMD Instinct GPUs」と題した記事を公開した。FP8量子化で756 GBのHBMを要するGLM 5.2を、AMD Instinct MI355X GPUを搭載したオンプレサーバー上で動かし、Claude Codeのバックエンドとして利用する方法が詳しく紹介されている。コードもデータも外部クラウドに出さずにエージェント型コーディングを実現したい組織にとって、実践的な構成ガイドとなっている。
クラウドAPIを使えない組織にとっての現実的な課題
Claude Codeはデフォルトで、プロンプトと読み込んだコードコンテキストをAnthropicのクラウドAPIに送信する。多くの個人開発者や小規模チームにとってこれは問題にならないが、医療記録・金融モデル・政府の機密データ・厳格なIP契約下のソースコードを扱う組織にとっては致命的な制約となる。
HIPAA、SOC 2、FedRAMP、ITARといったコンプライアンスフレームワークは、データを処理する場所を明示的に制限している。加えて、トークン単位のクラウド課金は継続的なエージェント型ワークフローを運用するチームにとってコスト面の問題も生じる。
「ローカルLLMでClaude Codeを動かす」ガイドはすでに多数存在するが、この記事はそれとは異なるアプローチを取る。開発者マシンにはClaude Codeだけを置き、モデルはGPUサーバー上で動かすという構成だ。
なぜ「開発者マシンでLLMを動かす」では不十分なのか
ここが本記事の核心だ。一般的な「ローカルLLM」ガイドの問題点を、記事は以下の比較表で整理している。
| 観点 | クラウドホスト | 開発者マシン上のLLM | GPUサーバー上のLLM（本記事） |
|---|---|---|---|
| データプライバシー | ネットワーク外に出る | マシン内に留まる | 自社インフラ内に留まる |
| モデル品質 | 最先端の大規模モデル | コンシューマーGPUメモリの制約で小型/高量子化モデルのみ | フルサイズの本番品質モデル（例: GLM 5.2、756 GB FP8） |
| コストモデル | トークン単位課金 | 既存ハードウェア | 共有GPUサーバー、固定インフラコスト |
| 開発者マシンへの影響 | なし | IDE・ブラウザと競合 | なし |
| オフライン使用 | 不可 | 可能 | エアギャップ環境でも可（サーバーへの到達性が前提） |
GLM 5.2はFP8で756 GBのHBMを必要とする。 開発者ワークステーションでこれを動かすには大幅な量子化が必要となり、エージェント型コーディングが依存するツール呼び出し精度と推論品質が劣化する。
構成の全体像：3層スタック
アーキテクチャはシンプルな3層構造になっている。
Claude Code (CLI or VS Code)
| Anthropic Messages API (POST /v1/messages)
v
LiteLLM router (127.0.0.1:4000 on the server, reached over SSH tunnel)
| OpenAI API
v
GLM-5.2 (SGLang, 127.0.0.1:31090 on the server)
LiteLLM（軽量APIトランスレーションレイヤー）が重要な役割を果たす。Claude CodeはAnthropicのMessages APIで話し、SGLang（高性能LLM推論エンジン。連続バッチ処理・RadixAttention・投機的デコードなどを実装したOSS）はOpenAI APIで話す。LiteLLMがその間に立ち、ツール呼び出し・ツール結果・ストリーミングを含めたフォーマット変換を行う。単純なプロキシでは不十分で、LiteLLMなしではツール引数が切り捨てられるかクライアントがクラッシュすると記事は明記している。
SSHトンネルがセキュリティ境界を担う。LiteLLMはサーバーの127.0.0.1:4000にバインドし、個人のSSHトンネル経由でのみ到達可能な構成とする。設定に使われるキー（sk-glm-localなど）はローカルのダミー値であり、実際のセキュリティ境界はSSHトンネル自体が担う。
モデル：GLM 5.2の特性
本記事が採用するモデルはGLM 5.2だ。開発元のZAI（旧称 Zhipu AI）は中国・北京に拠点を置くAI企業で、GLMシリーズ（General Language Model）を継続的に開発・公開している。GLM 5.2はその最新世代にあたる。主要な特性は以下のとおり。
- MoEアーキテクチャ：総パラメータ数約753B、トークンあたりのアクティブパラメータは約40B
- 1Mトークンのコンテキストウィンドウ：IndexShareアーキテクチャにより1Mコンテキスト時のトークンあたりFLOPsを2.9倍削減
- ネイティブツール呼び出し：SGLangの
--tool-call-parser glm47と--reasoning-parser glm45フラグで有効化。Claude Codeのファイル読み書き・テスト実行・コードベース検索などのエージェントループはすべてツール呼び出しに依存するため、この対応は必須条件だ - FP8量子化＋8-way テンソル並列：8枚のAMD Instinct GPU（各288 GB HBM3、8 TB/sバンド幅）に分散して動作
- 投機的デコード（MTP）：内蔵のMTPドラフトレイヤーがSGLangのEAGLE投機的デコードと連携し、デコードスループットを向上
セットアップ手順の概要
前提条件
| 要件 | 詳細 |
|---|---|
| GPUサーバーへのSSHアクセス | ssh <username>@<server_name> true が通ること |
| Bashシェル（開発者マシン） | WSL（Ubuntu）、Linux、またはmacOS。元記事ではWindows PowerShellは明示的に非対応と記載されている |
| VS Code（任意） | VS Code拡張機能を使う場合のみ必要 |
GPUサーバー側
まずモデルウェイト（約756 GB）をダウンロードする。
pip install huggingface-hub
huggingface-cli download zai-org/GLM-5.2-FP8 --local-dir /data/GLM-5.2-FP8
次にSGLangのROCm Dockerイメージを起動し、コンテナ内でサーバーを立ち上げる。
docker run -d --name glm52_baseline \
--network host --ipc host \
--device /dev/kfd --device /dev/dri \
--group-add video --group-add render \
--security-opt seccomp=unconfined --security-opt label=disable \
--shm-size 64g \
-v /data:/models \
rocm/sgl-dev:v0.5.15.post1-rocm720-mi35x-20260714 sleep infinity
コンテナ内でSGLangサーバーを起動する。
export SGLANG_ROCM_FUSED_DECODE_MLA=0
export SAFETENSORS_FAST_GPU=1
python3 -m sglang.launch_server \
--model-path /models/GLM-5.2-FP8 \
--tp 8 --port 31090 --trust-remote-code \
--enable-expert-parallel \
--tool-call-parser glm47 --reasoning-parser glm45 \
--mem-fraction-static 0.85 \
--model-loader-extra-config '{"enable_multithread_load": true, "num_threads": 8}' \
--nsa-prefill-backend tilelang --nsa-decode-backend tilelang --disable-radix-cache \
--kv-cache-dtype fp8_e4m3 \
--served-model-name glm-5.2-fp8
完成後の状態
セットアップが完了すると、以下の構成が整う。
- SGLangがGPUサーバー上でGLM 5.2をFP8量子化・8-wayテンソル並列で提供
- LiteLLMルーターがClaude CodeのAnthropicメッセージAPI呼び出しをSGLangへのOpenAI APIリクエストに変換
- SSHトンネルが開発者マシンとLiteLLMルーターを接続
- Claude Code（CLIまたはVS Code）がGPUサーバーをAnthropicのAPIかのように利用
- すべての推論がAMD MI355X上で完結し、コードとデータは自社インフラの外に出ない
詳細はBring Claude Code On‑Prem with AMD Instinct GPUsを参照していただきたい。
