--- title: "MoE Offloading Benchmark Testlerimi Yeniledim: Bazı Sonuçlarım Değişti" url: https://blog.edumints.com/moe-offloading-benchmark-testlerimi-yeniledim-bazi-sonuclarim-degisti category: "LLM" date: 2026-11-01T08:06:27.712Z publisher: Edumints Blog lang: tr-TR source_name: "dev.to" source_url: https://dev.to/sizzlebop/i-retested-my-moe-offloading-benchmarks-some-of-my-conclusions-changed-6f4 --- # MoE Offloading Benchmark Testlerimi Yeniledim: Bazı Sonuçlarım Değişti Yakın zamanda dizüstü bilgisayarımda **Mixture-of-Experts (MoE) offloading** (yük devretme) deneylerim üzerine bir çalışma gerçekleştirmiştim. Beş farklı modeli test etmiş, geleneksel katman (layer) bölme yöntemi ile seçici uzman (selective expert) yük devretme yöntemini karşılaştırmış ve oldukça ilginç sonuçlar elde etmiştim. Bazı modeller seçici yük devretme ile daha iyi performans gösterirken, diğerleri geleneksel katman bölme ile çok daha hızlıydı. Özellikle **LFM2.5** modeli seçici yük devretmede o kadar kötü performans göstermişti ki bunun altında yatan nedeni gerçekten çözmek istedim. Yazılım topluluğundan gelen değerli geri bildirimler, hesaba katmadığım noktaları görmemi, varsayımlarımı sorgulamamı ve daha sağlıklı test yöntemleri geliştirmemi sağladı. Bu geri bildirimler ışığında, tutarlı niceleme (quantization) ve tekrarlanan ölçümlerle 16GB GPU deneyimi yeniden tasarladım; bu kez sonuçların bir kısmı oldukça farklı çıktı. ## İlk Olarak, Nelerin Düzeltilmesi Gerekiyordu? İlk deneyde, GPU'mun VRAM kapasitesine tamamen sığmayacak kadar büyük modelleri çalıştırırken seçici MoE yük devretmenin performansı artırıp artırmayacağını test ediyordum. Temel fikir, belirli işlemleri GPU üzerinde tutarken seçici uzman ağırlıklarını (expert weights) ve hesaplamalarını CPU'ya aktarmaktı. Bunun için **llama.cpp** üzerinde `--n-cpu-moe` seçeneğini kullandım ve bunu `-ngl` kullanan geleneksel katman bölme yöntemiyle karşılaştırdım. Ancak ilk test sürecimde metodolojik açıdan iki temel sorun vardı: - **Farklı Niceleme (Quantization) Seviyeleri:** Modellerin tamamı aynı niceleme seviyesini kullanmıyordu. Phi-3.5 **Q4_K_M**, Apex **Q5_K_M**, Qwen **Q6_K** ve Gemma ile LFM **Q8_0** seviyesinde çalışıyordu. Bu durum, performans farklarının model mimarisinden mi, nicelemeden mi yoksa başka bir faktörden mi kaynaklandığını anlamayı zorlaştırıyordu. Özellikle LFM modelinin kötü performansında bu durum kritik bir rol oynuyordu. - **Yetersiz Tekrar ve Termal Gürültü:** Yeterince tekrarlı ölçüm yapmamıştım. Dizüstü bilgisayarın termal durumu (ısınma), arka plan işlemleri ve olağan ölçüm gürültüsü sonuçları etkileyebilirdi. Bir stratejiyi tamamen bitirip diğerine geçmek yerine, yapılandırmaları dönüşümlü (interleaved) olarak çalıştırmak gerekiyordu. ## Yeni Test Kurulumu Testlerde aynı dizüstü bilgisayar donanımını kullanmaya devam ettim: - **GPU:** NVIDIA RTX 4090 Laptop GPU, 16GB VRAM - **CPU:** Intel Core i9-14900HX, 24 çekirdek / 32 iş parçacığı (threads) - **RAM:** 32GB DDR5 - **İşletim Sistemi:** CachyOS / Arch Linux - **Çıkarım Motoru (Inference Engine):** CUDA ve Flash Attention etkinleştirilmiş llama.cpp Ancak test sürecinde ve yazılım yapılandırmasında önemli değişiklikler yaptım: - **Standart Niceleme:** Beş modelin tamamı artık **Q4_K_M** seviyesinde çalıştırıldı. - **Güncel Ortam ve Bellek Yönetimi:** **llama.cpp** güncellendi, yük devretme yapılandırmaları daha küçük nicelenmiş modellere göre ayarlandı ve GPU'yu bellek sınırına kadar zorlamamak için yeterli boş VRAM bırakıldı. - **Standart İstem (Prompt):** Her model için aynı istem kullanıldı: *"What are 3 practical benefits of using Arch Linux?"* (Arch Linux kullanmanın 3 pratik faydası nedir?) - **Isınma ve Dönüşümlü Ölçüm:** Ölçümden önce her yapılandırmaya bir ısınma (warmup) isteği gönderildi. Ardından, çalıştırmalar arasında kısa soğuma (cooldown) süreleri bırakılarak, dönüşümlü sırayla her strateji için üç tekrarlı ölçüm yapıldı. ## Geliştiriciler İçin Pratik Çıkarımlar Yerel LLM çıkarımı (inference) ve performans optimizasyonu yapan mühendisler için bu süreç önemli dersler barındırır: - **Değişkenleri İzole Edin:** Mimari veya yük devretme stratejilerini kıyaslarken tüm modellerin aynı niceleme (**Q4_K_M** gibi) seviyesinde olduğundan emin olun; aksi halde bellek bant genişliği darboğazlarını mimari farklarla karıştırabilirsiniz. - **VRAM Sınırında Çalışmayın:** GPU belleğini tamamen doldurmak sistemin kararsızlaşmasına veya gizli bellek takaslarına yol açar; her zaman güvenli bir VRAM payı bırakın. - **Dönüşümlü (Interleaved) Test Uygulayın:** Özellikle mobil/dizüstü donanımlarda termal kısma (thermal throttling) sonuçları yanıltır. Isınma turları eklemek ve testleri dönüşümlü çalıştırmak ölçüm gürültüsünü en aza indirir. Orijinal makaleye [buradan](https://dev.to/sizzlebop/i-retested-my-moe-offloading-benchmarks-some-of-my-conclusions-changed-6f4) ulaşabilirsiniz. --- Bu konuyu derinlemesine öğrenmek isterseniz: [Ölçeklendirme ve Optimizasyon](https://edumints.com/kesfet/embedding-ve-reranking-modelleri-productionda-depl-blu6) modülüne göz atın. --- **Kaynak:** dev.to (https://dev.to/sizzlebop/i-retested-my-moe-offloading-benchmarks-some-of-my-conclusions-changed-6f4) **Yayıncı:** [Edumints Blog](https://blog.edumints.com) · Alıntılarken bu URL'ye bağlantı verin: https://blog.edumints.com/moe-offloading-benchmark-testlerimi-yeniledim-bazi-sonuclarim-degisti