GLM-OCRとは？0.9Bの実体と日本語精度・vLLM/Ollama導入手順とAPI料金

GLM-OCRは、Z.ai（智譜AI）が2026年1月30日にHugging Faceへ公開した文書解析特化のマルチモーダルOCRモデルです。公称0.9BとOmniDocBench V1.5の94.62点が注目を集めましたが、実際に業務へ入れるときに効くのは別の3点です。公称値と実際にロードする重みの容量差、日本語の実測スコア、そしてプロンプトが2系統に限定されているという設計上の制約。技術報告（arXiv:2603.10910）・公式モデルカード・config.json・同梱の評価結果ファイル・SDKリポジトリ・API仕様から取れる数値だけで、この3点を含めた導入判断の材料を整理します。

まとめ

GLM-OCRの要点は次のとおりです。モデル重みはMITライセンスでHugging Faceに公開され、直近1か月のダウンロードは1,677,350件、累計は31,422,868件です。

• 公称0.9Bは、0.4BのCogViT視覚エンコーダと0.5BのGLM言語デコーダを合わせた値。ただし配布されるチェックポイントの集計は1,325,258,240パラメータ、重みファイルは2.65GBある。
• OmniDocBench V1.5は発表時点で94.62点の首位。ただしMDPBenchの日本語は65.5点で、英語84.5点より19.0ポイント低い。
• クラウドAPIは https://api.z.ai/api/paas/v4/layout_parsing、モデルIDは glm-ocr、入出力とも100万トークンあたり0.03ドル。PDFは50MB・100ページまで。
• セルフホストはvLLM 0.19.0以降かSGLang 0.5.10以降。Ollamaは glm-ocr:latest が2.2GB、glm-ocr:q8_0 が1.6GB。
• 受け付けるプロンプトは文書パースの3種と情報抽出のJSONスキーマだけ。自由記述の指示は設計外。

以降で、各数値の出どころと、どの用途なら採用して良いかを順に見ていきます。

公称0.9Bの内訳と配布される重みの容量

技術報告の要旨は、GLM-OCRを0.9Bパラメータのコンパクトなマルチモーダルモデルと述べたうえで、0.4BのCogViT視覚エンコーダと0.5BのGLM言語デコーダを組み合わせた構成だと明記しています。0.9Bは視覚側を除いた数字ではなく、主要2ブロックを足した規模です。

公称値と配布容量のずれ

一方、Hugging Faceがsafetensorsから集計する総パラメータ数は1,325,258,240（BF16）で、単一ファイル model.safetensors は2,650,579,464バイト、同ページの表示で2.65GB（2.47GiB）あります。公称0.9Bは主要2ブロックを丸めた規模であって、実際にロードする重みの量ではありません。config.jsonを見ると、チェックポイントにはこの2ブロックのほかに独立した入出力埋め込み（tie_word_embeddings が false）とMTPの先読み層（num_nextn_predict_layers が1）が含まれています。VRAMやディスクを見積もるときは、0.9Bという表記ではなく配布容量2.65GBを起点にしてください。

アーキテクチャと構成値

モデルカードの説明は、CogViT視覚エンコーダ、トークンダウンサンプリングを行う軽量なクロスモーダルコネクタ、GLM-0.5B言語デコーダの3層構成で、これにPP-DocLayout-V3によるレイアウト解析と並列認識の2段パイプラインを組み合わせる、というものです。学習側ではMulti-Token Prediction（MTP）損失と全タスク強化学習を導入しています。config.jsonで確認できる値は次のとおりです。

入力画像は縦横の寸法ではなく面積で正規化されます。A4を300dpiでスキャンした2,480×3,508の画像は約870万ピクセルで上限9,633,792の内側に収まりますが、600dpiの4,961×7,016は約3,481万ピクセルで上限の3.6倍に達し、推論前に自動で縮小されます。文字が潰れるときは、入稿した原本・前処理後の画像・モデルへ渡る直前の画像を並べて、どの段階で解像度が落ちているかを切り分けてください。なおMTP先読み層は、後述するvLLM起動時の投機デコーディング設定と対応しています。

ベンチマークの内訳と弱い領域

公称94.62点はOmniDocBench V1.5のスコアで、公式ドキュメントは発表時点（at launch）の比較でこのベンチマークの首位だったと記しています。速度は同一ハードウェア・単一レプリカ・単一並列という条件下でPDF 1.86ページ/秒、画像0.67枚/秒。ただし導入判断に必要なのは総合点ではなく、自社の文書がどのカテゴリに当たるかです。リポジトリに同梱されている評価結果ファイルには、カテゴリ別と言語別の実数が入っています。

olmOCR-Benchのカテゴリ別

overallの75.2にはヘッダー・フッター項目を除外したうえでZ.aiのAPI経由で計測したという注記が付きます。目を引くのは旧スキャンの37.6で、次に低いold_scans_mathの68.3より30.7ポイント、複段組の76.7より39.1ポイント低い値です。カテゴリ別スコアは条件を統制した比較実験ではないため原因までは特定できませんが、劣化が旧スキャン系の2カテゴリに集中している事実は残ります。退色した複写やマイクロフィルムを主対象にするなら、自社の実資料で文字誤り率を測り、許容できる修正工数に収まるかを確認してから採否を決めてください。

MDPBenchの言語別スコア

いずれも2026年4月14日時点のMDPBenchリーダーボード値です。日本語65.5は、英語より19.0ポイント、簡体字中国語より13.0ポイント低い。「多言語対応」の一語で日本語の精度を英語と同列に語ると見積もりを外します。撮影文書63.7とデジタル文書77.9の差が14.2ポイントある点も別に効いてきますが、日本語かつ撮影という交差条件のスコアは公開されていないため、スマートフォン撮影の日本語帳票を扱うなら自社サンプルで別途測ってください。日本語の帳票が主戦場なら、日本語専用に学習されたYomiTokuとの併走比較を先に済ませるほうが早いです。

Z.ai APIでの最短実行と上限・料金

GPUを持たずに試すならクラウドAPIが最短です。エンドポイントは https://api.z.ai/api/paas/v4/layout_parsing、モデルIDは glm-ocr で、fileにはURLまたはデータURIを渡します。

curl --location --request POST 'https://api.z.ai/api/paas/v4/layout_parsing' \
  --header 'Authorization: Bearer your-api-key' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "model": "glm-ocr",
    "file": "https://example.com/invoice.png"
  }'

Pythonは公式SDKのzai-sdkを使います。先に依存を入れます。

pip install zai-sdk

インストール後のPythonコードは次のとおりです。

from zai import ZaiClient

client = ZaiClient(api_key="your-api-key")
response = client.layout_parsing.create(
    model="glm-ocr",
    file="https://example.com/invoice.png",
)
print(response)

入力の制限と料金は公式のAPIガイドに記載があり、次のとおりです。料金は入力と出力で単価が変わらず、100万トークンあたり0.03ドルの一本値です。

100ページ上限はモデルの制約ではなくAPI側の受け付け上限です。数百ページの資料を流す設計なら、呼び出し側で100ページごとに分割するか、後述のセルフホストに寄せる必要があります。中国本土のMaaS（open.bigmodel.cn）を使う場合も、SDKのmaasモードで api_key を設定すれば同じパイプラインが動きます。

セルフホスト：vLLMとSGLangの起動コマンド

機密文書を外に出せない場合はvLLMかSGLangで自前配信します。どちらもMTPによる投機デコーディングを前提にした起動オプションが公式リポジトリに示されています。以下はいずれもホスト上に直接インストールして起動する手順です（公式はDockerイメージも案内していますが、コンテナで動かす場合は起動オプションをコンテナの実行コマンドとして渡す形になります）。

vLLMの導入とMTP設定

pip install -U "vllm>=0.19.0"
pip install "transformers>=5.3.0"

vllm serve zai-org/GLM-OCR --port 8080 \
  --speculative-config '{"method": "mtp", "num_speculative_tokens": 3}' \
  --served-model-name glm-ocr

公式リポジトリは、大きな画像やPDFを扱うなら --max-model-len と --gpu-memory-utilization をマシンに合わせて追加するよう注記しています。重みが2.65GBでも、ページ画像は面積に比例して視覚トークンが増えるため、投入する文書の解像度とページ数を決めてからこの2つを実測で調整してください。Docker利用時のイメージは vllm/vllm-openai:v0.19.0-ubuntu2404 です。

SGLangの導入と投機デコーディング設定

pip install "sglang>=0.5.10"

SGLANG_ENABLE_SPEC_V2=1 sglang serve --model-path zai-org/GLM-OCR --port 8080 \
  --speculative-algorithm NEXTN --speculative-num-steps 3 \
  --speculative-eagle-topk 1 --speculative-num-draft-tokens 4 \
  --served-model-name glm-ocr

SGLang側は --context-len と --mem-fraction-static が同じ役割の調整つまみです。Docker利用時のイメージは lmsysorg/sglang:v0.5.10 です。

公式SDKとモデルサーバの接続設定

モデルサーバを立てただけでは、レイアウト解析と領域ごとの並列OCR、Markdown整形が抜けます。この部分を担うのが公式SDKで、PP-DocLayoutV3の検出を含む完全なパイプラインを提供します。まず追加依存を入れます。

pip install "glmocr[selfhosted]"

次に、作業ディレクトリに config.yaml を作り、立ち上げたモデルサーバの宛先を書きます。

pipeline:
  maas:
    enabled: false
  ocr_api:
    api_host: localhost
    api_port: 8080

実行時は、この設定ファイルを --config で明示します。指定しないとパッケージ同梱の既定設定が読まれます。

glmocr parse invoice.pdf --config config.yaml --output ./results/
glmocr parse invoice.pdf --config config.yaml --layout-device cpu

--layout-device cpu はレイアウト検出だけをCPUへ逃がすオプションで、GPUをOCRモデル専有にしたいときに効きます。SDKにはFlaskサーバも用意されており、pip install "glmocr[server]" で依存を追加したうえで python -m glmocr.server を実行すると、5002番に /glmocr/parse が立ちます。GPUのないクライアントからは、このサーバのURLを maas.api_url に指定すれば同じインターフェースで呼べます。リクエストのimagesに配列を渡すと1つの文書の複数ページとして扱われるため、独立した複数文書は1件ずつ投げてください。

Ollama・GGUF・MLXでのローカル実行

手元のマシンで試すだけならOllamaが最も短く済みます。ライブラリに登録されているタグは3つだけで、いずれもコンテキスト長は128Kです。

LM Studioなどllama.cpp系のフロントエンドでGGUFを直接読む場合、言語モデル本体のファイルだけでは画像を受け取れません。視覚側は mmproj-GLM-OCR-Q8_0.gguf という別ファイルとして配布されているので、これを併せて読み込む設定になっているかを最初に確認してください。

Ollama経由でSDKを使うときは、OpenAI互換エンドポイントを使わないでください。公式のOllamaデプロイガイドは、Ollama側のOpenAI互換APIが画像リクエストで制限を抱えているため、ネイティブの /api/generate を推奨すると明記しています。502 Bad Gatewayが返る症状の対処法も、この設定へ切り替えることです。モデルの取得はこの1行です。

ollama pull glm-ocr:latest

Ollamaのサービスが localhost:11434 で動いている状態で、作業ディレクトリの config.yaml を次の内容にします。

pipeline:
  maas:
    enabled: false
  ocr_api:
    api_host: localhost
    api_port: 11434
    api_path: /api/generate
    model: glm-ocr:latest
    api_mode: ollama_generate

あとは設定ファイルを明示して実行します。

glmocr parse invoice.pdf --config config.yaml

Apple Siliconではmlx-vlmを使う手順が別途用意されており、公式ガイドはPython環境を2つ分ける前提で書かれています。ただしガイドが理由に挙げるtransformersのバージョン競合は、現行の pyproject.toml が transformers>=5.3.0 と下限のみを指定している以上、実際に競合するかは入るバージョンの組み合わせ次第です。SDKはHTTPでmlx-vlmサーバを叩く構成なので、環境を分けても分けなくても運用は成立します。

採用を見送るべき場面とライセンスの3層

GLM-OCRは汎用の視覚言語モデルではなく、受け付けるプロンプトが2系統に限定されています。文書パースは次の3つだけです。

Text Recognition:
Formula Recognition:
Table Recognition:

もう1系統が情報抽出で、こちらは厳密なJSONスキーマをプロンプトとして渡す形式に固定されています。モデルカードは、出力が定義済みスキーマに厳密に従う必要があると警告しています。つまり「この請求書の合計金額を要約して」のような自由記述の指示は設計の外です。文書を読ませたうえで推論や要約までさせたいなら、GLM-OCRではなくGLM系列の視覚言語モデル側を選ぶべきで、ここを取り違えると評価段階で「期待した答えが返らない」と誤った結論を出します。

言語と紙面の条件でも見送り判断が要ります。アラビア語21.7・タイ語27.4・ヒンディー語39.6は、ラテン文字系の平均78.7の半分以下です。旧スキャンの37.6も同水準です。これらが主戦場なら、まず自社サンプルで文字誤り率と後工程の修正工数を測り、既存OCRより工数が減らないならGLM-OCRを第一候補から外す、という順序で判断するのが早い。

ライセンスは1つではなく3層に分かれます。ここを「MITだから自由」で済ませると条件を取りこぼします。

公式READMEは、完全なOCRパイプラインがPP-DocLayoutV3を組み込んでいるため、利用者は両方のライセンスを遵守する必要があると明記しています。モデル重みだけを自前パイプラインに組み込むならMITの条件で足ります。SDKやPP-DocLayoutV3を含む形で成果物を再配布する場合は、Apache License 2.0の第4条に従い、ライセンス本文とNOTICEファイルの同梱・著作権表示の保持が必要になり、ファイルを改変したときはその旨の表示が追加で要ります。同じ文書解析OSSでも、YomiTokuのCC BY-NC-SA 4.0のように商用利用そのものに条件が付くものがあるため、OSSのOCRを比較するときはライセンス欄を最初に読むのが安全です。

よくある質問

GLM-OCRは日本語に対応していますか？

対応しています。Hugging Faceのモデルカードは対応言語に中国語・英語・フランス語・スペイン語・ロシア語・ドイツ語・日本語・韓国語を挙げています。ただし精度は英語と同等ではなく、MDPBenchの実測で日本語65.5に対し英語84.5です。日本語の帳票を大量に処理する用途では、事前に自社サンプルで精度を測ってから採用を決めてください。

Ollamaで動きますか？

動きます。ollama pull glm-ocr:latest でbf16版2.2GB、glm-ocr:q8_0 で1.6GBを取得できます。ただしSDKと組み合わせる場合は、OpenAI互換エンドポイントではなくネイティブの /api/generate を指定し、api_mode に ollama_generate を設定する必要があります。

PDFは何ページまで処理できますか？

Z.aiのクラウドAPIでは1リクエストあたり100ページ、ファイルサイズ50MBまでです。これはAPI側の受け付け上限なので、セルフホストであればこの制限は適用されません。

商用利用できますか？

できます。モデル重みはMITライセンスです。ただしSDKのコードとレイアウト解析に使われるPP-DocLayoutV3はApache-2.0なので、これらを含む形で配布する場合はApache-2.0の条件も併せて満たす必要があります。

手書き文字は読めますか？

公式のAPIドキュメントは、テキスト認識の対象に活字・手書き・数式を含むと記載しています。ただし手書き精度を単独で示す公開スコアは出ておらず、Z.aiの社内評価で手書きを含む6シナリオに優位性があるとされているだけです。手書き帳票が主用途なら、公開ベンチの数値ではなく自社サンプルでの実測を判断材料にしてください。

関連記事

• dots.mocrとは？83.9点の実力と日本語精度・導入手順【2026年9月】
• YomiTokuとは？使い方とYomiToku Studio（GUI）・商用利用の条件【v0.15.0】
• GLM（Z.ai）とは？最新バージョンGLM-5.2までの世代一覧と選び方・料金・使い方
• Snowflake AI_PARSE_DOCUMENTとAI_EXTRACTの使い方｜日本語の対応範囲・上限・料金【2026年9月】