Amazon, Claude Sonnet'i Strands Decider ile değiştirerek bilet etiketleme maliyetini yüzde 98 düşürdü

Ne oldu

İki Amazon mühendisi, dahili bir bilet sistemlerinde biletleri etiketlemek için Claude Sonnet 4.6'yı küçük bir karar modeli olan Strands Decider ile değiştirdi ve bu değişikliğin, LLM'in etiketleme kalitesini yaklaşık yüzde 98 daha düşük maliyetle eşlediğini bildiriyor. Hacker News'in ana sayfasına ulaşan Strands Agents blogundaki yazılarına göre, bilet başına maliyet yaklaşık 0,0222 dolardan yaklaşık 0,0005 dolara düştü — milyonlarca bilet başına kabaca 22.200 dolardan yaklaşık 500 dolara — ve ekip, bu tasarrufun yılda milyonlarca dolara ulaşmasını bekliyor.

Sistem, müşteri tırmandırmalarını (escalation), kapasite taleplerini, otomatik alarmları, güvenlik bulgularını ve diğer olayları 20 sabit kategoriye ayırıyor. Amazon Bedrock üzerinden sunulan Anthropic modeli Sonnet 4.6, bu işi büyük ölçekte yapıyordu: her bilete uzun bir system prompt çalıştırıyor ve etiket setine karşı akıl yürütme içeren JSON üretiyordu.\n

Bir karar modeli neden uygun

Yazıdan yaklaşık bir ay önce Strands ekibinin piyasaya sürdüğü Strands Decider hiç metin üretemez. Bir state, bir soru ve bir seçenek kümesi alır; her seçenek için bir olasılık ve bir güven skoru döndürür. Carr ve Mehul adındaki mühendiler, bunun tam olarak bilet sınıflandırmanın biçimi olduğunu savunuyor: bilet state'tir, etiket kataloğu da seçenek kümesidir.

2 milyar parametreli Decider ile başladılar, ancak Gemma 4 üzerine kurulu bir E4B sürümü bir test setinde belirgin biçimde daha iyi sonuçlar verdi, bu yüzden ona geçtiler. Gerçek biletlerden oluşan ayrı bir eldeki tutulan (held-out) sette E4B modeli, üretimdeki Sonnet kurulumunu geride bıraktı.

Model, her biri tek bir A10G GPU ve 24 GB belleğe sahip SageMaker ml.g5.xlarge instance'larında çalışıyor. Yaklaşık 19 GiB bellek kullanıyor ve yaklaşık 640 ms'de yanıt veriyor; giden erişimi engelleyen izole bir ağda bir autoscaling endpoint'i var; ağırlıklar başlangıçta S3'ten kopyalanıyor. Yolun geri kalanı standart AWS tesisatı: bilet olayları bir SQS kuyruğuna düşer, bir Lambda fonksiyonu SageMaker endpoint'ini çağırır, AppConfig trafik anahtarını tutar ve CloudWatch log, metrik ve alarmları taşır.

Ölçülen sayılar

Her iki sistemi aynı biletlerde çalıştırmak şu rakamları üretti:

• Çağrı başına ortalama süre: Sonnet için 4.215 ms'ye karşılık Decider için 897 ms — yüzde 78 iyileşme.
• Bilet başına girdi token'ı: 6.554'e karşılık 2.009.
• Bilet başına çıktı token'ı: 170'e karşılık 1.
• Bilet başına toplam token: 6.724'e karşılık 2.010 — yüzde 70 düşüş.

Token çöküşü iki yerden geliyor. Decider yalnızca JSON bir yanıt yerine seçilen seçeneği yayıyor ve prompt'u çok daha kısa. Sonnet'in üretim etiket açıklamaları tek başına Decider'ın 4.096 token'lık penceresini aşıyordu; bu yüzden mühendisler 20 etiketin tamamını bir-iki cümlelik kriterler olarak yeniden yazdı ve bunları tek bir seçim sorusunun seçenekleri olarak, ayrıca bir "hiçbiri" seçeneğiyle birlikte geçti. Uzun biletler, en eski yorumlar atılarak kısaltılıyor. Sonnet'in kapatıldığı gün, ortalama Lambda yürütme süresi yüzde 74 düştü.

Maliyetler, yayımlanmış us-east-1 liste fiyatlarıyla veriliyor: Bedrock'taki Sonnet için milyonlarca girdi token'ı başına 3,00 dolar ve milyonlarca çıktı token'ı başına 15,00 dolar; buna karşılık SageMaker'daki Decider için instance-saati başına 1,408 dolar. İstek başına 640 ms ile tek bir instance saatte yaklaşık 5.600 bilet işleyebiliyor — tam kullanımda milyon başına 250 dolar — ancak ani yükler için pay bırakmak pratik rakamı milyon başına yaklaşık 500 dolara itiyor.

Üç yönlü anahtar

Ekip basitçe bir düğmeye basmadı. Etiketleme Lambda'sı her mesajda AppConfig'den üç yönlü bir ayar okuyor: BEDROCK, Sonnet her şeyi etiketler; DUAL, her iki model paralel çalışır, Sonnet'in yanıtı uygulanır ve her anlaşmazlık karşılaştırılır; DECIDER, Decider her şeyi etiketler ve Bedrock çağrılmaz. Canlı trafiğin anlaşmazlıklarını değerlendirmenin, yazdıklarına göre, herhangi bir çevrimdışı değerlendirmeden daha çok şey öğrettiğini ve geri almayı 45 saniyelik bir config değişikliğine dönüştürdüğünü belirtiyorlar.

Bir tesadüfi keşif: JSON anahtar sırası sonuçları etkiliyordu. Aynı içeriği anahtarları yeniden sıralayarak yeniden göndermek, çıktı olasılıklarını 0,19'a kadar oynatıyordu; bu yüzden artık her istekte sıralı anahtarlar kullanılıyor.

Dikkate değer uyarılar

Rakamlar, işin içindeki mühendislerin yazdığı bir sağlayıcı blog yazısından geliyor, yani manşetteki tasarruflar bağımsız olarak denetlenmemiş, kendilerinin bildirdiği değerler. Mühendisler sınır konusunda açık sözlü: yaklaşım işe yaradı çünkü görev sabit bir katalogdan kapalı bir seçimdi, hacim yüksekti ve latency önemliydi. Etiketlerin açıklama metnine ihtiyacı varsa, katalog haftalık değişiyorsa ya da yararlı bağlam birkaç bin token'a sığmıyorsa, bir karar modeli muhtemelen LLM'in yerini alamaz.

Neden önemli

Bu, her işi bir frontier LLM'e yönlendirmek ile aracı göreve göre seçmek arasındaki maliyet farkına dair şimdiye kadarki en net kamusal veri noktalarından biri. Genel amaçlı bir modelle bilet başına 0,022 dolara mal olan bir sınıflandırma işi, küçük bir karar modeliyle bilet başına 0,0005 dolara mal oldu — kabaca 44 kat daha ucuz ve daha iyi latency ile. Agent ölçeğinde bu fark hızla birikir. Yazının operasyonel deseni — eski ve yeni sistemleri gerçek trafikte paralel çalıştırıp anında geri alabilmek — hangi modelleri çalıştırırsa çalıştırsın her ekibin kopyalayabileceği bir şablon.