我的理解是，vLLM的JIT kernel缓存和shape捕获机制确实能减少后续相同或更小shape的JIT延迟，但它并不是“只要有过大shape，所有更小shape都能100%直接复用”。实际上，JIT kernel的复用依赖于shape的具体匹配和实现细节。
根据vLLM官方文档和相关issue，vLLM会为不同的shape（如batch size、seq len等）分别编译和缓存kernel。只有当后续请求的shape与已缓存的kernel完全匹配时，才能直接复用，否则仍需JIT编译。例如，prefill和decode阶段的shape差异、batch size变化、特殊算子等都可能导致新一轮JIT。你遇到“先大后小仍有高TTFT”，很可能是shape未完全匹配或涉及不同的算子路径，导致重新编译。
因此，TTFT的JIT抖动不仅与shape大小有关，还与shape具体参数、调度策略、算子实现等多因素相关。要获得稳定TTFT，建议在服务启动后用典型shape做warmup，覆盖常见输入长度和batch size。官方建议
需要更详细的shape捕获/JIT缓存机制说明或warmup脚本示例吗？
Sources: