Yerel Yapay Zekâ Modeli Kurarken Donanım ve Model Dengesi

Yerel yapay zekâ denemelerinde ilk soru genellikle “Bu bilgisayar kaç milyar parametreli model çalıştırır?” oluyor. Bir iş istasyonunda model gerçekten açılmış, fakat uzun belgelerde cevap süresi uzamış, bağlam büyüdüğünde GPU kullanımı değişmiş ve eş zamanlı kullanıcı düşünülünce deneyim sürdürülemez hale gelmişti. Teknik olarak çalışmak ile iş için kullanılabilir olmak aynı sonuç değildir.

17-20 Temmuz 2026 arasında Windows ve Ollama üzerinde yaptığımız değerlendirmede model adından önce kullanım profilini tanımladık. Kod yardımı, Türkçe metin özeti, görsel anlama ve araç çağırma farklı kalite ile kaynak beklentileri taşır. Amaç laboratuvar rekoru değil; veriyi kontrollü tutan, ölçülebilir ve desteklenebilir bir yerel AI hizmeti kurmaktı.

Sorunun ortaya çıkışı

Qwen ve Gemma sınıfındaki farklı modeller denenirken katalogdaki parametre sayısı ana seçim ölçütü yapılmıştı. Daha büyük modelin her görevde daha iyi olacağı kabul ediliyor, quantization düzeyi ile bağlam uzunluğunun bellek etkisi gözden kaçıyordu. Model dosyası GPU belleğine sığsa bile KV cache, çalışma zamanı payı, görüntü bileşeni ve işletim sisteminin kullandığı kaynaklar için yeterli boşluk kalmayabiliyordu.

İş beklentileri de tek listede toplanmıştı: doküman özetleme, kod üretimi, kurum içi soru-cevap, görsel analizi ve otomasyon. Oysa bir modelin Türkçe anlatımı güçlü olabilirken araç çağırma biçimi zayıf, başka bir model kodda iyi iken uzun bağlamda yavaş olabilirdi. Önce görevleri önem, veri hassasiyeti, beklenen doğruluk ve kabul edilebilir yanıt süresine göre ayırdık.

İlk belirtiler ve yanlış varsayımlar

İlk belirti GPU kullanımının bazı isteklerde yüksek, bazılarında beklenmedik biçimde düşük olmasıydı. Bu durum hemen sürücü arızası sanıldı. Gerçekte modelin bir bölümü sistem belleğine taşınıyor, uzun bağlam veya farklı quantization nedeniyle CPU-GPU paylaşımı değişiyordu. Token üretim hızı ile ilk token gecikmesi de tek metrik sanılmıştı; kullanıcı deneyiminde ikisi farklı etkiler yaratır.

“RAM iki katına çıkarsa hız iki katına çıkar” ve “daha düşük quantization her zaman kabul edilemez kalite verir” varsayımları da ölçümle doğrulanmadı. Sistem belleği modeli çalıştırmayı mümkün kılabilir, fakat GPU belleği darboğazını otomatik olarak çözmez. Quantization etkisi modele ve göreve göre değişir. Aynı örnek kümesiyle kalite, gecikme ve kaynak tüketimi ölçülmeden katalog bilgisine dayanmak güvenilir değildir.

Teknik analiz

Model ağırlıklarının yaklaşık bellek ihtiyacı parametre sayısı ve bit genişliğiyle tahmin edilebilir; ancak bu yalnızca başlangıçtır. Çalışma zamanı ek yükü, KV cache, context window, batch büyüklüğü ve eş zamanlı oturumlar ayrıca yer tüketir. VRAM dolduğunda katmanların RAM ve CPU tarafına taşınması kapasite sağlar, fakat veri yolu ve işlem hızı nedeniyle gecikmeyi artırabilir. Ölçüm bu nedenle gerçek istemlerle yapılmalıdır.

Test matrisine model sürümü, quantization, bağlam uzunluğu, GPU aktarım oranı, ilk token süresi, saniyedeki token, tepe VRAM/RAM ve görev kalitesi eklendi. Türkçe özet, teknik soru, güvenli kod inceleme ve uzun belge bulma gibi anonim örnekler sabitlendi. Vision ve tool desteği yalnızca katalogda var diye kabul edilmedi; arayüzün, şablonun ve agent katmanının bu yeteneği doğru kullanıp kullanmadığı da doğrulandı.

# Yalnızca yerel model envanteri ve çalışma durumunu gözlemleyin.
ollama list
ollama ps

# İşletim sisteminde GPU kullanımını üreticinin desteklenen aracıyla izleyin.
# Sonuçları aynı test metni ve aynı bağlam ayarıyla karşılaştırın.

Uygulanan çözüm veya önerilen mimari

Tek model yaklaşımı yerine kullanım profillerine göre küçük bir model kataloğu önerdik. Günlük hızlı işler için daha küçük ve dengeli quantize model, zor analiz için daha güçlü fakat kontrollü kullanılan model, görsel işler için ilgili yeteneği doğrulanmış ayrı seçenek tanımlandı. Varsayılan context gereksiz büyütülmedi; kullanıcıya görevine uygun profil sunuldu. Böylece donanım yükseltmeden önce mevcut kapasite daha verimli kullanıldı.

Ollama model sunumu ile web arayüzü ve erişim katmanı ayrı değerlendirildi. Kaynak ölçümleri merkezi kayda alınırken istem içeriği gereksiz yere loglanmadı. Kurumsal belge kullanımı için erişim kontrolü, saklama politikası ve RAG veri yetkileri model seçiminden bağımsız güvenlik gereksinimleri olarak ele alındı. Pilot sonuçları kabul eşiğini karşılamazsa donanım yatırımı somut ölçüme dayandırıldı.

Alternatifler ve karar gerekçesi

Tamamen yerel çalışma veri kontrolü ve çevrimdışı kullanım sağlar; buna karşılık ilk yatırım, enerji, bakım ve kapasite sınırı getirir. Bulut API seçenekleri ölçek ve güçlü modellere erişim sunabilir, ancak veri işleme koşulları, değişken maliyet, bağlantı ve sağlayıcı bağımlılığı değerlendirilmelidir. Hassas görevleri yerelde, uygun sınıftaki yoğun veya özel işleri onaylı hizmette çalıştıran hibrit yaklaşım birçok kurum için dengelidir.

Tek büyük GPU almak sade görünür; birden fazla kullanıcı, yüksek erişilebilirlik veya büyüme hedefinde iş istasyonu mimarisi kısa sürede sınır olabilir. CPU ağırlıklı çalışma düşük başlangıç maliyetiyle deneme sağlar fakat etkileşimli kullanımda yavaş kalabilir. Kararı en yüksek parametreye göre değil, hedef görevlerin yüzde kaçını kabul edilen kalite ve sürede karşıladığına göre vermek daha savunulabilir oldu.

Güvenlik ve operasyonel riskler

Yerel model kullanmak verinin otomatik olarak güvende olduğu anlamına gelmez. Web arayüzü, sohbet geçmişi, yüklenen belgeler, eklentiler ve yedekler ayrı veri yüzeyleridir. Servis yalnızca gerekli ağ alanından erişilmeli, güçlü kimlik doğrulama uygulanmalı, modeller ile konteynerler güvenilir kaynaklardan alınmalı ve güncellemeler önce test ortamında doğrulanmalıdır. Gizli anahtarlar istemlere veya model dosyalarına eklenmemelidir.

Model çıktıları doğru görünse de hatalı olabilir; özellikle yapılandırma, hukuk, insan kaynakları ve güvenlik kararlarında insan onayı gerekir. Araç çağıran modellerin dosya ve terminal izinleri varsayılan olarak sınırlandırılmalı, çalışma alanı ayrılmalı ve yıkıcı eylemler açık onaya bağlanmalıdır. Kaynak tükenmesi, disk büyümesi ve model sürümü değişikliğine karşı kapasite, yedekleme ve geri dönüş planı tutulmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Yerel model denemeleri komut satırında başarılı olduğunda sıradaki doğal beklenti, çalışanların tarayıcıdan kullanabileceği sade bir arayüz oluyor. Bir pilotta Open WebUI kısa sürede kullanılabilir hale gelmişti; fakat sohbetlerin nerede tutulduğu, modele hangi ağ yolundan erişildiği ve güncellemede verinin korunup korunmayacağı sonradan soruldu. Teknik demo ile kurumsal servis arasındaki fark tam burada ortaya çıktı.

20 Temmuz 2026 tarihinde ele aldığımız mimaride Ollama model çalışma zamanı, Open WebUI kullanıcı katmanı ve Docker işletimi ayrı sorumluluk alanları olarak tasarlandı. Amaç internete açık bir deneme servisi oluşturmak değil; sınırlı kullanıcı grubuna, anonim test verileriyle başlayan ve güvenlik kontrolleri doğrulandıkça gelişen yönetilebilir bir yerel AI platformu kurmaktı.

Sorunun ortaya çıkışı

Windows iş istasyonunda Ollama modelleri çalışıyordu, ancak her kullanıcının komut satırı öğrenmesi ve model adlarını bilmesi beklenemezdi. Merkezi sohbet geçmişi, model seçimi ve belge yükleme gibi ihtiyaçlar doğdu. Docker Desktop üzerinde Open WebUI mantıklı bir arayüz seçeneğiydi. Buna karşın pilotun hangi kullanıcıya, hangi veriye ve hangi hizmet seviyesine sunulacağı tanımlanmadan yalnızca port yayınlamak riskliydi.

İlk tasarım görüşmesinde model sunucusu ile web konteyneri tek uygulama gibi konuşuluyordu. Oysa Ollama ağırlıkları yükleyip çıkarım yaparken Open WebUI kimlik, oturum, sohbet ve kullanıcı deneyimini yönetir. Docker ise paketleme ve çalışma ortamını sağlar. Sorun çıktığında hangi katmanın sorumlu olduğunu ayırabilmek için bile bu mimari sınırların açık yazılması gerekiyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım, servis yerel bilgisayarda çalıştığı için yalnızca o bilgisayardan erişilebileceğiydi. Konteyner portunun tüm arayüzlere bağlanması veya güvenlik duvarı kuralı, hizmeti beklenenden geniş bir ağa açabilir. İkinci varsayım konteyner silinince yalnızca uygulamanın silineceğiydi; kalıcı volume tanımlanmamışsa kullanıcı ayarları ve sohbet kayıtları da kaybolabilir.

Bağlantı hatalarında da modelin bozuk olduğu düşünüldü. Asıl neden bazen konteyner içindeki “localhost” kavramının ana bilgisayarı değil konteynerin kendisini göstermesiydi. Windows, Docker ağı ve Ollama dinleme ayarı birlikte incelenmeden rastgele adres ve port değişiklikleri yapmak sorunu büyütebilirdi. Model listesi, servis sağlığı ve ağ yolu katman katman doğrulanmalıydı.

Teknik analiz

Akışı tarayıcıdan Open WebUI konteynerine, oradan Ollama API katmanına ve seçili modele kadar izledik. Her adım için dinlenen arayüz, ad çözümleme, güvenlik duvarı ve hata kaydı kontrol edildi. Sohbet verisi ile model dosyalarının aynı yerde tutulmadığı belirlendi. Bu ayrım yedekleme, kapasite ve silme taleplerinin doğru bileşende yönetilmesini sağladı.

Konteyner imajı sürümle sabitlendi, kalıcı veri için isimlendirilmiş volume kullanıldı ve yeniden başlatma davranışı belirlendi. Sağlık kontrolü yalnızca web sayfasının açılmasına değil, arayüzün model kataloğuna ulaşmasına göre düşünüldü. GPU ve RAM tüketimi Open WebUI’dan çok Ollama iş yüküyle ilişkili olduğundan kapasite ölçümleri model, context ve eş zamanlı oturum bazında kaydedildi.

# Örnek yalnızca yerel pilot içindir; güçlü kimlik ve ağ kısıtı ayrıca uygulanmalıdır.
docker volume create open-webui-data

docker run -d --name open-webui 
  --restart unless-stopped 
  -p 127.0.0.1:3000:8080 
  -v open-webui-data:/app/backend/data 
  ghcr.io/open-webui/open-webui:<onayli-surum>

# İmaj etiketini test edilmiş gerçek sürümle değiştirin; latest kullanmayın.

Uygulanan çözüm veya önerilen mimari

Pilot aşamada arayüz yalnızca ana bilgisayara bağlandı ve küçük bir kullanıcı grubuna kontrollü erişim sağlandı. Kurumsal yaygınlaştırma için TLS sonlandıran ters proxy, merkezi kimlik, rol bazlı model erişimi ve ağ segmentasyonu ayrı katman olarak önerildi. Ollama servisi doğrudan son kullanıcılara yayınlanmadı; yalnızca uygulama katmanının gerekli yoldan erişmesi hedeflendi.

Veri yaşam döngüsü ayrıca tasarlandı. Sohbet geçmişinin varsayılan saklama süresi, kullanıcı silme yöntemi, yönetici erişimi, yedekleme kapsamı ve belge yükleme kuralları açıklandı. Model güncellemesi kalite regresyonu yaratabileceği için onaylı model kataloğu tutuldu. Kullanıcı eğitiminde sistemin sınırları, doğrulama ihtiyacı ve hangi veri sınıflarının isteme yazılamayacağı anlatıldı.

Alternatifler ve karar gerekçesi

Komut satırı en az bileşenli yöntemdir ve teknik kullanıcıların kişisel denemeleri için uygundur; fakat kimlik, kullanım kolaylığı ve ortak yönetişim sınırlıdır. Masaüstü uygulamaları hızlı deneyim sunabilir, ancak merkezi politika ve sürüm yönetimi ürüne göre değişir. Open WebUI seçimi açık bir web katmanı ve çoklu model deneyimi sağladığı için yapıldı; her ortam için tek doğru olduğu iddia edilmedi.

Docker Desktop pilot için hızlı ve taşınabilir oldu. Sürekli, çok kullanıcılı hizmette Linux sunucu veya orkestrasyon platformu daha öngörülebilir işletim sağlayabilir; bunun karşılığında ek uzmanlık ve bakım gerekir. Bulut tabanlı arayüzler ölçek avantajı sunar, fakat veri yerleşimi ve sağlayıcı koşulları farklıdır. Karar, kullanıcı sayısı, veri sınıfı ve destek hedefiyle birlikte verilmelidir.

Güvenlik ve operasyonel riskler

En önemli risk, arayüzün kontrolsüz ağda yayınlanması ve kullanıcıların hassas doküman yüklemesidir. Varsayılan hesaplar kullanılmamalı, kayıt açma politikası sınırlandırılmalı ve yönetici rolleri ayrılmalıdır. Eklenti, araç ve dış web erişimi varsayılan olarak kapalı tutulmalı; etkinleştirilecekse veri çıkışı ile komut yetkileri ayrıca incelenmelidir. İmajlar güvenilir kaynaktan ve sabit sürümle alınmalıdır.

Operasyonda disk büyümesi, eski sohbetler, model indirmeleri ve loglar izlenmelidir. Ana bilgisayar yeniden başladığında servis sırası, Ollama erişimi ve sağlık alarmı test edilmelidir. Yedek yalnızca volume kopyalamak değildir; geri yükleme denenmeli ve kişisel veri saklama kuralları korunmalıdır. Arayüzün açılması hizmetin sağlıklı olduğu anlamına gelmediğinden örnek çıkarım testi izlemeye eklenmelidir.

Çıkarılan Dersler

Kontrol Listesi

Bir yerel model sohbet ekranında iyi kod örnekleri ürettiğinde, dosyaları okuyup test çalıştıran ve değişiklik yapan bir geliştirme deneyiminin de kendiliğinden oluşacağı düşünülebiliyor. Denemede model güçlüydü, fakat masaüstü araç terminal çağrısını doğru yönetmiyor, çalışma dizinini ayırmıyor ve uzun görevlerde bağlamı kaybediyordu. Eksik parça model değil, agent sisteminin geri kalan katmanlarıydı.

17-20 Temmuz 2026 arasında Ollama, yönlendirilmiş API seçenekleri ve çeşitli masaüstü geliştirme arayüzlerini değerlendirirken modeli, agent runtime’ı, editörü ve araç izinlerini ayrı test ettik. Hedef, sınırsız komut çalıştıran bir otomasyon değildi. Geliştiricinin kontrolünü koruyan, değişiklikleri görünür kılan ve yerel modelin sınırlarını dürüstçe yöneten güvenli bir yardımcı deneyimiydi.

Sorunun ortaya çıkışı

Kullanıcı beklentisi doğal dille görev vermek, agent’ın depo yapısını anlaması, ilgili dosyaları değiştirmesi ve test sonucunu yorumlamasıydı. İlk kurulum yalnızca sohbet arayüzünü farklı bir LLM uç noktasına bağlamıştı. Model cevap üretiyor, ancak dosya araçları ve terminal protokolü uygulama tarafından sağlanmadığı için gerçek çalışma alanında işlem yapamıyordu. “Model desteklemiyor” teşhisi bu nedenle eksikti.

Başka bir istemci araç çağırabiliyor fakat modelin beklediği şema ile runtime’ın sunduğu şema uyuşmuyordu. Komut sonucunun kesilmesi, dosya kodlaması ve bağlam sınırı da kaliteyi etkiliyordu. Aynı model iki arayüzde farklı başarı gösterdi. Bu gözlem, değerlendirmeyi yalnızca benchmark puanından çıkarıp uçtan uca görev tamamlama ve güvenlik davranışına taşımamızı sağladı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım tool calling etiketi olan her modelin bütün agent’larla uyumlu çalışacağıydı. Araç şeması, sohbet şablonu, durdurma belirteçleri ve yapılandırılmış çıktı davranışı farklı olabilir. İkinci varsayım büyük context window değerinin tüm depoyu güvenilir biçimde anlamaya yeteceğiydi. Gereksiz dosyalar bağlamı doldurur, ilgili bilgi gürültü içinde kaybolur ve maliyet ya da bellek tüketimi artar.

Başarı, birkaç etkileyici kod önerisiyle ölçülüyordu. Agent’ın yanlış dosyayı değiştirmesi, testi hiç çalıştırmadan tamamlandı demesi veya komut hatasını görmezden gelmesi değerlendirmede yer almıyordu. Ayrıca tam disk ve terminal erişiminin kullanım kolaylığı sağladığı varsayıldı. Oysa model hatası, kötü niyetli depo içeriği veya yanlış anlaşılmış talep bu geniş yetkiyi operasyonel riske dönüştürebilir.

Teknik analiz

Mimariyi dört parçaya ayırdık: LLM backend metin ve araç kararını üretir; agent runtime döngüyü, bağlamı ve araç sonuçlarını yönetir; IDE veya masaüstü arayüzü farkları gösterir ve onay alır; sandbox ise dosya, süreç ve ağ sınırını uygular. Bunlara model yönlendirme, sır saklama ve gözlem katmanı eklendi. Her arızanın hangi sınırda oluştuğu kayıtlarla incelendi.

Temsilî görev setinde tek dosya düzeltmesi, çok dosyalı yeniden düzenleme, test hatası analizi ve yalnızca inceleme görevleri kullanıldı. Başarı; doğru değişiklik, gereksiz dosya sayısı, test sonucu, kullanıcı onayı ve geri alınabilirlik ile ölçüldü. Modelin hızına ek olarak ilk planın kalitesi, araç çağrısı doğruluğu ve hatadan toparlanma değerlendirildi. Gizli anahtar içeren gerçek depolar test kapsamına alınmadı.

# Agent için örnek güvenli çalışma yaklaşımı
# 1. Temiz ve ayrı bir çalışma dalı oluşturun.
git switch -c ai-deneme

# 2. Değişiklikleri çalıştırmadan önce inceleyin.
git diff --check
git diff

# 3. Yalnızca projenin tanımlı test komutunu kullanıcı onayıyla çalıştırın.
# Agent'a yönetici yetkisi veya çalışma alanı dışı yazma izni vermeyin.

Uygulanan çözüm veya önerilen mimari

Yerel Ollama backend’i güvenilir bir agent runtime’a bağlandı ve çalışma alanı proje diziniyle sınırlandı. Varsayılan mod salt okuma ve planlama oldu; dosya değişikliği açık yetki, terminal komutları ise komut sınıfına göre onay istedi. Değişiklikler ayrı dalda ve diff üzerinden gösterildi. Test sonucu alınmadan agent’ın tamamlandı iddiası kabul edilmedi; başarısız test kullanıcıya eksiksiz raporlandı.

Model profilleri görev türüne göre ayrıldı. Hızlı gezinme ve küçük düzenlemeler yerel modelde, kapasiteyi aşan görevler ise veri sınıfı uygunsa önceden onaylı uzak sağlayıcıda çalıştırılabildi. Yönlendirme kararı kullanıcıya görünür tutuldu. Sistem istemleri, araç şemaları ve model sürümleri yapılandırma olarak versiyonlandı; böylece davranış değişikliği izlenebilir hale geldi.

Alternatifler ve karar gerekçesi

IDE eklentileri geliştiricinin mevcut akışına yakın ve fark incelemesinde güçlüdür; bağımsız masaüstü agent’lar daha geniş görev akışı sunabilir. Komut satırı agent’ları otomasyona uygundur fakat izinlerin görünürlüğü kullanıcı deneyimine bağlıdır. Seçim model puanından önce ekibin editör standardı, onay ihtiyacı, platform desteği ve günlük yönetim gereksinimine göre yapılmalıdır.

Tam yerel çözüm kodun ortamdan çıkmamasını kolaylaştırır, ancak küçük modeller karmaşık görevlerde daha fazla yönlendirme isteyebilir. Uzak API yüksek kapasite sağlayabilir; veri işleme, anahtar güvenliği, kota ve maliyet yönetimi gerektirir. Hibrit seçenek esnektir fakat yanlış yönlendirme riski taşır. Bu nedenle depo veya dosya sınıfına bağlı açık politika, kullanıcı göstergesi ve varsayılan yerel tercih benimsendi.

Güvenlik ve operasyonel riskler

Agent’ın okuduğu depo içeriği güvenilir komut değildir. Dokümana veya kaynak dosyaya yerleştirilmiş yönlendirmeler modeli yetki genişletmeye ikna edebilir; runtime sistem politikası bunları veri olarak ele almalıdır. Gizli dosyalar, kimlik depoları ve çalışma alanı dışındaki dizinler varsayılan olarak erişim dışı bırakılmalı; ağ çıkışı sadece görev için gerekli, onaylı hedeflerle sınırlandırılmalıdır.

Otomatik değişiklikler lisans, güvenlik, iş mantığı ve bağımlılık riski taşır. Kod incelemesi, statik analiz ve testler insan sorumluluğunun yerini almaz. Agent kayıtlarında kaynak kodun veya sırların gereksiz kopyaları tutulmamalıdır. Model, eklenti ve araç güncellemeleri davranışı değiştirebildiğinden kontrollü yayımlanmalı; olay halinde oturum, değişiklik ve onay izi incelenebilir olmalıdır.

Çıkarılan Dersler

Kontrol Listesi