Ollama, vLLM, llama.cpp: Homelab Operatörü İçin Çoklu GPU Gerçekçi Analizi

Bu bölüm, Ollama, vLLM ve llama.cpp’ye odaklanır; içeriği:

• Ollama, vLLM, llama.cpp: Çoklu GPU Gerçeklik Kontrolü: Bant Genişliği Darboğazları ve Enerji Maliyetleri
• PCIe Bant Genişliği Darboğazı
• Güç ve Isı Denklemi
• Neden “Daha Fazla GPU” Her Zaman “Daha Hızlı” Demektir?
• Gerçek Hayatta İstikrarsızlığın Bedeli
• Ollama: Çoklu Cihaz Yürütmesi İçin Pratik Bir Sarıcı
• Ollama’nın Model Bölme Mekanizması
• Dağıtım ve Yapılandırmanın Kolaylığı
• Eş Zamanlılık Kısıtlamaları
• Operatör Notları: “Ollama” Farkı
• vLLM: Yüksek Eş Zamanlılık Yükleri İçin İşlemcanı Canavar
• PagedAttention Mekanikleri
• Dağıtık Servis Yetenekleri
• Yüksek Eş Zamanlılık vs. Düşük Gecikme
• Operatör Notları: Karmaşıklık Vergisi
• llama.cpp: Granüler Kontrol İçin Sağlam Motor
• GGUF Formatı ve Quantization
• Manuel Tensor Bölme ve Katman Kontrolü
• Düşük Seviye Kontrol ve Esneklik
• Operatör Notları: Bakım Yükü
• Donanım Topolojisi Önemlidir: NVLink vs. PCIe Darboğazları
• NVLink Avantajı (ve Yokluğu)
• PCIe Gen3 vs. Gen4 vs. Gen5
• Bağlam Değiştirmeye Gecikmenin Etkisi
• Karşılaştırma: Veri Merkezi vs. Tüketici
• Bellek Hiyerarşisi: VRAM, RAM ve Takas Riskleri
• VRAM Hiyerarşisi
• CPU Offloading ve RAM Takası
• Swap Dosyalarının Riski
• Operatör Notları: “Swap” Paniği
• Dağıtımdan Önce Donanım Denetimi: İstikrar İçin Kontrol Listesi
• Çoklu GPU Yapılandırması Doğrulama: Adım Adım Rehber
• Çıkarım Motoru Özellik Matrisi
• Topolojiye Göre Çoklu GPU Performans Beklentileri
• Donanım Arıza Modu Analizi
• Sorun Giderme: Çoklu GPU Hata Verdiğinde Ne Olur?
• Sorun 1: GPU 0’da “CUDA out of memory”
• Sorun 2: Performans tek GPU’dan daha yavaş
• Sorun 3: Bir GPU boşta, diğeri dolu
• Sorun 4: Sistem birkaç dakika sonra çöker
• Pratik Senaryo: İki RTX 3090 Üzerinde 70B Model
• Sık Sorulan Sorular
• Sonuç: İşin Doğru Aletini Seçmek

Tezgahın önünde iki veya üç adet tüketici sınıfı GPU ve bir avuç fatura ile duruyorsanız, donanımı yığınlamak anında sihirli sonuçlar vereceğine inanıyor olabilirsiniz. Bu doğru değil. Tüketici donanımında Ollama, vLLM, llama.cpp çalıştırmanın gerçeği, düşen verim, termal darbelendirme ve cüzdanınızı token üretmekten daha hızlı eriten bant genişliği darboğazlarıyla dolu bir oyundur. Güç dağıtım üniteleri veya soğutma yükseltmeleri için bir kuruş daha harcamadan önce, PCIe bus’un bir otoyol değil, bir darboğaz olduğunu anlamanız gerekir.

İşletme donanımınıza ikinci bir GPU eklemek doğrusal bir yükseltme değildir. Yeni arıza modlarını devreye sokan karmaşık bir entegrasyon görevidir. Veri merkezlerinde NVLink bu açığı kapatır; ancak homelab ortamında PCIe Gen3 veya Gen4 şeritleri verinin sürekli geri ve ileri karıştırılmasını zorunlu kılar, bu da ikinci kartı varlıktan ziyade bir yük haline getirir. 70 milyar parametreli bir modeli iki adet 12GB’lık kart üzerinde çalıştırıyor veya RTX 3090’lar üzerinde 48GB VRAM’i yayarak devasa bir bağlam penceresini sıkıştırmaya çalışıyor olabilirsiniz. Bu kısıtlamaların fiziği, hangi motoru çalıştırmanız gerektiğini belirler.

Bu kılavuz, “bulut-native” benchmarklarının hype’inden sıyrılır. Elektrik faturasına, oturma odanızdaki fan gürültüsüne ve ev internet bağlantısı üzerinde 7/24 çalışan bir sistemin istikrarına bakıyoruz. Ollama, vLLM veya llama.cpp basitliğinden ziyade, vLLM’in ham işleyiş kapasitesini veya llama.cpp’nin granüler kontrolünü seçseniz bile, seçiminiz fiziksel donanım topolojinizle uyumlu olmalıdır.

Motorların katmanları nasıl böldüğünü, bellek bant genişliğinde nerede tıkanacaklarını ve fanlar %100 hızda döndüğünde sistemde RAM’e takas yapmaya başladığında neler olacağını detaylandıracağız. Bu teorik bir genel bakış değil, elektrik faturasını ödeyen operatör için bir hayatta kalma kılavuzudur.

Ollama vllm llama cpp: Çoklu GPU Gerçekliği: Bant Genişliği Tıkanıklıkları ve Enerji Maliyetleri

İkinci bir ekran kartı satın aldığınızda, sadece bellek satın almıyorsunuz; aynı zamanda ısı, güç tüketimi ve çok daha karmaşık bir sistem mimarisi de satın alıyorsunuz. Homelab yöneticilerinin yaptığı en yaygın hata, aynı modeli çalıştıran iki GPU’nun performansın iki katını vereceğini varsaymaktır. Büyük Dil Modeli (LLM) çıkarımı dünyasında, bu varsayım NVLink ve devasa yığın boyutları içeren çok spesifik koşullar dışında neredeyse hiçbir zaman doğru değildir.

PCIe Bant Genişliği Tıkanıklığı

Konsumeri çoklu GPU kurulumlarındaki temel kısıtlama, Peripheral Component Interconnect (PCIe) veri yoludır. Modern tüketici anakartları genellikle PCIe Gen4 x16 yolları sunar, ancak bunlar bile büyük modellerin çıkarımı sırasında gereken veri hareketi için yetersizdir. Model iki GPU’ya bölündüğünde, katıklar sürekli iletişim kurmak zorunda kalır. İleri pass (forward pass) sırasında GPU 0’dan çıkan çıktı, GPU 1 için girdi olur. Geri dönüş (backward pass) veya bağlam oluşturma sırasında ise verinin geri akması gerekir.

İki RTX 3090’ınız olduğunu düşünün. Her birinde 24GB VRAM var. 70B parametreli bir modeli yüklersiniz. Model tek bir kartta sığmaz. Çıkarım motoru katıkları bölmek zorundadır. GPU 0 0-20. katmanları, GPU 1 ise 21-50. katmanları işler. Model bir token ürettiğinde, GPU 0 hesaplamasını tamamlar ve sonucu PCIe veri yolu üzerinden GPU 1’e göndermek zorundadır. PCIe bant genişliğiniz doymuşsa, GPU 1 veriyi bekleyerek atıl durumdadır. Buna “PCIy stall” (PCIy takılması) denir.

Nişan bir tek GPU çalıştırmada veri hiç VRAM’den çıkmaz. Çoklu GPU PCIe çalıştırmada ise, üretilen her token için veri anakart üzerinde defalarca dolaşır. 70B’lik bir model için veri hareketi büyüktür. PCIe Gen3 x16 ile teorik bant genişliği yaklaşık 16 GB/s’dir. Gerçek dünya verimliliği genellikle protokol yükü nedeniyle daha düşüktür. Eğer çıkarım motorunuz 20 GB/s ara GPU trafiği gerektiriyorsa, hesaplamayı bile başlatmadan önce darboğaza takılırsınız. Bu da standart bir tüketici anakartına ikinci bir GPU eklemenin, umduğunuz 2.0x hızlanmanın yerine yalnızca 1.3x ile 1.5x hızlanma sağlayabileceği anlamına gelir.

Güç ve Isı Denklemi

Bunu muhtemelen bulut ücretleri ödemeden daha büyük modelleri yerel olarak çalıştırmak istediğiniz için yapıyorsunuz. Ancak güç maliyetini hesaba katmalısınız. Tam yük altında modern bir GPU 250W ile 350W arasında güç çekebilir. İkisini çalıştırmak, ev yükünüze 500W ile 700W eklemek demektir. 24 saatlik bir dönemde bu, ek olarak 12 ile 16.8 kWh anlamına gelir. Yerel elektrik oranlarınıza bağlı olarak bu, aylık önemli bir giderdir.

Evinizdeki elektrik oranı düşüktse, diyelim ki kWh başına 0.10$, iki GPU’lu bir kurulumu çalıştırmak için aylık 50$ ile 70$ arası ek ücret ödüyor olabilirsiniz. Eğer California veya Avrupa’nın bazı bölgeleri gibi daha yüksek oranlı bir yerde yaşıyorsanız, bu rakam ikiye katlanabilir. Üstelik güç denklemin sadece yarısıdır; diğer yarısı ısıdır.

Küçük bir kasada (standart bir 1U veya 2U sunucu kasasında veya hatta modifiye edilmiş bir ATX kulede) iki GPU, bir ısı adası yaratır. Kasanın içindeki hava çok çabuk ısınır. Çoğu tüketici ekran kartının maksimum sıcaklık limiti 83°C ile 90°C arasındadır. Bu eşiğe ulaştıklarında hız düşürürler (throttle). Hız düşürme, her tokenin üretimi için gereken süreyi artırır, bu da daha fazla ısı üretir. Sonuç olarak, donanımın kendini soğutmak için daha fazla çalıştığı ve performansı daha da kötüleştirdiği bir olumsuz geri besleme döngüsünde olursunuz.

Bunu daha fazla fanla çözebileceğinizi düşünebilirsiniz, ancak hızla ses sınırlarına takılırsınız. İki 3090’ı %100 fan hızında çalıştırmak, uçağın kalkış yaptığı gibi bir gürültü yaratır. Evinizde veya ofisinizde bu gürültüyü tolere edemiyorsanız, kartları aşındırmak (underclock) veya gerilimi düşürmek (undervolt) zorunda kalırsınız. Gerilim düşürme, manuel ayarlama gerektirir ve yanlış yapılırsa kararsızlığa yol açabilir.

Neden “Daha Fazla GPU” Her Zaman “Daha Hızlı” Değildir

“Daha fazla GPU daha hızlıdır” sözü, pazarlama departmanları tarafından satılan bir yalandır. Gerçeklik daha incelidir. Bir GPU eklemek kapasiteyi (çalıştırabileceğiniz model boyutunu) artırır, ancak yukarıda belirtilen yüklerden dolayı verimliliği (token alma hızını) genellikle düşürür.

Belirli bir senaryoya bakalım. 13B parametreli bir modeliniz var. Bu, tek bir 12GB kartın rahatça sığabileceği bir boyuttadır. Tek bir kartta çalıştırdığınızda yüksek token verimliliği, düşük gecikme ve düşük güç tüketimi elde edersiniz. Ancak bunu iki 8GB kart üzerinde çalıştırmayı (modeli bölerek) denerseniz, PCIe yükü getirmiş, güç tüketimi ikiye katlanmış ve ısı artmış olursunuz. Büyük ihtimalle tek kartta çalıştırmaya göre daha yavaş performans alırsınız. Küçük yığın boyutlarında “ölçek verimsizliği” budur.

Çoklu GPU, model, tek bir tüketici kartının VRAM kapasitesinden büyük olduğunda anlamlıdır. Örneğin, bir 70B model (yaklaşık 35GB FP16 veya 30GB Q4_K_M için) tek bir 24GB kartta sığmaz. Zorunlu olarak iki kart kullanmanız gerekir. Bu spesifik durumda, mübadele kabul edilebilir: modeli çalıştırmayı sağlarsınız, ancak gecikme cezasını kabul edersiniz. Model tek bir kartta sığabiliyorsa, onu bölme. Güç ve donanım karmaşıklığı için hiçbir getiri elde etmeden para harcamış olursunuz.

Kararsızlığın Gerçek Dünya Maliyeti

Çoklu GPU kurulumlarının görünmeyen bir maliyeti de operasyonel kararsızlıktır. Tüketici sürücüleri, LLM çıkarımının sürdürülen, ağır yükü için tasarlanmamıştır. İki kart çalıştırdığınızda bellek yükü dağıtılır, ancak bölünmeyi yönetmek için gereken sistem belleği (RAM) kullanımı patlama yapabilir. İşletim sisteminin bellek doluluk (OOM) öldürücüsü tetiklenirse, tüm kurulumunuz çöker.

Ayrıca başarısızlık noktaları oluşturursunuz. Bir GPU sürücüsü çökerse veya kart aşırı ısınarak kapanırsa, tüm çıkarım işlemi durur. Çıkarım motoru zarif bir şekilde toparlanamayabilir. Tek GPU’lu bir kurulumda, bir çöküş yeniden başlatmadır. Çoklu GPU kurulumunda ise, bekleyen tüm istekler için bağlam penceresini kaybetmiş olabilirsiniz. Maliyet kadar “çalışma süresine” (uptime) önem veren bir homelab yöneticisi için bu, kritik bir riskdir.

Kendinize sormanız gereken şey: 70B’lik bir modeli çalıştırabilme yeteneği, artan karmaşılık değerinde mi? Eğer tek bir 24GB kart üzerinde (Llama 3 34B gibi) nicemlenmiş bir 34B model kullanabilirseniz, yüksek performans, düşük gecikme ve kararlılık elde edersiniz. Eğer 70B modelin saf zekasına ihtiyacınız varsa, iki karta ihtiyacınız var. Ancak PCIe darboğacını kabul etmelisiniz.

Ollama: Çoklu Cihaz Çalıştırması İçin Pratik Bir Sarıcı

Ollama, LLM’ler için “tamamı işe yarar” çözüm olarak konumlandırdı. Bir homelab operatörü için bu en güçlü satış noktasıdır. Python ortamları, bağımlılık yönetimi ve Docker konteynerlerinin karmaşıklığını soyutlar. Ancak çoklu GPU desteği sunduğunuzda, “sadece çalışır” büyüsü daha kırılgan hale gelir. Ollama’nın çoklu GPU uygulaması pragmatiktir ancak tek işlemli bir sarıcı mimarisiyle sınırlıdır.

Ollama Model Bölme Nasıl Yapar

Ollama, katmanlı bir bölme yaklaşımı kullanır. Tek bir GPU’ya sığmayan bir model istediğinizde, Ollama sinir ağı katmanlarını mevcut cihazlar arasında bölüştürmeye çalışır. Bunu otomatik olarak yapar, ancak davranışı genellikle ortam değişkenleriyle etkileyebilirsiniz. Motor, ilk GPU’ya sığmayan en büyük katmanı belirler ve onu sonrakine taşır.

İki RTX 3090’lı tipik bir kurulumda Ollama, ilk 20 katmanı GPU 0’a ve kalan katmanları GPU 1’e atayabilir. Kritik nokta şudur: Bu bölünme model yükleme aşamasında gerçekleşir. Katmanlar çıkarım (inference) sırasında dinamik olarak içeri alınmaz veya çıkarılmaz; sabittir. Model yüklendikten sonra GPU 0 alt katmanlardan, GPU 1 ise üst katmanlardan sorumludur.

Bu statik bölme basit iş yükleri için verimlidir ancak darboğazlar yaratabilir. Katmanlar arasındaki hesaplama yükü dengesizse (ki bu bazen olur), bir GPU işini diğerinden önce bitirebilir, ancak bir sonraki token oluşturulmadan önce diğerinin ileri geçişi (forward pass) bitirmesini beklemek zorunda kalır. Bu senkronizasyon maliyeti tasarımın doğasında vardır.

Kurulum ve Yapılandırma Kolaylığı

Operatörlerin Ollama’yı seçmesinin birincil nedeni kurulum kolaylığıdır. Tek bir komutla bir sunucu başlatabilirsiniz: ollama serve. Çoklu GPU ortamlarında CUDA sürücülerinin doğru şekilde haritaya eklenmesini sağlamak için genellikle konteynerize bir kurulum gerekir.

Ollama’nın çoklu GPU kullanmak için bir Docker konteynerinde nasıl yapılandırılacağına dair örnek budur. Bunun için NVIDIA Container Toolkit gereklidir.

docker run -d --name ollama-multi-gpu --gpus all \
  -p 11434:11434 \
  -v ollama:/root/.ollama \
  ollama/ollama:latest

--gpus all bayrağı hayati önem taşır. Docker’a kullanıma hazır tüm GPU’ları konteynerle paylaşması talimatını verir. Ollama ardından mevcut CUDA cihazlarını tarar ve model katmanlarını buna göre atar. Hangi GPU’ların kullanıldığını kontrol loglarını inceleyerek veya nvidia-smi komutuyla doğrulayabilirsiniz.

Ancak sınırlamalar vardır. Ollama’nın çoklu GPU desteği nispeten yenidir ve vLLM kadar olgun değildir. Küçük topluluklar için gecikmeyi optimize eder, yüksek akışlı hizmet sunma için değil. Çoklu kullanıcı için bir API sunucusu çalıştırıyorsanız, Ollama eşzamanlı isteklerde zorlanabilir. Tek kullanıcı etkileşimi veya küçük bir istek grubu için mükemmeldir, ancak kurumsal motorlar sunan gelişmiş istek zamanlama yeteneğinden yoksundur.

Eşzamanlılık Sınırlamaları

Ollama yerel çalışan bir kişisel asistan için harika olsa da, aynı anda çoklu kullanıcıyı yönetmeniz gerektiğinde yetersiz kalır. Ollama’daki varsayılan çıkarım motoru istekleri sırayla veya küçük topluluklar halinde işler. İki kullanıcı aynı anda istek gönderdiğinde, Ollama bunları kuyruğa alır.

Çoklu GPU kurulumunda bu kuyrulama darboğaza dönüşebilir. 48GB VRAM’iniz olsa bile, topluluk boyutu küçükse sistem her iki GPU’yu da verimli kullanmayabilir. PCIe busu katmanlar arasında veri aktarımı için darboğaz haline gelir ve Ollama’nın tek işlemli mimarisi, önemli bir iç karmaşıklık olmadan istek işleme işlemi çoklu GPU çiftleri arasında kolayca paralelleştiremez.

Operatör Notları: “Ollama” Takas Dengesi

Ollama’yı seçerseniz, esneklik yerine konforu alırsınız. Yönetimi kolay sağlam bir sistem elde edersiniz, ancak katman bölme mantığını ince ayar yapma veya hafıza düzenini dinamik olarak değiştirme yeteneğinden yoksun kalırsınız. Hafıza düzenine aşırı duyarlı (bazı özel nicemleme formatları gibi) bir modeli çalıştırmanız gerekiyorsa, Ollama gerekli ince ayar butonlarını (knobs) sunmayabilir.

Ayrıca kaynak maliyetine dikkat edin. Ollama bellekte kalan bir sunucu işlemi çalıştırır. Birden fazla model çalıştırıyorsanız, Ollama bunların hepsini yükler ve RAM ve VRAM tüketir. Sisteminizi çok zorlarsanız bu OOM (Out of Memory) hatalarına yol açabilir. Kullanılmayan modelleri durdurmak konusunda titiz olmanız gerekir.

vLLM: Yüksek Eşzamanlılık İş Yükleri İçin Bant Genişliği Canavarı

Eğer Ollama pratik bir sarmalayıcı (wrapper) ise, vLLM ölçeklenebilirlik için tasarlanmış yüksek performanslı motordur. UC Berkeley araştırmacıları tarafından geliştirilen vLLM, PagedAttention adı verilen bir teknik kullanarak LLM sunumundaki bellek darboğazını çözmeye özel olarak kurgulanmıştır. Birden fazla kullanıcıyı yöneten çoklu GPU’lu bir istemci sunucusu kurmaya çalışan bir homelab operatörü için, öğrenme eğrisinin daha dik olması ve kaynak yükü daha fazla olmasına rağmen, vLLM genellikle üstün bir tercihtir.

PagedAttention Mekanizması

Traditional LLM serving engines store the attention key-value (KV) cache in a contiguous block of memory. As the context window grows, this memory grows linearly. To save memory, you have to reduce the batch size or the context window. This is inefficient.

vLLM, PagedAttention’ı tanıtır. Bu mekanizma KV önbelleğini birbirine bağlı olmayan küçük bloklara böler. İşletim sistemlerinin fiziksel RAM sayfalarını yönetme biçimine benzer şekilde, bu blokları birbirine bağlamak için bir bellek yönetim tablosu kullanır. Bu sayede vLLM şunları yapabilir:
1. Bellek verimliliği: Aynı önekle (prefix) sahip istekler varsa, aynı bellek bloğu istekler arasında paylaşılabilir (tekrar önleme).
2. Parçalanmayı ortadan kaldırır: Bellek sabit boyutlu bloklar halinde tahsis edilir, bu da boşa harcanan alan kalmaz demektir.
3. Büyük batch’leri destekler: Bellek daha verimli kullanıldığı için, aynı donanım üzerinde daha fazla eşzamanlı istek sığdırabilirsiniz.

Bir çoklu GPU kurulumunda, bu verimlilik kritiktir. Bir modeli iki GPU’ya böldüğünüzde, KV önbelleği için bellek fazlalığı yine de mevcuttur. vLLM’in bu belleği yönetebilme kabiliyeti, bellek tavanına çarpmadan önce daha fazla isteği çalıştırabilmenizi sağlar.

Dağıtık Sunum Yetenekleri

vLLM, tensor paralelliği (TP) ve pipeline paralelliği (PP) kullanan dağıtık çıkarım için yerel desteğe sahiptir. vLLM’ün çoklu GPU’lu bir homelab ortamında parladığı yer burasıdır.

• Tensor Paralelliği (TP): Model GPU’lar arasında bölünür. Her GPU, aynı katmanın bir dilimini işler. Örneğin, bir katmanda 1024 giriş kanalı varsa, GPU 0 ilk 512’sini, GPU 1 son 512’sini işler. Her tokende kilitleşmiş olarak (lockstep) çalışırlar. Bu, yüksek hızlı bağlantılar (NVLink gibi) gerektirir ancak devasa hız artışları sunar.
• Pipeline Paralelliği (PP): Farklı GPU’lar modelin farklı katmanlarını işler. GPU 0 0-10 katmanlarını, GPU 1 11-20 katmanlarını vb. işler. Bu, Ollama’nın yaklaşımına benzer ancak daha iyi batch planlaması ve örtüşme sağlar.

PCIe üzerinden bağlı tüketici kartları için vLLM yine de TP veya PP kullanabilir, ancak performans kazançları veriyolu ile sınırlanacaktır. Ancak vLLM, Ollama’ya kıyasla gecikme fazlalığını daha iyi yönetecek şekilde optimize edilmiştir. Mevcut bant genişliğinin kullanımını maksimize etmek için daha sofistike bir zamanlayıcı kullanır.

Yüksek Eşzamanlılık vs. Düşük Gecikme

vLLM, bant genişliği (throughput) için tasarlanmıştır. Aynı anda 100 kullanıcıya hizmet veren bir web siteniz veya API’niz varsa, bu senaryoda vLLM Ollama’yı ezer geçer. Birçok aktif isteğe rağmen yüksek bir token oluşturma hızını koruyabilir.

Bununla birlikte, vLLM de bedelini ister. llama.cpp veya Ollama’dan daha yüksek bir bellek fazlalığına sahiptir. PagedAttention uygulaması ek metadata yapıları gerektirir. Ayrıca vLLM’i dikkatli bir şekilde yapılandırmanız gerekir. GPU sayısını, tensor paralellik boyutunu ve pipeline paralellik boyutunu belirtmeniz gerekir.

# docker-compose.yaml example for vLLM multi-GPU serving
version: '3.8'
services:
  vllm:
    image: vllm/vllm-openai:latest
    command:
      - --model
      - meta-llama/Llama-3-70B-Instruct
      - --tensor-parallel-size
      - "2"
      - --dtype
      - float16
      - --max-model-len
      - "8192"
      - --gpu-memory-utilization
      - "0.95"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]
    ports:
      - "8000:8000"
    volumes:
      - ./models:/models

Bu yapılandırma, vLLM’in Llama 3 70B modelini 2 boyutunda tensor paralelliği ile çalıştıracağını belirtir. İki GPU’ya sahip olduğunuzu varsayar. VRAM kullanımını en üst düzeye çıkarmak için gpu-memory-utilization bayrağı 0.95 olarak ayarlanmıştır; güvenlik için küçük bir tampon bırakılır.

Operatör Notları: Karmaşıklık Vergisi

Homelab ortamında vLLM kullanmak sıradan bir iş değildir. Docker, ağ ve vLLM yapılandırma bayraklarını anlamanız gerekir. Tensor paralellik boyutunu yanlış yapılandırırsanız, sunucu çöker. Model uzunluğunu çok yüksek ayarlarsanız, bellek yetersiz kalır.

Ancak, “üretim benzeri stabilite” ve bant genişliğine değer veren bir homelab operatörü için vLLM en iyi araçtır. Bellek yönetimi ve istek zamanlaması gibi zorlu işleri halleder; böylece siz altyapıya değil, iş yüküne odaklanabilirsiniz.

llama.cpp: Granüler Kontrol İçin Ham Motor

Ollama bir kabuk, vLLM ise optimize edilmiş bir sunucu ise, llama.cpp doğrudan çalışan ham motordur. Bir C/C++ kütüphanesi olarak birçok aracın (Ollama dahil) arkasındaki itici güçtür. llama.cpp’yi doğrudan çalıştırmak, donanım, model quantization (nicemleme) ve bellek düzeni üzerinde en geniş kontrolü sağlar. GPU’larınızdan her bir son damla performansı sıkmak isteyen operatör için llama.cpp kraldır.

GGUF Formatı ve Quantization (Nicemleme)

llama.cpp’nin gücünün kalbi GGUF formatındadır. Genellikle FP16 veya FP32 olan standart PyTorch modellerinin aksine, GGUF modelleri bellek hacmini düşürmek için nicemleme kullanır. Yaygın nicemleme seçenekleri Q4_K_M (4-bit) ve Q8_0 (8-bit)’dir.

Nicemleme, modelin gerektirdiği belleği 4’ten 8’e kadar azaltır. FP16 formatında 140GB gerektiren bir 70B model, Q4_K_M olarak nicemlendiğinde yaklaşık 40GB VRAM’e sığdırılabilir. İşte llama.cpp’nin homelab topluluğunda bu kadar popüler olmasının sebebi: Aksi halde imkansız olacak devasa modelleri tüketiciler seviyesinde donanımda çalıştırmanıza izin verir.

llama.cpp’yi çoklu GPU için kullanırken, modeli sığdırmak için genellikle bu nicemleme avantajını kullanırsınız. Ancak model VRAM’den fazlaysa, katmanları sistem RAM’ine taşımak (offload) seçeneğiniz de vardır. Bu seçenek her zaman çalışmaz; bellek yolundaki gecikme (latency) ciddi şekilde artar ve bunu bir üretim ortamında beklersiniz. Alternatif çözümler genelde buna izin vermez veya çok daha yavaştır.

Manuel Tensör Bölümleme ve Katman Kontrolü

llama.cpp’de modeli nasıl böldüğünüz konusunda açık bir kontrolünüz vardır. Katmanları GPU’ya taşıma sayısını belirtmek için -ngl bayrağını (offload edilecek katman sayısı) kullanırsınız.

Çoklu GPU kurulumlarında tipik komut satırı şöyle görünür:

./llama-server -m models/llama-3-70b.Q4_K_M.gguf \
  --ctx-size 8192 \
  --n-ctx 8192 \
  --ngl 80 \
  --threads 12 \
  --gpu-layers 20

Durak, yukarıdaki komut tek bir GPU içindir. Çoklu GPU için llama.cpp farklı bir mekanizma kullanır. GPU sayısını ve dağılımı belirtmeniz gerekir. Son sürümlerde llama.cpp otomatik olarak birden fazla GPU’yu algılar ve katmanları böler, ancak çevre değişkenleri veya --split-mode gibi belirli bayraklar kullanarak bunu manuel olarak da kontrol edebilirsiniz.

Örneğin, belirli bir bölünmeyi zorlamak isteyebilirsiniz:

export LLAMA_MAX_BATCH_SIZE=128
./llama-server -m models/llama-3-70b.Q4_K_M.gguf --gpu-layers 40

Aslında, gerçek çoklu GPU dağılımı için genellikle toplam katmanlara göre --ngl bayrağına güvenmeniz gerekir. Toplam 80 katnınız ve iki GPU’nuz varsa, her GPU için --ngl 40 ayarlayabilirsiniz; ancak llama.cpp dağıtım mantığını mevcut VRAM’e göre kendi içinde halleder. Modeli eşit şekilde bölmeye çalışır. Farklı VRAM’lere sahipseniz (örneğin biri 24GB, diğeri 12GB), llama.cpp daha akıllı davranır ve 24GB’lık karta daha fazla, 12GB’lık karta daha az katman yükler. Ama unutmayın, kararsız donanım yapıları her zaman beklenmedik hatalar yaratır.

Düşük Seviye Kontrol ve Esneklik

llama.cpp’nin en büyük avantajı esnekliktir. Özel yapılar oluşturabilirsiniz. Donanımınıza özel optimizasyonlar için belirli kernel’leri (CUDA, ROCm, Metal) aktif edebilir, kullanım durumunuza özel bellek düzenini ince ayara getirebilirsiniz.

Örneğin, çok büyük bir bağlam penceresi (örn. 128k token) gerektiren bir model çalıştırıyorsanız, llama.cpp başka motorların erişime açmadığı farklı kaydırma penceresi tekniklerini veya KV önbellek atma politikalarını denemenize olanak tanır. Alternatif araçlar genellikle bu düzeyde kısıtlandırılmıştır.

Operatör Notları: Bakım Yükü

llama.cpp’yi doğrudan çalıştırmak ciddi bir iş yüküdür. Binary’leri derlemeniz, model dosyalarını yönetmeniz ve komut satırı argümanlarının doğru olduğundan emin olmanız gerekir. Bunu bir API üzerinden sunmak istiyorsanız, llama-server binary’sini çalıştırıp HTTP isteklerini kendiniz yönetmeniz veya bunları text-generation-webui veya oobabooga gibi bir框架ın içine sarmalamanız gerekir.

Ancak tam olarak ne olduğunu anlamak isteyen operatör için llama.cpp en iyi araçtır. Logları görebilir, parametreleri ince ayarlayabilir ve spesifik donanım topolojinize göre optimize edebilirsiniz. Diğerleri sadece “çalışsın” derken, siz sistemi yönetirsiniz. Beklenen performans ve stabilite için bu maliyeti ödemelisiniz.

Donör Topolojisi Önemlidir: NVLink vs. PCIe Darboğazları

Ollama, vLLM veya llama.cpp arasında seçim yapmak, fiziksel donanör topolojisinden ikincildir. Dünyanın en iyi yazılımına sahip olsanız bile, eğer donanör topolojiniz hatalıysa performansınız berbat olur. En kritik faktör GPU’lar arasındaki bağlantıdır.

NVLink Avantajı (ve Yokluğu)

Veri merkezlerinde GPU’lar NVLink (Nvidia Yüksek Hızlı İletişim) ile bağlanır. NVLink, muazzam bant genişliği (H100 için 900 GB/s’e kadar) ve düşük gecikme süresi sağlar. Bu, GPU’lar arasında sıkı bir birleşim anlamına gelir. İki H100 arasında NVLink ile çalışan bir modeli çalıştırdığınızda, neredeyse tek devasa bir GPU gibi davranırlar. Overhead ihmal edilebilir düzeydedir.

Tüketici kartları (RTX 3090, 4090) NVLink’e sahip değildir. NVIDIA, tüketici kartlarından NVLink bağlantısını kaldırdı. PCIe bus’ı ile baş başa kalırsınız. Bu temel bir kısıttır.

PCIe Gen3 vs. Gen4 vs. Gen5

Tüketici donanımda çoklu-GPU çıkarımı için sınırlayıcı faktör PCIe bus hızıdır.
* PCIe Gen3 x16: ~16 GB/s teorik bant genişliği.
* PCIe Gen4 x16: ~32 GB/s teorik bant genişliği.
* PCIe Gen5 x16: ~64 GB/s teorik bant genişliği.

Uygulamada, protokol overhaddı nedeniyle teorik bant genişliğinin %70-80’ini alırsınız.

Eğer PCIe Gen4 x16 slotunda iki RTX 3090’ınız varsa, teorik olarak 32 GB/s’lik bir borunuz var demektir. 70B’lik bir model için veri hareketi yoğundur. Bir katmanın çıktısını bir sonrakinin girişine taşıyorsunuz. Model büyükse, veri hareketi PCIe bus’ı doyurabilir. Bu, GPU’ların hesaplama yapmaktan ziyade veri bekledikleri anlamına gelir.

Bağlam Değiştirme Üzerindeki Gecikme Etkisi

Çoklu-GPU kurulumlarında her token üretimi, birden fazla veri aktarım turu içerir. Yüksek gecikmeli bir bağlantınız varsa (PCIe gibi), token başına gecikme artar. Bu doğrudan “ilk tokena kadar geçen süre” (TTFT) ve toplam token üretim hızını etkiler.

Bir tek kullanıcılı senaryo için bu kabule edilebilir olabilir. saniyede 5 token ile 8 token arasındaki fark fark edilmeyebilir. Ancak yüksek eşzamanlılık gerektiren bir sistemde bu gecikme birikir. 100 eşzamanlı isteğiniz varsa ve her isteğin PCIe aktarımını beklemesi gerekiyorsa, sisteminiz yavaşlar.

Karşılaştırma: Veri Merkezi vs. Tüketici

Gördüğünüz gibi, tüketici kurulumu büyük bir tavizdir. Para tasarrufu sağlarsınız ama performanstan kaybedersiniz. Benchmarklarda okuduğunuz “doğrusal ölçeklenebilirlik” tüketici kartlar için bir efsanedir.

Bellek Hiyerarşisi: VRAM, RAM ve Takas Riskleri

Çoklu GPU kullandığınızda, karmaşık bir bellek hiyerarşisiyle uğraşıyorsunuz demektir. Her GPU üzerinde VRAM, sistem RAM’i ve potansiyel olarak disk (takas) mevcuttur. Çökmeleri önlemenin anahtarı, bu katmanların nasıl etkileşime girdiğini anlamaktır.

VRAM Hiyerarşisi

Çoklu GPU kurulumunda toplam VRAM, tüm GPUlardaki VRAM’lerin toplamıdır. Ancak bunları toplayıp tümünü doğrudan kullanabileceğinizi varsayamazsınız. Katmanlar bölünmelidir. İki adet 24GB kartınız olsa, toplamda 48GB’a sahipsiniz demektir. Fakat 48GB ağırlığı tek bir katmanda tutamazsınız. Ağırlıklar kartlar arasında bölünür.

Eğer bir katman, tek bir kartın VRAM kapasitesinden büyükse, bu katman birden fazla karta bölünmek zorundadır. Bu da veri hareketini artırır. Eğer bir katman tek bir karta bile sığamazsa, sistem çöker veya CPU’ya kaydırma (offloading) moduna düşer.

CPU Kaydırma ve RAM Takası

VRAM dolduğunda, çıkarım motoru bazı katmanları sistem RAM’ine kaydırabilir. Buna “CPU kaydırma” denir. Bu, performans katili bir işlemdir. RAM, VRAM’den çok daha yavaştır. Bant genişliği farkı 10x ile 20x arasında değişir.

Eğer modeliniz toplam VRAM kapasitesinden büyükse, iki seçeneğiniz var:

1. Quantize (Nicemleme): Ağırlığın hassasiyetini düşürün (örn. FP16’dan Q4_K_M’e). Bu, bellek ayak izini azaltır.
2. Offload (Kaydırma): Bazı katmanları RAM’e taşıyın.

Eğer kaydırma seçeneğini seçerseniz, token üretme hızınız dramatik şekilde düşer. 1 saniyede 10 tokenden 1 tokene gerileyebilirsiniz. Bunun sebebi CPU’nun RAM’i beklemesidir. Alternatif olarak bellek yönetimini elden geçirip RAM’e yükü azaltabilirsiniz, ama o zaman da işlemci gücü gerekir.

Swap Dosyaları Riski

Eğer sistem RAM’i dolarsa, işletim sistemi diski takas (swap) alanı olarak kullanmaya başlar. Bu, LLM çıkarımı için felakettir. Disk G/Ç işlemi, RAM’e kıyasla iki büyüklük derecesi daha yavaştır. Sistem donar ve verileriniz kaybolabilir.

Bunu önlemek için, kaydırılan katmanları tutabilecek kadar sistem RAM’inize sahip olduğunuzdan emin olmalısınız. 40GB civarı yer kaplayan Q4_K_M formatında bir 70B modeliniz varsa ve 64GB RAM’iniz varsa, işletim sistemi ve diğer işlemler için geriye sadece 24GB kalır. Bu sıkışık bir durumdur. Sistem bellek kullanımını sürekli izlemeniz gerekir.

Operatör Notları: “Swap” Paniği

Sisteminizde takas (swap) gördüğünüz an, çıkarımı hemen durdurun. Takas veriyi bozabilir ve GPU sürücüsünü çökebilir. Her zaman bir güvenlik payı bırakın. RAM’inizin %100’ünü kullanmayın. İşletim sistemi için en az %10-15 boşluk bırakın. Alternatif olarak sanal bellek boyutunu kısıtlayıp sistemi korumaya almak da bir seçenektir.

Dağıtım Öncesi Donanım Denetimi: Stabilite için Kontrol Listesi

Modelleri çalıştırmaya başlamadan önce donanımı denetlemeniz şart. Bu bir lüks değil. Bağırsızız denetim, dağıtımın çökmesiyle sonuçlanır. Kurulumunuzu doğrulamak için bu listeyi kullanın.

• ☐ GPU Uyumluluğu: Tüm GPU’ların NVIDIA veya AMD (tutarlı) olduğundan emin olun. Aynı çoklu-GPU kurulumunda NVIDIA ve AMD kartları karıştırmayın (sürücü uyumsuzlukları kaçınılmaz olur).
• ☐ PCIe Topolojisi: Tüm GPU’ların aynı PCIe kök kümesinde olup olmadığını kontrol edin. NVLink veya yüksek hızlı bir ara bağlayıcınız yoksa, GPU’ları farklı CPU yuvalarına bölmekten kaçının. Intel’nin QuickPath veya AMD’nin Infinity Fabric’i gibi alternatifler bile tam bant genişliği sağlamaz, gecikme artar.
• ☐ Güç Kaynağı: PSU’nun yeterli marjı olduğundan emin olun. İki adet 3090, anlık olarak 700W’ı geçebilir. Yeterli raylere sahip en az 1000W+ bir PSU şarttır. Ucuz veya kalitesiz güç kaynakları yük altında anında kilitlenir.
• ☐ Soğutma: Hava akışını doğrulayın. Küçük bir kasa içinde iki GPU ısıya karşı direnç göstermez. Sıvı soğutma veya yüksek statik basınçlı fanlar şarttır. Fanlar tıkalı olduğunda sistem koruma kipiyle kapanır, bu bir sorun değil, bir kurtarıcıdır.
• ☐ Sürücü Sürümü: CUDA sürücülerinin güncel olduğundan emin olun. Eski sürücüler, OOM (Yetersiz Bellek) hatalarının en yaygın sebebidir. Neden? Çünkü yeni modeller eski sürücülerin bellek yönetimini atlar.
• ☐ Sistem RAM’i: Önekleme (offloading) için yeterli sistem RAM’iniz olduğundan emin olun. Beklenen önekleme durumunda modeli boyutunun en az 2 katı RAM hedefleyin. DDR5 kullanmak zorunda değilseniz, eski DDR4 bile yeterli olabilir ama hız farkını göreceksiniz.
• ☐ Swap Alanı: Swap’ı devre dışı bırakın veya çöküşleri önlemek için çok büyük bir dosya olarak ayarlayın (ama değiştirme işleminden tamamen kaçınmak en iyisidir). Swap kullanımı, SSD ömrünü hızla tüketir ve performansı felç eder. Sanal belleğe ihtiyacınız varsa, fiziksel RAM eksikliğine dikkat edin.

Çoklu GPU Konfigürasyonu Doğrulama: Adım Adım Rehber

Donanım denetimi tamamlandıktan sonra, yazılımın doğru yapılandırıldığını teyit etmelisin. Çoklu GPU kurulumunun beklendiği gibi çalışmasını sağlamak için şu adımları izle.

• ☐ Cihaz Tanıma: Tüm GPU’ların görünür ve sağlıklı olduğunu doğrulamak için nvidia-smi komutunu çalıştır. Alternatif olarak, sürücü sorunlarında `lspci`’yi kontrol et ama asıl kanıt burada.
• ☐ CUDA Bağlamı: Tüm cihazlarda CUDA bağlamının oluşturulduğundan emin ol. Bu basit adımlı atlanmazsa sistem sessizce hata vermez ama işlemez.
• ☐ Katman Ayrımı: Katmanların GPU’lar arasında bölündüğünü teyit etmek için loglara bak. “Layer 0-20 on GPU 0, Layer 21-50 on GPU 1” gibi mesajları ara. Bir kartın yükü taşırken diğeri boşsa, ayrım mantığın bozuk demektir.
• ☐ Bellek Kullanımı: Her kartın VRAM kullanımını izle. Dengeli olmalı. Bir kart tıka doluyken diğerinin boş olması, paylaşım mantığının yanlış kurulduğunun en net kanıtıdır.
• ☐ Performans Tabanı: Küçük bir test isteği gönder. Token oluşturma hızını ölç. Tek GPU performansıyla kıyaslayarak hızlanma (speedup) elde edip etmediğini netleştir. Tekil bir GPU’nun ısınma sorunuyla yavaşlaması, çiftliğin avantajını maskeleyebilir.
• ☐ Stres Testi: 30 dakikalık uzun süreli bir çıkarım (inference) çalıştır. Termal darbe (throttling) veya sürücü çöküşlerini kontrol et. İlk bozulan genellikle soğutma sistemidir, sadece yazılıma güvenme.
• ☐ Paralellik Testi: Aynı anda birden fazla istek gönder. Sistemin yük altında çökmeden yönetebildiğini teyit et. Birden fazla akışta bellek bariyeri olmaksızın çalışmazsa, mimarin gerçek bir çoklu kullanıcı senaryosu için hazır değil demektir.

Inference Motoru Özellik Matrisi

Doğru motoru seçmenize yardımcı olmak için Ollama, vLLM ve llama.cpp’nin ana metrikler üzerindeki doğrudan karşılaştırması. Not edin: En ucuz çözüm her zaman en az sorunu yaşamaz; beklenen ömür ve faturalara göre karar verin.

Topolojiye Göre Çoklu GPU Performans Beklentileri

Çoklu GPU kurulumlarında performans artışı bus topolojisine doğrudan bağlıdır. Donanıma göre hızlandırma oranları ciddi farklılıklar gösterir. Alternatif olarak PCIe üzerinden yapılan bağlantıların maliyeti daha düşük olsa da, NVLink gibi özel bağlantılarda ortaya çıkacak darboğazlar sistemin tüm ömrü boyunca yavaşlatıcı etki yapar. Beklentinizi geride bırakacak en zayıf halka hemen fark edilir.

Not: Bunlar 70B parametreye sahip bir model için tahminlerdir. Daha küçük modellerde bu fayda daha azdır, daha büyük modellerde ise VRAM ihtiyacından dolayı daha fazla fayda sağlanabilir. Ancak donanımın eski olması durumunda soğutma ve elektrik maliyetleri performans artışıyla orantılı olmayacaktır.

Donanım Arıza Modu Analizi

Çoklu GPU kurulumları belirli arıza modlarına yatkındır. Bunu anlamak saatler süren sorun giderme sürecini kurtarır. Çoklu kartlı yapılar tek bir karta göre daha fazla nokta atışı arıza üretir; soğutma ve güç kaynağı ilk olarak göç eder.

Sorun Giderme: Çoklu GPU Başarısız Olduğunda

En iyi planlamaya rağmen şeyler ters gider. İşte sık yaşanan sorunlar ve çözümleri.

Sorun 1: GPU 0’da “CUDA out of memory”

Bu genellikle modelin doğru bölünmediğini gösterir. GPU 0, çok fazla katmanı yüklemeye çalışıyor.
* Düzeltme: İkinci GPU için --ngl parametresini artırın veya modeli manuel olarak bölün. Eğer tek GPU’ya sığmıyorsa alternatif olarak model boyutunu küçültmek veya belleği artırmak daha mantıklı bir çözüm olabilir.

Sorun 2: Performans, tek GPU’ya göre daha yavaş

Bu durum genellikle PCIe bant genişliğinin darboğaz yarattığında ortaya çıkar.
* Düzeltme: Modeli tek bir GPU’ya sığdırabileceğinizden emin olun. Yoksa, gecikmeyi kabullenin. PCIe yollarının Gen4 modunda çalıştığını kontrol edin. Alternatif olarak, model boyutunu PCIe slot hızınıza göre yeniden boyutlandırmayı düşünebilirsiniz.

Sorun 3: Bir GPU boş, diğeri tam dolu

Bu kötü bir bölünme işaretidir.
* Düzeltme: Logları kontrol edin. Modelin eşit şekilde bölündüğünden emin olun. Modelin katman boyutları düzensizse, bölünmeyi ayarlamanız gerekebilir. Bu durumda model dağıtımını elle düzenlemek en kesin çözümdür.

Sorun 4: Sistem birkaç dakika sonra çöker

Bu muhtemelen ısıl veya güç sorunu.
* Düzeltme: Sıcaklıkları kontrol edin. PSU’nun aşırı yüklenmediğinden emin olun. Gerçekçi beklenmedik bir sorun, kısa sürede voltaj düşüşüne yol açan zayıf güç kaynaklarıdır; bunları değiştirmek zorundasınız.

Pratik Senaryo: İki RTX 3090 Üzerinde 70B Modeli

Tamam, elinde iki RTX 3090 (her biri 24GB) var ve Llama 3 70B’yi çalıştırmak istiyorsun.

1. Model Boyutu: Q4_K_M quantize’ında 70B model yaklaşık 40GB yer kaplar.
2. Toplam VRAM: 48GB.
3. Bölünme: Modeli ikiye bölersin: 20GB GPU 0’da, 20GB GPU 1’de.
4. Performans: Tek bir 24GB kart (ki bu modeli hiç çalıştıramaz) yerine 1.5x hız beklentisi.
5. Gerçeklik: PCIe Gen4 darboğazı yüzünden elde ettiğin hız 1.3x olur. Beklentini boşa çıkarma.
6. Güç: Sistem 700W çeker.
7. Maliyet: Elektrik faturasına ayda ek $50 yansıyacak.
8. Yargı: Çalışıyor evet, ama pahalı ve gürültülü. Tek bir kartta 34B model çalıştırabiliyorsan, bunu tercih et. Alternatifler her zaman daha mantıklıdır.

Sıkça Sorulan Sorular

Çoklu GPU çıkarımı için NVIDIA ve AMD kartlarını birleştirilebilir mi?
Genellikle hayır. Çoğu çıkarım yığın yazılımı (Ollama, vLLM, llama.cpp) NVIDIA için CUDA ve AMD için ROCm kullanır. Bu sürücü ekosistemleri tek bir çıkarım işiyle uyumlu değildir. Bir modeli aynı işlemde NVIDIA ve AMD kartları arasında bölemezsiniz. Ayrı instance’lar olarak çalıştırmak zorunda kalırsınız ki bu, çoklu GPU ölçeklendirmesinin amacını ortadan kaldırır.

İkinci bir GPU eklemek hızı her zaman iki katına çıkarır mı?
Hayır. PCIe bant genişliği darboğazı ve senkronizasyon yükü nedeniyle hız artışı nadiren doğrusaldır. Genellikle yığın topolojisine bağlı olarak %1.3 ile %1.8 arasında bir artış elde edersiniz. Bazı durumlarda, model çok küçükse, yük nedeniyle ikinci bir GPU eklemek sizi yavaşlatabilir.

Toplam VRAM’ı aşan modellerle nasıl başa çıkılır?
Üç seçeneğiniz var:
1. Quantize: Hafıza izdüşümünü azaltmak için daha düşük hassasiyet kullanın (örn. Q3_K_S).
2. Offload: Katmanları sistem RAM’ine taşıyın. Bu, çıkarımı ciddi şekilde yavaşlatır.
3. Dağılın: İki’den fazla kartınız varsa, katmanları daha fazla kart arasında dağıtabilirsiniz.

Çoklu GPU performansını izlemenin en iyi yolu nedir?
GPU kullanımı ve hafızasını izlemek için nvtop veya htop kullanın. Katman dağıtım mesajları için çıkarım motorunuzun loglarını kontrol edin. Token/saniye hızını ölçmek için bir benchmark aracını kullanın.

PCIe Gen5 anakarta yükseltmek mantıklı mı?
Duruma bağlı. Eğer PCIe Gen4 kartınız varsa, Gen5 fazla bir şey katmayacaktır. Gen4 kartlarınız ve Gen5 anakartınız varsa, küçük bir artış elde edebilirsiniz. Ancak Gen5 anakart ve CPU maliyetleri yüksek. Çoğu homolab için Gen4 yeterlidir.

Sonuç: İşe En Uygun Aleti Seçmek

Ollama, vLLM ve llama.cpp arasında çoklu GPU çıkarımı için yapılacak tercih, “en iyi” olanı seçmek değil, kısıtlarınıza en uygun olanı bulmak meselesidir.

• Ollama’yı seçin eğer kişisel kullanım veya küçük bir ekip için basit, kullanıcı dostu bir kurulum istiyorsanız. Karmaşıklığı sizin için halleder, ancak esneklik ve eşzamanlı işlem kapasitesinden feragat edersiniz.
• vLLM’i seçin eğer yüksek iş hacmi, düşük gecikme ve eşzamanlı isteklere ihtiyacınız varsa. Üretim benzeri bir homelab sunucusu için en iyi seçenek budur; ancak daha fazla yapılandırma ve kaynak gerektirir.
• llama.cpp’i seçin eğer maksimum kontrol, özel quantization (nicemleme) veya standart olmayan donanımda çalıştırma ihtiyacınız varsa. En esnek olandır ancak yönetimi en karmaşık olandır.

Hangi seçimi yaparsanız yapın, donanım topolojisinin nihai kısıt olduğunu unutmayın. PCIe busu tüketiciler için her zaman darboğaz olacaktır. Elektrik faturası her zaman bir faktördür. Stabilite ise hep bir taviz meselesidir.

Benzersiz benchmark sonuçlarına kafa yormayın. Belirli kullanım senaryonuz için güvenilir çalışan bir sistem kurun. 70B’lik bir model çalıştırmanız gerekiyorsa, iki GPU alın ve PCIe cezasını kabul edin. Hızlı bir asistan istiyorsanız tek bir büyük kartla başlayın ve gereksiz düşünceyi bırakın.

Homelab’ın gerçek gücü, en pahalı donanıma sahip olmada değil, sahip olduğunuz donanımın sınırlarını anlamada gizlidir. Bu bilgiyle verimli, kararlı ve ekonomik bir sistem kurun. Elektrik faturası, işin sonunda tek önemlidir.