dev.to'daki Adım Adım İnceleme, vLLM'de Bir generate() İsteğini GPU'ya Kadar Takip Ediyor

dev.to'da yayınlanan bir adım adım inceleme, tek bir offline çıkarım isteğini vLLM'nin V1 motoru boyunca takip ediyor: herkese açık LLM.generate() çağrısından başlayarak, süreçler arası bir sınırı aşarak zamanlama, GPU model yürütmesi ve sayfalı KV-cache erişimine kadar uzanıyor. Yazar tarafından Zhihu'da özgün olarak yayınlanmış Çince bir makaleden uyarlanan bu inceleme, vLLM iç yapısına dair üç bölümlük bir serinin ilk yazısı; ilerleyen bölümlerde sayfalı attention ile CUDA kernel'ları ve PyTorch'tan Triton'a FlashAttention ele alınacak. dev.to makalesine göre tüm kaynak referansları, 3 Eylül 2026'da kontrol edildiği şekliyle vLLM 0.22.0 ile doğrulanmış; ancak yazar, proje ilerledikçe dosya adlarının ve çağrı sınırlarının değişeceği konusunda okurları uyarıyor.

Tek istek, iki süreç

Yazara göre tüm yolu şekillendiren yapısal detay, vLLM 0.22'nin çağrı yapan tarafa yönelik motoru EngineCore'dan bir süreç sınırıyla ayırması. EngineCore bir alt süreçte sürekli olarak çalışıyor ve çağıran taraf GPU yürütmesini token token sürmüyor. Gönderilen bir istek, LLM.generate() üzerinden LLMEngine.add_request() ve bir EngineCoreClient aracılığıyla bir IPC giriş kuyruğuna geçiyor ve orada scheduler'a kaydediliyor.

Sınırın diğer tarafında EngineCore'un run_busy_loop() metodu sürekli olarak EngineCore.step() işlemini gerçekleştiriyor; inceleme bunu üç aşamaya ayrıştırıyor. Birincisi, scheduler.schedule() token ve KV-cache bütçelerini harcayarak bir SchedulerOutput üretiyor. İkincisi, model_executor.execute_model() GPU'da ileri geçişi (forward pass) ve örnekleme işlemini yürütüyor. Üçüncüsü, scheduler.update_from_output() istek durumunu güncelliyor, tamamlanan isteklere ait KV bloklarını serbest bırakıyor ve sonuçları ana sürecin alması için bir IPC çıkış kuyruğuna iletiyor.

step() sonuçları tüketir, hesaplamaz

Makaledeki merkezi açıklamalardan biri LLMEngine.step() ile ilgili. İsmine rağmen bu metot ne istek gönderir ne de doğrudan model yürütmesini sürer. Uygulaması, EngineCore'un get_output() aracılığıyla zaten üretmiş olduğu çıktıyı alır, token'ları çözer ve durdurma koşullarını değerlendirir, stop string'lerle sonlandırılan istekleri iptal eder ve kullanıcıya dönük RequestOutput nesnelerini döndürmeden önce istatistikleri kaydeder. Gönderme işlemi daha önce add_request() içinde yapılmıştır ve asıl hesaplama alt süreç içinde bağımsız olarak ilerler. Yazar, bu tanımlamanın varsayılan çok süreçli (multiprocess) V1 yapılandırmasını varsıdığına dikkat çekiyor; bu yapılandırma hata ayıklama için VLLM_ENABLE_V1_MULTIPROCESSING=0 ile devre dışı bırakılabilir.

LLM bir facade, generate() bir döngü

entrypoints/llm.py içinde LLM sınıfı ince bir sarmalayıcıdır: modeli, dtype'ı ve ilgili yapılandırmayı EngineArgs içinde paketler ve motor oluşturmayı fabrika metodu LLMEngine.from_engine_args()'a devreder. Detayları çıkarıldığında generate()'ın iç yapısı her prompt'u add_request() ile kaydeder ve herhangi bir istek bitmemişken step() üzerinde döner, tamamlanan sonuçları toplayıp döndürmeden önce onları biriktirir. Yazar, tek bir dizi üzerinden elle yazılmış bir döngünün aksine bunun, uzunlukları ve tamamlanma zamanları farklı olan bir istek kümesini takip ettiğine işaret ediyor.

O döngü aynı zamanda continuous batching'in somutlaştığı yerdir. Güncelleme aşaması tamamlanan istekleri kaldırıp kaynaklarını serbest bırakırken, schedule() için bir sonraki çağrı bekleyen işleri kabul edebildiği için etkin istek kümesi adımdan adıma değişir. Böylece GPU'nun, başka bir istek katılmadan önce sabit bir grubun bitmesini beklemesi gerekmez.

Benzetimin ötesinde kaynağı okumak

Kaynağa başvurma motivasyonu olarak şöyle belirtiliyor: çoğu tanıtım yazısı, PagedAttention'in KV-cache'i sanal belleğin sayfaları yönetmesi gibi yönettiği benzetmesinde takılıyor; bir isteğin nasıl kabul edildiğini, değişken uzunluktaki isteklerin düz bir token grubuna nasıl dönüştüğünü veya kernel sınırında sayfa tablosunun neye benzediğini açıklamıyor. Bu nedenle inceleme, motor döngüsünü altı parçaya genişletiyor — giriş, zamanlama, girdi hazırlama, model yürütme, PagedAttention'in yazma ve okuma yolları ile çıktı işleme — ve bir sınırı bir sonrakine bağlamak için gereken kodu tutuyor. Okurun zaten prefill, decode, KV caching ve otoregresif üretimi bildiğini varsayıyor ve bu kavramların kodda nasıl ortaya çıktığına odaklanıyor.

Neden önemli

vLLM, LLM çıkarımını çalıştırmak ve servis etmek için yaygın olarak kullanılıyor ve öne çıkan performansı, continuous batching, token bütçeleri, sayfalı KV tahsisi ve zamanlamanın yürütmeden ayrılması gibi genellikle yalnızca benzetimlerle açıklanan mekanizmalara dayanıyor. Kaynak referanslı bir inceleme bu benzetimleri doğrulanabilir kod yollarına dönüştürüyor; bu da throughput hata ayıklayan, batch davranışını ayarlayan veya vLLM'nin fikirlerini kendi stack'lerine taşıyan mühendisler için önemli. Açıklamayı belirli bir tarihte vLLM 0.22.0'a sabitlemek, yazarın kendisinin sürekli değişmesini beklediği bir kod tabanında ekiplere sabit bir referans noktası veriyor.