Patent's ST.25 listings become tables and digit-changing generation loops in vLLM

Summary

When using baidu/Unlimited-OCR with vLLM to parse patent PDF pages, I encounter two reproducible failure modes:

1. ST.25 biological sequence listings are incorrectly interpreted as HTML tables.
2. Ordinary two-column patent text can enter a digit-changing generation loop until max_tokens is reached.

The second issue appears related to the repetition behavior discussed in #55, but the repeated phrase contains changing numbers, which may allow it to evade exact n-gram blocking.

Environment

• Model: baidu/Unlimited-OCR
• Model revision: 27a5997fa0524f9adcf9e2f3d5e7d3f784434fa5
• vLLM: 0.25.1
• Python: 3.12.13
• PyTorch: 2.11.0+cu130
• CUDA toolkit: 13.2
• PyTorch CUDA runtime: 13.0
• GPU: NVIDIA RTX PRO 5000
• Compute capability: 12.0
• NVIDIA driver: 595.84
• Input format: PDF pages rendered as PNG at 300 DPI

vLLM server configuration

vllm serve /path/to/Unlimited-OCR \
  --served-model-name Unlimited-OCR \
  --trust-remote-code \
  --logits_processors \
    vllm.model_executor.models.unlimited_ocr:NGramPerReqLogitsProcessor \
  --no-enable-prefix-caching \
  --mm-processor-cache-gb 0 \
  --dtype bfloat16 \
  --max-model-len 32768 \
  --max-num-seqs 8

Request configuration

{
  "model": "Unlimited-OCR",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "<image>document parsing."
        },
        {
          "type": "image_url",
          "image_url": {
            "url": "data:image/png;base64,..."
          }
        }
      ]
    }
  ],
  "temperature": 0.0,
  "max_tokens": 8192,
  "skip_special_tokens": false,
  "vllm_xargs": {
    "ngram_size": 35,
    "window_size": 128
  }
}

Responses truncated at 8,192 tokens were retried with max_tokens set to 16384.

Case 1: ST.25 sequence listing is interpreted as a table

Example document:

• [US10000559B2](https://patents.google.com/patent/US10000559B2/en)

The page contains a standard ST.25 sequence listing such as:

<210> SEQ ID NO 38
<211> LENGTH: 107
<212> TYPE: PRT
<213> ORGANISM: Mus musculus
<400> SEQUENCE: 38

This is a fixed-width biological sequence listing, not a semantic table.

However, Unlimited-OCR converts it into a very large HTML table containing sequence metadata, residue positions, and individual residues in hundreds or thousands of <td> elements.

Consequences include:

• Output reaches the token limit.
• The sequence may be reordered or duplicated.
• The output is much larger than the source.
• The original ST.25 structure is no longer preserved losslessly.

Expected behavior

The sequence listing should preferably be emitted as ordered plain text or a fenced text block that preserves the original ST.25 markers and sequence order.

It should not be converted into an HTML table unless explicitly requested.

Case 2: Digit-changing generation loop

Example document:

• [US10000560B2](https://patents.google.com/patent/US10000560B2/en)
• Affected page: patent columns 59–60

The source page is normal two-column patent prose. OCR output begins plausibly but diverges around an invented passage similar to:

In further embodiments, the variant Fc region binders, the variant Fc region
has decreased binding activity...

It then generates a very long numeric pattern:

50 or greater, 70 or greater, 80 or greater, 90 or greater,
100 or greater, 110 or greater, ...
1000 or greater, 1100 or greater, ...
100000 or greater, ...

The changing number appears to let the sequence evade detection as an exact repeating 35-gram within the 128-token window.

Measurements from this example

• Total generated text: 51,815 characters
• Final runaway paragraph: 49,243 characters
• Occurrences of or greater: 2,608
• Corruption begins at approximately byte 3,082
• The remaining source text is not transcribed
• Response finishes with finish_reason: "length"

Expected behavior

The model should stop or report a structured failure when output begins diverging into a low-entropy numeric pattern.

A partial but valid transcription would be preferable to tens of thousands of hallucinated characters.

Possibly related issues

• #55 — text repetition/looping and limitations of no_repeat_ngram_size=35
• #24 — table inference hanging
• #58 — OCR hallucination with incrementing content

Case 2 may be a variant of #55, but it is not an exact static repetition: a numeric token changes on each iteration.