- Reddit /r/ollama alt dizininde paylaşılan soru ve yanıtların derlemesi
- 300 kişilik bir hukuk bürosunun sistem yöneticisi olarak, tüm çalışanlara ChatGPT benzeri yapay zeka tabanlı belge yazma ve düzeltme aracı sunmak isteniyor
- PII gibi hassas bilgileri korumak için harici servisler yerine LLM'yi doğrudan şirket içi sunucuda barındırma fikri değerlendiriliyor (giriş, 2FA, VPN vb. erişim kontrolleri uygulanarak)
- Temel sorular
- Kendi kurulan bir LLM sunucusu gerçekten 300'den fazla kullanıcıyı destekleyebilir mi?
- Birkaç PC+GPU yeterli olur diye düşünülüyordu; gerçekte bu ciddi bir eksik tahmin mi?
- Kullanıcı oluşturma/yönetimi büyük bir yük haline gelir mi?
- Gözden kaçan önemli noktalar var mı?
- LLM alanında uzman olunmadığı için ölçeklenebilirlik, operasyon yükü ve uygulanabilirlik konusunda gerçekçi tavsiyeler isteniyor
Başlıca yanıtların özeti
1. Donanım, performans sınırları ve maliyet
- Ticari modeller (ör. ChatGPT) seviyesinde bir performans bekleniyorsa, yüz binlerce dolarlık pahalı GPU kümeleri gerekir (tahmin: $200,000~$1,000,000+)
- Açık kaynak modellerle (30B~70B parametre sınıfı) daha küçük ölçekte kalınırsa, performans düşüşü (gecikme, çıktı kalitesi) kabullenilmelidir. 10~40 eşzamanlı kullanıcı bile sınır olabilir
- 10 kişinin altında eşzamanlı kullanım varsayımıyla başlayıp, kademeli genişleme (sunucu ekleme) yaklaşımı öneriliyor
- Yerel ortam yerine buluttan GPU kiralamak daha ekonomik ve esnek olabilir
2. PoC (pilot) ve kademeli yaklaşım önerisi
- 1 sunucu + 1 GPU ile PoC (pilot) kurup, gerçek iş senaryoları ve yük ölçüldükten sonra büyütme öneriliyor
- Çok sayıda eşzamanlı istekte kuyruk sistemi şart; gerçek kullanıcı eşzamanlılığı 300 değil 10~30 seviyesinde olabilir
- Kısa vadede küçük modeller (3B~13B parametre) + iş istasyonu kombinasyonuyla deneme yapılabilir
3. Bulut/hibrit/alternatif seçenekler
- Bulut tabanlı LLM'ler (API, VPS, Azure, AWS Bedrock vb.) şirket içi altyapıyla entegre edilerek, güvenlik gereksinimlerine uygun hibrit bir yapı öneriliyor
- Kendi kendine barındırmada güvenlik, performans ve maliyet yükü yüksek; pratikte ChatGPT Enterprise/Teams, Microsoft Copilot Studio gibi ticari çözümler daha verimli olabilir
- Hukuki veri ve PII işleme için güvenlik gereksinimlerinin mutlaka incelenmesi gerekiyor
4. Diğer operasyonel, yönetimsel ve teknik konular
- Kullanıcı yönetimi/kimlik doğrulama: AD entegrasyonu, OAuth veya özel kimlik doğrulama ile sadeleştirilebilir
- Model seçimi/ince ayar: gerçek kullanım amacına (ör. belge düzeltme) uygun orta-küçük ölçekli açık kaynak modellerin (
LLama, Deepseek, Gemma, Qwen vb.) test edilmesi öneriliyor
- RAG, caching, load balancing vb. ek çözümlerin değerlendirilmesi mümkün
- Gerçek kullanım senaryolarının tanımlanması ve PoC ile uygun bütçe/ROI doğrulaması gerekli
Öne çıkan yanıtların derlemesi
ithkuil
- Ticari modellerle kıyaslandığında açık kaynak modellerde performans farkı büyük; 300 kişilik ölçekte çok yüksek donanım yatırımı gerekebilir
- Önümüzdeki 2 yılda donanım ve açık modellerin gelişmesi umut verici olabilir
SlimeQ
- Tek instance + kuyruk ile küçük başlamayı, kullanım arttıkça kademeli büyümeyi öneriyor
- 300 kişinin tamamının aynı anda kullanması mümkün değil; gerçek kullanım ölçülerek genişleme kararı verilmeli
Ok-Internal9317
- Gerçek eşzamanlı kullanıcı sayısı 10'un altında olabilir; 4~5 GPU yeterli bile olabilir
- Uzun vadede API maliyeti, kendi donanımını kurmaktan daha ekonomik olabilir
dyoh777
- Ollama+WebUI ile kolayca demo yapılabilir, ancak model kalitesi belirleyici
careful-monkey
- Mac Studio + yüksek RAM ile küçük modeller çalıştırılabilir; hız yaklaşık 20 token/sec
tshawkins
- Microsoft Copilot Studio gibi SaaS tabanlı çözümleri öneriyor; Power Platform içinde entegre çalışıyor
roman_fyseek, Cergorach, Space__Whiskey
- Modelin VRAM sınırı: 1 oturum = 1 GPU, 300 eşzamanlı kullanıcı için 300 GPU gerekir
- Gerçekte eşzamanlı erişim sınırı, caching ve hibrit mimari gerekir
Siderox, SandboChang, unrulywind
- Küçük bir sunucuyla PoC denemesi (ör. model başına 1~2 kişi, gerçek iş uygunluğunun kontrolü) → ardından kademeli genişleme öneriliyor
- Gerçek senaryolar tanımlanıp benchmark yapıldıktan sonra bütçe ve ROI doğrulanmalı
Little_Marzipan_2087, morosis1982, Daemonero
- Bulut GPU kiralama daha ucuz ve daha iyi ölçeklenebilirlik sunuyor; sık kullanılan bir yaklaşım
- Operasyon ve bakım yükü dikkate alındığında, donanıma yatırım yerine bulut kullanımı öneriliyor
CtiPath, alew3, faldore, Wheynelau
- vLLM, OpenWebUI, TGI, sglang vb. yüksek performanslı açık kaynak LLM sunucu çerçeveleri öneriliyor
- Kuyruk + load balancer mimarisi tavsiye ediliyor
Diğer
- Güvenlik/hukuk konuları: bulut kullanılsa bile veri konumu, şifreleme, mevzuata uyum dikkatle incelenmeli
- Mac Studio, RTX 6000 Pro, 4090 vb. farklı donanım seçenekleri anılıyor
- Caching, RAG, context sınırı, offload gibi yöntemlerle yük azaltılabilir
Sonuç özeti
- Kendi kendine barındırılan LLM sunucusu için gerçekçi yaklaşım, küçük ölçekli bir pilot (PoC) ile başlayıp gerçek kullanıcı sayısı/gereksinimler/performans/maliyet unsurlarını adım adım doğrulamaktır
- 300 eşzamanlı kullanıcıyı işlemek ciddi donanım ve operasyon maliyeti getirir; gerçek kullanım ve bütçeye göre bulut, hibrit veya ticari çözümler daha uygun olabilir
- Son aşamada güvenlik, maliyet, kullanıcı deneyimi ve bakım gibi çok boyutlu unsurlar birlikte değerlendirilmelidir
6 yorum
300 kişinin kullandığı iş akışlarında gereken muhakeme düzeyini sanırım fazla geniş tanımlamışsınız. Gerçekten çok genel sağduyudan akademik makalelere ve ileri konulara kadar her şeyi kapsamak isteniyorsa bu yaklaşım doğru olabilir; ancak fiilen işlenmesi gereken görevlerin seviyesini düşünürsek, yaklaşık 30B ve üzerine RAG eklenmiş bir yapı çoğu işi karşılayabilir gibi görünüyor. Temel açık kaynak modelin tüm ağırlıklarını yükseltip yüksek muhakeme gücü ve çeşitli özelliklere dayanınca ölçek fazla büyümüş olmuyor mu?? Ayrıca anında yapılabilen işlemler ile belge arama ve keşif işlerini ayrı fonksiyonlar olarak ayırmak daha doğru gibi görünüyor.
Eşzamanlı 300 kişiyi işlerken KV cache için hedeflenen token aralığı da kişi başı yaklaşık 20.000 tokenlık nicemleme değeriyle rahatça kullanılabilir gibi; bu kısım da fazla yüksek hesaplanmış olabilir... ??
Eğer gerçekten bu 300 kişinin tamamı makale üreten doktora seviyesinde araştırmacılar değilse, muhakeme seviyesini lise öğrencisi düzeyi (14~30B) civarında tutup çeşitli şirket içi belgeleri RAG mantığına uygun şekilde, uygun bir CoT ile tarayacak biçimde ayarlarsanız, makul bir bütçeyle pilot işletim seviyesinde bir proje çıkabilir diye düşünüyorum.
Ben de ihtiyaç nedeniyle o nadir bulunan H100 GPU’lardan 4 tane kullanarak bir RAG çözümü geliştiriyorum ama yalnızca donanıma doğrudan yatırım değil, elektrik faturası ve çeşitli soğutma çözümü maliyetleri gibi kalemleri de hesaba katınca, sadece API çağırmanın çok daha iyi olacağı düşüncesi aklımdan çıkmadı.
Ben de ilk başta testlere Ollama ile başladım; eşzamanlı 3 kullanıcıyı bile düzgün karşılayamadığını görünce hemen vLLM’e geçip bir şekilde RAG çözümünü kurdum, ama (10 eşzamanlı kullanıcı varsayımıyla) yalnızca bunun için bile şimdiden H100 GPU’lardan 2 tanesini neredeyse tam kapasite kullanmak gerekiyor. Embedding işleri ve arama işlemlerini de vLLM üzerinden açıp kullanıyorum; bu durumda H100 4 kart gerçekten çok kısıtlı kalıyor. Her kartta yaklaşık 90 GB VRAM olmasına rağmen durum böyle.
Elbette ben yapay zekadan çok anlamıyorum; departmanın ihtiyaçlarını ve şirket içi güvenlik kurallarını bir şekilde uydurmaya çalışırken biraz bodoslama ilerliyorum... Ama bunun doğru yaklaşım olup olmadığından emin değilim. ChatGPT Enterprise mıydı? Onu gerçekten fiyatına göre çok avantajlı buluyorum.
Aşırı iyi fiyatlı, aşırı iyi bir makine bir tane olsa yeter gibi? Aşırı iyi bir hukuk bürosuysa satın alır kullanır herhalde. Ama hani fabrika makinesini 24 saat çalıştırır gibi, lol
Porsche fiyatını düşünüp bakım masrafı, yakıt gideri, sigorta vb. şeyleri hiç hesaba katmayan biri
Streaming özelliği sunulması gereken chatbot benzeri servislerde, eşzamanlı işleme sırasında Prefill işi decode’u da etkilediği için VRAM geniş olsa bile kullanıcı açısından performans çok düşmüş gibi görünüyor.
Chunked prefill ile ilgili seçenekleri ve vLLM’nin deneysel olarak sunduğu Disaggregated Prefilling özelliğini de denedim, ancak hâlâ yeni bir istek geldiğinde mevcutta üretilmekte olan yanıtların takıla takıla kesilmesi sorunu var; bu yüzden acemi bir geliştirici olarak GPU ve node sayısını artırmanın dışında en verimli yöntemin ne olduğunu merak ediyorum.
Her şey dönüp dolaşıp duruma göre değişir!