This [Bug]:Image-heavy pages take 100s+ to ingest — ~24 LLM calls per image block

Do you need to file an issue?

• I have searched the existing issues and this bug is not already filed.
• I believe this is a legitimate bug, not just a question or feature request.

Describe the bug

Ingesting a single web page with 8-22 images through insert_content_list() takes 60-120+ seconds. The same page with images removed takes ~5 seconds.

The cause is call COUNT, not call size: each image block costs roughly 24 LLM calls. A page with 8 images issued 330 LLM calls. At a measured median of 6.2s per call and llm_model_max_async=16, that is ~124 seconds of wall clock for one page.

Measured across four site crawls (three Shopify storefronts, one Next.js marketing site), RAGAnything + lightrag-hku 1.4.16, gpt-4o-mini for both extraction and vision:

page shape	LLM calls	wall clock
text only	~11	~5s
8 image blocks	330	~124s
11 image blocks	259	~97s
22 image blocks	418	~157s

Page LENGTH barely matters — a 1,400-char text page and a 17,861-char text page cost about the same. Image COUNT is the only variable that moves ingestion time.

This makes crawling a real site impractical. A 500-page storefront at ~100s per page is over 13 hours of graph ingestion, against ~2 hours for the plain vector lane over the same content.

Individual call latencies observed (each a 3,800-5,500 token extraction call):

3.50 4.11 4.19 4.39 4.74 5.68 6.21 7.04 7.12 7.47 7.93 8.61 11.91 (s)

I would expect roughly 1 vision call per image plus a small number of extraction calls over the page as a whole. 24 calls per image suggests each caption is being fed back through entity extraction and merge summarisation as though it were its own document — which multiplies latency by image count rather than adding to it.

I cannot tell from outside how much of this is RAG-Anything's modal processing versus LightRAG's downstream extraction and merge behaviour; I only see the aggregate. If the amplification is expected, documenting it would still help, because the wall clock implications for image-heavy sites are severe and not discoverable until you run a crawl.

Steps to reproduce

1. Configure RAGAnything with: enable_image_processing=True parser=mineru, parse_method=auto and LightRAG with: llm_model_func -> gpt-4o-mini vision_model_func -> gpt-4o-mini, detail="low" embedding_func -> text-embedding-3-small entity_extract_max_gleaning=0 llm_model_max_async=16 max_parallel_insert=12 chunk_token_size=1200

2. Build a content_list for a typical e-commerce product page — roughly 2,000-8,000 chars of text and 8-20 image blocks.

3. Time insert_content_list() for that page, and count LLM calls by wrapping llm_model_func / vision_model_func with a counter.

4. Repeat with the identical page, image blocks removed.

Observed: ~330 calls / ~124s with images, ~11 calls / ~5s without. Expected: image count should add roughly one vision call each, not multiply total call count by ~24 per image.

Expected Behavior

Ingestion time should scale roughly linearly with image count at about one vision call per image — a page with 10 images taking perhaps 15-25 seconds rather than 100+.

An image caption should join the surrounding text as ordinary content for entity extraction, not trigger its own extraction and merge cycle.

If the current behaviour is intentional, documenting the per-image call amplification and its wall-clock cost would let users size crawls before committing to them.

Separately — and this is the most immediately actionable part — max_parallel_insert also gates modal item concurrency (processor.py:908 uses Semaphore(getattr(lightrag, "max_parallel_insert", 2))), so at the default of 2 a page with 14 images runs vision calls two at a time regardless of llm_model_max_async. At the measured 6s per call that is ~990s for a 330-call page versus ~124s at 12. The parameter name gives no hint that it controls image concurrency, and we lost a lot of time before finding it. A separate modal concurrency setting, or a line in the docs, would help.

LightRAG Config Used

Paste your config hereraganything: (run pip show raganything and fill this in)

lightrag-hku: 1.4.16 python: 3.12 OS: Debian (Docker, linux/amd64) LLM: gpt-4o-mini (extraction and vision) embeddings: text-embedding-3-small parser: mineru, parse_method=auto vision detail: low storage: Neo4j (graph) network: client hosted in Pakistan — see note below

Logs and screenshots

No response

Additional Information

• LightRAG Version:
• Operating System:
• Python Version:
• Related Issues: