Büyük Dil Modelleri (LLM'ler) deneysel prototiplerden üretim yüklerine geçtiğinde, darboğaz genellikle GPU hesaplamadan ağ G/Ç'ye kayar. Yüksek verimli sunum senaryolarında, standart bir Linux çekirdek yapılandırması nadiren yeterlidir. Bu gönderi, modelinizin istekleri milisaniyeler veya saniyeler içinde sunup sunamayacağını belirleyen kritik altyapı katmanlarını—özellikle TCP ayarlarını ve ağ topolojisini—inceliyor.
AI Sunumunda TCP Yığını Darboğazı
LLM çıkarımı; akış yanıtları için uzun süreli bağlantılar ve toplu işleme için küçük, sık isteklerle karakterizedir. Varsayılan TCP yığını, genel web trafiği için tasarlanmıştır, AI çıkarımının nüanslı gereksinimleri için değil. "Yavaş Başlangıç" (Slow Start) fazının gecikmeyi etkilemesini önlemek ve yüksek bant genişliğine, yüksek gecikmeye sahip bağlantılarda verimi maksimize etmek için temel parametrelerin ayarlanması genellikle gerekir.
İlk olarak, alma ve gönderme arabellek boyutlarını optimize etmeliyiz. Büyük arabellekler, ağ arayüzünün trafik patlamalarını emmesini sağlayarak paket kaybını ve ardından gelen yeniden iletimleri önler. Tipik bir veri merkezi bağlantısı için bu değerler, varsayılanlardan önemli ölçüde daha büyük olmalıdır.
# /etc/sysctl.conf
# Yüksek verimli ağlar için otomatik ayarlamayı etkinleştir
net.ipv4.tcp_window_scaling = 1
# Arabellek boyutlarını 16MB'a artırın (varsayılan genellikle 128KB-1MB'dir)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216Ayrıca, tcp_fastopen özelliğini etkinleştirmek, tekrarlanan istekler için bağlantı kurulum gecikmesini azaltabilir; bu, istemcilerin kalıcı bağlantılar sürdürdüğü API tabanlı hizmetler için hayati önem taşır.
Ağ Topolojileri: Fiziksel Katmanı Anlamak
Yazılım ayarları fiziksel sınırlamaları düzeltemez. LLM kümelerinde, özellikle dağıtılmış çıkarım veya vLLM kullananlarda, istemci ile GPU sunucusu arasındaki ağ topolojisi son derece önemlidir. Çıkarım trafiğini gereksiz atlama sayısına neden oluyorsa omurga-yaprak (spine-leaf) anahtarlarından yönlendirmekten kaçının. Bunun yerine, kat edilen anahtar sayısını en aza indiren bir Clos topolojisine yönelin.
Çok düğümlü kurulumlar için, Toplanmış Ethernet üzerinde RDMA (RoCE) veya InfiniBand kullanmayı düşünün. RDMA, çekirdek ağ yığını tamamen atlayarak GPU'nun veriyi doğrudan ağ kartından okumasını sağlar. Bu, standart TCP/IP yığınlarına kıyasla CPU yükünü ve gecikmeyi %50'ye kadar azaltır.
# Örnek: Linux NIC üzerinde RoCE yapılandırma
# Paket kaybını önlemek için PFC (Öncelikli Akış Kontrolü) özelliğinin etkin olduğundan emin olun
sudo ethtool -K eth0 roce on
sudo ip link set dev eth0 type ipvlan mode l2
# RoCE yeteneğini doğrula
sudo ethtool --dump-regset eth0 | grep roceUygulama Düzeyi Optimizasyonları
Çekirdek ve donanımın ötesinde, uygulama düzeyinde ayarlamalar da önemli bir rol oynar. vLLM veya TGI (Text Generation Inference) gibi çerçeveler kullanırken sürekli toplu işleme (continuous batching) özelliğini etkinleştirin. Bu, sunucunun birden fazla isteği tek bir ileri geçişte paketlemesini sağlar; bu da GPU kullanımını maksimize ederken bireysel istekler için gecikmeyi düşük tutar.
Ayrıca, HTTP yük dengeleyicinizin uzun süreli bağlantılar için yapılandırıldığından emin olun. Nginx veya HAProxy kullanıyorsanız, LLM'lerin değişken üretim sürelerini karşılamak için proxy_read_timeout değerini artırın. Erken sonlandırma, üretim LLM hizmetlerinde kısmi yanıt hatalarının yaygın bir kaynağıdır.
Sonuç
LLM çıkarımını optimize etmek yalnızca daha hızlı GPU'lar satın almakla ilgili değildir; tüm istek yolunun bütünsel bir görünümünü gerektirir. TCP çekirdek parametrelerini ayarlayarak, düşük gecikmeli düğümler arası iletişim için RDMA'dan yararlanarak ve uzun süreli oturumlar için yük dengeleyicileri yapılandırarak, ilk jeton süresini ve genel gecikmeyi önemli ölçüde azaltabilirsiniz. Ağ katmanından başlayın, taban çizginizi ölçün ve iterasyon yapın. Sallantılı bir kullanıcı deneyimi ile sorunsuz bir deneyim arasındaki fark, genellikle bu yapılandırma dosylarında gizlidir.