Kubernetes üzerinde üretim vLLM: egemen bir dağıtım kalıbı

Bir model sunucusunu başlatmak kolaydır; onu kurumsal bir servis olarak işletmek mühendislik işidir. Bu makale keyfî çıkış olmadan Kubernetes üzerinde vLLM için bir referans mimari verir: GPU işçileri, bir iç gateway, varsayılan olarak her şeyi reddeden ağ, izleme, yazılım sürümleri gibi ele alınan model yayınları ve kamu bulutu ani artışı olmadan yedek kapasite. Bu uygulamaları konteyner orkestrasyonu, LLM sunumu ve üretime hazırlık üzerine araştırmalarla ilişkilendirir.

Anahtar kelimeler vLLM · Kubernetes · model sunumu · çıkış kontrolü · izleme · yayınlar

vllm serve çalıştırmak kolaydır. Onu kurumsal bir servis olarak işletmek asıl mühendislik işidir.

Üretimdeki bir vLLM dağıtımı model yaşam döngüsü kontrollerine, kimlik doğrulamaya, gözlemlenebilirliğe, güvenli yayına, kapasite yönetimine ve hata yönetimine ihtiyaç duyar. Egemen bir ortamda ayrıca çıkış, model depolama ve ayrıcalıklı erişim üzerinde açık kontrol gerekir.

Kubernetes, Google'da birbirini izleyen üç sistemde on yılı aşkın süre konteynerleri büyük ölçekte yönetmenin tasarım derslerini taşır^[1]; model sunucularını sıradan, bildirimsel olarak yönetilen iş yükleri olarak çalıştırmak, onu burada kullanmanın nedenidir. Sunum katmanının kendisi sistem araştırmalarından gelir: vLLM'in PagedAttention'ı key-value önbelleğini sanal bellek gibi yönetir ve aynı gecikmede önceki sistemlere göre 2–4 kat daha yüksek verim bildirir^[2]. Ağ için varsayılan olarak her şeyi reddeden bir duruş, NIST'in tanımladığı sıfır güven mimarisinden başlar^[3].

ML operasyonları üzerine araştırmalar iki uyarı ekler. ML sistemleri model kodunun ötesinde gizli teknik borç biriktirir^[4] ve üretime hazırlık, başarılı bir demodan çok açık bir test ve izleme rubriğine göre daha iyi değerlendirilir^[5]. Aşağıdaki yayın ve izleme uygulamaları bu fikirleri model sunumuna uygular.

Pratik bir kalıp beş katman içerir:

1. GPU işçi katmanı — ayrılmış hızlandırıcı düğümlerinde vLLM pod'ları veya iş yükleri.
2. İç gateway — kimlik doğrulama, hız sınırları, istek politikası, akış ve model yönlendirme.
3. Model depolama — kurumun kontrol ettiği nesne depolama veya kalıcı birimler.
4. Gözlemlenebilirlik — vLLM metrikleri, gateway izleri, uygulama kayıtları ve uyarılar.
5. Kontrol düzlemi — Kubernetes zamanlaması, gizli bilgiler, yayın stratejisi ve altyapı politikası.

Çıkarım pod'larının bir isteği yanıtlamak için keyfî internet erişimine ihtiyaç duymaması gerekir.

vLLM, CPU ve GPU ortamları için Kubernetes dağıtım rehberliği sunar ve çeşitli ekosistem yığınları üzerinden de entegre edilebilir.

Basit bir egemen tasarım için ilk sürümü sıkıcı tutun:

• ayrılmış GPU düğüm havuzu;
• açık kaynak istekleri ve limitleri;
• sabitlenmiş model ve konteyner sürümleri;
• model yükleme süresini hesaba katan hazırlık/başlangıç kontrolleri;
• yalnızca içeriden erişilebilen servisler;
• kapasiteyi koruyan pod kesinti ve yayın ayarları.

Amaç azami platform karmaşıklığı değil, öngörülebilir işletimdir.

Model sunucusunu her iç uygulamaya doğrudan açmayın.

Bir iç gateway şunları sağlayabilir:

• API anahtarları veya iş yükü kimliği;
• ekip başına kotalar;
• denetim kaydı;
• istek kimlikleri ve iz yayılımı;
• model takma adları ve kontrollü sürüm değişiklikleri;
• akış politikası;
• prompt boyutu ve bağlam sınırları;
• isteğe bağlı DLP veya içerik kontrolleri.

Bu, çıkarım yaşam döngüsünü uygulama yaşam döngüsünden ayırır. Ekipler her istemciyi yeniden yazmadan model değiştirebilir.

Çıkarım dışarıya internet erişimi olmadan çalışabildiğinde egemenlik üzerine akıl yürütmek kolaylaşır.

Tipik bir kalıp şudur:

• konteyner imajlarını içeride yansıtmak;
• model ağırlıklarını kontrollü depolamaya önceden yerleştirmek;
• gereksiz telemetriyi kapatmak;
• yalnızca açıkça onaylanmış iç hedeflere izin vermek;
• model güncellemeleri için ayrı, kontrollü bir iş akışı kullanmak.

Bu, veri yolunu denetlenebilir kılar ve istek anında dış bir model tedarikçisine bağımlılığı azaltır.

vLLM üretim metriklerini /metrics üzerinden sunar. Bunları gateway ve Kubernetes telemetrisiyle birleştirin.

İzleyin:

• TTFT ve üretim gecikmesi;
• istek kuyrukları;
• token verimi;
• GPU bellek baskısı ve kullanımı;
• aktif dizi sayısı;
• model yükleme hataları;
• pod yeniden başlatmaları ve OOM olayları;
• model sürümüne göre hata oranı.

Otomatik ölçekleme yalnızca ham CPU kullanımını değil, gerçek doygunlukla ilişkili bir sinyali — örneğin kuyruk derinliğini veya eşzamanlılığı — izlemelidir.

API sözleşmesi aynı kalsa bile bir model güncellemesi çıktı üslubunu, araç güvenilirliğini, JSON geçerliliğini veya güvenlik davranışını değiştirebilir.

Kontrollü bir yayın kullanın:

1. yeni checkpoint'i kaydedin;
2. çevrimdışı değerlendirmeleri çalıştırın;
3. bir canary kopyası dağıtın;
4. gecikme ve görev metriklerini karşılaştırın;
5. trafiğin küçük bir yüzdesini kaydırın;
6. terfi ettirin veya geri alın;
7. kabul tamamlanana kadar önceki artefaktı saklayın.

Kuantize edilmiş modellerde hem temel modeli hem de kuantizasyon hattını kaydedin.

Bir dağıtım kamu bulutuna taşamıyorsa bakım yedeği önem kazanır.

En azından ortamınızda makul olan arızalar için tasarlayın: bir pod, bir GPU, bir düğüm, bir depolama kesintisi veya hatalı bir model yayını. Doğru yedeklilik düzeyi servisin iş açısından kritikliğine bağlıdır.

• vLLM — Kubernetes deployment
• vLLM — Production Metrics
• vLLM — Parallelism and Scaling
• LMXAI — Egemen vLLM kurulumu

• Egemen vLLM kurulumu + tedarikçi kontrol listesi
• Egemen çıkarım için vLLM GPU boyutlandırma
• vLLM kuantizasyonu: AWQ, GPTQ, FP8 ve INT4
• Egemen AI SSS