RAM'den büyük MoE LLM'leri çalıştırmak: expert offloading ve SSD streaming için llama.cpp rehberi

dev.to'da yayımlanan bir rehber, kulağa çelişkili gelen bir senaryoyu ele alıyor: ağırlık dosyası makinenin toplam belleğinden daha büyük bir dil modeli çalıştırmak. Yazar bunun yalnızca Mixture of Experts (MoE) mimarileri için işe yaradığını ve üç unsuru bir araya getirdiğini açıklıyor: memory-mapped model dosyaları, llama.cpp'nin tensör yerleşim bayrakları ve hızlı bir NVMe disk tarafından desteklenen işletim sisteminin sayfa önbelleği.

Yazı, yazarın Hacker News'te gördüğü ve expert ağırlıklarını SSD'den talep üzerine akıtan Janas adlı projeden ilham aldı. Yazarın kendi başlangıç noktası ise 100 milyar parametreyi aşan bir MoE modelini 32GB'lık bir dizüstü bilgisayara sığdırma denemesiydi — bu çaba önce makineyi tamamen dondurdu, sonra doğru yapılandırıldığında saniyede yaklaşık 8 token üretti.

Seyrek modeller neden sığar, yoğun modeller neden sığmaz

Llama 3.1 70B gibi yoğun bir modelde her token ağırlık setinin tamamından geçmek zorundadır. Bu ağırlıklar RAM'e sığmıyorsa her token gigabaytlarca disk okuması tetikler ve saniyede yaklaşık 7 GB/s hızındaki bir Gen4 NVMe disk bile ancak birkaç saniyede bir token üretebilir; yazar bunu fiilen kullanılamaz olarak nitelendiriyor.

MoE modelleri farklı davranır. Rehbere göre gpt-oss-120b toplamda kabaca 117 milyar parametre taşıyor ama token başına yalnızca yaklaşık 5,1 milyarını aktive ediyor; Qwen3-30B-A3B ise toplam 30 milyar parametreye sahip ve yaklaşık 3 milyarı aktif. Her katmandaki bir router az sayıda expert'i seçiyor — genellikle 128'e ulaşabilen havuzlardan top-4 veya top-8 — ve geri kalanına dokunmuyor.

Yerleşim de bu ayrımdan doğuyor. Attention katmanları, embedding'ler ve paylaşılan bileşenler her token'a dokunuyor ama küçükler; bu yüzden VRAM'de yer almalılar. Expert FFN ağırlıkları dosya boyutunun büyük kısmını oluşturuyor ama token başına yalnızca küçük bir bölümü okunuyor; dolayısıyla RAM'de yaşayabilir ve bellek yetmezse SSD'den sayfalabilir. Router'lar benzer türden prompt'larda sıcak bir expert kümesini yeniden kullanmaya eğilimli olduğundan, Linux sayfa önbelleği bunları doğal olarak bellekte tutarken soğuk expert'ler diskte kalıyor. Janas ve benzeri projeler bunun üzerine prefetching ve expert başına LRU önbellekleme ekliyor, ancak yazar llama.cpp'nin varsayılan mmap davranışının faydanın çoğunu zaten yakaladığını savunuyor.

İndirmeden önce boyutlandırmak

Rehber, gguf paketiyle GGUF metaverisini ayrıştıran ve tensör boyutlarını toplayarak expert tensörlerini (ffn_*_exps adlandırma kuralıyla tanımlanan) diğerlerinden ayıran kısa bir Python betiği içeriyor. Yaklaşık 120 milyar parametreli bir modelin Q4 derlemesi için yazar, 8GB'lık bir GPU'ya yetecek kadar yalnızca birkaç GB expert olmayan ağırlık ölçmüş; expert ağırlıkları ise yaklaşık 55-60GB.

Yazarın pratik kuralları şöyle: RAM expert boyutunun yüzde 70'i veya üzerindeyse hız, tamamen RAM'de çalıştırmaya yakın olur; yüzde 40 ile 70 arasındaysa model kullanılabilirdir ama hız prompt'a göre değişir ve konu değiştirmek kısa bir yavaşlamaya neden olur; yüzde 40'ın altındaysa daha küçük bir quant veya model daha iyi bir seçimdir.

llama.cpp'yi yapılandırmak

2025'in ortasından beri llama.cpp, tensörlerin nerede yaşayacağına ince ayar yapmak için --n-cpu-moe ve --override-tensor (-ot) sunuyor. Yazarın örneği -ngl 99 ile tüm katmanları GPU'ya devrederken -ot ".ffn_.*_exps.=CPU" ile expert'leri CPU'da tutuyor ya da ilk 30 katmanın expert'lerini CPU'da bırakmak için daha kısa olan --n-cpu-moe 30 bayrağını kullanıyor ve sayıyı VRAM sığana kadar ayarlıyor.

Rehber ayrıca deneme yanılma ile öğrenilen tuzakları listeliyor. Model RAM'i aştığında --no-mmap eklemek tam yüklemeye zorlar ve süreç OOM killer tarafından öldürülür; varsayılan mmap hangi sayfaların kalacağına çekirdeğin karar vermesine izin verir. --mlock da atlanmalı, çünkü her sayfayı RAM'e kilitlemek hemen başarısız olur. Thread sayısı (-t) mantıksal çekirdekler değil fiziksel çekirdeklerle eşleşmeli, çünkü CPU'daki expert matmul'ları bellek bant genişliğine bağlıdır ve hyperthread'ler işleri yavaşlatabilir. VRAM'de yer kaldığında ise --n-cpu-moe değerini düşürmek expert katmanlarını GPU'ya taşır ve her biri için birkaç yüzdelik ek hız sağlar.

SSD'nin darboğaz olup olmadığını kontrol etmek

Üretim beklenenden yavaşsa yazar önce diski kontrol ediyor. Önerilen araçlar arasında okuma verimi için iostat -xm 1 nvme0n1 var — üretim sırasında sürekli çok-GB/s okumalar thrashing işaretidir, yani çalışma seti RAM'i aşıyor — ayrıca major page fault'lar için ps -o maj_flt; burada ilk birkaç düzine token boyunca bir patlama normal ısınmadır. vmtouch, model dosyasının ne kadarının bellekte (resident) olduğunu gösterir ve demo öncesi önbelleği ısıtabilir. Apple Silicon'da unified memory VRAM/RAM sınırını kaldırır ve tek önemli sayı toplam RAM olur; sudo fs_usage -f diskio sürece filtrelendiğinde disk baskısını ortaya çıkarır.

Neden önemli

Daha geniş argüman ekonomiktir: güçlü GPU'lar ve kiralanan bulut instance'ları pahalıdır, bu yüzden mevcut donanımdan maksimum değer çıkarmak değerli bir beceridir. Pratik çıkarımlar şunlar: kısıtlı makinelerde yoğun modeller yerine MoE'yi tercih edin — yazar, 16GB'lık bir dizüstünde 30B-A3B modelinin genellikle agresif şekilde quantize edilmiş yoğun bir 14B'yi yendiğini söylüyor — büyük modeller düzenli bir iş yüküyse GPU yükseltmeden önce bir Gen4 NVMe disk alın ve tahmin etmek yerine iostat ve vmtouch ile ölçüm yapın, çünkü yavaşlamalar genellikle CPU sınırlarından değil thrashing'den kaynaklanır. Janas gibi router-farkında prefetch projeleri yaklaşımı daha da ileri taşıyor, ancak mmap artı tensör yerleşimi taban çizgisi tek başına artık tüketici donanımının bir yıl önce bir sunucu gerektirecek modelleri çalıştırmasına izin veriyor.