はじめに

ローカル 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ノードに素直に載せる構成のほうが、速度でも運用でも有利、というのが今回の判断材料です。

中国サーバー以外で GLM-5.2 を API 提供しているところ（価格・速度）

GLM-5.2 は MIT ライセンスなので、Z.ai（中国）以外にも多数の Western ホストが API 提供しています。主権の序列でいう「Western API（第三者のホスト型）」の段です。自前ホストよりは主権を譲りますが、中国法域は避けられ、no-train（入力を学習に使わない）ポリシーのホストも選べます。Artificial Analysis が GLM-5.2 を 14 プロバイダで継続ベンチしているので、その値（2026年6月時点・変動あり）を基に、主な非中国系を並べます。

プロバイダ（拠点）	量子化	入力/出力 $/1M	ブレンド $/1M	出力速度 t/s（ベンチ）	ひとこと
Fireworks（米）	FP8	—	中位	約 315（最速）	速度最優先・FP8 で品質寄り
Together AI（米）	FP8	—	中位	約 298	高速
Baseten（米）	FP8	—	—	約 287	高速
GMI（米/台）	FP8	$1.12 / $3.52	約 $0.72（最安）	—	最安ブレンド・FP8
Wafer（拠点要確認）	FP4	$1.20 / $4.10	約 $0.79	200+	安くて速いが拠点要確認
DeepInfra（米）	FP4	$1.20 / ~$4.2	約 $0.80	約 49（最遅）	最安級だが FP4・速度は低め
Nebius（EU/蘭）	FP8	—	約 $1.70（最高）	—	EU 拠点・価格は高め
参考: Z.ai 直叩き（中国）	FP8	一次提供で最安級	—	—	中国法域 → 今回は対象外

ほかに FriendliAI・Parasail・CoreWeave・Databricks・Makora なども非中国系で提供しています。価格・速度のレンジは、最速 Fireworks 約 315 t/s に対し最遅 DeepInfra(FP4) 約 49 t/s と 6.4 倍、ブレンド価格も GMI $0.72 〜 Nebius $1.70 と 2.4 倍の開きがあります。

注意: 上の価格・速度は Artificial Analysis のベンチ値（2026年6月時点、ブレンドは入出力混在の目安）で、時間帯・負荷で変動します。出力速度はベンチの単発生成値で、GLM-5.2 は「考える」モデルなので、実運用の reasoning 込みスループットはこれより落ちます（OpenRouter の実測加重平均で入力 $0.447 / 出力 $3.31 per 1M、スループットも数十 t/s 台との報告）。量子化に注意で、最安系（DeepInfra・Wafer 等）は FP4、Fireworks・Novita などは FP8。コーディング用途では FP8 のほうが無難です。

主権の観点も外せません。SiliconFlow（中国）は今回の趣旨では対象外、Novita（香港）も拠点を要確認です。Western ホストでも実体は「第三者に出す」ことに変わりはなく、エアギャップも自サブスク隔離もありません。OpenRouter はプロバイダの拠点国とデータポリシーを開示・フィルタできるので、no-train かつ拠点が許容できるホストか、必ず確認してください。

位置づけとしては、コスト・速度だけ見れば Fireworks（最速 ~315 t/s）や GMI（最安ブレンド ~$0.72/1M）のような Western API は、自前ホスト（Spot 月¥8.5万）より圧倒的に手軽で、評価の当たり付けには十分実用的です。ただし本記事の主眼である「センシティブなコードを自分の管理下に閉じる」要件では一段譲るので、当たり付けは Western API、センシティブ評価は自前ホスト、という使い分けが現実的だと思います。

別軸の選択肢: 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月時点）

本記事は概算と一般的な仕様に基づく検討メモです。価格・仕様は変動するため、もし本格的に導入を検討する場合は、一次情報での確認をお願い致します。