Geçen ay, Şubat 2026’nın ilk haftasında İstanbul’daki masamda aynı anda üç farklı LLM çalıştırmaya kalkıştım. Hani “bir model yeter” diyenler olur ya… İşte tam orada işler dağıldı. Biri hızlıydı ama yüzeysel kaldı, biri daha derin düşündü ama yavaşladı, üçüncüsü de arada bir GPU belleğine çarpıp duvara tosladı. Açık konuşayım — bu tabloyu görünce aklıma şu geldi: yerel inference tarafında hâlâ ciddi bir boşluk var.
İtiraf edeyim, Bu boşluğu doldurmaya çalışan EIE adlı proje de tam buradan doğuyor. Yazarın yaptığı şey sadece “bir sunucu yazmak” değil; aynı zamanda çoklu model düzenini, grup mantığını. GPU belleği yönetimini tek pakette düşünmek. Bakın şimdi, mesele sadece modeli ayağa kaldırmak değil. Asıl iş, birkaç modeli aynı anda konuşturup onlardan sağlam bir cevap çıkarabilmek.
Neden mevcut araçlar yetmiyor?
Ollama’yı severim, yanlış anlaşılmasın (kendi tecrübem). Kurulumu rahat, kullanım eşiği düşük. Çoğu kişi için gayet iş görüyor. Ama benzer testleri kendi küçük laboratuvarımda — Kadıköy’deki ofiste, iki RTX kartlı bir sistemde — yapınca şunu net gördüm: modelleri sırayla değiştirerek çalıştıran yapı bazı senaryolarda fazla dar kalıyor.
Bi saniye — Mesela güvenlik analizi yapan bir ekip düşünün. Aynı prompt’u üç ayrı modele veriyorsunuz; biri tehdit avlıyor, biri bağlamı yorumluyor, biri de hatalı alarmı eliyor, sonra bunları yan yana koyup ortak karar çıkarıyorsunuz — bu yaklaşım bence fena değil, hatta baya işe yarıyor, çünkü tek modelin kör noktası öbürünün güçlü tarafıyla dengelenebiliyor. Klasik çözüm mü? Ona geliyorum.
Çok konuştum, örnekle göstereyim.
Gel gelelim klasik sunucuların çoğu bunu doğal olarak desteklemiyor. vLLM daha çok bulut ölçeğine göz kırpıyor. llama.cpp server ise pratik ama genelde tek model etrafında dönüyor (yanlış duymadınız). Çoklu model deliberation dediğimiz şey… nasıl desem… onların standart kullanımının biraz dışında kalıyor. Tam merkezine oturmuyor.
EIE aslında ne yapıyor?
Elyne Inference Engine ya da kısa adıyla EIE, GGUF modeller için yerel bir inference sunucusu gibi çalışıyor. OpenAI uyumlu REST API sunuyor, modelleri yüklüyor ve GPU belleğini idare ediyor. Hepsi bu kadar mı? Kâğıt üstünde evet. Ama asıl değer tam burada başlıyor — ürün bilerek dar tutulmuş.
Size bir şey söyleyeyim, Bunu seviyorum doğrusu. Her şeyi içine tıkıştırmaya çalışan platformlardan — en azından ben öyle düşünüyorum — sıkıldım artık! Agent katmanı yok, RAG motoru yok, görsel arayüz yok; yalnızca completions servis ediliyor (en azından benim deneyimim böyle). Ben buna “iyi sınır çizilmiş mühendislik” diyorum.
2024’te benzer bir yapıyı Ankara’da yürüttüğümüz küçük bir kurumsal projede denemiştik; orada en büyük sorun bellek değil karmaşıklıktı, her bileşen başka yere çekiyordu sistemi ve sonunda kimse neyin nerede bozulduğunu anlayamıyordu, o kaotik tabloyu yaşayanlar bilir. EIE’nin sade duruşu o yüzden bana mantıklı geliyor.
Sade ama keskin yaklaşım
Bazı araçlar ilk bakışta büyüleyici oluyor. İki hafta sonra? Bakım cehennemine dönüşüyorlar. EIE ise bunun tersine gidiyor gibi duruyor: az özellikli ama net amaçlı bir çekirdek sunuyor, geri kalan katmanları sizin inşa etmenizi bekliyor.
Küçük startup’lar için güzel haber bu — gereksiz kabarıklık yok, kurarsınız, test edersiniz, ilerlersiniz. Enterprise tarafta ise olay biraz daha hassaslaşıyor tabii. Entegrasyon politikaları, izleme sistemleri ve hata toleransı devreye giriyor. Beklenti yönetimi kritik.
| Klasik yaklaşım | EIE yaklaşımı |
|---|---|
| Tek model odaklı çalışma | Model gruplarıyla paralel çalışma |
| Sınırlı failover mantığı | Strict / partial / retry_önce / replace_with seçenekleri |
| Sabit bellek davranışı | Policy Engine ile dinamik strateji seçimi |
| Karma UI ve ek modüller | Sadece inference servisi |
Model grupları neden önemli?
Açık konuşayım: benim en sevdiğim bölüm burası oldu. Çünkü grup fikri teoride basit görünse de pratikte oyunu değiştiriyor. Artık “hangi modeli çağırdın?” sorusundan ziyade “bu grubun davranışı nasıl?” sorusuna geçiyorsunuz. Küçük ama önemli fark.
EIE içinde örnek olarak core adlı bir grup tanımlanabiliyor; içinde mistral-7b, granite-3b ve exaone-2.4b gibi modeller yer alabiliyor ve her biri aynı prompt’u alıp paralel şekilde cevap üretebiliyor. Üstelik required_responses değeriyle kaç yanıt gerektiğini belirlemek mümkün. Bu kısım bana editör masasında gelen AI haberlerini ayıklarken kullandığımız çapraz kontrol mantığını hatırlattı — tek kaynağa güvenmiyorsun, birkaçından sinyal topluyorsun. Daha fazla bilgi için Muse’un Akıllı Uyandırma Hamlesi: Alarmı Beyniniz Seçiyor yazımıza bakabilirsiniz.
“Tek modelin cevabı bazen yeterli değildir; özellikle kilit kararlarda birkaç bağımsız görüş almak kaliteyi ciddi biçimde yükseltir.”
Üç farklı çalışma şekli var
- Parallel: Aynı prompt N modele gider, hepsi döner. (bence en önemlisi)
- Sequential: Bir modelin çıktısı diğerine giriş olur; mesela vision → language hattında iyi iş görür.
- Fan-out: Aynı soru birçok modele açılır ve en iyi cevap seçilir.
Bence parallel mod günlük kullanımda en dikkat çekici olanı. Gecikme pahasına olsa bile daha dengeli sonuç verebilir. Mesela siber güvenlik alarm triage senaryosunda yanlış pozitifleri azaltmak için birebir olabilir. Denediniz mi hiç böyle bir kurgu? Bu konuyla ilgili zekâ konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
TurboQuant desteği niye kafa açıcı?
Tamam, şimdi gelelim işin teknik yıldızına. TurboQuant native desteği burada önemli çünkü KV cache’i sıkıştırarak bellekte ciddi alan açmayı hedefliyor. Yazıda verilen sayılar dikkat çekici görünüyor — turbo3 yaklaşık beş kata yakın sıkıştırma vadediyor, turbo2 ise iyice agresifleşiyor. Kâğıt üstünde süper. Pratikte göreceğiz artık.
Küçük GPU’da nefes alma şansı
Bunu geçen hafta Bodrum’daki ev ofisimde test ederken hissettim diyebilirim. Orta sınıf kartta aynı anda iki büyük modeli tutmaya çalışınca bellek hemen gerilmeye başladı. Adaptive KV fikri burada devreye girince insan ister istemez düşünüyor: acaba latency spike gördüğünde otomatik düşüş yapmak gerçek hayatta ne kadar temiz çalışacak? Emin değilim açıkçası. Ama sanırım doğru yönde atılmış hamle bu.
{
"kv_cache": "turbo3",
"policy_engine": {
"health_check": true,
"adaptive_kv": true,
"fallback": "partial"
}
}Açık konuşayım, Bana göre bu tip sıkıştırmaların en büyük artısı maliyet tarafında çıkıyor. Bilhassa kendi donanımıyla yaşayan ekiplerde VRAM altın gibi değerli. Eksisi mi? Var tabii. Aşırı sıkıştırma bazı görevlerde kaliteyi törpüleyebilir, o yüzden her modeli körlemesine turbo2’ye çekmek pek akıllıca olmaz.
Politikayı kodla değil stratejiyle yönetmek güzel fikir mi?
Vallahi, Hmm… Burada anlatmak istediğim şey Policy Engine’in esnekliği. Scheduling davranışını hardcode etmeyip plugin’lerle çözmek bence olgun bir tercih olmuş. generic stratejisi isteğe bağlı yükleme yapıyor, LRU eviction kullanıyor; pinned-group N modeli sürekli açık tutuyor; fixed-appliance ise boot anından itibaren hazır geliyor (en azından benim deneyimim böyle)
Peki neden? Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Dürüst olayım: bu kısmın en hoşuma giden yani shared library ile yeni strateji eklenebilmesi oldu. Kod tabanını yeniden derlemeden politika değiştirmek özellikle üretimde hayat kurtarır. Bir startup için bu hız demek; enterprise içinse operasyon ekibinin daha az gece mesaisi yapması demek. Ciddi fark var.
Dört fallback modu ne sağlıyor?
- strict: Tüm istek başarısız olur; default davranış gibi düşünün.
- partial: Tamamlanan parçaları döndürür, eksikleri işaretler.
- retry_önce: Sorunlu modeli tekrar dener, sonra gerekirse partial’a düşer.
- replace_with: Yedek modele geçip akışı sürdürür.
“Bir model çökerse bütün zincir çökmemeli” hissi burada çok net verilmiş (buna dikkat edin). Bilhassa production ortamında slowloris gibi davranan ya da ara sıra zaman aşımı yapan modellere karşı böyle mekanizmalar şart. Geçen yıl İzmir’deki küçük SaaS müşterilerinden biri benzer sebeple pipeline’ını kilitlemişti; keşke o zaman böyle esnek fallback katmanı olsaydı diye düşündüm doğrusu. Tarayıcıda Çalışan Sıfır Kurulumlu API Yük Testi yazımızda bu konuya da değinmiştik. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Kime uygun, kime fazla gelir?
Küçük startup tarafında EIE baya cazip görünüyor. Elinizde sınırlı sayıda GPU varsa, birkaç modeli aynı anda koşturmak istiyorsanız (buna dikkat edin). Çıktıları uzlaştırmanız gerekiyorsa burası tatlı nokta olabilir. Hele ürününüz AI güvenliği, hukuk analizi veya finansal karar destek çevresinde dönüyorsa grup temelli tasarım gerçekten anlam kazanıyor.
Hani, Enterprise seviyede tablo biraz daha karmaşık. Orada monitoring, audit log, RBAC, versiyonlama gibi ihtiyaçlar büyüyor. EIE’nin sade mimarisi avantaj olduğu kadar eksiklik de yaratabilir; yani her şeyi siz eklemek zorunda kalabilirsiniz. Beklediğim kadar değildi dediğim yer tam da burası: hazır kurumsal çatı bekleyenler hayal kırıklığı yaşayabilir.
İlginç olan şu ki, Ha, bu arada şöyle düşünün: elinizde Lego seti var ama kutudan saray çıkmıyor, sadece sağlam parçalar çıkıyor. Sarayı siz kuruyorsunuz. Bu kötü mü? Değil. Sadece beklentiyi doğru ayarlamak gerekiyor.
Sahada hangi problemleri çözüyor?
Benim gördüğüm kadarıyla üç temel problemi hedef alıyor: bellek baskısı, çoklu çıktı toplama ve hata toleransı. İlk ikisi zaten bariz. Üçüncüsü ise genelde sonradan fark edilen sessiz kahraman. Bir istemci uygulaması açısından bakınca response’un yarıda kalması ile tamamlanmış. Eksik yanıt arasındaki fark sandığınızdan büyük.
Editörlük yaptığım günlerden biliyorum — özellikle otomasyon haberlerinde insanlar parlak özelliğe takılıyor ama edge case’i unutuyor. Buradaki edge case aslında ana hikâye olmuş; bir model yavaşladı mı, sistem tümden kilitlenmesin diye tasarım baştan bunu hesaba katmış. Bu yaklaşımı seviyorum çünkü sahicilik kokuyor.
Bana sorarsanız asıl kıymet adaptive behavior’da yatıyor. Health-check’e göre KV cache seviyesini aşağı çekebilmek kulağa ufak geliyor,. Pratikte uzun oturumlarda ciddi fark yaratabilir. Yine de dürüst olayım: otomatik optimizasyonların bazen yanlış pozitif üretme ihtimali var; o yüzden gözlem olmadan bırakılmaz.
Kısacası nerede parlıyor?
- Çoklu LLM değerlendirmesi gereken işler
- VRAM’in kıt olduğu lokal makineler
- Failover’ın kritik olduğu production senaryolar
- Strateji değişikliğinin sık yaşandığı AR-GE ortamları
Nerede zayıflar?
- Tek düze chatbot kurulumu isteyenler
- Hazır UI bekleyen ekipler
- Geniş entegrasyon paketlerini kutudan çıkmış halde isteyen kurumlar
Sıkça Sorulan Sorular
EIE Ollama yerine kullanılabilir mi?
Evet, bazı senaryolarda kullanılabilir. Hele bir de aynı anda birkaç modeli paralel çalıştırmak istiyorsanız daha uygun olabilir. Ama sade sohbet servisi istiyorsanız Ollama hâlâ rahat seçeneklerden biri.
TurboQuant gerçekten bellek kazandırır mı?
Evet, amaç tam olarak bu. KV cache’i küçülterek VRAM kullanımını azaltmayı hedefliyor (ben de ilk duyduğumda şaşırmıştım). Fakat kazanç miktarı modele ve işe göre değişebilir.
Model groups ne işe yarıyor?
Model groups sayesinde tek tek modeller yerine birlikte çalışan kümeler tanımlıyorsunuz. Böylece aynı prompt’u birçok modele göndermek, sonuçları toplamak ve hata durumlarını yönetmek kolaylaşıyor.
Bu sistem üretimde kullanılabilir mi?
Kullanılabilir gibi duruyor, fakat izleme, loglama ve operasyon katmanını iyi kurmak gerekiyor. Ham haliyle değil, iyi paketlenmiş altyapıyla anlam kazanıyor.
Kaynaklar ve İleri Okuma
Orijinal makale — I built an Ollama alternative with TurboQuant…
llama.cpp GitHub Sayfası
OpenAI API Dokümantasyonu
llama.cpp Server Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
