OCR timed out

[jianghr-shanghaitech]

System Info / 系統信息

image/open_shai_v15_exam_paper_115.jpg ===
Layout coords scale: prep 800x800 -> orig 6800x9067 (scale_x=8.500 scale_y=11.334)
OCR API request error (attempt 1/3): HTTPConnectionPool(host='127.0.0.1', port=8080): Read timed out. (read timeout=120). Retrying...
OCR API request error (attempt 2/3): HTTPConnectionPool(host='127.0.0.1', port=8080): Read timed out. (read timeout=120). Retrying...
Error during recognition: HTTPConnectionPool(host='127.0.0.1', port=8080): Read timed out. (read timeout=120)

Who can help? / 谁可以帮助到您？

No response

Information / 问题信息

• The official example scripts / 官方的示例脚本
• My own modified scripts / 我自己修改的脚本和任务

Reproduction / 复现过程

with GlmOcr() as ocr:
for img in images:
print(f"\n=== Parsing: {img} ===")
try:
subdir, json_name = parse_name(img.name)
out_dir = output_root / subdir
out_dir.mkdir(parents=True, exist_ok=True)

            results = ocr.parse(str(img))

Expected behavior / 期待表现

return in time

[JaredforReal]

Are u doing this with your own model deployment? Or using maas?
Modify the config as README says, please

[jianghr-shanghaitech]

Are u doing this with your own model deployment? Or using maas? Modify the config as README says, please

I’m testing this with my own model deployment, and I noticed that the model actually produces output even when the request times out.

[JaredforReal]

yep, that is result formatter doing its job.
change the config like this:

 ocr_api:
    # Basic connection
    api_host: 172.18.71.164 # change this to your model ip address
    api_port: 3000 # change this to the right port

[jianghr-shanghaitech]

My config is like this:

  # OCR API client configuration (for self-hosted vLLM/SGLang)
  ocr_api:
    # Basic connection
    api_host: 127.0.0.1
    api_port: 8080

[JaredforReal]

do u sure sdk and model deployment are running in the same machine? 127.0.0.1 means localhost, and double check the port, please

[ThanhNguyxn]

Thanks for the report. The SDK’s default pipeline.ocr_api.request_timeout in glmocr/config.yaml is currently 120s, which matches the log you posted. I opened a PR to raise the default to 300s (aligns with README/code defaults) to reduce timeouts on large images:

PR: #53

Workaround now:

pipeline:
  ocr_api:
    request_timeout: 300  # or higher for large PDFs/images

If you can confirm this resolves the timeout in your environment, that would help maintainers merge quickly.

[ThanhNguyxn]

I’ve opened a code fix that ensures connect_timeout is honored in the actual OCR HTTP requests (it was previously ignored and only used for preflight). This can reduce unexpected hangs on slow connections.

PR: #63

Note: this doesn’t change request_timeout (read timeout). You can still raise pipeline.ocr_api.request_timeout in config.yaml for large images, but now connect_timeout is applied consistently to requests.

[jianghr-shanghaitech]

I observed that the timeout issue may stem from the processing being stalled on certain individual elements. In particular, during my experiments, I noticed that when a relatively large table appears in the layout, a timeout consistently occurs, even though the timeout threshold was set to 300 seconds. In such cases, although the returned JSON is not empty, the entire content of the table is missing. This behavior does not occur when using the online API or the official demo.