Geçen ay, 2025’in Mart sonunda, İstanbul’daki küçük bir ürün ekibinde tam bu mesele masaya geldi: “Yapay zekâ özelliğini ekleyelim. Fatura patlamasın.” Açık konuşayım, bu soru artık klasik oldu. Herkes LLM istiyor. Kimse token faturasını görünce keyifli kalmıyor — hele bir de uygulama canlıya çıktıysa, iş gerçekten çığrından çıkabiliyor, bunu bizzat gördüm.
Benzer bir sahneyi 2024’te, Kadıköy’de bir mobil ürün toplantısında da yaşamıştım. Ekip OpenAI entegrasyonunu bitirmişti ama test trafiği bile beklenenden fazla harcamaya dönmüştü. Hani bazen teknik olarak çözüm var (belki yanılıyorum ama) gibi durur, her şey tamamlanmış görünür, ama sonra maliyet tablosuna bakınca insanın morali bir anda yere iner ya — aynen öyle bir tablo. İşin güzel yani şu ki: Flutter içinde yapay zekâyı illa dış API’lere bağımlı kurmak zorunda değilsiniz.
Peki neden? PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Dürüst olmak gerekirse, Bu yazıda meseleyi biraz tersinden ele alacağım. Önce neden API tabanlı modelin can sıkıcı hale geldiğini anlatayım, sonra da yerel model veya kendi sunucunda çalışan açık kaynak LLM yaklaşımının nerede iş gördüğünü açayım — valla güzel iş çıkarmışlar —. Çünkü lafı gevelemeden söyleyeyim: küçük ekipler için bu konu sadece “tasarruf” değil, çoğu zaman hayatta kalma meselesi.
Neden Fatura Bir Anda Şişiyor?
Tuhaf ama, Sessiz büyüme. LLM servislerindeki asıl tuzak tam da bu. Başta birkaç deneme yapıyorsunuz, her şey masum görünüyor, rakamlar güzel duruyor. Sonra kullanıcı sayısı artıyor, promptlar uzuyor, cevaplar da uzuyor ve bir bakıyorsunuz aylık gider kalemi bütçenin tam üstüne oturmuş. Hele bir de Flutter gibi doğrudan kullanıcıyla temas eden uygulamalarda bu çok daha hızlı oluyor — etkileşim sayısı yüksek olunca tablo değişiyor.
Ama mesele sadece para da değil, şunu da söyleyeyim. Veriyi üçüncü taraf API’ye gönderdiğiniz anda kontrol alanınız daralıyor. Kullanıcıdan gelen metinlerde kişisel bilgi olabilir, şirket içi notlar olabilir, hatta bazen istemeden gizli veri de sızabilir. Bu yüzden “Flutter private AI” fikri kulağa pazarlama cümlesi gibi gelse de pratikte bayağı ciddi bir ihtiyacı karşılıyor aslında.
Bir de gecikme tarafı var. API çağrısı demek internet üzerinden gidip gelmek demek; yani kullanıcı ekranında o ufak bekleme çemberini görmek demek. Ben 2023 sonbaharında Ankara’da bir danışmanlık projesinde bunu net gördüm — model hızlıydı, teknik olarak gayet iyiydi,. Ağ yavaşlayınca tüm deneyim çöktü. Tek tek bakınca sorun gibi durmaz ama toplu kullanımda sinir bozucu bir hal alıyor.
| Yaklaşım | Maliyet | Gizlilik | Gecikme |
|---|---|---|---|
| Dış LLM API | Kullanıma bağlı, sürprize açık | Daha düşük kontrol | Ağ durumuna bağlı |
| Yerel / Self-hosted LLM | Daha öngörülebilir | Daha yüksek kontrol | Daha iyi olabilir |
API’siz Mimari Ne Demek?
Özü basit aslında: modeli her istekte kiralamak yerine ya cihazın üzerinde çalıştırıyorsunuz ya da kendi sunucunuza kuruyorsunuz. Her prompt için dışarıya para akıtmak yerine compute’u siz yönetiyorsunuz. Bazen bu pahalı donanım olur, bazen makul bir CPU/GPU sunucusu yeter — kullanım senaryosuna göre değişiyor.
Açıkçası, Küçük bir startup için: düşük trafik varsa quantized modeller bayağı iş görüyor. Özet çıkarma, basit sınıflandırma veya metin bir düşüneyim… düzenleme gibi işler için devasa model şart değil zaten. Tahmin eder misiniz? Çoğu ürün ilk aşamada “çok akıllı” olmaktan çok “yeterince faydalı” olunca kazanıyor — bunu tecrübeyle söylüyorum.
Enterprise seviyede: tablo değişiyor tabi. Güvenlik politikaları, loglama ihtiyacı, erişim denetimi ve uyumluluk bir anda devreye giriyor. Burada self-hosting çoğu zaman daha mantıklı hale geliyor ama operasyon yükü de ciddi artıyor; yani rahat yok, bedava öğle yemeği hiç yok.
Bir üründe en iyi mimari çoğu zaman en havalı olan değil… en az sürpriz çıkaran mimaridir.
Quantization Neden O Kadar Önemli?
Teknik jargona girmeden anlatayım. Büyük bir defteri kopyalayıp daha ince bir deftere geçirmek gibi düşünün — bilgi kaybolmadan boyut küçülüyor, model daha az RAM tüketiyor ve daha ucuz donanımlarda çalışabiliyor. Flutter dünyasında bu can alıcı çünkü mobil cihazlar sınırsız kaynak vermiyor.
Tabii burada sihir yok. Model küçülürken kalite biraz düşebilir; özellikle karmaşık muhakeme isteyen işlerde fark hissedilir. Ama günlük kullanımda — mesela kısa yanıt üretme, form doldurma yardımı ya da uygulama içi asistan — bu düşüş çoğu zaman kabul edilebilir seviyede kalıyor, şaşırtıcı şekilde. Anthropic ile OpenAI Arasında Sessiz Yarış: İşte Pazarın Yeni Rüzgârı yazımızda bu konuya da değinmiştik.
Kendi deneyimimden konuşuyorum, Bende bu konuyla ilgili unutamadığım bir test var. Şubat 2024’te İzmir’de kurumsal bir demo sırasında quantized modeli eski bir dizüstünde denemiştim. Açıkçası beklediğim kadar kötü çıkmadı — hatta bazı görevlerde gayet tatmin ediciydi. Ama uzun bağlamlarda dağıldığını da saklamak gerekmiyor, o tarafı zayıf. Daha fazla bilgi için Ajinomoto’da ABF Savaşı: Fiyat Baskısı Neyi Değiştirir? yazımıza bakabilirsiniz.
// Basit yaklaşım örneği
final prompt = "Kullanıcı mesajını kısa Türkçe özetle:";
final modelPath = "models/llama-quantized.gguf";
// Uygulama tarafında yerel çalışma mantığı:
// 1) Prompt hazırla
// 2) Cihazdaki modele gönder
// 3) Yanıtı UI'a bas
// Dış API anahtarı yok.
Peki Flutter Tarafında Ne Kazanırsınız?
En büyük kazanç maliyetin öngörülebilir hale gelmesi. Token başına ödeme yerine sabit altyapı giderine geçiyorsunuz ve bütçe planlamak kolaylaşıyor. Bilhassa müşteri başına kullanım değişkense bu ciddi rahatlık veriyor; finans ekibi de biraz nefes alıyor doğrusu.
Peki neden?
Açıkçası, İkinci kazanç gizlilik. Kullanıcının metni cihazdan çıkmıyorsa risk alanınız daralıyor. Regülasyon tarafında eliniz güçleniyor — elbette tamamen sıfır risk diye bir şey yok, ama fark hissedilir. Bu nokta özellikle sağlık, eğitim ve iç iletişim uygulamalarında bayağı önemli bir etken haline geliyor. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
- Daha düşük uzun vadeli maliyet: Trafik arttıkça şaşırtıcı faturalar gelmez.
- Daha iyi veri kontrolü: Hassas içerik dış servise gitmez.
- Daha esnek mimari: Offline senaryolar mümkün olabilir.
- Daha az vendor bağımlılığı: Tek sağlayıcıya kilitlenmezsiniz.
Neyse uzatmayayım; avantajların yanında bazı eksiler de var ve bunları dürüstçe söylemek lazım…
Zor Kısım Nerede Başlıyor?
Yerel model güzel fikir. Ama her problem için altın bilet değil. İlk sorun paket boyutu ve cihaz kapasitesi oluyor — mobil uygulamaya büyük model gömmek bazen indirme süresini kabusa çevirebiliyor, kullanıcı henüz uygulamayı açmadan pes ediyor bile olabilir.
Kısa bir not düşeyim buraya. Daha fazla bilgi için Kod Yazmak Yetmiyor: UI’da Asıl Farkı Ne Belirliyor? yazımıza bakabilirsiniz.
Şöyle ki, İkinci sorun bakım yükü. Dış API’de güncelleme geldi mi sağlayıcı hallediyor; yerelde ise modeli seçmekten performans ayarlamaya kadar işi siz taşıyorsunuz. Küçük ekiplerde bu yük hafife alınmamalı çünkü iki hafta içinde “AI özelliği” diye başlayan iş üç ay boyunca altyapıya dönüşebiliyor… tanıdık geldi mi?
Bir de performans beklentisi var tabii. Kullanıcılar artık ChatGPT seviyesinde akıcılık bekliyor ama elindeki telefon orta segmentse bunu birebir vermek zor olabilir (ciddiyim). O yüzden ürünü tasarlarken doğru use-case seçmek şart. Her şeyi yapan asistan yerine dar kapsamlı ama hızlı çalışan özellikler çoğu zaman çok daha iyi sonuç veriyor.
Nerede işe yarar?
Kısaca söyleyeyim: özetleme, kategori önerisi, kısa yanıt üretimi, form yardımcısı ve içerik temizleme gibi işler için çok uygun olabilir.
Nerede zorlanır?
Karmaşık muhakeme isteyen görevlerde veya çok uzun bağlamlarla çalışırken kalite düşebilir; yani kağıt üstünde süper duran şey pratikte biraz tökezleyebilir.
Bence En Mantıklı Yol Nasıl Seçilir?
Bilmem anlatabiliyor muyum, Laf arasında sık sorulan şey şu oluyor: “Tamamen API’siz mi gidelim?” Ben buna otomatik evet demem açıkçası. Eğer ürününüzün çekirdeği yüksek kaliteli üretkenlik ise hibrit yapı daha mantıklı olabilir; hayati olmayan işleri yerelde çözersiniz, ağır işleri gerektiğinde sunucuya alırsınız. İkisi birbirini dışlamıyor.
Sektörde gördüğüm kadarıyla başarılı ekipler genelde ideolojik davranmıyor. Pragmatik davranıyor. Ne gerekiyorsa onu seçiyorlar.
Tamamını buluta taşımak kolaydır ama pahalıdır.
Tamamını cihaza koymak özgürlüktür ama bazen dertlidir.
Dengeyi bulmak esas maharet burada.
Bir şey dikkatimi çekti: Eğer ben bugün sıfırdan başlayacak olsam önce şunlara bakarım: veri hassas mı, kullanıcı etkileşimi sık mı, internet bağlantısı kritik mi ve ekip operasyon yükünü kaldırabilir mi? Bu dört sorunun cevabı aslında mimarinin yarısını veriyor zaten.
Dikkat Edilmesi Gereken Pratik Noktalar
Bakın, bir şey dikkatimi çekti: — Model seçimini demo videolarıyla değil gerçek cihazlarda yapın.
– Android düşük segment cihazlarda ayrıca test edin.
– Bellek tüketimini ölçmeden canlıya çıkmayın.
– Promptları gereksiz uzatmayın; kısa tutmak çoğu zaman hem hız hem kalite getirir.
– Loglama yapacaksanız hassas veriyi maskeleyin… aksi halde gizlilik avantajını kendi elinizle silersiniz.
Bunu geçen yaz Bodrum’daki bir saha testinde yine yaşadım: masaüstünde uçan prototip telefonda ağırlaştı çünkü bellek kullanımı hesaba katılmamıştı. O gün anladığım şey şu oldu — LLM entegrasyonu sadece model seçmek değil, ürün mühendisliği yapmak demekmiş!
Sıkça Sorulan Sorular
Flutter içinde LLM’i tamamen API’siz çalıştırabilir miyim?
Evet, bazı senaryolarda çalıştırabilirsiniz; özellikle küçük veya quantized modellerde bu mümkün olur., Ancak cihaz gücü sınırlıdır ve her use-case için uygun değildir., Ağır muhakeme isteyen işlerde hibrit yapı daha mantıklı olabilir.
Sabit maliyet ile token maliyeti arasında hangisi daha iyi?Kullanım hacmi düşükse token modeli başlangıçta rahat görünebilir., Trafik büyüyünce sabit altyapı genelde daha öngörülebilir olur., Yani karar kullanım desenine göre değişir..Yerel LLM gizlilik açısından gerçekten daha güvenli mi?Büyük ölçüde evet çünkü veri dış servise gitmeyebilir., Ama loglama,, crash raporu,, üçüncü parti SDK’lar gibi yan kanalları da kontrol etmeniz gerekir., Güvenlik tek hamlede çözülmez..Küçük startup’lar için en mantıklı başlangıç nedir?Küçük ekiple başlıyorsanız dar geniş bir özellik seçin., Mesela özetleme veya metin temizleme ile başlayın., Önce değer üretin,, sonra modeli büyütürsünüz..Kaynaklar ve İleri Okuma
- llama.cpp Proje Sayfası — bunu es geçmeyin
- Google Gemma Resmi Dokümantasyon Sayfası
- TensorFlow Lite Model Dönüştürme Dokümantasyonu
- WhatsApp’ta Kendi Yerel Yapay Zekânı Kurmak Node.js ve Ollama}
- Chunking Neden RAG’in En Büyük Hatası Olabiliyor?} — ciddi fark yaratıyor
- Conflux AI Kodlamada Spec Önce Kaos Sonra}
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
