Dokunulmamış bir sunucuda özdeş LLM maliyet benchmarkları %27 sapma gösterdi, dev.to yazısına göre

Dört ölçüm, dört farklı yanıt

dev.to'da yazan bir geliştirici, yerel bir LLM sunucusuna karşı aynı maliyet ölçümünü üst üste dört kez çalıştırdığını ve her seferinde önemli ölçüde farklı sayılar aldığını bildiriyor; ardışık iki çalışma arasında %27'lik bir sıçrama da bunlara dahil. Kurulum bilinçli olarak sade tutulmuş: Ollama çalıştıran bir MacBook, llama3.2:3b modeli, aynı sekiz yerleşik prompt, sıfır temperature, istek başına 64 çıktı token sabit sınırı ve yalnızca aritmetikte bir varsayım olarak kullanılan saatte 1,50 dolarlık GPU ücreti. Dört ölçümün tamamı birbirinden yaklaşık 70 saniye içinde tamamlandı.

Milyon çıktı token başına maliyet dört çalışmada sırasıyla 8,77 dolar, 8,86 dolar, 11,26 dolar ve 10,02 dolar çıktı. Üçüncü çalışma ikincisinden %27,1 daha pahalıydı; dördüncü ise üçüncüden %11 daha ucuzdu. Aradaki süreçte sunucuda, modelde veya ayarlarda hiçbir şey değişmemişti.

Aynı tokenlar, farklı saat

Dev.to yazısına göre her çalışmadaki her istek bloğu tam olarak aynı token sayısını üretti; yani fiyat hareketi tamamen geçen duvar saati süresinden kaynaklandı. İlk çalışmadaki üç blok her biri yaklaşık 5,2 ila 5,5 saniyede bitti; üçüncü çalışmada eşdeğer bloklar 6,6 ila 7,1 saniye sürdü. Aynı çıktı için yaklaşık %30 daha uzun geçen süre, token başına yaklaşık %27 daha fazla dolara dönüştü, çünkü maliyet modeli yalnızca varsayılan saatlik ücretin süreyle çarpılıp token sayısına bölünmesinden ibaret.

Yazı, zamanlamadaki bu kaymayı gerçek bir makinenin olağan davranışına bağlıyor: rekabet eden süreçler, termal durum ve saat hızı, bellek baskısı, işletim sistemi zamanlaması ve paylaşılan cloud düğümlerinde diğer kiracıların etkinliği. Yazar dizüstü bilgisayarı izole edip ölçmediği için spesifik neden bilinmiyor — bu da yazıya göre asıl mesele. Tek bir öncesi/sonrası çifti, arka plan yükünü gerçek bir değişimden ayırt edemez.

Neden hata payları bunu yakalamadı

Her ölçüm, yalnızca o tek çalışmadaki bloklardan hesaplanan bir %95 güven aralığı bildirdi. İlk çalışmanın (8,19 ila 9,35 dolar) ve üçüncünün (10,31 ila 12,21 dolar) aralıkları örtüşmüyor; olağan pratik kurala göre bu gerçek bir gerileme gibi görünürdü. Yazı, bunun aralığın neyi ölçtüğünü yanlış okuduğunu savunuyor: aralık, tek bir çalışmanın içindeki yaklaşık 20 saniyelik değişimi tanımlar ve bir çalışmadaki tüm bloklar aynı makine koşullarını paylaşır. Sistemin tamamı bir dakikalığına yavaşlarsa üç blok birlikte yavaşlar ve aralık yanlış sayının etrafında dar kalır.

Gerçekte maruz kaldığınız gürültüyü ölçmek

Önerilen çözüm, değişmeden kalan yapılandırmayı en az üç kez tekrarlayarak çalışmadan çalışmaya varyansı doğrudan ölçmektir. Yazar ilk üç çalışmayı (8,77, 8,86 ve 11,26 dolar) bu örneklem olarak alıyor; bu, 2 serbestlik derecesiyle %14,6'lık göreli standart sapma veriyor. Bunun 4,303'lük Student's t çarpanı ve iki bağımsız ölçümü karşılaştırmak için kök-iki faktörüyle birleştirilmesi yaklaşık %89'luk bir gürültü sınırı üretiyor — bu, gözlemlenen her iki salınımından da çok büyük, dolayısıyla %27'lik sıçramaya dair dürüst hüküm gerileme değil "kazanan yok" oluyor. Aynı mantıkla, 2. ve 3. çalışmaların karşılaştırması hiç değerlendirilemezdi, çünkü gürültüyü tahmin edecek yeterli tekrar henüz yoktu.

Sınırı daraltan iki kaldıraç var: tekrar sayısı — t çarpanı serbestlik derecesiyle hızla düşer (2 sd'de 4,30, 5'te 2,57, 10'da 2,23) — ve production eşzamanlılığında alınan daha sessiz, daha uzun bir ölçüm. Production'a ulaşacak kararlar için yazı, taban çizgisi ve aday çalışmaları iç içe geçirmeyi öneriyor — taban, aday, taban, aday — böylece kayma her iki tarafı da eşit etkiler. Yazarın güncük rutini şöyle: değişmeyen yapılandırmayı aynı gün üç kez çalıştır, tek bir şeyi değiştir ve bir farka ancak kalibre edilmiş gürültü sınırını aştığında ve güven aralıkları örtüşmediğinde güven.

Uyarılar

Deney, 3B parametreli bir model, kısa iş yükleri ve varsayıma dayalı bir GPU ücretiyle bir dizüstü bilgisayarda yapıldı; bu yüzden salınımın büyüklüğü o makineye ve o sabaha özgü. Yazar, diğer sunucuların ödünç alınamayıp ölçülmesi gereken kendi gürültülerinin olacağını açıkça belirtiyor. Ölçüm aracı olan Throttle adlı açık kaynaklı CLI, çalışmalarda özdeş promptları tekrarladı; yazıya göre bu, prompt-cache etkilerini burada dışlıyor çünkü önbellek dört çalışmada da sıcaktı; 0.4.1 sürümünden itibaren araç istekleri etiketliyor, böylece bir prefix cache sonraki ölçümleri yapay olarak ucuz gösteremiyor.

Neden önemli

LLM inference için bütçe planlayan veya optimizasyon yapan herkes kararlarını öncesi/sonrası sayılardan verir: yeni bir serving bayrağı, quantize edilmiş bir model, farklı bir yığın. Bu yazı, sıradan donanımda bu karşılaştırmaların ölçüm gürültüsü tarafından boğulabileceğini ve çalışma içi klasik güven aralıklarının sahte bir güven uyandırabildiğini gösteriyor — örtüşmeyen bir %27'lik gerileme yoktan belirdi. Herhangi bir farka güvenmeden önce çalışmadan çalışmaya gürültü tabanını kalibre etmek ucuzdur ve bunu atlamak iyi değişiklikleri geri alma ya da var olmayan tasarruflar duyurma riski taşır.