· kaynak dev.to (home feed)
Gemma 4 E2B QAT ağırlıkları tek bir SageMaker L4 üzerinde bf16'dan 2.05 kat daha hızlı decode ediyor
AWS Builders'ın dev.to üzerindeki benchmarkları, Gemma 4 E2B'nin QAT checkpoint'inin tek bir NVIDIA L4 SageMaker endpoint'inde saniyede 105.1 token decode ettiğini, bf16'ın ise 51.3 token'da kaldığını, kalitenin ise 37/40 ile değişmediğini gösteriyor.

SageMaker üzerinden Gemma 4 sunumu
AWS Builders ekibinin dev.to üzerindeki iki eş yazısı, Google'ın Gemma 4 E2B modelini Amazon SageMaker üzerinde çalıştırmanın ve ardından kendi quantize edilmiş checkpoint'iyle karşılaştırmanın tam bir reçetesini sunuyor. Model, AWS'nin SageMaker için sürdürdüğü vLLM imajı kullanılarak bir SageMaker real-time endpoint — bir container'ı GPU instance'ına yerleştiren, sağlık kontrolü yapan, istekleri yönlendiren ve logları CloudWatch'a gönderen yönetilen HTTPS inference servisi — üzerinden sunuluyor. Donanım, us-east-2 bölgesindeki bir ml.g6.xlarge instance üzerinde 24 GB belleğe sahip tek bir NVIDIA L4; vLLM 0.30.0 çalışıyor. Gemma 4 Apache-2.0 lisanslı ve Hugging Face üzerinde gated olmadığından ağırlıkları indirmek için token gerekmiyor.
Her altyapı adımı düz bir aws CLI komutu ve eşlik eden Python MCP sunucusu bu komutları Claude Code veya Gemini CLI'nin stdio üzerinden kullanabileceği on bir araç olarak sunuyor. Her araç read-only, write veya destructive olarak etiketlendiğinden bir istemci status sorgusuyla teardown'ı ayırt edebiliyor; test paketi aws subprocess'ını bir stub ile değiştirerek kimlik bilgisi olmadan çevrimdışı çalışıyor. Bir instance yerleştirildikten sonra endpoint yaklaşık on dakikada InService durumuna ulaşıyor.
Checkpoint değiştirmek tek bir değişken
İkinci yazı endpoint'i sabit tutuyor ve tek bir ortam değişkenini, SM_VLLM_MODEL'i değiştiriyor: bf16'daki google/gemma-4-E2B-it modelinden google/gemma-4-E2B-it-qat-w4a16-ct modeline geçiliyor. Google modeli dört quantization-aware trained biçiminde yayımlıyor, ancak yazıya göre yalnızca w4a16 compressed-tensors varyantı — 4-bit ağırlıklar, 16-bit aktivasyonlar — vLLM'de yükleniyor. Diğerleri tasarruf sağlamadan 16-bit olarak depolanıyor, llama.cpp ve Ollama gibi GGUF runtime'larını hedefliyor ya da on-device formatlarında geliyor. SageMaker JumpStart yedi hazır Gemma 4 paketi listeliyor ama hiçbiri QAT değil; bu yüzden genel vLLM container yolu tercih edilmiş.
Ölçülen sonuç
Her iki checkpoint aynı bölgede aynı instance tipinde art arda çalıştı. Yazarın bildirdiği farklar:
- Decode hızı: QAT için saniyede 105.1 token, bf16 için 51.3 token; 2.05 kat iyileşme.
- 16 eşzamanlı istekte throughput: saniyede 1077.25'e karşı 619.1 token (1.74 kat); 1 ve 4 istekte kazançlar 1.87 ve 1.92 kat.
- GPU belleğindeki ağırlıklar: 8.01 GiB'a karşı 9.75 GiB; %18 azalma.
- KV cache: 867.999 token'a karşı 723.484; yaklaşık 1.2 kat daha fazla yer.
- Model yükleme süresi: 66.19 saniyeye karşı 82.75 saniye.
- Kalite: her iki checkpoint 40 sabit sorunun 37'sine doğru yanıt veriyor; yanıtların 35'i birebir aynı.
Bellek tasarrufu neden sadece %18
QAT export'u ağın yalnızca bir kısmını quantize ediyor. Yazıdaki checkpoint dosyası dökümüne göre transformer gövdesi — dosyanın %12,7'si — 4-bit olarak paketlenmişken, katman başına embedding (%56,5), vocabulary embedding (%19,4), audio tower (%7,4) ve vision tower (%4,1) BF16 olarak kalıyor. Bu yüzden öne çıkan 4-bit iddiası bütün modelde daha mütevazı bir tasarrufa karşılık geliyor ve boşa çıkan bellek artık headroom olarak bırakılmak yerine daha büyük bir KV cache'e harcanıyor.
Sayılar nasıl üretildi
compare.py betiği her iki endpoint'e temperature 0'da aynı invoke-endpoint çağrısıyla istek atıyor. Decode hızı, 16 ve 512 tokenlık sabit uzunluktaki üretimlerden beşer taneyle türetiliyor: medyan sürelerin farkına 496'yı bölmek CLI başlangıç maliyetini ve ağ gidiş-dönüşünü iptal ediyor. Throughput, her biri 256 token olan 1, 4 ve 16 eşzamanlı istekle, düzey başına iki batch halinde ölçülüyor. Kalite, 40 tam yanıtlı soru — 15 iki haneli çarpma, 15 üç sayılı toplama ve 10 başkent — ile regular expression üzerinden puanlanıyor.
Kota kapasite değildir
Yazılar pratik bir kısıtı da dile getiriyor: SageMaker endpoint kotası instance tipi ve bölge başına sayılıyor ve kapasite ayrı bir konu. Yazarın anlatımında us-east-1 ve us-west-2'deki L4 istekleri InsufficientInstanceCapacity döndürmeden önce yaklaşık yarım saat Creating durumunda beklerken, us-east-2 dakikalar içinde instance yerleştirdi. Endpoint config'indeki bir fallback instance havuzu kotayı tipler arasında koruyarak iki endpoint'in bir bölgenin tek-L4 payında çakışmasını önlüyor.
Neden önemli
Benchmark, quantization-aware training'in orta sınıf tek bir GPU üzerinde test setinde ölçülebilir bir kalite kaybı olmadan fiilen bedava bir decode hızı ikiye katlanması sağladığını gösteriyor. Açık model sunan herkes için bu oran doğrudan malete yansıyor, çünkü faturalanan birim instance-saat başına throughput. Yazı ayrıca yeniden kullanılabilir bir örüntü sergiliyor: tamamen CLI komutlarıyla sürülen yönetilen inference altyapısı, bir AI coding agent'ın stack'i deploy etmesini, doğrulamasını ve teardown etmesini sağlayacak şekilde MCP ile sarılmış; ayrıca gelecekteki checkpoint'leri değerlendirmek için kontrollü bir A/B metodolojisi. Ve yayımlanan bir kotanın kapasite garantisi olmadığı anımsatması da değerli — fallback bölgeleri ve instance tipleri post-mortem'e değil, deployment betiğine ait.
- #gemma
- #sagemaker
- #vllm
- #quantization
- #aws
- #mcp