Llm-D 1.0, PyTorch Konferansı’nda Üretim İçin Çıkarım Yığınıyla Tanıtıldı

llm-d projesine katkıda bulunanlar, Kubernetes yerel dağıtık çıkarım hizmeti sunma yığını llm-d 1.0’ı, IBM Research’ün duyurusuna göre 20 Ekim 2026’da PyTorch Conference North America’da tanıttı. IBM, bu sürümün llm-d’yi tek tek performans tekniklerini sergilemenin ötesine taşıdığını ve çıkarım maliyetleri yükselirken kuruluşların model dağıtımını kendi bünyelerine almalarına yardımcı olmayı amaçladığını belirtti.

llm-d, herhangi bir modeli herhangi bir hızlandırıcıda ve herhangi bir bulutta dağıtmak üzere çıkarım yığınları oluşturmak için tasarlandı. Red Hat, IBM ve Google projenin başlıca bakım sorumlularıdır ve CoreWeave ile NVIDIA’yla birlikte llm-d’yi kurmuştur; AMD, Cisco, Hugging Face, Intel, Lambda ve Mistral AI ise projeye katkıda bulunanlar arasına katılmıştır. Cloud Native Computing Foundation (CNCF), llm-d’yi sandbox projesi olarak bünyesinde barındırıyor. IBM, ortaya çıkan çözümü; tek bir tescilli model sağlayıcısına, buluta veya donanım platformuna bütünüyle bağımlı olmadan, kendi deyimiyle en ileri düzeyde çıkarım performansı isteyen kuruluşlar için üreticiden bağımsız bir alternatif olarak tanımlıyor.

IBM Research’te Seçkin Mühendis ve llm-d’nin kurucu ortağı ve baş bakım sorumlusu olan Carlos Costa, 1.0 sürümünün llm-d’yi diğer tüm kritik hizmetler gibi çalıştırmak için gereken olgunluğu sağladığını söyledi. Costa, istikrarlı bir API’yi, öncelikleri birbiriyle yarışan birden fazla kiracının aynı altyapıyı paylaşabilmesini ve operasyonları kesintiye uğratmayan yükseltmeleri örnek gösterdi.

1.0 Sürümü Neler Getiriyor?

Projenin 20 Ekim 2026’da GitHub’da yayımlanan, imzalı ve doğrulanmış etiketler içeren v1.0.0 sürüm notları, çok kiracılı hizmet kalitesini öne çıkarıyor: kontrollü yük azaltma içeren, öncelikleri ve adaleti gözeten akış denetimi; buna olasılıksal kabul mekanizması, program farkındalıklı adalet ve tur önceliği puanlaması da dâhil. Böylece gecikmeye duyarlı istekler ile yoğun ve değişken aracı iş yükleri, aşırı yük altında birbirlerini kaynaklardan yoksun bırakmadan aynı kaynak havuzunu paylaşabiliyor. Akış denetimi yapılandırması tek bir flowControl alanı altında birleştirildi.

Kesintisiz operasyon için yönlendiriciye etkin-yedek çalışma ve güvenli aşamalı güncellemelerle yüksek erişilebilirlik kazandırılıyor. DisaggregatedSet denetleyicisi ise ön doldurma ve kod çözme kopyalarını, eşgüdümlü dağıtımlar, eşzamanlı yükseltmeler, Pod anlık görüntüsü hazır olana kadar bekleyen hazır olma denetimi ve yerel revizyon yönlendirmesiyle tek bir mantıksal birim olarak yönetiyor. Yönlendirici yapılandırma API’si v1 sürümüne yükseltiliyor, Responses API previous_response_id desteği kazanıyor ve uç nokta seçicisinin istek yolu güvenilirlik, performans ve ölçeklenebilirlik açısından güçlendiriliyor. DRA ve DRANET için topolojiyi dikkate alan bir hızlandırıcı kılavuzu da sunuluyor.

Aracı farkındalıklı hizmet sunumu, çok turlu konuşmaları önbelleğe alınmış bağlamlarına yakın tutmak için bir oturum durumu üreticisi eklentisi ve zaman içinde gelişen oturum bağlılığı ekliyor. Tur önceliğine dayalı zamanlama ve Responses API durumu, aracıların turlar boyunca bağlamı yeniden kullanmasına yardımcı oluyor. Sürüm, projenin bileşenlerini v1.0.0’da eşgüdümlüyor ve model ağırlıklarının eşler arası yüklenmesi için ai-dynamo/modelexpress ile entegrasyon, llm-d-api-extensions paketi ve llm-d-pd-utils tanılama araçları dâhil olmak üzere ekosisteme yeni bileşenler ekliyor. Ayrıca projenin kendi llm-d-rocm kapsayıcı imajı derlemelerini kullanımdan kaldırıyor. Model sunucusu imajları, çeşitli hızlandırıcı hedefleri için vLLM ve SGLang derlemelerini içeriyor. Ön doldurma ve kod çözmeyi ayrıştırma kılavuzu artık DisaggregatedSet API’si etkinleştirilmiş LeaderWorkerSet v0.11.1 veya daha yeni bir sürümü gerektiriyor.

Temel Teknikler ve Akış Denetimi

Proje, kullanıma sunulduğundan bu yana çıkarımı iyileştirmeye yönelik beş yaklaşıma odaklandı: bir isteği, ortak bağlamını hâlihazırda barındırıyor olabilecek altyapıya yönlendiren önek önbelleği farkındalıklı yönlendirme; önbelleğe alınmış bilgileri GPU, CPU ve depolama kaynakları arasında taşıyan KV önbelleği boşaltma; toplu çıkarım optimizasyonu; istemi okumayı yanıt üretiminden ayıran ön doldurma/kod çözme ayrıştırması; ve büyük karma uzman modellerini çok sayıda hızlandırıcıya dağıtan geniş ölçekli uzman paralelliği. Bu teknikler 1.0 sürümünden önce de mevcuttu. IBM’e göre yeni olan, bu teknikleri çevreleyen entegrasyon ve operasyonel olgunluk ile trafik değiştiğinde, donanım arızalandığında, yazılım güncellendiğinde veya farklı kullanıcılar aynı kaynaklar için rekabet ettiğinde performansı korumaya yönelik ikinci gün operasyon disiplinidir.

1.0 sürümündeki akış denetimi, adalet ve önceliklendirme; yoğun ve değişken iş yüklerinin, ister aynı donanımı paylaşsın ister farklı hızlandırıcıları bir arada kullansın, gecikmeye duyarlı hizmetleri aşırı yüklemesini önlemeyi amaçlıyor. Önek önbelleklerini sıcak tutmak için istekler birden fazla tur boyunca uygun altyapıya sabitlenebiliyor. llm-d, vLLM veya SGLang gibi çıkarım motorlarıyla çalışarak bunlara dağıtık yönlendirme ve operasyonel yetenekler ekliyor. Red Hat’in baş teknoloji sorumlusunun ofisinde başkan yardımcısı olan Stephen Watt, llm-d’nin Kubernetes yerel orkestrasyonunu doğrudan vLLM’ye ve modern çıkarım motorlarına taşıyarak PyTorch ve CNCF ekosistemlerini bir araya getirdiğini söyledi.

Gösterilen Sonuçlar ve Açıklanan Maliyetler

22 Temmuz 2026’da yayımlanan bir kıyaslama yazısında proje, burada 39 milyar etkin parametreye ve 78 katmana sahip, 744 milyar parametreli bir uzman karışımı modeli olarak tanımlanan GLM-5.2’nin ajan tabanlı sunumunu ölçtü. İş yükü analizi, medyan ana ajan isteğinin 195 bin girdi belirteci taşıdığı ve 317 çıktı belirteci döndürdüğü, ayrıca ana ajan turlarının %96’sında girdinin en az %90’ının yeniden kullanıldığı üretim ortamındaki 219 Claude Code oturumundan yararlandı. Yazıda, önek farkındalıklı yönlendirmenin iş yükünün mümkün kıldığı önbellek yeniden kullanımının %96–97’sini yakaladığı bildiriliyor. GPU-saat başına 2,71 $ varsayılan H200 kiralama ücreti üzerinden yapılan hesaplamada, iki adet 64 GPU’lu düzenekte kendi sunucularında barındırılan hizmetin maliyeti milyon girdi belirteci başına 0,05–0,08 $, milyon çıktı belirteci başına ise 1,92–3,55 $ olarak veriliyor. Yazarlar, bu rakamların yalnızca GPU kiralama ücretini kapsadığını ve sürekli yük varsaydığını belirtiyor.

Ayrı bir gösterimde IBM ve Red Hat, IBM Research’ün aktardığına göre yaklaşık 39 milyar etkin parametreye sahip, yaklaşık 753 milyar parametreli açık ağırlıklı bir model olarak tanımlanan GLM-5.2’yi 544 NVIDIA H100 GPU üzerinde devreye aldı. IBM, dağıtımın en yüksek düzeyde dakikada 6,6 milyondan fazla çıktı belirteci ürettiğini; aynı anda 3.000’e kadar kodlama ajanına sıfır ön kesintiyle hizmet verdiğini ve 2.500 ajanlık çalışma noktasında dakikada 7.612 isteği sürdürülebilir biçimde karşıladığını bildiriyor. IBM, güncel bulut kiralama ücretlerinde GLM-5.2’yi H100 GPU’larda llm-d ile kendi sunucularında barındırmanın belirteç başına maliyetinin eşdeğer ticari API fiyatlandırmasına göre 5 ila 10 kat daha düşük olduğunu belirtiyor. Red Hat’in çıkarım mühendisliği ekibinde kıdemli baş makine öğrenimi mühendisi olan Maroon Ayoub, “Binlerce eşzamanlı ajana ön kesinti olmadan hizmet sunabilmek, operatörlere bir kıyaslama sonucundan üretim ortamında dağıtıma geçiş için güvenilir bir yol sunuyor,” dedi.

Aynı açıklamaya göre, bu sonuçların temelinde ayrıştırılmış veri düzlemi, her biri ortalama 2,71 GiB olan 6,2 milyon KV önbelleği aktarımını hiçbir aktarım hatası olmadan tamamladı; tüm kıyaslamalar da hizmet sunumunda sıfır hatayla tamamlandı.