Kendi sunucunuzda barındırabileceğiniz AI modelleri

Hangi yapay zeka modellerini kendi sunucunuzda barındırabileceğinizi ne belirler

Hangi yapay zeka modellerini kendi sunucunuzda barındırabileceğinizi tek bir değer belirler: sunucudaki RAM miktarı. Model ailesi ve kullanılan framework, ağırlıkların belleğe sığıp sığmadığından ve geriye boş alan kalıp kalmadığından çok daha az önemlidir. Bu yazı, bu hesaplamayı nasıl yapacağınızı açıklar. Bir çalışma zamanı (runtime) kurmak ayrı bir iştir ve VPS üzerinde Ollama çalıştırma rehberi içerisinde ele alınmıştır.

Kararı iki maliyet belirler. Ağırlıklar, parametre sayısı ve kuantizasyon (quantisation) ile belirlenen sabit maliyettir. Bağlam penceresi (context window) ise değişken maliyettir; dün yüklenen bir modelin bugün yüklenmemesinin temel sebebi, insanların bu maliyeti göz ardı etmesidir.

Boyutlandırma aritmetiği: parametre başına bit

Bir model dosyası neredeyse tamamen ağırlıklardan oluşur. Her ağırlık belirli bir bit sayısında saklanır. Kuantizasyon, ağırlıkları eğitildikleri hassasiyetten daha az bit ile saklamak anlamına gelir; bu işlem az miktarda doğruluk kaybına karşılık ciddi miktarda bellek tasarrufu sağlar. Boyut doğrudan bu değerden hesaplanır:

weights in GB = (parameters in billions x bits per weight) / 8

Modeller 16 bit olarak yayınlanır; bu da milyar parametre başına 2 GB demektir. Bu nedenle neredeyse hiç kimse yayınlanan hassasiyette bir VPS üzerinde çalıştırma yapmaz. Aşağıda, ağırlık başına gerçek ortalama bit değerleriyle birlikte karşılaşacağınız kuantizasyon türleri yer almaktadır:

• Q8_0 ağırlık başına yaklaşık 8.5 bit saklar, yani milyar parametre başına kabaca 1.1 GB.
• Q6_K yaklaşık 6.6 bit saklar, yani milyar başına kabaca 0.83 GB.
• Q5_K_M yaklaşık 5.7 bit saklar, yani milyar başına kabaca 0.71 GB.
• Q4_K_M yaklaşık 4.8 bit saklar, yani milyar başına kabaca 0.6 GB.

Çalışma değeriniz olarak milyar parametre başına 0.6 GB oranını kullanın. Bellek kısıtlı bir sunucuda Q4_K_M mantıklı bir varsayılan değerdir: 8 bite kıyasla kalite kaybı çoğu görevde düşüktür ve dosya boyutu neredeyse yarı yarıyadır. 4 bitin altında kayıp hızla artar; bu nedenle 2 bite sıkıştırılmış 70B bir model, genellikle aynı nesilden 4 bitlik 32B bir modelden daha kötü yanıt verir. Bellek kısıtlıysa, 4 bitin altına düşmeden önce bir boyut sınıfı küçültmeyi tercih edin.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

Yukarıdaki ağırlık sütunu, milyar başına 0.6 GB kuralının uygulanmış halidir. Gerçek GGUF dosyaları bu değerin birkaç yüzde yakınına denk gelir, çünkü embedding ve çıktı katmanları geri kalanından daha yüksek hassasiyette tutulur. 4 bitlik 3B bir model yaklaşık 1.8 GB'tır. 8B bir model 4.8 GB'tır. 32B bir model 19.2 GB ve 70B bir model 42 GB'tır.

Bağlam uzunluğu neden ağırlıklardan daha fazla RAM tüketir?

KV cache (anahtar-değer önbelleği; modelin o anki konuşmadaki her token için tuttuğu dikkat durumu), ikinci maliyet kalemidir. Model yüklendiğinde, talep ettiğiniz bağlam uzunluğuna göre boyutlandırılarak tahsis edilir ve bu uzunlukla doğru orantılı olarak artar.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Ollama'nın varsayılan bağlam ayarında, bu 8B model önbellek için yarım gigabayt harcar. 8192 token değerinde 1 GB tüketir. Model kartında belirtilen 128k bağlam uzunluğunda ise, ağırlıkların üç katından fazla olan 16 GB tüketir. 70B modelde durum tam tersidir: 128k bağlamdaki önbelleği 40 GB'dir ve kendi ağırlıklarından daha düşüktür; çünkü grouped query attention mekanizması, token başına düşen maliyetin parametre sayısına yakın bir hızda büyümesini engeller.

Ollama'nın varsayılan bağlam uzunluğu, yalnızca CPU kullanılan sunucularda 4096 tokendır. GPU mevcut olduğunda ise varsayılan değer VRAM kapasitesine göre seçilir: 24 ile 48 GiB arasında 32k, 48 GiB ve üzerinde ise 256k. Bu değeri sunucu üzerindeki OLLAMA_CONTEXT_LENGTH değişkeni ile artırabilir, ardından çalışan bir modelin gerçekte ne kadar değer aldığını ollama ps içindeki CONTEXT sütunundan kontrol edebilirsiniz. Bu ayarın arkasındaki bellek hesaplamaları num_ctx ve bağlam uzunluğu hakkındaki yazı içerisinde detaylandırılmıştır.

Önbellek maliyetini düşürmenin iki yolu vardır. Model kartında belirtilen bağlam uzunluğu yerine ihtiyacınız olanı talep edin; zira çoğu sohbet ve kodlama işi 8k ile 32k arasına sığar. Alternatif olarak, önbelleğin kendisini 8 bite kuantize ederek boyutunu yarıya indirebilirsiniz; ancak bu durum uzun bağlam hatırlama başarısında bir miktar kayba yol açabilir.

Yerleşik bir model, bir şey onu bellekten boşaltana kadar RAM'i işgal eder

Ollama, son istekten sonra bir modeli 5 dakika boyunca bellekte tutar ve ardından boşaltır. Bu varsayılan ayar dizüstü bilgisayarlar için uygundur ancak sunucular için yanlıştır; sunucularda her boşluktan sonra gelen ilk istek, yükleme süresini tekrar beklemek zorunda kalır.

ollama ps
ollama stop qwen3:4b

ollama ps, bellekte nelerin yerleşik olduğunu listeler; SIZE sütunu ne kadar bellek tutulduğunu, UNTIL sütunu ise sürenin ne zaman dolacağını gösterir. Bir modeli kalıcı olarak sabitlemek için serviste OLLAMA_KEEP_ALIVE=-1 ayarını yapılandırın. 0 değeri, her yanıt tamamlandığında modeli bellekten boşaltır.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Bir istem gönderin ve ardından on dakika sonra ollama ps komutunu tekrar çalıştırın. Model hala listelenmektedir; tam olarak amaçlanan da budur: kimse kullanmasa bile o RAM'i tutmaya devam eder. Sabitlenmiş bir model, boş kapasite değildir. 16 GB RAM'e sahip bir VPS üzerinde 8k bağlam (context) ile çalışan 8B bir model, servis çalıştığı sürece yaklaşık 6 GB yer kaplar. Bu nedenle sunucu boyutunu yalnızca modele göre değil, model artı uygulamanızın toplam ihtiyacına göre belirleyin. Bir modeli belleğe sabitleme bölümü, soğuk başlatma gecikmesine karşı yapılan bu takası ele almaktadır.

4 GB VPS üzerinde neler çalıştırılabilir

İşletim sistemi ve model sunucusu için yaklaşık 1 GB ayırın; bu durumda geriye kabaca 3 GB kalır. Bu kapasite, varsayılan 4096 token bağlamında, 4 bit seviyesinde 1B ile 4B arası bir modele denk gelir. Ağustos 2026 itibarıyla bu sınıfa 3B boyutunda Llama 3.2, 1.7B ve 4B boyutlarında Qwen 3 ile küçük Gemma ve Phi sürümleri girmektedir. Bunları öneri olarak değil, boyut örnekleri olarak değerlendirin. İsimler birkaç ayda bir değişse de matematiksel hesaplama değişmez.

Saniyede kabaca 6 ile 14 arasında token üretimi bekleyin. Bu kadar küçük modeller dar kapsamlı işlerde başarılıdır: sınıflandırma, etiket çıkarma, kısa özetler ve bir paragrafı kurum diline göre yeniden yazma. Çok adımlı akıl yürütme ve birden fazla dosyayı kapsayan kod yazma konularında zayıftırlar; hiçbir istem (prompt) mühendisliği bu durumu düzeltemez.

Bu seviyedeki hata modu swap kullanımıdır. Model belleğe sığmazsa, Linux yüklemeyi reddetmez. Bunun yerine belleği diske aktarır (page out); tek bir token üretmek tüm ağırlıkların bir kez okunmasını gerektirdiğinden, üretim hızı token başına saniyelere düşer. Model yanıt verirken free -h komutunu ve vmstat 1 çıktısındaki si ve so sütunlarını izleyin. Üretim sırasında swap in ve swap out değerlerinin sıfırdan farklı olması, modelin mevcut plan için çok büyük olduğu anlamına gelir.

8 ile 16 GB RAM kapasiteli bir VPS üzerinde neler çalıştırılabilir

Self-hosted bir modelin genel olarak kullanışlı hale geldiği nokta burasıdır. 8 GB RAM üzerinde, 8k bağlam (context) uzunluğu ile 4-bit kuantize edilmiş 7B veya 8B boyutunda bir model çalıştırabilirsiniz; bu yaklaşık 4.8 GB ağırlık demektir. 16 GB RAM üzerinde ise 4-bit kuantize edilmiş 13B veya 14B boyutunda bir model çalıştırabilir (yaklaşık 8.4 GB) ya da belleği parametre sayısı yerine hassasiyete ayırmak isterseniz 8B boyutundaki bir modeli 8-bit olarak kullanabilirsiniz.

Buradaki temel kısıt hızdır. CPU üzerinde çalışan 8B boyutunda bir model saniyede yaklaşık 3 ile 7 arasında token üretirken, 14B boyutundaki bir model saniyede 1.5 ile 3.5 arasında token üretir. Bir insan saniyede yaklaşık 5 ile 10 token okuyabildiği için, CPU tabanlı bir VPS üzerinde 8B model kullanmak yavaş bir daktilo kullanıcısını izlemek gibidir. Bu durum arka plan görevleri için kabul edilebilir olsa da interaktif sohbetlerde yorucu olabilir. VPS üzerinde Qwen 3 8B ve daha büyük modellerle yapılan ölçümlü çalıştırmalar, bu durumun pratikte nasıl göründüğünü ortaya koymaktadır.

32 GB ile 64 GB arası VPS üzerinde neler çalışır?

4 bit seviyesindeki 32B bir model yaklaşık 19.2 GB yer kaplar; bu nedenle kısa bir bağlam (context) ile 32 GB'lık bir plana sığar ve 48 GB veya 64 GB üzerinde rahatlıkla çalışır. 4 bit seviyesindeki 70B bir model ise yaklaşık 42 GB yer kaplar; dolayısıyla herhangi bir önbellek (cache) eklemeden önce 64 GB belleğe ihtiyaç duyar.

Ardından hız konusunu gerçekçi bir şekilde değerlendirin. CPU üzerinde çalışan 32B bir model saniyede yaklaşık 0.6 ile 1.5 token, 70B bir model ise 0.2 ile 0.5 token hızında çalışır. 70B bir modelden 500 tokenlık bir yanıt almak yaklaşık yirmi dakika sürer. Bunlar toplu işleme (batch) araçlarıdır. Belgelerden oluşan bir kuyruğu gece boyunca bu modellere beslerseniz hızın bir önemi kalmaz. Ancak bunları bir sohbet penceresinin arkasına koyarsanız hız kritik bir önem taşır.

Mixture of experts (MoE) yönlendirmesi bu hesaplamayı değiştirir ve öğrenmeye değer tek mimari detay budur. Bir MoE modeli, her token'ı ağırlıklarının yalnızca küçük bir kısmından geçirir. Toplam 30B parametreye sahip ve token başına 3B aktif parametre kullanan bir model, 30B'lik bir modelin bellek ihtiyacına sahiptir ancak 3B'lik yoğun (dense) bir modelin hızına yakın bir performans sergiler; çünkü her token yalnızca aktif uzmanları okur. 32 GB'lık bir sunucuda bu yapıdaki bir MoE, yoğun bir 30B modelinden çok daha kullanışlıdır. Akılda tutulması gereken kural şudur: toplam parametreler bellek ihtiyacını, aktif parametreler ise hızı belirler.

CPU çıkarım hızı gerçekte ne kadardır?

Bir token üretmek, aktif olan tüm ağırlıkların bellekten bir kez okunmasını gerektirir. Bundan kaçınmanın bir yolu yoktur; dolayısıyla CPU üzerindeki üretim hızı çekirdek sayısına değil, bellek bant genişliğine bağlıdır. Üst sınır şu bölme işlemiyle belirlenir: kullanılabilir bellek bant genişliği, ağırlıkların bayt cinsinden boyutuna bölünür. Küçük bir paylaşımlı VPS, vCPU'ları üzerinden gerçekçi olarak saniyede 10 ila 25 GB arası hız sunar; bu nedenle 4.8 GB boyutundaki bir model saniyede yaklaşık 2 ila 5 token hızında çalışır.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Bu değerler, tek bir makinenin kıyaslama sonucu değil, standart VPS donanımlarında yaygın olarak bildirilen aralıklardır. Elde edeceğiniz sonuç; bellek nesline, ana makinedeki kanal sayısına ve aynı kaynak için yarışan komşu süreçlerin sayısına bağlıdır. Kendi hızınızı, halihazırda sahip olduğunuz herhangi bir model etiketiyle ölçün:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Cevap tamamlandıktan sonra yazdırılan özet, eval rate: ... tokens/s ifadesini içeren bir satırla biter. Bu, üretim hızınızdır. Bir oturumun ilk çalıştırmasını dikkate almayın, çünkü aynı özet içindeki load duration değeri ağırlıkların diskten okunma süresini de içerir. Token hızını doğru ölçme rehberi, karşılaştırmaya değer bir verinin nasıl elde edileceğini açıklar.

Burada iki sonuç kullanıcıları şaşırtır. vCPU eklemek kısa sürede etkisini yitirir; çünkü yaklaşık 8 çekirdekten sonra ek çekirdekler aritmetik işlem yapmak yerine belleği bekler. Ayrıca paylaşımlı bir planda aynı komut saatten saate farklı sonuçlar verir; bu durum sizin yanlış yapılandırmanızdan değil, gürültülü komşudan kaynaklanan CPU çalınma süresi ile ilgilidir.

İsteminizin okunması, cevabın üretilmesinden farklı bir işlemdir. İstem işleme süreci hesaplama yoğunlukludur, bu nedenle çekirdek sayısıyla ölçeklenir ve GPU'nun en büyük farkı attığı alan burasıdır. Uzun bir dokümanı okumak CPU için dakikalar sürerken, GPU için saniyeler sürer. Kodlama aracını kendi barındırdığınız bir modele yönlendirdiğinizde çarptığınız ilk engel budur; çünkü cevap üretilmeden önce her adımda dosya bağlamı ve araç tanımları yeniden gönderilir.

GPU eklediğinizde ne değişir

Aritmetik değişmez, yalnızca uygulandığı havuz değişir. VRAM kesin bir sınırdır, bu nedenle kiralamadan önce neyin sığacağını hesaplayın:

• 8 GB VRAM, kısa bir bağlam (context) ile 4 bitlik bir 7B veya 8B modeli barındırır.
• 16 GB VRAM, gerçek bir bağlam ile 4 bitlik bir 14B modelini veya 8 bitlik bir 8B modelini barındırır.
• 24 GB VRAM, kısa tutulan bir bağlam ile 4 bitlik bir 32B modelini barındırır.
• 48 GB ve üzeri, önbellek ve eşzamanlılık için yer bırakarak 4 bitlik bir 70B modelini barındırır.

Bir model sığmadığında Ollama onu böler: katmanların bir kısmı GPU'da, geri kalanı CPU'da çalışır. ollama ps, bu bölünmeyi PROCESSOR sütununda 78%/22% CPU/GPU gibi bir ifadeyle raporlar. Bunu bir özellikten ziyade bir uyarı olarak değerlendirin. CPU tarafı hızı belirler, çünkü her token hala o katmanları beklemektedir; bu nedenle katmanlarının dörtte biri CPU'da olan bir model, GPU hızından ziyade CPU hızına çok daha yakın çalışır. Beklemediğiniz bir bölünme görürseniz, önce bağlam uzunluğunu düşürün. Sınırı aşan genellikle önbellektir.

Eşzamanlılık, kapasiteyi artırmanın diğer nedenidir. Ağırlıklar eşzamanlı istekler arasında paylaşılır, ancak her aktif isteğin kendi KV önbelleğine ihtiyacı vardır; bu nedenle 8k bağlamda 8B modelini kullanan on eşzamanlı kullanıcı, ağırlıklara ek olarak on kat 1 GB önbelleğe ihtiyaç duyar. Tek bir self-hosted modelden eşzamanlı kullanıcılara hizmet vermek bölümü, bu tavanın nerede oluştuğunu detaylandırır.

Bir GPU kiralamanın mantıklı olup olmadığı da bir aritmetik sorusudur ve ayda kaç token ürettiğinize bağlıdır. GPU VPS ile API tokenları arasındaki başa baş noktası bu rakamları içermektedir.

Neleri kendi sunucunuzda barındıramazsınız

Burada iki farklı engel bulunmaktadır ve hangisiyle karşılaştığınızı bilmek faydalıdır.

Birincisi kapalı ağırlıklardır. Öncü ticari modeller dağıtılmadığı için indirilebilecek bir dosya yoktur ve RAM miktarını ne kadar değiştirirseniz değiştirin bu durum değişmez. Arayüz, erişim katmanı, aracı döngüsü ve günlük kayıtları gibi modelin çevresindeki her şeyi kendi sunucunuzda barındırabilirsiniz. Modelin kendisi ise uzak bir API olarak kalır. Claude modelini kendi sunucunuzda barındırıp barındıramayacağınız konusu bunu tüm detaylarıyla ele almaktadır.

İkincisi ise sadece çok büyük olan açık ağırlıklardır. En büyük açık sürümler, toplam parametre sayısı yüz milyarları bulan uzman karışımı (mixture of experts) tasarımlarıdır. Aynı kural onlar için de geçerlidir: 4 bit seviyesinde 400B toplam parametreli bir model, herhangi bir önbellek hesaba katılmadan sadece ağırlıklar için yaklaşık 240 GB alana ihtiyaç duyar. Bu, uzmanlaşmış donanım gerektirir ve bu donanımı aylık olarak kiralamak, çoğu kişinin bir yılda API token'larına harcadığından çok daha maliyetlidir. Kimi sınıfı bir modeli kendi sunucunuzda barındırmanın gereklilikleri gerçek ihtiyaçları adım adım açıklar.

İkisi arasındaki dürüst ayrım şudur: Yük sabit olduğunda ve veriler sunucunuzdan çıkmaması gerektiğinde kendi sunucunuzda barındırın. Yük düzensiz olduğunda veya gerçekten ihtiyaç duyduğunuz şey öncü modellerin yanıt kalitesi olduğunda token satın alın.

Seçim yapmadan önce mevcut kaynakları kontrol edin

free -h
nproc
lscpu | grep 'Model name'

Planlamanızı free -h tablosunun available sütununa göre yapın, total sütununu kullanmayın; çünkü total sistemin halihazırda kullandığı belleği de kapsar. İşletim sistemi ve model sunucusu için yaklaşık 1 GB değerini çıkarın. Kalan miktarı 0.6'ya bölerek 4-bit seviyesinde çalıştırabileceğiniz en yüksek milyar parametre sayısını elde edin. Ardından, kullanmayı planladığınız bağlam (context) için gerekli KV önbelleğini (cache) çıkarın. Geriye kalan değer sizin cevabınızdır; model isimlerinden oluşan bir listenin aksine bu hesaplama güncelliğini yitirmez.

FAQ

8B bir modeli çalıştırmak için ne kadar RAM gerekir?

4 bit kuantizasyon ile ağırlıklar için yaklaşık 4.8 GB, buna ek olarak bağlam uzunluğunuz için KV önbelleği ve işletim sistemi ile model sunucusu için yaklaşık 1 GB RAM gerekir. 8192 token bağlam uzunluğunda önbellek yaklaşık 1 GB ek yük getirir; bu nedenle 8 GB'lık bir plan yeterli olurken 4 GB'lık bir plan yetersiz kalır. Model kartında belirtilen tam 128k bağlam uzunluğunu kullanmak isterseniz, sadece önbellek 16 GB yer kaplar ve 32 GB'lık bir plana ihtiyaç duyarsınız.

VPS üzerinde çok sayıda vCPU olmasına rağmen modelim neden yavaş?

Çünkü üretim hızı çekirdek sayısına değil, bellek bant genişliğine bağlıdır. Her token, tüm aktif ağırlık setinin RAM'den çekilmesini gerektirir; bu nedenle birkaç çekirdek bellek kanallarını doyurduğunda, geri kalan çekirdekler sadece bekler. Diğer yaygın neden ise swap kullanımıdır. Eğer model yanıt verirken vmstat 1 komutu sıfırdan farklı si ve so değerleri gösteriyorsa, ağırlıklar RAM'e sığmıyor demektir. Bu durumda her token'ın bir kısmı diskten servis edilir ve bu işlem beklenenden çok daha yüksek maliyetli bir gecikmeye yol açar.

Daha uzun bir bağlam penceresi gerçekten daha fazla bellek gerektirir mi?

Evet, bellek kullanımı token sayısı ile doğrusal oranda artar. Tipik bir 8B model, token başına yaklaşık 128 KiB KV önbelleği kullanır; bu nedenle 8192 token 1 GB, 131072 token ise 16 GB maliyet getirir. Önbellek, konuşma uzadıkça değil, model yüklendiği anda rezerve edilir. Bu yüzden 128k bağlam uzunluğu talep ettiğinizde, gönderdiğiniz her istem sadece 200 token uzunluğunda olsa bile bu bellek miktarı en baştan ayrılır.

Büyük bir modeli 2 bit ile mi yoksa daha küçük bir modeli 4 bit ile mi çalıştırmalıyım?

Daha küçük olanı 4 bit ile çalıştırmayı tercih edin. Kalite 8 bitten 4 bite kadar yavaş, 4 bitin altında ise hızla düşer. Bu nedenle 2 bite sıkıştırılmış 70B bir model, genellikle aynı model nesline ait 4 bitlik 32B bir modelden daha kötü yanıtlar verir. Ağır kuantizasyon, hata mesajı yerine tekrara düşme ve talimatları göz ardı etme şeklinde kendini gösterir; bu da sorunu isteminize bağlamanıza neden olabilir. 4 biti alt sınır olarak kabul edin ve bunun yerine parametre sayısını değiştirin.

Büyük ticari modeller kadar yetenekli bir modeli kendi sunucumda barındırabilir miyim?

Sıradan bir VPS üzerinde hayır. En güçlü açık ağırlıklı modeller yüz milyarlarca parametreye sahiptir; bu da 4 bit seviyesinde, herhangi bir KV önbelleği hesaba katılmadan bile 200 GB'ın üzerinde RAM gerektirir. En güçlü ticari modeller ise zaten dağıtılmamaktadır. Sıradan donanımların başarılı olduğu alan, belirli bir iş için iyi bir 8B ile 32B arası model çalıştırmaktır; burada dar kapsamlı ve iyi yapılandırılmış küçük bir model, genel amaçlı bir modelle sıklıkla aynı performansı gösterir. Eğer en üst düzey kaliteye ihtiyacınız varsa, donanım satın almadan önce API maliyetini donanım maliyetiyle kıyaslayın.