The 0.55 configuration booted cleanly, passed every startup check, and then
killed the engine on an ordinary request of roughly 20k tokens:
torch.OutOfMemoryError allocating 614 MiB in the GDN causal_conv1d path with
443 MiB free. The container self-recovered via restart: unless-stopped.
Context length was not the cause. gpu-memory-utilization is not a hard
reservation. Weights and KV are reserved up front, but activation memory is
allocated on demand and the profile that sizes it uses dummy data at
max_num_batched_tokens. The profile predicted 3.62 GiB; the process sat about
1 GiB over its entire budget even at idle. With six vLLM containers sharing
GPU1 there was no slack left to grow into, and a modest allocation lost the
race. 0.52 leaves roughly 7.7 GiB free against 4.6 GiB at 0.55.
Records a measurement that governs how max-model-len can be chosen at all:
the KV pool varies between boots. Two consecutive boots at 0.52 produced
425,663 and 453,600 tokens, a 6.6 percent swing, because the pool is sized
from free memory at startup and that depends on what the other tenants hold
at that instant. 420,000 sits under the lower observation so the seat starts
in both conditions. Sizing to the higher one would boot today and refuse
tomorrow, which is why the value was measured across boots rather than
estimated from one.
Concurrency of about 1.0 to 1.08x means one request at full length. Shorter
requests still batch normally, since vLLM schedules by tokens rather than by
max-model-len.
vh
6e82899ba7