GLM-5.3-Flash導入ガイド：Ox Alphaの正体、API料金、ローカル実行

Ox Alphaは独立した正式modelではありません。Z.aiは、OpenCodeとOpenRouterでこの名前を使って匿名テストしていたmodelがGLM-5.3-Flashだったと説明しています。正式公開後のZ.ai APIではglm-5.3-flash、公式weightsではzai-org/GLM-5.3-Flashを使います。

個人や小規模teamなら、最初にhosted APIで実際のtaskを試す方が合理的です。公式FP8 checkpointのweight filesだけで約305.8 GiBあります。「18B active parameters」は1 tokenで使うexpertの規模を表す数字で、18B modelと同じmemoryに収まるという意味ではありません。

Ox Alphaから引き継ぐのは実績ではなく同一性

GLM-5.3-Flash公式ガイドによると、GLM-5.3-Flashは320B total、18B activeのMoEで、GLM-5 family初のnative multimodal modelです。text、image、video、fileを入力でき、出力はtextです。contextは1M tokens、最大outputは128K tokensと記載されています。

Z.aiはsparse attentionとlinear attentionを組み合わせ、GLM-5.3よりattention computeとKV cacheを削減したと報告しています。この説明は安いserving costの背景になりますが、自社repositoryでの正解率やlatencyを保証しません。

識別子は利用先ごとに分けます。

同じ基盤modelでも、providerが変わればendpoint、parameter、context、billing ruleが変わる可能性があります。

長期budgetでは通常料金を使う

2026年9月3日に確認したZ.ai公式pricingは、1M tokensあたり次の金額です。

割引は2026年9月9日24:00 UTC+8で終了します。長期間のmodel選定には通常料金を使い、割引は期間中のbillだけに反映させます。

1M uncached inputと200K outputを使うtaskは、retryやtool feeの前で通常$0.25です。

$0.15 + 0.2 × $0.50 = $0.25

割引中は$0.125です。ただしproductionで比較するなら、全call、retry、reviewerの時間、failure recoveryを合計した「合格taskあたりの費用」を見ます。安いcallでも3回やり直せば差は縮まります。

公式APIで最初のresponseを確認する

通常のapplicationはAPI introductionにあるhttps://api.z.ai/api/paas/v4を 使います。Coding Planのhttps://api.z.ai/api/coding/paas/v4は対 応coding tool向けで、一般的なwebsite、bot、SaaS用のquotaではありません。

key、endpoint、model IDをまとめて確認する最小requestです。

bash
curl -sS https://api.z.ai/api/paas/v4/chat/completions \
  -H "Authorization: Bearer $ZAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3-flash",
    "messages": [
      {"role": "user", "content": "Return exactly: GLM53_FLASH_OK"}
    ],
    "temperature": 1,
    "top_p": 0.95,
    "reasoning_effort": "low",
    "stream": false
  }'

HTTP 200だけで終わらせず、choices[0].message.contentに指定文字列があることを確認します。401ならAuthorization headerとkeyの発行元、model not foundならox-alpha、Hugging Face repo名、別providerのaliasが入っていないかを見ます。

reasoning_effortはlow、high、maxを受け付けます。公式docsでは省略または未知の値はmaxになります。費用とlatencyを比較する時は同じlevelに固定します。

imageはmessages[].content[]へtype: image_urlを追加し、image_url.urlにURLまたはBase64 Data URLを入れます。multimodal inputに対応していても、image/videoを生成するmodelではありません。

ローカル実行はweight容量を出発点にする

公式Hugging Face model cardはMIT licenseを示し、SGLang、vLLM、Transformers、KTransformers、Unslothを案内しています。2026年9月3日の公式repo APIでは、FP8の.safetensorsが62 file、合計328,337,455,672 bytes、約305.8 GiBでした。

これはweight filesの容量だけです。実行時にはmodel metadata、vision encoder workspace、一時buffer、KDA state、KV cache、CUDA graph、concurrency分の余裕も必要です。1M contextは短いtestよりはるかに多くのcacheを使います。CPU/RAMやdiskへoffloadしてprocessが起動しても、first-token latencyやthroughputが用途に合うとは限りません。

現在のvLLM recipeも、runtimeとKV cacheの前に約306 GiBのnative FP8 weightsが必要と説明し、最初の例は4 GPUのtensor parallelです。SGLang recipeはH100、H200、B200、B300、GB200、GB300別の設定とvalidation状態を示します。

download前に次を決めます。

• GPU全体でweightsと実行余裕を保持できるか
• 実際に必要なcontextと同時request数はいくつか
• image/videoを扱うためのworkspaceが必要か
• 起動確認だけか、throughput、monitoring、update、failoverまで必要か

weightsだけでcapacityを超えるならAPIを使います。収まるなら、自分のGPUに対応する公式recipeを選び、短いcontextと1 requestから始めます。別世代GPU向けのFP8 KV cacheやspeculative decoding設定をそのまま移植しないでください。

6〜10件の実taskで継続を決める

長いdocument、tool call、image理解、自動testのあるcode changeを含む小さなtask setを用意します。repository state、prompt、reasoning_effort、timeout、最大retry、acceptance commandを固定し、first-pass合格、総時間、token、review時間、failure typeを記録します。

hosted APIは需要と品質を早く確かめる方法です。self-hostingはdata control、高い継続利用率、予測可能なcapacityの価値がhardwareと運用費を上回る時に検討します。idle GPUの費用も無視できません。

高リスクなtext-only engineeringでGLM-5.3も比較したい場合は、別のGLM-5.3とGLM-5.3-Flashの検証ガイドを使えます。Flashだけを導入するなら、API responseの中身を確認し、local memory planにweights以外の余裕を含める。この2点が最初のgo/no-goになります。