HPD-Parsing、文書生成を並列分岐に分解、1Bモデルでピークスループット毎秒4,752 tokenを達成

PaddlePaddleはこのほど、HPD-Parsingの重み、モデルカード、デプロイ文書を公開し、視覚言語モデルによる文書解析のデコード方式を刷新しようとしている。従来のエンドツーエンド文書モデルは、まずページ全体の画像を理解し、その後、単一の自己回帰シーケンスに沿ってテキスト、表、数式を出力する。ページが長くなるほど、後続のtokenは先行部分の完了を待たなければならない。一方、HPD-Parsingでは、メイン分岐がグローバルレイアウトと読み順のみを担当する。ブロックに到達すると特殊なディスパッチ信号を出力し、実行環境が複数のサブリクエストを動的に作成して各領域の内容を同時に生成する。最後に、メイン分岐の構造に従って結果を組み立てる。

さらに、このモデルにはProgressive Multi-Token Predictionが導入されており、1回に予測するtoken数を段階的に増やすことで、デコード回数を一段と削減する。論文では、公開文書データにおけるピーク性能として4,752 token/sを報告している。これは比較対象で最速のモデルの2.62倍、一般的な自己回帰ベースラインの3.06倍に相当する。Hugging Faceのモデルカードに記載されたOmniDocBench v1.6の総合スコアは94.91%。モデル本体は約1Bパラメータで、InternVL3.5-1Bシリーズをベースとし、重みはApache-2.0ライセンスで提供される。

技術的な価値はOCRスコアだけにあるのではなく、文書が本来持つブロック構造を推論スケジューリングへ直接マッピングした点にある。大量の請求書や論文の処理、RAGインデックス作成では、ブロック並列化によってGPU使用率が向上し、長いページのテールレイテンシーが短縮される可能性がある。ただし、現時点のデプロイにはカスタム版の`vllm-0.17.1+hpdparsing`をインストールする必要があり、まだ標準のvLLM機能ではないことを意味する。また、動的分岐はスケジューリング、メモリ、結果再構成のコストも増加させる。エンジニアリングチームは今後、tokenのピーク値だけを採用するのではなく、実際のPDFにおけるページ当たりのレイテンシー、バッチスループット、VRAMピーク使用量、複雑な読み順に関するエラーを比較すべきだ。