feat: Set concurrency and the CUDA graph list from .env

MAX_SEQS and the prefill chunk were fixed in the start profile, so any
change to concurrency needed an edit to the script. Read both from .env,
and validate them before the engine starts. The chunk must be at least
the sequence count, the rule vLLM applies at scheduler.py:309. A
MAX_SEQS whose full context exceeds the 924,993-token pool prints a
note, because that shape preempts and recomputes instead of failing.

The captured graph list was a fixed [1,2,4,8,12,16], which covers a
decode batch of 4 requests and nothing wider. One decode step is K+1 = 4
tokens per request, so the list now follows MAX_SEQS: 1, 2, 4, then
every 4 tokens up to MAX_SEQS x 4. At the shipped 4 it produces the old
list exactly. Above 8 graphs a note prints, since each size costs
capture time and graph VRAM.

Drop --mm-processor-cache-gb. This workload sends each image once, so
the cache never had a hit to keep, and vLLM's own 4 GiB default is the
better base.

Co-Authored-By: Hinata <hinata@idihore.id>
Signed-off-by: MOVZX <movzx@yahoo.com>

.env.example

@@ -33,6 +33,12 @@ TOPO_TIMEOUT=20
 GUARD=warn
 # 1 adds the two logging-only counters (exact-restart counters /30 s, FP8 KV clips /300 s).
 COUNTERS=0
+# Concurrent requests. CUDA graphs are captured up to MAX_SEQS x 4 tokens (MTP K=3), so a raise
+# adds capture time and graph VRAM. N x 262144 tokens above the 924,993-token KV pool preempts.
+MAX_SEQS=4
+# Prefill chunk in tokens. Must be >= MAX_SEQS. 2048 matches --block-size; 4096 prefills one
+# max-size image in one chunk.
+MAX_BATCHED_TOKENS=2048
 # Seconds between engine stats lines (throughput, KV usage, queue depth). The vLLM default is 10 s.
 VLLM_LOG_STATS_INTERVAL=1