Local AI Agent Deployment: AgentSpace Token Testi
Local ai agent deployment neden şimdi gündemime girdi
LFM2.5-2.6B gibi küçük, yerelde çalışabilen modellerin ajan görevlerinde kullanılmasıyla ilgili haberleri okuyunca aklıma tek bir soru takıldı: AgentSpace’in worker havuzundaki bazı görevleri Claude’dan alıp bir local modele mi vermeliyim? AgentSpace şu an lider ajan planlıyor, worker’lar Claude üzerinde koşup görevi sprint halinde tamamlıyor. Her worker çağrısı token faturası demek. Küçük bir local model bu faturanın bir kısmını gerçekten kesebilir mi, yoksa sadece kalite kaybı satın almış olur muyum — bunu yazıyla birlikte düşünmek istedim.
Bu yazı bir sonuç raporu değil. Local ai agent deployment fikrini nasıl test edeceğimi, hangi görevleri aday gördüğümü ve neyi henüz bilmediğimi açık şekilde anlatıyorum.
AgentSpace’te token maliyeti nereden geliyor
AgentSpace’te maliyetin büyük kısmı worker ajanların görev başına ürettiği bağlam ve çıktı token’larından geliyor. Lider ajan sprint planını çıkarıyor, worker’lar görev panosundan işi alıp gerçek yazılım görevini yürütüyor, kalıcı hafızadan geçmiş bağlamı okuyor. Bu akışın hepsi Claude üzerinde çalışıyor çünkü şu ana kadar tek model katmanım buydu.
Sorun şu: her worker görevi aynı ağırlıkta değil. Bazı görevler gerçekten muhakeme, çok adımlı planlama, kod tabanında ilişki kurma istiyor — burada Claude’un gücüne ihtiyacım var. Ama bazı görevler basit: bir dosyayı belirli bir formata çevirmek, bir log çıktısını özetlemek, sabit bir şablona göre metin üretmek. Bu ikinci grup, büyük bir modelin tüm kapasitesini kullanmadan da halledilebilir gibi görünüyor.
LFM2.5-2.6B haberi ne vaat ediyor
Haberde dikkatimi çeken nokta, küçük parametreli bir modelin ajan görevlerinde (araç çağırma, adım adım talimat takibi) kullanılabilir bulunması. Burada net olmak istiyorum: bu modeli henüz AgentSpace’e bağlamadım, kendi worker’larımda benchmark yapmadım. Elimde “şu görevde şu kadar token tasarrufu sağladı” diyebileceğim hiçbir rakam yok. Sadece haberin tetiklediği bir hipotez var: küçük, yerelde barındırılan bir modeli belirli worker görevlerine önden filtre veya doğrudan yürütücü olarak koyup Claude’a giden çağrı sayısını azaltmak.
Hangi görevler local’e taşınabilir, hangileri taşınamaz
Bunu net ayırmadan test kurmanın anlamı yok, o yüzden önce bir sınıflandırma yapıyorum.
Local model adayı olabilecekler
- Sabit formatlı metin üretimi (görev özet kartı, log dönüştürme)
- Basit sınıflandırma (bu görev acil mi, hangi kategoriye giriyor)
- Ön filtre: worker’a gitmeden önce görevin gerçekten Claude gerektirip gerektirmediğine karar vermek
Claude’da kalması gerekenler
- Çok adımlı kod değişikliği ve gerçek yazılım görevi yürütme
- Kalıcı hafızadaki geçmiş bağlamı yorumlayıp plana bağlama
- Lider ajanın sprint planlama ve görev bölme kararı
Bu ayrımın kendisi de bir varsayım — pratikte “basit” sandığım bir sınıflandırma görevinin küçük modelde beklenmedik şekilde bozulması hiç şaşırtıcı olmaz. Bunu ölçmeden iddia etmiyorum.
Deployment planım
Local ai agent deployment’ı AgentSpace’e üç adımda sokmayı planlıyorum. Şu an hiçbiri prod’da değil, sırayla anlatıyorum.
1. Model seçimi ve barındırma
İlk adım, modeli AgentSpace’in çalıştığı ortamdan bağımsız, izole bir şekilde ayağa kaldırmak. Amacım worker akışına dokunmadan önce modelin kendi başına ne kadar tutarlı çalıştığını görmek. Donanım tarafında ne kullanacağıma henüz karar vermedim — bu da yazının açık kalan noktalarından biri.
2. AgentSpace worker havuzuna router ekleme
Şu anki mimaride her görev doğrudan bir worker’a, worker da Claude’a gidiyor. Planım, bu akışın önüne ince bir router koymak: görev panosundan gelen iş, önce basit bir sınıflandırmadan geçecek. “Local’e uygun” etiketlenen görevler local modele, geri kalanı normal Claude worker akışına gidecek. Bu router’ın kendisi de bir karar noktası olduğu için hata payı taşıyor — yanlış sınıflandırma, düşük kaliteli çıktının fark edilmeden sprint sonucuna karışması riski var.
3. Görev sınıflandırma mantığı
Sınıflandırmayı ilk aşamada kural tabanlı tutmayı düşünüyorum (görev tipi etiketine göre), model tabanlı bir sınıflandırıcıya geçmeyi ikinci aşamaya bırakıyorum. Sebep basit: kural tabanlı sistemde hata ayıklamak daha kolay, ilk testlerde neyin çalışıp neyin çalışmadığını görmek istiyorum.
4. Ölçüm: neyi karşılaştıracağım
Test kurulunca üç şeye bakacağım:
- Aynı görev tipi için local model ile Claude worker arasında token/maliyet farkı
- Çıktı kalitesinde gözle görülür bir düşüş var mı (kabul/red oranı gibi kaba bir ölçüt)
- Router’ın yanlış sınıflandırma oranı — yani “local’e uygun” dediğim görevlerin gerçekte ne kadarı aslında Claude gerektiriyormuş
Bunların hiçbirinde şu an elimde sayı yok. Bu yazı, ölçüme başlamadan önceki plan aşamasının notu.
Riskler ve henüz bilmediklerim
En büyük risk, token tasarrufunun kalite kaybıyla gizli şekilde ödenmesi. Bir worker görevi local modelde “ucuza” tamamlanır ama çıktısı sprint sonunda düzeltme gerektirirse, gerçek maliyet düşmüyor, sadece başka bir yere kayıyor — üstelik fark edilmesi daha zor. Bunu net ölçmeden “local ai agent deployment token maliyetini kesiyor” gibi bir iddiada bulunmayacağım.
İkinci bilinmeyen, router’ın kendisinin ek bir bakım yükü olması. Sınıflandırma kuralları görev tipleri değiştikçe eskiyecek, bunu kim ve ne sıklıkla güncelleyecek — henüz düşünmedim.
Üçüncüsü, ölçek. Tek kurucu olarak çalıştığım bir sistemde local model barındırmanın operasyonel yükü, kazanılacak token tasarrufunu karşılar mı — bunu da test etmeden bilemem.
Sonuç
Local ai agent deployment fikri kağıt üzerinde mantıklı: AgentSpace worker havuzundaki her görev aynı ağırlıkta değil, bazılarını daha küçük bir modele devretmek token faturasını düşürebilir. Ama şu an elimde plan var, sonuç yok. Router’ı kurup ilk sınıflandırmayı devreye aldığımda, hangi görev tiplerinde gerçekten fark oluştuğunu ve neyin beklendiği gibi çalışmadığını ayrı bir yazıda paylaşacağım.