OCI A10 GPUにMinerUをデプロイして文書解析APIを立てる

はじめに

RAGを業務で利用する場合、回答生成モデルだけでなく、PDFや画像から検索可能なテキストを作る前処理が重要になります。

社内ドライブには、次のような形式の異なる資料が混在しています。

• テキスト主体のPDF
• 表を含む会議資料
• スキャンされた帳票
• 複数カラムのマニュアル
• 図やチャートを含む提案書
• PowerPointから出力したPDF

通常のPDFテキスト抽出では、見出し、読み順、表の行列関係が崩れることがあります。

そこで今回は、文書解析モデルのMinerUをOCIのNVIDIA A10 GPUへデプロイします。

使用するTerraformスタックは、

です。

このスタックをOCI Resource Managerから実行すると、A10インスタンスの作成、NVIDIAドライバー、Docker、NVIDIA Container Toolkit、vLLM、MinerUモデルの起動までを自動化できます。

まず結論

このツールを使うと、次の環境をOCI上に作成できます。

OCI Resource Manager
  |
  v
OCI Compute
VM.GPU.A10.1 / VM.GPU.A10.2
Ubuntu 24.04
  |
  +-- NVIDIA Driver
  +-- Docker
  +-- NVIDIA Container Toolkit
  |
  v
vLLM OpenAI互換サーバー
  |
  v
opendatalab/MinerU2.5-Pro-2605-1.2B

デフォルトのHugging Faceモデルは次のとおりです。

opendatalab/MinerU2.5-Pro-2605-1.2B

APIで使用するモデル名は次のとおりです。

mineru2-5-pro-2605-1-2b

デプロイ後は、認証付きのOpenAI互換APIとして、/v1/modelsと/v1/chat/completionsから利用できます。

ただし、このスタックがデプロイするのは、MinerU VLMを実行するvLLM APIサーバーです。

PDFやOfficeファイルを直接アップロードできる完全なmineru-apiや、MinerU WebUIをデプロイするものではありません。

MinerUとは

MinerUは、PDFや文書画像から、本文、見出し、表、画像などの文書構造を抽出するためのドキュメント解析ツールです。

単に画像内の文字を左上から順番に読むOCRではなく、ページ内のレイアウトを解析して、後段で利用しやすい構造へ変換することを得意とします。

代表的な出力は次のとおりです。

Markdown
HTMLテーブル
抽出画像
レイアウト情報
JSON

このため、次のような処理に向いています。

PDFのMarkdown化
RAG用テキストの生成
見出し単位のチャンク分割
表構造の保持
文書内画像の分離

実測で分かったMinerUの特長

OCR比較記事では、性格の異なる6種類の実データを使い、GLM-OCR、dots.mocr、Unlimited-OCR、MinerUを比較しました。

その結果、MinerUは特にテキスト主体のPDFと構造化された業務文書で強みを発揮しました。

1. テキストPDFの処理が速い

4ページの日本語会議録PDFを処理した検証では、MinerUは約8.9秒で処理を完了しました。

同じ検証では、GLM-OCRが約31.4秒、dots.mocrが約30.2秒、Unlimited-OCRが約24.4秒でした。

1回の計測結果ではありますが、MinerUは4モデルの中で最も高速でした。

会議録PDF・4ページ

MinerU         約8.9秒
Unlimited-OCR 約24.4秒
dots.mocr     約30.2秒
GLM-OCR       約31.4秒

GLM-OCRはPDFをページ画像へ変換してから1ページずつ処理する必要があります。

一方、完全なMinerUパイプラインではPDFを文書として処理できるため、複数ページの資料を効率よく解析できます。

2. 見出し付きのMarkdownを生成できる

会議録PDFでは、MinerUは次のような見出し付きMarkdownを生成しました。

## 会議録

1. 会議情報

会議ID: M03

## 2. 議題

候補モデルの比較観点の最終決定

見出しを保持できると、RAGへ登録するときに文書を章や節ごとに分割できます。

例えば、Markdown見出しを基準に次のようなチャンクを作成できます。

## 会議情報
  → チャンク1

## 議題
  → チャンク2

## 決定事項
  → チャンク3

## アクションアイテム
  → チャンク4

固定文字数だけで分割する方法と比べて、意味的なまとまりを保持しやすくなります。

参考記事の検証でも、MinerUはテキストPDFに対して、速度とMarkdown構造の両面で扱いやすい結果でした。

3. 表をHTMLテーブルとして保持できる

日本語、英語、記号、表を含む画面スクリーンショットの検証では、MinerUは高い文字認識精度を維持しながら、表をHTML形式で復元しました。

出力イメージは次のようになります。

<table>
  <tr>
    <td>AI ID</td>
    <td>Action</td>
    <td>Owner</td>
    <td>Status</td>
  </tr>
  <tr>
    <td>A08</td>
    <td>分析環境の整備</td>
    <td>担当者A</td>
    <td>Closed</td>
  </tr>
</table>

一般的なOCRでは、表が次のような単純テキストになることがあります。

A08
分析環境の整備
担当者A
Closed
A09
データ確認
担当者B
Open

この形式では、どの値がどの列に対応しているか分かりにくくなります。

HTMLテーブルであれば、行と列の対応関係を維持できます。

そのため、次の用途に適しています。

一覧表の検索
アクションアイテムの抽出
担当者と期限の対応付け
表データのJSON変換
RAGによる条件検索

例えば、LLMに「未完了のアクションと担当者を一覧化してください」と問い合わせる場合も、HTMLテーブルの方が正確に解釈しやすくなります。

4. PDF全体の一次解析に向いている

MinerUの最大の特長は、文書内のすべてを視覚OCRするのではなく、まず文書構造を解析する点です。

PDF
  |
  +-- タイトル
  +-- 見出し
  +-- 本文
  +-- 表
  +-- 画像
  +-- ページ構造

テキスト、見出し、表を構造化し、図や写真は独立した画像として抽出します。

そのため、すべてのページを高コストな視覚モデルへ送る必要がありません。

実運用では、まずMinerUで文書全体を処理し、MinerUでテキスト化できなかった部分だけを別のOCRへ渡す構成が効率的です。

PDF
  |
  v
MinerUで一次解析
  |
  +-- 本文・見出し
  |      → Markdownを利用
  |
  +-- 表
  |      → HTMLテーブルを利用
  |
  +-- 図・チャート
         → GLM-OCRへ送信

5. RAGの前処理と相性が良い

RAGでは、PDFから文字が取れればよいわけではありません。

次の情報を可能な限り残す必要があります。

• 見出しと本文の関係
• 表の行列関係
• ページ番号
• 画像の位置
• 文書内の章構造
• 元ファイルとの対応

MinerUのMarkdownとHTMLテーブルを使うと、これらを後段の処理へ渡しやすくなります。

MinerU
  |
  +-- Markdown
  |      → 見出し単位で分割
  |
  +-- HTML Table
  |      → 表単位で分割
  |
  +-- Images
  |      → 必要な画像だけ別OCR
  |
  +-- Metadata
         → 元PDF・ページ番号と関連付け

参考記事では、「まずMinerUで大半を処理し、図と取りこぼしだけをGLM-OCRで補完する」という優先ラダーが、コストと精度のバランスに優れる構成として整理されています。

MinerUが向いている資料

実測結果を踏まえると、MinerUは次の資料に向いています。

会議録
業務マニュアル
仕様書
規程
報告書
契約関連文書
論文
表を含む業務資料
テキスト主体のPDF

特に、次の条件に当てはまる資料では、MinerUを最初に試す価値があります。

複数ページのPDF

複数ページを一つの文書として処理したい場合です。

4ページの会議録
50ページのマニュアル
100ページの仕様書

ページ単位のOCRだけでは、改ページ前後の文脈や章構造が分断されることがあります。

MinerUパイプラインでは、文書全体を解析したうえでMarkdownへ変換できます。

見出し構造のある文書

次のような文書です。

1. はじめに
2. システム構成
  2.1 ネットワーク
  2.2 データベース
3. 運用手順

Markdown見出しを保持できれば、後段の検索インデックスでも章構造を利用できます。

表を含む文書

次のような資料です。

課題管理表
アクションアイテム一覧
テスト結果一覧
構成パラメータ表
比較表

表をHTMLで維持できるため、単純なテキスト化よりも正確な検索や抽出が期待できます。

MinerUが向いていない資料

MinerUは、図やチャートの内部を読むことを主目的とした視覚OCRではありません。

参考記事の検証では、次の資料に対して、MinerUは図を画像として抽出しましたが、内部の数値やラベルまではテキスト化しませんでした。

• 相関ヒートマップ
• 棒グラフ
• 複数のヒストグラム
• SmartArt形式の提案スライド
• 図形内に文字が埋め込まれたPDF

出力は次のような画像参照になります。

![](images/example.jpg)

これは単純な失敗ではなく、MinerUが図を独立した文書要素として扱った結果です。

ただし、RAGで図の内部にある数値や文字を検索対象にしたい場合は、画像参照だけでは不十分です。

例えば、棒グラフについて次の質問へ回答する必要がある場合です。

多数派クラスは何件か
最も値が高い項目は何か
前年比で増加した項目は何か

この場合は、抽出された画像をGLM-OCRなどの視覚OCRへ送ります。

おすすめの使い分け

OCRモデルは、役割によって大きく2系統に分けられます。

文書レイアウト解析
  → MinerU

画像全面の視覚OCR
  → GLM-OCR

参考記事の実測では、MinerUは文書PDFで高速かつ高構造な出力を生成し、GLM-OCRは図、チャート、SmartArt内の文字や数値を取得できました。

MinerUを使うもの

テキスト主体のPDF
会議録
マニュアル
報告書
表を含む文書
Markdown化したい資料

GLM-OCRを使うもの

棒グラフ
ヒートマップ
ヒストグラム
構成図
SmartArt
画面キャプチャ
テキスト層のない提案スライド

実運用での推奨構成

入力ファイル
  |
  +-- PDF
  |     |
  |     v
  |   MinerU
  |     |
  |     +-- 本文・見出し
  |     |      → Markdownを採用
  |     |
  |     +-- 表
  |     |      → HTMLを採用
  |     |
  |     +-- 画像
  |            → 必要なものだけGLM-OCR
  |
  +-- 独立画像
        |
        +-- 文書・帳票
        |      → MinerU
        |
        +-- 図・チャート
               → GLM-OCR

万能な1モデルへ寄せるよりも、MinerUを主力とし、図だけをGLM-OCRで補完する方が取りこぼしを減らせます。

対応構成

Terraformスタックの主な仕様は次のとおりです。

項目	内容
リージョン	東京、大阪
OS	Canonical Ubuntu 24.04
GPU	VM.GPU.A10.1 / VM.GPU.A10.2
ブート・ボリューム	デフォルト200GB
APIポート	デフォルト80
API認証	sk-で始まるAPIキー
Hugging Face認証	任意のHF_TOKEN
dtype	bfloat16
最大コンテキスト長	8,192
GPUメモリー使用率	デフォルト0.90
vLLMイメージ	vllm/vllm-openai:v0.25.1

vLLMイメージには固定タグを使用し、latestタグはTerraformの入力検証で拒否されます。

A10.1とA10.2の違い

シェイプ	GPU構成	Tensor Parallel	最大同時シーケンス
VM.GPU.A10.1	A10 24GB × 1	1	4
VM.GPU.A10.2	A10 24GB × 2	2	8

A10.2は、48GBの単一GPUとして動作するわけではありません。

24GBのA10を2枚使い、Tensor Parallel Sizeを2として1つのモデルを分散実行します。

GPU 0 --+
        +-- 1つのMinerUモデル
GPU 1 --+

検証や少人数での利用では、まずA10.1を選択します。

VM.GPU.A10.1
最大同時シーケンス: 4

複数リクエストを並列に処理したい場合は、A10.2を検討します。

VM.GPU.A10.2
最大同時シーケンス: 8

事前準備

デプロイ前に、次のOCIリソースを用意します。

• コンパートメント
• VCN
• パブリック・サブネット
• インターネット・ゲートウェイ
• A10 GPUのサービス制限
• SSH公開鍵
• API接続元のCIDR
• sk-で始まるAPIキー

このスタックは、既存のVCNとパブリック・サブネットを使用します。

A10 GPUの空き容量は、リージョンと可用性ドメインによって異なります。

Apply時に容量不足が発生した場合は、別の可用性ドメイン、リージョン、またはA10シェイプを試します。

OCI Resource Managerからデプロイする

1. Deploy to Oracle Cloudを開く

GitHubリポジトリのREADMEにあるDeploy to Oracle Cloudボタンを押します。

リリースv0.1.0では、東京、大阪、VM.GPU.A10.1、VM.GPU.A10.2がサポートされています。

2. OCI環境を選択する

Resource Managerの入力画面で、次の項目を指定します。

リージョン
コンパートメント
可用性ドメイン
VCN
パブリック・サブネット
SSH公開鍵

東京リージョンは次のとおりです。

ap-tokyo-1

大阪リージョンは次のとおりです。

ap-osaka-1

3. GPUシェイプを選択する

検証環境では、次の構成から始めます。

Shape:
VM.GPU.A10.1

Boot Volume:
200 GB

API Port:
80

同時処理数を増やす場合は、VM.GPU.A10.2を選択します。

4. モデルを設定する

デフォルト設定は次のとおりです。

hf_model_id:
opendatalab/MinerU2.5-Pro-2605-1.2B

served_model_name:
mineru2-5-pro-2605-1-2b

別のvLLM対応Hugging Faceモデルも指定できます。

hf_model_id:
namespace/model-name

served_model_name:
model-name

ただし、モデル名の形式が正しくても、A10上で動作するとは限りません。

次の条件を事前に確認します。

• vLLMバージョンへの対応
• NVIDIA A10への対応
• 必要なGPUメモリー
• BF16への対応
• Tensor Parallelへの対応
• モデル固有コードの信頼性

このスタックでは、公式MinerUモデルを実行するために--trust-remote-codeが有効です。

別モデルへ変更する場合は、信頼できる提供元だけを指定します。

5. APIキーを入力する

vLLM APIで使用するキーを入力します。

sk-example-mineru-api-key

API呼び出しではBearer Tokenとして指定します。

Authorization: Bearer sk-example-mineru-api-key

Hugging Face Tokenは任意です。

hf_xxxxxxxxxxxxxxxxx

6. API接続元を制限する

APIへの接続を許可するCIDRを入力します。

管理端末1台から利用する場合は、次のように/32で制限します。

203.0.113.10/32

本番環境では、0.0.0.0/0を指定しないようにします。

7. PlanとApplyを実行する

入力が完了したら、Planを確認してApplyします。

A10インスタンス作成
  |
  v
Ubuntu 24.04起動
  |
  v
NVIDIAドライバー確認
  |
  +-- 未導入ならインストール
  |        |
  |        v
  |      自動再起動
  |
  v
Docker導入
  |
  v
NVIDIA Container Toolkit導入
  |
  v
vLLMコンテナ取得
  |
  v
MinerUモデル取得
  |
  v
API起動確認

NVIDIAドライバーが導入されていない場合、初期化中にインスタンスが1回再起動します。

再起動後は、systemdサービスが初期化処理を継続します。

初期化状況を確認する

Apply完了後も、Dockerイメージやモデルのダウンロードが続いている場合があります。

SSH接続後、次のコマンドで初期化サービスを確認します。

sudo systemctl status \
  mineru-vllm-bootstrap.service \
  --no-pager

ログをリアルタイムで確認します。

sudo journalctl \
  -u mineru-vllm-bootstrap.service \
  -f

GPUを確認します。

nvidia-smi

コンテナを確認します。

sudo docker ps -a

vLLMログを確認します。

sudo docker logs -f \
  vllm-mineru2-5-pro-2605-1-2b

初期化完了マーカーは次の場所に作成されます。

/var/lib/mineru-vllm-deployer/bootstrap-complete

GPU関連パッケージの固定対象は次のファイルに保存されます。

/var/lib/mineru-vllm-deployer/gpu-stack-packages.txt

APIの動作を確認する

Resource Managerの出力からAPI URLを確認します。

export VLLM_API_KEY='sk-example-mineru-api-key'
export VLLM_BASE_URL='http://<PUBLIC_IP>:80/v1'

モデル一覧を取得します。

curl -sS "${VLLM_BASE_URL}/models" \
  -H "Authorization: Bearer ${VLLM_API_KEY}"

次のモデル名が返れば、APIは起動しています。

{
  "id": "mineru2-5-pro-2605-1-2b",
  "object": "model"
}

文書画像を解析する

画像URLを/v1/chat/completionsへ渡します。

curl -sS "${VLLM_BASE_URL}/chat/completions" \
  -H "Authorization: Bearer ${VLLM_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mineru2-5-pro-2605-1-2b",
    "messages": [
      {
        "role": "user",
        "content": [
          {
            "type": "text",
            "text": "Parse this document image."
          },
          {
            "type": "image_url",
            "image_url": {
              "url": "https://example.com/document.png"
            }
          }
        ]
      }
    ],
    "temperature": 0,
    "max_tokens": 1024
  }'

この呼び出し方法は、リポジトリのREADMEで案内されているOpenAI互換APIの使用例に基づきます。

ローカル画像を使用する場合は、Base64 Data URLへ変換します。

IMAGE_BASE64=$(base64 -w 0 document.png)

リクエスト内では次の形式で指定します。

{
  "type": "image_url",
  "image_url": {
    "url": "data:image/png;base64,<BASE64_DATA>"
  }
}

PDFを解析する方法

このTerraformスタックが公開するvLLM APIへ、PDFファイルを直接アップロードすることはできません。

PDFを処理する方法は2つあります。

方法1：PDFをページ画像へ変換する

PDF
  |
  v
ページ画像へ変換
  |
  +-- page-1.png
  +-- page-2.png
  +-- page-3.png
  |
  v
vLLM APIへ送信

pdftoppmを使用する例です。

pdftoppm \
  -png \
  -r 150 \
  input.pdf \
  page

生成されるファイルは次のようになります。

page-1.png
page-2.png
page-3.png

この方法は簡単ですが、ページ間の統合、Markdown生成、抽出画像の管理はクライアント側で実装する必要があります。

方法2：MinerU公式クライアントを使用する

MinerU本来の文書抽出パイプラインを利用する場合は、別環境にmineru-vl-utilsを用意します。

http-clientバックエンドの接続先として、OCI上のvLLM APIを指定します。

PDF
  |
  v
MinerU Client
  |
  | http-client backend
  v
OCI A10上のvLLM API
  |
  v
MinerU VLM
  |
  v
Markdown / JSON / Images

クライアント側では、次の処理を担当します。

• PDFの読み込み
• ページ画像の生成
• モデルへのリクエスト
• レイアウト解析結果の整理
• Markdown生成
• HTMLテーブル生成
• 文書内画像の保存
• ページ間の統合

RAGパイプラインへ組み込む場合は、この方式が適しています。

RAG向けの処理フロー

実運用では、MinerUを一次解析器として利用します。

入力ファイル
  |
  v
MinerU
  |
  +-- Markdown
  |      |
  |      v
  |   見出し単位でチャンク分割
  |
  +-- HTMLテーブル
  |      |
  |      v
  |   表単位でインデックス化
  |
  +-- 抽出画像
         |
         v
      GLM-OCRで補完

MinerUの出力に次のような画像参照が含まれる場合、その画像だけをGLM-OCRへ送ります。

![](images/example.jpg)

さらに、MinerUの結果が短すぎるページを検出して、フォールバックする方法もあります。

if len(extracted_text.strip()) < minimum_length:
    run_visual_ocr(page_image)

実際には、文字数だけでなく、次の条件を組み合わせます。

本文が空
本文が極端に短い
画像参照だけが含まれる
表が期待されるのに表がない
ページの大部分が画像

これにより、全ページを複数モデルへ送るよりも、GPUコストを抑えられます。

セキュリティ上の注意

API接続元を制限する

本番環境では、API接続元を利用サーバーや管理端末のCIDRだけに制限します。

203.0.113.10/32

SSHルールは別途設定する

このスタックは、SSH用TCP 22番ポートの許可ルールを作成しません。

既存のSecurity Listまたは別のNSGで、運用者のCIDRだけを許可します。

HTTPのまま公開される

デフォルトでは次のURLで公開されます。

http://<PUBLIC_IP>:80/v1

機密文書を扱う場合は、次のいずれかを追加します。

• OCI Load Balancer
• OCI API Gateway
• リバースプロキシ
• TLS証明書
• プライベート・サブネット
• VPNまたは閉域接続

APIキーだけに依存しない

APIキーに加えて、ネットワーク側でも接続元を制限します。

インターネット
  |
  v
NSG / Security List
  |
  v
TLS / API Gateway
  |
  v
vLLM API Key
  |
  v
MinerU

まとめ

no.1-oci-a10-mineru-deployerを使うと、MinerU VLMをOCI A10 GPUへデプロイし、認証付きのOpenAI互換APIとして利用できます。

OCI Resource Manager
  |
  v
Ubuntu 24.04 + NVIDIA A10
  |
  v
Docker + NVIDIA Container Toolkit
  |
  v
vLLM
  |
  v
MinerU2.5-Pro

実測結果から確認できたMinerUの主な特長は、次のとおりです。

テキストPDFの処理が速い
見出し付きMarkdownを生成できる
表をHTMLとして保持できる
複数ページ文書の一次解析に向く
RAGのチャンク分割と相性が良い

一方で、図やチャート内部の数値、SmartArt内の文字を読むことは得意ではありません。

そのため、実運用では次の構成がおすすめです。

文書・PDF・表
  → MinerU

図・チャート・スクリーンショット
  → GLM-OCR

まずMinerUで文書全体を高速に構造化し、画像として残った図やテキストを取得できなかったページだけをGLM-OCRで補完します。

この2系統のルーティングが、文書構造、処理速度、図中テキストの取得精度のバランスを取りやすい構成です。