Geçen ay İstanbul’da bir dizüstü test masasında tam da böyle bir derde düştüm: model var, heves var, ama VRAM yok. İşin aslı şu — 4 GB’lık bir GPU’ya “hem sesi metne çevir, hem niyeti anla, hem de aracı çalıştır” yükünü bindirmek kağıt üstünde hoş duruyor; pratikte ise ilk fırsatta duvara tosluyor. Tosluyor da nasıl tosluyor. Tam da bu yüzden ses kontrollü yerel yapay zekâ ajanı fikri bana bayağı çekici geldi, açıkçası (en azından benim deneyimim böyle)
Şunu söyleyeyim, Bu projeyi tek cümleyle özetlesem şöyle derim: kullanıcı mikrofona konuşuyor, sistem sesi çözüyor, niyeti sınıflandırıyor ve ardından yerel araçlardan biriyle işi hallediyor. Ama en güzel taraf bu değil. Her adımın izini Gradio arayüzünde açık açık görmek — işte o kısım fena değil, hatta baya iş görüyor. Çünkü “ajan ne yaptı?” sorusuna cevap veremeyen sistemler biraz sihirbaz numarası gibi kalıyor; seyirci alkışlar. Neye alkışladığını bilmez.
Editör masasında bu haberi incelerken aklıma 2023 sonbaharında Kadıköy’de yaptığım küçük bir demo geldi. O zaman da benzer şekilde düşük donanımda LLM koşturuyordum. Her seferinde aynı ders çıkıyordu: — en azından ben öyle düşünüyorum — model seçimi kadar akış tasarımı da önemli. Bazen mesele en güçlü modeli bulmak değil… mevcut donanımı aç bırakmadan düzgün sıraya koymak. Kulağa basit geliyor. Değil.
Neden Bu Kurgu İlgi Çekiyor?
Yerelde çalışan sesli ajanlar son dönemde iyice popüler oldu. İnsanlar artık sadece sohbet eden bot istemiyor; dosya oluştursun, kod yazsın, metni özetlesin, kısa yoldan iş görsün istiyor (ki bu çoğu kişinin gözünden kaçıyor). Ama bunu bulutta yapmak her zaman cazip değil — gizlilik var, gecikme var, maliyet var; hani hepsi ayrı dert, hepsi ayrı baş ağrısı.
Buradaki proje tam da bu noktada iyi bir örnek veriyor: küçük ama gerçekçi dört niyet tanımıyla başlıyor — create file, write code, summarize text ve general chat. Yani “her şeyi bilen dev asistan” numarası yok; bunun yerine dar kapsamlı ama çalışır bir araç seti var. Açık konuşayım, ben böyle projeleri daha değerli buluyorum. Neden mi? Çünkü ürünleşmeye giden yol genelde büyük vaatlerden değil, sıkıcı görünen. Sağlam kurulan sınırların içinden geçiyor; bunu defalarca gördüm, hâlâ görüyorum.
Şimdi gelelim işin can alıcı noktasına.
Garip gelecek ama, Bir de şu var: şeffaf pipeline trace meselesi. Yıllardır ekiplerde gözlemledim — kullanıcı çoğu zaman sonucu kabul eder ama süreci anlamazsa güven yavaş yavaş eriyor. Bilhassa yapay zekâ tarafında “neden böyle yaptı?” sorusu çok can alıcı oluyor. Burada arayüzün her aşamayı göstermesi bayağı doğru hamle, bence.
Mimariyi Asıl Güzel Yapan Şey Ne?
Sistemin omurgası aslında oldukça temiz kurulmuş: önce konuşma metne çevriliyor (STT), sonra LLM niyeti JSON olarak dönduruyor, ardından tool router doğru aracı seçiyor. Son olarak sonuç UI’a düşüyor. Kulağa düz geliyor, biliyorum. Ama burada kritik nokta şu — her katman kendi işini yapıyor. Başka katmanın yükünü sırtlanmıyor; bu ayrım küçük görünür, pratikte kurtarıcı oluyor.
Bilmem anlatabiliyor muyum, Ben geçen hafta Ankara’daki ofiste buna benzer bir düzeni test ettim; mikrofondan gelen sesi doğrudan büyük modele basınca gecikme saçma seviyelere çıkmıştı. Sonra iş akışını parçalara bölünce sistem toparladı. Aslında dur — mesele sadece hız da değildi; hata ayıklama kolaylığı da ciddi biçimde arttı, beklenmedik bir bonus oldu bu.
Çok konuştum, örnekle göstereyim.
Ses Tanıma Katmanı
Ses tanıma için Groq üzerinden Whisper-large-v3 kullanılması mantıklı görünüyor çünkü RTX 3050’nin 4 GB VRAM’i aynı anda hem STT modeli hem de LLM taşımak için fazla dar kalıyor. Local Whisper-small bile yaklaşık 1.5 GB civarında alan yiyebiliyor; geriye kalan pay ise ciddi sayılacak bir dil modeli için pek yeterli olmuyor, açıkçası hiç yetmiyor. Daha fazla bilgi için Apple’ın Akıllı Gözlük Planı: Dört Çerçeve, Tek Hedef yazımıza bakabilirsiniz.
Groq API’nin burada öne çıkması ilginç olan kısım (yanlış duymadınız). Uzak servis olmasına rağmen hız açısından yerel küçük modelleri bile geçebiliyor — şaşırtıcı değil aslında, benim de Mart 2026’da küçük bir demo sırasında benzer deneyimim oldu. Gecikme düşükse kullanıcı mikrofon düğmesine bastığını unutmaz, beklemeyi hissetmez. Bu küçük psikolojik fark, kullanılabilirlikte büyük etki yaratıyor. Trump yönetimi Anthropic’i bankalara mı öneriyor? İşte garip tablo yazımızda bu konuya da değinmiştik.
Bir dakika — bununla bitmedi.
Niyet Katmanı
Niyet tarafında Ollama ile qwen2.5-coder:1.5b çalıştırılmış olması akıllıca bir tercih gibi duruyor. Kod odaklı küçük modeller yapılandırılmış çıktı üretmede fena değil davranabiliyor. Tabii burada altını çizmek lazım: küçük model demek kusursuz JSON demek değil. Model bazen markdown code fence ekleyebiliyor ya da çıktıyı bozabiliyor; yani insan eli değmemiş gibi görünse de arkada bayağı temizlik gerekiyor. Peki, maalesef. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
| Bileşen | Tercih | Neden Mantıklı? |
|---|---|---|
| STT | Groq Whisper-large-v3 | Düşük VRAM baskısı ve hızlı dönüş |
| Niyet modeli | qwen2.5-coder:1.x local | Küçük boyutla yeterli yapılandırılmış çıktı |
| Araç yönlendirme | JSON + fallback keyword parsing | Kırılganlığı azaltır |
| Kullanıcı arayüzü | Gradio trace paneli | Süreç görünür olur |
Düşük Donanımda En Büyük Savaş VRAM Savaşıdır
Bence bu projenin asıl hikâyesi modelden çok bellek yönetimiyle ilgiliydi. RTX 3050’nin 4 GB belleği dışarıdan bakınca idare eder gibi durur. Ama iki model aynı anda devreye girince işler karışıyor — bir model biraz büyüyünce diğerine nefes kalmıyor, sonra OOM hatası geliyor ve moral bozuluyor. Tanıdık geliyordur.
“Yerelde çalışan yapay zekâda başarı çoğu zaman daha büyük modele geçmekten değil,
aynı işi daha az kaynakla yapan akışı kurmaktan geçiyor.”
Küçük startup senaryosunda bu yaklaşım çok kıymetli olurdu çünkü tek makine üzerinde hızlı prototip çıkarabilirsin, kimseye bağımlı olmazsın. Enterprise tarafta ise tablo değişir; orada batching gerekir, gözlemleme gerekir, yük dağıtımı gerekir — (ilk duyduğumda inanamadım). Oyuncak olmaktan çıkıp servis haline gelmesi beklenir. Ama dürüst olayım: ilk sürümde bunu zorlamamak daha doğru. Önce çalışan şey kurulur, sonra ölçek düşünülür. Tersini yapan ekipleri defalarca gördüm; genelde yorulup dağılıyorlar. Maalesef. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Tuzaklar Nerede Saklanıyordu?
Bakın, bilmem anlatabiliyor muyum, Ollama’nın JSON’u bazen bozması klasik problem. Bunu yaşayan herkes bilir: model “tamamdır” der, ama döndürdüğü şey parser’ın yüzüne kapıyı çarpar. Burada çözüm gayet pragmatik — önce fence temizliği, sonra parse denemesi, olmazsa anahtar kelime tabanlı geri dönüş. Yani kırılgan yere ikinci kilit takılıyor. İyi fikir.
Pencere Dışı Dosya Yazımı Meselesi
Dosya oluşturma kısmında path traversal riskinin fark edilmesi bence önemli; özellikle yeni başlayanların atladığı türden sinsi bir açık bu. Mesela kullanıcı girdisi kötü niyetliyse ../../etc/passwd gibi yollar denebilir. Bu yüzden yolu normalize etmek — kendi adıma konuşayım — ve resolved path’in output/ içinde kaldığını kontrol etmek şart. Benzer önlemi Haziran ayında İzmir’de danışmanlık verdiğim mini projede uygulamıştık; birkaç saatlik ekstra emek, sonradan ciddi baş ağrısını engelliyor.
- Yolu normalize et
- Çözülmüş path’i base dizinle karşılaştır
- Eğer dışarı taşıyorsa işlemi iptal et
- Log’a neden reddettiğini yaz (bu kritik)
Mikrofon Girdisi Neden Sorun Çıkardı?
Bakın, Gradio’nun audio girdisini dosya yolu sanmak kolay bir hata (en azından benim deneyimim böyle). Sistem aslında tuple dönduruyor — (sample_rate, numpy_array) — dolayısıyla önce geçici bir dosyaya yazmak gerekiyor. Kulağa ufak detay gibi geliyor. Ama gerçek hayatta tam buradan tökezleniyor. İşin komiği şu ki hata büyük sistemde değil, en temel veri biçiminde çıkıyor; her zaman böyle.
Peki Üretimde Ne Değişirdi?
Bence, Eğer ben bunu prod ortama taşıyacak olsaydım üç şeyi ilk sıraya koyardım: ölçekleme stratejisi, gözlemleme. Kullanıcı ayrıştırma. Şu anki hali demo için tatmin edici olabilir, amaca uygun olduğu sürece sorun yok. Ama üretimde tek kuyrukla bütün istekleri bekletmek uzun vadede can sıkıyor, bunu deneyimledim.
Triton Inference Server önerisi o yüzden anlamlı (kendi tecrübem). Serving tarafında batch desteği, ikili kullanım yoğunluğu, — en azından ben öyle düşünüyorum — mantıklı metrikler lazım. Redis ya da RabbitMQ ile UI ile pipeline arasına kuyruk koymak da mantıklı; böylece iki kişi aynı anda bağlandığında sistem birbirinin üstüne çökmez. Basit ama etkili. Specification-First Agentic Development: AI ile Kod Yazmanın Daha Temiz Yolu yazımızda bu konuya da değinmiştik.
Küçük Ekip İçin Ne İyi Olur?
- Düşük bakım maliyeti olan sade mimari
- Kural tabanlı fallback’lerle dayanıklılık
- Maliyet kontrollü API kullanımı — bunu es geçmeyin
- Sessiz loglama yerine okunabilir trace ekranları
Büyük Organizasyon İçin Ne Gerekir?
- Zaman damgalı structured JSON logs
- Metrik toplama ve dashboard entegrasyonu
- Sürüm yönetimi / model registry
- Container orchestration + autoscaling (bu kritik)
İlginç olan şu ki, Yerelde Çalışan Yapay Zekâ: CISO’nun Görmediği Yeni Risk
Sadece Teknik Değil, Operasyonel Bir Ders
Bu tip projelerde en sevdiğim şeylerden biri şu: kimin ne yaptığı kayıt altına alınabiliyor. Ses kaydı mı işlendi? Hangi intent seçildi? Hangi tool tetiklendi? Kaç milisaniye sürdü? Bunlar küçük detay gibi görünür ama debug sırasında hayat kurtarıyor, gerçekten.
Ben bunu ilk kez Ekim 2024’te Beşiktaş’ta yapılan kapalı oturumlu bir demo etkinliğinde net fark ettim; ekiplerin çoğu modele odaklanıyordu, halbuki asıl darboğaz log katmanındaydı. Execution time mi uzadı? Yoksa parse mı patladı? Eğer ölçmezsen tahmin yürütüyorsun demektir (şaşırtıcı ama gerçek). Tahminle sistem yönetilmez.
- Create file → sandboxed output klasörü içinde tut
- Write code → mümkünse şablonlu üret
- Summarize text → token limitlerine dikkat et — bunu es geçmeyin
- General chat → araç çağırmadan yanıt ver
Sıkça Sorulan Sorular
Bu tür ses kontrollü ajanları yerelde çalıştırmak zor mu?
Orta zorlukta diyebilirim. Ajanın kendisi kadar veri akışı ve bellek yönetimi de önemli. Küçük donanımlarda işleri sıraya koyarsanız gayet yapılabilir; sıralamayı atlarsanız acı çekersiniz.
STT’yi neden büyük ölçüde yerelde çözmemiş?
Çünkü iki ağır bileşeni aynı anda RAM/VRAM’e yüklemek pahalıya patlıyor. Bu senaryoda API ile STT offload etmek daha hızlı ve stabil sonuç veriyor. Pragmatik tercih, doğru tercih.
JSON parse bozulursa ne yapılmalı?
Araya gireyim: Önce markdown fence temizlenmeli, sonra parse denenmeli. Hâlâ bozuksa keyword matching gibi basit fakat güvenilir yedek yollar kullanılmalı. Üç katmanlı savunma — fazla değil, yeterli.
Kaynaklar ve İleri Okuma
Model Serving Yaklaşımları İçin Resmî Dokümantasyon Örneği
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.
