Mimari ve çalışma modeli
Quantization, ağırlık ve bazen aktivasyon/KV cache değerlerini daha düşük hassasiyetle temsil ederek bellek ve bant genişliğini azaltır. FP16/BF16 çoğu GPU için temel üretim hassasiyetidir; INT8 ve INT4 daha yüksek sıkıştırma sağlar fakat kernel desteği, kalibrasyon ve kalite kaybı modele/donanıma bağlıdır.
Post-training quantization mevcut modeli kalibrasyon verisiyle veya weight-only yöntemle dönüştürür. Quantization-aware training düşük hassasiyet etkisini eğitimde simüle eder ve bazı işlerde kaliteyi koruyabilir. GPTQ, AWQ, bitsandbytes ve FP8 aynı şey değildir; ağırlık/aktivasyon kapsamı ve donanım kernel'i ayrı doğrulanır.
Kalite yalnız genel perplexity ile kabul edilmez. Türkçe görevler, uzun bağlam, kod, sayısal muhakeme, tool şeması ve RAG alıntısı gibi kullanım dilimleri karşılaştırılır. Bellek kazancı throughput'a dönüşmeyebilir; dequantization, uyumsuz kernel veya küçük batch darboğazı gecikmeyi artırabilir.
- 1FP16/BF16 referans model
- 2Quantization ve kernel seçimi
- 3Eş kalite ve yük benchmark'ı
- 4Artifact kaydı ve kontrollü dağıtım
Tasarım parametreleri
- Ağırlık alt sınırı
- 8B parametre için FP16 yaklaşık 16 GB, INT8 yaklaşık 8 GB, INT4 yaklaşık 4 GB ham ağırlık alt sınırıdır.
- Kalibrasyon seti
- Gerçek dil, domain, context uzunluğu ve çıktı biçimini temsil eden örnekler kullanın.
- Kernel uyumu
- GPU mimarisi, runtime ve quantization formatının desteklenen hızlı kernel'i gerçekten seçtiğini logdan doğrulayın.
- Kalite bütçesi
- Görev başarı, kritik hata, format uyumu ve güvenlik metriklerine ayrı maksimum düşüş belirleyin.
Hesap ve uygulama örneği
FP16 sürüm 23 GB toplam GPU belleği ve 12.000 token/s; INT4 sürüm 10 GB ve 18.000 token/s veriyor. Fakat Türkçe hukuk setinde doğruluk %91'den %84'e düşüyorsa %57 throughput artışı kritik kullanım için kabul edilmez; daha yüksek hassasiyet veya karma quantization denenir.
INT8 sürüm iki modeli aynı GPU'ya sığdırıp yoğunluk kazandırabilir. Ancak iki replica bellek bant genişliğini paylaşıp p95 TTFT'yi 600'den 980 ms'ye çıkarıyorsa yalnız 'sığdı' sonucu kapasite kanıtı değildir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
quantize build --model model.safetensors --method int8 --calibration eval/calibration-v3.jsonl
quantize bench --baseline bf16 --candidate int8 --trace traffic.jsonl
quantize gate --max-quality-drop 0.02 --max-ttft-p95-ms 900Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Bellek düştü, hız artmadı | Hızlı kernel seçilmemiş, dequantization veya CPU darboğazı vardır. | Runtime kernel logu, profiler ve batch/context dağılımını inceleyin. |
| Yalnız bazı görevler bozuldu | Kalibrasyon veri dağılımı veya hassas katmanlar yetersiz temsil edilmiştir. | Hata dilimlerini katman/quantization ayarıyla karşılaştırıp karma hassasiyet deneyin. |
| Başka GPU'da model açılmıyor | Format, compute capability veya runtime sürümü uyumsuzdur. | Artifact manifestindeki quantization yöntemi ve destek matrisiyle hedef donanımı eşleyin. |
Kabul ve doğrulama kontrolleri
- FP16/BF16 referans çıktıları ve performansını sabitleyin.
- Quantization artifact ve kalibrasyon veri sürümünü kaydedin.
- Gerçek görev dilimlerinde kalite regresyonu çalıştırın.
- Aynı trafik izinde TTFT, TPOT, token/s ve belleği ölçün.
- Hedef GPU/runtime kombinasyonlarında kernel seçimini doğrulayın.
- Canary sırasında kalite ve hata eşiğinde otomatik rollback sağlayın.
İlgili kavramlar
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.
Bağımlılık ve yeniden başlatma sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Hizmetlerin yeniden başlatılma sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.