---
title: "GLM-OCRとは？API・Ollama・vLLM・Pythonでの使い方と日本語精度・料金【2026年11月】"
url: "https://www.issoh.co.jp/tech/details/10872/"
published: 2026-02-05
updated: 2026-11-11
categories: ["LLM・RAG"]
publisher: "株式会社一創"
---

# GLM-OCRとは？API・Ollama・vLLM・Pythonでの使い方と日本語精度・料金【2026年11月】

GLM-OCRは、Z.ai（智譜AI）がHugging Faceで公開している文書解析用のOCRモデルです。公称0.9Bと小さく、クラウドAPI・Ollama・vLLM/SGLang・Transformersのどれでも動きます。ただし経路によって、レイアウト解析が付くか、JSONでの情報抽出ができるかが違います。この記事では4つの経路の起動手順を並べ、どれを選ぶべきかを[公式モデルカード](https://huggingface.co/zai-org/GLM-OCR)・SDKリポジトリ・API仕様の記述で判断できるようにしました。日本語の実測スコアと、採用を見送るべき条件も載せています。

## まとめ

GLM-OCRの使い方と導入判断の要点です。数値は2026年11月11日に確認したものです。

- 最短で試すならZ.ai API（`glm-ocr`、入出力とも100万トークンあたり0.03ドル）。GPU不要でレイアウト解析込みのMarkdownが返る。
- ページ上限は公式ガイドが100ページ、APIリファレンスが30ページと食い違う。PDFを30ページ以下のファイルに分割して送れば両方に収まる。
- 機密文書を外に出せないなら、vLLM 0.19.0以降かSGLang 0.5.10以降でモデルを配信し、公式SDK（`glmocr[selfhosted]`）でレイアウト解析を付ける。
- ローカルのPCで試すだけならOllama。`glm-ocr:latest` は2.7GB、`glm-ocr:q8_0` は1.8GB。
- 公式SDKは文書パース専用。請求書の項目をJSONで抜き出す情報抽出は、Transformersなどでモデルを直接呼ぶ。
- 日本語はMDPBenchで65.5点（英語84.5点）。旧スキャン文書は37.6点と弱い。

まず構成と配布容量を確認し、そのあと経路の選び方と各手順に進みます。

## GLM-OCRの構成：公称0.9Bの内訳と配布容量

[技術報告（arXiv:2603.10910）](https://arxiv.org/abs/2603.10910)の要旨は、GLM-OCRを0.4BのCogViT視覚エンコーダと0.5BのGLM言語デコーダを組み合わせたモデルと説明しています。0.9Bはこの主要2ブロックの合計です。推論時は、PP-DocLayoutV3でページを領域に分け、領域ごとにGLM-OCRで並列に認識する2段構成になります。

### VRAM見積り：重み容量2.65GBと追加メモリ

Hugging Faceがsafetensorsから集計する総パラメータ数は1,325,258,240（BF16）、重みファイル `model.safetensors` は2,650,579,464バイト（表示2.65GB）です。公称0.9Bより多いのは、config.jsonで入出力の埋め込みが共有されず（`tie_word_embeddings` が false）、MTPの先読み層（`num_nextn_predict_layers` が1）も入っているためです。GPUメモリやディスクを見積もるときは0.9Bでなく2.65GBから始め、さらにページ画像の視覚トークン分を上乗せしてください。

| 項目                       | 値                 |
| ------------------------ | ----------------- |
| 公称パラメータ                  | 0.9B（0.4B + 0.5B） |
| 集計パラメータ（BF16）            | 1,325,258,240     |
| 言語デコーダ hidden\_size / 層数 | 1,536 / 16        |
| 最大コンテキスト長                | 131,072           |
| 視覚エンコーダ depth / hidden   | 24 / 1,024        |
| 入力画像の面積上限                | 9,633,792 px      |

入力画像は面積で正規化されます。A4を300dpiで取り込んだ2,480×3,508（約870万ピクセル）は上限内ですが、600dpiの4,961×7,016（約3,481万ピクセル）は推論前に自動で縮小されます。この面積上限だけでは認識精度や必要なdpiは判断できません。文字サイズと文書の状態に応じて、取り込み解像度を比較してください。

## GLM-OCRの使い方を選ぶ：4つの実行経路の比較

どの経路でもモデル本体は同じですが、レイアウト解析とMarkdown整形はSDKかクラウドAPIを通したときにしか付きません。モデルカードは「SDKは現時点で文書パース専用で、情報抽出はモデルを直接呼んで推論する」と明記しています。用途と経路の対応は次のとおりです。

| 経路              | GPU | レイアウト解析  | JSON情報抽出  | 向く用途         |
| --------------- | --- | -------- | --------- | ------------ |
| Z.ai API        | 不要  | あり       | なし        | まず精度を見る      |
| vLLM/SGLang＋SDK | 必要  | あり（SDK）  | サーバー直呼びで可 | 社内配信・大量処理    |
| Ollama          | 任意  | SDK併用時のみ | 直呼びで可     | ローカルのPCで試す   |
| Transformers    | 推奨  | なし       | 可         | Pythonへの組み込み |

判断の順番は単純です。PDFをMarkdownにしたいだけなら、API→SDK＋vLLMの順で検討します。請求書や身分証から決まった項目を抜き出したいなら、SDKではなくTransformersかvLLMのサーバーを直接呼ぶ経路を選びます。ここを取り違えて、SDKにJSONスキーマを渡しても期待した出力は得られません。

## Z.ai APIによるGLM-OCRの実行手順と入力条件

エンドポイントは `https://api.z.ai/api/paas/v4/layout_parsing`、モデルIDは `glm-ocr` です。`file` には画像やPDFのURLか、base64のデータ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.pdf",
    "start_page_id": 1,
    "end_page_id": 30
  }'
```

Pythonでは公式SDKの `zai-sdk` を入れ、`client.layout_parsing.create` を呼びます。

```
pip install zai-sdk
```

```
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)
```

応答の `md_results` にMarkdown、`layout_details` に領域ごとの座標と種別、`usage` にトークン数が入ります。RAGに入れるならMarkdownを、帳票の位置で後処理するならlayout\_detailsを使います。

### APIの入力上限：30ページと100ページの記載差

入力条件は[公式ガイド](https://docs.z.ai/guides/vlm/glm-ocr)と[APIリファレンス](https://docs.z.ai/api-reference/tools/layout-parsing)で一致していません。

| 項目     | 公式ガイド                  | APIリファレンス       |
| ------ | ---------------------- | --------------- |
| 形式     | PDF / JPG / PNG        | PDF / JPG / PNG |
| 画像1枚   | 10MB以下                 | 10MB以下          |
| PDF1件  | 50MB以下                 | 50MB以下          |
| 最大ページ数 | 100ページ                 | 30ページ           |
| 料金     | 入出力とも100万トークンあたり0.03ドル | –               |

どちらが実際の上限かは公式に明示されていません。APIリファレンスにある `start_page_id` と `end_page_id` は解析対象のページ範囲を指定するパラメータで、30ページを超えるPDF自体を受け付ける保証にはなりません。安全側に倒すなら、入力PDFを30ページ以下かつ50MB以下のファイルに分割して送信してください。料金は入力と出力で同額なので、画像の多いページでも単価の見積りはトークン数だけで済みます。

## vLLM・SGLangによるGLM-OCRのセルフホスト手順

機密文書を社外に出せない場合は、vLLMかSGLangでモデルを配信し、その手前に公式SDKを置きます。起動オプションは[公式リポジトリ](https://github.com/zai-org/GLM-OCR)のREADMEにあります。

### 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
```

Dockerなら `vllm/vllm-openai:v0.19.0-ubuntu2404` が公式の指定です。一方、[vLLM Recipes](https://recipes.vllm.ai/zai-org/GLM-OCR)は「vLLM 0.16.0以降・Transformers 5.0.0以降」と書き、投機トークン数も1で起動しています。両者の条件は揃っていないので、SDKと組み合わせる本番ではREADMEの0.19.0・投機トークン3に合わせ、Recipesの値は参考にとどめてください。大きな画像やPDFを扱うなら、READMEの注記どおり `--max-model-len` と `--gpu-memory-utilization` を追加して調整します。

### SGLangの起動とNEXTN設定

```
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をモデルサーバーにつなぐ設定

モデルサーバーだけではレイアウト解析とMarkdown整形が付きません。SDKにPP-DocLayoutV3の依存を入れ、作業ディレクトリに `config.yaml` を置きます。PyPIの `glmocr` は2026年4月8日公開の0.1.5が最新で、Python 3.10以降が必要です。

```
pip install "glmocr[selfhosted]"
```

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

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

`--config` を省くとパッケージ同梱の既定設定が読まれ、立てたサーバーに接続しません。`--layout-device cpu` はレイアウト検出だけをCPUで動かし、GPUをOCRモデルに空けるオプションです。GPUの無い端末から使わせるなら、`pip install "glmocr[server]"` をサーバー側に追加し、`python -m glmocr.server --config config.yaml` を起動すると、5002番ポートに `/glmocr/parse` が立ちます。このときリクエストの `images` に配列を渡すと1つの文書の複数ページとして扱われるため、別々の文書は1件ずつ送ってください。

## OllamaによるGLM-OCRのローカル実行手順

Ollamaのライブラリにあるタグは3つで、2026年11月11日時点の容量は次のとおりです。9月時点の2.2GB・1.6GBから増えているので、ディスクの空きは新しい値で見積もってください。

| タグ                      | サイズ   | コンテキスト |
| ----------------------- | ----- | ------ |
| glm-ocr:latest（bf16と同一） | 2.7GB | 128K   |
| glm-ocr:bf16            | 2.7GB | 128K   |
| glm-ocr:q8\_0           | 1.8GB | 128K   |

いちばん短い試し方は、[Ollamaのライブラリページ](https://ollama.com/library/glm-ocr)にある1行です。プロンプトの後ろに画像のパスを付けます。

```
ollama run glm-ocr "Text Recognition: ./image.png"
ollama run glm-ocr "Table Recognition: ./image.png"
```

この方法はページ全体を1回で読むだけで、レイアウト解析は通りません。段組みや表の混ざったPDFを扱うなら、SDKからOllamaを呼ぶ構成にします。

### SDKとOllamaの接続：/api/generateの設定

[公式のOllamaデプロイガイド](https://github.com/zai-org/GLM-OCR/blob/main/examples/ollama-deploy/README.md)は、OllamaのOpenAI互換APIが画像リクエストで制限を抱えているため、ネイティブの `/api/generate` を使うよう指示しています。502 Bad Gatewayが返る場合の対処もこの設定です。

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

### LM StudioでGGUFを読むときの注意

ggml-org/GLM-OCR-GGUFでは、言語モデル本体（`GLM-OCR-Q8_0.gguf` 950,433,408バイト、f16版は1,785,771,648バイト）と、視覚側の `mmproj-GLM-OCR-Q8_0.gguf`（484,403,648バイト）が別ファイルです。LM Studioなどllama.cpp系のツールで画像を処理するには、対応するmmprojの読み込みが必要です。未読み込み時の挙動はツールやバージョンにより異なり、画像入力エラーになる場合もあります。Apple Siliconではmlx-vlmを使う手順が公式に用意されています。

## PythonによるGLM-OCRの直接推論とJSON情報抽出

TransformersはGLM-OCRをv5.1.0で取り込んでいます。[Transformersの公式ドキュメント](https://github.com/huggingface/transformers/blob/main/docs/source/en/model%5Fdoc/glm%5Focr.md)は `GlmOcrForConditionalGeneration` で読み込む例を載せています。下は、そのコードを情報抽出のプロンプトに差し替えたものです。

```
pip install "transformers>=5.3.0" torch accelerate
```

```
from transformers import AutoProcessor, GlmOcrForConditionalGeneration

model_id = "zai-org/GLM-OCR"
processor = AutoProcessor.from_pretrained(model_id)
model = GlmOcrForConditionalGeneration.from_pretrained(model_id, device_map="auto")

prompt = """请按下列JSON格式输出图中信息:
{
    "invoice_number": "",
    "issue_date": "",
    "seller_name": "",
    "total_amount": ""
}"""

messages = [{
    "role": "user",
    "content": [
        {"type": "image", "path": "invoice.png"},
        {"type": "text", "text": prompt},
    ],
}]
inputs = processor.apply_chat_template(
    messages, tokenize=True, add_generation_prompt=True,
    return_dict=True, return_tensors="pt",
).to(model.device)

output = model.generate(**inputs, max_new_tokens=1024)
print(processor.decode(output[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))
```

先頭の中国語は「次のJSON形式で画像内の情報を出力してください」という意味で、モデルカードの情報抽出例がこの一文で始まっています。モデルカードは、後段処理との互換性のために出力を定義済みスキーマに合わせるよう求めています。生成結果はJSONとして解析し、必須キー・型・入れ子構造を検証してから利用してください。文書パースだけなら、`prompt` を `Text Recognition:`・`Formula Recognition:`・`Table Recognition:` のいずれかに置き換えます。

受け付けるプロンプトはこの2系統だけです。「合計金額を要約して」のような自由記述の指示は設計の外なので、読み取った内容で推論や要約までさせたいなら[GLM系列の汎用モデル](/tech/details/12795/)に渡してください。

## ベンチマークの内訳と日本語の精度

公称の94.62点はOmniDocBench V1.5の総合点で、公式ガイドは発表時点の首位と記しています。採否を決めるには、リポジトリ同梱の評価ファイルにあるカテゴリ別と言語別の値を見ます。

### MDPBenchの日本語は65.5点

| 区分      | スコア  |
| ------- | ---- |
| 英語      | 84.5 |
| 中国語（簡体） | 78.5 |
| デジタル文書  | 77.9 |
| 日本語     | 65.5 |
| 撮影文書    | 63.7 |
| 韓国語     | 61.2 |
| アラビア語   | 21.7 |

値は2026年4月14日付の[MDPBenchの評価ファイル](https://huggingface.co/zai-org/GLM-OCR/blob/main/.eval%5Fresults/mdpbench.yaml)です。日本語は英語より19.0ポイント低く、撮影文書はデジタル文書より14.2ポイント低い。日本語かつスマートフォン撮影という組み合わせのスコアは公開されていないため、その用途なら自社の帳票で文字誤り率を測ってから決めてください。日本語の帳票が中心なら、日本語に特化した[YomiToku](/tech/details/6169/)や、MDPBenchの日本語でGLM-OCRを上回る[dots.mocr](/tech/details/11776/)と並べて比べるのが近道です。

### olmOCR-Benchで旧スキャンは37.6点

| カテゴリ             | スコア  |
| ---------------- | ---- |
| baseline         | 98.8 |
| long\_tiny\_text | 86.9 |
| arxiv\_math      | 80.7 |
| table\_tests     | 77.6 |
| multi\_column    | 76.7 |
| old\_scans\_math | 68.3 |
| old\_scans       | 37.6 |
| overall          | 75.2 |

overallはヘッダー・フッター項目を除き、Z.aiのAPI経由で測った値です（[olmOCR-Benchの評価ファイル](https://huggingface.co/zai-org/GLM-OCR/blob/main/.eval%5Fresults/olmocrbench.yaml)の注記）。旧スキャンの37.6は次に低いold\_scans\_mathより30.7ポイント低く、劣化はこのカテゴリに集中しています。退色した複写やマイクロフィルムの電子化が主目的なら、GLM-OCRを第一候補にしないでください。

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

見送るべきなのは次の場合です。アラビア語・タイ語（27.4点）・ヒンディー語（39.6点）が主な対象の場合。旧スキャンが大半を占める場合。読み取った内容の要約や判断までOCRモデル1つで済ませたい場合。最初の2つは精度の問題で、3つめはプロンプトが2系統に限られる設計の問題です。

ライセンスは1つではありません。

| 対象                      | ライセンス      |
| ----------------------- | ---------- |
| モデル重み（zai-org/GLM-OCR）  | MIT        |
| SDKリポジトリのコード            | Apache-2.0 |
| PP-DocLayoutV3（レイアウト解析） | Apache-2.0 |

モデルカードは、完全なOCRパイプラインがPP-DocLayoutV3を組み込んでいるため両方のライセンスを守るよう求めています。重みだけを自前の処理に組み込むならMITの条件で足ります。SDKを含めて再配布するなら、[Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0.html)第4条に従ってライセンス本文を提供し、改変ファイルには変更を明記します。派生物のソースを配布する場合は関連する権利表示を保持し、元の配布物にNOTICEがある場合は、その関連する帰属表示も所定の方法で提供します。帳票OCRを業務フローに組み込む設計から相談したい場合は、[AI-OCR導入支援](/service/ai/ocr/)で対応しています。

## よくある質問

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

対応しています。モデルカードは対応言語に中国語・英語・フランス語・スペイン語・ロシア語・ドイツ語・日本語・韓国語を挙げています。ただしMDPBenchの実測では日本語65.5点、英語84.5点と差があります。日本語の帳票を大量に処理するなら、自社サンプルで文字誤り率を測ってから採用を決めてください。

### GPUなしで使えますか？

使えます。Z.aiのクラウドAPIならGPUは不要で、入出力とも100万トークンあたり0.03ドルです。手元で動かす場合も、Ollamaの `glm-ocr:q8_0`（1.8GB）ならGPUの無いPCで起動できます。ただし処理速度はハードウェアに大きく左右されるため、大量処理にはvLLMかSGLangをGPU上で動かす構成が向いています。

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

Z.aiのクラウドAPIは、公式ガイドでは100ページ、APIリファレンスでは30ページと書かれています。ファイルサイズは50MBまでです。`start_page_id` と `end_page_id` は解析範囲の指定に使います。入力上限への対策としては、PDF自体を30ページ以下かつ50MB以下のファイルに分割してください。セルフホストではこのAPIの制限はかかりません。

### 商用利用できますか？

できます。モデル重みはMITライセンスです。ただしSDKのコードとレイアウト解析のPP-DocLayoutV3はApache-2.0なので、これらを含めて配布するなら、ライセンス本文の提供や改変の明示などApache-2.0の条件も満たす必要があります。元の配布物にNOTICEがある場合は、関連する帰属表示も提供します。

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

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

## 関連記事

- [dots.mocrとは？dots.ocrとの違いと日本語精度・vLLM導入手順【2026年10月】](/tech/details/11776/)
- [DeepSeek-OCRとは？OCR 2との違い・仕組み・使い方とAPI・ローカル実行](/tech/details/9455/)
- [YomiToku Studioの使い方：4つのワークスペースとPython版・商用利用の条件【v0.15.0】](/tech/details/6169/)
- [MinerUとは？PDFをMarkdown化する使い方と4.0の新コマンド【4.0.12で実測】](/tech/details/6505/)
- [GLM（Z.ai）とは？最新GLM-5.3までの世代一覧と料金・使い方](/tech/details/12795/)

---

出典: [GLM-OCRとは？API・Ollama・vLLM・Pythonでの使い方と日本語精度・料金【2026年11月】](<https://www.issoh.co.jp/tech/details/10872/>)（株式会社一創）