Modeli uç cihaza indirmek: nicemleme ve gecikme bütçesi

Bütçe bir mühendislik çıktısı değil ürün girdisidir ve aday model elinize geçmeden yazılmalıdır. Aksi hâlde ilk çalışan model bütçenin kendisi olur: ne kadar yavaşsa o kadar kabul edilir. Sayılar etkileşimin biçiminden türetilir — kullanıcı yazarken öneri üreten bir yüzeyin ilk token bütçesi ile arka planda belge özetleyen bir işin bütçesi aynı olamaz.

Uç cihaz tek bir hedef değil, bir dağılımdır. Aynı nicemleme biçimi bir sinir işlemcisinde donanım hızlandırmalı çalışırken başka bir cihazda desteklenmediği için çalışma zamanı tarafından çözülüp işlemcide yürütülür. Bu düşüş hata vermez; yalnızca gecikme ve güç tüketimi değişir. Sahada en sık karşılaşılan sürpriz budur ve ancak fiziksel cihazda görülür.

• Cihaz sınıfı başına: uygulamaya düşen bellek payı ve işletim sistemi sürüm aralığı.
• Kullanılacak hızlandırıcı ve o hızlandırıcının desteklediği nicemleme biçimleri.
• Çalışma zamanı sürümü ve desteklenmeyen operatörlerin listesi.
• İşlemciye düşme durumunda uygulanacak davranış: küçültülmüş model, sunucuya devretme veya özelliği kapatma.
• Her sınıf için ayrı bütçe satırı — tek bir ortalama bütçe yazılmaz.

Doğrulama adımı: ölçümü en düşük hedef sınıfta alın. Üst sınıfta alınan sayıyı tüm kullanıcı tabanına genellemek, kullanıcıların bir kısmı için ürünü baştan kullanılamaz kılar ve bu genellikle yayından sonra fark edilir.

Temel çizgi yoksa kalite kaybı tartışması anekdota döner: birisi çıktıyı beğenmez, birisi beğenir ve karar en yüksek sesle konuşana kalır. Set nicemlemeden önce dondurulmalı, çünkü sonradan eklenen her vaka farkında olmadan mevcut sonucu haklı çıkaracak biçimde seçilir.

• En uzun ve en kısa gerçek girdiler — kayıp uçlarda yoğunlaşır.
• Alan terimleri, kısaltmalar ve özel adlar; Türkçe karakterlerin korunduğu örnekler.
• Biçim gerektiren çıktılar: yapılandırılmış alan, liste, sayısal cevap.
• Üretimde hata verdiği bilinen gerçek vakalar.
• Setin en az bir bölümü yalnızca sürüm kararında açılmak üzere ayrılır.

Karar ölçütü basit: eğitim sonrası nicemleme hedeflediğiniz bit genişliğinde dondurulmuş kalite çıtasını karşılıyorsa, nicemleme farkındalıklı eğitim gereksiz bir maliyettir. Karşılamıyorsa sırayla önce daha ince ölçekleme (kanal veya grup bazlı), sonra karma duyarlık, en son eğitim döngüsü denenir. Sıralamayı tersine çevirmek, en pahalı çözümü en ucuz sorun için harcamaktır. Yöntemi ve kalibrasyon setini bir sonraki adımdaki inişten önce sabitleyin; aksi hâlde her durakta ölçtüğünüz kalite başka bir kuruluma ait olur ve duraklar birbiriyle karşılaştırılamaz.

Ağırlık belleği tanım gereği öngörülebilir: parametre sayısı ile parametre başına bayt çarpımıdır. Kalite ise öngörülebilir değildir; yalnızca ölçülebilir. Bu asimetri kademeli inmeyi zorunlu kılar — her durakta bellek kazancı hesapla bilinir, kalite kaybı ise sizin setinizle ölçülür ve ikisi aynı tabloya yazılır.

Üretim aşamasında metin üretimi genellikle bellek bant genişliğine bağlıdır: her token için ağırlıkların bellekten okunması gerekir, dolayısıyla parametre başına bayt azaldığında saniyedeki token sayısı da artma eğilimindedir. Girdiyi işleyen ilk aşama ise daha çok hesaplamaya bağlıdır ve aynı kazancı göstermez. Bu yüzden ilk token süresi ile üretim hızı ayrı ölçülür.

Ağırlıklar sabit bir maliyettir ve kurulum anında bilinir. Anahtar-değer önbelleği ise çalışma zamanında, üretilen her token ile birlikte büyür. Kısa istemlerle rahatça sığan bir model, uzun bir belge verildiğinde bellek hatasıyla kapanır. Desteklenen en uzun bağlam bu yüzden bir ürün kararıdır ve kodda zorlanır; çökmeyle keşfedilen bir sınır olmamalıdır.

• Model ağırlıkları — nicemleme biçimine göre sabit.
• Anahtar-değer önbelleği — dizi uzunluğu ve katman sayısıyla büyür.
• Ara aktivasyonlar ve çalışma zamanının kendi tamponları.
• Uygulamanın model dışındaki bellek kullanımı (arayüz, görsel, veri).
• İşletim sisteminin uygulamaya bıraktığı payın alt sınırı.

Doğrulama adımı: en uzun desteklenen girdi ile en uzun desteklenen çıktıyı aynı koşuda birlikte çalıştırıp tepe belleği kaydedin. Ortalama girdiyle alınan ölçüm, sahada gerçekten çöken durumu hiçbir zaman göstermez. Bütçeyi aşıyorsanız önce bağlam sınırını daraltın, bit genişliğini indirmek ikinci seçenektir.

Sürekli çıkarım yükü yonga sıcaklığını yükseltir ve sistem belirli bir eşikten sonra saat hızını düşürür. Sonuç: ilk koşu en hızlı koşudur ve raporlanan sayı odur. Kullanıcının yaşadığı sayı ise onuncu koşununkidir. Bütçeye yazılacak değer, düşüşün oturduğu kararlı hızdır; en iyi koşu değil.

1. 1Cihazı bilinen bir durumdan başlat

   Ölçüm öncesi cihazı oda sıcaklığına bırakın, ekran parlaklığını ve ağ durumunu sabitleyin; aksi hâlde iki koşu karşılaştırılamaz.

2. 2Aynı işi arka arkaya tekrarla

   Tek koşu değil, gerçek kullanım temposunu taklit eden bir dizi koşu yapın; her koşunun süresini ve cihaz sıcaklığını ayrı ayrı kaydedin.

3. 3Düşüşün oturduğu noktayı bul

   Koşu süreleri belirli bir seviyede yatay seyretmeye başladığında kararlı hıza ulaşılmıştır; bütçe karşılaştırması bu değerle yapılır.

4. 4Enerjiyi iş başına normalize et

   Toplam pil düşüşü yerine tamamlanan iş başına enerjiyi raporlayın; yalnızca bu değer farklı bit genişlikleri arasında karşılaştırılabilir.

Sunucudaki bir modeli tek hamlede geri alabilirsiniz; cihazdaki modeli alamazsınız. Bu asimetri, uç cihaz dağıtımının en pahalı tarafıdır ve mimariyle karşılanır: model artefaktı uygulama ikilisinden ayrılır, kendi sürüm numarasını ve bütünlük imzasını taşır, bir önceki artefakt yeni sürüm saha ölçümüyle doğrulanana kadar cihazda kalır.

• Artefakt sürümleme ve bütünlük doğrulaması (indirilen dosya beklenen artefakt mı).
• Kademeli yayın: küçük bir dilimle başlayıp cihaz sınıfı başına telemetriye bakarak genişletme.
• Geri dönüş yolu: önceki artefakt saklanır ve dönüş güncelleme öncesinde test edilir.
• İndirme davranışı: ölçülü bağlantıda ve düşük pilde ertelenir, yarım kalan indirme devam ettirilir.
• Fark (delta) güncellemesi mümkünse tam artefakt yerine yamanın dağıtılması.