Ollama ile Llama ve Qwen Modellerini Şirket İçi Ağda Çalıştırmak

Bir şirketin yapay zeka kullanımında en kritik sorulardan biri, çalışanların gönderdiği dokümanların, kodların ve iş verilerinin hangi sistemlerden geçtiğidir. Ollama ile Llama ve Qwen Modellerini Şirket İçi Ağda Çalıştırmak, bu kontrolü kurumun kendi sunucularına taşımanın pratik yollarından biridir. Yaklaşık on yıllık altyapı ve yazılım deneyimimde gördüğüm temel nokta şu: yerel bir model çalıştırmak kolaydır, onu onlarca kullanıcıya güvenli ve ölçülebilir biçimde sunmak ise ayrı bir mimari iştir. Bu rehberde Ollama ile Llama ve Qwen modelleri şirket içi sunucuda nasıl çalıştırılır sorusundan başlayarak ağ erişimi, reverse proxy, kimlik doğrulama, GPU kapasitesi, model seçimi, RAG, log yönetimi ve production ölçeklendirmesine kadar ilerleyeceğiz. Sonunda elinizde yalnızca çalışan bir Ollama kurulumu değil, kurumsal kullanıma geçerken hangi kararların verilmesi gerektiğini gösteren uygulanabilir bir yol haritası olacak.

Ollama ile Şirket İçi LLM Çalıştırmak Ne Anlama Gelir?

Şirket içi LLM çalıştırmak, model inference işlemlerinin kurumun kontrol ettiği sunucu, veri merkezi veya özel bulut altyapısında gerçekleştirilmesi anlamına gelir. Kullanıcıların prompt'ları doğrudan şirket içindeki inference servisine ulaşır ve doğru ağ politikası uygulandığında üçüncü taraf model API'sine gönderilmek zorunda kalmaz. Bunun temel avantajı veri akışının, erişim izinlerinin ve model sürümlerinin kurum tarafından yönetilebilmesidir. Ancak on-premise yaklaşım yalnızca modeli indirmekten ibaret değildir; GPU kapasitesi, authentication, TLS, log politikası, model artifact güvenliği ve monitoring de tasarımın parçasıdır. Ollama Llama Qwen on-premise kurulum ve yapılandırma rehberi hazırlanırken ilk karar modelden önce güven sınırının nerede başlayıp nerede biteceğinin belirlenmesi olmalıdır.

Ollama Nedir?

Ollama, çeşitli açık ağırlıklı ve yerel çalıştırılabilir modelleri tek bir çalışma biçimi üzerinden indirmenizi, yüklemenizi ve API aracılığıyla kullanmanızı kolaylaştıran bir model çalıştırma katmanıdır. Geliştirici açısından en büyük avantajı, bir modeli birkaç komutla ayağa kaldırıp yerel HTTP API üzerinden uygulamaya bağlayabilmesidir. Şirket açısından değerli olan taraf ise model servisinin kurum tarafından kontrol edilen makinede çalıştırılabilmesidir. Bununla birlikte Ollama'yı doğrudan son kullanıcının eriştiği tam teşekküllü kurumsal AI gateway olarak düşünmek doğru değildir. Production ortamında önüne kimlik doğrulama, TLS, kota, log ve erişim politikalarını uygulayabilen ayrı bir gateway veya reverse proxy koymak daha sağlıklı bir mimari oluşturur.

Lokal LLM ile Şirket İçi LLM Arasındaki Fark

Lokal LLM çoğu zaman tek geliştiricinin dizüstü bilgisayarında veya masaüstünde model çalıştırmasını ifade eder. Şirket içi LLM ise aynı fikri ortak servis, merkezi erişim, kullanıcı yetkilendirmesi ve operasyon sorumluluğu ile genişletir. Bir geliştiricinin bilgisayarında localhost üzerinden çalışan Ollama için TLS veya kullanıcı kotası önemli olmayabilir. Aynı servis finans, insan kaynakları, yazılım ve destek ekiplerinin ortak kullandığı bir endpoint haline geldiğinde güvenlik ve kapasite gereksinimleri tamamen değişir. Bu nedenle başarılı kurumsal kurulumlarda “model çalışıyor mu?” sorusunun hemen ardından “kim erişiyor, hangi modele erişiyor, ne kadar kaynak tüketiyor ve ne loglanıyor?” soruları sorulmalıdır.

On-Premise, Private Cloud ve Air-Gapped Deployment

On-premise deployment model sunucusunun şirketin kendi fiziksel altyapısında çalışmasını ifade ederken private cloud kurumun kontrol ettiği izole bulut kaynaklarını kullanabilir. Air-gapped yapı ise model sunucusunun internetle doğrudan bağlantısının bulunmadığı daha sıkı bir güvenlik modelidir. Bu üç yapının ortak hedefi inference trafiğini kurumun güven sınırı içinde tutmaktır. Fakat güncelleme, model indirme, lisans kontrolü ve artifact transferi bakımından operasyon biçimleri farklılaşır. Özellikle air-gapped yapılarda model dosyalarının güvenilir başka bir ortamda indirilmesi, hash doğrulamasından geçirilmesi ve kontrollü medya veya artifact repository üzerinden iç ağa aktarılması gerekir.

Veriler Şirket Dışına Çıkmadan LLM Kullanmanın Avantajları

Şirket içi inference modelinin temel avantajı prompt ve yanıt trafiği üzerinde daha doğrudan kontrol sağlamasıdır. Kurum ağ kurallarını, log politikasını, kullanıcı izinlerini ve model sürümünü kendi güvenlik gereksinimlerine göre belirleyebilir. Bu yaklaşım özellikle kaynak kod, iç prosedür, müşteri destek kaydı ve şirket dokümanları gibi hassas verilerin işlendiği kullanım senaryolarında değerlidir. Buna rağmen modelin yerel olması tek başına veri güvenliği garantisi değildir; yanlış RAG yetkilendirmesi veya kontrolsüz prompt logları yine veri sızıntısına neden olabilir. Bu nedenle veri dışarı çıkmıyor ifadesi ancak outbound ağ trafiği, kullanılan entegrasyonlar, model indirme davranışı ve yardımcı servisler birlikte doğrulandıktan sonra kullanılmalıdır.

Veri Gizliliği

Yerel inference, prompt ve response verisinin kurumun kontrol ettiği sistemlerde işlenebilmesini sağlar. Özellikle çalışanların iç dokümanları özetlediği veya kod tabanına ilişkin sorular sorduğu uygulamalarda bu mimari önemli bir güvenlik avantajı sunar. Yine de kullanıcıların her türlü hassas veriyi modele göndermesine sınırsız izin verilmemelidir. Prompt politikaları, yetkilendirme, veri sınıflandırması ve gerekli durumlarda otomatik maskeleme uygulanmalıdır. Veri gizliliği modelin fiziksel konumundan çok, verinin bütün yaşam döngüsünün nasıl yönetildiğiyle ilgilidir.

Veri Egemenliği

Veri egemenliği, verinin nerede işlendiğini ve hangi hukuki veya organizasyonel kontrol alanında kaldığını yönetebilme kabiliyetidir. Şirket kendi inference sunucusunu kullandığında veri akışının coğrafi ve teknik sınırlarını daha açık tanımlayabilir. Bu durum özellikle regülasyon veya müşteri sözleşmeleri belirli veri işleme koşulları gerektirdiğinde değer kazanır. Bununla birlikte yedekleme, log toplama ve monitoring gibi yardımcı servislerin de aynı sınırlar içinde olup olmadığı kontrol edilmelidir. Aksi halde model yerel olsa bile prompt metadata'sı başka bir sisteme aktarılabilir.

Maliyet Kontrolü

Yerel model kullanımında maliyet doğrudan token başına API faturası yerine donanım, enerji, bakım ve operasyon kapasitesi üzerinden oluşur. Düzenli ve yüksek hacimli kullanımda bu yapı belirli senaryolarda ekonomik olabilir. Düşük kullanım hacminde ise pahalı GPU'nun günün büyük bölümünde boş kalması toplam maliyeti yükseltebilir. Bu nedenle karar vermeden önce kullanıcı sayısı, ortalama prompt uzunluğu, çıktı token miktarı ve concurrency ölçülmelidir. On-premise yatırımının anlamlı olup olmadığı gerçek iş yüküyle yapılan break-even analizi üzerinden değerlendirilmelidir.

Vendor Lock-In'in Azaltılması

Ollama gibi yerel inference araçları farklı model aileleri arasında geçiş yapmayı kolaylaştırabilir. Uygulamalar model adına doğrudan bağımlı olmak yerine ortak gateway veya OpenAI-compatible katmana bağlanırsa model değişimi daha yönetilebilir hale gelir. Bugün Llama kullanan bir ekip yarın belirli bir iş için Qwen veya başka bir uygun model deneyebilir. Buradaki kritik nokta prompt template, tool calling ve structured output davranışlarının modeller arasında aynı olmayabileceğini kabul etmektir. Model bağımsız mimari, uygulama kodundaki bağımlılığı azaltırken regression benchmark süreci yeni modele geçişte kaliteyi korur.

Ollama Şirket İçi Kullanım İçin Uygun mu?

Ollama şirket içi pilotlar, ekip içi araçlar ve kontrollü kullanıcı grupları için oldukça pratik bir başlangıç noktasıdır. Model indirme, çalıştırma ve API servis etme sürecini basitleştirdiği için altyapı ekibinin kısa sürede çalışan bir prototip kurmasını sağlar. Production uygunluğu ise kullanıcı sayısı, model büyüklüğü, beklenen throughput ve yüksek erişilebilirlik ihtiyacına bağlıdır. Onlarca eşzamanlı kullanıcının düşük gecikmeyle büyük modeller tükettiği senaryolarda farklı inference motorlarının değerlendirilmesi gerekebilir. Benim tercih ettiğim yaklaşım, Ollama'yı önce ölçülebilir pilot ortamında kullanmak ve gerçek metrikler ölçek ihtiyacını gösterdiğinde mimariyi büyütmektir.

Ollama'nın Güçlü Yanları

Ollama'nın en güçlü taraflarından biri hızlı kurulum ve kolay model yönetimidir. Geliştirici ekipler tek bir API biçimi üzerinden farklı model ailelerini deneyebilir ve prototip süresini kısaltabilir. Docker, yerel kurulum ve API istemcileri sayesinde mevcut geliştirme süreçlerine kolay adapte olabilir. Model dosyalarının yerel tutulabilmesi şirket içi kullanım senaryoları için önemli avantaj sağlar. Özellikle 10 ile 20 kullanıcıyla başlayan pilot çalışmalarda karmaşık inference platformu kurmadan gerçek kullanım verisi toplamak için oldukça uygundur.

Ollama'nın Production Sınırlamaları

Production ortamında Ollama'nın kendisini tek güvenlik ve trafik yönetim katmanı olarak kullanmak doğru değildir. Kimlik doğrulama, departman bazlı yetkilendirme, merkezi rate limit, gelişmiş routing ve ayrıntılı audit gereksinimleri için önüne ek bir katman gerekir. Büyük concurrency altında model scheduling ve GPU utilization hedefleri de daha uzman inference sistemlerine ihtiyaç doğurabilir. Yüksek availability için birden fazla instance, load balancer ve dış model storage stratejisi ayrıca tasarlanmalıdır. Bu nedenle Ollama'yı inference engine olarak konumlandırıp kurumsal özellikleri gateway ve platform katmanlarında sağlamak daha esnek bir yöntemdir.

Küçük ve Orta Ölçekli Ekipler İçin Ollama

Küçük ve orta ölçekli ekiplerde Ollama'nın operasyon sadeliği güçlü avantajdır. Tek GPU sunucusu üzerinde birkaç uygun model tutularak yazılım geliştirme, doküman özetleme veya kurum içi soru cevap gibi görevler desteklenebilir. Nginx, SSO ve monitoring eklendiğinde birçok ekip için yeterli bir iç servis oluşturulabilir. Burada ilk hedef yüzlerce kullanıcıya ölçeklemek yerine en çok değer üreten iki veya üç kullanım senaryosunu doğrulamak olmalıdır. Kullanım verisi toplandıkça hangi modelin, hangi quantization seviyesinin ve hangi GPU kapasitesinin gerekli olduğu daha doğru belirlenir.

Ollama Ne Zaman Yetersiz Kalmaya Başlar?

Ollama genellikle concurrency, GPU scheduling ve büyük model servis etme gereksinimleri arttığında sınırlarına yaklaşmaya başlar. Kullanıcılar yoğun saatlerde uzun kuyruk bekliyorsa, GPU belleği sürekli model load ve unload işlemleriyle boğuluyorsa veya çok sayıda inference instance merkezi biçimde yönetilmek isteniyorsa daha farklı platformlar değerlendirilebilir. Benzer şekilde belirli throughput hedefleri için continuous batching veya gelişmiş distributed inference özelliklerine ihtiyaç oluşabilir. Burada karar tahmine göre değil TTFT, token throughput, queue wait ve GPU utilization verilerine göre verilmelidir. Ollama'dan başka bir inference motoruna geçiş başarısızlık değil, iş yükünün büyüdüğünü gösteren doğal bir platform kararıdır.

Ollama ile vLLM Arasındaki Fark

Ollama kullanım kolaylığı ve yerel model deneyimi tarafında güçlü bir araçken vLLM daha yüksek throughput ve production odaklı serving senaryolarında sık değerlendirilen bir inference motorudur. Özellikle çok sayıda eşzamanlı istekte batching ve GPU kullanım verimliliği karar üzerinde etkili olabilir. Ollama küçük ve kontrollü bir şirket içi kurulum için daha hızlı başlangıç sağlarken vLLM yoğun servis trafiğinin olduğu ortamlarda farklı avantajlar sunabilir. Uygulamalar ortak bir AI gateway arkasına bağlanırsa backend inference motorunun değiştirilmesi kolaylaşır. Bu nedenle istemcilerin doğrudan Ollama'ya bağımlı hale getirilmemesi uzun vadede mimari esneklik sağlar.

Şirket İçi Ollama Mimarisi Nasıl Olmalı?

Kurumsal Ollama mimarisinde kullanıcıların doğrudan inference sunucusuna bağlanması yerine kontrollü bir gateway üzerinden geçmesi tercih edilmelidir. Internal DNS kullanıcıların anlamlı bir servis adı kullanmasını sağlar, reverse proxy TLS ve authentication uygular, Ollama ise yalnızca güvenilen backend ağından erişilir durumda tutulur. GPU sunucusu inference katmanını barındırırken monitoring sistemi performans ve hata metriklerini toplar. Model yönetimi normal kullanıcı trafiğinden ayrılarak yalnızca yetkili AI administrator grubuna açılmalıdır. Bu yaklaşım Ollama ile yerel LLM API servisi kurma ve şirket ağına açma sürecini basit port yönlendirmesinden kurumsal servis tasarımına taşır.

Önerilen Referans Mimari

Pratik bir referans mimari kullanıcı veya kurumsal uygulama, internal DNS, AI gateway, authentication katmanı, Ollama inference instance, model storage ve GPU sunucusundan oluşabilir. Kullanıcı yalnızca HTTPS üzerinden gateway'e ulaşır. Gateway kullanıcı kimliğini doğrular, izin verilen modeli kontrol eder ve uygun backend'e isteği aktarır. Model pull veya delete gibi yönetim çağrıları ayrı network ve admin endpoint üzerinden yapılır. Monitoring sistemi gateway, Ollama ve GPU metriklerini birlikte izleyerek performans sorununun hangi katmanda oluştuğunu gösterebilir.

Kullanıcılar ve Kurumsal Uygulamalar

Çalışanlar Open WebUI gibi bir arayüzden, geliştiriciler IDE entegrasyonundan ve şirket uygulamaları doğrudan API üzerinden modeli kullanabilir. Bütün bu istemcilerin aynı kimlik ve kota sisteminden geçmesi yönetimi kolaylaştırır. İnsan kullanıcılarla servis hesaplarının erişim modelleri ayrılmalıdır. Bir ERP entegrasyonunun kullandığı service identity ile çalışan hesabına aynı quota uygulanması gerekmeyebilir. Kullanım tipi gateway üzerinde açık biçimde ayrıştırıldığında maliyet ve performans raporlaması da daha anlamlı olur.

Internal DNS

Internal DNS kullanıcıların IP adresi yerine örneğin ai.internal benzeri sabit bir kurumsal endpoint kullanmasını sağlar. Bu yaklaşım backend sunucu değiştiğinde istemci yapılandırmasını değiştirme ihtiyacını azaltır. TLS sertifikası da bu servis adına göre düzenlenebilir. Birden fazla inference instance eklendiğinde DNS doğrudan load balancing yapmak yerine gateway veya load balancer adresine işaret edebilir. DNS kaydının yalnızca gerekli iç ağlardan çözülebilmesi ek kontrol sağlayabilir.

Reverse Proxy / AI Gateway

Reverse proxy Ollama'nın ham API'si ile kullanıcı arasında güvenlik ve trafik kontrol katmanı oluşturur. Nginx gibi bir proxy TLS termination, rate limit, request size ve bağlantı sınırı uygulayabilir. Daha gelişmiş AI gateway çözümleri model routing, kullanıcı kotası ve merkezi maliyet ölçümü ekleyebilir. Backend Ollama portu yalnızca gateway'in bulunduğu ağdan erişilebilir olmalıdır. Böylece kullanıcıların gateway politikalarını atlayıp doğrudan inference servisine ulaşması engellenir.

Authentication ve Authorization

Authentication kullanıcının kim olduğunu doğrular, authorization ise hangi modele ve endpoint'e erişebileceğini belirler. Şirket içinde mevcut SSO veya identity provider altyapısını kullanmak yeni parola sistemi oluşturmaktan daha mantıklıdır. Departman grupları model izinlerine eşlenebilir. Örneğin yazılım ekibi coder modeline erişirken bütün çalışanlara yalnızca genel chat modeli sunulabilir. Model yönetim endpoint'leri ise normal kullanıcı rollerinden tamamen ayrılmalıdır.

Ollama Inference Server

Ollama inference server mümkün olduğunda doğrudan kullanıcı ağına açık olmamalıdır. Backend yalnızca gateway veya belirlenmiş application subnet'ten gelen trafiği kabul etmelidir. Model dosyaları kalıcı storage üzerinde tutulabilir ve servis restart sonrasında tekrar kullanılabilir. Sunucudaki model listesini ve yüklü sürümleri değişiklik yönetimi kapsamına almak önemlidir. Production ortamında geliştiricinin istediği modeli doğrudan pull etmesi yerine onaylanmış model registry yaklaşımı tercih edilebilir.

Llama ve Qwen Modelleri

Llama ve Qwen farklı kullanım profilleri için aynı şirket içi altyapıda birlikte bulunabilir. Model routing görev türüne göre uygun modeli seçebilir. Genel sohbet, kod üretimi, Türkçe rapor veya reasoning görevlerinin aynı model tarafından en iyi şekilde karşılanacağı varsayılmamalıdır. Ollama kütüphanesi güncel olarak Llama 4 Scout ve Maverick ile Qwen3 ve Qwen3.5 ailelerini sunmaktadır. Qwen3.5 tarafında 0.8B'den 122B'ye uzanan seçenekler görülürken Llama 4 modelleri çok daha büyük depolama ve bellek gereksinimleriyle gelir.

GPU Sunucusu

GPU sunucusu model ağırlıkları, KV cache ve eşzamanlı istekler için yeterli VRAM sağlamalıdır. Sadece model dosyasının disk boyutuna bakarak kapasite seçmek sık yapılan hatalardandır. Context uzunluğu ve parallel request sayısı VRAM tüketimini ciddi biçimde artırabilir. İşletim sistemi, monitoring agent ve diğer servisler için sistem RAM'i de ayrıca ayrılmalıdır. Pilot aşamada gerçek kullanıcı prompt'larıyla load test yapmadan yüz kullanıcı için kesin GPU sayısı vermek sağlıklı değildir.

Monitoring

Monitoring yalnızca sunucunun çalışıp çalışmadığını değil kullanıcı deneyimini de ölçmelidir. GPU utilization, VRAM, TTFT, tokens per second, queue wait ve error rate temel metriklerdir. Gateway seviyesinde kullanıcı, departman ve model bazında request sayıları izlenebilir. Ollama restart veya model load süresi gibi olaylar latency artışının kaynağını açıklamaya yardımcı olur. Bu veriler kapasite yatırımının tahmin yerine gerçek kullanıma göre yapılmasını sağlar.

Inference Plane ve Management Plane Ayrımı

Inference plane kullanıcıların prompt gönderdiği ve modelden yanıt aldığı trafik alanıdır. Management plane ise model pull, create, delete, configuration değişikliği ve yönetici işlemlerini içerir. Bu iki trafik türünün aynı erişim politikasında tutulması gereksiz risk yaratır. Normal kullanıcı inference yapabilmeli ancak sunucudaki modeli silememeli veya yeni artifact indirmemelidir. Management endpoint'lerini ayrı network segment, ayrı gateway veya yalnızca administrator VPN erişimi üzerinden sunmak daha güvenli bir yapıdır.

Kullanıcı Trafiği ile Model Yönetim Trafiğinin Ayrılması

Kullanıcı trafiği yoğun ve sürekli olabilirken model yönetim işlemleri daha seyrek fakat daha yüksek yetki gerektirir. Model pull işlemi dış ağ erişimi oluşturabilir, büyük storage tüketebilir veya production'a doğrulanmamış artifact getirebilir. Bu nedenle kullanıcıların eriştiği endpoint seti yalnızca inference çağrılarıyla sınırlandırılmalıdır. Model operasyonları change management ve security review sürecine bağlanabilir. Böylece şirket içinde model kullanımı kolay kalırken model platformunun kontrolü merkezi biçimde korunur.

Şirket Ağında Ollama Hangi Portu Kullanır?

Ollama yerel API'si varsayılan kullanımda 11434 numaralı port üzerinden erişilebilir. Geliştirme makinesinde bu endpoint çoğunlukla localhost üzerinden kullanılır ve uygulama aynı makineden API çağrısı yapar. Şirket ağına servis açarken 11434 portunu doğrudan bütün kullanıcılara yayınlamak yerine gateway arkasında tutmak daha güvenlidir. Dış kullanıcı tarafında standart HTTPS portu kullanılabilir ve proxy trafiği backend'deki 11434'e aktarabilir. Böylece backend portu, authentication ve TLS mekanizması olmayan doğrudan kullanıcı endpoint'i olmaktan çıkar.

11434 Portu Nedir?

11434 Ollama'nın yerel HTTP API servisinde kullanılan varsayılan porttur. Uygulamalar chat, generation ve model işlemleri için bu API'ye bağlanabilir. Yerel geliştirmede localhost üzerinde erişmek oldukça pratiktir. Ancak şirket içinde aynı portu firewall üzerinde geniş bir subnet'e açmak kullanıcıların reverse proxy politikasını atlamasına neden olabilir. Production mimarisinde 11434'ü backend servis portu olarak görmek, kullanıcı endpoint'i olarak görmemek daha doğru bir yaklaşımdır.

Varsayılan Localhost Binding

Localhost binding servisin yalnızca aynı makineden gelen bağlantıları kabul etmesini sağlar. Bu davranış geliştirici bilgisayarında iyi bir varsayılandır çünkü servis ağdaki diğer makinelerden doğrudan erişilebilir olmaz. Şirket içinde gateway aynı sunucuda bulunuyorsa Ollama localhost'ta bırakılabilir. Gateway farklı bir makinedeyse yalnızca ilgili private interface veya güvenilir backend ağına bind etmek tercih edilebilir. Binding değişikliği firewall kuralıyla birlikte ele alınmalıdır.

OLLAMA_HOST Nedir?

OLLAMA_HOST, Ollama servisinin hangi ağ adresinde dinleyeceğini yapılandırmak için kullanılan ortam değişkenidir. Bu değer üzerinden localhost dışındaki interface'lere servis açılabilir. Yapılandırma işletim sistemi ve servis çalıştırma yöntemine göre environment veya service configuration içinde tanımlanabilir. Production ortamında değişiklik yapılırken yalnızca gerekli ağ arayüzünün tercih edilmesi önemlidir. 0.0.0.0 gibi bütün interface'leri kapsayan bir değer kullanılıyorsa firewall ve gateway kontrolü zorunlu hale gelir.

0.0.0.0 Kullanmanın Riskleri

0.0.0.0 servisin makinedeki bütün uygun IPv4 interface'lerinde dinlemesine neden olabilir. Sunucuda yönetim, kullanıcı ve başka network interface'leri bulunuyorsa beklenenden daha geniş erişim oluşabilir. Firewall yanlış yapılandırılmışsa ham Ollama API'si doğrudan erişilebilir hale gelir. Bu durumda kullanıcı gateway'in authentication ve rate-limit politikasını atlayabilir. Dolayısıyla 0.0.0.0 kullanımını basit çözüm olarak görmek yerine erişim yüzeyini ayrıca doğrulamak gerekir.

Ham Ollama Portu Neden Kullanıcılara Açılmamalı?

Ham API portuna doğrudan erişim kullanıcıların gateway katmanındaki güvenlik kontrollerini bypass etmesine neden olabilir. Authentication, quota, audit ve departman bazlı model politikaları bu durumda uygulanamayabilir. Ayrıca model yönetimiyle ilgili endpoint'lerin aynı API yüzeyinde erişilebilir olması riski büyütür. Kullanıcı trafiğinin tek kontrollü giriş noktasından geçmesi hem operasyon hem güvenlik açısından daha anlaşılırdır. Production tasarımında backend portu yalnızca gateway ve yetkili yönetim sistemleri tarafından erişilebilir tutulmalıdır.

Ollama'yı LAN Üzerinden Diğer Bilgisayarlara Açmak

Ollama'yı LAN üzerinden açmak teknik olarak binding ve firewall ayarını değiştirmekle mümkündür, fakat production için yalnızca bu iki adım yeterli değildir. İlk aşamada test ortamında servisin uygun internal interface üzerinde dinlediği doğrulanabilir. Ardından firewall yalnızca belirlenen istemci subnet veya gateway IP'sine izin verecek şekilde yapılandırılır. Bağlantı curl veya basit uygulama istemcileriyle test edilir. Kurumsal kullanımda bu doğrudan erişim modeli daha sonra HTTPS reverse proxy ve authentication katmanıyla sınırlandırılmalıdır.

Linux'ta Network Binding

Linux üzerinde Ollama servisinin environment yapılandırmasına uygun host binding değeri eklenebilir. Systemd kullanılıyorsa servis environment ayarının doğru unit veya override dosyasına yazılması gerekir. Değişiklikten sonra daemon configuration yeniden yüklenmeli ve servis restart edilmelidir. Ardından dinlenen adres ss veya benzeri network aracıyla kontrol edilebilir. Firewall kuralı yapılmadan yalnızca binding değiştirmenin güvenli bir kurulum oluşturmadığı unutulmamalıdır.

Windows'ta Network Binding

Windows ortamında environment ayarı üzerinden Ollama'nın ağ binding davranışı değiştirilebilir. Değişiklik sonrasında ilgili Ollama sürecinin yeniden başlatılması gerekir. Windows Firewall üzerinde yalnızca gerekli internal profile ve subnet için inbound kural tanımlanmalıdır. Public network profile üzerinde geniş erişim verilmemesi önemlidir. Kurumsal Windows makinelerinde merkezi group policy veya endpoint yönetim sistemiyle firewall kuralının tutarlı uygulanması tercih edilebilir.

macOS'ta Network Binding

macOS üzerinde de Ollama'nın environment ve uygulama başlatma biçimine göre network binding yapılandırılabilir. Test sunucusu olarak kullanılıyorsa hangi interface üzerinde portun açıldığı net biçimde kontrol edilmelidir. Kişisel dizüstü bilgisayarın bütün şirket için sürekli inference servisi olarak kullanılması operasyon açısından uygun değildir. Production için sabit sunucu, kontrollü network ve izlenebilir servis yönetimi daha sağlıklı olur. macOS daha çok geliştirici ve küçük pilot deneyimleri için uygun bir çalışma ortamı olarak görülebilir.

Firewall Kuralları

Firewall kuralı erişim alanını mümkün olan en dar subnet veya kaynak grubuyla sınırlandırmalıdır. Eğer kullanıcılar yalnızca Nginx gateway üzerinden bağlanacaksa Ollama portuna yalnızca gateway IP'sinin erişmesi yeterlidir. Yönetim trafiği farklı subnet'ten geliyorsa ayrı bir kural tanımlanabilir. Any-to-any benzeri geniş kurallar uzun vadede mimarinin güvenlik sınırını belirsiz hale getirir. Ağ güvenliği ve erişim kuralı yönetimini daha geniş çerçevede ele almak için kurum içi ağ tasarımının ayrıca dokümante edilmesi yararlıdır.

Bağlantının Başka Bir İstemciden Test Edilmesi

Bağlantı testi yalnızca portun açık olup olmadığını değil gerçek API isteğinin çalışıp çalışmadığını doğrulamalıdır. İlk olarak health veya model listeleme gibi düşük etkili bir endpoint denenebilir. Daha sonra küçük bir modelle kısa prompt gönderilerek streaming davranışı gözlemlenebilir. Test farklı VLAN veya istemci ağlarından tekrar edilerek firewall politikasının beklenen şekilde çalıştığı doğrulanabilir. Production öncesinde yetkisiz bir istemcinin ham 11434 portuna erişemediği de ayrıca test edilmelidir.

curl

curl API bağlantısını en hızlı doğrulama yöntemlerinden biridir. İstemci makineden HTTP isteği gönderildiğinde DNS, routing ve firewall sorunları hızlıca ayırt edilebilir. JSON body içinde model ve prompt bilgisi gönderilebilir. Streaming yanıt terminalde parça parça görülebilir. Production gateway testinde aynı komut HTTPS endpoint ve gerekli authentication header ile tekrar çalıştırılmalıdır.

Python

Python istemcisi şirket uygulamalarının Ollama servisine nasıl bağlanacağını test etmek için kullanılabilir. Basit script timeout, retry ve response handling davranışlarını gözlemlemeyi sağlar. Doğrudan backend IP yerine kurumsal gateway URL'si kullanılması uygulama bağımlılığını azaltır. Authentication token environment veya secret store üzerinden verilmelidir. Test script'inin production credential'ını kaynak kod içinde içermemesi gerekir.

JavaScript

JavaScript veya Node.js uygulamaları da Ollama veya OpenAI-compatible gateway üzerinden inference isteği gönderebilir. Backend uygulaması kullanıldığında token yönetimi tarayıcı tarafına göre daha güvenlidir. Web tarayıcısından doğrudan Ollama portuna erişmek CORS ve credential güvenliği açısından tercih edilmemelidir. Kurumsal web uygulaması kendi backend'i üzerinden AI gateway'e bağlanabilir. Böylece kullanıcı kimliği, audit ve quota tek merkezde uygulanır.

Neden Ollama'nın Önüne Reverse Proxy Konulmalı?

Reverse proxy şirket içi Ollama kurulumunu production servis haline getiren en önemli katmanlardan biridir. Ham inference endpoint'i yerine tek bir HTTPS adresi sunar ve authentication, rate limiting, logging ve connection control gibi işlevleri merkezi hale getirir. Model backend'i değişse bile istemcilerin endpoint'i sabit kalabilir. Ayrıca birden fazla Ollama instance eklendiğinde proxy load balancer görevini üstlenebilir. Benim üretim ortamlarında tercih ettiğim yaklaşım, Ollama'yı mümkün olduğunca kapalı backend servisi olarak tutup kullanıcı trafiğinin tamamını bu kontrol noktasından geçirmektir.

Authentication

Reverse proxy authentication kullanıcı kimliğini Ollama'ya ulaşmadan önce doğrular. API key, Basic Authentication veya daha kurumsal OAuth2 ve OIDC tabanlı modeller uygulanabilir. Şirket içi kullanıcılar için mevcut SSO sisteminin kullanılması parola yönetimini kolaylaştırır. Service-to-service çağrılar için ayrı machine identity veya token kullanılabilir. Authentication olmadan yalnızca iç ağda olmak, kullanıcının gerçekten yetkili olduğunu kanıtlamaz.

TLS Encryption

TLS kullanıcı prompt ve model yanıtlarının ağ üzerinde şifreli taşınmasını sağlar. İç ağdaki trafik de hassas şirket verisi taşıyabileceği için düz HTTP varsayımı yapılmamalıdır. Internal CA veya kurumun kullandığı güvenilir sertifika altyapısı kullanılabilir. Gateway üzerinde HTTPS sonlandırılıp backend tarafında güvenilir izole network tercih edilebilir. Daha yüksek güvenlik gereksiniminde gateway ile inference server arasında da TLS uygulanabilir.

Rate Limiting

Rate limit tek kullanıcının veya hatalı uygulamanın GPU kaynaklarını tüketmesini önlemeye yardımcı olur. Kullanıcı, API key, departman veya source application bazında limit uygulanabilir. Sabit request sayısı tek başına yeterli olmayabilir çünkü bir kısa prompt ile binlerce token üreten başka bir prompt aynı maliyeti oluşturmaz. Mümkün olduğunda token veya inference süresi bazlı quota ile desteklenmelidir. Rate limit aşımı loglanarak kapasite planlaması için veri olarak kullanılabilir.

Request Logging

Request logging güvenlik ve operasyon açısından yararlıdır ancak prompt içeriğini kontrolsüz biçimde kaydetmek risklidir. Çoğu durumda kullanıcı kimliği, model, zaman, latency, status ve token miktarı gibi metadata yeterli olabilir. Tam prompt yalnızca açık iş gerekçesi varsa ve retention politikası belirlenmişse tutulmalıdır. Hassas alanlar otomatik redaction mekanizmasıyla temizlenebilir. Audit log ile conversation log birbirinden ayrı kavramlar olarak yönetilmelidir.

Connection Limits

GPU inference sistemleri sınırsız bağlantı kabul etse bile gerçek kapasiteye sahip değildir. Reverse proxy connection limit uygulayarak çok sayıda eşzamanlı isteğin backend'i kararsız hale getirmesini önleyebilir. Fazla istek kontrollü kuyruğa alınabilir veya uygun hata koduyla reddedilebilir. Kullanıcı tarafında retry ve backoff davranışı tasarlanmalıdır. Limit değerleri load test sonucuna göre belirlenmelidir.

Streaming Desteği

LLM yanıtlarının streaming olarak kullanıcıya aktarılması algılanan gecikmeyi azaltır. Reverse proxy buffering davranışı yanlış ayarlanırsa token'lar backend'den gelse bile kullanıcı tüm yanıtı tamamlandıktan sonra görebilir. Bu nedenle proxy configuration streaming kullanımına uygun olmalıdır. Timeout değerleri normal web request'lerinden daha uzun ayarlanabilir. Load test sırasında hem streaming hem uzun generation senaryosu ayrı ayrı doğrulanmalıdır.

Merkezi Endpoint Yönetimi

Kurumsal uygulamaların doğrudan tek tek Ollama sunucularına bağlanması zamanla yönetim yükü oluşturur. Merkezi gateway sabit endpoint sağlayarak backend değişikliklerini istemcilerden saklar. Model routing, maintenance veya migration gateway üzerinden yapılabilir. Ollama'dan farklı inference motoruna geçildiğinde uygulamaların tamamını değiştirmek gerekmeyebilir. Bu soyutlama kurumsal LLM platformunun uzun vadeli bakımını kolaylaştırır.

Nginx ile Güvenli Ollama Gateway Kurulumu

Nginx Ollama'nın önünde TLS, reverse proxy ve temel trafik yönetimi sağlamak için kullanılabilir. En güvenli basit tasarımda Ollama yalnızca localhost veya izole backend interface üzerinde dinler ve Nginx dış bağlantıları HTTPS üzerinden kabul eder. Authentication harici identity proxy veya Nginx uyumlu mekanizmayla eklenebilir. Streaming için buffering ve timeout ayarları LLM response davranışına göre düzenlenmelidir. Production yapılandırması değişiklik yönetimi kapsamında tutulmalı ve config değişiklikleri uygulanmadan önce test ortamında doğrulanmalıdır.

Ollama'yı Localhost'ta Tutmak

Nginx ile Ollama aynı sunucuda çalışıyorsa backend'i localhost üzerinde tutmak saldırı yüzeyini küçültür. Ağdaki başka makineler doğrudan 11434 portuna ulaşamaz. Nginx ise 443 üzerinden güvenli endpoint sunar. Firewall dışarıdan yalnızca gerekli HTTPS trafiğine izin verebilir. Bu model küçük ve orta ölçekli şirket içi kurulumlar için anlaşılır bir güven sınırı oluşturur.

Nginx Upstream Tanımı

Nginx upstream tanımı Ollama backend adresini merkezi config içinde tutar. Tek instance ile başlanıp daha sonra birden fazla backend eklendiğinde aynı istemci endpoint'i korunabilir. Health check desteği kullanılan Nginx sürüm ve kurulum biçimine göre ayrıca planlanmalıdır. Backend connection timeout ve keepalive değerleri inference davranışına göre ayarlanabilir. Config dosyası version control altında saklanırsa değişiklik geçmişi izlenebilir.

HTTPS Endpoint

Kullanıcıların eriştiği endpoint yalnızca HTTPS sunmalıdır. HTTP bağlantıları kapatılabilir veya kontrollü biçimde HTTPS'e yönlendirilebilir. Sertifika internal CA veya kurumun uygun sertifika hizmetiyle sağlanabilir. API istemcilerinin CA zincirine güvenmesi gerekir. Sertifika süresi dolmadan otomatik rotation ve monitoring kurulması servis kesintisini önler.

Proxy Buffering Ayarları

LLM streaming yanıtlarında proxy buffering kullanıcı deneyimini doğrudan etkileyebilir. Buffering açık olduğunda küçük token parçaları proxy üzerinde birikerek gecikmeli iletilebilir. Streaming endpoint için uygun proxy ayarları uygulanmalıdır. Aynı gateway başka normal HTTP servisleri sunuyorsa ayar yalnızca ilgili location alanında sınırlandırılabilir. Değişiklik sonrası time to first token ölçümüyle gerçek etkisi doğrulanmalıdır.

Timeout Ayarları

LLM istekleri klasik REST endpoint'lerine göre daha uzun sürebilir. Uzun context ve büyük output üretiminde birkaç saniyelik varsayılan timeout yetersiz kalabilir. Buna karşılık sınırsız timeout da takılmış bağlantıların kaynak tüketmesine neden olur. Read, send ve connect timeout değerleri farklı düşünülmelidir. P95 ve P99 generation süreleri ölçülerek makul üst sınır belirlenebilir.

Request Size Limit

Büyük request body uzun prompt veya dosya içeriğinin kontrolsüz gönderilmesine yol açabilir. Reverse proxy request size limiti bu riski azaltabilir. RAG mimarisinde kullanıcının bütün dokümanı prompt'a göndermesi yerine retrieval katmanının gerekli parçaları seçmesi daha verimlidir. Limit aşımı kullanıcıya açıklayıcı hata mesajıyla bildirilmelidir. API entegrasyonlarının gerçek gereksinimleri ölçülmeden çok düşük sınır koymak da işlevselliği bozabilir.

Rate Limit

Nginx temel request rate limit uygulayabilir ve kötü yapılandırılmış istemcinin yoğun istek göndermesini engelleyebilir. Kullanıcı kimliğini doğrudan Nginx görebiliyorsa limit buna göre yapılabilir. Daha gelişmiş token bazlı quota için ayrı AI gateway katmanı gerekebilir. Burst davranışı özellikle chat arayüzlerinde kullanıcı deneyimini etkileyebilir. Limit değerleri production trafiğinin gerçek dağılımına göre ayarlanmalıdır.

Şirket İçinde TLS Nasıl Kullanılır?

Şirket içi servislerde TLS kullanmak prompt ve yanıtların ağ üzerinde okunabilir halde dolaşmasını önler. Internal DNS adı için public sertifika kullanılabiliyorsa yönetim kolay olabilir, ancak birçok kurum private isimler veya internal CA kullanır. Internal CA'nın root sertifikası çalışan bilgisayarlarına merkezi olarak dağıtılabilir. Certificate rotation süreci otomatikleştiğinde bakım riski önemli ölçüde azalır. TLS konfigürasyonu yalnızca sertifika takmak değil, kabul edilen protokol sürümleri ve key yönetimini de içerir.

Public Certificate ile Internal CA Farkı

Public certificate genel olarak istemcilerin zaten güvendiği certificate authority tarafından imzalanır. Internal CA ise kurumun kendi güven zincirini oluşturmasını sağlar. Private DNS isimleri ve izole ağlar için internal CA daha uygun olabilir. Bunun karşılığında bütün istemcilere root certificate dağıtılması ve CA güvenliğinin korunması gerekir. Hangi modelin seçileceği mevcut kurumsal PKI yapısına göre belirlenmelidir.

Internal Certificate Authority

Internal CA şirket içi servisler için sertifika üretme ve yenileme sürecini merkezi hale getirir. AI gateway için belirli süreli sertifika çıkarılabilir. CA private key yüksek güvenlikle korunmalı ve erişim minimum kullanıcıyla sınırlandırılmalıdır. Sertifika talebi otomatik servis kimliği üzerinden yapılabilir. Böylece manuel sertifika kopyalama işlemleri azaltılır.

Kurumsal Bilgisayarlara CA Dağıtımı

Internal CA kullanıldığında istemci bilgisayarların root veya gerekli intermediate certificate'e güvenmesi gerekir. Windows domain ortamında group policy, cihaz yönetim platformları veya configuration management aracı kullanılabilir. Geliştiricilerin sertifikayı tek tek manuel kurması uzun vadede hataya açıktır. Dağıtım sonrası browser, curl, Python ve Node.js istemcileri ayrı test edilmelidir. Bazı runtime'lar işletim sistemi trust store yerine kendi certificate store'unu kullanabilir.

Certificate Rotation

Sertifikaların süresi dolduğu için rotation süreci kurulmadan TLS operasyonu tamamlanmış sayılmaz. Expiry monitoring en az birkaç hafta önceden uyarı verebilir. Otomatik yenileme sonrasında Nginx reload işlemi servis kesintisi oluşturmadan yapılabilir. Private key dosyalarının permission değerleri sınırlı tutulmalıdır. Eski certificate ve key dosyaları retention politikasına göre güvenli biçimde temizlenmelidir.

TLS 1.2 ve TLS 1.3

Kurumsal gateway modern TLS sürümlerini desteklemelidir. Eski ve güvensiz protokollerin devre dışı bırakılması genel güvenlik politikasının parçasıdır. TLS 1.3 destekleyen istemciler daha modern handshake ve cipher seçeneklerinden yararlanabilir. Legacy uygulama desteği gerekiyorsa TLS 1.2 kontrollü biçimde açık tutulabilir. Kabul edilen cipher ve protocol listesi şirketin güvenlik standardıyla uyumlu olmalıdır.

Ollama'da Authentication Nasıl Sağlanır?

Şirket içi Ollama kullanımında authentication'ın ayrı gateway katmanında ele alınması en güvenli yaklaşımdır. Yerel API'nin tasarımını internete açık veya çok kullanıcılı identity platformu gibi değerlendirmemek gerekir. Reverse proxy API key, Basic Authentication veya OAuth2 tabanlı doğrulama uygulayabilir. Kurumda Active Directory, Entra ID, LDAP veya başka bir SSO sistemi bulunuyorsa kullanıcı yaşam döngüsünü aynı identity kaynağı üzerinden yönetmek daha pratiktir. Authentication sonrasında authorization ve quota uygulanmadığı sürece yalnızca kullanıcının kim olduğunu bilmek yeterli değildir.

Ollama'nın Lokal API Authentication Modeli

Ollama'nın yerel API kullanım modeli ağırlıklı olarak aynı makine veya güvenilir ağdaki istemcilerin doğrudan bağlantısına dayanır. Bu nedenle kurumsal kullanıcı doğrulama katmanı gateway üzerinde tasarlanmalıdır. Backend portu kullanıcı ağına kapatıldığında gateway bypass edilmesi zorlaşır. Yönetim endpoint'leri ayrıca sınırlandırılmalıdır. Böylece Ollama inference işini yaparken kimlik ve politika yönetimi bu görev için daha uygun bileşene bırakılır.

Reverse Proxy Authentication

Reverse proxy authentication bütün istemcilerin tek kontrol noktasında doğrulanmasını sağlar. Nginx tek başına temel yöntemleri uygulayabilir veya identity-aware proxy ile birlikte çalışabilir. Kullanıcı bilgisi backend'e güvenilir header üzerinden aktarılabilir. Bu header yalnızca proxy tarafından oluşturulmalı ve doğrudan kullanıcıdan gelen değerler temizlenmelidir. Audit log kullanıcı kimliğiyle model çağrısını ilişkilendirebilir.

API Key

API key uygulamadan uygulamaya bağlantıda basit ve etkili yöntem olabilir. Her entegrasyon için ayrı key verilmesi kullanım takibini kolaylaştırır. Ortak tek key bütün departmanlarla paylaşılmamalıdır. Key secret manager içinde saklanmalı, düzenli döndürülmeli ve gerekli olduğunda anında iptal edilebilmelidir. Kullanıcı bazlı yetkilendirme gereken insan kullanımında SSO daha uygun bir modeldir.

Basic Authentication

Basic Authentication küçük pilotlarda hızlı koruma sağlayabilir ancak kurumsal kullanıcı yönetiminin nihai çözümü olarak görülmemelidir. Parolalar yalnızca TLS üzerinden gönderilmelidir. Ortak kullanıcı ve ortak parola kullanmak audit trail değerini azaltır. Mevcut identity sistemine entegrasyon mümkünse daha güçlü SSO modeli tercih edilmelidir. Basic Authentication geçici kullanımda bile güçlü parola ve düzenli rotation gerektirir.

OAuth2 / OIDC

OAuth2 ve OIDC modern kurumsal uygulamalarda merkezi identity entegrasyonu için uygundur. Kullanıcı mevcut şirket hesabıyla giriş yapabilir ve gateway doğrulanmış identity bilgisini alabilir. Token claim'leri departman veya grup bazlı authorization için kullanılabilir. Token lifetime sınırlı tutulabilir ve logout veya account disable işlemleri merkezi sistemden yönetilebilir. Bu model çalışan yaşam döngüsünü ayrı AI kullanıcı veritabanında tekrar oluşturma ihtiyacını azaltır.

Active Directory / Entra ID

Active Directory veya Entra ID kullanan kurumlar mevcut kullanıcı ve grup bilgisini AI gateway yetkilendirmesine bağlayabilir. İnsan kaynaklarından ayrılan kullanıcının hesabı devre dışı bırakıldığında AI erişimi de otomatik kapanabilir. Security group'lar belirli model izinlerine eşlenebilir. Örneğin yalnızca yazılım geliştirme grubuna coder modeli sunulabilir. Bu entegrasyon access review süreçlerini mevcut kurumsal kimlik yönetimiyle uyumlu hale getirir.

LDAP

LDAP mevcut directory altyapısıyla entegrasyon gerektiren ortamlarda kullanılabilir. Kullanıcı ve grup sorguları gateway veya identity proxy tarafından yapılabilir. LDAP bağlantısının kendisi TLS ile korunmalıdır. Grup membership bilgisi authorization kararında kullanılabilir. Authentication sorgularının her model isteğinde directory üzerinde aşırı yük oluşturmayacak şekilde cache veya session tasarımı yapılmalıdır.

SSO

SSO çalışanların AI servisine mevcut kurumsal hesaplarıyla erişmesini sağlar. Kullanıcının yeni parola oluşturması gerekmez ve MFA politikaları korunabilir. Kullanıcı departman değiştirirse erişim grupları merkezi identity sisteminde güncellenir. Audit log gerçek çalışan kimliğiyle eşleşir. Kurumsal AI servisinin diğer iç uygulamalarla aynı giriş deneyimini sunması kullanıcı benimsemesini de kolaylaştırır.

Kullanıcı ve Departman Bazlı Yetkilendirme

Her kullanıcının bütün modellere ve aynı kapasiteye erişmesi gerekli değildir. Departman bazlı yetkilendirme GPU maliyetini kontrol ederken hassas kullanım senaryolarını da sınırlandırabilir. RBAC modeli kullanıcıyı rol ve gruplarla eşleştirerek erişim kurallarını merkezi hale getirir. Quota ve rate limit kullanıcıların sistemi adil biçimde paylaşmasını sağlar. Audit trail ise hangi kullanıcının hangi modele ne zaman eriştiğini güvenlik ve kapasite analizi için kaydeder.

RBAC

Role-Based Access Control kullanıcı yetkilerini tek tek tanımlamak yerine roller üzerinden yönetir. Viewer, AI User, Developer ve AI Administrator gibi roller oluşturulabilir. Normal AI User yalnızca inference çağrısı yaparken administrator model yönetimi yapabilir. Roller identity provider gruplarına eşlenebilir. Bu yapı çalışan sayısı arttıkça kullanıcı bazlı manuel permission yönetiminden daha sürdürülebilir hale gelir.

Grup Bazlı Erişim

Grup bazlı erişim özellikle mevcut Active Directory veya SSO altyapısıyla kolay uygulanır. İnsan kaynakları, yazılım, finans veya müşteri destek ekipleri farklı model ve kullanım politikalarına sahip olabilir. Grup membership değişikliği merkezi identity sisteminde yapıldığında AI erişimi otomatik güncellenebilir. Ortak servis hesapları insan kullanıcı gruplarından ayrı tutulmalıdır. Yetki grupları düzenli access review sürecinden geçirilmelidir.

Departman Bazlı Model Yetkisi

Bazı modeller belirli departman görevleri için optimize edilebilir veya yüksek GPU maliyeti nedeniyle sınırlı tutulabilir. Genel küçük model bütün personele, daha büyük reasoning modeli yalnızca belirli iş gruplarına sunulabilir. Kodlama modeli yazılım ve DevOps ekiplerine açılabilir. Model erişim kararı yalnızca kalite değil lisans ve veri riski açısından da değerlendirilebilir. Bu politika gateway routing katmanında uygulanmalıdır.

Kullanıcı Bazlı Quota

Kullanıcı bazlı quota GPU kapasitesinin birkaç yoğun kullanıcı tarafından tüketilmesini önler. Günlük request, token veya inference süresi sınırı uygulanabilir. Daha yüksek ihtiyacı olan kullanıcı veya servis için farklı plan tanımlanabilir. Quota aşımı kullanıcıya açık mesajla gösterilmelidir. Bu metrikler hangi ekiplerin daha fazla kapasiteye gerçekten ihtiyaç duyduğunu göstermesi açısından da yararlıdır.

Rate Limit

Rate limit kısa zaman içinde gönderilebilecek istek sayısını sınırlar. Otomasyon script'inin hata nedeniyle saniyede onlarca request göndermesi böylece engellenebilir. İnsan kullanıcı ile service account için farklı limitler uygulanabilir. Burst toleransı normal chat deneyiminin gereksiz yere engellenmesini önler. Limit olaylarının merkezi loglanması kapasite ve kötüye kullanım incelemesini kolaylaştırır.

Audit Trail

Audit trail kullanıcı kimliği, model adı, zaman, endpoint, sonuç durumu ve yönetsel işlemleri kayıt altına alabilir. Her prompt'un tam metnini audit için tutmak zorunlu değildir. Metadata-only logging çoğu operasyon senaryosu için yeterli olabilir. Model pull, delete ve yetki değişikliği gibi administrator işlemleri daha ayrıntılı kaydedilmelidir. Loglar değiştirilmesi zor merkezi sisteme gönderilirse incident incelemesinde daha güvenilir kanıt sağlar.

Model Yönetim Endpoint'leri Nasıl Korunmalı?

Model yönetimi inference çağrısından daha yüksek yetki gerektirir çünkü sunucunun çalışma durumunu doğrudan değiştirebilir. Kullanıcıya model pull, create veya delete yetkisi vermek storage tüketimi, lisans ve supply-chain riski oluşturabilir. Bu işlemler yalnızca AI administrator rolüne açılmalıdır. Management network veya ayrı gateway endpoint kullanmak erişim sınırını netleştirir. Model değişiklikleri staging evaluation ve approval sürecinden sonra production'a taşınmalıdır.

Inference Endpoint'leri

Inference endpoint'leri normal kullanıcı ve kurumsal uygulamaların eriştiği temel servis alanıdır. Bu endpoint'lerde model listesi de kullanıcı rolüne göre filtrelenebilir. Prompt ve generation parametreleri güvenlik politikasıyla sınırlandırılabilir. Çok yüksek context veya output token isteği GPU maliyetini yükselteceği için üst limit uygulanması yararlıdır. Inference erişimi model yönetim yetkisi anlamına gelmemelidir.

Model Pull İşlemleri

Model pull dış kaynaktan büyük artifact indirilmesine ve yeni modelin sunucuya eklenmesine neden olur. Bu işlem yalnızca güvenilir model repository ve onaylanmış model adları için yapılmalıdır. Lisans metadata'sı indirme öncesinde kontrol edilebilir. Air-gapped sistemde doğrudan internet pull yerine internal approved registry kullanılmalıdır. Model digest kayıt altına alınarak production sürümü sabitlenebilir.

Model Create İşlemleri

Model create işlemi özel model configuration veya türetilmiş model oluşturulmasına imkan verebilir. Kurumsal ortamda geliştiricinin rastgele model tanımı oluşturması governance sorununa yol açabilir. Template, system prompt ve parameter değişiklikleri version control altında tutulmalıdır. Yeni model önce staging üzerinde değerlendirilmelidir. Production'a promotion onaylandıktan sonra yapılmalıdır.

Model Delete İşlemleri

Model delete yanlış kullanıldığında çalışan servislerin ihtiyaç duyduğu artifact'in kaybolmasına neden olabilir. Normal kullanıcıların bu endpoint'e erişmesi için iş gerekçesi yoktur. Production model silme işlemi change management ve backup planıyla yapılmalıdır. Aktif deployment tarafından kullanılıp kullanılmadığı kontrol edilmelidir. Silme olayı audit log'a administrator kimliğiyle kaydedilmelidir.

Normal Kullanıcı ile AI Administrator Ayrımı

Normal kullanıcı yalnızca kendisine izin verilen modellerle inference yapmalıdır. AI Administrator model lifecycle, gateway policy ve kapasite ayarlarını yönetebilir. Bu iki rolün ayrılması yanlışlıkla veya kötü niyetli yapılandırma değişikliğini azaltır. Administrator erişimi MFA ve daha sıkı network politikasıyla korunabilir. Günlük sohbet için administrator hesabı kullanılması engellenmelidir.

Model Yönetim Ağının İzole Edilmesi

Management plane ayrı subnet veya yalnızca administrator VPN üzerinden erişilebilir hale getirilebilir. Kullanıcı VLAN'ından model yönetim endpoint'ine network route bulunmaması güçlü ek kontrol sağlar. Gateway kullanıcı trafiğini sadece inference endpoint'lerine yönlendirir. Yönetim işlemleri ayrı hostname ve certificate üzerinden sunulabilir. Network izolasyonu RBAC hatası durumunda ikinci güvenlik katmanı oluşturur.

Ollama'da Cloud Özelliklerini Tamamen Kapatmak

Şirket içi LLM kurulumunda “veri dışarı çıkmıyor” iddiasının teknik olarak doğrulanması gerekir. Ollama'nın cloud ile ilişkili özellikleri kullanılmayacaksa local-only yaklaşım tercih edilmeli ve ilgili cloud seçenekleri kapatılmalıdır. Uygulama seviyesindeki ayara ek olarak sunucunun outbound network erişimini firewall ile sınırlamak daha güçlü kontrol sağlar. DNS ve network logları beklenmeyen bağlantı olup olmadığını gösterebilir. Güvenlik review sırasında yalnızca configuration'a değil gerçek trafik gözlemine bakmak gerekir.

Local-Only Mode Nedir?

Local-only yaklaşım model inference işlemlerinin ve ilgili servislerin yalnızca yerel altyapı kaynaklarını kullanmasını hedefler. Bu modelde cloud model çağrıları veya dış web özellikleri kullanılmaz. Kurum kendi model artifact'lerini ve güncelleme sürecini yönetir. Ancak model indirme işlemi internet gerektiriyorsa ayrı kontrollü management ortamı kullanılabilir. Production inference sunucusunun internete çıkması zorunlu değildir.

OLLAMA_NO_CLOUD

OLLAMA_NO_CLOUD gibi cloud kullanımını kapatmaya yönelik yapılandırmalar kurumun local-only politikasının bir parçası olarak değerlendirilebilir. Uygulama configuration'ı tek başına nihai güvenlik sınırı olarak görülmemelidir. Firewall egress rule ve proxy politikası ikinci kontrol katmanı sağlamalıdır. Environment variable değeri deployment config içinde version control ile yönetilebilir. Değişiklik sonrası network telemetry üzerinden davranış doğrulanmalıdır.

Cloud Model Kullanımının Kapatılması

Kurumsal politika yalnızca onaylanmış yerel modellerin kullanılmasına izin verebilir. Kullanıcı arayüzünde cloud model seçenekleri gösterilmemelidir. Gateway de model allowlist uygulayarak bilinmeyen hedeflere routing yapılmasını engelleyebilir. Model katalog yönetimi merkezi platform ekibinde tutulmalıdır. Bu yaklaşım hem veri güvenliği hem maliyet kontrolü açısından daha öngörülebilir kullanım sağlar.

Web Search Özelliğinin Kapatılması

Web search kullanan AI özellikleri kullanıcı prompt'unun veya türetilmiş sorgunun dış servislere gitmesine neden olabilir. Tamamen izole şirket içi kullanım hedefleniyorsa bu entegrasyon devre dışı bırakılmalıdır. RAG yalnızca internal doküman kaynaklarını kullanacak şekilde tasarlanabilir. Kullanıcının dış web erişimine gerçekten ihtiyacı varsa ayrı onaylı proxy ve sanitization katmanı kullanılmalıdır. Özellik kapalı olsa bile egress firewall politikası beklenmeyen dış bağlantıları engellemeye devam etmelidir.

Outbound Network Trafiğinin Firewall ile Engellenmesi

Egress firewall uygulamanın dış servislere bağlantısını altyapı seviyesinde sınırlar. Production Ollama sunucusu yalnızca internal DNS, monitoring ve gerekli storage servislerine erişebilir. Model güncellemesi farklı management sunucusundan internal registry'ye aktarılabilir. Böylece inference host internete doğrudan çıkmak zorunda kalmaz. Firewall deny logları beklenmeyen bağlantı girişimlerini güvenlik ekibine gösterebilir.

Gerçekten Dışarı Trafik Çıkmadığının Doğrulanması

Configuration dosyasına bakmak tek başına dış trafik olmadığını kanıtlamaz. Firewall log, DNS query log ve network flow kayıtları incelenmelidir. Test sırasında kullanıcı prompt gönderirken bağlantı davranışı gözlemlenebilir. Container veya host seviyesinde packet capture kontrollü test ortamında ek doğrulama sağlayabilir. Bu kontrol production'a geçmeden önce security acceptance test'in parçası olmalıdır.

Air-Gapped Ağda Ollama Nasıl Kullanılır?

Air-gapped kurulumda inference sunucusunun internet bağlantısı bulunmadığı için kurulum paketleri ve modeller kontrollü transfer sürecinden geçer. Ollama binary veya container image güvenilir bağlantılı ortamda temin edilip güvenlik kontrolünden sonra iç ağa aktarılabilir. Model artifact'leri de aynı şekilde hash ve lisans doğrulamasından geçirilmelidir. Internal artifact repository güncelleme ve rollback sürecini kolaylaştırır. Bu model yüksek veri hassasiyeti olan sistemlerde güçlü izolasyon sağlar ancak operasyon sürecinin önceden iyi tasarlanmasını gerektirir.

İnternetsiz Sunucuya Ollama Kurulumu

İnternetsiz sunucuya kurulum için gerekli binary, package veya container image önceden hazırlanmalıdır. Dosyalar güvenilir kaynaktan indirilip malware ve integrity kontrolünden geçirilmelidir. Transfer edilen version deployment manifest içinde sabitlenmelidir. Kurulum sırasında internetten dependency çekmeye çalışan adımlar önceden tespit edilmelidir. Internal repository kullanmak tekrar eden kurulumları daha kolay hale getirir.

Model Dosyalarının Güvenli Ortamdan İndirilmesi

Model artifact'i internet erişimi olan kontrollü bir staging ortamında indirilebilir. Kaynak model repository ve yayıncı kimliği doğrulanmalıdır. Model lisansı ve intended use bilgisi kayıt altına alınmalıdır. Dosyanın digest veya checksum değeri transfer belgesine eklenebilir. Güvenlik ve hukuk onayından geçen artifact internal registry'ye taşınmalıdır.

Offline Model Transferi

Offline transfer güvenlik seviyesi yüksek ortamlarda kontrollü medya veya güvenilir cross-domain transfer mekanizmasıyla yapılabilir. Transfer medyası kurumun removable media politikasına uygun olmalıdır. Dosya iç ağda tekrar hash kontrolünden geçirilmelidir. Büyük model dosyaları için storage kapasitesi ve transfer süresi önceden planlanmalıdır. Kullanıcıların kendi indirdiği modelleri USB ile production sunucusuna taşımasına izin verilmemelidir.

Hash / Checksum Kontrolü

Checksum dosyanın transfer sırasında değişip değişmediğini doğrulamak için kullanılabilir. Güvenilir ortamda hesaplanan hash iç ağda yeniden hesaplanarak karşılaştırılır. Değer deployment kaydıyla birlikte saklanabilir. Model artifact'in güvenilir yayıncıdan geldiğini tek başına hash kanıtlamaz, kaynak doğrulaması da gereklidir. İmza veya provenance bilgisi varsa checksum kontrolüne ek olarak değerlendirilmelidir.

Model Artifact Onayı

Production model katalogunda yalnızca onaylanmış artifact'ler bulunmalıdır. Onay sürecinde lisans, kaynak, boyut, güvenlik ve benchmark sonucu değerlendirilebilir. Her artifact digest ile benzersiz tanımlanmalıdır. “latest” gibi hareketli tag'ler production referansı olarak tek başına kullanılmamalıdır. Onaylanan model belirli version ID ile deployment sistemine aktarılmalıdır.

Güncelleme Süreci

Air-gapped model güncellemesi otomatik internet pull yaklaşımından farklıdır. Yeni model önce bağlantılı evaluation ortamında alınır ve bütün kontrollerden geçirilir. Daha sonra internal artifact repository'ye import edilir. Staging benchmark ve regression evaluation başarılı olursa production'a promotion yapılır. Eski model artifact'i rollback için belirli süre saklanmalıdır.

Llama mı Qwen mi?

Llama mı Qwen mi sorusuna bütün şirketler için geçerli tek cevap vermek doğru değildir. Model seçimi görev, Türkçe kalite, latency, GPU bütçesi, tool calling ve lisans gereksinimi üzerinden yapılmalıdır. Bazı ekiplerde küçük Qwen modeli düşük maliyetle yeterli sonuç verirken başka bir kullanımda Llama ailesinin belirli sürümü daha iyi sonuç verebilir. En sağlıklı yöntem gerçek kurumsal prompt dataset'i üzerinde ikisini yan yana benchmark etmektir. Model markası yerine ölçülebilir görev başarısı, güvenlik ve toplam sahip olma maliyeti kararın temelini oluşturmalıdır.

Model Markasına Göre Değil Kullanım Senaryosuna Göre Seçim

Genel benchmark sıralaması sizin doküman özetleme veya Türkçe destek talebi sınıflandırma işinizi doğrudan temsil etmeyebilir. Model seçiminde önce kullanım senaryosu ve kabul kriteri tanımlanmalıdır. Örneğin yapılandırılmış JSON üretiminde schema uyumu, kod analizinde bug tespit doğruluğu veya rapor üretiminde Türkçe akıcılık ölçülebilir. Aynı test seti Llama ve Qwen varyantlarında çalıştırılır. Sonuç kalite, latency ve GPU maliyetiyle birlikte karşılaştırılır.

Llama Ailesinin Güçlü Yanları

Llama ailesi geniş geliştirici ekosistemi ve farklı model boyutları sayesinde şirket içi kullanımda sık değerlendirilen seçeneklerden biridir. Llama 3.1, 3.2 ve 3.3 sürümleri farklı kapasite ihtiyaçlarına hitap ederken Llama 4 multimodal ve MoE mimarisiyle daha büyük deployment senaryolarına yönelmiştir. Ollama Llama 4 için Scout ve Maverick varyantlarını sunmaktadır. Scout'un Ollama kütüphanesindeki Q4_K_M paketi yaklaşık 67 GB, Maverick'in ilgili paketi yaklaşık 245 GB görünmektedir; bu fark donanım planlamasında önemlidir. Türkçe kullanım resmi destek kapsamı ve gerçek şirket prompt'ları üzerinden ayrıca test edilmelidir.

Qwen Ailesinin Güçlü Yanları

Qwen ailesi geniş model boyutu seçenekleri, çok dilli yetenekleri ve coding varyantları sayesinde şirket içi görevlerde güçlü adaydır. Qwen3 ailesi dense ve MoE seçenekleriyle 0.6B'den çok büyük modellere kadar uzanırken Qwen3.5 Ollama üzerinde 0.8B, 2B, 4B, 9B, 27B, 35B ve 122B gibi seçenekler sunmaktadır. Qwen3.5 model kartı text ve image desteği ile geniş dil kapsamı belirtmektedir. Bu geniş seçenek aralığı küçük departman sunucusundan daha büyük GPU altyapısına kadar farklı maliyet profilleri oluşturur. Türkçe performans yine kurumun kendi benchmark setiyle doğrulanmalıdır.

Genel Chat

Genel chat kullanımında modelin tek soruluk benchmark başarısından çok çok turlu konuşma tutarlılığı önemlidir. Kullanıcılar kısa bilgi soruları, metin düzenleme ve özetleme gibi farklı görevleri aynı arayüzde yapabilir. Küçük ve orta boy model kullanıcı sayısı yüksek ortamda daha düşük latency sağlayabilir. Büyük model bazı zor sorularda kalite artışı sunabilir ancak GPU maliyetini yükseltir. Pilot kullanımda kullanıcı memnuniyeti ve gerçek latency verileri model seçimini belirlemelidir.

Türkçe Kullanım

Türkçe için yalnızca “multilingual” etiketine bakmak yeterli değildir. Eklerin doğru kullanımı, kurumsal terimler, resmi yazışma biçimi ve uzun metinde tutarlılık ayrı test edilmelidir. Şirketin gerçek anonimleştirilmiş prompt'larından test seti oluşturmak bu nedenle önemlidir. Llama ve Qwen aynı prompt'larla blind değerlendirmeye sokulabilir. Dil kalitesinin yanında hallucination ve instruction following oranı da ölçülmelidir.

Kodlama

Kodlama görevlerinde genel chat modeli yerine coder odaklı model daha iyi sonuç verebilir. Repository dili, framework ve kullanılan internal library'ler benchmark setine eklenmelidir. Code completion, refactoring, test üretme ve hata analizi ayrı görevler olarak ölçülebilir. Modelin kod üretmesi kadar güvenli olmayan API veya dependency önermemesi de önemlidir. Geliştirici araçlarının modele erişimi source code gizlilik politikasına uygun olmalıdır.

Reasoning

Reasoning ağırlıklı görevler modelin daha fazla generation süresi veya token tüketmesine neden olabilir. Bu nedenle yalnızca doğruluk değil latency ve kaynak maliyeti de ölçülmelidir. Bazı küçük modeller rutin sınıflandırma veya özetleme için yeterliyken karmaşık analizler daha güçlü modele yönlendirilebilir. Model routing bu maliyet farkını yönetmek için etkili olur. Kullanıcı bütün sorgularda en büyük modeli kullanmak zorunda kalmaz.

Tool Calling

Tool calling şirket içi LLM'nin ERP, ticket sistemi veya bilgi tabanı gibi araçlarla etkileşmesini sağlar. Modelin doğru tool seçmesi ve parametreleri beklenen schema'ya göre üretmesi gerekir. Yetkilendirme model kararına bırakılmamalıdır; backend her tool çağrısında kullanıcı permission'ını doğrulamalıdır. Llama ve Qwen modellerinin tool calling başarısı aynı gerçek workflow testleriyle karşılaştırılabilir. Yanlış tool kullanımının etkisi yüksekse approval veya confirmation adımı eklenmelidir.

Multimodal Kullanım

Multimodal modeller text yanında image gibi ek girdileri işleyebilir. Belge ekran görüntüsü, teknik diyagram veya fotoğraf analizi kullanım senaryolarında bu özellik değerli olabilir. Llama 4 Ollama model kartında text ve image input desteği bulunurken Qwen3.5 de multimodal model ailesi olarak sunulmaktadır. Görsel içeriğin hassas veri barındırabileceği unutulmamalıdır. Dosya retention ve log politikası text prompt'lardan ayrı değerlendirilmelidir.

Structured Output

Structured output ERP entegrasyonu, veri çıkarma ve workflow otomasyonu için kritik olabilir. Modelden JSON istenmesi tek başına her zaman geçerli schema garantisi vermez. Çıktı backend tarafında schema validation'dan geçirilmelidir. Hatalı response yeniden denenebilir veya daha güvenilir modele escalation yapılabilir. Model benchmark'ında yalnızca metin kalitesi değil geçerli JSON oranı da ölçülmelidir.

RAG

RAG şirketin kendi dokümanlarını modele ek bilgi olarak sunar. Model seçimi retrieval başarısından bağımsız değerlendirilmemelidir çünkü kötü retrieval en güçlü modelde bile kötü yanıt üretebilir. Llama ve Qwen aynı retrieved context üzerinde karşılaştırılabilir. Citation doğruluğu, dokümana bağlı kalma ve bilinmeyen durumda cevap vermeme davranışı ölçülebilir. RAG authorization özellikle departmanlar arası veri sınırında zorunludur.

Güncel Llama Modelleri Ollama'da Nasıl Konumlanıyor?

Ollama ekosisteminde Llama 3.1, 3.2, 3.3 ve Llama 4 farklı kullanım profillerine hitap eder. Daha eski küçük modeller düşük donanım maliyeti ve hızlı inference nedeniyle hâlâ anlamlı olabilir. Llama 4 ise Scout ve Maverick gibi büyük MoE modelleriyle daha yüksek donanım ihtiyacına sahiptir. Ollama kütüphanesinde Scout'un yaklaşık 67 GB Q4 paketi ve Maverick'in yaklaşık 245 GB Q4 paketi listelenmektedir. Bu nedenle güncel model her zaman kurum için en doğru model anlamına gelmez.

Llama 3.1

Llama 3.1 ailesi farklı model boyutlarıyla yerel inference ekosisteminde uzun süredir kullanılan seçeneklerden biridir. Şirket içinde mevcut benchmark ve entegrasyonları olan ekipler için sürümü hemen değiştirmek zorunlu değildir. Production modeli yalnızca daha yeni sürüm çıktığı için güncellemek yerine regression değerlendirmesi yapılmalıdır. Daha küçük quantized seçenekler orta seviye GPU'larda uygulanabilir olabilir. Kullanım senaryosu karşılanıyorsa stabil eski model operasyon açısından daha değerli olabilir.

Llama 3.2

Llama 3.2 daha küçük model seçenekleri ve farklı kullanım profilleriyle edge veya düşük kaynaklı senaryolarda değerlendirilebilir. Küçük modelin avantajı hızlı cold start ve daha yüksek kullanıcı concurrency olasılığıdır. Buna karşılık karmaşık reasoning veya uzun doküman görevlerinde kalite sınırı daha erken görülebilir. Kurumsal pilotta küçük model first-line görevler için kullanılabilir. Başarısız veya yüksek riskli sorgular daha güçlü modele yönlendirilebilir.

Llama 3.3

Llama 3.3 daha güçlü genel amaçlı kullanım senaryoları için değerlendirilebilecek Llama ailesi seçeneklerinden biridir. Büyük model olması GPU ve quantization kararını önemli hale getirir. Tek kullanıcılı testte iyi görünen performans çok kullanıcılı ortamda farklılaşabilir. Context ve parallel request etkisi load test ile ölçülmelidir. Production seçimi yalnızca model benchmark değil maliyet ve throughput verisini de içermelidir.

Llama 4

Llama 4 Ollama'da multimodal Scout ve Maverick seçenekleriyle konumlanmaktadır. Resmi Ollama model kartı Scout'u 109B toplam parametreli, 17B aktif parametreli MoE model; Maverick'i 400B toplam parametreli, 17B aktif parametreli MoE model olarak tanımlar. Aynı kart Scout ve Maverick için text ve image girişini desteklediğini belirtir. Büyük artifact boyutu nedeniyle modelin yalnızca aktif parametre sayısına bakarak VRAM planlamak doğru değildir. Production öncesi gerçek quantized artifact ve runtime memory kullanımı ölçülmelidir.

Scout

Llama 4 Scout daha büyük context ve multimodal kullanım ihtiyacı olan kurumsal senaryolarda değerlendirilebilir. Ollama kütüphanesinde Q4_K_M paketinin yaklaşık 67 GB olduğu görülmektedir. Bu boyut tipik tek küçük GPU sunucusundan daha yüksek memory planlaması gerektirir. CPU offload teknik olarak mümkün olsa bile latency ve throughput ciddi biçimde etkilenebilir. Scout seçimi yapılmadan önce gerçek eşzamanlı kullanıcı yüküyle GPU benchmark çalıştırılmalıdır.

Maverick

Llama 4 Maverick daha büyük MoE yapısıyla Scout'a göre çok daha yüksek artifact ve memory gereksinimine sahiptir. Ollama kütüphanesinde Maverick Q4_K_M paketinin yaklaşık 245 GB olduğu listelenmektedir. Bu büyüklük multi-GPU veya çok yüksek bellekli inference altyapısını gündeme getirir. Küçük ve orta ölçekli şirketlerin yalnızca modelin yeni olması nedeniyle bu maliyete girmesi gerekli değildir. Kullanım senaryosu daha küçük modelle karşılanıyorsa toplam sahip olma maliyeti önemli ölçüde düşebilir.

Büyük Llama Modellerinin Donanım Maliyeti

Büyük model maliyeti yalnızca GPU satın alma fiyatından oluşmaz. Yüksek VRAM, güçlü PSU, sunucu kasası, enerji, soğutma ve bakım maliyeti birlikte değerlendirilmelidir. Multi-GPU sistemde interconnect ve PCIe topology de performansı etkileyebilir. Model dosyasının tamamını hızlı storage üzerinde tutmak load süresini azaltır. Bu yüzden büyük model yatırımından önce küçük ve orta modellerin gerçek görevlerde yeterli olup olmadığı benchmark edilmelidir.

Daha Eski Küçük Llama Modellerinin Hâlâ Mantıklı Olduğu Senaryolar

Metin sınıflandırma, kısa özet, basit bilgi çıkarma veya belirli template çıktısı gibi görevlerde küçük model yeterli olabilir. Bu modeller daha düşük VRAM tüketerek aynı GPU üzerinde daha fazla eşzamanlı kullanıcıya izin verebilir. Cold start süresi ve enerji tüketimi de genellikle daha düşüktür. Kullanıcı deneyiminde düşük latency bazen küçük kalite farkından daha değerlidir. Kurumsal model seçiminin “en büyük modeli çalıştırabilir miyiz?” yerine “işi en düşük toplam maliyetle hangi model çözüyor?” sorusuna cevap vermesi gerekir.

Güncel Qwen Modelleri Ollama'da Nasıl Konumlanıyor?

Qwen ailesi Ollama üzerinde geniş boyut seçenekleri ve görev odaklı varyantlarla dikkat çeker. Qwen3 modelleri 0.6B, 1.7B, 4B, 8B, 14B, 30B, 32B ve 235B gibi seçeneklerle listelenmektedir. Qwen3.5 tarafında ise 0.8B, 2B, 4B, 9B, 27B, 35B ve 122B seçenekleri Ollama kütüphanesinde yer almaktadır. Bu geniş ölçek aralığı şirketlerin tek GPU'dan daha güçlü altyapılara kadar farklı deployment profilleri oluşturmasını sağlar. Türkçe ve görev kalitesi gerçek benchmark setiyle ayrıca doğrulanmalıdır.

Qwen3

Qwen3 dense ve Mixture-of-Experts seçenekleri barındıran geniş bir model ailesidir. Ollama model kartında 0.6B'den 235B'ye uzanan varyantlar ve thinking ile tool yetenekleri gösterilmektedir. Küçük modeller basit ve hızlı görevlerde, orta modeller daha genel kullanımda değerlendirilebilir. Büyük MoE modeller daha yüksek kalite hedeflerken memory ve operasyon maliyeti getirir. Kurumsal deployment için model boyutu gerçek prompt başarısı ve concurrency hedefiyle eşleştirilmelidir.

Qwen3.5

Qwen3.5 Ollama kütüphanesinde multimodal, tool ve thinking özellikleriyle sunulan daha yeni Qwen ailesidir. 0.8B, 2B, 4B, 9B, 27B, 35B ve 122B model seçenekleri listelenmektedir. Varsayılan 9B varyantın yaklaşık 6.6 GB, 27B'nin yaklaşık 17 GB, 35B'nin yaklaşık 24 GB ve 122B'nin yaklaşık 81 GB artifact boyutuna sahip olduğu görülmektedir. Bu boyutlar doğrudan VRAM ihtiyacı değildir ancak kapasite planlamasında başlangıç göstergesidir. Runtime context ve parallel request belleği ayrıca ölçülmelidir.

Küçük Qwen Modelleri

0.8B, 2B ve 4B gibi küçük modeller edge, sınıflandırma, kısa özet veya düşük latency gereken görevlerde değerlendirilebilir. Bu boyutlar daha mütevazı GPU veya bazı CPU tabanlı sistemlerde de çalıştırılabilir. Kalite büyük modele göre sınırlı olabileceği için kritik karar desteğinde doğrudan kullanılmamalıdır. Küçük model ilk aşama router veya intent classifier rolünde faydalı olabilir. Başarısız sonuçlar daha büyük modele escalation edilerek maliyet dengesi kurulabilir.

Orta Boy Qwen Modelleri

9B, 14B, 27B veya 35B sınıfındaki modeller birçok kurum için kalite ve donanım arasında dengeli seçenek oluşturabilir. Tek yüksek VRAM'li GPU veya uygun quantization ile uygulanabilir deployment profilleri oluşturmak mümkündür. Gerçek bellek ihtiyacı context ve concurrency ile birlikte ölçülmelidir. Genel chat, doküman özetleme ve kod destek görevleri aynı modelde benchmark edilebilir. Bir modelin ortalama sonucu iyi olsa bile departman bazlı görevlerde farklı sonuçlar verebileceği unutulmamalıdır.

Büyük ve MoE Qwen Modelleri

Büyük Qwen modelleri daha güçlü reasoning ve geniş görev kapsamı sunabilir ancak sunucu maliyeti ciddi biçimde artar. MoE mimarisinde aktif parametre sayısı düşük olsa bile model ağırlıklarının saklanması için yüksek bellek veya hızlı transfer mekanizması gerekir. Multi-GPU topology ve model loading süresi kullanıcı deneyimini etkileyebilir. Büyük model yalnızca az sayıdaki zor sorgu için kullanılacaksa routing ile talep üzerine devreye alınabilir. Bütün kullanıcılara varsayılan model yapmak çoğu şirkette gereksiz kaynak tüketimine yol açabilir.

Qwen Coder Modelleri

Qwen Coder modelleri yazılım geliştirme, code completion, bug analysis ve refactoring gibi görevler için değerlendirilir. Ollama kütüphanesinde Qwen3 Coder modelleri de ayrı aile olarak yer almaktadır. Kurumun kullandığı diller ve framework'ler gerçek test setine dahil edilmelidir. Internal repository kodları modele gönderiliyorsa inference servisinin veri politikası ve access control'ü önem kazanır. Kod önerileri normal code review ve güvenlik taramasından geçmeye devam etmelidir.

Türkçe ve Çok Dilli Kullanım

Qwen3 model kartı geniş çok dilli destekten söz etmektedir ve Qwen3.5 daha da geniş dil kapsamı belirtmektedir. Buna rağmen kurumsal Türkçe kalite yalnızca model kartına göre kabul edilmemelidir. Yerel terimler, resmi yazı biçimi, hukuk veya teknik jargon farklı sonuçlar üretebilir. En az yüzlerce gerçek ve anonimleştirilmiş prompt ile değerlendirme yapmak daha güvenilir sonuç sağlar. Kullanıcı değerlendirmesiyle otomatik metriklerin birlikte kullanılması yararlıdır.

Llama ve Qwen Lisansları Kurumsal Kullanımı Nasıl Etkiler?

Modelin teknik olarak indirilebilir olması kurumun onu her koşulda kullanabileceği anlamına gelmez. Ollama aracının lisansı ile çalıştırılan modelin lisansı birbirinden ayrı değerlendirilmelidir. Qwen modellerinin belirli sürümleri Apache 2.0 gibi lisanslarla yayınlanabilirken Llama modelleri Meta'nın Community License koşullarına tabidir. Örneğin Ollama üzerindeki Qwen3.5 4B sayfası Apache License 2.0 bilgisi gösterirken Llama 4 Scout sayfası Llama 4 Community License içerir. Kurum hukuk ekibi commercial use, redistribution, fine-tuning ve kullanım sınırlamalarını model bazında incelemelidir.

Ollama Lisansı

Ollama yazılımının lisansı kullanılan modelin lisansından ayrı konudur. Bir inference aracını şirket içinde kullanma hakkı model ağırlıklarının ticari kullanım koşullarını otomatik olarak değiştirmez. Kurum deployment envanterinde hem runtime software hem model artifact lisansını kayıt altına almalıdır. Version değiştiğinde lisansın aynı kaldığı varsayılmamalıdır. Procurement veya hukuk incelemesi bu ayrımı açık biçimde ele almalıdır.

Qwen Model Lisansları

Qwen ailesindeki model lisansları sürüm ve artifact bazında kontrol edilmelidir. Örneğin Ollama üzerindeki Qwen3.5 4B model detayında Apache License 2.0 görünmektedir. Bunun başka bütün Qwen sürümleri için otomatik geçerli olduğu varsayılmamalıdır. Model metadata ve resmi yayın sayfası deployment öncesinde incelenmelidir. Approved model registry içinde lisans adı ve source URL gibi metadata saklanabilir.

Llama Community License

Llama modelleri Meta'nın Llama Community License koşulları altında sunulur ve Apache 2.0 ile aynı lisans modeli değildir. Llama 4 Scout'un Ollama sayfasında Llama 4 Community License açık biçimde gösterilmektedir. Modelin intended use ve acceptable use koşulları da değerlendirilmelidir. Kurumsal hukuk ekibi modelin kullanım amacını lisansla karşılaştırmalıdır. Özellikle model çıktısının ürün içinde kullanılması veya türetilmiş model dağıtımı gibi senaryolar ayrı incelenmelidir.

Commercial Use

Commercial use değerlendirmesi şirketin modeli yalnızca iç çalışan aracı olarak mı yoksa müşteri ürününün parçası olarak mı kullanacağını dikkate almalıdır. Lisans koşulları bu iki senaryoda farklı yükümlülükler doğurabilir. Model kartında ticari kullanıma izin ifadesi bulunması yine de bütün koşulların sağlandığı anlamına gelmez. Acceptable use ve attribution gereksinimleri ayrıca incelenmelidir. Hukuk onayı model production promotion sürecinin zorunlu kontrolü haline getirilebilir.

Redistribution

Model ağırlıklarının yalnızca şirket sunucusunda tutulması ile müşteriye veya başka kuruma dağıtılması farklı hukuki senaryolardır. Redistribution planlanıyorsa lisansın ilgili şartları ayrıca değerlendirilmelidir. Container image içine model ağırlığı gömmek de dağıtım modeli açısından önem taşıyabilir. Internal artifact repository erişimi yalnızca çalışanlarla sınırlı olabilir. Model package paylaşımı yapılmadan önce lisans metadata'sı kontrol edilmelidir.

Fine-Tuning

Fine-tuning model lisansındaki türetilmiş model koşullarını gündeme getirir. Eğitilen adapter veya yeni ağırlıkların nasıl kullanılabileceği lisans bazında değerlendirilmelidir. Training dataset'in şirket verisi veya kişisel veri içermesi ayrıca veri koruma konusu oluşturur. Fine-tuned model de approved registry ve security review sürecinden geçmelidir. Base model version ve training dataset referansı provenance kaydında tutulabilir.

Hukuk Ekibinin Kontrol Etmesi Gereken Maddeler

Hukuk ekibi commercial use, redistribution, attribution, acceptable use, derivative model ve marka kullanım koşullarını gözden geçirmelidir. Modelin hangi ülkelerde ve hangi müşteri segmentlerinde kullanılacağı da önemli olabilir. Lisans metninin model sürümüyle birlikte arşivlenmesi sonradan değişiklik takibini kolaylaştırır. “Açık model” ifadesi otomatik olarak sınırsız kullanım hakkı anlamına gelmez. Teknik ekip production'a yalnızca hukuk ve güvenlik açısından onaylanan artifact'i almalıdır.

Şirket İçin Doğru Model Boyutu Nasıl Seçilir?

Doğru model boyutu kalite hedefi ile donanım maliyetinin kesiştiği noktada bulunur. 1B ile 4B arası modeller basit görevlerde şaşırtıcı derecede kullanışlı olabilirken 70B ve üzeri modeller ciddi GPU yatırımı gerektirir. Parametre sayısı tek başına kaliteyi göstermediği gibi MoE modellerde toplam ve aktif parametre kavramları da farklıdır. Aynı prompt seti birden fazla boyutta test edilmelidir. En küçük kabul edilebilir model çoğu production sistemi için maliyet açısından en iyi başlangıç noktasıdır.

1B–4B Modeller

1B ile 4B sınıfı modeller düşük latency ve düşük memory ihtiyacı nedeniyle sınıflandırma, bilgi çıkarma ve kısa metin dönüşümlerinde değerlendirilebilir. Karmaşık reasoning veya uzun kurumsal doküman sorularında kalite sınırlı olabilir. Bu modeller router veya pre-processing katmanı olarak da kullanılabilir. Çok sayıda kullanıcı aynı GPU üzerinde daha rahat servis edilebilir. Task-specific benchmark yeterli sonuç veriyorsa büyük modele geçmek gereksiz maliyet oluşturur.

7B–9B Modeller

7B ile 9B sınıfı modeller birçok genel chat ve kurumsal yardımcı kullanımında iyi denge sunabilir. Quantization ile orta seviye GPU'larda çalıştırılmaları daha kolaydır. Türkçe özetleme, içerik dönüştürme ve basit RAG senaryoları bu boyutta test edilebilir. Uzun context ve yüksek concurrency yine VRAM'i artırır. Model seçimi yalnızca tek prompt kalite testine göre yapılmamalıdır.

14B–35B Modeller

14B ile 35B modeller daha güçlü reasoning ve instruction following sunabilir ancak bellek maliyeti belirgin biçimde yükselir. 24 GB veya daha yüksek VRAM'li GPU sınıfları quantization seviyesine göre gündeme gelebilir. İki model aynı anda bellekte tutulacaksa toplam VRAM ihtiyacı ayrıca hesaplanmalıdır. Multi-user deployment'ta KV cache ve parallel request önemli hale gelir. Bu sınıf birçok kurum için ciddi production benchmark gerektiren noktadır.

70B+ Modeller

70B ve üzeri modeller tek GPU'da uygulanabilirlik sınırını hızlı biçimde aşabilir. Güçlü quantization bazı durumlarda yardımcı olsa da context ve concurrency için ek headroom gerekir. Multi-GPU veya yüksek memory accelerator altyapısı gerekebilir. Büyük modelin bütün çalışanlara varsayılan sunulması GPU maliyetini hızla artırır. Yalnızca zorlu görevleri routing ile bu modele yönlendirmek daha ekonomik olabilir.

Model Boyutu ile Kalite Arasındaki İlişki

Daha büyük model çoğu genel benchmark'ta daha güçlü sonuç verme eğiliminde olabilir, ancak iş görevinde doğrusal kalite artışı garanti değildir. Küçük model belirli sınıflandırma veya extraction görevini zaten yüzde 98 doğrulukla çözüyorsa daha büyük model ekonomik değer üretmeyebilir. Büyük model latency'yi artırıp concurrency'yi düşürebilir. Bu nedenle quality per cost metriği düşünmek yararlıdır. Model size kararı iş sonucuyla ilişkilendirilmelidir.

Büyük Model Her Zaman Daha İyi midir?

Hayır, büyük model her kullanım için daha iyi değildir. Kullanıcının kısa e-posta özetlemesi için çok büyük MoE modeli çalıştırmak GPU kaynaklarını gereksiz tüketebilir. Büyük model cold start ve queue süresini de artırabilir. Küçük model belirli görevde daha tutarlı structured output üretebilir. Production mimarisinde birden fazla modelin görev bazlı routing ile kullanılması bu nedenle güçlü bir yaklaşımdır.

Quantization Nedir?

Quantization model ağırlıklarının daha düşük hassasiyetli sayısal biçimlerde temsil edilerek bellek ve disk ihtiyacının azaltılmasıdır. Yerel LLM çalıştırmada Q4, Q5, Q6 veya Q8 gibi seçenekler sık görülür. Daha düşük bit kullanımı aynı GPU'da daha büyük model çalıştırmayı mümkün kılabilir. Bunun karşılığında belirli görevlerde kalite kaybı oluşabilir. Kurumsal seçim yalnızca dosya boyutuna göre değil gerçek benchmark başarısı ve throughput ölçümüne göre yapılmalıdır.

FP16 / BF16

FP16 ve BF16 model ağırlıklarını yüksek hassasiyetle tutan formatlardır ve quantized seçeneklere göre daha fazla bellek gerektirir. Büyük modellerde VRAM ihtiyacı çok hızlı artabilir. Eğitim veya belirli yüksek doğruluk senaryolarında avantaj sağlayabilir. Inference için çoğu şirket daha düşük bit quantization'ı maliyet nedeniyle değerlendirecektir. Kalite farkı gerçek görev dataset'i üzerinde ölçülmelidir.

Q8

Q8 daha yüksek quantization hassasiyeti sunarken Q4 veya Q5'e göre daha büyük model dosyası ve memory gerektirir. Kaliteyi mümkün olduğunca korumak isteyen ancak FP16 maliyetini istemeyen ekipler için seçenek olabilir. Aynı GPU üzerinde concurrency düşebilir. Model loading süresi de daha büyük artifact nedeniyle uzayabilir. Q8'in gerçek faydası task benchmark ile doğrulanmalıdır.

Q6

Q6 bellek kullanımı ile kalite arasında orta-yüksek bir denge sunabilir. Büyük modellerde Q8'e göre anlamlı memory tasarrufu sağlayabilir. Küçük kalite farkının iş sonucuna etkisi görevden göreve değişir. Özellikle structured output veya hassas extraction görevlerinde quantization karşılaştırması yapılmalıdır. Production için kullanılan exact quantization version pinlenmelidir.

Q5

Q5 birçok yerel inference senaryosunda kalite ve bellek arasında dengeli seçeneklerden biridir. Model boyutunu Q8'e göre azaltırken bazı görevlerde Q4'e göre daha iyi kalite koruyabilir. Ancak bu genelleme her model ve task için aynı değildir. Aynı benchmark seti Q4, Q5 ve Q8 ile çalıştırılabilir. Kazanılan kalite GPU kapasitesi kaybına değiyorsa Q5 seçilebilir.

Q4

Q4 yerel LLM kullanımında düşük bellek ihtiyacı nedeniyle oldukça yaygındır. Büyük modelin tek GPU veya daha az GPU ile çalışmasını mümkün kılabilir. Buna karşılık bazı zor reasoning veya çok dilli görevlerde kalite düşüşü görülebilir. Kurumsal kullanımda özellikle Türkçe terminoloji ve structured output testi yapılmalıdır. Q4 sonucu kabul kriterlerini karşılıyorsa toplam donanım maliyeti önemli ölçüde düşebilir.

Quantization'ın RAM ve VRAM'e Etkisi

Daha düşük bit quantization model weight belleğini azaltır. Ancak toplam runtime belleği yalnızca model ağırlığından oluşmaz. KV cache, context, parallel requests ve runtime overhead ayrıca VRAM tüketir. Model dosyası GPU'ya sığıyor diye production kapasitesi yeterli kabul edilmemelidir. Load test altında peak VRAM ölçümü yapılmalıdır.

Quantization'ın Kaliteye Etkisi

Quantization kaliteyi görev türüne bağlı olarak farklı etkileyebilir. Basit özetleme çok az değişirken hassas reasoning veya kod üretiminde fark daha belirgin olabilir. Ortalama benchmark puanı şirketin kritik görevini temsil etmeyebilir. Model çıktıları kör insan değerlendirmesine de sokulabilir. En düşük maliyetli ve kabul kriterini geçen quantization seçilmelidir.

Kurumsal Benchmark ile Doğru Quantization Seçimi

Kurumsal benchmark aynı modelin farklı quantization sürümlerini aynı dataset üzerinde karşılaştırmalıdır. Accuracy, hallucination, JSON validity, latency ve token throughput birlikte ölçülmelidir. GPU memory peak değeri ayrıca kaydedilmelidir. Sonuçlar yalnızca teknik ekip değil gerçek iş kullanıcıları tarafından da değerlendirilebilir. Bu süreç model deployment kararını kişisel tercihten ölçülebilir standarda taşır.

Ollama İçin Ne Kadar RAM ve VRAM Gerekir?

Ollama Llama ve Qwen için GPU RAM performans ve güvenlik gereksinimleri belirlenirken tek bir sabit sayı kullanmak doğru değildir. Model boyutu, quantization, context length, eşzamanlı request ve aynı anda bellekte tutulan model sayısı toplam ihtiyacı belirler. Diskte 6 GB görünen model runtime sırasında yalnızca 6 GB kaynak tüketecek diye varsayılmamalıdır. GPU için headroom bırakmak out-of-memory riskini azaltır. Production kapasitesi gerçek load test ve monitoring verileriyle hesaplanmalıdır.

Model Dosya Boyutu ile VRAM Aynı Şey midir?

Hayır, model dosya boyutu ve runtime VRAM aynı kavram değildir. Model ağırlıkları VRAM'in önemli kısmını oluştursa da KV cache ve runtime buffer gibi ek kullanım bulunur. Uzun context daha fazla KV cache gerektirir. Parallel request sayısı arttıkça toplam bellek ihtiyacı büyür. Bu nedenle model sayfasındaki GB değeri yalnızca ilk kapasite tahmininde kullanılmalıdır.

Model Weight Belleği

Model weight belleği inference sırasında ağırlıkların saklandığı temel bellek alanıdır. Quantization bu alanı ciddi biçimde azaltabilir. Model tamamen GPU'ya sığmıyorsa bazı runtime'lar CPU offload kullanabilir ancak performans düşebilir. Büyük model için çoklu GPU dağıtımı gerekebilir. Weight boyutu kapasite hesabının başlangıcıdır, sonu değildir.

KV Cache

KV cache modelin önceki token'lara ilişkin attention bilgisini saklayarak generation performansını destekler. Context uzadıkça cache boyutu artar. Eşzamanlı kullanıcı sayısı da toplam KV cache tüketimini artırabilir. Bu nedenle 128K veya 256K context destekleyen modelin maksimum context'ini varsayılan kullanmak çoğu şirket için gereksiz olabilir. Gerçek prompt dağılımına uygun limit seçilmelidir.

Context Window

Context window modelin tek istekte işleyebileceği token miktarını belirler. Büyük context uzun doküman ve uzun konuşmalar için faydalı olabilir. Ancak daha geniş context GPU memory ve hesaplama süresini artırır. RAG kullanıyorsanız bütün dokümanı prompt'a koymak yerine ilgili chunk'ları seçmek daha verimli olur. Kullanıcı başına context limiti platform policy ile sınırlandırılabilir.

Parallel Requests

Parallel request sayısı aynı anda birden fazla kullanıcının generation yapabilmesini sağlar. Bu değer arttıkça throughput yükselirken VRAM ve latency davranışı değişebilir. GPU kapasitesini aşan concurrency queue veya out-of-memory sorununa yol açabilir. Load test kademeli kullanıcı artışıyla yapılmalıdır. P95 latency hedefi bozulduğu noktada güvenli kapasite sınırı belirlenebilir.

GPU Headroom

GPU'nun yüzde yüz VRAM kullanımına göre planlanması production ortamında risklidir. Farklı context uzunlukları veya ani concurrency artışı peak memory oluşturabilir. Belirli miktarda headroom bırakmak out-of-memory hatalarını azaltır. Monitoring peak VRAM değerini takip etmelidir. Yeni model sürümü production'a alınırken bellek profili yeniden ölçülmelidir.

İşletim Sistemi ve Diğer Servisler İçin Bellek

Sistem RAM'i de yalnızca model dosyalarına ayrılmamalıdır. İşletim sistemi, filesystem cache, Nginx, monitoring agent ve container runtime kaynak tüketir. Model load sırasında diskten RAM'e yoğun veri aktarımı olabilir. Swap kullanımı inference latency'yi ciddi biçimde etkileyebilir. Sunucu RAM kapasitesi GPU VRAM hesabından ayrı planlanmalıdır.

Context Length Sunucu Kapasitesini Nasıl Etkiler?

Context length arttıkça model daha fazla geçmiş bilgi işleyebilir ancak bunun doğrudan memory ve latency maliyeti vardır. Büyük context özellikle RAG sistemlerinde kolayca gereğinden fazla kullanılabilir. Kullanıcıların yüz binlerce token göndermesine izin vermek yerine uygulama ihtiyacına uygun maksimum değer belirlenmelidir. Ollama context ayarları deployment configuration içinde merkezi yönetilebilir. Context ve concurrency aynı GPU kaynağını paylaştığı için biri yükseldiğinde diğerinin kapasitesi etkilenebilir.

OLLAMA_CONTEXT_LENGTH

OLLAMA_CONTEXT_LENGTH sunucu tarafında context boyutunu yapılandırmak için kullanılabilir. Değer seçilirken modelin desteklediği teorik maksimum yerine gerçek iş ihtiyacı dikkate alınmalıdır. Çoğu chat ve RAG görevi maksimum context'e ihtiyaç duymaz. Daha küçük değer bellek kullanımını ve latency'yi iyileştirebilir. Değişiklik sonrası benchmark ve peak VRAM ölçümü tekrar yapılmalıdır.

Uzun Context'in Avantajları

Uzun context büyük dokümanları, uzun konuşma geçmişini veya birden fazla kaynak parçasını aynı prompt içinde tutmayı kolaylaştırır. Kullanıcı deneyiminde geçmiş mesajları hatırlama oranı artabilir. Kod analizi sırasında daha fazla dosya bağlamı verilebilir. Ancak bütün bağlamın gerçekten gerekli olup olmadığı sorgulanmalıdır. Retrieval veya summarization ile context daha kontrollü küçültülebilir.

Uzun Context'in VRAM Maliyeti

Context büyüdükçe KV cache için daha fazla bellek gerekir. Bu durum aynı GPU üzerinde desteklenebilecek parallel request sayısını düşürebilir. Tek kullanıcılı benchmark sorunsuzken 20 kullanıcı altında out-of-memory görülebilir. Context limitleri kullanıcı veya model bazında farklı tanımlanabilir. Gerçek memory eğrisi load test ile ölçülmelidir.

RAG Kullanırken Gereksiz Uzun Context'ten Kaçınmak

RAG sisteminin amacı bütün bilgi tabanını modele göndermek değil ilgili parçaları seçmektir. Retrieval kalitesi iyiyse daha küçük context ile daha iyi ve hızlı yanıt alınabilir. Çok fazla chunk modele verildiğinde alakasız bilgi hallucination veya dikkat dağılması oluşturabilir. Reranking ve metadata filtreleme context'i daraltabilir. Bu yaklaşım GPU maliyetini de azaltır.

Context ve Eşzamanlı Kullanıcı Dengesi

Context limiti ile concurrent user kapasitesi arasında doğrudan operasyonel ilişki vardır. Kullanıcı başına çok büyük context ayrılırsa aynı GPU daha az paralel session taşıyabilir. Bu nedenle hizmet seviyesi tanımlanırken maksimum context ve concurrency birlikte belirlenmelidir. Bazı departmanlara uzun doküman modeli, diğerlerine daha küçük context'li hızlı model sunulabilir. Gateway routing bu ayrımı yönetebilir.

Çok Kullanıcılı Ollama Sunucusu Nasıl Ayarlanır?

Çok kullanıcılı sunucuda amaç yalnızca aynı endpoint'i herkese açmak değil kaynak tüketimini öngörülebilir hale getirmektir. Parallel request, loaded model sayısı, queue boyutu ve keep alive ayarları birlikte değerlendirilmelidir. Her modelin VRAM profili farklıdır. Aynı anda Llama ve Qwen bellekte tutuluyorsa model weight tüketimi hızlı biçimde artabilir. Configuration değişiklikleri gerçek concurrency testiyle doğrulanmalıdır.

OLLAMA_NUM_PARALLEL

OLLAMA_NUM_PARALLEL aynı model üzerinde paralel request davranışını etkileyen önemli kapasite ayarlarından biridir. Daha yüksek değer throughput'u artırabilir ancak GPU memory ihtiyacını da yükseltebilir. Çok düşük değer kullanıcıların kuyrukta gereksiz beklemesine neden olabilir. En iyi değer GPU ve model kombinasyonuna göre değişir. Load test sırasında TTFT ve peak VRAM birlikte izlenmelidir.

OLLAMA_MAX_LOADED_MODELS

OLLAMA_MAX_LOADED_MODELS aynı anda bellekte tutulabilecek model sayısını kontrol etmeye yardımcı olur. Çok sayıda model sürekli yüklü tutulursa VRAM hızla dolar. Kullanım düşük modeller unload edilerek popüler model için daha fazla alan bırakılabilir. Routing ve keep alive policy birlikte tasarlanmalıdır. Model kullanım sıklığı monitoring verisinden çıkarılabilir.

OLLAMA_MAX_QUEUE

Queue kapasitesi anlık talep GPU'nun işleme kapasitesini aştığında önemli hale gelir. Çok küçük queue gereksiz hata üretirken çok büyük queue kullanıcıların dakikalarca beklemesine neden olabilir. Beklenen maksimum kullanıcı latency'si belirlenmelidir. Queue dolduğunda istemciye retry-after benzeri yönlendirme yapılabilir. Queue wait time ayrı metrik olarak izlenmelidir.

OLLAMA_KEEP_ALIVE

Keep alive modeli request sonrasında belirli süre bellekte tutarak cold start maliyetini azaltabilir. Popüler model uzun süre sıcak tutulabilir. Nadiren kullanılan büyük model ise kısa sürede unload edilerek VRAM boşaltabilir. Aynı sunucuda birden fazla model olduğunda bu politika özellikle önemlidir. Çalışma saatleri ve kullanım sıklığına göre farklı lifecycle yaklaşımı uygulanabilir.

Concurrent Request ve VRAM İlişkisi

Concurrent request arttığında her aktif context için ek memory ihtiyacı doğabilir. Modelin tek request ile VRAM'e sığması production kapasitesini kanıtlamaz. 5, 10, 20 ve daha fazla eşzamanlı kullanıcıyla kademeli test yapılmalıdır. Peak memory ve P95 latency eş zamanlı izlenmelidir. Güvenli kapasite out-of-memory sınırından daha düşük bir noktada belirlenmelidir.

Queue Bekleme Süresi

Queue wait kullanıcı deneyiminin önemli ama sık gözden kaçan metriğidir. Model tokens per second değeri iyi olsa bile kullanıcı request'i başlamadan uzun süre bekleyebilir. TTFT metriği queue ve inference gecikmesini birlikte yansıtabilir. Gateway request acceptance zamanı ile backend generation başlangıcı ayrı kaydedilirse kaynak daha kolay bulunur. Yüksek queue süresi scale-out veya daha küçük modele routing ihtiyacını gösterebilir.

Aynı Sunucuda Llama ve Qwen Birlikte Çalıştırılabilir mi?

Evet, aynı Ollama sunucusunda Llama ve Qwen modelleri birlikte bulunabilir ve kullanılabilir. Ancak iki modelin aynı anda GPU belleğinde tutulması toplam VRAM ihtiyacını artırır. Kullanım yoğunluğuna göre modeller load ve unload edilebilir. Gateway hangi görevin hangi modele gideceğini belirleyebilir. Donanım yetersizse modelleri ayrı GPU sunucu havuzlarına bölmek daha iyi latency sağlar.

Birden Fazla Modelin Bellekte Tutulması

Birden fazla modelin bellekte tutulması model değişimindeki cold start süresini azaltır. Bunun karşılığında her model weight belleği VRAM'den alan tüketir. Aynı GPU üzerinde büyük Llama ve orta Qwen modelini sürekli tutmak concurrency alanını azaltabilir. Kullanım sıklığına göre yalnızca popüler iki model sıcak tutulabilir. Monitoring hangi modelin ne kadar çağrıldığını göstermelidir.

Model Load / Unload

Model load diskten veya RAM'den GPU belleğine ağırlıkların taşınmasını içerir ve büyük modellerde saniyeler veya daha uzun süre alabilir. Unload VRAM'i başka model için serbest bırakır. Çok sık model değişimi kullanıcı latency'sini yükseltebilir. Routing benzer görevleri aynı modele gruplayarak thrashing etkisini azaltabilir. Büyük model için ayrı instance kullanmak bazı sistemlerde daha verimli olur.

VRAM Competition

Llama ve Qwen aynı GPU üzerinde çalışırken model weight, KV cache ve runtime buffer için aynı VRAM'i paylaşır. İki model ayrı ayrı sığıyor diye aynı anda sorunsuz çalışacakları garanti değildir. Parallel request bu competition'ı daha da artırır. OOM yaşanırsa model sayısı, context veya concurrency azaltılabilir. Daha büyük GPU veya ayrı GPU havuzu uzun vadeli çözüm olabilir.

Keep Alive Politikası

Keep alive modeli kullanım sonrası bellekte ne kadar tutacağınızı belirlemek için kullanılabilir. Gün boyu yoğun kullanılan varsayılan model uzun süre sıcak tutulabilir. Ayda birkaç kez kullanılan büyük reasoning modeli daha kısa süre sonra unload edilebilir. Bu politika model usage telemetry'ye göre ayarlanmalıdır. Amaç cold start ve VRAM kullanımını dengede tutmaktır.

Llama ve Qwen Arasında Routing

Gateway prompt tipine, kullanıcı grubuna veya açık model seçimine göre Llama ve Qwen arasında routing yapabilir. Basit sistemde kullanıcı model seçer. Daha gelişmiş sistem intent classifier ile kod sorularını coder modeline, Türkçe raporları belirli Qwen modeline yönlendirebilir. Routing kararı loglanmalıdır. Yanlış routing oranı benchmark sürecinde izlenebilir.

Göreve Göre Model Seçimi

Her görevin aynı modele gitmesi donanım ve kalite açısından verimsiz olabilir. Sınıflandırma küçük modele, genel chat orta modele, zor reasoning büyük modele yönlendirilebilir. Kod görevleri coder varyantına gidebilir. Bu model cascade toplam GPU maliyetini azaltabilir. Routing policy'nin kullanıcı tarafından anlaşılır ve gerektiğinde override edilebilir olması yararlıdır.

Model Routing ile Llama ve Qwen Birlikte Nasıl Kullanılır?

Model routing kurumsal LLM servisinde kalite ile maliyeti dengeleyen güçlü bir yöntemdir. Kullanıcıya tek endpoint sunulurken backend'de farklı görevler farklı modellere gönderilebilir. Varsayılan küçük veya orta model çoğu isteği karşılar. Daha zor sorgular büyük reasoning modeline escalation edilir. Fallback mekanizması model unavailable olduğunda servis sürekliliğini destekler.

Default Model

Default model kullanıcıların çoğu rutin isteğini düşük latency ile karşılamalıdır. En büyük modelin default seçilmesi GPU maliyetini yükseltebilir. Genel chat, kısa özet ve basit extraction görevlerinde orta boy model yeterli olabilir. Kullanıcı memnuniyeti ve başarısız escalation oranı izlenmelidir. Gerekirse departman bazında farklı default model tanımlanabilir.

Kodlama Modeli

Kod soruları özel coder modeline yönlendirilebilir. Gateway prompt metadata veya uygulama context'inden görevi anlayabilir. IDE entegrasyonu doğrudan coder route kullanabilir. Kodlama modeline repository context gönderildiği için source code access policy uygulanmalıdır. Üretilen kod normal security review ve test sürecinden geçmelidir.

Türkçe Model

Türkçe görevlerde şirket benchmark'ında en iyi sonucu veren model ayrı route olarak seçilebilir. Dil tespiti otomatik yapılabilir veya kullanıcı model tercihinde bulunabilir. Türkçe modelin kurumsal terminoloji ve resmi yazışma biçimi test edilmelidir. Sadece genel çok dilli benchmark sonucu yeterli değildir. Latency ve hallucination oranı birlikte değerlendirilmelidir.

Reasoning Modeli

Zor analiz ve çok adımlı problem çözme görevleri daha güçlü reasoning modeline yönlendirilebilir. Bu model daha pahalı ve yavaş olabileceği için her sorguda kullanılmamalıdır. Kullanıcı “derin analiz” seçeneğiyle route'u açıkça tetikleyebilir. Otomatik classifier da belirli prompt türlerini escalation edebilir. Maliyet ve latency dashboard'da ayrı izlenmelidir.

Küçük Modelden Büyük Modele Escalation

Küçük model önce soruyu çözmeye çalışır ve güven düşükse büyük modele aktarım yapılabilir. Güven ölçümü structured validation, retrieval score veya task-specific classifier üzerinden yapılabilir. Modelin kendi “eminim” ifadesini tek başına güven sinyali olarak kullanmak doğru değildir. Escalation oranı fazla ise default model yetersiz olabilir. Bu oran kapasite ve kalite kararında önemli metriktir.

Fallback Model

Fallback model ana model unavailable veya overload olduğunda servis sürekliliği sağlar. Aynı görevde benzer output format üretebilmesi önemlidir. Gateway health check backend durumunu izleyebilir. Fallback'e geçildiğinde kullanıcıya kalite farkı varsa açık bilgi verilebilir. Model version değişimi audit log'a eklenmelidir.

Model Cold Start Nasıl Önlenir?

Cold start modelin bellekte olmadığı durumda ilk isteğin ağırlıkları yüklemesini beklemesidir. Küçük modelde birkaç saniye kabul edilebilirken büyük modelde kullanıcı deneyimini ciddi biçimde etkileyebilir. Preloading, keep alive ve warm-up request bu gecikmeyi azaltabilir. Buna karşılık bütün modelleri sürekli bellekte tutmak VRAM tüketimini artırır. Model lifecycle kullanım saatleri ve talep sıklığına göre tasarlanmalıdır.

Model Preloading

Preloading yoğun kullanılan modeli kullanıcı trafiği başlamadan belleğe alır. Sunucu restart sonrasında otomatik warm-up job çalıştırılabilir. Sabah çalışma saatinden önce model hazır hale getirilebilir. Health check yalnızca API portunun açık olmasını değil modelin inference yapabildiğini doğrulayabilir. Büyük model load süresi monitoring metriği olarak kaydedilmelidir.

OLLAMA_KEEP_ALIVE

OLLAMA_KEEP_ALIVE modelin istek sonrasında bellekte tutulma davranışını yönetmek için kullanılabilir. Popüler modeller için daha uzun süre seçmek cold start sayısını azaltır. VRAM sınırlıysa nadir kullanılan modeller kısa sürede çıkarılabilir. Değer tek başına değil max loaded models ve concurrency ayarlarıyla birlikte düşünülmelidir. Production değişikliği önce load test ortamında denenmelidir.

Warm-Up Request

Warm-up request modelin ilk gerçek kullanıcı isteğinden önce yüklenmesini sağlar. Kısa ve düşük tokenlı test prompt'u kullanılabilir. Response içeriğinden çok modelin hazır olması önemlidir. Deployment sonrası readiness check bu işlemi tetikleyebilir. Warm-up başarısızsa load balancer instance'ı trafiğe açmamalıdır.

Çalışma Saatlerine Göre Model Lifecycle

Kurumun kullanım yoğunluğu belirli saatlerde artıyorsa modeller bu takvime göre preload edilebilir. Gece çok az kullanılan büyük model unload edilerek kaynak başka batch işlerine bırakılabilir. Hafta sonu farklı policy uygulanabilir. Monitoring gerçek kullanım dağılımını göstererek lifecycle ayarını yönlendirebilir. Statik tahmin yerine birkaç haftalık telemetry ile karar verilmelidir.

VRAM ile Cold Start Arasındaki Trade-Off

Model bellekte kaldığında cold start azalır ancak VRAM başka modeller için kullanılamaz. Çok model sunan sistemlerde bu trade-off belirginleşir. En çok kullanılan modeller sıcak, diğerleri talep üzerine yüklenebilir. Ayrı GPU pool kullanmak kritik modeller için bu sorunu azaltabilir. Kullanıcı latency hedefi ile donanım maliyeti birlikte değerlendirilmelidir.

Ollama Performansı Nasıl Ölçülür?

Ollama performansını yalnızca tokens per second ile ölçmek kullanıcı deneyimini eksik gösterir. Time to first token, end-to-end latency, queue wait ve error rate birlikte izlenmelidir. P50 normal kullanıcı deneyimini, P95 ve P99 yoğun veya zor durumları anlamaya yardımcı olur. Concurrent users arttıkça metriklerin nasıl değiştiği load test ile görülmelidir. Model, quantization ve context configuration her benchmark kaydında belirtilmelidir.

Time to First Token

TTFT kullanıcının isteği göndermesi ile ilk yanıt token'ını görmesi arasındaki süreyi ölçer. Queue, model load ve prompt processing bu değeri etkileyebilir. Streaming chat deneyiminde TTFT kullanıcı algısı açısından çok önemlidir. Ortalama yerine P95 değer de izlenmelidir. Model cold start olduğunda TTFT'nin nasıl değiştiği ayrı kaydedilebilir.

Tokens per Second

Tokens per second generation hızını ölçer ve GPU performansı hakkında önemli fikir verir. Fakat kullanıcı request'i kuyrukta bekliyorsa yüksek token hızı tek başına iyi deneyim anlamına gelmez. Farklı model ve quantization'lar aynı prompt setiyle karşılaştırılmalıdır. Concurrency arttıkça kişi başına throughput düşebilir. Sistem toplam throughput ile kullanıcı başına throughput'u ayrı göstermelidir.

End-to-End Latency

End-to-end latency gateway request başlangıcından response tamamlanmasına kadar geçen toplam süredir. Authentication, queue, inference ve network gecikmesini birlikte kapsar. Aynı model için kısa ve uzun output görevleri ayrı kategoriye ayrılmalıdır. P95 latency hizmet seviyesi hedefi için kullanılabilir. Kullanıcıların timeout yaşadığı eşik özellikle izlenmelidir.

P50

P50 isteklerin yarısının bu değerin altında tamamlandığını gösterir. Günlük normal kullanıcı deneyimini anlamak için yararlıdır. Tek başına iyi P50 yoğun saatlerde yaşanan kötü deneyimi saklayabilir. Bu nedenle P95 ve P99 ile birlikte raporlanmalıdır. Model ve departman bazında farklı P50 değerleri kapasite sorununu gösterebilir.

P95

P95 isteklerin yüzde 95'inin altında kaldığı latency seviyesini gösterir. Production hizmet seviyesi için ortalamadan daha anlamlı olabilir. Queue birikmesi P95'te hızlı biçimde görünür. Model loading ve büyük context istekleri tail latency'yi yükseltebilir. Kapasite artışı kararı P95 trendiyle desteklenebilir.

P99

P99 en kötü kullanıcı deneyimlerinin önemli bölümünü gösterir. Çok yüksek P99 nadir fakat ciddi queue veya cold start sorununa işaret edebilir. Average latency iyi görünürken P99 dakikalara çıkıyorsa sistem kararlı değildir. Request trace ile yavaş isteklerin model, context ve kullanıcı tipi incelenebilir. Outlier'ların gerçek kullanım mı yoksa hatalı istemci mi olduğu ayrıştırılmalıdır.

Queue Wait Time

Queue wait inference başlamadan önce request'in beklediği süredir. GPU tamamen dolu olduğunda bu değer hızla artar. Kullanıcı generation başladıktan sonra hızlı token alsa bile uzun queue deneyimi olumsuzdur. Scale-out ve model routing kararında doğrudan kullanılabilir. Queue wait belirli eşik üzerinde ise gateway isteği daha küçük modele yönlendirebilir.

Concurrent Users

Concurrent users aynı anda aktif generation yapan kullanıcı sayısını ifade eder. Toplam kayıtlı kullanıcı sayısından farklıdır. 100 çalışanınız olması 100 eşzamanlı request anlamına gelmez. Gerçek concurrency dağılımı pilot kullanımda ölçülmelidir. GPU kapasitesi bu veri üzerinden planlandığında gereksiz fazla veya yetersiz donanım riski azalır.

Error Rate

Error rate timeout, out-of-memory, gateway rejection ve model runtime hatalarını içerebilir. Hata türleri tek yüzde altında toplanmamalıdır. 429 benzeri quota hatası ile 500 inference hatası farklı aksiyon gerektirir. Model update sonrası error rate artışı deployment rollback sinyali olabilir. P95 latency ile birlikte izlemek kapasite sorunlarını erken gösterir.

Türkçe Llama ve Qwen Benchmark'ı Nasıl Yapılır?

Türkçe benchmark şirketin kendi gerçek iş dilini temsil etmelidir. Genel benchmark setleri model karşılaştırması için yararlıdır ancak kurum içi e-posta, teknik destek ve rapor dilini tam yansıtmaz. Gerçek prompt'lar hassas bilgiler temizlendikten sonra test dataset'ine dönüştürülebilir. Model çıktıları kalite, hallucination, instruction following, structured output ve latency açısından ölçülebilir. Aynı test setinin her model sürümünde tekrar çalıştırılması regression değerlendirmesi sağlar.

Genel Benchmark Sonuçları Neden Yeterli Değildir?

Genel benchmark modellerin ortak akademik veya standart görevlerde karşılaştırılmasını sağlar. Ancak sizin şirketinizdeki ürün isimleri, teknik jargon ve yazışma biçimi farklıdır. Model benchmark'ta yüksek puan alıp gerçek destek kayıtlarını kötü sınıflandırabilir. Türkçe ek yapısı ve yerel ifadeler de değerlendirme farkı oluşturabilir. Production kararı şirket dataset'inde doğrulanmalıdır.

Şirketin Gerçek Prompt'larından Test Seti Oluşturmak

Gerçek kullanıcı prompt'ları benchmark için en değerli veri kaynağıdır. Ancak kişisel ve hassas bilgiler anonimleştirilmelidir. Farklı departman ve görevlerden dengeli örnek seçilmelidir. Expected output veya scoring rubric uzman kullanıcılarla hazırlanabilir. Dataset version control altında tutulup model upgrade testlerinde yeniden kullanılabilir.

Türkçe Dil Kalitesi

Türkçe dil kalitesi yalnızca gramer hatası sayısıyla ölçülmemelidir. Cümle doğallığı, hitap biçimi, ek kullanımı ve kurumsal ton birlikte değerlendirilmelidir. İnsan değerlendiriciler blind test ile model adını görmeden puan verebilir. Çok uzun yanıt üretme eğilimi de kullanıcı deneyimini etkileyebilir. Aynı görev için kalite ve latency birlikte raporlanmalıdır.

Kurumsal Terminoloji

Şirket ürünleri, departman isimleri ve teknik kısaltmalar genel model eğitiminde bulunmayabilir. RAG veya system prompt bu terminolojiyi modele sağlayabilir. Benchmark özel terimlerin doğru kullanılıp kullanılmadığını ölçmelidir. Yanlış ürün adı üretmek hallucination olarak işaretlenebilir. Terminoloji sözlüğü retrieval veya prompt template'in parçası yapılabilir.

Hallucination

Hallucination modelin kaynakta olmayan bilgi üretmesi veya emin olmadığı halde yanlış cevap vermesidir. RAG testlerinde cevap içindeki iddialar retrieved dokümanla karşılaştırılabilir. “Bilmiyorum” demesi gereken sorular dataset'e bilinçli olarak eklenmelidir. Modelin yanlış özgüveni önemli risk sinyalidir. Kritik iş süreçlerinde insan onayı veya kaynak gösterme zorunluluğu uygulanabilir.

Instruction Following

Instruction following modelin verilen format, uzunluk ve görev sınırlarına uyup uymadığını ölçer. “Yalnızca JSON döndür” veya “üç maddede özetle” gibi testler uygulanabilir. Kurumsal otomasyon için format uyumu özellikle önemlidir. Aynı model farklı quantization'da farklı başarı gösterebilir. Uyum oranı yüzde olarak dashboard'da izlenebilir.

Structured Output

Structured output benchmark'ında JSON schema veya beklenen alan yapısı validator ile otomatik kontrol edilebilir. Geçersiz JSON doğrudan başarısız kabul edilebilir. Field value doğruluğu ayrıca değerlendirilebilir. Model bazında valid schema rate ölçülmelidir. Uygulama production'da yine response validation yapmalıdır.

Latency

Benchmark yalnızca kalite testi olmamalıdır çünkü kullanıcı düşük latency bekler. Her prompt için TTFT ve end-to-end latency kaydedilebilir. Aynı model cold ve warm durumda ayrı ölçülmelidir. Concurrency load test kalite benchmark'ından ayrı çalıştırılabilir. Sonuçlar quality-latency matrisi halinde değerlendirilebilir.

Kaynak Kullanımı

GPU utilization, VRAM peak, power consumption ve model load time benchmark'a eklenebilir. İki model benzer kalite veriyorsa daha düşük kaynak tüketen seçenek production için avantajlı olabilir. Quantization farkı burada belirginleşir. Kullanıcı başına efektif GPU zamanı maliyet hesabında kullanılabilir. Donanım kapasitesi gerçek performans verisiyle eşleştirilmelidir.

Şirket İçi Kullanım İçin Örnek Model Benchmark Senaryoları

Benchmark senaryoları doğrudan çalışanların yapacağı gerçek işlerden seçilmelidir. E-posta özetleme, doküman soru cevap, teknik destek, kod analizi ve rapor üretme farklı model yeteneklerini ölçer. Her görev için açık scoring rubric hazırlanmalıdır. Aynı prompt farklı modellerde tekrarlanmalı ve çıktı kimliği gizlenerek değerlendirilebilir. Böylece model seçimi kişisel marka tercihinden çıkar ve ölçülebilir kurumsal karara dönüşür.

E-posta Özetleme

E-posta özetleme testinde uzun thread içinden karar, sorumlu ve son tarih çıkarılması istenebilir. Model gereksiz ayrıntıları azaltırken kritik bilgiyi kaybetmemelidir. Türkçe ve İngilizce karışık yazışmalar ayrıca test edilebilir. Hassas e-posta verisi benchmark dataset'ine alınmadan anonimleştirilmelidir. Sonuç doğruluk ve sıkıştırma oranıyla değerlendirilebilir.

Doküman Soru-Cevap

Doküman soru cevap testinde model yalnızca sağlanan kaynaklara dayanmalıdır. Cevabı dokümanda olmayan sorular bilinçli olarak eklenmelidir. Kaynak gösterme doğruluğu ayrıca ölçülebilir. RAG retrieval hatası ile model hallucination'ı ayrı etiketlenmelidir. Kullanıcıların gerçek prosedür dokümanlarına benzeyen anonim örnekler tercih edilmelidir.

Teknik Destek

Teknik destek benchmark'ı ticket sınıflandırma, çözüm önerisi ve escalation kararını içerebilir. Şirketin ürün isimleri ve bilinen hata kodları test setine eklenebilir. Model yanlış veya riskli komut önerirse başarısız sayılmalıdır. Kısa ve uygulanabilir cevap tercih edilebilir. Çözüm doğruluğu gerçek destek uzmanları tarafından puanlanabilir.

Kod Analizi

Kod analizi benchmark'ında bug bulma, refactoring ve test üretimi gibi görevler ayrı değerlendirilmelidir. Şirketin kullandığı dil ve framework'ler dataset'e dahil edilmelidir. Güvenlik açığı bulunan kontrollü örnekler modele verilebilir. Modelin problemi bulması kadar doğru düzeltme önermesi de puanlanmalıdır. Üretilen kod otomatik test ve static analysis'tan geçirilebilir.

Metin Sınıflandırma

Metin sınıflandırma küçük modellerin güçlü olabileceği kullanım alanıdır. Müşteri talebi kategori, öncelik veya departmana göre sınıflandırılabilir. Accuracy, precision ve recall gibi klasik metrikler kullanılabilir. Yanlış sınıflandırmanın iş maliyeti kategori bazında farklı olabilir. Büyük modelin küçük modelden anlamlı üstünlüğü yoksa küçük model production için daha ekonomiktir.

Veri Çıkarma

Veri extraction senaryosunda serbest metinden isim, tarih, ürün kodu veya tutar gibi alanlar çıkarılabilir. JSON schema ile output doğruluğu otomatik ölçülebilir. Eksik alanların null veya belirtilen biçimde dönmesi test edilmelidir. Uydurulan field değeri ciddi hata olarak işaretlenmelidir. Bu görevde küçük ve orta modeller çoğu zaman güçlü aday olabilir.

Türkçe Rapor Oluşturma

Türkçe rapor testinde modelin resmi ve doğal dil kullanması önemlidir. Kaynak metindeki sayıları yanlış değiştirmemesi gerekir. Bölüm yapısı, başlık kullanımı ve terminoloji puanlanabilir. Gereksiz uzunluk kalite düşüşü olarak değerlendirilebilir. İnsan değerlendirmesi otomatik metriklere eklenmelidir.

Model Güncellemeleri Nasıl Yönetilmeli?

Production model güncellemesi package update kadar kontrollü yürütülmelidir. Hareketli tag kullanmak aynı model adının farklı artifact'e işaret etmesine neden olabilir. Digest veya sabit version kullanımı tekrar üretilebilir deployment sağlar. Yeni model önce candidate olarak staging benchmark'ından geçmelidir. Başarısız sonuçta önceki production artifact'e hızlı rollback mümkün olmalıdır.

Model Tag'i Kullanmanın Riski

Latest benzeri tag zaman içinde farklı model artifact'ine işaret edebilir. Aynı deployment komutu bugün ve gelecek ay farklı sonuç üretirse audit ve regression zorlaşır. Production sürümü immutable digest veya açık version ile sabitlenmelidir. Tag yalnızca insan tarafından okunabilir alias olarak kullanılabilir. Actual artifact identity ayrıca kaydedilmelidir.

Digest / Version Pinning

Digest pinning belirli model artifact'inin değişmeden kullanılmasını sağlar. Benchmark edilen model ile production'daki modelin aynı olduğu doğrulanabilir. Rollback eski digest'e dönmek kadar basit hale gelir. Model metadata ve lisans aynı kayıtla ilişkilendirilebilir. Internal registry immutable artifact politikasını desteklemelidir.

Candidate Model

Yeni model production'a doğrudan alınmak yerine candidate statüsünde tutulmalıdır. Security, lisans ve kalite kontrolleri bu aşamada yapılır. Benchmark sonucunun eski production modelle farkı raporlanabilir. Bazı kullanım senaryolarında candidate daha kötü sonuç veriyorsa upgrade ertelenebilir. Yeni modelin daha yeni olması tek başına promotion kriteri değildir.

Staging Evaluation

Staging evaluation gerçek production prompt dataset'i ve benzer GPU configuration ile yapılmalıdır. Latency, memory ve quality birlikte ölçülmelidir. RAG ve tool calling regression testleri ayrıca çalıştırılmalıdır. Model API davranışı veya template değişikliği uygulama entegrasyonunu etkileyebilir. Sonuçlar change request'e eklenebilir.

Production Promotion

Promotion onaylanan exact artifact'in production registry veya server'a taşınmasıdır. Model staging'de test edilen digest ile aynı olmalıdır. Gateway routing önce küçük kullanıcı grubunu yeni modele gönderebilir. Monitoring eski ve yeni model metriklerini karşılaştırabilir. Sorun görülmezse trafik kademeli artırılır.

Rollback

Rollback planı model güncellemesinin zorunlu parçasıdır. Eski artifact belirli süre storage üzerinde tutulmalıdır. Gateway veya deployment configuration önceki model version'a hızlı dönebilecek şekilde tasarlanmalıdır. Conversation state model değişiminde uyumsuzluk yaratabilir ve test edilmelidir. Rollback olayı audit ve change log'a eklenmelidir.

Değişiklik Kaydı

Her model update tarih, eski version, yeni version, digest, benchmark sonucu ve onaylayan kişilerle kaydedilmelidir. Kullanıcıların fark ettiği davranış değişikliği bu kayıtla ilişkilendirilebilir. Lisans değişikliği de change record içinde bulunmalıdır. Performance metrikleri rollout öncesi ve sonrası karşılaştırılabilir. Düzenli kayıt incident investigation süresini ciddi biçimde kısaltır.

Yeni Qwen veya Llama Sürümü Çıktığında Ne Yapılmalı?

Yeni model sürümü çıkar çıkmaz production'a otomatik yüklemek doğru değildir. Önce lisans ve source kontrolü yapılmalıdır. Ardından güvenlik review, regression evaluation ve performance benchmark çalıştırılır. Candidate model küçük canary grubunda gerçek kullanıcı deneyimiyle test edilebilir. Yalnızca açık kalite veya maliyet avantajı varsa production rollout yapılmalıdır.

Otomatik Güncelleme Yapılmalı mı?

Production model ağırlıklarında kontrolsüz otomatik güncelleme önerilmez. Model davranışı, template veya lisans koşulları değişebilir. Otomasyon yeni sürümü tespit edip değerlendirme pipeline'ını başlatabilir. Promotion ise policy ve onay sonucuna bağlı olmalıdır. Böylece güncellik ile değişiklik kontrolü dengelenir.

Lisans Kontrolü

Yeni sürümün önceki modelle aynı lisansa sahip olduğu varsayılmamalıdır. Resmi model sayfası ve lisans dosyası arşivlenmelidir. Commercial use ve redistribution koşulları yeniden kontrol edilmelidir. Hukuk ekibi önemli değişikliklerde bilgilendirilmelidir. Onay sonucu model metadata'sına eklenebilir.

Security Review

Model artifact kaynağı, digest ve supply-chain bilgisi security review sırasında kontrol edilmelidir. Yeni model farklı custom code veya runtime requirement gerektiriyorsa bunlar ayrıca incelenmelidir. Outbound network davranışında değişiklik olup olmadığı test edilebilir. Prompt injection ve tool calling regression'ları çalıştırılmalıdır. Güvenlik sonucu başarısızsa model production'a alınmamalıdır.

Regression Evaluation

Regression evaluation mevcut production modelin iyi yaptığı görevlerin yeni sürümde bozulup bozulmadığını kontrol eder. Aynı benchmark dataset'i tekrar kullanılmalıdır. Türkçe kalite, structured output ve hallucination metriği karşılaştırılmalıdır. Yeni model bazı görevlerde daha iyi, bazı görevlerde daha kötü olabilir. Routing ile yalnızca güçlü olduğu görevlerde kullanmak seçenek olabilir.

Performance Benchmark

Yeni model latency ve memory profilini değiştirebilir. Aynı GPU üzerinde TTFT, tokens per second ve peak VRAM ölçülmelidir. Concurrency testi gerçek production seviyesine yakın yapılmalıdır. Kalite artışı büyük ama throughput yarıya düşüyorsa kapasite maliyeti hesaplanmalıdır. Karar kalite ve toplam operasyon maliyetini birlikte değerlendirmelidir.

Canary Kullanıcı Grubu

Canary rollout küçük çalışan grubunun yeni modeli gerçek işte kullanmasına izin verir. Kullanıcılar model adını görmeden kalite geri bildirimi verebilir. Error ve latency metrikleri eski modelle karşılaştırılabilir. Sorun görülürse trafik hızlıca eski modele döner. Canary grubu farklı departmanları temsil edecek şekilde seçilebilir.

Production Rollout

Production rollout canary başarılı olduktan sonra kademeli yapılmalıdır. Gateway routing yüzde 10, yüzde 25 ve daha yüksek trafik oranlarıyla artırılabilir. Her aşamada hata, latency ve kullanıcı şikayeti izlenir. Rollback kriterleri önceden tanımlanmalıdır. Tam geçiş tamamlandıktan sonra eski model belirli süre backup olarak tutulabilir.

Docker ile Ollama Çalıştırmak

Docker Ollama deployment'ını tekrarlanabilir ve izole hale getirmek için güçlü bir yöntemdir. Official container image kullanıldığında runtime bağımlılıkları daha düzenli yönetilebilir. Model volume container yaşam döngüsünden ayrı tutulmalıdır. GPU passthrough ve resource limit host kapasitesine göre yapılandırılmalıdır. Container network doğrudan kullanıcı ağına açılmak yerine reverse proxy ile izole edilmelidir.

Official Ollama Container

Official image kullanmak kaynağı belirsiz üçüncü taraf container'lara göre daha güvenli başlangıç sağlar. Image version production'da pinlenmelidir. Registry digest kaydedilirse aynı runtime yeniden üretilebilir. Container security scan build veya pull sonrasında uygulanabilir. Image update model update'ten ayrı change süreci olarak yönetilmelidir.

Persistent Model Volume

Model dosyaları ephemeral container filesystem içinde tutulursa container yeniden oluşturulduğunda tekrar indirme gerekebilir. Persistent volume model artifact'lerini korur. Volume permission yalnızca Ollama service account'a verilebilir. Backup ihtiyacı modelin internal registry'den yeniden oluşturulabilir olup olmadığına göre belirlenmelidir. Hassas fine-tuned model varsa backup güvenliği ayrıca önemlidir.

GPU Passthrough

Container'ın GPU kullanabilmesi için host driver ve container runtime entegrasyonu doğru yapılandırılmalıdır. GPU device yalnızca gerekli container'a verilmelidir. Aynı host'ta birden fazla inference container bulunuyorsa kaynak paylaşımı planlanmalıdır. Driver ve runtime version uyumluluğu deployment checklist'inde bulunabilir. GPU görünürlüğü container içinden doğrulanmalıdır.

Health Check

Health check yalnızca container process'in çalıştığını kontrol etmemelidir. API endpoint'in cevap verdiği ve mümkünse modelin kısa inference yapabildiği readiness kontrolü uygulanabilir. Model load süresi nedeniyle startup probe daha uzun tolerans gerektirebilir. Fail olan container load balancer trafiğinden çıkarılmalıdır. Health event'leri monitoring sistemine gönderilmelidir.

Restart Policy

Restart policy geçici process crash durumunda servisin otomatik ayağa kalkmasını sağlar. Ancak sürekli crash loop gerçek problemi gizlememelidir. Belirli tekrar sayısından sonra alert oluşturulabilir. Model load her restart'ta uzun sürüyorsa kullanıcı etkisi ölçülmelidir. Persistent volume sayesinde model artifact tekrar indirilmeden yüklenebilir.

Resource Limits

CPU ve RAM limitleri Ollama container'ın host üzerindeki diğer servisleri etkilemesini önleyebilir. GPU resource limit yaklaşımı kullanılan runtime ve altyapıya bağlıdır. Çok düşük CPU limiti tokenization veya model load performansını bozabilir. Memory limit OOM kill oluşturmayacak şekilde benchmark ile belirlenmelidir. Production resource request ve limit değerleri monitoring verisine göre güncellenmelidir.

Container Network Isolation

Ollama container yalnızca internal Docker network üzerinde bulunabilir. Nginx container bu network üzerinden backend'e bağlanır. Host 11434 portunun dış interface'e publish edilmesi gerekmez. Model pull gerekiyorsa management sırasında kontrollü outbound erişim sağlanabilir. Production inference network'ü internet erişiminden tamamen ayrılabilir.

Docker Compose ile Şirket İçi Ollama Stack'i

Docker Compose küçük ve orta ölçekli şirket içi pilotta Nginx, Ollama, Open WebUI ve monitoring bileşenlerini tek tanımda çalıştırmayı kolaylaştırır. Her servis ayrı container ve network role sahip olabilir. Model volume ve monitoring storage persistent tutulur. Secret değerler compose dosyasına düz metin yazılmamalıdır. Production büyüdükçe orchestration ihtiyacı Kubernetes veya başka platforma geçişi gündeme getirebilir.

Nginx

Nginx dış kullanıcıların eriştiği tek network entry point olarak yapılandırılabilir. TLS, rate limit ve authentication burada uygulanır. Ollama service ismi internal network üzerinden upstream olarak kullanılabilir. 11434 host portuna publish edilmeden yalnızca Compose network içinde erişilebilir. Nginx config ayrı version-controlled dosyada tutulmalıdır.

Ollama

Ollama container GPU device ve persistent model volume ile çalıştırılabilir. Container yalnızca internal network üzerinde bulunmalıdır. Environment ayarları compose config veya secret mekanizmasıyla yönetilebilir. Model pull yetkisi normal kullanıcı trafiğinden ayrılmalıdır. Health check orchestration sisteminin restart ve routing kararına girdi sağlayabilir.

Open WebUI

Open WebUI çalışanlara chat benzeri kullanıcı arayüzü sunabilir. Ollama backend doğrudan browser tarafından değil Open WebUI veya gateway üzerinden erişilebilir. Authentication mevcut SSO ile mümkün olduğunca entegre edilmelidir. Conversation history politikasının nerede saklandığı incelenmelidir. Open WebUI'nin tek başına bütün network güvenlik sınırı olmadığı unutulmamalıdır.

Monitoring

Monitoring container'ları GPU, proxy ve application metriklerini toplar. Prometheus benzeri sistem metrikleri scrape edebilir. Grafana dashboard kullanıcı, model ve GPU görünümü sunabilir. Loglar ayrı merkezi sistemde tutulabilir. Monitoring servisine production secret veya prompt içeriği verilmemelidir.

Persistent Storage

Model dosyası, kullanıcı history'si ve monitoring database farklı storage ihtiyaçlarına sahiptir. Hepsini aynı volume altında tutmak backup ve erişim kontrolünü zorlaştırabilir. Model artifact yeniden indirilebilirken conversation history kişisel veri içerebilir. Backup ve retention policy bu nedenle ayrı tanımlanmalıdır. Storage doluluk metriği büyük model pull işlemlerinden önce kontrol edilmelidir.

Internal Network

Compose internal network backend servislerini host dışından doğrudan erişilemez hale getirebilir. Nginx dış network ile internal network arasında kontrollü köprü görevi görür. Open WebUI ve Ollama aynı backend network üzerinde olabilir. Monitoring yalnızca gerekli endpoint'lere erişmelidir. Network map deployment dokümantasyonunda açık biçimde gösterilmelidir.

Secrets Management

API key ve TLS private key gibi değerler compose YAML içine düz metin yazılmamalıdır. Docker secret, external secret manager veya deployment sistemi kullanılabilir. Environment variable kullanılıyorsa process ve debug log sızıntısı riski değerlendirilmelidir. Secret rotation container restart gerektiriyorsa prosedür otomatikleştirilebilir. Production ve staging secret'ları birbirinden ayrı tutulmalıdır.

Open WebUI ile Çalışanlara ChatGPT Benzeri Arayüz Sunmak

Open WebUI şirket çalışanlarına yerel modeller için tanıdık chat arayüzü sunmak amacıyla kullanılabilir. Kullanıcı model seçebilir, konuşma geçmişi tutabilir ve uygun entegrasyonlarla şirket içi Ollama backend'ine bağlanabilir. Ancak arayüzün kolay kullanılması güvenlik katmanlarının kaldırılması anlamına gelmemelidir. SSO, grup bazlı model yetkisi, history retention ve backend network izolasyonu ayrıca tasarlanmalıdır. Kullanıcı deneyimi ile güvenlik policy aynı platform mimarisi içinde birlikte yürütülmelidir.

Open WebUI Nedir?

Open WebUI yerel ve farklı LLM backend'leriyle çalışabilen web tabanlı kullanıcı arayüzüdür. Çalışanların komut satırı veya API istemcisi kullanmadan modellerle konuşmasını kolaylaştırır. Kurumsal kullanımda kullanıcı ve history yönetimi önemli hale gelir. Uygulamanın kendi veritabanı backup ve access control kapsamına alınmalıdır. Sürüm güncellemeleri normal software supply-chain süreciyle yönetilmelidir.

Ollama Bağlantısı

Open WebUI Ollama backend'e internal network üzerinden bağlanabilir. Backend URL kullanıcı browser'ına açık olmak zorunda değildir. Aynı sunucudaysa container network veya localhost kullanılabilir. Farklı sunucudaysa TLS ve firewall ile güvenilir servis bağlantısı kurulmalıdır. Open WebUI'nin backend'e geniş model management permission ile bağlanıp bağlanmadığı kontrol edilmelidir.

Authentication

Çalışanların Open WebUI erişimi kurumsal identity ile korunmalıdır. SSO entegrasyonu mümkünse local password hesabı sayısı azaltılabilir. Administrator hesapları normal kullanıcı hesaplarından ayrılmalıdır. MFA kurumsal identity provider üzerinden uygulanabilir. Shared account kullanımından kaçınılmalıdır.

Kullanıcı Yönetimi

Kullanıcı onboarding ve offboarding insan kaynakları yaşam döngüsüyle uyumlu olmalıdır. Yeni çalışan uygun role otomatik eklenebilir. Ayrılan çalışanın AI erişimi merkezi identity sistemi üzerinden kapanmalıdır. Local orphan account'lar düzenli kontrol edilmelidir. Kullanıcı role ve grup değişiklikleri audit log'a kaydedilmelidir.

Model Seçimi

Arayüzde kullanıcıya bütün modelleri göstermek gerekmez. Departman bazlı allowlist uygulanabilir. Büyük ve pahalı reasoning model yalnızca yetkili kullanıcı grubuna açılabilir. Default model kolay görevlerde yeterli hızlı seçenek olabilir. Model adı yanında kullanım amacı kullanıcıya açıklanırsa doğru seçim oranı artar.

Conversation History

Conversation history hassas şirket verisi ve kişisel bilgi içerebilir. Saklama süresi açık policy ile belirlenmelidir. Kullanıcı konuşmasını silebilmeli veya retention otomatik uygulanmalıdır. Backup sistemi silinen veriyi sonsuza kadar tutmamalıdır. History erişimi yalnızca ilgili kullanıcı ve yetkili yönetim rolleriyle sınırlandırılmalıdır.

Open WebUI Güvenlik Sınırı Olarak Yeterli midir?

Open WebUI tek başına bütün kurumsal güvenlik sınırı olarak görülmemelidir. Backend Ollama portu kullanıcı ağından erişilebiliyorsa arayüzdeki yetkilendirme bypass edilebilir. Reverse proxy, firewall ve management endpoint izolasyonu yine gereklidir. Uygulamanın kendi authentication ve session güvenliği de düzenli güncellenmelidir. Defense-in-depth yaklaşımı arayüz, gateway ve network kontrollerini birlikte kullanır.

Kurumsal Uygulamalar Ollama API'ye Nasıl Bağlanır?

Kurumsal uygulamalar doğrudan ham Ollama IP adresine değil merkezi AI gateway endpoint'ine bağlanmalıdır. Bu gateway native API veya OpenAI-compatible interface sunabilir. Python ve Node.js uygulamaları service identity ile authentication yapabilir. IDE veya ERP entegrasyonları ayrı API key ve quota kullanabilir. Böylece hangi uygulamanın ne kadar model kaynağı tükettiği açık biçimde ölçülebilir.

Ollama Native API

Ollama Native API modelin sunduğu temel generation ve chat işlemlerini doğrudan kullanmak için uygundur. Uygulama model adı, prompt ve generation parameter'larını gönderebilir. Streaming response kullanıcı deneyimini iyileştirir. Kurumsal gateway native endpoint'i proxy edebilir ve policy uygulayabilir. İstemci doğrudan backend network detayını bilmek zorunda kalmaz.

OpenAI-Compatible API

OpenAI-compatible API mevcut SDK ve uygulamaların local inference backend'e daha az değişiklikle bağlanmasını sağlar. Gateway bu compatibility katmanını merkezi sunabilir. Ancak bütün modeller tool calling, response format ve parameter davranışında birebir aynı olmayabilir. Regression integration testleri yapılmalıdır. Model özel özellikler gerekirse native API ayrıca kullanılabilir.

Python Uygulamaları

Python uygulaması internal gateway URL'sine HTTP veya uygun SDK üzerinden bağlanabilir. Timeout ve retry değerleri LLM latency'sine göre ayarlanmalıdır. Token secret store üzerinden alınmalıdır. Response schema validation automation workflow'larında zorunlu tutulabilir. Uygulama loguna kullanıcı prompt'unu otomatik yazdırmamak gerekir.

Node.js Uygulamaları

Node.js backend aynı gateway'i kullanarak chat veya generation request gönderebilir. Browser frontend'in API key'i doğrudan taşıması güvenli değildir. Frontend kendi backend'ine, backend ise AI gateway'e bağlanmalıdır. Streaming için server-sent events veya uygun stream proxy mekanizması kullanılabilir. Connection timeout ve cancellation davranışı test edilmelidir.

VS Code ve Geliştirici Araçları

Geliştirici araçları şirket kaynak kodunu modele gönderebileceği için approved endpoint kullanmalıdır. Local extension doğrudan internet model servisine bağlanmamalıdır. Kurumsal AI gateway IDE için özel token veya SSO akışı sunabilir. Repository access policy modele gönderilebilecek context'i sınırlandırabilir. Kullanım logları kaynak kodun kendisini kaydetmeden metadata seviyesinde tutulabilir.

ERP / CRM Entegrasyonları

ERP veya CRM entegrasyonlarında model müşteri ve iş verisiyle çalışabilir. Bu nedenle service identity minimum permission ile sınırlandırılmalıdır. Model yalnızca gerekli field'ları görmelidir. Structured output backend validation'dan geçmeden otomatik işlem yapılmamalıdır. Kritik karar veya kayıt değişikliği insan onayı gerektirebilir.

Şirket Dokümanları ile RAG Kullanmak

RAG şirketin özel dokümanlarını modelin training verisine eklemeden sorgu sırasında ilgili parçaları sağlamayı amaçlar. Dokümanlar ingestion aşamasında parse edilir, chunk'lara ayrılır ve embedding üretilir. Kullanıcı sorusu geldiğinde benzer chunk'lar vector database üzerinden bulunur. Llama veya Qwen yalnızca seçilen context'i kullanarak yanıt üretir. RAG kalitesinin yarısı modelden, diğer yarısı veri hazırlama ve retrieval tasarımından gelir.

RAG Nedir?

Retrieval-Augmented Generation modelin cevap üretmeden önce harici bilgi kaynağından ilgili içerik almasını sağlar. Bu yöntem şirket prosedürü veya ürün dokümanı gibi özel bilgileri modele sunmak için kullanışlıdır. Model ağırlığını değiştirmek gerekmez. Doküman güncellendiğinde index yeniden oluşturulabilir. Retrieval authorization doğru uygulanmazsa kullanıcı yetkisiz doküman içeriğini görebilir.

Ollama ile Embedding

Embedding modeli metni sayısal vektör temsiline dönüştürür. Ollama üzerinden uygun embedding modelleri yerel olarak çalıştırılabilir. Doküman ve sorgu aynı embedding model ailesiyle işlenmelidir. Embedding model değişirse index yeniden oluşturma gerekebilir. Türkçe retrieval kalitesi gerçek soru doküman setiyle test edilmelidir.

Vector Database

Vector database embedding vektörlerini ve ilgili document metadata'sını saklar. Retrieval en yakın vektörleri bulurken departman veya ACL filtreleri de uygulamalıdır. Backup ve encryption politikası vector store için geçerlidir çünkü chunk metinleri hassas olabilir. Database network erişimi yalnızca RAG backend ile sınırlandırılmalıdır. Index version model ve chunking configuration ile ilişkilendirilebilir.

Document Ingestion

Ingestion dokümanların sisteme alınması, formatının çıkarılması ve metadata eklenmesi sürecidir. Kaynak sistem, document owner, departman ve erişim grubu metadata olarak tutulabilir. Zararlı veya beklenmeyen dosya formatları güvenlik kontrolünden geçirilmelidir. Çok eski veya duplicate dokümanlar retrieval kalitesini düşürebilir. Ingestion pipeline değişiklik ve silme olaylarını kaynak sistemle senkronize etmelidir.

Chunking

Chunking uzun dokümanı retrieval için yönetilebilir parçalara böler. Çok küçük chunk bağlamı kaybettirebilir, çok büyük chunk gereksiz context ve token maliyeti oluşturabilir. Başlık ve paragraf yapısını koruyan semantic chunking bazı dokümanlarda daha iyi sonuç verebilir. Chunk size benchmark ile seçilmelidir. Her chunk document ACL bilgisini taşımaya devam etmelidir.

Retrieval

Retrieval kullanıcı sorusuna en ilgili chunk'ları bulur. Similarity score yanında metadata filter ve reranker kullanılabilir. Çok fazla sonuç modele gönderilmemelidir. Retrieval hit rate ayrı benchmark metriği olmalıdır. Yanlış cevap bazen model değil yanlış chunk seçiminden kaynaklanır.

Llama ve Qwen ile Yanıt Üretimi

Retrieved chunk'lar system prompt ile Llama veya Qwen modeline aktarılır. Modelden yalnızca verilen kaynaklara göre cevap vermesi istenebilir. Kaynak citation veya document ID response'a eklenebilir. Aynı retrieval sonucu farklı modellerde benchmark edilerek generation kalitesi karşılaştırılabilir. Model retrieval sistemindeki yetki sınırını değiştirmemelidir.

RAG Kullanırken Yetki Kontrolü

Kurumsal RAG sisteminin en önemli güvenlik gereksinimlerinden biri kullanıcının yalnızca erişmeye yetkili olduğu dokümanlardan retrieval yapılmasıdır. Kullanıcı model arayüzünde “finans raporunu göster” dedi diye retrieval sistemi finans indeksini aramamalıdır. Document ve chunk metadata'sında ACL bilgisi tutulabilir. Query sırasında kullanıcı identity'siyle filtre uygulanmalıdır. Bu kontrol prompt seviyesinde değil backend authorization katmanında yapılmalıdır.

Her Çalışanın Her Dokümana Erişememesi

Şirket dosya sisteminde herkesin her dokümana erişimi olmadığı gibi RAG sistemi de bu kuralı korumalıdır. Kaynak sistemin permission bilgisi ingestion sırasında taşınabilir. Kullanıcı identity provider grup bilgisi retrieval filtresine eklenir. Yetkisiz chunk model context'ine hiç girmemelidir. Modelden “bu bilgiyi paylaşma” demek access control değildir.

Document-Level ACL

Document-level ACL bütün belge için erişim gruplarını tanımlar. İnsan kaynakları dokümanı yalnızca HR grubuna açık olabilir. Ingestion sırasında ACL metadata vector store'a eklenir. Retrieval sorgusu user group listesiyle filter uygular. Kaynak sistemde permission değiştiğinde index metadata güncellenmelidir.

Chunk-Level ACL

Bazı dokümanların farklı bölümleri farklı permission gerektirebilir. Chunk-level ACL bu daha ayrıntılı erişim modelini destekler. Ancak permission yönetimi daha karmaşık hale gelir ve senkronizasyon dikkatli tasarlanmalıdır. Yanlış metadata sızıntıya neden olabilir. Gerçek ihtiyaç yoksa document-level model daha sade ve güvenlidir.

Kullanıcı ve Grup Metadata'sı

User identity gateway'den RAG backend'e güvenilir biçimde aktarılmalıdır. Kullanıcının gönderdiği header doğrudan kabul edilmemelidir. Identity provider'dan gelen signed token veya proxy verified claim kullanılabilir. Grup listesi retrieval filter oluşturur. Çok büyük grup listeleri için merkezi authorization servisi daha verimli olabilir.

Retrieval-Time Authorization

Authorization retrieval yapılırken uygulanmalıdır. Önce bütün chunk'ları çekip sonra modelden gizlemesini istemek güvenli değildir. Database query yalnızca izin verilen kayıtları döndürmelidir. Cache kullanılıyorsa cache key kullanıcı veya permission context'ini içermelidir. Yetki değişikliği cache invalidation sürecini tetiklemelidir.

Departmanlar Arası Veri Sızıntısının Önlenmesi

Departmanlar arası veri sızıntısı RAG tasarımındaki en ciddi risklerden biridir. Finans kullanıcısının HR chunk'ını veya tersini alması modelden bağımsız authorization hatasıdır. Automated security test farklı role sahip kullanıcılarla aynı soruyu çalıştırabilir. Retrieval result ID'leri loglanarak erişim doğrulanabilir. Security review yalnızca chatbot UI'sine değil vector database query katmanına odaklanmalıdır.

Şirket İçi Ollama Kullanımında Güvenlik Riskleri

Yerel model kullanmak veri kontrolünü artırır ancak güvenlik risklerini ortadan kaldırmaz. Yetkisiz API kullanımı GPU kaynağını tüketebilir, management endpoint suistimali model setini değiştirebilir ve RAG hataları hassas veriyi yanlış kullanıcıya gösterebilir. Prompt injection tool kullanan uygulamalarda daha ciddi etki oluşturabilir. Model artifact'in kendisi supply-chain kaynağıdır ve güvenilir kaynaktan gelmelidir. Production threat model bu risklerin tamamını birlikte değerlendirmelidir.

Yetkisiz API Kullanımı

Authentication olmayan internal endpoint herhangi bir çalışan veya compromised cihaz tarafından kullanılabilir. GPU kaynağı kötüye kullanılabilir ve hassas model output erişimi oluşabilir. Gateway authentication ve network segmentation birlikte uygulanmalıdır. API key leak durumunda hızlı revoke mekanizması bulunmalıdır. Audit log anormal request rate'i tespit etmeye yardımcı olur.

GPU Resource Abuse

Kullanıcı çok uzun context ve output isteyerek GPU'yu dakikalarca meşgul edebilir. Script hatası yüzlerce paralel request gönderebilir. Context, output token, request rate ve quota limitleri bu riski azaltır. Departman başına kullanım bütçesi tanımlanabilir. Anormal tüketim monitoring alert'i oluşturmalıdır.

Model Yönetim Endpoint'lerinin Kötüye Kullanımı

Yetkisiz model pull storage'ı doldurabilir veya lisansı onaylanmamış artifact'i production'a getirebilir. Delete çağrısı aktif modeli kaldırabilir. Create işlemi güvenlik policy'sini değiştiren system prompt veya template oluşturabilir. Management endpoint yalnızca administrator role açılmalıdır. Network erişimi ayrıca ayrılmalıdır.

Prompt Injection

Prompt injection özellikle RAG ve tool kullanan uygulamalarda önemlidir. Zararlı doküman modelden sistem talimatlarını yok saymasını isteyebilir. Model instruction hierarchy tek başına kesin güvenlik sınırı değildir. Tool permission backend tarafında kullanıcı yetkisine göre doğrulanmalıdır. Retrieved content untrusted data olarak ele alınmalıdır.

Sensitive Data Leakage

Kullanıcı prompt içinde kişisel veri, parola veya müşteri bilgisi gönderebilir. Model response bu veriyi conversation history veya log üzerinden başka yere taşıyabilir. Input classification veya redaction belirli veri türlerini engelleyebilir. Conversation access control ve retention politikası uygulanmalıdır. Eğitim amacıyla prompt logları başka ortama taşınmamalıdır.

RAG Data Leakage

RAG data leakage çoğu zaman retrieval authorization eksikliğinden kaynaklanır. Model yalnızca kendisine verilen chunk'ı görür, dolayısıyla yanlış chunk verilirse güvenlik ihlali gerçekleşmiştir. ACL filter query öncesinde uygulanmalıdır. Cache permission context'i dikkate almalıdır. Security regression test farklı departman kullanıcılarıyla düzenli çalıştırılmalıdır.

Malicious Model Artifact

Model artifact güvenilir olmayan kaynaktan alındığında supply-chain riski oluşturabilir. Model formatı ve runtime davranışı incelenmelidir. Custom code çalıştırılması gereken model repository'leri daha yüksek risk taşır. Approved registry ve hash kontrolü bu riski azaltır. Production sunucusunun kullanıcı tarafından yüklenen rastgele model dosyalarını kabul etmemesi gerekir.

Supply-Chain Riskleri

Supply chain model, container image, Python package, UI ve gateway dependency'lerini kapsar. Bir bileşenin compromised olması bütün internal AI servisini etkileyebilir. Artifact version pinning ve vulnerability scanning uygulanmalıdır. Third-party image ve model kaynağı allowlist ile sınırlandırılabilir. Update süreci security review'dan geçmelidir.

Model Supply-Chain Güvenliği

Model supply-chain güvenliği hangi modelin nereden geldiğini, hangi lisansla kullanıldığını ve production'a nasıl taşındığını izlenebilir hale getirir. Model artifact büyük olduğu için ekipler çoğu zaman yalnızca indirme kolaylığına odaklanır. Oysa kaynağın doğrulanması, digest kaydı ve approved registry kullanımı en az container image kadar önemlidir. Air-gapped sistemlerde offline artifact repository bu süreci daha da kritik hale getirir. Her production model için source, version, hash, lisans ve benchmark kaydı bulunmalıdır.

Model Kaynağının Doğrulanması

Model yalnızca resmi veya kurum tarafından güvenilir kabul edilen repository'den alınmalıdır. Benzer isimli community upload'ları production için otomatik kabul edilmemelidir. Publisher identity ve model metadata kontrol edilmelidir. Kullanılan exact source URL change record'a eklenebilir. Kaynak değişikliği yeni security review gerektirebilir.

Model Hash Kontrolü

Hash model dosyasının beklenen artifact ile aynı olduğunu doğrulamaya yardımcı olur. İndirme ve transfer sonrası digest karşılaştırılabilir. Internal registry hash'i immutable metadata olarak saklayabilir. Production deployment yalnızca approved digest'i kabul edebilir. Hash kaynağın güvenilirliğini tek başına kanıtlamaz ancak integrity kontrolü sağlar.

Approved Model Registry

Approved registry kurumsal olarak izin verilen model artifact'lerinin merkezi kataloğudur. Kullanıcı veya production server internetten doğrudan model pull etmek yerine bu kaynağı kullanabilir. Registry lisans, owner, version ve security status metadata'sı tutabilir. Deprecated modeller işaretlenebilir. Bu yapı model governance sürecini önemli ölçüde kolaylaştırır.

Model Lisans Metadata'sı

Her artifact yanında lisans adı, lisans dosyası ve değerlendirme tarihi tutulabilir. Aynı model ailesinin farklı sürümünde lisans değişikliği mümkün olduğundan metadata version bazında olmalıdır. Hukuk onay kaydı eklenebilir. Redistribution veya fine-tuning koşulları kısa not olarak saklanabilir. Deployment pipeline yalnızca approved status taşıyan modeli kabul edebilir.

Security Review

Security review model artifact'in kaynağı, runtime requirement ve kullanım biçimini değerlendirir. Modelle birlikte custom code indiriliyorsa özellikle dikkat edilmelidir. Tool calling veya multimodal özelliklerin saldırı yüzeyi ayrıca incelenebilir. Prompt injection regression test model değişiminde tekrar çalıştırılabilir. Review sonucu registry status alanına işlenebilir.

Offline Artifact Repository

Offline repository air-gapped veya egress kısıtlı sistemlere model dağıtmak için merkezi kaynak sağlar. Artifact bir kez güvenli ortamda onaylanır ve iç ağa aktarılır. Production sunucuları yalnızca bu repository'ye erişir. Böylece internet model repository'siyle doğrudan iletişim gerekmez. Backup ve storage kapasitesi büyük model dosyaları dikkate alınarak planlanmalıdır.

Prompt ve Response Logları Nasıl Yönetilmeli?

Prompt ve response loglama operasyon için değerli olsa da aynı zamanda yeni hassas veri deposu oluşturur. Her prompt'u sonsuza kadar saklamak doğru varsayım değildir. Metadata-only logging birçok performans ve audit ihtiyacını karşılayabilir. Tam içerik gerekiyorsa PII redaction ve kısa retention uygulanmalıdır. Conversation history ile audit log ayrı sistem ve erişim politikalarına sahip olabilir.

Her Prompt Loglanmalı mı?

Hayır, her prompt'un tam içeriğini loglamak zorunlu değildir. Kullanıcı ID, model, token sayısı, latency ve status operasyon için yeterli olabilir. Debug amacıyla sınırlı örnekleme yapılabilir. Tam prompt log gerekiyorsa açık iş gerekçesi ve retention süresi belirlenmelidir. Hassas departmanlarda içerik logging tamamen kapatılabilir.

PII ve Hassas Veri

Kullanıcılar prompt içinde isim, telefon, müşteri numarası veya başka kişisel bilgiler gönderebilir. Log sistemi bu verileri model servisinden daha uzun süre saklayabilir. Otomatik PII detection ve redaction uygulanabilir. Hassas veri sınıflandırması departman kullanımına göre farklı olabilir. Log erişimi minimum yetkiyle sınırlandırılmalıdır.

Log Redaction

Redaction belirli alanları log yazılmadan önce maskeleyebilir. E-posta, telefon, token ve API key pattern'leri örnek kategorilerdir. Model request JSON'unun tamamını raw biçimde saklamak yerine güvenli alan listesi kullanılabilir. Redaction kuralı false negative açısından düzenli test edilmelidir. Debug log production'da varsayılan açık bırakılmamalıdır.

Metadata-Only Logging

Metadata-only yaklaşım içerik yerine model adı, kullanıcı, timestamp, latency ve token sayısı tutar. Kapasite planlaması için oldukça yeterlidir. Kullanıcı davranışı içerik okunmadan analiz edilebilir. Güvenlik incident'inde gerekirse belirli süreli enhanced logging açılabilir. Bu model data minimization yaklaşımını destekler.

Retention

Retention logların ne kadar süre tutulacağını tanımlar. Audit log ve conversation history aynı süreye sahip olmak zorunda değildir. Performans metrikleri anonimleştirilmiş olarak daha uzun süre saklanabilir. Prompt içeriği varsa daha kısa retention tercih edilebilir. Silme işleminin backup kopyalarındaki veriyi nasıl etkilediği ayrıca belirlenmelidir.

Audit Log ile Conversation Log Farkı

Audit log kimin hangi yönetsel veya erişim işlemini yaptığını kanıtlamaya odaklanır. Conversation log ise kullanıcı ile model arasındaki içerik geçmişidir. Audit için prompt'un tamamı çoğu zaman gerekli değildir. Conversation history kullanıcı deneyimi için saklanabilir ancak daha hassas veri sınıfına sahiptir. İki veri türü farklı erişim ve retention politikasıyla yönetilmelidir.

KVKK Açısından Şirket İçi Ollama Kullanımı

Şirket içi Ollama kullanımı kişisel verilerin tamamen risk dışına çıktığı anlamına gelmez. Prompt, conversation history, RAG dokümanı ve access log içinde kişisel veri bulunabilir. Veri minimization ve amaçla sınırlı kullanım ilkeleri teknik tasarıma yansıtılmalıdır. Retention, silme ve yetkilendirme süreçleri veri yaşam döngüsünü kontrol etmelidir. KVKK kapsamındaki kesin hukuki yükümlülükler kurumun veri işleme faaliyetine göre hukuk ve kişisel veri uzmanlarıyla ayrıca değerlendirilmelidir.

Prompt İçindeki Kişisel Veriler

Çalışan modelden yardım isterken gerçek müşteri veya çalışan bilgilerini prompt'a yapıştırabilir. Bu davranış kullanım politikası ve eğitimle kontrol edilmelidir. Gerekirse input redaction belirli veri kategorilerini maskeleyebilir. Hassas kullanım senaryoları ayrı model endpoint'ine yönlendirilebilir. Kullanıcının modele erişimi bütün veri sınıflarına erişim hakkı verdiği anlamına gelmez.

Conversation History

Conversation history uzun süre tutulduğunda yeni bir kişisel veri deposu haline gelebilir. Kullanıcı kendi geçmişini yönetebilmelidir. Administrator erişimi minimum olmalıdır. Otomatik retention ve silme mekanizması uygulanabilir. Backup ve export işlemleri aynı veri politikasına dahil edilmelidir.

RAG Dokümanları

RAG kaynaklarında personel dosyası, müşteri kaydı veya sözleşme gibi kişisel veri bulunabilir. Vector database içinde chunk'ların hangi dokümandan geldiği takip edilmelidir. ACL kaynak sistem izinlerini korumalıdır. Doküman silindiğinde index'teki ilgili chunk'lar da silinmelidir. Embedding vektörleri de veri yönetişimi kapsamında değerlendirilmelidir.

Access Logs

Access log kullanıcı ID ve IP gibi kişisel veri niteliği taşıyabilecek bilgiler içerebilir. Log retention yalnızca güvenlik ihtiyacı kadar tutulmalıdır. Erişim güvenlik ve operasyon ekipleriyle sınırlandırılabilir. Analitik amaçla uzun süre tutulacak veri anonimleştirilebilir. Log export işlemleri de kontrollü yapılmalıdır.

Data Minimization

Data minimization modelin görev için ihtiyaç duymadığı veriyi hiç almamasını hedefler. ERP entegrasyonu bütün müşteri kaydını değil yalnızca gerekli alanları göndermelidir. RAG retrieval yalnızca ilgili chunk'ı sağlar. Prompt logları metadata seviyesinde tutulabilir. Bu yaklaşım olası sızıntının etkisini de azaltır.

Retention ve Silme

Her veri kategorisi için saklama süresi belirlenmelidir. Conversation, audit log ve benchmark dataset'i farklı retention ihtiyacına sahip olabilir. Kullanıcı hesabı silindiğinde konuşma geçmişinin ne olacağı açık olmalıdır. Backup retention süresi canlı sistemden farklı olabilir. Silme süreci düzenli olarak test edilmelidir.

Yetkilendirme

Yetkilendirme kullanıcının yalnızca gerekli model, RAG kaynağı ve conversation verisine erişmesini sağlamalıdır. SSO group bilgisi permission policy'ye bağlanabilir. Administrator rolü sınırlı kullanıcı grubunda tutulmalıdır. Yetki değişiklikleri audit log'a kaydedilmelidir. Düzenli access review eski izinlerin birikmesini önler.

Ollama Monitoring Nasıl Kurulur?

Monitoring production Ollama servisinin kapasitesini ve kullanıcı deneyimini görünür hale getirir. Nginx request metrikleri, GPU telemetry, application log ve health check verileri ortak dashboard'da birleştirilebilir. Prometheus zaman serisi metriklerini toplarken Grafana görselleştirme sağlayabilir. Prompt içeriğini monitoring sistemine taşımak gerekmez. Model ve kullanıcı grubuna göre latency ile kaynak tüketimi karar vermek için yeterli sinyal üretir.

Uygulama Metrikleri

Gateway veya AI uygulaması request rate, latency, token count ve status bilgisi üretebilir. Model adı ve route label metriklere eklenebilir. Kullanıcı kimliğini doğrudan yüksek cardinality label yapmak yerine departman veya application gibi daha kontrollü boyutlar tercih edilebilir. Error type ayrı sayaçlarla tutulmalıdır. Metrikler kapasite planlama ve SLA analizi için kullanılabilir.

Nginx Metrikleri

Nginx aktif bağlantı, request rate ve HTTP status bilgisi sağlayabilir. 429 oranı rate limit politikasının ne kadar sık devreye girdiğini gösterir. Upstream response time backend inference sorununu ayırmaya yardımcı olur. 502 veya timeout artışı Ollama veya network problemi gösterebilir. Nginx logları prompt body içermeden yapılandırılmalıdır.

GPU Metrikleri

GPU utilization ve VRAM kullanımı kapasitenin temel göstergeleridir. Power, temperature ve throttling bilgileri donanım sağlığını izlemek için faydalıdır. VRAM sürekli yüksek ama GPU utilization düşükse büyük model bellekte boş bekliyor olabilir. GPU yüzde yüz dolu ve queue artıyorsa scale ihtiyacı vardır. Multi-GPU sistemde her cihaz ayrı izlenmelidir.

Loglar

Application, gateway ve system logları merkezi log platformuna gönderilebilir. Request ID katmanlar arasında correlation sağlar. Prompt ve response içeriği varsayılan log formatına eklenmemelidir. Model load, unload ve error olayları açık loglanmalıdır. Log retention güvenlik ve gizlilik politikasıyla uyumlu olmalıdır.

Health Checks

Liveness check process'in çalıştığını, readiness check ise trafiği kabul etmeye hazır olduğunu göstermelidir. Model yüklenirken instance canlı olabilir ancak hazır olmayabilir. Load balancer readiness sonucuna göre trafik yönlendirmelidir. Deep health check düşük sıklıkta kısa inference yapabilir. Çok sık inference health check gereksiz GPU yükü oluşturabilir.

Prometheus

Prometheus gateway ve exporter'ların sunduğu metrikleri toplayabilir. GPU exporter ile hardware telemetry eklenebilir. Label tasarımı cardinality kontrolü açısından önemlidir. Alert rule yüksek queue, GPU error veya error rate için oluşturulabilir. Metric retention uzun dönem kapasite trendini analiz etmeye yardımcı olur.

Grafana

Grafana teknik ve yönetim dashboard'ları hazırlamak için kullanılabilir. Operasyon ekibi GPU ve latency detayını, yönetim ise kullanıcı ve maliyet trendini görebilir. P50, P95 ve P99 aynı panelde karşılaştırılabilir. Deployment annotation model sürüm değişikliklerinin metrik etkisini gösterir. Dashboard alarm sistemi yerine gözlem katmanı olarak kullanılmalı, kritik uyarılar alert mekanizmasına bağlanmalıdır.

Hangi Metrikler Takip Edilmeli?

Production LLM servisinde GPU kullanımı kadar kullanıcı deneyimi ve queue davranışı da izlenmelidir. VRAM, request rate, TTFT, token throughput, error rate ve model load time temel metriklerdir. Concurrent user sayısı kapasite planlamasını gerçek kullanıcı hacmine bağlar. Queue size artışı throughput sınırına yaklaşıldığını gösterir. Metriklerin model ve version bazında ayrılması update etkisini anlamayı kolaylaştırır.

GPU Utilization

GPU utilization accelerator'ın ne kadar aktif çalıştığını gösterir. Uzun süre düşük kullanım aşırı kapasiteye işaret edebilir. Yüzde yüze yakın kullanım ve artan queue yeni GPU ihtiyacını gösterebilir. Tek anlık değer yerine zaman serisi incelenmelidir. Departman kullanım saatleri kapasite profiline eklenebilir.

VRAM Usage

VRAM model weight, KV cache ve runtime buffer tarafından tüketilir. Peak değer özellikle concurrency testinde önemlidir. Sürekli yüzde 95 üzeri kullanım OOM riskini artırabilir. Model load ve unload olayları grafikte işaretlenebilir. Yeni context config sonrası memory trendi karşılaştırılmalıdır.

Request Rate

Request rate saniye veya dakika başına gelen model çağrısını gösterir. Kullanıcı sayısından daha anlamlı gerçek trafik metriğidir. Sabah ve öğleden sonra yoğunluk farklı olabilir. Application bazında request rate capacity planning'e yardımcı olur. Ani sıçrama hatalı script veya abuse sinyali olabilir.

Queue Size

Queue size GPU'nun işleyemediği bekleyen istek sayısını gösterir. Sürekli yükselmesi kapasitenin talebin altında olduğunu gösterir. Kısa burst normal olabilir. Queue limit dolduğunda rejection metriği ayrıca izlenmelidir. Load balancer yeni instance ekleyerek queue'yu azaltabilir.

TTFT

TTFT kullanıcı deneyiminde en önemli latency metriklerinden biridir. Cold start, queue ve prompt processing etkisini içerir. P95 TTFT yoğun kullanıcıların durumunu gösterir. Model bazında karşılaştırılmalıdır. Çok yüksek TTFT model routing veya preloading ihtiyacını gösterebilir.

Token Throughput

Token throughput GPU'nun generation kapasitesini gösterir. Toplam sistem throughput ve request başına throughput ayrı tutulabilir. Concurrency arttıkça toplam throughput artarken bireysel hız düşebilir. Kullanıcı kabul kriteri belirlenmelidir. Model quantization karşılaştırmasında önemli metriktir.

Error Rate

Error rate backend, gateway ve client kaynaklı hataları kategorilere ayırmalıdır. OOM, timeout, rate limit ve authentication hataları farklıdır. Model deployment sonrası ani artış rollback kriteri olabilir. 5xx oranı SLA için izlenebilir. Error log request ID ile trace edilebilir.

Model Load Time

Model load time cold start deneyimini belirler. Büyük artifact ve yavaş storage süreyi artırır. Restart sonrası modelin hazır olması dakikalar sürüyorsa high availability tasarımı önem kazanır. NVMe storage ve preloading fayda sağlayabilir. Load süresi model version benchmark'ına eklenmelidir.

Concurrent Users

Concurrent users kapasite modelinin temel girdisidir. Toplam çalışan sayısı yerine aynı anda inference yapan kullanıcı sayısı ölçülmelidir. P95 concurrency değeri normal peak yükü temsil edebilir. Özel etkinlik veya rapor dönemleri daha yüksek burst oluşturabilir. GPU yatırımı bu gerçek verilere göre planlanmalıdır.

Ollama Sunucusu Nasıl Ölçeklendirilir?

Ollama ölçeklendirme önce vertical scaling ile daha büyük GPU veya daha fazla RAM kullanarak başlayabilir. Tek sunucu sınırına ulaşıldığında birden fazla Ollama instance ve load balancer eklenebilir. Model bazlı sunucu havuzları büyük ve küçük modellerin kaynaklarını ayırır. Multi-GPU belirli büyük modeller için gerekli olabilir. Çok yüksek throughput hedefinde vLLM gibi farklı serving motorlarına migration değerlendirilmelidir.

Vertical Scaling

Vertical scaling mevcut sunucuya daha güçlü GPU veya daha fazla sistem kaynağı eklemektir. Operasyon olarak en basit yöntemdir. Tek endpoint ve tek model store korunabilir. Ancak hardware failure bütün servisi etkileyebilir. Bir noktadan sonra daha büyük GPU ekonomik veya fiziksel olarak sınırlı hale gelir.

Daha Büyük GPU

Daha büyük VRAM'li GPU daha büyük modeli tamamen accelerator üzerinde tutmayı sağlayabilir. Concurrency için de daha fazla headroom sunar. Ancak purchase cost ve enerji tüketimi artar. Model benchmark kalitesi bu yatırımı haklı çıkarmalıdır. İkinci orta GPU bazen tek çok pahalı GPU'dan daha iyi availability sağlayabilir.

Multi-GPU

Multi-GPU büyük model ağırlıklarını birden fazla cihaza dağıtmayı mümkün kılabilir. Performance topology ve interconnect'e bağlıdır. Her inference motoru multi-GPU kullanımını aynı verimlilikte yönetmez. Power, cooling ve server chassis gereksinimi artar. Pilot benchmark gerçek production donanımında yapılmalıdır.

Birden Fazla Ollama Instance

Birden fazla instance horizontal scaling sağlar. Her instance ayrı GPU kullanabilir veya ayrı sunucuda çalışabilir. Load balancer healthy backend'lere trafik dağıtır. Model version bütün instance'larda aynı tutulmalıdır. Configuration drift otomasyonla engellenmelidir.

Load Balancer

Load balancer kullanıcı endpoint'ini birden fazla backend'e dağıtır. Health check başarısız instance'ı trafiğe kapatır. Model-aware routing farklı backend'lerin farklı model barındırmasına izin verir. Sticky session çoğu stateless inference çağrısında zorunlu olmayabilir. Streaming connection desteği test edilmelidir.

Model Bazlı Sunucu Havuzları

Küçük hızlı modeller bir GPU havuzunda, büyük reasoning modelleri başka havuzda tutulabilir. Gateway model adına göre uygun pool'a request gönderir. Bu yapı büyük modelin bütün GPU kaynaklarını etkilemesini önler. Capacity her pool için ayrı izlenir. Kritik model için daha fazla replica çalıştırılabilir.

Ollama'dan vLLM'e Migration

Concurrency ve throughput ihtiyacı Ollama mimarisinin üzerinde olduğunda vLLM değerlendirilebilir. İstemciler doğrudan Ollama API'ye sıkı bağlı değilse migration daha kolay olur. AI gateway backend adapter değişikliğini gizleyebilir. Aynı model benchmark ve response compatibility testi yapılmalıdır. Migration nedeni ve beklenen performans kazancı gerçek metriklerle doğrulanmalıdır.

Load Balancing Stratejileri

LLM load balancing normal web servisinden farklı olarak model varlığı ve GPU durumunu da dikkate alabilir. Round robin basit başlangıçtır ancak backend'lerin yükü eşit değilse verimsiz olabilir. Least connections aktif streaming request sayısına göre daha iyi denge sağlayabilir. Model-aware ve GPU-aware routing daha gelişmiş production sistemlerinde avantaj sunar. Health check ve failover bütün stratejilerin temelidir.

Round Robin

Round robin istekleri sırayla backend instance'lara gönderir. Backend'ler aynı GPU ve model kapasitesine sahipse basit ve etkili olabilir. Uzun ve kısa request süreleri çok farklıysa yük zamanla dengesizleşebilir. Model cache durumu da hesaba katılmaz. Küçük homojen cluster için başlangıç stratejisi olabilir.

Least Connections

Least connections daha az aktif bağlantısı olan backend'i seçer. Streaming LLM request'lerinde connection süresi uzun olduğu için round robin'e göre daha dengeli olabilir. Ancak iki request'in token yükü eşit olmayabilir. GPU utilization metriği eklenirse daha doğru karar verilebilir. Load balancer'ın connection state'i doğru izlemesi gerekir.

Model-Aware Routing

Model-aware routing request'teki model adına göre yalnızca ilgili artifact'i barındıran instance'lara yönlendirir. Böylece her sunucuda bütün modelleri tutmak gerekmez. Model load thrashing azalabilir. Gateway model registry'den backend mapping bilgisi alabilir. Instance unhealthy olduğunda aynı modeli taşıyan başka node'a failover yapılmalıdır.

GPU-Aware Routing

GPU-aware routing utilization, VRAM ve queue bilgisine göre backend seçer. Daha boş GPU yeni request alır. Metric'in gerçek zamanlı güncellenmesi gerekir. Routing kararının kendisi çok karmaşık hale getirilmemelidir. Büyük cluster'larda scheduler yaklaşımı daha uygun olabilir.

Health Check

Health check backend'in yalnızca TCP portunu değil inference readiness durumunu değerlendirmelidir. Model yüklenmemiş instance kısa süre unhealthy kalabilir. Deep check çok sık yapılırsa gereksiz GPU kullanır. Basit readiness endpoint daha verimli olabilir. Health state load balancer tarafından hızlı güncellenmelidir.

Failover

Failover backend arızasında request'leri başka instance'a taşır. Streaming başladıktan sonra aynı response'u başka node'da kaldığı yerden devam ettirmek çoğu sistemde mümkün değildir. İstemci yeniden request göndermek zorunda kalabilir. Retry idempotency ve duplicate işlem riskleri dikkate alınmalıdır. Kritik uygulamalar fallback model seçeneği sunabilir.

Response Cache Kullanılmalı mı?

Response cache aynı prompt ve aynı model sonucu tekrar kullanıldığında inference maliyetini azaltabilir. Ancak chat, kullanıcı context'i ve hassas veri içeren sistemlerde cache tasarımı dikkat gerektirir. Exact cache yalnızca birebir aynı request için güvenli başlangıçtır. Cache key model version ve generation parameter'larını içermelidir. Kullanıcı verisi cache'e yazılıyorsa access control ve retention uygulanmalıdır.

Exact Cache

Exact cache request body veya normalize edilmiş prompt'un birebir eşleşmesine dayanır. Aynı deterministic görev tekrarlandığında iyi sonuç verir. Temperature yüksek chat cevabında aynı response'u dönmek kullanıcı beklentisine uymayabilir. Kullanıcı identity'si sonucu etkiliyorsa cache scope buna göre ayrılmalıdır. RAG retrieval sonucu değiştiğinde cache invalidate edilmelidir.

Redis

Redis düşük latency cache katmanı olarak kullanılabilir. Cache key hashed prompt ve model metadata içerebilir. Hassas response storage policy Redis için de geçerlidir. Encryption ve network access uygulanmalıdır. TTL gereksiz uzun veri saklamayı önler.

Cache Key Tasarımı

Cache key yalnızca prompt text'ten oluşmamalıdır. Model version, system prompt, temperature, retrieval version ve kullanıcı permission context'i sonucu değiştirebilir. Eksik key alanı yanlış kullanıcıya yanlış veya yetkisiz response dönmesine yol açabilir. Key versioning schema değişikliğini yönetir. Tasarım güvenlik review'dan geçirilmelidir.

Model Versiyonunun Cache Key'e Eklenmesi

Model update aynı prompt için farklı cevap üretebilir. Version key'de yoksa eski response yeni model kullanılıyormuş gibi dönebilir. Exact digest veya deployment version cache key'e eklenmelidir. Model promotion yeni namespace oluşturarak doğal invalidation sağlayabilir. Eski cache TTL sonrası temizlenebilir.

Cache Invalidation

RAG dokümanı veya system prompt değiştiğinde eski cache geçersiz hale gelebilir. Invalidation event deployment veya document index update ile tetiklenebilir. TTL tek başına bazı kritik senaryolarda yetersizdir. Cache key version bump basit çözüm olabilir. Invalidation stratejisi geliştirme aşamasında tasarlanmalıdır.

Hassas Verilerin Cache Riskleri

Cache kullanıcıya özel hassas response tutabilir. Yanlış key tasarımı başka kullanıcıya bu içeriği döndürebilir. Çok hassas endpoint'lerde cache tamamen kapatılabilir. Encryption at rest ve network isolation uygulanmalıdır. Retention mümkün olduğunca kısa tutulmalıdır.

Streaming ile Cache Trade-Off'u

Streaming response'u cache'e yazmak response tamamlanana kadar ek yönetim gerektirir. Kullanıcı ilk token'ı beklemeden görürken cache arka planda birikebilir. Yarım kalan response cache'e alınmamalıdır. Cached response da streaming taklidiyle iletilebilir ancak uygulama karmaşıklığı artar. Cache faydası gerçek tekrar oranı düşükse buna değmeyebilir.

High Availability ve Disaster Recovery

Production LLM servisi kritik iş süreçlerinde kullanılıyorsa tek GPU sunucusuna bağımlı kalmak risklidir. Health check, automatic restart ve ikinci instance temel availability önlemleridir. GPU arızası fiziksel değişim gerektirebileceği için spare kapasite veya başka node planlanmalıdır. Model storage ve configuration backup recovery süresini kısaltır. RTO ve RPO iş sahipleriyle birlikte belirlenmelidir.

Health Check

HA sistemi instance health durumunu sürekli izlemelidir. Backend cevap vermediğinde load balancer trafiği başka node'a yönlendirir. Model ready değilse instance healthy kabul edilmemelidir. GPU driver hataları özel health sinyali oluşturabilir. Failover testleri periyodik olarak yapılmalıdır.

Automatic Restart

Process crash veya container exit durumunda automatic restart servis kesintisini azaltır. Fakat tekrar eden crash alert olmadan sonsuz restart döngüsünde kalmamalıdır. Model load süresi restart sonrası readiness gecikmesi oluşturur. İkinci instance bu sürede trafiği taşıyabilir. Root cause daha sonra loglardan incelenmelidir.

İkinci Ollama Instance

İkinci instance tek sunucu arızasına karşı temel redundancy sağlar. Aynı model version ve configuration otomasyonla dağıtılmalıdır. Load balancer iki instance arasında trafik paylaştırabilir. Maintenance sırasında biri devre dışı bırakılıp diğeri hizmet vermeye devam edebilir. Gerçek failover kapasitesinin peak traffic'i taşıyıp taşımadığı test edilmelidir.

GPU Arızası

GPU hardware veya driver arızası inference servisinin tamamen durmasına neden olabilir. Monitoring ECC error, temperature ve driver reset olaylarını izleyebilir. Cluster içinde başka GPU node varsa otomatik failover yapılabilir. Tek sunucu ortamında spare GPU veya replacement SLA planlanmalıdır. Kritik sistem için cloud burst veya alternatif API fallback ayrıca değerlendirilebilir.

Model Storage Backup

Public model artifact internal registry'den tekrar indirilebiliyorsa full backup zorunlu olmayabilir. Fine-tuned veya özel model için backup kritiktir. Backup digest ile doğrulanmalı ve restore testi yapılmalıdır. Çok büyük artifact storage maliyetini artırır. Retention model version policy'yle uyumlu olmalıdır.

Configuration Backup

Nginx, gateway, model routing ve environment configuration version control altında tutulmalıdır. Secret değerler repository dışında güvenli secret manager'da bulunmalıdır. Infrastructure as Code yeni sunucuyu hızlı yeniden oluşturmayı sağlar. Backup tek başına restore sürecini garanti etmez. Disaster recovery tatbikatı belirli aralıklarla yapılmalıdır.

RTO ve RPO

RTO servisin ne kadar sürede geri gelmesi gerektiğini, RPO ise ne kadar veri kaybının kabul edilebileceğini belirler. Stateless inference için RPO düşük öneme sahip olabilir. Conversation history ve RAG database farklı RPO gereksinimine sahip olabilir. Business owner bu hedefleri belirlemelidir. Mimari yatırım seviyesi bu değerlerle ilişkilendirilmelidir.

Ollama, Llama ve Qwen İçin Maliyet Nasıl Hesaplanır?

Yerel LLM maliyeti yalnızca GPU fiyatından oluşmaz. Sunucu, elektrik, storage, soğutma, operasyon ve bakım maliyeti toplam sahip olma maliyetine eklenmelidir. Kullanıcı sayısı ve token hacmi üzerinden efektif maliyet hesaplanabilir. GPU düşük kullanımda çalışıyorsa token başına maliyet beklenenden yüksek çıkabilir. Cloud API ile break-even analizi gerçek production trafik tahmini üzerinden yapılmalıdır.

GPU Donanım Maliyeti

GPU maliyeti model boyutu ve gerekli VRAM'e göre büyük farklılık gösterir. Küçük model tek tüketici sınıfı GPU'da çalışabilirken Llama 4 Maverick gibi büyük artifact'ler çok daha güçlü altyapı gerektirir. Ollama kütüphanesinde Maverick Q4 paketinin yaklaşık 245 GB olduğu görülmektedir. Bu seviyede yalnızca GPU değil sunucu platformu da maliyeti yükseltir. Model kalitesi bu yatırıma değip değmediği benchmark ile kanıtlanmalıdır.

Sunucu Maliyeti

GPU dışında CPU, RAM, motherboard, PSU ve network kartları toplam sunucu maliyetini oluşturur. Multi-GPU sistemde chassis ve power kapasitesi daha yüksek olmalıdır. Enterprise warranty ve support ek maliyet getirebilir. Rack alanı ve data center hizmeti varsa hesaba katılmalıdır. Üç veya beş yıllık amortisman üzerinden yıllık maliyet hesaplanabilir.

Elektrik

GPU yoğun inference ciddi enerji tüketebilir. Ortalama power draw monitoring verisinden ölçülebilir. Elektrik fiyatı ve cooling overhead toplam maliyete eklenmelidir. Gece düşük kullanımda model sunucusunun nasıl çalışacağı policy ile belirlenebilir. Enerji verimliliği daha küçük model seçiminde önemli avantaj sağlayabilir.

Storage

Birden fazla quantization ve model version saklamak hızla yüzlerce GB veya TB seviyesine çıkabilir. NVMe model load performansını artırırken maliyeti daha yüksektir. Internal registry ve backup storage ayrıca hesaplanmalıdır. Deprecated artifact retention süresi gereksiz storage büyümesini önler. Disk doluluk alert'i model pull hatalarını önceden gösterir.

Operasyon ve Bakım

Platform ekibinin kurulum, monitoring, update ve incident için harcadığı zaman gerçek maliyettir. Model benchmark ve security review da operasyon yüküne dahildir. Çok sayıda farklı model desteklemek support maliyetini artırır. Standart model katalogu bu yükü azaltabilir. Kendi inference sisteminiz varsa sorumluluğu da size ait olur.

Kullanıcı Başına Maliyet

Aylık toplam altyapı ve operasyon maliyeti aktif kullanıcı sayısına bölünerek kaba kullanıcı maliyeti hesaplanabilir. Ancak bazı kullanıcılar diğerlerinden çok daha fazla token tüketebilir. Departman veya use-case bazlı cost allocation daha doğru olabilir. GPU utilization düşükse kullanıcı başına maliyet artar. Pilot sonrası gerçek kullanım dağılımı hesaplamayı iyileştirir.

Token Başına Efektif Maliyet

Toplam aylık maliyet işlenen toplam token miktarına bölünerek efektif token maliyeti çıkarılabilir. Input ve output token maliyetini ayrı değerlendirmek daha ayrıntılı model sağlar. GPU boş kaldığı süre de toplam maliyete dahil olduğu için utilization önemli etkendir. Quantization throughput artışı token maliyetini düşürebilir. Model kalite farkı ekonomik metriğin yanında tutulmalıdır.

Cloud API ile Break-Even Analizi

Break-even analizi yerel altyapının toplam maliyetini aynı iş yükünün cloud API maliyetiyle karşılaştırır. Düşük kullanımda cloud daha ekonomik olabilir. Yüksek ve sürekli kullanımda local inference avantaj sağlayabilir. Veri güvenliği ve latency gibi finansal olmayan faktörler de karara dahil edilmelidir. Hesap model API fiyatlarının ve hardware maliyetinin zamanla değişebileceğini dikkate almalıdır.

Open Source ve İşbirliği Ekosistemi

Yerel LLM altyapısı yalnızca Ollama'dan oluşmaz. Llama ve Qwen model ekosistemi, Hugging Face, llama.cpp, Open WebUI ve LiteLLM gibi projeler farklı katmanlarda rol oynayabilir. Bu araçlar model dağıtımı, arayüz, gateway ve inference seçeneklerini genişletir. Kurum açık kaynak bileşenleri kullanırken version, license ve security süreçlerini yönetmelidir. Topluluk katkısı ve kurumsal destek ihtiyacı kullanım kritikliğine göre değerlendirilmelidir.

Ollama

Ollama yerel model deneyimini kolaylaştıran merkezi çalışma katmanı olarak kullanılabilir. Model catalog ve API geliştirici onboarding süresini kısaltır. Küçük ekip pilotlarında operasyon sadeliği değerlidir. Production büyüdükçe gateway, monitoring ve load balancing eklenmelidir. Açık kaynak ekosistemde issue ve contribution takibi platform kararına katkı sağlar.

Llama Ekosistemi

Llama etrafında model fine-tuning, quantization ve inference araçlarından oluşan geniş bir ekosistem vardır. Community benchmark ve kullanım örnekleri model değerlendirmesinde başlangıç noktası sağlar. Ancak production kararı yalnızca topluluk yorumuna dayanmaz. Resmi lisans ve model kartı ayrıca incelenmelidir. Kurum kendi regression dataset'ini her durumda korumalıdır.

Qwen Ekosistemi

Qwen ailesi farklı boyut, coder ve multimodal seçenekleriyle geniş bir kullanım alanı sunar. Ollama kütüphanesinde Qwen3, Qwen3.5 ve Qwen3 Coder gibi farklı aileler bulunur. Bu çeşitlilik routing ve görev bazlı model seçimi için avantajdır. Model sayısını kontrolsüz artırmak benchmark ve operasyon yükünü büyütebilir. Approved catalog yaklaşımı yine önemlidir.

Hugging Face

Hugging Face model ve dataset dağıtım ekosisteminde yaygın kullanılan platformlardan biridir. Kurum model artifact kaynağını ve uploader kimliğini doğrulamalıdır. Community model ile resmi organization repository'si aynı güven seviyesinde kabul edilmemelidir. Air-gapped ortamda Hugging Face doğrudan production'dan erişilmez. Model önce güvenli staging ortamında incelenip internal registry'ye alınabilir.

llama.cpp

llama.cpp özellikle GGUF ve yerel inference ekosisteminde önemli projelerden biridir. CPU ve farklı hardware üzerinde model çalıştırma seçenekleri sunar. Ollama'nın altında veya alternatif yerel serving yaklaşımında teknolojik rol oynayabilir. Kurum doğrudan llama.cpp kullanmayı seçerse daha fazla runtime configuration sorumluluğu üstlenebilir. Benchmark iki serving seçeneğinin gerçek performansını karşılaştırmalıdır.

Open WebUI

Open WebUI kullanıcı arayüzü katmanında çalışanların yerel modellere kolay erişimini sağlar. Model management ve conversation özellikleri kullanıcı deneyimini iyileştirebilir. Kurumsal SSO, retention ve network güvenliği ayrıca tasarlanmalıdır. Uygulama bağımlılıkları düzenli güncellenmelidir. UI ile inference backend aynı güvenlik alanı olarak kabul edilmemelidir.

LiteLLM

LiteLLM gibi gateway ve compatibility araçları farklı model backend'lerini ortak API üzerinden sunmak için kullanılabilir. Bu yaklaşım backend migration ve model routing'i kolaylaştırabilir. Kullanılacak özelliklerin security ve latency etkisi pilot ortamda ölçülmelidir. Gateway yeni kritik bileşen olduğu için authentication ve availability tasarımı önemlidir. Model provider abstraction vendor bağımlılığını azaltabilir.

Açık Kaynak Projelere Kurumsal Katkı

Kurum yalnızca açık kaynak tüketicisi olmak zorunda değildir. Bulunan bug, dokümantasyon iyileştirmesi veya integration geliştirmesi upstream projeye katkı olarak gönderilebilir. Güvenlik bulguları responsible disclosure süreciyle paylaşılmalıdır. Açık kaynak katkısı şirket içi mühendislerin platformu daha iyi anlamasını sağlar. Contribution policy ve fikri mülkiyet süreci önceden tanımlanmalıdır.

Community Support ve Enterprise Support

Community support hızlı öğrenme ve yaygın sorunlar için değerlidir. Kritik production servisinde yalnızca forum yanıtına bağlı kalmak riskli olabilir. İşletme kendi iç platform uzmanlığını geliştirmeli veya uygun profesyonel destek modeli oluşturmalıdır. RTO hedefi support beklentisini belirler. Kurumsal Ollama Llama Qwen kurulumu ve on-premise LLM entegrasyon hizmeti seçerken yalnızca kurulum değil operasyon ve güvenlik tecrübesi de değerlendirilmelidir.

Pilot Ortamdan Production'a Geçiş Yol Haritası

Başarılı şirket içi LLM projesi doğrudan yüz kullanıcıyla başlamaz. Önce net kullanım senaryosu belirlenir, gerçek Türkçe prompt dataset'i hazırlanır ve Llama ile Qwen modelleri benchmark edilir. Ardından GPU kapasitesi hesaplanıp güvenli Ollama pilotu kurulur. Reverse proxy, SSO, cloud kapatma, quota ve monitoring tamamlandıktan sonra 10 ile 20 kullanıcıyla pilot yapılır. Gerçek kapasite verisi toplandıktan sonra production rollout kademeli biçimde genişletilir.

1. Kullanım Senaryosunu Belirleyin

İlk adım “şirkette AI kullanalım” gibi geniş hedef yerine ölçülebilir kullanım senaryosu seçmektir. Doküman soru cevap, teknik destek veya kod yardımı gibi tek alanla başlanabilir. Kullanıcı grubu ve başarı kriteri belirlenmelidir. Hangi verilerin modele gönderileceği çıkarılmalıdır. Güvenlik ve maliyet değerlendirmesi bu kapsam üzerinden yapılır.

2. Gerçek Türkçe Prompt Dataset'i Oluşturun

Gerçek prompt dataset'i model seçiminin en önemli girdilerindendir. Hassas bilgi temizlenerek farklı kullanıcı tiplerinden örnekler toplanabilir. Her prompt için beklenen davranış veya scoring rubric hazırlanmalıdır. Dataset versionlanmalıdır. Yeni model her zaman aynı set üzerinde yeniden değerlendirilebilir.

3. Llama ve Qwen Modellerini Benchmark Edin

En az birkaç model boyutu ve quantization seçeneği aynı dataset üzerinde test edilmelidir. Quality, TTFT, throughput ve VRAM birlikte ölçülmelidir. Model adı değerlendiren kullanıcıya gizlenebilir. Sonuç iş birimiyle birlikte puanlanmalıdır. En büyük model otomatik kazanan kabul edilmemelidir.

4. GPU Kapasitesini Hesaplayın

Seçilen modelin weight, context ve concurrency profili load test ile ölçülmelidir. Tek kullanıcı memory değeri production kapasitesi değildir. Peak concurrency tahmini pilot kullanıcı davranışına göre oluşturulabilir. Headroom bırakılmalıdır. Hardware purchase benchmark tamamlandıktan sonra yapılmalıdır.

5. Ollama Pilot Sunucusunu Kurun

Pilot production'a benzeyen güvenlik sınırında kurulmalıdır. Model server ve gateway ayrımı baştan yapılırsa ileride yeniden mimari kurmak gerekmez. Başlangıçta tek GPU yeterli olabilir. Infrastructure configuration version control altında tutulmalıdır. Model artifact ve runtime version pinlenmelidir.

6. Reverse Proxy Ekleyin

Kullanıcıların ham 11434 portuna bağlanmasını engelleyin. Nginx veya uygun gateway üzerinden HTTPS endpoint sunun. Request limit ve timeout değerlerini LLM workload'a göre ayarlayın. Backend yalnızca proxy'den erişilebilir olmalıdır. Streaming davranışını test edin.

7. SSO / Authentication Ekleyin

Pilot bile olsa gerçek kullanıcı kimliği kullanılmalıdır. SSO mevcut şirket identity sistemiyle entegre edilmelidir. Grup bilgisi model erişimine bağlanabilir. Shared account kullanımından kaçınılmalıdır. Audit log kullanıcı kimliğini kaydetmelidir.

8. Cloud Özelliklerini Kapatın

Local-only kullanım hedefleniyorsa cloud bağlantıları kapatılmalıdır. Configuration yanında outbound firewall uygulanmalıdır. DNS ve network log üzerinden dış trafik testi yapılmalıdır. Model güncellemesi ayrı management workflow'a taşınabilir. Bu kontrol security review'da belgelenmelidir.

9. Rate Limit ve Quota Ekleyin

Pilot kullanıcıların kaynak tüketimi sınırsız olmamalıdır. User ve service account bazında farklı limit uygulanabilir. Context ve output token üst sınırı tanımlanabilir. Quota olayları loglanmalıdır. Gerçek kullanım kapasite hesabının girdisi olur.

10. Monitoring Kurun

GPU utilization, VRAM, TTFT, queue ve error metrikleri ilk günden toplanmalıdır. Kullanıcı geri bildirimi teknik metric ile ilişkilendirilebilir. Dashboard model version bilgisi göstermelidir. Alert threshold pilot sırasında ayarlanabilir. Monitoring olmadan capacity planning tahmine dönüşür.

11. Security Review Yapın

Authentication bypass, network exposure, management endpoint ve RAG ACL test edilmelidir. Prompt log politikası gözden geçirilmelidir. Model source ve lisans kayıtları doğrulanmalıdır. Outbound traffic ayrıca kontrol edilmelidir. Kritik açıklar kapatılmadan gerçek kullanıcı pilotuna geçilmemelidir.

12. 10–20 Kullanıcılık Pilot Başlatın

Küçük kullanıcı grubu sistemi gerçek iş akışında dener. Farklı departmanlardan temsilci seçmek kullanım çeşitliliği sağlar. Kullanıcılar model kalite ve hızını puanlayabilir. Support ticket ve error kayıtları toplanmalıdır. Bu dönem production mimarisinin en değerli veri kaynağıdır.

13. Kapasite Ölçümü Yapın

Pilot sonunda peak concurrency, token hacmi ve GPU utilization hesaplanır. P95 TTFT ve queue davranışı kullanıcı memnuniyetiyle karşılaştırılır. 50 veya 100 kullanıcıya ölçek tahmini gerçek veriden yapılır. Yeni GPU veya instance ihtiyacı hesaplanır. Tahmin üzerine hardware almak yerine ölçüme dayalı karar verilir.

14. Production Rollout Yapın

Production rollout kullanıcı grubunu kademeli artırmalıdır. İlk aşamada tek departman, ardından diğer ekipler eklenebilir. Her büyüme adımında capacity ve error rate izlenir. Model ve gateway rollback planı hazır tutulur. Kullanıcı politikası ve eğitim dokümanı rollout ile birlikte yayınlanmalıdır.

En Sık Yapılan Hatalar

Şirket içi Ollama kurulumlarında en yaygın hata çalışan bir demo ile güvenli production servisini aynı şey sanmaktır. 11434 portunu bütün LAN'a açmak, authentication kullanmamak ve prompt loglarını kontrolsüz saklamak ciddi risk oluşturur. Diğer sık hata model seçimini yalnızca parametre sayısına göre yapmak ve Türkçe benchmark çalıştırmamaktır. Context ile concurrency hesaplanmadığında GPU kapasitesi beklenenden erken dolar. Production başarı için network, identity, model lifecycle ve monitoring aynı tasarım içinde ele alınmalıdır.

11434 Portunu Tüm Şirket Ağına Açmak

Ham Ollama portunu bütün şirkete açmak gateway kontrolünü bypass edilebilir hale getirir. Kullanıcılar authentication ve quota olmadan inference yapabilir. Management endpoint'ler de beklenmedik şekilde erişilebilir olabilir. Port yalnızca reverse proxy veya güvenilir backend subnet'ten erişilebilir olmalıdır. Kullanıcıya 443 üzerinden HTTPS endpoint sunmak daha doğru tasarımdır.

Authentication Olmadan Kullanıma Sunmak

İç network güvenilir kullanıcı kimliği anlamına gelmez. Compromised cihaz veya yanlış VLAN erişimi servisi kullanabilir. SSO veya API key uygulanmalıdır. Kullanıcı kimliği audit ve quota için gereklidir. Backend portu authentication katmanını bypass edememelidir.

“İç Ağdayız, TLS Gerekmiyor” Demek

İç ağda da prompt ve response hassas veri taşıyabilir. Düz HTTP trafik ağ erişimi olan taraflarca gözlemlenebilir. TLS internal CA ile uygulanabilir. Sertifika dağıtımı merkezi cihaz yönetimi üzerinden yapılabilir. Şifreleme internet trafiğine özel bir gereksinim değildir.

Herkese Model Pull/Delete Yetkisi Vermek

Model pull storage ve supply-chain riski oluşturur. Delete aktif servisi bozabilir. Normal kullanıcının bu işlemlere ihtiyacı yoktur. AI Administrator rolü ayrılmalıdır. Management network ayrıca izole edilmelidir.

Modeli Sadece Parametre Sayısına Göre Seçmek

Daha büyük parametre sayısı her görevde daha iyi iş sonucu garanti etmez. Latency ve GPU maliyeti de artabilir. Küçük model belirli extraction veya classification işini daha ekonomik çözebilir. Gerçek benchmark yapılmalıdır. Quality per cost temel karar metriği olabilir.

Türkçe Benchmark Yapmamak

Genel İngilizce benchmark şirketin Türkçe kullanımını temsil etmez. Ek yapısı, yerel terimler ve resmi dil farklı sonuç üretir. Gerçek Türkçe prompt dataset'i oluşturulmalıdır. İnsan değerlendirmesi eklenmelidir. Her model update aynı benchmark'tan geçmelidir.

Context Window'u Gereksiz Yere Çok Yüksek Tutmak

Maksimum context destekleniyor diye her kullanıcıya vermek gerekli değildir. KV cache memory hızla artar. Concurrency düşebilir ve TTFT uzayabilir. RAG daha ilgili küçük context seçebilir. Gerçek kullanım dağılımına göre limit belirlenmelidir.

Paralel Kullanıcı Sayısını VRAM Hesabına Katmamak

Tek request ile modelin GPU'ya sığması production kapasitesini göstermez. Her eşzamanlı context ek memory kullanabilir. Load test 5, 10 ve 20 kullanıcıyla yapılmalıdır. OOM sınırından önce güvenli headroom bırakılmalıdır. P95 latency de kapasite kriteridir.

Model Tag'lerini Pinlememek

Latest tag gelecekte farklı artifact'e işaret edebilir. Benchmark edilen ile production modeli ayrışabilir. Digest veya immutable version kullanılmalıdır. Rollback için eski version saklanmalıdır. Deployment log exact model identity göstermelidir.

Yeni Modeli Test Etmeden Güncellemek

Yeni model bazı görevlerde regression oluşturabilir. Tool calling veya JSON output davranışı değişebilir. Lisans şartları da farklı olabilir. Candidate model staging benchmark'tan geçmelidir. Canary rollout başarılı olmadan bütün kullanıcılar taşınmamalıdır.

Rollback Planı Olmaması

Model update sonrası latency veya kalite sorunu çıkabilir. Eski artifact silindiyse dönüş zorlaşır. Gateway önceki route'a hızlı geçebilmelidir. Configuration ve model digest versionlanmalıdır. Rollback prosedürü düzenli test edilmelidir.

Prompt'ları Kontrolsüz Loglamak

Prompt logları müşteri, çalışan ve şirket bilgisi içerebilir. Debug amacıyla bütün içeriği süresiz saklamak gereksiz risk yaratır. Metadata-only logging tercih edilebilir. Gerekli içerik redaction ve kısa retention ile tutulmalıdır. Log erişimi sınırlandırılmalıdır.

Ollama Cloud Özelliklerini Açık Bırakmak

Local-only politika hedefleniyorsa cloud ve dış web özellikleri açık bırakılmamalıdır. Configuration ile kapatma yapılmalıdır. Egress firewall ikinci güvenlik katmanı sağlar. Network log gerçek davranışı doğrulamalıdır. Model update ayrı controlled network üzerinden yapılabilir.

Monitoring Olmadan Production'a Çıkmak

Monitoring yoksa kullanıcı şikayeti geldiğinde sorunun GPU, queue veya network kaynaklı olduğu bilinemez. TTFT ve VRAM baştan izlenmelidir. Capacity planning tahmin yerine metrik kullanmalıdır. Error ve model load time alarm oluşturabilir. Dashboard production operasyonunun zorunlu parçasıdır.

Ollama'yı Her Ölçekte Kullanmakta Israr Etmek

Ollama pilot ve orta ölçekli kullanımda güçlü araç olabilir. Çok yüksek throughput veya distributed serving ihtiyacı oluştuğunda farklı inference engine değerlendirmek normaldir. vLLM gibi seçenekler benchmark edilebilir. Gateway backend soyutlaması migration'ı kolaylaştırır. Araç seçimi kullanıcı yüküne göre değişmelidir.

Sık Sorulan Sorular

Şirket içi Ollama projelerinde sorular genellikle ağ erişimi, model seçimi, GPU kapasitesi ve güvenlik etrafında toplanır. Aşağıdaki cevaplar production tasarımında en çok karşılaşılan kararları kısa biçimde özetler. Donanım gereksinimi konusunda tek bir kullanıcı sayısından kesin GPU sonucu çıkarılamayacağını özellikle vurgulamak gerekir. Context, model boyutu ve concurrency gerçek ihtiyacı belirler. Ollama ile Llama ve Qwen Modellerini Şirket İçi Ağda Çalıştırmak isteyen ekipler önce küçük pilotla ölçüm yaparak ilerlemelidir.

Ollama şirket içi ağda kullanılabilir mi?

Evet, Ollama şirketin kontrol ettiği sunucuda çalıştırılıp internal network üzerinden servis edilebilir. Ancak ham portu bütün LAN'a açmak yerine reverse proxy kullanılması daha güvenlidir. HTTPS, authentication ve rate limit uygulanmalıdır. Model management endpoint'leri normal kullanıcıdan ayrılmalıdır. Outbound network politikası veri güvenliği ihtiyacına göre sınırlandırılmalıdır.

Ollama'yı başka bilgisayarlara nasıl açarım?

Ollama host binding ayarı localhost dışındaki gerekli interface'e genişletilebilir. Firewall yalnızca belirli kaynak IP veya gateway'e izin vermelidir. Production'da kullanıcı doğrudan bu porta bağlanmamalıdır. Nginx veya AI gateway HTTPS endpoint sunmalıdır. Başka bir istemciden curl ile bağlantı ve yetkisiz erişim testi birlikte yapılmalıdır.

Ollama hangi portu kullanır?

Ollama yerel API için varsayılan olarak 11434 portunu kullanır. Bu port geliştirme ortamında localhost üzerinden kullanılabilir. Şirket içinde backend portu olarak tutulması daha uygundur. Kullanıcı endpoint'i standart HTTPS 443 üzerinden sunulabilir. Firewall 11434 erişimini yalnızca gateway ve yönetim sistemleriyle sınırlandırmalıdır.

Ollama'da authentication var mı?

Kurumsal kullanıcı authentication'ı ayrı reverse proxy veya gateway katmanında tasarlanmalıdır. API key, Basic Authentication, OAuth2 veya OIDC seçenekleri kullanılabilir. Mevcut SSO ve Active Directory entegrasyonu çalışan yönetimini kolaylaştırır. Backend Ollama portu kullanıcıların gateway'i bypass edemeyeceği şekilde kapatılmalıdır. Model yetkilendirmesi authentication sonrasında ayrıca uygulanmalıdır.

Ollama internet olmadan çalışır mı?

Gerekli yazılım ve model artifact'leri önceden hazırlandıysa Ollama internet erişimi olmadan inference yapabilir. Modelin ilk kez indirilmesi için ayrı bağlantılı ortam kullanılabilir. Air-gapped sistemde artifact kontrollü transfer edilir. Hash ve lisans doğrulaması yapılmalıdır. Update süreci internal registry üzerinden yönetilebilir.

Ollama verileri dışarı gönderir mi?

Yerel inference tasarımında prompt'lar yerel Ollama sunucusunda işlenebilir. Ancak gerçek veri akışını kullanılan cloud özellikleri, web entegrasyonları ve yardımcı servisler belirler. “Dışarı veri gitmiyor” ifadesi configuration ve network log ile doğrulanmalıdır. Outbound firewall doğrudan kontrol sağlayabilir. Prompt loglarının başka monitoring servisine aktarılıp aktarılmadığı da incelenmelidir.

Ollama Cloud tamamen kapatılabilir mi?

Local-only politika için cloud özellikleri kapatılabilir ve sunucu egress firewall ile internete erişemez hale getirilebilir. Uygulama ayarı ile network policy birlikte kullanılmalıdır. Model güncellemesi ayrı yönetim ortamından internal repository'ye alınabilir. Web search benzeri dış bağlantı gerektiren özellikler de kapatılmalıdır. DNS ve firewall logları davranışı doğrulamalıdır.

Llama mı Qwen mi daha iyi?

Tek bir model ailesi bütün kullanım senaryolarında daha iyi değildir. Llama ve Qwen gerçek şirket prompt'ları üzerinde benchmark edilmelidir. Türkçe kalite, kodlama, structured output ve latency ayrı puanlanmalıdır. GPU maliyeti sonuçla birlikte değerlendirilmelidir. En küçük kabul edilebilir model genellikle daha ekonomik production seçeneğidir.

Türkçe için Llama mı Qwen mi tercih edilmeli?

Türkçe için marka adına göre kesin seçim yapmak yerine şirket dataset'i üzerinde test yapılmalıdır. Qwen aileleri geniş çok dilli destek sunarken Llama'nın farklı sürümleri de güçlü genel yeteneklere sahiptir. Resmi destek listesi tek başına kurumsal Türkçe başarısını garanti etmez. Terim, akıcılık, hallucination ve instruction following puanlanmalıdır. Model seçimi blind insan değerlendirmesiyle desteklenebilir.

Qwen3.5 Ollama'da çalışır mı?

Evet, Qwen3.5 Ollama kütüphanesinde doğrudan listelenmektedir. Ollama sayfasında 0.8B, 2B, 4B, 9B, 27B, 35B ve 122B seçenekleri bulunmaktadır. Model ailesi text ve image kullanımını destekleyen multimodal seçenek olarak sunulmaktadır. Hangi varyantın şirket sunucusuna uygun olduğu GPU ve benchmark sonucuna bağlıdır. Production version digest ile sabitlenmelidir.

Llama 4 Ollama'da çalışır mı?

Evet, Llama 4 Ollama kütüphanesinde Scout ve Maverick varyantlarıyla bulunmaktadır. Ollama model kartı Scout'u 109B toplam, 17B aktif parametreli; Maverick'i 400B toplam, 17B aktif parametreli MoE model olarak tanımlar. Scout Q4 paketi yaklaşık 67 GB, Maverick Q4 paketi yaklaşık 245 GB listelenmektedir. Bu nedenle özellikle Maverick güçlü multi-GPU veya yüksek bellekli altyapı gerektirebilir.

Tek sunucuda Llama ve Qwen aynı anda çalışabilir mi?

Evet, aynı Ollama sunucusunda birden fazla model tutulabilir. Aynı anda bellekte bulunmaları toplam VRAM ihtiyacını artırır. Keep alive ve loaded model policy ile kullanım yönetilebilir. Donanım yetmiyorsa modeller farklı GPU veya sunuculara ayrılabilir. Gateway task-based routing ile doğru backend'i seçebilir.

20, 50 veya 100 kullanıcı için ne kadar GPU gerekir?

Kullanıcı sayısından tek başına kesin GPU hesabı yapılamaz. Gerçek concurrent request, model size, quantization, context length ve output token miktarı gereksinimi belirler. 100 çalışan bulunan şirkette aynı anda yalnızca 5 kişi model kullanıyor olabilir. Pilot sırasında peak concurrency ölçülmelidir. GPU planı P95 latency ve peak VRAM hedefi üzerinden yapılmalıdır.

Ollama Docker ile çalıştırılmalı mı?

Docker tekrarlanabilir deployment, network isolation ve version pinning açısından güçlü avantaj sunar. Ancak zorunlu değildir. Bare-metal servis de doğru şekilde yönetilebilir. Container kullanılıyorsa GPU passthrough, persistent volume ve security scanning uygulanmalıdır. Production standardı ekibin mevcut operasyon altyapısıyla uyumlu seçilmelidir.

Open WebUI şirket içi kullanım için yeterli mi?

Open WebUI iyi bir kullanıcı arayüzü sağlar ancak tek güvenlik katmanı olarak yeterli kabul edilmemelidir. Backend portu firewall ile izole edilmelidir. SSO, TLS ve model authorization ayrıca uygulanmalıdır. Conversation history retention policy gerektirir. Reverse proxy veya AI gateway arayüzün önünde veya backend erişim yolunda kullanılmalıdır.

Ollama için Nginx neden gereklidir?

Nginx zorunlu tek seçenek değildir ancak reverse proxy olarak TLS, rate limit ve merkezi endpoint yönetimini kolaylaştırır. Kullanıcıların ham 11434 portuna erişmesini engeller. Streaming ve timeout ayarları LLM kullanımına göre düzenlenebilir. Authentication harici identity proxy ile birlikte uygulanabilir. Daha gelişmiş ihtiyaçlarda özel AI gateway tercih edilebilir.

Ollama ne zaman vLLM ile değiştirilmelidir?

Ollama yetersiz hale geldiğini concurrency ve throughput metrikleri gösterdiğinde vLLM gibi alternatifler değerlendirilmelidir. Sürekli yüksek queue, düşük GPU verimliliği veya distributed serving ihtiyacı güçlü sinyallerdir. Migration kararı benchmark ile doğrulanmalıdır. Gateway backend abstraction kullanılıyorsa istemci uygulamaları değişmeden geçiş yapılabilir. Pilot başarısından sonra ölçek büyümesi doğal platform dönüşümüdür.

Ollama ile Llama ve Qwen modelleri şirket içi ağda nasıl çalıştırılır?

İlk olarak GPU veya uygun CPU kapasitesine sahip şirket sunucusuna Ollama kurulur ve seçilen Llama veya Qwen modeli kontrollü biçimde indirilir. Ollama backend'i doğrudan çalışanlara açmak yerine localhost veya güvenilir internal interface üzerinde tutulur. Önüne Nginx veya AI gateway eklenerek HTTPS, SSO, rate limit ve audit uygulanır. Model yönetim endpoint'leri normal inference erişiminden ayrılır ve yalnızca administrator grubuna açılır. Production'a geçmeden önce Türkçe benchmark, concurrency load test, outbound network kontrolü ve model lisans değerlendirmesi tamamlanmalıdır.

Ollama sunucusuna yerel ağdaki farklı bilgisayarlardan güvenli erişim nasıl sağlanır?

En güvenli yöntem kullanıcıların 11434 portuna doğrudan bağlanmamasıdır. Internal DNS üzerinden tek bir HTTPS gateway adresi yayınlanır. Nginx veya uygun gateway kullanıcı kimliğini doğrulayıp isteği backend Ollama instance'a gönderir. Firewall ham Ollama portunu yalnızca gateway IP'sinden erişilebilir hale getirir. Bu model authentication, rate limit, TLS ve audit politikalarının atlanmasını zorlaştırır.

Llama ve Qwen modellerini şirket içinde çalıştırmak için RAM, VRAM ve GPU gereksinimleri nelerdir?

Donanım gereksinimi model parametre sayısı, quantization, context ve concurrency'ye göre değişir. Küçük 4B ile 9B quantized modeller tek orta seviye GPU'da çalışabilirken 70B üzeri veya Llama 4 gibi büyük modeller çok daha yüksek VRAM gerektirebilir. Örneğin Ollama kütüphanesinde Llama 4 Scout Q4 yaklaşık 67 GB ve Maverick Q4 yaklaşık 245 GB artifact olarak listelenmektedir. Qwen3.5 tarafında 9B yaklaşık 6.6 GB, 27B yaklaşık 17 GB, 35B yaklaşık 24 GB ve 122B yaklaşık 81 GB artifact seçenekleri bulunur. Bu dosya değerleri doğrudan VRAM ihtiyacı değildir; KV cache ve parallel requests için ek headroom mutlaka load test ile hesaplanmalıdır.

Ollama tabanlı şirket içi LLM altyapısında API erişimi, kullanıcı yetkilendirmesi ve veri güvenliği nasıl yapılandırılmalıdır?

Ollama inference backend yalnızca güvenilir gateway ağına açık tutulmalıdır. Kullanıcılar reverse proxy veya AI gateway üzerinde SSO, OAuth2/OIDC veya uygun API key mekanizmasıyla doğrulanmalıdır. RBAC ve departman grupları kullanıcının hangi modele erişebileceğini belirlemelidir. Prompt ve response logları mümkün olduğunca metadata seviyesinde tutulmalı, RAG erişimi document ACL ile sınırlandırılmalı ve outbound internet trafiği local-only gereksinimine göre firewall ile kontrol edilmelidir. Model pull ve delete gibi management işlemleri ayrı administrator rolü ve mümkünse ayrı management network üzerinden yürütülmelidir.

Ollama ile Llama ve Qwen modellerinin şirket içi kurulumu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Ollama ve yerel LLM kurulum danışmanlığı yakınımda diye araştırırken yalnızca modeli çalıştırabilen değil network güvenliği, GPU kapasitesi, RAG yetkilendirmesi ve production operasyonunu birlikte değerlendirebilen teknik yaklaşım aramak önemlidir. Diyarbakır'da yazılım ve yerel teknoloji topluluğu çalışmalarına ulaşmak için https://www.diyarbakiryazilim.com.tr/about sayfasını inceleyebilirsiniz. Güncel proje ve topluluk çalışmalarına https://www.diyarbakiryazilim.com.tr/projects adresinden ulaşabilirsiniz. Dify ve şirket içi yapay zeka orkestrasyonuna ilişkin ek uygulama içeriği için https://www.diyarbakiryazilim.com.tr/posts/ubuntu-sunucularda-dify-kurulumu-ve-yapay-zeka-orkestrasyonu sayfası da ilgili bir sonraki adım olabilir. Kurumsal Ollama Llama Qwen kurulumu ve on-premise LLM entegrasyon hizmeti değerlendirirken pilot, benchmark, güvenlik review ve kapasite ölçümünün aynı çalışma kapsamına dahil edilmesi daha sağlıklı sonuç verir.

Sonuç

Ollama ile Llama ve Qwen Modellerini Şirket İçi Ağda Çalıştırmak, şirket verisi üzerinde daha fazla kontrol ve yerel model esnekliği sağlayan güçlü bir yaklaşım olabilir. Fakat gerçek production başarısı modeli indirip 11434 portunu açmaktan değil, inference servisinin önüne doğru güvenlik ve operasyon katmanlarını koymaktan gelir. Reverse proxy, TLS, SSO, RBAC, model registry, GPU monitoring, RAG ACL, lisans kontrolü ve regression benchmark birlikte ele alındığında küçük bir pilot güvenilir kurumsal servise dönüşebilir. İlk adım olarak 10 ile 20 kullanıcıyla gerçek Türkçe prompt dataset'i üzerinde Llama ve Qwen modellerini karşılaştırmak, ardından ölçülen concurrency değerine göre GPU kapasitesi belirlemek oldukça sağlam bir yol sunar. Diyarbakır Yazılım Topluluğu ile proje, eğitim ve teknik çalışmalar hakkında bağlantı kurmak için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.