v1.2.5

Fix: proper async initialization with spawn multiprocessing guard

Root cause: Lazy initialization triggered inside RunPod's running event loop, causing "This event loop is already running" error.

Solution:

• handler.py: Eager initialization at module load (before runpod.serverless.start) with multiprocessing spawn guard
• engine.py: Lazy async initialization via _ensure_initialized() called on first generate() request

This matches the official RunPod worker-vllm pattern while supporting vLLM V1's spawn multiprocessing.

v1.2.4

Fix: remove nest_asyncio to prevent RunPod event loop corruption (IndexError: pop from an empty deque)

v1.2.3

Fix: remove model_config parameter from OpenAIServingModels, OpenAIServingChat, OpenAIServingCompletion (removed in vLLM 0.15.0)

v1.2.2

Fix: model_config is now a property, not a method in vLLM 0.15.0

v1.2.1

Fix: ErrorResponse now wraps ErrorInfo in vLLM 0.15.0

v1.2.0

Upgrade to vLLM 0.15.0 with refactored import paths for new module structure

v1.1.0

Upgrade vLLM 0.11.0 → 0.15.0 (fixes GPU memory check issue), remove MistralTokenizer patch (refactored in 0.15.0)

v1.0.9

Fix: move nest_asyncio.apply() inside function to avoid vLLM V1 multiprocessing spawn issues

v1.0.8

Fix: use nest_asyncio for RunPod event loop compatibility

v1.0.7

Fix: use existing event loop for RunPod compatibility