LLM Kendi Kendine Barındırma için VRAM Hesaplayıcı

Bir LLM'yi kendi kendine barındırmak, çıkarımı operatörün kontrol ettiği donanımda, üçüncü taraf bir API aracılığıyla değil, çalıştırmak anlamına gelir; bu da maliyeti, veri kontrolünü ve gizlilik profilini değiştirir. Bir modelin hiç çalışıp çalışmayacağı belleğe bağlıdır.

LLM Uyumluluk Hesaplayıcı

Hesaplayıcı, modele, hassasiyetine, bağlam uzunluğuna ve hedef donanıma bağlı olarak bir modelin yerel olarak çalıştırılması için gereken VRAM veya birleşik belleği tahmin eder. Bir yapılandırmanın sığıp sığmadığını, ağırlıklar, KV cache ve ek yük arasında bellek dağılımını ve belirli bir GPU veya Mac'in çalıştırabileceği modelleri döndürür. Kuantalama formatları ve hassasiyet genişlikleri Hugging Face Transformers belgelerini takip eder. ¹

Bu tahminlerin arkasındaki tüm matematiği görmek için kendi kendine barındırılan LLM VRAM hesaplama metodolojimize bakın.

Kendi kendine barındırma için donanım: GPU'lar ve Apple Silicon

Donanımı iki sayı belirler. Kapasite uyum kapısıdır ve çözme, bellek bant genişliğine bağlıdır; bu nedenle saniyedeki token sayısı kabaca kartın GB/s değeriyle ölçeklenir.

Yukarıdaki satırlar her seviyeyi örneklemektedir. Hesaplayıcı toplamda 34 kart içerir; A100, L40S, RTX A6000, AMD Radeon RX 7900 XTX ve AMD Instinct serisini de ekler. 24 ila 32 GB'de, bir 70B model ağır kuantalama artı kısa bağlam veya iki kart gerektirir. Bir 671B model standart minimum olarak 640 GB (8×80 GB) gerektirir. RTX PRO 6000, en üst düzey iş istasyonu sınıfı tek karttır ve sokak fiyatı, yaklaşık $13,000'e 2026 ortasına kadar, bir $8,565 MSRP'den yükseldi.²

Apple Silicon ve birleşik bellek: Apple Silicon'da, CPU ve GPU tek bir bellek havuzunu paylaşır ve GPU varsayılan olarak toplam RAM'in yaklaşık %75'ine Metal’in recommendedMaxWorkingSetSize aracılığıyla erişir; küçük Mac'lerde biraz daha düşüktür. Üst sınır, macOS için 8 ila 16 GB bırakarak sudo sysctl iogpu.wired_limit_mb= ile yükseltilebilir. ^{3 4} Bir 128 GB Mac, yaklaşık 96 GB'ı GPU'ya sunar. En fazla 512 GB'a sahip M3 Ultra, yaklaşık 384 GB sunar; bu, 4-bit'te KV boşluk payıyla, bir 400B sınıfı model için, tek bir cihazda çoklu GPU çoğaltma vergisi olmadan yeterlidir. ⁵ Büyük modeller için bu tek cihazlı yol Apple'ın avantajıdır; ancak AMD Strix Halo (128 GB) ve NVIDIA DGX Spark (128 GB) artık ucuz büyük birleşik bellek de sunmaktadır. ⁶

LLM servis motorları

Servis motoru seçimi, tek bir en iyi araç yerine iş yüküne göre ayrılır. Üretim sunum motorları, veri merkezi GPU'larında birçok eşzamanlı kullanıcı için sayfalı dikkat ve sürekli toplu işleme kullanırken, yerel öncelikli çalışma zamanları masaüstü, dizüstü veya tek bir GPU'da tek bir kullanıcıyı hedefler. Fark yük altında ortaya çıkar. 64 eşzamanlı istekte, vLLM, llama.cpp'den yaklaşık 44 kat daha fazla saniyede token sundu; llama.cpp'nin ilk token süresi 3 dakikayı aştı. Tek bir kullanıcı için ikisi karşılaştırılabilir. ⁷

Hesaplayıcı, iki kamp genelinde sekiz motoru modeller:

Üretim katmanında, SGLang’ın RadixAttention'ı istekler arası önekleri yeniden kullanır, TensorRT-LLM motor oluşturulduğunda aktivasyon bütçesini dondurur ve LMDeploy, InternLM, Qwen ve DeepSeek için W4A16 ve MXFP4'ü maliyet etkin şekilde sunar. ⁸ Yerel tarafta, TabbyAPI'li ExLlamaV2, bir kartı tam olarak doldurmak için kesirli ortalama bit genişliğini ayarlar ve MLX, Apple birleşik belleğini kullanır, böylece toplam RAM bütçe olur. Hugging Face TGI tek çıkıştır. Aralık 2025'te bakım moduna geçti ve GitHub deposu 21 Mart 2026'da (salt okunur) arşivlendi; kullanıcılar vLLM, SGLang ve llama.cpp'ye yönlendirildi. ^{9 10}

Çoğu insan bu motorlarla, onları saran son kullanıcı uygulamaları aracılığıyla tanışır. Ollama, LM Studio ve AnythingLLM, llama.cpp üzerinde çalışır (LM Studio ayrıca MLX'te), tek komutla modeller, OpenAI uyumlu localhost API ve AnythingLLM için PDF'ler ve kod tabanları üzerinde belge RAG'ı ekler. GitHub yıldızlarına göre, 2026-07-11 itibarıyla kaba bir benimseme göstergesi olarak, Ollama 175.925'e, vLLM 85.979'a sahiptir (her ikisi de açık kaynak) ve AnythingLLM 63.120. LM Studio'nun 5.053 yıldızı, kapalı kaynak uygulamasından değil, açık kaynak CLI deposundan (lmstudio-ai/lms) gelir; bu nedenle gerçek masaüstü benimsemesini olduğundan az gösterir. ^{11 12 13 14}

Etkileşimli bir ortam bileşeni bu araçları kullanım durumlarına eşler. Entegrasyonlar ve geniş uyumluluk Ollama'ya, geliştiriciler ve yüksek performans vLLM'e, yerel RAG uygulamaları AnythingLLM'e ve yeni başlayan dostu denemeler LM Studio'ya gider.

Açık kaynak büyük dil modelleri

Açık ağırlıklı modeller mimarilerini ve ağırlık dosyalarını yayınlar; böylece herkes genellikle Hugging Face'ten indirip değiştirebilir ve çalıştırabilir. 2026 ortası kendi kendine barındırılabilir sınır, Qwen2.5 ve Llama-3 döneminin çok ötesine geçmiştir:

Toplam ve aktif sütunlar arasındaki fark taşıyıcıdır. Toplam parametreler belleği ve GPU sayısını belirler; aktif parametreler ise hesaplamayı belirler. DeepSeek-V4-Flash ve GLM-5.2 2026'da açık ağırlıklar olarak geldi; Gemma 4 aileyi Apache 2.0 altında yeniden lisansladı ve GPT-OSS, MoE uzmanlarını yerel MXFP4'te sunar. ^{15 16 17 18 19}

Özel amiral gemileri (OpenAI’nın GPT-5.6'sı, Google’ın Gemini 3.1 Pro'su, Anthropic’in Claude Opus 4.8'i, xAI’nin Grok 4.5'i) indirilemez veya kendi kendine barındırılamaz; bunlar yalnızca API'dir, genellikle OpenAI uyumlu bir endpoint'in arkasındadır. Yalnızca yerel bir dağıtım, bu modellerin belirli bir görevde daha iyi yaptığı her şeyden vazgeçer. ^{20 21 22}

Kuantalama ve MoE boyutlandırma

Kuantalama, 2026'da eğitimden sonra ağırlıkları yuvarlamaktan çok, tasarım gereği düşük bitli olarak sunulan kontrol noktaları ve kuantalama devreye girmeden önbelleği azaltan mimari seçimlerle ilgilidir.

Yerel düşük bitli kontrol noktaları: Öncü açık modeller giderek kuantalama farkındalıklı olarak sunuluyor. GPT-OSS, MoE uzmanlarını MXFP4 (paylaşılan 8 bit ölçekli E2M1, parametre başına 4.25 bit) ile sunar; böylece 120B, yaklaşık 63 GB'a sığar, yani tek bir 80 GB GPU'ya; saf bir BF16 tahmini ise üç GPU genelinde yaklaşık 234 GB talep ederdi. DeepSeek-V3 ve R1, parametre başına yaklaşık 1 bayt olacak şekilde yerel FP8 sunar. Ağırlıklar, parametre sayısına göre değil, kontrol noktasının gerçek dtype'ına göre boyutlandırılmalıdır. ^{23 24}

GGUF etkin bit tuzağı: GGUF dosyaları hassasiyeti karıştırır; blok başına FP16 ölçekleri ve kuantlanmamış gömme ve çıktı tensörleri vardır; bu nedenle isim, boyuttan ziyade bir alt sınırdır. Q4_K_M yaklaşık 4.9 etkin bittir (parametre başına 0.61 bayt), 4.0 değil. Q8_0 8.5 bittir (parametre başına 1.06 bayt), 8.0 değil. Bit sayısına göre çalışan bir hesaplayıcı, ağırlıkları Q4'te yaklaşık %20 ve Q8'de %6 eksik boyutlandırır. IQ4_XS gibi IQ kuantaları (yaklaşık 4.25 bit) artık daha küçük boyutta Q4_K_M kalitesiyle eşleşir. ²⁵

KV önbellek kuantalaması: KV dtype'ını düşürmek tüm önbelleği doğrusal olarak ölçeklendirir ve ağırlık hassasiyetinden bağımsızdır. FP8 (e4m3) KV bunu yarıya indirir (Llama-3-8B 128k bağlamda, batch 1, 16.0 GiB BF16'dan 8.0 GiB FP8'e) ve geniş ölçüde ücretsiz kalitededir. INT4 bunu dörtte bire indirir ancak bir değerlendirme gerektirir. vLLM'de bu tek bir bayraktır (--kv-cache-dtype fp8). ²⁶

Bellek tasarrufu sağlayan dikkat: Çok başlı Gizli Dikkat (MLA, DeepSeek tarafından kullanılır), baş başına anahtarlar ve değerler yerine tek bir paylaşılan düşük dereceli gizli temsili (katman başına token başına yaklaşık 576 öğe) önbelleğe alır; bu, nominal 128 başlı okumadan yaklaşık 30 kat daha küçüktür. Bir 671B modelin 128k bağlamı yaklaşık 8.6 GiB KV ile sunmasını sağlayan şey budur. Kayan pencere ve yerel-küresel dikkat (Gemma 2 ve 3, GPT-OSS, Llama 4), çoğu katmanı tam bağlam yerine sabit bir pencereyle sınırlar; uzun bağlam KV'sini saf tam küresel tahmine kıyasla 10 ila 40 kat azaltır. Bunlar ayarlanabilir parametreler değil, mimari ailesine göre sabittir. ²⁷

Yük boşaltma ve parçalama: Ağırlıklar GPU belleğini aştığında, yük boşaltma, kullanılmayan MoE uzmanları gibi etkin olmayan parçaları GPU belleği ile daha yavaş sistem RAM'i arasında taşır; bu, hiç çalıştırma yeteneği karşılığında saniyede token sayısından ödün verir. ²⁸ Parçalama, bir modeli birkaç cihaza veya bellek katmanına böler; bu, bir 671B modelin 8-GPU'lu bir düğüme yayılmasını sağlar. Her ikisi de sabit donanımın erişimini bant genişliği maliyetiyle genişletir.

Kendi kendine barındırmanın faydaları ve ödünleşimleri

Kendi kendine barındırmanın gerekçesi veri kontrolü, hacimde maliyet ve yapılandırma özgürlüğüdür. Karşı gerekçe ise donanım maliyeti, operasyonel yük ve özel model açığıdır.

Veri ikameti ve uyumluluk: Sınır ötesi veri aktarımı uyumluluğun itici gücüdür. GDPR kapsamında, kişisel verilerin AB dışına gönderilmesi yasal koruma önlemlerini, sözleşme yükümlülüklerini veya kısıtlamaları tetikleyebilir. AB Yapay Zeka Yasası ikinci bir katman ekler, ancak tam olarak yürürlükte olmak yerine kademeli olarak devreye giriyor. 2026 ortası itibarıyla, yasaklar (2 Şubat 2025'ten beri geçerli) ve genel amaçlı yapay zeka (GPAI) model yükümlülükleri (2 Ağustos 2025'ten beri) halihazırda uygulanmaktadır; risk yönetimi, denetlenebilirlik ve yönetişimle ilgili yüksek riskli gereklilikler ise 2025-26 Dijital Omnibus paketi kapsamında, Ek III bağımsız yüksek riskli sistemler için 2 Aralık 2027'ye ve Ek I gömülü sistemler için 2 Ağustos 2028'e ertelenmiştir. ^{29 30 31} Yargı alanı içinde, kontrollü bir ağda çıkarım çalıştırmak, hassas verileri üçüncü tarafların elinden uzak tutar; bu da finans, sağlık ve kamu sektörü için egemen yapay zeka gerekçesidir.

Maliyet ve kontrol: Kendi kendine barındırma, tüketici GPU'ları veya küçük bir sunucuyla pahalı başlar; ancak yerel çıkarım, yüksek istek hacmi üreten ekipler için yinelenen API ücretlerini düşürebilir. Ayrıca satıcı bağımlılığını ve bağlam penceresi, çıkarım ayarları ve entegrasyon üzerindeki dayatılan sınırları ortadan kaldırır ve özel veriler üzerinde ince ayar için ağırlıklara doğrudan erişim sağlar.

Ödünleşimler: GPU belleği bağlayıcı sınırdır ve bazı iş yükleri hâlâ 16 ila 48 GB VRAM gerektirir; bu, küçük ekipler için erişilemezdir. Dağıtım, bağımlılık yönetimi, CUDA ve çekirdek sorun giderme, izleme ve normalde bir bulut sağlayıcısının üstleneceği güncellemeleri ekler. Performans, toplu işleme ve parçalamadan donanım kullanımına kadar operatörün sorumluluğundadır. Ve en güçlü özel modeller yalnızca API olarak kalır; bu nedenle yerel bir dağıtım, onların önde olduğu görevlerde bir yetenek açığını kabul eder.

Kıyaslamalarımızı ve veri odaklı içgörülerimizi kaçırmayın. Düğme Google'ı açar; AIMultiple'ı seçmeniz, Google arama sonuçlarında AIMultiple'ı daha sık görmek istediğinizi onaylar.

Tercih edilen kaynak olarak ekle

Kendi kendine barındırılan LLM VRAM hesaplama metodolojisi

Bir modelin bellek ayak izi, parametre sayısından ölçeklenen tek bir rakam değil, bağımsız olarak hesaplanan ve toplanan dört terimin toplamıdır:

VRAM_total = Weights + KV cache + Activations + Overhead

En yaygın tahmin hatası, son üç terimi ağırlıklar üzerinde sabit bir %20 işaretlemesine indirger. Bu, bir model boyutunda yakındır ve diğerlerinde yanlıştır çünkü üç terim farklı ölçeklenir. ³²

Ağırlıklar: Ağırlık belleği, parametre sayısı çarpı parametre başına bayttır. BF16 ve FP16, parametre başına 2.0 bayt depolar; FP8 ve INT8 ise yaklaşık 1.0 depolar. Tuzak 4-bittir; bu, parametre başına 0.5 bayt değildir. Gerçek gruplandırılmış INT4 (GPTQ, AWQ) 0.52 ila 0.55 arasındadır ve GGUF Q4_K_M parametre başına yaklaşık 0.61 bayttır (4.9 etkin bit, 4.0 değil). GGUF Q8_0 8.5 bittir (parametre başına 1.06 bayt), 8.0 değil. 0.5 varsayımı, bir 70B modeli yaklaşık 8 GB eksik sayar ve bu da uyum kararını tersine çevirir. ²⁵

Uzman karışımı, aktif olanları değil her uzmanı boyutlandırır: Tüm uzman ağırlıkları, token başına yalnızca birkaçı ateşlense bile VRAM'de yerleşik kalır. Mixtral-8x7B, Q4'te yaklaşık 28 GB gerektirir; tam 46.7B parametre için, 13B aktif olanı değil. Toplam parametreler belleği ve GPU sayısını belirler; aktif parametreler hesaplamayı belirler. Aktif parametrelere göre boyutlandırma yapan bir hesaplayıcı, büyük MoE modellerini yanlışlıkla uygun gösterir.

KV önbellek: Anahtar-değer önbelleği 2 x n_layers x n_kv_heads x head_dim x seq_len x batch x bytes_per_element şeklindedir. Mevcut modellerin çoğu, birçok sorgu başının birkaç KV başını paylaştığı gruplanmış sorgu dikkati (GQA) kullanır; bu nedenle n_kv_heads çiftleri önbelleğe alınır ve bu, tam çok başlı dikkate kıyasla önbelleği Llama-3-8B için 4 kat, Llama-3-70B için 8 kat küçültür. Hem head_dim hem de n_kv_heads, gizli boyut ve baş sayısından türetilmek yerine her modelin config.json dosyasından okunur; çünkü Gemma (head_dim 256) ve Qwen3 (128) gibi aileler aksi takdirde yaklaşık 2 kat yanlış boyutlandırılırdı. Önbellek, hem bağlam uzunluğu hem de batch boyutu ile doğrusal olarak büyür ve uzun bağlamda ağırlıklara rakip olur veya onları aşar. Llama-3-8B, token başına 128 KiB önbelleğe alır; bu nedenle 128k bağlamda ve batch 1'de bir FP16 KV önbelleği 16.0 GiB'dir; bu, 16 GB BF16 ağırlığa eşittir. Bir FP8 KV önbelleği bunu yarıya indirir. ³³

Ek yük bir tabandır, yüzde değildir: Çerçeve ek yükü, GPU başına sabit bir tabandır (CUDA bağlamı ve çekirdekler, GPU başına yaklaşık 1 ila 2 GB) artı küçük sınırlı bir kesirdir; ağırlıkların bir payı değildir. Sabit bir %20 oranı, yalnızca CUDA bağlamının 6 GB'lık bir modelin %20'sini aşabildiği küçük modelleri eksik sayar; 140 GB'lık bir modelin 28 GB bağlam gerektirmediği büyük modelleri ise fazla sayar. Parçalı taban doğru modeldir ve sabit %20 hızlı bir tahmin olarak işe yarar. ³⁴

Aktivasyonlar ve servis motoru: Aktivasyon terimi geçicidir. Çözme sırasında, bir seferde bir token olarak küçüktür ve ek yük tabanına katlanır; ancak ön doldurma tüm prompt'lar bir kerede işler, bu nedenle aktivasyon zirvesi batch boyutu ve prompt'lar uzunluğu ile ölçeklenir. Tabanın kendisi motora bağlıdır. Sayfalı sunucular (vLLM, SGLang), bellek kullanımı ayarı aracılığıyla her kartın sabit bir payını, yaklaşık %10 (varsayılan 0.90'da) olarak ayırır ve ağırlıkları ve KV'yi geri kalanına sığdırır. Sayfasız çalışma zamanları (llama.cpp, Ollama) bunun yerine yaklaşık 1 ila 2 GB'lık sabit bir hesaplama tamponu tutar. Her ikisini aynı şekilde boyutlandırmak birkaç GB yanıltır.

Çoklu GPU'lar temiz bölünmez: İki 24 GB kart, 48 GB kullanılabilir alan değildir. Tensor paralelliği altında ağırlıklar ve KV önbelleği N karta bölünür (W/N ve KV/N), ancak aktivasyonlar, CUDA bağlamı ve NCCL iletişim tamponları her kartta çoğaltılır; bu nedenle toplam ayak izi, aynı toplamın tek cihazlı tahmininden daha büyüktür. Bu çoğaltma vergisi, 70B'lik bir modelin 43 GB ağırlık gerektirmesine rağmen kısa bağlamla iki 24 GB karta sığmasının ve güvenli kontrolün, toplamın GPU sayısına bölünmesi yerine GPU başına toplam olmasının nedenidir.

Dört terim uyum sınırında etkileşir. Bir yapılandırma, gerekli bellek kullanılabilir belleğin %90'inin altında veya eşitinde olduğunda 'Fits' (Uyar), kapasitenin en üst %10'inde olduğunda 'Tight' (Gergin) ve kullanılabilirliğin üzerinde olduğunda 'Won’t-fit' (Uymaz) olarak okunur. Sayfalı sunucular, kullanım ayarı aracılığıyla bu %10'i zaten geri tutar. Aşağıdaki örnekler, tüketici kartlarında llama.cpp ile birlikte Llama-3 kullanır:

128k bağlamda KV önbelleği ağırlıklara eşittir; bu nedenle uyumu bağlam uzunluğu belirler, parametre sayısı değil. Son satır uyar çünkü Q4 ağırlıkları (~405 GB) 8k bağlamda 640 GB'ın altındadır. MLA'nın getirisi uzun bağlamdadır; burada bir 671B modelin KV'sini 128k sunacak kadar küçük tutar.

Daha fazla okuma

• LLM Kuantalama: BF16 vs FP8 vs INT4
• LLM Çıkarım Motorları: vLLM vs LMDeploy vs SGLang
• GPU Eşzamanlılık Karşılaştırması: H100 vs H200 vs B200 vs MI300X
• Çoklu GPU Karşılaştırması: B200 vs H200 vs H100 vs MI300X
• En İyi 60+ Bulut GPU Sağlayıcısı
• Bulut LLM vs Yerel LLM'ler
• LLM Fiyatlandırma: Karşılaştırılan En İyi 15+ Sağlayıcı
• LLM Kurumlar için İnce Ayar Rehberi

SSS'ler

Bu araştırmayı kaynak gösterin

Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{LLM Kendi Kendine Barındırma için VRAM Hesaplayıcı}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/self-hosted-llm}},
  note   = {AIMultiple. Erişim tarihi: 31 Ağustos 2026}
}

Değişiklik günlüğü

3 güncelleme

1. 202612 Tem

   Kendi kendine barındırılan LLM VRAM hesaplama metodolojisi bölümü eklendi.

2. 26 Oca

   Avantajları bölümüne Gizlilik ve uyumluluk adında bir bölüm eklendi.

3. 20254 Ara

   Girişe en iyi 4 kendi kendine barındırılan araç listesi eklendi.

Referans Linkleri

1.

Overview · Hugging Face

2.

RTX 5090 vs RTX PRO 6000 Blackwell: Consumer vs Pro GPU for AI (2026) | Spheron Blog

Spheron

3.

recommendedMaxWorkingSetSize | Apple Developer Documentation

4.

Adjust VRAM/RAM split on Apple Silicon · ggml-org/llama.cpp · Discussion #2182 · GitHub

5.

Apple reveals M3 Ultra, taking Apple silicon to a new extreme - Apple

Apple

6.

Personal AI Supercomputer Powered by Blackwell | NVIDIA DGX Spark

7.

llama.cpp vs. vLLM: Choosing the right local LLM inference engine | Red Hat Developer

Red Hat

8.

vLLM, Ollama, LM Studio, llama.cpp: Choosing the best LLM inference engine in 2026 [ Updated ] | BIZON

BIZON

9.

GitHub - huggingface/text-generation-inference: Large Language Model Text Generation Inference · GitHub

10.

Migrate from Hugging Face TGI to vLLM or SGLang on GPU Cloud: A 2026 Move-Off Guide | Spheron Blog

Spheron

11.

GitHub - lmstudio-ai/lms: LM Studio CLI · GitHub

12.

GitHub - ollama/ollama: Get up and running with Kimi-K2.6, GLM-5.2, MiniMax, DeepSeek, gpt-oss, Qwen, Gemma and other models. · GitHub

13.

GitHub - vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs · GitHub

14.

GitHub - Mintplex-Labs/anything-llm: Stop renting your intelligence. Own it with AnythingLLM. Everything you need for a powerful local-first agent experience · GitHub

15.

DeepSeek V4 Ships 1M Context, Open-Weights

WinBuzzer

16.

Gemma 4: Our most capable open models to date

Google

17.

New Released - Overview - Z.AI DEVELOPER DOCUMENT

Mintlify

18.

Qwen 3.5 to 3.8: Alibaba Open-Weights Guide (2026)

Codersera Blogs

19.

Welcome GPT OSS, the new open-source model family from OpenAI!

Hugging Face

20.

GPT-5.6: Frontier intelligence that scales with your ambition | OpenAI

21.

Introducing Claude Opus 4.8 \ Anthropic

22.

Introducing Grok 4.5 | SpaceXAI

xAI

23.

MXFP4 · Hugging Face

24.

OpenAI gpt-oss LLMs use MXFP4: smaller, faster, cheaper

theregister

25.

Which Quantization Should I Use? A Unified Evaluation of llama.cpp Quantization on Llama-3.1-8B-Instruct

26.

Quantized KV Cache - vLLM

27.

Decoding Multi-Head Latent Attention (Part 1): The KV Cache Memory Bottleneck, Solved.

Vizuara’s Substack

28.

https://arxiv.org/pdf/2312.17238

29.

EU Artificial Intelligence Act | Up-to-date developments and analyses of the EU AI Act

30.

EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes - Gibson Dunn

Gibson Dunn & Crutcher, LLP

31.

EU AI Act Update: Timeline Relief, Targeted Simplification, and New Prohibitions | Inside Privacy

32.

A Practical Guide to LLM Inference at Scale

The Neural Maze

33.

The State of FP8 KV-Cache and Attention Quantization in vLLM | vLLM Blog

vLLM

34.

How LLM Inference Works (Prefill, Decode & the GPU Memory Wall)

Into AI

Ekrem Sarı

Yapay Zeka Araştırmacısı

Takip Et

Ekrem, AIMultiple'da Yapay Zeka Araştırmacısı ve Veri Bilimcidir. Yapay zeka ve LLM sistemleri için uygulamalı benchmark'lar tasarlar ve yürütür.

Tam Profili Görüntüle

Yorum yapan ilk kişi olun

E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.

Ad

E-posta Adresi

Yorum

0/450

Yorumu Gönder