はじめに
ローカル LLM を SV/UVM 用に評価している流れで、Z.ai の GLM-5.2（744B MoE / 40B active）を自分の評価ループに入れてみたくなりました。問題はサイズです。FP8 でも重みだけで約 744GB、私の手元（WSL2 機や届く予定の M5 Max 128GB）には到底載りません。
ただ、Unsloth の Dynamic 2-bit GGUF（約 240GB）まで落とせば、クラウドの GPU を数枚借りれば回せます。用途は常時稼働ではなく「評価したいときに 1日8時間くらい」。
ここで一つ、正直に認めておくべきことがあります。ローカルLLM（WSL2 機や M5 Max）で評価する場合は、通すコードもプロンプトも手元のマシンから一歩も出ない、いわばエアギャップ相当の守りがあります。クラウドに出す以上、この守りは失われます。プロンプトも生成結果も、TLS で暗号化されるとはいえネットワークを通って事業者のデータセンターに渡るので、もう「物理的に隔離されている」とは言えません。
それでも、せめてデータ主権 ─ コードが日本国内・自分のサブスク・Western 法域の中に閉じている状態 ─ までは守りたい。整理すると、守りの強さはこういう序列になります。
| 選択肢 | エアギャップ | データ主権 | ひとことで |
|---|---|---|---|
| ローカル実行（これまで） | あり（相当） | ◎ | 最強の隔離。コードが手元から一歩も出ない |
| 東京ハイパースケーラの自サブスク（今回検討） | なし | ◎ | エアギャップは失うが、主権は維持できる |
| Western API（Fireworks 等） | なし | ○ | 第三者のホスト型に出す |
| 匿名マーケット型ネオクラウド（Vast.ai 等） | なし | △〜✕ | 所在も運用者も握れない |
| 中国系 API（z.ai 直叩き等） | なし | ✕ | 中国法（国家情報法・データセキュリティ法等）の適用下に入るため、検討外 |
補足: z.ai を直叩きすると基本的に中国本土のインフラで処理されるため、送ったプロンプト（＝コード）が中国法の適用下に置かれます。中でも国家情報法 第7条（組織・個人の情報活動への協力義務）が懸念の中心です。ただし実際の処理リージョンや越境移転の扱いは利用規約・データ処理条項次第で、断定はできません。私は法律の専門家ではないので、最終的なコンプラ判断は利用規約と社内規程（必要なら法務）でご確認ください。なお GLM-5.2 の重みは MIT ライセンスなので、Western ホストの API か自前ホストにすればこの問題自体を回避できます。
「エアギャップは手放すが、データ主権までは手放さない」。この線引きが今回の出発点で、だから z.ai や中国系インフラ、ホストが匿名のマーケット型ネオクラウドは外し、「Western クラウドの東京リージョンで、自分のサブスク内で、使うときだけ起動」という構成に絞り込みました。
そこで AWS / Azure / GCP / Cloudflare、さらに RunPod・Spheron・Vast.ai といったネオクラウドまで横並びで比較してみました。比較した結果、現時点で一番有力に見えたのは次の構成です。
Azure の Japan East、NC96ads A100 v4（A100 80GB × 4）を Spot で使う
Spot なら 8h×20日でおおよそ月8.5万円前後。この記事はその比較プロセスと、有力候補として検討してみた Azure Spot の使い方・ハマりどころを、自分の備忘録も兼ねてまとめたものです。まだ運用を始めたわけではなく、「机上で検討してみた」段階のメモです。
本記事の価格はすべて 2026年6月時点の概算です。クラウド GPU の単価・在庫・Spot 価格は頻繁に動きます。実際に発注する前に、各社の料金ページと Azure ポータルの料金履歴で必ず最新値を確認してください。為替は 1USD≈¥162 で換算しています。
要点（先にまとめ）
- GLM-5.2 2-bit は約 240GB。全 VRAM 載せなら「80〜96GB GPU ×4（320〜384GB）」または「L40S ×8（358GB）」が目安。
- Cloudflare は土俵が違う。Workers AI はサーバーレス推論（トークン従量）で、240GB の自前モデルを持ち込んで動かす用途には使えない。X で「GLM-5.2 を無料で」と話題になったが、無料枠は1日 10,000 Neurons と小さく、超えれば普通の従量 API、しかもホスト型で主権要件も満たさない（自前ホストの代替にはならない）。
- ネオクラウド（Vast.ai/RunPod/Spheron）は月7〜14万円とハイパースケーラの 1/3〜1/5。ただし日本拠点が弱く、市場型は実行ハードの所在を握れないので、センシティブなコードを通すなら主権面で不利。
- 東京ハイパースケーラ（GCP/Azure/AWS）は主権最強・最も高い。その中で Azure A100 v4 が在庫の厚さとコストのバランスで一番マシに見えた。
- 有力候補は Azure Spot。Spot で月8.5万円前後、主権はオンデマンドと同等（同じ Japan East の MS データセンター）。代わりに「30秒で落とされる」前提の設計が必須。
- 落とされても痛くないよう、stateless 推論＋resumable な評価ループ＋自動再デプロイで組むのがコツ。長い1本の run だけは別扱いにする。
- 別軸として Claude Code / Codex のサブスク（$200≈¥3.2万）はコストだけなら自前ホストより安いが、動かすのは Claude/GPT で GLM-5.2 ではなく、コードも US ホストに出る（主権は Western API 相当）。さらに週次キャップがあり、重い 8h/day だと週の途中で当たる。「強いエージェントが欲しい」ならサブスク、「GLM-5.2 を主権下で上限を気にせず評価したい」なら自前ホスト。
前提: GLM-5.2 2-bit に必要なメモリ
GLM-5.2 は 744B 総パラメータ・40B active の MoE です。MoE でも active は推論時だけの話で、重みは全部メモリに載せる必要があります。各精度のおおよその footprint は次の通りです。
| 精度 | 重みサイズ(目安) | 載る構成の例 |
|---|---|---|
| BF16 | 約 1.5TB | 8×H200 でも厳しい |
| FP8 | 約 744GB | 8×H200（1,128GB）に収まる |
| 2-bit (UD-IQ2_M / UD-Q2_K_XL) | 約 240GB | 4×(A100/H200/RTX PRO 6000) or 8×L40S |
| 1-bit (UD-IQ1_S / UD-IQ1_M) | 約 217〜228GB | さらに小さいが精度は落ちる（総メモリ約 223GB） |
本記事は 2-bit（約 240GB）前提です。全 VRAM 載せで気持ちよく回すなら合計 320〜384GB の VRAM が欲しい、というのが出発点になります。
A100 でも 2-bit は動くのかという疑問がでるかもしれませんが、結論としては動きます。2-bit GGUF の推論に世代の縛りはありません。llama.cpp の 2-bit（IQ2 系など）は重みを 2bit で「格納」しているだけで、計算時には GPU が扱える精度（FP16/BF16）へ逆量子化してから積和します。A100 は FP16/BF16 を普通に回せるので、量子化形式が 2bit でも問題なく動作します（Unsloth の GLM-5.2 2-bit GGUF も A100 を含む各種 GPU で動作実績あり）。後述する A100 の「FP8 テンソルコア非対応」は、FP8 で配布されたモデルをハード支援で速く回す機能の話で、2bit GGUF の可否とは別物です。ただし世代差は「動くか」ではなく「速度」に出ます。2-bit 推論はメモリ帯域律速になりやすく、A100 の HBM2e 約 2.0TB/s は H100 の HBM3 約 3.35TB/s より狭いぶん、トークン生成は遅くなります。なお GLM-5.2 は MoE で active 40B なので、240GB を全載せしても1トークンあたり実際に読むのは active 分が中心。A100 80GB×4=320GB に全載せできれば CPU オフロードなしで素直に回せます。
KV キャッシュの注意: A100 80GB×4=320GB は、約 239GB の重みに加えて「ほどほどのコンテキスト長」までは載りますが、余裕は約 80GB しかありません。GLM-5.2 の売りである 1M トークンコンテキストをフルに使うと KV キャッシュだけで数百 GB に膨らむため、長コンテキストを使う場合は llama.cpp の KV キャッシュ量子化（
--cache-type-k q4_1 --cache-type-v q4_1やq8_0など）が事実上必須になります。評価で長文を流すなら、ここを忘れると OOM します。
精度の注意: 2-bit は top-1 で約 82%、「フル比で約 18% 劣化」とされます。これは「能力が一律に2割落ちる」という意味ではありませんが、UVM ドライバ生成のようにプロトコルの正確さ（VALID/READY 順序、B チャネル方向、fork…join 並列）で点が動く評価では量子化が効いてくる可能性があります。当たり付けは 2-bit、最終採点だけ 4-bit（UD-Q4_K_XL, 約 376GB）で取り直す二段運用が無難です。本記事は「当たり付け用に安く回す」前提で 2-bit を選んでいます。
比較: 主要クラウド + ネオクラウド
評価条件は 2-bit（約 240GB）/ 1日8h × 20日 = 月160h / 1USD≈¥162 で揃えました。各社で「2-bit が載る最小構成」を選んでいます。
| プロバイダ | 構成 | VRAM | 時間単価(OD) | 月160h(OD) | Spot単価 | 月160h(Spot) | 主権 |
|---|---|---|---|---|---|---|---|
| GCP(東京) | g4-standard-192（RTX PRO 6000 ×4） | 384GB | $18.0 | 約47万円 | $3.69 | 約9.6万円 | ◎ |
| Azure(Japan East) | NC96ads A100 v4（A100 80GB ×4） | 320GB | ≈$14.7 | 約38万円 | ≈$3.3 | 約8.5万円 | ◎ |
| AWS(東京) | g6e.24xlarge（L40S ×4）＋RAMオフロード | 192GB | ≈$15.1 | 約39万円 | ≈$6.5 | 約17万円 | ◎ |
| AWS(東京) | g6e.48xlarge（L40S ×8 全載せ） | 358GB | ≈$30.1 | 約78万円 | ≈$13 | 約34万円 | ◎ |
| Spheron | A100 80GB ×4 | 320GB | ≈$4.3 | 約11万円 | さらに下 | ─ | △ |
| RunPod | A100 80GB ×4 | 320GB | ≈$4.8〜5.6 | 約12〜14万円 | ─ | ─ | △ |
| Vast.ai(市場型) | A100 80GB ×4 | 320GB | ≈$2.7 | 約7万円 | ─ | ─ | ✕〜△ |
| Cloudflare | Workers AI（自前モデル持ち込み不可） | ─ | ─ | ─ | ─ | ─ | ─ |
数字の出どころ（2026年6月時点）: AWS g6e.48xlarge は L40S×8 計384GB で US 月約 $21,995（≈$30/h）。Azure NC24ads A100 v4（A100 80GB×1）が $3.673/h・Spot $0.82/h なので 4 枚で上表。ネオクラウドは RunPod が A100 80GB $1.19〜1.39/h、Spheron が A100 80GB SXM ≈$1.07/h、Vast.ai が市場価格で A100 SXM 80GB ≈$0.67/h あたり。いずれも要再確認。
Azure の Spot 単価について補足: 上表の ≈$3.3/h は NC24ads の Spot を 4 倍した推定値です。NC96ads A100 v4 の直接掲載 Spot 価格はリージョン・時間帯により ≈$2.95〜3.29/h と幅があり（East US で ≈$2.95/h の例あり）、実際はもう一段安いことがあります。発注前に VM 作成画面の「View pricing history and compare prices in nearby regions」で実値を確認してください。なお NC96ads A100 v4 が Japan East で利用可能なこと、A100 v4 が Spot 対応であることは確認済みです。
Cloudflare が表で空欄な理由
Cloudflare Workers AI は「GPU を借りる場所」ではなく、キュレーションされた公開モデル群をサーバーレスで叩く仕組みです。課金は「Neuron」（$0.011 / 1,000 Neuron）= 実質トークン従量。つまり GLM-5.2 の 240GB GGUF を自分で持ち込んで llama.cpp で動かす、という使い方ができません（プライベート/カスタムモデルは別途エンタープライズ相談）。
実は GLM-5.2 については、Cloudflare が 2026年6月16日（Z.ai のモデル公開翌日）に Workers AI のカタログへ追加しています（モデル ID @cf/zai-org/glm-5.2、コンテキスト 262k）。なので「Cloudflare で GLM-5.2 を叩く」こと自体は今すぐできます。ただしこれはあくまで Cloudflare のホスト型 API を叩く話で、本記事の「自分のサブスク内・東京で動かす」自前ホストとは別カテゴリです。
余談: X で話題の「Cloudflare で GLM-5.2 を無料で動かす」件
先日、X で「Cloudflare Workers AI なら GLM-5.2 が無料・無制限で使える」という投稿が拡散しました。OpenCode や Cursor、Claude Code などの OpenAI 互換ツールから @cf/zai-org/glm-5.2 を指すだけ、というやつです。手軽なコーディングエージェントのお試しとしては確かに良いのですが、これを「コスト問題が解決した」と受け取るのは早計です。理由を整理します。
まず「無料・無制限」は正確ではありません。実際この投稿にはコミュニティノートが付いて訂正されていて、Workers AI の無料枠は1日あたり 10,000 Neurons です。$0.011 / 1,000 Neuron 換算で1日約 $0.11 相当。GLM-5.2 の従量単価は入力 $1.4/M・出力 $4.4/M トークンなので、無料枠で生成できるのは出力換算でおおよそ1日 25,000 トークン程度。エージェントを数回まわせば終わる量で、UVM ドライバ生成を多数流すような評価キャンペーンには全然足りません。
無料枠を超えれば普通の従量課金で、$1.4 / $4.4（入力/出力, 100万トークンあたり）。これは z.ai や Fireworks といった他の GLM-5.2 ホストと同水準で、特別に安いわけではありません。つまり「無料で全部済む」わけでも「飛び抜けて安い」わけでもなく、本格的に回せばそれなりに払う、ごく普通の従量 API です。
そして本記事の文脈で一番効くのはここです。Cloudflare 経由はあくまでホスト型推論で、実行ハードの所在を自分で握れません（Cloudflare のグローバル網のどこか）。コンテキストも 262k で、フルの 1M ではありません。仮に完全無料だったとしても、センシティブな半導体コードを通す主権要件を満たさないので、私の用途では土俵に乗らない、というのが結論です。前述の「主権の序列」でいう Western API の位置づけ（第三者のホスト型に出す）そのものです。
まとめると、「Cloudflare で GLM-5.2 無料」は、雑にコーディングエージェントを試すには便利だが、(a) 無料枠は評価用途には小さすぎ、(b) 有料化すれば普通の従量 API でコストメリットは実質なく、(c) そもそもホスト型なので主権要件を満たさない。だから本記事の比較表からは外していますし、「これがあるから自前ホストを検討する意味はない」という話にもなりません。狙う土俵が違う、というのが正しい理解だと思います。
ネオクラウドが安い理由と、それがそのままリスクになる話
ネオクラウドはハイパースケーラ比でオンデマンド 40〜85% 安く、月7〜14万円まで落ちます。東京ハイパースケーラ（OD ¥38〜78万）の 1/3〜1/5 です。とても魅力的ですが、私の用途では安さの源泉がそのままリスクになります。
- Vast.ai（最安）: 匿名の独立ホストから供給を集める市場型。稼働保証なし、日本拠点も引ける保証なし → センシティブコードは載せない。
- RunPod / Lambda / Spheron: Secure 系を選べば中間。ただし在庫は基本 US/EU 中心で日本リージョンは弱い。「データ所在を東京に固定したい」要件と噛み合いにくい。
- 東京ハイパースケーラ: 物理ロケーション・契約・コンプラを自分で握れる。主権は最強だが最も高い。
速度の目安: decode は何トークン/sec 出そうか
コストとは別軸で、実際の体感速度（生成 = decode のトークン/sec）も見ておきます。ここは構成差が大きいので、コスト表とは分けて整理します。数字はすべて単一ユーザ・llama.cpp・2-bit 前提の粗い目安で、要ベンチです。
| 構成 | GPU / 帯域(枚あたり) | 全VRAM載せ | 推定 decode tok/s（目安・要ベンチ） | ひとこと |
|---|---|---|---|---|
| Azure A100 80GB×4（採用案） | A100 / HBM2e ~2.0TB/s, NVLink | 全載せ(320GB) | おおよそ 15〜40 | 計算性能が高く IQ2 を捌ける。単一ユーザのエージェント用途には十分 |
| GCP RTX PRO 6000×4 | Blackwell / GDDR7 ~1.8TB/s, NVLinkなし | 全載せ(384GB) | おおよそ 12〜35 | 帯域は A100 同等。NVLink 無しはテンソル並列で不利だが層分割なら影響小 |
| AWS L40S×8（g6e.48xl） | L40S / GDDR6 ~0.86TB/s, NVLinkなし | 全載せ(358GB) | おおよそ 8〜20 | 枚数は多いが層分割の decode は単枚帯域律速。帯域が低いぶん遅め |
| AWS L40S×4 + RAMオフロード（g6e.24xl） | L40S 192GB + システムRAM | オフロード | おおよそ 3〜8 | 重みが RAM に溢れた時点で system RAM 帯域(~100GB/s級)律速。一気に落ちる |
| 参考: M3 Ultra 256GB（実測報告） | UMA ~0.82TB/s | ほぼ全載せ(余裕僅少) | 3〜9 | 256GB に 239GB でカツカツ。メモリ逼迫で帯域を活かしきれない |
| 参考: 1×H200 + オフロード（実測報告） | HBM3e + RAM | オフロード | 約 8.7 | 単枚では 239GB が入らずオフロード。H200 でもオフロードだとこの程度 |
| 参考: 2×DGX Spark (GB10) RPC（実測報告） | GB10 / LPDDR5x ~0.27TB/s ×2, RPC接続 | 全載せ(計256GB・1-bit) | 約 8（1-bit, 256K ctx） | ノード跨ぎ RPC が重く、decode は出ても prefill が遅く「実用展開は無理なトイ実験」との報告 |
| 参考: 8×H200 vLLM FP8（別スタック） | HBM3e, NVLink | 全載せ(FP8) | 数十 tok/s 級 | llama.cpp/2-bit とは別物。本番用の高スループット経路 |
算出根拠と注意: decode 速度は「メモリ帯域 ÷ 1トークンあたりに読む重み」でほぼ決まります。GLM-5.2 は active 40B なので 2-bit では1トークンあたり概ね 12〜14GB を読む計算で、例えば 2.0TB/s ÷ 13GB ≈ 154 tok/s が理論上限です。実際は IQ2 系の逆量子化負荷・KV キャッシュ増加・マルチGPU同期で理論値を下回るため、上表はそこに経験的なヘアカットを掛けた粗い目安にすぎません（環境差が大きいので必ず llama-bench で実測を）。重要な性質が2つあります。ひとつは、llama.cpp の層分割（
-sm layer）では単一ストリームの decode は「枚数ぶん速くなる」のではなく単枚の帯域で頭打ちになること（多GPU は速度ではなく容量を稼ぐ手段）。もうひとつは、最大の崖は VRAM に載りきらずシステムRAMへオフロードする構成で、ここに落ちると一気に一桁 tok/s になること。なお prefill（プロンプト処理）は計算律速で桁違いに速く、上表は体感に効く decode 側の数字です。
採用案の A100×4 全載せなら、単一ユーザのエージェント評価には困らない速度域に収まりそうです。一方、コストだけ見て AWS の L40S×4（オフロード）に寄せると、速度が一桁まで落ちて評価が回らなくなりかねません。「全VRAMに載せきること」が、コスト以上に速度を左右するというのが要点です。
ちなみに DGX Spark（GB10, 128GB/~273GB/s）を束ねる構成も話題ですが、報告を見るとこの用途では厳しめです。2台を llama.cpp RPC でつないで GLM-5.2 1-bit・256K コンテキストを動かして約 8 tok/s、4台でも IQ4_XS の llama.cpp で 6.28 tok/s、AWQ-INT4＋エキスパート枝刈り＋専用スイッチで頑張って約 22 tok/s decode、という具合です。いずれも「decode は耐えるが prefill が遅く、ノード跨ぎ RPC が重い」という共通の弱点を抱えます。LPDDR5x の帯域（~273GB/s）と TCP/RPC のオーバーヘッドがボトルネックで、HBM＋NVLink のデータセンター GPU 1ノードに素直に載せる構成のほうが、速度でも運用でも有利、というのが今回の判断材料です。
別軸の選択肢: Claude Code / Codex のサブスクと比べると
ここまでは「GLM-5.2 を自前ホストする」前提で比較してきました。ですが「そもそも強いコーディングエージェントが欲しいだけ」なら、Claude Code や Codex のサブスクのままでよいのでは？ という事になります。コストだけ見ると、実はこちらのほうが安い。ただし軸がいくつかズレているので、正直に整理します。
| 選択肢 | 月額(目安) | 動かすモデル | リミット構造 | 主権 |
|---|---|---|---|---|
| Claude Code Max 20x | $200 ≈ ¥3.2万 | Claude (Opus/Sonnet) | 5時間枠 + 週次キャップ×2 | Western ホスト型 |
| Claude Code Max 5x | $100 ≈ ¥1.6万 | Claude | 同上（枠は少なめ） | Western ホスト型 |
| Codex (ChatGPT Pro) | $200 ≈ ¥3.2万 | GPT-5 系 | 5時間枠 + 週次キャップ | Western ホスト型 |
| Codex (ChatGPT Plus) | $20 ≈ ¥3,240 | GPT-5 系 | 同上（枠は少なめ） | Western ホスト型 |
| 参考: GLM-5.2 自前ホスト(Azure Spot) | ≈ ¥8.5万 | GLM-5.2（自分で） | リミットなし（VRAM 次第） | 自サブスク・東京 |
注意（2026年6月時点・変動が激しい）: 両社のリミットは 2026 年に何度も改定されています（Claude Code は 5月に 5時間枠を倍増、週次上限を 7/13 まで +50% の一時増量など）。最新値は各社の Usage 画面で確認してください。加えて Claude Code の消費は Claude Code・Claude.ai チャット・Cowork で 1 つのプールを共有するので、日中にチャットを多用するとコーディング側の枠が削れます。さらに 2026年6月15日から、対話ではないプログラム実行（Agent SDK、
claude -p、CI、サードパーティ製エージェント）は別建ての月額クレジット枠（Pro $20 / Max 5x $100 / Max 20x $200、API レート課金）に分離されました。評価バッチをスクリプトで自動で回す場合は、対話枠ではなくこちらに当たる点に注意です。
「1日8h でリミットに当たるか」を週区切りで考える
両社とも週次リセットですが、結論から言うと、正確な「週◯時間」「◯メッセージ」は両社とも非公開です。バーン量はモデル・コンテキスト長・並列エージェント数・タスク複雑度で大きく変わるため、「週 45 メッセージ」のような固定値を出している記事は 2025 年の古い数字です。そのうえで、わかっている範囲で見積もります。
重要な前提として、週次キャップは「実際に処理・推論している時間（active compute）」で測られ、ただ開いているだけのアイドル時間はカウントされません。なので「1日8h 起動」イコール「8h 分の消費」ではありません。とはいえ 8h ずっとエージェントを実働させる（並列実行・大きいコンテキスト・連続リファクタ）なら、相応に重くなります。
その前提で、ざっくりこうです。
- $20 クラス（Codex Plus / Claude Pro）: 軽量向け。Codex Plus は「長いリファクタ1本で週次キャップが3時間で枯れた」という報告もあるくらいで、1日8h の実働を毎日続ければ、週の半ばでキャップに当たる可能性が高い。評価キャンペーンには力不足。
- $100 クラス（Max 5x）: かなり伸びるが、重い 8h/day を毎日だと週次キャップに当たる場面は出てきます。
- $200 クラス（Max 20x / Codex Pro）: 最も余裕があり、「1週間分のログをまとめて処理」といった使い方を想定した枠。軽〜中程度の 8h/day なら週内に収まることが多い一方、並列エージェントやマラソンビルドを 8h/day 実働で回すと、ヘビーユーザーは週次キャップに当たると思います(自分もそうなので)。当たった後は API レート従量へオーバーフロー（有料、Max 20x や Codex の追加クレジット）か、リセット待ちです。
まとめると、「1日8h で当たるか」は実働の重さ次第。$20 クラスはほぼ当たる、$200 クラスでも重い回し方なら当たりうる。正確な閾値は非公開なので、評価を止めたくないなら「当たる前提でオーバーフロー（API 従量）を用意しておく」のが安全策です。
では自前ホストの意味は
コストだけ見れば、Max 20x も Codex Pro も $200（約 ¥3.2万）で、GLM-5.2 自前ホスト（約 ¥8.5万）より安く、運用も要りません。一般的なコーディング用途なら、正直サブスクの方が楽です。それでも今回 GLM-5.2 自前ホストを検討したのは、軸が3つズレているからです。
- モデルが違う。Claude Code は Claude、Codex は GPT を動かします。GLM-5.2 そのものを SV/UVM 用に評価・実行したい、というのが今回の目的なので、そもそも代替になりません。(オープンなLLMでどこまで出来るか、という点にも興味があります)
- 主権が違う。どちらもホスト型で、コードは Anthropic / OpenAI のサーバに出ます。Western で、ビジネス利用はデフォルトで学習に使われない等のポリシーはありますが、自サブスク・日本リージョンに閉じる自前ホストとは別物です。前述の序列でいう「Western API（第三者のホスト型に出す）」の位置づけ。
- リミットの性質が違う。サブスクには週次キャップがあるので、大きな評価キャンペーンを止めずに回したいときは、フラットで上限のない自前ホスト（VRAM が許す限り）のほうが読みやすい。
つまり「ただ強いエージェントが欲しい」ならサブスクが安くて速い。「GLM-5.2 を、自分の主権下で、上限を気にせず評価したい」なら自前ホスト。狙う土俵が違う、というのが結論です。
Azure (Japan East) の Spot が有力に見えた理由
主権を最優先にすると、選択肢は実質「東京ハイパースケーラ」に絞られます。その中で Azure が有力に見えた理由は次の通りです。
-
A100 v4 が東京で在庫が厚い。これは「A100 が古いから」が背景にあります。A100 は Ampere 世代（2020 年）で、いまの最前線は H100（Hopper, 2022〜）→ H200（2024）→ B200（Blackwell）と 2〜3 世代後ろ。GPU の取り合い（クォータ待ち・Capacity Block・価格高騰）は最新チップ側で起きていて、新規データセンター増設もそちら中心です。そのぶん A100 は相対的に需要が落ち着き、供給が追いついて在庫が厚く、価格も下がっています。実際 Azure の H100 系（NDv5）はクォータ申請に時間がかかり（経験則として 1〜4週間程度。公式の SLA ではありません）、承認後もオンデマンド在庫は保証されない。AWS の H100（P5）も Capacity Block 予約前提。対して A100 v4 は比較的ポンと取れます。「使われていない」のではなく「最前線の取り合いから外れて枯れている」のがポイントで、Spot でも容量を取り戻される圧力が H100 系より穏やかな傾向があります（最終確認はポータルの eviction 率で）。2-bit 240GB なら A100 80GB×4=320GB で十分なので、無理に H100 を狙う理由がありません。
ただし古さゆえのトレードオフはあります。A100 は FP8 テンソルコアを持たず（FP8 は Hopper 以降）、メモリ帯域も HBM2e で約 2.0 TB/s と、H100 の HBM3 約 3.35 TB/s より狭い。llama.cpp の 2-bit 推論は帯域がトークン速度に効くので、H100/H200 より遅くなります。とはいえ 1日8h の評価用途なら許容範囲、というのが今回の割り切りです。
-
Spot との相性。NC96ads A100 v4（320GB）に 2-bit を全載せでき、Spot で月8.5万円前後。「8h 使ったら止める」運用と Spot は相性が良い（落とされても次に取り直すだけ）。
-
主権が落ちない。Spot でも物理は同じ Japan East の MS データセンター。前述のネオクラウドと違い、主権はオンデマンドと完全に同等。安いからといってここが劣化しないのが効きました。
-
on-demand フォールバックがある。どうしても容量が出ない日は、同じ VM サイズを Standard で起動する分岐を用意できる（その日の数時間だけなら数千円）。
-
GPU 間接続が速い。A100 v4 は NVLink/NVSwitch を持つため、複数 GPU でモデルを分割（テンソル並列）する推論に向きます。後述の GCP 候補（RTX PRO 6000）は NVLink を持たず PCIe 接続なので、高スループットなテンソル並列では不利。価格だけでなくこの点も Azure に寄せた理由です。
GCP の RTX PRO 6000×4（Spot 約9.6万円）も僅差で良い候補でしたが、A100 v4 のほうが東京での在庫実績に安心感があり、今回は Azure を本命に置いて検討を進めました。
GPU 世代を一枚にすると、A100 が「枯れているぶん取りやすいが、速度は譲る」位置づけなのがよく分かります（帯域・年次は概数）。
| GPU | 世代(登場年) | メモリ帯域(目安) | FP8 対応 | いまの立ち位置 |
|---|---|---|---|---|
| A100 80GB | Ampere (2020) | HBM2e 約 2.0TB/s | なし | 枯れて在庫厚・安い ← 今回採用 |
| H100 | Hopper (2022) | HBM3 約 3.35TB/s | あり | 取り合いの主戦場 |
| H200 | Hopper改 (2024) | HBM3e 約 4.8TB/s | あり | 取り合い・大容量 |
| B200 | Blackwell (2024〜) | HBM3e 約 8TB/s | あり(FP4も) | 最前線・最も逼迫 |
2-bit 240GB の推論に H100 の FP8 や H200/B200 の大容量・広帯域は必須ではありません。みんなが最新世代を取り合う横で、確実に取れて安い A100 を使う、という割り切りです。
Azure Spot の制約（注意点）
ここからが本題です。Spot は「いつでも 30秒で叩き落とされる」前提のハードです。GPU Spot 特有の効いてくる点を挙げます。
30秒前通知・SLA なし
Azure が容量を取り戻したいとき、Spot VM は 30秒前通知で退去（eviction）させられ、SLA はありません。作成直後・ワークロード起動前ですら落とされることがあります。これは仕様なので、設計で吸収するしかありません。
GPU Spot は容量が薄い
GPU Spot は CPU より在庫が不安定で、リージョン・ゾーン・時間帯で容量がばらつきます。Japan East で NC A100 v4 Spot が時間帯によって「そもそも取れない」ことがあります。VM 作成画面の「View pricing history and compare prices in nearby regions」で、サイズ別・リージョン別の Spot 価格と eviction 率が見られるので、発注前に必ず確認します。
Spot は別クォータ枠
Spot VM は通常とは別のクォータ枠を持ちます。Japan East の Standard NCADSA100v4 Family vCPUs（NC96ads=96 vCPU）の Spot クォータを事前申請しておかないと、起動すらできません。盲点になりがちなので最初にやります。
単一 Spot VM は自動復旧しない
落ちても自動では戻りません。Deallocate でも自動起動はせず、自前で再起動が必要です。自動復旧が欲しいなら VMSS（後述）を使います。
Deallocate と Delete の性格差
| 項目 | Deallocate（既定） | Delete |
|---|---|---|
| 退去後の状態 | 停止状態で保持、再展開可 | VM・付随ディスクごと削除 |
| ディスク課金 | 継続（クォータも消費） | なし |
| 逃がし先 | 同一リージョン/ゾーンに固定 | 別ゾーン/リージョンへ逃がせる |
| 向き | 同じ環境を温存したい | 容量を素早く見つけたい・stateless |
GPU のように容量が薄いものは、Delete ＋ イメージから再作成のほうが結局つかまえやすい、というのが実感です。
うまい使い方
落とされる前提で、痛くない組み方を順に。
① eviction type は「Capacity only」/ max price は -1
中途半端な価格上限を付けると、容量 eviction に加えて価格 eviction まで増えて損です。「Capacity only」なら max price 不要で自動的に PAYG 価格まで払い、価格起因の退去を排除できます。
az vm create -g rg-glm -n glm-spot --location japaneast \
--size Standard_NC96ads_A100_v4 \
--image <自作CUDA+llamacppイメージ> \
--priority Spot --eviction-policy Delete --max-price -1 \
--zone 1 --admin-username azureuser --generate-ssh-keys
② 30秒通知を必ず拾う（Scheduled Events）
VM 内から IMDS の http://169.254.169.254/metadata/scheduledevents を 1〜5秒間隔でポーリングし、Preempt イベントを検知したら graceful 停止します。30秒では「保存」する時間はないので、常に保存済みにしておき、検知時は llama-server を drain して終了マークを打つだけにする設計が肝です。
#!/usr/bin/env bash
# preempt-watch.sh : Scheduled Events を監視し、Preempt 検知で graceful 停止
ENDPOINT="http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"
while true; do
EV=$(curl -s -H "Metadata:true" "$ENDPOINT")
if echo "$EV" | grep -q '"EventType":"Preempt"'; then
echo "$(date -Is) Preempt detected -> draining llama-server"
systemctl stop llama-server # 進捗は逐次 Blob 保存済みなので drain だけ
# 任意: orchestrator に通知 / 進捗フラグを Blob にフラッシュ
break
fi
sleep 2
done
この30秒窓のやり取りを時系列にすると、こうなります（マクロな再デプロイのループは後述の全体像を参照）。
③ 評価ループを resumable に
推論サーバ自体は stateless なので再起動で OK。問題は評価バッチです。「どのテストケースまで完了したか」を Blob/Azure Files に逐次記録し、再起動時に続きから再開する idempotent 設計にしておけば、途中で落ちても痛くありません。
長い1本の agentic run（plan-then-execute を延々）を回す最中に落ちると、その run は丸ごとやり直しになります。長い run はチェックポイントを挟むか短く区切るのがコツです。
④ 240GB モデルを毎回 DL しない
同一リージョン（Japan East）の Blob Storage（LRS, Cool/Cold）に GGUF を置き、起動時にローカル NVMe 一時ディスクへコピーします。リージョン内転送は egress 無料で、NCads は大きめのローカル NVMe を持つので数分でステージングできます。Delete ポリシーでも Blob 側は残るので相性が良い。Premium SSD データディスク常設だと Deallocate 中もディスク代（256GB で月35ドル前後）がかかるので、断続運用なら Blob 案が安く済みます。
⑤ カスタムイメージで cold start を短縮
CUDA ＋ llama.cpp（-DGGML_CUDA=ON ビルド済み）＋起動スクリプトを Shared Image Gallery に入れて Japan East へ複製。毎回ビルドしないぶん起動が速く、Delete 再作成戦略とも噛み合います。
⑥ 自動復旧は VMSS（1インスタンスでも可）
手運用が面倒なら、VMSS の Try-Restore を使うと容量が戻ったとき自動で復元してくれます。Spot Priority Mix で「1台 Standard ＋残り Spot」のベースライン確保も可能ですが、A100×4 の Standard は高いので、ここは割り切ってフル Spot でも実用上問題ありません。
⑦ 時間帯とゾーンを選ぶ
GPU 需要は JST 日中が高いので、8h の窓を夜間〜早朝に寄せると容量・価格・eviction 率がたいてい有利です。Japan East は zone 1/2/3 があるので、1つで容量が出なければ別ゾーンを試します（Delete ＋自動化なら別ゾーン再試行が容易）。
⑧ start/stop 自動化でアイドル課金ゼロ
Azure Automation runbook で「窓の開始に起動 → 終了時に deallocate/delete」をスケジュール。使わない時間は 1円も払いません。
⑨ on-demand フォールバックを1段持つ
どうしても容量が出ない／落ち続ける日用に、同じ Standard_NC96ads_A100_v4 を Standard（オンデマンド）で起動する分岐を用意し、「Spot で N 回失敗したら on-demand」というリトライにしておくと評価が止まりません。
全体像
構成例（検討してみた案）
今回検討してみた構成案は次の通りです。
- 作り方:
Delete＋Capacity only＋max price -1、ゾーン総当たり。 - モデル: 同一リージョン Blob（CMK 暗号化 + Private Endpoint）→ 起動時にローカル NVMe へステージング。
- 起動: CUDA+llama.cpp を焼いた Shared Image Gallery イメージから。cloud-init で Blob ステージング → systemd で llama-server 常駐 →
preempt-watch.shを併走。 - 復旧: VMSS Try-Restore か Automation 自動再作成。on-demand フォールバックを 1段。
- 評価: resumable（テストケース完了フラグを Blob へ）。長い run だけ短く区切る or その回だけ on-demand。
これで前述の Spot 月8.5万円前後（160h）を、評価の信頼性を大きく落とさずに取りにいけそうです。センシティブな SV/UVM コードも自分のサブスク内・Japan East に閉じるので、主権面も担保できます。
まとめ
- GLM-5.2 2-bit は約 240GB。1日8h の評価用途なら、フル 8GPU ノードは要らず A100 80GB×4 クラスで十分。
- Cloudflare はサーバーレス推論で自前 240GB モデルを持ち込めず、今回の用途とは別カテゴリ。
- ネオクラウドは月7〜14万円と激安だが、日本拠点の弱さと主権リスクで、センシティブコードには向かない。
- 主権を最優先するなら東京ハイパースケーラ。その中で Azure Japan East の A100 v4 Spot が在庫・コスト・主権のバランスで一番良さそうに見えた。
- Spot は「30秒で落とされる」前提。stateless 推論 ＋ resumable な評価ループ ＋ 自動再デプロイで組めば、推論用途とは相性が良い。長い1本の run だけ別扱いにする。
結局のところ「常時稼働で月数百万円」だった話が、精度を割り切って 2-bit にし、使うときだけ Spot で回すだけで月10万円を切るところまで落ちました。ローカルに 240GB を載せる機材を買う前の「クラウドで当たりを付ける」フェーズとしては、十分に現実的そうだと思います。
これはあくまで机上で検討してみた段階なので、次は実際にこの構成で GLM-5.2 2-bit を回し、いつもの AXI4-Lite UVM ドライバ生成プロンプトなどで採点して、Dense 系・他 MoE との比較に並べてみる予定です。
参考
- Z.ai GLM-5.2 / Unsloth GLM-5.2-GGUF（Dynamic 2-bit のサイズ・量子化ベンチ）
- Google Cloud / AWS / Azure 各社のアクセラレータ最適化 VM 料金ページ（2026年6月時点で要再確認）
- Microsoft Learn「About Azure Spot Virtual Machines」「Build Workloads with Azure Spot Virtual Machines」（eviction / Scheduled Events / max price の仕様）
- Cloudflare Workers AI Pricing（Neuron 課金・無料枠 1日 10,000 Neurons・カスタムモデルの扱い）/ Workers AI Changelog「GLM-5.2 on Workers AI」（2026-06-16 追加,
@cf/zai-org/glm-5.2, 262k コンテキスト） - ネオクラウド各社（RunPod / Spheron / Vast.ai）の GPU 料金ページ
- Claude Code: support.claude.com「How do usage and length limits work」「Usage limit best practices」、Anthropic Pro/Max プラン（5時間枠＋週次キャップ、2026年5月の上限改定、6/15 のプログラム実行クレジット分離）/ Codex: OpenAI Help「Codex rate card」「Using Codex with your ChatGPT plan」、developers.openai.com/codex/pricing（トークン従量・週次キャップ、2026年6月時点）
本記事は概算と一般的な仕様に基づく検討メモです。価格・在庫・仕様は変動するため、発注前に一次情報での確認をおすすめします。