MAPLE'ın 6 GB GPU'da 26B LLM'i 45 tok/s iddiası nasıl doğrulanır

İddia

dev.to'daki bir rehber, MAPLE adlı açık kaynak projeden göz alıcı bir benchmark'ı yakından inceliyor; proje, budanmış bir Gemma 4 26B-A4B modelini 6 GB VRAM'li bir RTX 4050 dizüstü GPU'sunda saniyede 45,4 token çalıştırdığını bildiriyor. Projenin deposuna göre model 4,75 GB'lık bir GGUF dosyasına sıkıştırılmış, 30 katmanın tamamı VRAM'de tutuluyor ve yalnızca 30 katmandan 16'sını GPU'da tutabilen orijinal modelin saniyede 6,9 token hızıyla karşılaştırılıyor.

dev.to yazarı kaynağa dikkat ediyor: bunlar projenin kendi ölçümleri ve rehber, MAPLE'ı çalıştırdığını ya da benchmark'ını yeniden ürettiğini iddia etmiyor. Savunulan düşünce, doğru tepkinin ne reddetmek ne de tekrarlamak,而是 sayıların gerçekte neyi ölçtüğüne dair yapılandırılmış bir denetim yapmak olduğu.

Depo ne bildiriyor

README, GGUF biçiminde budanmış 48-uzmanlı bir container'ı ve 6.144 MiB'lik GPU üzerinde 2.048 token'lık bağlam ve scratch buffer'lar dahil toplam 4.820 MiB'lik runtime tahsisini açıklıyor. dev.to yazısı, başlıktaki karşılaştırmadaki bir asimetriye dikkat çekiyor: MAPLE tamamen VRAM'de çalışırken taban model katmalarının çoğunu GPU belleğinin dışına taşıyor; dolayısıyla sonuç, iki eşdeğer model arasındaki aynı kaynaklı bir yarıştan çok dağıtım davranışına işaret ediyor.

README'deki kalite kanıtları dört görevi kapsıyor — Fibonacci, bir ikili arama ağacı, Rayleigh saçılması ve silojistik mantık — çoğunlukla anahtar kelime isabet oranlarıyla puanlanmış, üretilen bir Fibonacci fonksiyonu için tek bir işlevsel doğrulama var. Proje modelini Python programlama, algoritmalar, veri yapıları ve resmi STEM akıl yürütmeye Scoped ediyor. Depo Apache-2.0 lisansı taşıyor, ancak rehber, taban modelin kendi şartlarının farklı olabileceğine ve ticari kullanım öncesi ayrıca kontrol edilmesi gerektiğine değiniyor.

İddiayı üç soruya bölün

Rehberin çerçevesi herhangi bir yerel model iddiasını bağımsız parçalara ayırıyor: artifact'ın hiç yüklenip yüklenmediği — yani dosya boyutu, runtime uyumluluğu, kullanılabilir bellek ve GPU'da yerleşim kontrolü; ne kadar hızlı ürettiği — prompt işleme ve çıktı, belirtilen bağlam ve iş yükü altında ayrı ayrı ölçülerek; ve amacına uygun işi hâlâ yapıp yapmadığı — orijinale veya güvenilir bir taban çizgisine karşı. Bir hız benchmark'ı yalnızca ikinci soruyu yanıtlar ve bir bellek ekran görüntüsü de birincinin yalnızca bir kısmını.

Bir çalışma manifesti kaydedin

Herhangi bir şeyi ölçmeden önce koşulları kaydedin: GPU ve VRAM, sürücü ve işletim sistemi, runtime sürümü ya da commit'i, model dosyasının görünen adı değil SHA-256 karması, biçim ve quantization, bağlam uzunluğu, offload edilen katmanlar, üretim ayarlarıyla birlikte prompt seti ve güç modu ile arka plandaki GPU iş yükleri. Rehbere göre model kimliği ve runtime revizyonu olmadan bir sonuç fiilen yeniden üretilemez.

Hız karşılaştırmasını adil yapın

İki modeli iki yapılandırma altında test edin: her modelin aynı donanımdaki ulaşılabilir en iyi kurulumu ve aynı runtime, prompt'lar, bağlam uzunluğu, üretim uzunluğu ve örnekleme ayarlarını kullanan eşleştirilmiş bir yapılandırma. Bir model katmanlarını sistem belleğine taşıyorsa, sonuç saf bir model hız karşılaştırması yerine bu bellek kısıtları altındaki hız olarak etiketlenmeli.

Her prompt'u birkaç kez çalıştırın ve model yükleme ile ısınma içerebilecek ilk çalışmayı, kararlı durum üretiminden ayırın. Prompt işleme hızını ve üretim hızını, ilk token'a kadar geçen süre, toplam çıktı token'ları ve zirve GPU belleğiyle birlikte ayrı ayrı raporlayın — tek bir saniyedeki token ortalaması, acı verici derecede yavaş bir başlangıcı ya da yalnızca kısa prompt'larla iyi performans gösteren bir iş yükünü gizleyebilir.

Kaliteyi gerçek iş üzerinde test edin

Dört prompt'luk bir demo bozuk bir indirmeyi yakatmaya yeter, benimsenmeyi gerekçelendirmeye yetmez. Rehber, ekibin kullanmasına izin verilen gerçekçi, hassas olmayan örneklerden küçük bir test seti oluşturmayı öneriyor: kod tamamlama, testler çalıştırılarak doğrulanan hata düzeltme, atıf yapılan satırlarla yanıtlanan depo soruları, boş veya hatalı biçimli girdi gibi uç durumlar ve gerekli bir çıktı biçimine karşı kontrol edilen talip takibi. Geçme koşulları modelin çıktısı görülmeden önce tanımlanmalı ve çalıştırılabilir testler anahtar kelime eşleştirmesinden iyidir. İki taban çizgisi tutun — orijinal model ve belleğe rahatça sığan daha küçük bir model — çünkü pratik soru, sıkıştırılmış modelin görevlerinizi o bellek ve gecikme bütçesinde daha güvenilir çözüp çözmediğidir.

Perplexity bir teşhis aracıdır, hüküm değil

llama.cpp belgeleri, perplexity'nin farklı tokenizer'lara sahip modeller arasında doğrudan karşılaştırılamayacağı ve ince ayarlı modellerin daha yüksek perplexity puanı alırken insan değerlendirmesinde daha iyi çıktı üretebileceği konusunda uyarıyor. Rehber, bunu görev geçme oranları, çalıştırma testleri, çıktı biçimi kontrolleri ve temsili çıktıların insan incelemesinin yanında tek bir sinyal olarak ele almayı öneriyor.

Neden önemli

İddia doğru çıkarsa, 26B sınıfı modeller giriş seviyesi dizüstü GPU'larda pratik hale gelir ve bu, insanların zaten sahip olduğu donanımda yerel AI hesabını değiştirir. dev.to yazısının kalıcı değeri yöntemin kendisi: budanmış ve quantize edilmiş modeller için gösterişli benchmark'lar görünmeye devam edecek ve yeniden üretilebilir koşullar, dürüstçe etiketlenmiş karşılaştırmalar ile iş yüküne özgü kalite testleri bir demoyu dağıtabileceğiniz bir şeyden ayıran şeydir. Bağımsız bir tekrarlama ortaya çıkana kadar saniyede 45,4 token projenin kendi sayısı olarak kalıyor.