2026年7月5日 追記・修正
初版（2026-06-28）公開後、価格・可用性を一次情報で再確認したところ、結論の根拠に3点の事実誤認・言葉足らずがあったので修正しました。要点だけ先に:
- 「A100 v4 は在庫が厚い」は言い過ぎでした。 実態は Microsoft が A100 世代の新規増設を止めた「凍結プール」です。Microsoft Learn の NC A100 v4 ページに「We are currently only deploying net new capacity for the latest generation of the NC product line, the NCads_H100_v5-series.」と明記されています。今は取れますが将来の保証はなく、豪州 East ではクォータ拒否の事例も出ています。「今は取れるが早めに確保し、撤退条件を持て」というトーンに直しました。
- GCP の対抗馬を取り違えていました。 初版で本命の次点にした GCP RTX PRO 6000×4（g4）と、A100 80GB×4 の A2 Ultra（a2-ultragpu-4g）は、どちらも東京リージョン（asia-northeast1）では提供されていません（gcloud-compute.com で確認、A2 Ultra は us-central1 / us-east5 / us-east4 / europe-west4 / asia-southeast1 の5リージョンのみ）。東京・データ主権前提の比較では土俵に上がれないので、比較表から降格しました。
- 東京で実在する GCP の直接対抗馬は A2 Standard（A100 40GB×8＝320GB）でした。これを比較に追加。ただし Spot でも Azure の約5倍で、結果的に Azure 有利は揺らぎませんでした。
- 結論を「条件付きの最適解」に書き換え、末尾に発注前チェックリストと判断変更の閾値を追加しました。
数値はすべて 2026年7月3〜4日に再確認。為替は 1USD≈¥161（2026-07-03 実勢）で再換算しています。- 参考情報として、DGX Spark (GB10) クラスタでの GLM-5.2 実測報告、を最後に追加しました。
はじめに
ローカル 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 といったネオクラウドまで横並びで比較してみました。比較した結果、東京リージョン・データ主権維持・GPUメモリ 240GB クラス・Spot 利用という条件下では、現時点で一番マシに見えたのは次の構成です。
Azure の Japan East、NC96ads A100 v4（A100 80GB × 4）を Spot で使う
Spot なら 8h×20日でおおよそ月8.5万円前後。この記事はその比較プロセスと、有力候補として検討してみた Azure Spot の使い方・ハマりどころを、自分の備忘録も兼ねてまとめたものです。まだ運用を始めたわけではなく、「机上で検討してみた」段階のメモです。
本記事の価格はすべて 2026年7月3〜4日時点で再確認した概算です。クラウド GPU の単価・在庫・Spot 価格は頻繁に動きます。実際に発注する前に、各社の料金ページと Azure ポータルの料金履歴で必ず最新値を確認してください。為替は 1USD≈¥161 で換算しています。
要点（先にまとめ）
- まず大前提。主権を気にせず「ただ GLM-5.2 を試したい・使いたい」だけなら、自前ホストは要りません。最安の Western API（GMI、FP8・ブレンド $0.72/1M・後述の 8h×20日想定で月 ¥2.3万前後）を直叩きするか、いろいろ叩き比べたいなら OpenRouter 経由（プロバイダ価格＋5.5%手数料）が手軽です。以下は「コードを自分の管理下（東京・自サブスク）に閉じたい」という制約込みの検討です。
- GLM-5.2 2-bit は約 240GB。全 VRAM 載せなら「80〜96GB GPU ×4（320〜384GB）」または「L40S ×8（358GB）」「A100 40GB ×8（320GB）」が目安。
- Cloudflare は土俵が違う。Workers AI はサーバーレス推論（トークン従量）で、240GB の自前モデルを持ち込んで動かす用途には使えない。
- ネオクラウド（Vast.ai/RunPod/Spheron）は月7〜14万円とハイパースケーラの 1/3〜1/5。ただし日本拠点が弱く、市場型は実行ハードの所在を握れないので、センシティブなコードを通すなら主権面で不利。
- 東京ハイパースケーラ（GCP/Azure/AWS）は主権最強・最も高い。その中で、東京で A100 80GB×4（320GB）を Spot で素直に取れるのは実質 Azure だけだった。 GCP の A100 80GB（A2 Ultra）も RTX PRO 6000（G4）も東京には無く、東京で取れる GCP の A100 は 40GB 版（A2 Standard）で、320GB を作るには 8 枚必要になり Spot でも Azure の約5倍だった。
- A100 v4 は「在庫が厚い」のではなく「凍結プール」。 Microsoft は A100 世代の新規増設を止め、H100 v5 系にのみ新規容量を割いている（Microsoft Learn 明記）。今は取れるが将来の保証はなく、豪州 East ではクォータ拒否事例もある。確保は早めに、撤退条件を持って。
- 有力候補は Azure Spot。Spot で月8.5万円前後、主権はオンデマンドと同等（同じ Japan East の MS データセンター）。代わりに「30秒で落とされる」前提の設計が必須。
- 落とされても痛くないよう、stateless 推論＋resumable な評価ループ＋自動再デプロイで組むのがコツ。長い1本の run だけは別扱いにする。
- 中国系以外で GLM-5.2 を叩くなら Western API（Fireworks 最速 ~315 t/s、GMI 最安 ~$0.72/1M 等）が手軽で安く、当たり付けには十分。ただし主権の序列では「第三者ホスト型」で自前ホストには一段譲る。
- 別軸として Claude Code / Codex のサブスク（$200≈¥3.2万）はコストだけなら自前ホストより安いが、動かすのは Claude/GPT で GLM-5.2 ではなく、コードも US ホストに出る（主権は Western API 相当）。
前提: 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 or 8×A100 40GB |
| 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 でも問題なく動作します。後述する A100 の「FP8 テンソルコア非対応」は、FP8 で配布されたモデルをハード支援で速く回す機能の話で、2bit GGUF の可否とは別物です。ただし世代差は「動くか」ではなく「速度」に出ます。2-bit 推論はメモリ帯域律速になりやすく、A100 80GB SXM の HBM2e 約 2.04TB/s（NVIDIA A100 データシートで 2,039 GB/s、PCIe 版は 1,935 GB/s）は H100 SXM5 の HBM3 3.35TB/s より狭いぶん、トークン生成は遅くなります。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）で取り直す二段運用が無難です。
比較: 主要クラウド + ネオクラウド（2026年7月 更新）
評価条件は 2-bit（約 240GB）/ 1日8h × 20日 = 月160h / 1USD≈¥161 で揃えました。各社で「2-bit が載る最小構成」を選んでいます。この表は東京リージョン・データ主権前提です。
| プロバイダ | 構成 | VRAM | 時間単価(OD) | 月160h(OD) | Spot単価 | 月160h(Spot) | 主権 | 東京可否 |
|---|---|---|---|---|---|---|---|---|
| Azure(Japan East) | NC96ads A100 v4（A100 80GB ×4） | 320GB | ≈$14.69 | 約38万円 | ≈$3.29 | 約8.5万円 | ◎ | ○ |
| GCP(東京) | a2-highgpu-8g（A100 40GB ×8） | 320GB | ≈$32.40 | 約83万円 | ≈$17.82 | 約46万円 | ◎ | ○ |
| GCP(東京) | a2-ultragpu-4g（A100 80GB ×4） | 320GB | ─ | ─ | ─ | ─ | ◎ | ✕(東京未提供) |
| GCP(東京) | g4-standard-192（RTX PRO 6000 ×4） | 384GB | ─ | ─ | ─ | ─ | ◎ | ✕(東京未提供) |
| AWS(東京) | p4de.24xlarge（A100 80GB ×8 全載せ） | 640GB | ≈$27.45 | 約71万円 | ≈$13.4 | 約35万円 | ◎ | ○ |
| AWS(東京) | g6e.48xlarge（L40S ×8 全載せ） | 358GB | ≈$30.13 | 約78万円 | 変動 | ─ | ◎ | ○ |
| さくら高火力 VRT | H100 80GB ×1（VM型・1枚単位） | 80GB | 990円/h（税込） | 約16万円※単枚 | ─ | ─ | ◎(国内) | ○(石狩) |
| さくら高火力 PHY | H100 80GB ×8（ベアメタル専有） | 640GB | 月304.6万円（税込・最低2ヶ月） | ─ | ─ | ─ | ◎(国内) | ○(石狩) |
| GMO GPUクラウド | H100/H200（要問い合わせ） | 構成次第 | 要問い合わせ | ─ | ─ | ─ | ◎(国内) | ○(国内DC) |
| 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年7月3〜4日 再確認）:
- Azure NC96ads A100 v4: OD $14.692/h・Spot $3.285131/h（Vantage、A100×4）。Japan East 提供は Spare Cores の27リージョン一覧に Japan East (JP) が含まれることを確認済み。
- GCP a2-highgpu-8g（東京・A100 40GB×8＝320GB）: OD $32.3967/h・Spot $17.8213/h（gcloud-compute.com、asia-northeast1 行）。東京で 320GB を作れる GCP の最小構成はこれで、A100 80GB 版（A2 Ultra）は東京に無い。
- AWS p4de.24xlarge（A100 80GB×8＝640GB）: 東京 ap-northeast-1 提供あり（cloudprice.net の Asia Pacific (Tokyo) 記載）。OD $27.4471/h（us-east-1 基準）・Spot ≈$13.4/h。640GB は 240GB には過剰だが、AWS で A100 80GB を取ると 8 枚単位になる。
- AWS g6e.48xlarge（L40S×8＝358GB）: OD $30.13118/h（Vantage）、US 月約 $21,995。
- さくら/GMO は後述の「国内クラウド」節を参照。
- ネオクラウドは 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.29/h は Vantage 掲載の NC96ads A100 v4 直接値です。リージョン・時間帯により振れ、発注前に VM 作成画面の「View pricing history and compare prices in nearby regions」で実値を確認してください。
東京・主権前提だと、GCP の初版本命は土俵に上がれない。 初版では GCP の RTX PRO 6000×4（g4）を「僅差の次点」、A100 80GB×4 を候補に置いていましたが、再確認したところどちらも東京リージョン（asia-northeast1）では提供されていません。gcloud-compute.com によれば A2 Ultra（a2-ultragpu-4g, A100 80GB）は us-central1 / us-east5 / us-east4 / europe-west4 / asia-southeast1 の5リージョンのみで、東京は含まれていません。G4（RTX PRO 6000）は 2026年6月に GA したばかりで、東京の提供もまだです。GCP で東京・A100・320GB を作ろうとすると、A100 40GB の a2-highgpu-8g（8枚）になり、Spot でも約46万円/月と Azure の約5倍。つまり「東京・主権維持」を外さない限り、GCP は価格で Azure に並べません。
Cloudflare が表で空欄な理由
Cloudflare Workers AI は「GPU を借りる場所」ではなく、キュレーションされた公開モデル群をサーバーレスで叩く仕組みです。課金は「Neuron」で、Cloudflare 公式 docs の記述どおり「priced at $0.011 per 1,000 Neurons. Our free allocation allows anyone to use a total of 10,000 Neurons per day at no charge」＝実質トークン従量です。つまり GLM-5.2 の 240GB GGUF を自分で持ち込んで llama.cpp で動かす、という使い方ができません。実は GLM-5.2 については Cloudflare が 2026年6月16日にカタログへ追加していますが（モデル ID @cf/zai-org/glm-5.2、コンテキスト 262k）、これはあくまでホスト型 API を叩く話で、本記事の「自分のサブスク内・東京で動かす」自前ホストとは別カテゴリです。無料枠は1日 10,000 Neurons と小さく、超えれば普通の従量 API（入力 $1.4/M・出力 $4.4/M）で、しかもホスト型なので主権要件を満たしません。
ネオクラウドが安い理由と、それがそのままリスクになる話
ネオクラウドはハイパースケーラ比でオンデマンド 40〜85% 安く、月7〜14万円まで落ちます。とても魅力的ですが、私の用途では安さの源泉がそのままリスクになります。
- Vast.ai（最安）: 匿名の独立ホストから供給を集める市場型。稼働保証なし、日本拠点も引ける保証なし → センシティブコードは載せない。
- RunPod / Lambda / Spheron: Secure 系を選べば中間。ただし在庫は基本 US/EU 中心で日本リージョンは弱い。「データ所在を東京に固定したい」要件と噛み合いにくい。
- 東京ハイパースケーラ: 物理ロケーション・契約・コンプラを自分で握れる。主権は最強だが最も高い。
国内クラウド（さくら高火力 / GMO）はどうか
「主権を最優先」なら、そもそも国内事業者が最右翼のはずです。日本法・国内データセンターに閉じるので、Western ハイパースケーラの東京リージョンより主権は理論上さらに強い。ただし、今回の「240GB を1ノードに全載せして Spot で断続運用」という要件とは噛み合いが悪く、比較の本命には置けませんでした。整理します。
- さくら高火力 VRT（VM型）: NVIDIA H100 SXM 80GB×1 で、時間額990円・日額23,100円・月額385,000円（すべて税込、石狩第1ゾーン）。問題はGPU 1枚単位のVM型で、1VM=1GPUという点。240GB を全載せするには 4VM 必要ですが、VM を跨いだ NVLink プールはできないので、llama.cpp RPC でノード跨ぎになり、後述の「ノード跨ぎRPCは遅い」問題に直撃します。単一ノードで 320GB を素直に取る、という今回の設計には向きません。V100 プランは 2027年3月末で提供終了予定（新規作成は 2026年12月末で終了）。
- さくら高火力 PHY（ベアメタル）: H100 SXM 80GB×8＝640GB の専有で、月額3,046,120円（税込・最低2ヶ月、1年コミット月2,741,508円、3年コミット月2,436,896円）。H200 ベアメタルは月2,783,000円（税込）。これは「1ノードに 640GB」で要件は満たしますが、月300万円級・最低2ヶ月・専有で、「使うときだけ8h」の断続評価には過剰かつ割高です。B200 モデルも整備中で、H100/H200 のオンライン申し込みは再開済み。
- さくら高火力 DOK（コンテナ型）: 0.016円/秒（＝57.6円/時）〜の秒課金で H100 対応（2026年4月に H100 プラン正式提供）。単発タスクや Jupyter 実験向きで、240GB 常駐の推論サーバを長時間立てる用途とは設計が違います。
- GMO GPUクラウド: H100/H200 を国内自社DCで提供。世界200社超対象の「ClusterMAX 2.0」で国内GPUクラウド事業者初の評価を獲得（2025年11月）と、エンタープライズ品質は高い。ただし料金は基本「要問い合わせ」で、月単位・法人前提。個人の「8h×20日だけ」という断続利用にはフィットしにくい。なお同グループの ConoHa VPS 版 H100 は 1,398円/時・月額上限582,010円/枚で公開されています。
まとめると、国内クラウドは主権で最強だが、「240GB を1ノードに Spot で断続」という今回の形にハマる商品が今のところ無い（VRTは1枚単位、PHYは専有・月契約・高額）。主権の最後の砦として頭には置きつつ、当面の当たり付けフェーズでは Azure Spot が現実的、という位置づけです。
速度の目安: decode は何トークン/sec 出そうか
コストとは別軸で、実際の体感速度（生成 = decode のトークン/sec）も見ておきます。数字はすべて単一ユーザ・llama.cpp・2-bit 前提の粗い目安で、要ベンチです。
| 構成 | GPU / 帯域(枚あたり) | 全VRAM載せ | 推定 decode tok/s（目安・要ベンチ） | ひとこと |
|---|---|---|---|---|
| Azure A100 80GB×4（採用案） | A100 / HBM2e ~2.04TB/s, NVLink | 全載せ(320GB) | おおよそ 15〜40 | 計算性能が高く IQ2 を捌ける。単一ユーザのエージェント用途には十分 |
| GCP A100 40GB×8（東京の代替） | A100 / HBM2e ~2.04TB/s, NVLink | 全載せ(320GB) | おおよそ 15〜40 | 帯域は同等だが、40GB×8 なので枚数が倍で価格が跳ねる |
| AWS L40S×8（g6e.48xl） | L40S / GDDR6 ~0.86TB/s, NVLinkなし | 全載せ(358GB) | おおよそ 8〜20 | 枚数は多いが層分割の decode は単枚帯域律速。帯域が低いぶん遅め |
| AWS A100 80GB×8（p4de） | A100 / HBM2e ~2.04TB/s, NVSwitch | 全載せ(640GB・過剰) | おおよそ 15〜40 | 640GB は過剰だが速度は出る。8枚ぶんの金は払う |
| 参考: 1×H200 + オフロード（実測報告） | HBM3e + RAM | オフロード | 約 8.7 | 単枚では 239GB が入らずオフロード |
| 参考: 2×DGX Spark (GB10) RPC（実測報告） | GB10 / LPDDR5x ~0.27TB/s ×2, RPC接続 | 全載せ(計256GB・1-bit) | 約 8（1-bit, 256K ctx） | ノード跨ぎ RPC が重く「実用展開は無理なトイ実験」との報告 |
算出根拠と注意: decode 速度は「メモリ帯域 ÷ 1トークンあたりに読む重み」でほぼ決まります。GLM-5.2 は active 40B なので 2-bit では1トークンあたり概ね 12〜14GB を読む計算で、例えば 2.04TB/s ÷ 13GB ≈ 157 tok/s が理論上限です。実際は逆量子化負荷・KV増加・マルチGPU同期で下回るので、上表は経験的ヘアカット込みの粗い目安。重要な性質が2つ。ひとつは llama.cpp の層分割（
-sm layer）では単一ストリームの decode は単枚の帯域で頭打ちになること（多GPU は速度でなく容量を稼ぐ手段）。もうひとつは、VRAM に載りきらずシステムRAMへオフロードすると一気に一桁 tok/s に落ちること。
中国サーバー以外で GLM-5.2 を API 提供しているところ（価格・速度）
GLM-5.2 は MIT ライセンスなので、Z.ai（中国）以外にも多数の Western ホストが API 提供しています。主権の序列でいう「Western API（第三者のホスト型）」の段です。自前ホストよりは主権を譲りますが、中国法域は避けられ、no-train ポリシーのホストも選べます。
| プロバイダ（拠点・量子化） | 入力 $/1M | 出力 $/1M | ブレンド $/1M（7:2:1） | 8h×20日の概算/月※ |
|---|---|---|---|---|
| Fireworks（米・FP8） | $1.40 | $4.40 | $0.90 | 約 $180（¥2.9万） |
| GMI（米/台・FP8） | $1.12 | $3.52 | $0.72（最安） | 約 $144（¥2.3万） |
| Wafer（拠点要確認・FP4） | $1.20 | $4.10 | $0.79 | 約 $158（¥2.5万） |
| DeepInfra（米・FP4） | $1.20 | 〜$4.20 | $0.80 | 約 $160（¥2.6万） |
| 参考: Z.ai 直叩き（中国・FP8） | $1.40 | $4.40 | cached $0.26 | （対象外） |
※ 月概算の前提: 出力を月 2,000万トークン、キャッシュ込み 7:2:1 で総 2億トークンと置き、ブレンド単価 × 総トークンで計算（¥161換算）。あくまで一例で、並列エージェント・巨大コンテキスト・最大 thinking を多用すると数倍に増えます。
この想定なら月 ¥2〜3万で、自前ホスト（Azure Spot 月¥8.5万）より安く済みます。ただし API はトークン従量なので、出力が月 5,000万〜7,000万トークン（この想定の約3倍）を超えるあたりで Spot と逆転し、それ以上の高頻度・大量利用では自前ホストのほうが安くなります。速度は Artificial Analysis の直近72時間中央値で Fireworks 約 315 ＞ Baseten 約 278 ＞ Databricks 約 241 ＞ CoreWeave 約 166 ＞ Together AI 約 164 t/s、最遅は Novita 約 46 t/s。SiliconFlow（中国）は対象外、Novita（香港）も拠点を要確認です。当たりを付ける段階では OpenRouter（パススルー＋クレジット購入 5.5%手数料）で各社を横断比較し、本命を決めたら直叩きに寄せる、という使い分けが効率的です。
別軸の選択肢: Claude Code / Codex のサブスクと比べると
「そもそも強いコーディングエージェントが欲しいだけ」なら、Claude Code や Codex のサブスクのままでよいのでは？ という話もあります。コストだけ見ると、実はこちらのほうが安い。
| 選択肢 | 月額(目安) | 動かすモデル | リミット構造 | 主権 |
|---|---|---|---|---|
| Claude Code Max 20x | $200 ≈ ¥3.2万 | Claude (Opus/Sonnet) | 5時間枠 + 週次キャップ×2 | Western ホスト型 |
| Codex (ChatGPT Pro) | $200 ≈ ¥3.2万 | GPT-5 系 | 5時間枠 + 週次キャップ | Western ホスト型 |
| 参考: GLM-5.2 自前ホスト(Azure Spot) | ≈ ¥8.5万 | GLM-5.2（自分で） | リミットなし（VRAM 次第） | 自サブスク・東京 |
軸が3つズレています。(1) モデルが違う（Claude/GPT であって GLM-5.2 ではない）。今後継続的に米国政府からフロンティアモデルに規制が入りそうな今、オープンな LLM でどこまで出来るか、という点に興味があります。(2) 主権が違う（US ホストに出る）。(3) リミットの性質が違う（週次キャップ vs VRAM が許す限り）。「ただ強いエージェントが欲しい」ならサブスク、「GLM-5.2 を主権下で上限を気にせず評価したい」なら自前ホスト、と土俵が違います。
Azure (Japan East) の Spot が有力に見えた理由
主権を最優先にすると、選択肢は実質「東京ハイパースケーラ」に絞られます。その中で Azure が有力に見えた理由は次の通りです。
- 東京で A100 80GB×4（320GB）を Spot で素直に取れるのが実質 Azure だけだった。 これは「A100 が古い」ことと表裏です。A100 は Ampere 世代（2020年5月発表、TSMC 7nm・54.2B トランジスタ・6,912 CUDA コア）で、いまの最前線は H100（2022〜）→ H200（2024）→ B200（Blackwell）と 2〜3 世代後ろ。GPU の取り合いは最新チップ側で起きていて、A100 は相対的に需要が落ち着いています。前述のとおり、GCP の A100 80GB（A2 Ultra）も RTX PRO 6000（G4）も東京には無く、AWS の A100 80GB は 8枚単位（p4de、640GB・過剰）。「東京・A100・320GB・Spot」という4条件を全部満たすのは NC96ads A100 v4 だけ、というのが実態でした。
重要な訂正（初版からの修正点）: A100 v4 は「在庫が厚い」のではなく「凍結プール」です。 Microsoft Learn の NC A100 v4 ページ（NVIDIA A100 PCIe 80GB×4・AMD EPYC 7V13 Milan の SKU）には「We are currently only deploying net new capacity for the latest generation of the NC product line, the NCads_H100_v5-series.（新規容量は最新世代の NCads H100 v5 系にのみ配備している）」と明記されています。つまり A100 v4 の在庫はもう増えない固定プールで、今取れているのは「新規増設が止まって取り合いが落ち着いた既存容量」を使っているだけ。しかも豪州 East リージョンでは、2026年2月に「Standard_NC24ads_A100_v4 のクォータを（容量を理由に）拒否された」という報告が Microsoft Q&A に出ています。「今は取れるが、確保は早めに。取れなくなる／値上がりする閾値を決めて撤退条件を持つ」のが正しいスタンスです。なお A100 v4 シリーズ自体のリタイア（廃止）announcement は出ていません（廃止予定は V100 の NCv3 のみ、2025年9月末〜一部リージョン延長）。凍結≠即廃止ですが、凍結プールが徐々に痩せていくリスクは織り込むべきです。
-
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（P2P）接続なので、仮に東京にあってもテンソル並列では不利でした。
GPU 世代を一枚にすると、A100 が「枯れて凍結されたぶん今は取りやすいが、速度は譲る」位置づけなのがよく分かります（帯域・年次は概数）。
| GPU | 世代(登場年) | メモリ帯域(目安) | FP8 対応 | いまの立ち位置 |
|---|---|---|---|---|
| A100 80GB | Ampere (2020) | HBM2e 約 2.04TB/s | なし | 凍結プール・新規増設停止 ← 今回採用 |
| H100 | Hopper (2022) | HBM3 3.35TB/s | あり | 取り合いの主戦場・新規増設はこちら |
| H200 | Hopper改 (2024) | HBM3e 4.8TB/s（141GB） | あり | 取り合い・大容量 |
| B200 | Blackwell (2024〜) | HBM3e 約 8TB/s | あり(FP4も) | 最前線・最も逼迫 |
Azure Spot の制約（注意点）
Spot は「いつでも 30秒で叩き落とされる」前提のハードです。
- 30秒前通知・SLA なし。 Azure が容量を取り戻したいとき、Spot VM は 30秒前通知で退去（eviction）させられ、SLA はありません。作成直後ですら落とされることがあります。
- GPU Spot は容量が薄い。 リージョン・ゾーン・時間帯で容量がばらつき、Japan East で NC A100 v4 Spot が時間帯によって「そもそも取れない」ことがあります。VM 作成画面の「View pricing history and compare prices in nearby regions」で eviction 率を発注前に必ず確認。
- Spot は別クォータ枠。 Japan East の
Standard NCADSA100v4 Family vCPUs（NC96ads=96 vCPU）の Spot クォータを事前申請しておかないと起動すらできません。 - 単一 Spot VM は自動復旧しない。 落ちても自動では戻りません。自動復旧が欲しいなら VMSS を使います。
Deallocate と Delete の性格差
| 項目 | Deallocate（既定） | Delete |
|---|---|---|
| 退去後の状態 | 停止状態で保持、再展開可 | VM・付随ディスクごと削除 |
| ディスク課金 | 継続（クォータも消費） | なし |
| 逃がし先 | 同一リージョン/ゾーンに固定 | 別ゾーン/リージョンへ逃がせる |
| 向き | 同じ環境を温存したい | 容量を素早く見つけたい・stateless |
GPU のように容量が薄いものは、Delete ＋ イメージから再作成のほうが結局つかまえやすい、というのが実感です。
うまい使い方
落とされる前提で、痛くない組み方を順に。
① eviction type は「Capacity only」/ max price は -1
「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 の scheduledevents を 1〜5秒間隔でポーリングし、Preempt イベントを検知したら graceful 停止します。30秒では「保存」する時間はないので、常に保存済みにしておき、検知時は llama-server を drain して終了マークを打つだけにする設計が肝です。
#!/usr/bin/env bash
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
break
fi
sleep 2
done
③ 評価ループを resumable に
推論サーバ自体は stateless なので再起動で OK。問題は評価バッチです。「どのテストケースまで完了したか」を Blob/Azure Files に逐次記録し、再起動時に続きから再開する idempotent 設計にしておけば、途中で落ちても痛くありません。長い1本の agentic run はチェックポイントを挟むか短く区切る。
④ 240GB モデルを毎回 DL しない
同一リージョン（Japan East）の Blob Storage（LRS, Cool/Cold）に GGUF を置き、起動時にローカル NVMe 一時ディスクへコピーします。リージョン内転送は egress 無料で、NCads は大きめのローカル NVMe を持つので数分でステージングできます。
⑤ カスタムイメージで cold start を短縮
CUDA ＋ llama.cpp（-DGGML_CUDA=ON ビルド済み）＋起動スクリプトを Shared Image Gallery に入れて Japan East へ複製。毎回ビルドしないぶん起動が速く、Delete 再作成戦略とも噛み合います。
⑥ 自動復旧は VMSS（1インスタンスでも可）
VMSS の Try-Restore を使うと容量が戻ったとき自動で復元してくれます。
⑦ 時間帯とゾーンを選ぶ
GPU 需要は JST 日中が高いので、8h の窓を夜間〜早朝に寄せると容量・価格・eviction 率がたいてい有利です。Japan East は zone 1/2/3 があるので、1つで容量が出なければ別ゾーンを試します。
⑧ start/stop 自動化でアイドル課金ゼロ
Azure Automation runbook で「窓の開始に起動 → 終了時に deallocate/delete」をスケジュール。
⑨ on-demand フォールバックを1段持つ
「Spot で N 回失敗したら on-demand」というリトライにしておくと評価が止まりません。
発注前チェックリスト
実際に発注する前に、上から順に潰すと事故りにくいです。
- 為替と単価の再確認。 記事の数値は 2026年7月時点。VM 作成画面と料金ページで当日の Spot/OD 単価を再取得したか。1USD≈¥161 想定がまだ妥当か。
-
Spot クォータの事前申請。 Japan East の
Standard NCADSA100v4 Family vCPUsを Spot 枠で（通常枠とは別）96 vCPU 以上申請したか。0 のままだと起動不可。 - eviction 率の確認。 「View pricing history and compare prices in nearby regions」で Japan East 各ゾーンの Spot 価格と eviction 率を見たか。日中/夜間で差があるか。
- 凍結プールの残量リスクを織り込んだか。 A100 v4 は新規増設停止。今週取れても来月取れる保証はない。取れなかった日の on-demand フォールバック分岐を用意したか。
- Blob ステージングの準備。 GGUF を Japan East の Blob（CMK 暗号化 + Private Endpoint）に置き、リージョン内転送（egress 無料）でローカル NVMe へ落とす cloud-init を書いたか。
-
KV キャッシュ量子化の設定。 長コンテキストを流すなら
--cache-type-k/vを設定したか。320GB に 239GB 載せると余裕は約80GB しかない。 - resumable 評価ループ。 テストケース完了フラグを Blob に逐次書き、再起動で続きから走るか。長い run は短く区切ったか。
- preempt-watch の常駐。 Scheduled Events ポーリング → graceful drain が systemd で常駐しているか。
- start/stop 自動化。 窓外は deallocate/delete でアイドル課金ゼロになっているか。
- 主権の最終確認。 使うリソース（VM/Blob/イメージ）が全部 Japan East に閉じているか。ログ送信先や監視 SaaS が海外に出ていないか。
- 精度の二段運用。 当たり付け 2-bit、最終採点は 4-bit で取り直す運用を決めたか。
判断変更の閾値（この条件が崩れたら乗り換える）
今回の結論は「東京・主権維持・240GBクラス・Spot」という条件下でのもので、条件が変われば最適解も変わります。以下のいずれかに触れたら、机上検討をやり直します。
- Azure Spot の実効単価が OD の 5〜6割を超えて張り付いたら。 いまは OD $14.69 に対し Spot $3.29（約22%）。もし Spot が常時 $8〜9/h（月13〜14万円）まで上がるなら、Spot の旨味が薄れ、後述の乗り換え先を再評価する。
- Japan East の A100 v4 Spot クォータ拒否／容量枯渇が常態化したら。 豪州 East で既に起きている「容量を理由にクォータ拒否」が Japan East でも起きたら、凍結プールが痩せた合図。国内クラウド（さくら PHY / GMO）か、H100/H200 系への移行を前倒しする。
- H100/H200 系の Spot が A100 の 1.5倍以内に降りてきたら。 帯域が 1.6〜2.4倍あるので、価格差が縮めば速度で H100 に寄せる価値が出る。NCads H100 v5 の Japan East Spot 単価を定点観測。
- 国内クラウドが「1ノード 240〜320GB を時間課金 Spot 相当」で出したら。 さくら VRT がマルチGPU単一VM（例: H100×4）を時間課金で出す、あるいは GMO が個人向け従量で 4GPU ノードを出したら、主権が一段強い国内へ即移行を検討。
- GCP が東京に A2 Ultra（A100 80GB）または G4（RTX PRO 6000）を投入したら。 そのときは東京で GCP が価格競争に復帰するので、Azure と再比較する。
- 評価の月間出力が 5,000万〜7,000万トークンを超えたら（逆方向）。 ここを超えると Western API より自前ホストが安くなる分岐点。逆に下回るなら、そもそも自前ホストをやめて GMI/Fireworks 直叩きに戻す。
- GLM-5.2 の精度が 2-bit で評価要件を満たさないと分かったら。 4-bit（約376GB）が要るなら 320GB では足りず、H200/B200 の大容量か 8GPU ノードへ構成変更。コスト前提が丸ごと変わる。
まとめ
- GLM-5.2 2-bit は約 240GB。1日8h の評価用途なら、フル 8GPU ノードは要らず A100 80GB×4 クラスで十分。
- Cloudflare はサーバーレス推論で自前 240GB モデルを持ち込めず、今回の用途とは別カテゴリ。
- ネオクラウドは月7〜14万円と激安だが、日本拠点の弱さと主権リスクで、センシティブコードには向かない。
- 国内クラウド（さくら/GMO）は主権最強だが、「240GB を1ノードに Spot で断続」という今回の形にハマる商品が今のところ無い。
- 東京リージョン・データ主権維持・GPUメモリ 240GB クラス・Spot 利用という条件下では、2026年7月時点でも Azure Japan East の A100 v4（NC A100 v4 / ND A100 v4）Spot が妥当な最適解。 GCP の A100 80GB も RTX PRO 6000 も東京に無く、東京の GCP A100 は 40GB×8 で Spot でも Azure の約5倍。AWS は 8枚単位で過剰。
- ただし A100 v4 は凍結プール（新規増設停止）。 クォータ確保は早めに、判断変更の閾値を決めて撤退条件を持っておくこと。
- Spot は「30秒で落とされる」前提。stateless 推論 ＋ resumable な評価ループ ＋ 自動再デプロイで組めば、推論用途とは相性が良い。
結局のところ「常時稼働で月数百万円」だった話が、精度を割り切って 2-bit にし、使うときだけ Spot で回すだけで月10万円を切るところまで落ちました。次は実際にこの構成で GLM-5.2 2-bit を回し、いつもの AXI4-Lite UVM ドライバ生成プロンプトなどで採点して、Dense 系・他 MoE との比較に並べてみる予定です。
参考: DGX Spark (GB10) クラスタでの GLM-5.2 実測報告
クラウドに載せずに手元のハードウェアで GLM-5.2 を動かす選択肢として、DGX Spark (GB10) を複数台束ねる構成の実測報告が NVIDIA Developer Forums に複数上がっている。ここでは出典を明記した上で整理する (参照日: 2026年7月5日)。
注意点として、本記事の主題は 2-bit (UD-Q2_K_XL 級) 量子化だが、以下の 2 ノード実測は 1-bit (UD-IQ1_S) であり、量子化レベルが一段低い。2×GB10 (統合メモリ 128GB × 2) では 2-bit 級の GLM-5.2 はメモリに収まらないため、1-bit まで落とした「動くかどうかの確認」に近い実験である点に留意されたい。
実測報告一覧
| 構成 | モデル / 量子化 | 接続 | decode 速度 | 出典 |
|---|---|---|---|---|
| 2× DGX Spark | GLM-5.2 UD-IQ1_S (1-bit) | ConnectX-7 直結 + llama.cpp RPC | 約 8 tok/s (256K ctx) | [1] |
| 4× GB10 | GLM-5.2 IQ4_XS (4-bit) | クラスタ + llama.cpp | 6.28 tok/s (DSA 有効) | [2] |
| 4× GB10 | GLM-5.2 AWQ-INT4 + 枝刈り | 100GbE (MikroTik CRS504) | 約 22 tok/s (256K ctx) | [3] |
| 4× DGX Spark | GLM-5.2 NVFP4 (枝刈りなし) | クラスタ | 約 24 tok/s (128K ctx) | [4] |
[1] NVIDIA Developer Forums「(Academic) GLM-5.2 on 2x DGX-Spark/GB10 nodes: Crazy 1-bit UD-IQ1_S + RPC llama.cpp + 256K context + 8 tok/s」(2026年6月)
https://forums.developer.nvidia.com/t/academic-glm-5-2-on-2x-dgx-spark-gb10-nodes-crazy-1-bit-ud-iq1-s-rpc-llama-cpp-256k-context-8-tok-s/374523
[2] NVIDIA Developer Forums「GLM-5.2 IQ4_XS on 4× GB10 — 6.28 tok/s, DSA active, full recipe」(2026年6月)
https://forums.developer.nvidia.com/t/glm-5-2-iq4-xs-on-4x-gb10-6-28-tok-s-dsa-active-full-recipe/373933
[3] NVIDIA Developer Forums「GLM-5.2 on a 4× GB10 cluster: ~22 tok/s decode, 256K ctx, Recipe」(2026年6月)
https://forums.developer.nvidia.com/t/glm-5-2-on-a-4x-gb10-cluster-22-tok-s-decode-256k-ctx-recipe/374125
[4] NVIDIA Developer Forums「Followup: Mystery Solved: 4x Spark, GLM-5.2-nfp4, 24tp/s, 128k ctx, no REAP」(2026年7月)
https://forums.developer.nvidia.com/t/followup-mystery-solved-4x-spark-glm-5-2-nfp4-24tp-s-128k-ctx-no-reap/375416
各報告の読み方
2 ノード RPC (8 tok/s) [1] は、投稿者自身が「toy experiment であり実運用には向かない」と明言している学術的興味の実験である。token generation は許容範囲だが、llama.cpp の RPC 越し tensor split はノード間分割が不均一になりやすく、prompt processing が実用に耐えないと報告されている。2×GB10 で GLM-5.2 を RPC 分散すること自体は可能、というのがこの報告の意味であり、快適に使えるという意味ではない。
4 ノード IQ4_XS (6.28 tok/s) [2] は、DSA (DeepSeek Sparse Attention) を有効にした素直な llama.cpp 構成での数値。4-bit 品質を維持した場合の現実的なベースラインとして参考になる。
22 tok/s [3] は見出しだけ見ると魅力的だが、素の RPC 構成ではない点に注意が必要。AWQ-INT4 に加えて expert の枝刈り (約 636B total / 約 40B active、safetensors を直接加工してノードあたり約 12GiB を解放) を施し、cudagraph 等の最適化を効かせた特殊構成であり、モデル品質は無加工の GLM-5.2 とは別物と考えるべき。再現には相応の手間がかかる。
24 tok/s [4] は [3] の系譜の追試で、枝刈りなし (no REAP) の NVFP4 で MTP 周りの問題を解決した結果。品質を落とさず 4 ノードで 20 tok/s 台に到達した報告として、現時点で最も実用に近い。ただしコンテキストは 128K。
本記事の結論との関係
GB10 4 台 (実売で約 250〜260 万円) を揃えれば GLM-5.2 を 4-bit 品質・20 tok/s 台で常時手元に置けるが、初期投資と運用の手間 (クラスタ構築、llama.cpp/vLLM のノード間問題への追従) を考えると、月 10 万円弱のクラウド Spot 運用とはユースケースが分かれる。断続的な利用でデータ主権を守りたいだけなら本文の Azure NC A100 v4 Spot 案が依然として有利であり、24 時間常時稼働・長期利用が前提なら GB10 クラスタの償却が効いてくる、という整理になる。
その他の参考情報
- Microsoft Learn「NC_A100_v4 size series」（凍結プール＝「We are currently only deploying net new capacity for the latest generation of the NC product line, the NCads_H100_v5-series.」の記述）/「NCv3-series Retirement」（A100 v4 はリタイア対象外）/「About Azure Spot Virtual Machines」
- Microsoft Q&A（豪州 East での NC24ads_A100_v4 クォータ拒否事例, 2026年2月）
- Vantage / Spare Cores（Azure NC96ads A100 v4 の OD $14.692・Spot $3.285131・Japan East 提供）
- gcloud-compute.com（GCP a2-ultragpu-4g は5リージョンのみ・東京なし / a2-highgpu-8g 東京 OD $32.3967・Spot $17.8213）
- NVIDIA A100 データシート（HBM2e 2,039 GB/s）/ NVIDIA H200 公式ページ（141GB HBM3e・4.8TB/s）
- NVIDIA/Google Cloud Blog（G4＝RTX PRO 6000 の GA, 2026年6月）
- AWS（p4de/g6e/G7e の東京提供状況）
- さくらインターネット公式（高火力 PHY 月304.6万円/VRT 990円h/DOK 秒課金の料金）/ GMO GPUクラウド公式
- Cloudflare Workers AI Pricing（$0.011/1,000 Neurons・無料枠 1日 10,000 Neurons）/ Changelog（GLM-5.2, 2026-06-16）
- Artificial Analysis「GLM-5.2 providers」/ OpenRouter「z-ai/glm-5.2」
- Unsloth GLM-5.2-GGUF（Dynamic 2-bit のサイズ・量子化ベンチ）
本記事は概算と一般的な仕様に基づく検討メモです。価格・仕様は変動するため、本格導入時は一次情報での確認をお願い致します。