Küçük modellerin asıl gerekçesi maliyet değil, verinin cihazdan çıkmaması

Tez#

Küçük ve cihaz üstü modeller çoğunlukla ekonomik bir argümanla sunuluyor: token başına ödeme yok, sabit donanım maliyeti var, ölçek büyüdükçe avantaj artıyor. Bu argüman belirli koşullarda doğru ama koşullar genellikle belirtilmiyor.

Ekonomik hesabın kırılma noktası kullanım oranı. Sabit donanım maliyeti, donanım sürekli meşgulse token başına düşük bir maliyete bölünüyor; donanım günün büyük bölümünde boşta duruyorsa aynı maliyet çok daha az token'a bölünüyor ve API'nin üstüne çıkıyor. Buna donanım tedariki, güncelleme, izleme ve yedeklilik maliyetleri ekleniyor. Bu yüzden küçük modeli maliyet gerekçesiyle seçen çoğu kurum hesabı yanlış yapıyor. Doğru gerekçe ise ekonomik değil: verinin cihazdan ya da kurum ağından hiç çıkmaması ve bunun bir mimari özellik olarak garanti edilebilmesi.

Bağlam: gerekçeleri ayırmak#

Tablo, küçük model tercihinin olası gerekçelerini ve her birinin ne kadar sağlam olduğunu ayırıyor.

Beşinci satır sık yanlış okunuyor. Sağlayıcı bağımsızlığı bir kazanç ama bedeli bakım yükünün kuruma geçmesi: model güncellemesi, güvenlik yaması, donanım arızası, kapasite planlaması artık sizin işiniz. Bu, sağlayıcı riskini ortadan kaldırmıyor; onu operasyonel riske dönüştürüyor. Karar bu takası kabul etmekse sağlam, bu takası görmüyorsa değil.

Kanıt: gizlilik gerekçesinin somut hâlleri#

"Veri çıkmıyor" soyut bir avantaj değil; belirli kullanımlarda başka bir yolu olmayan bir gereklilik.

• Sağlık verisi: hasta kayıtlarının cihazdan çıkmaması, bir tercih değil çoğu zaman bir zorunluluk.
• Adli ve hukuki belge: içeriğin kurum dışına çıkmaması sözleşmeyle ya da mevzuatla bağlı olabiliyor.
• Üretim hattı görüntüsü: fabrika içi görüntülerin dışarıya gönderilmesi ticari sır kaygısı doğuruyor.
• Çocuk ve eğitim verisi: ek koruma gerektiren veri kategorilerinde dışarıya aktarım eşiği yüksek.
• Kamuya ait veri: bazı kamu kurumlarında veri yurt dışına aktarılamıyor ve bu bir yapılandırma sorunu değil.
• Cihaz içi kişisel bağlam: kullanıcının kendi mesajları, notları ve konumu üzerinde çalışan asistanlar.
• Bağlantısız ortam: uçak, maden, gemi, sınır bölgesi — bağlantı yoksa seçenek de yok.

Altıncı madde tüketici ürünlerinde belirleyici hâle geliyor. Bir asistan kullanıcının mesajlarına, notlarına ve takvimine erişiyorsa, bu verinin cihazdan çıkmaması bir pazarlama vaadi değil ürün mimarisi kararı. Ve mimari karar olduğu için sonradan değiştirilmesi pahalı: cihaz içi çalışacak bir model, ürünün özellik kapsamını baştan sınırlıyor ve bu sınır kabul edilerek tasarım yapılması gerekiyor.

Mekanizma: hibrit kurulumun doğru biçimi#

Pratikte çoğu sistem tümüyle cihazda ya da tümüyle bulutta olmuyor; karma çalışıyor. Ama karma kurulumun gizlilik değeri, bölmenin nasıl yapıldığına bağlı.

Yanlış bölme şöyle görünüyor: hassas veri cihazda işleniyor ama zor sorular buluta gönderiliyor — ve zor sorular tam olarak hassas veriyi içeren sorular oluyor. Bu kurulumda gizlilik vaadi çoğu zaman en kritik durumda bozuluyor. Doğru bölme veri sınıfına göre yapılıyor, zorluğa göre değil: belirli bir sınıftaki veri hiçbir koşulda dışarı çıkmıyor ve o sınıfla ilgili sorular, cihaz modeli yetersiz olsa bile dışarı gitmiyor — yetersizlik hâlinde kullanıcıya bir sınır bildiriliyor. Bu ayrım, hibrit kurulumun gizlilik iddiasını anlamlı kılan tek şey; "gerektiğinde buluta gidiyor" diyen bir sistemin gizlilik iddiası yok.

Karşı görüş#

Üç itiraz var. Birincisi: sağlayıcılar veri işleme koşullarını sözleşmeyle bağlıyor; veri dışarı çıksa da korunuyor. İkincisi: küçük modellerin kalitesi birçok görev için yetersiz ve gizlilik uğruna kalite feda edilmiş oluyor. Üçüncüsü: maliyet gerekçesi bazı yüksek hacimli kullanımlarda gerçekten tutuyor.

Maliyet hesabıyla başladık, donanım aldık. Kullanım oranı yüzde on beşte kaldı ve maliyet API'nin üstüne çıktı. Projeyi bitirmedik çünkü asıl gerekçe zaten gizlilikti — onu baştan yazmamıştık.

Birinci itiraz önemli ve büyük ölçüde doğru: sözleşmeyle bağlı bir veri işleme ilişkisi ciddi bir korumadır. Ama iki durumda yetmiyor — veri yurt dışına aktarılamıyorsa ve bağlantı yoksa. Bu iki koşul sözleşmeyle çözülemiyor. İkinci itiraz doğru ve kararın gerçek maliyetini gösteriyor: cihaz içi kurulum ürünün kapsamını sınırlıyor ve bu sınır baştan kabul edilmeli. Üçüncü itiraz da doğru ama koşullu: hesabın donanım, bakım ve boşta kalan kapasiteyi içermesi gerekiyor. Alıntının gösterdiği şey ise en pratik ders — gerekçeyi baştan doğru yazmak, projeyi kurtaran şey oluyor.

Sınırlar ve belirsizlik#

Bu analiz bir maliyet hesabı sunmuyor; hesabın hangi kalemleri içermesi gerektiğini söylüyor.

• Kırılma noktası kuruma özgü: kullanım oranı, donanım fiyatı ve iş yükü profiline bağlı.
• Küçük model kalitesi hızla değişiyor: bugün yetersiz olan bir görev yarın karşılanabilir hâle gelebilir.
• Cihaz çeşitliliği yönetim yükü: farklı donanımlarda aynı kaliteyi garanti etmek ayrı bir iş.
• Veri yerelliği kuralları alana göre değişiyor: hangi verinin yurt dışına aktarılamayacağı tek cevaba indirgenemiyor.

Sonuç#

Küçük ve cihaz üstü modellerin maliyet gerekçesi kırılgan: hesap kullanım oranına, donanım maliyetine ve bakım yüküne bağlı ve düşük kullanımda API'nin üstüne çıkıyor. Bu gerekçeyle başlayan projeler, hesap tutmadığında dayanaksız kalıyor.

Sağlam gerekçe veri tarafında: verinin cihazdan ya da kurum ağından hiç çıkmaması ve bunun mimari olarak garanti edilebilmesi. Bu bir maliyet kalemi değil bir uyum özelliği ve bazı kullanımlarda tek seçenek. Kararı bu gerekçeye dayandırmak, ürün kapsamındaki sınırı da kabul etmeyi gerektiriyor — ve o sınır kabul edildiğinde karar hem sağlam hem savunulabilir oluyor.

Ne yapmalı?#

1. 1Gerekçeyi yazılı olarak belirleyin

   Gizlilik mi, çevrimdışı çalışma mı, maliyet mi? Maliyetse hesap donanım, bakım ve boşta kapasiteyi içermeli.

2. 2Kullanım oranını tahmin edin

   Maliyet avantajı donanımın meşgul kalmasına bağlı. Düşük oranda hesap tersine dönüyor.

3. 3Bölmeyi veri sınıfına göre yapın

   Zorluğa göre bölme, gizlilik vaadini en kritik durumda bozuyor.

4. 4Sınırı kullanıcıya bildirin

   Cihaz modeli yetersizse istek dışarı gitmesin; kullanıcıya sınır açıkça söylenmeli.

5. 5Bakım yükünü bütçeleyin

   Sağlayıcı bağımsızlığı riski kaldırmıyor, operasyonel riske dönüştürüyor.

6. 6Ürün kapsamını sınıra göre tasarlayın

   Cihaz içi kurulum özellik kapsamını daraltıyor; bu sınır baştan kabul edilmeli.