Step 11 of 15Method

Attribute the 22 seconds before the engine starts

89% of the time before the engine starts is Python imports, paid twice because the engine process is spawned. Forking it saved 5.7 s on the twin.

Imports
89% of pre-engine
Forking saves
5.7 s
on the twin
Step 07 · Driver kernel cache kept
All graphs, driver cache
51 s
No graphs, driver cache
40 s
All graphs, autotune off
130 s
No graphs, autotune off
80 s
Step 11 · Before the engine starts
LoRA support off
40 s
Engine forked
30 s

Hover or tap a segment for its time. The twin's readiness probe runs every 10 s, so totals land on 10-second steps and the last segment absorbs the wait.

Once the driver cache is kept, Python before the engine is the largest phase left. Forking the engine process shortens it by 5.7 seconds. Totals move in 10-second probe steps, so the drop from 40 to 30 overstates it: judge it on the phase.

Problem

With the engine fast, the 22 seconds of Python before it was the largest phase left.

Change

An import-time profile captured inside the real image, and a debug-log timeline.

Result

The API server spends 13.75 seconds importing, led by torch (3.8 seconds) and transformers (2.4). The engine process spends another 5.3, because vLLM's command line starts it with spawn and it imports everything again. Turning LoRA support off changed nothing over two runs, and production, which exports traces, spent the same time before the engine as the twin, which doesn't. Running the engine in-process isn't supported by the async server. Forking the engine process cut 5.7 seconds with decode unchanged.

The 22 seconds before the engine starts · Where it goes

API server imports
13.75 s
Engine re-imports after spawn
5.3 s
Interpreter start and config
~2.4 s
Where the time before the engine goes, and what forking saves.

Decision

Forking saved 5.7 seconds of a 40-second start, about 14%, under the 20% rule, so it was reported rather than adopted. Step 15 picks it up.