Blog

GLM-OCR 導入ガイド：文書理解のための完全版

Ashley Goolam

Ashley Goolam

5 2月 2026

GLM-OCR 導入ガイド：文書理解のための完全版

ほとんどのスマートフォンアプリよりも小さいモデルで、複雑なPDF、テーブル、数式からテキストを抽出できるとしたらどうでしょう？GLM-OCRは、わずか9億のパラメータで最先端のドキュメント理解を実現します。控えめなハードウェアでも動作するほど軽量でありながら、OmniDocBench V1.5のリーダーボードで94.62ポイントを獲得し、首位に立つほど正確です。

従来のOCRツールは、ドキュメントの構造に対応するのに苦労していました。テーブルの書式設定が失われたり、数式を誤読したり、複数列のレイアウトで失敗したりします。クラウドAPIはこれらの問題を解決しますが、リクエストごとに課金され、機密文書をサードパーティのサーバーに送信します。GLM-OCRは、これらの問題を両方とも解消します。複雑なレイアウトをローカルでプロダクションレベルの精度で処理し、商業利用をライセンス費用なしで許可するMITライセンスの下で提供されます。

💡
請求書からのデータ抽出、技術ドキュメントの解析、フォーム処理の自動化など、信頼性の高いAPIテストを必要とするドキュメント処理パイプラインを構築する際、Apidogはワークフロー全体を効率化します。Apidogは、視覚的なリクエスト構築、自動ドキュメント生成、およびGLM-OCRデプロイメントとシームレスに連携する共同デバッグツールを提供します。
ボタン

GLM-OCRアーキテクチャの理解

GLM-OCRは、ドキュメント理解に最適化された3コンポーネントのエンコーダー・デコーダーアーキテクチャを使用しています。CogViT視覚エンコーダーは、数十億の画像とテキストのペアで事前学習された重みを使用して、ドキュメント画像を処理します。レイアウト理解に不可欠な空間関係を維持しながら、視覚的特徴を抽出します。

軽量なクロスモーダルコネクタがエンコーダーとデコーダーの間に配置されています。このコンポーネントは視覚トークンを効率的にダウンサンプリングし、精度を犠牲にすることなく計算オーバーヘッドを削減します。GLM-0.5B言語デコーダーは、プレーンな段落から複雑なネストされたテーブルまで、あらゆるものを処理する構造化されたテキスト出力を生成します。

このモデルは2段階の推論パイプラインを採用しています。まず、PP-DocLayout-V3がドキュメント構造（ヘッダー、段落、テーブル、図など）を分析します。次に、並列認識が各領域を同時に処理します。このアプローチにより、従来のOCRがすべてを非構造化テキストに平坦化するのに対し、ドキュメントの階層が維持されます。

トレーニングの革新により、パフォーマンスがさらに向上します。マルチトークン予測損失は、複数のトークンを同時に予測することでトレーニング効率を向上させます。安定したフルタスク強化学習は、多様なドキュメントタイプに対する汎化性能を高めます。その結果、数式認識で96.5%、テーブル認識で86.0%の精度を達成し、情報抽出タスクで優れた性能を発揮します。

推論時、GLM-OCRは単一GPUで毎秒1.86PDFページを処理し、同等のモデルよりも大幅に高速です。9億のパラメータ数は、エンタープライズクラスターではなく、消費者向けハードウェアにデプロイできることを意味します。

GLM-OCRモデル

モデルの仕様

GLM-OCRは、最大8K解像度（7680×4320ピクセル）のドキュメントを処理できます。英語、中国語、日本語、韓国語を含む8つの言語を認識します。このモデルは、ラスター画像（PNG、JPEG）とベクター入力の両方を処理します。一般的な推論では、FP16精度で4〜6GBのVRAMを消費し、RTX 3060のような消費者向けGPUやAWS g4dn.xlargeのようなクラウドインスタンスに適合します。

> | ハードウェア        | 必要なVRAM | ページ/秒 | 用途               |
 --------------------------------------------------------------------
> | RTX 3060        | 4-6GB         | ~1.5      | 開発               |
> | RTX 4090        | 4-6GB         | ~2.5      | 本番               |
> | AWS g4dn.xlarge | 16GB          | ~1.8      | クラウドデプロイ   |
> | 4x A100 (TPS=4) | 80GB          | ~7.0      | エンタープライズ   |

ローカルデプロイのオプション

GLM-OCRは、インフラストラクチャとパフォーマンス要件に応じて4つのデプロイ方法をサポートしています。それぞれHugging Faceからの同じ基盤モデルの重みを使用しますが、異なるシナリオに合わせて最適化されています。

  1. vLLMは、本番ワークロードにおいてスループットとレイテンシの最適なバランスを提供します。効率的なメモリ管理のためにPagedAttentionを実装し、高並行シナリオのために連続バッチ処理をサポートします。
  2. SGLangは、ランタイム最適化により最高のパフォーマンスを提供します。投機的デコーディングと構造化生成に優れており、可能な限り最速の推論が必要な場合に最適です。
  3. Ollamaは、最も簡単なセットアップを提供します。Pythonの依存関係や設定ファイルなしで、1つのコマンドでモデルをダウンロードしてローカルで実行できます。プロトタイプ作成や個人利用に最適です。
  4. Transformersは、Pythonとの直接統合を可能にします。開発、デバッグ、または推論パイプラインのきめ細かな制御が必要な場合に使用します。

すべての方法でHugging FaceのGLM-OCRの重み（zai-org/GLM-OCR）が必要です。このモデルはCUDAをサポートするNVIDIA GPUで動作します。CPUのみの推論も可能ですが、速度が大幅に低下します。

本番環境向けvLLMのセットアップ

vLLMは、OpenAI互換APIエンドポイントを使用して、本番環境に対応した推論を提供します。これにより、既存のOpenAIのビジョンモデルを使用しているアプリケーションにGLM-OCRを組み込むことができます。

インストール

CUDAサポート付きでvLLMをインストールする：

pip install -U vllm --extra-index-url https://wheels.vllm.ai/nightly

コンテナ化されたデプロイには、公式のDockerイメージを使用します：

docker pull vllm/vllm-openai:nightly

互換性のあるTransformersをインストールします。vLLMはGLM-OCRをサポートするために最新の開発バージョンを必要とします：

pip install git+https://github.com/huggingface/transformers.git

サービスの起動

GLM-OCRでvLLMサーバーを起動する：

vllm serve zai-org/GLM-OCR \
  --allowed-local-media-path / \
  --port 8080 \
  --speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'

--allowed-local-media-pathフラグを使用すると、モデルがローカル画像ファイルにアクセスできるようになります。これをドキュメントディレクトリまたは無制限のアクセス用に/に設定します（本番環境では注意して使用してください）。

--speculative-configは、GLM-OCRの機能であるMulti-Token Predictionを有効にします。これは、複数のトークンを同時に予測することで推論を高速化します。

クライアント統合

実行が開始されたら、標準のHTTPリクエストを通じてGLM-OCRと対話します：

curl --location --request POST 'http://localhost:8080/v1/chat/completions' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "model": "zai-org/GLM-OCR",
    "messages": [
      {
        "role": "user",
        "content": [
          {"type": "image_url", "image_url": {"url": "file:///path/to/document.png"}},
          {"type": "text", "text": "Extract all text from this document"}
        ]
      }
    ]
  }'

OpenAI互換のレスポンス形式により、既存のSDKは変更なしで動作します。OpenAIクライアントをhttp://localhost:8080に接続し、モデル名としてzai-org/GLM-OCRを使用してください。

本番環境の設定

高スループットのデプロイには、複数のGPUにわたるテンソル並列処理を追加します：

vllm serve zai-org/GLM-OCR \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.95 \
  --max-model-len 8192 \
  --allowed-local-media-path / \
  --port 8080

--tensor-parallel-sizeをGPU数に合わせて調整してください。GPUの使用率を監視し、バッチサイズを増やしてスループットを最大化します。

監視とスケーリング

vLLMのパフォーマンスは、/metricsにある組み込みのメトリクスエンドポイントを通じて追跡できます。Prometheus互換のデータには、リクエストレイテンシ、キュー深度、GPU使用率が含まれます。キュー深度が10リクエストを超えたり、GPUメモリが90%に達したりした場合にアラートを設定してください。水平スケーリングには、ロードバランサーの背後に複数のvLLMインスタンスをデプロイし、スティッキーセッションを使用してリクエスト間のコンテキストを維持します。

モデルのパフォーマンスと並行して本番環境のメトリクスを追跡するために、ApidogのAPI監視機能の使用を検討してください。

SGLangによる高性能推論

SGLangは、最大の推論速度のために高度なランタイム最適化を提供します。投機的デコーディングと構造化生成に優れており、レイテンシに敏感なアプリケーションに最適です。

インストール

Docker経由でSGLangをインストールします（依存関係の分離に推奨）：

docker pull lmsysorg/sglang:dev

またはソースからインストールします：

pip install git+https://github.com/sgl-project/sglang.git#subdirectory=python

互換性のあるTransformersをインストールします：

pip install git+https://github.com/huggingface/transformers.git

サービスの起動

最適化された投機的デコーディングでSGLangを起動する：

python -m sglang.launch_server \
  --model zai-org/GLM-OCR \
  --port 8080 \
  --speculative-algorithm NEXTN \
  --speculative-num-steps 3 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 4

投機的デコーディングのパラメータは、複数のトークンを同時にドラフトし、それらを並行して検証することで推論を高速化します。--speculative-num-stepsはハードウェアに基づいて調整してください。高い値は速度を向上させますが、より多くのメモリを必要とします。

構造化出力

SGLangの構造化生成により、GLM-OCRが有効なJSONまたはその他のスキーマを出力することが保証されます：

import sglang as sgl

@sgl.function
def extract_invoice(s, image_path):
    s += sgl.user(sgl.image(image_path) + "Extract invoice data as JSON")
    s += sgl.assistant(sgl.gen("json_output", json_schema={
        "type": "object",
        "properties": {
            "invoice_number": {"type": "string"},
            "date": {"type": "string"},
            "total": {"type": "number"},
            "items": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "description": {"type": "string"},
                        "quantity": {"type": "integer"},
                        "price": {"type": "number"}
                    }
                }
            }
        }
    }))

result = extract_invoice.run(image_path="invoice.png")
print(result["json_output"])

これにより、後処理やリトライロジックなしで機械可読な出力が保証されます。構造化されたレスポンスを提供するAPIエンドポイントの場合、Apidogのスキーマ検証は、出力形式が期待されるJSON構造と一致することを自動的に検証できます。

vLLMではなくSGLangを選択すべき時

構造化された出力または投機的デコーディングが必要な場合は、SGLangを選択してください。その正規表現制約付き生成は、有効なJSONスキーマを保証し、リトライロジックを不要にします。投機的アルゴリズムは、十分なメモリを持つGPUでトークン生成を30〜40%高速化します。

> | 特徴              | vLLM            | SGLang              |
 ---------------------------------------------------------------
> | スループット      | 高い            | 非常に高い          |
> | レイテンシ        | 良好            | 非常に優れている    |
> | OpenAI互換        | はい            | いいえ              |
> | 構造化出力        | 手動            | 組み込み            |
> | コミュニティサポート | 非常に優れている | 成長中             |
> | セットアップの複雑さ | 中程度          | 高い                |
> | 最適な用途        | 本番API         | 速度が重要なアプリ  |

厳密なレイテンシ要件がない標準のOCRの場合、vLLMはよりシンプルな設定と優れたコミュニティサポートにより十分なパフォーマンスを提供します。

Transformersの直接統合

開発、デバッグ、またはカスタムパイプラインの場合、Transformersライブラリを直接使用します。これは、vLLMやSGLangと比較してスループットが低くなるという犠牲を伴いますが、最大限の柔軟性を提供します。

インストール

最新のTransformersをソースからインストールします：

pip install git+https://github.com/huggingface/transformers.git

基本的な推論

PythonでGLM-OCRをロードして実行する：

from transformers import AutoProcessor, AutoModelForImageTextToText
import torch

MODEL_PATH = "zai-org/GLM-OCR"

# Prepare input
messages = [
    {
        "role": "user",
        "content": [
            {"type": "image", "url": "document.png"},
            {"type": "text", "text": "Text Recognition:"}
        ],
    }
]

# Load model and processor
processor = AutoProcessor.from_pretrained(MODEL_PATH)
model = AutoModelForImageTextToText.from_pretrained(
    MODEL_PATH,
    torch_dtype="auto",
    device_map="auto",
)

# Process input
inputs = processor.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_dict=True,
    return_tensors="pt"
).to(model.device)

inputs.pop("token_type_ids", None)

# Generate output
generated_ids = model.generate(**inputs, max_new_tokens=8192)
output_text = processor.decode(
    generated_ids[0][inputs["input_ids"].shape[1]:],
    skip_special_tokens=False
)

print(output_text)

device_map="auto"は、利用可能なGPUにモデル層を自動的に分散します。シングルGPUデプロイの場合、これによりフルモデルが1つのデバイスにロードされます。CPUのみの推論の場合、device_map="cpu"に変更しますが、パフォーマンスは大幅に低下します。

バッチ処理

複数のドキュメントを効率的に処理する：

import os
from pathlib import Path

def batch_process(directory, output_file):
    documents = list(Path(directory).glob("*.png")) + \
                list(Path(directory).glob("*.pdf"))
    
    results = []
    for doc_path in documents:
        # Convert PDF to images if needed
        if doc_path.suffix == ".pdf":
            images = convert_pdf_to_images(doc_path)
        else:
            images = [doc_path]
        
        for image in images:
            text = extract_text(image)  # Your extraction function
            results.append({
                "file": str(doc_path),
                "page": image.page_num if hasattr(image, 'page_num') else 1,
                "text": text
            })
    
    # Save results
    with open(output_file, 'w') as f:
        json.dump(results, f, indent=2)

# Usage
batch_process("./invoices/", "extracted_data.json")

本番環境でドキュメントを処理する場合、 Apidogのワークスペース管理は、複数のドキュメント処理エンドポイントを論理的なグループに整理するのに役立ち、さまざまなワークフローのテストと監視を容易にします。

メモリ最適化

VRAMが限られているGPUの場合、量子化を使用します：

from transformers import BitsAndBytesConfig

quantization_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.float16
)

model = AutoModelForImageTextToText.from_pretrained(
    MODEL_PATH,
    quantization_config=quantization_config,
    device_map="auto",
)

4ビット量子化は、ドキュメント理解タスクにおいて精度への影響を最小限に抑えながら、メモリ使用量を75%削減します。

エッジケースの処理

手書きが多いドキュメントや極端な傾斜角のあるドキュメントは、精度を低下させます。GLM-OCRに送信する前に、傾斜補正アルゴリズムで画像を前処理してください。複数ページのPDFの場合、ファイル全体を渡すのではなく、ページを個別の画像として抽出します。これにより、並列処理が可能になり、個々のページが失敗した場合のエラー処理が簡素化されます。透かしのあるドキュメントは、テキスト領域で誤検出を誘発することがあるため、特定の領域で文字化けした出力が見られる場合は、コントラスト調整を試してください。

GLM-OCRのリアルワールドユースケース

GLM-OCRは、いくつかの本番シナリオで優れています：

請求書処理

経理チームは、スキャンされた請求書から明細項目、日付、合計を抽出します。このモデルはテーブル構造を維持し、手動レビューなしで正確な合計計算を保証します。ローカルデプロイメントにより、数千件の請求書を1日あたり処理でき、APIコストはゼロです。

技術文書

エンジニアリングチームは、PDFのマニュアルや仕様書を検索可能なテキストに変換します。数式認識により数式が保持され、技術コンテンツが機械可読になります。レガシー文書の最新化プロジェクトに最適です。

GLM-OCRの例

法的文書分析

法務担当者は、ドキュメントの階層を尊重するOCRで契約書や合意書をレビューします。複数列のレイアウト処理により、段落が誤って結合されることがなくなります。プライバシーを第一に考えたアプローチにより、機密データはオンプレミスに保持されます。

医療記録

医療機関は、患者のフォームや処方箋をデジタル化します。8言語を認識するため、多言語医療環境で役立ちます。ローカルデプロイメントは、データを内部に保持することでHIPAAコンプライアンス要件を満たします。

結論

GLM-OCRは、9億のパラメータパッケージでプロダクションレベルのドキュメント理解を提供します。ローカルにデプロイし、データプライバシーを維持しながら、クラウドAPIに匹敵するスループットレートを実現します。しかも、リクエストごとの課金はありません。従来のOCRでは見逃されがちな複雑なレイアウト、テーブル、数式を処理できるアーキテクチャを持ち、MITライセンスにより無制限の商業利用が許可されます。

高スループットとOpenAI互換性が必要な本番デプロイにはvLLMを選択してください。最大の推論速度が重要な場合はSGLangを使用します。開発およびカスタムパイプラインにはTransformersを選択してください。各オプションは同じ基盤モデルを実行するため、再トレーニングや再調整なしでデプロイ方法を切り替えることができます。

請求書からのデータ抽出、技術文書の解析、フォーム処理の自動化など、ドキュメント処理パイプラインを構築する際は、ApidogでAPIテストを効率化しましょう。Apidogは、視覚的なリクエスト構築、自動ドキュメント生成、およびGLM-OCRのデプロイワークフローを補完する共同デバッグツールを提供します。

ボタン

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる

無料会員登録ダウンロード