Amazon, iç ticket sınıflandırmasında Sonnet 4.6'yı küçük karar modeli Strands Decider ile değiştirdi; maliyetin yüzde 98 düştüğünü söylüyor
Strands Agents ekibinin 9 Kasım tarihli yazısına göre Amazon, iç destek kayıtlarını 20 kategoriye ayıran işte Claude Sonnet 4.6 yerine Gemma 4 tabanlı Strands Decider'ı kullanmaya başladı. Ekip aynı başarıyı ticket başına yaklaşık 44 kat daha düşük maliyetle aldığını öne sürüyor.
AWS'nin açık kaynak agent çatısı Strands Agents'ın ekibi, 9 Kasım'da yayımladığı blog yazısında Amazon içindeki bir iş akışında büyük dil modelini küçük bir "karar modeliyle" değiştirdiklerini anlattı. İş, iç destek kayıtlarını (ticket) 20 kategoriye ve bir "hiçbiri" seçeneğine ayırmaktı. Daha önce bu işi Claude Sonnet 4.6 yapıyordu; artık Strands Decider'ın Gemma 4 E4B tabanlı sürümü yapıyor. Yazı Hacker News'te ön sayfaya çıktı.
Strands Decider nedir?
Decider metin üreten bir model değil. Yazıya göre modele bir durum, bir soru ve seçenekler veriliyor; model her seçenek için bir olasılık ve bir güven skoru döndürüyor. Yani cevap bir paragraf değil, tek bir seçim. Ekibin tablosunda bu fark açıkça görülüyor: Sonnet ticket başına ortalama 170 çıktı token'ı üretirken Decider 1 token üretiyor.
Ekibin paylaştığı rakamlar (üreticinin kendi ölçümü):
- Çağrı başına ortalama süre: Sonnet 4.6'da 4.215 ms, Decider'da 897 ms.
- Ticket başına toplam token: 6.724'e karşı 2.010.
- Ticket başına maliyet: 0,0222 dolara karşı yaklaşık 0,0005 dolar; milyon ticket başına yaklaşık 22.200 dolara karşı 500 dolar. Ekip bunu "yaklaşık 44 kat daha ucuz", yüzde 98 düşüş olarak özetliyor ve yılda milyonlarca dolarlık token tasarrufu bekliyor.
Model, tek A10G GPU'lu bir SageMaker ml.g5.xlarge örneğinde çalışıyor. Geçiş üç konumlu bir ayarla yapıldı: yalnızca Sonnet, ikisi paralel (anlaşmazlıklar karşılaştırılarak) ve yalnızca Decider. Ekip geri dönüşün 45 saniyelik bir ayar değişikliği olduğunu yazıyor.
Sınırlar
Yazı sınırları da sıralıyor: Decider'ın context window'u 4.096 token; bu yüzden 20 kategori tanımı bir-iki cümlelik ölçütlere indirildi ve uzun ticket'larda en eski yorumlar atılıyor. JSON anahtar sırasının değişmesi olasılıkları 0,19'a kadar oynattığı için anahtarlar artık sıralı gönderiliyor. Ekip, yöntemin bilinen bir katalogdan seçim yapılan kapalı uçlu işlere uygun olduğunu, açıklama metni gereken ya da kategorileri her hafta değişen işlere muhtemelen uymadığını belirtiyor. Yazıda Decider deposunun lisansı ayrıca belirtilmiyor.
Neden önemli?
Kurumlarda AI faturasının büyük kısmı inference'ta, yani modelin her gün binlerce kez çağrıldığı tekrar eden işlerde birikiyor. Bu örnek, "hangi kategori?" gibi tek kelimelik cevabı olan işlerde büyük modelin yerine küçük ve kendi altyapınızda çalışan bir modelin yeterli olabileceğini somut rakamlarla gösteriyor.
Kimin işine yarar, ne yapabilirsiniz?
- Ticket yönlendirme, e-posta etiketleme, uyarı (alert) önceliklendirme gibi kapalı uçlu işlerinizi listeleyin; bunlar küçük model adayıdır.
- Geçişi Amazon ekibinin yaptığı gibi paralel çalıştırarak ölçün: aynı girdiyi iki modele verip anlaşmazlık oranına bakın, sonra karar verin.
- Context sınırını hesaba katın: uzun kayıtlarda neyin atıldığını bilmeden kritik sınıflandırmayı küçük modele bırakmayın.
- Lisans ve barındırma koşullarını, modeli üretime almadan önce depodan ayrıca doğrulayın.
