LLM inference sunucularında başlatma süresini kısaltan yaklaşımlar

LLM inference sunucularının başlatma süresini kısaltmak için vLLM, SGLang, llm-d ve Kubernetes katmanlarında birbirinden bağımsız çalışmalar ilerliyor. VLLM’de weight daemon ve vllm preload komutu merge edildi, initialized-engine snapshot desteği ise deneysel durumda. CheckpointPod ve RestorePod çağrıları 22 Temmuz 2026’da Kubernetes’in CRI’sine eklendi. Pod düzeyinde checkpoint için hedef v1.38 alfa.

vLLM nedir?

vLLM, büyük dil modellerini servis etmek için geliştirilen açık kaynak bir inference ve serving motorudur. GPU belleğini verimli kullanarak yüksek throughput ile istek karşılamayı hedefler. Model servis eden ekipler onu genellikle OpenAI uyumlu bir API sunucusu olarak çalıştırır. Yaygın alternatifleri arasında SGLang ve Hugging Face Text Generation Inference bulunur.

LLM inference replica’sı neden geç hazır oluyor

Yeni bir replica, ilk isteğe cevap verene kadar kapasite sayılmaz. Bu arada weight’ler yükleniyor, kernel’ler derleniyor, CUDA Graph capture yapılıyor ve engine warm-up’tan geçiyor. Autoscaling ile LLM inference replica’larını scale-out ediyorsanız bu bekleme her yeni Pod’da baştan yaşanıyor.

Optimizasyonları ayırmanın en net yolu, her birinin neyi sakladığına bakmak: model dosyası, derlenmiş artifact, işlenmiş weight, canlı engine veya tüm process state. Her katman bir sonrakinin işini olduğu gibi bırakıyor. Snapshot bile model dosyalarına bağımlılığı kaldırmıyor.

Önce darboğazı ölçün

Sıralama ortama göre değişiyor. Model dosyaları local cache’e alındığında engine initialization öne çıkıyor. Weight’ler GPU’da yeniden kullanılınca bu kez import, autotune ve graph capture kalan sürenin büyük kısmını oluşturuyor. Snapshot’a atlamadan önce startup log’larında hangi adımın ne kadar sürdüğüne bakın.

Mantıklı bir sıra şöyle:

• Model dosyalarını node’a önceden çekin, uzak depolamadan her açılışta indirmeyin.
• VLLM compilation ve autotune cache’lerini kalıcı bir volume’a koyun, restart’ta yeniden üretilmesin.
• Aynı node’da sık restart veya model değişimi varsa weight daemon’a geçin.
• Snapshot’ı en sona bırakın.

VLLM preload ve weight daemon

VLLM’de weight daemon ve vllm preload komutu merge edildi. Daemon weight’leri işleyip GPU belleğinde tutuyor, uyumlu engine’ler bunlara CUDA IPC ile erişiyor. Zero-copy modda engine, daemon’un allocation’larını kopyalamadan map’liyor. Yapılandırma uyuşmazsa normal yüklemeye düşüyor.

Bunun bir maliyeti de var. Engine’ler daemon’un belleğini kullandığı sürece daemon ayakta kalmak zorunda. Bu yüzden daemon’u kendi lifecycle’ı olan bir bileşen olarak izlemeniz gerekiyor. CUDA IPC handle’ları node’a özgü, multi-node kurulumda her node kendi shard’ını local tutmalı. Zero-copy modu sleep mode üzerinden weight offloading ile birleştirmenin de belgelenmiş kısıtları var.

Kurulu sürümü ve komutun parametrelerini kendi ortamınızda kontrol edin:

pip show vllm
vllm preload --help

SGLang’de de CUDA IPC ile çalışan bir weight-cache daemon merge edildi. Model ve quantization kapsamını genişletme planları ise henüz roadmap aşamasında.

Snapshot’ın dar kapsamı

VLLM’in initialized-engine snapshot’ı deneysel ve CRIU ile CUDA checkpoint üzerine kurulu. Belgelenen kapsam aynı makine, tek NVIDIA GPU ve tensor parallelism 1. Weight ve KV state capture öncesi bırakılıyor, restore’da yeniden yükleniyor. SGLang’deki karşılığı hâlâ açık bir RFC.

Platform bileşenlerinin sürümünü sabitlemeden ilerlemeyin. Ai-dynamo altındaki Snapshot projesinin vLLM rehberi, v0.27.1 ile doğrulandığını ve v0.28’de çalışmadığını belirtiyor. Dynamo v1.4.0 belgelerinde GPU Memory Service ile Snapshot’ın birlikte kullanımı devre dışı ve üretim için desteklenmiyor. Snapshot depolaması şimdilik PVC üzerinden yürüyor, object storage backend’leri ileriye bırakılmış.

Llm-d’nin Pod Snapshots rehberi GKE Pod Snapshots, gVisor tabanlı GKE Sandbox ve Google Cloud Storage’a bağlı. GVisor kendi checkpoint mekanizmasını kullandığı için bu akışla CRIU tabanlı akışın formatları ve API’leri aynı değil. Bir platformda aldığınız snapshot’ı diğerine taşıyabileceğinizi varsaymayın.

Kubernetes native checkpoint henüz GPU’yu kapsamıyor

Kubernetes’te container checkpointing KEP 2008 ile v1.30’da beta oldu. Pod düzeyindeki KEP-5823 için hedef v1.38 alfa, fakat ilk kapsamda device state ve node’lar arası restore yok. GPU desteği ayrı ve provisional durumdaki KEP-6274’te konuşuluyor. CRI değişikliği merge edildi. Kubernetes ve containerd implementasyon PR’ları açık, CRI-O PR’ı ise taslak.

GPU’lu bir LLM inference iş yükü için platform seviyesinde hazır bir checkpoint ve restore yolu şu an yok. Şimdilik başlatma süresini engine içindeki mekanizmalar kısaltıyor: kalıcı cache, preload ve sleep/wake. Snapshot denemek istiyorsanız tek GPU’lu, tensor parallelism 1 olan bir modelle ve sabitlenmiş framework sürümüyle başlayın; restore sonrasındaki generation doğrulamasını rollout pipeline’ınızda tutun.